From andy.sago@bt.com Wed Feb 1 02:34:22 2012 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 0FBF921F861B for ; Wed, 1 Feb 2012 02:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvV06vjzH3Lq for ; Wed, 1 Feb 2012 02:34:12 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 6674F21F8606 for ; Wed, 1 Feb 2012 02:34:11 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 1 Feb 2012 10:34:10 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Wed, 1 Feb 2012 10:34:09 +0000 From: To: , , , Date: Wed, 1 Feb 2012 10:34:07 +0000 Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM4GhgAXLRm0MfH0eU5prccikhbJYnpdQQgAAi1DA= Message-ID: <619CDADDCCD2B44380834BE8BF6F714140653B4DF6@EMV62-UKRD.domain1.systemhost.net> References: <23293D9BB25E0B48A038B78C7D1D0D5C01E6017B@008-AM1MPN1-021.mgdnok.nokia.com> In-Reply-To: <23293D9BB25E0B48A038B78C7D1D0D5C01E6017B@008-AM1MPN1-021.mgdnok.nokia.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F714140653B4DF6EMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 01 Feb 2012 10:34:22 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140653B4DF6EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV = white spaces, whereas the scope of PAWS is white spaces in general. I would= question not only why the lower-priority service would always be licence-e= xempt, but why the higher priority service would always be licenced. To avo= id this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/= paws/current/msg00576.html) a revision of the Abstract that avoids the term= s licence exempt or unlicensed, or any mention of the regulatory status of = the incumbent services. The Abstract derives from the Introduction and the = text could be aligned to be the same in the Introduction, with "opportunist= ic" replacing "secondary" in later sentences in the Introduction. I have ch= ecked and there are no further references to licensing in the document, so = we don't need the definitions of licence exempt, light licensing or unlicen= sed. This is not a regulatory document - we are defining requirements fora = protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum= use has now got muddled with the potential for opportunistic use. This can= be fixed by taking the white space and white space device definitions toge= ther. From Scott, Gerald and Jussi's comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum= , under control of a white space database. A white space device can be an = access point, base station, a portable device or similar. In this context,= a white space device is required by local regulations to query a database = with its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jus= si.kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not= necessarily apply to all under-utilised radio spectrum. Why would the lowe= r priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Geral= d Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed by = local regulations for use to be used opportunistica= lly as licensed-exempt spectrum under control of a white space data= base. This way, it is understood that the database does not "assign" white space = devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= "Protected Entity" and "White Space Devices (WSD)" where the notion of sec= ondary use is included. The secondary status is used in the ITU-R Radio Re= gulations for a different purpose. In fact, it is possible that a band has= already primary and secondary services allotted to it and that the White S= pace operation is a tertiary opportunistic operation where the two first ty= pes of services are not being used. The use of "lower priority opportunist= ic" service rather than "secondary" service would be preferable to describe= white space allocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use<= /Delete>and assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unl= icensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an "unlicensed" band is typically a new ba= nd, say in the 300 GHz, for which no request has been made for its use. It= is therefore un-allocated to a specific service so far and thus it is an "= unlicensed" frequency band. Once the ITU-R allocates this band to one or ma= ny services on a primary or secondary basis, then the administrations can t= hendecide under what king of regime it will 'assign' this band foroperation= . They may decide to allow the use of the band on the basis of licensed ope= ration (with different options to do the assignment: auction, first come/fi= rst served, etc.) or allow operation with an exemption of licenses, thus "l= icense-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicen= sed" in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a "license-exempt" operation. If, h= owever, someone decides to start an RF transmission operation in a licensed= band for which he has no license or in a license-exempt band for which he = does not meet the requirements such as operating according to the type of o= peration for which the band is exempted from a license or he operates outsi= de the technical limits imposed by this license-exempt ruling, his operatio= n is therefore illegal and he is then considered to be running an "unlicens= ed" operation. If the qualifier applies to the transmission device, such device may be a "= license-exempt" device if its operation does not require a specific license= or registration with the local administration such as TV receivers of Wi-F= i devices in the 2.4 GHz ISM band. However, if someone smuggles a device t= hat is not allowed in a country by, for example, buying it on eBay and oper= ates it, this is then an illegal device in the country and id de-facto an "= unlicensed" device since it has not passed through the normal certification= process. Note that a "license-exempt" device still has to go through a certification= process and meet the limits imposed by the local regulator for the "licens= e-exempt" operation in the given frequency band whereas an "unlicensed" dev= ice may not pass the certification process since it has not been licensed t= o operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the = footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licens= ed" operation, the situation will be much simpler to manage since specific = conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word'unlicensed' which may mean 'illegal' operation= of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as 'license-exempt', in most cases the t= erm 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe = a legal operation because the term "license-exempt" has been used for anoth= er specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of 'licensed' and 'license-exempt' with a foo= tnote indicating that the term 'unlicensed' is used in the USA instead of t= he usual 'license-exempt'. Gerald _______________________________________________ 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 --_000_619CDADDCCD2B44380834BE8BF6F714140653B4DF6EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott, All

 

I agree with Jussi = that we have now narrowed the definition to apply to TV white spaces, where= as the scope of PAWS is white spaces in general. I would question not only = why the lower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27= th Jan I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00= 576.html) a revision of the Abstract that avoids the terms licence exem= pt or unlicensed, or any mention of the regulatory status of the incumbent = services. The Abstract derives from the Introduction and the text could be = aligned to be the same in the Introduction, with “opportunistic”= ; replacing “secondary” in later sentences in the Introduction.= I have checked and there are no further references to licensing in the doc= ument, so we don’t need the definitions of licence exempt, light lice= nsing or unlicensed. This is not a regulatory document – we are defin= ing requirements fora protocol. Keep it simple.

 

That just leaves the definition= of white space, where the existing spectrum use has now got muddled with t= he potential for opportunistic use. This can be fixed by taking the white s= pace and white space device definitions together.  From Scott, Gerald = and Jussi’s comments perhaps we could agree on:

=

 

White Space (WS)

 

= Radio spectrum which is not fully occupied at a specific = location and time.

 

Whit= e Space device

=  

A devi= ce which opportunistically uses some part of the white space spectrum, unde= r control of a white space database.  A white space device can be an a= ccess point, base station, a portable device or similar.  In this cont= ext, a white space device is required by local regulations to query a datab= ase with its location to obtain information about available spectrum.<= /o:p>

 

Regards

=  

Andy

 

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.= org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 Februar= y 2012 07:31
To: gerald.chouinard@sympatico.ca; scott.probasco@no= kia.com; paws@ietf.org
Subject: Re: [paws] Use cases and requirem= ents I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior= Work)

 

That statement is valid for TV White Spa= ces on UHF frequencies but does not necessarily apply to all under-utilised= radio spectrum. Why would the lower priority service by default be licence= -exempt?

 =

Kind regards,

<= p class=3DMsoNormal>Jussi

=  

From: paws-boun= ces@ietf.org [mailto:= paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
S= ent: 31 January 2012 22:33
To: Probasco Scott (Nokia-CIC/Dall= as); paws@ietf.org
Subject: = Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, C= onventions and Terminology, Prior Work)

 

Scott,

&nbs= p;

Very good improvemen= ts. I would suggest to insert the notion of opportunistic use of the spectr= um by white space devices in the last sentence of the definition of “= white space” as follows:

 

White Space=

 

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'>Radio spectrum which has been allocated and assigned for l= icensed use, but is not fully occupied by that licensed use at a specific l= ocation and time. This spectrum is then <delete>assigned<delete>= ; <insert>allowed<insert> by local regulations <delete>fo= r use<delete> <insert>to be used opportunistically<insert>= ; as licensed-exempt spectrum under control of a white space database.</= Insert>

&n= bsp;

This way, it is un= derstood that the database does not “assign” white space device= s for them to choose from.

 

Ge= rald

From: <= a href=3D"mailto:scott.probasco@nokia.com">scott.probasco@nokia.com [mailto:scott.probasco@no= kia.com]
Sent: Tuesday, 31 January, 2012 15:12
To:= gerald.chouinard@sympatic= o.ca; paws@ietf.org
Subject:= Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introducti= on, Conventions and Terminology, Prior Work)=

 <= /o:p>

Hi Gerald,=

&= nbsp;

Goo= d to avoid overloading the term "secondary". I have made addition= al proposed changes to the text below based on your suggestion. "Lower= priority opportunistic service" could indeed by used, but I am guessi= ng that we would need some explanation of what that means. Since we now hav= e descriptions of licensed spectrum and license-exempt spectrum, I used the= se words. Do these changes remove your concerns?

 

I also corrected "loca= tion" to "local" in previous text proposed for "White S= pace".

 

Kind Regards,

Scott

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.ca>= ;
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and req= uirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, = Prior Work)

 

Scott,

Great proposal.  However, I am still a bit nervous about the defi= nitions of “Protected Entity” and “White Space Devices (W= SD)” where the notion of secondary use is included.  The seconda= ry status is used in the ITU-R Radio Regulations for a different purpose. &= nbsp;In fact, it is possible that a band has already primary and secondary = services allotted to it and that the White Space operation is a tertiary op= portunistic operation where the two first types of services are not being u= sed.  The use of “lower priority opportunistic” service ra= ther than “secondary” service would be preferable to describe w= hite space allocations.

 <= /span>

Gerald

 

From: paws= -bounces@ietf.org [mailto:paws= -bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56<= br>To: paws@ietf.org
Subject: Re: [= paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conven= tions and Terminology, Prior Work)

 

Hi,

 

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'>I changed the subject line from " Re: [paws] Discussi= on on 'license-exempt' vs 'unlicensed'  ". Here I try to propose = some changes to the draft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. = I have inserted new terms for 'licensed' and 'license-exempt' and made chan= ges to the term 'white space'. I have tried to work from the perspective th= at the document should accurately explain the subject with aim that a reade= r can understand the use cases and the subsequent requirements. No doubt we= could include much more text on this topic of spectrum allocation, assignm= ent, licensing and usage.

 =

I= hope this captures the key points of the discussion. Please do reply if so= mething is still missing.

 =

K= ind Regards,

Scot= t<= /b>

 

 

2.2.  Terminology<= /b>

 

<= p class=3DMsoNormal>   Database

<= div>

 

      In the contex= t of white space and cognitive radio technologies,

      the database i= s an entity which contains current information about

      available spe= ctrum at any given location and other types of

      information.=

<= /div>

 

=

   Device ID=

 

      A unique nu= mber for each master device and slave device that

      identifies the= manufacturer, model number and serial number.

 

= <Insert>

   Licensed Spectrum

 

      Spectrum that is ac= quired by an operator over a given service area

      for a given time p= eriod.  This is usually done through auctions,award

      (beauty c= ontest), acquisition from secondary market, company merger &=

      a= cquisition,  first-come / first-served or by government allocation

     =  (e.g., public service).

 <= o:p>

   License-exempt Spectrum

 

=       Spectrum that is not assigne= d to any specific user. One example is the 2.4 Ghz ISM band, where RF devic= es=

   &= nbsp;  operate without a formal licensing process. In the <= b>USA, license-ex= empt spectrum is

      Typically referred to as "unlicensed= " spectrum. In this document the terms

      license-exempt and unl= icensed are used interchangeably.

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'> 

</Insert>

 <= /o:p>

&n= bsp;  Location Based Service

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'> 

      An application or device which provides d= ata, information or<= o:p>

      service to a user based on their location.

 =

   Master Device

 =

      A de= vice which queries the WS Database to find out the available<= span lang=3DEN-US style=3D'color:black'>

      opera= ting channels.<= /o:p>

&n= bsp;

  = Protected Entity

 

 &nb= sp;    <Insert>A licensed user of spectrum, when the licens= ed spectrum has been assigned as white space spectrum.</Insert> <D= elete>A primary</Delete><Insert>A licensed</Insert> us= er of white space spectrum <Delete>which</Delete> is afforded=

    = ;  protection against interference by <Delete>secondary</Dele= te><Insert>license-exempt white space</Insert> users <Del= ete>(white space<= o:p>

      devices) for its use</Delete> in a given= area and time.=

&= nbsp;

  = ; Protected Contour<= o:p>

 =

 =      The exclusion area for a Protected Entity, held in the = database<= /span>

 =      and expressed as a polygon with geospatial points as th= e vertices.

 = ;<= /b>

   Sl= ave Device

 =

   &nb= sp;  A device which uses the spectrum made available by a master

=

     &n= bsp;device.

 = ;<= /b>

   TV= White Space

&nbs= p;=

   &= nbsp;  TV white space refers specifically to radio spectrum which has<= /span>

   &nbs= p;  been allocated for TV broadcast, but is not occupied by a TV

=

     &n= bsp;broadcast, or other licensed user (such as a wireless microphone),

     &= nbsp;at a specific location and time.

=  

   White Space

=  

      Radio spectrum which has been allocate= d <Delete>for some primary use</Delete><Insert>and assign= ed for licensed use</Insert>, but

      is not fully occupied by t= hat <Delete>primary use</Delete><Insert> licensed use <= ;/Insert> at a specificlocation

=       and time. <Insert>This sp= ectrum is then assigned by <Delete>location</Delete><Insert&= gt;local</Insert> regulations for use as licensed-exempt spectrum und= er control of a white space database.</Insert>

 

   White Space Device (WSD)<= b>

=

 

     A device whic= h is a <Delete>secondary</Delete><Insert>license-exempt&l= t;/Insert> user of some part of white space

      spectrum.  A w= hite space device can be an access point, base

      station, a portable= device or similar.  In this context, a white

      space device i= s required to query a database with its location to

      obtain informa= tion about available spectrum.

 =

 

=  

From: = ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07:30 -05= 00
To: 'Nancy Bravin' <nbrav= in@earthlink.net>
Cc: "paws= @ietf.org" <paws@ietf.org&= gt;
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'=

 <= b>

= <= /span>

Nancy= ,

 

This is not that = simple.  In fact, the qualifiers “license-exempt” and R= 20;unlicensed” can apply to more than one thing.

 

= If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an “unlicensed” band is typica= lly a new band, say in the 300 GHz, for which no request has been made for = its use.  It is therefore un-allocated to a specific service so far an= d thus it is an “unlicensed” frequency band. Once the ITU-R all= ocates this band to one or many services on a primary or secondary basis, t= hen the administrations can thendecide under what king of regime it will &#= 8216;assign’ this band foroperation. They may decide to allow the use= of the band on the basis of licensed operation (with different options to = do the assignment: auction, first come/first served, etc.) or allow operati= on with an exemption of licenses, thus “license-exempt”such as = in the 2.4 GHz ISM band. This is also called “unlicensed” in th= e USA.

 

If the qualifier applies to an operation, the operation can= be exempt of license by the local administration, thus a “license-ex= empt” operation. If, however, someone decides to start an RF transmis= sion operation in a licensed band for which he has no license or in a licen= se-exempt band for which he does not meet the requirements such as operatin= g according to the type of operation for which the band is exempted from a = license or he operates outside the technical limits imposed by this license= -exempt ruling, his operation is therefore illegal and he is then considere= d to be running an “unlicensed” operation.

 

= If the qualifier applies to the transmission device, such device may be a &= #8220;license-exempt” device if its operation does not require a spec= ific license or registration with the local administration such as TV recei= vers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someone sm= uggles a device that is not allowed in a country by, for example, buying it= on eBay and operates it, this is then an illegal device in the country and= id de-facto an “unlicensed” device since it has not passed thr= ough the normal certification process.

 <= /o:p>

Note that a R= 20;license-exempt” device still has to go through a certification pro= cess and meet the limits imposed by the local regulator for the “lice= nse-exempt” operation in the given frequency band whereas an “u= nlicensed” device may not pass the certification process since it has= not been licensed to operation in the country.

<= b> 

This is= why the qualifier “unlicensed” has to be treated with care and= the footnote will need to be crafted very carefully.

 

W= ith respect to your second point, if an administration only allows “l= icensed” operation, the situation will be much simpler to manage sinc= e specific conditions will be attached to these licenses.

 

Gerald

 

From: Nancy Brav= in [mailto:nbravin@earthlink.net]
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc= : Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discus= sion on 'license-exempt' vs 'unlicensed'

 

<= p class=3DMsoNormal>Gabor and G= erald, 

Since we are dealing on a global basis, ca= n there a footnote to "unlicensed" we can use to indicate that &q= uot;according to each countries regulatory requirements"  

How to get around the fact that some Countries are or w= ill be "licensed only" by their gov'ts?  Thanks

Nancy<= /ns0:place>

On Jan 30, 2012, at 4:13 PM, Gerald Chouinar= d wrote:



<= /o:p>

Gabor,<= /p>

 

= I agree with your proposal.  Thisseems to be reasona= ble.  However one needs to be careful with the word‘unlicensed&#= 8217; which may mean ‘illegal’ operation of an RF device in man= y administrations.

 

=

Gerald

=  

From: Gabor.Bajk= o@nokia.com [mailto:Gabor.Bajk= o@nokia.com]
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.ca; paw= s@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs 'un= licensed'

 

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>These look to be very precise definitions, however in ev= eryday use I rarely hear people referring to ISM band as ‘license-exe= mpt’, in most cases the term ‘unlicensed-band’ is used. <= /span>

 

Therefore, may I suggest that the draft will = include the following statement:

 

The terms un= licensed and license-exempt spectrum are used in this document interchangea= bly and refer to a spectrum in which no formal licensing process is needed = for RF devices to operate in, such as the ISM band.

 

- = ;         Gabor

 

From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org]= On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 = PM
To: paws@ietf.org
Subject: [p= aws] Discussion on 'license-exempt' vs 'unlicensed'

 

All,<= span lang=3DEN-US style=3D'color:black'>

 

Here is my understanding of the terms:

 

Licensed= : Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of th= e Telcos), beauty contest, first-come / first-served or by government alloc= ation (e.g., public service).

&= nbsp;

Lightly licensed: Special= case where thefrequency allocation is done through first-come / first-serv= ed process for a given time frame over a relatively limited service area. T= he annual license fee is usually small to facilitate the deployment of a se= rvice that would not normally be economically attractive.  Small local= operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would n= ormally work with full licensing through auction over large service areas.<= /span>

 

License-exempt: Operation of RF devices in a fre= quency band where no formal licensing process is needed such as in the 2.4 = GHz ISM band. In the USA, thi= s term is used for a specific type of operation. The FCC should be contacte= d to clarify it.

 <= /span>

Unlicensed: Illegal operation o= f an RF device that can transmit in a frequency band without a duly issued = license.  In the USA, th= is term is used to mean “license-exempt," see above.

 

To my knowledge, the term “unlicensed” is used = only in the = USA to describe a= legal operation because the term “license-exempt” has been use= d for another specific purpose.

 <= /o:p>

Since the PAWS a= ddresses the interface to the database for the international market, it sho= uld rely on the definition of the terms recognized by the ITU-R. I would su= ggest the use of ‘licensed’ and ‘license-exempt’ wi= th a footnote indicating that the term ‘unlicensed’ is used in = the USA instead of the usual = ‘license-exempt’.

 

Gerald=

_______________________________________________
pa= ws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws

 

____= ___________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws=

= --_000_619CDADDCCD2B44380834BE8BF6F714140653B4DF6EMV62UKRDdoma_-- From stephen.farrell@cs.tcd.ie Wed Feb 1 02:39:30 2012 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 321F921F8655 for ; Wed, 1 Feb 2012 02:39:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_WEOFFER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dT7Ul-Tn7Gy for ; Wed, 1 Feb 2012 02:39:29 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C6B1921F8650 for ; Wed, 1 Feb 2012 02:39:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id F2F2D171C41; Wed, 1 Feb 2012 10:39:26 +0000 (GMT) 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=1328092764; bh=QsKsjw/07nc1xb N+qLvK1+iYNbnmMCNY7jTy5GqZ4fQ=; b=68wdFc6r++MHF57e2sjgjk2kMQ+N+T ca3QVycaQwHFERUL2vuJKvrwaNEzm/wGlp7i9iSyLcWxrx+a1/pL9b01RQvzLJuw v+hI1ZxjIkfS9b0OO2E0SbqIomF78SevyaQpdAqVOrR4Xv7wh6FDhU8WA1SSWJQy 8/3Wi4E5J+DTx2XbiKNojiR1WNlAyRI0o1wb6+8Z9BFGqeGGTaypqi0I8dqZTxAc Ud674o4twsCjnkV/yQEaki6nB6wvnF5b/UQhiCQAsRigVVmCO1fzDCsUmVzugdTB stSjC91NaHHrIZJUaLiEl01H9BLE4vhXwEaTUI6tLR618l40IhzdPxng== 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 Qu884vmkUtwK; Wed, 1 Feb 2012 10:39:24 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A3C4B171C07; Wed, 1 Feb 2012 10:39:17 +0000 (GMT) Message-ID: <4F291656.5020508@cs.tcd.ie> Date: Wed, 01 Feb 2012 10:39:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Rosen, Brian" References: <27AA2A3F470FC14E8E04A5A3699BDDBF081EAC884C@STNTEXCH01.cis.neustar.com> In-Reply-To: <27AA2A3F470FC14E8E04A5A3699BDDBF081EAC884C@STNTEXCH01.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'paws@ietf.org'" Subject: Re: [paws] Threats, Services and Predicatable Availability 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, 01 Feb 2012 10:39:30 -0000 On 02/01/2012 01:22 AM, Rosen, Brian wrote: > We have nice tools to discover the right database. I don't think we will need to use anything but LoST, RFC5222, to discover the right one. Query with your location and a service urn related to the type of device/band/whatever and get back a list of URIs to the database. It's the base of emergency call routing, another government service, so making it secure should be straightforward. Right. I guess this work might or might not (I dunno) require something different or additional in terms of TLS server identity checking but that could be figured out later. S > > Brian > > > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Tuesday, January 31, 2012 05:55 PM Eastern Standard Time > To: Paul Lambert > Cc: paws@ietf.org > Subject: Re: [paws] Threats, Services and Predicatable Availability > > > > On 01/31/2012 07:13 PM, Paul Lambert wrote: >> >> One more observation on threat modeling. Discovering the database is a service: >> >> 4) Support discovery of all authorized databases services for a geographic region. > > Good one. (And presumably withstanding related spoofs will turn out to > be desired too.) > >> Associated threat event would be: >> - Modification of paws protocol messages in transit to prevent discovery of authorized databases >> >> >> When there are multiple authorized database services we need to make sure that all authorized services are available to end devices. >> >> This implies a trust hierarchy with the regulatory authority (Gov based) as a root for a region. New regions are not going to be easy to add ... which is good since any new region also requires some level of regional conformance. > > Well, a hierarchy is a design choice for later I guess. (But clearly > one that'll be a natural idea for some of the involved parties.) > > S > >> >> Paul >> >> >> >>> -----Original Message----- >>> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] >>> Sent: Monday, January 30, 2012 3:35 PM >>> To: Paul Lambert >>> Cc: Basavaraj.Patil@nokia.com; paws@ietf.org >>> Subject: Re: [paws] Threats, Services and Predicatable Availability >>> >>> >>> Sorry to keep on on the same thing, but it doesn't seem >>> to be resonating much;-) >>> >>> The charter says: "Robust privacy and security mechanisms >>> are needed..." >>> >>> I'm guessing its possible an analysis starting from your >>> suggestions below should produce a good result wrt security >>> but maybe less so for privacy (which is less well >>> understood by us all). >>> >>> How about adding "Prevent unnecessary exposure of >>> personally identifying information (PII)" ? >>> >>> Note that the above could me met via encryption of >>> PII, (with possibly high-cost key management) or by >>> just not sending PII when you don't need to which is >>> fairly cheap if you're not forced by regulation to >>> send it. (Since some devices presumably are not >>> personally identifying but others are, then maybe >>> there's a simple enough answer in the end...) >>> >>> S >>> >>> On 01/30/2012 10:29 PM, Paul Lambert wrote: >>>> >>>> Hi Raj, >>>> >>>>> Do you have any proposals or text w.r.t the threat model writeup? >>> Also >>>> >from an IETF perspective regarding threat models, please see Peter's >>>>> email: http://www.ietf.org/mail- >>> archive/web/paws/current/msg00592.html >>>>> >>>>> -Raj >>>> >>>> I'll spend a little time formalizing the ideas I submitted below. >>> However, "threats" are part of a complete set of requirements and >>> looking at the current proposal, I feel we need to clarify the service >>> that we offer before we can say what are real threats. Specifically, >>> the threat: >>>> >>>>>>> device which can be used maliciously. The effect of such an >>>>>>> attack being successful would result in a malicious client >>>>>>> replaying the stolen authentication/authorization secrets to >>> a >>>>>>> white space database. >>>> >>>> This is not a threat as worded... but why? >>>> >>>> We need to define what we offer, and then things that prevent or break >>> these offered services are potential risks that can be mapped to >>> threats. As a start, I propose (which I hope is mostly in line with the >>> use cases) two main services with some subtopics: >>>> >>>> 1) Prevent Interference of License-exempt Use with Licensed Operation >>> >>>> - Support changes in channel, time Period and region for licensed >>> operation >>>> - Support predictable availability of licensed channels >>>> - Support the ability to disable specific vendor/model-types from >>> operation when >>>> they are determined to be causing interference >>>> 2) Enable Authorized Channel Utilization for License-exempt Operation >>> >>>> - Facilitate fixed use of channels >>>> - Facilitate mobile use of channels >>>> - Facilitate indoor use of channels >>>> - Support predictable availability of license-exempt channels >>>> - Support changing of authorized channels to prevent interference >>> with licensed usage >>>> >>>> So, threat event is something that has a result of preventing the >>> promised services. The threat event either causes unapproved >>> interference with licensed operation, or it prevents White Space >>> "license-exempt" operation. >>>> >>>> The "Support Predictable Availability" is something new I'd like to >>> introduce for discussion. There needs to be a expectation that once you >>> are using a channel that your use will not be terminated abruptly in an >>> unanticipated manner. Right now - we are creating mechanism to quickly >>> cutoff a device for any reason at all (for the use case of mobile >>> microphones). This is actually supposed to be a predictable event with >>> some type of scheduling. An license-exempt devices needs to be able to >>> determine how long it might operate under the regulations in a >>> particular channel/region. Building a system where you never know when >>> your communications might get cut off seems like a bad idea. >>>> >>>> >>>> >>>> Paul >>>> >>>> >>>>> >>>>> On 1/27/12 5:24 PM, "ext Paul Lambert" wrote: >>>>> >>>>>> It's good to have requirements based on such an analysis. This is >>> an >>>>>> interesting start, but we may be mixing threats, vulnerabilities and >>>>>> mechanisms. >>>>>> >>>>>> Threats are typically tied to an actor ... human or not. I'm not >>> sure >>>>>> it's worth going hard over to something like the NIST 800-30 >>>>> definitions >>>>>> of threats, but within this framework the threats are Governments, >>>>>> disgruntled insiders, tsunamis etc. Being the IETF we can jump more >>>>>> quickly to the threat event and specifics of an attack, but should >>> at >>>>>> least expand threats to include natural events and connectivity >>>>> problems. >>>>>> Robustness or emergency modes might be interesting to consider. >>>>>> >>>>>> We also have a problem in this analysis of perspective - are we >>>>>> considering threats as viewed from regulatory agency or the end >>> device >>>>>> owner or both. We should consider both - but they are contradictory >>>>>> perspectives. Users want continuity of service. Governments (the >>>>>> regulators) want control of the airwaves. >>>>>> >>>>>> Most of the real threats that we have are nearly impossible to >>> prevent >>>>> at >>>>>> the protocol level. It's still worth examining the threats to see >>>>> where >>>>>> we stand. >>>>>> >>>>>> On the current document threats: >>>>>> >>>>>>> o It is assumed that the master device or the white space database >>>>>>> have NOT been compromised from a security standpoint. >>>>>>> >>>>>>> Threat 1: Obtain master device authentication/authorization secrets >>>>>>> The master device needs to authenticate itself with the >>> white >>>>>>> space database prior to requesting channel information. The >>>>>>> attacker may try to get access to the secrets of the master >>>>>>> device which can be used maliciously. The effect of such an >>>>>>> attack being successful would result in a malicious client >>>>>>> replaying the stolen authentication/authorization secrets to >>> a >>>>>>> white space database. >>>>>> This does not seem consistent with the prior statement of "not >>>>>> compromised". >>>>>> Restatement >>>>>> >>>>>> Threat: User modifies a device to masquerade as another valid >>> certified >>>>>> device. >>>>>> >>>>>> This is an interesting case where threat/vulnerability/risk play >>>>>> together. The FCC or other regulatory agencies want traceability of >>>>>> devices. If a user wants to run a rogue radio, there is no reason >>> to >>>>>> access the database (low risk - no payoff). The only reason this >>> would >>>>>> be an interesting attack might be to avoid tracking and have some >>>>>> anonymity. >>>>>> >>>>>>> Threat 2: Spoofed white space database >>>>>>> A master device discovers a white space database(s) thru >>> which >>>>>>> it can query for channel information. The master device >>> needs >>>>>>> to ensure that the white space database with which it >>>>>>> communicates with is an authentic entity. The white space >>>>>>> database needs to provide its identity to the master device >>>>>>> which can confirm the validity/authenticty of the database. >>> An >>>>>>> attacker may attempt to spoof a white space database and >>>>>>> provide responses to a master device which are malicious and >>>>>>> result in the master device causing interference to the >>> primary >>>>>>> user of the spectrum. >>>>>> >>>>>> I think this is two types of threat events: >>>>>> - malicious denial of service or intentional interference with >>>>> incumbents >>>>>> - impersonation of white space database to enable operation of a >>>>> device >>>>>> that may >>>>>> not otherwise be possible (blocked device, unallocated channels). >>>>>> This may or may not >>>>>> interfere with incumbent devices >>>>>> >>>>>>> Threat 3: Modifying a query request >>>>>> ... >>>>>> >>>>>>> Threat 4: Modifying a query response >>>>>> Seems like these two could be lumped together ...MiTM modifies >>> protocol >>>>>> messages to: >>>>>> - deny service >>>>>> - interfere with incumbents >>>>>> - provide unauthorized channel usage (most likely risk IMHO) >>>>>> >>>>>>> Threat 5: Using query response information >>>>>>> An attacker may be a master device which is not certified >>> for >>>>>>> use by the relevant regulatory body. The attacker may listen >>> to >>>>>>> the communication between a valid master device and white >>> space >>>>>>> database and utilize the information about available >>> channels >>>>>>> in the response message by utilizing those channels. The >>> result >>>>>>> of such an attack is unauthorized use of channels by a >>> master >>>>>>> device which is not certified to operate. >>>>>> As stated this is a mechanism - a clearer statement might be. >>>>>> >>>>>> Threat: Unauthorized use of channels by an uncertified device. >>>>>> >>>>>> Anyone can already go to a database and find available channels. If >>> a >>>>>> device can operate without going to the database there is nothing >>> that >>>>>> paws can do to stop it operating in available or non-available >>>>> channels. >>>>>> >>>>>> Just to get some discussion going -here's a couple more possible >>>>> threats.. >>>>>> >>>>>> Threat: Third party tracking of white space device location >>>>>> Likely a valuable commodity to sell for advertizing with no >>>>> technical >>>>>> design or policy for privacy >>>>>> Threat: Database owner termination of device service for reasons >>> other >>>>>> than incumbent protection >>>>>> >>>>>> >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>> >>>> _______________________________________________ >>>> 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 nbravin@earthlink.net Wed Feb 1 06:35:25 2012 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 9191411E8359 for ; Wed, 1 Feb 2012 06:35:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lP2rRqJk1un7 for ; Wed, 1 Feb 2012 06:35:22 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5A13F11E811B for ; Wed, 1 Feb 2012 06:35:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=e1uUQfQcksX8JexHiUOY3Z47EnilRFHKShrE2Rj1sA8u92kH38X5SxdCMmLK9Z9i; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RsbHC-0004XJ-Qc; Wed, 01 Feb 2012 09:35:13 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2--240125192 From: Nancy Bravin In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140653B4DF6@EMV62-UKRD.domain1.systemhost.net> Date: Wed, 1 Feb 2012 06:35:09 -0800 Message-Id: References: <23293D9BB25E0B48A038B78C7D1D0D5C01E6017B@008-AM1MPN1-021.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F714140653B4DF6@EMV62-UKRD.domain1.systemhost.net> To: Andy Sago X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad867f43d80b85e5035458159e4ff9a4e8c8350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 01 Feb 2012 14:35:25 -0000 --Apple-Mail-2--240125192 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Andy, All In section 4.4, license exempt is also mentioned as well.=20 I am conflicted in a global sense when emerging countries, or countries = with very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby = join the existing DB companies, or will they do their own thing leaving holes in what one hopes will be an interoperable global protocol = that deals with TVWS, and/or White spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, wrote: > Scott, All > =20 > I agree with Jussi that we have now narrowed the definition to apply = to TV white spaces, whereas the scope of PAWS is white spaces in = general. I would question not only why the lower-priority service would = always be licence-exempt, but why the higher priority service would = always be licenced. To avoid this issue on 27th Jan I proposed = (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a = revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent = services. The Abstract derives from the Introduction and the text could = be aligned to be the same in the Introduction, with =93opportunistic=94 = replacing =93secondary=94 in later sentences in the Introduction. I have = checked and there are no further references to licensing in the = document, so we don=92t need the definitions of licence exempt, light = licensing or unlicensed. This is not a regulatory document =96 we are = defining requirements fora protocol. Keep it simple. > =20 > That just leaves the definition of white space, where the existing = spectrum use has now got muddled with the potential for opportunistic = use. This can be fixed by taking the white space and white space device = definitions together. =46rom Scott, Gerald and Jussi=92s comments = perhaps we could agree on: > =20 > White Space (WS) > =20 > Radio spectrum which is not fully occupied at a specific location and = time. > =20 > White Space device > =20 > A device which opportunistically uses some part of the white space = spectrum, under control of a white space database. A white space device = can be an access point, base station, a portable device or similar. In = this context, a white space device is required by local regulations to = query a database with its location to obtain information about available = spectrum. > =20 > Regards > =20 > Andy > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of jussi.kahtava@nokia.com > Sent: 01 February 2012 07:31 > To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > That statement is valid for TV White Spaces on UHF frequencies but = does not necessarily apply to all under-utilised radio spectrum. Why = would the lower priority service by default be licence-exempt? > =20 > Kind regards, > Jussi > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard > Sent: 31 January 2012 22:33 > To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Scott, > =20 > Very good improvements. I would suggest to insert the notion of = opportunistic use of the spectrum by white space devices in the last = sentence of the definition of =93white space=94 as follows: > =20 > White Space > =20 > Radio spectrum which has been allocated and assigned for licensed use, = but is not fully occupied by that licensed use at a specific location = and time. This spectrum is then assigned = allowed by local regulations for use = to be used opportunistically as licensed-exempt spectrum = under control of a white space database. > =20 > This way, it is understood that the database does not =93assign=94 = white space devices for them to choose from. > =20 > Gerald > From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 > Sent: Tuesday, 31 January, 2012 15:12 > To: gerald.chouinard@sympatico.ca; paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi Gerald, > =20 > Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower = priority opportunistic service" could indeed by used, but I am guessing = that we would need some explanation of what that means. Since we now = have descriptions of licensed spectrum and license-exempt spectrum, I = used these words. Do these changes remove your concerns? > =20 > I also corrected "location" to "local" in previous text proposed for = "White Space". > =20 > Kind Regards, > Scott > =20 > From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 > To: Scott , "paws@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Scott, > Great proposal. However, I am still a bit nervous about the = definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 = where the notion of secondary use is included. The secondary status is = used in the ITU-R Radio Regulations for a different purpose. In fact, = it is possible that a band has already primary and secondary services = allotted to it and that the White Space operation is a tertiary = opportunistic operation where the two first types of services are not = being used. The use of =93lower priority opportunistic=94 service = rather than =93secondary=94 service would be preferable to describe = white space allocations. > =20 > Gerald > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com > Sent: Tuesday, 31 January, 2012 13:56 > To: paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi, > =20 > I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes = to the draft based on the email discussion. > =20 > Below is a copy of chapter 2.2. Terminology. I have inserted new terms = for 'licensed' and 'license-exempt' and made changes to the term 'white = space'. I have tried to work from the perspective that the document = should accurately explain the subject with aim that a reader can = understand the use cases and the subsequent requirements. No doubt we = could include much more text on this topic of spectrum allocation, = assignment, licensing and usage. > =20 > I hope this captures the key points of the discussion. Please do reply = if something is still missing. > =20 > Kind Regards, > Scott > =20 > =20 > 2.2. Terminology > =20 > Database > =20 > In the context of white space and cognitive radio technologies, > the database is an entity which contains current information = about > available spectrum at any given location and other types of > information. > =20 > Device ID > =20 > A unique number for each master device and slave device that > identifies the manufacturer, model number and serial number. > =20 > > Licensed Spectrum > =20 > Spectrum that is acquired by an operator over a given service = area > for a given time period. This is usually done through = auctions,award > (beauty contest), acquisition from secondary market, company = merger & > acquisition, first-come / first-served or by government = allocation > (e.g., public service). > =20 > License-exempt Spectrum > =20 > Spectrum that is not assigned to any specific user. One example = is the 2.4 Ghz ISM band, where RF devices > operate without a formal licensing process. In the USA, = license-exempt spectrum is > Typically referred to as "unlicensed" spectrum. In this document = the terms > license-exempt and unlicensed are used interchangeably. > =20 > > =20 > Location Based Service > =20 > An application or device which provides data, information or > service to a user based on their location. > =20 > Master Device > =20 > A device which queries the WS Database to find out the available > operating channels. > =20 > Protected Entity > =20 > A licensed user of spectrum, when the licensed spectrum = has been assigned as white space spectrum. A = primaryA licensed user of white space spectrum = which is afforded > protection against interference by = secondarylicense-exempt white space = users (white space > devices) for its use in a given area and time. > =20 > Protected Contour > =20 > The exclusion area for a Protected Entity, held in the database > and expressed as a polygon with geospatial points as the = vertices. > =20 > Slave Device > =20 > A device which uses the spectrum made available by a master > device. > =20 > TV White Space > =20 > TV white space refers specifically to radio spectrum which has > been allocated for TV broadcast, but is not occupied by a TV > broadcast, or other licensed user (such as a wireless = microphone), > at a specific location and time. > =20 > White Space > =20 > Radio spectrum which has been allocated for some primary = useand assigned for licensed use, but > is not fully occupied by that primary = use licensed use at a specificlocation > and time. This spectrum is then assigned by = locationlocal regulations for use as = licensed-exempt spectrum under control of a white space = database. > =20 > White Space Device (WSD) > =20 > A device which is a = secondarylicense-exempt user of some = part of white space > spectrum. A white space device can be an access point, base > station, a portable device or similar. In this context, a white > space device is required to query a database with its location = to > obtain information about available spectrum. > =20 > =20 > =20 > From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 > To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Nancy, > =20 > This is not that simple. In fact, the qualifiers =93license-exempt=94 = and =93unlicensed=94 can apply to more than one thing. > =20 > If the qualifier applies to a frequency band, different options exist. = As an example, in the ITU-R context, an =93unlicensed=94 band is = typically a new band, say in the 300 GHz, for which no request has been = made for its use. It is therefore un-allocated to a specific service so = far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R = allocates this band to one or many services on a primary or secondary = basis, then the administrations can thendecide under what king of regime = it will =91assign=92 this band foroperation. They may decide to allow = the use of the band on the basis of licensed operation (with different = options to do the assignment: auction, first come/first served, etc.) or = allow operation with an exemption of licenses, thus =93license-exempt=94su= ch as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in = the USA. > =20 > If the qualifier applies to an operation, the operation can be exempt = of license by the local administration, thus a =93license-exempt=94 = operation. If, however, someone decides to start an RF transmission = operation in a licensed band for which he has no license or in a = license-exempt band for which he does not meet the requirements such as = operating according to the type of operation for which the band is = exempted from a license or he operates outside the technical limits = imposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an =93unlicensed=94 = operation. > =20 > If the qualifier applies to the transmission device, such device may = be a =93license-exempt=94 device if its operation does not require a = specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if = someone smuggles a device that is not allowed in a country by, for = example, buying it on eBay and operates it, this is then an illegal = device in the country and id de-facto an =93unlicensed=94 device since = it has not passed through the normal certification process. > =20 > Note that a =93license-exempt=94 device still has to go through a = certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band = whereas an =93unlicensed=94 device may not pass the certification = process since it has not been licensed to operation in the country. > =20 > This is why the qualifier =93unlicensed=94 has to be treated with care = and the footnote will need to be crafted very carefully. > =20 > With respect to your second point, if an administration only allows = =93licensed=94 operation, the situation will be much simpler to manage = since specific conditions will be attached to these licenses. > =20 > Gerald > =20 > From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 > Sent: Tuesday, 31 January, 2012 06:33 > To: Gerald Chouinard > Cc: Gabor.Bajko@nokia.com; paws@ietf.org > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Gabor and Gerald,=20 > Since we are dealing on a global basis, can there a footnote to = "unlicensed" we can use to indicate that "according to each countries = regulatory requirements" =20 > How to get around the fact that some Countries are or will be = "licensed only" by their gov'ts? Thanks > Nancy > On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: >=20 >=20 >=20 > Gabor, > =20 > I agree with your proposal. Thisseems to be reasonable. However one = needs to be careful with the word=91unlicensed=92 which may mean = =91illegal=92 operation of an RF device in many administrations. > =20 > Gerald > =20 > From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 > Sent: Monday, 30 January, 2012 17:49 > To: gerald.chouinard@sympatico.ca; paws@ietf.org > Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > These look to be very precise definitions, however in everyday use I = rarely hear people referring to ISM band as =91license-exempt=92, in = most cases the term =91unlicensed-band=92 is used. > =20 > Therefore, may I suggest that the draft will include the following = statement: > =20 > The terms unlicensed and license-exempt spectrum are used in this = document interchangeably and refer to a spectrum in which no formal = licensing process is needed for RF devices to operate in, such as the = ISM band. > =20 > - Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard > Sent: Monday, January 30, 2012 12:30 PM > To: paws@ietf.org > Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > All, > =20 > Here is my understanding of the terms: > =20 > Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). > =20 > Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos that would = normally work with full licensing through auction over large service = areas. > =20 > License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. > =20 > Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. > =20 > To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. > =20 > Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I would suggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. > =20 > Gerald > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=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 --Apple-Mail-2--240125192 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Andy, All

In section 4.4, = license exempt is also mentioned as well. 
I am = conflicted in a global sense when emerging countries, or countries with = very different types of gov't want to implement
the protocol, = will they have enough information to do so? and thereby join the = existing DB companies, or will they do their own thing
leaving = holes in what one hopes will be an interoperable global protocol that = deals with TVWS, and/or White spaces in = general?

Thanks, just a = thought.

SIncerely, = Nancy


On Feb 1, 2012, = at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

Scott, = All
I agree with Jussi that = we have now narrowed the definition to apply to TV white spaces, whereas = the scope of PAWS is white spaces in general. I would question not only = why the lower-priority service would always be licence-exempt, but why = the higher priority service would always be licenced. To avoid this = issue on 27th Jan I proposed (That just leaves the = definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by = taking the white space and white space device definitions together. =  =46rom Scott, Gerald and Jussi=92s comments perhaps we could agree = on:
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of  01 February 2012 = 07:31
To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
That = statement is valid for TV White Spaces on UHF frequencies but does not = necessarily apply to all under-utilised radio spectrum. Why would the = lower priority service by default be = licence-exempt?
Kind = regards,
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald = Chouinard
Sent: 31 January 2012 = 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
White Space Radio spectrum which has been allocated and assigned for = licensed use, but is not fully occupied by that licensed use at a = specific location and time. This spectrum is then = <delete>assigned<delete> <insert>allowed<insert> = by local regulations <delete>for use<delete> = <insert>to be used opportunistically<insert> as = licensed-exempt spectrum under control of a white space = database.</Insert>
 
This way, it is understood that the database does not = =93assign=94 white space devices for them to choose = from.
From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.ca; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
Hi = Gerald,
 
Good to avoid = overloading the term "secondary". I have made additional proposed = changes to the text below based on your suggestion. "Lower priority = opportunistic service" could indeed by used, but I am guessing that we = would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used = these words. Do these changes remove your = concerns?
I also corrected "location" to "local" in = previous text proposed for "White = Space".
 
Kind = Regards,
Scott
From: ext Gerald = Chouinard <scott.probasco@nokia.com>, "paws@ietf.org" <Scott,
 paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of scott.probasco@nokia.com
Sent: = Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
Hi, I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some = changes to the draft based on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted = new terms for 'licensed' and 'license-exempt' and made changes to the = term 'white space'. I have tried to work from the perspective that the = document should accurately explain the subject with aim that a reader = can understand the use cases and the subsequent requirements. No doubt = we could include much more text on this topic of spectrum allocation, = assignment, licensing and usage.
I hope this captures the key points of the discussion. Please = do reply if something is still missing.
Kind Regards,
Scott
 2.2.  Terminology    Database
      In the context of white space and = cognitive radio technologies,
     =  the database is an entity which contains current information = about      available spectrum at any given = location and other types of
     =  information.
 
   Device = ID       A unique number for each master = device and slave device that
     =  identifies the manufacturer, model number and serial = number. <Insert>
   Licensed = Spectrum       Spectrum that is acquired by an = operator over a given service area
     =  for a given time period.  This is usually done through = auctions,award      (beauty contest), acquisition from = secondary market, company merger &
     =  acquisition,  first-come / first-served or by government = allocation      (e.g., public = service).    License-exempt = Spectrum       Spectrum that is not assigned to any = specific user. One example is the 2.4 Ghz ISM band, where RF = devices      operate without a formal licensing = process. In the USA, license-exempt spectrum is      Typically referred to as "unlicensed" = spectrum. In this document the terms
     =  license-exempt and unlicensed are used = interchangeably.
 
 
   Location = Based Service       An application or device which = provides data, information or
     =  service to a user based on their location.    Master Device
      A device which queries the WS = Database to find out the available
     =  operating channels.
   Protected Entity
      <Insert>A licensed user of = spectrum, when the licensed spectrum has been assigned as white space = spectrum.</Insert> <Delete>A = primary</Delete><Insert>A licensed</Insert> user of = white space spectrum <Delete>which</Delete> is = afforded      protection against interference by = <Delete>secondary</Delete><Insert>license-exempt white = space</Insert> users <Delete>(white space      devices) for its use</Delete> = in a given area and time.
   Protected Contour
      The exclusion area for a Protected = Entity, held in the database
     =  and expressed as a polygon with geospatial points as the = vertices.    Slave Device
      A device which uses the spectrum made = available by a master
     =  device.    TV White Space
      TV white space refers specifically to = radio spectrum which has
      been allocated for = TV broadcast, but is not occupied by a TV      broadcast, or other licensed user = (such as a wireless microphone),
     =  at a specific location and time.
   White Space
      Radio spectrum which has been = allocated <Delete>for some primary = use</Delete><Insert>and assigned for licensed = use</Insert>, but
      is not fully = occupied by that <Delete>primary use</Delete><Insert> = licensed use </Insert> at a specificlocation      and time. <Insert>This spectrum = is then assigned by = <Delete>location</Delete><Insert>local</Insert> = regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>
   White Space Device (WSD)      A device which is a = <Delete>secondary</Delete><Insert>license-exempt</Ins= ert> user of some part of white space
     =  spectrum.  A white space device can be an access point, = base      station, a portable device or = similar.  In this context, a white
     =  space device is required to query a database with its location = to      obtain information about available = spectrum.   
From: ext Gerald Chouinard <nbravin@earthlink.net>
Cc: "paws@ietf.org" <
 
Sent: Tuesday, 31 = January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'
Gabor and = Gerald, 
Since we are dealing on a global = basis, can there a footnote to "unlicensed" we can use to indicate that = "according to each countries regulatory requirements" =  
How to get around the fact that = some Countries are or will be "licensed only" by their gov'ts? =  Thanks
On Jan 30, 2012, at 4:13 PM, = Gerald Chouinard wrote:



Gabor,
 Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 = January, 2012 17:49
To: ; paws@ietf.org
Subject: RE: [paws] Discussion on = 'license-exempt' vs 'unlicensed'
These look to be very precise definitions, however = in everyday use I rarely hear people referring to ISM band as = =91license-exempt=92, in most cases the term =91unlicensed-band=92 is = used. 
Therefore, = may I suggest that the draft will include the following = statement: 
The terms = unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band. 
- Gabor
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 = PM
To: paws@ietf.org
Subject: [paws] Discussion on = 'license-exempt' vs 'unlicensed'
 
Licensed: Spectrum that = is acquired by an operator over a given service area for a given time = period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government = allocation (e.g., public service).
 
Lightly licensed: Special = case where thefrequency allocation is done through first-come / = first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically = attractive.  Small local operators would be interested by this = (e.g., rural broadband in ) = and not big Telcos that would normally work with full licensing through = auction over large service areas.
 
License-exempt: Operation = of RF devices in a frequency band where no formal licensing process is = needed such as in the 2.4 GHz ISM band. In the , = this term is used for a specific type of operation. The FCC should be = contacted to clarify it.
 
Unlicensed: Illegal = operation of an RF device that can transmit in a frequency band without = a duly issued license.  In the , = this term is used to mean =93license-exempt," see = above.  to describe a legal = operation because the term =93license-exempt=94 has been used for = another specific purpose.
 
Since the PAWS addresses = the interface to the database for the international market, it should = rely on the definition of the terms recognized by the ITU-R. I would = suggest the use of =91licensed=92 and =91license-exempt=92 with a = footnote indicating that the term =91unlicensed=92 is used in the  instead of the usual = =91license-exempt=92.
 
Geraldpaws@ietf.org
 
 paws@ietf.org paws@ietf.org
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 14:48:10 -0000 --Apple-Mail-3--239356416 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, = 4.6=85so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain = how the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could = change, but, why not give the information on both for countries to = understand fully what it's choices are?=20 Thanks Andy, just some early morning thoughts=85Sincerely, Nancy Begin forwarded message: > From: Nancy Bravin > Date: February 1, 2012 6:35:09 AM PST > To: Andy Sago > Cc: , , = , > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to = 3 (Introduction, Conventions and Terminology, Prior Work) >=20 > Hi Andy, All >=20 > In section 4.4, license exempt is also mentioned as well.=20 > I am conflicted in a global sense when emerging countries, or = countries with very different types of gov't want to implement > the protocol, will they have enough information to do so? and thereby = join the existing DB companies, or will they do their own thing > leaving holes in what one hopes will be an interoperable global = protocol that deals with TVWS, and/or White spaces in general? >=20 > Thanks, just a thought. >=20 > SIncerely, Nancy >=20 >=20 > On Feb 1, 2012, at 2:34 AM, = wrote: >=20 >> Scott, All >> =20 >> I agree with Jussi that we have now narrowed the definition to apply = to TV white spaces, whereas the scope of PAWS is white spaces in = general. I would question not only why the lower-priority service would = always be licence-exempt, but why the higher priority service would = always be licenced. To avoid this issue on 27th Jan I proposed = (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a = revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent = services. The Abstract derives from the Introduction and the text could = be aligned to be the same in the Introduction, with =93opportunistic=94 = replacing =93secondary=94 in later sentences in the Introduction. I have = checked and there are no further references to licensing in the = document, so we don=92t need the definitions of licence exempt, light = licensing or unlicensed. This is not a regulatory document =96 we are = defining requirements fora protocol. Keep it simple. >> =20 >> That just leaves the definition of white space, where the existing = spectrum use has now got muddled with the potential for opportunistic = use. This can be fixed by taking the white space and white space device = definitions together. =46rom Scott, Gerald and Jussi=92s comments = perhaps we could agree on: >> =20 >> White Space (WS) >> =20 >> Radio spectrum which is not fully occupied at a specific location and = time. >> =20 >> White Space device >> =20 >> A device which opportunistically uses some part of the white space = spectrum, under control of a white space database. A white space device = can be an access point, base station, a portable device or similar. In = this context, a white space device is required by local regulations to = query a database with its location to obtain information about available = spectrum. >> =20 >> Regards >> =20 >> Andy >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of jussi.kahtava@nokia.com >> Sent: 01 February 2012 07:31 >> To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> That statement is valid for TV White Spaces on UHF frequencies but = does not necessarily apply to all under-utilised radio spectrum. Why = would the lower priority service by default be licence-exempt? >> =20 >> Kind regards, >> Jussi >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard >> Sent: 31 January 2012 22:33 >> To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Scott, >> =20 >> Very good improvements. I would suggest to insert the notion of = opportunistic use of the spectrum by white space devices in the last = sentence of the definition of =93white space=94 as follows: >> =20 >> White Space >> =20 >> Radio spectrum which has been allocated and assigned for licensed = use, but is not fully occupied by that licensed use at a specific = location and time. This spectrum is then assigned = allowed by local regulations for use = to be used opportunistically as licensed-exempt spectrum = under control of a white space database. >> =20 >> This way, it is understood that the database does not =93assign=94 = white space devices for them to choose from. >> =20 >> Gerald >> From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 >> Sent: Tuesday, 31 January, 2012 15:12 >> To: gerald.chouinard@sympatico.ca; paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi Gerald, >> =20 >> Good to avoid overloading the term "secondary". I have made = additional proposed changes to the text below based on your suggestion. = "Lower priority opportunistic service" could indeed by used, but I am = guessing that we would need some explanation of what that means. Since = we now have descriptions of licensed spectrum and license-exempt = spectrum, I used these words. Do these changes remove your concerns? >> =20 >> I also corrected "location" to "local" in previous text proposed for = "White Space". >> =20 >> Kind Regards, >> Scott >> =20 >> From: ext Gerald Chouinard >> Date: Tue, 31 Jan 2012 14:41:36 -0500 >> To: Scott , "paws@ietf.org" >> Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Scott, >> Great proposal. However, I am still a bit nervous about the = definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 = where the notion of secondary use is included. The secondary status is = used in the ITU-R Radio Regulations for a different purpose. In fact, = it is possible that a band has already primary and secondary services = allotted to it and that the White Space operation is a tertiary = opportunistic operation where the two first types of services are not = being used. The use of =93lower priority opportunistic=94 service = rather than =93secondary=94 service would be preferable to describe = white space allocations. >> =20 >> Gerald >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com >> Sent: Tuesday, 31 January, 2012 13:56 >> To: paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi, >> =20 >> I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes = to the draft based on the email discussion. >> =20 >> Below is a copy of chapter 2.2. Terminology. I have inserted new = terms for 'licensed' and 'license-exempt' and made changes to the term = 'white space'. I have tried to work from the perspective that the = document should accurately explain the subject with aim that a reader = can understand the use cases and the subsequent requirements. No doubt = we could include much more text on this topic of spectrum allocation, = assignment, licensing and usage. >> =20 >> I hope this captures the key points of the discussion. Please do = reply if something is still missing. >> =20 >> Kind Regards, >> Scott >> =20 >> =20 >> 2.2. Terminology >> =20 >> Database >> =20 >> In the context of white space and cognitive radio technologies, >> the database is an entity which contains current information = about >> available spectrum at any given location and other types of >> information. >> =20 >> Device ID >> =20 >> A unique number for each master device and slave device that >> identifies the manufacturer, model number and serial number. >> =20 >> >> Licensed Spectrum >> =20 >> Spectrum that is acquired by an operator over a given service = area >> for a given time period. This is usually done through = auctions,award >> (beauty contest), acquisition from secondary market, company = merger & >> acquisition, first-come / first-served or by government = allocation >> (e.g., public service). >> =20 >> License-exempt Spectrum >> =20 >> Spectrum that is not assigned to any specific user. One example = is the 2.4 Ghz ISM band, where RF devices >> operate without a formal licensing process. In the USA, = license-exempt spectrum is >> Typically referred to as "unlicensed" spectrum. In this = document the terms >> license-exempt and unlicensed are used interchangeably. >> =20 >> >> =20 >> Location Based Service >> =20 >> An application or device which provides data, information or >> service to a user based on their location. >> =20 >> Master Device >> =20 >> A device which queries the WS Database to find out the = available >> operating channels. >> =20 >> Protected Entity >> =20 >> A licensed user of spectrum, when the licensed spectrum = has been assigned as white space spectrum. A = primaryA licensed user of white space spectrum = which is afforded >> protection against interference by = secondarylicense-exempt white space = users (white space >> devices) for its use in a given area and time. >> =20 >> Protected Contour >> =20 >> The exclusion area for a Protected Entity, held in the database >> and expressed as a polygon with geospatial points as the = vertices. >> =20 >> Slave Device >> =20 >> A device which uses the spectrum made available by a master >> device. >> =20 >> TV White Space >> =20 >> TV white space refers specifically to radio spectrum which has >> been allocated for TV broadcast, but is not occupied by a TV >> broadcast, or other licensed user (such as a wireless = microphone), >> at a specific location and time. >> =20 >> White Space >> =20 >> Radio spectrum which has been allocated for some = primary useand assigned for licensed use, but >> is not fully occupied by that primary = use licensed use at a specificlocation >> and time. This spectrum is then assigned by = locationlocal regulations for use as = licensed-exempt spectrum under control of a white space = database. >> =20 >> White Space Device (WSD) >> =20 >> A device which is a = secondarylicense-exempt user of some = part of white space >> spectrum. A white space device can be an access point, base >> station, a portable device or similar. In this context, a = white >> space device is required to query a database with its location = to >> obtain information about available spectrum. >> =20 >> =20 >> =20 >> From: ext Gerald Chouinard >> Date: Tue, 31 Jan 2012 10:07:30 -0500 >> To: 'Nancy Bravin' >> Cc: "paws@ietf.org" >> Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> Nancy, >> =20 >> This is not that simple. In fact, the qualifiers =93license-exempt=94 = and =93unlicensed=94 can apply to more than one thing. >> =20 >> If the qualifier applies to a frequency band, different options = exist. As an example, in the ITU-R context, an =93unlicensed=94 band is = typically a new band, say in the 300 GHz, for which no request has been = made for its use. It is therefore un-allocated to a specific service so = far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R = allocates this band to one or many services on a primary or secondary = basis, then the administrations can thendecide under what king of regime = it will =91assign=92 this band foroperation. They may decide to allow = the use of the band on the basis of licensed operation (with different = options to do the assignment: auction, first come/first served, etc.) or = allow operation with an exemption of licenses, thus =93license-exempt=94su= ch as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in = the USA. >> =20 >> If the qualifier applies to an operation, the operation can be exempt = of license by the local administration, thus a =93license-exempt=94 = operation. If, however, someone decides to start an RF transmission = operation in a licensed band for which he has no license or in a = license-exempt band for which he does not meet the requirements such as = operating according to the type of operation for which the band is = exempted from a license or he operates outside the technical limits = imposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an =93unlicensed=94 = operation. >> =20 >> If the qualifier applies to the transmission device, such device may = be a =93license-exempt=94 device if its operation does not require a = specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if = someone smuggles a device that is not allowed in a country by, for = example, buying it on eBay and operates it, this is then an illegal = device in the country and id de-facto an =93unlicensed=94 device since = it has not passed through the normal certification process. >> =20 >> Note that a =93license-exempt=94 device still has to go through a = certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band = whereas an =93unlicensed=94 device may not pass the certification = process since it has not been licensed to operation in the country. >> =20 >> This is why the qualifier =93unlicensed=94 has to be treated with = care and the footnote will need to be crafted very carefully. >> =20 >> With respect to your second point, if an administration only allows = =93licensed=94 operation, the situation will be much simpler to manage = since specific conditions will be attached to these licenses. >> =20 >> Gerald >> =20 >> From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 >> Sent: Tuesday, 31 January, 2012 06:33 >> To: Gerald Chouinard >> Cc: Gabor.Bajko@nokia.com; paws@ietf.org >> Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> Gabor and Gerald,=20 >> Since we are dealing on a global basis, can there a footnote to = "unlicensed" we can use to indicate that "according to each countries = regulatory requirements" =20 >> How to get around the fact that some Countries are or will be = "licensed only" by their gov'ts? Thanks >> Nancy >> On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: >>=20 >>=20 >>=20 >> Gabor, >> =20 >> I agree with your proposal. Thisseems to be reasonable. However one = needs to be careful with the word=91unlicensed=92 which may mean = =91illegal=92 operation of an RF device in many administrations. >> =20 >> Gerald >> =20 >> From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 >> Sent: Monday, 30 January, 2012 17:49 >> To: gerald.chouinard@sympatico.ca; paws@ietf.org >> Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> These look to be very precise definitions, however in everyday use I = rarely hear people referring to ISM band as =91license-exempt=92, in = most cases the term =91unlicensed-band=92 is used. >> =20 >> Therefore, may I suggest that the draft will include the following = statement: >> =20 >> The terms unlicensed and license-exempt spectrum are used in this = document interchangeably and refer to a spectrum in which no formal = licensing process is needed for RF devices to operate in, such as the = ISM band. >> =20 >> - Gabor >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard >> Sent: Monday, January 30, 2012 12:30 PM >> To: paws@ietf.org >> Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> All, >> =20 >> Here is my understanding of the terms: >> =20 >> Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). >> =20 >> Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos that would = normally work with full licensing through auction over large service = areas. >> =20 >> License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. >> =20 >> Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. >> =20 >> To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. >> =20 >> Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I would suggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. >> =20 >> Gerald >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=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 >=20 --Apple-Mail-3--239356416 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, = 4.6=85so if you propose to remove any reference to TVWS it will = affect
the document as a whole, and information that seems necessary = to explain how the DB and protocol interacts with TVWS devices = and
the methods of doing so. One can envision that current = rules could change, but, why not give the information on both for = countries to understand fully
what it's choices = are? 

Thanks Andy, just some early morning = thoughts=85Sincerely, Nancy

Begin forwarded = message:

Date: February 1, 2012 6:35:09 AM PST
To: Andy Sago <andy.sago@bt.com>
=
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, = Conventions and Terminology, Prior Work)

Hi = Andy, All

In section 4.4, license exempt is also = mentioned as well. 
I am conflicted in a global sense = when emerging countries, or countries with very different types of gov't = want to implement
the protocol, will they have enough = information to do so? and thereby join the existing DB companies, or = will they do their own thing
leaving holes in what one hopes = will be an interoperable global protocol that deals with TVWS, and/or = White spaces in general?

Thanks, just a = thought.

SIncerely, = Nancy


On Feb 1, 2012, = at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

Scott, = All
I agree with Jussi that = we have now narrowed the definition to apply to TV white spaces, whereas = the scope of PAWS is white spaces in general. I would question not only = why the lower-priority service would always be licence-exempt, but why = the higher priority service would always be licenced. To avoid this = issue on 27th Jan I proposed (That just leaves the = definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by = taking the white space and white space device definitions together. =  =46rom Scott, Gerald and Jussi=92s comments perhaps we could agree = on:
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of  01 February 2012 = 07:31
To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
That = statement is valid for TV White Spaces on UHF frequencies but does not = necessarily apply to all under-utilised radio spectrum. Why would the = lower priority service by default be = licence-exempt?
Kind = regards,
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald = Chouinard
Sent: 31 January 2012 = 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
White Space Radio spectrum which has been allocated and assigned for = licensed use, but is not fully occupied by that licensed use at a = specific location and time. This spectrum is then = <delete>assigned<delete> <insert>allowed<insert> = by local regulations <delete>for use<delete> = <insert>to be used opportunistically<insert> as = licensed-exempt spectrum under control of a white space = database.</Insert>
 
This way, it is understood that the database does not = =93assign=94 white space devices for them to choose = from.
From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.ca; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
Hi = Gerald,
 
Good to avoid = overloading the term "secondary". I have made additional proposed = changes to the text below based on your suggestion. "Lower priority = opportunistic service" could indeed by used, but I am guessing that we = would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used = these words. Do these changes remove your = concerns?
I also corrected "location" to "local" in = previous text proposed for "White = Space".
 
Kind = Regards,
Scott
From: ext Gerald = Chouinard <scott.probasco@nokia.com>, "paws@ietf.org" <Scott,
 paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of scott.probasco@nokia.com
Sent: = Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
Hi, I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some = changes to the draft based on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted = new terms for 'licensed' and 'license-exempt' and made changes to the = term 'white space'. I have tried to work from the perspective that the = document should accurately explain the subject with aim that a reader = can understand the use cases and the subsequent requirements. No doubt = we could include much more text on this topic of spectrum allocation, = assignment, licensing and usage.
I hope this captures the key points of the discussion. Please = do reply if something is still missing.
Kind Regards,
Scott
 2.2.  Terminology    Database
      In the context of white space and = cognitive radio technologies,
     =  the database is an entity which contains current information = about      available spectrum at any given = location and other types of
     =  information.
 
   Device = ID       A unique number for each master = device and slave device that
     =  identifies the manufacturer, model number and serial = number. <Insert>
   Licensed = Spectrum       Spectrum that is acquired by an = operator over a given service area
     =  for a given time period.  This is usually done through = auctions,award      (beauty contest), acquisition from = secondary market, company merger &
     =  acquisition,  first-come / first-served or by government = allocation      (e.g., public = service).    License-exempt = Spectrum       Spectrum that is not assigned to any = specific user. One example is the 2.4 Ghz ISM band, where RF = devices      operate without a formal licensing = process. In the USA, license-exempt spectrum is      Typically referred to as "unlicensed" = spectrum. In this document the terms
     =  license-exempt and unlicensed are used = interchangeably.
 
 
   Location = Based Service       An application or device which = provides data, information or
     =  service to a user based on their location.    Master Device
      A device which queries the WS = Database to find out the available
     =  operating channels.
   Protected Entity
      <Insert>A licensed user of = spectrum, when the licensed spectrum has been assigned as white space = spectrum.</Insert> <Delete>A = primary</Delete><Insert>A licensed</Insert> user of = white space spectrum <Delete>which</Delete> is = afforded      protection against interference by = <Delete>secondary</Delete><Insert>license-exempt white = space</Insert> users <Delete>(white space      devices) for its use</Delete> = in a given area and time.
   Protected Contour
      The exclusion area for a Protected = Entity, held in the database
     =  and expressed as a polygon with geospatial points as the = vertices.    Slave Device
      A device which uses the spectrum made = available by a master
     =  device.    TV White Space
      TV white space refers specifically to = radio spectrum which has
      been allocated for = TV broadcast, but is not occupied by a TV      broadcast, or other licensed user = (such as a wireless microphone),
     =  at a specific location and time.
   White Space
      Radio spectrum which has been = allocated <Delete>for some primary = use</Delete><Insert>and assigned for licensed = use</Insert>, but
      is not fully = occupied by that <Delete>primary use</Delete><Insert> = licensed use </Insert> at a specificlocation      and time. <Insert>This spectrum = is then assigned by = <Delete>location</Delete><Insert>local</Insert> = regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>
   White Space Device (WSD)      A device which is a = <Delete>secondary</Delete><Insert>license-exempt</Ins= ert> user of some part of white space
     =  spectrum.  A white space device can be an access point, = base      station, a portable device or = similar.  In this context, a white
     =  space device is required to query a database with its location = to      obtain information about available = spectrum.   
From: ext Gerald Chouinard <nbravin@earthlink.net>
Cc: "paws@ietf.org" <
 
Sent: Tuesday, 31 = January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'
Gabor and = Gerald, 
Since we are dealing on a global = basis, can there a footnote to "unlicensed" we can use to indicate that = "according to each countries regulatory requirements" =  
How to get around the fact that = some Countries are or will be "licensed only" by their gov'ts? =  Thanks
On Jan 30, 2012, at 4:13 PM, = Gerald Chouinard wrote:



Gabor,
 Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 = January, 2012 17:49
To: ; paws@ietf.org
Subject: RE: [paws] Discussion on = 'license-exempt' vs 'unlicensed'
These look to be very precise definitions, however = in everyday use I rarely hear people referring to ISM band as = =91license-exempt=92, in most cases the term =91unlicensed-band=92 is = used. 
Therefore, = may I suggest that the draft will include the following = statement: 
The terms = unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band. 
- Gabor
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 = PM
To: paws@ietf.org
Subject: [paws] Discussion on = 'license-exempt' vs 'unlicensed'
 
Licensed: Spectrum that = is acquired by an operator over a given service area for a given time = period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government = allocation (e.g., public service).
 
Lightly licensed: Special = case where thefrequency allocation is done through first-come / = first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically = attractive.  Small local operators would be interested by this = (e.g., rural broadband in ) = and not big Telcos that would normally work with full licensing through = auction over large service areas.
 
License-exempt: Operation = of RF devices in a frequency band where no formal licensing process is = needed such as in the 2.4 GHz ISM band. In the , = this term is used for a specific type of operation. The FCC should be = contacted to clarify it.
 
Unlicensed: Illegal = operation of an RF device that can transmit in a frequency band without = a duly issued license.  In the , = this term is used to mean =93license-exempt," see = above.  to describe a legal = operation because the term =93license-exempt=94 has been used for = another specific purpose.
 
Since the PAWS addresses = the interface to the database for the international market, it should = rely on the definition of the terms recognized by the ITU-R. I would = suggest the use of =91licensed=92 and =91license-exempt=92 with a = footnote indicating that the term =91unlicensed=92 is used in the  instead of the usual = =91license-exempt=92.
 
Geraldpaws@ietf.org
 
 paws@ietf.org paws@ietf.org
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2012 14:58:01 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140653B5173EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nancy, all Good questions. I'm not proposing to remove references to TVWS, they are en= tirely appropriate within the use cases since it is the TV bands we are stu= dying as first candidate for opportunistic access, but the charter says we = are addressing all white space in the resulting protocol. To answer your ot= her questions, IMO our aim should be to provide all the necessary informati= on in this PAWS requirements I-D to enable the PAWS protocol I-D to be deve= loped. I don't think it's our job to explain different regulatory regimes o= r applications (beyond use cases) in this document, ITU and others do this = very well, and regulators tend to be well coordinated or play 'follow my le= ader'. Thanks for pointing out the reference to licence-exempt that I had missed i= n 4.4 - I think the meaning would be just the same with 'in a license-exem= pt TVWS environment' deleted from that sentence. That would be my suggestio= n. Regards Andy From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: 01 February 2012 14:48 To: Sago,AJ,Andy,COD R Cc: paws@ietf.org Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Intro= duction, Conventions and Terminology, Prior Work) Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6..= .so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain ho= w the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could change, = but, why not give the information on both for countries to understand fully what it's choices are? Thanks Andy, just some early morning thoughts...Sincerely, Nancy Begin forwarded message: From: Nancy Bravin > Date: February 1, 2012 6:35:09 AM PST To: Andy Sago > Cc: >, >, >, > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Andy, All In section 4.4, license exempt is also mentioned as well. I am conflicted in a global sense when emerging countries, or countries wit= h very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby join = the existing DB companies, or will they do their own thing leaving holes in what one hopes will be an interoperable global protocol th= at deals with TVWS, and/or White spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, > > wrote: Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV = white spaces, whereas the scope of PAWS is white spaces in general. I would= question not only why the lower-priority service would always be licence-e= xempt, but why the higher priority service would always be licenced. To avo= id this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/= paws/current/msg00576.html) a revision of the Abstract that avoids the term= s licence exempt or unlicensed, or any mention of the regulatory status of = the incumbent services. The Abstract derives from the Introduction and the = text could be aligned to be the same in the Introduction, with "opportunist= ic" replacing "secondary" in later sentences in the Introduction. I have ch= ecked and there are no further references to licensing in the document, so = we don't need the definitions of licence exempt, light licensing or unlicen= sed. This is not a regulatory document - we are defining requirements fora = protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum= use has now got muddled with the potential for opportunistic use. This can= be fixed by taking the white space and white space device definitions toge= ther. From Scott, Gerald and Jussi's comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum= , under control of a white space database. A white space device can be an = access point, base station, a portable device or similar. In this context,= a white space device is required by local regulations to query a database = with its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of jussi.kah= tava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; sc= ott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not= necessarily apply to all under-utilised radio spectrum. Why would the lowe= r priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Geral= d Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed by = local regulations for use to be used opportunistica= lly as licensed-exempt spectrum under control of a white space data= base. This way, it is understood that the database does not "assign" white space = devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= "Protected Entity" and "White Space Devices (WSD)" where the notion of sec= ondary use is included. The secondary status is used in the ITU-R Radio Re= gulations for a different purpose. In fact, it is possible that a band has= already primary and secondary services allotted to it and that the White S= pace operation is a tertiary opportunistic operation where the two first ty= pes of services are not being used. The use of "lower priority opportunist= ic" service rather than "secondary" service would be preferable to describe= white space allocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use<= /Delete>and assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unl= icensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an "unlicensed" band is typically a new ba= nd, say in the 300 GHz, for which no request has been made for its use. It= is therefore un-allocated to a specific service so far and thus it is an "= unlicensed" frequency band. Once the ITU-R allocates this band to one or ma= ny services on a primary or secondary basis, then the administrations can t= hendecide under what king of regime it will 'assign' this band foroperation= . They may decide to allow the use of the band on the basis of licensed ope= ration (with different options to do the assignment: auction, first come/fi= rst served, etc.) or allow operation with an exemption of licenses, thus "l= icense-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicen= sed" in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a "license-exempt" operation. If, h= owever, someone decides to start an RF transmission operation in a licensed= band for which he has no license or in a license-exempt band for which he = does not meet the requirements such as operating according to the type of o= peration for which the band is exempted from a license or he operates outsi= de the technical limits imposed by this license-exempt ruling, his operatio= n is therefore illegal and he is then considered to be running an "unlicens= ed" operation. If the qualifier applies to the transmission device, such device may be a "= license-exempt" device if its operation does not require a specific license= or registration with the local administration such as TV receivers of Wi-F= i devices in the 2.4 GHz ISM band. However, if someone smuggles a device t= hat is not allowed in a country by, for example, buying it on eBay and oper= ates it, this is then an illegal device in the country and id de-facto an "= unlicensed" device since it has not passed through the normal certification= process. Note that a "license-exempt" device still has to go through a certification= process and meet the limits imposed by the local regulator for the "licens= e-exempt" operation in the given frequency band whereas an "unlicensed" dev= ice may not pass the certification process since it has not been licensed t= o operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the = footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licens= ed" operation, the situation will be much simpler to manage since specific = conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word'unlicensed' which may mean 'illegal' operation= of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as 'license-exempt', in most cases the t= erm 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe = a legal operation because the term "license-exempt" has been used for anoth= er specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of 'licensed' and 'license-exempt' with a foo= tnote indicating that the term 'unlicensed' is used in the USA instead of t= he usual 'license-exempt'. Gerald _______________________________________________ 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 --_000_619CDADDCCD2B44380834BE8BF6F714140653B5173EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nancy, all

 

Good questions. I&#= 8217;m not proposing to remove references to TVWS, they are entirely approp= riate within the use cases since it is the TV bands we are studying as firs= t candidate for opportunistic access, but the charter says we are addressin= g all white space in the resulting protocol. To answer your other questions= , IMO our aim should be to provide all the necessary information in this PA= WS requirements I-D to enable the PAWS protocol I-D to be developed. I don&= #8217;t think it’s our job to explain different regulatory regimes or= applications (beyond use cases) in this document, ITU and others do this v= ery well, and regulators tend to be well coordinated or play ‘follow = my leader’.

 <= /p>

Thanks for pointing out the reference to licence-exempt that = I had missed in 4.4 -  I think the meaning would be just the same with= ‘in a license-exempt TVWS environment’ deleted from that sente= nce. That would be my suggestion.

&nbs= p;

Regards

=  

Andy

 

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: = 01 February 2012 14:48
To: Sago,AJ,Andy,COD R
Cc: paws@= ietf.org
Subject: Fwd: [paws] Use cases and requirements I-D: sec= tions 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 

Hi Andy, also, throughout the document TVWS are mentioned in= 4.1,4.5, 4.6…so if you propose to remove any reference to TVWS it wi= ll affect

the document as a whole, = and information that seems necessary to explain how the DB and protocol int= eracts with TVWS devices and

= the methods of doing so. One can envision that current rules could change, = but, why not give the information on both for countries to understand fully=

what it's choices are? =

 

<= div>

Thanks Andy, just some early morning thoughts̷= 0;Sincerely, Nancy

 

Begin forwarded message:



= Date:= February 1, 2012 6:35:09 AM PST

To: Andy Sago <= andy.sago@bt.com>

= Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work)

<= /div>

 

Hi= Andy, All

 

In section 4.4, license exempt is also mention= ed as well. 

I am confli= cted in a global sense when emerging countries, or countries with very diff= erent types of gov't want to implement

the protocol, will they have enough information to do so? and the= reby join the existing DB companies, or will they do their own thing

leaving holes in what one hopes wil= l be an interoperable global protocol that deals with TVWS, and/or White sp= aces in general?

 <= /o:p>

Thanks, just a thought.=

 

SIncerely, Nancy

 

 

On Feb 1, 2012, at 2:34 AM, <= andy.sago@bt.com> <andy.sago@bt.com> wrote:



Scott, = All

 

=

I agree with Jussi that we have now narrowed the defi= nition to apply to TV white spaces, whereas the scope of PAWS is white spac= es in general. I would question not only why the lower-priority service wou= ld always be licence-exempt, but why the higher priority service would alwa= ys be licenced. To avoid this issue on 27th Jan I proposed (http://www.iet= f.org/mail-archive/web/paws/current/msg00576.html) a revision of the Ab= stract that avoids the terms licence exempt or unlicensed, or any mention o= f the regulatory status of the incumbent services. The Abstract derives fro= m the Introduction and the text could be aligned to be the same in the Intr= oduction, with “opportunistic” replacing “secondary”= ; in later sentences in the Introduction. I have checked and there are no f= urther references to licensing in the document, so we don’t need the = definitions of licence exempt, light licensing or unlicensed. This is not a= regulatory document – we are defining requirements fora protocol. Ke= ep it simple.

 =

That just leaves the definition of white sp= ace, where the existing spectrum use has now got muddled with the potential= for opportunistic use. This can be fixed by taking the white space and whi= te space device definitions together.  From Scott, Gerald and Jussi= 217;s comments perhaps we could agree on:

<= p class=3DMsoNormal> 

White Space (WS)

 

Radio spectrum which is not fully occupied a= t a specific location and time.

 

White Space device

 

<= /div>

A device which opportunist= ically uses some part of the white space spectrum, under control of a white= space database.  A white space device can be an access point, base st= ation, a portable device or similar.  In this context, a white space d= evice is required by local regulations to query a database with its locatio= n to obtain information about available spectrum.

 

Regards

 

Andy=

 

From:=  paws-boun= ces@ietf.org [mailto:paws-bounces@ietf.org]<= span class=3Dapple-converted-space> On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: gerald.chouinard@sympatico.ca; scott.proba= sco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and requirements= I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Wor= k)

 <= o:p>

That statement is vali= d for TV White Spaces on UHF frequencies but does not necessarily apply to = all under-utilised radio spectrum. Why would the lower priority service by = default be licence-exempt?

 

Kind regards,

Jussi

&nbs= p;

From: paws-bounces@ietf.org [mailto:= paws-bounces@ietf.org] = On Behalf Of ext Ger= ald Chouinard
Sent: 31 January 2012 22:33
To:&= nbsp;Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org
<= b>Subject: Re: [paws] U= se cases and requirements I-D: sections 1 to 3 (Introduction, Conventions a= nd Terminology, Prior Work)

 

Scott,

 

Very good improvements. I would suggest to insert the notion of = opportunistic use of the spectrum by white space devices in the last senten= ce of the definition of “white space” as follows:

 

White Space

 

Radio = spectrum which has been allocated and assigned for licensed use, but is not= fully occupied by that licensed use at a specific location and time. This = spectrum is then <delete>assigned<delete> <insert>allowed= <insert> by local regulations <delete>for use<delete> <= ;insert>to be used opportunistically<insert> as licensed-exempt sp= ectrum under control of a white space database.</Insert><= /o:p>

 <= /o:p>

This way, it is und= erstood that the database does not “assign” white space devices= for them to choose from.

 

Gerald

= From: scott.probasco@n= okia.com [mailto:scott.probasco@nokia.com] 
Sent: Tuesday, 31 January, 2012 15:12
= To: gerald.chouinard@sympatico.ca; p= aws@ietf.org
Subject:&nbs= p;Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work)

 

Hi Gerald,

 

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'>Good to avoid overloading the term "secondary". = I have made additional proposed changes to the text below based on your sug= gestion. "Lower priority opportunistic service" could indeed by u= sed, but I am guessing that we would need some explanation of what that mea= ns. Since we now have descriptions of licensed spectrum and license-exempt = spectrum, I used these words. Do these changes remove your concerns?=

 

I also corrected "location" to "local" i= n previous text proposed for "White Space".

=

 <= o:p>

= Kind Regards,

Scott

 

<= div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0= cm 0cm;border-width:initial;border-color:initial'>

From: ext Gerald Chouinard <gerald.chouinard@sympatico.ca>
Date: T= ue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-= D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)<= /span>

 

Scott,

=

Great proposal.  However, = I am still a bit nervous about the definitions of “Protected Entity&#= 8221; and “White Space Devices (WSD)” where the notion of secon= dary use is included.  The secondary status is used in the ITU-R Radio= Regulations for a different purpose.  In fact, it is possible that a = band has already primary and secondary services allotted to it and that the= White Space operation is a tertiary opportunistic operation where the two = first types of services are not being used.  The use of “lower p= riority opportunistic” service rather than “secondary” se= rvice would be preferable to describe white space allocations.

 

Geral= d

 

From: paws-bounces@ietf= .org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 201= 2 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and= requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminolo= gy, Prior Work)

 

Hi,

 

I changed the subject line from " Re: [pa= ws] Discussion on 'license-exempt' vs 'unlicensed'  ". Here I try= to propose some changes to the draft based on the email discussion.=

 

Below is a copy of chapter 2.2. Terminology. I= have inserted new terms for 'licensed' and 'license-exempt' and made chang= es to the term 'white space'. I have tried to work from the perspective tha= t the document should accurately explain the subject with aim that a reader= can understand the use cases and the subsequent requirements. No doubt we = could include much more text on this topic of spectrum allocation, assignme= nt, licensing and usage.

 

I hope this cap= tures the key points of the discussion. Please do reply if something is sti= ll missing.

 

=

Kind Regards,

= Scott

<= b> 

<= p class=3DMsoNormal> 

2.2. &= nbsp;Terminology

 

=

   Database

 

      In the context = of white space and cognitive radio technologies,

<= /div>

  =    the database is an entity which contains current information = about

<= b>      available spectrum at any giv= en location and other types of

      info= rmation.

 

   Device ID

 

      A unique number for = each master device and slave device that

     =  identifies the manufacturer, model number and serial number.

 

<Insert>

=

  = Licensed Spectrum

 

     =  Spectrum that is acquired by an operator over a given service area

      for a given time period.  This i= s usually done through auctions,award

=

     &nb= sp;(beauty contest), acquisition from secondary market, company merger &= ;

      acquisition,  first-come / f= irst-served or by government allocation

     &= nbsp;(e.g., public service).

 

=

 = ;  License-exempt Spectrum

<= div>

 <= /p>

 =      Spectrum that is not assigned to any specific user. One= example is the 2.4 Ghz ISM band, where RF devices

 &nbs= p;    operate without a formal licensing process. In the USA, license-exempt spectrum is

      Typically referred to as "unlicen= sed" spectrum. In this document the terms

   &= nbsp;  license-exempt and unlicensed are used interchangeably.<= /b>

 

</Insert>

 

   Location Based Service

 

      An application or device which provides data, in= formation or

      service to a user base= d on their location.

 

   Master= Device

 

      A devi= ce which queries the WS Database to find out the available<= /o:p>

&n= bsp;     operating channels.

=

 =

   Protected Entity

 

 =      <Insert>A licensed user of spectrum, when the lic= ensed spectrum has been assigned as white space spectrum.</Insert> &l= t;Delete>A primary</Delete><Insert>A licensed</Insert>= user of white space spectrum <Delete>which</Delete> is afforde= d

      protection against interference b= y <Delete>secondary</Delete><Insert>license-exempt white = space</Insert> users <Delete>(white space=

 =      devices) for its use</Delete> in a given area and= time.

=  

=

   Protected Contour

 

      The exclusion a= rea for a Protected Entity, held in the database

<= /div>

  =    and expressed as a polygon with geospatial points as the vert= ices.

<= b> 

<= p class=3DMsoNormal>   Slave Device

 

      A device which uses = the spectrum made available by a master

     &= nbsp;device.

 

   TV White Space=

 

      TV white spac= e refers specifically to radio spectrum which has

=

  = ;    been allocated for TV broadcast, but is not occupied by a TV=

      broadcast, or other licensed user = (such as a wireless microphone),

=

      at= a specific location and time.

 

 &nb= sp; White Space

 

<= div>

     &nbs= p;Radio spectrum which has been allocated <Delete>for some primary us= e</Delete><Insert>and assigned for licensed use</Insert>,= but

      is not fully occupied by that = <Delete>primary use</Delete><Insert> licensed use </In= sert> at a specificlocation

      and = time. <Insert>This spectrum is then assigned by <Delete>locatio= n</Delete><Insert>local</Insert> regulations for use as l= icensed-exempt spectrum under control of a white space database.</Insert= >

 

   White Space Device (WS= D)

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'> 

     A device whi= ch is a <Delete>secondary</Delete><Insert>license-exempt&= lt;/Insert> user of some part of white space

   =    spectrum.  A white space device can be an access point, b= ase

=       station, a portable device or s= imilar.  In this context, a white

     &n= bsp;space device is required to query a database with its location to

      obtain information about available spect= rum.

 

 

 =

From: ext Gera= ld Chouinard <gerald.ch= ouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To= : 'Nancy Bravin' <nbravin@earth= link.net>
Cc: "paws@ietf.or= g" <paws@ietf.org>
S= ubject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Nancy,

 

This is not that simple.  In= fact, the qualifiers “license-exempt” and “unlicensed= 221; can apply to more than one thing.

=

 

If the qualifier applies to a= frequency band, different options exist. As an example, in the ITU-R conte= xt, an “unlicensed” band is typically a new band, say in the 30= 0 GHz, for which no request has been made for its use.  It is therefor= e un-allocated to a specific service so far and thus it is an “unlice= nsed” frequency band. Once the ITU-R allocates this band to one or ma= ny services on a primary or secondary basis, then the administrations can t= hendecide under what king of regime it will ‘assign’ this band = foroperation. They may decide to allow the use of the band on the basis of = licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licen= ses, thus “license-exempt”such as in the 2.4 GHz ISM band. This= is also called “unlicensed” in the USA.

 

If the qualifier applies to an operation, = the operation can be exempt of license by the local administration, thus a = “license-exempt” operation. If, however, someone decides to sta= rt an RF transmission operation in a licensed band for which he has no lice= nse or in a license-exempt band for which he does not meet the requirements= such as operating according to the type of operation for which the band is= exempted from a license or he operates outside the technical limits impose= d by this license-exempt ruling, his operation is therefore illegal and he = is then considered to be running an “unlicensed” operation.

&nb= sp;

If the qualifier applies to the transmission device, such device may b= e a “license-exempt” device if its operation does not require a= specific license or registration with the local administration such as TV = receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someo= ne smuggles a device that is not allowed in a country by, for example, buyi= ng it on eBay and operates it, this is then an illegal device in the countr= y and id de-facto an “unlicensed” device since it has not passe= d through the normal certification process.

=

 

Note that a “licen= se-exempt” device still has to go through a certification process and= meet the limits imposed by the local regulator for the “license-exem= pt” operation in the given frequency band whereas an “unlicense= d” device may not pass the certification process since it has not bee= n licensed to operation in the country.

 

This is why the qualifier &#= 8220;unlicensed” has to be treated with care and the footnote will ne= ed to be crafted very carefully.

 

With respect to your second point, = if an administration only allows “licensed” operation, the situ= ation will be much simpler to manage since specific conditions will be atta= ched to these licenses.

 

Gerald

<= p class=3DMsoNormal> 

=

Fr= om: Nancy Bravin [mailto:nbravin@e= arthlink.net] 
Sent:= Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paw= s] Discussion on 'license-exempt' vs 'unlicensed'

=

 

<= span lang=3DEN-US style=3D'color:black'>Gabor and Gerald, <= o:p>

Since we are dealing on a global basis, can there a foo= tnote to "unlicensed" we can use to indicate that "according= to each countries regulatory requirements"  

How to get around the fact that some Countries are or wil= l be "licensed only" by their gov'ts?  Thanks

Nancy

=

On Jan 30,= 2012, at 4:13 PM, Gerald Chouinard wrote:

<= /div>




<= p class=3DMsoNormal>Gabor,

 

I agree with your propo= sal.  Thisseems to be reasonable.  However one needs to be carefu= l with the word‘unlicensed’ which may mean ‘illegal’= ; operation of an RF device in many administrations.<= /p>

 =

Gerald

 

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.ca; paws@ietf.orgSubject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed'<= /b>

 

These look to be very precise definiti= ons, however in everyday use I rarely hear people referring to ISM band as = ‘license-exempt’, in most cases the term ‘unlicensed-band= ’ is used.

<= b> 

Therefore, may I suggest that the draft= will include the following statement:

=

 

The terms unlicense= d and license-exempt spectrum are used in this document interchangeably and= refer to a spectrum in which no formal licensing process is needed for RF = devices to operate in, such as the ISM band.

 

-          G= abor

 

= From: paws-bounces@ietf.org [mailto:paws-bo= unces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, Janu= ary 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Dis= cussion on 'license-exempt' vs 'unlicensed'

=

 

<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Arial","sans-serif= ";color:black'>All,

 

Here is my understanding of the terms:

 

L= icensed: Spectrum that is acquired by an operator over a given service area= for a given time period.  This is usually done through auctions (thin= k of the Telcos), beauty contest, first-come / first-served or by governmen= t allocation (e.g., public service).

 

=

Lightly licensed: Special case = where thefrequency allocation is done through first-come / first-served pro= cess for a given time frame over a relatively limited service area. The ann= ual license fee is usually small to facilitate the deployment of a service = that would not normally be economically attractive.  Small local opera= tors would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would norma= lly work with full licensing through auction over large service areas.

&nbs= p;

License-exempt: Operation of RF devices in a frequency band where no f= ormal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a= specific type of operation. The FCC should be contacted to clarify it.

&nb= sp;

Unlicensed: Illegal operation of an RF device that can transmit in a f= requency band without a duly issued license.  In the USA, this term is used to mean “licens= e-exempt," see above.

 

To my knowledge, the term “unlicens= ed” is used only in the USA to describe a legal = operation because the term “license-exempt” has been used for a= nother specific purpose.

 

Since the PAWS addresses the interface to t= he database for the international market, it should rely on the definition = of the terms recognized by the ITU-R. I would suggest the use of ‘lic= ensed’ and ‘license-exempt’ with a footnote indicating th= at the term ‘unlicensed’ is used in the USA instead of the usual ‘license-exempt’.<= /p>

 =

Gerald

_________________________= ______________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws


=

 

______________________________= _________________ paws mailing list&nbs= p;paws@ietf.org https://www.ietf.org/mailman/listinfo/paws=

_______________________________= ________________
paws mailing list
p= aws@ietf.org
= https://www.ietf.org/mailman/listinfo/paws

<= /div>

 

 

= --_000_619CDADDCCD2B44380834BE8BF6F714140653B5173EMV62UKRDdoma_-- From nbravin@earthlink.net Wed Feb 1 13:30:22 2012 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 EA95211E809B for ; Wed, 1 Feb 2012 13:30:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrvLx6VX6pQm for ; Wed, 1 Feb 2012 13:30:22 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 1323911E8072 for ; Wed, 1 Feb 2012 13:30:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Y62pjGD+//4/wUjIi6tzsZGNezRyMQ9DXTAGZbkD9yNaz6AiPSCbR1VOrQZcDU3Q; h=Received:From:Content-Type:Subject:Date:Message-Id:Cc:To:Mime-Version:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Rshkz-0006qV-56; Wed, 01 Feb 2012 16:30:21 -0500 From: Nancy Bravin Content-Type: multipart/alternative; boundary=Apple-Mail-1--215214583 Date: Wed, 1 Feb 2012 13:30:19 -0800 Message-Id: To: scott.probasco@nokia.com Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8622937a1606a31e9536fc93ea9a5e0b0f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: [paws] FCC OET Requests Comments on Testing of Telcordia TV Bands Database 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, 01 Feb 2012 21:30:23 -0000 --Apple-Mail-1--215214583 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Scott and all,=20 Thought you might be interested = http://transition.fcc.gov/Daily_Releases/Daily_Business/2012/db0201/DA-12-= 118A1.pdf --Apple-Mail-1--215214583 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Scott and all, 
Thought you might be interested
http://transition.fcc.gov/Daily_Releases/Daily_Business/2012/db0201/DA-12-118A1.pdf

--Apple-Mail-1--215214583-- From nbravin@earthlink.net Thu Feb 2 01:49:00 2012 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 2C5ED21F8AA7 for ; Thu, 2 Feb 2012 01:49:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESpoDEYNtCBX for ; Thu, 2 Feb 2012 01:48:59 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 76FF121F8AB7 for ; Thu, 2 Feb 2012 01:48:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WGtGfEKC8wCBOfipxaNP136hIK8g/ZkswIh82Oo+RVqpJXEB37usrohZZ1hZsdv4; h=Received:From:Content-Type:Content-Transfer-Encoding:Subject:Date:Message-Id:Cc:To:Mime-Version:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RstHm-0006Q6-L7; Thu, 02 Feb 2012 04:48:58 -0500 From: Nancy Bravin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Feb 2012 01:48:57 -0800 Message-Id: <6207679C-25AD-409D-9E22-438BC94C2104@earthlink.net> To: Andy Sago Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad862cc4fda0c605c6c5262b63d8e1551f91350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: [paws] terminology 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, 02 Feb 2012 09:49:00 -0000 Hi Andy, all I found it interesting that the doc I linked to on PAWS simplified the = language re DB, which is the reason I posted it. Hope that was ok to do. SIncerely, Nancy= From scott.probasco@nokia.com Thu Feb 2 08:22:00 2012 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 7C91E21F8600 for ; Thu, 2 Feb 2012 08:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.116 X-Spam-Level: X-Spam-Status: No, score=-2.116 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, J_BACKHAIR_22=1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkZnkNVaLBYB for ; Thu, 2 Feb 2012 08:21:48 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5021F85E9 for ; Thu, 2 Feb 2012 08:21:47 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12GLl43010893 for ; Thu, 2 Feb 2012 18:21:47 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 18:21:46 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 17:21:46 +0100 From: To: Thread-Topic: UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) Thread-Index: AQHM4cbBM1LY84Ao6UaXhXGJCbWG9A== Date: Thu, 2 Feb 2012 16:21:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <67D1CB574B25424EBF468A2C23676702@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 16:21:46.0875 (UTC) FILETIME=[C26F4CB0:01CCE1C6] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) 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, 02 Feb 2012 16:22:00 -0000 Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for sections on protocol services (new section numbering). This text has been marked up from version-02 as uploaded January 26, 2012 to include the previous comments on the mail reflector about use cases vs. protocol services, plus a few suggestions from the editor (removing 'TV' since PAWS applies to all white space, correcting for the fact that we only know at this time the FCC's specific requirements for registration). Our goal is that any discussion on this text will conclude by February 9. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 4.1 Protocol Services A complete protocol solution must provide all services that are essential to enable the white space paradigm. Before a white space device can request service from a white space database, such as a query for a list of available channels, the white space device must first locate or "discover" a suitable database. Additionally, some regulatory authorities require the white space device to register with the database as a first step. This section describes the services required from the protocol. 4.1.1. TVWSWhite space database discovery This use caseWhite space database discovery is preliminary to creating a radio network using TV white space; it is a prerequisite to otherthe use cases below. The radio network is created by a master device. Before the master device can transmit in TV white space spectrum, it must contact a trusted database where the device can learn if any channels are available for it to use. The master device will need to discover a trusted database in the relvant regulatory domain, using the following steps: 1. The master device is connected to the internet by any means other than using the TV white space radio. 2. The master device constructs and sends a service request over the Internet to discover availability of trusted databases in the local regulatory domain and waits for responses. 3. If no acceptable response is received within a pre-configured time limit, the master device concludes that no trusted database is available. If at least one response is received, the master device evaluates the response(s) to determine if a trusted database can be identified where the master device is able to register and receive service from the database. Optionally the radio device is pre-programmed with the internet address of at least one trusted database. The device can establish contact with a trusted database using one of the pre-programmed internet addresses and establish a TV white space network (as described in one of the following use cases). Optionally the initial query will be made to a listing approved by the national regulator for the domain of operation (e.g. a website either hosted by or under control of the national regulator) which maintains a list of TVWS databases and their internet addresses. The query results in the list of databases and their internet addresses being sent to the master, which then evaluates the repsonse to determine if a trusted database can be identified where the master device is able to register and receive service from the database. 4.1.2. Device registration with trusted Database This use caseRegistration is preliminary to creating a radio network using TV white space; it is a prerequisite to otherthe use cases below. The radio network is created by a master device. Before the master device can transmit in TV white space spectrum, it must contact a trusted database where the device can learn if any channels are available for it to use. Before the database will provide information on available TVradio channels, the master device must register with the trusted database. Specific requirements for registration come from individual regulatory domains and may be different. The figure below shows an example deployment of this scenario. \|/ ---------- | |Database| | .---. /--------- |-|---------| ( ) / \|/ | Master | / \ | / | |=3D=3D=3D=3D=3D=3D=3D=3D( Interne= t ) | / |-----------| \ / +-|----+ (TDD AirIF) ( ) |Master| / (----) | | / +------+ Figure 2: Example illustration of registration requirement in TV white space use-case A simplified operational scenario showing registration consists of the following steps: 1. The master device must register with theits most current and up-to- date information. Typically the master device will register prior to operating in TV white space for the first time after power up, after changing location by a predetermined distance, and after regular time intervals. 2. The master device shall provide to the database during registration all information required according to local regulatory requirements. This information may include, but is not limited to, a minimum of the Device ID, serial number assigned by the manufacturer and the device's location, device antenna height above ground, name of the individual or business that owns the device, name of a contact person responsible for the device's operation, address for the contact person, email address for the contact person and phone number of the contact person. 3. Depending upon regulatory domain requirements, the device may also provide device antenna height above ground, name of the individual or business that owns the device, name of a contact person responsible for the device's operation, address for the contact person, email address for the contact person and phone number of the contact person to the database during registration. From scott.probasco@nokia.com Thu Feb 2 09:47:26 2012 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 19FFF21F845E for ; Thu, 2 Feb 2012 09:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8bmzhPCWXi9 for ; Thu, 2 Feb 2012 09:47:23 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B998421F8601 for ; Thu, 2 Feb 2012 09:47:14 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12Hl5Ba012073; Thu, 2 Feb 2012 19:47:05 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 19:47:04 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 18:47:03 +0100 From: To: , , Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM4dKrwPTLa6tGq06svuG1v2Ro4Q== Date: Thu, 2 Feb 2012 17:47:02 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140653B5173@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: multipart/alternative; boundary="_000_CB50241EFEEAscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 17:47:04.0593 (UTC) FILETIME=[ACD51810:01CCE1D2] X-Nokia-AV: Clean Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 02 Feb 2012 17:47:26 -0000 --_000_CB50241EFEEAscottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, Thanks Nancy and Andy for the comments. An excellent point from Andy, we do= n't need to remove all references to TV white space, rather ensure that the= document does not focus on TV bands to the point of excluding other freque= ncy bands. Kind Regards, Scott From: ext com > Date: Wed, 1 Feb 2012 14:57:43 +0000 To: >, "paws@ietf.org" > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Nancy, all Good questions. I=92m not proposing to remove references to TVWS, they are = entirely appropriate within the use cases since it is the TV bands we are s= tudying as first candidate for opportunistic access, but the charter says w= e are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary informa= tion in this PAWS requirements I-D to enable the PAWS protocol I-D to be de= veloped. I don=92t think it=92s our job to explain different regulatory reg= imes or applications (beyond use cases) in this document, ITU and others do= this very well, and regulators tend to be well coordinated or play =91foll= ow my leader=92. Thanks for pointing out the reference to licence-exempt that I had missed i= n 4.4 - I think the meaning would be just the same with =91in a license-ex= empt TVWS environment=92 deleted from that sentence. That would be my sugge= stion. Regards Andy From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: 01 February 2012 14:48 To: Sago,AJ,Andy,COD R Cc: paws@ietf.org Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Intro= duction, Conventions and Terminology, Prior Work) Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6= =85so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain ho= w the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could change, = but, why not give the information on both for countries to understand fully what it's choices are? Thanks Andy, just some early morning thoughts=85Sincerely, Nancy Begin forwarded message: From: Nancy Bravin > Date: February 1, 2012 6:35:09 AM PST To: Andy Sago > Cc: >, >, >, > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Andy, All In section 4.4, license exempt is also mentioned as well. I am conflicted in a global sense when emerging countries, or countries wit= h very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby join = the existing DB companies, or will they do their own thing leaving holes in what one hopes will be an interoperable global protocol th= at deals with TVWS, and/or White spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, > > wrote: Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV = white spaces, whereas the scope of PAWS is white spaces in general. I would= question not only why the lower-priority service would always be licence-e= xempt, but why the higher priority service would always be licenced. To avo= id this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/= paws/current/msg00576.html) a revision of the Abstract that avoids the term= s licence exempt or unlicensed, or any mention of the regulatory status of = the incumbent services. The Abstract derives from the Introduction and the = text could be aligned to be the same in the Introduction, with =93opportuni= stic=94 replacing =93secondary=94 in later sentences in the Introduction. I= have checked and there are no further references to licensing in the docum= ent, so we don=92t need the definitions of licence exempt, light licensing = or unlicensed. This is not a regulatory document =96 we are defining requir= ements fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum= use has now got muddled with the potential for opportunistic use. This can= be fixed by taking the white space and white space device definitions toge= ther. From Scott, Gerald and Jussi=92s comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum= , under control of a white space database. A white space device can be an = access point, base station, a portable device or similar. In this context,= a white space device is required by local regulations to query a database = with its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of jussi.kah= tava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; sc= ott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not= necessarily apply to all under-utilised radio spectrum. Why would the lowe= r priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Geral= d Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of =93white space=94 as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed by = local regulations for use to be used opportunistica= lly as licensed-exempt spectrum under control of a white space data= base. This way, it is understood that the database does not =93assign=94 white sp= ace devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notio= n of secondary use is included. The secondary status is used in the ITU-R = Radio Regulations for a different purpose. In fact, it is possible that a = band has already primary and secondary services allotted to it and that the= White Space operation is a tertiary opportunistic operation where the two = first types of services are not being used. The use of =93lower priority o= pportunistic=94 service rather than =93secondary=94 service would be prefer= able to describe white space allocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use<= /Delete>and assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers =93license-exempt=94 and = =93unlicensed=94 can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an =93unlicensed=94 band is typically a ne= w band, say in the 300 GHz, for which no request has been made for its use.= It is therefore un-allocated to a specific service so far and thus it is = an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to o= ne or many services on a primary or secondary basis, then the administratio= ns can thendecide under what king of regime it will =91assign=92 this band = foroperation. They may decide to allow the use of the band on the basis of = licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licen= ses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also= called =93unlicensed=94 in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a =93license-exempt=94 operation. I= f, however, someone decides to start an RF transmission operation in a lice= nsed band for which he has no license or in a license-exempt band for which= he does not meet the requirements such as operating according to the type = of operation for which the band is exempted from a license or he operates o= utside the technical limits imposed by this license-exempt ruling, his oper= ation is therefore illegal and he is then considered to be running an =93un= licensed=94 operation. If the qualifier applies to the transmission device, such device may be a = =93license-exempt=94 device if its operation does not require a specific li= cense or registration with the local administration such as TV receivers of= Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a dev= ice that is not allowed in a country by, for example, buying it on eBay and= operates it, this is then an illegal device in the country and id de-facto= an =93unlicensed=94 device since it has not passed through the normal cert= ification process. Note that a =93license-exempt=94 device still has to go through a certifica= tion process and meet the limits imposed by the local regulator for the =93= license-exempt=94 operation in the given frequency band whereas an =93unlic= ensed=94 device may not pass the certification process since it has not bee= n licensed to operation in the country. This is why the qualifier =93unlicensed=94 has to be treated with care and = the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows =93lice= nsed=94 operation, the situation will be much simpler to manage since speci= fic conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word=91unlicensed=92 which may mean =91illegal=92 o= peration of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as =91license-exempt=92, in most cases t= he term =91unlicensed-band=92 is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ 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 --_000_CB50241EFEEAscottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi All,

Thanks Nancy and Andy for the comments. An excellent point from Andy, = we don't need to remove all references to TV white space, rather ensure tha= t the document does not focus on TV bands to the point of excluding other f= requency bands.

Kind Regards,
Scott 

From: ext com <andy.sago@bt.com>
Date: Wed, 1 Feb 2012 14:57:43 += ;0000
To: <nbravin@earthlink.net>, "paws@ietf.org" <paws@= ietf.org>
Subject: Re: [paws] Use cases and r= equirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology= , Prior Work)

Nancy, all

 

Good questions. I=92m not proposing to remove refer= ences to TVWS, they are entirely appropriate within the use cases since it = is the TV bands we are studying as first candidate for opportunistic access, but the charter says we are addressing= all white space in the resulting protocol. To answer your other questions,= IMO our aim should be to provide all the necessary information in this PAW= S requirements I-D to enable the PAWS protocol I-D to be developed. I don=92t think it=92s our job to expla= in different regulatory regimes or applications (beyond use cases) in this = document, ITU and others do this very well, and regulators tend to be well = coordinated or play =91follow my leader=92.

 

Thanks for pointing out the reference to licence-ex= empt that I had missed in 4.4 -  I think the meaning would be just the= same with =91in a license-exempt TVWS environment=92 deleted from that sentence. That would be my suggestion.=

 

Regards

 

Andy

 

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February 2012 14:48
To: Sago,AJ,Andy,COD R
Cc: paws@ietf.org
Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3= (Introduction, Conventions and Terminology, Prior Work)<= /p>

 

Hi Andy, also, throughout the document TVWS are ment= ioned in 4.1,4.5, 4.6=85so if you propose to remove any reference to TVWS i= t will affect

the document as a whole, and information that seems = necessary to explain how the DB and protocol interacts with TVWS devices an= d

the methods of doing so. One can envision that curre= nt rules could change, but, why not give the information on both for countr= ies to understand fully

what it's choices are? 

 

Thanks Andy, just some early morning thoughts=85Sinc= erely, Nancy

 

Begin forwarded message:



From: Nancy Bravin <nbravin@e= arthlink.net>

Date: February 1, 2012 6:35:09 AM PST

To: Andy Sago <andy.sago@bt.com<= /a>>

Subject: Re: [paws] Use cases and requirements I-D: = sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 

Hi Andy, All

 

In section 4.4, license exempt is also mentioned as = well. 

I am conflicted in a global sense when emerging coun= tries, or countries with very different types of gov't want to implement

the protocol, will they have enough information to d= o so? and thereby join the existing DB companies, or will they do their own= thing

leaving holes in what one hopes will be an interoper= able global protocol that deals with TVWS, and/or White spaces in general?<= o:p>

 

Thanks, just a thought.

 

SIncerely, Nancy

 

 

On Feb 1, 2012, at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> wrote:



Scott, All

 

I agree with Jussi that we have now narrowed the de= finition to apply to TV white spaces, whereas the scope of PAWS is white sp= aces in general. I would question not only why the lower-priority service would always be licence-exempt, but wh= y the higher priority service would always be licenced. To avoid this issue= on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/paws/current= /msg00576.html) a revision of the Abstract that avoids the terms licence exempt or unlicen= sed, or any mention of the regulatory status of the incumbent services. The= Abstract derives from the Introduction and the text could be aligned to be= the same in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in later sentences in the In= troduction. I have checked and there are no further references to licensing= in the document, so we don=92t need the definitions of licence exempt, lig= ht licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep i= t simple.

 

That just leaves the definition of white space, whe= re the existing spectrum use has now got muddled with the potential for opp= ortunistic use. This can be fixed by taking the white space and white space device definitions together.  = >From Scott, Gerald and Jussi=92s comments perhaps we could agree on:=

 

White Space (WS)=

 

Radio spectrum which is not = fully occupied at a specific location and time.

 

White Space device

 

A device which opportunistic= ally uses some part of the white space spectrum, under control of a white s= pace database.  A white space device can be an access point, base station, a portable device or similar.  In t= his context, a white space device is required by local regulations to query= a database with its location to obtain information about available spectru= m.

 

Regards

 

Andy

 

From: paws-bounces@ietf.org=  [mailto:paws= -bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February = 2012 07:31
To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws= ] Use cases and requirements I-D: sections 1 to 3 (Introduction, Convention= s and Terminology, Prior Work)

 

That statement is valid for TV Whi= te Spaces on UHF frequencies but does not necessarily apply to all under-ut= ilised radio spectrum. Why would the lower priority service by default be licence-exempt?

 

Kind regards,

Jussi

 

From: paws-bounces@ietf.org=  [mailto:paws= -bounces@ietf.org] On Behalf Of ext Gerald= Chouinard
Sent: 31 January 2= 012 22:33
To: Probasco Scott= (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws= ] Use cases and requirements I-D: sections 1 to 3 (Introduction, Convention= s and Terminology, Prior Work)

 

Scott,

 

Very good improvements. I would s= uggest to insert the notion of opportunistic use of the spectrum by white s= pace devices in the last sentence of the definition of =93white space=94 as follows:

 

White Space

 

Radio spectrum which has bee= n allocated and assigned for licensed use, but is not fully occupied by tha= t licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <i= nsert>allowed<insert> by local regulations <delete>for use&l= t;delete> <insert>to be used opportunistically<insert> as li= censed-exempt spectrum under control of a white space database.</Insert&= gt;

 

This way, it is understood that t= he database does not =93assign=94 white space devices for them to choose fr= om.

 

Gerald

From: scott.probasco@nokia.com [ma= ilto:scott.probasco@nokia.com]&nb= sp;
Sent: Tuesday, 31 = January, 2012 15:12
To: gerald.chouinard@sympatico.ca; paws@ietf.org
Subject: Re: [paws= ] Use cases and requirements I-D: sections 1 to 3 (Introduction, Convention= s and Terminology, Prior Work)

 

Hi Gerald,=

 

Good to avoid overloading th= e term "secondary". I have made additional proposed changes to th= e text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that w= e would need some explanation of what that means. Since we now have descrip= tions of licensed spectrum and license-exempt spectrum, I used these words.= Do these changes remove your concerns?

 

I also corrected "locat= ion" to "local" in previous text proposed for "White Sp= ace".

 

Kind Regards,

Scott

 

From: ext Gerald Chouinard = <gerald.chouinard@sympa= tico.ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@no= kia.com>, "paws@ietf.org&q= uot; <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work)

 

Scott,

Great proposal.  However,= I am still a bit nervous about the definitions of =93Protected Entity=94 a= nd =93White Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary status is used in the IT= U-R Radio Regulations for a different purpose.  In fact, it is possibl= e that a band has already primary and secondary services allotted to it and= that the White Space operation is a tertiary opportunistic operation where the two first types of services are not bein= g used.  The use of =93lower priority opportunistic=94 service rather = than =93secondary=94 service would be preferable to describe white space al= locations.

 

Gerald

 

From: paws-b= ounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work)

 =

Hi,=

 

I changed the subject lin= e from " Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' &nb= sp;". Here I try to propose some changes to the draft based on the email discussion.

 

Below is a copy of chapte= r 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-e= xempt' and made changes to the term 'white space'. I have tried to work from the perspective that the document should= accurately explain the subject with aim that a reader can understand the u= se cases and the subsequent requirements. No doubt we could include much mo= re text on this topic of spectrum allocation, assignment, licensing and usage.

 

I hope this captures the = key points of the discussion. Please do reply if something is still missing= .

 

Kind Regards,<= o:p>

Scott

 

 

2.2.  Terminology

 

   Database

 

      = ;In the context of white space and cognitive radio technologies,=

      = ;the database is an entity which contains current information about<= /b>

      = ;available spectrum at any given location and other types of

      = ;information.

 

   Device ID

 

      = ;A unique number for each master device and slave device that

      = ;identifies the manufacturer, model number and serial number.

 

<Insert>=

   Licensed Spe= ctrum

 

      = ;Spectrum that is acquired by an operator over a given service area<= /b>

      = ;for a given time period.  This is usually done through auctions,award=

      = ;(beauty contest), acquisition from secondary market, company merger &<= /span>

      = ;acquisition,  first-come / first-served or by government allocation

      = ;(e.g., public service).

 

   License-exem= pt Spectrum

 

      = ;Spectrum that is not assigned to any specific user. One example is the 2.4= Ghz ISM band, where RF devices

      = ;operate without a formal licensing process. In the USA, license-exempt spectrum is<= /o:p>

      = ;Typically referred to as "unlicensed" spectrum. In this document= the terms

      = ;license-exempt and unlicensed are used interchangeably.

 

</Insert>

 

   Location Bas= ed Service

 

      = ;An application or device which provides data, information or

      = ;service to a user based on their location.

 

   Master Devic= e

 

      = ;A device which queries the WS Database to find out the available

      = ;operating channels.

 

   Protected En= tity

 

      = ;<Insert>A licensed user of spectrum, when the licensed spectrum has = been assigned as white space spectrum.</Insert> <Delete>A prima= ry</Delete><Insert>A licensed</Insert> user of white space spectrum <Delete>which&l= t;/Delete> is afforded

      = ;protection against interference by <Delete>secondary</Delete>&= lt;Insert>license-exempt white space</Insert> users <Delete>= (white space

      = ;devices) for its use</Delete> in a given area and time.

 

   Protected Co= ntour

 

      = ;The exclusion area for a Protected Entity, held in the database=

      = ;and expressed as a polygon with geospatial points as the vertices.<= /b>

 

   Slave Device=

 

      = ;A device which uses the spectrum made available by a master

      = ;device.

 

   TV White Spa= ce

 

      = ;TV white space refers specifically to radio spectrum which has<= o:p>

      = ;been allocated for TV broadcast, but is not occupied by a TV

      = ;broadcast, or other licensed user (such as a wireless microphone),<= /b>

      = ;at a specific location and time.

 

   White Space<= /span>

 

      = ;Radio spectrum which has been allocated <Delete>for some primary use= </Delete><Insert>and assigned for licensed use</Insert>, = but

      = ;is not fully occupied by that <Delete>primary use</Delete><= Insert> licensed use </Insert> at a specificlocation

      = ;and time. <Insert>This spectrum is then assigned by <Delete>lo= cation</Delete><Insert>local</Insert> regulations for use= as licensed-exempt spectrum under control of a white space database.</Insert>

 

   White Space = Device (WSD)

 

     = A device which is a <Delete>secondary</Delete><Insert>lic= ense-exempt</Insert> user of some part of white space=

      = ;spectrum.  A white space device can be an access point, base

      = ;station, a portable device or similar.  In this context, a white

      = ;space device is required to query a database with its location to

      = ;obtain information about available spectrum.

 

 

 

From: ext Gerald Chouinard = <gerald.chouinard@sympa= tico.ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@ear= thlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Nancy,

 

This is not that simple.  = ;In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can appl= y to more than one thing.

 

If the qualifier applies to a = frequency band, different options exist. As an example, in the ITU-R contex= t, an =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its u= se.  It is therefore un-allocated to a specific service so far and thu= s it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this b= and to one or many services on a primary or secondary basis, then the administrations can thendecide under what kin= g of regime it will =91assign=92 this band foroperation. They may decide to= allow the use of the band on the basis of licensed operation (with differe= nt options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of lic= enses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is al= so called =93unlicensed=94 in the&nbs= p;USA.

 

If the qualifier applies to an= operation, the operation can be exempt of license by the local administrat= ion, thus a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a li= censed band for which he has no license or in a license-exempt band for whi= ch he does not meet the requirements such as operating according to the typ= e of operation for which the band is exempted from a license or he operates outside the technical limits imp= osed by this license-exempt ruling, his operation is therefore illegal and = he is then considered to be running an =93unlicensed=94 operation.

 

If the qualifier applies to th= e transmission device, such device may be a =93license-exempt=94 device if = its operation does not require a specific license or registration with the local administration such as TV receivers= of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someone smuggl= es a device that is not allowed in a country by, for example, buying it on = eBay and operates it, this is then an illegal device in the country and id de-facto an =93unlicensed=94 device s= ince it has not passed through the normal certification process.=

 

Note that a =93license-exempt= =94 device still has to go through a certification process and meet the lim= its imposed by the local regulator for the =93license-exempt=94 operation in the given frequency band whereas an =93u= nlicensed=94 device may not pass the certification process since it has not= been licensed to operation in the country.

 

This is why the qualifier =93u= nlicensed=94 has to be treated with care and the footnote will need to be c= rafted very carefully.

 

With respect to your second po= int, if an administration only allows =93licensed=94 operation, the situati= on will be much simpler to manage since specific conditions will be attached to these licenses.

 

Gerald

 

From: Nancy Bravin [mailto:nbravin@earthlink.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 =

Gabor = and Gerald, 

Since = we are dealing on a global basis, can there a footnote to "unlicensed&= quot; we can use to indicate that "according to each countries regulat= ory requirements"  

How to= get around the fact that some Countries are or will be "licensed only= " by their gov'ts?  Thanks

Nancy<= /span>

On Jan= 30, 2012, at 4:13 PM, Gerald Chouinard wrote:




Gabor,

 

I agree with your proposal.&nb= sp; Thisseems to be reasonable.  However one needs to be careful with = the word=91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many administrations.

 

Gerald

 

From: Gabor.= Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 =

These look to be= very precise definitions, however in everyday use I rarely hear people ref= erring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.

 

Therefore, may I= suggest that the draft will include the following statement:

 

The terms unlice= nsed and license-exempt spectrum are used in this document interchangeably = and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM = band.

 

-    &= nbsp;     Gabor=

 

From: paws-b= ounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 =

All,

 <= /p>

Here is my understanding of th= e terms:

 

Licensed: Spectrum that is acq= uired by an operator over a given service area for a given time period. &nb= sp;This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government= allocation (e.g., public service).

 

Lightly licensed: Special case= where thefrequency allocation is done through first-come / first-served pr= ocess for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitat= e the deployment of a service that would not normally be economically attra= ctive.  Small local operators would be interested by this (e.g., rural= broadband in Canada) and not big Telcos that would normally work with full licensing through au= ction over large service areas.

 

License-exempt: Operation of R= F devices in a frequency band where no formal licensing process is needed s= uch as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be cont= acted to clarify it.

 

Unlicensed: Illegal operation = of an RF device that can transmit in a frequency band without a duly issued= license.  In the US= A, this term is used to mean =93license-exempt," see above.

 

To my knowledge, the term =93u= nlicensed=94 is used only in the = ;USA to describe a legal operation because the term =93license-exempt=94 has been = used for another specific purpose.

 

Since the PAWS addresses the i= nterface to the database for the international market, it should rely on th= e definition of the terms recognized by the ITU-R. I would suggest the use of =91licensed=92 and =91license-exempt= =92 with a footnote indicating that the term =91unlicensed=92 is used in th= e USA instead of the usual =91license-exempt=92.

 

Gerald

_______________________________________________ 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 ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB50241EFEEAscottprobasconokiacom_-- From Gabor.Bajko@nokia.com Thu Feb 2 10:26:00 2012 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 4982F21F85D4 for ; Thu, 2 Feb 2012 10:26:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.358 X-Spam-Level: X-Spam-Status: No, score=-1.358 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuAuDENmk2Ni for ; Thu, 2 Feb 2012 10:25:58 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1F13B21F85BE for ; Thu, 2 Feb 2012 10:25:57 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12IPLne011445; Thu, 2 Feb 2012 20:25:22 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 20:25:21 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.5]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 19:25:21 +0100 From: To: , , , Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: AczfoOYkBqIvPtzVQA6ucq3r2yBLaf//+A4AgAEbk4CAACxgAP/81wcg Date: Thu, 2 Feb 2012 18:25:19 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DECC79@008-AM1MPN1-006.mgdnok.nokia.com> References: <5CFF94AC6128EA478EB1B82775E1B6A726FA2CD75F@rrc-dte-exmb1.dte.telcordia.com> <86AFD2C7-533D-446D-9A3F-D1489F7C039A@earthlink.net> <7BAC95F5A7E67643AAFB2C31BEE662D01567642FA6@SC-VEXCH2.marvell.com> <32E7EA09-A091-4FE5-B3A1-85F249D3520E@neustar.biz> <7BAC95F5A7E67643AAFB2C31BEE662D01567642FBD@SC-VEXCH2.marvell.com> <1328026335.6265.YahooMailNeo@web36703.mail.mud.yahoo.com> <7BAC95F5A7E67643AAFB2C31BEE662D01567643194@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567643194@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DECC79008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 18:25:21.0774 (UTC) FILETIME=[060F18E0:01CCE1D8] X-Nokia-AV: Clean Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' 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, 02 Feb 2012 18:26:00 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DECC79008AM1MPN1006mg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSB3b25kZXJpbmcgd2hlcmUgd2UgYXJlIHdpdGggdGhlIGRpc2N1c3Npb24gb24gdGhpcyB0 b3BpYy4NCg0KR2VyYWxkIGNsYXJpZmllZCBpbiBvbmUgb2YgdGhlIHByZXZpb3VzIG1haWxzIHdo YXQgdGhlIHF1YWxpZmllcnMg4oCYbGljZW5zZS1leGVtcHTigJkgYW5kIOKAmHVubGljZW5zZWTi gJkgbWVhbiB3aGVuIHRoZXkgYXJlIGF0dGFjaGVkIHRvIGEgZnJlcXVlbmN5IGJhbmQsIGFuIG9w ZXJhdGlvbiBvciBhIGRldmljZS4NClNjYW5uaW5nIHRocm91Z2ggdGhlIGRvY3VtZW50LCBJIGZv dW5kIDIgaW5zdGFuY2VzIG9mIHVubGljZW5zZWQgbm90IGF0dGFjaGVkIHRvIGFueXRoaW5nLCBh bmQgb25lIGluc3RhbmNlIG9mIOKAmGxpY2Vuc2UtZXhlbXB04oCZIHNwZWN0cnVtLg0KDQpTaW5j ZSBJRVRGIGhpc3RvcmljYWxseSBoYXMgbm90IGRlYWx0IG11Y2ggd2l0aCBvcGVyYXRpb24gaW4g Y2VydGFpbiBmcmVxdWVuY3kgYmFuZHMsIGl0IHdvdWxkIGJlIGdvb2QgdG8gZGVmaW5lIHRoZXNl IHRlcm1pbm9sb2dpZXMgYW5kIGFkanVzdCB0aGUgdGV4dCBpbiB0aGUgZHJhZnQgYWNjb3JkaW5n bHkuDQoNCk5vdywgdGhlIHF1ZXN0aW9uIGlzIGlmIHRoZXNlIHRlcm1pbm9sb2dpZXMgY2FuIGJl IHVzZWQgdG8gYWxzbyBxdWFsaWZ5IGEgV1MgZGV2aWNlLCBXUyBzcGVjdHJ1bSBhbmQvb3IgV1Mg b3BlcmF0aW9uLiBJZiBub3QsIHdlIG1heSBuZWVkIGFkZGl0aW9uYWwgZGVmaW5pdGlvbnMgZm9y IHRoZXNlLCBJIHRoaW5rIHRoaXMgaXMgd2hhdCBQYXVsIHN1Z2dlc3RlZCBkb3duIGJlbG93Lg0K DQoNCi0gICAgICAgICAgR2Fib3INCg0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBleHQgUGF1bCBMYW1iZXJ0 DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDMxLCAyMDEyIDEwOjUxIEFNDQpUbzogTS5LLlNhamVl djsgUm9zZW4sIEJyaWFuOyBwYXdzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3Bhd3NdIERpc2N1 c3Npb24gb24gJ2xpY2Vuc2UtZXhlbXB0JyB2cyAndW5saWNlbnNlZCcNCg0KDQpMaWdodGx5ICBs aWNlbnNlZCBhbmQgbGljZW5zZSBleGVtcHQgKG9yIHVubGljZW5zZWQgaW4gRkNDIHZlcm5hY3Vs YXIpIGhhdmUgcHJpb3Ig4oCTIHRoYXQgd2FzIHdoeSBJIHdhcyBwcm9wb3NpbmcgdGhhdCB3ZSBz aG91bGQgaW5jbHVkZSBhIGRlZmluaXRpb24gZm9yIHRoZSBnZW9sb2NhdGlvbiBiYXNlZCB3aGl0 ZSBzcGFjZSBhY2Nlc3MgdGhhdCBwYXdzIGlzIHN1cHBvcnRpbmcgYXMgYSBuZXcgZGVmaW5pdGlv bi4NCg0KUGF1bA0KDQoNClBhdWwgQS4gTGFtYmVydCB8IE1hcnZlbGwgU2VtaWNvbmR1Y3RvciB8 ICsxLTY1MC03ODctOTE0MQ0KDQpGcm9tOiBNLksuU2FqZWV2IFttYWlsdG86bWtzYWppQHlhaG9v LmNvbV08bWFpbHRvOlttYWlsdG86bWtzYWppQHlhaG9vLmNvbV0+DQpTZW50OiBUdWVzZGF5LCBK YW51YXJ5IDMxLCAyMDEyIDg6MTIgQU0NClRvOiBQYXVsIExhbWJlcnQ7IFJvc2VuLCBCcmlhbjsg cGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbcGF3c10g RGlzY3Vzc2lvbiBvbiAnbGljZW5zZS1leGVtcHQnIHZzICd1bmxpY2Vuc2VkJw0KDQpIaSwNCg0K QSBiaXQgY29uZnVzZWQgc2VlaW5nIHRoZSAndW5saWNlbnNlZCcgYmFuZCBkaXNjdXNzaW9uIGhl cmUuIFdpbGwgYSB3aGl0ZSBzcGFjZSBkYXRhYmFzZSBiZSBtYWludGFpbmluZyBkZXRhaWxzIG9m IGRldmljZXMvY2hhbm5lbCBhbGxvY2F0aW9ucyBvZiB1bmxpY2Vuc2VkIGJhbmQgb3BlcmF0aW9u IG9mIGRldmljZXM/IChpcyBpdCByZWFsbHkgZmVhc2libGUsIGFzIHVubGljZW5zZWQgYmFuZCBj YW4gYmUgdXNlZCBieSBhbnkgZGV2aWNlIHdpdGhvdXQgYW55IHNwZWNpZmljIGNoYW5uZWxzIGFs bG9jYXRpb24sIGV0Yy4uLi4pIE9yIHdpbGwgdGhlIGRhdGFiYXNlcyBsaW1pdCB0aGVpciBvcGVy YXRpb24gdG8ganVzdCB0aGUgIGxpY2Vuc2VkL2xpZ2h0bHkgbGljZW5zZWQgYmFuZCBvcGVyYXRp b25zPyBPciBpcyBpdCBqdXN0IHRoYXQgd2UgYXJlIG9ubHkgZGVmaW5pbmcgdGhlc2UgdGVybXMg aGVyZS4NCg0KQmVzdCBSZWdhcmRzLA0KDQpTYWplZXYgTWFuaWtrb3RoDQpNb2JpbGU6ICs5MTk2 NjMzMTEzNzgNCkVtYWlsOiBta3NhamlAaWVlZS5vcmc8bWFpbHRvOm1rc2FqaUBpZWVlLm9yZz4N Cmh0dHA6Ly93d3cubGlua2VkaW4uY29tL2luL21rc2FqZWV2DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KRnJvbTogUGF1bCBMYW1iZXJ0IDxwYXVsQG1hcnZlbGwuY29tPG1haWx0 bzpwYXVsQG1hcnZlbGwuY29tPj4NClRvOiAiUm9zZW4sIEJyaWFuIiA8QnJpYW4uUm9zZW5AbmV1 c3Rhci5iaXo8bWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Pj47ICJwYXdzQGlldGYub3Jn PG1haWx0bzpwYXdzQGlldGYub3JnPiIgPHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5v cmc+Pg0KU2VudDogVHVlc2RheSwgMzEgSmFudWFyeSAyMDEyLCA0OjQ3DQpTdWJqZWN0OiBSZTog W3Bhd3NdIERpc2N1c3Npb24gb24gJ2xpY2Vuc2UtZXhlbXB0JyB2cyAndW5saWNlbnNlZCcNCg0K PiBVaCwgd2hpdGVzcGFjZSBkZXZpY2U/DQrimLoNCk1heWJlIOKApiBidXQgaWYgd2UgYXJlIHRh bGtpbmcgYWJvdXQgdGhlIOKAnGxpY2Vuc2XigJ0gaXQgbWlnaHQgYmUgIOKAnERhdGFiYXNlIExp Y2Vuc2Vk4oCdLCDigJxEYXRhYmFzZSBMaWNlbnNlLUV4ZW1wdOKAnSwgb3IgIOKAnFdoaXRlIFNw YWNlIExpY2Vuc2Vk4oCdDQoNClNlZW1zIGxpa2Ugd2UgaGFkIHNvbWUgcmVhbGx5IGV4Y2VsbGVu dCBkZWZpbml0aW9ucyDigJMgYnV0IGhhcHBlbmVkIHRvIGJlIG1pc3NpbmcgdGhlIGNhdGVnb3J5 IHRoYXQgd2UgYXJlIHRyeWluZyB0byBzdXBwb3J0Lg0KDQrigJxVbmxpY2Vuc2Vk4oCdIGluIEZD QyB0ZXJtcyBhbHNvIGhhcyBhIGNvbm5vdGF0aW9uIG9mIG11bHRpcGxlIHVzZXJzIGFuZCByb2J1 c3RuZXNzLiAgRGV2aWNlcyBvcGVyYXRpbmcg4oCcdW5saWNlbnNlZOKAnSBhcmUgbm90IGNvbmNl cm5lZCBhYm91dCBwb3RlbnRpYWwgaW50ZXJmZXJlbmNlIHdpdGggb3RoZXIgdW5saWNlbnNlZCBk ZXZpY2VzLiAgVGhlcmUgYXJlIHBvdGVudGlhbGx5IG11bHRpcGxlIGFuZCB0aGV5IGdlbmVyYWxs eSBuZWVkIHRvIHBsYXkgd2VsbCB0b2dldGhlci4gIExpY2Vuc2VkIGRldmljZXMgYXJlIHR5cGlj YWxseSBhIHNpbmdsZSBvd25lciB0byBmYWNpbGl0YXRlIGEgbGV2ZWwgb2Ygc2VydmljZSBiYXNl ZCBvbiBhIG1vcmUgY29vcmRpbmF0ZWQgbW9kZWwuDQoNClNlZW1zIGxpa2UgYWxsIGRldmljZXMg YXJlIGxpY2Vuc2VkIGZyb20gdGhlIHBlcnNwZWN0aXZlIHRoYXQgdGhlIGFpci13YXJlcyBhcmUg Y29udHJvbGxlZCBhbmQgYWxsb2NhdGVkLiAgRXZlbiB1bmxpY2Vuc2VkIG9yIGxpY2Vuc2VkIGV4 ZW1wdCBhbGxvY2F0aW9ucyBoYXZlIGxpbWl0YXRpb25zIGFuZCBkZXZpY2UgY29uZm9ybWFuY2Ug dGVzdGluZy4gIEl04oCZcyBqdXN0IHRoYXQgdGhlIGVuZC11c2VyIGRvZXMgbm90IG5lZWQgdG8g ZXhwbGljaXRseSBmaWxlIGZvciBhIGxpY2Vuc2UgaW4gdGhlc2UgYmFuZHMuDQoNCkFzIGFuIGFy Y2hpdGVjdHVyZSDigJMgYWxsIGRldmljZXMgaGF2ZSBhIGxpY2Vuc2UsIGFuZCB0aGF0IHNvbWUg anVzdCBoYXBwZW4gdG8gaGF2ZSBwYWlkIG1vbmV5IG9yIGJlZW4gZ2l2ZW4gYSBtb25vcG9seSBi eSBhbiBhdXRob3JpdHkgdG8gaGF2ZSBhIHNpbmdsZSB1c2VyIGxpY2Vuc2UuICBTb21lIG9mIHRo ZSBsaWNlbnNlcyBjYW4gYmUgc2hvcnQgbGl2ZWQgYW5kIG5lZWQgdG8gYmUgZGlzdHJpYnV0ZWQu ICBTb21lIGFyZSBpbXBsaWNpdCBiYXNlZCBvbiB0aGUgY29uZm9ybWFuY2UgdGVzdHMgdGhhdCB0 aGUgZGV2aWNlIG11c3QgcGFzcy4gIFRoZSBsaWNlbnNlcyB0aGF0IHBhd3MgaXMgYWRkcmVzc2lu ZyBhcmUgb25lcyB0aGF0IGNhbiBiZSBtb2RpZmllZCBieSBzb21lIGZvcm0gb2YgSVAgY29tbXVu aWNhdGlvbnMgKGFrYSBkYXRhYmFzZSBsb29rdXApLg0KDQpTbyDigKYgYXMgYW4gYXR0ZW1wdCBm b3IgdGV4dCDigKYuDQoNCldoaXRlc3BhY2UgbGljZW5zZWQ6IE9wZXJhdGlvbiBvZiBSRiBkZXZp Y2VzIGluIGEgZnJlcXVlbmN5IGJhbmQgd2hlcmUgYXV0aG9yaXplZCBvcGVyYXRpb24gaXMgZGV0 ZXJtaW5lZCBiYXNlZCBvbiBhIGRldmljZXMgbG9jYXRpb24sIGRldmljZSB0eXBlIGFuZCBvcGVy YXRpbmcgdGltZSBwZXJpb2QuICBDb29yZGluYXRpb24gb2YgdGhpcyBtb2RlIG9mIG9wZXJhdGlv biB3aWxsIHR5cGljYWxseSBiZSBtYW5hZ2VkIGJ5IGRhdGFiYXNlcyB0cmFja2luZyBMaWNlbnNl ZCBvcGVyYXRpb24gaW4gdGhlIHNhbWUgYmFuZHMuDQoNCg0KUGF1bA0KDQpQYXVsIEEuIExhbWJl cnQgfCBNYXJ2ZWxsIFNlbWljb25kdWN0b3IgfCArMS02NTAtNzg3LTkxNDENCg0KRnJvbTogUm9z ZW4sIEJyaWFuIFttYWlsdG86QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXpdPG1haWx0bzpbbWFpbHRv OkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6XT4NClNlbnQ6IE1vbmRheSwgSmFudWFyeSAzMCwgMjAx MiAyOjQ2IFBNDQpUbzogUGF1bCBMYW1iZXJ0DQpDYzogTmFuY3kgQnJhdmluOyBNYWx5YXIsIEpv aG4gUDsgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb cGF3c10gRGlzY3Vzc2lvbiBvbiAnbGljZW5zZS1leGVtcHQnIHZzICd1bmxpY2Vuc2VkJw0KDQpV aCwgd2hpdGVzcGFjZSBkZXZpY2U/DQoNClNvcnJ5LCBjb3VsZG4ndCByZXNpc3QuDQoNCkJyaWFu DQoNCk9uIEphbiAzMCwgMjAxMiwgYXQgNTo0NCBQTSwgUGF1bCBMYW1iZXJ0IHdyb3RlOg0KDQoN CldoYXQgaXMgdGhlIGNvcnJlY3QgdGVybSBmb3Igc29tZXRoaW5nIHRoYXQgaXMgb3BlcmF0aW5n IGFzIGEgbGljZW5zZS1leGVtcHQgZGV2aWNlIOKAkyB5ZXQgaGFzIGJlZW4gZ2l2ZW4gc2hvcnQg dGVybSBhdXRob3JpemF0aW9uIHRvIHNoYXJlIGEgY2hhbm5lbCB3aXRoIG90aGVyIGxpY2Vuc2Ut ZXhlbXB0IGRldmljZXMgYmFzZWQgb24gYSBxdWVyeSB0byBhIHJlZ2lvbmFsIGF1dGhvcml0aWVz IGRhdGFiYXNlIGluIGEgcG9ydGlvbiBvZiBzcGVjdHJ1bSB0aGF0IG1heSBhbHNvIGluY2x1ZGUg bGljZW5zZWQgb3IgbGlnaHQtbGljZW5zZWQgZGV2aWNlcyBhdCBvdGhlciB0aW1lcyBvciBpbiBv dGhlciBhcmVhcy4NCg0KDQpQYXVsDQoNCg0KDQpGcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5v cmddPG1haWx0bzpbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBH ZXJhbGQgQ2hvdWluYXJkDQpTZW50OiBNb25kYXksIEphbnVhcnkgMzAsIDIwMTIgMzozMCBQTQ0K VG86IHBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbcGF3c10g RGlzY3Vzc2lvbiBvbiAnbGljZW5zZS1leGVtcHQnIHZzICd1bmxpY2Vuc2VkJw0KDQpBbGwsDQoN CkhlcmUgaXMgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgdGVybXM6DQoNCkxpY2Vuc2VkOiBTcGVj dHJ1bSB0aGF0IGlzIGFjcXVpcmVkIGJ5IGFuIG9wZXJhdG9yIG92ZXIgYSBnaXZlbiBzZXJ2aWNl IGFyZWEgZm9yIGEgZ2l2ZW4gdGltZSBwZXJpb2QuICBUaGlzIGlzIHVzdWFsbHkgZG9uZSB0aHJv dWdoIGF1Y3Rpb25zICh0aGluayBvZiB0aGUgVGVsY29zKSwgYmVhdXR5IGNvbnRlc3QsIGZpcnN0 LWNvbWUgLyBmaXJzdC1zZXJ2ZWQgb3IgYnkgZ292ZXJubWVudCBhbGxvY2F0aW9uIChlLmcuLCBw dWJsaWMgc2VydmljZSkuDQoNCkxpZ2h0bHkgbGljZW5zZWQ6IFNwZWNpYWwgY2FzZSB3aGVyZSB0 aGVmcmVxdWVuY3kgYWxsb2NhdGlvbiBpcyBkb25lIHRocm91Z2ggZmlyc3QtY29tZSAvIGZpcnN0 LXNlcnZlZCBwcm9jZXNzIGZvciBhIGdpdmVuIHRpbWUgZnJhbWUgb3ZlciBhIHJlbGF0aXZlbHkg bGltaXRlZCBzZXJ2aWNlIGFyZWEuIFRoZSBhbm51YWwgbGljZW5zZSBmZWUgaXMgdXN1YWxseSBz bWFsbCB0byBmYWNpbGl0YXRlIHRoZSBkZXBsb3ltZW50IG9mIGEgc2VydmljZSB0aGF0IHdvdWxk IG5vdCBub3JtYWxseSBiZSBlY29ub21pY2FsbHkgYXR0cmFjdGl2ZS4gIFNtYWxsIGxvY2FsIG9w ZXJhdG9ycyB3b3VsZCBiZSBpbnRlcmVzdGVkIGJ5IHRoaXMgKGUuZy4sIHJ1cmFsIGJyb2FkYmFu ZCBpbiBDYW5hZGEpIGFuZCBub3QgYmlnIFRlbGNvcyB0aGF0IHdvdWxkIG5vcm1hbGx5IHdvcmsg d2l0aCBmdWxsIGxpY2Vuc2luZyB0aHJvdWdoIGF1Y3Rpb24gb3ZlciBsYXJnZSBzZXJ2aWNlIGFy ZWFzLg0KDQpMaWNlbnNlLWV4ZW1wdDogT3BlcmF0aW9uIG9mIFJGIGRldmljZXMgaW4gYSBmcmVx dWVuY3kgYmFuZCB3aGVyZSBubyBmb3JtYWwgbGljZW5zaW5nIHByb2Nlc3MgaXMgbmVlZGVkIHN1 Y2ggYXMgaW4gdGhlIDIuNCBHSHogSVNNIGJhbmQuIEluIHRoZSBVU0EsIHRoaXMgdGVybSBpcyB1 c2VkIGZvciBhIHNwZWNpZmljIHR5cGUgb2Ygb3BlcmF0aW9uLiBUaGUgRkNDIHNob3VsZCBiZSBj b250YWN0ZWQgdG8gY2xhcmlmeSBpdC4NCg0KVW5saWNlbnNlZDogSWxsZWdhbCBvcGVyYXRpb24g b2YgYW4gUkYgZGV2aWNlIHRoYXQgY2FuIHRyYW5zbWl0IGluIGEgZnJlcXVlbmN5IGJhbmQgd2l0 aG91dCBhIGR1bHkgaXNzdWVkIGxpY2Vuc2UuICBJbiB0aGUgVVNBLCB0aGlzIHRlcm0gaXMgdXNl ZCB0byBtZWFuIOKAnGxpY2Vuc2UtZXhlbXB0LCIgc2VlIGFib3ZlLg0KDQpUbyBteSBrbm93bGVk Z2UsIHRoZSB0ZXJtIOKAnHVubGljZW5zZWTigJ0gaXMgdXNlZCBvbmx5IGluIHRoZSBVU0EgdG8g ZGVzY3JpYmUgYSBsZWdhbCBvcGVyYXRpb24gYmVjYXVzZSB0aGUgdGVybSDigJxsaWNlbnNlLWV4 ZW1wdOKAnSBoYXMgYmVlbiB1c2VkIGZvciBhbm90aGVyIHNwZWNpZmljIHB1cnBvc2UuDQoNClNp bmNlIHRoZSBQQVdTIGFkZHJlc3NlcyB0aGUgaW50ZXJmYWNlIHRvIHRoZSBkYXRhYmFzZSBmb3Ig dGhlIGludGVybmF0aW9uYWwgbWFya2V0LCBpdCBzaG91bGQgcmVseSBvbiB0aGUgZGVmaW5pdGlv biBvZiB0aGUgdGVybXMgcmVjb2duaXplZCBieSB0aGUgSVRVLVIuIEkgd291bGQgc3VnZ2VzdCB0 aGUgdXNlIG9mIOKAmGxpY2Vuc2Vk4oCZIGFuZCDigJhsaWNlbnNlLWV4ZW1wdOKAmSB3aXRoIGEg Zm9vdG5vdGUgaW5kaWNhdGluZyB0aGF0IHRoZSB0ZXJtIOKAmHVubGljZW5zZWTigJkgaXMgdXNl ZCBpbiB0aGUgVVNBIGluc3RlYWQgb2YgdGhlIHVzdWFsIOKAmGxpY2Vuc2UtZXhlbXB04oCZLg0K DQpHZXJhbGQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QN CnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFp bHRvOnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Bhd3MNCg== --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DECC79008AM1MPN1006mg_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAw IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmlu aXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29B Y2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC55aXY5MTM2MjcxMTJtc29ub3JtYWwsIGxpLnlpdjkx MzYyNzExMm1zb25vcm1hbCwgZGl2LnlpdjkxMzYyNzExMm1zb25vcm1hbA0KCXttc28tc3R5bGUt bmFtZTp5aXY5MTM2MjcxMTJtc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCnAueWl2OTEzNjI3MTEybXNvY2hwZGVmYXVsdCwgbGkueWl2OTEzNjI3 MTEybXNvY2hwZGVmYXVsdCwgZGl2LnlpdjkxMzYyNzExMm1zb2NocGRlZmF1bHQNCgl7bXNvLXN0 eWxlLW5hbWU6eWl2OTEzNjI3MTEybXNvY2hwZGVmYXVsdDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC55aXY5MTM2MjcxMTJtc29ub3JtYWwxLCBsaS55aXY5 MTM2MjcxMTJtc29ub3JtYWwxLCBkaXYueWl2OTEzNjI3MTEybXNvbm9ybWFsMQ0KCXttc28tc3R5 bGUtbmFtZTp5aXY5MTM2MjcxMTJtc29ub3JtYWwxOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiIsInNlcmlmIjt9DQpwLnlpdjkxMzYyNzExMm1zb2NocGRlZmF1bHQxLCBsaS55aXY5 MTM2MjcxMTJtc29jaHBkZWZhdWx0MSwgZGl2LnlpdjkxMzYyNzExMm1zb2NocGRlZmF1bHQxDQoJ e21zby1zdHlsZS1uYW1lOnlpdjkxMzYyNzExMm1zb2NocGRlZmF1bHQxOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLnlpdjkxMzYyNzExMm1zb2h5cGVy bGluaw0KCXttc28tc3R5bGUtbmFtZTp5aXY5MTM2MjcxMTJtc29oeXBlcmxpbms7fQ0Kc3Bhbi55 aXY5MTM2MjcxMTJtc29oeXBlcmxpbmtmb2xsb3dlZA0KCXttc28tc3R5bGUtbmFtZTp5aXY5MTM2 MjcxMTJtc29oeXBlcmxpbmtmb2xsb3dlZDt9DQpzcGFuLnlpdjkxMzYyNzExMmVtYWlsc3R5bGUx OQ0KCXttc28tc3R5bGUtbmFtZTp5aXY5MTM2MjcxMTJlbWFpbHN0eWxlMTk7fQ0Kc3Bhbi55aXY5 MTM2MjcxMTJtc29oeXBlcmxpbmsxDQoJe21zby1zdHlsZS1uYW1lOnlpdjkxMzYyNzExMm1zb2h5 cGVybGluazE7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNw YW4ueWl2OTEzNjI3MTEybXNvaHlwZXJsaW5rZm9sbG93ZWQxDQoJe21zby1zdHlsZS1uYW1lOnlp djkxMzYyNzExMm1zb2h5cGVybGlua2ZvbGxvd2VkMTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLnlpdjkxMzYyNzExMmVtYWlsc3R5bGUxOTENCgl7 bXNvLXN0eWxlLW5hbWU6eWl2OTEzNjI3MTEyZW1haWxzdHlsZTE5MTsNCglmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4ueWl2OTEzNjI3MTEy YXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOnlpdjkxMzYyNzExMmFwcGxl LWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29u IFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NTMw ODYwNzQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjEx NTgwNDk1NzIgMTI3NDg0MjA4NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2 NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7 bXNvLWxldmVsLXN0YXJ0LWF0Ojg7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGli cmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBs aXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIHdvbmRlcmluZyB3aGVyZSB3ZSBhcmUgd2l0aCB0 aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIHRvcGljLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5HZXJhbGQgY2xhcmlmaWVk IGluIG9uZSBvZiB0aGUgcHJldmlvdXMgbWFpbHMgd2hhdCB0aGUgcXVhbGlmaWVycyDigJhsaWNl bnNlLWV4ZW1wdOKAmSBhbmQg4oCYdW5saWNlbnNlZOKAmSBtZWFuIHdoZW4gdGhleSBhcmUgYXR0 YWNoZWQgdG8gYSBmcmVxdWVuY3kgYmFuZCwgYW4gb3BlcmF0aW9uDQogb3IgYSBkZXZpY2UuIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TY2FubmluZyB0aHJvdWdoIHRoZSBkb2N1bWVu dCwgSSBmb3VuZCAyIGluc3RhbmNlcyBvZiB1bmxpY2Vuc2VkIG5vdCBhdHRhY2hlZCB0byBhbnl0 aGluZywgYW5kIG9uZSBpbnN0YW5jZSBvZiDigJhsaWNlbnNlLWV4ZW1wdOKAmSBzcGVjdHJ1bS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNpbmNlIElFVEYgaGlzdG9yaWNhbGx5IGhhcyBub3QgZGVhbHQgbXVjaCB3aXRo IG9wZXJhdGlvbiBpbiBjZXJ0YWluIGZyZXF1ZW5jeSBiYW5kcywgaXQgd291bGQgYmUgZ29vZCB0 byBkZWZpbmUgdGhlc2UgdGVybWlub2xvZ2llcyBhbmQgYWRqdXN0IHRoZSB0ZXh0IGluDQogdGhl IGRyYWZ0IGFjY29yZGluZ2x5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm93LCB0aGUgcXVlc3Rpb24gaXMgaWYgdGhl c2UgdGVybWlub2xvZ2llcyBjYW4gYmUgdXNlZCB0byBhbHNvIHF1YWxpZnkgYSBXUyBkZXZpY2Us IFdTIHNwZWN0cnVtIGFuZC9vciBXUyBvcGVyYXRpb24uIElmIG5vdCwgd2UgbWF5IG5lZWQgYWRk aXRpb25hbCBkZWZpbml0aW9ucw0KIGZvciB0aGVzZSwgSSB0aGluayB0aGlzIGlzIHdoYXQgUGF1 bCBzdWdnZXN0ZWQgZG93biBiZWxvdy4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdhYm9yPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHBhd3MtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+ZXh0IFBhdWwgTGFtYmVydDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51 YXJ5IDMxLCAyMDEyIDEwOjUxIEFNPGJyPg0KPGI+VG86PC9iPiBNLksuU2FqZWV2OyBSb3Nlbiwg QnJpYW47IHBhd3NAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXdzXSBEaXNj dXNzaW9uIG9uICdsaWNlbnNlLWV4ZW1wdCcgdnMgJ3VubGljZW5zZWQnPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5M aWdodGx5ICZuYnNwO2xpY2Vuc2VkIGFuZCBsaWNlbnNlIGV4ZW1wdCAob3IgdW5saWNlbnNlZCBp biBGQ0MgdmVybmFjdWxhcikgaGF2ZSBwcmlvciDigJMgdGhhdCB3YXMgd2h5IEkgd2FzIHByb3Bv c2luZyB0aGF0IHdlIHNob3VsZCBpbmNsdWRlIGEgZGVmaW5pdGlvbiBmb3IgdGhlDQogZ2VvbG9j YXRpb24gYmFzZWQgd2hpdGUgc3BhY2UgYWNjZXNzIHRoYXQgcGF3cyBpcyBzdXBwb3J0aW5nIGFz IGEgbmV3IGRlZmluaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QYXVsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdGN0Y3RiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM3RjdGN0YiPlBhdWwgQS4gTGFtYmVydCB8IE1hcnZlbGwg U2VtaWNvbmR1Y3RvciB8ICYjNDM7MS02NTAtNzg3LTkxNDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBNLksuU2FqZWV2DQo8YSBocmVmPSJtYWls dG86W21haWx0bzpta3NhamlAeWFob28uY29tXSI+W21haWx0bzpta3NhamlAeWFob28uY29tXTwv YT4gPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMzEsIDIwMTIgODoxMiBBTTxi cj4NCjxiPlRvOjwvYj4gUGF1bCBMYW1iZXJ0OyBSb3NlbiwgQnJpYW47IDxhIGhyZWY9Im1haWx0 bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3Bhd3NdIERpc2N1c3Npb24gb24gJ2xpY2Vuc2UtZXhlbXB0JyB2cyAndW5saWNlbnNlZCc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkEgYml0IGNvbmZ1c2VkIHNlZWluZyB0aGUgJ3VubGljZW5zZWQnIGJhbmQgZGlzY3Vzc2lvbiBo ZXJlLiBXaWxsIGEgd2hpdGUgc3BhY2UgZGF0YWJhc2UgYmUgbWFpbnRhaW5pbmcgZGV0YWlscyBv ZiBkZXZpY2VzL2NoYW5uZWwgYWxsb2NhdGlvbnMgb2YgdW5saWNlbnNlZCBiYW5kIG9wZXJhdGlv biBvZiBkZXZpY2VzPyAoaXMNCiBpdCByZWFsbHkgZmVhc2libGUsIGFzIHVubGljZW5zZWQgYmFu ZCBjYW4gYmUgdXNlZCBieSBhbnkgZGV2aWNlIHdpdGhvdXQgYW55IHNwZWNpZmljIGNoYW5uZWxz IGFsbG9jYXRpb24sIGV0Yy4uLi4pIE9yIHdpbGwgdGhlIGRhdGFiYXNlcyBsaW1pdCB0aGVpciBv cGVyYXRpb24gdG8ganVzdCB0aGUgJm5ic3A7bGljZW5zZWQvbGlnaHRseSBsaWNlbnNlZCBiYW5k IG9wZXJhdGlvbnM/IE9yIGlzIGl0IGp1c3QgdGhhdCB3ZSBhcmUgb25seSBkZWZpbmluZw0KIHRo ZXNlIHRlcm1zIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxpPjxzcGFuIHN0 eWxlPSJjb2xvcjojQzAwMDAwIj5CZXN0IFJlZ2FyZHMsPC9zcGFuPjwvaT48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5k OndoaXRlIj48aT48c3BhbiBzdHlsZT0iY29sb3I6I0MwMDAwMCI+U2FqZWV2IE1hbmlra290aDxi cj4NCk1vYmlsZTogJiM0Mzs5MTk2NjMzMTEzNzg8YnI+DQpFbWFpbDogPGEgaHJlZj0ibWFpbHRv Om1rc2FqaUBpZWVlLm9yZyI+bWtzYWppQGllZWUub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHA6 Ly93d3cubGlua2VkaW4uY29tL2luL21rc2FqZWV2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3 dy5saW5rZWRpbi5jb20vaW4vbWtzYWplZXY8L2E+PC9zcGFuPjwvaT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1h bGlnbjpjZW50ZXI7YmFja2dyb3VuZDp3aGl0ZSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIxIiB3aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+ DQo8L3NwYW4+PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBQYXVsIExhbWJl cnQgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXVsQG1hcnZlbGwuY29tIj5wYXVsQG1hcnZlbGwuY29t PC9hPiZndDs8YnI+DQo8Yj5Ubzo8L2I+ICZxdW90O1Jvc2VuLCBCcmlhbiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6Ij5Ccmlhbi5Sb3NlbkBuZXVzdGFy LmJpejwvYT4mZ3Q7OyAmcXVvdDs8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyI+cGF3c0Bp ZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIj5wYXdz QGlldGYub3JnPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCAzMSBKYW51YXJ5 IDIwMTIsIDQ6NDc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXdzXSBEaXNjdXNzaW9uIG9u ICdsaWNlbnNlLWV4ZW1wdCcgdnMgJ3VubGljZW5zZWQnPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5aXY5MTM2MjcxMTIiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiBVaCwgd2hpdGVzcGFjZSBkZXZpY2U/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5NYXliZSDigKYgYnV0IGlmIHdlIGFyZSB0YWxraW5nIGFib3V0 IHRoZSDigJxsaWNlbnNl4oCdIGl0IG1pZ2h0IGJlICZuYnNwO+KAnERhdGFiYXNlIExpY2Vuc2Vk 4oCdLCDigJxEYXRhYmFzZSBMaWNlbnNlLUV4ZW1wdOKAnSwgb3IgJm5ic3A74oCcV2hpdGUgU3Bh Y2UgTGljZW5zZWTigJ08L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWVt cyBsaWtlIHdlIGhhZCBzb21lIHJlYWxseSBleGNlbGxlbnQgZGVmaW5pdGlvbnMg4oCTIGJ1dCBo YXBwZW5lZCB0byBiZSBtaXNzaW5nIHRoZSBjYXRlZ29yeSB0aGF0IHdlIGFyZSB0cnlpbmcgdG8g c3VwcG9ydC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxVbmxpY2Vu c2Vk4oCdIGluIEZDQyB0ZXJtcyBhbHNvIGhhcyBhIGNvbm5vdGF0aW9uIG9mIG11bHRpcGxlIHVz ZXJzIGFuZCByb2J1c3RuZXNzLiZuYnNwOyBEZXZpY2VzIG9wZXJhdGluZyDigJx1bmxpY2Vuc2Vk 4oCdIGFyZSBub3QgY29uY2VybmVkDQogYWJvdXQgcG90ZW50aWFsIGludGVyZmVyZW5jZSB3aXRo IG90aGVyIHVubGljZW5zZWQgZGV2aWNlcy4mbmJzcDsgVGhlcmUgYXJlIHBvdGVudGlhbGx5IG11 bHRpcGxlIGFuZCB0aGV5IGdlbmVyYWxseSBuZWVkIHRvIHBsYXkgd2VsbCB0b2dldGhlci4mbmJz cDsgTGljZW5zZWQgZGV2aWNlcyBhcmUgdHlwaWNhbGx5IGEgc2luZ2xlIG93bmVyIHRvIGZhY2ls aXRhdGUgYSBsZXZlbCBvZiBzZXJ2aWNlIGJhc2VkIG9uIGEgbW9yZSBjb29yZGluYXRlZCBtb2Rl bC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWVtcyBsaWtlIGFsbCBk ZXZpY2VzIGFyZSBsaWNlbnNlZCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSB0aGF0IHRoZSBhaXItd2Fy ZXMgYXJlIGNvbnRyb2xsZWQgYW5kIGFsbG9jYXRlZC4mbmJzcDsgRXZlbiB1bmxpY2Vuc2VkIG9y IGxpY2Vuc2VkDQogZXhlbXB0IGFsbG9jYXRpb25zIGhhdmUgbGltaXRhdGlvbnMgYW5kIGRldmlj ZSBjb25mb3JtYW5jZSB0ZXN0aW5nLiZuYnNwOyBJdOKAmXMganVzdCB0aGF0IHRoZSBlbmQtdXNl ciBkb2VzIG5vdCBuZWVkIHRvIGV4cGxpY2l0bHkgZmlsZSBmb3IgYSBsaWNlbnNlIGluIHRoZXNl IGJhbmRzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGFuIGFyY2hp dGVjdHVyZSDigJMgYWxsIGRldmljZXMgaGF2ZSBhIGxpY2Vuc2UsIGFuZCB0aGF0IHNvbWUganVz dCBoYXBwZW4gdG8gaGF2ZSBwYWlkIG1vbmV5IG9yIGJlZW4gZ2l2ZW4gYSBtb25vcG9seSBieSBh biBhdXRob3JpdHkNCiB0byBoYXZlIGEgc2luZ2xlIHVzZXIgbGljZW5zZS4mbmJzcDsgU29tZSBv ZiB0aGUgbGljZW5zZXMgY2FuIGJlIHNob3J0IGxpdmVkIGFuZCBuZWVkIHRvIGJlIGRpc3RyaWJ1 dGVkLiZuYnNwOyBTb21lIGFyZSBpbXBsaWNpdCBiYXNlZCBvbiB0aGUgY29uZm9ybWFuY2UgdGVz dHMgdGhhdCB0aGUgZGV2aWNlIG11c3QgcGFzcy4mbmJzcDsgVGhlIGxpY2Vuc2VzIHRoYXQgcGF3 cyBpcyBhZGRyZXNzaW5nIGFyZSBvbmVzIHRoYXQgY2FuIGJlIG1vZGlmaWVkIGJ5IHNvbWUgZm9y bQ0KIG9mIElQIGNvbW11bmljYXRpb25zIChha2EgZGF0YWJhc2UgbG9va3VwKS48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyDigKYgYXMgYW4gYXR0ZW1wdCBmb3IgdGV4 dCDigKYuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hp dGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+V2hpdGVzcGFjZSBs aWNlbnNlZDo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJ5aXY5MTM2MjcxMTJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPk9wZXJhdGlv bg0KIG9mIFJGIGRldmljZXMgaW4gYSBmcmVxdWVuY3kgYmFuZCB3aGVyZSBhdXRob3JpemVkIG9w ZXJhdGlvbiBpcyBkZXRlcm1pbmVkIGJhc2VkIG9uIGEgZGV2aWNlcyBsb2NhdGlvbiwgZGV2aWNl IHR5cGUgYW5kIG9wZXJhdGluZyB0aW1lIHBlcmlvZC4mbmJzcDsgQ29vcmRpbmF0aW9uIG9mIHRo aXMgbW9kZSBvZiBvcGVyYXRpb24gd2lsbCB0eXBpY2FsbHkgYmUgbWFuYWdlZCBieSBkYXRhYmFz ZXMgdHJhY2tpbmcgTGljZW5zZWQgb3BlcmF0aW9uIGluIHRoZQ0KIHNhbWUgYmFuZHMuPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGF1bDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojN0Y3RjdGIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojN0Y3RjdGIj5QYXVsIEEuIExhbWJlcnQgfCBNYXJ2ZWxsIFNlbWljb25kdWN0 b3IgfCAmIzQzOzEtNjUwLTc4Ny05MTQxPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+IFJvc2VuLCBCcmlhbg0KPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86QnJp YW4uUm9zZW5AbmV1c3Rhci5iaXpdIj5bbWFpbHRvOkJyaWFuLlJvc2VuQG5ldXN0YXIuYml6XTwv YT4NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEphbnVhcnkgMzAsIDIwMTIgMjo0NiBQTTxi cj4NCjxiPlRvOjwvYj4gUGF1bCBMYW1iZXJ0PGJyPg0KPGI+Q2M6PC9iPiBOYW5jeSBCcmF2aW47 IE1hbHlhciwgSm9obiBQOyA8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyI+cGF3c0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtwYXdzXSBEaXNjdXNzaW9uIG9uICds aWNlbnNlLWV4ZW1wdCcgdnMgJ3VubGljZW5zZWQnPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPlVoLCB3aGl0ZXNwYWNlIGRldmljZT88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+U29ycnksIGNvdWxkbid0IHJlc2lzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5CcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+T24gSmFuIDMwLCAyMDEyLCBh dCA1OjQ0IFBNLCBQYXVsIExhbWJlcnQgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoYXQgaXMgdGhlIGNvcnJl Y3QgdGVybSBmb3Igc29tZXRoaW5nIHRoYXQgaXMgb3BlcmF0aW5nIGFzIGEgbGljZW5zZS1leGVt cHQgZGV2aWNlIOKAkyB5ZXQgaGFzIGJlZW4gZ2l2ZW4gc2hvcnQgdGVybSBhdXRob3JpemF0aW9u IHRvDQogc2hhcmUgYSBjaGFubmVsIHdpdGggb3RoZXIgbGljZW5zZS1leGVtcHQgZGV2aWNlcyBi YXNlZCBvbiBhIHF1ZXJ5IHRvIGEgcmVnaW9uYWwgYXV0aG9yaXRpZXMgZGF0YWJhc2UgaW4gYSBw b3J0aW9uIG9mIHNwZWN0cnVtIHRoYXQgbWF5IGFsc28gaW5jbHVkZSBsaWNlbnNlZCBvciBsaWdo dC1saWNlbnNlZCBkZXZpY2VzIGF0IG90aGVyIHRpbWVzIG9yIGluIG90aGVyIGFyZWFzLjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlBhdWw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzdGN0Y3RiI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xvcjppbml0aWFsIj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMy4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItY29sb3I6aW5pdGlhbCBpbml0aWFsIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9InlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86 cGF3cy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3cy1ib3VuY2VzQGlldGYu b3JnPC9hPjxzcGFuIGNsYXNzPSJ5aXY5MTM2MjcxMTJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86W21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmdd Ij5bbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ108L2E+PHNwYW4gY2xhc3M9InlpdjkxMzYy NzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uDQogQmVoYWxmIE9m PHNwYW4gY2xhc3M9InlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvYj5HZXJhbGQgQ2hvdWluYXJkPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9Inlp djkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1vbmRheSwgSmFu dWFyeSAzMCwgMjAxMiAzOjMwIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJ5aXY5MTM2 MjcxMTJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9InlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPltwYXdzXSBEaXNjdXNzaW9uIG9uICdsaWNlbnNlLWV4ZW1wdCcgdnMg J3VubGljZW5zZWQnPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj5BbGwsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5h dnkiPkhlcmUgaXMgbXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgdGVybXM6PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+TGljZW5zZWQ6PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0i eWl2OTEzNjI3MTEyYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOm5hdnkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpuYXZ5Ij5TcGVjdHJ1bQ0KIHRoYXQgaXMgYWNxdWlyZWQgYnkgYW4gb3BlcmF0 b3Igb3ZlciBhIGdpdmVuIHNlcnZpY2UgYXJlYSBmb3IgYSBnaXZlbiB0aW1lIHBlcmlvZC4gJm5i c3A7VGhpcyBpcyB1c3VhbGx5IGRvbmUgdGhyb3VnaCBhdWN0aW9ucyAodGhpbmsgb2YgdGhlIFRl bGNvcyksIGJlYXV0eSBjb250ZXN0LCBmaXJzdC1jb21lIC8gZmlyc3Qtc2VydmVkIG9yIGJ5IGdv dmVybm1lbnQgYWxsb2NhdGlvbiAoZS5nLiwgcHVibGljIHNlcnZpY2UpLjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnki PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPkxpZ2h0bHkgbGljZW5zZWQ6PC9zcGFuPjwvYj48c3Bh biBjbGFzcz0ieWl2OTEzNjI3MTEyYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5TcGVjaWFsDQogY2FzZSB3aGVyZSB0aGVmcmVxdWVu Y3kgYWxsb2NhdGlvbiBpcyBkb25lIHRocm91Z2ggZmlyc3QtY29tZSAvIGZpcnN0LXNlcnZlZCBw cm9jZXNzIGZvciBhIGdpdmVuIHRpbWUgZnJhbWUgb3ZlciBhIHJlbGF0aXZlbHkgbGltaXRlZCBz ZXJ2aWNlIGFyZWEuIFRoZSBhbm51YWwgbGljZW5zZSBmZWUgaXMgdXN1YWxseSBzbWFsbCB0byBm YWNpbGl0YXRlIHRoZSBkZXBsb3ltZW50IG9mIGEgc2VydmljZSB0aGF0IHdvdWxkIG5vdCBub3Jt YWxseSBiZQ0KIGVjb25vbWljYWxseSBhdHRyYWN0aXZlLiAmbmJzcDtTbWFsbCBsb2NhbCBvcGVy YXRvcnMgd291bGQgYmUgaW50ZXJlc3RlZCBieSB0aGlzIChlLmcuLCBydXJhbCBicm9hZGJhbmQg aW48c3BhbiBjbGFzcz0ieWl2OTEzNjI3MTEyYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+Q2FuYWRhKSBhbmQgbm90IGJpZyBUZWxjb3MgdGhhdCB3b3VsZCBub3JtYWxseSB3b3Jr IHdpdGggZnVsbCBsaWNlbnNpbmcgdGhyb3VnaCBhdWN0aW9uIG92ZXIgbGFyZ2UNCiBzZXJ2aWNl IGFyZWFzLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOm5hdnkiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPkxpY2Vuc2UtZXhl bXB0Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9InlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+T3BlcmF0aW9uDQog b2YgUkYgZGV2aWNlcyBpbiBhIGZyZXF1ZW5jeSBiYW5kIHdoZXJlIG5vIGZvcm1hbCBsaWNlbnNp bmcgcHJvY2VzcyBpcyBuZWVkZWQgc3VjaCBhcyBpbiB0aGUgMi40IEdIeiBJU00gYmFuZC4gSW4g dGhlPHNwYW4gY2xhc3M9InlpdjkxMzYyNzExMmFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPlVTQSwgdGhpcyB0ZXJtIGlzIHVzZWQgZm9yIGEgc3BlY2lmaWMgdHlwZSBvZiBvcGVy YXRpb24uIFRoZSBGQ0Mgc2hvdWxkIGJlIGNvbnRhY3RlZA0KIHRvIGNsYXJpZnkgaXQuPC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6bmF2eSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+VW5saWNlbnNlZDo8L3NwYW4+PC9iPjxz cGFuIGNsYXNzPSJ5aXY5MTM2MjcxMTJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6bmF2eSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPklsbGVnYWwNCiBvcGVyYXRpb24gb2YgYW4gUkYg ZGV2aWNlIHRoYXQgY2FuIHRyYW5zbWl0IGluIGEgZnJlcXVlbmN5IGJhbmQgd2l0aG91dCBhIGR1 bHkgaXNzdWVkIGxpY2Vuc2UuICZuYnNwO0luIHRoZTxzcGFuIGNsYXNzPSJ5aXY5MTM2MjcxMTJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5VU0EsIHRoaXMgdGVybSBpcyB1c2Vk IHRvIG1lYW4g4oCcbGljZW5zZS1leGVtcHQsJnF1b3Q7IHNlZSBhYm92ZS48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5 Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij5UbyBteSBrbm93bGVkZ2UsIHRoZSB0ZXJtIOKAnHVubGlj ZW5zZWTigJ0gaXMgdXNlZCBvbmx5IGluIHRoZTxzcGFuIGNsYXNzPSJ5aXY5MTM2MjcxMTJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5VU0E8c3BhbiBjbGFzcz0ieWl2OTEzNjI3 MTEyYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+dG8NCiBkZXNjcmliZSBhIGxl Z2FsIG9wZXJhdGlvbiBiZWNhdXNlIHRoZSB0ZXJtIOKAnGxpY2Vuc2UtZXhlbXB04oCdIGhhcyBi ZWVuIHVzZWQgZm9yIGFub3RoZXIgc3BlY2lmaWMgcHVycG9zZS48L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpuYXZ5Ij4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpuYXZ5Ij5TaW5jZSB0aGUgUEFXUyBhZGRyZXNzZXMgdGhlIGludGVyZmFjZSB0 byB0aGUgZGF0YWJhc2UgZm9yIHRoZSBpbnRlcm5hdGlvbmFsIG1hcmtldCwgaXQgc2hvdWxkIHJl bHkgb24gdGhlIGRlZmluaXRpb24gb2YgdGhlIHRlcm1zIHJlY29nbml6ZWQNCiBieSB0aGUgSVRV LVIuIEkgd291bGQgc3VnZ2VzdCB0aGUgdXNlIG9mIOKAmGxpY2Vuc2Vk4oCZIGFuZCDigJhsaWNl bnNlLWV4ZW1wdOKAmSB3aXRoIGEgZm9vdG5vdGUgaW5kaWNhdGluZyB0aGF0IHRoZSB0ZXJtIOKA mHVubGljZW5zZWTigJkgaXMgdXNlZCBpbiB0aGUgVVNBIGluc3RlYWQgb2YgdGhlIHVzdWFsIOKA mGxpY2Vuc2UtZXhlbXB04oCZLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOm5hdnkiPkdl cmFsZDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KcGF3cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cGF3c0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cGF3c0BpZXRmLm9yZzwv YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bh d3MiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3czwvYT48L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3 czwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DECC79008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Thu Feb 2 10:36:12 2012 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 5A7C621F85F8 for ; Thu, 2 Feb 2012 10:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.772 X-Spam-Level: X-Spam-Status: No, score=-0.772 tagged_above=-999 required=5 tests=[AWL=-0.587, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nsfs9aa1eQ35 for ; Thu, 2 Feb 2012 10:36:11 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 46C5221F85EF for ; Thu, 2 Feb 2012 10:36:11 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12Ia8c3016228; Thu, 2 Feb 2012 20:36:10 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 20:36:08 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.5]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 19:36:07 +0100 From: To: , , Thread-Topic: [paws] Threat model Thread-Index: AQHM3StRJwsi78gZm0WinGjlBlOxJpYgzoXQgARXlwCABNINMA== Date: Thu, 2 Feb 2012 18:36:06 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DECC94@008-AM1MPN1-006.mgdnok.nokia.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 18:36:08.0512 (UTC) FILETIME=[878B7C00:01CCE1D9] X-Nokia-AV: Clean Subject: Re: [paws] Threat model 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, 02 Feb 2012 18:36:12 -0000 The discussions on this mail thread have slowed down. Raj, can you implement the comments received on the list so far and post th= e text again for further input? - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pat= il Basavaraj (Nokia-CIC/Dallas) Sent: Monday, January 30, 2012 9:57 AM To: paul@marvell.com; paws@ietf.org Subject: Re: [paws] Threat model Hi Paul, Do you have any proposals or text w.r.t the threat model writeup? Also from= an IETF perspective regarding threat models, please see Peter's email: http://www.ietf.org/mail-archive/web/paws/current/msg00592.html -Raj On 1/27/12 5:24 PM, "ext Paul Lambert" wrote: >It's good to have requirements based on such an analysis. This is an=20 >interesting start, but we may be mixing threats, vulnerabilities and=20 >mechanisms. > >Threats are typically tied to an actor ... human or not. I'm not sure=20 >it's worth going hard over to something like the NIST 800-30=20 >definitions of threats, but within this framework the threats are=20 >Governments, disgruntled insiders, tsunamis etc. Being the IETF we can=20 >jump more quickly to the threat event and specifics of an attack, but=20 >should at least expand threats to include natural events and connectivity = problems. > Robustness or emergency modes might be interesting to consider. > >We also have a problem in this analysis of perspective - are we=20 >considering threats as viewed from regulatory agency or the end device=20 >owner or both. We should consider both - but they are contradictory=20 >perspectives. Users want continuity of service. Governments (the >regulators) want control of the airwaves. > >Most of the real threats that we have are nearly impossible to prevent=20 >at the protocol level. It's still worth examining the threats to see=20 >where we stand. > >On the current document threats: > >>o It is assumed that the master device or the white space database >> have NOT been compromised from a security standpoint. >> >>Threat 1: Obtain master device authentication/authorization secrets >> The master device needs to authenticate itself with the white >> space database prior to requesting channel information. The >> attacker may try to get access to the secrets of the master >> device which can be used maliciously. The effect of such an >> attack being successful would result in a malicious client >> replaying the stolen authentication/authorization secrets to a >> white space database. >This does not seem consistent with the prior statement of "not=20 >compromised". >Restatement > >Threat: User modifies a device to masquerade as another valid certified=20 >device. > >This is an interesting case where threat/vulnerability/risk play=20 >together. The FCC or other regulatory agencies want traceability of=20 >devices. If a user wants to run a rogue radio, there is no reason to=20 >access the database (low risk - no payoff). The only reason this would=20 >be an interesting attack might be to avoid tracking and have some=20 >anonymity. > >>Threat 2: Spoofed white space database >> A master device discovers a white space database(s) thru which >> it can query for channel information. The master device needs >> to ensure that the white space database with which it >> communicates with is an authentic entity. The white space >> database needs to provide its identity to the master device >> which can confirm the validity/authenticty of the database. An >> attacker may attempt to spoof a white space database and >> provide responses to a master device which are malicious and >> result in the master device causing interference to the primary >> user of the spectrum. > >I think this is two types of threat events: > - malicious denial of service or intentional interference with=20 >incumbents > - impersonation of white space database to enable operation of a=20 >device that may > not otherwise be possible (blocked device, unallocated channels). >This may or may not > interfere with incumbent devices > >>Threat 3: Modifying a query request >... > >>Threat 4: Modifying a query response >Seems like these two could be lumped together ...MiTM modifies protocol=20 >messages to: > - deny service > - interfere with incumbents > - provide unauthorized channel usage (most likely risk IMHO) > >>Threat 5: Using query response information >> An attacker may be a master device which is not certified for >> use by the relevant regulatory body. The attacker may listen to >> the communication between a valid master device and white space >> database and utilize the information about available channels >> in the response message by utilizing those channels. The result >> of such an attack is unauthorized use of channels by a master >> device which is not certified to operate. >As stated this is a mechanism - a clearer statement might be. > >Threat: Unauthorized use of channels by an uncertified device. > >Anyone can already go to a database and find available channels. If a=20 >device can operate without going to the database there is nothing that=20 >paws can do to stop it operating in available or non-available channels. > >Just to get some discussion going -here's a couple more possible threats.. > >Threat: Third party tracking of white space device location > Likely a valuable commodity to sell for advertizing with no=20 >technical design or policy for privacy >Threat: Database owner termination of device service for reasons other=20 >than incumbent protection > > > >Paul > > _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Thu Feb 2 11:02:31 2012 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 2ECA721F84F5 for ; Thu, 2 Feb 2012 11:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, J_BACKHAIR_22=1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6Ox8VfnjJEl for ; Thu, 2 Feb 2012 11:02:30 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id EA5F121F84F3 for ; Thu, 2 Feb 2012 11:02:29 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Feb 2012 19:02:29 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Thu, 2 Feb 2012 19:02:28 +0000 From: To: , Date: Thu, 2 Feb 2012 19:02:26 +0000 Thread-Topic: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) Thread-Index: AQHM4cbBM1LY84Ao6UaXhXGJCbWG9JYp8Mrg Message-ID: <619CDADDCCD2B44380834BE8BF6F714140654A1703@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) 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, 02 Feb 2012 19:02:31 -0000 Scott The Device Registration use case at 4.1.2 is shown as a pre-requisite, but = may not be required in all regulatory domains. I take your point though tha= t at present we only have firm requirements from the FCC. I guess that the left most device in the diagram in 4.1.2 should be labelle= d slave, not master. There is a conflict between the use case (elsewhere) that allows for WS bac= khaul, and step 1 of database discovery in 4.1.1. It is possible for a mast= er to send a service request to the database over the WS, if it does so as = a slave to another master on that master's allowed frequencies. We could co= rrect step 1 to reflect this as follows: 1. The master device is connected to the internet by any means other than = using the TV white space radio. An exception is wh= ere the master device also has slave capabilities and is already connected = to the internet as a slave of the white space radio network of another mast= er. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 02 February 2012 16:22 To: paws@ietf.org Subject: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device regi= stration with trusted database) Hello All, As editors of the problem statement, use cases & requirements draft we are = attempting to prepare a completed draft which could be ready for working gr= oup last call before IETF83. In the coming days we will post the sections o= f the draft to the mailing list. Our request is that you review these secti= ons and reply to the email with any comments. Below is the text for sections on protocol services (new section numbering)= . This text has been marked up from version-02 as uploaded January 26, 2012= to include the previous comments on the mail reflector about use cases vs.= protocol services, plus a few suggestions from the editor (removing 'TV' s= ince PAWS applies to all white space, correcting for the fact that we only = know at this time the FCC's specific requirements for registration). Our goal is that any discussion on this text will conclude by February 9. To be clear, approval of the document will go through the normal process of= last calls etc.. We are simply asking for your assistance in preparing a c= omplete & accurate document that could progress the work. So please review = the text and send your comments either directly to the editor or to the mai= ling list. Kind Regards, Raj & Scott 4.1 Protocol Services A complete protocol solution must provide all services that are essential t= o enable the white space paradigm. Before a white space device can request = service from a white space database, such as a query for a list of availabl= e channels, the white space device must first locate or "discover" a suitab= le database. Additionally, some regulatory authorities require the white sp= ace device to register with the database as a first step. This section desc= ribes the services required from the protocol. 4.1.1. TVWSWhite space database discover= y This use caseWhite space database discovery is preliminary to creating a radio network using TV white space; it is a prerequisite to otherthe use cases below= . The radio network is created by a master device. Before the master device can transmit in TV white space spectrum, it must contact a = trusted database where the device can learn if any channels are available for it to use. The master device will need to discover a trusted database in the relvant regulatory domain, using the following steps: 1. The master device is connected to the internet by any means other than using the TV white space radio. 2. The master device constructs and sends a service request over the Internet to discover availability of trusted databases in the local regulatory domain and waits for responses. 3. If no acceptable response is received within a pre-configured time limit, the master device concludes that no trusted database is available. If at least one response is received, the master device evaluates the response(s) to determine if a trusted database can be identified where the master device is able to register and receive service from the database. Optionally the radio device is pre-programmed with the internet address of at least one trusted database. The device can establish contact with a trusted database using one of the pre-programmed internet addresses and establish a TV white space netwo= rk (as described in one of the following use cases). Optionally the initial query will be made to a listing approved by the national regulator for the domain of operation (e.g. a website either hosted by or under control of the national regulator) which maintains a list of TVWS databases and their internet a= ddresses. The query results in the list of databases and their internet addresses being sent to the master, which then evaluates the repsonse to determine if a trusted database can be identified where the master device is able to register and receive service from the database. 4.1.2. Device registration with trusted Database This use caseRegistration is prelimina= ry to creating a radio network using TV white space; it is a prerequisite to otherthe use cases below= . The radio network is created by a master device. Before the master device can transmit in TV white space spectrum, it must contact a = trusted database where the device can learn if any channels are available for it to use. Before the database will provide information on available TVradio channels, the master device mu= st register with the trusted database. Specific requirements for registration come from individual regulatory domains and may be different. The figure below shows an example deployment of this scenario. \|/ ---------- | |Database| | .---. /--------- |-|---------| ( ) / \|/ | Master | / \ | / | |=3D=3D=3D=3D=3D=3D=3D=3D( Interne= t ) | / |-----------| \ / +-|----+ (TDD AirIF) ( ) |Master| / (----) | | / +------+ Figure 2: Example illustration of registration requirement in = TV white space use-case A simplified operational scenario showing registration consists of the following steps: 1. The master device must register with theits= most current and up-to- date information. Typically the master device will register prior to operating in TV white space for the first = time after power up, after changing location by a predetermined distance, and after regular time intervals. 2. The master device shall provide to the database during registration all information required according to local reg= ulatory requirements. This information may include, but is not limited to, = a minimum of the Device ID, serial number assigne= d by the manufacturer and the device's location, d= evice antenna height above ground, name of the individual or business that = owns the device, name of a contact person responsible for the device's oper= ation, address for the contact person, email address for the contact person and phone numbe= r of the contact person. 3. Depending upon regulatory domain requirements, the device may also provide device antenna height above ground, name of the individual or business that owns the device, name of a contact person responsible for the device's operation, address for the contact person, email address for the contact person and phone number of the contact person to the database during registration. _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Thu Feb 2 11:40:08 2012 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 DD10921F864C for ; Thu, 2 Feb 2012 11:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rgaQ1vNKWcB for ; Thu, 2 Feb 2012 11:40:05 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id E3EA521F85D4 for ; Thu, 2 Feb 2012 11:40:04 -0800 (PST) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 2 Feb 2012 19:40:03 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT63-UKRD.domain1.systemhost.net ([10.36.3.100]) with mapi; Thu, 2 Feb 2012 19:40:03 +0000 From: To: , Date: Thu, 2 Feb 2012 19:40:01 +0000 Thread-Topic: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: Aczh4m78mn7Obw4wRYWe29xpVWEwHA== Message-ID: <619CDADDCCD2B44380834BE8BF6F714140654A170F@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F714140654A170FEMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 02 Feb 2012 19:40:09 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140654A170FEMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott Section 3 only addresses the US, presumably due to lack of contributions fr= om elsewhere. I propose a couple of short paragraphs to cover the UK situat= ion. The wording is not mine but is almost entirely taken from the latest O= fcom Statement. Section 3.2 is copied below for reference, unchanged, and I propose a new s= ection 3.3, also below: 3.2. Background information on white space in US Television transmission in the United States has moved to the use of digital signals as of June 12, 2009. Since June 13, 2009, all fullpower U.S. television stations have broadcast over-the-air signals in digital only. An important benefit of the switch to all-digital broadcasting is that it freed up parts of the valuable broadcast spectrum. More information about the switch to digital transmission is at : [DTV]. Probasco & Patil Expires July 30, 2012 [Page 8] Internet-Draft PAWS: Problem, uses and requirements January 2012 With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. The FCC has made this spectrum available for unlicensed use and this is generally referred to as white space. Please see the details of the FCC ruling and regulations in [FCC Ruling]. The spectrum can be used to provide wireless broadband as an example. The term "Super-Wifi" is also used to describe this spectrum and potential for providing wifi type of service. 3.3. Background information on white space in UK Since its launch in 2005, Ofcom's Digital Dividend Review [DDR] has conside= red how to make the spectrum freed up by digital switchover available for n= ew uses, including the capacity available within the spectrum that is retai= ned to carry the digital terrestrial television service. Similarly to the U= S, this interleaved or guard spectrum occurs because not all the spectrum i= n any particular location will be used for terrestrial television and so is= available for other services, as long as they can interleave their usage a= round the existing users. In its September 2011 Statement [Ofcom Implementing] Ofcom says that a key = element in enabling white space usage in the TV bands is the definition and= provision of a database which, given a device's location, can tell the dev= ice which frequency channels and power levels it is able to use without cau= sing harmful interference to other licensed users in the vicinity. Ofcom wi= ll specify requirements to be met by such geolocation databases. It also sa= ys that the technology has the possibility of being usefully applied elsewh= ere in the radio spectrum to ensure it is used to maximum benefit. For exam= ple, it may have potential in making spectrum available for new uses follow= ing any switch to digital radio services. Alternatively it may be helpful i= n exploiting some of the public sector spectrum holdings. Ofcom will contin= ue to consider other areas of the radio spectrum where white space usage ma= y be of benefit. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 26 January 2012 23:43 To: paws@ietf.org Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi, Revision 2 of the PS, Use cases and requirements I-D has been posted. Pleas= e see: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-02.txt This version only includes changes requested by the co-chair in his email o= f January 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.htm= l Specifically: " 2. requirements. In the last f2f we agreed to modify requirement D.1 to include the suggestions from slide 7= -10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D= .6 and D.9 slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also con= tain suggestions on how to revise this requirement. Agreed to revise requirement D.2 as suggested in slide 11 of http://www.iet= f.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/pr= oceedings/82/slides/paws-1.pdf We seem to have agreed with the reformulation suggested to D.3 in slide 12 = ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agre= e on the format the location would be represented in. The data format part = is still open, but as this piece does not really belong to requirements but= rather the data model spec, we are not in a hurry to decide it. Delete d.4 D.5: augment with lower/upper frequencies and time of availability, as sugg= ested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/= proceedings/82/slides/paws-2.pdf. D.7: change to single and multiple locations. Clarify that in case of multi= ple locations the channel availability for each location should be sent by = the db. D.8: delete " And " Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/8= 2/slides/paws-2.pdf contain suggestions on rewording, I propose the editor = considers them. " Regards, Scott & Raj --_000_619CDADDCCD2B44380834BE8BF6F714140654A170FEMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott

 

Section 3 only addresses= the US, presumably due to lack of contributions from elsewhere. I propose = a couple of short paragraphs to cover the UK situation. The wording is not = mine but is almost entirely taken from the latest Ofcom Statement.

 

Section 3.2 = is copied below for reference, unchanged, and I propose a new section 3.3, = also below:

 

3.2. Background information on white space in US<= o:p>

Television transmission i= n the United States has moved to the use of

digital signals as of June 12, 2009. Since June 13, 20= 09, all fullpower

U.S. te= levision stations have broadcast over-the-air signals in<= /p>

digital only. An important benefit of the s= witch to all-digital

broa= dcasting is that it freed up parts of the valuable broadcast

spectrum. More information about the sw= itch to digital transmission

is at : [DTV].

Probas= co & Patil Expires July 30, 2012 [Page 8]

Internet-Draft PAWS: Problem, uses and requirements Ja= nuary 2012

With the switc= h to digital transmission for TV, the guard bands that

existed to protect the signals between statio= ns can now be used for

ot= her purposes. The FCC has made this spectrum available for

unlicensed use and this is generally refe= rred to as white space.

P= lease see the details of the FCC ruling and regulations in [FCC<= /span>

Ruling]. The spectrum can be used to= provide wireless broadband as

an example. The term "Super-Wifi" is also used to describe = this

spectrum and potential for providing wifi type of = service.

 

<Insert>

3.3.  Background inf= ormation on white space in UK

Since its lau= nch in 2005, Ofcom’s Digital Dividend Review [DDR] has considered how= to make the spectrum freed up by digital switchover available for new uses= , including the capacity available within the spectrum that is retained to = carry the digital terrestrial television service. Similarly to the US, this= interleaved or guard spectrum occurs because not all the spectrum in any p= articular location will be used for terrestrial television and so is availa= ble for other services, as long as they can interleave their usage around t= he existing users.

 

In its September 2011 Statement [Ofcom Implementing] Ofco= m says that a key element in enabling white space usage in the TV bands is = the definition and provision of a database which, given a device’s lo= cation, can tell the device which frequency channels and power levels it is= able to use without causing harmful interference to other licensed users i= n the vicinity. Ofcom will specify requirements to be met by such geolocati= on databases. It also says that the technology has the possibility of being= usefully applied elsewhere in the radio spectrum to ensure it is used to m= aximum benefit. For example, it may have potential in making spectrum avail= able for new uses following any switch to digital radio services. Alternati= vely it may be helpful in exploiting some of the public sector spectrum hol= dings. Ofcom will continue to consider other areas of the radio spectrum wh= ere white space usage may be of benefit.

&l= t;/Insert>

 

<= p class=3DMsoNormal>Regards

 <= /p>

Andy

 =

 

From: paws-bounces@ietf.org [mailto:paws-bounces= @ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: 26 = January 2012 23:43
To: paws@ietf.org
Subject: [paws] dr= aft-ietf-paws-problem-stmt-usecases-rqmts-02.txt

 

<= p class=3DMsoNormal>Hi,

 

Revision 2 of the PS, Use cases and requ= irements I-D has been posted. Please see:

=

 =

This version only includes changes = requested by the co-chair in his email of January 12 http://www.ietf.= org/mail-archive/web/paws/current/msg00516.html =

Specifically:

<= /div>

"

2. requirements. In the last f2f

=

we agreed to modify requirement D.1 to include the s= uggestions from slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf=  and merge with D.6 and D.9

slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf&n= bsp;also contain suggestions on how to revise this requirement.<= /span>

Agreed to revise requirement D.2 as sugges= ted in slide 11 of http://www.ietf.org/proceedings/82/slides/paws-2.pdfand s= lide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf

We seem to have agreed with the reformulatio= n suggested to D.3 in slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf= , but we did not agree on the format the location would be represented = in. The data format part is still open, but as this piece does not really b= elong to requirements but rather the data model spec, we are not in a hurry= to decide it.

Delete d.4<= /o:p>

D.5: augment with lower/upper freque= ncies and time of availability, as suggested on slide 10 ofhttp://www.ietf.org/procee= dings/82/slides/paws-1.pdf

= D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/proce= edings/82/slides/paws-2.pdf.

D.7: change to single and multiple locations. Clarify that in case of m= ultiple locations the channel availability for each location should be sent= by the db.

D.8: delete

"

&nb= sp;

And

"

Operational requirements: slides 22-24 = of ht= tp://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggest= ions on rewording, I propose the editor considers them.

"= ;

 

 

Regards,

= Scott &am= p; Raj

= --_000_619CDADDCCD2B44380834BE8BF6F714140654A170FEMV62UKRDdoma_-- From scott.probasco@nokia.com Thu Feb 2 12:17:44 2012 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 0D32D21F85A7 for ; Thu, 2 Feb 2012 12:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, J_BACKHAIR_22=1, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdjjwK5pYEiS for ; Thu, 2 Feb 2012 12:17:42 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 979E221F8596 for ; Thu, 2 Feb 2012 12:17:42 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12KHaJB019874 for ; Thu, 2 Feb 2012 22:17:38 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 22:17:36 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 21:17:35 +0100 From: To: Thread-Topic: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) Thread-Index: AQHM4cbBM1LY84Ao6UaXhXGJCbWG9JYp8Mrg//+lsgA= Date: Thu, 2 Feb 2012 20:17:34 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140654A1703@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4241214C4E92764FBE74ED33DF302322@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 20:17:36.0387 (UTC) FILETIME=[B4337D30:01CCE1E7] X-Nokia-AV: Clean Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) 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, 02 Feb 2012 20:17:44 -0000 Hi Andy, Thank you for reviewing, you have indeed discovered an inconsistency. I believe Figure 2 is accurate, this was meant to cover the ability of a Master device to initialize and register over TVWS, as anticipated by the FCC in 47 CFR Part 15 subpart H =A7 15.711 (e). As you point out, the text in step 1 clearly does not support this, and thus should be improved. As this applies to a Master device which is not already connected to the internet, I wonder if you would be okay with the following replacement text: "A local regulator may identify exception cases where a Master may initialize over white space (e.g. the FCC allows a Master to initialize over TV white space in certain conditions)." Kind Regards, Scott On 2/2/12 1:02 PM, "ext andy.sago@bt.com" wrote: >Scott > >The Device Registration use case at 4.1.2 is shown as a pre-requisite, >but may not be required in all regulatory domains. I take your point >though that at present we only have firm requirements from the FCC. > >I guess that the left most device in the diagram in 4.1.2 should be >labelled slave, not master. > >There is a conflict between the use case (elsewhere) that allows for WS >backhaul, and step 1 of database discovery in 4.1.1. It is possible for a >master to send a service request to the database over the WS, if it does >so as a slave to another master on that master's allowed frequencies. We >could correct step 1 to reflect this as follows: > >1. The master device is connected to the internet by any means other >than using the TV white space radio. An >exception is where the master device also has slave capabilities and is >already connected to the internet as a slave of the white space radio >network of another master. > >Regards > >Andy > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >scott.probasco@nokia.com >Sent: 02 February 2012 16:22 >To: paws@ietf.org >Subject: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device >registration with trusted database) > >Hello All, > >As editors of the problem statement, use cases & requirements draft we >are attempting to prepare a completed draft which could be ready for >working group last call before IETF83. In the coming days we will post >the sections of the draft to the mailing list. Our request is that you >review these sections and reply to the email with any comments. > >Below is the text for sections on protocol services (new section >numbering). This text has been marked up from version-02 as uploaded >January 26, 2012 to include the previous comments on the mail reflector >about use cases vs. protocol services, plus a few suggestions from the >editor (removing 'TV' since PAWS applies to all white space, correcting >for the fact that we only know at this time the FCC's specific >requirements for registration). > >Our goal is that any discussion on this text will conclude by February 9. >To be clear, approval of the document will go through the normal process >of last calls etc.. We are simply asking for your assistance in preparing >a complete & accurate document that could progress the work. So please >review the text and send your comments either directly to the editor or >to the mailing list. > >Kind Regards, >Raj & Scott > > > > > >4.1 Protocol Services > >A complete protocol solution must provide all services that are essential >to enable the white space paradigm. Before a white space device can >request service from a white space database, such as a query for a list >of available channels, the white space device must first locate or >"discover" a suitable database. Additionally, some regulatory authorities >require the white space device to register with the database as a first >step. This section describes the services required from the protocol. > > >4.1.1. TVWSWhite space database >discovery > >This use caseWhite space database >discovery is preliminary to creating a radio network using >TV > white space; it is a prerequisite to >otherthe use cases >below. The radio > network is created by a master device. Before the master device can > transmit in TV white space spectrum, it must contact >a trusted > database where the device can learn if any channels are available for > it to use. The master device will need to discover a trusted > database in the relvant regulatory domain, using the following steps: > > 1. The master device is connected to the internet by any means other > than using the TV white space radio. > > 2. The master device constructs and sends a service request over the > Internet to discover availability of trusted databases in the > local regulatory domain and waits for responses. > > 3. If no acceptable response is received within a pre-configured > time limit, the master device concludes that no trusted database > is available. If at least one response is received, the master > device evaluates the response(s) to determine if a trusted > database can be identified where the master device is able to > register and receive service from the database. > > Optionally the radio device is pre-programmed with the internet > address of at least one trusted database. The device can establish > contact with a trusted database using one of the pre-programmed > internet addresses and establish a TV white space >network (as > described in one of the following use cases). > > Optionally the initial query will be made to a listing approved by > the national regulator for the domain of operation (e.g. a website > either hosted by or under control of the national regulator) which > maintains a list of TVWS databases and their internet >addresses. The > query results in the list of databases and their internet addresses > being sent to the master, which then evaluates the repsonse to > determine if a trusted database can be identified where the master > device is able to register and receive service from the database. > > >4.1.2. Device registration with trusted Database > > This use caseRegistration is >preliminary to creating a radio network using TV > white space; it is a prerequisite to >otherthe use cases >below. The radio > network is created by a master device. Before the master device can > transmit in TV white space spectrum, it must contact >a trusted > database where the device can learn if any channels are available for > it to use. Before the database will provide information on available > TVradio channels, the master device >must register with the trusted > database. Specific requirements for registration come from > individual regulatory domains and may be different. > > The figure below shows an example deployment of this scenario. > > > > \|/ ---------- > | |Database| > | .---. /--------- > |-|---------| ( ) / > \|/ | Master | / \ > | / | |=3D=3D=3D=3D=3D=3D=3D=3D( Intern= et ) > | / |-----------| \ / > +-|----+ (TDD AirIF) ( ) > |Master| / (----) > | | / > +------+ > > Figure 2: Example illustration of registration requirement in >TV > white space use-case > > A simplified operational scenario showing registration consists of > the following steps: > > 1. The master device must register with >theits most current and up-to- > date information. Typically the master device will register > prior to operating in TV white space for the >first time after > power up, after changing location by a predetermined distance, > and after regular time intervals. > > 2. The master device shall provide to the database during > registration all information required according to local >regulatory requirements. This information may include, but is not limited >to, a minimum of the Device ID, serial number >assigned by the manufacturer and the device's >location, device antenna height above ground, name of the >individual or business that owns the device, name of a contact person >responsible for the device's operation, address for the > contact person, email address for the contact person and phone >number of the contact person. > > > 3. Depending upon regulatory domain requirements, the device may > also provide device antenna height above ground, name of the > individual or business that owns the device, name of a contact > person responsible for the device's operation, address for the > contact person, email address for the contact person and phone > number of the contact person to the database during registration. > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Thu Feb 2 12:26:36 2012 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 9B6F321F867C for ; Thu, 2 Feb 2012 12:26:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7V7IjPfNhEZs for ; Thu, 2 Feb 2012 12:26:35 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id DF69E21F867B for ; Thu, 2 Feb 2012 12:26:34 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12KQUh3028476; Thu, 2 Feb 2012 22:26:31 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 22:26:30 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 21:26:30 +0100 From: To: , Thread-Topic: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: Aczh4m78mn7Obw4wRYWe29xpVWEwHP//l6eA Date: Thu, 2 Feb 2012 20:26:28 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140654A170F@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: multipart/alternative; boundary="_000_CB504CF4FFB6scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 20:26:30.0712 (UTC) FILETIME=[F2AF0380:01CCE1E8] X-Nokia-AV: Clean Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 02 Feb 2012 20:26:36 -0000 --_000_CB504CF4FFB6scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Andy, Very good to cover the UK situation also. I support your proposal and plan = to include the new section in the next update, pending any further discussi= on on this thread. Kind Regards, Scott From: ext com > Date: Thu, 2 Feb 2012 19:40:01 +0000 To: Scott >, "paw= s@ietf.org" > Subject: RE: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Scott Section 3 only addresses the US, presumably due to lack of contributions fr= om elsewhere. I propose a couple of short paragraphs to cover the UK situat= ion. The wording is not mine but is almost entirely taken from the latest O= fcom Statement. Section 3.2 is copied below for reference, unchanged, and I propose a new s= ection 3.3, also below: 3.2. Background information on white space in US Television transmission in the United States has moved to the use of digital signals as of June 12, 2009. Since June 13, 2009, all fullpower U.S. television stations have broadcast over-the-air signals in digital only. An important benefit of the switch to all-digital broadcasting is that it freed up parts of the valuable broadcast spectrum. More information about the switch to digital transmission is at : [DTV]. Probasco & Patil Expires July 30, 2012 [Page 8] Internet-Draft PAWS: Problem, uses and requirements January 2012 With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. The FCC has made this spectrum available for unlicensed use and this is generally referred to as white space. Please see the details of the FCC ruling and regulations in [FCC Ruling]. The spectrum can be used to provide wireless broadband as an example. The term "Super-Wifi" is also used to describe this spectrum and potential for providing wifi type of service. 3.3. Background information on white space in UK Since its launch in 2005, Ofcom=92s Digital Dividend Review [DDR] has consi= dered how to make the spectrum freed up by digital switchover available for= new uses, including the capacity available within the spectrum that is ret= ained to carry the digital terrestrial television service. Similarly to the= US, this interleaved or guard spectrum occurs because not all the spectrum= in any particular location will be used for terrestrial television and so = is available for other services, as long as they can interleave their usage= around the existing users. In its September 2011 Statement [Ofcom Implementing] Ofcom says that a key = element in enabling white space usage in the TV bands is the definition and= provision of a database which, given a device=92s location, can tell the d= evice which frequency channels and power levels it is able to use without c= ausing harmful interference to other licensed users in the vicinity. Ofcom = will specify requirements to be met by such geolocation databases. It also = says that the technology has the possibility of being usefully applied else= where in the radio spectrum to ensure it is used to maximum benefit. For ex= ample, it may have potential in making spectrum available for new uses foll= owing any switch to digital radio services. Alternatively it may be helpful= in exploiting some of the public sector spectrum holdings. Ofcom will cont= inue to consider other areas of the radio spectrum where white space usage = may be of benefit. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: 26 January 2012 23:43 To: paws@ietf.org Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi, Revision 2 of the PS, Use cases and requirements I-D has been posted. Pleas= e see: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-02.txt This version only includes changes requested by the co-chair in his email o= f January 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.htm= l Specifically: " 2. requirements. In the last f2f we agreed to modify requirement D.1 to include the suggestions from slide 7= -10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D= .6 and D.9 slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also con= tain suggestions on how to revise this requirement. Agreed to revise requirement D.2 as suggested in slide 11 of http://www.iet= f.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/pr= oceedings/82/slides/paws-1.pdf We seem to have agreed with the reformulation suggested to D.3 in slide 12 = ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agre= e on the format the location would be represented in. The data format part = is still open, but as this piece does not really belong to requirements but= rather the data model spec, we are not in a hurry to decide it. Delete d.4 D.5: augment with lower/upper frequencies and time of availability, as sugg= ested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/= proceedings/82/slides/paws-2.pdf. D.7: change to single and multiple locations. Clarify that in case of multi= ple locations the channel availability for each location should be sent by = the db. D.8: delete " And " Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/8= 2/slides/paws-2.pdf contain suggestions on rewording, I propose the editor = considers them. " Regards, Scott & Raj --_000_CB504CF4FFB6scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <88F0EC3A680BD94B8E0B9CE7D23107DB@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi Andy,

Very good to cover the UK situation also. I support your proposal and = plan to include the new section in the next update, pending any further dis= cussion on this thread.

Kind Regards,
Scott

From: ext com <andy.sago@bt.com>
Date: Thu, 2 Feb 2012 19:40:01 += ;0000
To: Scott <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: draft-ietf-paws-proble= m-stmt-usecases-rqmts-02.txt

Scott

 

Section 3 only addresses the US, presumably due to = lack of contributions from elsewhere. I propose a couple of short paragraph= s to cover the UK situation. The wording is not mine but is almost entirely taken from the latest Ofcom Statement.<= o:p>

 

Section 3.2 is copied below for reference, unchange= d, and I propose a new section 3.3, also below:

 

3.2. Background information on white space i= n US

Television transmission in the United States= has moved to the use of

digital signals as of June 12, 2009. Since J= une 13, 2009, all fullpower

U.S. television stations have broadcast over= -the-air signals in

digital only. An important benefit of the sw= itch to all-digital

broadcasting is that it freed up parts of th= e valuable broadcast

spectrum. More information about the switch = to digital transmission

is at : [DTV].

Probasco & Patil Expires July 30, 2012 [= Page 8]

Internet-Draft PAWS: Problem, uses and requi= rements January 2012

With the switch to digital transmission for = TV, the guard bands that

existed to protect the signals between stati= ons can now be used for

other purposes. The FCC has made this spectr= um available for

unlicensed use and this is generally referre= d to as white space.

Please see the details of the FCC ruling and= regulations in [FCC

Ruling]. The spectrum can be used to provide= wireless broadband as

an example. The term "Super-Wifi" = is also used to describe this

spectrum and potential for providing wifi type of service.

 

<Insert>

3.3.  Background information on white space in= UK

Since its launch in 2005, Ofcom=92s Digital Dividen= d Review [DDR] has considered how to make the spectrum freed up by digital = switchover available for new uses, including the capacity available within the spectrum that is retained to carry the d= igital terrestrial television service. Similarly to the US, this interleave= d or guard spectrum occurs because not all the spectrum in any particular l= ocation will be used for terrestrial television and so is available for other services, as long as they can int= erleave their usage around the existing users.

 

In its September 2011 Statement [Ofcom Implementing= ] Ofcom says that a key element in enabling white space usage in the TV ban= ds is the definition and provision of a database which, given a device=92s location, can tell the device which f= requency channels and power levels it is able to use without causing harmfu= l interference to other licensed users in the vicinity. Ofcom will specify = requirements to be met by such geolocation databases. It also says that the technology has the possibility of being u= sefully applied elsewhere in the radio spectrum to ensure it is used to max= imum benefit. For example, it may have potential in making spectrum availab= le for new uses following any switch to digital radio services. Alternatively it may be helpful in exploiting s= ome of the public sector spectrum holdings. Ofcom will continue to consider= other areas of the radio spectrum where white space usage may be of benefi= t.

</Insert>

 

Regards

 

Andy

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.proba= sco@nokia.com
Sent: 26 January 2012 23:43
To: paws@ietf.org
Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt

 

Hi,

 

Revision 2 of the PS, Use cases and requirements I-D has been= posted. Please see:

 

This version only includes changes requested by the co-chair = in his email of January 12 http://www.ietf.org/mail-archive/web/paws/= current/msg00516.html 

Specifically:

"

2. requirements. In the last f2f

we agreed to modify requirement D.1 to include the suggestion= s from slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D.6 and D.9

slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1= .pdf also contain suggestions on how to revise this requirement.

Agreed to revise requirement D.2 as suggested in slide 11 of&= nbsp;http:= //www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf<= /span>

We seem to have agreed with the reformulation suggested to D.= 3 in slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented in. T= he data format part is still open, but as this piece does not really belong= to requirements but rather the data model spec, we are not in a hurry to d= ecide it.

Delete d.4

D.5: augment with lower/upper frequencies and time of availab= ility, as suggested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pd= f

D.6: change power to eirp, as suggested in slide 13 of <= a href=3D"http://www.ietf.org/proceedings/82/slides/paws-2.pdf">http://www.= ietf.org/proceedings/82/slides/paws-2.pdf.

D.7: change to single and multiple locations. Clarify that in= case of multiple locations the channel availability for each location shou= ld be sent by the db.

D.8: delete

"

 

And

"

Operational requirements: slides 22-24 of http://www.ietf.org/proc= eedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers them.

"

 

 

Regards,

Scott & Raj

 --_000_CB504CF4FFB6scottprobasconokiacom_-- From Basavaraj.Patil@nokia.com Thu Feb 2 12:30:30 2012 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 E57FD21F86B5 for ; Thu, 2 Feb 2012 12:30:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOYsTejVi1eg for ; Thu, 2 Feb 2012 12:30:30 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBCB21F85FF for ; Thu, 2 Feb 2012 12:30:29 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12KUSY7031492; Thu, 2 Feb 2012 22:30:28 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 22:30:28 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 21:30:27 +0100 From: To: , Thread-Topic: [paws] Threat model Thread-Index: AQHM3Uuw2q+mv4TAuUKOAAuKydmQAZYpoycA Date: Thu, 2 Feb 2012 20:30:26 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [72.64.95.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <1723328C7E205A4DB290788E25BF083E@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 20:30:28.0093 (UTC) FILETIME=[802C7AD0:01CCE1E9] X-Nokia-AV: Clean Subject: Re: [paws] Threat model 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, 02 Feb 2012 20:30:31 -0000 Hi Paul,=20 Comment inline: On 1/27/12 5:24 PM, "ext Paul Lambert" wrote: >It's good to have requirements based on such an analysis. This is an >interesting start, but we may be mixing threats, vulnerabilities and >mechanisms. > >Threats are typically tied to an actor ... human or not. I'm not sure >it's worth going hard over to something like the NIST 800-30 definitions >of threats, but within this framework the threats are Governments, >disgruntled insiders, tsunamis etc. Being the IETF we can jump more >quickly to the threat event and specifics of an attack, but should at >least expand threats to include natural events and connectivity problems. > Robustness or emergency modes might be interesting to consider. > >We also have a problem in this analysis of perspective - are we >considering threats as viewed from regulatory agency or the end device >owner or both. We should consider both - but they are contradictory >perspectives. Users want continuity of service. Governments (the >regulators) want control of the airwaves. Raj> The context and scope of this threat analysis is limited to the protocol and communication between a master device and the white space database. What you are proposing above is a much broader scope in terms of the white space technology itself. We need to limit our scope to the protocol aspect here and that is what the proposed threat analysis is intended to do. > >Most of the real threats that we have are nearly impossible to prevent at >the protocol level. It's still worth examining the threats to see where >we stand. =20 > >On the current document threats: > >>o It is assumed that the master device or the white space database >> have NOT been compromised from a security standpoint. >> >>Threat 1: Obtain master device authentication/authorization secrets >> The master device needs to authenticate itself with the white >> space database prior to requesting channel information. The >> attacker may try to get access to the secrets of the master >> device which can be used maliciously. The effect of such an >> attack being successful would result in a malicious client >> replaying the stolen authentication/authorization secrets to a >> white space database. >This does not seem consistent with the prior statement of "not >compromised". >Restatement > >Threat: User modifies a device to masquerade as another valid certified >device. Raj> Okay.=20 > >This is an interesting case where threat/vulnerability/risk play >together. The FCC or other regulatory agencies want traceability of >devices. If a user wants to run a rogue radio, there is no reason to >access the database (low risk - no payoff). The only reason this would >be an interesting attack might be to avoid tracking and have some >anonymity. > >>Threat 2: Spoofed white space database >> A master device discovers a white space database(s) thru which >> it can query for channel information. The master device needs >> to ensure that the white space database with which it >> communicates with is an authentic entity. The white space >> database needs to provide its identity to the master device >> which can confirm the validity/authenticty of the database. An >> attacker may attempt to spoof a white space database and >> provide responses to a master device which are malicious and >> result in the master device causing interference to the primary >> user of the spectrum. > >I think this is two types of threat events: > - malicious denial of service or intentional interference with incumbents > - impersonation of white space database to enable operation of a device >that may=20 > not otherwise be possible (blocked device, unallocated channels). >This may or may not > interfere with incumbent devices Raj> Okay. Will add the additional consequences text. > >>Threat 3: Modifying a query request >... > >>Threat 4: Modifying a query response >Seems like these two could be lumped together ...MiTM modifies protocol >messages to: > - deny service > - interfere with incumbents > - provide unauthorized channel usage (most likely risk IMHO) Raj> Will keep them separate for now and see if there is a significant overlap. > >>Threat 5: Using query response information >> An attacker may be a master device which is not certified for >> use by the relevant regulatory body. The attacker may listen to >> the communication between a valid master device and white space >> database and utilize the information about available channels >> in the response message by utilizing those channels. The result >> of such an attack is unauthorized use of channels by a master >> device which is not certified to operate. >As stated this is a mechanism - a clearer statement might be. > >Threat: Unauthorized use of channels by an uncertified device. Raj> Okay. > >Anyone can already go to a database and find available channels. If a >device can operate without going to the database there is nothing that >paws can do to stop it operating in available or non-available channels. Raj> Sure. But regulation requires a certain behavior. Anything outside that expected behavior is illegal and PAWS cannot do anything about that. > >Just to get some discussion going -here's a couple more possible threats.. > >Threat: Third party tracking of white space device location > Likely a valuable commodity to sell for advertizing with no technical >design or policy for privacy >Threat: Database owner termination of device service for reasons other >than incumbent protection Raj> Okay. Will add these to the next rev. Please review and provide additional text when I post the revised threat analysis shortly. Thanks for your comments. Appreciate your help in improving the text. -Raj > > > >Paul > > From Basavaraj.Patil@nokia.com Thu Feb 2 12:37:12 2012 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 0547D21F86A6 for ; Thu, 2 Feb 2012 12:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.742 X-Spam-Level: X-Spam-Status: No, score=-102.742 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2O8FUe6LloWz for ; Thu, 2 Feb 2012 12:37:11 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3795321F869C for ; Thu, 2 Feb 2012 12:37:11 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12Kb866021054; Thu, 2 Feb 2012 22:37:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 22:37:08 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 21:37:07 +0100 From: To: , Thread-Topic: Threat model (Rev 2) Thread-Index: AQHM4epuqv36MRvsf0SahgFpeCsR0g== Date: Thu, 2 Feb 2012 20:37:07 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567642D48@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [72.64.95.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <24779A61818A6447A97C1407896FDDE8@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 20:37:08.0532 (UTC) FILETIME=[6EDA9F40:01CCE1EA] X-Nokia-AV: Clean Subject: [paws] Threat model (Rev 2) 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, 02 Feb 2012 20:37:12 -0000 Based on comments received from Paul and others I have updated the threat analysis text. Please review and comment. -Raj Rev 2 (2/2/12) Threat model for the PAWS protocol ---------------------------------- Assumptions: ............ o It is assumed that an attacker has full access to the network medium between the master device and the white space database. The attacker may be able to eavesdrop on any communications between these entities. The link between the master device and the white space database can be wired or wireless and provides IP connectivity. o It is assumed that the master device or the white space database have NOT been compromised from a security standpoint. Threat 1: User modifies a device to masquerade as another valid certified device The master device needs to authenticate itself with the white space database prior to requesting channel information. The attacker may try to get access to the secrets of the master device which can be used maliciously. The effect of such an attack being successful would result in a malicious client replaying the stolen authentication/authorization secrets to a white space database. Threat 2: Spoofed white space database A master device discovers a white space database(s) thru which it can query for channel information. The master device needs to ensure that the white space database with which it communicates with is an authentic entity. The white space database needs to provide its identity to the master device which can confirm the validity/authenticty of the database. An attacker may attempt to spoof a white space database and provide responses to a master device which are malicious and result in the master device causing interference to the primary user of the spectrum. Threat 3: Modifying a query request An attacker may modify the query request sent by a master device to a white space database. The attacker may change the location of the device or the capabilities in terms of its transmit power or antenna height etc. which could result in the database responding with incorrect information about available channels or max transmit power allowed. The result of such an attack is that the master device would cause intereference to the primary user of the spectrum. It could also result in a denial of service to the master device by indicating that no channels are available. Threat 4: Modifying a query response An attacker could modify the query response sent by the white space database to a master device. The channel information or transmit power allowed type of parameters carried in the response could be modified by the attacker resulting in the master device using channels that are not available at a location or transmitting at a greater power level than allowed resulting in interference to the primary user of that spectrum. Alternatively the attacker may indicate no channel availability at a location resulting in a denial of service to the master device. Threat 5: Unauthorized use of channels by an uncertified device An attacker may be a master device which is not certified for use by the relevant regulatory body. The attacker may listen to the communication between a valid master device and white space database and utilize the information about available channels in the response message by utilizing those channels. The result of such an attack is unauthorized use of channels by a master device which is not certified to operate. The master device querying the white space database may be operated by a law-enforcement agency and the communications between the device and the database are intended to be kept private. A malicious device should not be able to eavesdrop on such communications. Threat 6: Third party tracking of white space device location =20 A master device needs to provide its location to the white space database in order to obtain the channel availability information at that location. Such location information can be gleaned by an eavesdropper. A master device may prefer to keep the location information secret. Hence the protocol should provide a means to protect the location information and prevent tracking of locations associated with a white space database. Threat 7: Database owner termination of device service for reasons other than incumbent protection A white space database may include a mechanism by which service and channels allocated to a master device can be revoked. A malicious node can send a revoke messages to a master device. This results in denial of service to the master device.=20 From stephen.farrell@cs.tcd.ie Thu Feb 2 12:48:53 2012 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 F11FC21F85BE for ; Thu, 2 Feb 2012 12:48:53 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOZzGm4CAu2T for ; Thu, 2 Feb 2012 12:48:53 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 4574221F85AF for ; Thu, 2 Feb 2012 12:48:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A8A79171C3A; Thu, 2 Feb 2012 20:48:52 +0000 (GMT) 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=1328215732; bh=LioioKD1AvbyeV L1b+So0M1o8NoohU3ws3hPhJtPqL8=; b=29MNmafnQmiEJrV2U1GVdc+d79zLEW 6LBTZWI9nTwtWnAHgTOEXFHK7rFsV6XghNtL1AMHkepD7vcs+yPeZpB9rl7j3vMB GnfT+AoCJql09GCjzg2RzHqcaTWndViSjcQ0FHmEmdT77a8DPeIEk231oSj4NDST VVekyXeS3MCrJzgdp3MNPYl4wpCGl8HnDI2Xhtw9pwAkls8OWCWxPn4vV3sRINuo 179RtnxDhQVU+FLkZKl7Dyk0JWsZ75/z+7uTu+fIeBykLBHXf9Ewv1NbVHr3o691 XVdDhU0Vo4z2Nd76WKepsrEwXA9vQXSsjDrTDQr8nt8oXwwAZn2GqeIQ== 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 PBbnXICrd4J4; Thu, 2 Feb 2012 20:48:52 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.45.53.99]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id B4CAB171C27; Thu, 2 Feb 2012 20:48:51 +0000 (GMT) Message-ID: <4F2AF6A8.6000106@cs.tcd.ie> Date: Thu, 02 Feb 2012 20:48:40 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 2) 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, 02 Feb 2012 20:48:54 -0000 Pretty good overall. I'll keep on my usual track since I seem stuck on it here;-) On 02/02/2012 08:37 PM, Basavaraj.Patil@nokia.com wrote: > > Threat 6: Third party tracking of white space device location > > > A master device needs to provide its location to the white > space database in order to obtain the channel availability > information at that location. Such location information can be > gleaned by an eavesdropper. A master device may prefer to keep > the location information secret. Hence the protocol should > provide a means to protect the location information and prevent > tracking of locations associated with a white space database. What's wrong with not wanting the DB to track me (as a master device)? Could be that current known regulators don't like anonymous masters, but that may change. (So I think 3rd party here is wrong.) Why is it only location tracking that's of concern? Why is exposing identity not an equal deal? Same logic as above. S. From Basavaraj.Patil@nokia.com Thu Feb 2 12:53:32 2012 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 6742221F8601 for ; Thu, 2 Feb 2012 12:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.724 X-Spam-Level: X-Spam-Status: No, score=-102.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGDoYDGIGlqS for ; Thu, 2 Feb 2012 12:53:32 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9A33D21F85EF for ; Thu, 2 Feb 2012 12:53:31 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12KrR16014407; Thu, 2 Feb 2012 22:53:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 22:53:27 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 21:53:26 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 2) Thread-Index: AQHM4epuqv36MRvsf0SahgFpeCsR0pYqA30A//+c2gA= Date: Thu, 2 Feb 2012 20:53:26 +0000 Message-ID: In-Reply-To: <4F2AF6A8.6000106@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [72.64.95.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F5F5A3E99524C4AA095D836411916C0@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 20:53:27.0219 (UTC) FILETIME=[B6326830:01CCE1EC] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 2) 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, 02 Feb 2012 20:53:32 -0000 On 2/2/12 2:48 PM, "ext Stephen Farrell" wrote: > >Pretty good overall. I'll keep on my usual track since I seem >stuck on it here;-) > >On 02/02/2012 08:37 PM, Basavaraj.Patil@nokia.com wrote: >> >> Threat 6: Third party tracking of white space device location >> >> >> A master device needs to provide its location to the white >> space database in order to obtain the channel availability >> information at that location. Such location information can be >> gleaned by an eavesdropper. A master device may prefer to keep >> the location information secret. Hence the protocol should >> provide a means to protect the location information and prevent >> tracking of locations associated with a white space database. > >What's wrong with not wanting the DB to track me (as a master >device)? Could be that current known regulators don't like >anonymous masters, but that may change. (So I think 3rd party >here is wrong.) The issue is not with the database tracking your location. It is a a malicious node which could be eavesdropping on the link between the master device and the database. The database will always have the master device's location. Whether it saves that location is an orthogonal issue, but its not the one that is captured in this threat. > >Why is it only location tracking that's of concern? Why is >exposing identity not an equal deal? Same logic as above. The concern is not about exposing location of identity to the white space database. -Raj > > >S. > From nbravin@earthlink.net Thu Feb 2 12:57:19 2012 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 6CA9821F847F for ; Thu, 2 Feb 2012 12:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WigfXDK0get for ; Thu, 2 Feb 2012 12:57:19 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id EE57021F845E for ; Thu, 2 Feb 2012 12:57:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=W/m0tW6SZfvYaP/TxvHDU4FcXll5mgnAfjWV2RBh4KE5Nwj6KcrPBgtAW3+cgs7N; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Rt3iV-0007zk-Su; Thu, 02 Feb 2012 15:57:15 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nancy Bravin In-Reply-To: <4F2AF6A8.6000106@cs.tcd.ie> Date: Thu, 2 Feb 2012 12:57:14 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <4F2AF6A8.6000106@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86e92acc1b10c5250c03f05bf66eaae939350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 2) 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, 02 Feb 2012 20:57:19 -0000 Guys, I think given the Global community that will be using this Protocol, On Feb 2, 2012, at 12:48 PM, Stephen Farrell wrote: > > Pretty good overall. I'll keep on my usual track since I seem > stuck on it here;-) > > On 02/02/2012 08:37 PM, Basavaraj.Patil@nokia.com wrote: >> >> Threat 6: Third party tracking of white space device location >> >> >> A master device needs to provide its location to the white >> space database in order to obtain the channel availability >> information at that location. Such location information can be >> gleaned by an eavesdropper. A master device may prefer to keep >> the location information secret. Hence the protocol should >> provide a means to protect the location information and prevent >> tracking of locations associated with a white space database. > > What's wrong with not wanting the DB to track me (as a master > device)? Could be that current known regulators don't like > anonymous masters, but that may change. (So I think 3rd party > here is wrong.) > > Why is it only location tracking that's of concern? Why is > exposing identity not an equal deal? Same logic as above. > > > S. > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From nbravin@earthlink.net Thu Feb 2 12:59:39 2012 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 18E5321F8655 for ; Thu, 2 Feb 2012 12:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UITzxJXM4u8d for ; Thu, 2 Feb 2012 12:59:38 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id 83AE821F8653 for ; Thu, 2 Feb 2012 12:59:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=MbiFftf/IO2tT9oVFV/ScuOu7Zrp762LxHdAgYVME10WeKt8QMt22JfJWGoHiIEJ; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Rt3km-0004WO-O5; Thu, 02 Feb 2012 15:59:36 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: Date: Thu, 2 Feb 2012 12:59:35 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4E2C9D45-519B-4574-B3BD-62A8E9AEAEB4@earthlink.net> References: <4F2AF6A8.6000106@cs.tcd.ie> To: Nancy Bravin X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86596a44ad23ef752927ddcbb24cc7b39a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 2) 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, 02 Feb 2012 20:59:39 -0000 oops sorry I was about to say what Raj just said=85ditto. Nancy On Feb 2, 2012, at 12:57 PM, Nancy Bravin wrote: > Guys,=20 >=20 > I think given the Global community that will be using this Protocol,=20= >=20 > On Feb 2, 2012, at 12:48 PM, Stephen Farrell wrote: >=20 >>=20 >> Pretty good overall. I'll keep on my usual track since I seem >> stuck on it here;-) >>=20 >> On 02/02/2012 08:37 PM, Basavaraj.Patil@nokia.com wrote: >>>=20 >>> Threat 6: Third party tracking of white space device location >>>=20 >>>=20 >>> A master device needs to provide its location to the white >>> space database in order to obtain the channel availability >>> information at that location. Such location information can be >>> gleaned by an eavesdropper. A master device may prefer to keep >>> the location information secret. Hence the protocol should >>> provide a means to protect the location information and = prevent >>> tracking of locations associated with a white space database. >>=20 >> What's wrong with not wanting the DB to track me (as a master >> device)? Could be that current known regulators don't like >> anonymous masters, but that may change. (So I think 3rd party >> here is wrong.) >>=20 >> Why is it only location tracking that's of concern? Why is >> exposing identity not an equal deal? Same logic as above. >>=20 >>=20 >> S. >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 From scott.probasco@nokia.com Thu Feb 2 13:19:28 2012 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 4FD2721F8523 for ; Thu, 2 Feb 2012 13:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uTGPbF0wYtg8 for ; Thu, 2 Feb 2012 13:19:26 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1E21F851E for ; Thu, 2 Feb 2012 13:19:26 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12LJIeE026138; Thu, 2 Feb 2012 23:19:19 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 23:19:17 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 22:19:16 +0100 From: To: , , , , Thread-Topic: [paws] Discussion on 'license-exempt' vs 'unlicensed' Thread-Index: AczfoOYkBqIvPtzVQA6ucq3r2yBLaf//+A4AgAEbk4CAACxgAP/81wcggAYSbYA= Date: Thu, 2 Feb 2012 21:19:15 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DECC79@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: multipart/alternative; boundary="_000_CB5054A4FFDAscottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 21:19:17.0875 (UTC) FILETIME=[5275BC30:01CCE1F0] X-Nokia-AV: Clean Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' 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, 02 Feb 2012 21:19:28 -0000 --_000_CB5054A4FFDAscottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, According to my unofficial tracking, the latest progress is recorded here http://www.ietf.org/mail-archive/web/paws/current/msg00644.html where the proposal is to update the terms White Space and White Space devi= ce, a suggestion to align the Introduction with Andy's proposed corrections= to the Abstract http://www.ietf.org/mail-archive/web/paws/current/msg00576.html Assuming no further comments on the reflector, I plan to implement the abov= e for version-03. Kind Regards, Scott From: Gabor Bajko > Date: Thu, 2 Feb 2012 18:25:19 +0000 To: >, >, >,= "paws@ietf.org" = > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' I am wondering where we are with the discussion on this topic. Gerald clarified in one of the previous mails what the qualifiers =91licens= e-exempt=92 and =91unlicensed=92 mean when they are attached to a frequency= band, an operation or a device. Scanning through the document, I found 2 instances of unlicensed not attach= ed to anything, and one instance of =91license-exempt=92 spectrum. Since IETF historically has not dealt much with operation in certain freque= ncy bands, it would be good to define these terminologies and adjust the te= xt in the draft accordingly. Now, the question is if these terminologies can be used to also qualify a W= S device, WS spectrum and/or WS operation. If not, we may need additional d= efinitions for these, I think this is what Paul suggested down below. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Paul Lambert Sent: Tuesday, January 31, 2012 10:51 AM To: M.K.Sajeev; Rosen, Brian; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Lightly licensed and license exempt (or unlicensed in FCC vernacular) have= prior =96 that was why I was proposing that we should include a definition= for the geolocation based white space access that paws is supporting as a = new definition. Paul Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 From: M.K.Sajeev [mailto:mksaji@yahoo.com] Sent: Tuesday, January 31, 2012 8:12 AM To: Paul Lambert; Rosen, Brian; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Hi, A bit confused seeing the 'unlicensed' band discussion here. Will a white s= pace database be maintaining details of devices/channel allocations of unli= censed band operation of devices? (is it really feasible, as unlicensed ban= d can be used by any device without any specific channels allocation, etc..= ..) Or will the databases limit their operation to just the licensed/light= ly licensed band operations? Or is it just that we are only defining these = terms here. Best Regards, Sajeev Manikkoth Mobile: +919663311378 Email: mksaji@ieee.org http://www.linkedin.com/in/mksajeev ________________________________ From: Paul Lambert > To: "Rosen, Brian" = >; "paws@ietf.org" > Sent: Tuesday, 31 January 2012, 4:47 Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > Uh, whitespace device? :) Maybe =85 but if we are talking about the =93license=94 it might be =93Dat= abase Licensed=94, =93Database License-Exempt=94, or =93White Space Licens= ed=94 Seems like we had some really excellent definitions =96 but happened to be = missing the category that we are trying to support. =93Unlicensed=94 in FCC terms also has a connotation of multiple users and = robustness. Devices operating =93unlicensed=94 are not concerned about pot= ential interference with other unlicensed devices. There are potentially m= ultiple and they generally need to play well together. Licensed devices ar= e typically a single owner to facilitate a level of service based on a more= coordinated model. Seems like all devices are licensed from the perspective that the air-wares= are controlled and allocated. Even unlicensed or licensed exempt allocati= ons have limitations and device conformance testing. It=92s just that the = end-user does not need to explicitly file for a license in these bands. As an architecture =96 all devices have a license, and that some just happe= n to have paid money or been given a monopoly by an authority to have a sin= gle user license. Some of the licenses can be short lived and need to be d= istributed. Some are implicit based on the conformance tests that the devi= ce must pass. The licenses that paws is addressing are ones that can be mo= dified by some form of IP communications (aka database lookup). So =85 as an attempt for text =85. Whitespace licensed: Operation of RF devices in a frequency band where auth= orized operation is determined based on a devices location, device type and= operating time period. Coordination of this mode of operation will typica= lly be managed by databases tracking Licensed operation in the same bands. Paul Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Monday, January 30, 2012 2:46 PM To: Paul Lambert Cc: Nancy Bravin; Malyar, John P; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Uh, whitespace device? Sorry, couldn't resist. Brian On Jan 30, 2012, at 5:44 PM, Paul Lambert wrote: What is the correct term for something that is operating as a license-exemp= t device =96 yet has been given short term authorization to share a channel= with other license-exempt devices based on a query to a regional authoriti= es database in a portion of spectrum that may also include licensed or ligh= t-licensed devices at other times or in other areas. Paul From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Gerald Ch= ouinard Sent: Monday, January 30, 2012 3:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ 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 --_000_CB5054A4FFDAscottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0A7C5FF9C9F12442B14527C978C561B2@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi,

According to my unofficial tracking, the latest progress is recorded h= ere
http://www.ietf.org/mail-archive/web/paws/current/msg00644.html
where the proposal is to update the terms  White Space and White = Space device, a suggestion to align the Introduction with Andy's proposed c= orrections to the Abstract
http://www.ietf.org/mail-archive/web/paws/current/msg00576.html
 
Assuming no further comments on the reflector, I plan to implement the= above for version-03.

Kind Regards,
Scott

From: Gabor Bajko <Gabor.Bajko@nokia.com>
Date: Thu, 2 Feb 2012 18:25:19 += ;0000
To: <paul@marvell.com>, <m= ksaji@ieee.org>, <Bria= n.Rosen@neustar.biz>, "paws@ie= tf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on '= license-exempt' vs 'unlicensed'

I am wondering where we are with t= he discussion on this topic.

 

Gerald clarified in one of the pre= vious mails what the qualifiers =91license-exempt=92 and =91unlicensed=92 m= ean when they are attached to a frequency band, an operation or a device.

Scanning through the document, I f= ound 2 instances of unlicensed not attached to anything, and one instance o= f =91license-exempt=92 spectrum.

 

Since IETF historically has not de= alt much with operation in certain frequency bands, it would be good to def= ine these terminologies and adjust the text in the draft accordingly.

 

Now, the question is if these term= inologies can be used to also qualify a WS device, WS spectrum and/or WS op= eration. If not, we may need additional definitions for these, I think this is what Paul suggested down below.

 

-    &nb= sp;     Gabor

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Paul Lambert
Sent: Tuesday, January 31, 2012 10:51 AM
To: M.K.Sajeev; Rosen, Brian; paws@= ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

 

Lightly  licensed and license= exempt (or unlicensed in FCC vernacular) have prior =96 that was why I was= proposing that we should include a definition for the geolocation based white space access that paws is supporting as a = new definition.

 

Paul

 

 

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

 

From: M.K.Sajeev [mailto:mksaji@yahoo.com] =
Sent: Tuesday, January 31, 2012 8:12 AM
To: Paul Lambert; Rosen, Brian; paw= s@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Hi,

 

A bit confused seeing the 'unlicensed' band discussion here. Will a whit= e space database be maintaining details of devices/channel allocations of u= nlicensed band operation of devices? (is it really feasible, as unlicensed band can be used by any device without a= ny specific channels allocation, etc....) Or will the databases limit their= operation to just the  licensed/lightly licensed band operations? Or = is it just that we are only defining these terms here.

 

Best Regards,

 

<= span style=3D"color:#C00000">Sajeev Manikkoth
Mobile: +919663311378
Email: mksaji@ieee.org
http://ww= w.linkedin.com/in/mksajeev<= /o:p>

From:<= span style=3D"font-size: 10pt; color: black; font-family: Arial, sans-serif= ; "> Paul Lambert <paul@marvell.com<= /a>>
To: "Rosen, Brian" <Brian.Rosen@neustar.biz>; "paws@ietf.org" <paws@ietf= .org>
Sent: Tuesday, 31 January 2012, 4:47
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

> Uh, whitespace device?

J 

Maybe =85= but if we are talking about the =93license=94 it might be  =93Databas= e Licensed=94, =93Database License-Exempt=94, or  =93White Space Licensed=94

 

Seems lik= e we had some really excellent definitions =96 but happened to be missing t= he category that we are trying to support.

 

=93Unlice= nsed=94 in FCC terms also has a connotation of multiple users and robustnes= s.  Devices operating =93unlicensed=94 are not concerned about potential interference with other unlicensed devices. = ; There are potentially multiple and they generally need to play well toget= her.  Licensed devices are typically a single owner to facilitate a le= vel of service based on a more coordinated model.

 

Seems lik= e all devices are licensed from the perspective that the air-wares are cont= rolled and allocated.  Even unlicensed or licensed exempt allocations have limitations and device conformance tes= ting.  It=92s just that the end-user does not need to explicitly file = for a license in these bands.=

 

As an arc= hitecture =96 all devices have a license, and that some just happen to have= paid money or been given a monopoly by an authority to have a single user license.  Some of the licenses can= be short lived and need to be distributed.  Some are implicit based o= n the conformance tests that the device must pass.  The licenses that = paws is addressing are ones that can be modified by some form of IP communications (aka database lookup).

 

So =85 as= an attempt for text =85.

 

Whitespace license= d: <= /span>Operation of RF devices in a frequency band where authorized operation is determined= based on a devices location, device type and operating time period.  = Coordination of this mode of operation will typically be managed by databas= es tracking Licensed operation in the same bands.

 

 

Paul

 <= /span>

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

 

From:<= span style=3D"font-size: 10pt; color: black; font-family: Arial, sans-serif= ; "> Rosen, Brian [mailto:Brian.Rosen@neu= star.biz]
Sent: Monday, January 30, 2012 2:46 PM
To: Paul Lambert
Cc: Nancy Bravin; Malyar, John P; p= aws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Uh, whitespace device?

 

Sorry, couldn't resist.

 

Brian

 

On Jan 30, 2012, at 5:44 PM, Paul Lambert wrote:

 

 

What is t= he correct term for something that is operating as a license-exempt device = =96 yet has been given short term authorization to share a channel with other license-exempt devices based on a query to a= regional authorities database in a portion of spectrum that may also inclu= de licensed or light-licensed devices at other times or in other areas.

 

 

Paul

 

 <= /span>

 

From:<= span class=3D"yiv913627112apple-converted-space"> <= span style=3D"font-size: 10pt; color: black; font-family: Arial, sans-serif= ; ">paws-bounces= @ietf.org [mailto:paws-bounces@iet= f.org] On Behalf Of Gerald Chouinard
Sent: = Monday, January 30, 2012 3:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

All,

 

Here is my understand= ing of the terms:

 

Licensed: Spectrum that is acquired by an operator over a given service area for a given time= period.  This is usually done through auctions (think of the Telcos),= beauty contest, first-come / first-served or by government allocation (e.g= ., public service).

 

Lightly licensed:<= /span> Special case where thefrequency allocation is done through first-come / first-serv= ed process for a given time frame over a relatively limited service area. T= he annual license fee is usually small to facilitate the deployment of a se= rvice that would not normally be economically attractive.  Small local operators would be interested b= y this (e.g., rural broadband in Canada) and not big Telcos that would normally work wit= h full licensing through auction over large service areas.

 

License-exempt: = Operation of RF devices in a frequency band where no formal licensing process is nee= ded such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type o= f operation. The FCC should be contacted to clarify it.

 

Unlicensed:=  Illegal operation of an RF device that can transmit in a frequency band without a = duly issued license.  In the USA, this term is used to mean =93license-exempt,"= ; see above.

 

To my knowledge, the = term =93unlicensed=94 is used only in the USA to describe a legal operation because the term =93license-exempt=94 has been = used for another specific purpose.<= /o:p>

 

Since the PAWS addres= ses the interface to the database for the international market, it should r= ely on the definition of the terms recognized by the ITU-R. I would suggest the use of =91licensed=92 and =91license-exe= mpt=92 with a footnote indicating that the term =91unlicensed=92 is used in= the USA instead of the usual =91license-exempt=92.

 

Gerald

__________________= _____________________________
paws mailing list
paws@ietf.org
ht= tps://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
ht= tps://www.ietf.org/mailman/listinfo/paws

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB5054A4FFDAscottprobasconokiacom_-- From nbravin@earthlink.net Thu Feb 2 13:25:40 2012 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 BE28D21F85A2 for ; Thu, 2 Feb 2012 13:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=-0.567, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t2JnhpvAM-2 for ; Thu, 2 Feb 2012 13:25:39 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id A1BEF21F8585 for ; Thu, 2 Feb 2012 13:25:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TC6dz3v09ElTE0JOiUdSXJlpUXO9IGgWCDEY1vpSOveOMfqvWcarFaMBG7cqzZo3; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1Rt49c-00011Y-1n; Thu, 02 Feb 2012 16:25:17 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-7--129120265 From: Nancy Bravin In-Reply-To: Date: Thu, 2 Feb 2012 13:25:14 -0800 Message-Id: References: To: X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad862b29bb6c0321eb03e684210f51ebb46a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' 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, 02 Feb 2012 21:25:40 -0000 --Apple-Mail-7--129120265 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear All, I am fine with this version, and happy to see so much = interaction that made it possible to come to this consensus. Thanks, = Sincerely, Nancy On Feb 2, 2012, at 1:19 PM, wrote: > Hi, >=20 > According to my unofficial tracking, the latest progress is recorded = here > http://www.ietf.org/mail-archive/web/paws/current/msg00644.html > where the proposal is to update the terms White Space and White Space = device, a suggestion to align the Introduction with Andy's proposed = corrections to the Abstract > http://www.ietf.org/mail-archive/web/paws/current/msg00576.html > =20 > Assuming no further comments on the reflector, I plan to implement the = above for version-03. >=20 > Kind Regards, > Scott >=20 > From: Gabor Bajko > Date: Thu, 2 Feb 2012 18:25:19 +0000 > To: , , , = "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' >=20 >=20 > I am wondering where we are with the discussion on this topic. > =20 > Gerald clarified in one of the previous mails what the qualifiers = =91license-exempt=92 and =91unlicensed=92 mean when they are attached to = a frequency band, an operation or a device. > Scanning through the document, I found 2 instances of unlicensed not = attached to anything, and one instance of =91license-exempt=92 spectrum. > =20 > Since IETF historically has not dealt much with operation in certain = frequency bands, it would be good to define these terminologies and = adjust the text in the draft accordingly. > =20 > Now, the question is if these terminologies can be used to also = qualify a WS device, WS spectrum and/or WS operation. If not, we may = need additional definitions for these, I think this is what Paul = suggested down below. > =20 > - Gabor > =20 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Paul Lambert > Sent: Tuesday, January 31, 2012 10:51 AM > To: M.K.Sajeev; Rosen, Brian; paws@ietf.org > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > =20 > Lightly licensed and license exempt (or unlicensed in FCC vernacular) = have prior =96 that was why I was proposing that we should include a = definition for the geolocation based white space access that paws is = supporting as a new definition. > =20 > Paul > =20 > =20 > Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > =20 > From: M.K.Sajeev [mailto:mksaji@yahoo.com]=20 > Sent: Tuesday, January 31, 2012 8:12 AM > To: Paul Lambert; Rosen, Brian; paws@ietf.org > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Hi, > =20 > A bit confused seeing the 'unlicensed' band discussion here. Will a = white space database be maintaining details of devices/channel = allocations of unlicensed band operation of devices? (is it really = feasible, as unlicensed band can be used by any device without any = specific channels allocation, etc....) Or will the databases limit their = operation to just the licensed/lightly licensed band operations? Or is = it just that we are only defining these terms here. > =20 > Best Regards, > =20 > Sajeev Manikkoth > Mobile: +919663311378 > Email: mksaji@ieee.org > http://www.linkedin.com/in/mksajeev >=20 > From: Paul Lambert > To: "Rosen, Brian" ; "paws@ietf.org" = =20 > Sent: Tuesday, 31 January 2012, 4:47 > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > > Uh, whitespace device? > J=20 > Maybe =85 but if we are talking about the =93license=94 it might be = =93Database Licensed=94, =93Database License-Exempt=94, or =93White = Space Licensed=94 > =20 > Seems like we had some really excellent definitions =96 but happened = to be missing the category that we are trying to support. > =20 > =93Unlicensed=94 in FCC terms also has a connotation of multiple users = and robustness. Devices operating =93unlicensed=94 are not concerned = about potential interference with other unlicensed devices. There are = potentially multiple and they generally need to play well together. = Licensed devices are typically a single owner to facilitate a level of = service based on a more coordinated model. > =20 > Seems like all devices are licensed from the perspective that the = air-wares are controlled and allocated. Even unlicensed or licensed = exempt allocations have limitations and device conformance testing. = It=92s just that the end-user does not need to explicitly file for a = license in these bands. > =20 > As an architecture =96 all devices have a license, and that some just = happen to have paid money or been given a monopoly by an authority to = have a single user license. Some of the licenses can be short lived and = need to be distributed. Some are implicit based on the conformance = tests that the device must pass. The licenses that paws is addressing = are ones that can be modified by some form of IP communications (aka = database lookup). > =20 > So =85 as an attempt for text =85. > =20 > Whitespace licensed: Operation of RF devices in a frequency band where = authorized operation is determined based on a devices location, device = type and operating time period. Coordination of this mode of operation = will typically be managed by databases tracking Licensed operation in = the same bands. > =20 > =20 > Paul > =20 > Paul A. Lambert | Marvell Semiconductor | +1-650-787-9141 > =20 > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] > Sent: Monday, January 30, 2012 2:46 PM > To: Paul Lambert > Cc: Nancy Bravin; Malyar, John P; paws@ietf.org > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Uh, whitespace device? > =20 > Sorry, couldn't resist. > =20 > Brian > =20 > On Jan 30, 2012, at 5:44 PM, Paul Lambert wrote: > =20 >=20 > =20 > What is the correct term for something that is operating as a = license-exempt device =96 yet has been given short term authorization to = share a channel with other license-exempt devices based on a query to a = regional authorities database in a portion of spectrum that may also = include licensed or light-licensed devices at other times or in other = areas. > =20 > =20 > Paul > =20 > =20 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of Gerald Chouinard > Sent: Monday, January 30, 2012 3:30 PM > To: paws@ietf.org > Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > All, > =20 > Here is my understanding of the terms: > =20 > Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). > =20 > Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos that would = normally work with full licensing through auction over large service = areas. > =20 > License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. > =20 > Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. > =20 > To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. > =20 > Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I would suggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. > =20 > Gerald > _______________________________________________ > 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 >=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 --Apple-Mail-7--129120265 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = All, I am fine with this version, and happy to see so much interaction = that made it possible to come to this consensus. Thanks, Sincerely, = Nancy

On Feb 2, 2012, at 1:19 PM, <scott.probasco@nokia.com> = wrote:

Hi,

According to my unofficial tracking, the latest progress is = recorded here
where the proposal is to update the terms  White Space and = White Space device, a suggestion to align the Introduction with Andy's = proposed corrections to the Abstract
 
Assuming no further comments on the reflector, I plan to implement = the above for version-03.

Kind Regards,
Scott

From: Gabor Bajko <Gabor.Bajko@nokia.com>
Date: Thu, 2 Feb 2012 18:25:19 = +0000
To: <paul@marvell.com>, <mksaji@ieee.org>, <Brian.Rosen@neustar.biz>, = "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion = on 'license-exempt' vs 'unlicensed'

I am wondering where we are with the discussion on this = topic.
Gerald clarified in one of the previous mails what the = qualifiers =91license-exempt=92 and =91unlicensed=92 mean when they are = attached to a frequency band, an operation or a device.
Scanning through the document, = I found 2 instances of unlicensed not attached to anything, and one = instance of =91license-exempt=92 spectrum.
Since IETF historically has not dealt much with operation = in certain frequency bands, it would be good to define these = terminologies and adjust the text in the draft accordingly.
Now, the question is if these terminologies can be used to = also qualify a WS device, WS spectrum and/or WS operation. If not, we = may need additional definitions for these, I think this is what Paul suggested down below. =
-           
 
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Paul Lambert
Sent: Tuesday, January 31, 2012 10:51 AM
To: M.K.Sajeev; Rosen, Brian; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
Lightly  licensed and license exempt (or unlicensed = in FCC vernacular) have prior =96 that was why I was proposing that we = should include a definition for the geolocation based white space access that paws is supporting as = a new definition.
 
Paul
 
Paul A. Lambert | Marvell Semiconductor | = +1-650-787-9141
From: M.K.Sajeev [mailto:mksaji@yahoo.com]=
Sent: Tuesday, January 31, 2012 8:12 AM
To: Paul Lambert; Rosen, Brian; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 

Hi,

 

A bit confused seeing the 'unlicensed' band = discussion here. Will a white space database be maintaining details of = devices/channel allocations of unlicensed band operation of devices? (is it really feasible, as unlicensed band can be used by any device = without any specific channels allocation, etc....) Or will the databases = limit their operation to just the  licensed/lightly licensed band = operations? Or is it just that we are only defining these terms here.

 

Best Regards,

 

Sajeev Manikkoth
Mobile: +919663311378
Email: mksaji@ieee.org
http://www.linkedin.com/in/mksajeev

Paul Lambert <paul@marvell.com>
To: "Rosen, Brian" <Brian.Rosen@neustar.biz>; = "paws@ietf.org" <paws@ietf.org>
Sent: Tuesday, 31 January 2012, 4:47
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

> Uh, whitespace = device?

J 

Maybe =85 but if we are talking about the =93license=94 it = might be  =93Database Licensed=94, =93Database License-Exempt=94, = or  =93White Space Licensed=94

 

Seems like we had some really excellent definitions =96 = but happened to be missing the category that we are trying to = support.

 

=93Unlicensed=94 in FCC terms also has a connotation of = multiple users and robustness.  Devices operating =93unlicensed=94 = are not concerned about potential interference with other unlicensed = devices.  There are potentially multiple and they generally need to = play well together.  Licensed devices are typically a single owner = to facilitate a level of service based on a more coordinated model.

 

Seems like all devices are licensed from the perspective = that the air-wares are controlled and allocated.  Even unlicensed or licensed exempt allocations have limitations and device conformance = testing.  It=92s just that the end-user does not need to explicitly = file for a license in these bands.

 

As an architecture =96 all devices have a license, and = that some just happen to have paid money or been given a monopoly by an authority to have a single user license.  Some of the licenses = can be short lived and need to be distributed.  Some are implicit = based on the conformance tests that the device must pass.  The = licenses that paws is addressing are ones that can be modified by some form of IP communications (aka database lookup).

 

So =85 as an attempt for text =85.

 

Operation of RF devices in a frequency band where authorized operation is = determined based on a devices location, device type and operating time = period.  Coordination of this mode of operation will typically be = managed by databases tracking Licensed operation in the same bands.

 

 

Paul

 

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

 

Rosen, Brian [mailto:Brian.Rosen@neust= ar.biz]
Sent: Monday, January 30, 2012 2:46 PM
To: Paul Lambert
Cc: Nancy Bravin; Malyar, John P; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Uh, whitespace device?

 

Sorry, couldn't resist.

 

Brian

 

On Jan 30, 2012, at 5:44 PM, Paul Lambert = wrote:

 

 

What is the correct term for something that is operating = as a license-exempt device =96 yet has been given short term = authorization to share a channel with other license-exempt devices based on a query = to a regional authorities database in a portion of spectrum that may = also include licensed or light-licensed devices at other times or in = other areas.

 

 

Paul

 

 

 

paws-bounces@ietf.org [mailto:paws-bounces@ietf.o= rg] On Behalf Of Gerald = Chouinard
Sent: Monday, January = 30, 2012 3:30 PM
To: paws@ietf.org
Subject: [paws] = Discussion on 'license-exempt' vs 'unlicensed'

 

Spectrum that is acquired by an operator over a given service area for a given = time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government = allocation (e.g., public service).

Special case where thefrequency allocation is done through first-come / = first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small local operators would be = interested by this (e.g., rural broadband in Canada) and not = big Telcos that would normally work with full licensing through auction = over large service areas.

Operation of RF devices in a frequency band where no formal licensing process is = needed such as in the 2.4 GHz ISM band. In the USA, this term = is used for a specific type of operation. The FCC should be contacted to clarify it.

Illegal operation of an RF device that can transmit in a frequency band without = a duly issued license.  In the USA, this term = is used to mean =93license-exempt," see above.

 USA to describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose.

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/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/m= ailman/listinfo/paws
_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws

= --Apple-Mail-7--129120265-- From Gabor.Bajko@nokia.com Thu Feb 2 13:39:43 2012 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 6AB8421F862D for ; Thu, 2 Feb 2012 13:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.685 X-Spam-Level: X-Spam-Status: No, score=-1.685 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SWvOoOOvmVLd for ; Thu, 2 Feb 2012 13:39:42 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 22E1721F8610 for ; Thu, 2 Feb 2012 13:39:41 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12Lddt9031814; Thu, 2 Feb 2012 23:39:40 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 2 Feb 2012 23:39:39 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.5]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 22:39:39 +0100 From: To: , Thread-Topic: [paws] Threat model (Rev 2) Thread-Index: AQHM4erMy/MZUkes7U+ecSFOJrxaWJYqA3wAgAAdfLA= Date: Thu, 2 Feb 2012 21:39:38 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DECDCD@008-AM1MPN1-006.mgdnok.nokia.com> References: <4F2AF6A8.6000106@cs.tcd.ie> In-Reply-To: <4F2AF6A8.6000106@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 21:39:39.0965 (UTC) FILETIME=[2AE1DED0:01CCE1F3] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 2) 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, 02 Feb 2012 21:39:43 -0000 I think that's a different threat from the one addressed below in threat 6. If in a regulatory domain the DB requires the master to provide its identit= y, then there's nothing to be done to prevent tracking of the masters by th= e DB. But if some other regulatory domain will not require the master to se= nd its identity when querying the DB, the master may decide not to send its= identity, to prevent the DB to track it. We could add this as another threat. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Stephen Farrell Sent: Thursday, February 02, 2012 12:49 PM To: Patil Basavaraj (Nokia-CIC/Dallas) Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 2) Pretty good overall. I'll keep on my usual track since I seem stuck on it h= ere;-) On 02/02/2012 08:37 PM, Basavaraj.Patil@nokia.com wrote: > > Threat 6: Third party tracking of white space device location > > > A master device needs to provide its location to the white > space database in order to obtain the channel availability > information at that location. Such location information can be > gleaned by an eavesdropper. A master device may prefer to keep > the location information secret. Hence the protocol should > provide a means to protect the location information and prevent > tracking of locations associated with a white space database. What's wrong with not wanting the DB to track me (as a master device)? Coul= d be that current known regulators don't like anonymous masters, but that m= ay change. (So I think 3rd party here is wrong.) Why is it only location tracking that's of concern? Why is exposing identit= y not an equal deal? Same logic as above. S. _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Thu Feb 2 13:47:40 2012 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 CE33821F85F0 for ; Thu, 2 Feb 2012 13:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfkh6a8SPMoF for ; Thu, 2 Feb 2012 13:47:39 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0894D21F85D7 for ; Thu, 2 Feb 2012 13:47:38 -0800 (PST) Received: by eaae12 with SMTP id e12so1182876eaa.31 for ; Thu, 02 Feb 2012 13:47:38 -0800 (PST) Received: by 10.213.3.198 with SMTP id 6mr735350ebo.61.1328219258049; Thu, 02 Feb 2012 13:47:38 -0800 (PST) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id z47sm6233901eeh.9.2012.02.02.13.47.37 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Feb 2012 13:47:37 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_6EA9D9F3-5ED0-4FF3-891D-512C9B4C603B" From: Teco Boot In-Reply-To: Date: Thu, 2 Feb 2012 22:47:35 +0100 Message-Id: <89B4F555-814C-4480-8E30-022F0727DCEA@inf-net.nl> References: To: "scott.probasco@nokia.com> X-Mailer: Apple Mail (2.1251.1) Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 02 Feb 2012 21:47:40 -0000 --Apple-Mail=_6EA9D9F3-5ED0-4FF3-891D-512C9B4C603B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Scott, It is a pity EU cannot report a straightforward plan for usage of white = spaces. But steps are taken. The doc has already a ref to ECC Report = 159. Minor comment on: > With the switch to digital transmission for TV, the guard bands that > existed to protect the signals between stations can now be used for > other purposes. I'm not sure this is true. I can't see why analogue broadcasting didn't = had white spaces. Maybe it is just an increased demand on spectrum and = the opportunities created with new technology, such as PAWS. Teco Op 2 feb. 2012, om 21:26 heeft = het volgende geschreven: > Hi Andy, >=20 > Very good to cover the UK situation also. I support your proposal and = plan to include the new section in the next update, pending any further = discussion on this thread. >=20 > Kind Regards, > Scott >=20 > From: ext com > Date: Thu, 2 Feb 2012 19:40:01 +0000 > To: Scott , "paws@ietf.org" > Subject: RE: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt=20 >=20 > Scott > =20 > Section 3 only addresses the US, presumably due to lack of = contributions from elsewhere. I propose a couple of short paragraphs to = cover the UK situation. The wording is not mine but is almost entirely = taken from the latest Ofcom Statement. > =20 > Section 3.2 is copied below for reference, unchanged, and I propose a = new section 3.3, also below: > =20 > 3.2. Background information on white space in US > Television transmission in the United States has moved to the use of > digital signals as of June 12, 2009. Since June 13, 2009, all = fullpower > U.S. television stations have broadcast over-the-air signals in > digital only. An important benefit of the switch to all-digital > broadcasting is that it freed up parts of the valuable broadcast > spectrum. More information about the switch to digital transmission > is at : [DTV]. > Probasco & Patil Expires July 30, 2012 [Page 8] > Internet-Draft PAWS: Problem, uses and requirements January 2012 > With the switch to digital transmission for TV, the guard bands that > existed to protect the signals between stations can now be used for > other purposes. The FCC has made this spectrum available for > unlicensed use and this is generally referred to as white space. > Please see the details of the FCC ruling and regulations in [FCC > Ruling]. The spectrum can be used to provide wireless broadband as > an example. The term "Super-Wifi" is also used to describe this > spectrum and potential for providing wifi type of service. > =20 > > 3.3. Background information on white space in UK > Since its launch in 2005, Ofcom=92s Digital Dividend Review [DDR] has = considered how to make the spectrum freed up by digital switchover = available for new uses, including the capacity available within the = spectrum that is retained to carry the digital terrestrial television = service. Similarly to the US, this interleaved or guard spectrum occurs = because not all the spectrum in any particular location will be used for = terrestrial television and so is available for other services, as long = as they can interleave their usage around the existing users. > =20 > In its September 2011 Statement [Ofcom Implementing] Ofcom says that a = key element in enabling white space usage in the TV bands is the = definition and provision of a database which, given a device=92s = location, can tell the device which frequency channels and power levels = it is able to use without causing harmful interference to other licensed = users in the vicinity. Ofcom will specify requirements to be met by such = geolocation databases. It also says that the technology has the = possibility of being usefully applied elsewhere in the radio spectrum to = ensure it is used to maximum benefit. For example, it may have potential = in making spectrum available for new uses following any switch to = digital radio services. Alternatively it may be helpful in exploiting = some of the public sector spectrum holdings. Ofcom will continue to = consider other areas of the radio spectrum where white space usage may = be of benefit. > > =20 > Regards > =20 > Andy > =20 > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com > Sent: 26 January 2012 23:43 > To: paws@ietf.org > Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > =20 > Hi, > =20 > Revision 2 of the PS, Use cases and requirements I-D has been posted. = Please see: > = http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-= rqmts-02.txt > =20 > This version only includes changes requested by the co-chair in his = email of January 12 = http://www.ietf.org/mail-archive/web/paws/current/msg00516.html=20 > Specifically: > " >> 2. requirements. In the last f2f >> we agreed to modify requirement D.1 to include the suggestions from = slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and = merge with D.6 and D.9 >> slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf = also contain suggestions on how to revise this requirement. >> Agreed to revise requirement D.2 as suggested in slide 11 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of = http://www.ietf.org/proceedings/82/slides/paws-1.pdf >> We seem to have agreed with the reformulation suggested to D.3 in = slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we = did not agree on the format the location would be represented in. The = data format part is still open, but as this piece does not really belong = to requirements but rather the data model spec, we are not in a hurry to = decide it. >> Delete d.4 >> D.5: augment with lower/upper frequencies and time of availability, = as suggested on slide 10 = ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf >> D.6: change power to eirp, as suggested in slide 13 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdf. >> D.7: change to single and multiple locations. Clarify that in case of = multiple locations the channel availability for each location should be = sent by the db. >> D.8: delete >=20 > " >> =20 >=20 > And > " >> Operational requirements: slides 22-24 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions = on rewording, I propose the editor considers them. >=20 > " > =20 > =20 > Regards, > Scott & Raj > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_6EA9D9F3-5ED0-4FF3-891D-512C9B4C603B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Scott,

It is a pity EU cannot report a = straightforward plan for usage of white spaces. But steps are taken. The = doc has already a ref to ECC Report 159.

Minor = comment on:
With the switch = to digital transmission for TV, the guard bands = that
existed to protect the signals between stations can now be = used for
other = purposes.
I'm not sure this is true. I can't see why analogue = broadcasting didn't had white spaces. Maybe it is just an increased = demand on spectrum and the opportunities created with new technology, = such as PAWS.

Teco

Op 2 = feb. 2012, om 21:26 heeft <scott.probasco@nokia.com> = <scott.probasco@nokia.com> = het volgende geschreven:

Hi Andy,

Very good to cover the UK situation also. I support your proposal = and plan to include the new section in the next update, pending any = further discussion on this thread.

Kind Regards,
Scott

From: ext com <andy.sago@bt.com>
Date: Thu, 2 Feb 2012 19:40:01 = +0000
To: Scott <scott.probasco@nokia.com>,= "paws@ietf.org" <paws@ietf.org>
Subject: RE: = draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt

 

3.2. Background = information on white space in US

Television transmission = in the United States has moved to the use of

digital signals as of = June 12, 2009. Since June 13, 2009, all = fullpower

U.S. television stations = have broadcast over-the-air signals in

digital only. An = important benefit of the switch to all-digital

broadcasting is that it = freed up parts of the valuable broadcast

spectrum. More = information about the switch to digital = transmission

is at : = [DTV].

Probasco & Patil = Expires July 30, 2012 [Page 8]

Internet-Draft PAWS: = Problem, uses and requirements January 2012

With the switch to = digital transmission for TV, the guard bands = that

existed to protect the = signals between stations can now be used for

other purposes. The FCC = has made this spectrum available for

unlicensed use and this = is generally referred to as white space.

Please see the details of = the FCC ruling and regulations in [FCC

Ruling]. The spectrum can = be used to provide wireless broadband as

an example. The term = "Super-Wifi" is also used to describe this

spectrum and potential = for providing wifi type of service.Since its launch = in 2005, Ofcom=92s Digital Dividend Review [DDR] has considered how to = make the spectrum freed up by digital switchover available for new uses, = including the capacity available within the spectrum that is retained to carry = the digital terrestrial television service. Similarly to the US, this = interleaved or guard spectrum occurs because not all the spectrum in any = particular location will be used for terrestrial television and so is available for other services, as long as they can = interleave their usage around the existing users.
In = its September 2011 Statement [Ofcom Implementing] Ofcom says that a key = element in enabling white space usage in the TV bands is the definition = and provision of a database which, given a device=92s location, can tell the device = which frequency channels and power levels it is able to use without = causing harmful interference to other licensed users in the vicinity. = Ofcom will specify requirements to be met by such geolocation databases. It also says that the technology has the possibility of = being usefully applied elsewhere in the radio spectrum to ensure it is = used to maximum benefit. For example, it may have potential in making = spectrum available for new uses following any switch to digital radio services. Alternatively it may be helpful in = exploiting some of the public sector spectrum holdings. Ofcom will = continue to consider other areas of the radio spectrum where white space = usage may be of benefit.
</Insert>
 
Regards
 
Andy
 
 
paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: 26 January 2012 23:43
To: paws@ietf.org
Subject: [paws] = draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt
=
 
Hi,=
 
Revision 2 = of the PS, Use cases and requirements I-D has been posted. Please = see:
 
This version = only includes changes requested by the co-chair in his email of January = 12 h= ttp://www.ietf.org/mail-archive/web/paws/current/msg00516.html 
Specifically:<= o:p>
"
2. = requirements. In the last f2f
we agreed to = modify requirement D.1 to include the suggestions from slide 7-10 ofhttp://www.i= etf.org/proceedings/82/slides/paws-2.pdf and merge with D.6 and D.9
slides = 7&8 of http://www.i= etf.org/proceedings/82/slides/paws-1.pdf also contain = suggestions on how to revise this requirement.
Agreed to = revise requirement D.2 as suggested in slide 11 of http://www.i= etf.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.i= etf.org/proceedings/82/slides/paws-1.pdf
We seem to = have agreed with the reformulation suggested to D.3 in slide 12 ofhttp://www.i= etf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented = in. The data format part is still open, but as this piece does not = really belong to requirements but rather the data model spec, we are not = in a hurry to decide it.
Delete = d.4
D.5: augment = with lower/upper frequencies and time of availability, as suggested on = slide 10 ofhttp://www.i= etf.org/proceedings/82/slides/paws-1.pdf
D.6: change = power to eirp, as suggested in slide 13 of http://www.i= etf.org/proceedings/82/slides/paws-2.pdf.
D.7: change = to single and multiple locations. Clarify that in case of multiple = locations the channel availability for each location should be sent by = the db.
D.8: = delete
"
 
And=
"
Operational = requirements: slides 22-24 of http://www.i= etf.org/proceedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers = them.
"
 
 
Regards,<= /o:p>
Scott & = Raj
_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws

= --Apple-Mail=_6EA9D9F3-5ED0-4FF3-891D-512C9B4C603B-- From scott.probasco@nokia.com Thu Feb 2 14:21:14 2012 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 007A221F865B for ; Thu, 2 Feb 2012 14:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wJLXcVGB9l9 for ; Thu, 2 Feb 2012 14:21:12 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 82F1E21F8663 for ; Thu, 2 Feb 2012 14:21:12 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12ML2iA017637; Fri, 3 Feb 2012 00:21:05 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 00:21:03 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 23:21:02 +0100 From: To: Thread-Topic: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: AQHM4fRNM6PQoXlBZEKtd2pq8c01upYpuJ4A Date: Thu, 2 Feb 2012 22:21:02 +0000 Message-ID: In-Reply-To: <89B4F555-814C-4480-8E30-022F0727DCEA@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: multipart/alternative; boundary="_000_CB506816100D2scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 22:21:04.0046 (UTC) FILETIME=[F3828CE0:01CCE1F8] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 02 Feb 2012 22:21:14 -0000 --_000_CB506816100D2scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Teco, Did you have any text you want to suggest? I guess the text in question is = accurate enough in practical terms, even if it does allow room for discussi= on in theoretical terms. I get your point that white space paradigm applies= regardless of the incumbent radio service. I also believe a thorough discu= ssion of your comment would wander into the realm of radio transmission the= ory and perhaps we could leave that for offline discussion at the next meet= ing :-) Kind Regards, Scott From: ext Teco Boot > Date: Thu, 2 Feb 2012 22:47:35 +0100 To: Scott > Cc: ext com >, "paws@ietf.org" > Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi Scott, It is a pity EU cannot report a straightforward plan for usage of white spa= ces. But steps are taken. The doc has already a ref to ECC Report 159. Minor comment on: With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. I'm not sure this is true. I can't see why analogue broadcasting didn't had= white spaces. Maybe it is just an increased demand on spectrum and the opp= ortunities created with new technology, such as PAWS. Teco Op 2 feb. 2012, om 21:26 heeft > >= het volgende geschreven: Hi Andy, Very good to cover the UK situation also. I support your proposal and plan = to include the new section in the next update, pending any further discussi= on on this thread. Kind Regards, Scott From: ext com > Date: Thu, 2 Feb 2012 19:40:01 +0000 To: Scott >, "paw= s@ietf.org" > Subject: RE: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Scott Section 3 only addresses the US, presumably due to lack of contributions fr= om elsewhere. I propose a couple of short paragraphs to cover the UK situat= ion. The wording is not mine but is almost entirely taken from the latest O= fcom Statement. Section 3.2 is copied below for reference, unchanged, and I propose a new s= ection 3.3, also below: 3.2. Background information on white space in US Television transmission in the United States has moved to the use of digital signals as of June 12, 2009. Since June 13, 2009, all fullpower U.S. television stations have broadcast over-the-air signals in digital only. An important benefit of the switch to all-digital broadcasting is that it freed up parts of the valuable broadcast spectrum. More information about the switch to digital transmission is at : [DTV]. Probasco & Patil Expires July 30, 2012 [Page 8] Internet-Draft PAWS: Problem, uses and requirements January 2012 With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. The FCC has made this spectrum available for unlicensed use and this is generally referred to as white space. Please see the details of the FCC ruling and regulations in [FCC Ruling]. The spectrum can be used to provide wireless broadband as an example. The term "Super-Wifi" is also used to describe this spectrum and potential for providing wifi type of service. 3.3. Background information on white space in UK Since its launch in 2005, Ofcom=92s Digital Dividend Review [DDR] has consi= dered how to make the spectrum freed up by digital switchover available for= new uses, including the capacity available within the spectrum that is ret= ained to carry the digital terrestrial television service. Similarly to the= US, this interleaved or guard spectrum occurs because not all the spectrum= in any particular location will be used for terrestrial television and so = is available for other services, as long as they can interleave their usage= around the existing users. In its September 2011 Statement [Ofcom Implementing] Ofcom says that a key = element in enabling white space usage in the TV bands is the definition and= provision of a database which, given a device=92s location, can tell the d= evice which frequency channels and power levels it is able to use without c= ausing harmful interference to other licensed users in the vicinity. Ofcom = will specify requirements to be met by such geolocation databases. It also = says that the technology has the possibility of being usefully applied else= where in the radio spectrum to ensure it is used to maximum benefit. For ex= ample, it may have potential in making spectrum available for new uses foll= owing any switch to digital radio services. Alternatively it may be helpful= in exploiting some of the public sector spectrum holdings. Ofcom will cont= inue to consider other areas of the radio spectrum where white space usage = may be of benefit. Regards Andy From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: 26 January 2012 23:43 To: paws@ietf.org Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi, Revision 2 of the PS, Use cases and requirements I-D has been posted. Pleas= e see: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-02.txt This version only includes changes requested by the co-chair in his email o= f January 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.htm= l Specifically: " 2. requirements. In the last f2f we agreed to modify requirement D.1 to include the suggestions from slide 7= -10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D= .6 and D.9 slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also con= tain suggestions on how to revise this requirement. Agreed to revise requirement D.2 as suggested in slide 11 of http://www.iet= f.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/pr= oceedings/82/slides/paws-1.pdf We seem to have agreed with the reformulation suggested to D.3 in slide 12 = ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agre= e on the format the location would be represented in. The data format part = is still open, but as this piece does not really belong to requirements but= rather the data model spec, we are not in a hurry to decide it. Delete d.4 D.5: augment with lower/upper frequencies and time of availability, as sugg= ested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/= proceedings/82/slides/paws-2.pdf. D.7: change to single and multiple locations. Clarify that in case of multi= ple locations the channel availability for each location should be sent by = the db. D.8: delete " And " Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/8= 2/slides/paws-2.pdf contain suggestions on rewording, I propose the editor = considers them. " Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CB506816100D2scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6BC505760AF1E943A237939104DEBB3E@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi Teco,

Did you have any text you want to suggest? I guess the text in qu= estion is accurate enough in practical terms, even if it does allow room fo= r discussion in theoretical terms. I get your point that white space p= aradigm applies regardless of the incumbent radio service. I also believe a thorough discussion of your comment would = wander into the realm of radio transmission theory and perhaps we could lea= ve that for offline discussion at the next meeting :-) 

Kind Regards,
Scott

From: ext Teco Boot <teco@inf-net.nl>
Date: Thu, 2 Feb 2012 22:47:35 += ;0100
To: Scott <scott.probasco@nokia.com>
Cc: ext com <andy.sago@bt.com>, "paws@ietf.org" <paws@ie= tf.org>
Subject: Re: [paws] draft-ietf-paws= -problem-stmt-usecases-rqmts-02.txt

Hi Scott,

It is a pity EU cannot report a straightforward plan for usage of whit= e spaces. But steps are taken. The doc has already a ref to ECC Report= 159.

Minor comment on:
With the switch to digital t= ransmission for TV, the guard bands that
existed to protect = the signals between stations can now be used for
other purposes.
I'm not sure this is true. I can't see why analogue broadcasting didn'= t had white spaces. Maybe it is just an increased demand on spectrum a= nd the opportunities created with new technology, such as PAWS.

Teco

Op 2 feb. 2012, om 21:26 heeft <scott.probasco@nokia.com> <scott.probasco@nokia.com> het volgende geschreven:
Hi Andy,

Very good to cover the UK situation also. I support your proposal and = plan to include the new section in the next update, pending any further dis= cussion on this thread.

Kind Regards,
Scott

From: ext com <andy.sago@bt.com>
Date: Thu, 2 Feb 2012 19:40:01 += ;0000
To: Scott <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: draft-ietf-paws-proble= m-stmt-usecases-rqmts-02.txt

Scott
 
Section 3 only addresses the US, presumably due t= o lack of contributions from elsewhere. I propose a couple of short paragra= phs to cover the UK situation. The wording is not mine but is almost entirely taken from the latest Ofcom Statement.<= o:p>
 
Section 3.2 is copied below for reference, unchan= ged, and I propose a new section 3.3, also below:
 

3.2. Background information on white space i= n US

Television transmission in the United States= has moved to the use of

digital signals as of June 12, 2009. Since J= une 13, 2009, all fullpower

U.S. television stations have broadcast over= -the-air signals in

digital only. An important benefit of the sw= itch to all-digital

broadcasting is that it freed up parts of th= e valuable broadcast

spectrum. More information about the switch = to digital transmission

is at : [DTV].

Probasco & Patil Expires July 30, 2012 [= Page 8]

Internet-Draft PAWS: Problem, uses and requi= rements January 2012

With the switch to digital transmission for = TV, the guard bands that

existed to protect the signals between stati= ons can now be used for

other purposes. The FCC has made this spectr= um available for

unlicensed use and this is generally referre= d to as white space.

Please see the details of the FCC ruling and= regulations in [FCC

Ruling]. The spectrum can be used to provide= wireless broadband as

an example. The term "Super-Wifi" = is also used to describe this

spectrum and potential for providing wifi type of service.<= /o:p>
 
<Insert>
3.3.  Background information on white space = in UK
Since its launch in 2005, Ofcom=92s Digital Divid= end Review [DDR] has considered how to make the spectrum freed up by digita= l switchover available for new uses, including the capacity available within the spectrum that is retained to carry the d= igital terrestrial television service. Similarly to the US, this interleave= d or guard spectrum occurs because not all the spectrum in any particular l= ocation will be used for terrestrial television and so is available for other services, as long as they can int= erleave their usage around the existing users.
 
In its September 2011 Statement [Ofcom Implementi= ng] Ofcom says that a key element in enabling white space usage in the TV b= ands is the definition and provision of a database which, given a device=92s location, can tell the device whic= h frequency channels and power levels it is able to use without causing har= mful interference to other licensed users in the vicinity. Ofcom will speci= fy requirements to be met by such geolocation databases. It also says that the technology has the possibilit= y of being usefully applied elsewhere in the radio spectrum to ensure it is= used to maximum benefit. For example, it may have potential in making spec= trum available for new uses following any switch to digital radio services. Alternatively it may be helpful in e= xploiting some of the public sector spectrum holdings. Ofcom will continue = to consider other areas of the radio spectrum where white space usage may b= e of benefit.
</Insert>
 
Regards
 
Andy
 
 
From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of scott.probasco@nokia.com
Sent: 26 January 2012 23:43
To: paws@ietf.org
Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt
 
Hi,
 
Revision 2 of the PS, Use cases and requirements I-D has be= en posted. Please see:
 
This version only includes changes requested by the co-chai= r in his email of January 12 http://www.ietf.org/mail-archive/web/paw= s/current/msg00516.html 
Specifically:
"
2. requirements. In the last f2f
we agreed to modify requirement D.1 to include the suggesti= ons from slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf a= nd merge with D.6 and D.9
slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws= -1.pdf also contain suggestions on how to revise this requirement.
Agreed to revise requirement D.2 as suggested in slide 11 o= f htt= p://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf<= /span>
We seem to have agreed with the reformulation suggested to = D.3 in slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented in. T= he data format part is still open, but as this piece does not really belong= to requirements but rather the data model spec, we are not in a hurry to d= ecide it.
Delete d.4
D.5: augment with lower/upper frequencies and time of avail= ability, as suggested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.= pdf
D.6: change power to eirp, as suggested in slide 13 of = ;http://ww= w.ietf.org/proceedings/82/slides/paws-2.pdf.
D.7: change to single and multiple locations. Clarify that = in case of multiple locations the channel availability for each location sh= ould be sent by the db.
D.8: delete
"
 
And
"
Operational requirements: slides 22-24 of http://www.ietf.org/pr= oceedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers them.<= /span>
"
 
 
Regards,
Scott & Raj
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org= /mailman/listinfo/paws

--_000_CB506816100D2scottprobasconokiacom_-- From scott.probasco@nokia.com Thu Feb 2 14:53:31 2012 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 EB2C621F8650 for ; Thu, 2 Feb 2012 14:53:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.988 X-Spam-Level: X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=0.611, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uOVRqNnQ43dh for ; Thu, 2 Feb 2012 14:53:30 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8F0A521F864F for ; Thu, 2 Feb 2012 14:53:30 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q12MrLew018189; Fri, 3 Feb 2012 00:53:21 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 00:53:15 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Thu, 2 Feb 2012 23:53:14 +0100 From: To: , , Thread-Topic: [paws] Use cases and requirements: sections 9 and 11 (Summary and Conclusion, References) Thread-Index: AQHM4f1yjs07xx/sZUKTv3Bp3ggXTQ== Date: Thu, 2 Feb 2012 22:53:13 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F71414065033161@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <2207AF41F141054B86FB7CF85F571283@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 02 Feb 2012 22:53:15.0351 (UTC) FILETIME=[72A84E70:01CCE1FD] X-Nokia-AV: Clean Subject: Re: [paws] Use cases and requirements: sections 9 and 11 (Summary and Conclusion, References) 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, 02 Feb 2012 22:53:32 -0000 Gerald, Andy, Thank you for these comments. I will include these changes in version 03. Kind Regards, Scott On 1/30/12 10:55 AM, "ext andy.sago@bt.com" wrote: >Scott > >Agreed these are good changes. Also, last paragraph of the conclusion, >"... and also shows an examples of a services provided ....", delete both >"an" and "a". In the references, there is a shorter link to [Ofcom >Implementing] :=20 >http://stakeholders.ofcom.org.uk/consultations/geolocation/statement/ > >Regards > >Andy > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >gerald.chouinard@crc.ca >Sent: 30 January 2012 15:27 >To: scott.probasco@nokia.com >Cc: paws@ietf.org >Subject: Re: [paws] Use cases and requirements: sections 9 and 11 >(Summary and Conclusion, References) > >Hi Scott, all, > >Here are some suggested changes to the text: > >- 7th line of section 9: change "secondary" for "opportunistic". In the >ITU-R Table of frequency allotment, there are bands where primary and >secondary services already exist. White Space opportunistic use would >then become some sort of tertiary service usage. > >- Penultimate sentence of section 9: add a coma as follows: "From these >use cases, requirements are determined." > >- Section 11, first reference: >(802.11p) ... > >- Section 11, add a new second reference: >(802.22) IEEE, "IEEE Standard for Information technology - > Telecommunications and information exchange between > systems - Wireless Regional Area Networks (WRAN) - Specific > requirements; Part 22: Cognitive Wireless RAN Medium Access > Control (MAC) and Physical Layer (PHY) Specifications: >Policies > and Procedures for Operation in the TV bands; http:// > standards.ieee.org/getieee802/download/802.22-2011.pdf", > July 2011. > >Regards, > >Gerald > > >Quoting scott.probasco@nokia.com: > >> Hello All, >> >> As editors of the problem statement, use cases & requirements draft we >> are attempting to prepare a completed draft which could be ready for >> working group last call before IETF83. In the coming days we will post >> the sections of the draft to the mailing list. Our request is that you >> review these sections and reply to the email with any comments. >> >> Below is the text for sections 9 and 11. This text has not changed >> from >> version-02 as uploaded January 26, 2012. Our goal is that any >> discussion on this text will conclude by February 6. To be clear, >> approval of the document will go through the normal process of last >> calls etc.. We are simply asking for your assistance in preparing a >> complete & accurate document that could progress the work. So please >> review the text and send your comments either directly to the editor or >>to the mailing list. >> >> Kind Regards, >> Raj & Scott >> >> >> >> 9. Summary and Conclusion >> >> Wireless spectrum is a scarce resource. As the demand for spectrum >> grows, there is a need to more efficiently utilize the available and >> allocated spectrum. Cognitive radio technologies enable the >> efficient usage of spectrum via means such as sensing or by querying >> a database to determine available spectrum at a given location for >> secondary use. White space is the general term used to refer to the >> bands within the spectrum which is available for secondary use at a >> given location. In order to use this spectrum a device needs to >> query a database which maintains information about the available >> channels within a band. A protocol is necessary for communication >> between the devices and databases which would be globally applicable. >> >> The document describes some examples of the role of the white space >> database in the operation of a radio network and also shows an >> examples of a services provided to the user of a TVWS device. From >> these use cases requirements are determined. These requirements are >> to be used as input to the definition of a Protocol to Access White >> Space database (PAWS). >> >> >> >> 11. References >> >> 11.1. Normative References >> >> [80211P] IEEE, "IEEE Standard for Information technology - >> Telecommunications and information exchange between >> systems - Local and metropolitan area networks - Specific >> requirements; Part 11: Wireless LAN Medium Access Control >> (MAC) and Physical Layer (PHY) Specifications; Amendment >> 6: Wireless Access in Vehicular Environments; http:// >> standards.ieee.org/getieee802/download/802.11p-2010.pdf", >> July 2010. >> >> [FCC47CFR90.210] >> FCC, "Title 47 Telecommunication CFR Chapter I - Federal >> Communication Commission Part 90 - Private Land Mobile >> Radio Services - Section 210 Emission masks; http:// >> edocket.access.gpo.gov/cfr_2010/octqtr/pdf/ >> 47cfr90.210.pdf", October 2010. >> >> [PAWS-PS] IETF, "Protocol to Access White Space database: Problem >> statement; https://datatracker.ietf.org/doc/ >> draft-patil-paws-problem-stmt/", July 2011. >> >> [RFC2119] IETF, "Key words for use in RFCs to Indicate Requirement >> Levels; >> http://www.rfc-editor.org/rfc/pdfrfc/rfc2119.txt.pdf", >> March 1997. >> >> 11.2. Informative References >> >> [DDR] Ofcom - Independent regulator and competition authority >> for the UK communications industries, "Digital Dividend >> Review; http://stakeholders.ofcom.org.uk/spectrum/ >> project-pages/ddr/". >> >> [DTV] "Digital TV Transition; http://www.dtv.gov". >> >> [ECC Report 159] >> Electronic Communications Committee (ECC) within the >> European Conference of Postal and Telecommunications >> Administrations (CEPT), "TECHNICAL AND OPERATIONAL >> REQUIREMENTS FOR THE POSSIBLE OPERATION OF COGNITIVE RADIO >> SYSTEMS IN THE 'WHITE SPACES' OF THE FREQUENCY BAND 470- >> 590 MHZ; http://www.erodocdb.dk/Docs/doc98/official/pdf/ >> ECCREP159.PDF", January 2011. >> >> [FCC Ruling] >> >> >> >> Probasco & Patil Expires July 18, 2012 [Page 32] >> >> Internet-Draft PAWS: Problem, uses and requirements January 2012 >> >> >> FCC, "Federal Communications Commission, "Unlicensed >> Operation in the TV Broadcast Bands; >> http://edocket.access.gpo.gov/2010/pdf/2010-30184.pdf"", >> December 2010. >> >> [Ofcom Implementing] >> Ofcom, "Ofcom, "Implementing Geolocation; http:// >> stakeholders.ofcom.org.uk/consultations/geolocation/ >> statement/ >> ?utm_source=3Dupdates&utm_medium=3Demail& >> utm_campaign=3Dgeolocation-statement"", September 2011. >> >> [RFC5222] IETF, Hardie, T., Netwon, A., Schulzrinne, H., and H. >> Tschofenig, "LoST: A Location-to-Service Translation Proto >> col;http://www.rfc-editor.org/rfc/pdfrfc/rfc5222.txt.pdf", >> August 2008. >> >> [Spectrum Framework Review] >> Ofcom - Independent regulator and competition authority >> for the UK communications industries, "Spectrum Framework >> Review; >> http://stakeholders.ofcom.org.uk/consultations/sfr/", >> February 2005. >> >> [TV Whitespace Tutorial Intro] >> IEEE 802 Executive Committee Study Group on TV White >> Spaces, "TV Whitespace Tutorial Intro; http:// >> grouper.ieee.org/groups/802/802_tutorials/2009-03/ >> 2009-03-10%20TV%20Whitespace%20Tutorial%20r0.pdf", >> March 2009. >> >> _______________________________________________ >> 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 teco@inf-net.nl Thu Feb 2 23:40:40 2012 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 EB24F21F85B5 for ; Thu, 2 Feb 2012 23:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.428 X-Spam-Level: X-Spam-Status: No, score=-3.428 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYeCRihlfXHl for ; Thu, 2 Feb 2012 23:40:39 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C750221F85A7 for ; Thu, 2 Feb 2012 23:40:35 -0800 (PST) Received: by eekc41 with SMTP id c41so1013772eek.31 for ; Thu, 02 Feb 2012 23:40:35 -0800 (PST) Received: by 10.14.130.208 with SMTP id k56mr1909965eei.123.1328254834899; Thu, 02 Feb 2012 23:40:34 -0800 (PST) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id z47sm11246197eeh.9.2012.02.02.23.40.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 02 Feb 2012 23:40:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_F2FFDD58-2EB0-4CF8-AF43-832A85D025EC" From: Teco Boot In-Reply-To: Date: Fri, 3 Feb 2012 08:40:32 +0100 Message-Id: References: To: X-Mailer: Apple Mail (2.1251.1) Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 03 Feb 2012 07:40:41 -0000 --Apple-Mail=_F2FFDD58-2EB0-4CF8-AF43-832A85D025EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Scott, Something like this? WithBesides the switch to digital = transmission for TV, the guard bands that existedexists to protect the signals = between stations can now be used for other purposes. Teco Op 2 feb. 2012, om 23:21 heeft = het volgende geschreven: > Hi Teco, >=20 > Did you have any text you want to suggest? I guess the text in = question is accurate enough in practical terms, even if it does allow = room for discussion in theoretical terms. I get your point that white = space paradigm applies regardless of the incumbent radio service. I also = believe a thorough discussion of your comment would wander into the = realm of radio transmission theory and perhaps we could leave that for = offline discussion at the next meeting :-)=20 >=20 > Kind Regards, > Scott >=20 > From: ext Teco Boot > Date: Thu, 2 Feb 2012 22:47:35 +0100 > To: Scott > Cc: ext com , "paws@ietf.org" > Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >=20 > Hi Scott, >=20 > It is a pity EU cannot report a straightforward plan for usage of = white spaces. But steps are taken. The doc has already a ref to ECC = Report 159. >=20 > Minor comment on: >> With the switch to digital transmission for TV, the guard bands that >> existed to protect the signals between stations can now be used for >> other purposes. >=20 > I'm not sure this is true. I can't see why analogue broadcasting = didn't had white spaces. Maybe it is just an increased demand on = spectrum and the opportunities created with new technology, such as = PAWS. >=20 > Teco >=20 > Op 2 feb. 2012, om 21:26 heeft = het volgende geschreven: >=20 >> Hi Andy, >>=20 >> Very good to cover the UK situation also. I support your proposal and = plan to include the new section in the next update, pending any further = discussion on this thread. >>=20 >> Kind Regards, >> Scott >>=20 >> From: ext com >> Date: Thu, 2 Feb 2012 19:40:01 +0000 >> To: Scott , "paws@ietf.org" >> Subject: RE: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt=20 >>=20 >> Scott >> =20 >> Section 3 only addresses the US, presumably due to lack of = contributions from elsewhere. I propose a couple of short paragraphs to = cover the UK situation. The wording is not mine but is almost entirely = taken from the latest Ofcom Statement. >> =20 >> Section 3.2 is copied below for reference, unchanged, and I propose a = new section 3.3, also below: >> =20 >> 3.2. Background information on white space in US >> Television transmission in the United States has moved to the use of >> digital signals as of June 12, 2009. Since June 13, 2009, all = fullpower >> U.S. television stations have broadcast over-the-air signals in >> digital only. An important benefit of the switch to all-digital >> broadcasting is that it freed up parts of the valuable broadcast >> spectrum. More information about the switch to digital transmission >> is at : [DTV]. >> Probasco & Patil Expires July 30, 2012 [Page 8] >> Internet-Draft PAWS: Problem, uses and requirements January 2012 >> With the switch to digital transmission for TV, the guard bands that >> existed to protect the signals between stations can now be used for >> other purposes. The FCC has made this spectrum available for >> unlicensed use and this is generally referred to as white space. >> Please see the details of the FCC ruling and regulations in [FCC >> Ruling]. The spectrum can be used to provide wireless broadband as >> an example. The term "Super-Wifi" is also used to describe this >> spectrum and potential for providing wifi type of service. >> =20 >> >> 3.3. Background information on white space in UK >> Since its launch in 2005, Ofcom=92s Digital Dividend Review [DDR] has = considered how to make the spectrum freed up by digital switchover = available for new uses, including the capacity available within the = spectrum that is retained to carry the digital terrestrial television = service. Similarly to the US, this interleaved or guard spectrum occurs = because not all the spectrum in any particular location will be used for = terrestrial television and so is available for other services, as long = as they can interleave their usage around the existing users. >> =20 >> In its September 2011 Statement [Ofcom Implementing] Ofcom says that = a key element in enabling white space usage in the TV bands is the = definition and provision of a database which, given a device=92s = location, can tell the device which frequency channels and power levels = it is able to use without causing harmful interference to other licensed = users in the vicinity. Ofcom will specify requirements to be met by such = geolocation databases. It also says that the technology has the = possibility of being usefully applied elsewhere in the radio spectrum to = ensure it is used to maximum benefit. For example, it may have potential = in making spectrum available for new uses following any switch to = digital radio services. Alternatively it may be helpful in exploiting = some of the public sector spectrum holdings. Ofcom will continue to = consider other areas of the radio spectrum where white space usage may = be of benefit. >> >> =20 >> Regards >> =20 >> Andy >> =20 >> =20 >> From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com >> Sent: 26 January 2012 23:43 >> To: paws@ietf.org >> Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >> =20 >> Hi, >> =20 >> Revision 2 of the PS, Use cases and requirements I-D has been posted. = Please see: >> = http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-= rqmts-02.txt >> =20 >> This version only includes changes requested by the co-chair in his = email of January 12 = http://www.ietf.org/mail-archive/web/paws/current/msg00516.html=20 >> Specifically: >> " >>> 2. requirements. In the last f2f >>> we agreed to modify requirement D.1 to include the suggestions from = slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and = merge with D.6 and D.9 >>> slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf = also contain suggestions on how to revise this requirement. >>> Agreed to revise requirement D.2 as suggested in slide 11 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of = http://www.ietf.org/proceedings/82/slides/paws-1.pdf >>> We seem to have agreed with the reformulation suggested to D.3 in = slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we = did not agree on the format the location would be represented in. The = data format part is still open, but as this piece does not really belong = to requirements but rather the data model spec, we are not in a hurry to = decide it. >>> Delete d.4 >>> D.5: augment with lower/upper frequencies and time of availability, = as suggested on slide 10 = ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf >>> D.6: change power to eirp, as suggested in slide 13 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdf. >>> D.7: change to single and multiple locations. Clarify that in case = of multiple locations the channel availability for each location should = be sent by the db. >>> D.8: delete >>=20 >> " >>> =20 >>=20 >> And >> " >>> Operational requirements: slides 22-24 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions = on rewording, I propose the editor considers them. >>=20 >> " >> =20 >> =20 >> Regards, >> Scott & Raj >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 --Apple-Mail=_F2FFDD58-2EB0-4CF8-AF43-832A85D025EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Scott,

Something like = this?

<delete>With</delete><insert>Besides</insert> = the switch to digital transmission for TV, the guard bands = that
existed to protect the signals between stations = can <delete>now be used = for
other purposes.

scott.probasco@nokia.com> = <scott.probasco@nokia.com> = het volgende geschreven:

Hi Teco,

Did you have any text you want to suggest? I guess the text in = question is accurate enough in practical terms, even if it does allow = room for discussion in theoretical terms. I get your point that = white space paradigm applies regardless of the incumbent radio service. I also believe a thorough discussion of your comment = would wander into the realm of radio transmission theory and perhaps we = could leave that for offline discussion at the next meeting = :-) 

Kind Regards,
Scott

From: ext Teco Boot <teco@inf-net.nl>
Date: Thu, 2 Feb 2012 22:47:35 = +0100
To: Scott <scott.probasco@nokia.com><= br> Cc: ext com <andy.sago@bt.com>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] = draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt

Hi Scott,

It is a pity EU cannot report a straightforward plan for usage of = white spaces. But steps are taken. The doc has already a ref to ECC = Report 159.

Minor comment on:
With the switch = to digital transmission for TV, the guard bands that
existed to = protect the signals between stations can now be used = for
other = purposes.
I'm not sure this is true. I can't see why analogue broadcasting = didn't had white spaces. Maybe it is just an increased demand on = spectrum and the opportunities created with new technology, such as = PAWS.

Teco

Op 2 feb. 2012, om 21:26 heeft <scott.probasco@nokia.com> = <scott.probasco@nokia.com> = het volgende geschreven:

Hi Andy,

Very good to cover the UK situation also. I support your proposal = and plan to include the new section in the next update, pending any = further discussion on this thread.

Kind Regards,
Scott

From: ext com <andy.sago@bt.com>
Date: Thu, 2 Feb 2012 19:40:01 = +0000
To: Scott <scott.probasco@nokia.com>,= "paws@ietf.org" <paws@ietf.org>
Subject: RE: = draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt

Scott
 
Section 3 only addresses the US, = presumably due to lack of contributions from elsewhere. I propose a = couple of short paragraphs to cover the UK situation. The wording is not mine but is almost entirely taken from the latest Ofcom = Statement.
 
Section 3.2 is copied below for = reference, unchanged, and I propose a new section 3.3, also = below:
 

3.2. Background = information on white space in US

Television transmission = in the United States has moved to the use of

digital signals as of = June 12, 2009. Since June 13, 2009, all = fullpower

U.S. television stations = have broadcast over-the-air signals in

digital only. An = important benefit of the switch to all-digital

broadcasting is that it = freed up parts of the valuable broadcast

spectrum. More = information about the switch to digital = transmission

is at : = [DTV].

Probasco & Patil = Expires July 30, 2012 [Page 8]

Internet-Draft PAWS: = Problem, uses and requirements January 2012

With the switch to = digital transmission for TV, the guard bands = that

existed to protect the = signals between stations can now be used for

other purposes. The FCC = has made this spectrum available for

unlicensed use and this = is generally referred to as white space.

Please see the details of = the FCC ruling and regulations in [FCC

Ruling]. The spectrum can = be used to provide wireless broadband as

an example. The term = "Super-Wifi" is also used to describe this

spectrum and potential = for providing wifi type of service.
 
3.3.  Background information on = white space in UK
Since its launch in 2005, Ofcom=92s = Digital Dividend Review [DDR] has considered how to make the spectrum = freed up by digital switchover available for new uses, including the capacity available within the spectrum that is retained to carry = the digital terrestrial television service. Similarly to the US, this = interleaved or guard spectrum occurs because not all the spectrum in any = particular location will be used for terrestrial television and so is available for other services, as long as they can = interleave their usage around the existing users.
 
In its September 2011 Statement = [Ofcom Implementing] Ofcom says that a key element in enabling white = space usage in the TV bands is the definition and provision of a database which, given a device=92s location, can tell the device = which frequency channels and power levels it is able to use without = causing harmful interference to other licensed users in the vicinity. = Ofcom will specify requirements to be met by such geolocation databases. It also says that the technology has the = possibility of being usefully applied elsewhere in the radio spectrum to = ensure it is used to maximum benefit. For example, it may have potential = in making spectrum available for new uses following any switch to digital radio services. Alternatively it may be helpful = in exploiting some of the public sector spectrum holdings. Ofcom will = continue to consider other areas of the radio spectrum where white space = usage may be of benefit.
 
Regards
 
Andy
 
 
From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of scott.probasco@nokia.com
Sent: 26 January 2012 23:43
To: paws@ietf.org
Subject: [paws] = draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt
=
 
Hi,=
 
Revision 2 = of the PS, Use cases and requirements I-D has been posted. Please = see:
 
This version = only includes changes requested by the co-chair in his email of January = 12 h= ttp://www.ietf.org/mail-archive/web/paws/current/msg00516.html 
Specifically:<= o:p>
"
2. = requirements. In the last f2f
we agreed to = modify requirement D.1 to include the suggestions from slide 7-10 ofhttp://www.i= etf.org/proceedings/82/slides/paws-2.pdf and merge with D.6 and D.9
slides = 7&8 of http://www.i= etf.org/proceedings/82/slides/paws-1.pdf also contain = suggestions on how to revise this requirement.
Agreed to = revise requirement D.2 as suggested in slide 11 of http://www.i= etf.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.i= etf.org/proceedings/82/slides/paws-1.pdf
We seem to = have agreed with the reformulation suggested to D.3 in slide 12 ofhttp://www.i= etf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented = in. The data format part is still open, but as this piece does not = really belong to requirements but rather the data model spec, we are not = in a hurry to decide it.
Delete = d.4
D.5: augment = with lower/upper frequencies and time of availability, as suggested on = slide 10 ofhttp://www.i= etf.org/proceedings/82/slides/paws-1.pdf
D.6: change = power to eirp, as suggested in slide 13 of http://www.i= etf.org/proceedings/82/slides/paws-2.pdf.
D.7: change = to single and multiple locations. Clarify that in case of multiple = locations the channel availability for each location should be sent by = the db.
D.8: = delete
"
 
And=
"
Operational = requirements: slides 22-24 of http://www.i= etf.org/proceedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers = them.
"
 
 
Regards,<= /o:p>
Scott & = Raj
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws

= --Apple-Mail=_F2FFDD58-2EB0-4CF8-AF43-832A85D025EC-- From stephen.farrell@cs.tcd.ie Fri Feb 3 01:30:48 2012 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 3C76421F85D6 for ; Fri, 3 Feb 2012 01:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZdhoVKyqrzR for ; Fri, 3 Feb 2012 01:30:47 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 0F08621F85D4 for ; Fri, 3 Feb 2012 01:30:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2B526171C9E; Fri, 3 Feb 2012 09:30:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1328261443; bh=lCoV3 V87TiY5eiCziQm7l7zmqZ6kwRrX10IyhA9kgwU=; b=HifARTR3SWdPYhzJWCpK5 r+nDZ7LejXsVquMxsiFHpltfxmT3nHF/fvIxwdz3agy59/95Fvo0qKkRXruPvtqL +f40S+OPsrPsJKRDf8P5DxpdmnfKY175vh3UuHAjIpSz93B6K5E2ZVjbuynVM1uq HMTeGGgENM5BkkI6bDsPyxjFjGC1W7PmvGHh/FCgTkyKRUrkbZUsgXyLtGyaRtcf brT251LWviYNGz/VLWaVvJbIY5w9ECkoY1p1OgfNcx0ToUmVl96YZgGJv/dkbfqF c/OYg8Hpa/JetdoWRavHUZcC/gZBmBy65EaMmPxoP1f7pU177Ay2Xb4enoYqCT0u w== 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 8hcXs3QgspBV; Fri, 3 Feb 2012 09:30:43 +0000 (GMT) Received: from [10.54.1.167] (mobileinternet4.o2.ie [62.40.32.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C4294171BFD; Fri, 3 Feb 2012 09:30:42 +0000 (GMT) References: <4F2AF6A8.6000106@cs.tcd.ie> <1ECAFF543A2FED4EA2BEB6CACE08E47601DECDCD@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DECDCD@008-AM1MPN1-006.mgdnok.nokia.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <3526E393-D4FF-46B3-B48B-BDBC51F01E21@cs.tcd.ie> X-Mailer: iPhone Mail (9A405) From: Stephen Farrell Date: Fri, 3 Feb 2012 09:30:36 +0000 To: "" Cc: "" Subject: Re: [paws] Threat model (Rev 2) 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, 03 Feb 2012 09:30:48 -0000 On 2 Feb 2012, at 21:39, wrote: > I think that's a different threat from the one addressed below in threat 6= . >=20 > If in a regulatory domain the DB requires the master to provide its identi= ty, then there's nothing to be done to prevent tracking of the masters by th= e DB. But if some other regulatory domain will not require the master to sen= d its identity when querying the DB, the master may decide not to send its i= dentity, to prevent the DB to track it. That's precisely what I think needs to be remembered and taken into account i= n developing the protocol >=20 > We could add this as another threat. Sure, or modify the existing one, I've no strong opinion, S >=20 > - Gabor >=20 >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ex= t Stephen Farrell > Sent: Thursday, February 02, 2012 12:49 PM > To: Patil Basavaraj (Nokia-CIC/Dallas) > Cc: paws@ietf.org > Subject: Re: [paws] Threat model (Rev 2) >=20 >=20 > Pretty good overall. I'll keep on my usual track since I seem stuck on it h= ere;-) >=20 > On 02/02/2012 08:37 PM, Basavaraj.Patil@nokia.com wrote: >>=20 >> Threat 6: Third party tracking of white space device location >>=20 >>=20 >> A master device needs to provide its location to the white >> space database in order to obtain the channel availability >> information at that location. Such location information can be >> gleaned by an eavesdropper. A master device may prefer to keep >> the location information secret. Hence the protocol should >> provide a means to protect the location information and prevent >> tracking of locations associated with a white space database. >=20 > What's wrong with not wanting the DB to track me (as a master device)? Cou= ld be that current known regulators don't like anonymous masters, but that m= ay change. (So I think 3rd party here is wrong.) >=20 > Why is it only location tracking that's of concern? Why is exposing identi= ty not an equal deal? Same logic as above. >=20 >=20 > S. >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From stephen.farrell@cs.tcd.ie Fri Feb 3 01:36:25 2012 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 E306F21F861A for ; Fri, 3 Feb 2012 01:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aX8C7Gc7rAap for ; Fri, 3 Feb 2012 01:36:24 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 44ECD21F8609 for ; Fri, 3 Feb 2012 01:36:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B2094171C9B; Fri, 3 Feb 2012 09:36:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1328261783; bh=CJSJn +TH8NJSwSzF69c9w11IsLVVzBZPSO3CAuxHgv8=; b=eRlK0qL4/IGfxEyPJ8mPz 8D5a0AxJjwv4xKwhO/uvvR5zazxM4YZyndILSBa0bPlFkDDA5xFB0j3/yQWQ0wN3 kw/iBPxrNG/9ZnMeIic2GEvL9kbrwtgum+AuuQ6pzXrYtEtDnpL1FHn9h4O0FkK6 f/XFnPEblmEvbYCS0+oK8sOXL9XIm24TWExgzJWKASIbaZeD3JvKyOitUCGy3wWx sggDaJzOUFq1hPvQfBtNXZ6lBIjo1bilK+YVDkY2x1bcvLxzKaGoull/Ddw9uv2I NMJ8+rbWb2sob84Mfk8SLNiz+iaU4WrATUHDSbL3mpei/e3xERTkJNprWtFIPz9A w== 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 h2WjoMX4Q4B0; Fri, 3 Feb 2012 09:36:23 +0000 (GMT) Received: from [10.54.1.167] (mobileinternet4.o2.ie [62.40.32.14]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9E0C1171BFD; Fri, 3 Feb 2012 09:36:20 +0000 (GMT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (9A405) From: Stephen Farrell Date: Fri, 3 Feb 2012 09:36:11 +0000 To: "" Cc: "" Subject: Re: [paws] Threat model (Rev 2) 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, 03 Feb 2012 09:36:25 -0000 Hi, On 2 Feb 2012, at 20:53, wrote: >=20 >=20 > On 2/2/12 2:48 PM, "ext Stephen Farrell" wrote= : >=20 >>=20 >> Pretty good overall. I'll keep on my usual track since I seem >> stuck on it here;-) >>=20 >> On 02/02/2012 08:37 PM, Basavaraj.Patil@nokia.com wrote: >>>=20 >>> Threat 6: Third party tracking of white space device location >>>=20 >>>=20 >>> A master device needs to provide its location to the white >>> space database in order to obtain the channel availability >>> information at that location. Such location information can be >>> gleaned by an eavesdropper. A master device may prefer to keep >>> the location information secret. Hence the protocol should >>> provide a means to protect the location information and prevent >>> tracking of locations associated with a white space database. >>=20 >> What's wrong with not wanting the DB to track me (as a master >> device)? Could be that current known regulators don't like >> anonymous masters, but that may change. (So I think 3rd party >> here is wrong.) >=20 > The issue is not with the database tracking your location. It is a a > malicious node which could be eavesdropping on the link between the master= > device and the database. The database will always have the master device's= > location. Whether it saves that location is an orthogonal issue, but its > not the one that is captured in this threat. >=20 >>=20 >> Why is it only location tracking that's of concern? Why is >> exposing identity not an equal deal? Same logic as above. >=20 > The concern is not about exposing location of identity to the white space > database. It seems like you're maybe conflating location and identity above, not sure.= But those are different and will need to be differentiated in the protocol,= and hence also in the requirements, S >=20 > -Raj >=20 >=20 >>=20 >>=20 >> S. >>=20 >=20 From andy.sago@bt.com Fri Feb 3 03:16:30 2012 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 ADB5321F8639 for ; Fri, 3 Feb 2012 03:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeXPlyoLE-xO for ; Fri, 3 Feb 2012 03:16:25 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1BC21F85FF for ; Fri, 3 Feb 2012 03:16:24 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Feb 2012 11:16:24 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Fri, 3 Feb 2012 11:16:23 +0000 From: To: , Date: Fri, 3 Feb 2012 11:16:23 +0000 Thread-Topic: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: AcziRytGrklRl588SmeNAt3IXgLs+AAGLQ5Q Message-ID: <619CDADDCCD2B44380834BE8BF6F714140654A1A42@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F714140654A1A42EMV62UKRDdoma_" MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 03 Feb 2012 11:16:30 -0000 --_000_619CDADDCCD2B44380834BE8BF6F714140654A1A42EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scott, Teco Teco makes a good suggestion to amend the US text, for historical accuracy.= Certainly in UK there is no connection between digital switchover and perm= itting white space usage per se, but the two became connected in people's m= inds due to their similar timing. I guess there could be a similar confusio= n in US. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Tec= o Boot Sent: 03 February 2012 07:41 To: scott.probasco@nokia.com Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi Scott, Something like this? WithBesides the switch to digital transmi= ssion for TV, the guard bands that existedexists to protect the signals betw= een stations can now be used for other purposes. Teco Op 2 feb. 2012, om 23:21 heeft > >= het volgende geschreven: Hi Teco, Did you have any text you want to suggest? I guess the text in question is = accurate enough in practical terms, even if it does allow room for discussi= on in theoretical terms. I get your point that white space paradigm applies= regardless of the incumbent radio service. I also believe a thorough discu= ssion of your comment would wander into the realm of radio transmission the= ory and perhaps we could leave that for offline discussion at the next meet= ing :-) Kind Regards, Scott From: ext Teco Boot > Date: Thu, 2 Feb 2012 22:47:35 +0100 To: Scott > Cc: ext com >, "paws@ietf.org" > Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi Scott, It is a pity EU cannot report a straightforward plan for usage of white spa= ces. But steps are taken. The doc has already a ref to ECC Report 159. Minor comment on: With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. I'm not sure this is true. I can't see why analogue broadcasting didn't had= white spaces. Maybe it is just an increased demand on spectrum and the opp= ortunities created with new technology, such as PAWS. Teco Op 2 feb. 2012, om 21:26 heeft > >= het volgende geschreven: Hi Andy, Very good to cover the UK situation also. I support your proposal and plan = to include the new section in the next update, pending any further discussi= on on this thread. Kind Regards, Scott From: ext com > Date: Thu, 2 Feb 2012 19:40:01 +0000 To: Scott >, "paw= s@ietf.org" > Subject: RE: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Scott Section 3 only addresses the US, presumably due to lack of contributions fr= om elsewhere. I propose a couple of short paragraphs to cover the UK situat= ion. The wording is not mine but is almost entirely taken from the latest O= fcom Statement. Section 3.2 is copied below for reference, unchanged, and I propose a new s= ection 3.3, also below: 3.2. Background information on white space in US Television transmission in the United States has moved to the use of digital signals as of June 12, 2009. Since June 13, 2009, all fullpower U.S. television stations have broadcast over-the-air signals in digital only. An important benefit of the switch to all-digital broadcasting is that it freed up parts of the valuable broadcast spectrum. More information about the switch to digital transmission is at : [DTV]. Probasco & Patil Expires July 30, 2012 [Page 8] Internet-Draft PAWS: Problem, uses and requirements January 2012 With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. The FCC has made this spectrum available for unlicensed use and this is generally referred to as white space. Please see the details of the FCC ruling and regulations in [FCC Ruling]. The spectrum can be used to provide wireless broadband as an example. The term "Super-Wifi" is also used to describe this spectrum and potential for providing wifi type of service. 3.3. Background information on white space in UK Since its launch in 2005, Ofcom's Digital Dividend Review [DDR] has conside= red how to make the spectrum freed up by digital switchover available for n= ew uses, including the capacity available within the spectrum that is retai= ned to carry the digital terrestrial television service. Similarly to the U= S, this interleaved or guard spectrum occurs because not all the spectrum i= n any particular location will be used for terrestrial television and so is= available for other services, as long as they can interleave their usage a= round the existing users. In its September 2011 Statement [Ofcom Implementing] Ofcom says that a key = element in enabling white space usage in the TV bands is the definition and= provision of a database which, given a device's location, can tell the dev= ice which frequency channels and power levels it is able to use without cau= sing harmful interference to other licensed users in the vicinity. Ofcom wi= ll specify requirements to be met by such geolocation databases. It also sa= ys that the technology has the possibility of being usefully applied elsewh= ere in the radio spectrum to ensure it is used to maximum benefit. For exam= ple, it may have potential in making spectrum available for new uses follow= ing any switch to digital radio services. Alternatively it may be helpful i= n exploiting some of the public sector spectrum holdings. Ofcom will contin= ue to consider other areas of the radio spectrum where white space usage ma= y be of benefit. Regards Andy From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: 26 January 2012 23:43 To: paws@ietf.org Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi, Revision 2 of the PS, Use cases and requirements I-D has been posted. Pleas= e see: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-02.txt This version only includes changes requested by the co-chair in his email o= f January 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.htm= l Specifically: " 2. requirements. In the last f2f we agreed to modify requirement D.1 to include the suggestions from slide 7= -10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D= .6 and D.9 slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also con= tain suggestions on how to revise this requirement. Agreed to revise requirement D.2 as suggested in slide 11 of http://www.iet= f.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/pr= oceedings/82/slides/paws-1.pdf We seem to have agreed with the reformulation suggested to D.3 in slide 12 = ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agre= e on the format the location would be represented in. The data format part = is still open, but as this piece does not really belong to requirements but= rather the data model spec, we are not in a hurry to decide it. Delete d.4 D.5: augment with lower/upper frequencies and time of availability, as sugg= ested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/= proceedings/82/slides/paws-2.pdf. D.7: change to single and multiple locations. Clarify that in case of multi= ple locations the channel availability for each location should be sent by = the db. D.8: delete " And " Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/8= 2/slides/paws-2.pdf contain suggestions on rewording, I propose the editor = considers them. " Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_619CDADDCCD2B44380834BE8BF6F714140654A1A42EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott, Teco

 

Teco makes a good = suggestion to amend the US text, for historical accuracy. Certainly in UK t= here is no connection between digital switchover and permitting white space= usage per se, but the two became connected in people’s minds due to = their similar timing. I guess there could be a similar confusion in US.

 

Regard= s

 

An= dy

 

From: paws-bounces@ietf.org= [mailto:paws-bounces@ietf.org] On Behalf Of Teco Boot
Sent: 03 February 2012 07:41
To: scott.probasco@nokia.com
Cc:<= /b> paws@ietf.org
Subject: Re: [paws] draft-ietf-paws-problem-stm= t-usecases-rqmts-02.txt

 

Hi Scott,

<= div>

 

Something like this?

=  

<delete>Wit= h</delete><insert>Besides</insert> the switch to digital = transmission for TV, the guard bands that

<delete>existed</delete><= ;insert>exists</insert> to protect the signals between statio= ns can <delete>now </delete>be used for=

oth= er purposes.

=

 

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'>Teco

 

<= /div>

Op 2 feb. 2012, om 23:21 heeft <scott.probasco@nokia.com> &l= t;scott.probasco@nokia.com&= gt; het volgende geschreven:


<= br>

Hi Teco,

 =

Did you have any text you want to = suggest? I guess the text in question is accurate enough in practical = terms, even if it does allow room for discussion in theoretical terms. = ;I get your point that white space paradigm applies regardless of the incum= bent radio service. I also believe a thorough discussion of your comment wo= uld wander into the realm of radio transmission theory and perhaps we could= leave that for offline discussion at the next meeting :-) =

 

Kind Regards,=

Scott

<= /div>

 

From: ext Teco Boot <teco@inf-net.nl>
Date: Th= u, 2 Feb 2012 22:47:35 +0100
To: Scott <scott.probasco@nokia.com>
Cc: ext co= m <andy.sago@bt.com>, "<= a href=3D"mailto:paws@ietf.org">paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] draft= -ietf-paws-problem-stmt-usecases-rqmts-02.txt

 

Hi Scott,

 

It is a pity EU cannot report a straightforward plan for usage of white s= paces. But steps are taken. The doc has already a ref to ECC Report 15= 9.

 

Minor comment on:<= /span>

With the= switch to digital transmission for TV, the guard bands that<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'>

existed to protect the signals between stations can now be used for

o= ther purposes.

= I'm not sure this is true. I can't see why analogue broadcasting didn'= t had white spaces. Maybe it is just an increased demand on spectrum a= nd the opportunities created with new technology, such as PAWS.<= /span>

 

=

Teco

<= p class=3DMsoNormal> 

Op 2 feb. 2012, om 21:26 heeft <scott.probasco@nokia.com> <scott.probasco@nokia.com> het volgende gesch= reven:



Hi Andy,

 

Very good to cover the UK situation also. = I support your proposal and plan to include the new section in the next upd= ate, pending any further discussion on this thread.

 

<= p class=3DMsoNormal>Kind Regards,

Scott

 

= From: ext com <andy.sago@bt.com>
Date: Thu, 2 Feb 2012 19:40:01 +0000<= br>To: Scott <scott.p= robasco@nokia.com>, "paws@ietf= .org" <paws@ietf.org>Subject: RE: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt

 <= /span>

Scott

 

Section 3 only= addresses the US, presumably due to lack of contributions from elsewhere. = I propose a couple of short paragraphs to cover the UK situation. The wordi= ng is not mine but is almost entirely taken from the latest Ofcom Statement= .

 

<= div>

Section 3.2 is copied below for reference, unchanged, and I = propose a new section 3.3, also below:

 

3.2. Background information on white space in US

Te= levision transmission in the United States has moved to the use of

digital signals as of June 12, 2009. Since June 13, 2009, al= l fullpower

U.S. television stations have broadcast o= ver-the-air signals in=

digital only. An important ben= efit of the switch to all-digital

broadcasting is tha= t it freed up parts of the valuable broadcast

spectru= m. More information about the switch to digital transmission

is at : [DTV].=

Probasco & Patil Expires J= uly 30, 2012 [Page 8]<= /p>

Internet-Draft PAWS: Problem, u= ses and requirements January 2012

With the switch to = digital transmission for TV, the guard bands that

exi= sted to protect the signals between stations can now be used for

other purposes. The FCC has made this spectrum available for

unlicensed use and this is generally referred to as whi= te space.

Please see the details of the FCC ruling a= nd regulations in [FCC=

Ruling]. The spectrum can be u= sed to provide wireless broadband as

an example. The = term "Super-Wifi" is also used to describe this

spectrum and potenti= al for providing wifi type of service.

 

<Insert>=

3.3= .  Background information on white space in UK

Since its launch in = 2005, Ofcom’s Digital Dividend Review [DDR] has considered how to mak= e the spectrum freed up by digital switchover available for new uses, inclu= ding the capacity available within the spectrum that is retained to carry t= he digital terrestrial television service. Similarly to the US, this interl= eaved or guard spectrum occurs because not all the spectrum in any particul= ar location will be used for terrestrial television and so is available for= other services, as long as they can interleave their usage around the exis= ting users.

=

 =

In its September 2011 Statement [Ofcom Implementi= ng] Ofcom says that a key element in enabling white space usage in the TV b= ands is the definition and provision of a database which, given a device= 217;s location, can tell the device which frequency channels and power leve= ls it is able to use without causing harmful interference to other licensed= users in the vicinity. Ofcom will specify requirements to be met by such g= eolocation databases. It also says that the technology has the possibility = of being usefully applied elsewhere in the radio spectrum to ensure it is u= sed to maximum benefit. For example, it may have potential in making spectr= um available for new uses following any switch to digital radio services. A= lternatively it may be helpful in exploiting some of the public sector spec= trum holdings. Ofcom will continue to consider other areas of the radio spe= ctrum where white space usage may be of benefit.

</Insert>

&n= bsp;

Regards

 

Andy

 

 

From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: 26 January 2012 23:43
To: paws@ietf.org
Subject: [paws] draft-ietf-paws-problem-st= mt-usecases-rqmts-02.txt

 

Hi,

 =

Revision 2 of the PS, Use case= s and requirements I-D has been posted. Please see:

<= div>

 =

This version only includes changes re= quested by the co-chair in his email of January 12 http://www.ietf.or= g/mail-archive/web/paws/current/msg00516.html 

Sp= ecifically:

<= /div>

"

<= div>

2. requirements. In the last = f2f

we agreed to modify requirement D.1 to include the sugge= stions from slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf&nbs= p;and merge with D.6 and D.9<= /span>

slides 7&8 of http://www.ietf.o= rg/proceedings/82/slides/paws-1.pdf also contain suggestions on ho= w to revise this requirement.=

Agreed to revise requirement D= .2 as suggested in slide 11 of http://www.ietf.org/proceedings/82/slides/paws-2.= pdfand slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf

We seem to have agreed with the reformulation suggested to D.= 3 in slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did = not agree on the format the location would be represented in. The data form= at part is still open, but as this piece does not really belong to requirem= ents but rather the data model spec, we are not in a hurry to decide it.

Delete d.4

D.5: augment with lower/upper freque= ncies and time of availability, as suggested on slide 10 ofhttp://www.ietf.org/procee= dings/82/slides/paws-1.pdf

D.6: change power to eirp, as= suggested in slide 13 of http://www.ietf.org/proceedings/82/slides/paws-2.pdf.

D.7: change to single and multiple locations. Clarify th= at in case of multiple locations the channel availability for each location= should be sent by the db.

Operational requirements: slides 22-24 of http://www.i= etf.org/proceedings/82/slides/paws-2.pdf contain suggestions on re= wording, I propose the editor considers them.

=

"

 <= /span>

 <= /p>

Regards,

Scott & Ra= j

____________= ___________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 

 

= --_000_619CDADDCCD2B44380834BE8BF6F714140654A1A42EMV62UKRDdoma_-- From scott.probasco@nokia.com Fri Feb 3 09:11:24 2012 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 51EA021F859E for ; Fri, 3 Feb 2012 09:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7AqRrkS7wCY for ; Fri, 3 Feb 2012 09:11:22 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7475421F84D5 for ; Fri, 3 Feb 2012 09:11:22 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13HB8uH001279; Fri, 3 Feb 2012 19:11:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 19:11:07 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 18:11:06 +0100 From: To: , , Thread-Topic: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: AQHM4fRNM6PQoXlBZEKtd2pq8c01upYpuJ4AgAEA7QCAADxOgP///oOA Date: Fri, 3 Feb 2012 17:11:05 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140654A1A42@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: multipart/alternative; boundary="_000_CB5170C710285scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 17:11:07.0761 (UTC) FILETIME=[D1AC6610:01CCE296] X-Nokia-AV: Clean Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 03 Feb 2012 17:11:24 -0000 --_000_CB5170C710285scottprobasconokiacom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Thank you Teco and Andy for the comments. I will include the proposed text = in the next version, assuming no conflicting comments to the thread. Kind Regards, Scott From: ext com > Date: Fri, 3 Feb 2012 11:16:23 +0000 To: >, Scott > Cc: "paws@ietf.org" > Subject: RE: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Scott, Teco Teco makes a good suggestion to amend the US text, for historical accuracy.= Certainly in UK there is no connection between digital switchover and perm= itting white space usage per se, but the two became connected in people=92s= minds due to their similar timing. I guess there could be a similar confus= ion in US. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Teco Boot Sent: 03 February 2012 07:41 To: scott.probasco@nokia.com Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi Scott, Something like this? WithBesides the switch to digital transmi= ssion for TV, the guard bands that existedexists to protect the signals betw= een stations can now be used for other purposes. Teco Op 2 feb. 2012, om 23:21 heeft > >= het volgende geschreven: Hi Teco, Did you have any text you want to suggest? I guess the text in question is = accurate enough in practical terms, even if it does allow room for discussi= on in theoretical terms. I get your point that white space paradigm applies= regardless of the incumbent radio service. I also believe a thorough discu= ssion of your comment would wander into the realm of radio transmission the= ory and perhaps we could leave that for offline discussion at the next meet= ing :-) Kind Regards, Scott From: ext Teco Boot > Date: Thu, 2 Feb 2012 22:47:35 +0100 To: Scott > Cc: ext com >, "paws@ietf.org" > Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi Scott, It is a pity EU cannot report a straightforward plan for usage of white spa= ces. But steps are taken. The doc has already a ref to ECC Report 159. Minor comment on: With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. I'm not sure this is true. I can't see why analogue broadcasting didn't had= white spaces. Maybe it is just an increased demand on spectrum and the opp= ortunities created with new technology, such as PAWS. Teco Op 2 feb. 2012, om 21:26 heeft > >= het volgende geschreven: Hi Andy, Very good to cover the UK situation also. I support your proposal and plan = to include the new section in the next update, pending any further discussi= on on this thread. Kind Regards, Scott From: ext com > Date: Thu, 2 Feb 2012 19:40:01 +0000 To: Scott >, "paw= s@ietf.org" > Subject: RE: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Scott Section 3 only addresses the US, presumably due to lack of contributions fr= om elsewhere. I propose a couple of short paragraphs to cover the UK situat= ion. The wording is not mine but is almost entirely taken from the latest O= fcom Statement. Section 3.2 is copied below for reference, unchanged, and I propose a new s= ection 3.3, also below: 3.2. Background information on white space in US Television transmission in the United States has moved to the use of digital signals as of June 12, 2009. Since June 13, 2009, all fullpower U.S. television stations have broadcast over-the-air signals in digital only. An important benefit of the switch to all-digital broadcasting is that it freed up parts of the valuable broadcast spectrum. More information about the switch to digital transmission is at : [DTV]. Probasco & Patil Expires July 30, 2012 [Page 8] Internet-Draft PAWS: Problem, uses and requirements January 2012 With the switch to digital transmission for TV, the guard bands that existed to protect the signals between stations can now be used for other purposes. The FCC has made this spectrum available for unlicensed use and this is generally referred to as white space. Please see the details of the FCC ruling and regulations in [FCC Ruling]. The spectrum can be used to provide wireless broadband as an example. The term "Super-Wifi" is also used to describe this spectrum and potential for providing wifi type of service. 3.3. Background information on white space in UK Since its launch in 2005, Ofcom=92s Digital Dividend Review [DDR] has consi= dered how to make the spectrum freed up by digital switchover available for= new uses, including the capacity available within the spectrum that is ret= ained to carry the digital terrestrial television service. Similarly to the= US, this interleaved or guard spectrum occurs because not all the spectrum= in any particular location will be used for terrestrial television and so = is available for other services, as long as they can interleave their usage= around the existing users. In its September 2011 Statement [Ofcom Implementing] Ofcom says that a key = element in enabling white space usage in the TV bands is the definition and= provision of a database which, given a device=92s location, can tell the d= evice which frequency channels and power levels it is able to use without c= ausing harmful interference to other licensed users in the vicinity. Ofcom = will specify requirements to be met by such geolocation databases. It also = says that the technology has the possibility of being usefully applied else= where in the radio spectrum to ensure it is used to maximum benefit. For ex= ample, it may have potential in making spectrum available for new uses foll= owing any switch to digital radio services. Alternatively it may be helpful= in exploiting some of the public sector spectrum holdings. Ofcom will cont= inue to consider other areas of the radio spectrum where white space usage = may be of benefit. Regards Andy From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: 26 January 2012 23:43 To: paws@ietf.org Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Hi, Revision 2 of the PS, Use cases and requirements I-D has been posted. Pleas= e see: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-02.txt This version only includes changes requested by the co-chair in his email o= f January 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.htm= l Specifically: " 2. requirements. In the last f2f we agreed to modify requirement D.1 to include the suggestions from slide 7= -10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D= .6 and D.9 slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also con= tain suggestions on how to revise this requirement. Agreed to revise requirement D.2 as suggested in slide 11 of http://www.iet= f.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/pr= oceedings/82/slides/paws-1.pdf We seem to have agreed with the reformulation suggested to D.3 in slide 12 = ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agre= e on the format the location would be represented in. The data format part = is still open, but as this piece does not really belong to requirements but= rather the data model spec, we are not in a hurry to decide it. Delete d.4 D.5: augment with lower/upper frequencies and time of availability, as sugg= ested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf D.6: change power to eirp, as suggested in slide 13 of http://www.ietf.org/= proceedings/82/slides/paws-2.pdf. D.7: change to single and multiple locations. Clarify that in case of multi= ple locations the channel availability for each location should be sent by = the db. D.8: delete " And " Operational requirements: slides 22-24 of http://www.ietf.org/proceedings/8= 2/slides/paws-2.pdf contain suggestions on rewording, I propose the editor = considers them. " Regards, Scott & Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CB5170C710285scottprobasconokiacom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <267F9B9EFE62EB4593FB6981802F2481@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi,

This does not include any acknowledgement. This is = something we do support in our FCC protocol. The reason being so we can acc= urately inform the device if the registration attempt fails. Listed below a= re some of the reasons, though I am sure there are more, we consider return= ing a failure code to the device:

malformed request (e.g= ., required fields missing)
FCC identifier not recognized or supp= orted
FCC designated no channels available
location out= side of regulatory domain
antenna height above 30 meters
HAAT above 76 meters

Thank you Teco and Andy for the comments. I will include the proposed = text in the next version, assuming no conflicting comments to the thread.

Kind Regards,
Scott

From: ext com <andy.sago@bt.com>
Date: Fri, 3 Feb 2012 11:16:23 += ;0000
To: <teco@inf-net.nl>, Scott <scott.probasco@nokia.com>
Cc: "paws@ietf.org" <paws@i= etf.org>
Subject: RE: [paws] draft-ietf-paws= -problem-stmt-usecases-rqmts-02.txt

Scott, Teco

 

Teco makes a good suggestion to amend the US text, = for historical accuracy. Certainly in UK there is no connection between dig= ital switchover and permitting white space usage per se, but the two became connected in people=92s minds due t= o their similar timing. I guess there could be a similar confusion in US.

 

Regards

 

Andy

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Teco Boot
Sent: 03 February 2012 07:41
To: scott.probasco@nokia= .com
Cc: paws@ietf.org
Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.t= xt

 

Hi Scott,

 

Something like this?

 

<delete>With</delete><insert>Besides</ins= ert> the switch to digital transmission for TV, the guard bands that

<delete><= span style=3D"font-size:10.0pt;font-family:Courier;color:black">existed</delete><insert>exists</insert= > to protect the signals between stations can <delete>now </= delete>be used for<= /span>

other purposes.<= /span>

 =

Teco

 

Op 2 feb. 2012, om 23:21 heeft <scott.probasco@nokia.com> <scott.probasco@nokia.com> het volge= nde geschreven:



Hi Teco,

 

Did you have any text you want to suggest?&= nbsp;I guess the text in question is accurate enough in practical terms, ev= en if it does allow room for discussion in theoretical terms. I get your point that white space paradigm applies= regardless of the incumbent radio service. I also believe a thorough discu= ssion of your comment would wander into the realm of radio transmission the= ory and perhaps we could leave that for offline discussion at the next meeting :-) 

 

Kind Regards,

Scott

 

From: ext Teco Boot <teco= @inf-net.nl>
Date: Thu, 2 Feb 2012 22:47:35 +0100
To: Scott <scott.prob= asco@nokia.com>
Cc: ext com <andy.sago@bt.com= >, "paws@ietf.org" &l= t;paws@ietf.org>
Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.t= xt

 

Hi Scott,

 

It is a pity EU cannot report a straightfor= ward plan for usage of white spaces. But steps are taken. The doc has alrea= dy a ref to ECC Report 159.

 

Minor comment on:

With the switch to digital tr= ansmission for TV, the guard bands that

existed to protect the signals between stations can now be use= d for

other purposes.<= /span>

I'm not sure this is true. I can't see why = analogue broadcasting didn't had white spaces. Maybe it is just an inc= reased demand on spectrum and the opportunities created with new technology, such as PAWS.

 

Teco

 

Op 2 feb. 2012, om 21:26 heeft <scott.probasco@nokia.com> <<= a href=3D"mailto:scott.probasco@nokia.com">scott.probasco@nokia.com> het volgende geschreven:



Hi Andy,

 

Very good to cover the UK situation also. I= support your proposal and plan to include the new section in the next upda= te, pending any further discussion on this thread.

 

Kind Regards,

Scott

 

From: ext com <andy.sago= @bt.com>
Date: Thu, 2 Feb 2012 19:40:01 +0000
To: Scott <scott.prob= asco@nokia.com>, "paws@ietf.or= g" <paws@ietf.org>
Subject: RE: draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt

 

Scott=

 

Section 3 only addresses the US, presumably due to = lack of contributions from elsewhere. I propose a couple of short paragraph= s to cover the UK situation. The wording is not mine but is almost entirely taken from the latest Ofcom Statement.<= /span>

 

Section 3.2 is copied below for reference, unchange= d, and I propose a new section 3.3, also below:

 

3.2. Background information on w= hite space in US

Television transmission in the U= nited States has moved to the use of

digital signals as of June 12, 2= 009. Since June 13, 2009, all fullpower<= o:p>

U.S. television stations have br= oadcast over-the-air signals in

digital only. An important benef= it of the switch to all-digital

broadcasting is that it freed up= parts of the valuable broadcast

spectrum. More information about= the switch to digital transmission=

is at : [DTV].

Probasco & Patil Expires Jul= y 30, 2012 [Page 8]

Internet-Draft PAWS: Problem, us= es and requirements January 2012

With the switch to digital trans= mission for TV, the guard bands that

existed to protect the signals b= etween stations can now be used for=

other purposes. The FCC has made= this spectrum available for<= /span>

unlicensed use and this is gener= ally referred to as white space.

Please see the details of the FC= C ruling and regulations in [FCC

Ruling]. The spectrum can be use= d to provide wireless broadband as<= /o:p>

an example. The term "Super= -Wifi" is also used to describe this

spectrum and potential for providing wifi type of service.

 

<Insert>

3.3.  Background information on white space in= UK

Since its launch in 2005, Ofcom=92s Digital Dividen= d Review [DDR] has considered how to make the spectrum freed up by digital = switchover available for new uses, including the capacity available within the spectrum that is retained to carry the d= igital terrestrial television service. Similarly to the US, this interleave= d or guard spectrum occurs because not all the spectrum in any particular l= ocation will be used for terrestrial television and so is available for other services, as long as they can int= erleave their usage around the existing users.

 

In its September 2011 Statement [Ofcom Implementing= ] Ofcom says that a key element in enabling white space usage in the TV ban= ds is the definition and provision of a database which, given a device=92s location, can tell the device which f= requency channels and power levels it is able to use without causing harmfu= l interference to other licensed users in the vicinity. Ofcom will specify = requirements to be met by such geolocation databases. It also says that the technology has the possibility of being u= sefully applied elsewhere in the radio spectrum to ensure it is used to max= imum benefit. For example, it may have potential in making spectrum availab= le for new uses following any switch to digital radio services. Alternatively it may be helpful in exploiting s= ome of the public sector spectrum holdings. Ofcom will continue to consider= other areas of the radio spectrum where white space usage may be of benefi= t.

</Insert><= o:p>

 

Regards

 

Andy<= /span>

 

 

From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of scott.probasco@nokia.com
Sent: 26 January 2012 23:43
To: paws@ietf.org
Subject: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt

 =

Hi,

 

Revision 2 of the PS, Use cases and requirements I-D has been= posted. Please see:

 

This version only includes changes requested by the co-chair = in his email of January 12 http://www.ietf.org/mail-archive/web/paws/= current/msg00516.html 

Specifically:

"

2. requirements. In the last f2f

we agreed to modify requirement D.1 to include the suggestion= s from slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D.6 and D.9

slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1= .pdf also contain suggestions on how to revise this requirement.

Agreed to revise requirement D.2 as suggested in slide 11 of&= nbsp;http:= //www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf

We seem to have agreed with the reformulation suggested to D.= 3 in slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented in. T= he data format part is still open, but as this piece does not really belong= to requirements but rather the data model spec, we are not in a hurry to d= ecide it.

Delete d.4

D.5: augment with lower/upper frequencies and time of availab= ility, as suggested on slide 10 ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pd= f

D.6: change power to eirp, as suggested in slide 13 of <= a href=3D"http://www.ietf.org/proceedings/82/slides/paws-2.pdf">http://www.= ietf.org/proceedings/82/slides/paws-2.pdf.

D.7: change to single and multiple locations. Clarify that in= case of multiple locations the channel availability for each location shou= ld be sent by the db.<= /p>

D.8: delete

"

 

And

"

Operational requirements: slides 22-24 of http://www.ietf.org/proc= eedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers them.

"

 

 

Regards,=

Scott & Raj=

___________________________________________= ____
paws mailing list
paws@ietf.org
https://www.ietf.org= /mailman/listinfo/paws

 

 

 --_000_CB5170C710285scottprobasconokiacom_-- From budden@nps.edu Fri Feb 3 09:23:16 2012 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 29FF021F84E2 for ; Fri, 3 Feb 2012 09:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fv++e2l3vghl for ; Fri, 3 Feb 2012 09:23:15 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id CA48621F84B9 for ; Fri, 3 Feb 2012 09:23:14 -0800 (PST) X-ASG-Debug-ID: 1328289793-036c920f20d1770001-Z0ZA9G Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id Sn2uHcOQASN1tiqX; Fri, 03 Feb 2012 09:23:13 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 09:23:13 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt To: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140654A1A42@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F714140654A1A42@EMV62-UKRD.domain1.systemhost.net> Content-Type: text/plain; charset="UTF-8" Date: Fri, 3 Feb 2012 09:22:36 -0800 Message-ID: <1328289756.9169.1870.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1328289793 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.87501 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 03 Feb 2012 17:23:16 -0000 It might be useful to get your head out of _TV_ white space for a minute and generalize. In the VHF band there are lots of 15kHz slivers of licensed. Similar in the 700/800MHz band for emergency services (also licensed). FWIW, the county where I live has over 200 VHF channel licenses. There are two trends being pushed in these parts of the spectrum: - 'narrowbanding' by reissuing the 15kHz slivers as even smaller ~7kHz sliverettes. This of course, perpetuates narrowband (as in Land Mobile Radio) and squeezes more efficiency out. The facts of life are that a lot of these channels are vacant a lot of the time. - recycling the spectrum by withdrawing the narrowband licenses entirely so they can be issued in the 5/10MHz slabs that IEEE 802.16 and LTE like. There's a big debate about the spectrum allocation in the 700MHz block and a lot of confused conversation in the emergency services comms world where they seem to want both broadband spectrum _and_ lots of narrowband channels. But the crux is whether the law or regulation states whether the 700MHz emergency services channels will be for _exclusive_ emergency services use or not. (Within that is the debate over just what constitutes emergency services ... one of my contacts in Wyoming insists that snowplows are). If non-exclusive, then there may be considerable value to whitespace recycling ability here. On Fri, 2012-02-03 at 11:16 +0000, andy.sago@bt.com wrote: > Scott, Teco > > > > Teco makes a good suggestion to amend the US text, for historical > accuracy. Certainly in UK there is no connection between digital > switchover and permitting white space usage per se, but the two became > connected in people’s minds due to their similar timing. I guess there > could be a similar confusion in US. > > > > Regards > > > > Andy > > > > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > Of Teco Boot > Sent: 03 February 2012 07:41 > To: scott.probasco@nokia.com > Cc: paws@ietf.org > Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > > > > > Hi Scott, > > > > > Something like this? > > > > > > WithBesides the switch to digital > transmission for TV, the guard bands that > > > existedexists to protect the signals > between stations can now be used for > > > other purposes. > > > > > > Teco > > > > > > Op 2 feb. 2012, om 23:21 heeft > het volgende geschreven: > > > > > Hi Teco, > > > > > > Did you have any text you want to suggest? I guess the text in > question is accurate enough in practical terms, even if it does allow > room for discussion in theoretical terms. I get your point that white > space paradigm applies regardless of the incumbent radio service. I > also believe a thorough discussion of your comment would wander into > the realm of radio transmission theory and perhaps we could leave that > for offline discussion at the next meeting :-) > > > > > > Kind Regards, > > > Scott > > > > > > From: ext Teco Boot > Date: Thu, 2 Feb 2012 22:47:35 +0100 > To: Scott > Cc: ext com , "paws@ietf.org" > > Subject: Re: [paws] > draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > > > > > > Hi Scott, > > > > > It is a pity EU cannot report a straightforward plan for usage > of white spaces. But steps are taken. The doc has already a > ref to ECC Report 159. > > > > > Minor comment on: > > > With the switch to digital transmission for TV, the > guard bands that > > > existed to protect the signals between stations can > now be used for > > > other purposes. > > > I'm not sure this is true. I can't see why analogue > broadcasting didn't had white spaces. Maybe it is just an > increased demand on spectrum and the opportunities created > with new technology, such as PAWS. > > > > > > Teco > > > > > Op 2 feb. 2012, om 21:26 heeft > het volgende geschreven: > > > > > Hi Andy, > > > > > > Very good to cover the UK situation also. I support your > proposal and plan to include the new section in the next > update, pending any further discussion on this thread. > > > > > > Kind Regards, > > > Scott > > > > > > From: ext com > Date: Thu, 2 Feb 2012 19:40:01 +0000 > To: Scott , "paws@ietf.org" > > Subject: RE: > draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > > > > > > Scott > > > > > > Section 3 only addresses the US, presumably due to lack of > contributions from elsewhere. I propose a couple of short > paragraphs to cover the UK situation. The wording is not mine > but is almost entirely taken from the latest Ofcom Statement. > > > > > > Section 3.2 is copied below for reference, unchanged, and I > propose a new section 3.3, also below: > > > > > > 3.2. Background information on white space in US > > Television transmission in the United States has moved to the > use of > > digital signals as of June 12, 2009. Since June 13, 2009, all > fullpower > > U.S. television stations have broadcast over-the-air signals > in > > digital only. An important benefit of the switch to > all-digital > > broadcasting is that it freed up parts of the valuable > broadcast > > spectrum. More information about the switch to digital > transmission > > is at : [DTV]. > > Probasco & Patil Expires July 30, 2012 [Page 8] > > Internet-Draft PAWS: Problem, uses and requirements January > 2012 > > With the switch to digital transmission for TV, the guard > bands that > > existed to protect the signals between stations can now be > used for > > other purposes. The FCC has made this spectrum available for > > unlicensed use and this is generally referred to as white > space. > > Please see the details of the FCC ruling and regulations in > [FCC > > Ruling]. The spectrum can be used to provide wireless > broadband as > > an example. The term "Super-Wifi" is also used to describe > this > > spectrum and potential for providing wifi type of service. > > > > > > > > > 3.3. Background information on white space in UK > > > Since its launch in 2005, Ofcom’s Digital Dividend Review > [DDR] has considered how to make the spectrum freed up by > digital switchover available for new uses, including the > capacity available within the spectrum that is retained to > carry the digital terrestrial television service. Similarly to > the US, this interleaved or guard spectrum occurs because not > all the spectrum in any particular location will be used for > terrestrial television and so is available for other services, > as long as they can interleave their usage around the existing > users. > > > > > > In its September 2011 Statement [Ofcom Implementing] Ofcom > says that a key element in enabling white space usage in the > TV bands is the definition and provision of a database which, > given a device’s location, can tell the device which frequency > channels and power levels it is able to use without causing > harmful interference to other licensed users in the vicinity. > Ofcom will specify requirements to be met by such geolocation > databases. It also says that the technology has the > possibility of being usefully applied elsewhere in the radio > spectrum to ensure it is used to maximum benefit. For example, > it may have potential in making spectrum available for new > uses following any switch to digital radio services. > Alternatively it may be helpful in exploiting some of the > public sector spectrum holdings. Ofcom will continue to > consider other areas of the radio spectrum where white space > usage may be of benefit. > > > > > > > > > Regards > > > > > > Andy > > > > > > > > > From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > Behalf Of scott.probasco@nokia.com > Sent: 26 January 2012 23:43 > To: paws@ietf.org > Subject: [paws] > draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > > > > > > Hi, > > > > > > Revision 2 of the PS, Use cases and requirements I-D has been > posted. Please see: > > > http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > > > > > > This version only includes changes requested by the co-chair > in his email of January > 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.html > > > Specifically: > > > " > > > 2. requirements. In the last f2f > > > we agreed to modify requirement D.1 to include the > suggestions from slide 7-10 > ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D.6 and D.9 > > > slides 7&8 > of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also contain suggestions on how to revise this requirement. > > > Agreed to revise requirement D.2 as suggested in slide > 11 > of http://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf > > > We seem to have agreed with the reformulation > suggested to D.3 in slide 12 > ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented in. The data format part is still open, but as this piece does not really belong to requirements but rather the data model spec, we are not in a hurry to decide it. > > > Delete d.4 > > > D.5: augment with lower/upper frequencies and time of > availability, as suggested on slide 10 > ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf > > > D.6: change power to eirp, as suggested in slide 13 > of http://www.ietf.org/proceedings/82/slides/paws-2.pdf. > > > D.7: change to single and multiple locations. Clarify > that in case of multiple locations the channel > availability for each location should be sent by the > db. > > > D.8: delete > > > " > > > > > > And > > > " > > > Operational requirements: slides 22-24 > of http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers them. > > > " > > > > > > > > > Regards, > > > Scott & Raj > > > _______________________________________________ > 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 Fri Feb 3 09:51:44 2012 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 C490421F855E for ; Fri, 3 Feb 2012 09:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.978 X-Spam-Level: X-Spam-Status: No, score=-5.978 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMP1eVexMhTh for ; Fri, 3 Feb 2012 09:51:43 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8ED21F855A for ; Fri, 3 Feb 2012 09:51:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1328291502; x=1643648665; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ctg3lmRERi+4Yj9MQCbPj QYy0bvGCb8L0mRbDrIVHl4=; b=gUnMeQASTnrDhZVSjsjkPLaksFrBjGo6HPHjZ v5r0hTMMsISnOmu6EEwSOLQX/F6uh6iwv1O7fmjS4vD8fxM1Q== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.3277779; Fri, 03 Feb 2012 12:51:41 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Fri, 3 Feb 2012 12:51:35 -0500 From: "Rosen, Brian" To: Rex Buddenberg Date: Fri, 3 Feb 2012 12:51:33 -0500 Thread-Topic: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: AczinHguw8sl/rytQNeRIg8rKgWmRg== Message-ID: References: <619CDADDCCD2B44380834BE8BF6F714140654A1A42@EMV62-UKRD.domain1.systemhost.net> <1328289756.9169.1870.camel@localhost.localdomain> In-Reply-To: <1328289756.9169.1870.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: On/kwinpu8+o0aViybi0QQ== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 03 Feb 2012 17:51:44 -0000 Rex I know whereof you speak. But, is there some use case, or requirement that= might arise out of this, which would help our work? We can't reasonably ask the database to react to, for example, Push to Talk= reservations - use has to be on a much more granular time scale. Regardle= ss of how the spectrum is sliced and diced, our basic paradigm of query the= database with your location, and it responds with what spectrum you can us= e, seems to apply to this use as well as TVBWS. Brian On Feb 3, 2012, at 12:22 PM, Rex Buddenberg wrote: > It might be useful to get your head out of _TV_ white space for a minute > and generalize. >=20 > In the VHF band there are lots of 15kHz slivers of licensed. Similar in > the 700/800MHz band for emergency services (also licensed). FWIW, the > county where I live has over 200 VHF channel licenses. There are two > trends being pushed in these parts of the spectrum: > - 'narrowbanding' by reissuing the 15kHz slivers as even smaller ~= 7kHz > sliverettes. This of course, perpetuates narrowband (as in Land Mobile > Radio) and squeezes more efficiency out. The facts of life are that a > lot of these channels are vacant a lot of the time. > - recycling the spectrum by withdrawing the narrowband licenses > entirely so they can be issued in the 5/10MHz slabs that IEEE 802.16 and > LTE like. There's a big debate about the spectrum allocation in the > 700MHz block and a lot of confused conversation in the emergency > services comms world where they seem to want both broadband spectrum > _and_ lots of narrowband channels. But the crux is whether the law or > regulation states whether the 700MHz emergency services channels will be > for _exclusive_ emergency services use or not. (Within that is the > debate over just what constitutes emergency services ... one of my > contacts in Wyoming insists that snowplows are). If non-exclusive, then > there may be considerable value to whitespace recycling ability here. >=20 >=20 >=20 > On Fri, 2012-02-03 at 11:16 +0000, andy.sago@bt.com wrote: >> Scott, Teco >>=20 >>=20 >>=20 >> Teco makes a good suggestion to amend the US text, for historical >> accuracy. Certainly in UK there is no connection between digital >> switchover and permitting white space usage per se, but the two became >> connected in people=92s minds due to their similar timing. I guess there >> could be a similar confusion in US. >>=20 >>=20 >>=20 >> Regards >>=20 >>=20 >>=20 >> Andy >>=20 >>=20 >>=20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >> Of Teco Boot >> Sent: 03 February 2012 07:41 >> To: scott.probasco@nokia.com >> Cc: paws@ietf.org >> Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >>=20 >>=20 >>=20 >>=20 >> Hi Scott, >>=20 >>=20 >>=20 >>=20 >> Something like this? >>=20 >>=20 >>=20 >>=20 >>=20 >> WithBesides the switch to digital >> transmission for TV, the guard bands that >>=20 >>=20 >> existedexists to protect the signals >> between stations can now be used for >>=20 >>=20 >> other purposes. >>=20 >>=20 >>=20 >>=20 >>=20 >> Teco >>=20 >>=20 >>=20 >>=20 >>=20 >> Op 2 feb. 2012, om 23:21 heeft >> het volgende geschreven: >>=20 >>=20 >>=20 >>=20 >> Hi Teco, >>=20 >>=20 >>=20 >>=20 >>=20 >> Did you have any text you want to suggest? I guess the text in >> question is accurate enough in practical terms, even if it does allow >> room for discussion in theoretical terms. I get your point that white >> space paradigm applies regardless of the incumbent radio service. I >> also believe a thorough discussion of your comment would wander into >> the realm of radio transmission theory and perhaps we could leave that >> for offline discussion at the next meeting :-) >>=20 >>=20 >>=20 >>=20 >>=20 >> Kind Regards, >>=20 >>=20 >> Scott >>=20 >>=20 >>=20 >>=20 >>=20 >> From: ext Teco Boot >> Date: Thu, 2 Feb 2012 22:47:35 +0100 >> To: Scott >> Cc: ext com , "paws@ietf.org" >> >> Subject: Re: [paws] >> draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >>=20 >>=20 >>=20 >>=20 >>=20 >> Hi Scott, >>=20 >>=20 >>=20 >>=20 >> It is a pity EU cannot report a straightforward plan for usage >> of white spaces. But steps are taken. The doc has already a >> ref to ECC Report 159. >>=20 >>=20 >>=20 >>=20 >> Minor comment on: >>=20 >>=20 >> With the switch to digital transmission for TV, the >> guard bands that >>=20 >>=20 >> existed to protect the signals between stations can >> now be used for >>=20 >>=20 >> other purposes. >>=20 >>=20 >> I'm not sure this is true. I can't see why analogue >> broadcasting didn't had white spaces. Maybe it is just an >> increased demand on spectrum and the opportunities created >> with new technology, such as PAWS. >>=20 >>=20 >>=20 >>=20 >>=20 >> Teco >>=20 >>=20 >>=20 >>=20 >> Op 2 feb. 2012, om 21:26 heeft >> het volgende geschreven: >>=20 >>=20 >>=20 >>=20 >> Hi Andy, >>=20 >>=20 >>=20 >>=20 >>=20 >> Very good to cover the UK situation also. I support your >> proposal and plan to include the new section in the next >> update, pending any further discussion on this thread. >>=20 >>=20 >>=20 >>=20 >>=20 >> Kind Regards, >>=20 >>=20 >> Scott >>=20 >>=20 >>=20 >>=20 >>=20 >> From: ext com >> Date: Thu, 2 Feb 2012 19:40:01 +0000 >> To: Scott , "paws@ietf.org" >> >> Subject: RE: >> draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >>=20 >>=20 >>=20 >>=20 >>=20 >> Scott >>=20 >>=20 >>=20 >>=20 >>=20 >> Section 3 only addresses the US, presumably due to lack of >> contributions from elsewhere. I propose a couple of short >> paragraphs to cover the UK situation. The wording is not mine >> but is almost entirely taken from the latest Ofcom Statement. >>=20 >>=20 >>=20 >>=20 >>=20 >> Section 3.2 is copied below for reference, unchanged, and I >> propose a new section 3.3, also below: >>=20 >>=20 >>=20 >>=20 >>=20 >> 3.2. Background information on white space in US >>=20 >> Television transmission in the United States has moved to the >> use of >>=20 >> digital signals as of June 12, 2009. Since June 13, 2009, all >> fullpower >>=20 >> U.S. television stations have broadcast over-the-air signals >> in >>=20 >> digital only. An important benefit of the switch to >> all-digital >>=20 >> broadcasting is that it freed up parts of the valuable >> broadcast >>=20 >> spectrum. More information about the switch to digital >> transmission >>=20 >> is at : [DTV]. >>=20 >> Probasco & Patil Expires July 30, 2012 [Page 8] >>=20 >> Internet-Draft PAWS: Problem, uses and requirements January >> 2012 >>=20 >> With the switch to digital transmission for TV, the guard >> bands that >>=20 >> existed to protect the signals between stations can now be >> used for >>=20 >> other purposes. The FCC has made this spectrum available for >>=20 >> unlicensed use and this is generally referred to as white >> space. >>=20 >> Please see the details of the FCC ruling and regulations in >> [FCC >>=20 >> Ruling]. The spectrum can be used to provide wireless >> broadband as >>=20 >> an example. The term "Super-Wifi" is also used to describe >> this >>=20 >> spectrum and potential for providing wifi type of service. >>=20 >>=20 >>=20 >>=20 >>=20 >> >>=20 >>=20 >> 3.3. Background information on white space in UK >>=20 >>=20 >> Since its launch in 2005, Ofcom=92s Digital Dividend Review >> [DDR] has considered how to make the spectrum freed up by >> digital switchover available for new uses, including the >> capacity available within the spectrum that is retained to >> carry the digital terrestrial television service. Similarly to >> the US, this interleaved or guard spectrum occurs because not >> all the spectrum in any particular location will be used for >> terrestrial television and so is available for other services, >> as long as they can interleave their usage around the existing >> users. >>=20 >>=20 >>=20 >>=20 >>=20 >> In its September 2011 Statement [Ofcom Implementing] Ofcom >> says that a key element in enabling white space usage in the >> TV bands is the definition and provision of a database which, >> given a device=92s location, can tell the device which frequency >> channels and power levels it is able to use without causing >> harmful interference to other licensed users in the vicinity. >> Ofcom will specify requirements to be met by such geolocation >> databases. It also says that the technology has the >> possibility of being usefully applied elsewhere in the radio >> spectrum to ensure it is used to maximum benefit. For example, >> it may have potential in making spectrum available for new >> uses following any switch to digital radio services. >> Alternatively it may be helpful in exploiting some of the >> public sector spectrum holdings. Ofcom will continue to >> consider other areas of the radio spectrum where white space >> usage may be of benefit. >>=20 >>=20 >> >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards >>=20 >>=20 >>=20 >>=20 >>=20 >> Andy >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >> Behalf Of scott.probasco@nokia.com >> Sent: 26 January 2012 23:43 >> To: paws@ietf.org >> Subject: [paws] >> draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >>=20 >>=20 >>=20 >>=20 >>=20 >> Hi, >>=20 >>=20 >>=20 >>=20 >>=20 >> Revision 2 of the PS, Use cases and requirements I-D has been >> posted. Please see: >>=20 >>=20 >> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-= usecases-rqmts-02.txt >>=20 >>=20 >>=20 >>=20 >>=20 >> This version only includes changes requested by the co-chair >> in his email of January >> 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.htm= l >>=20 >>=20 >> Specifically: >>=20 >>=20 >> " >>=20 >>=20 >> 2. requirements. In the last f2f >>=20 >>=20 >> we agreed to modify requirement D.1 to include the >> suggestions from slide 7-10 >> ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf an= d merge with D.6 and D.9 >>=20 >>=20 >> slides 7&8 >> of http://www.ietf.org/proceedings/82/slides/paws-1.pdf a= lso contain suggestions on how to revise this requirement. >>=20 >>=20 >> Agreed to revise requirement D.2 as suggested in slide >> 11 >> of http://www.ietf.org/proceedings/82/slides/paws-2.pdfan= d slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf >>=20 >>=20 >> We seem to have agreed with the reformulation >> suggested to D.3 in slide 12 >> ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, b= ut we did not agree on the format the location would be represented in. The= data format part is still open, but as this piece does not really belong t= o requirements but rather the data model spec, we are not in a hurry to dec= ide it. >>=20 >>=20 >> Delete d.4 >>=20 >>=20 >> D.5: augment with lower/upper frequencies and time of >> availability, as suggested on slide 10 >> ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf >>=20 >>=20 >> D.6: change power to eirp, as suggested in slide 13 >> of http://www.ietf.org/proceedings/82/slides/paws-2.pdf. >>=20 >>=20 >> D.7: change to single and multiple locations. Clarify >> that in case of multiple locations the channel >> availability for each location should be sent by the >> db. >>=20 >>=20 >> D.8: delete >>=20 >>=20 >> " >>=20 >>=20 >>=20 >>=20 >>=20 >> And >>=20 >>=20 >> " >>=20 >>=20 >> Operational requirements: slides 22-24 >> of http://www.ietf.org/proceedings/82/slides/paws-2.pdf c= ontain suggestions on rewording, I propose the editor considers them. >>=20 >>=20 >> " >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Regards, >>=20 >>=20 >> Scott & Raj >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> 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 budden@nps.edu Fri Feb 3 10:12:03 2012 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 0C3FB21F854B for ; Fri, 3 Feb 2012 10:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.429 X-Spam-Level: X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgohsWt0ylSa for ; Fri, 3 Feb 2012 10:12:01 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3F621F855E for ; Fri, 3 Feb 2012 10:12:01 -0800 (PST) X-ASG-Debug-ID: 1328292709-036c920f20d20e0001-Z0ZA9G Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id z7pxl66lolSENYei; Fri, 03 Feb 2012 10:11:49 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 Feb 2012 10:11:49 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt To: "Rosen, Brian" In-Reply-To: References: <619CDADDCCD2B44380834BE8BF6F714140654A1A42@EMV62-UKRD.domain1.systemhost.net> <1328289756.9169.1870.camel@localhost.localdomain> Content-Type: text/plain; charset="UTF-8" Date: Fri, 3 Feb 2012 10:11:13 -0800 Message-ID: <1328292673.9169.1889.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1328292709 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.87504 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: "paws@ietf.org" Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 03 Feb 2012 18:12:03 -0000 Brian, My comment is background; it doesn't contribute specifically to the text being folded, spindled and mutilated. I'm reacting to the use of the acronym TVWS which tends to get us into a tunnel. more in line... On Fri, 2012-02-03 at 12:51 -0500, Rosen, Brian wrote: > > Rex > > I know whereof you speak. But, is there some use case, or requirement > that might arise out of this, which would help our work? > We can't reasonably ask the database to react to, for example, Push to > Talk reservations - use has to be on a much more granular time scale. Push-to-talk is a term common in the LMR world ... but ports very imperfectly into a packet switched one. It conflates layer 3 concepts like multicast working groups with layer 7 things like voice apps. If you read the NPSTC statement on 'mission critical voice' from an internet point of view, the first thing you have to do is sort the issues into 1) application and 2) infrastructure bins -- they're all mixed up in the statement. > Regardless of how the spectrum is sliced and diced, our basic > paradigm of query the database with your location, and it responds > with what spectrum you can use, seems to apply to this use as well as > TVBWS. Agreed. My only hedge here is to stay out of a TVWS-only hole. > > Brian > > On Feb 3, 2012, at 12:22 PM, Rex Buddenberg wrote: > > > It might be useful to get your head out of _TV_ white space for a minute > > and generalize. > > > > In the VHF band there are lots of 15kHz slivers of licensed. Similar in > > the 700/800MHz band for emergency services (also licensed). FWIW, the > > county where I live has over 200 VHF channel licenses. There are two > > trends being pushed in these parts of the spectrum: > > - 'narrowbanding' by reissuing the 15kHz slivers as even smaller ~7kHz > > sliverettes. This of course, perpetuates narrowband (as in Land Mobile > > Radio) and squeezes more efficiency out. The facts of life are that a > > lot of these channels are vacant a lot of the time. > > - recycling the spectrum by withdrawing the narrowband licenses > > entirely so they can be issued in the 5/10MHz slabs that IEEE 802.16 and > > LTE like. There's a big debate about the spectrum allocation in the > > 700MHz block and a lot of confused conversation in the emergency > > services comms world where they seem to want both broadband spectrum > > _and_ lots of narrowband channels. But the crux is whether the law or > > regulation states whether the 700MHz emergency services channels will be > > for _exclusive_ emergency services use or not. (Within that is the > > debate over just what constitutes emergency services ... one of my > > contacts in Wyoming insists that snowplows are). If non-exclusive, then > > there may be considerable value to whitespace recycling ability here. > > > > > > > > On Fri, 2012-02-03 at 11:16 +0000, andy.sago@bt.com wrote: > >> Scott, Teco > >> > >> > >> > >> Teco makes a good suggestion to amend the US text, for historical > >> accuracy. Certainly in UK there is no connection between digital > >> switchover and permitting white space usage per se, but the two became > >> connected in people’s minds due to their similar timing. I guess there > >> could be a similar confusion in US. > >> > >> > >> > >> Regards > >> > >> > >> > >> Andy > >> > >> > >> > >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf > >> Of Teco Boot > >> Sent: 03 February 2012 07:41 > >> To: scott.probasco@nokia.com > >> Cc: paws@ietf.org > >> Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > >> > >> > >> > >> > >> Hi Scott, > >> > >> > >> > >> > >> Something like this? > >> > >> > >> > >> > >> > >> WithBesides the switch to digital > >> transmission for TV, the guard bands that > >> > >> > >> existedexists to protect the signals > >> between stations can now be used for > >> > >> > >> other purposes. > >> > >> > >> > >> > >> > >> Teco > >> > >> > >> > >> > >> > >> Op 2 feb. 2012, om 23:21 heeft > >> het volgende geschreven: > >> > >> > >> > >> > >> Hi Teco, > >> > >> > >> > >> > >> > >> Did you have any text you want to suggest? I guess the text in > >> question is accurate enough in practical terms, even if it does allow > >> room for discussion in theoretical terms. I get your point that white > >> space paradigm applies regardless of the incumbent radio service. I > >> also believe a thorough discussion of your comment would wander into > >> the realm of radio transmission theory and perhaps we could leave that > >> for offline discussion at the next meeting :-) > >> > >> > >> > >> > >> > >> Kind Regards, > >> > >> > >> Scott > >> > >> > >> > >> > >> > >> From: ext Teco Boot > >> Date: Thu, 2 Feb 2012 22:47:35 +0100 > >> To: Scott > >> Cc: ext com , "paws@ietf.org" > >> > >> Subject: Re: [paws] > >> draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > >> > >> > >> > >> > >> > >> Hi Scott, > >> > >> > >> > >> > >> It is a pity EU cannot report a straightforward plan for usage > >> of white spaces. But steps are taken. The doc has already a > >> ref to ECC Report 159. > >> > >> > >> > >> > >> Minor comment on: > >> > >> > >> With the switch to digital transmission for TV, the > >> guard bands that > >> > >> > >> existed to protect the signals between stations can > >> now be used for > >> > >> > >> other purposes. > >> > >> > >> I'm not sure this is true. I can't see why analogue > >> broadcasting didn't had white spaces. Maybe it is just an > >> increased demand on spectrum and the opportunities created > >> with new technology, such as PAWS. > >> > >> > >> > >> > >> > >> Teco > >> > >> > >> > >> > >> Op 2 feb. 2012, om 21:26 heeft > >> het volgende geschreven: > >> > >> > >> > >> > >> Hi Andy, > >> > >> > >> > >> > >> > >> Very good to cover the UK situation also. I support your > >> proposal and plan to include the new section in the next > >> update, pending any further discussion on this thread. > >> > >> > >> > >> > >> > >> Kind Regards, > >> > >> > >> Scott > >> > >> > >> > >> > >> > >> From: ext com > >> Date: Thu, 2 Feb 2012 19:40:01 +0000 > >> To: Scott , "paws@ietf.org" > >> > >> Subject: RE: > >> draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > >> > >> > >> > >> > >> > >> Scott > >> > >> > >> > >> > >> > >> Section 3 only addresses the US, presumably due to lack of > >> contributions from elsewhere. I propose a couple of short > >> paragraphs to cover the UK situation. The wording is not mine > >> but is almost entirely taken from the latest Ofcom Statement. > >> > >> > >> > >> > >> > >> Section 3.2 is copied below for reference, unchanged, and I > >> propose a new section 3.3, also below: > >> > >> > >> > >> > >> > >> 3.2. Background information on white space in US > >> > >> Television transmission in the United States has moved to the > >> use of > >> > >> digital signals as of June 12, 2009. Since June 13, 2009, all > >> fullpower > >> > >> U.S. television stations have broadcast over-the-air signals > >> in > >> > >> digital only. An important benefit of the switch to > >> all-digital > >> > >> broadcasting is that it freed up parts of the valuable > >> broadcast > >> > >> spectrum. More information about the switch to digital > >> transmission > >> > >> is at : [DTV]. > >> > >> Probasco & Patil Expires July 30, 2012 [Page 8] > >> > >> Internet-Draft PAWS: Problem, uses and requirements January > >> 2012 > >> > >> With the switch to digital transmission for TV, the guard > >> bands that > >> > >> existed to protect the signals between stations can now be > >> used for > >> > >> other purposes. The FCC has made this spectrum available for > >> > >> unlicensed use and this is generally referred to as white > >> space. > >> > >> Please see the details of the FCC ruling and regulations in > >> [FCC > >> > >> Ruling]. The spectrum can be used to provide wireless > >> broadband as > >> > >> an example. The term "Super-Wifi" is also used to describe > >> this > >> > >> spectrum and potential for providing wifi type of service. > >> > >> > >> > >> > >> > >> > >> > >> > >> 3.3. Background information on white space in UK > >> > >> > >> Since its launch in 2005, Ofcom’s Digital Dividend Review > >> [DDR] has considered how to make the spectrum freed up by > >> digital switchover available for new uses, including the > >> capacity available within the spectrum that is retained to > >> carry the digital terrestrial television service. Similarly to > >> the US, this interleaved or guard spectrum occurs because not > >> all the spectrum in any particular location will be used for > >> terrestrial television and so is available for other services, > >> as long as they can interleave their usage around the existing > >> users. > >> > >> > >> > >> > >> > >> In its September 2011 Statement [Ofcom Implementing] Ofcom > >> says that a key element in enabling white space usage in the > >> TV bands is the definition and provision of a database which, > >> given a device’s location, can tell the device which frequency > >> channels and power levels it is able to use without causing > >> harmful interference to other licensed users in the vicinity. > >> Ofcom will specify requirements to be met by such geolocation > >> databases. It also says that the technology has the > >> possibility of being usefully applied elsewhere in the radio > >> spectrum to ensure it is used to maximum benefit. For example, > >> it may have potential in making spectrum available for new > >> uses following any switch to digital radio services. > >> Alternatively it may be helpful in exploiting some of the > >> public sector spectrum holdings. Ofcom will continue to > >> consider other areas of the radio spectrum where white space > >> usage may be of benefit. > >> > >> > >> > >> > >> > >> > >> > >> > >> Regards > >> > >> > >> > >> > >> > >> Andy > >> > >> > >> > >> > >> > >> > >> > >> > >> From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On > >> Behalf Of scott.probasco@nokia.com > >> Sent: 26 January 2012 23:43 > >> To: paws@ietf.org > >> Subject: [paws] > >> draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > >> > >> > >> > >> > >> > >> Hi, > >> > >> > >> > >> > >> > >> Revision 2 of the PS, Use cases and requirements I-D has been > >> posted. Please see: > >> > >> > >> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt > >> > >> > >> > >> > >> > >> This version only includes changes requested by the co-chair > >> in his email of January > >> 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.html > >> > >> > >> Specifically: > >> > >> > >> " > >> > >> > >> 2. requirements. In the last f2f > >> > >> > >> we agreed to modify requirement D.1 to include the > >> suggestions from slide 7-10 > >> ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and merge with D.6 and D.9 > >> > >> > >> slides 7&8 > >> of http://www.ietf.org/proceedings/82/slides/paws-1.pdf also contain suggestions on how to revise this requirement. > >> > >> > >> Agreed to revise requirement D.2 as suggested in slide > >> 11 > >> of http://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf > >> > >> > >> We seem to have agreed with the reformulation > >> suggested to D.3 in slide 12 > >> ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we did not agree on the format the location would be represented in. The data format part is still open, but as this piece does not really belong to requirements but rather the data model spec, we are not in a hurry to decide it. > >> > >> > >> Delete d.4 > >> > >> > >> D.5: augment with lower/upper frequencies and time of > >> availability, as suggested on slide 10 > >> ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf > >> > >> > >> D.6: change power to eirp, as suggested in slide 13 > >> of http://www.ietf.org/proceedings/82/slides/paws-2.pdf. > >> > >> > >> D.7: change to single and multiple locations. Clarify > >> that in case of multiple locations the channel > >> availability for each location should be sent by the > >> db. > >> > >> > >> D.8: delete > >> > >> > >> " > >> > >> > >> > >> > >> > >> And > >> > >> > >> " > >> > >> > >> Operational requirements: slides 22-24 > >> of http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions on rewording, I propose the editor considers them. > >> > >> > >> " > >> > >> > >> > >> > >> > >> > >> > >> > >> Regards, > >> > >> > >> Scott & Raj > >> > >> > >> _______________________________________________ > >> 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 Fri Feb 3 10:20:25 2012 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 6B0B921F8595 for ; Fri, 3 Feb 2012 10:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.027 X-Spam-Level: X-Spam-Status: No, score=-6.027 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2zqRlzjYHK2 for ; Fri, 3 Feb 2012 10:20:24 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id D5E6621F858B for ; Fri, 3 Feb 2012 10:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1328293353; x=1643643922; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=7cKdciFjb1rT5sKeBdI9g r2Q75aRtWpuz9nTg3IlMO4=; b=sGlFwMaEE2JJ786iIutzEpFuRV6KVAfnjrNBW luOC0h7w0A2gfbi0ob44t0maf5P0c1aEOxq5ZRo8koOD2igtw== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.5165302; Fri, 03 Feb 2012 13:22:32 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 3 Feb 2012 13:20:19 -0500 From: "Rosen, Brian" To: Rex Buddenberg Date: Fri, 3 Feb 2012 13:20:16 -0500 Thread-Topic: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt Thread-Index: AczioHsBczxl6wAmQ6OtukTz5OSkNw== Message-ID: <4A02FAFD-CC60-4D96-A40F-5CC7CE9271D5@neustar.biz> References: <619CDADDCCD2B44380834BE8BF6F714140654A1A42@EMV62-UKRD.domain1.systemhost.net> <1328289756.9169.1870.camel@localhost.localdomain> <1328292673.9169.1889.camel@localhost.localdomain> In-Reply-To: <1328292673.9169.1889.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: /oNmoLU0fvaQ3HX//D0FYw== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 03 Feb 2012 18:20:25 -0000 Gotcha. My mind did wander on PTT. The narrow banding is geographically distributed statically, and then typic= ally, a "talk group" temporary reservation is made when the PTT button is m= ashed. We still are at human speed, and talk groups do require you wait fo= r the beep. So, we COULD think about, at some future time, a really fast response that = dynamically assigned a channel (or maybe not just a channel, maybe it's use= of a DSCP in a big wide channel) on the PTT button press. The database co= uld use geo-location and other data to make decisions. Generally, I don't think they need anything: just use wideband digital as-i= s with no spectrum management, but they don't believe it yet. We now return to our regularly scheduled discussion. Brian On Feb 3, 2012, at 1:11 PM, Rex Buddenberg wrote: > Brian, > > My comment is background; it doesn't contribute specifically to the text > being folded, spindled and mutilated. I'm reacting to the use of the > acronym TVWS which tends to get us into a tunnel. > > > more in line... > > On Fri, 2012-02-03 at 12:51 -0500, Rosen, Brian wrote: >> >> Rex >> >> I know whereof you speak. But, is there some use case, or requirement >> that might arise out of this, which would help our work? >> We can't reasonably ask the database to react to, for example, Push to >> Talk reservations - use has to be on a much more granular time scale. > > Push-to-talk is a term common in the LMR world ... but ports very > imperfectly into a packet switched one. It conflates layer 3 concepts > like multicast working groups with layer 7 things like voice apps. If > you read the NPSTC statement on 'mission critical voice' from an > internet point of view, the first thing you have to do is sort the > issues into 1) application and 2) infrastructure bins -- they're all > mixed up in the statement. > >> Regardless of how the spectrum is sliced and diced, our basic >> paradigm of query the database with your location, and it responds >> with what spectrum you can use, seems to apply to this use as well as >> TVBWS. > > Agreed. My only hedge here is to stay out of a TVWS-only hole. >> >> Brian >> >> On Feb 3, 2012, at 12:22 PM, Rex Buddenberg wrote: >> >>> It might be useful to get your head out of _TV_ white space for a minut= e >>> and generalize. >>> >>> In the VHF band there are lots of 15kHz slivers of licensed. Similar i= n >>> the 700/800MHz band for emergency services (also licensed). FWIW, the >>> county where I live has over 200 VHF channel licenses. There are two >>> trends being pushed in these parts of the spectrum: >>> - 'narrowbanding' by reissuing the 15kHz slivers as even smaller = ~7kHz >>> sliverettes. This of course, perpetuates narrowband (as in Land Mobile >>> Radio) and squeezes more efficiency out. The facts of life are that a >>> lot of these channels are vacant a lot of the time. >>> - recycling the spectrum by withdrawing the narrowband licenses >>> entirely so they can be issued in the 5/10MHz slabs that IEEE 802.16 an= d >>> LTE like. There's a big debate about the spectrum allocation in the >>> 700MHz block and a lot of confused conversation in the emergency >>> services comms world where they seem to want both broadband spectrum >>> _and_ lots of narrowband channels. But the crux is whether the law or >>> regulation states whether the 700MHz emergency services channels will b= e >>> for _exclusive_ emergency services use or not. (Within that is the >>> debate over just what constitutes emergency services ... one of my >>> contacts in Wyoming insists that snowplows are). If non-exclusive, the= n >>> there may be considerable value to whitespace recycling ability here. >>> >>> >>> >>> On Fri, 2012-02-03 at 11:16 +0000, andy.sago@bt.com wrote: >>>> Scott, Teco >>>> >>>> >>>> >>>> Teco makes a good suggestion to amend the US text, for historical >>>> accuracy. Certainly in UK there is no connection between digital >>>> switchover and permitting white space usage per se, but the two became >>>> connected in people=92s minds due to their similar timing. I guess the= re >>>> could be a similar confusion in US. >>>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>>> Of Teco Boot >>>> Sent: 03 February 2012 07:41 >>>> To: scott.probasco@nokia.com >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >>>> >>>> >>>> >>>> >>>> Hi Scott, >>>> >>>> >>>> >>>> >>>> Something like this? >>>> >>>> >>>> >>>> >>>> >>>> WithBesides the switch to digital >>>> transmission for TV, the guard bands that >>>> >>>> >>>> existedexists to protect the signals >>>> between stations can now be used for >>>> >>>> >>>> other purposes. >>>> >>>> >>>> >>>> >>>> >>>> Teco >>>> >>>> >>>> >>>> >>>> >>>> Op 2 feb. 2012, om 23:21 heeft >>>> het volgende geschreven: >>>> >>>> >>>> >>>> >>>> Hi Teco, >>>> >>>> >>>> >>>> >>>> >>>> Did you have any text you want to suggest? I guess the text in >>>> question is accurate enough in practical terms, even if it does allow >>>> room for discussion in theoretical terms. I get your point that white >>>> space paradigm applies regardless of the incumbent radio service. I >>>> also believe a thorough discussion of your comment would wander into >>>> the realm of radio transmission theory and perhaps we could leave that >>>> for offline discussion at the next meeting :-) >>>> >>>> >>>> >>>> >>>> >>>> Kind Regards, >>>> >>>> >>>> Scott >>>> >>>> >>>> >>>> >>>> >>>> From: ext Teco Boot >>>> Date: Thu, 2 Feb 2012 22:47:35 +0100 >>>> To: Scott >>>> Cc: ext com , "paws@ietf.org" >>>> >>>> Subject: Re: [paws] >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >>>> >>>> >>>> >>>> >>>> >>>> Hi Scott, >>>> >>>> >>>> >>>> >>>> It is a pity EU cannot report a straightforward plan for usage >>>> of white spaces. But steps are taken. The doc has already a >>>> ref to ECC Report 159. >>>> >>>> >>>> >>>> >>>> Minor comment on: >>>> >>>> >>>> With the switch to digital transmission for TV, the >>>> guard bands that >>>> >>>> >>>> existed to protect the signals between stations can >>>> now be used for >>>> >>>> >>>> other purposes. >>>> >>>> >>>> I'm not sure this is true. I can't see why analogue >>>> broadcasting didn't had white spaces. Maybe it is just an >>>> increased demand on spectrum and the opportunities created >>>> with new technology, such as PAWS. >>>> >>>> >>>> >>>> >>>> >>>> Teco >>>> >>>> >>>> >>>> >>>> Op 2 feb. 2012, om 21:26 heeft >>>> het volgende geschreven: >>>> >>>> >>>> >>>> >>>> Hi Andy, >>>> >>>> >>>> >>>> >>>> >>>> Very good to cover the UK situation also. I support your >>>> proposal and plan to include the new section in the next >>>> update, pending any further discussion on this thread. >>>> >>>> >>>> >>>> >>>> >>>> Kind Regards, >>>> >>>> >>>> Scott >>>> >>>> >>>> >>>> >>>> >>>> From: ext com >>>> Date: Thu, 2 Feb 2012 19:40:01 +0000 >>>> To: Scott , "paws@ietf.org" >>>> >>>> Subject: RE: >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >>>> >>>> >>>> >>>> >>>> >>>> Scott >>>> >>>> >>>> >>>> >>>> >>>> Section 3 only addresses the US, presumably due to lack of >>>> contributions from elsewhere. I propose a couple of short >>>> paragraphs to cover the UK situation. The wording is not mine >>>> but is almost entirely taken from the latest Ofcom Statement. >>>> >>>> >>>> >>>> >>>> >>>> Section 3.2 is copied below for reference, unchanged, and I >>>> propose a new section 3.3, also below: >>>> >>>> >>>> >>>> >>>> >>>> 3.2. Background information on white space in US >>>> >>>> Television transmission in the United States has moved to the >>>> use of >>>> >>>> digital signals as of June 12, 2009. Since June 13, 2009, all >>>> fullpower >>>> >>>> U.S. television stations have broadcast over-the-air signals >>>> in >>>> >>>> digital only. An important benefit of the switch to >>>> all-digital >>>> >>>> broadcasting is that it freed up parts of the valuable >>>> broadcast >>>> >>>> spectrum. More information about the switch to digital >>>> transmission >>>> >>>> is at : [DTV]. >>>> >>>> Probasco & Patil Expires July 30, 2012 [Page 8] >>>> >>>> Internet-Draft PAWS: Problem, uses and requirements January >>>> 2012 >>>> >>>> With the switch to digital transmission for TV, the guard >>>> bands that >>>> >>>> existed to protect the signals between stations can now be >>>> used for >>>> >>>> other purposes. The FCC has made this spectrum available for >>>> >>>> unlicensed use and this is generally referred to as white >>>> space. >>>> >>>> Please see the details of the FCC ruling and regulations in >>>> [FCC >>>> >>>> Ruling]. The spectrum can be used to provide wireless >>>> broadband as >>>> >>>> an example. The term "Super-Wifi" is also used to describe >>>> this >>>> >>>> spectrum and potential for providing wifi type of service. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 3.3. Background information on white space in UK >>>> >>>> >>>> Since its launch in 2005, Ofcom=92s Digital Dividend Review >>>> [DDR] has considered how to make the spectrum freed up by >>>> digital switchover available for new uses, including the >>>> capacity available within the spectrum that is retained to >>>> carry the digital terrestrial television service. Similarly to >>>> the US, this interleaved or guard spectrum occurs because not >>>> all the spectrum in any particular location will be used for >>>> terrestrial television and so is available for other services, >>>> as long as they can interleave their usage around the existing >>>> users. >>>> >>>> >>>> >>>> >>>> >>>> In its September 2011 Statement [Ofcom Implementing] Ofcom >>>> says that a key element in enabling white space usage in the >>>> TV bands is the definition and provision of a database which, >>>> given a device=92s location, can tell the device which frequency >>>> channels and power levels it is able to use without causing >>>> harmful interference to other licensed users in the vicinity. >>>> Ofcom will specify requirements to be met by such geolocation >>>> databases. It also says that the technology has the >>>> possibility of being usefully applied elsewhere in the radio >>>> spectrum to ensure it is used to maximum benefit. For example, >>>> it may have potential in making spectrum available for new >>>> uses following any switch to digital radio services. >>>> Alternatively it may be helpful in exploiting some of the >>>> public sector spectrum holdings. Ofcom will continue to >>>> consider other areas of the radio spectrum where white space >>>> usage may be of benefit. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards >>>> >>>> >>>> >>>> >>>> >>>> Andy >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>>> Behalf Of scott.probasco@nokia.com >>>> Sent: 26 January 2012 23:43 >>>> To: paws@ietf.org >>>> Subject: [paws] >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt >>>> >>>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> >>>> >>>> >>>> >>>> Revision 2 of the PS, Use cases and requirements I-D has been >>>> posted. Please see: >>>> >>>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt= -usecases-rqmts-02.txt >>>> >>>> >>>> >>>> >>>> >>>> This version only includes changes requested by the co-chair >>>> in his email of January >>>> 12 http://www.ietf.org/mail-archive/web/paws/current/msg00516.ht= ml >>>> >>>> >>>> Specifically: >>>> >>>> >>>> " >>>> >>>> >>>> 2. requirements. In the last f2f >>>> >>>> >>>> we agreed to modify requirement D.1 to include the >>>> suggestions from slide 7-10 >>>> ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf a= nd merge with D.6 and D.9 >>>> >>>> >>>> slides 7&8 >>>> of http://www.ietf.org/proceedings/82/slides/paws-1.pdf = also contain suggestions on how to revise this requirement. >>>> >>>> >>>> Agreed to revise requirement D.2 as suggested in slide >>>> 11 >>>> of http://www.ietf.org/proceedings/82/slides/paws-2.pdfa= nd slide 9 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf >>>> >>>> >>>> We seem to have agreed with the reformulation >>>> suggested to D.3 in slide 12 >>>> ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, = but we did not agree on the format the location would be represented in. Th= e data format part is still open, but as this piece does not really belong = to requirements but rather the data model spec, we are not in a hurry to de= cide it. >>>> >>>> >>>> Delete d.4 >>>> >>>> >>>> D.5: augment with lower/upper frequencies and time of >>>> availability, as suggested on slide 10 >>>> ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf >>>> >>>> >>>> D.6: change power to eirp, as suggested in slide 13 >>>> of http://www.ietf.org/proceedings/82/slides/paws-2.pdf. >>>> >>>> >>>> D.7: change to single and multiple locations. Clarify >>>> that in case of multiple locations the channel >>>> availability for each location should be sent by the >>>> db. >>>> >>>> >>>> D.8: delete >>>> >>>> >>>> " >>>> >>>> >>>> >>>> >>>> >>>> And >>>> >>>> >>>> " >>>> >>>> >>>> Operational requirements: slides 22-24 >>>> of http://www.ietf.org/proceedings/82/slides/paws-2.pdf = contain suggestions on rewording, I propose the editor considers them. >>>> >>>> >>>> " >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Regards, >>>> >>>> >>>> Scott & Raj >>>> >>>> >>>> _______________________________________________ >>>> 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 Fri Feb 3 11:34:12 2012 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 9F3EA21F855E for ; Fri, 3 Feb 2012 11:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGqRuF2EyY8r for ; Fri, 3 Feb 2012 11:34:12 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEDC21F854F for ; Fri, 3 Feb 2012 11:34:11 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13JY5qS008246; Fri, 3 Feb 2012 21:34:05 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 21:34:05 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 20:34:04 +0100 From: To: , Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS1w== Date: Fri, 3 Feb 2012 19:34:03 +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.13.0.110805 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 19:34:05.0035 (UTC) FILETIME=[CA208BB0:01CCE2AA] X-Nokia-AV: Clean Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 19:34:12 -0000 Below is Rev 3 of the threat model based on feedback from Stephen, Nancy and Gabor (Thanks). -Raj Rev 3 (3/2/12) Threat model for the PAWS protocol ---------------------------------- Assumptions: ............ o It is assumed that an attacker has full access to the network medium between the master device and the white space database. The attacker may be able to eavesdrop on any communications between these entities. The link between the master device and the white space database can be wired or wireless and provides IP connectivity. o It is assumed that the master device or the white space database have NOT been compromised from a security standpoint. Threat 1: User modifies a device to masquerade as another valid certified device The master device needs to authenticate itself with the white space database prior to requesting channel information. The attacker may try to get access to the secrets of the master device which can be used maliciously. The effect of such an attack being successful would result in a malicious client replaying the stolen authentication/authorization secrets to a white space database. Threat 2: Spoofed white space database A master device discovers a white space database(s) thru which it can query for channel information. The master device needs to ensure that the white space database with which it communicates with is an authentic entity. The white space database needs to provide its identity to the master device which can confirm the validity/authenticty of the database. An attacker may attempt to spoof a white space database and provide responses to a master device which are malicious and result in the master device causing interference to the primary user of the spectrum. Threat 3: Modifying a query request An attacker may modify the query request sent by a master device to a white space database. The attacker may change the location of the device or the capabilities in terms of its transmit power or antenna height etc. which could result in the database responding with incorrect information about available channels or max transmit power allowed. The result of such an attack is that the master device would cause intereference to the primary user of the spectrum. It could also result in a denial of service to the master device by indicating that no channels are available. Threat 4: Modifying a query response An attacker could modify the query response sent by the white space database to a master device. The channel information or transmit power allowed type of parameters carried in the response could be modified by the attacker resulting in the master device using channels that are not available at a location or transmitting at a greater power level than allowed resulting in interference to the primary user of that spectrum. Alternatively the attacker may indicate no channel availability at a location resulting in a denial of service to the master device. Threat 5: Unauthorized use of channels by an uncertified device An attacker may be a master device which is not certified for use by the relevant regulatory body. The attacker may listen to the communication between a valid master device and white space database and utilize the information about available channels in the response message by utilizing those channels. The result of such an attack is unauthorized use of channels by a master device which is not certified to operate. The master device querying the white space database may be operated by a law-enforcement agency and the communications between the device and the database are intended to be kept private. A malicious device should not be able to eavesdrop on such communications. Threat 6: Third party tracking of white space device location and identity =20 A white space database may require a master device to provide its identity in addition to its location in the query request. Such location/identity information can be gleaned by an eavesdropper. A master device may prefer to keep the location/identity information secret. Hence the protocol should provide a means to protect the location and identity information of the master device and prevent tracking of locations associated with a white space database. If regulations do not require the identity of the master device to be provided to the white space database, the master is not required to include its identity in the query. Threat 7: Termination of device service for reasons other than incumbent protection A white space database may include a mechanism by which service and channels allocated to a master device can be revoked. A malicious node can send a revoke message to a master device. This results in denial of service to the master device.=20 From jmh@joelhalpern.com Fri Feb 3 11:51:29 2012 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 25B9121F8516 for ; Fri, 3 Feb 2012 11:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.068 X-Spam-Level: X-Spam-Status: No, score=-102.068 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2RMm2wWHO6t for ; Fri, 3 Feb 2012 11:51:25 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD6321F8513 for ; Fri, 3 Feb 2012 11:51:25 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 689B0CD3DD for ; Fri, 3 Feb 2012 11:51:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 32CF31C0933; Fri, 3 Feb 2012 11:51:24 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-140.clppva.btas.verizon.net [71.161.52.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id B5A771C2B30; Fri, 3 Feb 2012 11:51:21 -0800 (PST) Message-ID: <4F2C3AB5.2070306@joelhalpern.com> Date: Fri, 03 Feb 2012 14:51:17 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 19:51:29 -0000 Can we please include in this document some articulation of the confidentiality assumption we are making with regard to the whitespace data itself? I am not trying to object to the threats. (And the personal information collection issues are enough to jsutify include confidentiality mechanisms in the solutions.) But I am still trying to get my head around this. There are going to be hoards of whitespace devices. They will be getting the data, and either using it themselves or retransmitting it. The resulting data one whitespace availability will be visible to people and or devices which are not completely controlled by the regulatory agencies. As such, what is the role of confidentiality with regard to this information? Yours, Joel On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: > > Below is Rev 3 of the threat model based on feedback from Stephen, Nancy > and Gabor (Thanks). > > -Raj > > > Rev 3 (3/2/12) > > Threat model for the PAWS protocol > ---------------------------------- > > Assumptions: > ............ > > o It is assumed that an attacker has full access to the network medium > between the master device and the white space database. The attacker > may be able to eavesdrop on any communications between these > entities. The link between the master device and the white space > database can be wired or wireless and provides IP connectivity. > > o It is assumed that the master device or the white space database > have NOT been compromised from a security standpoint. > > Threat 1: User modifies a device to masquerade as another valid > certified device > > The master device needs to authenticate itself with the white > space database prior to requesting channel information. The > attacker may try to get access to the secrets of the master > device which can be used maliciously. The effect of such an > attack being successful would result in a malicious client > replaying the stolen authentication/authorization secrets to a > white space database. > > Threat 2: Spoofed white space database > > A master device discovers a white space database(s) thru which > it can query for channel information. The master device needs > to ensure that the white space database with which it > communicates with is an authentic entity. The white space > database needs to provide its identity to the master device > which can confirm the validity/authenticty of the database. An > attacker may attempt to spoof a white space database and > provide responses to a master device which are malicious and > result in the master device causing interference to the primary > user of the spectrum. > > Threat 3: Modifying a query request > > An attacker may modify the query request sent by a master > device to a white space database. The attacker may change the > location of the device or the capabilities in terms of its > transmit power or antenna height etc. which could result in the > database responding with incorrect information about available > channels or max transmit power allowed. The result of such an > attack is that the master device would cause intereference to > the primary user of the spectrum. It could also result in a > denial of service to the master device by indicating that no > channels are available. > > Threat 4: Modifying a query response > > An attacker could modify the query response sent by the white > space database to a master device. The channel information or > transmit power allowed type of parameters carried in the > response could be modified by the attacker resulting in the > master device using channels that are not available at a > location or transmitting at a greater power level than allowed > resulting in interference to the primary user of that > spectrum. Alternatively the attacker may indicate no channel > availability at a location resulting in a denial of service to > the master device. > > Threat 5: Unauthorized use of channels by an uncertified device > > An attacker may be a master device which is not certified for > use by the relevant regulatory body. The attacker may listen to > the communication between a valid master device and white space > database and utilize the information about available channels > in the response message by utilizing those channels. The result > of such an attack is unauthorized use of channels by a master > device which is not certified to operate. > The master device querying the white space database may be > operated by a law-enforcement agency and the communications > between the device and the database are intended to be kept > private. A malicious device should not be able to eavesdrop on > such communications. > > Threat 6: Third party tracking of white space device location and identity > > A white space database may require a master device to provide > its identity in addition to its location in the query request. > Such location/identity information can be gleaned by an > eavesdropper. A master device may prefer to keep the > location/identity information secret. Hence the protocol should > provide a means to protect the location and identity > information of the master device and prevent tracking of > locations associated with a white space database. If > regulations do not require the identity of the master device to > be provided to the white space database, the master is not > required to include its identity in the query. > > > Threat 7: Termination of device service for reasons other than > incumbent protection > > A white space database may include a mechanism by which service > and channels allocated to a master device can be revoked. A > malicious node can send a revoke message to a master > device. This results in denial of service to the master > device. > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > From brian.rosen@neustar.biz Fri Feb 3 11:55:55 2012 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 E706A21F85E6 for ; Fri, 3 Feb 2012 11:55:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.179 X-Spam-Level: X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.420, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqjstHGyVsiY for ; Fri, 3 Feb 2012 11:55:54 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5ED21F8601 for ; Fri, 3 Feb 2012 11:55:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1328298991; x=1643654764; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=EDO1X97l4R+nWC+NhRdmk UIRS7Hi2w6ubOU6QdjuFPc=; b=E28osFKVImfH93VszJ2UwLKhmat8JhLE8IHS+ Q5efpo53+mwP14W7WSwy28WriIQHTCaqc7mcw3hWlh9tciMoA== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.4825900; Fri, 03 Feb 2012 14:56:30 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 3 Feb 2012 14:55:50 -0500 From: "Rosen, Brian" To: "Joel M. Halpern" Date: Fri, 3 Feb 2012 14:55:49 -0500 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AczirdOpe0Svsk7wQg24I/x8u4ymGg== Message-ID: <6E9FB277-9969-490B-AFCC-03BD0190AE75@neustar.biz> References: <4F2C3AB5.2070306@joelhalpern.com> In-Reply-To: <4F2C3AB5.2070306@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: x-ems-stamp: Ew7ChHTg5FWpQU0xbPsFIw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 19:55:56 -0000 Where do you see this assumption in the threat model? I took a quick look and didn't spot it. It would be "database information = leaked to bad guys" or something like it, right? I don't think that is a threat, and I don't think we need to protect anyone= from that threat. I would say, however, that if you could know the content of the database, a= nd you can observe a responses over a period of time, you may be able to in= fer the location of the querier. Brian On Feb 3, 2012, at 2:51 PM, Joel M. Halpern wrote: > Can we please include in this document some articulation of the=20 > confidentiality assumption we are making with regard to the whitespace=20 > data itself? I am not trying to object to the threats. (And the=20 > personal information collection issues are enough to jsutify include=20 > confidentiality mechanisms in the solutions.) > But I am still trying to get my head around this. There are going to be= =20 > hoards of whitespace devices. They will be getting the data, and either= =20 > using it themselves or retransmitting it. The resulting data one=20 > whitespace availability will be visible to people and or devices which=20 > are not completely controlled by the regulatory agencies. > As such, what is the role of confidentiality with regard to this=20 > information? >=20 > Yours, > Joel >=20 > On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>=20 >> Below is Rev 3 of the threat model based on feedback from Stephen, Nancy >> and Gabor (Thanks). >>=20 >> -Raj >>=20 >>=20 >> Rev 3 (3/2/12) >>=20 >> Threat model for the PAWS protocol >> ---------------------------------- >>=20 >> Assumptions: >> ............ >>=20 >> o It is assumed that an attacker has full access to the network medium >> between the master device and the white space database. The attacker >> may be able to eavesdrop on any communications between these >> entities. The link between the master device and the white space >> database can be wired or wireless and provides IP connectivity. >>=20 >> o It is assumed that the master device or the white space database >> have NOT been compromised from a security standpoint. >>=20 >> Threat 1: User modifies a device to masquerade as another valid >> certified device >>=20 >> The master device needs to authenticate itself with the white >> space database prior to requesting channel information. The >> attacker may try to get access to the secrets of the master >> device which can be used maliciously. The effect of such an >> attack being successful would result in a malicious client >> replaying the stolen authentication/authorization secrets to a >> white space database. >>=20 >> Threat 2: Spoofed white space database >>=20 >> A master device discovers a white space database(s) thru which >> it can query for channel information. The master device needs >> to ensure that the white space database with which it >> communicates with is an authentic entity. The white space >> database needs to provide its identity to the master device >> which can confirm the validity/authenticty of the database. An >> attacker may attempt to spoof a white space database and >> provide responses to a master device which are malicious and >> result in the master device causing interference to the primary >> user of the spectrum. >>=20 >> Threat 3: Modifying a query request >>=20 >> An attacker may modify the query request sent by a master >> device to a white space database. The attacker may change the >> location of the device or the capabilities in terms of its >> transmit power or antenna height etc. which could result in the >> database responding with incorrect information about available >> channels or max transmit power allowed. The result of such an >> attack is that the master device would cause intereference to >> the primary user of the spectrum. It could also result in a >> denial of service to the master device by indicating that no >> channels are available. >>=20 >> Threat 4: Modifying a query response >>=20 >> An attacker could modify the query response sent by the white >> space database to a master device. The channel information or >> transmit power allowed type of parameters carried in the >> response could be modified by the attacker resulting in the >> master device using channels that are not available at a >> location or transmitting at a greater power level than allowed >> resulting in interference to the primary user of that >> spectrum. Alternatively the attacker may indicate no channel >> availability at a location resulting in a denial of service to >> the master device. >>=20 >> Threat 5: Unauthorized use of channels by an uncertified device >>=20 >> An attacker may be a master device which is not certified for >> use by the relevant regulatory body. The attacker may listen to >> the communication between a valid master device and white space >> database and utilize the information about available channels >> in the response message by utilizing those channels. The result >> of such an attack is unauthorized use of channels by a master >> device which is not certified to operate. >> The master device querying the white space database may be >> operated by a law-enforcement agency and the communications >> between the device and the database are intended to be kept >> private. A malicious device should not be able to eavesdrop on >> such communications. >>=20 >> Threat 6: Third party tracking of white space device location and identi= ty >>=20 >> A white space database may require a master device to provide >> its identity in addition to its location in the query request. >> Such location/identity information can be gleaned by an >> eavesdropper. A master device may prefer to keep the >> location/identity information secret. Hence the protocol should >> provide a means to protect the location and identity >> information of the master device and prevent tracking of >> locations associated with a white space database. If >> regulations do not require the identity of the master device to >> be provided to the white space database, the master is not >> required to include its identity in the query. >>=20 >>=20 >> Threat 7: Termination of device service for reasons other than >> incumbent protection >>=20 >> A white space database may include a mechanism by which service >> and channels allocated to a master device can be revoked. A >> malicious node can send a revoke message to a master >> device. This results in denial of service to the master >> device. >>=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 From Basavaraj.Patil@nokia.com Fri Feb 3 11:57:46 2012 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 9D90221F8503 for ; Fri, 3 Feb 2012 11:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.076 X-Spam-Level: X-Spam-Status: No, score=-103.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1qsQKXxGwGN for ; Fri, 3 Feb 2012 11:57:45 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B527F21F84FF for ; Fri, 3 Feb 2012 11:57:45 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13Jvfjl029138; Fri, 3 Feb 2012 21:57:42 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 21:57:41 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 20:57:40 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmA//+dMoA= Date: Fri, 3 Feb 2012 19:57:39 +0000 Message-ID: In-Reply-To: <4F2C3AB5.2070306@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <968E59E71046FF448E6016F11A2D41B3@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 19:57:41.0468 (UTC) FILETIME=[166311C0:01CCE2AE] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 19:57:46 -0000 Hi Joel, Do you want to propose some text that I could include as part of the assumptions in the threat analysis section? The intent of this threat analysis text is to include it as a subsection of the security considerations section. -Raj On 2/3/12 1:51 PM, "ext Joel M. Halpern" wrote: >Can we please include in this document some articulation of the >confidentiality assumption we are making with regard to the whitespace >data itself? I am not trying to object to the threats. (And the >personal information collection issues are enough to jsutify include >confidentiality mechanisms in the solutions.) >But I am still trying to get my head around this. There are going to be >hoards of whitespace devices. They will be getting the data, and either >using it themselves or retransmitting it. The resulting data one >whitespace availability will be visible to people and or devices which >are not completely controlled by the regulatory agencies. >As such, what is the role of confidentiality with regard to this >information? > >Yours, >Joel > >On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >> >> Below is Rev 3 of the threat model based on feedback from Stephen, Nancy >> and Gabor (Thanks). >> >> -Raj >> >> >> Rev 3 (3/2/12) >> >> Threat model for the PAWS protocol >> ---------------------------------- >> >> Assumptions: >> ............ >> >> o It is assumed that an attacker has full access to the network medium >> between the master device and the white space database. The attacker >> may be able to eavesdrop on any communications between these >> entities. The link between the master device and the white space >> database can be wired or wireless and provides IP connectivity. >> >> o It is assumed that the master device or the white space database >> have NOT been compromised from a security standpoint. >> >> Threat 1: User modifies a device to masquerade as another valid >> certified device >> >> The master device needs to authenticate itself with the white >> space database prior to requesting channel information. The >> attacker may try to get access to the secrets of the master >> device which can be used maliciously. The effect of such an >> attack being successful would result in a malicious client >> replaying the stolen authentication/authorization secrets to a >> white space database. >> >> Threat 2: Spoofed white space database >> >> A master device discovers a white space database(s) thru which >> it can query for channel information. The master device needs >> to ensure that the white space database with which it >> communicates with is an authentic entity. The white space >> database needs to provide its identity to the master device >> which can confirm the validity/authenticty of the database. An >> attacker may attempt to spoof a white space database and >> provide responses to a master device which are malicious and >> result in the master device causing interference to the primary >> user of the spectrum. >> >> Threat 3: Modifying a query request >> >> An attacker may modify the query request sent by a master >> device to a white space database. The attacker may change the >> location of the device or the capabilities in terms of its >> transmit power or antenna height etc. which could result in the >> database responding with incorrect information about available >> channels or max transmit power allowed. The result of such an >> attack is that the master device would cause intereference to >> the primary user of the spectrum. It could also result in a >> denial of service to the master device by indicating that no >> channels are available. >> >> Threat 4: Modifying a query response >> >> An attacker could modify the query response sent by the white >> space database to a master device. The channel information or >> transmit power allowed type of parameters carried in the >> response could be modified by the attacker resulting in the >> master device using channels that are not available at a >> location or transmitting at a greater power level than allowed >> resulting in interference to the primary user of that >> spectrum. Alternatively the attacker may indicate no channel >> availability at a location resulting in a denial of service to >> the master device. >> >> Threat 5: Unauthorized use of channels by an uncertified device >> >> An attacker may be a master device which is not certified for >> use by the relevant regulatory body. The attacker may listen to >> the communication between a valid master device and white space >> database and utilize the information about available channels >> in the response message by utilizing those channels. The result >> of such an attack is unauthorized use of channels by a master >> device which is not certified to operate. >> The master device querying the white space database may be >> operated by a law-enforcement agency and the communications >> between the device and the database are intended to be kept >> private. A malicious device should not be able to eavesdrop on >> such communications. >> >> Threat 6: Third party tracking of white space device location and >>identity >> >> A white space database may require a master device to provide >> its identity in addition to its location in the query request. >> Such location/identity information can be gleaned by an >> eavesdropper. A master device may prefer to keep the >> location/identity information secret. Hence the protocol should >> provide a means to protect the location and identity >> information of the master device and prevent tracking of >> locations associated with a white space database. If >> regulations do not require the identity of the master device to >> be provided to the white space database, the master is not >> required to include its identity in the query. >> >> >> Threat 7: Termination of device service for reasons other than >> incumbent protection >> >> A white space database may include a mechanism by which service >> and channels allocated to a master device can be revoked. A >> malicious node can send a revoke message to a master >> device. This results in denial of service to the master >> device. >> >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> From jmh@joelhalpern.com Fri Feb 3 12:00:59 2012 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 AA76321F8631 for ; Fri, 3 Feb 2012 12:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.071 X-Spam-Level: X-Spam-Status: No, score=-102.071 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZTlpVSPfUoI for ; Fri, 3 Feb 2012 12:00:59 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1162A21F8638 for ; Fri, 3 Feb 2012 12:00:52 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id F3815CD10B for ; Fri, 3 Feb 2012 12:00:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D88D71BD5549; Fri, 3 Feb 2012 12:00:51 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.101] (pool-71-161-52-140.clppva.btas.verizon.net [71.161.52.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B0D4E1BD553F; Fri, 3 Feb 2012 12:00:48 -0800 (PST) Message-ID: <4F2C3CE9.9080902@joelhalpern.com> Date: Fri, 03 Feb 2012 15:00:41 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Rosen, Brian" References: <4F2C3AB5.2070306@joelhalpern.com> <6E9FB277-9969-490B-AFCC-03BD0190AE75@neustar.biz> In-Reply-To: <6E9FB277-9969-490B-AFCC-03BD0190AE75@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 20:00:59 -0000 In the unauthorized use section, there is still the text saying: The attacker may listen to the communication between a valid master device and white space database and utilize the information about available channels in the response message by utilizing those channels. I still find this totally mind-bending, as it is about the hardest way imaginable to undertake this attack. On 2/3/2012 2:55 PM, Rosen, Brian wrote: > > Where do you see this assumption in the threat model? > > I took a quick look and didn't spot it. It would be "database information leaked to bad guys" or something like it, right? > > I don't think that is a threat, and I don't think we need to protect anyone from that threat. > > I would say, however, that if you could know the content of the database, and you can observe a responses over a period of time, you may be able to infer the location of the querier. > > Brian > > > On Feb 3, 2012, at 2:51 PM, Joel M. Halpern wrote: > >> Can we please include in this document some articulation of the >> confidentiality assumption we are making with regard to the whitespace >> data itself? I am not trying to object to the threats. (And the >> personal information collection issues are enough to jsutify include >> confidentiality mechanisms in the solutions.) >> But I am still trying to get my head around this. There are going to be >> hoards of whitespace devices. They will be getting the data, and either >> using it themselves or retransmitting it. The resulting data one >> whitespace availability will be visible to people and or devices which >> are not completely controlled by the regulatory agencies. >> As such, what is the role of confidentiality with regard to this >> information? >> >> Yours, >> Joel >> >> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>> >>> Below is Rev 3 of the threat model based on feedback from Stephen, Nancy >>> and Gabor (Thanks). >>> >>> -Raj >>> >>> >>> Rev 3 (3/2/12) >>> >>> Threat model for the PAWS protocol >>> ---------------------------------- >>> >>> Assumptions: >>> ............ >>> >>> o It is assumed that an attacker has full access to the network medium >>> between the master device and the white space database. The attacker >>> may be able to eavesdrop on any communications between these >>> entities. The link between the master device and the white space >>> database can be wired or wireless and provides IP connectivity. >>> >>> o It is assumed that the master device or the white space database >>> have NOT been compromised from a security standpoint. >>> >>> Threat 1: User modifies a device to masquerade as another valid >>> certified device >>> >>> The master device needs to authenticate itself with the white >>> space database prior to requesting channel information. The >>> attacker may try to get access to the secrets of the master >>> device which can be used maliciously. The effect of such an >>> attack being successful would result in a malicious client >>> replaying the stolen authentication/authorization secrets to a >>> white space database. >>> >>> Threat 2: Spoofed white space database >>> >>> A master device discovers a white space database(s) thru which >>> it can query for channel information. The master device needs >>> to ensure that the white space database with which it >>> communicates with is an authentic entity. The white space >>> database needs to provide its identity to the master device >>> which can confirm the validity/authenticty of the database. An >>> attacker may attempt to spoof a white space database and >>> provide responses to a master device which are malicious and >>> result in the master device causing interference to the primary >>> user of the spectrum. >>> >>> Threat 3: Modifying a query request >>> >>> An attacker may modify the query request sent by a master >>> device to a white space database. The attacker may change the >>> location of the device or the capabilities in terms of its >>> transmit power or antenna height etc. which could result in the >>> database responding with incorrect information about available >>> channels or max transmit power allowed. The result of such an >>> attack is that the master device would cause intereference to >>> the primary user of the spectrum. It could also result in a >>> denial of service to the master device by indicating that no >>> channels are available. >>> >>> Threat 4: Modifying a query response >>> >>> An attacker could modify the query response sent by the white >>> space database to a master device. The channel information or >>> transmit power allowed type of parameters carried in the >>> response could be modified by the attacker resulting in the >>> master device using channels that are not available at a >>> location or transmitting at a greater power level than allowed >>> resulting in interference to the primary user of that >>> spectrum. Alternatively the attacker may indicate no channel >>> availability at a location resulting in a denial of service to >>> the master device. >>> >>> Threat 5: Unauthorized use of channels by an uncertified device >>> >>> An attacker may be a master device which is not certified for >>> use by the relevant regulatory body. The attacker may listen to >>> the communication between a valid master device and white space >>> database and utilize the information about available channels >>> in the response message by utilizing those channels. The result >>> of such an attack is unauthorized use of channels by a master >>> device which is not certified to operate. >>> The master device querying the white space database may be >>> operated by a law-enforcement agency and the communications >>> between the device and the database are intended to be kept >>> private. A malicious device should not be able to eavesdrop on >>> such communications. >>> >>> Threat 6: Third party tracking of white space device location and identity >>> >>> A white space database may require a master device to provide >>> its identity in addition to its location in the query request. >>> Such location/identity information can be gleaned by an >>> eavesdropper. A master device may prefer to keep the >>> location/identity information secret. Hence the protocol should >>> provide a means to protect the location and identity >>> information of the master device and prevent tracking of >>> locations associated with a white space database. If >>> regulations do not require the identity of the master device to >>> be provided to the white space database, the master is not >>> required to include its identity in the query. >>> >>> >>> Threat 7: Termination of device service for reasons other than >>> incumbent protection >>> >>> A white space database may include a mechanism by which service >>> and channels allocated to a master device can be revoked. A >>> malicious node can send a revoke message to a master >>> device. This results in denial of service to the master >>> device. >>> >>> >>> _______________________________________________ >>> 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 Fri Feb 3 12:11:39 2012 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 ED9F621F858F for ; Fri, 3 Feb 2012 12:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.944 X-Spam-Level: X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY+On2v0BmlZ for ; Fri, 3 Feb 2012 12:11:39 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E0DD621F85DA for ; Fri, 3 Feb 2012 12:11:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1328300029; x=1643654885; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=ckd54vReEO+Jp5NIwSZCK i2qlrivz+TjhffZVMyCvE8=; b=d2u9aXkYg4FVTnwp/P0RjQ7DzrodlQeCh7O4k d614oVOx00ins1VZjK8VO10c1VgoeWFvKRPER5WVZj2+GSmTg== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.5169383; Fri, 03 Feb 2012 15:13:48 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Fri, 3 Feb 2012 15:11:34 -0500 From: "Rosen, Brian" To: "" Date: Fri, 3 Feb 2012 15:11:32 -0500 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AczisAXvfo+BtXa4SVSvnDeok7BhxA== Message-ID: <66B79228-C0EF-4290-8F95-43CD5481E0D5@neustar.biz> References: 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: YFzA0CqnR4IF8PgyMregpQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 20:11:40 -0000 Huh, since that section was about misuse of channel data, I missed the poin= t you were making. So, should we get rid of that use case (leaving the Law Enforcement case)? It does seem to me that if a rogue device existed, it would ignore the data= base rather than eavesdrop. One thing we may wish to consider that got triggered by this exchange - the database may be operated by a commercial entity. That entity may wish = to restrict access to only authorized users. That means there is some kind= of identity/authorization requirement, with a threat of theft of service. Brian On Feb 3, 2012, at 2:57 PM, wrote: >=20 > Hi Joel, >=20 > Do you want to propose some text that I could include as part of the > assumptions in the threat analysis section? > The intent of this threat analysis text is to include it as a subsection > of the security considerations section. >=20 > -Raj >=20 > On 2/3/12 1:51 PM, "ext Joel M. Halpern" wrote: >=20 >> Can we please include in this document some articulation of the >> confidentiality assumption we are making with regard to the whitespace >> data itself? I am not trying to object to the threats. (And the >> personal information collection issues are enough to jsutify include >> confidentiality mechanisms in the solutions.) >> But I am still trying to get my head around this. There are going to be >> hoards of whitespace devices. They will be getting the data, and either >> using it themselves or retransmitting it. The resulting data one >> whitespace availability will be visible to people and or devices which >> are not completely controlled by the regulatory agencies. >> As such, what is the role of confidentiality with regard to this >> information? >>=20 >> Yours, >> Joel >>=20 >> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>=20 >>> Below is Rev 3 of the threat model based on feedback from Stephen, Nanc= y >>> and Gabor (Thanks). >>>=20 >>> -Raj >>>=20 >>>=20 >>> Rev 3 (3/2/12) >>>=20 >>> Threat model for the PAWS protocol >>> ---------------------------------- >>>=20 >>> Assumptions: >>> ............ >>>=20 >>> o It is assumed that an attacker has full access to the network medium >>> between the master device and the white space database. The attacker >>> may be able to eavesdrop on any communications between these >>> entities. The link between the master device and the white space >>> database can be wired or wireless and provides IP connectivity. >>>=20 >>> o It is assumed that the master device or the white space database >>> have NOT been compromised from a security standpoint. >>>=20 >>> Threat 1: User modifies a device to masquerade as another valid >>> certified device >>>=20 >>> The master device needs to authenticate itself with the white >>> space database prior to requesting channel information. The >>> attacker may try to get access to the secrets of the master >>> device which can be used maliciously. The effect of such an >>> attack being successful would result in a malicious client >>> replaying the stolen authentication/authorization secrets to a >>> white space database. >>>=20 >>> Threat 2: Spoofed white space database >>>=20 >>> A master device discovers a white space database(s) thru which >>> it can query for channel information. The master device needs >>> to ensure that the white space database with which it >>> communicates with is an authentic entity. The white space >>> database needs to provide its identity to the master device >>> which can confirm the validity/authenticty of the database. An >>> attacker may attempt to spoof a white space database and >>> provide responses to a master device which are malicious and >>> result in the master device causing interference to the primary >>> user of the spectrum. >>>=20 >>> Threat 3: Modifying a query request >>>=20 >>> An attacker may modify the query request sent by a master >>> device to a white space database. The attacker may change the >>> location of the device or the capabilities in terms of its >>> transmit power or antenna height etc. which could result in the >>> database responding with incorrect information about available >>> channels or max transmit power allowed. The result of such an >>> attack is that the master device would cause intereference to >>> the primary user of the spectrum. It could also result in a >>> denial of service to the master device by indicating that no >>> channels are available. >>>=20 >>> Threat 4: Modifying a query response >>>=20 >>> An attacker could modify the query response sent by the white >>> space database to a master device. The channel information or >>> transmit power allowed type of parameters carried in the >>> response could be modified by the attacker resulting in the >>> master device using channels that are not available at a >>> location or transmitting at a greater power level than allowed >>> resulting in interference to the primary user of that >>> spectrum. Alternatively the attacker may indicate no channel >>> availability at a location resulting in a denial of service to >>> the master device. >>>=20 >>> Threat 5: Unauthorized use of channels by an uncertified device >>>=20 >>> An attacker may be a master device which is not certified for >>> use by the relevant regulatory body. The attacker may listen to >>> the communication between a valid master device and white space >>> database and utilize the information about available channels >>> in the response message by utilizing those channels. The result >>> of such an attack is unauthorized use of channels by a master >>> device which is not certified to operate. >>> The master device querying the white space database may be >>> operated by a law-enforcement agency and the communications >>> between the device and the database are intended to be kept >>> private. A malicious device should not be able to eavesdrop on >>> such communications. >>>=20 >>> Threat 6: Third party tracking of white space device location and >>> identity >>>=20 >>> A white space database may require a master device to provide >>> its identity in addition to its location in the query request. >>> Such location/identity information can be gleaned by an >>> eavesdropper. A master device may prefer to keep the >>> location/identity information secret. Hence the protocol should >>> provide a means to protect the location and identity >>> information of the master device and prevent tracking of >>> locations associated with a white space database. If >>> regulations do not require the identity of the master device to >>> be provided to the white space database, the master is not >>> required to include its identity in the query. >>>=20 >>>=20 >>> Threat 7: Termination of device service for reasons other than >>> incumbent protection >>>=20 >>> A white space database may include a mechanism by which service >>> and channels allocated to a master device can be revoked. A >>> malicious node can send a revoke message to a master >>> device. This results in denial of service to the master >>> device. >>>=20 >>>=20 >>> _______________________________________________ >>> 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 Fri Feb 3 12:19:27 2012 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 13A1421F8601 for ; Fri, 3 Feb 2012 12:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.098 X-Spam-Level: X-Spam-Status: No, score=-103.098 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KX9adodSztS8 for ; Fri, 3 Feb 2012 12:19:26 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1D81821F85FC for ; Fri, 3 Feb 2012 12:19:26 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13KJMIb014666; Fri, 3 Feb 2012 22:19:24 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 22:19:23 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 21:19:22 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmA//+dMoCAAGh2AP//nZ2A Date: Fri, 3 Feb 2012 20:19:22 +0000 Message-ID: In-Reply-To: <66B79228-C0EF-4290-8F95-43CD5481E0D5@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <5D9363C225C34C4CA7E08C46E9B5B236@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 20:19:23.0404 (UTC) FILETIME=[1E66BCC0:01CCE2B1] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 20:19:27 -0000 Inline: On 2/3/12 2:11 PM, "ext Rosen, Brian" wrote: >Huh, since that section was about misuse of channel data, I missed the >point you were making. > >So, should we get rid of that use case (leaving the Law Enforcement case)? > >It does seem to me that if a rogue device existed, it would ignore the >database rather than eavesdrop. > >One thing we may wish to consider that got triggered by this exchange - >the database may be operated by a commercial entity. That entity may >wish to restrict access to only authorized users. That means there is >some kind of identity/authorization requirement, with a threat of theft >of service. Threat 1 sort of implies the need for identity/authorization. That is essentially the requirement that I was hoping would fall out of that description. The protocol needs to be capable of an eavesdropper from replaying credentials of a valid master device. It could be expanded to cover what you state above. -Raj > >Brian > >On Feb 3, 2012, at 2:57 PM, wrote: > >>=20 >> Hi Joel, >>=20 >> Do you want to propose some text that I could include as part of the >> assumptions in the threat analysis section? >> The intent of this threat analysis text is to include it as a subsection >> of the security considerations section. >>=20 >> -Raj >>=20 >> On 2/3/12 1:51 PM, "ext Joel M. Halpern" wrote: >>=20 >>> Can we please include in this document some articulation of the >>> confidentiality assumption we are making with regard to the whitespace >>> data itself? I am not trying to object to the threats. (And the >>> personal information collection issues are enough to jsutify include >>> confidentiality mechanisms in the solutions.) >>> But I am still trying to get my head around this. There are going to >>>be >>> hoards of whitespace devices. They will be getting the data, and >>>either >>> using it themselves or retransmitting it. The resulting data one >>> whitespace availability will be visible to people and or devices which >>> are not completely controlled by the regulatory agencies. >>> As such, what is the role of confidentiality with regard to this >>> information? >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>=20 >>>> Below is Rev 3 of the threat model based on feedback from Stephen, >>>>Nancy >>>> and Gabor (Thanks). >>>>=20 >>>> -Raj >>>>=20 >>>>=20 >>>> Rev 3 (3/2/12) >>>>=20 >>>> Threat model for the PAWS protocol >>>> ---------------------------------- >>>>=20 >>>> Assumptions: >>>> ............ >>>>=20 >>>> o It is assumed that an attacker has full access to the network medium >>>> between the master device and the white space database. The attacker >>>> may be able to eavesdrop on any communications between these >>>> entities. The link between the master device and the white space >>>> database can be wired or wireless and provides IP connectivity. >>>>=20 >>>> o It is assumed that the master device or the white space database >>>> have NOT been compromised from a security standpoint. >>>>=20 >>>> Threat 1: User modifies a device to masquerade as another valid >>>> certified device >>>>=20 >>>> The master device needs to authenticate itself with the white >>>> space database prior to requesting channel information. The >>>> attacker may try to get access to the secrets of the master >>>> device which can be used maliciously. The effect of such an >>>> attack being successful would result in a malicious client >>>> replaying the stolen authentication/authorization secrets to a >>>> white space database. >>>>=20 >>>> Threat 2: Spoofed white space database >>>>=20 >>>> A master device discovers a white space database(s) thru which >>>> it can query for channel information. The master device needs >>>> to ensure that the white space database with which it >>>> communicates with is an authentic entity. The white space >>>> database needs to provide its identity to the master device >>>> which can confirm the validity/authenticty of the database. An >>>> attacker may attempt to spoof a white space database and >>>> provide responses to a master device which are malicious and >>>> result in the master device causing interference to the primary >>>> user of the spectrum. >>>>=20 >>>> Threat 3: Modifying a query request >>>>=20 >>>> An attacker may modify the query request sent by a master >>>> device to a white space database. The attacker may change the >>>> location of the device or the capabilities in terms of its >>>> transmit power or antenna height etc. which could result in the >>>> database responding with incorrect information about available >>>> channels or max transmit power allowed. The result of such an >>>> attack is that the master device would cause intereference to >>>> the primary user of the spectrum. It could also result in a >>>> denial of service to the master device by indicating that no >>>> channels are available. >>>>=20 >>>> Threat 4: Modifying a query response >>>>=20 >>>> An attacker could modify the query response sent by the white >>>> space database to a master device. The channel information or >>>> transmit power allowed type of parameters carried in the >>>> response could be modified by the attacker resulting in the >>>> master device using channels that are not available at a >>>> location or transmitting at a greater power level than allowed >>>> resulting in interference to the primary user of that >>>> spectrum. Alternatively the attacker may indicate no channel >>>> availability at a location resulting in a denial of service to >>>> the master device. >>>>=20 >>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>=20 >>>> An attacker may be a master device which is not certified for >>>> use by the relevant regulatory body. The attacker may listen to >>>> the communication between a valid master device and white space >>>> database and utilize the information about available channels >>>> in the response message by utilizing those channels. The result >>>> of such an attack is unauthorized use of channels by a master >>>> device which is not certified to operate. >>>> The master device querying the white space database may be >>>> operated by a law-enforcement agency and the communications >>>> between the device and the database are intended to be kept >>>> private. A malicious device should not be able to eavesdrop on >>>> such communications. >>>>=20 >>>> Threat 6: Third party tracking of white space device location and >>>> identity >>>>=20 >>>> A white space database may require a master device to provide >>>> its identity in addition to its location in the query request. >>>> Such location/identity information can be gleaned by an >>>> eavesdropper. A master device may prefer to keep the >>>> location/identity information secret. Hence the protocol should >>>> provide a means to protect the location and identity >>>> information of the master device and prevent tracking of >>>> locations associated with a white space database. If >>>> regulations do not require the identity of the master device to >>>> be provided to the white space database, the master is not >>>> required to include its identity in the query. >>>>=20 >>>>=20 >>>> Threat 7: Termination of device service for reasons other than >>>> incumbent protection >>>>=20 >>>> A white space database may include a mechanism by which service >>>> and channels allocated to a master device can be revoked. A >>>> malicious node can send a revoke message to a master >>>> device. This results in denial of service to the master >>>> device. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> 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 Fri Feb 3 12:31:46 2012 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 DDF1621F858E for ; Fri, 3 Feb 2012 12:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.118 X-Spam-Level: X-Spam-Status: No, score=-103.118 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5h11gI6Hy4G8 for ; Fri, 3 Feb 2012 12:31:46 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 55E1921F858B for ; Fri, 3 Feb 2012 12:31:46 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13KVFii024680; Fri, 3 Feb 2012 22:31:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 22:31:29 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 21:31:28 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmA//+dMoCAAGh2AP//oPgA Date: Fri, 3 Feb 2012 20:31:27 +0000 Message-ID: In-Reply-To: <66B79228-C0EF-4290-8F95-43CD5481E0D5@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B5920B2D3FEBB4EB906D47769D7D643@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 20:31:29.0296 (UTC) FILETIME=[CF111100:01CCE2B2] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 20:31:47 -0000 How about the following revised text for Threat 1: Threat 1: User modifies a device to masquerade as another valid certified device Regulatory environments require that devices be certified and register in ways that accurately reflect their certification. Without suitable protection mechanisms, devices could simply listen to registration exchanges, and later registering claiming to be those other devices. Such replays would allow fasle registration, violating regulatory regimes. A white space database may be operated by a commercial entity which restricts access to authorized users. A master device needs to identify itself to the database and be authorized to obtain information about available channels. From brian.rosen@neustar.biz Fri Feb 3 12:32:59 2012 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 1932521F85F1 for ; Fri, 3 Feb 2012 12:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.23 X-Spam-Level: X-Spam-Status: No, score=-6.23 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfpljsaF+hUI for ; Fri, 3 Feb 2012 12:32:58 -0800 (PST) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id E7D8821F85FB for ; Fri, 3 Feb 2012 12:32:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1328301179; x=1643648665; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=fTXtLRq/yPn+hBSVK5AMU mRfd2Ew8X9FVVxiErIPJ6g=; b=HTwvwWv4wCeOYpO/UFKs2JpXFSLd3erLFzQHz hISDKFNoNXgeFf7FNE04nCqdCvUGJSB3zcq74PrOZqToYBtqQ== Received: from ([10.31.13.228]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.3281342; Fri, 03 Feb 2012 15:32:58 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Fri, 3 Feb 2012 15:32:52 -0500 From: "Rosen, Brian" Date: Fri, 3 Feb 2012 15:32:51 -0500 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AcziswAaR684ayvTQbynJEG0PYG9xQ== Message-ID: References: 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: h0Rq4S+VHKYMbT0G6uO9sg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: "" Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 20:32:59 -0000 WFM On Feb 3, 2012, at 3:31 PM, wrote: >=20 > How about the following revised text for Threat 1: >=20 > Threat 1: User modifies a device to masquerade as another valid > certified device >=20 > Regulatory environments require that devices be certified and > register in ways that accurately reflect their certification. > Without suitable protection mechanisms, devices could simply > listen to registration exchanges, and later registering > claiming to be those other devices. Such replays would allow > fasle registration, violating regulatory regimes. > A white space database may be operated by a commercial entity > which restricts access to authorized users. A master device > needs to identify itself to the database and be authorized to > obtain information about available channels. >=20 >=20 >=20 >=20 From stephen.farrell@cs.tcd.ie Fri Feb 3 12:48:10 2012 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 BC0C221F85A3 for ; Fri, 3 Feb 2012 12:48:10 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWWtDfZyt6tF for ; Fri, 3 Feb 2012 12:48:00 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 8BBAB21F85F1 for ; Fri, 3 Feb 2012 12:48:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id D461A171C9E; Fri, 3 Feb 2012 20:47:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h=date :subject:from:x-mailer:message-id:content-type :content-transfer-encoding:mime-version:in-reply-to:references :received:received:x-virus-scanned; s=cs; t=1328302075; bh=UHmAZ ZgAYGqk/YdZEoyHm9DUp0h3fbg94gWUswNwd2Y=; b=XDlgSOtWYVsBmWQ51JcNn /I1OZ4GzNqa4iiwAGBcX8Do04sJsg0M0uM+ACZFCKQhGjr0dptcMvk5DzYmPr1CN 4Jhu86XwCuFaKRgavuVZ9MyG4BpVrE9+wTTLl94+grdViqAAHGsoE7JBNW7Iap+G dTnBTEtCKeXe7xC/dVp03/mUZnMwrdklMqR3sxy5FAYAGG9YLJ7QWIivDWCSlWvW B/+VPsjEiwxt3vg0XxsuTC8i2ohZvB/PwUCBbgDURuUlWrwdIGglCOCf6tBkuYRA pVyrdaN0sqYeEvFlUtsnIGxAf0Tz8TYTELE12/qYqGUNHxHFvoHsVjjJmscbA+Ij A== 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 ap51J5FnkCEi; Fri, 3 Feb 2012 20:47:55 +0000 (GMT) Received: from [10.87.48.5] (unknown [86.44.75.73]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DF10B171C06; Fri, 3 Feb 2012 20:47:54 +0000 (GMT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <2B0DC0CC-08BB-42F3-BE2E-B4FBFB420573@cs.tcd.ie> X-Mailer: iPhone Mail (9A405) From: Stephen Farrell Date: Fri, 3 Feb 2012 20:47:53 +0000 To: "Rosen, Brian" Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 20:48:10 -0000 Isn't "needs to" wrong? "MAY need to" would seem much better S On 3 Feb 2012, at 20:32, "Rosen, Brian" wrote: > WFM > On Feb 3, 2012, at 3:31 PM, wrote: > >> >> How about the following revised text for Threat 1: >> >> Threat 1: User modifies a device to masquerade as another valid >> certified device >> >> Regulatory environments require that devices be certified and >> register in ways that accurately reflect their certification. >> Without suitable protection mechanisms, devices could simply >> listen to registration exchanges, and later registering >> claiming to be those other devices. Such replays would allow >> fasle registration, violating regulatory regimes. >> A white space database may be operated by a commercial entity >> which restricts access to authorized users. A master device >> needs to identify itself to the database and be authorized to >> obtain information about available channels. >> >> >> >> > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Fri Feb 3 12:51:02 2012 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 5373921F860D for ; Fri, 3 Feb 2012 12:51:02 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qs5K2gDHjVv8 for ; Fri, 3 Feb 2012 12:51:01 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B094221F85F4 for ; Fri, 3 Feb 2012 12:51:01 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13KowIJ008396; Fri, 3 Feb 2012 22:50:58 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 22:50:57 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 21:50:56 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmA//+dMoCAAGh2AP//oPgAgABk/YCAAAQzgP//nEUA Date: Fri, 3 Feb 2012 20:50:55 +0000 Message-ID: In-Reply-To: <2B0DC0CC-08BB-42F3-BE2E-B4FBFB420573@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 20:50:57.0684 (UTC) FILETIME=[877AED40:01CCE2B5] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 20:51:02 -0000 Agree.=20 S/A master device needs to identify itself to the database and be authorized to obtain information about available channels./A master device May need to identify itself to the database and be authorized to obtain information about available channels. On 2/3/12 2:47 PM, "ext Stephen Farrell" wrote: > >Isn't "needs to" wrong? "MAY need to" would seem much better > >S > >On 3 Feb 2012, at 20:32, "Rosen, Brian" wrote: > >> WFM >> On Feb 3, 2012, at 3:31 PM, wrote: >>=20 >>>=20 >>> How about the following revised text for Threat 1: >>>=20 >>> Threat 1: User modifies a device to masquerade as another valid >>> certified device >>>=20 >>> Regulatory environments require that devices be certified and >>> register in ways that accurately reflect their certification. >>> Without suitable protection mechanisms, devices could simply >>> listen to registration exchanges, and later registering >>> claiming to be those other devices. Such replays would allow >>> fasle registration, violating regulatory regimes. >>> A white space database may be operated by a commercial entity >>> which restricts access to authorized users. A master device >>> needs to identify itself to the database and be authorized to >>> obtain information about available channels. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Fri Feb 3 13:41:56 2012 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 543D221F85E6 for ; Fri, 3 Feb 2012 13:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7q1UI5oqiBy for ; Fri, 3 Feb 2012 13:41:54 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3386721F8552 for ; Fri, 3 Feb 2012 13:41:49 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13LfjrG000623 for ; Fri, 3 Feb 2012 23:41:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 23:41:45 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 22:41:45 +0100 From: To: Thread-Topic: UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) Thread-Index: AQHM4ryf5uLLQgfWlUG94XlZz/QApQ== Date: Fri, 3 Feb 2012 21:41:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 21:41:45.0781 (UTC) FILETIME=[A0499E50:01CCE2BC] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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, 03 Feb 2012 21:41:56 -0000 Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for section on the Hotspot use case (new section numbering is NOT shown, all use cases will be moved to section 4.2 Use cases in the next version). This text has been marked up from version-02 as uploaded January 26, 2012 as follows: * now includes steps to change the availability of spectrum on short notice * clarification that in some cases a master may initialize over a white space channel * clarification that registration includes device location * clarification on the possible parameters in the channel request * clarification on the possible parameters in the channel response Our goal is that any discussion on this text will conclude by February 10. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 4.3. Hotspot: urban internet connectivity service In this use case internet connectivity service is provided in a "hotspot" to local users. Typical deployment scenarios include urban areas where internet connectivity is provided to local businesses and residents, and campus environments where internet connectivity is provided to local buildings and relatively small outdoor areas. This deployment scenario is typically characterized by multiple masters (APs or hotspots) in close proximity, with low antenna height, cells with relatively small radius (a few kilometers or less), and limited numbers of available radio channels. Many of the masters/APs are assumed to be individually deployed and operated, i.e. there is no coordination between many of the masters/APs. The masters/APs in this scenario use a TDD radio technology and transmit at or below a relatively low transmit power threshold. Each master/AP has a connection to the internet and provides internet connectivity to multiple master and or slave devices. The figure below shows an example deployment of this scenario. -------- |Device|\ \|/ ---------- | 1 | (TDD AirIF) | |Database| -------- \ | .---. /--------- o \ |-|---------| ( ) / o | Master | / \ o / | |=3D=3D=3D=3D=3D=3D=3D=3D( Interne= t ) o / |-----------| \ / -------- (TDD AirIF) ( ) |Device| / (----) | n | -------- Figure 3: Hotspot service using TV white space spectrum Once a master/AP has been correctly installed and configured, a simplified power up and operation scenario utilizing TV White Space to provide Internet connectivity service to slave devices, including the ability to clear WSDs from select channels, is described. This scenario consists of the following steps: 1. The master/AP powers up; however its WS radio and all other WS capable devices will power up in idle/listen only mode (no active transmissions on the WS frequency band). A local regulator may identify exception cases where a Master may initialize over white space (e.g. the FCC allows a Master to initialize over TV white space in certain conditions)." 2. The master/AP has Internet connectivity , determines its location (either from location determination capability or from saved value that was set during installation), and establishes a connection to a trusted white space database (see Section 4.1 reference is to database discovery, will be updated in next version). 3. The master/AP registers with the trusted database according to regulatory domain requirements (see Section 4.2 reference is to registration, will be updated in next version). 4. Following the successful registration process, the master/AP will send a query to the trusted database requesting a list of available WS channels based upon its geolocation. The complete set of parameters to be provided from the Master to the database is specified by the local regulator. Parameters may include WSD location, accuracy of of that location, device antenna height, device identifier of a slave device requesting channel information. 5. If the master/AP has met all regulatory domain requirements (e.g. been previously authenticated, etc), the database responds with a list of available white space channels that the master may use, and optionally a duration of time for their use, associated maximum power levels or a notification of any additional requirement for sensing. 6. Once the master/AP has met all regulatory domain requirements (e.g. authenticated the WS channel list response message from the database, etc), the AP selects an available WS channel(s) from the list. 7. The slave or user device scans the TV bands to locate a master/AP transmission, and associates with the AP. insert new step 8. The slave/user device queries the master for a channel list, providing to the master the slaves' Device ID and optionally its geolocation. 9. Once the master/AP has met all regulatory domain requirements (e.g. validating the Device ID with the trusted database, etc) the master provides the list of channels locally available to the slave/user device. If the channel that the user terminal is currently using is not included in the list of locally available channels, the slave/user device ceases all operation on its current channel. The slave/user device may scan for another AP transmission on a different channel. 10. The master/AP must periodically repeat the process to request a channel list from the database, steps 4 through 6 above. The frequency to repeat the process is determined by the local regulator. If the response from the database indicates a channel being used by the master/AP is not available, the master/AP must stop transmitting on that channel immediately.In addition or optionally, the database may send a message to the master/AP to rescind the availability of one or more channels. The master/AP must stop transmitting on that channel immediately. 11. The slave or user device must periodically repeat the process to request a channel list from the master/AP, steps 8 and 9 above. The frequency to repeat the process is determined by the local regulator. If the response from the master/AP indicates that a channel being used by the slave or user device is not available, the slave or user device must stop transmitting on that channel immediately. In addition or optionally, the database may send a message to the master/AP to rescind the availability of one or more channels. The master/AP must then notify the slave or user device of the rescinded channels. The slave or user device must stop transmitting on that channel immediately. From scott.probasco@nokia.com Fri Feb 3 13:57:19 2012 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 020AC21F8452 for ; Fri, 3 Feb 2012 13:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHUWhlSJ30kS for ; Fri, 3 Feb 2012 13:57:17 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 861941F0C36 for ; Fri, 3 Feb 2012 13:57:17 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13LvEsO011255 for ; Fri, 3 Feb 2012 23:57:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 23:57:13 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 22:57:12 +0100 From: To: Thread-Topic: UC&R I-D: section 4.7 (Rapid deployed network for emergency scenario) Thread-Index: AQHM4r7Ifh1FdeX1hUm9X+st9k2fZA== Date: Fri, 3 Feb 2012 21:57:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 21:57:13.0619 (UTC) FILETIME=[C9527630:01CCE2BE] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: section 4.7 (Rapid deployed network for emergency scenario) 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, 03 Feb 2012 21:57:19 -0000 Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for section on the rapid deployed network for emergency scenario use case (new section numbering is NOT shown, all use cases will be moved to section 4.2 Use cases in the next version). This text has been marked up from version-02 as uploaded January 26, 2012 as follows: * changed the terms "free" and "freed" as discussed on email reflector Our goal is that any discussion on this text will conclude by February 10. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 4.7. Rapid deployed network for emergency scenario Organizations involved in handling emergency operations often have a fully owned and controlled infrastructure, with dedicated spectrum, for day to day operation. However, lessons learned from recent disasters show such infrastructures are often highly affected by the disaster itself. To set up a replacement quickly, there is a need for fast reallocation of spectrum, where in certain cases spectrum can be freedcleared for disaster relief. To utilize freeunused or freedcleared spectrum quickly and reliable, automation of allocation, assignment and configuration is needed. A preferred option is make use of a robust protocol, already adopted by radio manufacturers. This approach does in no way imply such organizations for disaster relief must compete on spectrum allocation with other white spaces users, but they can. A typical network topology would include wireless access links to the public Internet or private network, wireless ad hoc network radios working independent of a fixed infrastructure and satellite links for backup where lack of coverage, overload or outage of wireless access links occur. \|/ | ad hoc | |-|-------------| | Master node | |------------| \|/ | with | | Whitespace | | ad hoc /| backhaul link | | Database | | /------/ |---------------| |------------| ---|------------/ | \ / | Master node | | | (--/--) | without | | ------( ) | backhaul link | | Wireless / Private \ ----------------\ | Access ( net or ) \ | \ Internet ) \ \|/ | -------( /\ \ | ad hoc | | (------) \--------- \ | | / | Other | \--|------------- /Satellite | nodes | | Master node | / Link ---------- | with |/ | backhaul link | ----------------- Figure 7: Rapid deployed network with partly connected nodes In the ad hoc network, all nodes are master nodes in a way that they allocate RF channels from the white space database. However, the backhaul link may not be available to all nodes, such as depicted for the left node in the figure. To handle RF channel allocation for such nodes, a master node with a backhaul link relays or proxies the database query for them. So master nodes without a backhaul link follow the procedure as defined for clients. The ad hoc network radios utilise the provided RF channels. Details on forming and maintenance of the ad hoc network, including repair of segmented networks caused by segments operating on different RF channels, is out of scope of spectrum allocation. From paul@marvell.com Fri Feb 3 14:26:23 2012 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 97D5A21F8555 for ; Fri, 3 Feb 2012 14:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.309 X-Spam-Level: X-Spam-Status: No, score=-6.309 tagged_above=-999 required=5 tests=[AWL=0.290, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1R1+Avcj-TRy for ; Fri, 3 Feb 2012 14:26:22 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id E491D21F8552 for ; Fri, 3 Feb 2012 14:26:21 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKTyxe/xojOi4iBFm5oorn8RENfoCJyGXe@postini.com; Fri, 03 Feb 2012 14:26:22 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 3 Feb 2012 14:26:06 -0800 From: Paul Lambert To: "Joel M. Halpern" , "Rosen, Brian" Date: Fri, 3 Feb 2012 14:26:05 -0800 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AczirrByJJDlGaBWRAW8UdILIVuVZgAEePLw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F34@SC-VEXCH2.marvell.com> References: <4F2C3AB5.2070306@joelhalpern.com> <6E9FB277-9969-490B-AFCC-03BD0190AE75@neustar.biz> <4F2C3CE9.9080902@joelhalpern.com> In-Reply-To: <4F2C3CE9.9080902@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 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 22:26:23 -0000 >>> Threat 7: Termination of device service for reasons other than >>> incumbent protection >>> >>> A white space database may include a mechanism by which service >>> and channels allocated to a master device can be revoked. A >>> malicious node can send a revoke message to a master >>> device. This results in denial of service to the master >>> device. No clue what you mean by "malicious node" ... this could be a Database, Mas= ter, random MiM, etc.=20 I was really thinking more about the misuse of the Database, or Master to: - turn off devices presumed to be violating the DCMA - limiting spectrum usage based on the type or purpose of the traffic (e.g= . Oakland BART) - limitation of spectrum usage based on political affiliation, race, gende= r, ideology,=20 individual identity, etc. We may not be able to prevent (at a protocol level) unfair allocation or di= sablement. We should at least be able to have adequate logging and records = that given an expectation of fair allocation - we can detect and complain w= hen our mobile devices are turned off. Paul >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Joel M. Halpern >Sent: Friday, February 03, 2012 12:01 PM >To: Rosen, Brian >Cc: paws@ietf.org >Subject: Re: [paws] Threat model (Rev 3) > >In the unauthorized use section, there is still the text saying: > The attacker may listen to > the communication between a valid master device and white space > database and utilize the information about available channels > in the response message by utilizing those channels. > >I still find this totally mind-bending, as it is about the hardest way >imaginable to undertake this attack. > > >On 2/3/2012 2:55 PM, Rosen, Brian wrote: >> >> Where do you see this assumption in the threat model? >> >> I took a quick look and didn't spot it. It would be "database >information leaked to bad guys" or something like it, right? >> >> I don't think that is a threat, and I don't think we need to protect >anyone from that threat. >> >> I would say, however, that if you could know the content of the >database, and you can observe a responses over a period of time, you may >be able to infer the location of the querier. >> >> Brian >> >> >> On Feb 3, 2012, at 2:51 PM, Joel M. Halpern wrote: >> >>> Can we please include in this document some articulation of the >>> confidentiality assumption we are making with regard to the >whitespace >>> data itself? I am not trying to object to the threats. (And the >>> personal information collection issues are enough to jsutify include >>> confidentiality mechanisms in the solutions.) >>> But I am still trying to get my head around this. There are going to >be >>> hoards of whitespace devices. They will be getting the data, and >either >>> using it themselves or retransmitting it. The resulting data one >>> whitespace availability will be visible to people and or devices >which >>> are not completely controlled by the regulatory agencies. >>> As such, what is the role of confidentiality with regard to this >>> information? >>> >>> Yours, >>> Joel >>> >>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>> >>>> Below is Rev 3 of the threat model based on feedback from Stephen, >Nancy >>>> and Gabor (Thanks). >>>> >>>> -Raj >>>> >>>> >>>> Rev 3 (3/2/12) >>>> >>>> Threat model for the PAWS protocol >>>> ---------------------------------- >>>> >>>> Assumptions: >>>> ............ >>>> >>>> o It is assumed that an attacker has full access to the network >medium >>>> between the master device and the white space database. The >attacker >>>> may be able to eavesdrop on any communications between these >>>> entities. The link between the master device and the white space >>>> database can be wired or wireless and provides IP connectivity. >>>> >>>> o It is assumed that the master device or the white space database >>>> have NOT been compromised from a security standpoint. >>>> >>>> Threat 1: User modifies a device to masquerade as another valid >>>> certified device >>>> >>>> The master device needs to authenticate itself with the >white >>>> space database prior to requesting channel information. The >>>> attacker may try to get access to the secrets of the master >>>> device which can be used maliciously. The effect of such an >>>> attack being successful would result in a malicious client >>>> replaying the stolen authentication/authorization secrets to >a >>>> white space database. >>>> >>>> Threat 2: Spoofed white space database >>>> >>>> A master device discovers a white space database(s) thru >which >>>> it can query for channel information. The master device >needs >>>> to ensure that the white space database with which it >>>> communicates with is an authentic entity. The white space >>>> database needs to provide its identity to the master device >>>> which can confirm the validity/authenticty of the database. >An >>>> attacker may attempt to spoof a white space database and >>>> provide responses to a master device which are malicious and >>>> result in the master device causing interference to the >primary >>>> user of the spectrum. >>>> >>>> Threat 3: Modifying a query request >>>> >>>> An attacker may modify the query request sent by a master >>>> device to a white space database. The attacker may change >the >>>> location of the device or the capabilities in terms of its >>>> transmit power or antenna height etc. which could result in >the >>>> database responding with incorrect information about >available >>>> channels or max transmit power allowed. The result of such >an >>>> attack is that the master device would cause intereference >to >>>> the primary user of the spectrum. It could also result in a >>>> denial of service to the master device by indicating that no >>>> channels are available. >>>> >>>> Threat 4: Modifying a query response >>>> >>>> An attacker could modify the query response sent by the >white >>>> space database to a master device. The channel information >or >>>> transmit power allowed type of parameters carried in the >>>> response could be modified by the attacker resulting in the >>>> master device using channels that are not available at a >>>> location or transmitting at a greater power level than >allowed >>>> resulting in interference to the primary user of that >>>> spectrum. Alternatively the attacker may indicate no channel >>>> availability at a location resulting in a denial of service >to >>>> the master device. >>>> >>>> Threat 5: Unauthorized use of channels by an uncertified device >>>> >>>> An attacker may be a master device which is not certified >for >>>> use by the relevant regulatory body. The attacker may listen >to >>>> the communication between a valid master device and white >space >>>> database and utilize the information about available >channels >>>> in the response message by utilizing those channels. The >result >>>> of such an attack is unauthorized use of channels by a >master >>>> device which is not certified to operate. >>>> The master device querying the white space database may be >>>> operated by a law-enforcement agency and the communications >>>> between the device and the database are intended to be kept >>>> private. A malicious device should not be able to eavesdrop >on >>>> such communications. >>>> >>>> Threat 6: Third party tracking of white space device location and >identity >>>> >>>> A white space database may require a master device to >provide >>>> its identity in addition to its location in the query >request. >>>> Such location/identity information can be gleaned by an >>>> eavesdropper. A master device may prefer to keep the >>>> location/identity information secret. Hence the protocol >should >>>> provide a means to protect the location and identity >>>> information of the master device and prevent tracking of >>>> locations associated with a white space database. If >>>> regulations do not require the identity of the master device >to >>>> be provided to the white space database, the master is not >>>> required to include its identity in the query. >>>> >>>> >>>> Threat 7: Termination of device service for reasons other than >>>> incumbent protection >>>> >>>> A white space database may include a mechanism by which >service >>>> and channels allocated to a master device can be revoked. A >>>> malicious node can send a revoke message to a master >>>> device. This results in denial of service to the master >>>> device. >>>> >>>> >>>> _______________________________________________ >>>> 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 Fri Feb 3 14:35:24 2012 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 0A7FF21F859E for ; Fri, 3 Feb 2012 14:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hHhZIzNFLZn for ; Fri, 3 Feb 2012 14:35:23 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A121F858F for ; Fri, 3 Feb 2012 14:35:22 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q13MZHfp006421; Sat, 4 Feb 2012 00:35:17 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Feb 2012 00:35:17 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Fri, 3 Feb 2012 23:35:16 +0100 From: To: , , Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YA= Date: Fri, 3 Feb 2012 22:35:15 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F34@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0856F713E48BC641A1278B96843EF4CE@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 22:35:17.0268 (UTC) FILETIME=[1A7BA540:01CCE2C4] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 22:35:24 -0000 Hi Paul. On 2/3/12 4:26 PM, "ext Paul Lambert" wrote: > >>>> Threat 7: Termination of device service for reasons other than >>>> incumbent protection >>>> >>>> A white space database may include a mechanism by which >>>>service >>>> and channels allocated to a master device can be revoked. A >>>> malicious node can send a revoke message to a master >>>> device. This results in denial of service to the master >>>> device. > >No clue what you mean by "malicious node" ... this could be a Database, >Master, random MiM, etc. My interpretation of the additional threat you had suggested in a previous email=8A. The point about this threat is that we have discussed about the possibility of the database having the capability to send an unsolicited push notification (to the master device) for revoking the previously allocated channels and ceasing operation. So the "malicious node" in this case is an entity which pretends to be the database and sends such a push notification message to the master device. >=20 > >I was really thinking more about the misuse of the Database, or Master to: > - turn off devices presumed to be violating the DCMA DCMA? The aspect of a device being switched off is covered in this threat. > - limiting spectrum usage based on the type or purpose of the traffic >(e.g. Oakland BART) > - limitation of spectrum usage based on political affiliation, race, >gender, ideology,=20 > individual identity, etc. I don't get the above two. Care to expand on these? > >We may not be able to prevent (at a protocol level) unfair allocation or >disablement. We should at least be able to have adequate logging and >records that given an expectation of fair allocation - we can detect and >complain when our mobile devices are turned off. So do we need to capture this in the form of a threat? Do we want to have a requirement that the protocol needs to enable logging and record keeping? That=B9s more of an implementation issue. -Raj > >Paul > > > > > >>-----Original Message----- >>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>Joel M. Halpern >>Sent: Friday, February 03, 2012 12:01 PM >>To: Rosen, Brian >>Cc: paws@ietf.org >>Subject: Re: [paws] Threat model (Rev 3) >> >>In the unauthorized use section, there is still the text saying: >> The attacker may listen to >> the communication between a valid master device and white space >> database and utilize the information about available channels >> in the response message by utilizing those channels. >> >>I still find this totally mind-bending, as it is about the hardest way >>imaginable to undertake this attack. >> >> >>On 2/3/2012 2:55 PM, Rosen, Brian wrote: >>> >>> Where do you see this assumption in the threat model? >>> >>> I took a quick look and didn't spot it. It would be "database >>information leaked to bad guys" or something like it, right? >>> >>> I don't think that is a threat, and I don't think we need to protect >>anyone from that threat. >>> >>> I would say, however, that if you could know the content of the >>database, and you can observe a responses over a period of time, you may >>be able to infer the location of the querier. >>> >>> Brian >>> >>> >>> On Feb 3, 2012, at 2:51 PM, Joel M. Halpern wrote: >>> >>>> Can we please include in this document some articulation of the >>>> confidentiality assumption we are making with regard to the >>whitespace >>>> data itself? I am not trying to object to the threats. (And the >>>> personal information collection issues are enough to jsutify include >>>> confidentiality mechanisms in the solutions.) >>>> But I am still trying to get my head around this. There are going to >>be >>>> hoards of whitespace devices. They will be getting the data, and >>either >>>> using it themselves or retransmitting it. The resulting data one >>>> whitespace availability will be visible to people and or devices >>which >>>> are not completely controlled by the regulatory agencies. >>>> As such, what is the role of confidentiality with regard to this >>>> information? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>> >>>>> Below is Rev 3 of the threat model based on feedback from Stephen, >>Nancy >>>>> and Gabor (Thanks). >>>>> >>>>> -Raj >>>>> >>>>> >>>>> Rev 3 (3/2/12) >>>>> >>>>> Threat model for the PAWS protocol >>>>> ---------------------------------- >>>>> >>>>> Assumptions: >>>>> ............ >>>>> >>>>> o It is assumed that an attacker has full access to the network >>medium >>>>> between the master device and the white space database. The >>attacker >>>>> may be able to eavesdrop on any communications between these >>>>> entities. The link between the master device and the white space >>>>> database can be wired or wireless and provides IP connectivity. >>>>> >>>>> o It is assumed that the master device or the white space database >>>>> have NOT been compromised from a security standpoint. >>>>> >>>>> Threat 1: User modifies a device to masquerade as another valid >>>>> certified device >>>>> >>>>> The master device needs to authenticate itself with the >>white >>>>> space database prior to requesting channel information. The >>>>> attacker may try to get access to the secrets of the master >>>>> device which can be used maliciously. The effect of such an >>>>> attack being successful would result in a malicious client >>>>> replaying the stolen authentication/authorization secrets to >>a >>>>> white space database. >>>>> >>>>> Threat 2: Spoofed white space database >>>>> >>>>> A master device discovers a white space database(s) thru >>which >>>>> it can query for channel information. The master device >>needs >>>>> to ensure that the white space database with which it >>>>> communicates with is an authentic entity. The white space >>>>> database needs to provide its identity to the master device >>>>> which can confirm the validity/authenticty of the database. >>An >>>>> attacker may attempt to spoof a white space database and >>>>> provide responses to a master device which are malicious and >>>>> result in the master device causing interference to the >>primary >>>>> user of the spectrum. >>>>> >>>>> Threat 3: Modifying a query request >>>>> >>>>> An attacker may modify the query request sent by a master >>>>> device to a white space database. The attacker may change >>the >>>>> location of the device or the capabilities in terms of its >>>>> transmit power or antenna height etc. which could result in >>the >>>>> database responding with incorrect information about >>available >>>>> channels or max transmit power allowed. The result of such >>an >>>>> attack is that the master device would cause intereference >>to >>>>> the primary user of the spectrum. It could also result in a >>>>> denial of service to the master device by indicating that no >>>>> channels are available. >>>>> >>>>> Threat 4: Modifying a query response >>>>> >>>>> An attacker could modify the query response sent by the >>white >>>>> space database to a master device. The channel information >>or >>>>> transmit power allowed type of parameters carried in the >>>>> response could be modified by the attacker resulting in the >>>>> master device using channels that are not available at a >>>>> location or transmitting at a greater power level than >>allowed >>>>> resulting in interference to the primary user of that >>>>> spectrum. Alternatively the attacker may indicate no channel >>>>> availability at a location resulting in a denial of service >>to >>>>> the master device. >>>>> >>>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>> >>>>> An attacker may be a master device which is not certified >>for >>>>> use by the relevant regulatory body. The attacker may listen >>to >>>>> the communication between a valid master device and white >>space >>>>> database and utilize the information about available >>channels >>>>> in the response message by utilizing those channels. The >>result >>>>> of such an attack is unauthorized use of channels by a >>master >>>>> device which is not certified to operate. >>>>> The master device querying the white space database may be >>>>> operated by a law-enforcement agency and the communications >>>>> between the device and the database are intended to be kept >>>>> private. A malicious device should not be able to eavesdrop >>on >>>>> such communications. >>>>> >>>>> Threat 6: Third party tracking of white space device location and >>identity >>>>> >>>>> A white space database may require a master device to >>provide >>>>> its identity in addition to its location in the query >>request. >>>>> Such location/identity information can be gleaned by an >>>>> eavesdropper. A master device may prefer to keep the >>>>> location/identity information secret. Hence the protocol >>should >>>>> provide a means to protect the location and identity >>>>> information of the master device and prevent tracking of >>>>> locations associated with a white space database. If >>>>> regulations do not require the identity of the master device >>to >>>>> be provided to the white space database, the master is not >>>>> required to include its identity in the query. >>>>> >>>>> >>>>> Threat 7: Termination of device service for reasons other than >>>>> incumbent protection >>>>> >>>>> A white space database may include a mechanism by which >>service >>>>> and channels allocated to a master device can be revoked. A >>>>> malicious node can send a revoke message to a master >>>>> device. This results in denial of service to the master >>>>> device. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 paul@marvell.com Fri Feb 3 14:58:20 2012 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 4ADC611E8088 for ; Fri, 3 Feb 2012 14:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYlbV87Jay3F for ; Fri, 3 Feb 2012 14:58:19 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF3921F846C for ; Fri, 3 Feb 2012 14:58:18 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTyxmhS+FmzfvT5Als4ItqjdjyPFaWODM@postini.com; Fri, 03 Feb 2012 14:58:18 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 3 Feb 2012 14:58:12 -0800 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" , "jmh@joelhalpern.com" , "Brian.Rosen@neustar.biz" Date: Fri, 3 Feb 2012 14:58:11 -0800 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4A== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F43@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F34@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="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 22:58:20 -0000 Hi Raj, First - a threat needs an actor or source. We seem to have different views= of possible sources. >>>>> Threat 7: Termination of device service for reasons other than >>>>> incumbent protection Termination of device service is the end-impact (a useful starting point, b= ut not exactly the threat).=20 Some of the associated threat events are: a) Government (related to regulatory authority or not) uses WS Database to= terminate or unfairly limit spectrum access of devices for reasons other than incumbent protection. b) Service provider or DB provider uses WS Database to terminate or unfair= ly limit spectrum access of devices for reasons other than incumbent protection. c) Owner of a Master device uses WS Database to terminate or unfairly limi= t spectrum access of devices for reasons other than incumbent protection. d) Malicious individual acts as a PAWS entity (spoofing DB or as MiM) to t= erminate or unfairly limit spectrum access of devices for reasons other than incumbent protection e) Natural disaster knocks out communications to the database preventing s= pectrum access. It seems silly for us to rush so quickly into building the fastest possible= kill switch for communications. Push notifications are a cool mechanisms,= but we also need some level of assurance that we will have continuity of u= sage of a set of channels. Ideally we'd have some looser limits on the on-= channel times.=20 Paul >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Friday, February 03, 2012 2:35 PM >To: Paul Lambert; jmh@joelhalpern.com; Brian.Rosen@neustar.biz >Cc: paws@ietf.org >Subject: Re: [paws] Threat model (Rev 3) > > >Hi Paul. > >On 2/3/12 4:26 PM, "ext Paul Lambert" wrote: > >> >>>>> Threat 7: Termination of device service for reasons other than >>>>> incumbent protection >>>>> >>>>> A white space database may include a mechanism by which >>>>>service >>>>> and channels allocated to a master device can be revoked. A >>>>> malicious node can send a revoke message to a master >>>>> device. This results in denial of service to the master >>>>> device. >> >>No clue what you mean by "malicious node" ... this could be a Database, >>Master, random MiM, etc. > >My interpretation of the additional threat you had suggested in a >previous >email=D0. >The point about this threat is that we have discussed about the >possibility of the database having the capability to send an unsolicited >push notification (to the master device) for revoking the previously >allocated channels and ceasing operation. >So the "malicious node" in this case is an entity which pretends to be >the >database and sends such a push notification message to the master >device. > >> >> >>I was really thinking more about the misuse of the Database, or Master >to: >> - turn off devices presumed to be violating the DCMA > >DCMA? >The aspect of a device being switched off is covered in this threat. > >> - limiting spectrum usage based on the type or purpose of the traffic >>(e.g. Oakland BART) >> - limitation of spectrum usage based on political affiliation, race, >>gender, ideology, >> individual identity, etc. > >I don't get the above two. Care to expand on these? > >> >>We may not be able to prevent (at a protocol level) unfair allocation >or >>disablement. We should at least be able to have adequate logging and >>records that given an expectation of fair allocation - we can detect >and >>complain when our mobile devices are turned off. > >So do we need to capture this in the form of a threat? Do we want to >have >a requirement that the protocol needs to enable logging and record >keeping? That=B9s more of an implementation issue. > >-Raj > >> >>Paul >> >> >> >> >> >>>-----Original Message----- >>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >Of >>>Joel M. Halpern >>>Sent: Friday, February 03, 2012 12:01 PM >>>To: Rosen, Brian >>>Cc: paws@ietf.org >>>Subject: Re: [paws] Threat model (Rev 3) >>> >>>In the unauthorized use section, there is still the text saying: >>> The attacker may listen to >>> the communication between a valid master device and white >space >>> database and utilize the information about available channels >>> in the response message by utilizing those channels. >>> >>>I still find this totally mind-bending, as it is about the hardest way >>>imaginable to undertake this attack. >>> >>> >>>On 2/3/2012 2:55 PM, Rosen, Brian wrote: >>>> >>>> Where do you see this assumption in the threat model? >>>> >>>> I took a quick look and didn't spot it. It would be "database >>>information leaked to bad guys" or something like it, right? >>>> >>>> I don't think that is a threat, and I don't think we need to protect >>>anyone from that threat. >>>> >>>> I would say, however, that if you could know the content of the >>>database, and you can observe a responses over a period of time, you >may >>>be able to infer the location of the querier. >>>> >>>> Brian >>>> >>>> >>>> On Feb 3, 2012, at 2:51 PM, Joel M. Halpern wrote: >>>> >>>>> Can we please include in this document some articulation of the >>>>> confidentiality assumption we are making with regard to the >>>whitespace >>>>> data itself? I am not trying to object to the threats. (And the >>>>> personal information collection issues are enough to jsutify >include >>>>> confidentiality mechanisms in the solutions.) >>>>> But I am still trying to get my head around this. There are going >to >>>be >>>>> hoards of whitespace devices. They will be getting the data, and >>>either >>>>> using it themselves or retransmitting it. The resulting data one >>>>> whitespace availability will be visible to people and or devices >>>which >>>>> are not completely controlled by the regulatory agencies. >>>>> As such, what is the role of confidentiality with regard to this >>>>> information? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>>> >>>>>> Below is Rev 3 of the threat model based on feedback from Stephen, >>>Nancy >>>>>> and Gabor (Thanks). >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> Rev 3 (3/2/12) >>>>>> >>>>>> Threat model for the PAWS protocol >>>>>> ---------------------------------- >>>>>> >>>>>> Assumptions: >>>>>> ............ >>>>>> >>>>>> o It is assumed that an attacker has full access to the network >>>medium >>>>>> between the master device and the white space database. The >>>attacker >>>>>> may be able to eavesdrop on any communications between these >>>>>> entities. The link between the master device and the white >space >>>>>> database can be wired or wireless and provides IP connectivity. >>>>>> >>>>>> o It is assumed that the master device or the white space database >>>>>> have NOT been compromised from a security standpoint. >>>>>> >>>>>> Threat 1: User modifies a device to masquerade as another valid >>>>>> certified device >>>>>> >>>>>> The master device needs to authenticate itself with the >>>white >>>>>> space database prior to requesting channel information. >The >>>>>> attacker may try to get access to the secrets of the >master >>>>>> device which can be used maliciously. The effect of such >an >>>>>> attack being successful would result in a malicious client >>>>>> replaying the stolen authentication/authorization secrets >to >>>a >>>>>> white space database. >>>>>> >>>>>> Threat 2: Spoofed white space database >>>>>> >>>>>> A master device discovers a white space database(s) thru >>>which >>>>>> it can query for channel information. The master device >>>needs >>>>>> to ensure that the white space database with which it >>>>>> communicates with is an authentic entity. The white space >>>>>> database needs to provide its identity to the master >device >>>>>> which can confirm the validity/authenticty of the >database. >>>An >>>>>> attacker may attempt to spoof a white space database and >>>>>> provide responses to a master device which are malicious >and >>>>>> result in the master device causing interference to the >>>primary >>>>>> user of the spectrum. >>>>>> >>>>>> Threat 3: Modifying a query request >>>>>> >>>>>> An attacker may modify the query request sent by a master >>>>>> device to a white space database. The attacker may change >>>the >>>>>> location of the device or the capabilities in terms of its >>>>>> transmit power or antenna height etc. which could result >in >>>the >>>>>> database responding with incorrect information about >>>available >>>>>> channels or max transmit power allowed. The result of such >>>an >>>>>> attack is that the master device would cause intereference >>>to >>>>>> the primary user of the spectrum. It could also result in >a >>>>>> denial of service to the master device by indicating that >no >>>>>> channels are available. >>>>>> >>>>>> Threat 4: Modifying a query response >>>>>> >>>>>> An attacker could modify the query response sent by the >>>white >>>>>> space database to a master device. The channel information >>>or >>>>>> transmit power allowed type of parameters carried in the >>>>>> response could be modified by the attacker resulting in >the >>>>>> master device using channels that are not available at a >>>>>> location or transmitting at a greater power level than >>>allowed >>>>>> resulting in interference to the primary user of that >>>>>> spectrum. Alternatively the attacker may indicate no >channel >>>>>> availability at a location resulting in a denial of >service >>>to >>>>>> the master device. >>>>>> >>>>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>>> >>>>>> An attacker may be a master device which is not certified >>>for >>>>>> use by the relevant regulatory body. The attacker may >listen >>>to >>>>>> the communication between a valid master device and white >>>space >>>>>> database and utilize the information about available >>>channels >>>>>> in the response message by utilizing those channels. The >>>result >>>>>> of such an attack is unauthorized use of channels by a >>>master >>>>>> device which is not certified to operate. >>>>>> The master device querying the white space database may be >>>>>> operated by a law-enforcement agency and the >communications >>>>>> between the device and the database are intended to be >kept >>>>>> private. A malicious device should not be able to >eavesdrop >>>on >>>>>> such communications. >>>>>> >>>>>> Threat 6: Third party tracking of white space device location and >>>identity >>>>>> >>>>>> A white space database may require a master device to >>>provide >>>>>> its identity in addition to its location in the query >>>request. >>>>>> Such location/identity information can be gleaned by an >>>>>> eavesdropper. A master device may prefer to keep the >>>>>> location/identity information secret. Hence the protocol >>>should >>>>>> provide a means to protect the location and identity >>>>>> information of the master device and prevent tracking of >>>>>> locations associated with a white space database. If >>>>>> regulations do not require the identity of the master >device >>>to >>>>>> be provided to the white space database, the master is not >>>>>> required to include its identity in the query. >>>>>> >>>>>> >>>>>> Threat 7: Termination of device service for reasons other than >>>>>> incumbent protection >>>>>> >>>>>> A white space database may include a mechanism by which >>>service >>>>>> and channels allocated to a master device can be revoked. >A >>>>>> malicious node can send a revoke message to a master >>>>>> device. This results in denial of service to the master >>>>>> device. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 paul@marvell.com Fri Feb 3 15:04:41 2012 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 3FC4A11E8088 for ; Fri, 3 Feb 2012 15:04:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.362 X-Spam-Level: X-Spam-Status: No, score=-6.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUR0WmCRhqLm for ; Fri, 3 Feb 2012 15:04:40 -0800 (PST) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by ietfa.amsl.com (Postfix) with ESMTP id E2A1421F84D6 for ; Fri, 3 Feb 2012 15:04:39 -0800 (PST) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTyxoASjFSMUMMDNAwUpDXMcY3INSicts@postini.com; Fri, 03 Feb 2012 15:04:40 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Fri, 3 Feb 2012 15:03:33 -0800 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" , "stephen.farrell@cs.tcd.ie" , "paws@ietf.org" Date: Fri, 3 Feb 2012 15:03:32 -0800 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YryiWQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F4D@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] Threat model (Rev 3) 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, 03 Feb 2012 23:04:41 -0000 > Threat 3: Modifying a query response Not a threat ... perhaps a vulnerability if restated. =20 Suggest as a mechanism - any modification or spoofing of paws messages all = look about the same from the threat model. It's the actor, and end impact t= hat is interesting. Paul >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Basavaraj.Patil@nokia.com >Sent: Friday, February 03, 2012 11:34 AM >To: stephen.farrell@cs.tcd.ie; paws@ietf.org >Subject: Re: [paws] Threat model (Rev 3) > > >Below is Rev 3 of the threat model based on feedback from Stephen, Nancy >and Gabor (Thanks). > >-Raj > > >Rev 3 (3/2/12) > >Threat model for the PAWS protocol >---------------------------------- > >Assumptions: >............ > >o It is assumed that an attacker has full access to the network medium > between the master device and the white space database. The attacker > may be able to eavesdrop on any communications between these > entities. The link between the master device and the white space > database can be wired or wireless and provides IP connectivity. > >o It is assumed that the master device or the white space database > have NOT been compromised from a security standpoint. > >Threat 1: User modifies a device to masquerade as another valid > certified device > > The master device needs to authenticate itself with the white > space database prior to requesting channel information. The > attacker may try to get access to the secrets of the master > device which can be used maliciously. The effect of such an > attack being successful would result in a malicious client > replaying the stolen authentication/authorization secrets to a > white space database. > >Threat 2: Spoofed white space database > > A master device discovers a white space database(s) thru which > it can query for channel information. The master device needs > to ensure that the white space database with which it > communicates with is an authentic entity. The white space > database needs to provide its identity to the master device > which can confirm the validity/authenticty of the database. An > attacker may attempt to spoof a white space database and > provide responses to a master device which are malicious and > result in the master device causing interference to the primary > user of the spectrum. > >Threat 3: Modifying a query request > > An attacker may modify the query request sent by a master > device to a white space database. The attacker may change the > location of the device or the capabilities in terms of its > transmit power or antenna height etc. which could result in the > database responding with incorrect information about available > channels or max transmit power allowed. The result of such an > attack is that the master device would cause intereference to > the primary user of the spectrum. It could also result in a > denial of service to the master device by indicating that no > channels are available. > >Threat 4: Modifying a query response > > An attacker could modify the query response sent by the white > space database to a master device. The channel information or > transmit power allowed type of parameters carried in the > response could be modified by the attacker resulting in the > master device using channels that are not available at a > location or transmitting at a greater power level than allowed > resulting in interference to the primary user of that > spectrum. Alternatively the attacker may indicate no channel > availability at a location resulting in a denial of service to > the master device. > >Threat 5: Unauthorized use of channels by an uncertified device > > An attacker may be a master device which is not certified for > use by the relevant regulatory body. The attacker may listen to > the communication between a valid master device and white space > database and utilize the information about available channels > in the response message by utilizing those channels. The result > of such an attack is unauthorized use of channels by a master > device which is not certified to operate. > The master device querying the white space database may be > operated by a law-enforcement agency and the communications > between the device and the database are intended to be kept > private. A malicious device should not be able to eavesdrop on > such communications. > >Threat 6: Third party tracking of white space device location and >identity > > A white space database may require a master device to provide > its identity in addition to its location in the query request. > Such location/identity information can be gleaned by an > eavesdropper. A master device may prefer to keep the > location/identity information secret. Hence the protocol should > provide a means to protect the location and identity > information of the master device and prevent tracking of > locations associated with a white space database. If > regulations do not require the identity of the master device to > be provided to the white space database, the master is not > required to include its identity in the query. > > >Threat 7: Termination of device service for reasons other than > incumbent protection > > A white space database may include a mechanism by which service > and channels allocated to a master device can be revoked. A > malicious node can send a revoke message to a master > device. This results in denial of service to the master > device. > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Fri Feb 3 15:20:40 2012 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 352E021F8603 for ; Fri, 3 Feb 2012 15:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sFjn2ZYoCBGW for ; Fri, 3 Feb 2012 15:20:39 -0800 (PST) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4990421F85E6 for ; Fri, 3 Feb 2012 15:20:27 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKTyxrt/rjvUQK3jTVll3PrUyJyD9C6j77@postini.com; Fri, 03 Feb 2012 15:20:27 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 3 Feb 2012 15:19:30 -0800 From: Paul Lambert To: "Joel M. Halpern" , "Basavaraj.Patil@nokia.com" Date: Fri, 3 Feb 2012 15:19:29 -0800 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AczirTu0bVgeKWBFR5+3gm4Jj2g2XAAG7pFA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F54@SC-VEXCH2.marvell.com> References: <4F2C3AB5.2070306@joelhalpern.com> In-Reply-To: <4F2C3AB5.2070306@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 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 23:20:40 -0000 >using it themselves or retransmitting it. The resulting data one >whitespace availability will be visible to people and or devices which >are not completely controlled by the regulatory agencies. >As such, what is the role of confidentiality with regard to this >information? All channel availability (at least for the FCC) is openly available. There= is no threat of disclosure of this information. It's actually the reverse= . For planning purposes to buy and use WS devices - you really would like = a good picture of available spectrum. It would be very detremental to mark= et adoption to limit access to the available channels. That said - the current incumbants we discuss are just TV and microphones. = In the future, we might be sharing with public saftey or military applicat= ions that would not want readily accessable maps of their locations dissemi= nated. "Open" consumer devices might in these scenarios see no spectrum an= d the approved devices would get allocations. This still should be out-of-= scope. These types of devices are not in our use case scenarios. Privacy as you point out alone is a good justification for some form of con= fidentiality. But protecting a devices identity may not require encryption= of the full paws messages. Intgrity and data origin authentication seem more important for the protoco= l design considerations. =20 Paul >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Joel M. Halpern >Sent: Friday, February 03, 2012 11:51 AM >To: Basavaraj.Patil@nokia.com >Cc: paws@ietf.org >Subject: Re: [paws] Threat model (Rev 3) > >Can we please include in this document some articulation of the >confidentiality assumption we are making with regard to the whitespace >data itself? I am not trying to object to the threats. (And the >personal information collection issues are enough to jsutify include >confidentiality mechanisms in the solutions.) >But I am still trying to get my head around this. There are going to be >hoards of whitespace devices. They will be getting the data, and either >using it themselves or retransmitting it. The resulting data one >whitespace availability will be visible to people and or devices which >are not completely controlled by the regulatory agencies. >As such, what is the role of confidentiality with regard to this >information? > >Yours, >Joel > >On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >> >> Below is Rev 3 of the threat model based on feedback from Stephen, >Nancy >> and Gabor (Thanks). >> >> -Raj >> >> >> Rev 3 (3/2/12) >> >> Threat model for the PAWS protocol >> ---------------------------------- >> >> Assumptions: >> ............ >> >> o It is assumed that an attacker has full access to the network medium >> between the master device and the white space database. The >attacker >> may be able to eavesdrop on any communications between these >> entities. The link between the master device and the white space >> database can be wired or wireless and provides IP connectivity. >> >> o It is assumed that the master device or the white space database >> have NOT been compromised from a security standpoint. >> >> Threat 1: User modifies a device to masquerade as another valid >> certified device >> >> The master device needs to authenticate itself with the white >> space database prior to requesting channel information. The >> attacker may try to get access to the secrets of the master >> device which can be used maliciously. The effect of such an >> attack being successful would result in a malicious client >> replaying the stolen authentication/authorization secrets to a >> white space database. >> >> Threat 2: Spoofed white space database >> >> A master device discovers a white space database(s) thru which >> it can query for channel information. The master device needs >> to ensure that the white space database with which it >> communicates with is an authentic entity. The white space >> database needs to provide its identity to the master device >> which can confirm the validity/authenticty of the database. An >> attacker may attempt to spoof a white space database and >> provide responses to a master device which are malicious and >> result in the master device causing interference to the >primary >> user of the spectrum. >> >> Threat 3: Modifying a query request >> >> An attacker may modify the query request sent by a master >> device to a white space database. The attacker may change the >> location of the device or the capabilities in terms of its >> transmit power or antenna height etc. which could result in >the >> database responding with incorrect information about available >> channels or max transmit power allowed. The result of such an >> attack is that the master device would cause intereference to >> the primary user of the spectrum. It could also result in a >> denial of service to the master device by indicating that no >> channels are available. >> >> Threat 4: Modifying a query response >> >> An attacker could modify the query response sent by the white >> space database to a master device. The channel information or >> transmit power allowed type of parameters carried in the >> response could be modified by the attacker resulting in the >> master device using channels that are not available at a >> location or transmitting at a greater power level than allowed >> resulting in interference to the primary user of that >> spectrum. Alternatively the attacker may indicate no channel >> availability at a location resulting in a denial of service to >> the master device. >> >> Threat 5: Unauthorized use of channels by an uncertified device >> >> An attacker may be a master device which is not certified for >> use by the relevant regulatory body. The attacker may listen >to >> the communication between a valid master device and white >space >> database and utilize the information about available channels >> in the response message by utilizing those channels. The >result >> of such an attack is unauthorized use of channels by a master >> device which is not certified to operate. >> The master device querying the white space database may be >> operated by a law-enforcement agency and the communications >> between the device and the database are intended to be kept >> private. A malicious device should not be able to eavesdrop on >> such communications. >> >> Threat 6: Third party tracking of white space device location and >identity >> >> A white space database may require a master device to provide >> its identity in addition to its location in the query request. >> Such location/identity information can be gleaned by an >> eavesdropper. A master device may prefer to keep the >> location/identity information secret. Hence the protocol >should >> provide a means to protect the location and identity >> information of the master device and prevent tracking of >> locations associated with a white space database. If >> regulations do not require the identity of the master device >to >> be provided to the white space database, the master is not >> required to include its identity in the query. >> >> >> Threat 7: Termination of device service for reasons other than >> incumbent protection >> >> A white space database may include a mechanism by which >service >> and channels allocated to a master device can be revoked. A >> malicious node can send a revoke message to a master >> device. This results in denial of service to the master >> device. >> >> >> _______________________________________________ >> 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 stephen.farrell@cs.tcd.ie Fri Feb 3 15:42:52 2012 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 8899F21F850D for ; Fri, 3 Feb 2012 15:42:52 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Rf6XOetoBGW for ; Fri, 3 Feb 2012 15:42:47 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3883421F84EE for ; Fri, 3 Feb 2012 15:42:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 81A78171C9E for ; Fri, 3 Feb 2012 23:42:34 +0000 (GMT) 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=1328312553; bh=oDfbtxBwcAgtfV 0nxpSpZmmO4LSH/ongeSCDtrw0HjQ=; b=E2fucDM8md9geu/QC37ohiQY3P1Ijb UcwJJMGFeEqHHGIEnP22JO997+K1cfZ+QZELTfxCxC6hm0OZfCDIfkeIHJi8NUfL iD1ol4lvx89mPAPZ32ZuFQLnlRiTAL5oXd0omvqBlT1xw7DB/DvHy9saMjPTFj3Z 88V6G8Gb7NK/9+SMCwa1Sr9hTF61Q3nN5xmpIs70zoedabHexhr2gYeDs36Q0GlG lkHcp6SJGQH0q7qWAIyFdwznk7V/uT/E0uHq7ab6eSrL9nMYSClJRDNOic3fxQRv LQ2kfxWw3Ov07QNgBlP8rFpwSwB/JbwT1AMMnVMXLE5qmzPvTejwHGhw== 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 ZtM87Rs2W46X for ; Fri, 3 Feb 2012 23:42:33 +0000 (GMT) Received: from [10.87.48.10] (unknown [86.41.5.156]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AE1EF171C06 for ; Fri, 3 Feb 2012 23:42:33 +0000 (GMT) Message-ID: <4F2C70E8.2020205@cs.tcd.ie> Date: Fri, 03 Feb 2012 23:42:32 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "paws@ietf.org" References: <4F2C3AB5.2070306@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01567763F54@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F54@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) 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, 03 Feb 2012 23:42:52 -0000 So this is a bit of a side-issue maybe but I do wonder if there's any functional/technical reason, other than "the FCC said so," to identify a specific device in the paws protocol with a long-lived identifier? I can see why you'd want a device type of some sort, and the DB might need some kind of session ID, but I don't get the long-lived device identifier thing at all as a functional requirement. Can anyone explain? I'm not asking now from the privacy or security p-o-v, but rather because its easier and cheaper and simpler to not bother if you don't have to. It does also interact with privacy & security of course. Once you have to manage the identifier then you may need to go to some trouble to protect that, but that's a secondary question. Thanks, S. On 02/03/2012 11:19 PM, Paul Lambert wrote: >> using it themselves or retransmitting it. The resulting data one >> whitespace availability will be visible to people and or devices which >> are not completely controlled by the regulatory agencies. >> As such, what is the role of confidentiality with regard to this >> information? > > All channel availability (at least for the FCC) is openly available. There is no threat of disclosure of this information. It's actually the reverse. For planning purposes to buy and use WS devices - you really would like a good picture of available spectrum. It would be very detremental to market adoption to limit access to the available channels. > > That said - the current incumbants we discuss are just TV and microphones. In the future, we might be sharing with public saftey or military applications that would not want readily accessable maps of their locations disseminated. "Open" consumer devices might in these scenarios see no spectrum and the approved devices would get allocations. This still should be out-of-scope. These types of devices are not in our use case scenarios. > > Privacy as you point out alone is a good justification for some form of confidentiality. But protecting a devices identity may not require encryption of the full paws messages. > > Intgrity and data origin authentication seem more important for the protocol design considerations. > > Paul > > >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> Joel M. Halpern >> Sent: Friday, February 03, 2012 11:51 AM >> To: Basavaraj.Patil@nokia.com >> Cc: paws@ietf.org >> Subject: Re: [paws] Threat model (Rev 3) >> >> Can we please include in this document some articulation of the >> confidentiality assumption we are making with regard to the whitespace >> data itself? I am not trying to object to the threats. (And the >> personal information collection issues are enough to jsutify include >> confidentiality mechanisms in the solutions.) >> But I am still trying to get my head around this. There are going to be >> hoards of whitespace devices. They will be getting the data, and either >> using it themselves or retransmitting it. The resulting data one >> whitespace availability will be visible to people and or devices which >> are not completely controlled by the regulatory agencies. >> As such, what is the role of confidentiality with regard to this >> information? >> >> Yours, >> Joel >> >> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>> >>> Below is Rev 3 of the threat model based on feedback from Stephen, >> Nancy >>> and Gabor (Thanks). >>> >>> -Raj >>> >>> >>> Rev 3 (3/2/12) >>> >>> Threat model for the PAWS protocol >>> ---------------------------------- >>> >>> Assumptions: >>> ............ >>> >>> o It is assumed that an attacker has full access to the network medium >>> between the master device and the white space database. The >> attacker >>> may be able to eavesdrop on any communications between these >>> entities. The link between the master device and the white space >>> database can be wired or wireless and provides IP connectivity. >>> >>> o It is assumed that the master device or the white space database >>> have NOT been compromised from a security standpoint. >>> >>> Threat 1: User modifies a device to masquerade as another valid >>> certified device >>> >>> The master device needs to authenticate itself with the white >>> space database prior to requesting channel information. The >>> attacker may try to get access to the secrets of the master >>> device which can be used maliciously. The effect of such an >>> attack being successful would result in a malicious client >>> replaying the stolen authentication/authorization secrets to a >>> white space database. >>> >>> Threat 2: Spoofed white space database >>> >>> A master device discovers a white space database(s) thru which >>> it can query for channel information. The master device needs >>> to ensure that the white space database with which it >>> communicates with is an authentic entity. The white space >>> database needs to provide its identity to the master device >>> which can confirm the validity/authenticty of the database. An >>> attacker may attempt to spoof a white space database and >>> provide responses to a master device which are malicious and >>> result in the master device causing interference to the >> primary >>> user of the spectrum. >>> >>> Threat 3: Modifying a query request >>> >>> An attacker may modify the query request sent by a master >>> device to a white space database. The attacker may change the >>> location of the device or the capabilities in terms of its >>> transmit power or antenna height etc. which could result in >> the >>> database responding with incorrect information about available >>> channels or max transmit power allowed. The result of such an >>> attack is that the master device would cause intereference to >>> the primary user of the spectrum. It could also result in a >>> denial of service to the master device by indicating that no >>> channels are available. >>> >>> Threat 4: Modifying a query response >>> >>> An attacker could modify the query response sent by the white >>> space database to a master device. The channel information or >>> transmit power allowed type of parameters carried in the >>> response could be modified by the attacker resulting in the >>> master device using channels that are not available at a >>> location or transmitting at a greater power level than allowed >>> resulting in interference to the primary user of that >>> spectrum. Alternatively the attacker may indicate no channel >>> availability at a location resulting in a denial of service to >>> the master device. >>> >>> Threat 5: Unauthorized use of channels by an uncertified device >>> >>> An attacker may be a master device which is not certified for >>> use by the relevant regulatory body. The attacker may listen >> to >>> the communication between a valid master device and white >> space >>> database and utilize the information about available channels >>> in the response message by utilizing those channels. The >> result >>> of such an attack is unauthorized use of channels by a master >>> device which is not certified to operate. >>> The master device querying the white space database may be >>> operated by a law-enforcement agency and the communications >>> between the device and the database are intended to be kept >>> private. A malicious device should not be able to eavesdrop on >>> such communications. >>> >>> Threat 6: Third party tracking of white space device location and >> identity >>> >>> A white space database may require a master device to provide >>> its identity in addition to its location in the query request. >>> Such location/identity information can be gleaned by an >>> eavesdropper. A master device may prefer to keep the >>> location/identity information secret. Hence the protocol >> should >>> provide a means to protect the location and identity >>> information of the master device and prevent tracking of >>> locations associated with a white space database. If >>> regulations do not require the identity of the master device >> to >>> be provided to the white space database, the master is not >>> required to include its identity in the query. >>> >>> >>> Threat 7: Termination of device service for reasons other than >>> incumbent protection >>> >>> A white space database may include a mechanism by which >> service >>> and channels allocated to a master device can be revoked. A >>> malicious node can send a revoke message to a master >>> device. This results in denial of service to the master >>> device. >>> >>> >>> _______________________________________________ >>> 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 nbravin@earthlink.net Fri Feb 3 15:49:48 2012 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 839CF21F85D8 for ; Fri, 3 Feb 2012 15:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.508 X-Spam-Level: X-Spam-Status: No, score=-2.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPyf22j4ESdN for ; Fri, 3 Feb 2012 15:49:46 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 5A21821F85A2 for ; Fri, 3 Feb 2012 15:49:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=CW3G7lM1hVb8b2TSXzBPdYdQx2cLY4YjoAsZvtjDRWpmPie1bgGYsbDWwePBvq6Y; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RtSsg-0001tw-Mq; Fri, 03 Feb 2012 18:49:27 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F43@SC-VEXCH2.marvell.com> Date: Fri, 3 Feb 2012 15:49:25 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3460547E-3705-457C-B9CF-43A1C9AC969A@earthlink.net> References: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F34@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01567763F43@SC-VEXCH2.marvell.com> To: Paul Lambert X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8615dc91b0b679a23c5b9c2f61407a7a65350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 03 Feb 2012 23:49:48 -0000 I am in favor of a kill switch, and agree with Paul, further, the = scenarios must be severe to cut communications totally, or they are cut = as in e) where there is no access. Any other potential threats can be defined that warrant its use as he has, to me, explained = well.=20 Sincerely, Nancy On Feb 3, 2012, at 2:58 PM, Paul Lambert wrote: >=20 > Hi Raj, >=20 > First - a threat needs an actor or source. We seem to have different = views of possible sources. >=20 >>>>>> Threat 7: Termination of device service for reasons other than >>>>>> incumbent protection > Termination of device service is the end-impact (a useful starting = point, but not exactly the threat).=20 >=20 >=20 > Some of the associated threat events are: >=20 > a) Government (related to regulatory authority or not) uses WS = Database to terminate or unfairly limit > spectrum access of devices for reasons other than incumbent = protection. > b) Service provider or DB provider uses WS Database to terminate or = unfairly limit > spectrum access of devices for reasons other than incumbent = protection. > c) Owner of a Master device uses WS Database to terminate or unfairly = limit > spectrum access of devices for reasons other than incumbent = protection. > d) Malicious individual acts as a PAWS entity (spoofing DB or as MiM) = to terminate or unfairly limit > spectrum access of devices for reasons other than incumbent = protection > e) Natural disaster knocks out communications to the database = preventing spectrum access. >=20 >=20 > It seems silly for us to rush so quickly into building the fastest = possible kill switch for communications. Push notifications are a cool = mechanisms, but we also need some level of assurance that we will have = continuity of usage of a set of channels. Ideally we'd have some looser = limits on the on-channel times.=20 >=20 > Paul >=20 >=20 >=20 >> -----Original Message----- >> From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >> Sent: Friday, February 03, 2012 2:35 PM >> To: Paul Lambert; jmh@joelhalpern.com; Brian.Rosen@neustar.biz >> Cc: paws@ietf.org >> Subject: Re: [paws] Threat model (Rev 3) >>=20 >>=20 >> Hi Paul. >>=20 >> On 2/3/12 4:26 PM, "ext Paul Lambert" wrote: >>=20 >>>=20 >>>>>> Threat 7: Termination of device service for reasons other than >>>>>> incumbent protection >>>>>>=20 >>>>>> A white space database may include a mechanism by which >>>>>> service >>>>>> and channels allocated to a master device can be revoked. = A >>>>>> malicious node can send a revoke message to a master >>>>>> device. This results in denial of service to the master >>>>>> device. >>>=20 >>> No clue what you mean by "malicious node" ... this could be a = Database, >>> Master, random MiM, etc. >>=20 >> My interpretation of the additional threat you had suggested in a >> previous >> email=8A. >> The point about this threat is that we have discussed about the >> possibility of the database having the capability to send an = unsolicited >> push notification (to the master device) for revoking the previously >> allocated channels and ceasing operation. >> So the "malicious node" in this case is an entity which pretends to = be >> the >> database and sends such a push notification message to the master >> device. >>=20 >>>=20 >>>=20 >>> I was really thinking more about the misuse of the Database, or = Master >> to: >>> - turn off devices presumed to be violating the DCMA >>=20 >> DCMA? >> The aspect of a device being switched off is covered in this threat. >>=20 >>> - limiting spectrum usage based on the type or purpose of the = traffic >>> (e.g. Oakland BART) >>> - limitation of spectrum usage based on political affiliation, race, >>> gender, ideology, >>> individual identity, etc. >>=20 >> I don't get the above two. Care to expand on these? >>=20 >>>=20 >>> We may not be able to prevent (at a protocol level) unfair = allocation >> or >>> disablement. We should at least be able to have adequate logging and >>> records that given an expectation of fair allocation - we can detect >> and >>> complain when our mobile devices are turned off. >>=20 >> So do we need to capture this in the form of a threat? Do we want to >> have >> a requirement that the protocol needs to enable logging and record >> keeping? That=B9s more of an implementation issue. >>=20 >> -Raj >>=20 >>>=20 >>> Paul >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf >> Of >>>> Joel M. Halpern >>>> Sent: Friday, February 03, 2012 12:01 PM >>>> To: Rosen, Brian >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] Threat model (Rev 3) >>>>=20 >>>> In the unauthorized use section, there is still the text saying: >>>> The attacker may listen to >>>> the communication between a valid master device and white >> space >>>> database and utilize the information about available channels >>>> in the response message by utilizing those channels. >>>>=20 >>>> I still find this totally mind-bending, as it is about the hardest = way >>>> imaginable to undertake this attack. >>>>=20 >>>>=20 >>>> On 2/3/2012 2:55 PM, Rosen, Brian wrote: >>>>> >>>>> Where do you see this assumption in the threat model? >>>>>=20 >>>>> I took a quick look and didn't spot it. It would be "database >>>> information leaked to bad guys" or something like it, right? >>>>>=20 >>>>> I don't think that is a threat, and I don't think we need to = protect >>>> anyone from that threat. >>>>>=20 >>>>> I would say, however, that if you could know the content of the >>>> database, and you can observe a responses over a period of time, = you >> may >>>> be able to infer the location of the querier. >>>>>=20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> On Feb 3, 2012, at 2:51 PM, Joel M. Halpern wrote: >>>>>=20 >>>>>> Can we please include in this document some articulation of the >>>>>> confidentiality assumption we are making with regard to the >>>> whitespace >>>>>> data itself? I am not trying to object to the threats. (And the >>>>>> personal information collection issues are enough to jsutify >> include >>>>>> confidentiality mechanisms in the solutions.) >>>>>> But I am still trying to get my head around this. There are = going >> to >>>> be >>>>>> hoards of whitespace devices. They will be getting the data, and >>>> either >>>>>> using it themselves or retransmitting it. The resulting data one >>>>>> whitespace availability will be visible to people and or devices >>>> which >>>>>> are not completely controlled by the regulatory agencies. >>>>>> As such, what is the role of confidentiality with regard to this >>>>>> information? >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>>>>=20 >>>>>>> Below is Rev 3 of the threat model based on feedback from = Stephen, >>>> Nancy >>>>>>> and Gabor (Thanks). >>>>>>>=20 >>>>>>> -Raj >>>>>>>=20 >>>>>>>=20 >>>>>>> Rev 3 (3/2/12) >>>>>>>=20 >>>>>>> Threat model for the PAWS protocol >>>>>>> ---------------------------------- >>>>>>>=20 >>>>>>> Assumptions: >>>>>>> ............ >>>>>>>=20 >>>>>>> o It is assumed that an attacker has full access to the network >>>> medium >>>>>>> between the master device and the white space database. The >>>> attacker >>>>>>> may be able to eavesdrop on any communications between these >>>>>>> entities. The link between the master device and the white >> space >>>>>>> database can be wired or wireless and provides IP = connectivity. >>>>>>>=20 >>>>>>> o It is assumed that the master device or the white space = database >>>>>>> have NOT been compromised from a security standpoint. >>>>>>>=20 >>>>>>> Threat 1: User modifies a device to masquerade as another valid >>>>>>> certified device >>>>>>>=20 >>>>>>> The master device needs to authenticate itself with the >>>> white >>>>>>> space database prior to requesting channel information. >> The >>>>>>> attacker may try to get access to the secrets of the >> master >>>>>>> device which can be used maliciously. The effect of such >> an >>>>>>> attack being successful would result in a malicious = client >>>>>>> replaying the stolen authentication/authorization secrets >> to >>>> a >>>>>>> white space database. >>>>>>>=20 >>>>>>> Threat 2: Spoofed white space database >>>>>>>=20 >>>>>>> A master device discovers a white space database(s) thru >>>> which >>>>>>> it can query for channel information. The master device >>>> needs >>>>>>> to ensure that the white space database with which it >>>>>>> communicates with is an authentic entity. The white space >>>>>>> database needs to provide its identity to the master >> device >>>>>>> which can confirm the validity/authenticty of the >> database. >>>> An >>>>>>> attacker may attempt to spoof a white space database and >>>>>>> provide responses to a master device which are malicious >> and >>>>>>> result in the master device causing interference to the >>>> primary >>>>>>> user of the spectrum. >>>>>>>=20 >>>>>>> Threat 3: Modifying a query request >>>>>>>=20 >>>>>>> An attacker may modify the query request sent by a master >>>>>>> device to a white space database. The attacker may change >>>> the >>>>>>> location of the device or the capabilities in terms of = its >>>>>>> transmit power or antenna height etc. which could result >> in >>>> the >>>>>>> database responding with incorrect information about >>>> available >>>>>>> channels or max transmit power allowed. The result of = such >>>> an >>>>>>> attack is that the master device would cause = intereference >>>> to >>>>>>> the primary user of the spectrum. It could also result in >> a >>>>>>> denial of service to the master device by indicating that >> no >>>>>>> channels are available. >>>>>>>=20 >>>>>>> Threat 4: Modifying a query response >>>>>>>=20 >>>>>>> An attacker could modify the query response sent by the >>>> white >>>>>>> space database to a master device. The channel = information >>>> or >>>>>>> transmit power allowed type of parameters carried in the >>>>>>> response could be modified by the attacker resulting in >> the >>>>>>> master device using channels that are not available at a >>>>>>> location or transmitting at a greater power level than >>>> allowed >>>>>>> resulting in interference to the primary user of that >>>>>>> spectrum. Alternatively the attacker may indicate no >> channel >>>>>>> availability at a location resulting in a denial of >> service >>>> to >>>>>>> the master device. >>>>>>>=20 >>>>>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>>>>=20 >>>>>>> An attacker may be a master device which is not certified >>>> for >>>>>>> use by the relevant regulatory body. The attacker may >> listen >>>> to >>>>>>> the communication between a valid master device and white >>>> space >>>>>>> database and utilize the information about available >>>> channels >>>>>>> in the response message by utilizing those channels. The >>>> result >>>>>>> of such an attack is unauthorized use of channels by a >>>> master >>>>>>> device which is not certified to operate. >>>>>>> The master device querying the white space database may = be >>>>>>> operated by a law-enforcement agency and the >> communications >>>>>>> between the device and the database are intended to be >> kept >>>>>>> private. A malicious device should not be able to >> eavesdrop >>>> on >>>>>>> such communications. >>>>>>>=20 >>>>>>> Threat 6: Third party tracking of white space device location = and >>>> identity >>>>>>>=20 >>>>>>> A white space database may require a master device to >>>> provide >>>>>>> its identity in addition to its location in the query >>>> request. >>>>>>> Such location/identity information can be gleaned by an >>>>>>> eavesdropper. A master device may prefer to keep the >>>>>>> location/identity information secret. Hence the protocol >>>> should >>>>>>> provide a means to protect the location and identity >>>>>>> information of the master device and prevent tracking of >>>>>>> locations associated with a white space database. If >>>>>>> regulations do not require the identity of the master >> device >>>> to >>>>>>> be provided to the white space database, the master is = not >>>>>>> required to include its identity in the query. >>>>>>>=20 >>>>>>>=20 >>>>>>> Threat 7: Termination of device service for reasons other than >>>>>>> incumbent protection >>>>>>>=20 >>>>>>> A white space database may include a mechanism by which >>>> service >>>>>>> and channels allocated to a master device can be revoked. >> A >>>>>>> malicious node can send a revoke message to a master >>>>>>> device. This results in denial of service to the master >>>>>>> device. >>>>>>>=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 >>>>>=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 paul@marvell.com Fri Feb 3 17:43:49 2012 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 ABD3611E80E6 for ; Fri, 3 Feb 2012 17:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TndtminsC7JX for ; Fri, 3 Feb 2012 17:43:48 -0800 (PST) Received: from na3sys009aog107.obsmtp.com (na3sys009aog107.obsmtp.com [74.125.149.197]) by ietfa.amsl.com (Postfix) with ESMTP id EF5EA11E8096 for ; Fri, 3 Feb 2012 17:43:47 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob107.postini.com ([74.125.148.12]) with SMTP ID DSNKTyyNUBfFgeRitBe+gDSuSgeB0uXGW80z@postini.com; Fri, 03 Feb 2012 17:43:48 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 3 Feb 2012 17:43:43 -0800 From: Paul Lambert To: Stephen Farrell , "paws@ietf.org" Date: Fri, 3 Feb 2012 17:43:43 -0800 Thread-Topic: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) Thread-Index: AczizY4o3QIlMVs+SdmfFM7RdIZuCgAB5WKg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01567763FAB@SC-VEXCH2.marvell.com> References: <4F2C3AB5.2070306@joelhalpern.com> <7BAC95F5A7E67643AAFB2C31BEE662D01567763F54@SC-VEXCH2.marvell.com> <4F2C70E8.2020205@cs.tcd.ie> In-Reply-To: <4F2C70E8.2020205@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 Subject: Re: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) 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, 04 Feb 2012 01:43:49 -0000 Good question. If a set of certified devices (vendor / model type) are all supposed to act= the same, then any interference problem could be handled by changing conto= urs or blocking all of the model/types. =20 Paul >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >Stephen Farrell >Sent: Friday, February 03, 2012 3:43 PM >To: paws@ietf.org >Subject: [paws] wondering why a device identifier is needed (was: Re: >Threat model (Rev 3)) > > >So this is a bit of a side-issue maybe but I do wonder >if there's any functional/technical reason, other than >"the FCC said so," to identify a specific device in the >paws protocol with a long-lived identifier? > >I can see why you'd want a device type of some sort, >and the DB might need some kind of session ID, but >I don't get the long-lived device identifier thing >at all as a functional requirement. Can anyone explain? > >I'm not asking now from the privacy or security p-o-v, >but rather because its easier and cheaper and simpler to >not bother if you don't have to. > >It does also interact with privacy & security of course. >Once you have to manage the identifier then you may need >to go to some trouble to protect that, but that's a >secondary question. > >Thanks, >S. > >On 02/03/2012 11:19 PM, Paul Lambert wrote: >>> using it themselves or retransmitting it. The resulting data one >>> whitespace availability will be visible to people and or devices >which >>> are not completely controlled by the regulatory agencies. >>> As such, what is the role of confidentiality with regard to this >>> information? >> >> All channel availability (at least for the FCC) is openly available. >There is no threat of disclosure of this information. It's actually the >reverse. For planning purposes to buy and use WS devices - you really >would like a good picture of available spectrum. It would be very >detremental to market adoption to limit access to the available >channels. >> >> That said - the current incumbants we discuss are just TV and >microphones. In the future, we might be sharing with public saftey or >military applications that would not want readily accessable maps of >their locations disseminated. "Open" consumer devices might in these >scenarios see no spectrum and the approved devices would get >allocations. This still should be out-of-scope. These types of devices >are not in our use case scenarios. >> >> Privacy as you point out alone is a good justification for some form >of confidentiality. But protecting a devices identity may not require >encryption of the full paws messages. >> >> Intgrity and data origin authentication seem more important for the >protocol design considerations. >> >> Paul >> >> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >Of >>> Joel M. Halpern >>> Sent: Friday, February 03, 2012 11:51 AM >>> To: Basavaraj.Patil@nokia.com >>> Cc: paws@ietf.org >>> Subject: Re: [paws] Threat model (Rev 3) >>> >>> Can we please include in this document some articulation of the >>> confidentiality assumption we are making with regard to the >whitespace >>> data itself? I am not trying to object to the threats. (And the >>> personal information collection issues are enough to jsutify include >>> confidentiality mechanisms in the solutions.) >>> But I am still trying to get my head around this. There are going to >be >>> hoards of whitespace devices. They will be getting the data, and >either >>> using it themselves or retransmitting it. The resulting data one >>> whitespace availability will be visible to people and or devices >which >>> are not completely controlled by the regulatory agencies. >>> As such, what is the role of confidentiality with regard to this >>> information? >>> >>> Yours, >>> Joel >>> >>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>> >>>> Below is Rev 3 of the threat model based on feedback from Stephen, >>> Nancy >>>> and Gabor (Thanks). >>>> >>>> -Raj >>>> >>>> >>>> Rev 3 (3/2/12) >>>> >>>> Threat model for the PAWS protocol >>>> ---------------------------------- >>>> >>>> Assumptions: >>>> ............ >>>> >>>> o It is assumed that an attacker has full access to the network >medium >>>> between the master device and the white space database. The >>> attacker >>>> may be able to eavesdrop on any communications between these >>>> entities. The link between the master device and the white space >>>> database can be wired or wireless and provides IP connectivity. >>>> >>>> o It is assumed that the master device or the white space database >>>> have NOT been compromised from a security standpoint. >>>> >>>> Threat 1: User modifies a device to masquerade as another valid >>>> certified device >>>> >>>> The master device needs to authenticate itself with the >white >>>> space database prior to requesting channel information. The >>>> attacker may try to get access to the secrets of the master >>>> device which can be used maliciously. The effect of such an >>>> attack being successful would result in a malicious client >>>> replaying the stolen authentication/authorization secrets >to a >>>> white space database. >>>> >>>> Threat 2: Spoofed white space database >>>> >>>> A master device discovers a white space database(s) thru >which >>>> it can query for channel information. The master device >needs >>>> to ensure that the white space database with which it >>>> communicates with is an authentic entity. The white space >>>> database needs to provide its identity to the master device >>>> which can confirm the validity/authenticty of the database. >An >>>> attacker may attempt to spoof a white space database and >>>> provide responses to a master device which are malicious >and >>>> result in the master device causing interference to the >>> primary >>>> user of the spectrum. >>>> >>>> Threat 3: Modifying a query request >>>> >>>> An attacker may modify the query request sent by a master >>>> device to a white space database. The attacker may change >the >>>> location of the device or the capabilities in terms of its >>>> transmit power or antenna height etc. which could result in >>> the >>>> database responding with incorrect information about >available >>>> channels or max transmit power allowed. The result of such >an >>>> attack is that the master device would cause intereference >to >>>> the primary user of the spectrum. It could also result in a >>>> denial of service to the master device by indicating that >no >>>> channels are available. >>>> >>>> Threat 4: Modifying a query response >>>> >>>> An attacker could modify the query response sent by the >white >>>> space database to a master device. The channel information >or >>>> transmit power allowed type of parameters carried in the >>>> response could be modified by the attacker resulting in the >>>> master device using channels that are not available at a >>>> location or transmitting at a greater power level than >allowed >>>> resulting in interference to the primary user of that >>>> spectrum. Alternatively the attacker may indicate no >channel >>>> availability at a location resulting in a denial of service >to >>>> the master device. >>>> >>>> Threat 5: Unauthorized use of channels by an uncertified device >>>> >>>> An attacker may be a master device which is not certified >for >>>> use by the relevant regulatory body. The attacker may >listen >>> to >>>> the communication between a valid master device and white >>> space >>>> database and utilize the information about available >channels >>>> in the response message by utilizing those channels. The >>> result >>>> of such an attack is unauthorized use of channels by a >master >>>> device which is not certified to operate. >>>> The master device querying the white space database may be >>>> operated by a law-enforcement agency and the communications >>>> between the device and the database are intended to be kept >>>> private. A malicious device should not be able to eavesdrop >on >>>> such communications. >>>> >>>> Threat 6: Third party tracking of white space device location and >>> identity >>>> >>>> A white space database may require a master device to >provide >>>> its identity in addition to its location in the query >request. >>>> Such location/identity information can be gleaned by an >>>> eavesdropper. A master device may prefer to keep the >>>> location/identity information secret. Hence the protocol >>> should >>>> provide a means to protect the location and identity >>>> information of the master device and prevent tracking of >>>> locations associated with a white space database. If >>>> regulations do not require the identity of the master >device >>> to >>>> be provided to the white space database, the master is not >>>> required to include its identity in the query. >>>> >>>> >>>> Threat 7: Termination of device service for reasons other than >>>> incumbent protection >>>> >>>> A white space database may include a mechanism by which >>> service >>>> and channels allocated to a master device can be revoked. A >>>> malicious node can send a revoke message to a master >>>> device. This results in denial of service to the master >>>> device. >>>> >>>> >>>> _______________________________________________ >>>> 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 scott.probasco@nokia.com Fri Feb 3 18:03:24 2012 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 A150311E80A2 for ; Fri, 3 Feb 2012 18:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0gtyHQ-2KhL for ; Fri, 3 Feb 2012 18:03:23 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6267F11E8098 for ; Fri, 3 Feb 2012 18:03:23 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q14237jm004300; Sat, 4 Feb 2012 04:03:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 4 Feb 2012 04:03:07 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Sat, 4 Feb 2012 03:03:06 +0100 From: To: , , Thread-Topic: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) Thread-Index: AQHM4s2RBngGT1NM+kmcIUkz3XesvZYr5nuA//+g0oA= Date: Sat, 4 Feb 2012 02:03:05 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567763FAB@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2012 02:03:07.0645 (UTC) FILETIME=[23682AD0:01CCE2E1] X-Nokia-AV: Clean Subject: Re: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) 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, 04 Feb 2012 02:03:24 -0000 X-List-Received-Date: Sat, 04 Feb 2012 02:03:24 -0000 Hi, A couple of motivations for device-specific identifiers are * ability to black-list or disable a specific device. Regulators are interested in ability to switch off a device that causes interference. Device manufacturers are interested in ability to switch off stolen devices. * ability to directly address a specific device. One example here is the 'kill switch' described by Ofcom. Kind Regards, Scott On 2/3/12 7:43 PM, "ext Paul Lambert" wrote: > >Good question. > >If a set of certified devices (vendor / model type) are all supposed to >act the same, then any interference problem could be handled by changing >contours or blocking all of the model/types. > >Paul > > >>-----Original Message----- >>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>Stephen Farrell >>Sent: Friday, February 03, 2012 3:43 PM >>To: paws@ietf.org >>Subject: [paws] wondering why a device identifier is needed (was: Re: >>Threat model (Rev 3)) >> >> >>So this is a bit of a side-issue maybe but I do wonder >>if there's any functional/technical reason, other than >>"the FCC said so," to identify a specific device in the >>paws protocol with a long-lived identifier? >> >>I can see why you'd want a device type of some sort, >>and the DB might need some kind of session ID, but >>I don't get the long-lived device identifier thing >>at all as a functional requirement. Can anyone explain? >> >>I'm not asking now from the privacy or security p-o-v, >>but rather because its easier and cheaper and simpler to >>not bother if you don't have to. >> >>It does also interact with privacy & security of course. >>Once you have to manage the identifier then you may need >>to go to some trouble to protect that, but that's a >>secondary question. >> >>Thanks, >>S. >> >>On 02/03/2012 11:19 PM, Paul Lambert wrote: >>>> using it themselves or retransmitting it. The resulting data one >>>> whitespace availability will be visible to people and or devices >>which >>>> are not completely controlled by the regulatory agencies. >>>> As such, what is the role of confidentiality with regard to this >>>> information? >>> >>> All channel availability (at least for the FCC) is openly available. >>There is no threat of disclosure of this information. It's actually the >>reverse. For planning purposes to buy and use WS devices - you really >>would like a good picture of available spectrum. It would be very >>detremental to market adoption to limit access to the available >>channels. >>> >>> That said - the current incumbants we discuss are just TV and >>microphones. In the future, we might be sharing with public saftey or >>military applications that would not want readily accessable maps of >>their locations disseminated. "Open" consumer devices might in these >>scenarios see no spectrum and the approved devices would get >>allocations. This still should be out-of-scope. These types of devices >>are not in our use case scenarios. >>> >>> Privacy as you point out alone is a good justification for some form >>of confidentiality. But protecting a devices identity may not require >>encryption of the full paws messages. >>> >>> Intgrity and data origin authentication seem more important for the >>protocol design considerations. >>> >>> Paul >>> >>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>Of >>>> Joel M. Halpern >>>> Sent: Friday, February 03, 2012 11:51 AM >>>> To: Basavaraj.Patil@nokia.com >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] Threat model (Rev 3) >>>> >>>> Can we please include in this document some articulation of the >>>> confidentiality assumption we are making with regard to the >>whitespace >>>> data itself? I am not trying to object to the threats. (And the >>>> personal information collection issues are enough to jsutify include >>>> confidentiality mechanisms in the solutions.) >>>> But I am still trying to get my head around this. There are going to >>be >>>> hoards of whitespace devices. They will be getting the data, and >>either >>>> using it themselves or retransmitting it. The resulting data one >>>> whitespace availability will be visible to people and or devices >>which >>>> are not completely controlled by the regulatory agencies. >>>> As such, what is the role of confidentiality with regard to this >>>> information? >>>> >>>> Yours, >>>> Joel >>>> >>>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>> >>>>> Below is Rev 3 of the threat model based on feedback from Stephen, >>>> Nancy >>>>> and Gabor (Thanks). >>>>> >>>>> -Raj >>>>> >>>>> >>>>> Rev 3 (3/2/12) >>>>> >>>>> Threat model for the PAWS protocol >>>>> ---------------------------------- >>>>> >>>>> Assumptions: >>>>> ............ >>>>> >>>>> o It is assumed that an attacker has full access to the network >>medium >>>>> between the master device and the white space database. The >>>> attacker >>>>> may be able to eavesdrop on any communications between these >>>>> entities. The link between the master device and the white space >>>>> database can be wired or wireless and provides IP connectivity. >>>>> >>>>> o It is assumed that the master device or the white space database >>>>> have NOT been compromised from a security standpoint. >>>>> >>>>> Threat 1: User modifies a device to masquerade as another valid >>>>> certified device >>>>> >>>>> The master device needs to authenticate itself with the >>white >>>>> space database prior to requesting channel information. The >>>>> attacker may try to get access to the secrets of the master >>>>> device which can be used maliciously. The effect of such an >>>>> attack being successful would result in a malicious client >>>>> replaying the stolen authentication/authorization secrets >>to a >>>>> white space database. >>>>> >>>>> Threat 2: Spoofed white space database >>>>> >>>>> A master device discovers a white space database(s) thru >>which >>>>> it can query for channel information. The master device >>needs >>>>> to ensure that the white space database with which it >>>>> communicates with is an authentic entity. The white space >>>>> database needs to provide its identity to the master device >>>>> which can confirm the validity/authenticty of the database. >>An >>>>> attacker may attempt to spoof a white space database and >>>>> provide responses to a master device which are malicious >>and >>>>> result in the master device causing interference to the >>>> primary >>>>> user of the spectrum. >>>>> >>>>> Threat 3: Modifying a query request >>>>> >>>>> An attacker may modify the query request sent by a master >>>>> device to a white space database. The attacker may change >>the >>>>> location of the device or the capabilities in terms of its >>>>> transmit power or antenna height etc. which could result in >>>> the >>>>> database responding with incorrect information about >>available >>>>> channels or max transmit power allowed. The result of such >>an >>>>> attack is that the master device would cause intereference >>to >>>>> the primary user of the spectrum. It could also result in a >>>>> denial of service to the master device by indicating that >>no >>>>> channels are available. >>>>> >>>>> Threat 4: Modifying a query response >>>>> >>>>> An attacker could modify the query response sent by the >>white >>>>> space database to a master device. The channel information >>or >>>>> transmit power allowed type of parameters carried in the >>>>> response could be modified by the attacker resulting in the >>>>> master device using channels that are not available at a >>>>> location or transmitting at a greater power level than >>allowed >>>>> resulting in interference to the primary user of that >>>>> spectrum. Alternatively the attacker may indicate no >>channel >>>>> availability at a location resulting in a denial of service >>to >>>>> the master device. >>>>> >>>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>> >>>>> An attacker may be a master device which is not certified >>for >>>>> use by the relevant regulatory body. The attacker may >>listen >>>> to >>>>> the communication between a valid master device and white >>>> space >>>>> database and utilize the information about available >>channels >>>>> in the response message by utilizing those channels. The >>>> result >>>>> of such an attack is unauthorized use of channels by a >>master >>>>> device which is not certified to operate. >>>>> The master device querying the white space database may be >>>>> operated by a law-enforcement agency and the communications >>>>> between the device and the database are intended to be kept >>>>> private. A malicious device should not be able to eavesdrop >>on >>>>> such communications. >>>>> >>>>> Threat 6: Third party tracking of white space device location and >>>> identity >>>>> >>>>> A white space database may require a master device to >>provide >>>>> its identity in addition to its location in the query >>request. >>>>> Such location/identity information can be gleaned by an >>>>> eavesdropper. A master device may prefer to keep the >>>>> location/identity information secret. Hence the protocol >>>> should >>>>> provide a means to protect the location and identity >>>>> information of the master device and prevent tracking of >>>>> locations associated with a white space database. If >>>>> regulations do not require the identity of the master >>device >>>> to >>>>> be provided to the white space database, the master is not >>>>> required to include its identity in the query. >>>>> >>>>> >>>>> Threat 7: Termination of device service for reasons other than >>>>> incumbent protection >>>>> >>>>> A white space database may include a mechanism by which >>>> service >>>>> and channels allocated to a master device can be revoked. A >>>>> malicious node can send a revoke message to a master >>>>> device. This results in denial of service to the master >>>>> device. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 peter@spectrumbridge.com Sat Feb 4 05:30:18 2012 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 872BD21F8557 for ; Sat, 4 Feb 2012 05:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELxbLpOEBfFe for ; Sat, 4 Feb 2012 05:30:18 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id BD4EB21F85C6 for ; Sat, 4 Feb 2012 05:30:17 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Sat, 4 Feb 2012 08:31:03 -0500 From: Peter Stanforth To: "paws@ietf.org" Date: Sat, 4 Feb 2012 08:30:07 -0500 Thread-Topic: [paws] registration protocol Thread-Index: AczjQT0PzTJh5ngwTpaUmk6gdbQmOw== 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.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB529B2F1F320peterspectrumbridgecom_" MIME-Version: 1.0 Subject: [paws] registration protocol 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, 04 Feb 2012 13:30:18 -0000 --_000_CB529B2F1F320peterspectrumbridgecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 4.1.2 below describes the registration protocol 4.1.2. Device registration with trusted Database This use caseRegistration is preliminary to creating a radio network using TV white space; it is a prerequisite to otherthe use cases below. The radio network is created by a master device. Before the master device can transmit in TV white space spectrum, it must contact a trusted database where the device can learn if any channels are available for it to use. Before the database will provide information on available TVradio channels, the master device must register with the trusted database. Specific requirements for registration come from individual regulatory domains and may be different. This does not include any acknowledgement. This is something we do support = in our FCC protocol. The reason being so we can accurately inform the devic= e if the registration attempt fails. Listed below are some of the reasons, = though I am sure there are more, we consider returning a failure code to th= e device: malformed request (e.g., required fields missing) FCC identifier not recognized or supported FCC designated no channels available location outside of regulatory domain antenna height above 30 meters HAAT above 76 meters --_000_CB529B2F1F320peterspectrumbridgecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Section 4.1.2= below describes the registration protocol

4.1.2. Device registration with trusted Database

<Delete>This use ca= se</Delete><Insert>Registration</Insert> is
<= div>preliminary to creat= ing a radio network using <Delete>TV</Delete>
= white space; it is a = prerequisite to
<Delete>other</Delete><Insert>the</Insert>= use cases
<Insert>below</Insert>. The radio
network is created by a mast= er device. Before the master device can
transmit in <Delete>TV</Delet= e> white space spectrum, it must contact a
trusted
database where the device can l= earn if any channels are available for
it to use. Before the database will pro= vide information on available
<Delete>TV</Delete><Insert>radi= o</Insert> channels, the master device
must register with the trusted
database= . Specific requirements for registration come from
individual regulatory domai= ns and may be different.
<= br>

--_000_CB529B2F1F320peterspectrumbridgecom_-- From stephen.farrell@cs.tcd.ie Sat Feb 4 07:25:25 2012 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 5C69321F84E7 for ; Sat, 4 Feb 2012 07:25:25 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R4YiAs5kEh-Q for ; Sat, 4 Feb 2012 07:25:24 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A55BD21F84DE for ; Sat, 4 Feb 2012 07:25:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 24A021535C4; Sat, 4 Feb 2012 15:25:22 +0000 (GMT) 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=1328369121; bh=ebtSbPai3PB5Kq pmJviV+eFJR3CUzi4aT9BCvZI7Ksg=; b=FUPjvbBUcfGFRVuqLLZe8THkzM3ckS w9jlJF0d/31O8OEYxM5oaAEo+GuqpG75OJQNzOs+wLJna4fjjWsNPYKUqo9Z1CNG gWsJcYkT30+oXxRm8ExpPubApmuAUlQL8liBm6MjK+VDJJfZBVlyYEupaV5MmGXL rgHzbsF7dYojPOeHUz43gxUO9O6tVBdzIKniOX5m6G1fUl/raR5NM6BBDIsnSFhs pqVnrQHBzQx/tAnwORw5sLXCKq273Dlc2ruNKH4f691jgU4XJCz++sinP7PfU5Tq U9cn0wNUPOrrodpmypvQ1RWPs8qINPZsXeOJ1hrCvoTjC4yduKNxGp1A== 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 rkstJeirsrar; Sat, 4 Feb 2012 15:25:21 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.45.54.84]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DEFDB171C18; Sat, 4 Feb 2012 15:25:19 +0000 (GMT) Message-ID: <4F2D4DDE.6090400@cs.tcd.ie> Date: Sat, 04 Feb 2012 15:25:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: scott.probasco@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: paws@ietf.org Subject: Re: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) 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, 04 Feb 2012 15:25:25 -0000 Hi Scott, On 02/04/2012 02:03 AM, scott.probasco@nokia.com wrote: > Hi, > > A couple of motivations for device-specific identifiers are > * ability to black-list or disable a specific device. Regulators are > interested in ability to switch off a device that causes interference. So a) that's a "regulator says" response and b) is that really specific to an individual device instance or not rather more likely to be something done to a device-type? (I don't know, but would be surprised to hear manufacturing leads to such variability such that turning off just one device is useful enough to justify the costs.) > Device manufacturers are interested in ability to switch off stolen > devices. > * ability to directly address a specific device. One example here is the > 'kill switch' described by Ofcom. Neither of the above seem to be very paws-like though, what have those features got to do with whitespace? They also seem to implicitly assume some way to correlate that identifier across a whole bunch of protocols and only seem relevant to certain business models and not others. And of course, if the so-called "kill switch" is really a "pretty please kill yourself switch" then we're into the land of pretense as well. Gotta say I'm only really seeing "the FCC said so" here. S > > Kind Regards, > Scott > > > On 2/3/12 7:43 PM, "ext Paul Lambert" wrote: > >> >> Good question. >> >> If a set of certified devices (vendor / model type) are all supposed to >> act the same, then any interference problem could be handled by changing >> contours or blocking all of the model/types. >> >> Paul >> >> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>> Stephen Farrell >>> Sent: Friday, February 03, 2012 3:43 PM >>> To: paws@ietf.org >>> Subject: [paws] wondering why a device identifier is needed (was: Re: >>> Threat model (Rev 3)) >>> >>> >>> So this is a bit of a side-issue maybe but I do wonder >>> if there's any functional/technical reason, other than >>> "the FCC said so," to identify a specific device in the >>> paws protocol with a long-lived identifier? >>> >>> I can see why you'd want a device type of some sort, >>> and the DB might need some kind of session ID, but >>> I don't get the long-lived device identifier thing >>> at all as a functional requirement. Can anyone explain? >>> >>> I'm not asking now from the privacy or security p-o-v, >>> but rather because its easier and cheaper and simpler to >>> not bother if you don't have to. >>> >>> It does also interact with privacy& security of course. >>> Once you have to manage the identifier then you may need >>> to go to some trouble to protect that, but that's a >>> secondary question. >>> >>> Thanks, >>> S. >>> >>> On 02/03/2012 11:19 PM, Paul Lambert wrote: >>>>> using it themselves or retransmitting it. The resulting data one >>>>> whitespace availability will be visible to people and or devices >>> which >>>>> are not completely controlled by the regulatory agencies. >>>>> As such, what is the role of confidentiality with regard to this >>>>> information? >>>> >>>> All channel availability (at least for the FCC) is openly available. >>> There is no threat of disclosure of this information. It's actually the >>> reverse. For planning purposes to buy and use WS devices - you really >>> would like a good picture of available spectrum. It would be very >>> detremental to market adoption to limit access to the available >>> channels. >>>> >>>> That said - the current incumbants we discuss are just TV and >>> microphones. In the future, we might be sharing with public saftey or >>> military applications that would not want readily accessable maps of >>> their locations disseminated. "Open" consumer devices might in these >>> scenarios see no spectrum and the approved devices would get >>> allocations. This still should be out-of-scope. These types of devices >>> are not in our use case scenarios. >>>> >>>> Privacy as you point out alone is a good justification for some form >>> of confidentiality. But protecting a devices identity may not require >>> encryption of the full paws messages. >>>> >>>> Intgrity and data origin authentication seem more important for the >>> protocol design considerations. >>>> >>>> Paul >>>> >>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>> Of >>>>> Joel M. Halpern >>>>> Sent: Friday, February 03, 2012 11:51 AM >>>>> To: Basavaraj.Patil@nokia.com >>>>> Cc: paws@ietf.org >>>>> Subject: Re: [paws] Threat model (Rev 3) >>>>> >>>>> Can we please include in this document some articulation of the >>>>> confidentiality assumption we are making with regard to the >>> whitespace >>>>> data itself? I am not trying to object to the threats. (And the >>>>> personal information collection issues are enough to jsutify include >>>>> confidentiality mechanisms in the solutions.) >>>>> But I am still trying to get my head around this. There are going to >>> be >>>>> hoards of whitespace devices. They will be getting the data, and >>> either >>>>> using it themselves or retransmitting it. The resulting data one >>>>> whitespace availability will be visible to people and or devices >>> which >>>>> are not completely controlled by the regulatory agencies. >>>>> As such, what is the role of confidentiality with regard to this >>>>> information? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>>> >>>>>> Below is Rev 3 of the threat model based on feedback from Stephen, >>>>> Nancy >>>>>> and Gabor (Thanks). >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> Rev 3 (3/2/12) >>>>>> >>>>>> Threat model for the PAWS protocol >>>>>> ---------------------------------- >>>>>> >>>>>> Assumptions: >>>>>> ............ >>>>>> >>>>>> o It is assumed that an attacker has full access to the network >>> medium >>>>>> between the master device and the white space database. The >>>>> attacker >>>>>> may be able to eavesdrop on any communications between these >>>>>> entities. The link between the master device and the white space >>>>>> database can be wired or wireless and provides IP connectivity. >>>>>> >>>>>> o It is assumed that the master device or the white space database >>>>>> have NOT been compromised from a security standpoint. >>>>>> >>>>>> Threat 1: User modifies a device to masquerade as another valid >>>>>> certified device >>>>>> >>>>>> The master device needs to authenticate itself with the >>> white >>>>>> space database prior to requesting channel information. The >>>>>> attacker may try to get access to the secrets of the master >>>>>> device which can be used maliciously. The effect of such an >>>>>> attack being successful would result in a malicious client >>>>>> replaying the stolen authentication/authorization secrets >>> to a >>>>>> white space database. >>>>>> >>>>>> Threat 2: Spoofed white space database >>>>>> >>>>>> A master device discovers a white space database(s) thru >>> which >>>>>> it can query for channel information. The master device >>> needs >>>>>> to ensure that the white space database with which it >>>>>> communicates with is an authentic entity. The white space >>>>>> database needs to provide its identity to the master device >>>>>> which can confirm the validity/authenticty of the database. >>> An >>>>>> attacker may attempt to spoof a white space database and >>>>>> provide responses to a master device which are malicious >>> and >>>>>> result in the master device causing interference to the >>>>> primary >>>>>> user of the spectrum. >>>>>> >>>>>> Threat 3: Modifying a query request >>>>>> >>>>>> An attacker may modify the query request sent by a master >>>>>> device to a white space database. The attacker may change >>> the >>>>>> location of the device or the capabilities in terms of its >>>>>> transmit power or antenna height etc. which could result in >>>>> the >>>>>> database responding with incorrect information about >>> available >>>>>> channels or max transmit power allowed. The result of such >>> an >>>>>> attack is that the master device would cause intereference >>> to >>>>>> the primary user of the spectrum. It could also result in a >>>>>> denial of service to the master device by indicating that >>> no >>>>>> channels are available. >>>>>> >>>>>> Threat 4: Modifying a query response >>>>>> >>>>>> An attacker could modify the query response sent by the >>> white >>>>>> space database to a master device. The channel information >>> or >>>>>> transmit power allowed type of parameters carried in the >>>>>> response could be modified by the attacker resulting in the >>>>>> master device using channels that are not available at a >>>>>> location or transmitting at a greater power level than >>> allowed >>>>>> resulting in interference to the primary user of that >>>>>> spectrum. Alternatively the attacker may indicate no >>> channel >>>>>> availability at a location resulting in a denial of service >>> to >>>>>> the master device. >>>>>> >>>>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>>> >>>>>> An attacker may be a master device which is not certified >>> for >>>>>> use by the relevant regulatory body. The attacker may >>> listen >>>>> to >>>>>> the communication between a valid master device and white >>>>> space >>>>>> database and utilize the information about available >>> channels >>>>>> in the response message by utilizing those channels. The >>>>> result >>>>>> of such an attack is unauthorized use of channels by a >>> master >>>>>> device which is not certified to operate. >>>>>> The master device querying the white space database may be >>>>>> operated by a law-enforcement agency and the communications >>>>>> between the device and the database are intended to be kept >>>>>> private. A malicious device should not be able to eavesdrop >>> on >>>>>> such communications. >>>>>> >>>>>> Threat 6: Third party tracking of white space device location and >>>>> identity >>>>>> >>>>>> A white space database may require a master device to >>> provide >>>>>> its identity in addition to its location in the query >>> request. >>>>>> Such location/identity information can be gleaned by an >>>>>> eavesdropper. A master device may prefer to keep the >>>>>> location/identity information secret. Hence the protocol >>>>> should >>>>>> provide a means to protect the location and identity >>>>>> information of the master device and prevent tracking of >>>>>> locations associated with a white space database. If >>>>>> regulations do not require the identity of the master >>> device >>>>> to >>>>>> be provided to the white space database, the master is not >>>>>> required to include its identity in the query. >>>>>> >>>>>> >>>>>> Threat 7: Termination of device service for reasons other than >>>>>> incumbent protection >>>>>> >>>>>> A white space database may include a mechanism by which >>>>> service >>>>>> and channels allocated to a master device can be revoked. A >>>>>> malicious node can send a revoke message to a master >>>>>> device. This results in denial of service to the master >>>>>> device. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 teco@inf-net.nl Sat Feb 4 09:11:20 2012 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 F018521F85CD for ; Sat, 4 Feb 2012 09:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9KZ4bqW3CVF for ; Sat, 4 Feb 2012 09:11:20 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 07B3321F853D for ; Sat, 4 Feb 2012 09:11:19 -0800 (PST) Received: by eaaq13 with SMTP id q13so260217eaa.31 for ; Sat, 04 Feb 2012 09:11:18 -0800 (PST) Received: by 10.213.20.73 with SMTP id e9mr399482ebb.113.1328375476997; Sat, 04 Feb 2012 09:11:16 -0800 (PST) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id a58sm37123278eeb.8.2012.02.04.09.11.15 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 09:11:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Sat, 4 Feb 2012 18:11:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <071482DF-D477-447B-8DA2-B526BF451AC1@inf-net.nl> References: To: X-Mailer: Apple Mail (2.1251.1) X-Gm-Message-State: ALoCoQn0oI5L0hWirthcsOGjQ1Ly2uMlkG7UuopVd1NV3uf8Yf7oYBLfD1vpfuWVZ1aEd9oIuoIl Cc: paws@ietf.org Subject: Re: [paws] draft-ietf-paws-problem-stmt-usecases-rqmts-02.txt 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, 04 Feb 2012 17:11:21 -0000 Hi Scott, I checked the requirements against ECC report 159 requirements=20 (section 9.3.3 / 9.3.4 starting at page 69). I think we miss: 9.3.3: - location with height, with MAY on uncertainty on height (2nd bullet) =3D=3D> add in D.4 - device type (class of device, 3th bullet). =3D=3D> add in D.2 ...> although device ID would tell the device type - expected area of operation, a SHOULD or MAY (5th bullet) =3D=3D> extension to D.4, D6 or new requirement =3D=3D> D.6 describes multiple locations, where ECC-195 describes an area (circle, polygone) and movement. 9.3.4: - maximum transmit power (2nd bullet) =3D=3D> add in D.5 - wsdb redirect (2rd bullet) =3D=3D> this MAY / SHOULD be a mechanism besides the wsdb=20 discovery as described in 5.3 or 1st step in P.1 - requirement for sensing (5th bullet) =3D=3D> this is a MAY or SHOULD, to be added in D.5 Other remarks on requirements: P.10: fix typo (searial") I suggest we specify the protocol MUST support all data model elements=20= in D.1 to D.6. Then, the P.* can be cleaned up a bit. P.7 to P.13 are not protocol requirements. Maybe reword so these are requirements for the protocol, or make a new section for=20 requirements for master devices. Or put it in operational requirements. Question on D.1: are all parameters for data the master sends to wsdb? The second line "... of the subject, ..." is a bit fuzzy. Maybe add "subject" in 2.2 :-) Subject A person or thing that is being discussed,=20 described, or dealt with. Or scan the document on "subject" and try to replace. Maybe we need a term for device that can be Master Device and / or Slave Device. ECC-159 uses White Space Device (WSD). White space device White space devices (WSDs) are devices that can use White Space=20 spectrum without causing harmful interference to protected = services=20 by employing required cognitive capabilities. Thanks, Teco =20 > Hi, >=20 > Revision 2 of the PS, Use cases and requirements I-D has been posted. = Please see: > = http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-= rqmts-02.txt >=20 > This version only includes changes requested by the co-chair in his = email of January 12 = http://www.ietf.org/mail-archive/web/paws/current/msg00516.html=20 > Specifically: > " >> 2. requirements. In the last f2f >> we agreed to modify requirement D.1 to include the suggestions from = slide 7-10 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf and = merge with D.6 and D.9 >> slides 7&8 of http://www.ietf.org/proceedings/82/slides/paws-1.pdf = also contain suggestions on how to revise this requirement. >> Agreed to revise requirement D.2 as suggested in slide 11 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdfand slide 9 of = http://www.ietf.org/proceedings/82/slides/paws-1.pdf >> We seem to have agreed with the reformulation suggested to D.3 in = slide 12 ofhttp://www.ietf.org/proceedings/82/slides/paws-2.pdf, but we = did not agree on the format the location would be represented in. The = data format part is still open, but as this piece does not really belong = to requirements but rather the data model spec, we are not in a hurry to = decide it. >> Delete d.4 >> D.5: augment with lower/upper frequencies and time of availability, = as suggested on slide 10 = ofhttp://www.ietf.org/proceedings/82/slides/paws-1.pdf >> D.6: change power to eirp, as suggested in slide 13 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdf. >> D.7: change to single and multiple locations. Clarify that in case of = multiple locations the channel availability for each location should be = sent by the db. >> D.8: delete > " >>=20 > And > " >> Operational requirements: slides 22-24 of = http://www.ietf.org/proceedings/82/slides/paws-2.pdf contain suggestions = on rewording, I propose the editor considers them. > " >=20 >=20 > Regards, > Scott & Raj > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Sat Feb 4 10:32:33 2012 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 94DF521F8474 for ; Sat, 4 Feb 2012 10:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ve7xPSVw1ug for ; Sat, 4 Feb 2012 10:32:32 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38DFE21F8473 for ; Sat, 4 Feb 2012 10:32:31 -0800 (PST) Received: by eekc41 with SMTP id c41so1587634eek.31 for ; Sat, 04 Feb 2012 10:32:31 -0800 (PST) Received: by 10.14.39.202 with SMTP id d50mr3702066eeb.79.1328380351207; Sat, 04 Feb 2012 10:32:31 -0800 (PST) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id o49sm38025147eei.0.2012.02.04.10.32.30 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 04 Feb 2012 10:32:30 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: Date: Sat, 4 Feb 2012 19:32:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35181831-F969-4542-A040-5DD4C5AF748D@inf-net.nl> References: To: X-Mailer: Apple Mail (2.1251.1) Cc: paws@ietf.org Subject: Re: [paws] Threat model 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, 04 Feb 2012 18:32:33 -0000 Raj, I'm fine with having out of scope threads on the master device=20 or the wsdb themselves.=20 Maybe PAWS could help the wsdb to detect a compromised master=20 device (or slave device). Or misuse, e.g. incorrect position=20 and antenna info. Spending few words on this may help. Here is room for more thoughts: can PAWS help the wsdb to decide this=20 info is correct? A straightforward approach would be sending a=20 picture with recent newspaper, the antenna and a clear view of the=20 surrounding :-) More serious: in a project where I am involved, each set of equipment is registered, including photo's. Providing such to a wsdb is less=20 inept as one may think. Thanks, Teco Op 27 jan. 2012, om 20:39 heeft = het volgende geschreven: >=20 > Hello, >=20 > While discussing the requirements we concluded that it would be useful = to > have a threat model for PAWS. Below is an initial writeup of the = threat > model. This threat model can be included in the Security = considerations > section of the Use-case and Requirements I-D. Security requirements = can be > derived from this threat model. > Comments welcome. >=20 > -Raj >=20 >=20 > Threat model for the PAWS protocol > ---------------------------------- >=20 > Assumptions: > ............ >=20 > o It is assumed that an attacker has full access to the network medium > between the master device and the white space database. The attacker > may be able to eavesdrop on any communications between these > entities. The link between the master device and the white space > database can be wired or wireless and provides IP connectivity. >=20 > o It is assumed that the master device or the white space database > have NOT been compromised from a security standpoint. >=20 > Threat 1: Obtain master device authentication/authorization secrets > The master device needs to authenticate itself with the white > space database prior to requesting channel information. The > attacker may try to get access to the secrets of the master > device which can be used maliciously. The effect of such an > attack being successful would result in a malicious client > replaying the stolen authentication/authorization secrets to a > white space database. >=20 > Threat 2: Spoofed white space database > A master device discovers a white space database(s) thru which > it can query for channel information. The master device needs > to ensure that the white space database with which it > communicates with is an authentic entity. The white space > database needs to provide its identity to the master device > which can confirm the validity/authenticty of the database. An > attacker may attempt to spoof a white space database and > provide responses to a master device which are malicious and > result in the master device causing interference to the primary > user of the spectrum. >=20 > Threat 3: Modifying a query request > An attacker may modify the query request sent by a master > device to a white space database. The attacker may change the > location of the device or the capabilities in terms of its > transmit power or antenna height etc. which could result in the > database responding with incorrect information about available > channels or max transmit power allowed. The result of such an > attack is that the master device would cause intereference to > the primary user of the spectrum. It could also result in a > denial of service to the master device by indicating that no > channels are available. >=20 > Threat 4: Modifying a query response > An attacker could modify the query response sent by the white > space database to a master device. The channel information or > transmit power allowed type of parameters carried in the > response could be modified by the attacker resulting in the > master device using channels that are not available at a > location or transmitting at a greater power level than allowed > resulting in interference to the primary user of that > spectrum. Alternatively the attacker may indicate no channel > availability at a location resulting in a denial of service to > the master device. >=20 > Threat 5: Using query response information > An attacker may be a master device which is not certified for > use by the relevant regulatory body. The attacker may listen to > the communication between a valid master device and white space > database and utilize the information about available channels > in the response message by utilizing those channels. The result > of such an attack is unauthorized use of channels by a master > device which is not certified to operate. >=20 >=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Sun Feb 5 06:54:22 2012 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 2C9DF21F8566 for ; Sun, 5 Feb 2012 06:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B5JmtTj4jzwM for ; Sun, 5 Feb 2012 06:54:20 -0800 (PST) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8917121F8565 for ; Sun, 5 Feb 2012 06:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1328453663; x=1643790866; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Kff0LlmpPajm9Fkhno5rw F2FNr2msdLLMwpVnzitavQ=; b=nWQwcNJ9FP43VgzsMsQ1xswjIS0Kb7pMov9a+ tkE40+jbfxXjkxJqAxPwX+tjzFFoCaoYNfwbokUmw4wCRBnjA== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.3302531; Sun, 05 Feb 2012 09:54:22 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Sun, 5 Feb 2012 09:54:15 -0500 From: "Rosen, Brian" To: 'Stephen Farrell' , "'scott.probasco@nokia.com'" Date: Sun, 5 Feb 2012 09:54:15 -0500 Thread-Topic: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) Thread-Index: AczjUT4jccsfGvYnTa2+Pqd57RRjrgAxMk0e Message-ID: <27AA2A3F470FC14E8E04A5A3699BDDBF081EAC8850@STNTEXCH01.cis.neustar.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: oAY/PEyRiXEa6E13JLvC+Q== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "'paws@ietf.org'" Subject: Re: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) 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: Sun, 05 Feb 2012 14:54:22 -0000 V2VsbCwgaXQgaXMgYSByZXF1aXJlbWVudCwgZm9yIGJvdGggZ292ZXJubWVudHMsIGJ1dCBpdCdz IGJhc2VkIG9uIHRoZSBub3Rpb24gdGhhdCB5b3UgY291bGQgaGF2ZSBhIGRldmljZSB0aGF0IGlz IGludGVyZmVyaW5nIGJ1dCBub3QgYSB3aG9sZSBjbGFzcyBvZiBkZXZpY2VzLiAgVGhpcyBjYW4g b2NjdXIgZm9yIGEgbnVtYmVyIG9mIHJlYXNvbnMgaW5jbHVkaW5nIGFudGVubmEgbW9kaWZpY2F0 aW9uLgoKQnJpYW4KCg0KDQogLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IAlTdGVw aGVuIEZhcnJlbGwgW21haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllXQ0KU2VudDoJU2F0 dXJkYXksIEZlYnJ1YXJ5IDA0LCAyMDEyIDEwOjI1IEFNIEVhc3Rlcm4gU3RhbmRhcmQgVGltZQ0K VG86CXNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbQ0KQ2M6CXBhd3NAaWV0Zi5vcmcNClN1YmplY3Q6 CVJlOiBbcGF3c10gd29uZGVyaW5nIHdoeSBhIGRldmljZSBpZGVudGlmaWVyIGlzIG5lZWRlZCAo d2FzOiBSZTogVGhyZWF0IG1vZGVsIChSZXYgMykpDQoNCg0KSGkgU2NvdHQsDQoNCk9uIDAyLzA0 LzIwMTIgMDI6MDMgQU0sIHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbSB3cm90ZToNCj4gSGksDQo+ DQo+IEEgY291cGxlIG9mIG1vdGl2YXRpb25zIGZvciBkZXZpY2Utc3BlY2lmaWMgaWRlbnRpZmll cnMgYXJlDQo+ICogYWJpbGl0eSB0byBibGFjay1saXN0IG9yIGRpc2FibGUgYSBzcGVjaWZpYyBk ZXZpY2UuIFJlZ3VsYXRvcnMgYXJlDQo+IGludGVyZXN0ZWQgaW4gYWJpbGl0eSB0byBzd2l0Y2gg b2ZmIGEgZGV2aWNlIHRoYXQgY2F1c2VzIGludGVyZmVyZW5jZS4NCg0KU28gYSkgdGhhdCdzIGEg InJlZ3VsYXRvciBzYXlzIiByZXNwb25zZSBhbmQgYikgaXMgdGhhdCByZWFsbHkNCnNwZWNpZmlj IHRvIGFuIGluZGl2aWR1YWwgZGV2aWNlIGluc3RhbmNlIG9yIG5vdCByYXRoZXIgbW9yZQ0KbGlr ZWx5IHRvIGJlIHNvbWV0aGluZyBkb25lIHRvIGEgZGV2aWNlLXR5cGU/IChJIGRvbid0IGtub3cs IGJ1dA0Kd291bGQgYmUgc3VycHJpc2VkIHRvIGhlYXIgbWFudWZhY3R1cmluZyBsZWFkcyB0byBz dWNoIHZhcmlhYmlsaXR5DQpzdWNoIHRoYXQgdHVybmluZyBvZmYganVzdCBvbmUgZGV2aWNlIGlz IHVzZWZ1bCBlbm91Z2ggdG8ganVzdGlmeQ0KdGhlIGNvc3RzLikNCg0KID4gRGV2aWNlIG1hbnVm YWN0dXJlcnMgYXJlIGludGVyZXN0ZWQgaW4gYWJpbGl0eSB0byBzd2l0Y2ggb2ZmIHN0b2xlbg0K ID4gZGV2aWNlcy4NCg0KPiAqIGFiaWxpdHkgdG8gZGlyZWN0bHkgYWRkcmVzcyBhIHNwZWNpZmlj IGRldmljZS4gT25lIGV4YW1wbGUgaGVyZSBpcyB0aGUNCj4gJ2tpbGwgc3dpdGNoJyBkZXNjcmli ZWQgYnkgT2Zjb20uDQoNCk5laXRoZXIgb2YgdGhlIGFib3ZlIHNlZW0gdG8gYmUgdmVyeSBwYXdz LWxpa2UgdGhvdWdoLCB3aGF0DQpoYXZlIHRob3NlIGZlYXR1cmVzIGdvdCB0byBkbyB3aXRoIHdo aXRlc3BhY2U/DQoNClRoZXkgYWxzbyBzZWVtIHRvIGltcGxpY2l0bHkgYXNzdW1lIHNvbWUgd2F5 IHRvIGNvcnJlbGF0ZSB0aGF0DQppZGVudGlmaWVyIGFjcm9zcyBhIHdob2xlIGJ1bmNoIG9mIHBy b3RvY29scyBhbmQgb25seSBzZWVtDQpyZWxldmFudCB0byBjZXJ0YWluIGJ1c2luZXNzIG1vZGVs cyBhbmQgbm90IG90aGVycy4NCg0KQW5kIG9mIGNvdXJzZSwgaWYgdGhlIHNvLWNhbGxlZCAia2ls bCBzd2l0Y2giIGlzIHJlYWxseSBhDQoicHJldHR5IHBsZWFzZSBraWxsIHlvdXJzZWxmIHN3aXRj aCIgdGhlbiB3ZSdyZSBpbnRvIHRoZSBsYW5kDQpvZiBwcmV0ZW5zZSBhcyB3ZWxsLg0KDQpHb3R0 YSBzYXkgSSdtIG9ubHkgcmVhbGx5IHNlZWluZyAidGhlIEZDQyBzYWlkIHNvIiBoZXJlLg0KDQpT DQoNCg0KPg0KPiBLaW5kIFJlZ2FyZHMsDQo+IFNjb3R0DQo+DQo+DQo+IE9uIDIvMy8xMiA3OjQz IFBNLCAiZXh0IFBhdWwgTGFtYmVydCI8cGF1bEBtYXJ2ZWxsLmNvbT4gIHdyb3RlOg0KPg0KPj4N Cj4+IEdvb2QgcXVlc3Rpb24uDQo+Pg0KPj4gSWYgYSBzZXQgb2YgY2VydGlmaWVkIGRldmljZXMg KHZlbmRvciAvIG1vZGVsIHR5cGUpIGFyZSBhbGwgc3VwcG9zZWQgdG8NCj4+IGFjdCB0aGUgc2Ft ZSwgdGhlbiBhbnkgaW50ZXJmZXJlbmNlIHByb2JsZW0gY291bGQgYmUgaGFuZGxlZCBieSBjaGFu Z2luZw0KPj4gY29udG91cnMgb3IgYmxvY2tpbmcgYWxsIG9mIHRoZSBtb2RlbC90eXBlcy4NCj4+ DQo+PiBQYXVsDQo+Pg0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZy b206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mDQo+Pj4gU3RlcGhlbiBGYXJyZWxsDQo+Pj4gU2VudDogRnJpZGF5LCBGZWJy dWFyeSAwMywgMjAxMiAzOjQzIFBNDQo+Pj4gVG86IHBhd3NAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0 OiBbcGF3c10gd29uZGVyaW5nIHdoeSBhIGRldmljZSBpZGVudGlmaWVyIGlzIG5lZWRlZCAod2Fz OiBSZToNCj4+PiBUaHJlYXQgbW9kZWwgKFJldiAzKSkNCj4+Pg0KPj4+DQo+Pj4gU28gdGhpcyBp cyBhIGJpdCBvZiBhIHNpZGUtaXNzdWUgbWF5YmUgYnV0IEkgZG8gd29uZGVyDQo+Pj4gaWYgdGhl cmUncyBhbnkgZnVuY3Rpb25hbC90ZWNobmljYWwgcmVhc29uLCBvdGhlciB0aGFuDQo+Pj4gInRo ZSBGQ0Mgc2FpZCBzbywiIHRvIGlkZW50aWZ5IGEgc3BlY2lmaWMgZGV2aWNlIGluIHRoZQ0KPj4+ IHBhd3MgcHJvdG9jb2wgd2l0aCBhIGxvbmctbGl2ZWQgaWRlbnRpZmllcj8NCj4+Pg0KPj4+IEkg Y2FuIHNlZSB3aHkgeW91J2Qgd2FudCBhIGRldmljZSB0eXBlIG9mIHNvbWUgc29ydCwNCj4+PiBh bmQgdGhlIERCIG1pZ2h0IG5lZWQgc29tZSBraW5kIG9mIHNlc3Npb24gSUQsIGJ1dA0KPj4+IEkg ZG9uJ3QgZ2V0IHRoZSBsb25nLWxpdmVkIGRldmljZSBpZGVudGlmaWVyIHRoaW5nDQo+Pj4gYXQg YWxsIGFzIGEgZnVuY3Rpb25hbCByZXF1aXJlbWVudC4gQ2FuIGFueW9uZSBleHBsYWluPw0KPj4+ DQo+Pj4gSSdtIG5vdCBhc2tpbmcgbm93IGZyb20gdGhlIHByaXZhY3kgb3Igc2VjdXJpdHkgcC1v LXYsDQo+Pj4gYnV0IHJhdGhlciBiZWNhdXNlIGl0cyBlYXNpZXIgYW5kIGNoZWFwZXIgYW5kIHNp bXBsZXIgdG8NCj4+PiBub3QgYm90aGVyIGlmIHlvdSBkb24ndCBoYXZlIHRvLg0KPj4+DQo+Pj4g SXQgZG9lcyBhbHNvIGludGVyYWN0IHdpdGggcHJpdmFjeSYgIHNlY3VyaXR5IG9mIGNvdXJzZS4N Cj4+PiBPbmNlIHlvdSBoYXZlIHRvIG1hbmFnZSB0aGUgaWRlbnRpZmllciB0aGVuIHlvdSBtYXkg bmVlZA0KPj4+IHRvIGdvIHRvIHNvbWUgdHJvdWJsZSB0byBwcm90ZWN0IHRoYXQsIGJ1dCB0aGF0 J3MgYQ0KPj4+IHNlY29uZGFyeSBxdWVzdGlvbi4NCj4+Pg0KPj4+IFRoYW5rcywNCj4+PiBTLg0K Pj4+DQo+Pj4gT24gMDIvMDMvMjAxMiAxMToxOSBQTSwgUGF1bCBMYW1iZXJ0IHdyb3RlOg0KPj4+ Pj4gdXNpbmcgaXQgdGhlbXNlbHZlcyBvciByZXRyYW5zbWl0dGluZyBpdC4gIFRoZSByZXN1bHRp bmcgZGF0YSBvbmUNCj4+Pj4+IHdoaXRlc3BhY2UgYXZhaWxhYmlsaXR5IHdpbGwgYmUgdmlzaWJs ZSB0byBwZW9wbGUgYW5kIG9yIGRldmljZXMNCj4+PiB3aGljaA0KPj4+Pj4gYXJlIG5vdCBjb21w bGV0ZWx5IGNvbnRyb2xsZWQgYnkgdGhlIHJlZ3VsYXRvcnkgYWdlbmNpZXMuDQo+Pj4+PiBBcyBz dWNoLCB3aGF0IGlzIHRoZSByb2xlIG9mIGNvbmZpZGVudGlhbGl0eSB3aXRoIHJlZ2FyZCB0byB0 aGlzDQo+Pj4+PiBpbmZvcm1hdGlvbj8NCj4+Pj4NCj4+Pj4gQWxsIGNoYW5uZWwgYXZhaWxhYmls aXR5IChhdCBsZWFzdCBmb3IgdGhlIEZDQykgaXMgb3Blbmx5IGF2YWlsYWJsZS4NCj4+PiBUaGVy ZSBpcyBubyB0aHJlYXQgb2YgZGlzY2xvc3VyZSBvZiB0aGlzIGluZm9ybWF0aW9uLiAgSXQncyBh Y3R1YWxseSB0aGUNCj4+PiByZXZlcnNlLiAgRm9yIHBsYW5uaW5nIHB1cnBvc2VzIHRvIGJ1eSBh bmQgdXNlIFdTIGRldmljZXMgLSB5b3UgcmVhbGx5DQo+Pj4gd291bGQgbGlrZSBhIGdvb2QgcGlj dHVyZSBvZiBhdmFpbGFibGUgc3BlY3RydW0uICBJdCB3b3VsZCBiZSB2ZXJ5DQo+Pj4gZGV0cmVt ZW50YWwgdG8gbWFya2V0IGFkb3B0aW9uIHRvIGxpbWl0IGFjY2VzcyB0byB0aGUgYXZhaWxhYmxl DQo+Pj4gY2hhbm5lbHMuDQo+Pj4+DQo+Pj4+IFRoYXQgc2FpZCAtIHRoZSBjdXJyZW50IGluY3Vt YmFudHMgd2UgZGlzY3VzcyBhcmUganVzdCBUViBhbmQNCj4+PiBtaWNyb3Bob25lcy4gIEluIHRo ZSBmdXR1cmUsIHdlIG1pZ2h0IGJlIHNoYXJpbmcgd2l0aCBwdWJsaWMgc2FmdGV5IG9yDQo+Pj4g bWlsaXRhcnkgYXBwbGljYXRpb25zIHRoYXQgd291bGQgbm90IHdhbnQgcmVhZGlseSBhY2Nlc3Nh YmxlIG1hcHMgb2YNCj4+PiB0aGVpciBsb2NhdGlvbnMgZGlzc2VtaW5hdGVkLiAgIk9wZW4iIGNv bnN1bWVyIGRldmljZXMgbWlnaHQgaW4gdGhlc2UNCj4+PiBzY2VuYXJpb3Mgc2VlIG5vIHNwZWN0 cnVtIGFuZCB0aGUgYXBwcm92ZWQgZGV2aWNlcyB3b3VsZCBnZXQNCj4+PiBhbGxvY2F0aW9ucy4g IFRoaXMgc3RpbGwgc2hvdWxkIGJlIG91dC1vZi1zY29wZS4gIFRoZXNlIHR5cGVzIG9mIGRldmlj ZXMNCj4+PiBhcmUgbm90IGluIG91ciB1c2UgY2FzZSBzY2VuYXJpb3MuDQo+Pj4+DQo+Pj4+IFBy aXZhY3kgYXMgeW91IHBvaW50IG91dCBhbG9uZSBpcyBhIGdvb2QganVzdGlmaWNhdGlvbiBmb3Ig c29tZSBmb3JtDQo+Pj4gb2YgY29uZmlkZW50aWFsaXR5LiAgQnV0IHByb3RlY3RpbmcgYSBkZXZp Y2VzIGlkZW50aXR5IG1heSBub3QgcmVxdWlyZQ0KPj4+IGVuY3J5cHRpb24gb2YgdGhlIGZ1bGwg cGF3cyBtZXNzYWdlcy4NCj4+Pj4NCj4+Pj4gSW50Z3JpdHkgYW5kIGRhdGEgb3JpZ2luIGF1dGhl bnRpY2F0aW9uIHNlZW0gbW9yZSBpbXBvcnRhbnQgZm9yIHRoZQ0KPj4+IHByb3RvY29sIGRlc2ln biBjb25zaWRlcmF0aW9ucy4NCj4+Pj4NCj4+Pj4gUGF1bA0KPj4+Pg0KPj4+Pg0KPj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj4gT2YNCj4+Pj4+ IEpvZWwgTS4gSGFscGVybg0KPj4+Pj4gU2VudDogRnJpZGF5LCBGZWJydWFyeSAwMywgMjAxMiAx MTo1MSBBTQ0KPj4+Pj4gVG86IEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20NCj4+Pj4+IENjOiBw YXdzQGlldGYub3JnDQo+Pj4+PiBTdWJqZWN0OiBSZTogW3Bhd3NdIFRocmVhdCBtb2RlbCAoUmV2 IDMpDQo+Pj4+Pg0KPj4+Pj4gQ2FuIHdlIHBsZWFzZSBpbmNsdWRlIGluIHRoaXMgZG9jdW1lbnQg c29tZSBhcnRpY3VsYXRpb24gb2YgdGhlDQo+Pj4+PiBjb25maWRlbnRpYWxpdHkgYXNzdW1wdGlv biB3ZSBhcmUgbWFraW5nIHdpdGggcmVnYXJkIHRvIHRoZQ0KPj4+IHdoaXRlc3BhY2UNCj4+Pj4+ IGRhdGEgaXRzZWxmPyAgSSBhbSBub3QgdHJ5aW5nIHRvIG9iamVjdCB0byB0aGUgdGhyZWF0cy4g IChBbmQgdGhlDQo+Pj4+PiBwZXJzb25hbCBpbmZvcm1hdGlvbiBjb2xsZWN0aW9uIGlzc3VlcyBh cmUgZW5vdWdoIHRvIGpzdXRpZnkgaW5jbHVkZQ0KPj4+Pj4gY29uZmlkZW50aWFsaXR5IG1lY2hh bmlzbXMgaW4gdGhlIHNvbHV0aW9ucy4pDQo+Pj4+PiBCdXQgSSBhbSBzdGlsbCB0cnlpbmcgdG8g Z2V0IG15IGhlYWQgYXJvdW5kIHRoaXMuICBUaGVyZSBhcmUgZ29pbmcgdG8NCj4+PiBiZQ0KPj4+ Pj4gaG9hcmRzIG9mIHdoaXRlc3BhY2UgZGV2aWNlcy4gIFRoZXkgd2lsbCBiZSBnZXR0aW5nIHRo ZSBkYXRhLCBhbmQNCj4+PiBlaXRoZXINCj4+Pj4+IHVzaW5nIGl0IHRoZW1zZWx2ZXMgb3IgcmV0 cmFuc21pdHRpbmcgaXQuICBUaGUgcmVzdWx0aW5nIGRhdGEgb25lDQo+Pj4+PiB3aGl0ZXNwYWNl IGF2YWlsYWJpbGl0eSB3aWxsIGJlIHZpc2libGUgdG8gcGVvcGxlIGFuZCBvciBkZXZpY2VzDQo+ Pj4gd2hpY2gNCj4+Pj4+IGFyZSBub3QgY29tcGxldGVseSBjb250cm9sbGVkIGJ5IHRoZSByZWd1 bGF0b3J5IGFnZW5jaWVzLg0KPj4+Pj4gQXMgc3VjaCwgd2hhdCBpcyB0aGUgcm9sZSBvZiBjb25m aWRlbnRpYWxpdHkgd2l0aCByZWdhcmQgdG8gdGhpcw0KPj4+Pj4gaW5mb3JtYXRpb24/DQo+Pj4+ Pg0KPj4+Pj4gWW91cnMsDQo+Pj4+PiBKb2VsDQo+Pj4+Pg0KPj4+Pj4gT24gMi8zLzIwMTIgMjoz NCBQTSwgQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbSB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IEJl bG93IGlzIFJldiAzIG9mIHRoZSB0aHJlYXQgbW9kZWwgYmFzZWQgb24gZmVlZGJhY2sgZnJvbSBT dGVwaGVuLA0KPj4+Pj4gTmFuY3kNCj4+Pj4+PiBhbmQgR2Fib3IgKFRoYW5rcykuDQo+Pj4+Pj4N Cj4+Pj4+PiAtUmFqDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IFJldiAzICgzLzIvMTIpDQo+Pj4+ Pj4NCj4+Pj4+PiBUaHJlYXQgbW9kZWwgZm9yIHRoZSBQQVdTIHByb3RvY29sDQo+Pj4+Pj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+DQo+Pj4+Pj4gQXNzdW1wdGlv bnM6DQo+Pj4+Pj4gLi4uLi4uLi4uLi4uDQo+Pj4+Pj4NCj4+Pj4+PiBvIEl0IGlzIGFzc3VtZWQg dGhhdCBhbiBhdHRhY2tlciBoYXMgZnVsbCBhY2Nlc3MgdG8gdGhlIG5ldHdvcmsNCj4+PiBtZWRp dW0NCj4+Pj4+PiAgICAgIGJldHdlZW4gdGhlIG1hc3RlciBkZXZpY2UgYW5kIHRoZSB3aGl0ZSBz cGFjZSBkYXRhYmFzZS4gVGhlDQo+Pj4+PiBhdHRhY2tlcg0KPj4+Pj4+ICAgICAgbWF5IGJlIGFi bGUgdG8gZWF2ZXNkcm9wIG9uIGFueSBjb21tdW5pY2F0aW9ucyBiZXR3ZWVuIHRoZXNlDQo+Pj4+ Pj4gICAgICBlbnRpdGllcy4gVGhlIGxpbmsgYmV0d2VlbiB0aGUgbWFzdGVyIGRldmljZSBhbmQg dGhlIHdoaXRlIHNwYWNlDQo+Pj4+Pj4gICAgICBkYXRhYmFzZSBjYW4gYmUgd2lyZWQgb3Igd2ly ZWxlc3MgYW5kIHByb3ZpZGVzIElQIGNvbm5lY3Rpdml0eS4NCj4+Pj4+Pg0KPj4+Pj4+IG8gSXQg aXMgYXNzdW1lZCB0aGF0IHRoZSBtYXN0ZXIgZGV2aWNlIG9yIHRoZSB3aGl0ZSBzcGFjZSBkYXRh YmFzZQ0KPj4+Pj4+ICAgICAgaGF2ZSBOT1QgYmVlbiBjb21wcm9taXNlZCBmcm9tIGEgc2VjdXJp dHkgc3RhbmRwb2ludC4NCj4+Pj4+Pg0KPj4+Pj4+IFRocmVhdCAxOiBVc2VyIG1vZGlmaWVzIGEg ZGV2aWNlIHRvIG1hc3F1ZXJhZGUgYXMgYW5vdGhlciB2YWxpZA0KPj4+Pj4+ICAgICAgICAgICBj ZXJ0aWZpZWQgZGV2aWNlDQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAgICAgVGhlIG1hc3RlciBkZXZp Y2UgbmVlZHMgdG8gYXV0aGVudGljYXRlIGl0c2VsZiB3aXRoIHRoZQ0KPj4+IHdoaXRlDQo+Pj4+ Pj4gICAgICAgICAgIHNwYWNlIGRhdGFiYXNlIHByaW9yIHRvIHJlcXVlc3RpbmcgY2hhbm5lbCBp bmZvcm1hdGlvbi4gVGhlDQo+Pj4+Pj4gICAgICAgICAgIGF0dGFja2VyIG1heSB0cnkgdG8gZ2V0 IGFjY2VzcyB0byB0aGUgc2VjcmV0cyBvZiB0aGUgbWFzdGVyDQo+Pj4+Pj4gICAgICAgICAgIGRl dmljZSB3aGljaCBjYW4gYmUgdXNlZCBtYWxpY2lvdXNseS4gVGhlIGVmZmVjdCBvZiBzdWNoIGFu DQo+Pj4+Pj4gICAgICAgICAgIGF0dGFjayBiZWluZyBzdWNjZXNzZnVsIHdvdWxkIHJlc3VsdCBp biBhIG1hbGljaW91cyBjbGllbnQNCj4+Pj4+PiAgICAgICAgICAgcmVwbGF5aW5nIHRoZSBzdG9s ZW4gYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBzZWNyZXRzDQo+Pj4gdG8gYQ0KPj4+Pj4+ ICAgICAgICAgICB3aGl0ZSBzcGFjZSBkYXRhYmFzZS4NCj4+Pj4+Pg0KPj4+Pj4+IFRocmVhdCAy OiBTcG9vZmVkIHdoaXRlIHNwYWNlIGRhdGFiYXNlDQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAgICAg QSBtYXN0ZXIgZGV2aWNlIGRpc2NvdmVycyBhIHdoaXRlIHNwYWNlIGRhdGFiYXNlKHMpIHRocnUN Cj4+PiB3aGljaA0KPj4+Pj4+ICAgICAgICAgICBpdCBjYW4gcXVlcnkgZm9yIGNoYW5uZWwgaW5m b3JtYXRpb24uIFRoZSBtYXN0ZXIgZGV2aWNlDQo+Pj4gbmVlZHMNCj4+Pj4+PiAgICAgICAgICAg dG8gZW5zdXJlIHRoYXQgdGhlIHdoaXRlIHNwYWNlIGRhdGFiYXNlIHdpdGggd2hpY2ggaXQNCj4+ Pj4+PiAgICAgICAgICAgY29tbXVuaWNhdGVzIHdpdGggaXMgYW4gYXV0aGVudGljIGVudGl0eS4g VGhlIHdoaXRlIHNwYWNlDQo+Pj4+Pj4gICAgICAgICAgIGRhdGFiYXNlIG5lZWRzIHRvIHByb3Zp ZGUgaXRzIGlkZW50aXR5IHRvIHRoZSBtYXN0ZXIgZGV2aWNlDQo+Pj4+Pj4gICAgICAgICAgIHdo aWNoIGNhbiBjb25maXJtIHRoZSB2YWxpZGl0eS9hdXRoZW50aWN0eSBvZiB0aGUgZGF0YWJhc2Uu DQo+Pj4gQW4NCj4+Pj4+PiAgICAgICAgICAgYXR0YWNrZXIgbWF5IGF0dGVtcHQgdG8gc3Bvb2Yg YSB3aGl0ZSBzcGFjZSBkYXRhYmFzZSBhbmQNCj4+Pj4+PiAgICAgICAgICAgcHJvdmlkZSByZXNw b25zZXMgdG8gYSBtYXN0ZXIgZGV2aWNlIHdoaWNoIGFyZSBtYWxpY2lvdXMNCj4+PiBhbmQNCj4+ Pj4+PiAgICAgICAgICAgcmVzdWx0IGluIHRoZSBtYXN0ZXIgZGV2aWNlIGNhdXNpbmcgaW50ZXJm ZXJlbmNlIHRvIHRoZQ0KPj4+Pj4gcHJpbWFyeQ0KPj4+Pj4+ICAgICAgICAgICB1c2VyIG9mIHRo ZSBzcGVjdHJ1bS4NCj4+Pj4+Pg0KPj4+Pj4+IFRocmVhdCAzOiBNb2RpZnlpbmcgYSBxdWVyeSBy ZXF1ZXN0DQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAgICAgQW4gYXR0YWNrZXIgbWF5IG1vZGlmeSB0 aGUgcXVlcnkgcmVxdWVzdCBzZW50IGJ5IGEgbWFzdGVyDQo+Pj4+Pj4gICAgICAgICAgIGRldmlj ZSB0byBhIHdoaXRlIHNwYWNlIGRhdGFiYXNlLiBUaGUgYXR0YWNrZXIgbWF5IGNoYW5nZQ0KPj4+ IHRoZQ0KPj4+Pj4+ICAgICAgICAgICBsb2NhdGlvbiBvZiB0aGUgZGV2aWNlIG9yIHRoZSBjYXBh YmlsaXRpZXMgaW4gdGVybXMgb2YgaXRzDQo+Pj4+Pj4gICAgICAgICAgIHRyYW5zbWl0IHBvd2Vy IG9yIGFudGVubmEgaGVpZ2h0IGV0Yy4gd2hpY2ggY291bGQgcmVzdWx0IGluDQo+Pj4+PiB0aGUN Cj4+Pj4+PiAgICAgICAgICAgZGF0YWJhc2UgcmVzcG9uZGluZyB3aXRoIGluY29ycmVjdCBpbmZv cm1hdGlvbiBhYm91dA0KPj4+IGF2YWlsYWJsZQ0KPj4+Pj4+ICAgICAgICAgICBjaGFubmVscyBv ciBtYXggdHJhbnNtaXQgcG93ZXIgYWxsb3dlZC4gVGhlIHJlc3VsdCBvZiBzdWNoDQo+Pj4gYW4N Cj4+Pj4+PiAgICAgICAgICAgYXR0YWNrIGlzIHRoYXQgdGhlIG1hc3RlciBkZXZpY2Ugd291bGQg Y2F1c2UgaW50ZXJlZmVyZW5jZQ0KPj4+IHRvDQo+Pj4+Pj4gICAgICAgICAgIHRoZSBwcmltYXJ5 IHVzZXIgb2YgdGhlIHNwZWN0cnVtLiBJdCBjb3VsZCBhbHNvIHJlc3VsdCBpbiBhDQo+Pj4+Pj4g ICAgICAgICAgIGRlbmlhbCBvZiBzZXJ2aWNlIHRvIHRoZSBtYXN0ZXIgZGV2aWNlIGJ5IGluZGlj YXRpbmcgdGhhdA0KPj4+IG5vDQo+Pj4+Pj4gICAgICAgICAgIGNoYW5uZWxzIGFyZSBhdmFpbGFi bGUuDQo+Pj4+Pj4NCj4+Pj4+PiBUaHJlYXQgNDogTW9kaWZ5aW5nIGEgcXVlcnkgcmVzcG9uc2UN Cj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICBBbiBhdHRhY2tlciBjb3VsZCBtb2RpZnkgdGhlIHF1 ZXJ5IHJlc3BvbnNlIHNlbnQgYnkgdGhlDQo+Pj4gd2hpdGUNCj4+Pj4+PiAgICAgICAgICAgc3Bh Y2UgZGF0YWJhc2UgdG8gYSBtYXN0ZXIgZGV2aWNlLiBUaGUgY2hhbm5lbCBpbmZvcm1hdGlvbg0K Pj4+IG9yDQo+Pj4+Pj4gICAgICAgICAgIHRyYW5zbWl0IHBvd2VyIGFsbG93ZWQgdHlwZSBvZiBw YXJhbWV0ZXJzIGNhcnJpZWQgaW4gdGhlDQo+Pj4+Pj4gICAgICAgICAgIHJlc3BvbnNlIGNvdWxk IGJlIG1vZGlmaWVkIGJ5IHRoZSBhdHRhY2tlciByZXN1bHRpbmcgaW4gdGhlDQo+Pj4+Pj4gICAg ICAgICAgIG1hc3RlciBkZXZpY2UgdXNpbmcgY2hhbm5lbHMgdGhhdCBhcmUgbm90IGF2YWlsYWJs ZSBhdCBhDQo+Pj4+Pj4gICAgICAgICAgIGxvY2F0aW9uIG9yIHRyYW5zbWl0dGluZyBhdCBhIGdy ZWF0ZXIgcG93ZXIgbGV2ZWwgdGhhbg0KPj4+IGFsbG93ZWQNCj4+Pj4+PiAgICAgICAgICAgcmVz dWx0aW5nIGluIGludGVyZmVyZW5jZSB0byB0aGUgcHJpbWFyeSB1c2VyIG9mIHRoYXQNCj4+Pj4+ PiAgICAgICAgICAgc3BlY3RydW0uIEFsdGVybmF0aXZlbHkgdGhlIGF0dGFja2VyIG1heSBpbmRp Y2F0ZSBubw0KPj4+IGNoYW5uZWwNCj4+Pj4+PiAgICAgICAgICAgYXZhaWxhYmlsaXR5IGF0IGEg bG9jYXRpb24gcmVzdWx0aW5nIGluIGEgZGVuaWFsIG9mIHNlcnZpY2UNCj4+PiB0bw0KPj4+Pj4+ ICAgICAgICAgICB0aGUgbWFzdGVyIGRldmljZS4NCj4+Pj4+Pg0KPj4+Pj4+IFRocmVhdCA1OiBV bmF1dGhvcml6ZWQgdXNlIG9mIGNoYW5uZWxzIGJ5IGFuIHVuY2VydGlmaWVkIGRldmljZQ0KPj4+ Pj4+DQo+Pj4+Pj4gICAgICAgICAgIEFuIGF0dGFja2VyIG1heSBiZSBhIG1hc3RlciBkZXZpY2Ug d2hpY2ggaXMgbm90IGNlcnRpZmllZA0KPj4+IGZvcg0KPj4+Pj4+ICAgICAgICAgICB1c2UgYnkg dGhlIHJlbGV2YW50IHJlZ3VsYXRvcnkgYm9keS4gVGhlIGF0dGFja2VyIG1heQ0KPj4+IGxpc3Rl bg0KPj4+Pj4gdG8NCj4+Pj4+PiAgICAgICAgICAgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBh IHZhbGlkIG1hc3RlciBkZXZpY2UgYW5kIHdoaXRlDQo+Pj4+PiBzcGFjZQ0KPj4+Pj4+ICAgICAg ICAgICBkYXRhYmFzZSBhbmQgdXRpbGl6ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgYXZhaWxhYmxl DQo+Pj4gY2hhbm5lbHMNCj4+Pj4+PiAgICAgICAgICAgaW4gdGhlIHJlc3BvbnNlIG1lc3NhZ2Ug YnkgdXRpbGl6aW5nIHRob3NlIGNoYW5uZWxzLiBUaGUNCj4+Pj4+IHJlc3VsdA0KPj4+Pj4+ICAg ICAgICAgICBvZiBzdWNoIGFuIGF0dGFjayBpcyB1bmF1dGhvcml6ZWQgdXNlIG9mIGNoYW5uZWxz IGJ5IGENCj4+PiBtYXN0ZXINCj4+Pj4+PiAgICAgICAgICAgZGV2aWNlIHdoaWNoIGlzIG5vdCBj ZXJ0aWZpZWQgdG8gb3BlcmF0ZS4NCj4+Pj4+PiAgICAgICAgICAgVGhlIG1hc3RlciBkZXZpY2Ug cXVlcnlpbmcgdGhlIHdoaXRlIHNwYWNlIGRhdGFiYXNlIG1heSBiZQ0KPj4+Pj4+ICAgICAgICAg ICBvcGVyYXRlZCBieSBhIGxhdy1lbmZvcmNlbWVudCBhZ2VuY3kgYW5kIHRoZSBjb21tdW5pY2F0 aW9ucw0KPj4+Pj4+ICAgICAgICAgICBiZXR3ZWVuIHRoZSBkZXZpY2UgYW5kIHRoZSBkYXRhYmFz ZSBhcmUgaW50ZW5kZWQgdG8gYmUga2VwdA0KPj4+Pj4+ICAgICAgICAgICBwcml2YXRlLiBBIG1h bGljaW91cyBkZXZpY2Ugc2hvdWxkIG5vdCBiZSBhYmxlIHRvIGVhdmVzZHJvcA0KPj4+IG9uDQo+ Pj4+Pj4gICAgICAgICAgIHN1Y2ggY29tbXVuaWNhdGlvbnMuDQo+Pj4+Pj4NCj4+Pj4+PiBUaHJl YXQgNjogVGhpcmQgcGFydHkgdHJhY2tpbmcgb2Ygd2hpdGUgc3BhY2UgZGV2aWNlIGxvY2F0aW9u IGFuZA0KPj4+Pj4gaWRlbnRpdHkNCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgICAgICBBIHdoaXRlIHNw YWNlIGRhdGFiYXNlIG1heSByZXF1aXJlIGEgbWFzdGVyIGRldmljZSB0bw0KPj4+IHByb3ZpZGUN Cj4+Pj4+PiAgICAgICAgICAgaXRzIGlkZW50aXR5IGluIGFkZGl0aW9uIHRvIGl0cyBsb2NhdGlv biBpbiB0aGUgcXVlcnkNCj4+PiByZXF1ZXN0Lg0KPj4+Pj4+ICAgICAgICAgICBTdWNoIGxvY2F0 aW9uL2lkZW50aXR5IGluZm9ybWF0aW9uIGNhbiBiZSBnbGVhbmVkIGJ5IGFuDQo+Pj4+Pj4gICAg ICAgICAgIGVhdmVzZHJvcHBlci4gQSBtYXN0ZXIgZGV2aWNlIG1heSBwcmVmZXIgdG8ga2VlcCB0 aGUNCj4+Pj4+PiAgICAgICAgICAgbG9jYXRpb24vaWRlbnRpdHkgaW5mb3JtYXRpb24gc2VjcmV0 LiBIZW5jZSB0aGUgcHJvdG9jb2wNCj4+Pj4+IHNob3VsZA0KPj4+Pj4+ICAgICAgICAgICBwcm92 aWRlIGEgbWVhbnMgdG8gcHJvdGVjdCB0aGUgbG9jYXRpb24gYW5kIGlkZW50aXR5DQo+Pj4+Pj4g ICAgICAgICAgIGluZm9ybWF0aW9uIG9mIHRoZSBtYXN0ZXIgZGV2aWNlIGFuZCBwcmV2ZW50IHRy YWNraW5nIG9mDQo+Pj4+Pj4gICAgICAgICAgIGxvY2F0aW9ucyBhc3NvY2lhdGVkIHdpdGggYSB3 aGl0ZSBzcGFjZSBkYXRhYmFzZS4gSWYNCj4+Pj4+PiAgICAgICAgICAgcmVndWxhdGlvbnMgZG8g bm90IHJlcXVpcmUgdGhlIGlkZW50aXR5IG9mIHRoZSBtYXN0ZXINCj4+PiBkZXZpY2UNCj4+Pj4+ IHRvDQo+Pj4+Pj4gICAgICAgICAgIGJlIHByb3ZpZGVkIHRvIHRoZSB3aGl0ZSBzcGFjZSBkYXRh YmFzZSwgdGhlIG1hc3RlciBpcyBub3QNCj4+Pj4+PiAgICAgICAgICAgcmVxdWlyZWQgdG8gaW5j bHVkZSBpdHMgaWRlbnRpdHkgaW4gdGhlIHF1ZXJ5Lg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBU aHJlYXQgNzogVGVybWluYXRpb24gb2YgZGV2aWNlIHNlcnZpY2UgZm9yIHJlYXNvbnMgb3RoZXIg dGhhbg0KPj4+Pj4+ICAgICAgICAgICBpbmN1bWJlbnQgcHJvdGVjdGlvbg0KPj4+Pj4+DQo+Pj4+ Pj4gICAgICAgICAgIEEgd2hpdGUgc3BhY2UgZGF0YWJhc2UgbWF5IGluY2x1ZGUgYSBtZWNoYW5p c20gYnkgd2hpY2gNCj4+Pj4+IHNlcnZpY2UNCj4+Pj4+PiAgICAgICAgICAgYW5kIGNoYW5uZWxz IGFsbG9jYXRlZCB0byBhIG1hc3RlciBkZXZpY2UgY2FuIGJlIHJldm9rZWQuIEENCj4+Pj4+PiAg ICAgICAgICAgbWFsaWNpb3VzIG5vZGUgY2FuIHNlbmQgYSByZXZva2UgbWVzc2FnZSB0byBhIG1h c3Rlcg0KPj4+Pj4+ICAgICAgICAgICBkZXZpY2UuIFRoaXMgcmVzdWx0cyBpbiBkZW5pYWwgb2Yg c2VydmljZSB0byB0aGUgbWFzdGVyDQo+Pj4+Pj4gICAgICAgICAgIGRldmljZS4NCj4+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pj4+Pg0K Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ Pj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+Pj4+PiBwYXdzQGlldGYub3JnDQo+Pj4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gcGF3cyBtYWlsaW5nIGxpc3QN Cj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Bhd3MNCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHBhd3MgbWFpbGluZyBsaXN0 DQo+PiBwYXdzQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Bhd3MNCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo= From stephen.farrell@cs.tcd.ie Sun Feb 5 07:22:17 2012 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 1874D21F858E for ; Sun, 5 Feb 2012 07:22:17 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WmePDFgUyRD for ; Sun, 5 Feb 2012 07:22:15 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 1492821F8589 for ; Sun, 5 Feb 2012 07:22:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 1FAD515755C; Sun, 5 Feb 2012 15:22:14 +0000 (GMT) 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=1328455333; bh=T9qOuSMF7A+ieE T3dL/DQ3EFh3mYCAT0ajx0eUI98Vw=; b=cpGMAchuXZsNfs80JmOGnxjjCZc+jw rzcm90YHvOKQk/layM8XtXjpLgjNNQ8LOFvnq8a1olFUpJ0UsWeMjlZIJpKoH27o zgguTW8Ppf9hq++zjbsV+Bwnv+VsYRLLIUF4CO0uZoeacYaO0RlH2maw7JtIuJne n0v8GLimYMOcDl6adEH4akMSmiiu4GIt/QrgA5+a0XAQV3cpkwpENmQ3mquM1s4l K6EPnkKHS8eOHOH1JmBqURlHAmvHNiIaOjLYbFRDhB/IMWD1j415EdFf5527msT2 pzdQxLwzBzuDHkV4eDC2RitlPcGlJqXe/BcFo6yF0zUwgt8VpsTkZLng== 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 AcMqH0e2AB03; Sun, 5 Feb 2012 15:22:13 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.45.50.113]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 2210B171BFD; Sun, 5 Feb 2012 15:22:11 +0000 (GMT) Message-ID: <4F2E9EA2.20901@cs.tcd.ie> Date: Sun, 05 Feb 2012 15:22:10 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Rosen, Brian" References: <27AA2A3F470FC14E8E04A5A3699BDDBF081EAC8850@STNTEXCH01.cis.neustar.com> In-Reply-To: <27AA2A3F470FC14E8E04A5A3699BDDBF081EAC8850@STNTEXCH01.cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'paws@ietf.org'" Subject: Re: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) 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: Sun, 05 Feb 2012 15:22:17 -0000 On 02/05/2012 02:54 PM, Rosen, Brian wrote: > Well, it is a requirement, for both governments, Clearly. And I'm not trying to say "don't meet that requirement." (Much as that might be a logically pure approach.) > but it's based on the notion that you could have a device that is interfering but not a whole class of devices. This can occur for a number of reasons including antenna modification. You mean using the wrong antenna? Seems like that'd fit into a "modified device" category of problem in which case I'd wonder if the modder could've also changed the device identifier. But I guess there may be accidental interference cases where this could help maybe. I'm still puzzled by how this paws device identifier might be used though, but presumably one of the drafts will explain that. S. > > Brian > > > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Saturday, February 04, 2012 10:25 AM Eastern Standard Time > To: scott.probasco@nokia.com > Cc: paws@ietf.org > Subject: Re: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) > > > Hi Scott, > > On 02/04/2012 02:03 AM, scott.probasco@nokia.com wrote: >> Hi, >> >> A couple of motivations for device-specific identifiers are >> * ability to black-list or disable a specific device. Regulators are >> interested in ability to switch off a device that causes interference. > > So a) that's a "regulator says" response and b) is that really > specific to an individual device instance or not rather more > likely to be something done to a device-type? (I don't know, but > would be surprised to hear manufacturing leads to such variability > such that turning off just one device is useful enough to justify > the costs.) > > > Device manufacturers are interested in ability to switch off stolen > > devices. > >> * ability to directly address a specific device. One example here is the >> 'kill switch' described by Ofcom. > > Neither of the above seem to be very paws-like though, what > have those features got to do with whitespace? > > They also seem to implicitly assume some way to correlate that > identifier across a whole bunch of protocols and only seem > relevant to certain business models and not others. > > And of course, if the so-called "kill switch" is really a > "pretty please kill yourself switch" then we're into the land > of pretense as well. > > Gotta say I'm only really seeing "the FCC said so" here. > > S > > >> >> Kind Regards, >> Scott >> >> >> On 2/3/12 7:43 PM, "ext Paul Lambert" wrote: >> >>> >>> Good question. >>> >>> If a set of certified devices (vendor / model type) are all supposed to >>> act the same, then any interference problem could be handled by changing >>> contours or blocking all of the model/types. >>> >>> Paul >>> >>> >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>>> Stephen Farrell >>>> Sent: Friday, February 03, 2012 3:43 PM >>>> To: paws@ietf.org >>>> Subject: [paws] wondering why a device identifier is needed (was: Re: >>>> Threat model (Rev 3)) >>>> >>>> >>>> So this is a bit of a side-issue maybe but I do wonder >>>> if there's any functional/technical reason, other than >>>> "the FCC said so," to identify a specific device in the >>>> paws protocol with a long-lived identifier? >>>> >>>> I can see why you'd want a device type of some sort, >>>> and the DB might need some kind of session ID, but >>>> I don't get the long-lived device identifier thing >>>> at all as a functional requirement. Can anyone explain? >>>> >>>> I'm not asking now from the privacy or security p-o-v, >>>> but rather because its easier and cheaper and simpler to >>>> not bother if you don't have to. >>>> >>>> It does also interact with privacy& security of course. >>>> Once you have to manage the identifier then you may need >>>> to go to some trouble to protect that, but that's a >>>> secondary question. >>>> >>>> Thanks, >>>> S. >>>> >>>> On 02/03/2012 11:19 PM, Paul Lambert wrote: >>>>>> using it themselves or retransmitting it. The resulting data one >>>>>> whitespace availability will be visible to people and or devices >>>> which >>>>>> are not completely controlled by the regulatory agencies. >>>>>> As such, what is the role of confidentiality with regard to this >>>>>> information? >>>>> >>>>> All channel availability (at least for the FCC) is openly available. >>>> There is no threat of disclosure of this information. It's actually the >>>> reverse. For planning purposes to buy and use WS devices - you really >>>> would like a good picture of available spectrum. It would be very >>>> detremental to market adoption to limit access to the available >>>> channels. >>>>> >>>>> That said - the current incumbants we discuss are just TV and >>>> microphones. In the future, we might be sharing with public saftey or >>>> military applications that would not want readily accessable maps of >>>> their locations disseminated. "Open" consumer devices might in these >>>> scenarios see no spectrum and the approved devices would get >>>> allocations. This still should be out-of-scope. These types of devices >>>> are not in our use case scenarios. >>>>> >>>>> Privacy as you point out alone is a good justification for some form >>>> of confidentiality. But protecting a devices identity may not require >>>> encryption of the full paws messages. >>>>> >>>>> Intgrity and data origin authentication seem more important for the >>>> protocol design considerations. >>>>> >>>>> Paul >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>>> Of >>>>>> Joel M. Halpern >>>>>> Sent: Friday, February 03, 2012 11:51 AM >>>>>> To: Basavaraj.Patil@nokia.com >>>>>> Cc: paws@ietf.org >>>>>> Subject: Re: [paws] Threat model (Rev 3) >>>>>> >>>>>> Can we please include in this document some articulation of the >>>>>> confidentiality assumption we are making with regard to the >>>> whitespace >>>>>> data itself? I am not trying to object to the threats. (And the >>>>>> personal information collection issues are enough to jsutify include >>>>>> confidentiality mechanisms in the solutions.) >>>>>> But I am still trying to get my head around this. There are going to >>>> be >>>>>> hoards of whitespace devices. They will be getting the data, and >>>> either >>>>>> using it themselves or retransmitting it. The resulting data one >>>>>> whitespace availability will be visible to people and or devices >>>> which >>>>>> are not completely controlled by the regulatory agencies. >>>>>> As such, what is the role of confidentiality with regard to this >>>>>> information? >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>>>> >>>>>>> Below is Rev 3 of the threat model based on feedback from Stephen, >>>>>> Nancy >>>>>>> and Gabor (Thanks). >>>>>>> >>>>>>> -Raj >>>>>>> >>>>>>> >>>>>>> Rev 3 (3/2/12) >>>>>>> >>>>>>> Threat model for the PAWS protocol >>>>>>> ---------------------------------- >>>>>>> >>>>>>> Assumptions: >>>>>>> ............ >>>>>>> >>>>>>> o It is assumed that an attacker has full access to the network >>>> medium >>>>>>> between the master device and the white space database. The >>>>>> attacker >>>>>>> may be able to eavesdrop on any communications between these >>>>>>> entities. The link between the master device and the white space >>>>>>> database can be wired or wireless and provides IP connectivity. >>>>>>> >>>>>>> o It is assumed that the master device or the white space database >>>>>>> have NOT been compromised from a security standpoint. >>>>>>> >>>>>>> Threat 1: User modifies a device to masquerade as another valid >>>>>>> certified device >>>>>>> >>>>>>> The master device needs to authenticate itself with the >>>> white >>>>>>> space database prior to requesting channel information. The >>>>>>> attacker may try to get access to the secrets of the master >>>>>>> device which can be used maliciously. The effect of such an >>>>>>> attack being successful would result in a malicious client >>>>>>> replaying the stolen authentication/authorization secrets >>>> to a >>>>>>> white space database. >>>>>>> >>>>>>> Threat 2: Spoofed white space database >>>>>>> >>>>>>> A master device discovers a white space database(s) thru >>>> which >>>>>>> it can query for channel information. The master device >>>> needs >>>>>>> to ensure that the white space database with which it >>>>>>> communicates with is an authentic entity. The white space >>>>>>> database needs to provide its identity to the master device >>>>>>> which can confirm the validity/authenticty of the database. >>>> An >>>>>>> attacker may attempt to spoof a white space database and >>>>>>> provide responses to a master device which are malicious >>>> and >>>>>>> result in the master device causing interference to the >>>>>> primary >>>>>>> user of the spectrum. >>>>>>> >>>>>>> Threat 3: Modifying a query request >>>>>>> >>>>>>> An attacker may modify the query request sent by a master >>>>>>> device to a white space database. The attacker may change >>>> the >>>>>>> location of the device or the capabilities in terms of its >>>>>>> transmit power or antenna height etc. which could result in >>>>>> the >>>>>>> database responding with incorrect information about >>>> available >>>>>>> channels or max transmit power allowed. The result of such >>>> an >>>>>>> attack is that the master device would cause intereference >>>> to >>>>>>> the primary user of the spectrum. It could also result in a >>>>>>> denial of service to the master device by indicating that >>>> no >>>>>>> channels are available. >>>>>>> >>>>>>> Threat 4: Modifying a query response >>>>>>> >>>>>>> An attacker could modify the query response sent by the >>>> white >>>>>>> space database to a master device. The channel information >>>> or >>>>>>> transmit power allowed type of parameters carried in the >>>>>>> response could be modified by the attacker resulting in the >>>>>>> master device using channels that are not available at a >>>>>>> location or transmitting at a greater power level than >>>> allowed >>>>>>> resulting in interference to the primary user of that >>>>>>> spectrum. Alternatively the attacker may indicate no >>>> channel >>>>>>> availability at a location resulting in a denial of service >>>> to >>>>>>> the master device. >>>>>>> >>>>>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>>>> >>>>>>> An attacker may be a master device which is not certified >>>> for >>>>>>> use by the relevant regulatory body. The attacker may >>>> listen >>>>>> to >>>>>>> the communication between a valid master device and white >>>>>> space >>>>>>> database and utilize the information about available >>>> channels >>>>>>> in the response message by utilizing those channels. The >>>>>> result >>>>>>> of such an attack is unauthorized use of channels by a >>>> master >>>>>>> device which is not certified to operate. >>>>>>> The master device querying the white space database may be >>>>>>> operated by a law-enforcement agency and the communications >>>>>>> between the device and the database are intended to be kept >>>>>>> private. A malicious device should not be able to eavesdrop >>>> on >>>>>>> such communications. >>>>>>> >>>>>>> Threat 6: Third party tracking of white space device location and >>>>>> identity >>>>>>> >>>>>>> A white space database may require a master device to >>>> provide >>>>>>> its identity in addition to its location in the query >>>> request. >>>>>>> Such location/identity information can be gleaned by an >>>>>>> eavesdropper. A master device may prefer to keep the >>>>>>> location/identity information secret. Hence the protocol >>>>>> should >>>>>>> provide a means to protect the location and identity >>>>>>> information of the master device and prevent tracking of >>>>>>> locations associated with a white space database. If >>>>>>> regulations do not require the identity of the master >>>> device >>>>>> to >>>>>>> be provided to the white space database, the master is not >>>>>>> required to include its identity in the query. >>>>>>> >>>>>>> >>>>>>> Threat 7: Termination of device service for reasons other than >>>>>>> incumbent protection >>>>>>> >>>>>>> A white space database may include a mechanism by which >>>>>> service >>>>>>> and channels allocated to a master device can be revoked. A >>>>>>> malicious node can send a revoke message to a master >>>>>>> device. This results in denial of service to the master >>>>>>> device. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 andy.sago@bt.com Mon Feb 6 04:10:56 2012 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 0BB1C21F8600 for ; Mon, 6 Feb 2012 04:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.290, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lv7b322jlsGI for ; Mon, 6 Feb 2012 04:10:46 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 02E7D21F85E5 for ; Mon, 6 Feb 2012 04:10:37 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 Feb 2012 12:10:36 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 6 Feb 2012 12:10:36 +0000 From: To: , , Date: Mon, 6 Feb 2012 12:10:35 +0000 Thread-Topic: UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) Thread-Index: AQHM4ryf5uLLQgfWlUG94XlZz/QApZYvxnqA Message-ID: <619CDADDCCD2B44380834BE8BF6F7141406554D98B@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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: Mon, 06 Feb 2012 12:10:56 -0000 Scott, Raj, all I don't see the need for steps 8, 9 and 11, where slaves query the master f= or frequencies. In this use case, all slaves only talk to masters, not to e= ach other. By definition they must be using a WS channel allocated by the W= SDB to the master WSD - they are part of the master network and using its f= requencies. The master advertises its presence in some way on the WS (we do= n't need to know how or at what layer, but could be SSIDs, beacons, require= d timing information etc). There must be some sort of advertisement otherwi= se slaves can never connect. If the master drops use of a frequency that a = slave was using, then, like in cellular mobile or Wi-Fi, the slave drops of= f the network shortly after failing to hear the master, and will have to re= join using another frequency being transmitted by the master, if any. The s= lave never needs to ask for frequencies. Have I missed something, or are we making the protocol unnecessarily compli= cated? Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of sco= tt.probasco@nokia.com Sent: 03 February 2012 21:42 To: paws@ietf.org Subject: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity= service) Hello All, As editors of the problem statement, use cases & requirements draft we are = attempting to prepare a completed draft which could be ready for working gr= oup last call before IETF83. In the coming days we will post the sections o= f the draft to the mailing list. Our request is that you review these secti= ons and reply to the email with any comments. Below is the text for section on the Hotspot use case (new section numberin= g is NOT shown, all use cases will be moved to section 4.2 Use cases in the= next version). This text has been marked up from version-02 as uploaded Ja= nuary 26, 2012 as follows: * now includes steps to change the availability of spectrum on short notice * clarification that in some cases a master may initialize over a white spa= ce channel * clarification that registration includes device location * clarification on the possible parameters in the channel request * clarification on the possible parameters in the channel response Our goal is that any discussion on this text will conclude by February 10. To be clear, approval of the document will go through the normal process of= last calls etc.. We are simply asking for your assistance in preparing a c= omplete & accurate document that could progress the work. So please review = the text and send your comments either directly to the editor or to the mai= ling list. Kind Regards, Raj & Scott 4.3. Hotspot: urban internet connectivity service In this use case internet connectivity service is provided in a "hotspot" to local users. Typical deployment scenarios include urban areas where internet connectivity is provided to local businesses and residents, and campus environments where internet connectivity is provided to local buildings and relatively small outdoor areas. This deployment scenario is typically characterized by multiple masters (APs or hotspots) in close proximity, with low antenna height, cells with relatively small radius (a few kilometers or less), and limited numbers of available radio channels. Many of the masters/APs are assumed to be individually deployed and operated, i.e. there is no coordination between many of the masters/APs. The masters/APs in this scenario use a TDD radio technology and transmit at or below a relatively low transmit power threshold. Each master/AP has a connection to the internet and provides internet connectivity to multiple master and or slave devices. The figure below shows an example deployment of this scenario. -------- |Device|\ \|/ ---------- | 1 | (TDD AirIF) | |Database| -------- \ | .---. /--------- o \ |-|---------| ( ) / o | Master | / \ o / | |=3D=3D=3D=3D=3D=3D=3D=3D( Interne= t ) o / |-----------| \ / -------- (TDD AirIF) ( ) |Device| / (----) | n | -------- Figure 3: Hotspot service using TV white space spectrum Once a master/AP has been correctly installed and configured, a simplified power up and operation scenario utilizing TV White Space to provide Internet connectivity service to slave devices, inclu= ding the ability to clear WSDs from select channels, is described. This scenario consists of the following steps: 1. The master/AP powers up; however its WS radio and all other WS capable devices will power up in idle/listen only mode (no active transmissions on the WS frequency band). A local regulator m= ay identify exception cases where a Master may initialize over white space = (e.g. the FCC allows a Master to initialize over TV white space in certain = conditions)." 2. The master/AP has Internet connectivity , determines its loc= ation (either from location determination capability or from saved value th= at was set during installation), and establishes a connection to = a trusted white space database (see Section 4.1 reference is to database discovery, will be updated in next version). 3. The master/AP registers with the trusted database according to regulatory domain requirements (see Section 4.2 reference = is to registration, will be updated in next version). 4. Following the successful registration process, the = master/AP will send a query to the trusted database requesting a list of available WS channels based upon its geolocation. The complete set of par= ameters to be provided from the Master to the database is specified by the = local regulator. Parameters may include WSD location, accuracy of of that l= ocation, device antenna height, device identifier of a slave device request= ing channel information. 5. If the master/AP has met all regulatory domain requirements (e.g. been previously authenticated, etc), the database responds with a list of available white space channels that the master may use, and optionally a duration of time for their use, associated = maximum power levels or a notification of any additional requirement for se= nsing. 6. Once the master/AP has met all regulatory domain requirements (e.g. authenticated the WS channel list response message from the database, etc), the AP selects an available WS channel(s) from the list. 7. The slave or user device scans the TV bands to locate a master/AP transmission, and associates with the AP. insert new step<= /Ed. Note> 8. The slave/user device queries the master for a channel list, providing to the master the slaves' Device ID and optionally its geolocatio= n. 9. Once the master/AP has met all regulatory domain requirements (e.g. validating the Device ID with the trusted database, etc) the master provides the list of channels locally available to the slave/user device. If the channel that the user terminal is currently using is not included in the list of locally available channels, the slave/user device ceases all operation on its current channel. The slave/user device may scan for another AP transmission on a different channel. 10. The master/AP must periodically repeat the process to request a chan= nel list from the database, steps 4 through 6 above. The frequency to repea= t the process is determined by the local regulator. If the response from th= e database indicates a channel being used by the master/AP is not available= , the master/AP must stop transmitting on that channel immediately.In addit= ion or optionally, the database may send a message to the master/AP to resc= ind the availability of one or more channels. The master/AP must stop trans= mitting on that channel immediately. 11. The slave or user device must periodically repeat the process to req= uest a channel list from the master/AP, steps 8 and 9 above. The frequency = to repeat the process is determined by the local regulator. If the response= from the master/AP indicates that a channel being used by the slave or use= r device is not available, the slave or user device must stop transmitting = on that channel immediately. In addition or optionally, the database may se= nd a message to the master/AP to rescind the availability of one or more ch= annels. The master/AP must then notify the slave or user device of the resc= inded channels. The slave or user device must stop transmitting on that cha= nnel immediately. _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From jmalyar@telcordia.com Mon Feb 6 09:43:41 2012 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 6987621F86A6 for ; Mon, 6 Feb 2012 09:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.122 X-Spam-Level: X-Spam-Status: No, score=-2.122 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8K+EZ5MbGUZ for ; Mon, 6 Feb 2012 09:43:40 -0800 (PST) Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.23]) by ietfa.amsl.com (Postfix) with ESMTP id 817C921F8522 for ; Mon, 6 Feb 2012 09:43:39 -0800 (PST) Received: from rrc-dte-bms01.telcordia.com (rrc-dte-bms01.cc.telcordia.com [128.96.150.38]) by dnsmx2pya.telcordia.com (8.13.8+Sun/8.13.8) with ESMTP id q16HhV6a023923; Mon, 6 Feb 2012 12:43:36 -0500 (EST) X-AuditID: 80609626-b7bf7ae0000049ee-cf-4f301146a160 Received: from pya-dte-exhb1.dte.telcordia.com (pya-dte-exhb1.cc.telcordia.com [128.96.20.11]) by rrc-dte-bms01.telcordia.com (Symantec Brightmail Gateway) with SMTP id 94.38.18926.641103F4; Mon, 6 Feb 2012 12:43:34 -0500 (EST) Received: from rrc-dte-exmb1.dte.telcordia.com ([128.96.180.10]) by pya-dte-exhb1.dte.telcordia.com ([128.96.20.11]) with mapi; Mon, 6 Feb 2012 12:43:35 -0500 From: "Malyar, John P" To: "'Nancy Bravin'" , "'scott.probasco@nokia.com'" Date: Mon, 6 Feb 2012 12:43:34 -0500 Thread-Topic: [paws] FCC OET Requests Comments on Testing of Telcordia TV Bands Database Thread-Index: AczhKLco39NjuhFgSiCgGizw3VjyOgDzFHIg Message-ID: <5CFF94AC6128EA478EB1B82775E1B6A726FB091313@rrc-dte-exmb1.dte.telcordia.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: multipart/alternative; boundary="_000_5CFF94AC6128EA478EB1B82775E1B6A726FB091313rrcdteexmb1dt_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "'paws@ietf.org'" Subject: Re: [paws] FCC OET Requests Comments on Testing of Telcordia TV Bands Database 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: Mon, 06 Feb 2012 17:43:41 -0000 --_000_5CFF94AC6128EA478EB1B82775E1B6A726FB091313rrcdteexmb1dt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nancy, Scott I thought I would send a clarification/update regarding this previous email= . The purpose of the Public Notice was to inform that the Final Report rega= rding the 45 Day Public Trial of the Telcordia Database has been uploaded. = Unfortunately when it was first sent by the FCC it included the original Pu= blic Notice DA 11-1956 from December 2nd, about the Trial beginning Decembe= r 7th, 2011. It has since been updated. Now if anyone clicks the link you = included below it will correctly point to the updated Public Notice DA 12-1= 18 from February 1st. If anyone viewed the link the day you forwarded it, = they may want to review the updated notice. Regards, John Malyar From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Nan= cy Bravin Sent: Wednesday, February 01, 2012 4:30 PM To: scott.probasco@nokia.com Cc: paws@ietf.org Subject: [paws] FCC OET Requests Comments on Testing of Telcordia TV Bands = Database Scott and all, Thought you might be interested http://transition.fcc.gov/Daily_Releases/Daily_Business/2012/db0201/DA-12-1= 18A1.pdf --_000_5CFF94AC6128EA478EB1B82775E1B6A726FB091313rrcdteexmb1dt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nancy, Scott

 

I thought I would sen= d a clarification/update regarding this previous email. The purpose of the = Public Notice was to inform that the Final Report regarding the 45 Day Publ= ic Trial of the Telcordia Database has been uploaded. Unfortunately when it= was first sent by the FCC it included the original Public Notice DA 11-195= 6 from= December 2nd, about the Trial beginning December 7th, 2011. It has since been upd= ated.  Now if anyone clicks the link you included below it will correc= tly point to the updated Public Notice DA 12-118 from February 1st.  If anyone viewed the link the day you forwarded it, they may want= to review the updated notice.

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

Regards,=

 

John Malyar

From: p= aws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Nan= cy Bravin
Sent: Wednesday, February 01, 2012 4:30 PM
To: scott.probasco@nokia.com
Cc: paws@ietf.org
Subject: [= paws] FCC OET Requests Comments on Testing of Telcordia TV Bands Database

 

<= p class=3DMsoNormal>Scott and all, 

Thought you might be interested

http://transition.fcc.gov/Daily_Rel= eases/Daily_Business/2012/db0201/DA-12-118A1.pdf

 

= --_000_5CFF94AC6128EA478EB1B82775E1B6A726FB091313rrcdteexmb1dt_-- From scott.probasco@nokia.com Mon Feb 6 12:30:20 2012 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 9190521F872B for ; Mon, 6 Feb 2012 12:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKHRvHZt44uf for ; Mon, 6 Feb 2012 12:30:19 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 699ED21F8711 for ; Mon, 6 Feb 2012 12:30:15 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q16KTX0d004340; Mon, 6 Feb 2012 22:30:13 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 22:29:37 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Mon, 6 Feb 2012 21:29:36 +0100 From: To: , Thread-Topic: [paws] registration protocol Thread-Index: AQHM40EqtuE7icuw+02zHWZ2gjFODZYv4EQA Date: Mon, 6 Feb 2012 20:29:35 +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.14.0.111121 x-originating-ip: [10.241.48.4] Content-Type: multipart/alternative; boundary="_000_CB5593A2107C3scottprobasconokiacom_" MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2012 20:29:37.0417 (UTC) FILETIME=[0B9EEF90:01CCE50E] X-Nokia-AV: Clean Subject: Re: [paws] registration protocol 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: Mon, 06 Feb 2012 20:30:20 -0000 --_000_CB5593A2107C3scottprobasconokiacom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, Good comment. I will add another step to the registration service, step 3, = to include an acknowledgement from the database to the master, with a resul= t code. Kind Regards, Scott From: "ext com>" = > Date: Sat, 4 Feb 2012 08:30:07 -0500 To: "paws@ietf.org" > Subject: [paws] registration protocol Section 4.1.2 below describes the registration protocol 4.1.2. Device registration with trusted Database This use caseRegistration is preliminary to creating a radio network using TV white space; it is a prerequisite to otherthe use cases below. The radio network is created by a master device. Before the master device can transmit in TV white space spectrum, it must contact a trusted database where the device can learn if any channels are available for it to use. Before the database will provide information on available TVradio channels, the master device must register with the trusted database. Specific requirements for registration come from individual regulatory domains and may be different. This does not include any acknowledgement. This is something we do support = in our FCC protocol. The reason being so we can accurately inform the devic= e if the registration attempt fails. Listed below are some of the reasons, = though I am sure there are more, we consider returning a failure code to th= e device: malformed request (e.g., required fields missing) FCC identifier not recognized or supported FCC designated no channels available location outside of regulatory domain antenna height above 30 meters HAAT above 76 meters _______________________________________________ paws mailing list paws@ietf= .org https://www.ietf.org/mailman/listinfo/paws --_000_CB5593A2107C3scottprobasconokiacom_ Content-Type: text/html; charset="us-ascii" Content-ID: <57C99CC1CFF40D479EAE84CDBFB8A930@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable
Hi Peter,

Good comment. I will add another step to the registration service, ste= p 3, to include an acknowledgement from the database to the master, with a = result code.

Kind Regards,
Scott

From: "ext com>" <<= a href=3D"mailto:peter@spectrumbridge.com">peter@spectrumbridge.com>=
Date: Sat, 4 Feb 2012 08:30:07 -050= 0
To: "paws@ietf.org" <paws@i= etf.org>
Subject: [paws] registration protoc= ol

Section 4.1.2 below describes the regi= stration protocol

4.1.2. Device regis= tration with trusted Database

<Delete>This = use case</Delete><Insert>Registration</Insert> is<= /div>
preliminary to crea= ting a radio network using <Delete>TV</Delete>
white space; it is = a prerequisite to
<Delete>other= </Delete><Insert>the</Insert> use cases
<Insert>below= </Insert>. The radio
network is created = by a master device. Before the master device can
transmit in <Del= ete>TV</Delete> white space spectrum, it must contact a
trusted
database where the = device can learn if any channels are available for
it to use. Before t= he database will provide information on available
<Delete>TV<= ;/Delete><Insert>radio</Insert> channels, the master device<= /font>
must register with = the trusted
database. Specific = requirements for registration come from
individual regulato= ry domains and may be different.


This does not include any acknowledgem= ent. This is something we do support in our FCC protocol. The reason being = so we can accurately inform the device if the registration attempt fails. L= isted below are some of the reasons, though I am sure there are more, we consider returning a failure code to t= he device:

malformed request (e.g., required fields missing)
FCC identifier not recognized or supported
FCC designated no channels available
location outside of regulatory domain
antenna height above 30 meters
HAAT above 76 meters

_______________________________________________ paws mailing list paws@ietf.org ht= tps://www.ietf.org/mailman/listinfo/paws --_000_CB5593A2107C3scottprobasconokiacom_-- From scott.probasco@nokia.com Mon Feb 6 12:39:57 2012 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 B8BD221F87BA for ; Mon, 6 Feb 2012 12:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r80zA8eWQ5B3 for ; Mon, 6 Feb 2012 12:39:56 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B924521F87B9 for ; Mon, 6 Feb 2012 12:39:56 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q16KdnTb009262; Mon, 6 Feb 2012 22:39:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 22:39:48 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Mon, 6 Feb 2012 21:39:36 +0100 From: To: , , Thread-Topic: UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) Thread-Index: AQHM5Q9winjPL72/P0qKL6qZMyxLKA== Date: Mon, 6 Feb 2012 20:39:35 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141406554D98B@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.48.4] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5972D82DD119A748B4BC3ECDEEF87600@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2012 20:39:48.0816 (UTC) FILETIME=[780B0500:01CCE50F] X-Nokia-AV: Clean Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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: Mon, 06 Feb 2012 20:39:57 -0000 Hello Andy, These steps are meant to address the FCC requirements in =A715.711(b)(3)(iv= ) where the slave device may only transmit upon receiving a list of available channels from a master. Certainly this requirement, and thus steps 8, 9 & 11, may not apply in all parts of the world. Kind Regards, Scott On 2/6/12 6:10 AM, "ext andy.sago@bt.com" wrote: >Scott, Raj, all > >I don't see the need for steps 8, 9 and 11, where slaves query the master >for frequencies. In this use case, all slaves only talk to masters, not >to each other. By definition they must be using a WS channel allocated by >the WSDB to the master WSD - they are part of the master network and >using its frequencies. The master advertises its presence in some way on >the WS (we don't need to know how or at what layer, but could be SSIDs, >beacons, required timing information etc). There must be some sort of >advertisement otherwise slaves can never connect. If the master drops use >of a frequency that a slave was using, then, like in cellular mobile or >Wi-Fi, the slave drops off the network shortly after failing to hear the >master, and will have to rejoin using another frequency being transmitted >by the master, if any. The slave never needs to ask for frequencies. > >Have I missed something, or are we making the protocol unnecessarily >complicated? > >Andy > > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >scott.probasco@nokia.com >Sent: 03 February 2012 21:42 >To: paws@ietf.org >Subject: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet >connectivity service) > >Hello All, > >As editors of the problem statement, use cases & requirements draft we >are attempting to prepare a completed draft which could be ready for >working group last call before IETF83. In the coming days we will post >the sections of the draft to the mailing list. Our request is that you >review these sections and reply to the email with any comments. > >Below is the text for section on the Hotspot use case (new section >numbering is NOT shown, all use cases will be moved to section 4.2 Use >cases in the next version). This text has been marked up from version-02 >as uploaded January 26, 2012 as follows: >* now includes steps to change the availability of spectrum on short >notice >* clarification that in some cases a master may initialize over a white >space channel >* clarification that registration includes device location >* clarification on the possible parameters in the channel request >* clarification on the possible parameters in the channel response > >Our goal is that any discussion on this text will conclude by February 10. >To be clear, approval of the document will go through the normal process >of last calls etc.. We are simply asking for your assistance in preparing >a complete & accurate document that could progress the work. So please >review the text and send your comments either directly to the editor or >to the mailing list. > >Kind Regards, >Raj & Scott > > > > > > > >4.3. Hotspot: urban internet connectivity service > > In this use case internet connectivity service is provided in a > "hotspot" to local users. Typical deployment scenarios include urban > areas where internet connectivity is provided to local businesses and > residents, and campus environments where internet connectivity is > provided to local buildings and relatively small outdoor areas. This > deployment scenario is typically characterized by multiple masters > (APs or hotspots) in close proximity, with low antenna height, cells > with relatively small radius (a few kilometers or less), and limited > numbers of available radio channels. Many of the masters/APs are > assumed to be individually deployed and operated, i.e. there is no > coordination between many of the masters/APs. The masters/APs in > this scenario use a TDD radio technology and transmit at or below a > relatively low transmit power threshold. Each master/AP has a > connection to the internet and provides internet connectivity to > multiple master and or slave devices. > > The figure below shows an example deployment of this scenario. > > > > -------- > |Device|\ \|/ ---------- > | 1 | (TDD AirIF) | |Database| > -------- \ | .---. /--------- > o \ |-|---------| ( ) / > o | Master | / \ > o / | |=3D=3D=3D=3D=3D=3D=3D=3D( Intern= et ) > o / |-----------| \ / > -------- (TDD AirIF) ( ) > |Device| / (----) > | n | > -------- > > > Figure 3: Hotspot service using TV white space spectrum > > Once a master/AP has been correctly installed and configured, a > simplified power up and operation scenario utilizing TV White Space > to provide Internet connectivity service to slave devices, >including the ability to clear WSDs from select channels, is described. >This scenario consists of the following steps: > > 1. The master/AP powers up; however its WS radio and all other WS > capable devices will power up in idle/listen only mode (no active > transmissions on the WS frequency band). A local regulator >may identify exception cases where a Master may initialize over white >space (e.g. the FCC allows a Master to initialize over TV white space in >certain conditions)." > > 2. The master/AP has Internet connectivity , determines its >location (either from location determination capability or from saved >value that was set during installation), and establishes a >connection to a trusted white space database (see Section 4.1 Note>reference is to database discovery, will be updated in next >version). > > 3. The master/AP registers with the trusted database according to > regulatory domain requirements (see Section 4.2 Note>reference is to registration, will be updated in next versionNote>). > > 4. Following the successful registration process, >the master/AP will send a > query to the trusted database requesting a list of available WS > channels based upon its geolocation. The complete set of >parameters to be provided from the Master to the database is specified by >the local regulator. Parameters may include WSD location, accuracy of of >that location, device antenna height, device identifier of a slave device >requesting channel information. > > 5. If the master/AP has met all regulatory domain requirements (e.g. > been previously authenticated, etc), the database responds with a > list of available white space channels that the master may use, > and optionally a duration of time for their use, >associated maximum power levels or a notification of any additional >requirement for sensing. > > 6. Once the master/AP has met all regulatory domain requirements > (e.g. authenticated the WS channel list response message from the > database, etc), the AP selects an available WS channel(s) from > the list. > > 7. The slave or user device scans the TV bands to locate a master/AP > transmission, and associates with the AP. insert new >step > > 8. The slave/user device > queries the master for a channel list, providing to the master > the slaves' Device ID and optionally its >geolocation. > > 9. Once the master/AP has met all regulatory domain requirements > (e.g. validating the Device ID with the trusted database, etc) > the master provides the list of channels locally available to the > slave/user device. If the channel that the user terminal is > currently using is not included in the list of locally available > channels, the slave/user device ceases all operation on its > current channel. The slave/user device may scan for another AP > transmission on a different channel. > > > 10. The master/AP must periodically repeat the process to request a >channel list from the database, steps 4 through 6 above. The frequency to >repeat the process is determined by the local regulator. If the response >from the database indicates a channel being used by the master/AP is not >available, the master/AP must stop transmitting on that channel >immediately.In addition or optionally, the database may send a message to >the master/AP to rescind the availability of one or more channels. The >master/AP must stop transmitting on that channel immediately. > > 11. The slave or user device must periodically repeat the process to >request a channel list from the master/AP, steps 8 and 9 above. The >frequency to repeat the process is determined by the local regulator. If >the response from the master/AP indicates that a channel being used by >the slave or user device is not available, the slave or user device must >stop transmitting on that channel immediately. In addition or optionally, >the database may send a message to the master/AP to rescind the >availability of one or more channels. The master/AP must then notify the >slave or user device of the rescinded channels. The slave or user device >must stop transmitting on that channel immediately. > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From paul@marvell.com Mon Feb 6 12:57:17 2012 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 2D37421F874A for ; Mon, 6 Feb 2012 12:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.412 X-Spam-Level: X-Spam-Status: No, score=-6.412 tagged_above=-999 required=5 tests=[AWL=0.187, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIddb6SE6FsW for ; Mon, 6 Feb 2012 12:57:16 -0800 (PST) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBF321F8739 for ; Mon, 6 Feb 2012 12:57:15 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTzA+pcBv038Z07M8RdpFfLYrYVMgpdfn@postini.com; Mon, 06 Feb 2012 12:57:15 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 6 Feb 2012 12:57:02 -0800 From: Paul Lambert To: "scott.probasco@nokia.com" , "stephen.farrell@cs.tcd.ie" , "paws@ietf.org" Date: Mon, 6 Feb 2012 12:57:02 -0800 Thread-Topic: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) Thread-Index: AQHM4s2RBngGT1NM+kmcIUkz3XesvZYr5nuA//+g0oCABMKWcA== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4F62E@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01567763FAB@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 Subject: Re: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) 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: Mon, 06 Feb 2012 20:57:17 -0000 >Device manufacturers are interested in ability to switch off stolen >devices. No. This is not a valid use case for a license exempt usage of a regulator= y database. Any payment system or authorization to use a device outside of= the regulatory limitations should not be part of the regulatory focused pr= otocol. How would a device manufacture contact a regulatory authority to "kill" a d= evice? How would a user report a stolen device? How would you prevent incorrect reports of stolen devices being used to shu= t off a device. Why do we need a kill switch for a single non-conforming device - when the = certification is for a device class. If one device is interfering, it's li= kely all like device types would interfere at the same location. The enabl= ed region could be changed, or the device type black listed. If a device is able to operate in a manner that ignores the database, than = it may interfere, but would not be able to "killed" since it is already ign= oring the database. The is a history of needing unique identifiers for licensed devices. Corre= ct operation for most licensed devices is based on human configuration and = correct usage of the system. A unique identifier is required to allow such= human controlled usage to be tracked and action taken if the device operat= es outside of it's license considerations. "killing devices" should not be a mandatory feature of the paws protocol an= d should only be based a model of the regulatory requirements for a region. Unique device identifiers shoul also be optional. Paul >-----Original Message----- >From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] >Sent: Friday, February 03, 2012 6:03 PM >To: Paul Lambert; stephen.farrell@cs.tcd.ie; paws@ietf.org >Subject: Re: [paws] wondering why a device identifier is needed (was: >Re: Threat model (Rev 3)) > >Hi, > >A couple of motivations for device-specific identifiers are >* ability to black-list or disable a specific device. Regulators are >interested in ability to switch off a device that causes interference. >Device manufacturers are interested in ability to switch off stolen >devices. >* ability to directly address a specific device. One example here is the >'kill switch' described by Ofcom. > >Kind Regards, >Scott > > >On 2/3/12 7:43 PM, "ext Paul Lambert" wrote: > >> >>Good question. >> >>If a set of certified devices (vendor / model type) are all supposed to >>act the same, then any interference problem could be handled by >changing >>contours or blocking all of the model/types. >> >>Paul >> >> >>>-----Original Message----- >>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >Of >>>Stephen Farrell >>>Sent: Friday, February 03, 2012 3:43 PM >>>To: paws@ietf.org >>>Subject: [paws] wondering why a device identifier is needed (was: Re: >>>Threat model (Rev 3)) >>> >>> >>>So this is a bit of a side-issue maybe but I do wonder >>>if there's any functional/technical reason, other than >>>"the FCC said so," to identify a specific device in the >>>paws protocol with a long-lived identifier? >>> >>>I can see why you'd want a device type of some sort, >>>and the DB might need some kind of session ID, but >>>I don't get the long-lived device identifier thing >>>at all as a functional requirement. Can anyone explain? >>> >>>I'm not asking now from the privacy or security p-o-v, >>>but rather because its easier and cheaper and simpler to >>>not bother if you don't have to. >>> >>>It does also interact with privacy & security of course. >>>Once you have to manage the identifier then you may need >>>to go to some trouble to protect that, but that's a >>>secondary question. >>> >>>Thanks, >>>S. >>> >>>On 02/03/2012 11:19 PM, Paul Lambert wrote: >>>>> using it themselves or retransmitting it. The resulting data one >>>>> whitespace availability will be visible to people and or devices >>>which >>>>> are not completely controlled by the regulatory agencies. >>>>> As such, what is the role of confidentiality with regard to this >>>>> information? >>>> >>>> All channel availability (at least for the FCC) is openly available. >>>There is no threat of disclosure of this information. It's actually >the >>>reverse. For planning purposes to buy and use WS devices - you really >>>would like a good picture of available spectrum. It would be very >>>detremental to market adoption to limit access to the available >>>channels. >>>> >>>> That said - the current incumbants we discuss are just TV and >>>microphones. In the future, we might be sharing with public saftey or >>>military applications that would not want readily accessable maps of >>>their locations disseminated. "Open" consumer devices might in these >>>scenarios see no spectrum and the approved devices would get >>>allocations. This still should be out-of-scope. These types of >devices >>>are not in our use case scenarios. >>>> >>>> Privacy as you point out alone is a good justification for some form >>>of confidentiality. But protecting a devices identity may not require >>>encryption of the full paws messages. >>>> >>>> Intgrity and data origin authentication seem more important for the >>>protocol design considerations. >>>> >>>> Paul >>>> >>>> >>>>> -----Original Message----- >>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >Behalf >>>Of >>>>> Joel M. Halpern >>>>> Sent: Friday, February 03, 2012 11:51 AM >>>>> To: Basavaraj.Patil@nokia.com >>>>> Cc: paws@ietf.org >>>>> Subject: Re: [paws] Threat model (Rev 3) >>>>> >>>>> Can we please include in this document some articulation of the >>>>> confidentiality assumption we are making with regard to the >>>whitespace >>>>> data itself? I am not trying to object to the threats. (And the >>>>> personal information collection issues are enough to jsutify >include >>>>> confidentiality mechanisms in the solutions.) >>>>> But I am still trying to get my head around this. There are going >to >>>be >>>>> hoards of whitespace devices. They will be getting the data, and >>>either >>>>> using it themselves or retransmitting it. The resulting data one >>>>> whitespace availability will be visible to people and or devices >>>which >>>>> are not completely controlled by the regulatory agencies. >>>>> As such, what is the role of confidentiality with regard to this >>>>> information? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>>> >>>>>> Below is Rev 3 of the threat model based on feedback from Stephen, >>>>> Nancy >>>>>> and Gabor (Thanks). >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> Rev 3 (3/2/12) >>>>>> >>>>>> Threat model for the PAWS protocol >>>>>> ---------------------------------- >>>>>> >>>>>> Assumptions: >>>>>> ............ >>>>>> >>>>>> o It is assumed that an attacker has full access to the network >>>medium >>>>>> between the master device and the white space database. The >>>>> attacker >>>>>> may be able to eavesdrop on any communications between these >>>>>> entities. The link between the master device and the white >space >>>>>> database can be wired or wireless and provides IP >connectivity. >>>>>> >>>>>> o It is assumed that the master device or the white space database >>>>>> have NOT been compromised from a security standpoint. >>>>>> >>>>>> Threat 1: User modifies a device to masquerade as another valid >>>>>> certified device >>>>>> >>>>>> The master device needs to authenticate itself with the >>>white >>>>>> space database prior to requesting channel information. >The >>>>>> attacker may try to get access to the secrets of the >master >>>>>> device which can be used maliciously. The effect of such >an >>>>>> attack being successful would result in a malicious >client >>>>>> replaying the stolen authentication/authorization secrets >>>to a >>>>>> white space database. >>>>>> >>>>>> Threat 2: Spoofed white space database >>>>>> >>>>>> A master device discovers a white space database(s) thru >>>which >>>>>> it can query for channel information. The master device >>>needs >>>>>> to ensure that the white space database with which it >>>>>> communicates with is an authentic entity. The white space >>>>>> database needs to provide its identity to the master >device >>>>>> which can confirm the validity/authenticty of the >database. >>>An >>>>>> attacker may attempt to spoof a white space database and >>>>>> provide responses to a master device which are malicious >>>and >>>>>> result in the master device causing interference to the >>>>> primary >>>>>> user of the spectrum. >>>>>> >>>>>> Threat 3: Modifying a query request >>>>>> >>>>>> An attacker may modify the query request sent by a master >>>>>> device to a white space database. The attacker may change >>>the >>>>>> location of the device or the capabilities in terms of >its >>>>>> transmit power or antenna height etc. which could result >in >>>>> the >>>>>> database responding with incorrect information about >>>available >>>>>> channels or max transmit power allowed. The result of >such >>>an >>>>>> attack is that the master device would cause >intereference >>>to >>>>>> the primary user of the spectrum. It could also result in >a >>>>>> denial of service to the master device by indicating that >>>no >>>>>> channels are available. >>>>>> >>>>>> Threat 4: Modifying a query response >>>>>> >>>>>> An attacker could modify the query response sent by the >>>white >>>>>> space database to a master device. The channel >information >>>or >>>>>> transmit power allowed type of parameters carried in the >>>>>> response could be modified by the attacker resulting in >the >>>>>> master device using channels that are not available at a >>>>>> location or transmitting at a greater power level than >>>allowed >>>>>> resulting in interference to the primary user of that >>>>>> spectrum. Alternatively the attacker may indicate no >>>channel >>>>>> availability at a location resulting in a denial of >service >>>to >>>>>> the master device. >>>>>> >>>>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>>> >>>>>> An attacker may be a master device which is not certified >>>for >>>>>> use by the relevant regulatory body. The attacker may >>>listen >>>>> to >>>>>> the communication between a valid master device and white >>>>> space >>>>>> database and utilize the information about available >>>channels >>>>>> in the response message by utilizing those channels. The >>>>> result >>>>>> of such an attack is unauthorized use of channels by a >>>master >>>>>> device which is not certified to operate. >>>>>> The master device querying the white space database may >be >>>>>> operated by a law-enforcement agency and the >communications >>>>>> between the device and the database are intended to be >kept >>>>>> private. A malicious device should not be able to >eavesdrop >>>on >>>>>> such communications. >>>>>> >>>>>> Threat 6: Third party tracking of white space device location and >>>>> identity >>>>>> >>>>>> A white space database may require a master device to >>>provide >>>>>> its identity in addition to its location in the query >>>request. >>>>>> Such location/identity information can be gleaned by an >>>>>> eavesdropper. A master device may prefer to keep the >>>>>> location/identity information secret. Hence the protocol >>>>> should >>>>>> provide a means to protect the location and identity >>>>>> information of the master device and prevent tracking of >>>>>> locations associated with a white space database. If >>>>>> regulations do not require the identity of the master >>>device >>>>> to >>>>>> be provided to the white space database, the master is >not >>>>>> required to include its identity in the query. >>>>>> >>>>>> >>>>>> Threat 7: Termination of device service for reasons other than >>>>>> incumbent protection >>>>>> >>>>>> A white space database may include a mechanism by which >>>>> service >>>>>> and channels allocated to a master device can be revoked. >A >>>>>> malicious node can send a revoke message to a master >>>>>> device. This results in denial of service to the master >>>>>> device. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 andy.sago@bt.com Mon Feb 6 12:59:00 2012 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 9697321F86C7 for ; Mon, 6 Feb 2012 12:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I+pjBnhNkyl for ; Mon, 6 Feb 2012 12:58:59 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEB521F85F4 for ; Mon, 6 Feb 2012 12:58:59 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 6 Feb 2012 20:58:57 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT66-UKRD.domain1.systemhost.net ([10.36.3.103]) with mapi; Mon, 6 Feb 2012 20:58:57 +0000 From: To: , , Date: Mon, 6 Feb 2012 20:58:58 +0000 Thread-Topic: UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) Thread-Index: AQHM5Q9winjPL72/P0qKL6qZMyxLKJYwWiqo Message-ID: <619CDADDCCD2B44380834BE8BF6F7141406528B6ED@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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: Mon, 06 Feb 2012 20:59:00 -0000 Scott Thanks for the explanation, sorry I hadn't spotted this difference UK-US. Regards Andy -----Original Message----- From: scott.probasco@nokia.com Sent: 06 February 2012 20:39 To: Sago,AJ,Andy,COD R ; Basavaraj.Patil@nokia.com ; paws@ietf.org Subject: Re: UC&R I-D: section 4.3 (Hotspot: urban internet connectivity se= rvice) Hello Andy, These steps are meant to address the FCC requirements in =A715.711(b)(3)(iv= ) where the slave device may only transmit upon receiving a list of available channels from a master. Certainly this requirement, and thus steps 8, 9 & 11, may not apply in all parts of the world. Kind Regards, Scott On 2/6/12 6:10 AM, "ext andy.sago@bt.com" wrote: >Scott, Raj, all > >I don't see the need for steps 8, 9 and 11, where slaves query the master >for frequencies. In this use case, all slaves only talk to masters, not >to each other. By definition they must be using a WS channel allocated by >the WSDB to the master WSD - they are part of the master network and >using its frequencies. The master advertises its presence in some way on >the WS (we don't need to know how or at what layer, but could be SSIDs, >beacons, required timing information etc). There must be some sort of >advertisement otherwise slaves can never connect. If the master drops use >of a frequency that a slave was using, then, like in cellular mobile or >Wi-Fi, the slave drops off the network shortly after failing to hear the >master, and will have to rejoin using another frequency being transmitted >by the master, if any. The slave never needs to ask for frequencies. > >Have I missed something, or are we making the protocol unnecessarily >complicated? > >Andy > > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >scott.probasco@nokia.com >Sent: 03 February 2012 21:42 >To: paws@ietf.org >Subject: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet >connectivity service) > >Hello All, > >As editors of the problem statement, use cases & requirements draft we >are attempting to prepare a completed draft which could be ready for >working group last call before IETF83. In the coming days we will post >the sections of the draft to the mailing list. Our request is that you >review these sections and reply to the email with any comments. > >Below is the text for section on the Hotspot use case (new section >numbering is NOT shown, all use cases will be moved to section 4.2 Use >cases in the next version). This text has been marked up from version-02 >as uploaded January 26, 2012 as follows: >* now includes steps to change the availability of spectrum on short >notice >* clarification that in some cases a master may initialize over a white >space channel >* clarification that registration includes device location >* clarification on the possible parameters in the channel request >* clarification on the possible parameters in the channel response > >Our goal is that any discussion on this text will conclude by February 10. >To be clear, approval of the document will go through the normal process >of last calls etc.. We are simply asking for your assistance in preparing >a complete & accurate document that could progress the work. So please >review the text and send your comments either directly to the editor or >to the mailing list. > >Kind Regards, >Raj & Scott > > > > > > > >4.3. Hotspot: urban internet connectivity service > > In this use case internet connectivity service is provided in a > "hotspot" to local users. Typical deployment scenarios include urban > areas where internet connectivity is provided to local businesses and > residents, and campus environments where internet connectivity is > provided to local buildings and relatively small outdoor areas. This > deployment scenario is typically characterized by multiple masters > (APs or hotspots) in close proximity, with low antenna height, cells > with relatively small radius (a few kilometers or less), and limited > numbers of available radio channels. Many of the masters/APs are > assumed to be individually deployed and operated, i.e. there is no > coordination between many of the masters/APs. The masters/APs in > this scenario use a TDD radio technology and transmit at or below a > relatively low transmit power threshold. Each master/AP has a > connection to the internet and provides internet connectivity to > multiple master and or slave devices. > > The figure below shows an example deployment of this scenario. > > > > -------- > |Device|\ \|/ ---------- > | 1 | (TDD AirIF) | |Database| > -------- \ | .---. /--------- > o \ |-|---------| ( ) / > o | Master | / \ > o / | |=3D=3D=3D=3D=3D=3D=3D=3D( Intern= et ) > o / |-----------| \ / > -------- (TDD AirIF) ( ) > |Device| / (----) > | n | > -------- > > > Figure 3: Hotspot service using TV white space spectrum > > Once a master/AP has been correctly installed and configured, a > simplified power up and operation scenario utilizing TV White Space > to provide Internet connectivity service to slave devices, >including the ability to clear WSDs from select channels, is described. >This scenario consists of the following steps: > > 1. The master/AP powers up; however its WS radio and all other WS > capable devices will power up in idle/listen only mode (no active > transmissions on the WS frequency band). A local regulator >may identify exception cases where a Master may initialize over white >space (e.g. the FCC allows a Master to initialize over TV white space in >certain conditions)." > > 2. The master/AP has Internet connectivity , determines its >location (either from location determination capability or from saved >value that was set during installation), and establishes a >connection to a trusted white space database (see Section 4.1 Note>reference is to database discovery, will be updated in next >version). > > 3. The master/AP registers with the trusted database according to > regulatory domain requirements (see Section 4.2 Note>reference is to registration, will be updated in next versionNote>). > > 4. Following the successful registration process, >the master/AP will send a > query to the trusted database requesting a list of available WS > channels based upon its geolocation. The complete set of >parameters to be provided from the Master to the database is specified by >the local regulator. Parameters may include WSD location, accuracy of of >that location, device antenna height, device identifier of a slave device >requesting channel information. > > 5. If the master/AP has met all regulatory domain requirements (e.g. > been previously authenticated, etc), the database responds with a > list of available white space channels that the master may use, > and optionally a duration of time for their use, >associated maximum power levels or a notification of any additional >requirement for sensing. > > 6. Once the master/AP has met all regulatory domain requirements > (e.g. authenticated the WS channel list response message from the > database, etc), the AP selects an available WS channel(s) from > the list. > > 7. The slave or user device scans the TV bands to locate a master/AP > transmission, and associates with the AP. insert new >step > > 8. The slave/user device > queries the master for a channel list, providing to the master > the slaves' Device ID and optionally its >geolocation. > > 9. Once the master/AP has met all regulatory domain requirements > (e.g. validating the Device ID with the trusted database, etc) > the master provides the list of channels locally available to the > slave/user device. If the channel that the user terminal is > currently using is not included in the list of locally available > channels, the slave/user device ceases all operation on its > current channel. The slave/user device may scan for another AP > transmission on a different channel. > > > 10. The master/AP must periodically repeat the process to request a >channel list from the database, steps 4 through 6 above. The frequency to >repeat the process is determined by the local regulator. If the response >from the database indicates a channel being used by the master/AP is not >available, the master/AP must stop transmitting on that channel >immediately.In addition or optionally, the database may send a message to >the master/AP to rescind the availability of one or more channels. The >master/AP must stop transmitting on that channel immediately. > > 11. The slave or user device must periodically repeat the process to >request a channel list from the master/AP, steps 8 and 9 above. The >frequency to repeat the process is determined by the local regulator. If >the response from the master/AP indicates that a channel being used by >the slave or user device is not available, the slave or user device must >stop transmitting on that channel immediately. In addition or optionally, >the database may send a message to the master/AP to rescind the >availability of one or more channels. The master/AP must then notify the >slave or user device of the rescinded channels. The slave or user device >must stop transmitting on that channel immediately. > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Mon Feb 6 13:12:36 2012 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 8684221F853E for ; Mon, 6 Feb 2012 13:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RnokAtEqmFt for ; Mon, 6 Feb 2012 13:12:35 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id BEA9221F864F for ; Mon, 6 Feb 2012 13:12:34 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q16LCVoL002197; Mon, 6 Feb 2012 23:12:31 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 6 Feb 2012 23:12:30 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Mon, 6 Feb 2012 22:12:30 +0100 From: To: , , Thread-Topic: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) Thread-Index: AQHM4s2RBngGT1NM+kmcIUkz3XesvZYr5nuA//+g0oCABMKWcP//oz8A Date: Mon, 6 Feb 2012 21:12:29 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4F62E@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.48.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2012 21:12:31.0008 (UTC) FILETIME=[0999C200:01CCE514] X-Nokia-AV: Clean Subject: Re: [paws] wondering why a device identifier is needed (was: Re: Threat model (Rev 3)) 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: Mon, 06 Feb 2012 21:12:36 -0000 Hi Paul, I am not proposing a use case, merely replying to Stephen's side-issue. Kind Regards, Scott On 2/6/12 2:57 PM, "ext Paul Lambert" wrote: > >>Device manufacturers are interested in ability to switch off stolen >>devices. > >No. This is not a valid use case for a license exempt usage of a >regulatory database. Any payment system or authorization to use a device >outside of the regulatory limitations should not be part of the >regulatory focused protocol. > >How would a device manufacture contact a regulatory authority to "kill" a >device? >How would a user report a stolen device? >How would you prevent incorrect reports of stolen devices being used to >shut off a device. > >Why do we need a kill switch for a single non-conforming device - when >the certification is for a device class. If one device is interfering, >it's likely all like device types would interfere at the same location. >The enabled region could be changed, or the device type black listed. > >If a device is able to operate in a manner that ignores the database, >than it may interfere, but would not be able to "killed" since it is >already ignoring the database. > >The is a history of needing unique identifiers for licensed devices. >Correct operation for most licensed devices is based on human >configuration and correct usage of the system. A unique identifier is >required to allow such human controlled usage to be tracked and action >taken if the device operates outside of it's license considerations. > >"killing devices" should not be a mandatory feature of the paws protocol >and should only be based a model of the regulatory requirements for a >region. > >Unique device identifiers shoul also be optional. > >Paul > > > > > >>-----Original Message----- >>From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] >>Sent: Friday, February 03, 2012 6:03 PM >>To: Paul Lambert; stephen.farrell@cs.tcd.ie; paws@ietf.org >>Subject: Re: [paws] wondering why a device identifier is needed (was: >>Re: Threat model (Rev 3)) >> >>Hi, >> >>A couple of motivations for device-specific identifiers are >>* ability to black-list or disable a specific device. Regulators are >>interested in ability to switch off a device that causes interference. >>Device manufacturers are interested in ability to switch off stolen >>devices. >>* ability to directly address a specific device. One example here is the >>'kill switch' described by Ofcom. >> >>Kind Regards, >>Scott >> >> >>On 2/3/12 7:43 PM, "ext Paul Lambert" wrote: >> >>> >>>Good question. >>> >>>If a set of certified devices (vendor / model type) are all supposed to >>>act the same, then any interference problem could be handled by >>changing >>>contours or blocking all of the model/types. >>> >>>Paul >>> >>> >>>>-----Original Message----- >>>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >>Of >>>>Stephen Farrell >>>>Sent: Friday, February 03, 2012 3:43 PM >>>>To: paws@ietf.org >>>>Subject: [paws] wondering why a device identifier is needed (was: Re: >>>>Threat model (Rev 3)) >>>> >>>> >>>>So this is a bit of a side-issue maybe but I do wonder >>>>if there's any functional/technical reason, other than >>>>"the FCC said so," to identify a specific device in the >>>>paws protocol with a long-lived identifier? >>>> >>>>I can see why you'd want a device type of some sort, >>>>and the DB might need some kind of session ID, but >>>>I don't get the long-lived device identifier thing >>>>at all as a functional requirement. Can anyone explain? >>>> >>>>I'm not asking now from the privacy or security p-o-v, >>>>but rather because its easier and cheaper and simpler to >>>>not bother if you don't have to. >>>> >>>>It does also interact with privacy & security of course. >>>>Once you have to manage the identifier then you may need >>>>to go to some trouble to protect that, but that's a >>>>secondary question. >>>> >>>>Thanks, >>>>S. >>>> >>>>On 02/03/2012 11:19 PM, Paul Lambert wrote: >>>>>> using it themselves or retransmitting it. The resulting data one >>>>>> whitespace availability will be visible to people and or devices >>>>which >>>>>> are not completely controlled by the regulatory agencies. >>>>>> As such, what is the role of confidentiality with regard to this >>>>>> information? >>>>> >>>>> All channel availability (at least for the FCC) is openly available. >>>>There is no threat of disclosure of this information. It's actually >>the >>>>reverse. For planning purposes to buy and use WS devices - you really >>>>would like a good picture of available spectrum. It would be very >>>>detremental to market adoption to limit access to the available >>>>channels. >>>>> >>>>> That said - the current incumbants we discuss are just TV and >>>>microphones. In the future, we might be sharing with public saftey or >>>>military applications that would not want readily accessable maps of >>>>their locations disseminated. "Open" consumer devices might in these >>>>scenarios see no spectrum and the approved devices would get >>>>allocations. This still should be out-of-scope. These types of >>devices >>>>are not in our use case scenarios. >>>>> >>>>> Privacy as you point out alone is a good justification for some form >>>>of confidentiality. But protecting a devices identity may not require >>>>encryption of the full paws messages. >>>>> >>>>> Intgrity and data origin authentication seem more important for the >>>>protocol design considerations. >>>>> >>>>> Paul >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On >>Behalf >>>>Of >>>>>> Joel M. Halpern >>>>>> Sent: Friday, February 03, 2012 11:51 AM >>>>>> To: Basavaraj.Patil@nokia.com >>>>>> Cc: paws@ietf.org >>>>>> Subject: Re: [paws] Threat model (Rev 3) >>>>>> >>>>>> Can we please include in this document some articulation of the >>>>>> confidentiality assumption we are making with regard to the >>>>whitespace >>>>>> data itself? I am not trying to object to the threats. (And the >>>>>> personal information collection issues are enough to jsutify >>include >>>>>> confidentiality mechanisms in the solutions.) >>>>>> But I am still trying to get my head around this. There are going >>to >>>>be >>>>>> hoards of whitespace devices. They will be getting the data, and >>>>either >>>>>> using it themselves or retransmitting it. The resulting data one >>>>>> whitespace availability will be visible to people and or devices >>>>which >>>>>> are not completely controlled by the regulatory agencies. >>>>>> As such, what is the role of confidentiality with regard to this >>>>>> information? >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>>>> >>>>>>> Below is Rev 3 of the threat model based on feedback from Stephen, >>>>>> Nancy >>>>>>> and Gabor (Thanks). >>>>>>> >>>>>>> -Raj >>>>>>> >>>>>>> >>>>>>> Rev 3 (3/2/12) >>>>>>> >>>>>>> Threat model for the PAWS protocol >>>>>>> ---------------------------------- >>>>>>> >>>>>>> Assumptions: >>>>>>> ............ >>>>>>> >>>>>>> o It is assumed that an attacker has full access to the network >>>>medium >>>>>>> between the master device and the white space database. The >>>>>> attacker >>>>>>> may be able to eavesdrop on any communications between these >>>>>>> entities. The link between the master device and the white >>space >>>>>>> database can be wired or wireless and provides IP >>connectivity. >>>>>>> >>>>>>> o It is assumed that the master device or the white space database >>>>>>> have NOT been compromised from a security standpoint. >>>>>>> >>>>>>> Threat 1: User modifies a device to masquerade as another valid >>>>>>> certified device >>>>>>> >>>>>>> The master device needs to authenticate itself with the >>>>white >>>>>>> space database prior to requesting channel information. >>The >>>>>>> attacker may try to get access to the secrets of the >>master >>>>>>> device which can be used maliciously. The effect of such >>an >>>>>>> attack being successful would result in a malicious >>client >>>>>>> replaying the stolen authentication/authorization secrets >>>>to a >>>>>>> white space database. >>>>>>> >>>>>>> Threat 2: Spoofed white space database >>>>>>> >>>>>>> A master device discovers a white space database(s) thru >>>>which >>>>>>> it can query for channel information. The master device >>>>needs >>>>>>> to ensure that the white space database with which it >>>>>>> communicates with is an authentic entity. The white space >>>>>>> database needs to provide its identity to the master >>device >>>>>>> which can confirm the validity/authenticty of the >>database. >>>>An >>>>>>> attacker may attempt to spoof a white space database and >>>>>>> provide responses to a master device which are malicious >>>>and >>>>>>> result in the master device causing interference to the >>>>>> primary >>>>>>> user of the spectrum. >>>>>>> >>>>>>> Threat 3: Modifying a query request >>>>>>> >>>>>>> An attacker may modify the query request sent by a master >>>>>>> device to a white space database. The attacker may change >>>>the >>>>>>> location of the device or the capabilities in terms of >>its >>>>>>> transmit power or antenna height etc. which could result >>in >>>>>> the >>>>>>> database responding with incorrect information about >>>>available >>>>>>> channels or max transmit power allowed. The result of >>such >>>>an >>>>>>> attack is that the master device would cause >>intereference >>>>to >>>>>>> the primary user of the spectrum. It could also result in >>a >>>>>>> denial of service to the master device by indicating that >>>>no >>>>>>> channels are available. >>>>>>> >>>>>>> Threat 4: Modifying a query response >>>>>>> >>>>>>> An attacker could modify the query response sent by the >>>>white >>>>>>> space database to a master device. The channel >>information >>>>or >>>>>>> transmit power allowed type of parameters carried in the >>>>>>> response could be modified by the attacker resulting in >>the >>>>>>> master device using channels that are not available at a >>>>>>> location or transmitting at a greater power level than >>>>allowed >>>>>>> resulting in interference to the primary user of that >>>>>>> spectrum. Alternatively the attacker may indicate no >>>>channel >>>>>>> availability at a location resulting in a denial of >>service >>>>to >>>>>>> the master device. >>>>>>> >>>>>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>>>> >>>>>>> An attacker may be a master device which is not certified >>>>for >>>>>>> use by the relevant regulatory body. The attacker may >>>>listen >>>>>> to >>>>>>> the communication between a valid master device and white >>>>>> space >>>>>>> database and utilize the information about available >>>>channels >>>>>>> in the response message by utilizing those channels. The >>>>>> result >>>>>>> of such an attack is unauthorized use of channels by a >>>>master >>>>>>> device which is not certified to operate. >>>>>>> The master device querying the white space database may >>be >>>>>>> operated by a law-enforcement agency and the >>communications >>>>>>> between the device and the database are intended to be >>kept >>>>>>> private. A malicious device should not be able to >>eavesdrop >>>>on >>>>>>> such communications. >>>>>>> >>>>>>> Threat 6: Third party tracking of white space device location and >>>>>> identity >>>>>>> >>>>>>> A white space database may require a master device to >>>>provide >>>>>>> its identity in addition to its location in the query >>>>request. >>>>>>> Such location/identity information can be gleaned by an >>>>>>> eavesdropper. A master device may prefer to keep the >>>>>>> location/identity information secret. Hence the protocol >>>>>> should >>>>>>> provide a means to protect the location and identity >>>>>>> information of the master device and prevent tracking of >>>>>>> locations associated with a white space database. If >>>>>>> regulations do not require the identity of the master >>>>device >>>>>> to >>>>>>> be provided to the white space database, the master is >>not >>>>>>> required to include its identity in the query. >>>>>>> >>>>>>> >>>>>>> Threat 7: Termination of device service for reasons other than >>>>>>> incumbent protection >>>>>>> >>>>>>> A white space database may include a mechanism by which >>>>>> service >>>>>>> and channels allocated to a master device can be revoked. >>A >>>>>>> malicious node can send a revoke message to a master >>>>>>> device. This results in denial of service to the master >>>>>>> device. >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 paul@marvell.com Mon Feb 6 15:03:08 2012 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 47D9F11E80AE for ; Mon, 6 Feb 2012 15:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4qq4T2-uvSt for ; Mon, 6 Feb 2012 15:03:07 -0800 (PST) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id 6270211E8099 for ; Mon, 6 Feb 2012 15:03:06 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKTzBcJP3DutFmqlZNZxHOO1t+2tvkX/5R@postini.com; Mon, 06 Feb 2012 15:03:06 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Mon, 6 Feb 2012 15:00:05 -0800 From: Paul Lambert To: "andy.sago@bt.com" , "scott.probasco@nokia.com" , "Basavaraj.Patil@nokia.com" , "paws@ietf.org" Date: Mon, 6 Feb 2012 15:00:04 -0800 Thread-Topic: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) Thread-Index: AQHM4ryf5uLLQgfWlUG94XlZz/QApZYvxnqAgACwVbA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4F6A7@SC-VEXCH2.marvell.com> References: <619CDADDCCD2B44380834BE8BF6F7141406554D98B@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: <619CDADDCCD2B44380834BE8BF6F7141406554D98B@EMV62-UKRD.domain1.systemhost.net> 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] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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: Mon, 06 Feb 2012 23:03:08 -0000 Comments inline below. Paul >-----Original Message----- >4.3. Hotspot: urban internet connectivity service > > In this use case internet connectivity service is provided in a > "hotspot" to local users. Typical deployment scenarios include urban > areas where internet connectivity is provided to local businesses and > residents, and campus environments where internet connectivity is > provided to local buildings and relatively small outdoor areas. This > deployment scenario is typically characterized by multiple masters > (APs or hotspots) in close proximity, with low antenna height, cells > with relatively small radius (a few kilometers or less), and limited > numbers of available radio channels. Many of the masters/APs are > assumed to be individually deployed and operated, i.e. there is no > coordination between many of the masters/APs. The masters/APs in > this scenario use a TDD radio technology and transmit at or below a > relatively low transmit power threshold. Each master/AP has a > connection to the internet and provides internet connectivity to > multiple master and or slave devices. [Paul]=20 Remove TDD - not necessary and may not always be correct Remove low power threshold ... unnecessary, what do you mean by "low" May or may not provide Internet .... > Each master/AP has a > connection to the internet and internet connectivity to > master and slave devices. > > The figure below shows an example deployment of this scenario. > > > > -------- > |Device|\ \|/ ---------- > | 1 | (TDD AirIF) | |Database| > -------- \ | .---. /--------- > o \ |-|---------| ( ) / > o | Master | / \ > o / | |=3D=3D=3D=3D=3D=3D=3D=3D( Intern= et ) > o / |-----------| \ / > -------- (TDD AirIF) ( ) > |Device| / (----) > | n | > -------- > > > Figure 3: Hotspot service using TV white space spectrum [Paul] Remove TDD Add Connection from Device-to-Device > > Once a master/AP has been correctly installed and configured, a > simplified power up and operation scenario utilizing TV White Space > to provide Internet connectivity service to slave devices, >including the ability to clear WSDs from select channels, is described. >This scenario consists of the following steps: [Paul]=20 What this all about? Clearing devices from channels has nothing to do with= the regulatory requirements Please remove "clearlin devices" Remove "simplified" - simplified from what ... Change to: Once a master/AP has been correctly installed and configured, the master= may provide Internet connectivity through a start-up process that checks t= he database for available channels and enables any slave devices. This scenario consists of the following steps: > > 1. The master/AP powers up; however its WS radio and all other WS > capable devices will power up in idle/listen only mode (no active > transmissions on the WS frequency band). A local >regulator may identify exception cases where a Master may initialize >over white space (e.g. the FCC allows a Master to initialize over TV >white space in certain conditions)." [Paul]=20 I do not see that this is necessary. If a master is connecting to a DB ove= r WS, then it had to first act as a slave. Acting as a simultaneous slave = and master is a much cleaner architectural model than having a master somet= imes violate the basic premise of WS operation (transmit when not enabled). Remove portions in 1 between the inserts. Add another scenario for enablement of a Master device if you want to bette= r describe this process > > 2. The master/AP has Internet connectivity , determines its >location (either from location determination capability or from saved >value that was set during installation), and establishes a >connection to a trusted white space database (see Section 4.1 Note>reference is to database discovery, will be updated in next >version). [Paul]=20 Needs to have determination of correct database before connecting. > > 3. The master/AP registers with the trusted database according to > regulatory domain requirements (see Section 4.2 Note>reference is to registration, will be updated in next versionNote>). > > 4. Following the successful registration process, >the master/AP will send a > query to the trusted database requesting a list of available WS > channels based upon its geolocation. The complete set of >parameters to be provided from the Master to the database is specified >by the local regulator. Parameters may include WSD location, accuracy of >of that location, device antenna height, device identifier of a slave >device requesting channel information. > > 5. If the master/AP has met all regulatory domain requirements (e.g. > been previously authenticated, etc), the database responds with a > list of available white space channels that the master may use, > and optionally a duration of time for their use, >associated maximum power levels or a notification of any additional >requirement for sensing. [Paul]=20 Requirement for sensing????? =20 Why would this be in the response. If it's a regulation - the device would= already know this and be ready to sense. Please remove above text on sensing. If you are trying to describe use of sensing - please add a new secenario. > > 6. Once the master/AP has met all regulatory domain requirements > (e.g. authenticated the WS channel list response message from the > database, etc), the AP selects an available WS channel(s) from > the list. [Paul]=20 Strike "an" -- "AP selects one or more available WS channels ... What about the AP sending an enabling signal ... missing a step here ... > > 7. The slave or user device scans the TV bands to locate a master/AP > transmission, and associates with the AP. insert new >step [Paul] Needs to check not for an AP, but a specific enabling signal/message= /field. It may be possible to have a device that looks a lot like an AP, but is a s= lave device. > > 8. The slave/user device > queries the master for a channel list, providing to the master > the slaves' Device ID and optionally its >geolocation. [Paul]=20 What about the model/device type? Can we make the Device ID optional based on regulatory requirements.... Possible text: 8. The slave device sends a request to the master for the list of available channels. The slave device may optionally include device model/type, device Id,=20 device operating modes and device geolocation. Regulatory domains will have specific requirements for inclusion of various device attributes= . > > 9. Once the master/AP has met all regulatory domain requirements > (e.g. validating the Device ID with the trusted database, etc) > the master provides the list of channels locally available to the > slave/user device. If the channel that the user terminal is > currently using is not included in the list of locally available > channels, the slave/user device ceases all operation on its > current channel. The slave/user device may scan for another AP > transmission on a different channel. [Paul]=20 ? Except for a rare race condition - it's not possible to not have the cha= nnel being used by an AP not be on the list of available channels. Change to: 9. Once the master/AP has met all regulatory domain requirements (e.g. validating the Device ID with the trusted database, etc) the master provides the list of channels locally available to the slave/user device. =20 > > > 10. The master/AP must periodically repeat the process to request a >channel list from the database, steps 4 through 6 above. The frequency >to repeat the process is determined by the local regulator. If the >response from the database indicates a channel being used by the >master/AP is not available, the master/AP must stop transmitting on that >channel immediately.In addition or optionally, the database may send a >message to the master/AP to rescind the availability of one or more >channels. The master/AP must stop transmitting on that channel >immediately. > > 11. The slave or user device must periodically repeat the process to >request a channel list from the master/AP, steps 8 and 9 above. The >frequency to repeat the process is determined by the local regulator. If >the response from the master/AP indicates that a channel being used by >the slave or user device is not available, the slave or user device must >stop transmitting on that channel immediately. In addition or >optionally, the database may send a message to the master/AP to rescind >the availability of one or more channels. The master/AP must then notify >the slave or user device of the rescinded channels. The slave or user >device must stop transmitting on that channel immediately. > > >_______________________________________________ >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 nbravin@earthlink.net Mon Feb 6 15:13:12 2012 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 D438E21F86C4 for ; Mon, 6 Feb 2012 15:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k62tbylAvMW for ; Mon, 6 Feb 2012 15:13:11 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id DCABD21F85DD for ; Mon, 6 Feb 2012 15:13:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=eIRBPZWg1C18+zK4XUtOp8m0PnkGhn1xzm5UOPh3slIvIv0ZUe/7z/Ovbyg3N47N; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RuXkB-0005dA-8V; Mon, 06 Feb 2012 18:13:07 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4F6A7@SC-VEXCH2.marvell.com> Date: Mon, 6 Feb 2012 15:13:05 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <91EC22EC-ECC1-4271-86B7-BF996EC35D20@earthlink.net> References: <619CDADDCCD2B44380834BE8BF6F7141406554D98B@EMV62-UKRD.domain1.systemhost.net> <7BAC95F5A7E67643AAFB2C31BEE662D01579A4F6A7@SC-VEXCH2.marvell.com> To: Paul Lambert X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad865ed21631ff8feb322df38a3df666f5cd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: "paws@ietf.org" Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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: Mon, 06 Feb 2012 23:13:12 -0000 HI Guys, in addition there are a few places where it still says TV White = Space which I though was going to be eliminated and changed to White = Space=85 It may be deleted by suggested edits by Paul, but we need to be careful = to watch for those errors=85SIncerely, Nancy On Feb 6, 2012, at 3:00 PM, Paul Lambert wrote: >=20 > Comments inline below. >=20 > Paul >=20 >=20 >> -----Original Message----- >> 4.3. Hotspot: urban internet connectivity service >>=20 >> In this use case internet connectivity service is provided in a >> "hotspot" to local users. Typical deployment scenarios include = urban >> areas where internet connectivity is provided to local businesses = and >> residents, and campus environments where internet connectivity is >> provided to local buildings and relatively small outdoor areas. = This >> deployment scenario is typically characterized by multiple masters >> (APs or hotspots) in close proximity, with low antenna height, cells >> with relatively small radius (a few kilometers or less), and limited >> numbers of available radio channels. Many of the masters/APs are >> assumed to be individually deployed and operated, i.e. there is no >> coordination between many of the masters/APs. The masters/APs in >> this scenario use a TDD radio technology and transmit at or below a >> relatively low transmit power threshold. Each master/AP has a >> connection to the internet and provides internet connectivity to >> multiple master and or slave devices. > [Paul]=20 > Remove TDD - not necessary and may not always be correct > Remove low power threshold ... unnecessary, what do you mean by "low" > May or may not provide Internet .... >> Each master/AP has a >> connection to the internet and internet connectivity = to >> master and slave devices. >=20 >=20 >>=20 >> The figure below shows an example deployment of this scenario. >>=20 >>=20 >>=20 >> -------- >> |Device|\ \|/ ---------- >> | 1 | (TDD AirIF) | |Database| >> -------- \ | .---. /--------- >> o \ |-|---------| ( ) / >> o | Master | / \ >> o / | |=3D=3D=3D=3D=3D=3D=3D=3D( = Internet ) >> o / |-----------| \ / >> -------- (TDD AirIF) ( ) >> |Device| / (----) >> | n | >> -------- >>=20 >>=20 >> Figure 3: Hotspot service using TV white space spectrum > [Paul] > Remove TDD > Add Connection from Device-to-Device >>=20 >> Once a master/AP has been correctly installed and configured, a >> simplified power up and operation scenario utilizing TV White Space >> to provide Internet connectivity service to slave devices, >> including the ability to clear WSDs from select channels, is = described. >> This scenario consists of the following steps: > [Paul]=20 > What this all about? Clearing devices from channels has nothing to do = with the regulatory requirements > Please remove "clearlin devices" > Remove "simplified" - simplified from what ... >=20 > Change to: >=20 > Once a master/AP has been correctly installed and configured, the = master may provide Internet connectivity through a start-up process that = checks the database for available channels and enables any slave = devices. > This scenario consists of the following steps: >=20 >=20 >>=20 >> 1. The master/AP powers up; however its WS radio and all other WS >> capable devices will power up in idle/listen only mode (no = active >> transmissions on the WS frequency band). A local >> regulator may identify exception cases where a Master may initialize >> over white space (e.g. the FCC allows a Master to initialize over TV >> white space in certain conditions)." > [Paul]=20 > I do not see that this is necessary. If a master is connecting to a = DB over WS, then it had to first act as a slave. Acting as a = simultaneous slave and master is a much cleaner architectural model than = having a master sometimes violate the basic premise of WS operation = (transmit when not enabled). >=20 > Remove portions in 1 between the inserts. > Add another scenario for enablement of a Master device if you want to = better describe this process >=20 >>=20 >> 2. The master/AP has Internet connectivity , determines its >> location (either from location determination capability or from saved >> value that was set during installation), and establishes a >> connection to a trusted white space database (see Section 4.1 > Note>reference is to database discovery, will be updated in next >> version). > [Paul]=20 > Needs to have determination of correct database before connecting. >=20 >=20 >=20 >>=20 >> 3. The master/AP registers with the trusted database according to >> regulatory domain requirements (see Section 4.2 > Note>reference is to registration, will be updated in next = version> Note>). >>=20 >> 4. Following the successful registration process, >> the master/AP will send a >> query to the trusted database requesting a list of available WS >> channels based upon its geolocation. The complete set of >> parameters to be provided from the Master to the database is = specified >> by the local regulator. Parameters may include WSD location, accuracy = of >> of that location, device antenna height, device identifier of a slave >> device requesting channel information. >>=20 >> 5. If the master/AP has met all regulatory domain requirements = (e.g. >> been previously authenticated, etc), the database responds with = a >> list of available white space channels that the master may use, >> and optionally a duration of time for their use, >> associated maximum power levels or a notification of any additional >> requirement for sensing. > [Paul]=20 > Requirement for sensing????? =20 > Why would this be in the response. If it's a regulation - the device = would already know this and be ready to sense. > Please remove above text on sensing. > If you are trying to describe use of sensing - please add a new = secenario. >=20 >>=20 >> 6. Once the master/AP has met all regulatory domain requirements >> (e.g. authenticated the WS channel list response message from = the >> database, etc), the AP selects an available WS channel(s) from >> the list. > [Paul]=20 > Strike "an" -- "AP selects one or more available WS channels ... >=20 > What about the AP sending an enabling signal ... missing a step here = ... >>=20 >> 7. The slave or user device scans the TV bands to locate a = master/AP >> transmission, and associates with the AP. insert new >> step > [Paul] Needs to check not for an AP, but a specific enabling = signal/message/field. > It may be possible to have a device that looks a lot like an AP, but = is a slave device. >=20 >=20 >>=20 >> 8. The slave/user device >> queries the master for a channel list, providing to the master >> the slaves' Device ID and optionally its >> geolocation. > [Paul]=20 > What about the model/device type? >=20 > Can we make the Device ID optional based on regulatory = requirements.... > Possible text: > 8. The slave device > sends a request to the master for the list of available = channels. > The slave device may optionally include device model/type, = device Id,=20 > device operating modes and device geolocation. Regulatory = domains > will have specific requirements for inclusion of various device = attributes. >=20 >=20 >>=20 >> 9. Once the master/AP has met all regulatory domain requirements >> (e.g. validating the Device ID with the trusted database, etc) >> the master provides the list of channels locally available to = the >> slave/user device. If the channel that the user terminal is >> currently using is not included in the list of locally available >> channels, the slave/user device ceases all operation on its >> current channel. The slave/user device may scan for another AP >> transmission on a different channel. > [Paul]=20 > ? Except for a rare race condition - it's not possible to not have = the channel being used by an AP not be on the list of available = channels. >=20 > Change to: >=20 > 9. Once the master/AP has met all regulatory domain requirements > (e.g. validating the Device ID with the trusted database, etc) > the master provides the list of channels locally available to = the > slave/user device. =20 >=20 >>=20 >> >> 10. The master/AP must periodically repeat the process to request a >> channel list from the database, steps 4 through 6 above. The = frequency >> to repeat the process is determined by the local regulator. If the >> response from the database indicates a channel being used by the >> master/AP is not available, the master/AP must stop transmitting on = that >> channel immediately.In addition or optionally, the database may send = a >> message to the master/AP to rescind the availability of one or more >> channels. The master/AP must stop transmitting on that channel >> immediately. >=20 >>=20 >> 11. The slave or user device must periodically repeat the process to >> request a channel list from the master/AP, steps 8 and 9 above. The >> frequency to repeat the process is determined by the local regulator. = If >> the response from the master/AP indicates that a channel being used = by >> the slave or user device is not available, the slave or user device = must >> stop transmitting on that channel immediately. In addition or >> optionally, the database may send a message to the master/AP to = rescind >> the availability of one or more channels. The master/AP must then = notify >> the slave or user device of the rescinded channels. The slave or user >> device must stop transmitting on that channel immediately. >> >>=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 jstine@mitre.org Tue Feb 7 06:10:49 2012 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 4404821F873B for ; Tue, 7 Feb 2012 06:10:49 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X45UWyhe7d1q for ; Tue, 7 Feb 2012 06:10:47 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 33AC621F87C7 for ; Tue, 7 Feb 2012 06:10:46 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8987521B12B9 for ; Tue, 7 Feb 2012 09:10:45 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 502B821B17DE for ; Tue, 7 Feb 2012 09:10:45 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Tue, 7 Feb 2012 09:10:45 -0500 From: "Stine, John A." To: "paws@ietf.org" Thread-Topic: Separating business process data from spectrum use data Thread-Index: AczlokgxAN/NbRoURu+cZ+dAW9pXPQ== Date: Tue, 7 Feb 2012 14:10:44 +0000 Message-ID: <2782C93FD2244441893673F3F912819210EF95@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [paws] Separating business process data from spectrum use data 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, 07 Feb 2012 14:10:49 -0000 I fully understand the intent to limit the scope in this iteration of the p= aws standard to the items listed in paragraph 1.2.1 but I also believe it i= s important to look forward and consider what we would like the whitespace = database to become and to ensure that anything that is done in this first i= teration does not become a hurdle to overcome in the future. The future database roles that I think should be considered are: 1. Spectrum from licensed users can be added to databases allowing their s= pectrum to be used or reused in some way 2. Database administrators arbitrate coexistence 3. Database managers can convey policy to DSA systems that allow spectrum = use based on a radio using a particular behavior. =20 I do not believe consideration of these activities would have an effect on = the types of processes and messaging that the current scope prescribes but = it could have a very big impact on the data model. I recommend that the bu= siness process schemas be kept separate from the spectrum data model schema= s and that the standard be written so that spectrum data modeling schemas c= an be interchanged. The motivation for this separation is three-fold: 1. It allows other enterprises to use their own management methods but to s= hare data models making it easier for them to make their spectrum available= . 2. It allows spectrum data models tuned for particular administration regul= atory requirements 3. It allows evolution of the data models to support more dynamic and inter= active spectrum management without demanding confusing upgrades to schemas = that attempt to be backwards compatible. (Backwards compatibility is achie= ved at the databases that can understand multiple data model schemas. We m= ay want to add messaging that allows devices and databases to agree upon a = schema.) Potential changes that may enable this perspective could be to divide the d= ata model into two parts. The first part would include the information nec= essary for the business process, so D.2 and D.3, and the second part would= be data elements that provide the information relevant to spectrum use. I= n the current data model requirements, this is everything else. The output= of this initial standards work would be a paws protocol for the interactio= ns between WS devices and the WS database and a separate standard for a dat= a model that it uses for defining spectrum. =20 I would then add the following to the protocol requirements: P.14 The master device must identify the spectrum data model schema it use= s to convey its operating parameters and to receive channel availability fr= om the WS Database. There are likely multiple changes required throughout the document but want= ed to instigate a discussion before I try to suggest what they might be. John A. Stine Chief Technology Advisor Operations Research and Systems Analysis The MITRE Corporation email: jstine@mitre.org,=A0 Phone:703-983-6281 From scott.probasco@nokia.com Tue Feb 7 07:26:37 2012 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 544F221F8802 for ; Tue, 7 Feb 2012 07:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=-1.720, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2fIXvNi8Vvt for ; Tue, 7 Feb 2012 07:26:36 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2599621F87EB for ; Tue, 7 Feb 2012 07:26:35 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q17FOff7001242 for ; Tue, 7 Feb 2012 17:26:34 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 17:26:28 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Tue, 7 Feb 2012 16:26:28 +0100 From: To: Thread-Topic: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) Thread-Index: AQHM5azciGQw8jqBS0WARBXdNpj/HQ== Date: Tue, 7 Feb 2012 15:26:27 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4F6A7@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <5427DF9F213CB74290998E0CB73FEFF7@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2012 15:26:28.0866 (UTC) FILETIME=[DCD00E20:01CCE5AC] X-Nokia-AV: Clean Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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, 07 Feb 2012 15:26:37 -0000 Hello, Reply comments are inline below. Kind Regards, Scott On 2/6/12 5:00 PM, "ext Paul Lambert" wrote: > >Comments inline below. > >Paul > > >>-----Original Message----- >>4.3. Hotspot: urban internet connectivity service >> >> In this use case internet connectivity service is provided in a >> "hotspot" to local users. Typical deployment scenarios include urban >> areas where internet connectivity is provided to local businesses and >> residents, and campus environments where internet connectivity is >> provided to local buildings and relatively small outdoor areas. This >> deployment scenario is typically characterized by multiple masters >> (APs or hotspots) in close proximity, with low antenna height, cells >> with relatively small radius (a few kilometers or less), and limited >> numbers of available radio channels. Many of the masters/APs are >> assumed to be individually deployed and operated, i.e. there is no >> coordination between many of the masters/APs. The masters/APs in >> this scenario use a TDD radio technology and transmit at or below a >> relatively low transmit power threshold. Each master/AP has a >> connection to the internet and provides internet connectivity to >> multiple master and or slave devices. >[Paul]=20 >Remove TDD - not necessary and may not always be correct >Remove low power threshold ... unnecessary, what do you mean by "low" Scott>The intent here was to describe the first and most simplest use cases. Indeed the radio duplex may not always be TDD, but is the simplest case and is good as a first example since only one white space channel is required to deploy a network. Can be removed if the group desires, but I think TDD is a useful clarification for a first simple use case. "Low power threshold" is undefined, good clarification to remove this. >May or may not provide Internet .... >> Each master/AP has a >> connection to the internet and internet connectivity to >> master and slave devices. Scott>I agree with you. > > >> >> The figure below shows an example deployment of this scenario. >> >> >> >> -------- >> |Device|\ \|/ ---------- >> | 1 | (TDD AirIF) | |Database| >> -------- \ | .---. /--------- >> o \ |-|---------| ( ) / >> o | Master | / \ >> o / | |=3D=3D=3D=3D=3D=3D=3D=3D( Inter= net ) >> o / |-----------| \ / >> -------- (TDD AirIF) ( ) >> |Device| / (----) >> | n | >> -------- >> >> >> Figure 3: Hotspot service using TV white space spectrum >[Paul] >Remove TDD Scott>Suggest to keep this for this simple use case, as above. >Add Connection from Device-to-Device Scott>I agree with you. >> >> Once a master/AP has been correctly installed and configured, a >> simplified power up and operation scenario utilizing TV White Space >> to provide Internet connectivity service to slave devices, >>including the ability to clear WSDs from select channels, is described. >>This scenario consists of the following steps: >[Paul]=20 >What this all about? Clearing devices from channels has nothing to do >with the regulatory requirements >Please remove "clearlin devices" Scott>This was added based on discussion on the reflector (http://www.ietf.org/mail-archive/web/paws/current/msg00538.html) and based on requirements from Ofcom, see Implementing Geolocation =A73.41 and =A73.45(c).=20 >Remove "simplified" - simplified from what ... Scott>Simplified in this case means that the use case does not try to cover all possible events, just focus on a simple scenario in order to derive the corresponding requirements. > > Change to: > > Once a master/AP has been correctly installed and configured, the >master may provide Internet connectivity through a start-up process that >checks the database for available channels and enables any slave devices. >This scenario consists of the following steps: > > >> >> 1. The master/AP powers up; however its WS radio and all other WS >> capable devices will power up in idle/listen only mode (no active >> transmissions on the WS frequency band). A local >>regulator may identify exception cases where a Master may initialize >>over white space (e.g. the FCC allows a Master to initialize over TV >>white space in certain conditions)." >[Paul]=20 >I do not see that this is necessary. If a master is connecting to a DB >over WS, then it had to first act as a slave. Acting as a simultaneous >slave and master is a much cleaner architectural model than having a >master sometimes violate the basic premise of WS operation (transmit when >not enabled). > >Remove portions in 1 between the inserts. >Add another scenario for enablement of a Master device if you want to >better describe this process Scott>This text was added to address FCC =A715.711(e). The behavior is different from a slave in this case, the master must request and receive a channel list from the database, not from the (other) master. > >> >> 2. The master/AP has Internet connectivity , determines its >>location (either from location determination capability or from saved >>value that was set during installation), and establishes a >>connection to a trusted white space database (see Section 4.1 >Note>reference is to database discovery, will be updated in next >>version). >[Paul]=20 >Needs to have determination of correct database before connecting. Scott>I agree with you, this is in section 4.1 database discovery. > > > >> >> 3. The master/AP registers with the trusted database according to >> regulatory domain requirements (see Section 4.2 >Note>reference is to registration, will be updated in next version>Note>). >> >> 4. Following the successful registration process, >>the master/AP will send a >> query to the trusted database requesting a list of available WS >> channels based upon its geolocation. The complete set of >>parameters to be provided from the Master to the database is specified >>by the local regulator. Parameters may include WSD location, accuracy of >>of that location, device antenna height, device identifier of a slave >>device requesting channel information. >> >> 5. If the master/AP has met all regulatory domain requirements (e.g. >> been previously authenticated, etc), the database responds with a >> list of available white space channels that the master may use, >> and optionally a duration of time for their use, >>associated maximum power levels or a notification of any additional >>requirement for sensing. >[Paul]=20 >Requirement for sensing????? >Why would this be in the response. If it's a regulation - the device >would already know this and be ready to sense. >Please remove above text on sensing. >If you are trying to describe use of sensing - please add a new secenario. Scott>This sensing text comes from Ofcom's Implementing Geolocation =A72.15 (4th bullet). > >> >> 6. Once the master/AP has met all regulatory domain requirements >> (e.g. authenticated the WS channel list response message from the >> database, etc), the AP selects an available WS channel(s) from >> the list. >[Paul]=20 >Strike "an" -- "AP selects one or more available WS channels ... Scott>I agree with you. > >What about the AP sending an enabling signal ... missing a step here ... Scott>Good comment, will add this. >> >> 7. The slave or user device scans the TV bands to locate a master/AP >> transmission, and associates with the AP. insert new >>step >[Paul] Needs to check not for an AP, but a specific enabling >signal/message/field. >It may be possible to have a device that looks a lot like an AP, but is a >slave device. Scott>This text appears to fulfill both FCC and Ofcom requirements. FCC precludes peer-to-peer thus the slave (Mode I) device must find a master. Ofcom allows slave-to-slave but only under control of the same master. Also Ofcom does not require an enabling signal. > > >> >> 8. The slave/user device >> queries the master for a channel list, providing to the master >> the slaves' Device ID and optionally its >>geolocation. >[Paul]=20 >What about the model/device type? Scott>The Device ID includes manufacturer, model number and serial number. But you have a good point, this should be clarified. > >Can we make the Device ID optional based on regulatory requirements.... >Possible text: > 8. The slave device > sends a request to the master for the list of available channels. > The slave device may optionally include device model/type, device Id, > device operating modes and device geolocation. Regulatory domains > will have specific requirements for inclusion of various device >attributes. Scott>Clarifying the attributes are based on local regulatory requirement is good, will add this. I don't know what are the device operating modes nor which regulatory requirement these are addressing, can you please clarify? > > >> >> 9. Once the master/AP has met all regulatory domain requirements >> (e.g. validating the Device ID with the trusted database, etc) >> the master provides the list of channels locally available to the >> slave/user device. If the channel that the user terminal is >> currently using is not included in the list of locally available >> channels, the slave/user device ceases all operation on its >> current channel. The slave/user device may scan for another AP >> transmission on a different channel. >[Paul]=20 >? Except for a rare race condition - it's not possible to not have the >channel being used by an AP not be on the list of available channels. > >Change to: > > 9. Once the master/AP has met all regulatory domain requirements > (e.g. validating the Device ID with the trusted database, etc) > the master provides the list of channels locally available to the > slave/user device. Scott>I agree with you. > >> >> >> 10. The master/AP must periodically repeat the process to request a >>channel list from the database, steps 4 through 6 above. The frequency >>to repeat the process is determined by the local regulator. If the >>response from the database indicates a channel being used by the >>master/AP is not available, the master/AP must stop transmitting on that >>channel immediately.In addition or optionally, the database may send a >>message to the master/AP to rescind the availability of one or more >>channels. The master/AP must stop transmitting on that channel >>immediately. > >> >> 11. The slave or user device must periodically repeat the process to >>request a channel list from the master/AP, steps 8 and 9 above. The >>frequency to repeat the process is determined by the local regulator. If >>the response from the master/AP indicates that a channel being used by >>the slave or user device is not available, the slave or user device must >>stop transmitting on that channel immediately. In addition or >>optionally, the database may send a message to the master/AP to rescind >>the availability of one or more channels. The master/AP must then notify >>the slave or user device of the rescinded channels. The slave or user >>device must stop transmitting on that channel immediately. >> >> >>_______________________________________________ >>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 scott.probasco@nokia.com Tue Feb 7 07:44:49 2012 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 CFA4621F87D1 for ; Tue, 7 Feb 2012 07:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.86 X-Spam-Level: X-Spam-Status: No, score=-1.86 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPDkqF9hiCgl for ; Tue, 7 Feb 2012 07:44:48 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1977621F87C8 for ; Tue, 7 Feb 2012 07:44:47 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q17Fi271020455; Tue, 7 Feb 2012 17:44:23 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 17:44:19 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Tue, 7 Feb 2012 16:44:19 +0100 From: To: , , Thread-Topic: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) Thread-Index: AQHM5a9asG8W67OHOk64r2769TGbpw== Date: Tue, 7 Feb 2012 15:44:17 +0000 Message-ID: In-Reply-To: <91EC22EC-ECC1-4271-86B7-BF996EC35D20@earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2012 15:44:19.0618 (UTC) FILETIME=[5B07D820:01CCE5AF] X-Nokia-AV: Clean Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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, 07 Feb 2012 15:44:49 -0000 Hi Nancy, Yes we have discussed removing some of the TV white space emphasis, but my understanding was that we did not intend to expunge TV white space from the document. Clearly PAWS should work for bands other than TV, but also TV is the first commercial opportunity. Kind Regards, Scott On 2/6/12 5:13 PM, "ext Nancy Bravin" wrote: >HI Guys, in addition there are a few places where it still says TV White >Space which I though was going to be eliminated and changed to White >Space=8A >It may be deleted by suggested edits by Paul, but we need to be careful >to watch for those errors=8ASIncerely, Nancy > >On Feb 6, 2012, at 3:00 PM, Paul Lambert wrote: > >>=20 >> Comments inline below. >>=20 >> Paul >>=20 >>=20 >>> -----Original Message----- >>> 4.3. Hotspot: urban internet connectivity service >>>=20 >>> In this use case internet connectivity service is provided in a >>> "hotspot" to local users. Typical deployment scenarios include urban >>> areas where internet connectivity is provided to local businesses and >>> residents, and campus environments where internet connectivity is >>> provided to local buildings and relatively small outdoor areas. This >>> deployment scenario is typically characterized by multiple masters >>> (APs or hotspots) in close proximity, with low antenna height, cells >>> with relatively small radius (a few kilometers or less), and limited >>> numbers of available radio channels. Many of the masters/APs are >>> assumed to be individually deployed and operated, i.e. there is no >>> coordination between many of the masters/APs. The masters/APs in >>> this scenario use a TDD radio technology and transmit at or below a >>> relatively low transmit power threshold. Each master/AP has a >>> connection to the internet and provides internet connectivity to >>> multiple master and or slave devices. >> [Paul]=20 >> Remove TDD - not necessary and may not always be correct >> Remove low power threshold ... unnecessary, what do you mean by "low" >> May or may not provide Internet .... >>> Each master/AP has a >>> connection to the internet and internet connectivity to >>> master and slave devices. >>=20 >>=20 >>>=20 >>> The figure below shows an example deployment of this scenario. >>>=20 >>>=20 >>>=20 >>> -------- >>> |Device|\ \|/ ---------- >>> | 1 | (TDD AirIF) | |Database| >>> -------- \ | .---. /--------- >>> o \ |-|---------| ( ) / >>> o | Master | / \ >>> o / | |=3D=3D=3D=3D=3D=3D=3D=3D( Inter= net ) >>> o / |-----------| \ / >>> -------- (TDD AirIF) ( ) >>> |Device| / (----) >>> | n | >>> -------- >>>=20 >>>=20 >>> Figure 3: Hotspot service using TV white space spectrum >> [Paul] >> Remove TDD >> Add Connection from Device-to-Device >>>=20 >>> Once a master/AP has been correctly installed and configured, a >>> simplified power up and operation scenario utilizing TV White Space >>> to provide Internet connectivity service to slave devices, >>> including the ability to clear WSDs from select channels, is described. >>> This scenario consists of the following steps: >> [Paul]=20 >> What this all about? Clearing devices from channels has nothing to do >>with the regulatory requirements >> Please remove "clearlin devices" >> Remove "simplified" - simplified from what ... >>=20 >> Change to: >>=20 >> Once a master/AP has been correctly installed and configured, the >>master may provide Internet connectivity through a start-up process that >>checks the database for available channels and enables any slave devices. >> This scenario consists of the following steps: >>=20 >>=20 >>>=20 >>> 1. The master/AP powers up; however its WS radio and all other WS >>> capable devices will power up in idle/listen only mode (no active >>> transmissions on the WS frequency band). A local >>> regulator may identify exception cases where a Master may initialize >>> over white space (e.g. the FCC allows a Master to initialize over TV >>> white space in certain conditions)." >> [Paul]=20 >> I do not see that this is necessary. If a master is connecting to a DB >>over WS, then it had to first act as a slave. Acting as a simultaneous >>slave and master is a much cleaner architectural model than having a >>master sometimes violate the basic premise of WS operation (transmit >>when not enabled). >>=20 >> Remove portions in 1 between the inserts. >> Add another scenario for enablement of a Master device if you want to >>better describe this process >>=20 >>>=20 >>> 2. The master/AP has Internet connectivity , determines its >>> location (either from location determination capability or from saved >>> value that was set during installation), and establishes a >>> connection to a trusted white space database (see Section 4.1 >> Note>reference is to database discovery, will be updated in next >>> version). >> [Paul]=20 >> Needs to have determination of correct database before connecting. >>=20 >>=20 >>=20 >>>=20 >>> 3. The master/AP registers with the trusted database according to >>> regulatory domain requirements (see Section 4.2 >> Note>reference is to registration, will be updated in next version>> Note>). >>>=20 >>> 4. Following the successful registration process, >>> the master/AP will send a >>> query to the trusted database requesting a list of available WS >>> channels based upon its geolocation. The complete set of >>> parameters to be provided from the Master to the database is specified >>> by the local regulator. Parameters may include WSD location, accuracy >>>of >>> of that location, device antenna height, device identifier of a slave >>> device requesting channel information. >>>=20 >>> 5. If the master/AP has met all regulatory domain requirements (e.g. >>> been previously authenticated, etc), the database responds with a >>> list of available white space channels that the master may use, >>> and optionally a duration of time for their use, >>> associated maximum power levels or a notification of any additional >>> requirement for sensing. >> [Paul]=20 >> Requirement for sensing????? >> Why would this be in the response. If it's a regulation - the device >>would already know this and be ready to sense. >> Please remove above text on sensing. >> If you are trying to describe use of sensing - please add a new >>secenario. >>=20 >>>=20 >>> 6. Once the master/AP has met all regulatory domain requirements >>> (e.g. authenticated the WS channel list response message from the >>> database, etc), the AP selects an available WS channel(s) from >>> the list. >> [Paul]=20 >> Strike "an" -- "AP selects one or more available WS channels ... >>=20 >> What about the AP sending an enabling signal ... missing a step here ... >>>=20 >>> 7. The slave or user device scans the TV bands to locate a master/AP >>> transmission, and associates with the AP. insert new >>> step >> [Paul] Needs to check not for an AP, but a specific enabling >>signal/message/field. >> It may be possible to have a device that looks a lot like an AP, but is >>a slave device. >>=20 >>=20 >>>=20 >>> 8. The slave/user device >>> queries the master for a channel list, providing to the master >>> the slaves' Device ID and optionally its >>> geolocation. >> [Paul]=20 >> What about the model/device type? >>=20 >> Can we make the Device ID optional based on regulatory requirements.... >> Possible text: >> 8. The slave device >> sends a request to the master for the list of available channels. >> The slave device may optionally include device model/type, device Id, >> device operating modes and device geolocation. Regulatory domains >> will have specific requirements for inclusion of various device >>attributes. >>=20 >>=20 >>>=20 >>> 9. Once the master/AP has met all regulatory domain requirements >>> (e.g. validating the Device ID with the trusted database, etc) >>> the master provides the list of channels locally available to the >>> slave/user device. If the channel that the user terminal is >>> currently using is not included in the list of locally available >>> channels, the slave/user device ceases all operation on its >>> current channel. The slave/user device may scan for another AP >>> transmission on a different channel. >> [Paul]=20 >> ? Except for a rare race condition - it's not possible to not have the >>channel being used by an AP not be on the list of available channels. >>=20 >> Change to: >>=20 >> 9. Once the master/AP has met all regulatory domain requirements >> (e.g. validating the Device ID with the trusted database, etc) >> the master provides the list of channels locally available to the >> slave/user device. >>=20 >>>=20 >>> >>> 10. The master/AP must periodically repeat the process to request a >>> channel list from the database, steps 4 through 6 above. The frequency >>> to repeat the process is determined by the local regulator. If the >>> response from the database indicates a channel being used by the >>> master/AP is not available, the master/AP must stop transmitting on >>>that >>> channel immediately.In addition or optionally, the database may send a >>> message to the master/AP to rescind the availability of one or more >>> channels. The master/AP must stop transmitting on that channel >>> immediately. >>=20 >>>=20 >>> 11. The slave or user device must periodically repeat the process to >>> request a channel list from the master/AP, steps 8 and 9 above. The >>> frequency to repeat the process is determined by the local regulator. >>>If >>> the response from the master/AP indicates that a channel being used by >>> the slave or user device is not available, the slave or user device >>>must >>> stop transmitting on that channel immediately. In addition or >>> optionally, the database may send a message to the master/AP to rescind >>> the availability of one or more channels. The master/AP must then >>>notify >>> the slave or user device of the rescinded channels. The slave or user >>> device must stop transmitting on that channel immediately. >>> >>>=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 nbravin@earthlink.net Tue Feb 7 08:07:51 2012 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 4331921F861E for ; Tue, 7 Feb 2012 08:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtTEXTgpFJPq for ; Tue, 7 Feb 2012 08:07:50 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 7441021F85E5 for ; Tue, 7 Feb 2012 08:07:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=bT5vgFJxByRqhhz+DTalD4TVFqp/t1T5CE10qTR0q2r83PN2MJWAarJ4ZtUPAY+5; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RunZs-00058s-2k; Tue, 07 Feb 2012 11:07:32 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: Date: Tue, 7 Feb 2012 08:07:30 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <155F30AD-4604-4A24-8F5A-73ACA8918BB5@earthlink.net> References: To: scott.probasco@nokia.com X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86f004c648b47b629b50930c0e514ef92a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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, 07 Feb 2012 16:07:51 -0000 Hi Scott, The reason I mention this is There are discussions going on in the Congress and Senate about White = Space, as we noted as well from Rex, so how to not limit this to TVWS when in fact rules may change quickly and there may be more = shared spectrum =85.from other spectrum users that are not from TVWS. I think we should think in those terms.=20 In my opinion we may want to be a little more open to where the spectrum = comes from, and globally they could come from other than TVWS as well depending on how much spectrum is used = infrequently to allow such use.=20 SIncerely, Nancy On Feb 7, 2012, at 7:44 AM, = wrote: > Hi Nancy, >=20 > Yes we have discussed removing some of the TV white space emphasis, = but my > understanding was that we did not intend to expunge TV white space = from > the document. Clearly PAWS should work for bands other than TV, but = also > TV is the first commercial opportunity. >=20 > Kind Regards, > Scott >=20 > On 2/6/12 5:13 PM, "ext Nancy Bravin" wrote: >=20 >> HI Guys, in addition there are a few places where it still says TV = White >> Space which I though was going to be eliminated and changed to White >> Space=8A >> It may be deleted by suggested edits by Paul, but we need to be = careful >> to watch for those errors=8ASIncerely, Nancy >>=20 >> On Feb 6, 2012, at 3:00 PM, Paul Lambert wrote: >>=20 >>>=20 >>> Comments inline below. >>>=20 >>> Paul >>>=20 >>>=20 >>>> -----Original Message----- >>>> 4.3. Hotspot: urban internet connectivity service >>>>=20 >>>> In this use case internet connectivity service is provided in a >>>> "hotspot" to local users. Typical deployment scenarios include = urban >>>> areas where internet connectivity is provided to local businesses = and >>>> residents, and campus environments where internet connectivity is >>>> provided to local buildings and relatively small outdoor areas. = This >>>> deployment scenario is typically characterized by multiple masters >>>> (APs or hotspots) in close proximity, with low antenna height, = cells >>>> with relatively small radius (a few kilometers or less), and = limited >>>> numbers of available radio channels. Many of the masters/APs are >>>> assumed to be individually deployed and operated, i.e. there is no >>>> coordination between many of the masters/APs. The masters/APs in >>>> this scenario use a TDD radio technology and transmit at or below a >>>> relatively low transmit power threshold. Each master/AP has a >>>> connection to the internet and provides internet connectivity to >>>> multiple master and or slave devices. >>> [Paul]=20 >>> Remove TDD - not necessary and may not always be correct >>> Remove low power threshold ... unnecessary, what do you mean by = "low" >>> May or may not provide Internet .... >>>> Each master/AP has a >>>> connection to the internet and internet connectivity = to >>>> master and slave devices. >>>=20 >>>=20 >>>>=20 >>>> The figure below shows an example deployment of this scenario. >>>>=20 >>>>=20 >>>>=20 >>>> -------- >>>> |Device|\ \|/ ---------- >>>> | 1 | (TDD AirIF) | |Database| >>>> -------- \ | .---. /--------- >>>> o \ |-|---------| ( ) / >>>> o | Master | / \ >>>> o / | |=3D=3D=3D=3D=3D=3D=3D=3D( = Internet ) >>>> o / |-----------| \ / >>>> -------- (TDD AirIF) ( ) >>>> |Device| / (----) >>>> | n | >>>> -------- >>>>=20 >>>>=20 >>>> Figure 3: Hotspot service using TV white space spectrum >>> [Paul] >>> Remove TDD >>> Add Connection from Device-to-Device >>>>=20 >>>> Once a master/AP has been correctly installed and configured, a >>>> simplified power up and operation scenario utilizing TV White Space >>>> to provide Internet connectivity service to slave devices, >>>> including the ability to clear WSDs from select channels, is = described. >>>> This scenario consists of the following steps: >>> [Paul]=20 >>> What this all about? Clearing devices from channels has nothing to = do >>> with the regulatory requirements >>> Please remove "clearlin devices" >>> Remove "simplified" - simplified from what ... >>>=20 >>> Change to: >>>=20 >>> Once a master/AP has been correctly installed and configured, the >>> master may provide Internet connectivity through a start-up process = that >>> checks the database for available channels and enables any slave = devices. >>> This scenario consists of the following steps: >>>=20 >>>=20 >>>>=20 >>>> 1. The master/AP powers up; however its WS radio and all other WS >>>> capable devices will power up in idle/listen only mode (no = active >>>> transmissions on the WS frequency band). A local >>>> regulator may identify exception cases where a Master may = initialize >>>> over white space (e.g. the FCC allows a Master to initialize over = TV >>>> white space in certain conditions)." >>> [Paul]=20 >>> I do not see that this is necessary. If a master is connecting to a = DB >>> over WS, then it had to first act as a slave. Acting as a = simultaneous >>> slave and master is a much cleaner architectural model than having a >>> master sometimes violate the basic premise of WS operation (transmit >>> when not enabled). >>>=20 >>> Remove portions in 1 between the inserts. >>> Add another scenario for enablement of a Master device if you want = to >>> better describe this process >>>=20 >>>>=20 >>>> 2. The master/AP has Internet connectivity , determines = its >>>> location (either from location determination capability or from = saved >>>> value that was set during installation), and establishes = a >>>> connection to a trusted white space database (see Section 4.1 >>> Note>reference is to database discovery, will be updated in next >>>> version). >>> [Paul]=20 >>> Needs to have determination of correct database before connecting. >>>=20 >>>=20 >>>=20 >>>>=20 >>>> 3. The master/AP registers with the trusted database according to >>>> regulatory domain requirements (see Section 4.2 >>> Note>reference is to registration, will be updated in next = version>>> Note>). >>>>=20 >>>> 4. Following the successful registration process, >>>> the master/AP will send a >>>> query to the trusted database requesting a list of available WS >>>> channels based upon its geolocation. The complete set of >>>> parameters to be provided from the Master to the database is = specified >>>> by the local regulator. Parameters may include WSD location, = accuracy >>>> of >>>> of that location, device antenna height, device identifier of a = slave >>>> device requesting channel information. >>>>=20 >>>> 5. If the master/AP has met all regulatory domain requirements = (e.g. >>>> been previously authenticated, etc), the database responds with = a >>>> list of available white space channels that the master may use, >>>> and optionally a duration of time for their use, >>>> associated maximum power levels or a notification of any additional >>>> requirement for sensing. >>> [Paul]=20 >>> Requirement for sensing????? >>> Why would this be in the response. If it's a regulation - the = device >>> would already know this and be ready to sense. >>> Please remove above text on sensing. >>> If you are trying to describe use of sensing - please add a new >>> secenario. >>>=20 >>>>=20 >>>> 6. Once the master/AP has met all regulatory domain requirements >>>> (e.g. authenticated the WS channel list response message from = the >>>> database, etc), the AP selects an available WS channel(s) from >>>> the list. >>> [Paul]=20 >>> Strike "an" -- "AP selects one or more available WS channels ... >>>=20 >>> What about the AP sending an enabling signal ... missing a step here = ... >>>>=20 >>>> 7. The slave or user device scans the TV bands to locate a = master/AP >>>> transmission, and associates with the AP. insert new >>>> step >>> [Paul] Needs to check not for an AP, but a specific enabling >>> signal/message/field. >>> It may be possible to have a device that looks a lot like an AP, but = is >>> a slave device. >>>=20 >>>=20 >>>>=20 >>>> 8. The slave/user device >>>> queries the master for a channel list, providing to the master >>>> the slaves' Device ID and optionally its >>>> geolocation. >>> [Paul]=20 >>> What about the model/device type? >>>=20 >>> Can we make the Device ID optional based on regulatory = requirements.... >>> Possible text: >>> 8. The slave device >>> sends a request to the master for the list of available = channels. >>> The slave device may optionally include device model/type, = device Id, >>> device operating modes and device geolocation. Regulatory = domains >>> will have specific requirements for inclusion of various device >>> attributes. >>>=20 >>>=20 >>>>=20 >>>> 9. Once the master/AP has met all regulatory domain requirements >>>> (e.g. validating the Device ID with the trusted database, etc) >>>> the master provides the list of channels locally available to = the >>>> slave/user device. If the channel that the user terminal is >>>> currently using is not included in the list of locally available >>>> channels, the slave/user device ceases all operation on its >>>> current channel. The slave/user device may scan for another AP >>>> transmission on a different channel. >>> [Paul]=20 >>> ? Except for a rare race condition - it's not possible to not have = the >>> channel being used by an AP not be on the list of available = channels. >>>=20 >>> Change to: >>>=20 >>> 9. Once the master/AP has met all regulatory domain requirements >>> (e.g. validating the Device ID with the trusted database, etc) >>> the master provides the list of channels locally available to = the >>> slave/user device. >>>=20 >>>>=20 >>>> >>>> 10. The master/AP must periodically repeat the process to request = a >>>> channel list from the database, steps 4 through 6 above. The = frequency >>>> to repeat the process is determined by the local regulator. If the >>>> response from the database indicates a channel being used by the >>>> master/AP is not available, the master/AP must stop transmitting on >>>> that >>>> channel immediately.In addition or optionally, the database may = send a >>>> message to the master/AP to rescind the availability of one or more >>>> channels. The master/AP must stop transmitting on that channel >>>> immediately. >>>=20 >>>>=20 >>>> 11. The slave or user device must periodically repeat the process = to >>>> request a channel list from the master/AP, steps 8 and 9 above. The >>>> frequency to repeat the process is determined by the local = regulator. >>>> If >>>> the response from the master/AP indicates that a channel being used = by >>>> the slave or user device is not available, the slave or user device >>>> must >>>> stop transmitting on that channel immediately. In addition or >>>> optionally, the database may send a message to the master/AP to = rescind >>>> the availability of one or more channels. The master/AP must then >>>> notify >>>> the slave or user device of the rescinded channels. The slave or = user >>>> device must stop transmitting on that channel immediately. >>>> >>>>=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 >=20 From Gabor.Bajko@nokia.com Tue Feb 7 13:49:31 2012 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 6384D11E8081 for ; Tue, 7 Feb 2012 13:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.609, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tdEZkMwj5hF for ; Tue, 7 Feb 2012 13:49:30 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 775B711E8072 for ; Tue, 7 Feb 2012 13:49:29 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q17LnL2T023223; Tue, 7 Feb 2012 23:49:25 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Feb 2012 23:49:22 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.5]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Tue, 7 Feb 2012 22:49:22 +0100 From: To: , Thread-Topic: Separating business process data from spectrum use data Thread-Index: AczlokgxAN/NbRoURu+cZ+dAW9pXPQAM+Rrg Date: Tue, 7 Feb 2012 21:49:21 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DEFEE2@008-AM1MPN1-006.mgdnok.nokia.com> References: <2782C93FD2244441893673F3F912819210EF95@IMCMBX01.MITRE.ORG> In-Reply-To: <2782C93FD2244441893673F3F912819210EF95@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2012 21:49:22.0618 (UTC) FILETIME=[5A3C69A0:01CCE5E2] X-Nokia-AV: Clean Subject: Re: [paws] Separating business process data from spectrum use data 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, 07 Feb 2012 21:49:31 -0000 Hi John, You bring up interesting points in your email below. We had a hum last meeting on whether to extend the scope to include coexist= ence requirements, and the group preferred not to do that for the time bein= g. But that should not stop us from designing the solution space in an exte= nsible way to avoid redesigning needs once the scope is extended. We had a presentation last time on the data model structure: http://www.iet= f.org/id/draft-caufield-paws-protocol-for-tvws-01.txt, this initial proposa= l does not seem to separate the data model into what you call spectrum use = relevant and business process relevant parts. Are you for the time being su= ggesting that we group the requirements as spectrum relevant and eg not-spe= ctrum relevant? What comes to your suggestion to add: > P.14 The master device must identify the spectrum data model schema it u= ses to convey its operating parameters and to receive channel availability = from the WS Database. If I understand it correctly, you want to identify first what operating par= ameters need to be sent to the DB. That was the intention of =20 "P.2: The protocol MUST support regulatory domain discovery.", since each= regulatory domain has its own mandate of parameter list. Maybe we should e= xpand P.2 to more explicitly state what you are looking for. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Stine, John A. Sent: Tuesday, February 07, 2012 6:11 AM To: paws@ietf.org Subject: [paws] Separating business process data from spectrum use data I fully understand the intent to limit the scope in this iteration of the p= aws standard to the items listed in paragraph 1.2.1 but I also believe it i= s important to look forward and consider what we would like the whitespace = database to become and to ensure that anything that is done in this first i= teration does not become a hurdle to overcome in the future. The future database roles that I think should be considered are: 1. Spectrum from licensed users can be added to databases allowing their s= pectrum to be used or reused in some way 2. Database administrators arbitr= ate coexistence 3. Database managers can convey policy to DSA systems that= allow spectrum use based on a radio using a particular behavior. =20 I do not believe consideration of these activities would have an effect on = the types of processes and messaging that the current scope prescribes but = it could have a very big impact on the data model. I recommend that the bu= siness process schemas be kept separate from the spectrum data model schema= s and that the standard be written so that spectrum data modeling schemas c= an be interchanged. The motivation for this separation is three-fold: 1. It allows other enterprises to use their own management methods but to s= hare data models making it easier for them to make their spectrum available= . 2. It allows spectrum data models tuned for particular administration regul= atory requirements 3. It allows evolution of the data models to support mor= e dynamic and interactive spectrum management without demanding confusing u= pgrades to schemas that attempt to be backwards compatible. (Backwards com= patibility is achieved at the databases that can understand multiple data m= odel schemas. We may want to add messaging that allows devices and databas= es to agree upon a schema.) Potential changes that may enable this perspective could be to divide the d= ata model into two parts. The first part would include the information nec= essary for the business process, so D.2 and D.3, and the second part would= be data elements that provide the information relevant to spectrum use. I= n the current data model requirements, this is everything else. The output= of this initial standards work would be a paws protocol for the interactio= ns between WS devices and the WS database and a separate standard for a dat= a model that it uses for defining spectrum. =20 I would then add the following to the protocol requirements: P.14 The master device must identify the spectrum data model schema it use= s to convey its operating parameters and to receive channel availability fr= om the WS Database. There are likely multiple changes required throughout the document but want= ed to instigate a discussion before I try to suggest what they might be. John A. Stine Chief Technology Advisor Operations Research and Systems Analysis The MITRE Corporation email: jstine@mitre.org,=A0 Phone:703-983-6281 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Tue Feb 7 14:13:42 2012 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 13B4021F86A8 for ; Tue, 7 Feb 2012 14:13:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.15 X-Spam-Level: X-Spam-Status: No, score=-103.15 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+NMhIYhnXuv for ; Tue, 7 Feb 2012 14:13:40 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id A593C21F869F for ; Tue, 7 Feb 2012 14:13:40 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q17MDccg008113 for ; Wed, 8 Feb 2012 00:13:39 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 00:13:38 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Tue, 7 Feb 2012 23:13:38 +0100 From: To: Thread-Topic: UC&R I-D: Section 4.5 Offloading: moving traffic to a white space network Thread-Index: AQHM5eW9WNS1/EkqQEWtYL2WByhZow== Date: Tue, 7 Feb 2012 22:13:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2012 22:13:38.0546 (UTC) FILETIME=[BE096520:01CCE5E5] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: Section 4.5 Offloading: moving traffic to a white space network 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, 07 Feb 2012 22:13:42 -0000 Hello, Sec 4.5 of the I-D draft-ietf-paws-problem-stmt-usecases-rqmts describes the use case for offloading. The use case describes a session being moved from a cellular network to a white space network. Alternatively, a session may be initiated over a white space network when a user/device has the ability to choose between the cellular network and a white space network. " Either by user selection, preconfigured preferences, or other algorithm, the streaming session is started over the TVWS internet connection instead of the 3G cellular connection. This deployment scenario is typically characterized by a TVWS master/AP providing local coverage in the same geographical area as a 3G cellular system. " After further reviewing this use case, I do not see any added value to the document in terms of deriving requirements from it. While it is a valid scenario describing how white space networks can be used for offloading of data from cellular, it does not generate any specific requirements for consideration in the design of the protocol between a master device and white space database. Hence my proposal would be that we delete this use-case from the I-D. Please comment if you believe that we should keep this use case in the I-D or are able to point to some requirements that arise from it. -Raj From Gabor.Bajko@nokia.com Tue Feb 7 14:45:11 2012 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 443ED21F87C3 for ; Tue, 7 Feb 2012 14:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.142 X-Spam-Level: X-Spam-Status: No, score=-2.142 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbVKmJaXygGe for ; Tue, 7 Feb 2012 14:45:10 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id ABCB821F87C0 for ; Tue, 7 Feb 2012 14:45:08 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q17Mj4Fq028220 for ; Wed, 8 Feb 2012 00:45:04 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 00:45:03 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.5]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Tue, 7 Feb 2012 23:45:03 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrYJn4ueezOOUqV6hR34bPZkJYyDC5Q Date: Tue, 7 Feb 2012 22:45:02 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DEFF40@008-AM1MPN1-006.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Feb 2012 22:45:03.0801 (UTC) FILETIME=[21BC7A90:01CCE5EA] X-Nokia-AV: Clean Subject: Re: [paws] Threat model (Rev 3) 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, 07 Feb 2012 22:45:11 -0000 Minor rewording of threat 6: "A white space database in a regulatory domain may require a master device = to provide its identity in addition to its location in the query request. = Such location/identity information can be gleaned by an eavesdropper and us= ed for tracking purposes. A master device may prefer to keep the location/i= dentity information hidden from eavesdroppers, hence the protocol should pr= ovide a means to protect the location and identity information of the maste= r device and prevent tracking of locations associated with a white space da= tabase query.=20 When the master device sends both its identity and location to the DB, the = DB is able to track it. If a regulatory domain does not require the master = device to provide its identity to the white space database, the master devi= ce may decide not to send its identity, to prevent being tracked by the DB.= " - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pat= il Basavaraj (Nokia-CIC/Dallas) Sent: Friday, February 03, 2012 11:34 AM To: stephen.farrell@cs.tcd.ie; paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) Below is Rev 3 of the threat model based on feedback from Stephen, Nancy an= d Gabor (Thanks). -Raj Rev 3 (3/2/12) Threat model for the PAWS protocol ---------------------------------- Assumptions: ............ o It is assumed that an attacker has full access to the network medium between the master device and the white space database. The attacker may be able to eavesdrop on any communications between these entities. The link between the master device and the white space database can be wired or wireless and provides IP connectivity. o It is assumed that the master device or the white space database have NOT been compromised from a security standpoint. Threat 1: User modifies a device to masquerade as another valid certified device The master device needs to authenticate itself with the white space database prior to requesting channel information. The attacker may try to get access to the secrets of the master device which can be used maliciously. The effect of such an attack being successful would result in a malicious client replaying the stolen authentication/authorization secrets to a white space database. Threat 2: Spoofed white space database A master device discovers a white space database(s) thru which it can query for channel information. The master device needs to ensure that the white space database with which it communicates with is an authentic entity. The white space database needs to provide its identity to the master device which can confirm the validity/authenticty of the database. An attacker may attempt to spoof a white space database and provide responses to a master device which are malicious and result in the master device causing interference to the primary user of the spectrum. Threat 3: Modifying a query request An attacker may modify the query request sent by a master device to a white space database. The attacker may change the location of the device or the capabilities in terms of its transmit power or antenna height etc. which could result in the database responding with incorrect information about available channels or max transmit power allowed. The result of such an attack is that the master device would cause intereference to the primary user of the spectrum. It could also result in a denial of service to the master device by indicating that no channels are available. Threat 4: Modifying a query response An attacker could modify the query response sent by the white space database to a master device. The channel information or transmit power allowed type of parameters carried in the response could be modified by the attacker resulting in the master device using channels that are not available at a location or transmitting at a greater power level than allowed resulting in interference to the primary user of that spectrum. Alternatively the attacker may indicate no channel availability at a location resulting in a denial of service to the master device. Threat 5: Unauthorized use of channels by an uncertified device An attacker may be a master device which is not certified for use by the relevant regulatory body. The attacker may listen to the communication between a valid master device and white space database and utilize the information about available channels in the response message by utilizing those channels. The result of such an attack is unauthorized use of channels by a master device which is not certified to operate. The master device querying the white space database may be operated by a law-enforcement agency and the communications between the device and the database are intended to be kept private. A malicious device should not be able to eavesdrop on such communications. Threat 6: Third party tracking of white space device location and identity =20 A white space database may require a master device to provide its identity in addition to its location in the query request. Such location/identity information can be gleaned by an eavesdropper. A master device may prefer to keep the location/identity information secret. Hence the protocol should provide a means to protect the location and identity information of the master device and prevent tracking of locations associated with a white space database. If regulations do not require the identity of the master device to be provided to the white space database, the master is not required to include its identity in the query. Threat 7: Termination of device service for reasons other than incumbent protection A white space database may include a mechanism by which service and channels allocated to a master device can be revoked. A malicious node can send a revoke message to a master device. This results in denial of service to the master device.=20 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Wed Feb 8 02:51:41 2012 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 BDD2D21F86D0 for ; Wed, 8 Feb 2012 02:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.943 X-Spam-Level: X-Spam-Status: No, score=-2.943 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qoRSpymp+Yv for ; Wed, 8 Feb 2012 02:51:41 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id E58C621F86CB for ; Wed, 8 Feb 2012 02:51:40 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 Feb 2012 10:51:33 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 8 Feb 2012 10:51:33 +0000 From: To: , Date: Wed, 8 Feb 2012 10:51:23 +0000 Thread-Topic: [paws] UC&R I-D: Section 4.5 Offloading: moving traffic to a white space network Thread-Index: AQHM5eW9WNS1/EkqQEWtYL2WByhZo5Yy0b1Q Message-ID: <619CDADDCCD2B44380834BE8BF6F7141406560482D@EMV62-UKRD.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] UC&R I-D: Section 4.5 Offloading: moving traffic to a white space network 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, 08 Feb 2012 10:51:41 -0000 Raj I agree that the steps described in the offloading use case do not give ris= e to any additional WSD to WDSB interaction or requirements. Regards Andy -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Bas= avaraj.Patil@nokia.com Sent: 07 February 2012 22:14 To: paws@ietf.org Subject: [paws] UC&R I-D: Section 4.5 Offloading: moving traffic to a white= space network Hello, Sec 4.5 of the I-D draft-ietf-paws-problem-stmt-usecases-rqmts describes the use case for offloading. The use case describes a session bei= ng moved from a cellular network to a white space network. Alternatively, a= session may be initiated over a white space network when a user/device has= the ability to choose between the cellular network and a white space netwo= rk. " Either by user selection, preconfigured preferences, or other algorithm, the streaming session is started over the TVWS internet connection instead of the 3G cellular connection. This deployment scenario is typically characterized by a TVWS master/AP providing local coverage in the same geographical area as a 3G cellular system. " After further reviewing this use case, I do not see any added value to the = document in terms of deriving requirements from it. While it is a valid sce= nario describing how white space networks can be used for offloading of dat= a from cellular, it does not generate any specific requirements for conside= ration in the design of the protocol between a master device and white spac= e database. Hence my proposal would be that we delete this use-case from the I-D. Please comment if you believe that we should keep this use case in the I-D = or are able to point to some requirements that arise from it. -Raj _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From jstine@mitre.org Wed Feb 8 05:12:06 2012 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 5ACFC21F86E3 for ; Wed, 8 Feb 2012 05:12:06 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qU7jTc1wpCic for ; Wed, 8 Feb 2012 05:12:05 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB2321F86DF for ; Wed, 8 Feb 2012 05:12:05 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A271521B14AE; Wed, 8 Feb 2012 08:12:04 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8EC0E21B163F; Wed, 8 Feb 2012 08:12:04 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Wed, 8 Feb 2012 08:12:04 -0500 From: "Stine, John A." To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Thread-Topic: Separating business process data from spectrum use data Thread-Index: AczlokgxAN/NbRoURu+cZ+dAW9pXPQAM+RrgAB++LyA= Date: Wed, 8 Feb 2012 13:12:04 +0000 Message-ID: <2782C93FD2244441893673F3F912819210F457@IMCMBX01.MITRE.ORG> References: <2782C93FD2244441893673F3F912819210EF95@IMCMBX01.MITRE.ORG> <1ECAFF543A2FED4EA2BEB6CACE08E47601DEFEE2@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DEFEE2@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.53] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Separating business process data from spectrum use data 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, 08 Feb 2012 13:12:06 -0000 Gabor, Yes, I am suggesting that you separate the spectrum data model from the bus= iness process data model. This loose coupling can be very powerful in the = long term. Think of a very simple type of transaction where a device reque= sts spectrum but fails to provide sufficient information in their request.= The business process part might allow the WSDB to reply and identify the = additional information that is needed. Developing that type of request now= with the constraint of separate data models will cause that work to be reu= sable for whatever expansion or revision occurs to the data models in the f= uture. This might not be the case if you combine data models. You may end= up with a lot of separate request for different types of data elements. I= f you expand or change the spectrum data model, you would have to create mu= ltiple new messages. This is not so, if the design starts with the two sep= arate data models. If this is not motivation, you may consider a long term outcome where large= users of spectrum, think U.S. Department of Defense, which has its own bus= iness process might be willing to relinquish spectrum for reuse if managed = by a WSDB system. The DoD does not use its spectrum everywhere in the US. = A shared spectrum data model can support this sharing but it is highly unl= ikely that the WSDB systems and the DoD would share the same business proce= ss. Yes, P2 could be expanded for this purpose. Here is a suggestion. The protocol MUST support regulatory domain discovery and in that discovery= agreement on the spectrum data model to be used. In the near term there may only be different data models between regulatory= domains but in the long term I could see even regulatory domains having mu= ltiple data models as new ways of sharing are defined. John -----Original Message----- From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 Sent: Tuesday, February 07, 2012 4:49 PM To: Stine, John A.; paws@ietf.org Subject: RE: Separating business process data from spectrum use data Hi John, You bring up interesting points in your email below. We had a hum last meeting on whether to extend the scope to include coexist= ence requirements, and the group preferred not to do that for the time bein= g. But that should not stop us from designing the solution space in an exte= nsible way to avoid redesigning needs once the scope is extended. We had a presentation last time on the data model structure: http://www.iet= f.org/id/draft-caufield-paws-protocol-for-tvws-01.txt, this initial proposa= l does not seem to separate the data model into what you call spectrum use = relevant and business process relevant parts. Are you for the time being su= ggesting that we group the requirements as spectrum relevant and eg not-spe= ctrum relevant? What comes to your suggestion to add: > P.14 The master device must identify the spectrum data model schema it u= ses to convey its operating parameters and to receive channel availability = from the WS Database. If I understand it correctly, you want to identify first what operating par= ameters need to be sent to the DB. That was the intention of =20 "P.2: The protocol MUST support regulatory domain discovery.", since each= regulatory domain has its own mandate of parameter list. Maybe we should e= xpand P.2 to more explicitly state what you are looking for. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Stine, John A. Sent: Tuesday, February 07, 2012 6:11 AM To: paws@ietf.org Subject: [paws] Separating business process data from spectrum use data I fully understand the intent to limit the scope in this iteration of the p= aws standard to the items listed in paragraph 1.2.1 but I also believe it i= s important to look forward and consider what we would like the whitespace = database to become and to ensure that anything that is done in this first i= teration does not become a hurdle to overcome in the future. The future database roles that I think should be considered are: 1. Spectrum from licensed users can be added to databases allowing their s= pectrum to be used or reused in some way 2. Database administrators arbitr= ate coexistence 3. Database managers can convey policy to DSA systems that= allow spectrum use based on a radio using a particular behavior. =20 I do not believe consideration of these activities would have an effect on = the types of processes and messaging that the current scope prescribes but = it could have a very big impact on the data model. I recommend that the bu= siness process schemas be kept separate from the spectrum data model schema= s and that the standard be written so that spectrum data modeling schemas c= an be interchanged. The motivation for this separation is three-fold: 1. It allows other enterprises to use their own management methods but to s= hare data models making it easier for them to make their spectrum available= . 2. It allows spectrum data models tuned for particular administration regul= atory requirements 3. It allows evolution of the data models to support mor= e dynamic and interactive spectrum management without demanding confusing u= pgrades to schemas that attempt to be backwards compatible. (Backwards com= patibility is achieved at the databases that can understand multiple data m= odel schemas. We may want to add messaging that allows devices and databas= es to agree upon a schema.) Potential changes that may enable this perspective could be to divide the d= ata model into two parts. The first part would include the information nec= essary for the business process, so D.2 and D.3, and the second part would= be data elements that provide the information relevant to spectrum use. I= n the current data model requirements, this is everything else. The output= of this initial standards work would be a paws protocol for the interactio= ns between WS devices and the WS database and a separate standard for a dat= a model that it uses for defining spectrum. =20 I would then add the following to the protocol requirements: P.14 The master device must identify the spectrum data model schema it use= s to convey its operating parameters and to receive channel availability fr= om the WS Database. There are likely multiple changes required throughout the document but want= ed to instigate a discussion before I try to suggest what they might be. John A. Stine Chief Technology Advisor Operations Research and Systems Analysis The MITRE Corporation email: jstine@mitre.org,=A0 Phone:703-983-6281 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Wed Feb 8 07:11:19 2012 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 452F421F85B7 for ; Wed, 8 Feb 2012 07:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.145 X-Spam-Level: X-Spam-Status: No, score=-2.145 tagged_above=-999 required=5 tests=[AWL=-0.146, BAYES_00=-2.599, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmUCJ+DjlaFR for ; Wed, 8 Feb 2012 07:11:14 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4AF21F85FB for ; Wed, 8 Feb 2012 07:11:09 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q18FAmtK006845 for ; Wed, 8 Feb 2012 17:11:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 17:11:04 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Wed, 8 Feb 2012 16:11:03 +0100 From: To: Thread-Topic: UC&R I-D: section 4.8 (Mobility) Thread-Index: AQHM5nPf+XRA0jv7PUOy6i81HODdIQ== Date: Wed, 8 Feb 2012 15:11:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <4627F20B4FF8CA44A63106AEA835290B@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 15:11:04.0898 (UTC) FILETIME=[E07F7A20:01CCE673] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: section 4.8 (Mobility) 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, 08 Feb 2012 15:11:19 -0000 Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for section on the Mobility use case (new section numbering is NOT shown, all use cases will be moved to section 4.2 Use cases in the next version). This text has been marked up from version-02 as uploaded January 26, 2012 as follows: * change the scenario from peer-to-peer to simple master & slave. Motivation is to separate this mobility case from the case of peer-to-peer communications without a master involved (a separate topic) * include most of the applicable comments from the Hotspot use case (comments leading global clarifications or new text will be added in next version, v-03). Our goal is that any discussion on this text will conclude by February 15. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 4.8. Mobility In this use case, the user has a non-fixed (portable or mobile) device and is riding in a vehicle. The user wants to have connectivity to another device which is also moving. Typical deployment scenarios include urban areas and rural areas where the user may connect to other users while movingin peer-to-peer or ad-hoc networks. This deployment scenario is typically characterized by a master device with low antenna height, internet connectivity by some connection that does not utilize TV white space, and some means to predict its path of mobility. This knowledge of mobility could be simple (GPS plus accelerometer), sophisticated (GPS plus routing and mapping function) or completely specified by the user via user- interface. The figure below shows an example deployment of this scenario. \|/ \|/ | TDD Air Interface | | | +-|---------+ +-|---------+ | TVWS | | TVWS | |Master Dev | |Master Dev | +-----------+ +-----------+ \ (----) / \ ( ) / \ / \ / ( Internet ) \ / ( )\----------+ (----) | Database | +----------+ Figure 8: Example illustration of mobility in TV white space use-case A simplified operational scenario utilizing TV whitespace to provide peer-to-peer connectivity service in a mobility environment consists of the following steps: 1. The mobile master device powers up with its WS radio in idle or listen mode only (no active transmission on the WS frequency band). 2. The mobile master has internet connectivity , determines its location, and establishes a connection to a trusted white space database (see Section 4.1 reference is to database discovery, will be updated in next version). 3. The mobile master registers with the trusted database according to regulatory domain requirements (see Section 4.2 reference is to registration, will be updated in next version). 4. Following the successful registration process, the mobile master will send a query to the trusted database requesting a list of available WS channels based upon its current location, other parameters required by the local regulator (see Hotspot use case, step 4) and a=20 prediction of its future location, extrapolated from the motion or mobility of the device. The current location is specified in latitude and longitude. The method to specify the future location is TBD, potential methods include movement vector (direction and velocity), a set of latitude/longitude points which specify a closed polygon where the future location is within the polygon, or similar. 5. If the mobile master has met all regulatory domain requirements (e.g. been previously authenticated, etc), the database responds with a list of available white space channels that the mobile master may use, and optional information which may include (1) a duration of time for the use of each channel (2) a maximum transmit power for each channel and (3) notification of any additional requirement for sensing. 6. Once the mobile master has met all regulatory domain requirements (e.g. authenticated the WS channel list response message from the database, etc), the master selects anone or more available WS channel(s) from the list for use. 7. The otherslave / user device in the peer-to-peer connection scans the TV bands to locate a mobile master transmission, and associates with the mobile master. insert new step 8. The slave/user device queries the master for a channel list, based onproviding to the master the slave's device identification, and optionally its geolocation and optionally a prediction of its future location. 9. If required by local regulation, the master device verifies the slave's device identification with the database. 9. If allowed by local regulationOnce the mobile master has meet all regulatory domain requirements (e.g. the slave's device identification is verified by the database), the mobile master provides the list of channels locally available to the slave/user device. If the channel that the slave/user terminal is currently using is not included in the list of locally available channels, the slave/user device ceases all operation on its current channel. The slave/user device may scan for another Master's transmission on a different channel. 10. The mobile master moves outside the predicted range of future positions in step 4, it must repeat the process to request a channel list from the database, steps 4 through 6 above. If the response from the database indicates a channel being used by the mobile master is not available, the master/AP must stop transmitting on that channel Immediately. 11. The slave or user device must periodically repeat the process to request a channel list from the master/AP, steps 8 and 9 above. The frequency to repeat the process is determined by the local regulator. If the response from the master/AP indicates that a channel being used by the slave or user device is not available, the slave or user device must stop transmitting on that channel immediately. In addition or optionally, the database may send a message to the master/AP to rescind the availability of one or more channels. The master/AP must then notify the slave or user device of the rescinded channels. The slave or user device must stop transmitting on that channel immediately. From gerald.chouinard@sympatico.ca Wed Feb 8 07:22:49 2012 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 8432121F8552 for ; Wed, 8 Feb 2012 07:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.105 X-Spam-Level: X-Spam-Status: No, score=0.105 tagged_above=-999 required=5 tests=[AWL=-1.899, BAYES_50=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBA6oRSzcLTN for ; Wed, 8 Feb 2012 07:22:43 -0800 (PST) Received: from blu0-omc3-s37.blu0.hotmail.com (blu0-omc3-s37.blu0.hotmail.com [65.55.116.112]) by ietfa.amsl.com (Postfix) with ESMTP id 5380D21F8505 for ; Wed, 8 Feb 2012 07:22:42 -0800 (PST) Received: from BLU0-SMTP80 ([65.55.116.74]) by blu0-omc3-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:22:41 -0800 X-Originating-IP: [70.26.237.137] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([70.26.237.137]) by BLU0-SMTP80.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:22:40 -0800 From: Gerald Chouinard To: , References: <619CDADDCCD2B44380834BE8BF6F7141406554D98B@EMV62-UKRD.domain1.systemhost.net> Date: Wed, 8 Feb 2012 10:20:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHM5Q9winjPL72/P0qKL6qZMyxLKJYwd0zw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Feb 2012 15:22:41.0040 (UTC) FILETIME=[7F6E5100:01CCE675] Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) 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, 08 Feb 2012 15:22:49 -0000 Hi, I agree with Scott here. The FCC requirement seems to be superfluous = but even then, the way the master would send the channel information to the slaves should be beyond the scope of PAWS. It will not use the protocol = that needs to be defined to access the database. In the IEEE 802.22 Standard, the base station regularly broadcasts a prioritized list of backup channels so that if the base station needs to change the channel of the network because the current channel (or its adjacent channels if the device EIRP is larger than 100 mW) becomes = occupied by an incumbent as indicated by the database or some RF sensing scheme, = the slave CPEs can all switch to the next channel. This process has nothing = to do with the protocol used by the base station to access the database. Respectfully ... Gerald -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Monday, 06 February, 2012 15:40 To: andy.sago@bt.com; Basavaraj.Patil@nokia.com; paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet connectivity service) Hello Andy, These steps are meant to address the FCC requirements in = =A715.711(b)(3)(iv) where the slave device may only transmit upon receiving a list of available channels from a master. Certainly this requirement, and thus steps 8, 9 & 11, may not apply in all parts of the world. Kind Regards, Scott On 2/6/12 6:10 AM, "ext andy.sago@bt.com" wrote: >Scott, Raj, all > >I don't see the need for steps 8, 9 and 11, where slaves query the = master >for frequencies. In this use case, all slaves only talk to masters, not >to each other. By definition they must be using a WS channel allocated = by >the WSDB to the master WSD - they are part of the master network and >using its frequencies. The master advertises its presence in some way = on >the WS (we don't need to know how or at what layer, but could be SSIDs, >beacons, required timing information etc). There must be some sort of >advertisement otherwise slaves can never connect. If the master drops = use >of a frequency that a slave was using, then, like in cellular mobile or >Wi-Fi, the slave drops off the network shortly after failing to hear = the >master, and will have to rejoin using another frequency being = transmitted >by the master, if any. The slave never needs to ask for frequencies. > >Have I missed something, or are we making the protocol unnecessarily >complicated? > >Andy > > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >scott.probasco@nokia.com >Sent: 03 February 2012 21:42 >To: paws@ietf.org >Subject: [paws] UC&R I-D: section 4.3 (Hotspot: urban internet >connectivity service) > >Hello All, > >As editors of the problem statement, use cases & requirements draft we >are attempting to prepare a completed draft which could be ready for >working group last call before IETF83. In the coming days we will post >the sections of the draft to the mailing list. Our request is that you >review these sections and reply to the email with any comments. > >Below is the text for section on the Hotspot use case (new section >numbering is NOT shown, all use cases will be moved to section 4.2 Use >cases in the next version). This text has been marked up from = version-02 >as uploaded January 26, 2012 as follows: >* now includes steps to change the availability of spectrum on short >notice >* clarification that in some cases a master may initialize over a white >space channel >* clarification that registration includes device location >* clarification on the possible parameters in the channel request >* clarification on the possible parameters in the channel response > >Our goal is that any discussion on this text will conclude by February = 10. >To be clear, approval of the document will go through the normal = process >of last calls etc.. We are simply asking for your assistance in = preparing >a complete & accurate document that could progress the work. So please >review the text and send your comments either directly to the editor or >to the mailing list. > >Kind Regards, >Raj & Scott > > > > > > > >4.3. Hotspot: urban internet connectivity service > > In this use case internet connectivity service is provided in a > "hotspot" to local users. Typical deployment scenarios include = urban > areas where internet connectivity is provided to local businesses = and > residents, and campus environments where internet connectivity is > provided to local buildings and relatively small outdoor areas. = This > deployment scenario is typically characterized by multiple masters > (APs or hotspots) in close proximity, with low antenna height, cells > with relatively small radius (a few kilometers or less), and limited > numbers of available radio channels. Many of the masters/APs are > assumed to be individually deployed and operated, i.e. there is no > coordination between many of the masters/APs. The masters/APs in > this scenario use a TDD radio technology and transmit at or below a > relatively low transmit power threshold. Each master/AP has a > connection to the internet and provides internet connectivity to > multiple master and or slave devices. > > The figure below shows an example deployment of this scenario. > > > > -------- > |Device|\ \|/ ---------- > | 1 | (TDD AirIF) | |Database| > -------- \ | .---. /--------- > o \ |-|---------| ( ) / > o | Master | / \ > o / | |=3D=3D=3D=3D=3D=3D=3D=3D( = Internet ) > o / |-----------| \ / > -------- (TDD AirIF) ( ) > |Device| / (----) > | n | > -------- > > > Figure 3: Hotspot service using TV white space spectrum > > Once a master/AP has been correctly installed and configured, a > simplified power up and operation scenario utilizing TV White Space > to provide Internet connectivity service to slave devices, >including the ability to clear WSDs from select channels, is described. >This scenario consists of the following steps: > > 1. The master/AP powers up; however its WS radio and all other WS > capable devices will power up in idle/listen only mode (no = active > transmissions on the WS frequency band). A local = regulator >may identify exception cases where a Master may initialize over white >space (e.g. the FCC allows a Master to initialize over TV white space = in >certain conditions)." > > 2. The master/AP has Internet connectivity , determines its >location (either from location determination capability or from saved >value that was set during installation), and establishes a >connection to a trusted white space database (see Section 4.1 Note>reference is to database discovery, will be updated in next >version). > > 3. The master/AP registers with the trusted database according to > regulatory domain requirements (see Section 4.2 Note>reference is to registration, will be updated in next versionNote>). > > 4. Following the successful registration process, >the master/AP will send a > query to the trusted database requesting a list of available WS > channels based upon its geolocation. The complete set of >parameters to be provided from the Master to the database is specified = by >the local regulator. Parameters may include WSD location, accuracy of = of >that location, device antenna height, device identifier of a slave = device >requesting channel information. > > 5. If the master/AP has met all regulatory domain requirements = (e.g. > been previously authenticated, etc), the database responds with = a > list of available white space channels that the master may use, > and optionally a duration of time for their use, >associated maximum power levels or a notification of any additional >requirement for sensing. > > 6. Once the master/AP has met all regulatory domain requirements > (e.g. authenticated the WS channel list response message from = the > database, etc), the AP selects an available WS channel(s) from > the list. > > 7. The slave or user device scans the TV bands to locate a = master/AP > transmission, and associates with the AP. insert new >step > > 8. The slave/user device > queries the master for a channel list, providing to the master > the slaves' Device ID and optionally its >geolocation. > > 9. Once the master/AP has met all regulatory domain requirements > (e.g. validating the Device ID with the trusted database, etc) > the master provides the list of channels locally available to = the > slave/user device. If the channel that the user terminal is > currently using is not included in the list of locally available > channels, the slave/user device ceases all operation on its > current channel. The slave/user device may scan for another AP > transmission on a different channel. > > > 10. The master/AP must periodically repeat the process to request a >channel list from the database, steps 4 through 6 above. The frequency = to >repeat the process is determined by the local regulator. If the = response >from the database indicates a channel being used by the master/AP is = not >available, the master/AP must stop transmitting on that channel >immediately.In addition or optionally, the database may send a message = to >the master/AP to rescind the availability of one or more channels. The >master/AP must stop transmitting on that channel immediately. > > 11. The slave or user device must periodically repeat the process to >request a channel list from the master/AP, steps 8 and 9 above. The >frequency to repeat the process is determined by the local regulator. = If >the response from the master/AP indicates that a channel being used by >the slave or user device is not available, the slave or user device = must >stop transmitting on that channel immediately. In addition or = optionally, >the database may send a message to the master/AP to rescind the >availability of one or more channels. The master/AP must then notify = the >slave or user device of the rescinded channels. The slave or user = device >must stop transmitting on that channel immediately. > > >_______________________________________________ >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 gerald.chouinard@sympatico.ca Wed Feb 8 07:24:28 2012 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 6C70721F86BB for ; Wed, 8 Feb 2012 07:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.005 X-Spam-Level: * X-Spam-Status: No, score=1.005 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_50=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGr5i6AKBO2Y for ; Wed, 8 Feb 2012 07:24:15 -0800 (PST) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF2C21F8693 for ; Wed, 8 Feb 2012 07:24:11 -0800 (PST) Received: from BLU0-SMTP80 ([65.55.116.73]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:24:10 -0800 X-Originating-IP: [70.26.237.137] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([70.26.237.137]) by BLU0-SMTP80.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:24:07 -0800 From: Gerald Chouinard To: , , References: <1AFF4BC0-6A7E-405A-B3B7-09090E2E94E8@earthlink.net> <619CDADDCCD2B44380834BE8BF6F714140653B5173@EMV62-UKRD.domain1.systemhost.net> Date: Wed, 8 Feb 2012 10:20:52 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01CCE64B.CB3CB1F0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aczg8IPgWtCYNl09RPqA4m4B+qMGRgAAFHKgADSoSkA= In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140653B5173@EMV62-UKRD.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Feb 2012 15:24:08.0072 (UTC) FILETIME=[B34E5880:01CCE675] Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 15:24:28 -0000 ------=_NextPart_000_0031_01CCE64B.CB3CB1F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy, To resolve Nancy's concern, a new definition could be added for: TVWS White Space devices: White Space devices that operate in the TV bands. This would complement the definition of White Space devices and make it more specific. I am having second thoughts about your suggestion to remove the concept of classes of devices from the White Space devices. The opportunistic use of the RF spectrum assumes that these devices operate while protecting existing operation in the band. There is automatically assumes the existence of primary users of the band that have priority. Such primary users would most likely be licensed to use the band and it is only the portions that happen to be unused that will be accessible to the White Space devices. The latter are unlikely to be licensed to only use the 'crumbs'. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices and then why would they need to protect these 'primary' licensed devices. This would be similar to the situation in the 2.4 GHz where a database is not needed to protect other devices. As is well understood, the databases are there to protect primary and possibly secondary licensed devices from the new opportunistic devices, not opportunistic devices among themselves. The latter case would be covered by other means such as a database to provide coexistence and this is, I believe, beyond the scope of PAWS. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Wednesday, 01 February, 2012 09:58 To: nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Nancy, all Good questions. I'm not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your other questions, IMO our aim should be to provide all the necessary information in this PAWS requirements I-D to enable the PAWS protocol I-D to be developed. I don't think it's our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this very well, and regulators tend to be well coordinated or play 'follow my leader'. Thanks for pointing out the reference to licence-exempt that I had missed in 4.4 - I think the meaning would be just the same with 'in a license-exempt TVWS environment' deleted from that sentence. That would be my suggestion. Regards Andy From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: 01 February 2012 14:48 To: Sago,AJ,Andy,COD R Cc: paws@ietf.org Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6.so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain how the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could change, but, why not give the information on both for countries to understand fully what it's choices are? Thanks Andy, just some early morning thoughts.Sincerely, Nancy Begin forwarded message: From: Nancy Bravin Date: February 1, 2012 6:35:09 AM PST To: Andy Sago Cc: , , , Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Andy, All In section 4.4, license exempt is also mentioned as well. I am conflicted in a global sense when emerging countries, or countries with very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby join the existing DB companies, or will they do their own thing leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/or White spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, wrote: Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV white spaces, whereas the scope of PAWS is white spaces in general. I would question not only why the lower-priority service would always be licence-exempt, but why the higher priority service would always be licenced. To avoid this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or unlicensed, or any mention of the regulatory status of the incumbent services. The Abstract derives from the Introduction and the text could be aligned to be the same in the Introduction, with "opportunistic" replacing "secondary" in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don't need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document - we are defining requirements fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum use has now got muddled with the potential for opportunistic use. This can be fixed by taking the white space and white space device definitions together. From Scott, Gerald and Jussi's comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum, under control of a white space database. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required by local regulations to query a database with its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not necessarily apply to all under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunistic use of the spectrum by white space devices in the last sentence of the definition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but is not fully occupied by that licensed use at a specific location and time. This spectrum is then assigned allowed by local regulations for use to be used opportunistically as licensed-exempt spectrum under control of a white space database. This way, it is understood that the database does not "assign" white space devices for them to choose from. Gerald _____ From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do these changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White Space". Kind Regards, Scott From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott , "paws@ietf.org" Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of "Protected Entity" and "White Space Devices (WSD)" where the notion of secondary use is included. The secondary status is used in the ITU-R Radio Regulations for a different purpose. In fact, it is possible that a band has already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operation where the two first types of services are not being used. The use of "lower priority opportunistic" service rather than "secondary" service would be preferable to describe white space allocations. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes to the draft based on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the document should accurately explain the subject with aim that a reader can understand the use cases and the subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if something is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is the 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exempt spectrum is Typically referred to as "unlicensed" spectrum. In this document the terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondarylicense-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary useand assigned for licensed use, but is not fully occupied by that primary use licensed use at a specificlocation and time. This spectrum is then assigned by locationlocal regulations for use as licensed-exempt spectrum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' Cc: "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unlicensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As an example, in the ITU-R context, an "unlicensed" band is typically a new band, say in the 300 GHz, for which no request has been made for its use. It is therefore un-allocated to a specific service so far and thus it is an "unlicensed" frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrations can thendecide under what king of regime it will 'assign' this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus "license-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicensed" in the USA. If the qualifier applies to an operation, the operation can be exempt of license by the local administration, thus a "license-exempt" operation. If, however, someone decides to start an RF transmission operation in a licensed band for which he has no license or in a license-exempt band for which he does not meet the requirements such as operating according to the type of operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an "unlicensed" operation. If the qualifier applies to the transmission device, such device may be a "license-exempt" device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id de-facto an "unlicensed" device since it has not passed through the normal certification process. Note that a "license-exempt" device still has to go through a certification process and meet the limits imposed by the local regulator for the "license-exempt" operation in the given frequency band whereas an "unlicensed" device may not pass the certification process since it has not been licensed to operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licensed" operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses. Gerald _____ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs to be careful with the word'unlicensed' which may mean 'illegal' operation of an RF device in many administrations. Gerald _____ From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as 'license-exempt', in most cases the term 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statement: The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald _______________________________________________ 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 ------=_NextPart_000_0031_01CCE64B.CB3CB1F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy,

 

To resolve Nancy’s concern, a new = definition could be added for:

 

TVWS White Space devices: White = Space devices that operate in the TV bands.

 

This would complement the = definition of White Space devices and make it more = specific.

 

I am having second thoughts about = your suggestion to remove the concept of classes of devices from the White = Space devices. The opportunistic use of the RF spectrum assumes that these = devices operate while protecting existing operation in the band.  There is automatically assumes the existence of primary users of the band that = have priority. Such primary users would most likely be licensed to use the = band and it is only the portions that happen to be unused that will be accessible = to the White Space devices.  The latter are unlikely to be licensed to = only use the ‘crumbs’. Removing the concept of license-exempt could = put these new devices at the same level of priority as the primary devices = and then why would they need to protect these ‘primary’ licensed = devices.

 

This would be similar to the = situation in the 2.4 GHz where a database is not needed to protect other devices. As = is well understood, the databases are there to protect primary and possibly = secondary licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other means such = as a database to provide coexistence and this is, I believe, beyond the scope = of PAWS.

 

Gerald

 

From: = paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 = February, 2012 09:58
To: = nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Nancy, all

 <= /o:p>

Good = questions. I’m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are = studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary = information in this PAWS requirements I-D to enable the PAWS protocol I-D to be = developed. I don’t think it’s our job to explain different regulatory = regimes or applications (beyond use cases) in this document, ITU and others do this = very well, and regulators tend to be well coordinated or play ‘follow = my leader’.

 <= /o:p>

Thanks for = pointing out the reference to licence-exempt that I had missed in 4.4 -  I = think the meaning would be just the same with ‘in a license-exempt TVWS environment’ deleted from that sentence. That would be my = suggestion.

 <= /o:p>

Regards=

 <= /o:p>

Andy

 <= /o:p>

From: Nancy = Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February 2012 = 14:48
To: Sago,AJ,Andy,COD = R
Cc: paws@ietf.org
Subject: Fwd: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Hi Andy, also, throughout the document TVWS = are mentioned in 4.1,4.5, 4.6…so if you propose to remove any = reference to TVWS it will affect

the document as a whole, and information that = seems necessary to explain how the DB and protocol interacts with TVWS devices = and

the methods of doing so. One can envision = that current rules could change, but, why not give the information on both for = countries to understand fully

what it's choices = are? 

 

Thanks Andy, just some early morning thoughts…Sincerely, Nancy

 

Begin forwarded = message:

 

From: = Nancy Bravin <nbravin@earthlink.net>

Date: = February 1, 2012 6:35:09 AM PST

To: = Andy Sago <andy.sago@bt.com>

Subject= : Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 

Hi Andy, All

 

In section 4.4, license exempt is also = mentioned as well. 

I am conflicted in a global sense when = emerging countries, or countries with very different types of gov't want to = implement

the protocol, will they have enough = information to do so? and thereby join the existing DB companies, or will they do their = own thing

leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/or White spaces = in general?

 

Thanks, just a = thought.

 

SIncerely, Nancy

 

 

On Feb 1, 2012, at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

 

Scott, = All

 

I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only = why the lower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th Jan I = proposed (= http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with “opportunistic” replacing “secondary” in later sentences in the Introduction. I have = checked and there are no further references to licensing in the document, so we don’t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document – we are defining requirements fora protocol. Keep it simple.

 

That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  From Scott, = Gerald and Jussi’s comments perhaps we could agree on:

 

White Space = (WS)

 <= /font>

Radio = spectrum which is not fully occupied at a specific location and = time.

 <= /font>

White Space = device

 <= /font>

A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white = space device is required by local regulations to query a database with its = location to obtain information about available spectrum.

 

Regards

 

Andy<= /font>

 

From: paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: gerald.chouinard@sympatico.= ca; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?

 

Kind = regards,

Jussi=

 

From: paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of ext = Gerald Chouinard
Sent: 31 January 2012 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

Scott,

 

Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of “white space” as = follows:

 

White = Space

 <= /font>

Radio = spectrum which has been allocated and assigned for licensed use, but is not fully = occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> = by local regulations <delete>for use<delete> <insert>to = be used opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>

 

This way, it is understood that the database does not “assign” white space devices for them to = choose from.

 

Gerald

From: scott.probasco@nokia.com [mailto:scott.proba= sco@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

Hi = Gerald,

 <= /font>

Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that = we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?

 <= /font>

I also = corrected "location" to "local" in previous text proposed for "White Space".

 <= /font>

Kind = Regards,

Scott

 <= /font>

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>= , "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

= Scott,

= Great proposal.  However, I am still a bit nervous about the definitions = of “Protected Entity” and “White Space Devices = (WSD)” where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In = fact, it is possible that a band has already primary and secondary services = allotted to it and that the White Space operation is a tertiary opportunistic = operation where the two first types of services are not being used.  The use = of “lower priority opportunistic” service rather than “secondary” service would be preferable to describe white = space allocations.

=  

= Gerald

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
= Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

Hi,

 

I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the = draft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.

 

I hope this captures the key points of the discussion. Please do reply if something is still missing.

 

Kind Regards,

Scott

 

 

2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio = technologies,

      the database is an entity which contains current = information about

      available spectrum at any given location and other types = of

      information.

 

   Device ID

 

      A unique number for each master device and slave device = that

      identifies the manufacturer, model number and serial = number.

 

<Insert>

   Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given = service area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, = company merger &

      acquisition,  first-come / first-served or by = government allocation

      (e.g., public service).

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the USA, license-exempt = spectrum is

      Typically referred to as "unlicensed" spectrum. = In this document the terms

      license-exempt and unlicensed are used = interchangeably.

 

</Insert>

 

   Location Based Service

 

      An application or device which provides data, information = or

      service to a user based on their = location.

 

   Master Device

 

      A device which queries the WS Database to find out the = available

      operating channels.

 

   Protected Entity

 

      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space

      devices) for its use</Delete> in a given area and = time.

 

   Protected Contour

 

      The exclusion area for a Protected Entity, held in the = database

      and expressed as a polygon with geospatial points as the = vertices.

 

   Slave Device

 

      A device which uses the spectrum made available by a = master

      device.

 

   TV White Space

 

      TV white space refers specifically to radio spectrum which = has

      been allocated for TV broadcast, but is not occupied by a = TV

      broadcast, or other licensed user (such as a wireless = microphone),

      at a specific location and time.

 

   White Space

 

      Radio spectrum which has been allocated <Delete>for = some primary use</Delete><Insert>and assigned for licensed use</Insert>, but

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> = regulations for use as licensed-exempt spectrum under control of a white space database.</Insert>

 

   White Space Device (WSD)

 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</In= sert> user of some part of white space

      spectrum.  A white space device can be an access = point, base

      station, a portable device or similar.  In this = context, a white

      space device is required to query a database with its = location to

      obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" = <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Nancy,

=  

= This is not that simple.  In fact, the qualifiers = “license-exempt” and “unlicensed” can apply to more than one = thing.

=  

= If the qualifier applies to a frequency band, different options exist. As an = example, in the ITU-R context, an “unlicensed” band is typically a = new band, say in the 300 GHz, for which no request has been made for its = use.  It is therefore un-allocated to a specific service so far and thus it is an “unlicensed” frequency band. Once the ITU-R allocates this = band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will ‘assign’ = this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus “license-exempt”such as in the 2.4 GHz ISM band. This is = also called “unlicensed” in the USA.

=  

= If the qualifier applies to an operation, the operation can be exempt of = license by the local administration, thus a “license-exempt” operation. = If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an “unlicensed” operation.

=  

= If the qualifier applies to the transmission device, such device may be a “license-exempt” device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an “unlicensed” device since it has not passed = through the normal certification process.

=  

= Note that a “license-exempt” device still has to go through a certification process and meet the limits imposed by the local regulator = for the “license-exempt” operation in the given frequency band = whereas an “unlicensed” device may not pass the certification = process since it has not been licensed to operation in the = country.

=  

= This is why the qualifier “unlicensed” has to be treated with care = and the footnote will need to be crafted very carefully.

=  

= With respect to your second point, if an administration only allows “licensed” operation, the situation will be much simpler to = manage since specific conditions will be attached to these = licenses.

=  

= Gerald

=  

From: Nancy Bravin [mailto:nbravin@earthlink.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Gabor and = Gerald, 

Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use = to indicate that "according to each countries regulatory = requirements"  

How to get = around the fact that some Countries are or will be "licensed only" by = their gov'ts?  Thanks

Nancy

On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:



= Gabor,

=  

= I agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word‘unlicensed’ which may mean ‘illegal’ operation of an RF device in many = administrations.

=  

= Gerald

=  

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as ‘license-exempt’, in most = cases the term ‘unlicensed-band’ is used.

 

Therefore, may I suggest that the draft will include the following = statement:

 

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.

 

-      = ;    Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

All,

 

= Here is my understanding of the terms:

=  

= Licensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).

=  

= Lightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos = that would normally work with full licensing through auction over large = service areas.

=  

= License-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for = a specific type of operation. The FCC should be contacted to clarify = it.

=  

= Unlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, = this term is used to mean “license-exempt," see = above.

=  

= To my knowledge, the term “unlicensed” is used only in the USA to describe a legal operation = because the term “license-exempt” has been used for another specific purpose.

=  

= Since the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I = would suggest the use of ‘licensed’ and = ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in = the USA instead of the usual ‘license-exempt’.

=  

= Gerald

_______________________________________________
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

 

 

------=_NextPart_000_0031_01CCE64B.CB3CB1F0-- From gerald.chouinard@sympatico.ca Wed Feb 8 07:24:28 2012 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 A8C1621F86E0 for ; Wed, 8 Feb 2012 07:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.055 X-Spam-Level: * X-Spam-Status: No, score=1.055 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rzvWiJb83hB for ; Wed, 8 Feb 2012 07:24:17 -0800 (PST) Received: from blu0-omc3-s21.blu0.hotmail.com (blu0-omc3-s21.blu0.hotmail.com [65.55.116.96]) by ietfa.amsl.com (Postfix) with ESMTP id A2B2921F865B for ; Wed, 8 Feb 2012 07:24:14 -0800 (PST) Received: from BLU0-SMTP80 ([65.55.116.74]) by blu0-omc3-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:24:13 -0800 X-Originating-IP: [70.26.237.137] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([70.26.237.137]) by BLU0-SMTP80.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 07:24:11 -0800 From: Gerald Chouinard To: , , , References: <23293D9BB25E0B48A038B78C7D1D0D5C01E6017B@008-AM1MPN1-021.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F714140653B4DF6@EMV62-UKRD.domain1.systemhost.net> Date: Wed, 8 Feb 2012 10:20:52 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01CCE64B.CDBE05A0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHM4GhgAXLRm0MfH0eU5prccikhbJYnpdQQgAAi1DCAAfm44A== In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140653B4DF6@EMV62-UKRD.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Feb 2012 15:24:12.0275 (UTC) FILETIME=[B5CFAC30:01CCE675] Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 15:24:28 -0000 ------=_NextPart_000_0035_01CCE64B.CDBE05A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy, I like your suggestions to broaden it to any bands that are not fully occupied and for any type of devices. However, white space should be white and not grey: "White Space (WS) Radio spectrum which is not fully occupied at a specific location and time." Also, White Space devices should not be limited to those that need the database to operate, RF sensing or other opportunistic means may be allowed in some cases: "White Space device A device which opportunistically uses some part of the white space spectrum, under control of a white space database. A white space device can be an access point, base station, a portable device or similar. In this context, a A white space device is Insert>may be required by local regulations to query a database with its location to obtain information about available spectrum." Gerald _____ From: andy.sago@bt.com [mailto:andy.sago@bt.com] Sent: Wednesday, 01 February, 2012 05:34 To: jussi.kahtava@nokia.com; gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV white spaces, whereas the scope of PAWS is white spaces in general. I would question not only why the lower-priority service would always be licence-exempt, but why the higher priority service would always be licenced. To avoid this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or unlicensed, or any mention of the regulatory status of the incumbent services. The Abstract derives from the Introduction and the text could be aligned to be the same in the Introduction, with "opportunistic" replacing "secondary" in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don't need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document - we are defining requirements fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum use has now got muddled with the potential for opportunistic use. This can be fixed by taking the white space and white space device definitions together. From Scott, Gerald and Jussi's comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum, under control of a white space database. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required by local regulations to query a database with its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not necessarily apply to all under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunistic use of the spectrum by white space devices in the last sentence of the definition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but is not fully occupied by that licensed use at a specific location and time. This spectrum is then assigned allowed by local regulations for use to be used opportunistically as licensed-exempt spectrum under control of a white space database. This way, it is understood that the database does not "assign" white space devices for them to choose from. Gerald _____ From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do these changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White Space". Kind Regards, Scott From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott , "paws@ietf.org" Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of "Protected Entity" and "White Space Devices (WSD)" where the notion of secondary use is included. The secondary status is used in the ITU-R Radio Regulations for a different purpose. In fact, it is possible that a band has already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operation where the two first types of services are not being used. The use of "lower priority opportunistic" service rather than "secondary" service would be preferable to describe white space allocations. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes to the draft based on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the document should accurately explain the subject with aim that a reader can understand the use cases and the subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if something is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is the 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exempt spectrum is Typically referred to as "unlicensed" spectrum. In this document the terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondarylicense-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary useand assigned for licensed use, but is not fully occupied by that primary use licensed use at a specificlocation and time. This spectrum is then assigned by locationlocal regulations for use as licensed-exempt spectrum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' Cc: "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unlicensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As an example, in the ITU-R context, an "unlicensed" band is typically a new band, say in the 300 GHz, for which no request has been made for its use. It is therefore un-allocated to a specific service so far and thus it is an "unlicensed" frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrations can thendecide under what king of regime it will 'assign' this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus "license-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicensed" in the USA. If the qualifier applies to an operation, the operation can be exempt of license by the local administration, thus a "license-exempt" operation. If, however, someone decides to start an RF transmission operation in a licensed band for which he has no license or in a license-exempt band for which he does not meet the requirements such as operating according to the type of operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an "unlicensed" operation. If the qualifier applies to the transmission device, such device may be a "license-exempt" device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id de-facto an "unlicensed" device since it has not passed through the normal certification process. Note that a "license-exempt" device still has to go through a certification process and meet the limits imposed by the local regulator for the "license-exempt" operation in the given frequency band whereas an "unlicensed" device may not pass the certification process since it has not been licensed to operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licensed" operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses. Gerald _____ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs to be careful with the word'unlicensed' which may mean 'illegal' operation of an RF device in many administrations. Gerald _____ From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as 'license-exempt', in most cases the term 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statement: The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald _______________________________________________ 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 ------=_NextPart_000_0035_01CCE64B.CDBE05A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy,

 

I like your suggestions to broaden = it to any bands that are not fully occupied and for any type of devices. = However, white space should be white and not grey:

“White Space (WS)

 Radio = spectrum which is not <delete>fully<delete> occupied at a specific = location and time.”

 

Also, White Space devices should = not be limited to those that need the database to operate, RF sensing or other opportunistic means may be allowed in some = cases:

“White = Space device

A device = which opportunistically uses some part of the white space = spectrum<delete>, under control of a white space database<delete>.  A white = space device can be an access point, base station, a portable device or similar.  <delete>In this context, a<delete> = <insert>A<insert> white space device<delete> is<delete> Insert>may = be<insert> required by local regulations to query a database with its location to = obtain information about available = spectrum.”

 

Gerald

 

 

From: = andy.sago@bt.com [mailto:andy.sago@bt.com]
Sent: Wednesday, 01 = February, 2012 05:34
To: = jussi.kahtava@nokia.com; gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org
Subject: RE: [paws] Use = cases and requirements I-D: sections 1 to 3(Introduction, Conventions and = Terminology, Prior Work)

 

Scott, = All

 <= /o:p>

I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only = why the lower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th = Jan I proposed (= http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with “opportunistic” replacing “secondary” in later sentences in the Introduction. I have = checked and there are no further references to licensing in the document, so we don’t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document – we are defining requirements fora protocol. Keep it simple.

 <= /o:p>

That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  From Scott, = Gerald and Jussi’s comments perhaps we could agree = on:

 <= /o:p>

White Space = (WS)

 <= /font>

Radio = spectrum which is not fully occupied at a specific location and = time.

 

White Space = device

 

A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white = space device is required by local regulations to query a database with its = location to obtain information about available = spectrum.

 <= /o:p>

Regards=

 <= /o:p>

Andy

 <= /o:p>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 = 07:31
To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?

 <= /o:p>

Kind = regards,

Jussi

 <= /o:p>

From: paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of ext Gerald = Chouinard
Sent: 31 January 2012 = 22:33
To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Scott,

 

Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of “white space” as = follows:

 

White = Space

 <= /font>

Radio = spectrum which has been allocated and assigned for licensed use, but is not fully = occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> = by local regulations <delete>for use<delete> <insert>to = be used opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>

 

This way, it is understood that the database does not “assign” white space devices for them to = choose from.

 

Gerald

From: scott.probasco@nokia.com [mailto:scott.proba= sco@nokia.com]
Sent: Tuesday, 31 = January, 2012 15:12
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Hi = Gerald,

 

Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that = we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?

 

I also = corrected "location" to "local" in previous text proposed for "White Space".

 

Kind = Regards,

Scott

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>= , "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior = Work)

 

= Scott,

= Great proposal.  However, I am still a bit nervous about the definitions = of “Protected Entity” and “White Space Devices = (WSD)” where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In fact, = it is possible that a band has already primary and secondary services allotted = to it and that the White Space operation is a tertiary opportunistic operation = where the two first types of services are not being used.  The use of “lower priority opportunistic” service rather than “secondary” service would be preferable to describe white = space allocations.

=  

= Gerald

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of scott.probasco@nokia.com
= Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 =

Hi,

 

I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the = draft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage.

 

I hope this captures the key points of the discussion. Please do reply if something is still missing.

 

Kind Regards,

Scott

 

 

2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio = technologies,

      the database is an entity which contains current = information about

      available spectrum at any given location and other types = of

      information.

 

   Device ID

 

      A unique number for each master device and slave device = that

      identifies the manufacturer, model number and serial = number.

 

<Insert>

   Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given = service area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, = company merger &

      acquisition,  first-come / first-served or by = government allocation

      (e.g., public service).

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the = USA, license-exempt spectrum is

      Typically referred to as "unlicensed" spectrum. = In this document the terms

      license-exempt and unlicensed are used = interchangeably.

 

</Insert>

 

   Location Based Service

 

      An application or device which provides data, information = or

      service to a user based on their = location.

 

   Master Device

 

      A device which queries the WS Database to find out the = available

      operating channels.

 

   Protected Entity

 

      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white space

      devices) for its use</Delete> in a given area and = time.

 

   Protected Contour

 

      The exclusion area for a Protected Entity, held in the = database

      and expressed as a polygon with geospatial points as the = vertices.

 

   Slave Device

 

      A device which uses the spectrum made available by a = master

      device.

 

   TV White Space

 

      TV white space refers specifically to radio spectrum which = has

      been allocated for TV broadcast, but is not occupied by a = TV

      broadcast, or other licensed user (such as a wireless = microphone),

      at a specific location and time.

 

   White Space

 

      Radio spectrum which has been allocated <Delete>for = some primary use</Delete><Insert>and assigned for licensed use</Insert>, but

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>

 

   White Space Device (WSD)

 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</In= sert> user of some part of white space

      spectrum.  A white space device can be an access = point, base

      station, a portable device or similar.  In this = context, a white

      space device is required to query a database with its = location to

      obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" = <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Nancy,

=  

= This is not that simple.  In fact, the qualifiers = “license-exempt” and “unlicensed” can apply to more than one = thing.

=  

= If the qualifier applies to a frequency band, different options exist. As an = example, in the ITU-R context, an “unlicensed” band is typically a = new band, say in the 300 GHz, for which no request has been made for its = use.  It is therefore un-allocated to a specific service so far and thus it is an “unlicensed” frequency band. Once the ITU-R allocates this = band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will ‘assign’ = this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus “license-exempt”such as in the 2.4 GHz ISM band. This is = also called “unlicensed” in the USA.

=  

= If the qualifier applies to an operation, the operation can be exempt of = license by the local administration, thus a “license-exempt” operation. = If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an “unlicensed” operation.

=  

= If the qualifier applies to the transmission device, such device may be a “license-exempt” device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an “unlicensed” device since it has not passed = through the normal certification process.

=  

= Note that a “license-exempt” device still has to go through a certification process and meet the limits imposed by the local regulator = for the “license-exempt” operation in the given frequency band = whereas an “unlicensed” device may not pass the certification = process since it has not been licensed to operation in the country.

=  

= This is why the qualifier “unlicensed” has to be treated with care = and the footnote will need to be crafted very carefully.

=  

= With respect to your second point, if an administration only allows “licensed” operation, the situation will be much simpler to = manage since specific conditions will be attached to these = licenses.

=  

= Gerald

=  

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; = paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 =

Gabor and = Gerald, 

Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use = to indicate that "according to each countries regulatory = requirements"  

How to get = around the fact that some Countries are or will be "licensed only" by = their gov'ts?  Thanks

Nancy

On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:

 

= Gabor,

=  

= I agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word‘unlicensed’ which may mean ‘illegal’ operation of an RF device in many = administrations.

=  

= Gerald

=  

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] =
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 =

These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as ‘license-exempt’, in most = cases the term ‘unlicensed-band’ is used.

 

Therefore, may I suggest that the draft will include the following = statement:

 

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.

 

-          Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 =

All,

 

= Here is my understanding of the terms:

=  

= Licensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).

=  

= Lightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in = Canada) and not big Telcos that would normally work with full licensing through auction = over large service areas.

=  

= License-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for = a specific type of operation. The FCC should be contacted to clarify = it.

=  

= Unlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, this term is used to = mean “license-exempt," see above.

=  

= To my knowledge, the term “unlicensed” is used only in the = USA = to describe a legal operation because the term “license-exempt” has been = used for another specific purpose.

=  

= Since the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I = would suggest the use of ‘licensed’ and = ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in = the USA = instead of the usual ‘license-exempt’.

=  

= Gerald

_______________________________________________
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

------=_NextPart_000_0035_01CCE64B.CDBE05A0-- From andy.sago@bt.com Wed Feb 8 08:38:00 2012 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 D860221F85CC for ; Wed, 8 Feb 2012 08:38:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfuQx-TYGmrC for ; Wed, 8 Feb 2012 08:37:50 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.com [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0D21F84FD for ; Wed, 8 Feb 2012 08:37:48 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 8 Feb 2012 16:37:47 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.109]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Wed, 8 Feb 2012 16:37:47 +0000 From: To: , , , Date: Wed, 8 Feb 2012 16:37:43 +0000 Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) Thread-Index: AQHM4GhgAXLRm0MfH0eU5prccikhbJYnpdQQgAAi1DCAAfm44IAJbP3A Message-ID: <619CDADDCCD2B44380834BE8BF6F71414065604C94@EMV62-UKRD.domain1.systemhost.net> References: <23293D9BB25E0B48A038B78C7D1D0D5C01E6017B@008-AM1MPN1-021.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F714140653B4DF6@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_619CDADDCCD2B44380834BE8BF6F71414065604C94EMV62UKRDdoma_" MIME-Version: 1.0 Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 16:38:01 -0000 --_000_619CDADDCCD2B44380834BE8BF6F71414065604C94EMV62UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gerald Agree, delete "fully" in the definition of WS, since we correctly say "spec= trum" not "band". I'm also OK with your bold revisions to the definition of a WSD, if others = also agree. I was constraining my definition to the context of this PAWS wo= rk where we have a database to control the WSDs, but regulatory requirement= s at any one point in time (or for particular classes of device, perhaps) w= ould decide whether sensing, geolocation database control or both are neede= d. Certainly UK Ofcom has not discarded sensing, according to their public = statements, but it is moving ahead with the use of geolocation databases in= itially. The PAWS protocol will need to allow for the WSDB to signal any re= quirement for sensing to the WSD, so that this capability can be enabled in= the future by individual regulatory administrations as they become comfort= able with this approach. Regards Andy From: Gerald Chouinard [mailto:gerald.chouinard@sympatico.ca] Sent: 08 February 2012 15:21 To: Sago,AJ,Andy,COD R; jussi.kahtava@nokia.com; scott.probasco@nokia.com; = paws@ietf.org Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3(Introdu= ction, Conventions and Terminology, Prior Work) Andy, I like your suggestions to broaden it to any bands that are not fully occup= ied and for any type of devices. However, white space should be white and n= ot grey: "White Space (WS) Radio spectrum which is not fully occupied at a specific l= ocation and time." Also, White Space devices should not be limited to those that need the data= base to operate, RF sensing or other opportunistic means may be allowed in = some cases: "White Space device A device which opportunistically uses some part of the white space spectrum= , under control of a white space database. A white space d= evice can be an access point, base station, a portable device or similar. = In this context, a A white space device is Insert>may be required by local regulation to query= a database with its location to obtain information about available spectru= m." Gerald ________________________________ From: andy.sago@bt.com [mailto:andy.sago@bt.com] Sent: Wednesday, 01 February, 2012 05:34 To: jussi.kahtava@nokia.com; gerald.chouina= rd@sympatico.ca; scott.probasco@nokia= .com; paws@ietf.org Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3(Introdu= ction, Conventions and Terminology, Prior Work) Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV = white spaces, whereas the scope of PAWS is white spaces in general. I would= question not only why the lower-priority service would always be licence-e= xempt, but why the higher priority service would always be licenced. To avo= id this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/= paws/current/msg00576.html) a revision of the Abstract that avoids the term= s licence exempt or unlicensed, or any mention of the regulatory status of = the incumbent services. The Abstract derives from the Introduction and the = text could be aligned to be the same in the Introduction, with "opportunist= ic" replacing "secondary" in later sentences in the Introduction. I have ch= ecked and there are no further references to licensing in the document, so = we don't need the definitions of licence exempt, light licensing or unlicen= sed. This is not a regulatory document - we are defining requirements fora = protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum= use has now got muddled with the potential for opportunistic use. This can= be fixed by taking the white space and white space device definitions toge= ther. From Scott, Gerald and Jussi's comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum= , under control of a white space database. A white space device can be an = access point, base station, a portable device or similar. In this context,= a white space device is required by local regulations to query a database = with its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of jussi.kah= tava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; sc= ott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not= necessarily apply to all under-utilised radio spectrum. Why would the lowe= r priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext G= erald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed by = local regulations for use to be used opportunistica= lly as licensed-exempt spectrum under control of a white space data= base. This way, it is understood that the database does not "assign" white space = devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= "Protected Entity" and "White Space Devices (WSD)" where the notion of sec= ondary use is included. The secondary status is used in the ITU-R Radio Re= gulations for a different purpose. In fact, it is possible that a band has= already primary and secondary services allotted to it and that the White S= pace operation is a tertiary opportunistic operation where the two first ty= pes of services are not being used. The use of "lower priority opportunist= ic" service rather than "secondary" service would be preferable to describe= white space allocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for some primary use<= /Delete>and assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unl= icensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an "unlicensed" band is typically a new ba= nd, say in the 300 GHz, for which no request has been made for its use. It= is therefore un-allocated to a specific service so far and thus it is an "= unlicensed" frequency band. Once the ITU-R allocates this band to one or ma= ny services on a primary or secondary basis, then the administrations can t= hendecide under what king of regime it will 'assign' this band foroperation= . They may decide to allow the use of the band on the basis of licensed ope= ration (with different options to do the assignment: auction, first come/fi= rst served, etc.) or allow operation with an exemption of licenses, thus "l= icense-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicen= sed" in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a "license-exempt" operation. If, h= owever, someone decides to start an RF transmission operation in a licensed= band for which he has no license or in a license-exempt band for which he = does not meet the requirements such as operating according to the type of o= peration for which the band is exempted from a license or he operates outsi= de the technical limits imposed by this license-exempt ruling, his operatio= n is therefore illegal and he is then considered to be running an "unlicens= ed" operation. If the qualifier applies to the transmission device, such device may be a "= license-exempt" device if its operation does not require a specific license= or registration with the local administration such as TV receivers of Wi-F= i devices in the 2.4 GHz ISM band. However, if someone smuggles a device t= hat is not allowed in a country by, for example, buying it on eBay and oper= ates it, this is then an illegal device in the country and id de-facto an "= unlicensed" device since it has not passed through the normal certification= process. Note that a "license-exempt" device still has to go through a certification= process and meet the limits imposed by the local regulator for the "licens= e-exempt" operation in the given frequency band whereas an "unlicensed" dev= ice may not pass the certification process since it has not been licensed t= o operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the = footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licens= ed" operation, the situation will be much simpler to manage since specific = conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word'unlicensed' which may mean 'illegal' operation= of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as 'license-exempt', in most cases the t= erm 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe = a legal operation because the term "license-exempt" has been used for anoth= er specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of 'licensed' and 'license-exempt' with a foo= tnote indicating that the term 'unlicensed' is used in the USA instead of t= he usual 'license-exempt'. Gerald _______________________________________________ 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 --_000_619CDADDCCD2B44380834BE8BF6F71414065604C94EMV62UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gerald

 

Agree, delete “= fully” in the definition of WS, since we correctly say ”spectru= m” not “band”.

=  = ;

I’m also OK with your bold revisions to = the definition of a WSD, if others also agree. I was constraining my defini= tion to the context of this PAWS work where we have a database to control t= he WSDs, but regulatory requirements at any one point in time (or for parti= cular classes of device, perhaps) would decide whether sensing, geolocation= database control or both are needed. Certainly UK Ofcom has not discarded = sensing, according to their public statements, but it is moving ahead with = the use of geolocation databases initially. The PAWS protocol will need to = allow for the WSDB to signal any requirement for sensing to the WSD, so tha= t this capability can be enabled in the future by individual regulatory adm= inistrations as they become comfortable with this approach.

 

Regards=

 

Andy

 

From: Gerald Chouinard [mailto:gerald.= chouinard@sympatico.ca]
Sent: 08 February 2012 15:21
To: Sago,AJ,Andy,COD R; jussi.kahtava@nokia.com; scott.probasco@nokia.com; p= aws@ietf.org
Subject: RE: [paws] Use cases and requirements I-D: = sections 1 to 3(Introduction, Conventions and Terminology, Prior Work)=

 

Andy,

 

I like your suggestions to broaden it to any bands that are not fu= lly occupied and for any type of devices. However, white space should be wh= ite and not grey:

= “White Space (WS)

 Radio spectrum which is not <delete>fully<delete>= occupied at a specific location and time.”

 

Also, White Space devices should not be limited to = those that need the database to operate, RF sensing or other opportunistic = means may be allowed in some cases:

“White Space device

A device which opportunistically uses some = part of the white space spectrum<delete>, under control of a white sp= ace database<delete>.  A white space device can be an access poi= nt, base station, a portable device or similar.  <delete>In this= context, a<delete> <insert>A<insert> white space device&= lt;delete> is<delete> Insert>may be<insert> required by l= ocal regulation to query a database with its location to obtain information= about available spectrum.”

 

Gerald

=  

&nbs= p;

From: andy.sago@bt.com [mailto:andy.sago@bt.com]
Sent: Wednesda= y, 01 February, 2012 05:34
To: jussi.kahtava@nokia.com; gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org
Subject: RE: [paws] Use cases and requireme= nts I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior W= ork)

 

Scott, All

 

I agre= e with Jussi that we have now narrowed the definition to apply to TV white = spaces, whereas the scope of PAWS is white spaces in general. I would quest= ion not only why the lower-priority service would always be licence-exempt,= but why the higher priority service would always be licenced. To avoid thi= s issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/paws/= current/msg00576.html) a revision of the Abstract that avoids the terms= licence exempt or unlicensed, or any mention of the regulatory status of t= he incumbent services. The Abstract derives from the Introduction and the t= ext could be aligned to be the same in the Introduction, with “opport= unistic” replacing “secondary” in later sentences in the = Introduction. I have checked and there are no further references to licensi= ng in the document, so we don’t need the definitions of licence exemp= t, light licensing or unlicensed. This is not a regulatory document –= we are defining requirements fora protocol. Keep it simple.

 

That just leaves t= he definition of white space, where the existing spectrum use has now got m= uddled with the potential for opportunistic use. This can be fixed by takin= g the white space and white space device definitions together.  From S= cott, Gerald and Jussi’s comments perhaps we could agree on:

 

White Space (WS)

 

Radio spectrum which is not fully occupied a= t a specific location and time.

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'> 

White Space device

 

A device which opportunistically uses some part of the white space spe= ctrum, under control of a white space database.  A white space device = can be an access point, base station, a portable device or similar.  I= n this context, a white space device is required by local regulations to qu= ery a database with its location to obtain information about available spec= trum.

 =

Regards

 

Andy

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 = February 2012 07:31
To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org
Subject: Re: [paws] Use cases and requirements = I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work= )

 

That statement is valid for TV White Spaces o= n UHF frequencies but does not necessarily apply to all under-utilised radi= o spectrum. Why would the lower priority service by default be licence-exem= pt?

 

Kind regards,

Jussi

 

Fr= om: paws-bounces@i= etf.org [mailto:p= aws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Se= nt: 31 January 2012 22:33
To: Probasco Scott (Nokia-CIC/Dalla= s); paws@ietf.org
Subject: R= e: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Co= nventions and Terminology, Prior Work)

 

= Scott,

&nbs= p;

Very good improvemen= ts. I would suggest to insert the notion of opportunistic use of the spectr= um by white space devices in the last sentence of the definition of “= white space” as follows:

 

White Space=

 

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'>Radio spectrum which has been allocated and assigned for l= icensed use, but is not fully occupied by that licensed use at a specific l= ocation and time. This spectrum is then <delete>assigned<delete>= ; <insert>allowed<insert> by local regulations <delete>fo= r use<delete> <insert>to be used opportunistically<insert>= ; as licensed-exempt spectrum under control of a white space database.</= Insert>

&n= bsp;

This way, it is un= derstood that the database does not “assign” white space device= s for them to choose from.

 

Ge= rald

From: <= a href=3D"mailto:scott.probasco@nokia.com">scott.probasco@nokia.com [mailto:scott.probasc= o@nokia.com]
Sent: Tuesday, 31 January, 2012 15:12
To:= gerald.chouinard@symp= atico.ca; paws@ietf.org
Subj= ect: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work)<= o:p>

&nb= sp;

Hi Gerald,<= o:p>

 

G= ood to avoid overloading the term "secondary". I have made additi= onal proposed changes to the text below based on your suggestion. "Low= er priority opportunistic service" could indeed by used, but I am gues= sing that we would need some explanation of what that means. Since we now h= ave descriptions of licensed spectrum and license-exempt spectrum, I used t= hese words. Do these changes remove your concerns?

 

=

I also corrected "lo= cation" to "local" in previous text proposed for "White= Space".

 

Kind Regards,

Scott

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.ca= >
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminolog= y, Prior Work)

=  

Scott,

Great proposal.  However, I am still a bit nervous about the de= finitions of “Protected Entity” and “White Space Devices = (WSD)” where the notion of secondary use is included.  The secon= dary status is used in the ITU-R Radio Regulations for a different purpose.=  In fact, it is possible that a band has already primary and secondar= y services allotted to it and that the White Space operation is a tertiary = opportunistic operation where the two first types of services are not being= used.  The use of “lower priority opportunistic” service = rather than “secondary” service would be preferable to describe= white space allocations.

 = ;<= /b>

Gerald

 

=

From: pa= ws-bounces@ietf.org [mailto:pa= ws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:5= 6
To: paws@ietf.org
Subject: Re:= [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conv= entions and Terminology, Prior Work)

 

Hi,

 

= I changed the subject line from " Re: [paws] Disc= ussion on 'license-exempt' vs 'unlicensed'  ". Here I try to prop= ose some changes to the draft based on the email discussion.<= span lang=3DEN-US style=3D'color:black'>

 

Below is a copy of chapter 2.2. Terminol= ogy. I have inserted new terms for 'licensed' and 'license-exempt' and made= changes to the term 'white space'. I have tried to work from the perspecti= ve that the document should accurately explain the subject with aim that a = reader can understand the use cases and the subsequent requirements. No dou= bt we could include much more text on this topic of spectrum allocation, as= signment, licensing and usage.

 =

I hope this captures the key points of the discussion. Please do reply = if something is still missing.

 =

Kind Regards,

Scott

 

 =

2.2.  Terminology<= /p>

 

<= div>

   Database<= /b>

 

<= p class=3DMsoNormal>      In the c= ontext of white space and cognitive radio technologies,

      the databa= se is an entity which contains current information about

      available= spectrum at any given location and other types of

      information.=

 <= b>

=

   Device ID

=

 

      A uniq= ue number for each master device and slave device that

      identifies = the manufacturer, model number and serial number.

 

<Insert>

   Licensed Spectrum

=

 

      Spectrum that i= s acquired by an operator over a given service area

      for a given ti= me period.  This is usually done through auctions,award<= span lang=3DEN-US style=3D'color:black'>

      (beau= ty contest), acquisition from secondary market, company merger &=

<= /div>

     &nb= sp;acquisition,  first-come / first-served or by government allocation=

   &nb= sp;  (e.g., public service).

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'> 

   License-exempt Spectrum

 

      Spectrum that is not ass= igned to any specific user. One example is the 2.4 Ghz ISM band, where RF d= evices

 &nbs= p;    operate without a formal licensing process. In the USA, lic= ense-exempt spectrum is

      Typically referred to as "unlicensed= " spectrum. In this document the terms

      license-exempt and unl= icensed are used interchangeably.

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'> 

</Insert>

 <= /o:p>

&n= bsp;  Location Based Service

<= span lang=3DEN-US style=3D'font-size:10.5pt;font-family:"Calibri","sans-ser= if";color:black'> 

      An application or device which provides d= ata, information or<= o:p>

      service to a user based on their location.

 =

   Master Device

 =

      A de= vice which queries the WS Database to find out the available<= span lang=3DEN-US style=3D'color:black'>

      opera= ting channels.<= /o:p>

&n= bsp;

  = Protected Entity

 

 &nb= sp;    <Insert>A licensed user of spectrum, when the licens= ed spectrum has been assigned as white space spectrum.</Insert> <D= elete>A primary</Delete><Insert>A licensed</Insert> us= er of white space spectrum <Delete>which</Delete> is afforded=

    = ;  protection against interference by <Delete>secondary</Dele= te><Insert>license-exempt white space</Insert> users <Del= ete>(white space<= o:p>

      devices) for its use</Delete> in a given= area and time.=

&= nbsp;

  = ; Protected Contour<= o:p>

 =

 =      The exclusion area for a Protected Entity, held in the = database<= /span>

 =      and expressed as a polygon with geospatial points as th= e vertices.

 = ;<= /b>

   Sl= ave Device

 =

   &nb= sp;  A device which uses the spectrum made available by a master

=

     &n= bsp;device.

 = ;<= /b>

   TV= White Space

&nbs= p;=

   &= nbsp;  TV white space refers specifically to radio spectrum which has<= /span>

   &nbs= p;  been allocated for TV broadcast, but is not occupied by a TV

=

     &n= bsp;broadcast, or other licensed user (such as a wireless microphone),

     &= nbsp;at a specific location and time.

=  

   White Space

=  

      Radio spectrum which has been allocate= d <Delete>for some primary use</Delete><Insert>and assign= ed for licensed use</Insert>, but

      is not fully occupied by t= hat <Delete>primary use</Delete><Insert> licensed use <= ;/Insert> at a specificlocation

=       and time. <Insert>This sp= ectrum is then assigned by <Delete>location</Delete><Insert&= gt;local</Insert> regulations for use as licensed-exempt spectrum und= er control of a white space database.</Insert>

 

   White Space Device (WSD)<= b>

=

 

     A device whic= h is a <Delete>secondary</Delete><Insert>license-exempt&l= t;/Insert> user of some part of white space

      spectrum.  A w= hite space device can be an access point, base

      station, a portable= device or similar.  In this context, a white

      space device i= s required to query a database with its location to

      obtain informa= tion about available spectrum.

 =

 

=  

From: = ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07:30 -05= 00
To: 'Nancy Bravin' <nbrav= in@earthlink.net>
Cc: "paws= @ietf.org" <paws@ietf.org&= gt;
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'=

 <= b>

=

Nancy,

 

This is not that simple.  In fact, the qualifiers “license-exem= pt” and “unlicensed” can apply to more than one thing.<= /p>

 

= If the qualifier applies to a frequency band, different o= ptions exist. As an example, in the ITU-R context, an “unlicensedR= 21; band is typically a new band, say in the 300 GHz, for which no request = has been made for its use.  It is therefore un-allocated to a specific= service so far and thus it is an “unlicensed” frequency band. = Once the ITU-R allocates this band to one or many services on a primary or = secondary basis, then the administrations can thendecide under what king of= regime it will ‘assign’ this band foroperation. They may decid= e to allow the use of the band on the basis of licensed operation (with dif= ferent options to do the assignment: auction, first come/first served, etc.= ) or allow operation with an exemption of licenses, thus “license-exe= mpt”such as in the 2.4 GHz ISM band. This is also called “unlic= ensed” in the USA.

 =

If the qualifier applies to an= operation, the operation can be exempt of license by the local administrat= ion, thus a “license-exempt” operation. If, however, someone de= cides to start an RF transmission operation in a licensed band for which he= has no license or in a license-exempt band for which he does not meet the = requirements such as operating according to the type of operation for which= the band is exempted from a license or he operates outside the technical l= imits imposed by this license-exempt ruling, his operation is therefore ill= egal and he is then considered to be running an “unlicensed” op= eration.<= /span>

 

If the qualifier applies to the transmission= device, such device may be a “license-exempt” device if its op= eration does not require a specific license or registration with the local = administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM ban= d.  However, if someone smuggles a device that is not allowed in a cou= ntry by, for example, buying it on eBay and operates it, this is then an il= legal device in the country and id de-facto an “unlicensed” dev= ice since it has not passed through the normal certification process.

=

 

= Note that a “license-exempt” device still has to= go through a certification process and meet the limits imposed by the loca= l regulator for the “license-exempt” operation in the given fre= quency band whereas an “unlicensed” device may not pass the cer= tification process since it has not been licensed to operation in the count= ry.

 

This is why the qualifier “unlicensed” = has to be treated with care and the footnote will need to be crafted very c= arefully.=

 <= span lang=3DEN-US style=3D'color:black'>

With respect to your second point, if an adm= inistration only allows “licensed” operation, the situation wil= l be much simpler to manage since specific conditions will be attached to t= hese licenses.<= /o:p>

 

Gerald

 

From: Nancy Bravin [= mailto:nbravin@earthlink.net]
Sent: Tuesday, 31 January, 2012 06:33=
To: Gerald Chouinard
Cc: Ga= bor.Bajko@nokia.com; paws@ietf.org=
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

&nb= sp;

Gabor and Gerald, 

Since we are= dealing on a global basis, can there a footnote to "unlicensed" = we can use to indicate that "according to each countries regulatory re= quirements"  

How to get around the fac= t that some Countries are or will be "licensed only" by their gov= 'ts?  Thanks

= Nancy

=

= On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote:<= /p>

 

Gabor,

 <= /o:p>

I agree with you= r proposal.  Thisseems to be reasonable.  However one needs to be= careful with the word‘unlicensed’ which may mean ‘illega= l’ operation of an RF device in many administrations.

 

Gerald

 =

=

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]
Sent: Mond= ay, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.ca; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs= 'unlicensed'

 

These look to be very precise definitions, however in eve= ryday use I rarely hear people referring to ISM band as ‘license-exem= pt’, in most cases the term ‘unlicensed-band’ is used. =

 

Therefore, may I suggest that the draft will i= nclude the following statement:

 

The terms unl= icensed and license-exempt spectrum are used in this document interchangeab= ly and refer to a spectrum in which no formal licensing process is needed f= or RF devices to operate in, such as the ISM band.

 

- = ;         Gabor

 

From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org]= On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 = PM
To: paws@ietf.org
Subject: [p= aws] Discussion on 'license-exempt' vs 'unlicensed'

 

All,<= span lang=3DEN-US style=3D'color:black'>

 

Here is my understanding of the terms:

 

Licensed= : Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of th= e Telcos), beauty contest, first-come / first-served or by government alloc= ation (e.g., public service).

&= nbsp;

Lightly licensed: Special= case where thefrequency allocation is done through first-come / first-serv= ed process for a given time frame over a relatively limited service area. T= he annual license fee is usually small to facilitate the deployment of a se= rvice that would not normally be economically attractive.  Small local= operators would be interested by this (e.g., rural broadband in Canada) an= d not big Telcos that would normally work with full licensing through aucti= on over large service areas.

&n= bsp;

License-exempt: Operation = of RF devices in a frequency band where no formal licensing process is need= ed such as in the 2.4 GHz ISM band. In the USA, this term is used for a spe= cific type of operation. The FCC should be contacted to clarify it.<= /b>

 

Unlicensed: Illegal operation of an RF device that can transmi= t in a frequency band without a duly issued license.  In the USA, this= term is used to mean “license-exempt," see above.=

 

To my knowledge, the term “unlicensed” is used only in t= he USA to describe a legal operation because the term “license-exempt= ” has been used for another specific purpose.

 

Sin= ce the PAWS addresses the interface to the database for the international m= arket, it should rely on the definition of the terms recognized by the ITU-= R. I would suggest the use of ‘licensed’ and ‘license-exe= mpt’ with a footnote indicating that the term ‘unlicensed’= ; is used in the USA instead of the usual ‘license-exempt’.

 

<= b>Gerald

___________________= ____________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paws

 

_______________________________________________ paws = mailing list paws@ietf.org https://www.ietf.org/mailman/li= stinfo/paws=

= --_000_619CDADDCCD2B44380834BE8BF6F71414065604C94EMV62UKRDdoma_-- From peter@spectrumbridge.com Wed Feb 8 09:01:29 2012 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 BC45B21F8780 for ; Wed, 8 Feb 2012 09:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=-1.757, BAYES_40=-0.185, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxyCfCgBL+4Y for ; Wed, 8 Feb 2012 09:01:26 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id E9BE321F877C for ; Wed, 8 Feb 2012 09:01:25 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 8 Feb 2012 12:02:23 -0500 From: Peter Stanforth To: Gerald Chouinard , "andy.sago@bt.com" , "nbravin@earthlink.net" , "paws@ietf.org" Date: Wed, 8 Feb 2012 12:01:19 -0500 Thread-Topic: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: Aczmg2zHZybsGYEAQYyLgbjstKToqw== 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.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB5812BB1F987peterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 17:01:29 -0000 --_000_CB5812BB1F987peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable There is no reason to assume that use of white space is by licensed exempt = or unlicensed devices. This comes back to an earlier argument I made about = what constitutes licensed and unlicensed? Again there is no reason that a license exempt or unlicensed device should = get access to spectrum for "free" any more that a licensed device has to "p= ay" for spectrum access. The concept of a primary user, who has priority over a secondary user has n= o relevance to free or paid access. The rationale for white space is that the spectrum is shared and that someo= ne has primary, preferred or priority access and the database ensures that = those rights/requirements are met by anyone who uses the spectrum on a seco= ndary basis. I would go further and say that the secondary access could be = deterministic or opportunistic. There is no reason to require one or the ot= her, and an argument can be made for both. In a band occupied by a public s= afety user there may be no choice but to have opportunistic access but in o= ther bands a primary user may be willing to commit to specific availability= if their own use is deterministic. Peter S. From: Gerald Chouinard > Date: Wed, 8 Feb 2012 10:20:52 -0500 To: "andy.sago@bt.com" >, "nbravin@earthlink.net" >, "paws@ietf.org" > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Andy, To resolve Nancy=92s concern, a new definition could be added for: TVWS White Space devices: White Space devices that operate in the TV bands. This would complement the definition of White Space devices and make it mor= e specific. I am having second thoughts about yoursuggestion to remove the concept of c= lasses of devices from the White Spacedevices. The opportunistic use of the= RF spectrum assumes that these devices operate while protecting existing o= peration in the band. There is automatically assumes the existence of prim= ary users of the band that have priority. Such primary users would most lik= ely be licensed to use the band and it is only the portions that happen to = be unused that will be accessible to the White Space devices. The latter a= re unlikely to be licensed to only use the =91crumbs=92. Removing the conce= pt of license-exempt could put these new devices at the same level of prior= ity as the primary devices and then why would they need to protect these = =91primary=92 licensed devices. This would be similar to the situation in the 2.4 GHz where a database is n= ot needed to protect other devices. As is well understood, the databases ar= e there to protect primary and possibly secondary licensed devices from the= new opportunistic devices, not opportunistic devices among themselves. The= latter case would be covered by other means such as adatabase to provide c= oexistence and this is, I believe, beyond the scope ofPAWS. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Wednesday, 01 February, 2012 09:58 To: nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Nancy, all Good questions. I=92m not proposing to remove references to TVWS, they are = entirely appropriate within the use cases since it is the TV bands we are s= tudying as first candidate for opportunistic access, but the charter says w= e are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary informa= tion in this PAWS requirements I-D to enable the PAWS protocol I-D to be de= veloped. I don=92t think it=92s our job to explain different regulatory reg= imes or applications (beyond use cases) in this document, ITU and others do= this very well, and regulators tend to be well coordinated or play =91foll= ow my leader=92. Thanks for pointing out the reference to licence-exempt that I had missed i= n 4.4 - I think the meaning would be just the same with =91in a license-ex= empt TVWS environment=92 deleted from that sentence. That would be my sugge= stion. Regards Andy From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: 01 February 2012 14:48 To: Sago,AJ,Andy,COD R Cc: paws@ietf.org Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Intro= duction, Conventions and Terminology, Prior Work) Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6= =85so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain ho= w the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could change, = but, why not give the information on both for countries to understand fully what it's choices are? Thanks Andy, just some early morning thoughts=85Sincerely, Nancy Begin forwarded message: From: Nancy Bravin > Date: February 1, 2012 6:35:09 AM PST To: Andy Sago > Cc: >, >, >, > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Andy, All In section 4.4, license exempt is also mentioned as well. I am conflicted in a global sense when emerging countries, or countries wit= h very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby join = the existing DB companies, or will they do their own thing leaving holes in what one hopes will be an interoperable global protocol th= at deals with TVWS, and/or White spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, > > wrote: Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV = white spaces, whereas the scope of PAWS is white spaces in general. I would= question not only why the lower-priority service would always be licence-e= xempt, but why the higher priority service would always be licenced. To avo= id this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/= paws/current/msg00576.html) a revision of the Abstract that avoids the term= s licence exempt or unlicensed, or any mention of the regulatory status of = the incumbent services. The Abstract derives from the Introduction and the = text could be aligned to be the same in the Introduction, with =93opportuni= stic=94 replacing =93secondary=94 in later sentences in the Introduction. I= have checked and there are no further references to licensing in the docum= ent, so we don=92t need the definitions of licence exempt, light licensing = or unlicensed. This is not a regulatory document =96 we are defining requir= ements fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum= use has now got muddled with the potential for opportunistic use. This can= be fixed by taking the white space and white space device definitions toge= ther. From Scott, Gerald and Jussi=92s comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum= , under control of a white space database. A white space device can be an = access point, base station, a portable device or similar. In this context,= a white spacedevice is required by local regulations to query a database w= ith its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of jussi= .kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; sc= ott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not= necessarily apply to all under-utilised radio spectrum. Why would the lowe= r priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext G= erald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of =93white space=94 as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed byl= ocal regulations for use to be used opportunistical= ly as licensed-exempt spectrum under control of a white space datab= ase. This way, it is understood that the database does not =93assign=94 white sp= ace devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notio= n of secondary use is included. The secondary status is used in the ITU-R = Radio Regulations for a different purpose. In fact, it is possible that a = band has already primary and secondary services allotted to it and that the= White Space operation is a tertiary opportunistic operationwhere the two f= irst types of services are not being used. The use of =93lower priority op= portunistic=94 service rather than =93secondary=94 service would be prefera= ble to describe white spaceallocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for someprimary useand assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers =93license-exempt=94 and = =93unlicensed=94 can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an =93unlicensed=94 band is typically a ne= w band, say in the 300 GHz, for which no request has been made for its use.= It is therefore un-allocated to a specific service so far and thus it is = an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to o= ne or many services on a primary or secondary basis, then the administratio= ns can thendecide under what king of regime it will =91assign=92 this band = foroperation. They may decide to allow the use of the band on the basis of = licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licen= ses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also= called =93unlicensed=94 in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a =93license-exempt=94 operation. I= f, however, someone decides to start an RF transmission operation in a lice= nsed band for which he has no license or in a license-exempt band for which= he does not meet the requirements such as operating according to the type = of operation for which the band is exempted from a license or he operates o= utside the technical limits imposed by this license-exempt ruling, his oper= ation is therefore illegal and he is then considered to be running an =93un= licensed=94 operation. If the qualifier applies to the transmission device, such device may be a = =93license-exempt=94 device if its operation does not require a specific li= cense or registration with the local administration such as TV receivers of= Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a dev= ice that is not allowed in a country by, for example, buying it on eBay and= operates it, this is then an illegal device in the country and id de-facto= an =93unlicensed=94 device since it has not passed through the normal cert= ification process. Note that a =93license-exempt=94 device still has to go through a certifica= tion process and meet the limits imposed by the local regulator for the =93= license-exempt=94 operation in the given frequency band whereas an =93unlic= ensed=94 device may not pass the certification process since it has not bee= n licensed to operation in the country. This is why the qualifier =93unlicensed=94 has to be treated with care and = the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows =93lice= nsed=94 operation, the situation will be much simpler to manage since speci= fic conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word=91unlicensed=92 which may mean =91illegal=92 o= peration of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as =91license-exempt=92, in most cases t= he term =91unlicensed-band=92 is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos thatwould normally work with full lice= nsing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ 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 --_000_CB5812BB1F987peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
There is no reason to assume th= at use of white space is by licensed exempt or unlicensed devices. This com= es back to an earlier argument I made about what constitutes licensed and u= nlicensed?
Again there is no reason that a license exempt or unli= censed device should get access to spectrum for "free" any more t= hat a licensed device has to "pay" for spectrum access.
The concept of a primary user, who has priority over a secondary user has = no relevance to free or paid access. 
The rationale for whit= e space is that the spectrum is shared and that someone has primary, prefer= red or priority access and the database ensures that those rights/requireme= nts are met by anyone who uses the spectrum on a secondary basis. I would g= o further and say that the secondary access could be deterministic or oppor= tunistic. There is no reason to require one or the other, and an argument c= an be made for both. In a band occupied by a public safety user there may b= e no choice but to have opportunistic access but in other bands a primary u= ser may be willing to commit to specific availability if their own use is d= eterministic. 

Peter S.

<= span id=3D"OLK_SRC_BODY_SECTION">
From: Gerald Chouinard <gerald.chouinard@sympatico.ca= >
Date: Wed, 8 Feb 2012 = 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction,= Conventions and Terminology, Prior Work)

Andy,

 

To resolve Nancy=92s concern, a new definitio= n could be added for:

 

TVWS White Space devices: White Space devices that operate in the TV bands.

 =

This would complement the definition o= f White Space devices and make it more specific.

=

 

I am having second thoughts about your= suggestion to remove the concept of classes of devices from the White Space= devices. The opportunistic use of the RF spectrum assumes that these device= s operate while protecting existing operation in the band.  There is automatically assumes the existence of primary users of the band that have priority. Such primary users would most likely be licensed to use the band = and it is only the portions that happen to be unused that will be accessible to= the White Space devices.  The latter are unlikely to be licensed to only u= se the =91crumbs=92. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices and = then why would they need to protect these =91primary=92 licensed devices.

 

This would be similar to the situation= in the 2.4 GHz where a database is not needed to protect other devices. As is = well understood, the databases are there to protect primary and possibly seconda= ry licensed devices from the new opportunistic devices, not opportunistic devi= ces among themselves. The latter case would be covered by other means such as a= database to provide coexistence and this is, I believe, beyond the scope of= PAWS.

 

Gerald

 

<= /div>

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]= On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology= , Prior Work)

 

Nancy, all

 

Good questions. I=92m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are studying a= s first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your other questions, IMO our aim should be to provide all the necessary information i= n this PAWS requirements I-D to enable the PAWS protocol I-D to be developed.= I don=92t think it=92s our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this ve= ry well, and regulators tend to be well coordinated or play =91follow my leader=92.

 

Thanks for pointing out the reference to licence-exempt that I had missed in 4.4 -  I thin= k the meaning would be just the same with =91in a license-exempt TVWS environment=92 deleted from that sentence. That would be my suggestion.

 

R= egards

 

Andy

 

From: Nanc= y Bravin [mailto:nbravin@earthlink.net]=
Sent: 01 February 2012 = 14:48
To: Sago,AJ,Andy,CO= D R
Cc: paws@ietf.org
Su= bject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminolog= y, Prior Work)

=  

Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6=85so if you propose to remove any reference to TVWS it will affect

the document as a whole, and information that seems necessary to explain how the DB and protocol interacts with TVWS devices an= d

the methods of doing so. One can envision that current rules could change, but, why not give the information on both for countries= to understand fully

what it's choices are? 

 <= /font>

Thanks Andy, jus= t some early morning thoughts=85Sincerely, Nancy

 

Begin forwarded message:

=

=  

From: Nancy Bravin <nbravi= n@earthlink.net>

Date: = February 1, 2012 6:35:09 AM PST

To: Andy Sago <andy.sago@bt.c= om>

Cc: <jussi.kahtava@nok= ia.com>, <gerald.chouinard@sympa= tico.ca>, <scott.probasco@nokia.com>, <paws@ietf.org>

<= b>Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

=  

Hi= Andy, All

 

In section 4.4, license exempt is also mentioned as well. 

<= font size=3D"3" face=3D"Times New Roman">I am conflicted in a global sense when emerging countries, or countries with very different types of gov't want to implemen= t

the protocol, will they have enough information to do so? and thereby join the existing DB companies, or will they do their own t= hing

leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/or White spaces in general?

 

Thanks, just a thought.

<= /div>

=  

SIncerely, Nancy

&= nbsp;

 

On Feb 1, 2012, at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> wrote:

&= nbsp;

Scott, All

 

I agree with = Jussi that we have now narrowed the definition to apply to TV white spaces, where= as the scope of PAWS is white spaces in general. I would question not only why= the lower-priority service would always be licence-exempt, but why the higher p= riority service would always be licenced. To avoid this issue on 27th Jan I propose= d (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or unlicens= ed, or any mention of the regulatory status of the incumbent services. The Abst= ract derives from the Introduction and the text could be aligned to be the same = in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it simple.

 

That just leaves the definition of white space, where the existing spectrum use has now got mudd= led with the potential for opportunistic use. This can be fixed by taking the w= hite space and white space device definitions together.  From Scott, Gerald= and Jussi=92s comments perhaps we could agree on:

 

White Space (WS)

 

Radio spectrum which is not fully occupied at a specific location and time.

 

White Space device=

 

A device which opportunistically uses some part of the white space spectrum, under control= of a white space database.  A white space device can be an access point, = base station, a portable device or similar.  In this context, a white space= device is required by local regulations to query a database with its locati= on to obtain information about available spectrum.

 =

Regards

 

Andy

=

 

=

<= font size=3D"2" face=3D"Tahoma">From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: = gerald.chouinard@sympatico= .ca; scott.probasco@nokia.com; paws@ietf= .org
Subject: Re: [paws] Use cases and require= ments I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work= )

 =

That statement is valid for TV White Spaces on UHF frequencies but does not necessarily apply= to all under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt?

 

Kind regards,

Jussi

 

<= font size=3D"2" face=3D"Tahoma">From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext = Gerald Chouinard
Sent: 31 January 2012 22:33
To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work= )

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] 
Sen= t: Tuesday, 31= January, 2012 15:12
To:<= span class=3D"apple-converted-space"> gerald.chouinard@sympatico.ca; paws@iet= f.org
Subject: Re: [paws] Use cases and requir= ements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work= )

=

 

= Hi Gerald,

 

Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descripti= ons of licensed spectrum and license-exempt spectrum, I used these words. Do th= ese changes remove your concerns?=

 

I also corrected "location" to "local" in previous text proposed for "White Space".

 

Kind Regards,

Scott<= /span>

 

<= font size=3D"2" color=3D"black" face=3D"Calibri">From: ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@no= kia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

&nbs= p;

=

Scott,

Great proposal.  However, I am still a bit nervous about the definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary status i= s used in the ITU-R Radio Regulations for a different purpose.  In fact,= it is possible that a band has already primary and secondary services allotted= to it and that the White Space operation is a tertiary opportunistic operation= where the two first types of services are not being used.  The use of =93lower priority opportunistic=94 service rather than =93secondary=94 service would be preferable to describe white spaceallocati= ons.

<= span style=3D"font-size:10.0pt;font-family:Arial;color:navy;font-weight:bol= d"> 

Gerald

=

 

<= span style=3D"font-size:12.0pt;color:black; font-weight:bold">

From: <= /span>paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 <= /b>

Hi,<= /span>

 

I changed the subject line from " Re: [paws] Discussion on 'license-exem= pt' vs 'unlicensed'  ". Here I try to propose some changes to the dra= ft based on the email discussion.<= /o:p>

 

Belo= w is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licen= sed' and 'license-exempt' and made changes to the term 'white space'. I have tri= ed to work from the perspective that the document should accurately explain th= e subject with aim that a reader can understand the use cases and the subsequ= ent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage.

&nbs= p;

=

I hope this captures the key points of the discussion. Please do reply if something is still missing.

 

Kind Regards,

=

Scott

 

&nbs= p;

=

2.2.  Terminology<= /p>

 

=    Database

=

 <= /o:p>

      In the context of white space and cognitive radio technologies= ,

<= div>

      the database is an entity which contains current information a= bout

      available spectrum at any given location and other types of

=

      information.=

 

   Device ID

 =

      A unique number for each master device and slave device that

      identifies the manufacturer, model number and serial number.

 

<Insert>

&nbs= p;  Licensed Spectrum<= /p>

 

=       Spectrum that is acquired by an operator over a given service = area

      for a given time period.  This is usually done through auctions,award

=

      (beauty contest), acquisition from secondary market, company merger &

      acquisition,  first-come / first-served or by government allocation

      (e.g., public service).=

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One exampl= e is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the USA, license-exempt sp= ectrum is

      Typically referred to as "unlicensed" spectrum. In t= his document the terms=

      license-exempt and unlicensed are used interchangeably.=

 

</Insert>

 

   Location Based Service

 

=       An application or device which provides data, information or

      service to a user based on their location.

&nbs= p;

=

  Master Device

 

      A device which queries the WS Database to find out the availab= le

=

      operating channels.

 

&nbs= p;  Protected Entity

 

      <Insert>A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A licensed</Insert&g= t; user of white space spectrum <Delete>which</Delete> is afforded=

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white space

&nbs= p;     devices) for its use</Delete> in a given area and time.<= /span>

 

   Protected Contour<= /p>

 

=       The exclusion area for a Protected Entity, held in the databas= e

<= div>

      and expressed as a polygon with geospatial points as the verti= ces.

 

   Slave Device

 

      A device which uses the spectrum made available by a master

=

      device.

 

   TV White Space

=

 =

      TV white space refers specifically to radio spectrum which has=

      been allocated for TV broadcast, but is not occupied by a TV

      broadcast, or other licensed user (such as a wireless micropho= ne),

      at a specific location and time.

 

   White Space

 

      Radio spectrum which has been allocated <Delete>for some= primary use</Delete><Insert>and assigned for licensed use</Insert>, but

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> reg= ulations for use as licensed-exempt spectrum under control of a white space database.</Insert><= /span>

 

   White Space Device (WSD)<= /span>

 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</Inse= rt> user of some part of white space

      spectrum.  A white space device can be an access point, b= ase

      station, a portable device or similar.  In this context, = a white

      space device is required to query a database with its location= to

      obtain information about available spectrum.=

=  

 

 <= span lang=3D"EN-GB">

<= font size=3D"2" color=3D"black" face=3D"Calibri">From: ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@ear= thlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

<= p class=3D"MsoNormal">=  

<= /div>

Nancy,<= /o:p>

 <= o:p>

This is not that simple.  In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to more than one thing.

 

= If the qualifier applies to a frequency band, different options exist. As an examp= le, in the ITU-R context, an =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its use.  I= t is therefore un-allocated to a specific service so far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrati= ons can thendecide under what king of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licenses, = thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in the <= /span>USA.

 

If the qualifier applies to an operation, the operation can be exempt of license b= y the local administration, thus a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a license= d band for which he has no license or in a license-exempt band for which he d= oes not meet the requirements such as operating according to the type of operat= ion for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an =93unlicensed=94 operation.

 

If the qualifier applies to the transmission device, such device may be a =93license-exempt=94 device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someo= ne smuggles a device that is not allowed in a country by, for example, buying = it on eBay and operates it, this is then an illegal device in the country and = id de-facto an =93unlicensed=94 device since it has not passed through the normal certification process.

 <= o:p>

Note that a =93license-exempt=94 device still has to go through a certification process and meet the limits imposed by the local regulator fo= r the =93license-exempt=94 operation in the given frequency band whereas an =93unlicensed=94 device may not pass the certification process since it has not been licensed to operation in the country.

 

This is why the qualifier =93unlicensed=94 has to be treated with care and the footnote will need to be crafted very carefully.

 

With respect to your second point, if an administration only allows =93licensed=94 operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses.=

 

Gerald

 = ;

From: Nancy Bravin [mailto:nbravin@earth= link.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Gabor and G= erald, 

Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements&quo= t;  

How to get around the fact that some Countries are or will be "licensed only" by their gov'ts?  Thanks

Nancy

On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote:



=

Gabor,=

 

I agree with your proposal.  Thisseems to be reasonable.  However one nee= ds to be careful with the word=91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many administrations.

 

Gerald=

&= nbsp;

=

From: <= /span>Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.<= o:p>

 

Therefore, may I suggest that the draft will include the following statement:

=  

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band.

 

<= font size=3D"3" color=3D"black" face=3D"Calibri">-   &= nbsp;     &n= bsp;Gabor

 

<= font size=3D"2" color=3D"black" face=3D"Tahoma">From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

A= ll,

=

<= span style=3D"font-size:10.0pt;font-family:Arial;color:black;font-weight:bo= ld"> 

Here is my understanding of the terms:<= /o:p>

 <= o:p>

Licensed: Spectrum that is acquired by an operator over a given service area for a gi= ven time period.  This is usually done through auctions (think of the Telc= os), beauty contest, first-come / first-served or by government allocation (e.g.= , public service).

 

Lightly licensed: Special case where thefrequency allocation is done through first-= come / first-served process for a given time frame over a relatively limited ser= vice area. The annual license fee is usually small to facilitate the deployment = of a service that would not normally be economically attractive.  Small loc= al operators would be interested by this (e.g., rural broadband in Canada) and not big Te= lcos thatwould normally work with full licensing through auction over large= service areas.

 

License-exempt: Operation of RF devices in a frequency band where no formal licensing proce= ss is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it.

 =

U= nlicensed: Illegal operation of an RF device that can transmit in a frequency band wit= hout a duly issued license.  In the&n= bsp;USA, this term is used to mean =93license-exempt," see above.

<= font size=3D"2" color=3D"navy" face=3D"Arial"> <= span lang=3D"EN-GB">

To my knowledge, the term =93unlicensed=94 is used only in the USA to describe a legal operation because the term =93license-exempt=94 has been used for another specific purpose.

=

 

<= /div>

Since the PAWS addresses the interface to the database for the international mark= et, it should rely on the definition of the terms recognized by the ITU-R. I wo= uld suggest the use of =91licensed=92 and =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the = USA instead of the usual =91license-exempt=92.

 

Gerald=

_______________________________________________
paws mailing list
paws@ietf.org
= https://www.ietf.org= /mailman/listinfo/paws

 

<= font size=3D"2" color=3D"black" face=3D"Calibri">___________________= ____________________________ paws mailing list paws@ietf.org h= ttps://www.ietf.org/mailman/listinfo/paws

<= font size=3D"4" face=3D"Helvetica">_____________________________________________= __
paws mailing list
paws@ietf.org
= https://www.ietf.org= /mailman/listinfo/paws

 

 

=
--_000_CB5812BB1F987peterspectrumbridgecom_-- From peter@spectrumbridge.com Wed Feb 8 09:03:52 2012 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 C6ED021F8766 for ; Wed, 8 Feb 2012 09:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.572 X-Spam-Level: X-Spam-Status: No, score=-0.572 tagged_above=-999 required=5 tests=[AWL=-1.588, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIYhH8tPk6jk for ; Wed, 8 Feb 2012 09:03:50 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8F45521F8698 for ; Wed, 8 Feb 2012 09:03:49 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 8 Feb 2012 12:04:47 -0500 From: Peter Stanforth To: Gerald Chouinard , "andy.sago@bt.com" , "jussi.kahtava@nokia.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Date: Wed, 8 Feb 2012 12:03:45 -0500 Thread-Topic: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) Thread-Index: Aczmg8KhOV3465alQ5C89yZ3F25Jfg== 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.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB5814971F99Bpeterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 17:03:53 -0000 --_000_CB5814971F99Bpeterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable White Space is by definition grey. Specifically if we talk about TV White S= pace. The current US database ensures that the secondary user cannot interf= ere with the primary user. There is no guarantee of reciprocity. Channel av= ailability does not equate to channel usability. Sensing is a non issue. The whole purpose of PAWS is managing access with a= database. There is no reason to restrict devices from sensing but if the d= evice is not under the control of a database then it is outside the scope o= f PAWS. Peter S. From: Gerald Chouinard > Date: Wed, 8 Feb 2012 10:20:52 -0500 To: "andy.sago@bt.com" >, "jussi.kahtava@nokia.com"= >, "scott.probasco= @nokia.com" >, "paws@ietf.org" > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3(Introdu= ction, Conventions and Terminology, Prior Work) Andy, I like your suggestions to broaden it to any bands that are not fully occup= ied and for any type of devices. However,white space should be white and no= t grey: =93White Space (WS) Radio spectrum which is not fully occupied at a specific l= ocation and time.=94 Also, White Space devices should not be limited to those that need the data= base to operate, RF sensing or other opportunistic means may be allowed in = some cases: =93White Space device A device which opportunistically uses some part of the white space spectrum= ,under control of a white space database. A white space de= vice can be an access point, base station, a portable device or similar. <= delete>In this context, a A white space device is Insert>may be required by local regulations to query= a database with its location to obtain information about available spectru= m.=94 Gerald ________________________________ From: andy.sago@bt.com [mailto:andy.sago@bt.com] Sent: Wednesday, 01 February, 2012 05:34 To: jussi.kahtava@nokia.com; gerald.chouina= rd@sympatico.ca; scott.probasco@nokia= .com; paws@ietf.org Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3(Introdu= ction, Conventions and Terminology, Prior Work) Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV = white spaces, whereas the scope of PAWS is white spaces in general. I would= question not only why the lower-priority service would always be licence-e= xempt, but why the higher priority service would always be licenced. To avo= id this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/= paws/current/msg00576.html) a revision of the Abstract that avoids the term= s licence exempt or unlicensed, or any mention of the regulatory status of = the incumbent services. The Abstract derives from the Introduction and the = text could be aligned to be the same in the Introduction, with =93opportuni= stic=94 replacing =93secondary=94 in later sentences in the Introduction. I= have checked and there are no further references to licensing in the docum= ent, so we don=92t need the definitions of licence exempt, light licensing = or unlicensed. This is not a regulatory document =96 we are defining requir= ements fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum= use has now got muddled with the potential for opportunistic use. This can= be fixed by taking the white space and white space device definitions toge= ther. From Scott, Gerald and Jussi=92s comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum= , under control of a white space database. A white space device can be an = access point, base station, a portable device or similar. In this context,= a white spacedevice is required by local regulations to query a database w= ith its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of jussi.kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; sc= ott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not= necessarily apply to all under-utilised radio spectrum. Why would the lowe= r priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org]On Behalf Of ext Ge= rald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of =93white space=94 as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed byl= ocal regulations for use to be used opportunistical= ly as licensed-exempt spectrum under control of a white space datab= ase. This way, it is understood that the database does not =93assign=94 white sp= ace devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notio= n of secondary use is included. The secondary status is used in the ITU-R = Radio Regulations for a different purpose. In fact, it is possible that a = band has already primary and secondary services allotted to it and that the= White Space operation is a tertiary opportunistic operation where the two = first types of services are not being used. The use of =93lower priority o= pportunistic=94 service rather than =93secondary=94 service would be prefer= able to describe white spaceallocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for someprimary useand assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers =93license-exempt=94 and = =93unlicensed=94 can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an =93unlicensed=94 band is typically a ne= w band, say in the 300 GHz, for which no request has been made for its use.= It is therefore un-allocated to a specific service so far and thus it is = an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to o= ne or many services on a primary or secondary basis, then the administratio= ns can thendecide under what king of regime it will =91assign=92 this band = foroperation. They may decide to allow the use of the band on the basis of = licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licen= ses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also= called =93unlicensed=94 in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a =93license-exempt=94 operation. I= f, however, someone decides to start an RF transmission operation in a lice= nsed band for which he has no license or in a license-exempt band for which= he does not meet the requirements such as operating according to the type = of operation for which the band is exempted from a license or he operates o= utside the technical limits imposed by this license-exempt ruling, his oper= ation is therefore illegal and he is then considered to be running an =93un= licensed=94 operation. If the qualifier applies to the transmission device, such device may be a = =93license-exempt=94 device if its operation does not require a specific li= cense or registration with the local administration such as TV receivers of= Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a dev= ice that is not allowed in a country by, for example, buying it on eBay and= operates it, this is then an illegal device in the country and id de-facto= an =93unlicensed=94 device since it has not passed through the normal cert= ification process. Note that a =93license-exempt=94 device still has to go through a certifica= tion process and meet the limits imposed by the local regulator for the =93= license-exempt=94 operation in the given frequency band whereas an =93unlic= ensed=94 device may not pass the certification process since it has not bee= n licensed to operation in the country. This is why the qualifier =93unlicensed=94 has to be treated with care and = the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows =93lice= nsed=94 operation, the situation will be much simpler to manage since speci= fic conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word=91unlicensed=92 which may mean =91illegal=92 o= peration of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as =91license-exempt=92, in most cases t= he term =91unlicensed-band=92 is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos that would normally work with full lic= ensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I would suggest the use of =91licensed=92 and =91license-exempt=92 wi= th a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. Gerald _______________________________________________ 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 --_000_CB5814971F99Bpeterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
White Space is by definition gr= ey. Specifically if we talk about TV White Space. The current US database e= nsures that the secondary user cannot interfere with the primary user. Ther= e is no guarantee of reciprocity. Channel availability does not equate to c= hannel usability.
Sensing is a non issue. The whole purpose of PA= WS is managing access with a database. There is no reason to restrict devic= es from sensing but if the device is not under the control of a database th= en it is outside the scope of PAWS.
Peter S.

=
From: Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Wed, 8 Feb 2012= 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "jussi.kahtava@nokia.com" <jussi.kahtava@nokia.com>, "scott.probasco@nokia.com" <= ;scott.probasco@nokia.com&g= t;, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use cases and requirements I-D: sec= tions 1 to 3(Introduction, Conventions and Terminology, Prior Work)

Andy,

 

I like your suggestions to broaden it = to any bands that are not fully occupied and for any type of devices. However,= white space should be white and not grey:

=93White Space (WS)

 Radio spectrum which is not <delete>fully<delete> occupied at a specific locat= ion and time.=94

 

Also, White Space devices should not b= e limited to those that need the database to operate, RF sensing or other opportunistic means may be allowed in some cases:<= /p>

=93White = Space device

A device which opportunistically uses some part of the white space spectrum<delete>,= under control of a white space database<delete>.  A white space device can be an access point, base station, a portable device or similar.  <delete>In this context, a<delete> <insert>= ;A<insert> white space device<delete> is<delete> Insert>may be<inser= t> required by local regulations to query a database with its location to obta= in information about available spectrum.=94

 <= /span>

Gerald

 

 

<= /div>

From: andy.sago@bt.com [mailto:andy.sago@bt.com]
Sent: Wednesday, 01 February, 201= 2 05:34
To: jussi.kahtava@nokia.com; gerald.chouinard= @sympatico.ca; scott.probasco@nokia.com; <= a href=3D"mailto:paws@ietf.org">paws@ietf.org
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology= , Prior Work)

 

Scott, All

 

I agree with= Jussi that we have now narrowed the definition to apply to TV white spaces, where= as the scope of PAWS is white spaces in general. I would question not only why= the lower-priority service would always be licence-exempt, but why the higher priority service would always be licenced. To avoid this issue on 27th Jan = I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html<= /a>) a revision of the Abstract that avoids the terms licence exempt or unlicens= ed, or any mention of the regulatory status of the incumbent services. The Abst= ract derives from the Introduction and the text could be aligned to be the same = in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it simple.

 

That just leaves the definition of white space, where the existing spectrum use has now got mudd= led with the potential for opportunistic use. This can be fixed by taking the w= hite space and white space device definitions together.  From Scott, Gerald= and Jussi=92s comments perhaps we could agree on:

<= p class=3D"MsoNormal"><= span lang=3D"EN-GB" style=3D"font-size:12.0pt;font-family:Calibri;color:#1F= 497D"> 

White Space (WS)

 <= font color=3D"black"><= /p>

Radio spe= ctrum which is not fully occupied at a specific location and time.

 

White Space device

 

A device which opportunistically uses some part of the white space spectrum, under control= of a white space database.  A white space device can be an access point, = base station, a portable device or similar.  In this context, a white space= device is required by local regulations to query a database with its locati= on to obtain information about available spectrum.

&n= bsp;

Regards

 <= /font>

Andy

 

= From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ju= ssi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; <= a href=3D"mailto:paws@ietf.org">paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminolog= y, Prior Work)

=  

That statement is valid for TV White Spaces on UHF frequencies but does not necessarily apply= to all under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt?

 

Kind regards,

Jussi

 =

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]On Behalf Of ext Gerald Cho= uinard
Sent: 31 January 2= 012 22:33
To: Probasco Sc= ott (Nokia-CIC/Dallas); paws@ietf.org
<= b>Subject: Re: [paws] Use cases= and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminolog= y, Prior Work)

=  

Scott,

 

Very good improvements. I would sugges= t to insert the notion of opportunistic use of the spectrum by white space devic= es in the last sentence of the definition of =93white space=94 as follows:

 

White Space

 

Radio spectrum which has been allocated and assigned for licensed use, but is not fully occupied= by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> by= local regulations <delete>for use<delete> <insert>to be u= sed opportunistically<insert> as licensed-exempt spectrum under control o= f a white space database.</Insert>

 

This way, it is understood that the database does not =93assign=94 white space devices for them to choose from.

 

Gerald

From: scott.probasco@nokia.com [mailto:scott.probasco@n= okia.com]
Sent: Tuesd= ay, 31 January, 2012 15:12
To: gerald.chouinard@sympatico.ca; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminolog= y, Prior Work)

 

Hi Gerald,

=

<= o:p> 

Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descripti= ons of licensed spectrum and license-exempt spectrum, I used these words. Do th= ese changes remove your concerns?

 <= /span>

I also corrected "location" to "local" in previous text proposed for "White Space".

 

Kind Regards,

Scott

 

From= : ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@no= kia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work)

 

S= cott,<= /o:p>

Great proposal.  However, I am still a bit nervous about the definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary status i= s used in the ITU-R Radio Regulations for a different purpose.  In fact, it i= s possible that a band has already primary and secondary services allotted to= it and that the White Space operation is a tertiary opportunistic operation wh= ere the two first types of services are not being used.  The use of =93lower priority opportunistic=94 service rather than =93secondary=94 service would be preferable to describe white spaceallocati= ons.

 

Gerald

 

From: paws-bou= nces@ietf.org [mailto:paws-bou= nces@ietf.org] On Behalf Of scott.probasco@nokia.com=
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 

<= font size=3D"2" color=3D"black" face=3D"Calibri">Hi,

 

I changed the subject line from " Re: [paws] Discussion on 'license-exem= pt' vs 'unlicensed'  ". Here I try to propose some changes to the dra= ft based on the email discussion.

&nbs= p;

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licen= sed' and 'license-exempt' and made changes to the term 'white space'. I have tri= ed to work from the perspective that the document should accurately explain th= e subject with aim that a reader can understand the use cases and the subsequ= ent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage.

=

 

I hope this captures the key points of the discussion. Please do reply if something is still missing.

&nbs= p;

Kind Regards,

Scott

 

&nbs= p;

2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio technologies= ,

      the database is an entity which contains current information a= bout

      available spectrum at any given location and other types of

      information.

 

   Device ID

 <= /p>

     A unique number for each mas= ter device and slave device that

=       identifies the manufacturer, model number and serial number.

 

<Insert>

&nbs= p;  Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given service = area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, company merger &

      acquisition,  first-come / first-served or by government allocation<= o:p>

      (e.g., public service).

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One exampl= e is the 2.4 Ghz ISM band, where RF devices<= span style=3D"color:black">

      operate without a formal licensing process. In the USA, license-exempt spectrum is

&nbs= p;     Typically referred to as "unlicensed" spectrum. In t= his document the terms

<= b>      license-exempt and unlicensed are used interchangeably.= =

 

<= p class=3D"MsoNormal">= </Insert>

 

   Location Based Service

 

      An application or device which provides data, information or

      service to a user based on their location.

 

&nbs= p;  Master Device

 <= font color=3D"black"><= /b>

      A device which queries the WS Database to find out the availab= le

      operating channels.

=  =

   Protected Entity

=  

      <Insert>A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A licensed</Insert&g= t; user of white space spectrum <Delete>which</Delete> is afforded= =

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white space

=

      devices) for its use</Delete> in a given area and time.<= /span><= /span>

 

<= div>

   Protected Contour

 

      The exclusion area for a Protected Entity, held in the databas= e

      and expressed as a polygon with geospatial points as the verti= ces.

 

=

   Slave Device

 

      A device which uses the spectrum made available by a master

      device.

 <= /font><= /font>

   TV White Space

 = =

      TV white space refers specifically to radio spectrum which has= =

      been allocated for TV broadcast, but is not occupied by a TV

      broadcast, or other licensed user (such as a wireless micropho= ne),

      at a specific location and time.

 

   White Space=

 

      Radio spectrum which has been allocated <Delete>for some= primary use</Delete><Insert>and assigned for licensed use</Insert>, but

  = ;    is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

=       and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white sp= ace database.</Insert>

<= b> 

   White Space Device (WSD)

<= b> 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</Inse= rt> user of some part of white space

=       spectrum.  A white space device can be an access point, b= ase

      station, a portable device or similar.  In this context, = a white<= /o:p>

      space device is required to query a database with its location= to

      obtain information about available spectrum.=

 

&nbs= p;

 

From: ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@ear= thlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 <= span style=3D"color:black">

<= /w:sdtpr>Nancy,

=  <= font color=3D"black"><= /b>

This is not that simple.  In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to more than one thing.

&= nbsp;<= /o:p>

If the qualifier applies to a frequency band, different options exist. As an examp= le, in the ITU-R context, an =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its use.  I= t is therefore un-allocated to a specific service so far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrati= ons can thendecide under what king of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licenses, = thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in the USA.

&= nbsp;<= /o:p>

If the qualifier applies to an operation, the operation can be exempt of license b= y the local administration, thus a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a license= d band for which he has no license or in a license-exempt band for which he d= oes not meet the requirements such as operating according to the type of operat= ion for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an =93unlicensed=94 operation.

 

If the qualifier applies to the transmission device, such device may be a =93license-exempt=94 device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someo= ne smuggles a device that is not allowed in a country by, for example, buying = it on eBay and operates it, this is then an illegal device in the country and = id de-facto an =93unlicensed=94 device since it has not passed through the normal certification process.

<= b> 

Note that a =93license-exempt=94 device still has to go through a certification process and meet the limits imposed by the local regulator fo= r the =93license-exempt=94 operation in the given frequency band whereas an =93unlicensed=94 device may not pass the certification process since it has not been licensed to operation in the country.

=

 

This is why the qualifier =93unlicensed=94 has to be treated with care and the footnote will need to be crafted very carefully.

&= nbsp;<= /o:p>

With respect to your second point, if an administration only allows =93licensed=94 operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses.= =

 

Gerald

&nbs= p;

From: Nancy Bravin [mailto:nbravin@earth= link.net]
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Gabor and Gerald, <= o:p>

Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements&quo= t;  

How to get around the fact that some Countries are or will be "licensed only" by their gov'ts?  Thanks

Nancy

On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote:

 

Gabor,

 

I agree with your proposal.  Thisseems to be reasonable.  However one nee= ds to be careful with the word=91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many administrations.

 

Gerald

=  =

From: Gabor.Ba= jko@nokia.com [mailto:Gabor.Ba= jko@nokia.com]
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympa= tico.ca; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.

 = ;

Therefore, may I suggest that the draft will include the following statement:

 

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band.

 

- &= nbsp;        Gabor

 

From: paws-bounces@ietf.org [mailt= o:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

All,

 

Here is my understanding of the terms:

=  <= font color=3D"black"><= /b>

Licensed: Spectrum that is acquired by an operator over a given service area for a gi= ven time period.  This is usually done through auctions (think of the Telc= os), beauty contest, first-come / first-served or by government allocation (e.g.= , public service).

 

Ligh= tly licensed: Special case where thefrequency allocation is done through first-= come / first-served process for a given time frame over a relatively limited ser= vice area. The annual license fee is usually small to facilitate the deployment = of a service that would not normally be economically attractive.  Small loc= al operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos that would normally work with full licensing through auction ove= r large service areas.

 

L= icense-exempt: Operation of RF devices in a frequency band where no formal licensing proce= ss is needed such as in the 2.4 GHz ISM band. In the USA, this t= erm is used for a specific type of operation. The FCC should be contacted to clarify it.

 

Unlicensed: Illegal operation of an RF device that can transmit in a frequency band wit= hout a duly issued license.  In the USA, this term is used to = mean =93license-exempt," see above.

 

To my knowledge, the term =93unlicensed=94 is used only in the USA t= o describe a legal operation because the term =93license-exempt=94 has been used for another specific purpose.

<= b> 

Since the PAWS addresses the interface to the database for the international mark= et, it should rely on the definition of the terms recognized by the ITU-R. I wo= uld suggest the use of =91licensed=92 and =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the USA instead of the usual =91license-exempt=92.

 = =

Gerald

_______________________________________________
paws mailing list
paws@ietf.org
= https://www.ietf.org= /mailman/listinfo/paws

 <= /o:p>

______________________= _________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailm= an/listinfo/paws

--_000_CB5814971F99Bpeterspectrumbridgecom_-- From nbravin@earthlink.net Wed Feb 8 09:16:22 2012 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 6634C21E801C for ; Wed, 8 Feb 2012 09:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=-1.615, BAYES_40=-0.185, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4Ql+iNGfzxw for ; Wed, 8 Feb 2012 09:16:19 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id B7C2321F8698 for ; Wed, 8 Feb 2012 09:16:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=sXbSJRPBddkMpiNLuYrZntqIs07wo2s1PtK07UIuyJtH082A3DBuW6L1uQFZw/Ex; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RvB7a-00086i-NV; Wed, 08 Feb 2012 12:15:57 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-6-374318857 From: Nancy Bravin In-Reply-To: Date: Wed, 8 Feb 2012 09:15:53 -0800 Message-Id: References: To: Peter Stanforth X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8640e213f26f44af44c45df8fd1f19862f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: "paws@ietf.org" Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 17:16:22 -0000 --Apple-Mail-6-374318857 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear Peter, Yes, after consideration, I agree, and with John Stine's proposal as = well. It makes sense as long as the DB's are in control to have a couple = of different models, it becomes more attractive on a global basis for business investment = into White Space. Sincerely, Nancy On Feb 8, 2012, at 9:01 AM, Peter Stanforth wrote: > There is no reason to assume that use of white space is by licensed = exempt or unlicensed devices. This comes back to an earlier argument I = made about what constitutes licensed and unlicensed? > Again there is no reason that a license exempt or unlicensed device = should get access to spectrum for "free" any more that a licensed device = has to "pay" for spectrum access. > The concept of a primary user, who has priority over a secondary user = has no relevance to free or paid access.=20 > The rationale for white space is that the spectrum is shared and that = someone has primary, preferred or priority access and the database = ensures that those rights/requirements are met by anyone who uses the = spectrum on a secondary basis. I would go further and say that the = secondary access could be deterministic or opportunistic. There is no = reason to require one or the other, and an argument can be made for = both. In a band occupied by a public safety user there may be no choice = but to have opportunistic access but in other bands a primary user may = be willing to commit to specific availability if their own use is = deterministic.=20 >=20 > Peter S. >=20 > From: Gerald Chouinard > Date: Wed, 8 Feb 2012 10:20:52 -0500 > To: "andy.sago@bt.com" , "nbravin@earthlink.net" = , "paws@ietf.org" > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >=20 > Andy, > =20 > To resolve Nancy=92s concern, a new definition could be added for: > =20 > TVWS White Space devices: White Space devices that operate in the TV = bands. > =20 > This would complement the definition of White Space devices and make = it more specific. > =20 > I am having second thoughts about yoursuggestion to remove the concept = of classes of devices from the White Spacedevices. The opportunistic use = of the RF spectrum assumes that these devices operate while protecting = existing operation in the band. There is automatically assumes the = existence of primary users of the band that have priority. Such primary = users would most likely be licensed to use the band and it is only the = portions that happen to be unused that will be accessible to the White = Space devices. The latter are unlikely to be licensed to only use the = =91crumbs=92. Removing the concept of license-exempt could put these new = devices at the same level of priority as the primary devices and then = why would they need to protect these =91primary=92 licensed devices. > =20 > This would be similar to the situation in the 2.4 GHz where a database = is not needed to protect other devices. As is well understood, the = databases are there to protect primary and possibly secondary licensed = devices from the new opportunistic devices, not opportunistic devices = among themselves. The latter case would be covered by other means such = as adatabase to provide coexistence and this is, I believe, beyond the = scope ofPAWS. > =20 > Gerald > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of andy.sago@bt.com > Sent: Wednesday, 01 February, 2012 09:58 > To: nbravin@earthlink.net; paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Nancy, all > =20 > Good questions. I=92m not proposing to remove references to TVWS, they = are entirely appropriate within the use cases since it is the TV bands = we are studying as first candidate for opportunistic access, but the = charter says we are addressing all white space in the resulting = protocol. To answer your other questions, IMO our aim should be to = provide all the necessary information in this PAWS requirements I-D to = enable the PAWS protocol I-D to be developed. I don=92t think it=92s our = job to explain different regulatory regimes or applications (beyond use = cases) in this document, ITU and others do this very well, and = regulators tend to be well coordinated or play =91follow my leader=92. > =20 > Thanks for pointing out the reference to licence-exempt that I had = missed in 4.4 - I think the meaning would be just the same with =91in a = license-exempt TVWS environment=92 deleted from that sentence. That = would be my suggestion. > =20 > Regards > =20 > Andy > =20 > From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 > Sent: 01 February 2012 14:48 > To: Sago,AJ,Andy,COD R > Cc: paws@ietf.org > Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, = 4.6=85so if you propose to remove any reference to TVWS it will affect > the document as a whole, and information that seems necessary to = explain how the DB and protocol interacts with TVWS devices and > the methods of doing so. One can envision that current rules could = change, but, why not give the information on both for countries to = understand fully > what it's choices are?=20 > =20 > Thanks Andy, just some early morning thoughts=85Sincerely, Nancy > =20 > Begin forwarded message: > =20 >=20 > From: Nancy Bravin > Date: February 1, 2012 6:35:09 AM PST > To: Andy Sago > Cc: , , = , > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi Andy, All > =20 > In section 4.4, license exempt is also mentioned as well.=20 > I am conflicted in a global sense when emerging countries, or = countries with very different types of gov't want to implement > the protocol, will they have enough information to do so? and thereby = join the existing DB companies, or will they do their own thing > leaving holes in what one hopes will be an interoperable global = protocol that deals with TVWS, and/or White spaces in general? > =20 > Thanks, just a thought. > =20 > SIncerely, Nancy > =20 > =20 > On Feb 1, 2012, at 2:34 AM, = wrote: > =20 >=20 > Scott, All > =20 > I agree with Jussi that we have now narrowed the definition to apply = to TV white spaces, whereas the scope of PAWS is white spaces in = general. I would question not only why the lower-priority service would = always be licence-exempt, but why the higher priority service would = always be licenced. To avoid this issue on 27th Jan I proposed = (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a = revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent = services. The Abstract derives from the Introduction and the text could = be aligned to be the same in the Introduction, with =93opportunistic=94 = replacing =93secondary=94 in later sentences in the Introduction. I have = checked and there are no further references to licensing in the = document, so we don=92t need the definitions of licence exempt, light = licensing or unlicensed. This is not a regulatory document =96 we are = defining requirements fora protocol. Keep it simple. > =20 > That just leaves the definition of white space, where the existing = spectrum use has now got muddled with the potential for opportunistic = use. This can be fixed by taking the white space and white space device = definitions together. =46rom Scott, Gerald and Jussi=92s comments = perhaps we could agree on: > =20 > White Space (WS) > =20 > Radio spectrum which is not fully occupied at a specific location and = time. > =20 > White Space device > =20 > A device which opportunistically uses some part of the white space = spectrum, under control of a white space database. A white space device = can be an access point, base station, a portable device or similar. In = this context, a white spacedevice is required by local regulations to = query a database with its location to obtain information about available = spectrum. > =20 > Regards > =20 > Andy > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of jussi.kahtava@nokia.com > Sent: 01 February 2012 07:31 > To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > That statement is valid for TV White Spaces on UHF frequencies but = does not necessarily apply to all under-utilised radio spectrum. Why = would the lower priority service by default be licence-exempt? > =20 > Kind regards, > Jussi > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard > Sent: 31 January 2012 22:33 > To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Scott, > =20 > Very good improvements. I would suggest to insert the notion of = opportunistic use of the spectrum by white space devices in the last = sentence of the definition of =93white space=94 as follows: > =20 > White Space > =20 > Radio spectrum which has been allocated and assigned for licensed use, = but is not fully occupied by that licensed use at a specific location = and time. This spectrum is then assigned = allowed bylocal regulations for use = to be used opportunistically as licensed-exempt spectrum = under control of a white space database. > =20 > This way, it is understood that the database does not =93assign=94 = white space devices for them to choose from. > =20 > Gerald > From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 > Sent: Tuesday, 31 January, 2012 15:12 > To: gerald.chouinard@sympatico.ca; paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi Gerald, > =20 > Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower = priority opportunistic service" could indeed by used, but I am guessing = that we would need some explanation of what that means. Since we now = have descriptions of licensed spectrum and license-exempt spectrum, I = used these words. Do these changes remove your concerns? > =20 > I also corrected "location" to "local" in previous text proposed for = "White Space". > =20 > Kind Regards, > Scott > =20 > From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 > To: Scott , "paws@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Scott, > Great proposal. However, I am still a bit nervous about the = definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 = where the notion of secondary use is included. The secondary status is = used in the ITU-R Radio Regulations for a different purpose. In fact, = it is possible that a band has already primary and secondary services = allotted to it and that the White Space operation is a tertiary = opportunistic operationwhere the two first types of services are not = being used. The use of =93lower priority opportunistic=94 service = rather than =93secondary=94 service would be preferable to describe = white spaceallocations. > =20 > Gerald > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com > Sent: Tuesday, 31 January, 2012 13:56 > To: paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi, > =20 > I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes = to the draft based on the email discussion. > =20 > Below is a copy of chapter 2.2. Terminology. I have inserted new terms = for 'licensed' and 'license-exempt' and made changes to the term 'white = space'. I have tried to work from the perspective that the document = should accurately explain the subject with aim that a reader can = understand the use cases and the subsequent requirements. No doubt we = could include much more text on this topic of spectrum allocation, = assignment, licensing and usage. > =20 > I hope this captures the key points of the discussion. Please do reply = if something is still missing. > =20 > Kind Regards, > Scott > =20 > =20 > 2.2. Terminology > =20 > Database > =20 > In the context of white space and cognitive radio technologies, > the database is an entity which contains current information = about > available spectrum at any given location and other types of > information. > =20 > Device ID > =20 > A unique number for each master device and slave device that > identifies the manufacturer, model number and serial number. > =20 > > Licensed Spectrum > =20 > Spectrum that is acquired by an operator over a given service = area > for a given time period. This is usually done through = auctions,award > (beauty contest), acquisition from secondary market, company = merger & > acquisition, first-come / first-served or by government = allocation > (e.g., public service). > =20 > License-exempt Spectrum > =20 > Spectrum that is not assigned to any specific user. One example = is the 2.4 Ghz ISM band, where RF devices > operate without a formal licensing process. In the USA, = license-exempt spectrum is > Typically referred to as "unlicensed" spectrum. In this document = the terms > license-exempt and unlicensed are used interchangeably. > =20 > > =20 > Location Based Service > =20 > An application or device which provides data, information or > service to a user based on their location. > =20 > Master Device > =20 > A device which queries the WS Database to find out the available > operating channels. > =20 > Protected Entity > =20 > A licensed user of spectrum, when the licensed spectrum = has been assigned as white space spectrum. A = primaryA licensed user of white space spectrum = which is afforded > protection against interference by = secondarylicense-exempt white space = users (white space > devices) for its use in a given area and time. > =20 > Protected Contour > =20 > The exclusion area for a Protected Entity, held in the database > and expressed as a polygon with geospatial points as the = vertices. > =20 > Slave Device > =20 > A device which uses the spectrum made available by a master > device. > =20 > TV White Space > =20 > TV white space refers specifically to radio spectrum which has > been allocated for TV broadcast, but is not occupied by a TV > broadcast, or other licensed user (such as a wireless = microphone), > at a specific location and time. > =20 > White Space > =20 > Radio spectrum which has been allocated for someprimary = useand assigned for licensed use, but > is not fully occupied by that primary = use licensed use at a specificlocation > and time. This spectrum is then assigned by = locationlocal regulations for use as = licensed-exempt spectrum under control of a white space = database. > =20 > White Space Device (WSD) > =20 > A device which is a = secondarylicense-exempt user of some = part of white space > spectrum. A white space device can be an access point, base > station, a portable device or similar. In this context, a white > space device is required to query a database with its location = to > obtain information about available spectrum. > =20 > =20 > =20 > From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 > To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Nancy, > =20 > This is not that simple. In fact, the qualifiers =93license-exempt=94 = and =93unlicensed=94 can apply to more than one thing. > =20 > If the qualifier applies to a frequency band, different options exist. = As an example, in the ITU-R context, an =93unlicensed=94 band is = typically a new band, say in the 300 GHz, for which no request has been = made for its use. It is therefore un-allocated to a specific service so = far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R = allocates this band to one or many services on a primary or secondary = basis, then the administrations can thendecide under what king of regime = it will =91assign=92 this band foroperation. They may decide to allow = the use of the band on the basis of licensed operation (with different = options to do the assignment: auction, first come/first served, etc.) or = allow operation with an exemption of licenses, thus =93license-exempt=94su= ch as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in = the USA. > =20 > If the qualifier applies to an operation, the operation can be exempt = of license by the local administration, thus a =93license-exempt=94 = operation. If, however, someone decides to start an RF transmission = operation in a licensed band for which he has no license or in a = license-exempt band for which he does not meet the requirements such as = operating according to the type of operation for which the band is = exempted from a license or he operates outside the technical limits = imposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an =93unlicensed=94 = operation. > =20 > If the qualifier applies to the transmission device, such device may = be a =93license-exempt=94 device if its operation does not require a = specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if = someone smuggles a device that is not allowed in a country by, for = example, buying it on eBay and operates it, this is then an illegal = device in the country and id de-facto an =93unlicensed=94 device since = it has not passed through the normal certification process. > =20 > Note that a =93license-exempt=94 device still has to go through a = certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band = whereas an =93unlicensed=94 device may not pass the certification = process since it has not been licensed to operation in the country. > =20 > This is why the qualifier =93unlicensed=94 has to be treated with care = and the footnote will need to be crafted very carefully. > =20 > With respect to your second point, if an administration only allows = =93licensed=94 operation, the situation will be much simpler to manage = since specific conditions will be attached to these licenses. > =20 > Gerald > =20 > From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 > Sent: Tuesday, 31 January, 2012 06:33 > To: Gerald Chouinard > Cc: Gabor.Bajko@nokia.com; paws@ietf.org > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Gabor and Gerald,=20 > Since we are dealing on a global basis, can there a footnote to = "unlicensed" we can use to indicate that "according to each countries = regulatory requirements" =20 > How to get around the fact that some Countries are or will be = "licensed only" by their gov'ts? Thanks > Nancy > On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: >=20 >=20 >=20 > Gabor, > =20 > I agree with your proposal. Thisseems to be reasonable. However one = needs to be careful with the word=91unlicensed=92 which may mean = =91illegal=92 operation of an RF device in many administrations. > =20 > Gerald > =20 > From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 > Sent: Monday, 30 January, 2012 17:49 > To: gerald.chouinard@sympatico.ca; paws@ietf.org > Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > These look to be very precise definitions, however in everyday use I = rarely hear people referring to ISM band as =91license-exempt=92, in = most cases the term =91unlicensed-band=92 is used. > =20 > Therefore, may I suggest that the draft will include the following = statement: > =20 > The terms unlicensed and license-exempt spectrum are used in this = document interchangeably and refer to a spectrum in which no formal = licensing process is needed for RF devices to operate in, such as the = ISM band. > =20 > - Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard > Sent: Monday, January 30, 2012 12:30 PM > To: paws@ietf.org > Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > All, > =20 > Here is my understanding of the terms: > =20 > Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). > =20 > Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos thatwould = normally work with full licensing through auction over large service = areas. > =20 > License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. > =20 > Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. > =20 > To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. > =20 > Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I would suggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. > =20 > Gerald > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=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 > =20 > =20 --Apple-Mail-6-374318857 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = Peter,

Yes, after consideration, I agree, and with = John Stine's proposal as well. It makes sense as long as the DB's are in = control to have a couple of different models,
it becomes more = attractive on a global basis for business investment into White = Space.

Sincerely, Nancy
On Feb 8, = 2012, at 9:01 AM, Peter Stanforth wrote:

The = concept of a primary user, who has priority over a secondary user has no = relevance to free or paid access. 
The rationale for = white space is that the spectrum is shared and that someone has primary, = preferred or priority access and the database ensures that those = rights/requirements are met by anyone who uses the spectrum on a = secondary basis. I would go further and say that the secondary access = could be deterministic or opportunistic. There is no reason to require = one or the other, and an argument can be made for both. In a band = occupied by a public safety user there may be no choice but to have = opportunistic access but in other bands a primary user may be willing to = commit to specific availability if their own use is = deterministic. 

Peter = S.

From: Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Wed, 8 Feb = 2012 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use cases and = requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

Andy,
<= div class=3D"MsoNormal"> 
=
To resolve Nancy=92s = concern, a new definition could be added for:
 
=
TVWS White Space devices: White = Space devices that operate in the TV bands.
 <= /span>
This would complement the = definition of White Space devices and make it more = specific.
 
=
I am having second thoughts about = yoursuggestion to remove the concept of classes of devices from the = White Spacedevices. The opportunistic use of the RF spectrum assumes = that these devices operate while protecting existing operation in the band.  There is automatically assumes the existence of primary users of the band that = have priority. Such primary users would most likely be licensed to use the = band and it is only the portions that happen to be unused that will be accessible = to the White Space devices.  The latter are unlikely to be licensed to = only use the =91crumbs=92. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices = and then why would they need to protect these =91primary=92 licensed = devices.
 
=
This would be similar to the = situation in the 2.4 GHz where a database is not needed to protect other devices. As = is well understood, the databases are there to protect primary and possibly = secondary licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other means such = as adatabase to provide coexistence and this is, I believe, beyond the = scope ofPAWS.
 
=
Gerald
=
 
=
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
Nancy, all
 
Good = questions. I=92m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are = studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary = information in this PAWS requirements I-D to enable the PAWS protocol I-D to be = developed. I don=92t think it=92s our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this = very well, and regulators tend to be well coordinated or play =91follow my leader=92.
 
Thanks for = pointing out the reference to licence-exempt that I had missed in 4.4 -  I = think the meaning would be just the same with =91in a license-exempt TVWS environment=92 deleted from that sentence. That would be my = suggestion.
 
Regards<= /o:p>
 
Andy
 
From: Nancy Bravin [mailto:nbravin@earthlink.net] =
Sent: 01 February = 2012 14:48
To: = Sago,AJ,Andy,COD R
Cc: = paws@ietf.org
Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
Hi Andy, also, throughout the = document TVWS are mentioned in 4.1,4.5, 4.6=85so if you propose to remove any reference to TVWS it will affect
the document as a whole, and = information that seems necessary to explain how the DB and protocol interacts with TVWS devices = and
the methods of doing so. One = can envision that current rules could change, but, why not give the information on both for = countries to understand fully
what it's choices = are? 
 
Thanks Andy, just = some early morning thoughts=85Sincerely, Nancy
 
Begin forwarded = message:

 

From: = Nancy Bravin <nbravin@earthlink.net>=
Date: = February 1, 2012 6:35:09 AM PST
To: = Andy Sago <andy.sago@bt.com>
Subject:= Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)
 
Hi Andy, = All
 
In section 4.4, = license exempt is also mentioned as well. 
I am conflicted in a global = sense when emerging countries, or countries with very different types of gov't want to = implement
the protocol, will they have = enough information to do so? and thereby join the existing DB companies, or will they do their = own thing
leaving holes in what one = hopes will be an interoperable global protocol that deals with TVWS, and/or White spaces = in general?
 
Thanks, just a = thought.
 
SIncerely, = Nancy
 
 
On Feb 1, 2012, = at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

 

Scott, = All
 =
I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only = why the lower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th Jan I = proposed (h= ttp://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it simple.
 =
That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  =46rom Scott, = Gerald and Jussi=92s comments perhaps we could agree on:
 =
White Space = (WS)
 
Radio = spectrum which is not fully occupied at a specific location and = time.
 
White Space = device
 
A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white = spacedevice is required by local regulations to query a database with = its location to obtain information about available spectrum.
 =
Regards
 =
Andy
 =
From: paws-bounces@ietf.org [mailto:paws-bounces@ie= tf.org] On Behalf Of jussi.kahtava@nokia.com
= Sent: 01 February 2012 = 07:31
To: gerald.chouinard@sympatico.c= a; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 
That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?
 =
Kind = regards,
Jussi<= /font>
 =
From: paws-bounces@ietf.org [mailto:paws-bounces@ie= tf.org] On Behalf Of ext= Gerald Chouinard
Sent: 31 January 2012 = 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 
Scott,
 
Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of =93white space=94 as = follows:
 
White = Space
 
Radio = spectrum which has been allocated and assigned for licensed use, but is not fully = occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> = bylocal regulations <delete>for use<delete> <insert>to = be used opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>
 
This way, it is understood that the database does not =93assign=94 white space devices for them to choose from.
 
Gerald
From: scott.probasco@nokia.com [mailto:scott.probas= co@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 
Hi = Gerald,
 
Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?
 
I also = corrected "location" to "local" in previous text proposed for "White Space".
 
Kind = Regards,
Scott
 
From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>,= "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 
S= cott,
G= reat proposal.  However, I am still a bit nervous about the definitions = of =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In = fact, it is possible that a band has already primary and secondary services = allotted to it and that the White Space operation is a tertiary opportunistic = operationwhere the two first types of services are not being used. =  The use of =93lower priority opportunistic=94 service rather than =93secondary=94 service would be preferable to describe white = spaceallocations.
&= nbsp;
G= erald
&= nbsp;
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 
Hi,
 
I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the draft based on the email discussion.
 
Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.
 
I hope this captures the key points of the discussion. Please do reply if something is still missing.
 
Kind Regards,
Scott
 
 
2.2.  Terminology
 
   Database
 
      In the context of white space and cognitive radio = technologies,
      the database is an entity which contains current = information about
      available spectrum at any given location and other types = of
      information.
 
   Device ID
 
      A unique number for each master device and slave device = that
      identifies the manufacturer, model number and serial = number.
 
<Insert>
   Licensed Spectrum
 
      Spectrum that is acquired by an operator over a given = service area
      for a given time period.  This is usually done through auctions,award
      (beauty contest), acquisition from secondary market, = company merger &
      acquisition,  first-come / first-served or by = government allocation
      (e.g., public service).
 
   License-exempt Spectrum
 
      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices
      operate without a formal licensing process. In the USA, = license-exempt spectrum is
      Typically referred to as "unlicensed" spectrum. In this document the terms
      license-exempt and unlicensed are used = interchangeably.
 
</Insert>
 
   Location Based Service
 
      An application or device which provides data, information = or
      service to a user based on their = location.
 
  Master Device
 
      A device which queries the WS Database to find out the = available
      operating channels.
 
   Protected Entity
 
      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded
      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space
      devices) for its use</Delete> in a given area and = time.
 
   Protected Contour
 
      The exclusion area for a Protected Entity, held in the = database
      and expressed as a polygon with geospatial points as the = vertices.
 
   Slave Device
 
      A device which uses the spectrum made available by a = master
      device.
 
   TV White Space
 
      TV white space refers specifically to radio spectrum which = has
      been allocated for TV broadcast, but is not occupied by a = TV
      broadcast, or other licensed user (such as a wireless = microphone),
      at a specific location and time.
 
   White Space
 
      Radio spectrum which has been allocated <Delete>for = someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but
      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation
      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> = regulations for use as licensed-exempt spectrum under control of a white space database.</Insert>
 
   White Space Device (WSD)
 
     A device which is a = <Delete>secondary</Delete><Insert>license-exempt</Ins= ert> user of some part of white space
      spectrum.  A white space device can be an access = point, base
      station, a portable device or similar.  In this = context, a white
      space device is required to query a database with its = location to
      obtain information about available = spectrum.
 
 
 
From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
Nancy,
&= nbsp;
T= his is not that simple.  In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to more than one = thing.
&= nbsp;
I= f the qualifier applies to a frequency band, different options exist. As an = example, in the ITU-R context, an =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its = use.  It is therefore un-allocated to a specific service so far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in the USA.
&= nbsp;
I= f the qualifier applies to an operation, the operation can be exempt of = license by the local administration, thus a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an =93unlicensed=94 operation.
&= nbsp;
I= f the qualifier applies to the transmission device, such device may be a =93license-exempt=94 device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an =93unlicensed=94 device since it has not passed through the normal certification process.
&= nbsp;
N= ote that a =93license-exempt=94 device still has to go through a certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band whereas an =93unlicensed=94 device may not pass the certification process since it has not been licensed to operation in the = country.
&= nbsp;
T= his is why the qualifier =93unlicensed=94 has to be treated with care and the footnote will need to be crafted very carefully.
&= nbsp;
W= ith respect to your second point, if an administration only allows =93licensed=94 operation, the situation will be much simpler to manage since specific conditions will be attached to these = licenses.
&= nbsp;
G= erald
&= nbsp;
From: Nancy Bravin [mailto:nbravin@earthlink.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
Gabor and = Gerald, 
Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements"  
How to get = around the fact that some Countries are or will be "licensed only" by their gov'ts?  Thanks
Nancy
On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:



G= abor,
&= nbsp;
I= agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word=91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many = administrations.
&= nbsp;
G= erald
&= nbsp;
From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.
 
Therefore, may I suggest that the draft will include the following = statement:
 
The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.
 

-=       =     Gabor

 
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
= All,
=  
H= ere is my understanding of the terms:
&= nbsp;
L= icensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).
&= nbsp;
L= ightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos = thatwould normally work with full licensing through auction over large = service areas.
&= nbsp;
L= icense-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, = this term is used for a specific type of operation. The FCC should be contacted to clarify = it.
&= nbsp;
U= nlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, = this term is used to mean =93license-exempt," see above.
&= nbsp;
T= o my knowledge, the term =93unlicensed=94 is used only in the USA to describe a legal = operation because the term =93license-exempt=94 has been used for another specific purpose.
&= nbsp;
S= ince the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I = would suggest the use of =91licensed=92 and =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the USA instead of the usual =91license-exempt=92.
&= nbsp;
G= erald

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws

 
_______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/m= ailman/listinfo/paws
_________________________= ______________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws
 
 

= --Apple-Mail-6-374318857-- From scott.probasco@nokia.com Wed Feb 8 09:54:51 2012 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 B38F021F8698 for ; Wed, 8 Feb 2012 09:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BQWFY3zbkXb for ; Wed, 8 Feb 2012 09:54:50 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB1021F8589 for ; Wed, 8 Feb 2012 09:54:50 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q18Hsl7F021680 for ; Wed, 8 Feb 2012 19:54:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 19:54:48 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Wed, 8 Feb 2012 18:54:48 +0100 From: To: Thread-Topic: UC&R I-D: section 4.4 (Wide-Area or Rural internet broadband access) Thread-Index: AQHM5oq+RfFTVzSSnEya70hzTx9liA== Date: Wed, 8 Feb 2012 17:54:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <313EF4988C35FC428A8744CC60B3B3F7@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 17:54:48.0600 (UTC) FILETIME=[BFE17180:01CCE68A] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadband access) 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, 08 Feb 2012 17:54:51 -0000 Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for section on the Wide-Area or Rural use case (new section numbering is NOT shown, all use cases will be moved to section 4.2 Use cases in the next version). This text has been marked up from version-02 as uploaded January 26, 2012 as follows: * include applicable comments from Hotspot use case Our goal is that any discussion on this text will conclude by February 15. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 4.4. Wide-Area or Rural internet broadband access In this use case, internet broadband access is provided as a Wide- Area Network (WAN) or Wireless Regional Area Network (WRAN). A typical deployment scenario is a wide area or rural area, where internet broadband access is provided to local businesses and residents from a master (i.e. BS) connected to the internet. This deployment scenario is typically characterized by one or more Fixed master(s)/BS(s), cells with relatively large radius (tens of kilometers, up to 100 km), and a number of available radio channels. Some of the masters/BSs may be deployed and operated by a single entity, i.e. there can be centralized coordination between these masters/BSs, whereas other masters/BSs may be deployed and operated by operators competing for the radio channels in a license-exempt TVWS environment where decentralized coordination using the air-interface would be required. The BS in this scenario use a TDD radio technology and transmit at or below a transmit power limit established by the local regulator. Each base station has a connection to the internet and may provides internet connectivity to multiple slave/end-user devices. End user terminals or devices may be fixed or portable. The figure below shows an example deployment of this scenario. ------- |Slave|\ \|/ ---------- |Dev 1| (TDD AirIF) | |Database| ------- \ | .---. /---------- o \ |-|---------| ( ) / o | Master | / \ o / | (BS) |=3D=3D=3D=3D=3D=3D=3D=3D( Interne= t ) o / |-----------| \ / ------- (TDD AirIF) ( ) |Slave| / (----) |Dev n| ------- Figure 4: Rural internet broadband access using TV white space spectrum Once the master/BS has been professionally installed and configured, a simplified power up and operation scenario utilizing TV White Space to provide rural internet broadband access consists of the following steps: 1. The master/BS powers up; however its WS radio and all other WS capable devices will power up in idle/listen only mode (No active transmissions on the WS frequency band) 2. The master/BS has internet connectivity , determines its location (either from location determination capability or from saved value that was set during installation), and establishes a connection to a trusted white space database (see use case "TVWS database discovery" above). 3. The master/BS registers its geolocation, address, contact information, etc. associated with the owner/operator of the master/BS with the trusted database service (if not currently registered, see Section 4.2reference is to registration, will be updated in next version). Meanwhile the DB administrator may be required to store and forward the registration information to the regulatory authority. If a trusted white space database administrator is not discovered, further operation of the WRAN may be allowed according to local regulator policy (in this case operation of the WRAN is outside the scope of the PAWS protocol). 4. Following the successful registration process, the master/BS will send a query to the trusted database requesting a list of available WS channels based upon its geolocation. The complete set of parameters to be provided from the master to the database is specified by the local regulator. Parameters may include WSD location, accuracy of of that location, device antenna height, device identifier of a slave device requesting channel information. 5. If the master/BS has been previously authenticated, the database responds with a list of available white space channels that may be used and optionally a maximum transmit power (EIRP) for each channel and a duration of time the channel may be used or a notification of any additional requirement for sensing. 6. Once the master/BS authenticates the WS channel list response message from the database, the master/BS selects an available WS channel(s) from the list. The operator may disallow some channels from the list to suit local needs if required. 7. The slave or user device scans the TV bands to locate a WRAN transmission, and associates with the master/BS.insert new step 8. The slave/user device provides its geolocation to the BS which, in turn, queries the databasemaster for a list of channels available at the slaves' Geolocation providing to the master the slave's Device ID and optionally its geolocation.. 9. Once this list of available channels is received from the database by the master, the latter will decide, based on the list of available channels for all its other associated slaves whether it should continue operation on its current channel or change channel to accommodate the new slave in case this channel is not available at its location. The master will notify all its associated slaves/user devices of the new channel to move to if operation needs to change channel. If the channel that the user terminal is currently using is not included in the list of locally available channels, the master will drop its association with the slave/user device so that it ceases all operation on its current channel and indicate the new operating channel before dropping the link if a change has been decided. The slave/user device may move to the indicated new channel if so indicated or scan for another WRAN transmission on a different channel. 10. The master/BS must periodically repeat the process to request a channel list from the database, steps 4 through 6 above. The frequency to repeat the process is determined by the local regulator. If the response from the database indicates a channel being used by the master/BS is not available, the master/BS must stop transmitting on that channel immediately. 11. The slave or user device must periodically repeat the process to request a channel list from the master/BS, steps 8 and 9 above. The frequency to repeat the process is determined by the local regulator. If the response from the master/BS indicates that a channel being used by the slave or user device is not available, the slave or user device must stop transmitting on that channel immediately. From teco@inf-net.nl Wed Feb 8 10:44:46 2012 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 1B45B21F85A7 for ; Wed, 8 Feb 2012 10:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.191 X-Spam-Level: X-Spam-Status: No, score=-2.191 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC0mg+6hQRPh for ; Wed, 8 Feb 2012 10:44:43 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B51A121F8581 for ; Wed, 8 Feb 2012 10:44:39 -0800 (PST) Received: by eaal12 with SMTP id l12so285884eaa.31 for ; Wed, 08 Feb 2012 10:44:39 -0800 (PST) Received: by 10.14.99.195 with SMTP id x43mr8707698eef.46.1328726678912; Wed, 08 Feb 2012 10:44:38 -0800 (PST) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id o49sm147003eei.0.2012.02.08.10.44.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 08 Feb 2012 10:44:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_7D30AE30-B6F7-48C4-B070-2FDE09FE9E3F" From: Teco Boot In-Reply-To: Date: Wed, 8 Feb 2012 19:44:36 +0100 Message-Id: <6F5D89D7-21A4-40A4-88B3-CB48A94CCC88@inf-net.nl> References: To: Peter Stanforth X-Mailer: Apple Mail (2.1251.1) Cc: "paws@ietf.org" Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 18:44:46 -0000 --Apple-Mail=_7D30AE30-B6F7-48C4-B070-2FDE09FE9E3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Op 8 feb. 2012, om 18:03 heeft Peter Stanforth het volgende geschreven: > White Space is by definition grey. Specifically if we talk about TV = White Space. The current US database ensures that the secondary user = cannot interfere with the primary user. There is no guarantee of = reciprocity. Channel availability does not equate to channel usability. > Sensing is a non issue. The whole purpose of PAWS is managing access = with a database. There is no reason to restrict devices from sensing but = if the device is not under the control of a database then it is outside = the scope of PAWS. wsdb can reply sensing is required for a set of channels. See CEPT = ECC-195.=20 Teco > Peter S. >=20 > From: Gerald Chouinard > Date: Wed, 8 Feb 2012 10:20:52 -0500 > To: "andy.sago@bt.com" , "jussi.kahtava@nokia.com" = , "scott.probasco@nokia.com" = , "paws@ietf.org" > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to = 3(Introduction, Conventions and Terminology, Prior Work) >=20 > Andy, > =20 > I like your suggestions to broaden it to any bands that are not fully = occupied and for any type of devices. However,white space should be = white and not grey: > =93White Space (WS) > Radio spectrum which is not fully occupied at a = specific location and time.=94 > =20 > Also, White Space devices should not be limited to those that need the = database to operate, RF sensing or other opportunistic means may be = allowed in some cases: > =93White Space device > A device which opportunistically uses some part of the white space = spectrum,under control of a white space database. A = white space device can be an access point, base station, a portable = device or similar. In this context, a A = white space device is Insert>may be required by = local regulations to query a database with its location to obtain = information about available spectrum.=94 > =20 > Gerald > =20 > =20 > From: andy.sago@bt.com [mailto:andy.sago@bt.com]=20 > Sent: Wednesday, 01 February, 2012 05:34 > To: jussi.kahtava@nokia.com; gerald.chouinard@sympatico.ca; = scott.probasco@nokia.com; paws@ietf.org > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to = 3(Introduction, Conventions and Terminology, Prior Work) > =20 > Scott, All > =20 > I agree with Jussi that we have now narrowed the definition to apply = to TV white spaces, whereas the scope of PAWS is white spaces in = general. I would question not only why the lower-priority service would = always be licence-exempt, but why the higher priority service would = always be licenced. To avoid this issue on 27th Jan I proposed = (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a = revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent = services. The Abstract derives from the Introduction and the text could = be aligned to be the same in the Introduction, with =93opportunistic=94 = replacing =93secondary=94 in later sentences in the Introduction. I have = checked and there are no further references to licensing in the = document, so we don=92t need the definitions of licence exempt, light = licensing or unlicensed. This is not a regulatory document =96 we are = defining requirements fora protocol. Keep it simple. > =20 > That just leaves the definition of white space, where the existing = spectrum use has now got muddled with the potential for opportunistic = use. This can be fixed by taking the white space and white space device = definitions together. =46rom Scott, Gerald and Jussi=92s comments = perhaps we could agree on: > =20 > White Space (WS) > =20 > Radio spectrum which is not fully occupied at a specific location and = time. > =20 > White Space device > =20 > A device which opportunistically uses some part of the white space = spectrum, under control of a white space database. A white space device = can be an access point, base station, a portable device or similar. In = this context, a white spacedevice is required by local regulations to = query a database with its location to obtain information about available = spectrum. > =20 > Regards > =20 > Andy > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of jussi.kahtava@nokia.com > Sent: 01 February 2012 07:31 > To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > That statement is valid for TV White Spaces on UHF frequencies but = does not necessarily apply to all under-utilised radio spectrum. Why = would the lower priority service by default be licence-exempt? > =20 > Kind regards, > Jussi > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]On Behalf Of = ext Gerald Chouinard > Sent: 31 January 2012 22:33 > To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Scott, > =20 > Very good improvements. I would suggest to insert the notion of = opportunistic use of the spectrum by white space devices in the last = sentence of the definition of =93white space=94 as follows: > =20 > White Space > =20 > Radio spectrum which has been allocated and assigned for licensed use, = but is not fully occupied by that licensed use at a specific location = and time. This spectrum is then assigned = allowed bylocal regulations for use = to be used opportunistically as licensed-exempt spectrum = under control of a white space database. > =20 > This way, it is understood that the database does not =93assign=94 = white space devices for them to choose from. > =20 > Gerald > From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] > Sent: Tuesday, 31 January, 2012 15:12 > To: gerald.chouinard@sympatico.ca; paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi Gerald, > =20 > Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower = priority opportunistic service" could indeed by used, but I am guessing = that we would need some explanation of what that means. Since we now = have descriptions of licensed spectrum and license-exempt spectrum, I = used these words. Do these changes remove your concerns? > =20 > I also corrected "location" to "local" in previous text proposed for = "White Space". > =20 > Kind Regards, > Scott > =20 > From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 > To: Scott , "paws@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Scott, > Great proposal. However, I am still a bit nervous about the = definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 = where the notion of secondary use is included. The secondary status is = used in the ITU-R Radio Regulations for a different purpose. In fact, = it is possible that a band has already primary and secondary services = allotted to it and that the White Space operation is a tertiary = opportunistic operation where the two first types of services are not = being used. The use of =93lower priority opportunistic=94 service = rather than =93secondary=94 service would be preferable to describe = white spaceallocations. > =20 > Gerald > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com > Sent: Tuesday, 31 January, 2012 13:56 > To: paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi, > =20 > I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes = to the draft based on the email discussion. > =20 > Below is a copy of chapter 2.2. Terminology. I have inserted new terms = for 'licensed' and 'license-exempt' and made changes to the term 'white = space'. I have tried to work from the perspective that the document = should accurately explain the subject with aim that a reader can = understand the use cases and the subsequent requirements. No doubt we = could include much more text on this topic of spectrum allocation, = assignment, licensing and usage. > =20 > I hope this captures the key points of the discussion. Please do reply = if something is still missing. > =20 > Kind Regards, > Scott > =20 > =20 > 2.2. Terminology > =20 > Database > =20 > In the context of white space and cognitive radio technologies, > the database is an entity which contains current information = about > available spectrum at any given location and other types of > information. > =20 > Device ID > =20 > A unique number for each master device and slave device that > identifies the manufacturer, model number and serial number. > =20 > > Licensed Spectrum > =20 > Spectrum that is acquired by an operator over a given service = area > for a given time period. This is usually done through = auctions,award > (beauty contest), acquisition from secondary market, company = merger & > acquisition, first-come / first-served or by government = allocation > (e.g., public service). > =20 > License-exempt Spectrum > =20 > Spectrum that is not assigned to any specific user. One example = is the 2.4 Ghz ISM band, where RF devices > operate without a formal licensing process. In the USA, = license-exempt spectrum is > Typically referred to as "unlicensed" spectrum. In this document = the terms > license-exempt and unlicensed are used interchangeably. > =20 > > =20 > Location Based Service > =20 > An application or device which provides data, information or > service to a user based on their location. > =20 > Master Device > =20 > A device which queries the WS Database to find out the available > operating channels. > =20 > Protected Entity > =20 > A licensed user of spectrum, when the licensed spectrum = has been assigned as white space spectrum. A = primaryA licensed user of white space spectrum = which is afforded > protection against interference by = secondarylicense-exempt white space = users (white space > devices) for its use in a given area and time. > =20 > Protected Contour > =20 > The exclusion area for a Protected Entity, held in the database > and expressed as a polygon with geospatial points as the = vertices. > =20 > Slave Device > =20 > A device which uses the spectrum made available by a master > device. > =20 > TV White Space > =20 > TV white space refers specifically to radio spectrum which has > been allocated for TV broadcast, but is not occupied by a TV > broadcast, or other licensed user (such as a wireless = microphone), > at a specific location and time. > =20 > White Space > =20 > Radio spectrum which has been allocated for someprimary = useand assigned for licensed use, but > is not fully occupied by that primary = use licensed use at a specificlocation > and time. This spectrum is then assigned by = locationlocal regulations for use as = licensed-exempt spectrum under control of a white space = database. > =20 > White Space Device (WSD) > =20 > A device which is a = secondarylicense-exempt user of some = part of white space > spectrum. A white space device can be an access point, base > station, a portable device or similar. In this context, a white > space device is required to query a database with its location = to > obtain information about available spectrum. > =20 > =20 > =20 > From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 > To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Nancy, > =20 > This is not that simple. In fact, the qualifiers =93license-exempt=94 = and =93unlicensed=94 can apply to more than one thing. > =20 > If the qualifier applies to a frequency band, different options exist. = As an example, in the ITU-R context, an =93unlicensed=94 band is = typically a new band, say in the 300 GHz, for which no request has been = made for its use. It is therefore un-allocated to a specific service so = far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R = allocates this band to one or many services on a primary or secondary = basis, then the administrations can thendecide under what king of regime = it will =91assign=92 this band foroperation. They may decide to allow = the use of the band on the basis of licensed operation (with different = options to do the assignment: auction, first come/first served, etc.) or = allow operation with an exemption of licenses, thus =93license-exempt=94su= ch as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in = the USA. > =20 > If the qualifier applies to an operation, the operation can be exempt = of license by the local administration, thus a =93license-exempt=94 = operation. If, however, someone decides to start an RF transmission = operation in a licensed band for which he has no license or in a = license-exempt band for which he does not meet the requirements such as = operating according to the type of operation for which the band is = exempted from a license or he operates outside the technical limits = imposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an =93unlicensed=94 = operation. > =20 > If the qualifier applies to the transmission device, such device may = be a =93license-exempt=94 device if its operation does not require a = specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if = someone smuggles a device that is not allowed in a country by, for = example, buying it on eBay and operates it, this is then an illegal = device in the country and id de-facto an =93unlicensed=94 device since = it has not passed through the normal certification process. > =20 > Note that a =93license-exempt=94 device still has to go through a = certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band = whereas an =93unlicensed=94 device may not pass the certification = process since it has not been licensed to operation in the country. > =20 > This is why the qualifier =93unlicensed=94 has to be treated with care = and the footnote will need to be crafted very carefully. > =20 > With respect to your second point, if an administration only allows = =93licensed=94 operation, the situation will be much simpler to manage = since specific conditions will be attached to these licenses. > =20 > Gerald > =20 > From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 > Sent: Tuesday, 31 January, 2012 06:33 > To: Gerald Chouinard > Cc: Gabor.Bajko@nokia.com; paws@ietf.org > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Gabor and Gerald,=20 > Since we are dealing on a global basis, can there a footnote to = "unlicensed" we can use to indicate that "according to each countries = regulatory requirements" =20 > How to get around the fact that some Countries are or will be = "licensed only" by their gov'ts? Thanks > Nancy > On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: > =20 >=20 > Gabor, > =20 > I agree with your proposal. Thisseems to be reasonable. However one = needs to be careful with the word=91unlicensed=92 which may mean = =91illegal=92 operation of an RF device in many administrations. > =20 > Gerald > =20 > From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 > Sent: Monday, 30 January, 2012 17:49 > To: gerald.chouinard@sympatico.ca; paws@ietf.org > Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > These look to be very precise definitions, however in everyday use I = rarely hear people referring to ISM band as =91license-exempt=92, in = most cases the term =91unlicensed-band=92 is used. > =20 > Therefore, may I suggest that the draft will include the following = statement: > =20 > The terms unlicensed and license-exempt spectrum are used in this = document interchangeably and refer to a spectrum in which no formal = licensing process is needed for RF devices to operate in, such as the = ISM band. > =20 > - Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard > Sent: Monday, January 30, 2012 12:30 PM > To: paws@ietf.org > Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > All, > =20 > Here is my understanding of the terms: > =20 > Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). > =20 > Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos that would = normally work with full licensing through auction over large service = areas. > =20 > License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. > =20 > Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. > =20 > To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. > =20 > Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I would suggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. > =20 > Gerald > _______________________________________________ > 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 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws --Apple-Mail=_7D30AE30-B6F7-48C4-B070-2FDE09FE9E3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Peter = S.

From: Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Wed, 8 Feb = 2012 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "jussi.kahtava@nokia.com" = <jussi.kahtava@nokia.com>, = "scott.probasco@nokia.com"= <scott.probasco@nokia.com>,= "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3(Introduction, Conventions and = Terminology, Prior Work)

Andy,
<= div class=3D"MsoNormal"> 
=
I like your suggestions to broaden = it to any bands that are not fully occupied and for any type of devices. = However,white space should be white and not = grey:
=93White Space (WS)
 Radio = spectrum which is not <delete>fully<delete> occupied at a specific = location and time.=94
 
Also, White Space devices should = not be limited to those that need the database to operate, RF sensing or other opportunistic means may be allowed in some = cases:
=93White = Space device
A device = which opportunistically uses some part of the white space = spectrum<delete>,under control of a white space = database<delete>.  A white space device can be an access point, base station, a portable device or similar.  <delete>In this context, a<delete> = <insert>A<insert> white space device<delete> is<delete> Insert>may = be<insert> required by local regulations to query a database with its location to = obtain information about available = spectrum.=94
 
Gerald
 
=
 
=
From: andy.sago@bt.com [mailto:andy.sago@bt.com] =
Sent: Wednesday, 01 = February, 2012 05:34
To: jussi.kahtava@nokia.com; = gerald.chouinard@sympatico.c= a; scott.probasco@nokia.com; = paws@ietf.org
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and = Terminology, Prior Work)
 
Scott, = All
 
I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only = why the lower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th = Jan I proposed (h= ttp://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it = simple.
 
That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  =46rom Scott, = Gerald and Jussi=92s comments perhaps we could agree = on:
 
White Space = (WS)
 
Radio = spectrum which is not fully occupied at a specific location and = time.
 
White Space = device
 
A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white = spacedevice is required by local regulations to query a database with = its location to obtain information about available = spectrum.
 
Regards<= /o:p>
 
Andy
 
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of jussi.kahtava@nokia.com
= Sent: 01 February 2012 = 07:31
To: = gerald.chouinard@sympatico.c= a; scott.probasco@nokia.com; = paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?
 
Kind = regards,
Jussi
 
From: paws-bounces@ietf.org [mailto:paws-bounces@ie= tf.org]On Behalf Of = ext Gerald Chouinard
Sent: 31 January 2012 = 22:33
To: Probasco = Scott (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
Scott,
=
 
=
Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of =93white space=94 as = follows:
 
=
White = Space
 
Radio = spectrum which has been allocated and assigned for licensed use, but is not fully = occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> = bylocal regulations <delete>for use<delete> <insert>to = be used opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>
 
=
This way, it is understood that the database does not =93assign=94 white space devices for them to choose from.
 
=
Gerald
=
From: scott.probasco@nokia.com [mailto:scott.probas= co@nokia.com]
Sent: = Tuesday, 31 January, 2012 15:12
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
Hi = Gerald,
 
Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your = concerns?
 
I also = corrected "location" to "local" in previous text proposed for "White Space".
 
Kind = Regards,
Scott
 
From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>,= "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior = Work)
 
S= cott,
G= reat proposal.  However, I am still a bit nervous about the definitions = of =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In fact, = it is possible that a band has already primary and secondary services allotted = to it and that the White Space operation is a tertiary opportunistic operation = where the two first types of services are not being used.  The use of =93lower priority opportunistic=94 service rather than =93secondary=94 service would be preferable to describe white = spaceallocations.
&= nbsp;
G= erald
&= nbsp;
From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] = On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 <= /span>
Hi,
 
I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the draft based on the email discussion.
 
Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage.
 
I hope this captures the key points of the discussion. Please do reply if something is still missing.
 
Kind Regards,
Scott
 
 
<= div class=3D"MsoNormal">2.2.  Terminology
 
   Database
 
      In the context of white space and cognitive radio = technologies,
      the database is an entity which contains current = information about
      available spectrum at any given location and other types = of
      information.
 
   Device ID
 
     A unique number for each master device and = slave device that
      identifies the manufacturer, model number and serial = number.
 
<Insert>
<= div class=3D"MsoNormal">   Licensed Spectrum
 
      Spectrum that is acquired by an operator over a given = service area
      for a given time period.  This is usually done through auctions,award
      (beauty contest), acquisition from secondary market, = company merger &
      acquisition,  first-come / first-served or by = government allocation
      (e.g., public service).
 
=
   License-exempt Spectrum
 
      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices
      operate without a formal licensing process. In the = USA, license-exempt spectrum is
      Typically referred to as "unlicensed" spectrum. In this document the terms
      license-exempt and unlicensed are used = interchangeably.
 
</Insert>
 
   Location Based Service
 
      An application or device which provides data, information = or
      service to a user based on their = location.
 
   Master Device
 
      A device which queries the WS Database to find out the = available
      operating channels.
 
   Protected Entity
 
      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded
      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white space
      devices) for its use</Delete> in a given area and = time.
 
   Protected Contour
 
      The exclusion area for a Protected Entity, held in the = database
      and expressed as a polygon with geospatial points as the = vertices.
 
   Slave Device
 
      A device which uses the spectrum made available by a = master
      device.
 
   TV White Space
 
      TV white space refers specifically to radio spectrum which = has
      been allocated for TV broadcast, but is not occupied by a = TV
      broadcast, or other licensed user (such as a wireless = microphone),
      at a specific location and time.
 
   White Space
 
      Radio spectrum which has been allocated <Delete>for = someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but
      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation
      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>
 
   White Space Device (WSD)
 
     A device which is a = <Delete>secondary</Delete><Insert>license-exempt</Ins= ert> user of some part of white space
      spectrum.  A white space device can be an access = point, base
      station, a portable device or similar.  In this = context, a white
      space device is required to query a database with its = location to
      obtain information about available = spectrum.
 
 
=
 
From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
<= div class=3D"MsoNormal">Nancy,
&= nbsp;
T= his is not that simple.  In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to more than one thing.
&= nbsp;
I= f the qualifier applies to a frequency band, different options exist. As an = example, in the ITU-R context, an =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its = use.  It is therefore un-allocated to a specific service so far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in the USA.
&= nbsp;
I= f the qualifier applies to an operation, the operation can be exempt of = license by the local administration, thus a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an =93unlicensed=94 operation.
&= nbsp;
I= f the qualifier applies to the transmission device, such device may be a =93license-exempt=94 device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an =93unlicensed=94 device since it has not passed through the normal certification process.
&= nbsp;
N= ote that a =93license-exempt=94 device still has to go through a certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band whereas an =93unlicensed=94 device may not pass the certification process since it has not been licensed to operation in the country.
&= nbsp;
T= his is why the qualifier =93unlicensed=94 has to be treated with care and the footnote will need to be crafted very carefully.
&= nbsp;
W= ith respect to your second point, if an administration only allows =93licensed=94 operation, the situation will be much simpler to manage since specific conditions will be attached to these = licenses.
&= nbsp;
G= erald
&= nbsp;
From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; = paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 <= /span>
Gabor and = Gerald, 
Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements"  
How to get = around the fact that some Countries are or will be "licensed only" by their gov'ts?  Thanks
Nancy
=
On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:

 

G= abor,
&= nbsp;
I= agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word=91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many = administrations.
&= nbsp;
G= erald
&= nbsp;
From: Gabor.Bajko@nokia.com = [mailto:Gabor.Bajko@nokia.com] =
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 <= /span>
These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.
 
Therefore, may I suggest that the draft will include the following = statement:
 
The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.
 

-          Gabor

 
From: paws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] = On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 <= /span>
= All,
=  
H= ere is my understanding of the terms:
&= nbsp;
L= icensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).
&= nbsp;
L= ightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in = Canada) and not big Telcos that would normally work with full licensing through auction = over large service areas.
&= nbsp;
L= icense-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, = this term is used for a specific type of operation. The FCC should be contacted to clarify = it.
&= nbsp;
U= nlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, = this term is used to mean =93license-exempt," see above.
&= nbsp;
T= o my knowledge, the term =93unlicensed=94 is used only in the = USA to describe a legal operation because the term =93license-exempt=94 has been used for another specific purpose.
&= nbsp;
S= ince the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I = would suggest the use of =91licensed=92 and =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the = USA instead of the usual =91license-exempt=92.
&= nbsp;
G= erald

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws

 <= /span>
_______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/m= ailman/listinfo/paws
_______________________________________________
paws mailing = list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws

= --Apple-Mail=_7D30AE30-B6F7-48C4-B070-2FDE09FE9E3F-- From scott.probasco@nokia.com Wed Feb 8 13:16:18 2012 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 27E8621F853B for ; Wed, 8 Feb 2012 13:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88slnT8y6lly for ; Wed, 8 Feb 2012 13:16:17 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6669B21F8535 for ; Wed, 8 Feb 2012 13:16:17 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q18LGE91000702 for ; Wed, 8 Feb 2012 23:16:16 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 23:16:15 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Wed, 8 Feb 2012 22:16:15 +0100 From: To: Thread-Topic: [paws] UC&R I-D: section 4.9 (Indoor networking) Thread-Index: AQHM5qbjU+pzrSykQUaPgHtpLT2cOg== Date: Wed, 8 Feb 2012 21:16:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: <928AE141CB65154DA0222E6487610E54@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 21:16:15.0675 (UTC) FILETIME=[E456B8B0:01CCE6A6] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: section 4.9 (Indoor networking) 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, 08 Feb 2012 21:16:18 -0000 Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for section on the Indoor Networking use case (new section numbering is NOT shown, all use cases will be moved to section 4.2 Use cases in the next version). This text has been marked up from version-02 as uploaded January 26, 2012 as follows: * includes relevant updates from comments to the Hotspot use case * removes "an indication of the quality of the spectrum for each channel" from the database response message. If there is a regulatory requirement for this, the text should not be deleted. Our goal is that any discussion on this text will conclude by February 15. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 4.9. Indoor Networking In this use case, the users are inside a house or office. The users want to have connectivity to the internet or to equipment in the same or other houses / offices. This deployment scenario is typically characterized by master devices within buildings, that are connected to the Internet using a method that does not utilise TV whitespace. The master devices can establish TV whitespace links between themselves, or between themselves and one or more user devices. The figure below shows an example deployment of this scenario. \|/ | +-------+ | |TVWS |\ +-|---------+ |Usr Dev| WS AirIF \ | TVWS |\ +-------+ X|Master Dev | \ / +-----------+ \ +-------+ WS AirIF | \ +----------+ |TVWS |/ | \ (----) | Database | |Usr Dev| | \ ( ) /----------+ +-------+ WS AirIF \ / \ | X( Internet ) | / \ / +-------+ \|/ | / ( ) |TVWS |\ | | / (----) |Usr Dev| WS AirIF | | / +-------+ \ +-|---------+ / \| TVWS | / |Master Dev |/ +-----------+ Figure 9: Example illustration of indoor TV white space use-case A simplified operational scenario utilizing TV whitespace to provide indoor networking consists of the following steps: 1. The master device powers up with its whitespace radio in idle or listen mode only (no active transmission on the whitespace frequency band). 2. The master device has internet connectivity , determines its location (either from location determination capability or from saved value that was set during installation), and establishes a connection to a trusted white space database (see Section 3.1 above reference is to database discovery, will be updated in next version). 3. The master device registers with the trusted database according to regulatory domain requirements (see Section 4.1.2). 4. Following the successful registration process,The master device sends a query to the trusted database requesting a list of available WS channels based upon its geolocation. The complete set of parameters to be provided from the master to the database is specified by the local regulator. Parameters may include WSD location, accuracy of of that location, device antenna height, device identifier of a slave device requesting channel information.its geolocation and location uncertainty information, and optionally additional information which may include (1) device ID and (2) antenna characteristics, to a trusted database, requesting a list of available whitespace channels based upon this information. 5. If the master has met all regulatory requirements,The database responds with a list of available white space channels that the master device may use, and optional information which may include inter alia (1) a duration of time for the use of each channel (channel validity time) (2) a maximum radiated power for each channel, (3) an indication of the quality of the spectrum for each channel and (4) directivity and other antenna information. 6. Once the master device authenticates the whitespace channel list response message from the database, the master device selects one or more available whitespace channels from the list. 7. The user device(s) scan(s) the TV white space bands to locate the master device transmissions, and associates with the master. From Basavaraj.Patil@nokia.com Wed Feb 8 14:00:38 2012 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 87CF911E8080 for ; Wed, 8 Feb 2012 14:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.665 X-Spam-Level: X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=-0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wW6Ww4wdAsqh for ; Wed, 8 Feb 2012 14:00:37 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id DADC611E807F for ; Wed, 8 Feb 2012 14:00:36 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q18M0Uv7018528; Thu, 9 Feb 2012 00:00:30 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 00:00:29 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Wed, 8 Feb 2012 23:00:29 +0100 From: To: , , Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAHW0EA Date: Wed, 8 Feb 2012 22:00:28 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F43@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.28] Content-Type: text/plain; charset="utf-8" Content-ID: <811C8FAABF21B64EA2B597DCE342E22B@mgd.nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 22:00:30.0004 (UTC) FILETIME=[12712F40:01CCE6AD] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 08 Feb 2012 22:00:38 -0000 DQpIaSBQYXVsLA0KDQpPbiAyLzMvMTIgNDo1OCBQTSwgImV4dCBQYXVsIExhbWJlcnQiIDxwYXVs QG1hcnZlbGwuY29tPiB3cm90ZToNCg0KPg0KPkhpIFJhaiwNCj4NCj5GaXJzdCAtIGEgdGhyZWF0 IG5lZWRzIGFuIGFjdG9yIG9yIHNvdXJjZS4gIFdlIHNlZW0gdG8gaGF2ZSBkaWZmZXJlbnQNCj52 aWV3cyBvZiBwb3NzaWJsZSBzb3VyY2VzLg0KPg0KPj4+Pj4+IFRocmVhdCA3OiBUZXJtaW5hdGlv biBvZiBkZXZpY2Ugc2VydmljZSBmb3IgcmVhc29ucyBvdGhlciB0aGFuDQo+Pj4+Pj4gICAgICAg ICBpbmN1bWJlbnQgcHJvdGVjdGlvbg0KPlRlcm1pbmF0aW9uIG9mIGRldmljZSBzZXJ2aWNlIGlz IHRoZSBlbmQtaW1wYWN0IChhIHVzZWZ1bCBzdGFydGluZyBwb2ludCwNCj5idXQgbm90IGV4YWN0 bHkgdGhlIHRocmVhdCkuDQoNCkFzc3VtaW5nIHRoYXQgdGhlcmUgZXhpc3RzIHRoZSBhYmlsaXR5 IHRvIHNlbmQgYW4gdW5zb2xpY2l0ZWQgcHVzaA0Kbm90aWZpY2F0aW9uIHRvIHRoZSBtYXN0ZXIg ZGV2aWNlIHRvIGN1cnRhaWwgc2VydmljZSBmcm9tIHRoZSBkYXRhYmFzZSwNCnRoZSB0aHJlYXQg aGVyZSBpcyB0aGUgcG9zc2liaWxpdHkgb2YgYW4gYXR0YWNrZXIgc2VuZGluZyBzdWNoIGEgbWVz c2FnZQ0KdG8gYSBtYXN0ZXIgZGV2aWNlLg0KT2YgY291cnNlIHRoZSBwcm90b2NvbCBjb3VsZCBi ZSBkZXNpZ25lZCB0byBlbnN1cmUgdGhhdCB0aGUgbWFzdGVyIGRldmljZQ0KdmVyaWZpZXMgdGhl IG1lc3NhZ2UgZm9yIGF1dGhlbnRpY2l0eSBldGMuLCBidXQgdGhlIHRocmVhdCBpdHNlbGYgZXhp c3RzLg0KDQo+IA0KPg0KPg0KPlNvbWUgb2YgdGhlIGFzc29jaWF0ZWQgdGhyZWF0IGV2ZW50cyBh cmU6DQo+DQo+IGEpIEdvdmVybm1lbnQgKHJlbGF0ZWQgdG8gcmVndWxhdG9yeSBhdXRob3JpdHkg b3Igbm90KSB1c2VzIFdTIERhdGFiYXNlDQo+dG8gdGVybWluYXRlIG9yIHVuZmFpcmx5IGxpbWl0 DQo+ICAgIHNwZWN0cnVtIGFjY2VzcyBvZiBkZXZpY2VzIGZvciByZWFzb25zIG90aGVyIHRoYW4g aW5jdW1iZW50DQo+cHJvdGVjdGlvbi4NCj4gYikgU2VydmljZSBwcm92aWRlciBvciBEQiBwcm92 aWRlciB1c2VzIFdTIERhdGFiYXNlIHRvIHRlcm1pbmF0ZSBvcg0KPnVuZmFpcmx5IGxpbWl0DQo+ ICAgIHNwZWN0cnVtIGFjY2VzcyBvZiBkZXZpY2VzIGZvciByZWFzb25zIG90aGVyIHRoYW4gaW5j dW1iZW50DQo+cHJvdGVjdGlvbi4NCj4gYykgT3duZXIgb2YgYSBNYXN0ZXIgZGV2aWNlIHVzZXMg V1MgRGF0YWJhc2UgdG8gdGVybWluYXRlIG9yIHVuZmFpcmx5DQo+bGltaXQNCj4gICAgc3BlY3Ry dW0gYWNjZXNzIG9mIGRldmljZXMgZm9yIHJlYXNvbnMgb3RoZXIgdGhhbiBpbmN1bWJlbnQNCj5w cm90ZWN0aW9uLg0KPiBkKSBNYWxpY2lvdXMgaW5kaXZpZHVhbCBhY3RzIGFzIGEgUEFXUyBlbnRp dHkgKHNwb29maW5nIERCIG9yIGFzIE1pTSkgdG8NCj50ZXJtaW5hdGUgb3IgdW5mYWlybHkgbGlt aXQNCj4gICAgc3BlY3RydW0gYWNjZXNzIG9mIGRldmljZXMgZm9yIHJlYXNvbnMgb3RoZXIgdGhh biBpbmN1bWJlbnQgcHJvdGVjdGlvbg0KPiBlKSBOYXR1cmFsIGRpc2FzdGVyIGtub2NrcyBvdXQg Y29tbXVuaWNhdGlvbnMgdG8gdGhlIGRhdGFiYXNlIHByZXZlbnRpbmcNCj5zcGVjdHJ1bSBhY2Nl c3MuDQo+DQo+DQo+SXQgc2VlbXMgc2lsbHkgZm9yIHVzIHRvIHJ1c2ggc28gcXVpY2tseSBpbnRv IGJ1aWxkaW5nIHRoZSBmYXN0ZXN0DQo+cG9zc2libGUga2lsbCBzd2l0Y2ggZm9yIGNvbW11bmlj YXRpb25zLiAgUHVzaCBub3RpZmljYXRpb25zIGFyZSBhIGNvb2wNCj5tZWNoYW5pc21zLCBidXQg d2UgYWxzbyBuZWVkIHNvbWUgbGV2ZWwgb2YgYXNzdXJhbmNlIHRoYXQgd2Ugd2lsbCBoYXZlDQo+ Y29udGludWl0eSBvZiB1c2FnZSBvZiBhIHNldCBvZiBjaGFubmVscy4NCg0KV2UgcHJldmlvdXNs eSBkaXNjdXNzZWQgdGhlIG5lZWQgZm9yIGEga2lsbCBzd2l0Y2ggYW5kIG15IHJlY29sbGVjdGlv biBpcw0KdGhhdCBpdCBpcyBhIG5pY2UtdG8taGF2ZSBmZWF0dXJlIGFuZCBub3Qgc29tZXRoaW5n IHRoYXQgaXMgbWFuZGF0b3J5Lg0KUmVndWxhdG9yeSBlbnZpcm9ubWVudHMgd2lsbCBjaG9vc2Ug dG8gZGVmaW5lIHdoZXRoZXIgaXQgaXMgcmVxdWlyZWQgb3INCm5vdC4gIFRoZSB0aHJlYXQgZGVz Y3JpYmVkIGluICg3KSBpcyBzaW1wbHkgYmFzZWQgb24gdGhlIGFzc3VtcHRpb24gb2YNCnN1Y2gg YSBmZWF0dXJlIGV4aXN0aW5nLg0KDQotUmFqDQoNCj5JZGVhbGx5IHdlJ2QgaGF2ZSBzb21lIGxv b3NlciBsaW1pdHMgb24gdGhlIG9uLWNoYW5uZWwgdGltZXMuDQo+DQo+UGF1bA0KPg0KPg0KPg0K Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBCYXNhdmFyYWouUGF0aWxAbm9r aWEuY29tIFttYWlsdG86QmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbV0NCj4+U2VudDogRnJpZGF5 LCBGZWJydWFyeSAwMywgMjAxMiAyOjM1IFBNDQo+PlRvOiBQYXVsIExhbWJlcnQ7IGptaEBqb2Vs aGFscGVybi5jb207IEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6DQo+PkNjOiBwYXdzQGlldGYub3Jn DQo+PlN1YmplY3Q6IFJlOiBbcGF3c10gVGhyZWF0IG1vZGVsIChSZXYgMykNCj4+DQo+Pg0KPj5I aSBQYXVsLg0KPj4NCj4+T24gMi8zLzEyIDQ6MjYgUE0sICJleHQgUGF1bCBMYW1iZXJ0IiA8cGF1 bEBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+Pg0KPj4+DQo+Pj4+Pj4gVGhyZWF0IDc6IFRlcm1pbmF0 aW9uIG9mIGRldmljZSBzZXJ2aWNlIGZvciByZWFzb25zIG90aGVyIHRoYW4NCj4+Pj4+PiAgICAg ICAgIGluY3VtYmVudCBwcm90ZWN0aW9uDQo+Pj4+Pj4NCj4+Pj4+PiAgICAgICAgIEEgd2hpdGUg c3BhY2UgZGF0YWJhc2UgbWF5IGluY2x1ZGUgYSBtZWNoYW5pc20gYnkgd2hpY2gNCj4+Pj4+PnNl cnZpY2UNCj4+Pj4+PiAgICAgICAgIGFuZCBjaGFubmVscyBhbGxvY2F0ZWQgdG8gYSBtYXN0ZXIg ZGV2aWNlIGNhbiBiZSByZXZva2VkLiBBDQo+Pj4+Pj4gICAgICAgICBtYWxpY2lvdXMgbm9kZSBj YW4gc2VuZCBhIHJldm9rZSBtZXNzYWdlIHRvIGEgbWFzdGVyDQo+Pj4+Pj4gICAgICAgICBkZXZp Y2UuIFRoaXMgcmVzdWx0cyBpbiBkZW5pYWwgb2Ygc2VydmljZSB0byB0aGUgbWFzdGVyDQo+Pj4+ Pj4gICAgICAgICBkZXZpY2UuDQo+Pj4NCj4+Pk5vIGNsdWUgd2hhdCB5b3UgbWVhbiBieSAibWFs aWNpb3VzIG5vZGUiIC4uLiB0aGlzIGNvdWxkIGJlIGEgRGF0YWJhc2UsDQo+Pj5NYXN0ZXIsIHJh bmRvbSBNaU0sIGV0Yy4NCj4+DQo+Pk15IGludGVycHJldGF0aW9uIG9mIHRoZSBhZGRpdGlvbmFs IHRocmVhdCB5b3UgaGFkIHN1Z2dlc3RlZCBpbiBhDQo+PnByZXZpb3VzDQo+PmVtYWlsxaAuDQo+ PlRoZSBwb2ludCBhYm91dCB0aGlzIHRocmVhdCBpcyB0aGF0IHdlIGhhdmUgZGlzY3Vzc2VkIGFi b3V0IHRoZQ0KPj5wb3NzaWJpbGl0eSBvZiB0aGUgZGF0YWJhc2UgaGF2aW5nIHRoZSBjYXBhYmls aXR5IHRvIHNlbmQgYW4gdW5zb2xpY2l0ZWQNCj4+cHVzaCBub3RpZmljYXRpb24gKHRvIHRoZSBt YXN0ZXIgZGV2aWNlKSBmb3IgcmV2b2tpbmcgdGhlIHByZXZpb3VzbHkNCj4+YWxsb2NhdGVkIGNo YW5uZWxzIGFuZCBjZWFzaW5nIG9wZXJhdGlvbi4NCj4+U28gdGhlICJtYWxpY2lvdXMgbm9kZSIg aW4gdGhpcyBjYXNlIGlzIGFuIGVudGl0eSB3aGljaCBwcmV0ZW5kcyB0byBiZQ0KPj50aGUNCj4+ ZGF0YWJhc2UgYW5kIHNlbmRzIHN1Y2ggYSBwdXNoIG5vdGlmaWNhdGlvbiBtZXNzYWdlIHRvIHRo ZSBtYXN0ZXINCj4+ZGV2aWNlLg0KPj4NCj4+Pg0KPj4+DQo+Pj5JIHdhcyByZWFsbHkgdGhpbmtp bmcgbW9yZSBhYm91dCB0aGUgbWlzdXNlIG9mIHRoZSBEYXRhYmFzZSwgb3IgTWFzdGVyDQo+PnRv Og0KPj4+IC0gdHVybiBvZmYgZGV2aWNlcyBwcmVzdW1lZCB0byBiZSB2aW9sYXRpbmcgdGhlIERD TUENCj4+DQo+PkRDTUE/DQo+PlRoZSBhc3BlY3Qgb2YgYSBkZXZpY2UgYmVpbmcgc3dpdGNoZWQg b2ZmIGlzIGNvdmVyZWQgaW4gdGhpcyB0aHJlYXQuDQo+Pg0KPj4+IC0gbGltaXRpbmcgc3BlY3Ry dW0gdXNhZ2UgYmFzZWQgb24gdGhlIHR5cGUgb3IgcHVycG9zZSBvZiB0aGUgdHJhZmZpYw0KPj4+ KGUuZy4gT2FrbGFuZCBCQVJUKQ0KPj4+IC0gbGltaXRhdGlvbiBvZiBzcGVjdHJ1bSB1c2FnZSBi YXNlZCBvbiBwb2xpdGljYWwgYWZmaWxpYXRpb24sIHJhY2UsDQo+Pj5nZW5kZXIsIGlkZW9sb2d5 LA0KPj4+ICAgaW5kaXZpZHVhbCBpZGVudGl0eSwgZXRjLg0KPj4NCj4+SSBkb24ndCBnZXQgdGhl IGFib3ZlIHR3by4gQ2FyZSB0byBleHBhbmQgb24gdGhlc2U/DQo+Pg0KPj4+DQo+Pj5XZSBtYXkg bm90IGJlIGFibGUgdG8gcHJldmVudCAoYXQgYSBwcm90b2NvbCBsZXZlbCkgdW5mYWlyIGFsbG9j YXRpb24NCj4+b3INCj4+PmRpc2FibGVtZW50LiBXZSBzaG91bGQgYXQgbGVhc3QgYmUgYWJsZSB0 byBoYXZlIGFkZXF1YXRlIGxvZ2dpbmcgYW5kDQo+Pj5yZWNvcmRzIHRoYXQgZ2l2ZW4gYW4gZXhw ZWN0YXRpb24gb2YgZmFpciBhbGxvY2F0aW9uIC0gd2UgY2FuIGRldGVjdA0KPj5hbmQNCj4+PmNv bXBsYWluIHdoZW4gb3VyIG1vYmlsZSBkZXZpY2VzIGFyZSB0dXJuZWQgb2ZmLg0KPj4NCj4+U28g ZG8gd2UgbmVlZCB0byBjYXB0dXJlIHRoaXMgaW4gdGhlIGZvcm0gb2YgYSB0aHJlYXQ/IERvIHdl IHdhbnQgdG8NCj4+aGF2ZQ0KPj5hIHJlcXVpcmVtZW50IHRoYXQgdGhlIHByb3RvY29sIG5lZWRz IHRvIGVuYWJsZSBsb2dnaW5nIGFuZCByZWNvcmQNCj4+a2VlcGluZz8gVGhhdMK5cyBtb3JlIG9m IGFuIGltcGxlbWVudGF0aW9uIGlzc3VlLg0KPj4NCj4+LVJhag0KPj4NCj4+Pg0KPj4+UGF1bA0K Pj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+PkZyb206IHBhd3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmDQo+Pk9mDQo+Pj4+Sm9lbCBNLiBIYWxwZXJuDQo+Pj4+U2VudDogRnJp ZGF5LCBGZWJydWFyeSAwMywgMjAxMiAxMjowMSBQTQ0KPj4+PlRvOiBSb3NlbiwgQnJpYW4NCj4+ Pj5DYzogcGF3c0BpZXRmLm9yZw0KPj4+PlN1YmplY3Q6IFJlOiBbcGF3c10gVGhyZWF0IG1vZGVs IChSZXYgMykNCj4+Pj4NCj4+Pj5JbiB0aGUgdW5hdXRob3JpemVkIHVzZSBzZWN0aW9uLCB0aGVy ZSBpcyBzdGlsbCB0aGUgdGV4dCBzYXlpbmc6DQo+Pj4+ICAgICAgICBUaGUgYXR0YWNrZXIgbWF5 IGxpc3RlbiB0bw0KPj4+PiAgICAgICAgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBhIHZhbGlk IG1hc3RlciBkZXZpY2UgYW5kIHdoaXRlDQo+PnNwYWNlDQo+Pj4+ICAgICAgICBkYXRhYmFzZSBh bmQgdXRpbGl6ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgYXZhaWxhYmxlIGNoYW5uZWxzDQo+Pj4+ ICAgICAgICBpbiB0aGUgcmVzcG9uc2UgbWVzc2FnZSBieSB1dGlsaXppbmcgdGhvc2UgY2hhbm5l bHMuDQo+Pj4+DQo+Pj4+SSBzdGlsbCBmaW5kIHRoaXMgdG90YWxseSBtaW5kLWJlbmRpbmcsIGFz IGl0IGlzIGFib3V0IHRoZSBoYXJkZXN0IHdheQ0KPj4+PmltYWdpbmFibGUgdG8gdW5kZXJ0YWtl IHRoaXMgYXR0YWNrLg0KPj4+Pg0KPj4+Pg0KPj4+Pk9uIDIvMy8yMDEyIDI6NTUgUE0sIFJvc2Vu LCBCcmlhbiB3cm90ZToNCj4+Pj4+IDxhcyBpbmRpdmlkdWFsPg0KPj4+Pj4gV2hlcmUgZG8geW91 IHNlZSB0aGlzIGFzc3VtcHRpb24gaW4gdGhlIHRocmVhdCBtb2RlbD8NCj4+Pj4+DQo+Pj4+PiBJ IHRvb2sgYSBxdWljayBsb29rIGFuZCBkaWRuJ3Qgc3BvdCBpdC4gIEl0IHdvdWxkIGJlICJkYXRh YmFzZQ0KPj4+PmluZm9ybWF0aW9uIGxlYWtlZCB0byBiYWQgZ3V5cyIgb3Igc29tZXRoaW5nIGxp a2UgaXQsIHJpZ2h0Pw0KPj4+Pj4NCj4+Pj4+IEkgZG9uJ3QgdGhpbmsgdGhhdCBpcyBhIHRocmVh dCwgYW5kIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCB0byBwcm90ZWN0DQo+Pj4+YW55b25lIGZyb20g dGhhdCB0aHJlYXQuDQo+Pj4+Pg0KPj4+Pj4gSSB3b3VsZCBzYXksIGhvd2V2ZXIsIHRoYXQgaWYg eW91IGNvdWxkIGtub3cgdGhlIGNvbnRlbnQgb2YgdGhlDQo+Pj4+ZGF0YWJhc2UsIGFuZCB5b3Ug Y2FuIG9ic2VydmUgYSByZXNwb25zZXMgb3ZlciBhIHBlcmlvZCBvZiB0aW1lLCB5b3UNCj4+bWF5 DQo+Pj4+YmUgYWJsZSB0byBpbmZlciB0aGUgbG9jYXRpb24gb2YgdGhlIHF1ZXJpZXIuDQo+Pj4+ Pg0KPj4+Pj4gQnJpYW4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gT24gRmViIDMsIDIwMTIsIGF0IDI6 NTEgUE0sIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4+Pj4+DQo+Pj4+Pj4gQ2FuIHdlIHBsZWFz ZSBpbmNsdWRlIGluIHRoaXMgZG9jdW1lbnQgc29tZSBhcnRpY3VsYXRpb24gb2YgdGhlDQo+Pj4+ Pj4gY29uZmlkZW50aWFsaXR5IGFzc3VtcHRpb24gd2UgYXJlIG1ha2luZyB3aXRoIHJlZ2FyZCB0 byB0aGUNCj4+Pj53aGl0ZXNwYWNlDQo+Pj4+Pj4gZGF0YSBpdHNlbGY/ICBJIGFtIG5vdCB0cnlp bmcgdG8gb2JqZWN0IHRvIHRoZSB0aHJlYXRzLiAgKEFuZCB0aGUNCj4+Pj4+PiBwZXJzb25hbCBp bmZvcm1hdGlvbiBjb2xsZWN0aW9uIGlzc3VlcyBhcmUgZW5vdWdoIHRvIGpzdXRpZnkNCj4+aW5j bHVkZQ0KPj4+Pj4+IGNvbmZpZGVudGlhbGl0eSBtZWNoYW5pc21zIGluIHRoZSBzb2x1dGlvbnMu KQ0KPj4+Pj4+IEJ1dCBJIGFtIHN0aWxsIHRyeWluZyB0byBnZXQgbXkgaGVhZCBhcm91bmQgdGhp cy4gIFRoZXJlIGFyZSBnb2luZw0KPj50bw0KPj4+PmJlDQo+Pj4+Pj4gaG9hcmRzIG9mIHdoaXRl c3BhY2UgZGV2aWNlcy4gIFRoZXkgd2lsbCBiZSBnZXR0aW5nIHRoZSBkYXRhLCBhbmQNCj4+Pj5l aXRoZXINCj4+Pj4+PiB1c2luZyBpdCB0aGVtc2VsdmVzIG9yIHJldHJhbnNtaXR0aW5nIGl0LiAg VGhlIHJlc3VsdGluZyBkYXRhIG9uZQ0KPj4+Pj4+IHdoaXRlc3BhY2UgYXZhaWxhYmlsaXR5IHdp bGwgYmUgdmlzaWJsZSB0byBwZW9wbGUgYW5kIG9yIGRldmljZXMNCj4+Pj53aGljaA0KPj4+Pj4+ IGFyZSBub3QgY29tcGxldGVseSBjb250cm9sbGVkIGJ5IHRoZSByZWd1bGF0b3J5IGFnZW5jaWVz Lg0KPj4+Pj4+IEFzIHN1Y2gsIHdoYXQgaXMgdGhlIHJvbGUgb2YgY29uZmlkZW50aWFsaXR5IHdp dGggcmVnYXJkIHRvIHRoaXMNCj4+Pj4+PiBpbmZvcm1hdGlvbj8NCj4+Pj4+Pg0KPj4+Pj4+IFlv dXJzLA0KPj4+Pj4+IEpvZWwNCj4+Pj4+Pg0KPj4+Pj4+IE9uIDIvMy8yMDEyIDI6MzQgUE0sIEJh c2F2YXJhai5QYXRpbEBub2tpYS5jb20gd3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEJlbG93IGlz IFJldiAzIG9mIHRoZSB0aHJlYXQgbW9kZWwgYmFzZWQgb24gZmVlZGJhY2sgZnJvbSBTdGVwaGVu LA0KPj4+Pk5hbmN5DQo+Pj4+Pj4+IGFuZCBHYWJvciAoVGhhbmtzKS4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gLVJhag0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBSZXYgMyAoMy8yLzEyKQ0KPj4+Pj4+ Pg0KPj4+Pj4+PiBUaHJlYXQgbW9kZWwgZm9yIHRoZSBQQVdTIHByb3RvY29sDQo+Pj4+Pj4+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQXNzdW1w dGlvbnM6DQo+Pj4+Pj4+IC4uLi4uLi4uLi4uLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBvIEl0IGlzIGFz c3VtZWQgdGhhdCBhbiBhdHRhY2tlciBoYXMgZnVsbCBhY2Nlc3MgdG8gdGhlIG5ldHdvcmsNCj4+ Pj5tZWRpdW0NCj4+Pj4+Pj4gICAgYmV0d2VlbiB0aGUgbWFzdGVyIGRldmljZSBhbmQgdGhlIHdo aXRlIHNwYWNlIGRhdGFiYXNlLiBUaGUNCj4+Pj5hdHRhY2tlcg0KPj4+Pj4+PiAgICBtYXkgYmUg YWJsZSB0byBlYXZlc2Ryb3Agb24gYW55IGNvbW11bmljYXRpb25zIGJldHdlZW4gdGhlc2UNCj4+ Pj4+Pj4gICAgZW50aXRpZXMuIFRoZSBsaW5rIGJldHdlZW4gdGhlIG1hc3RlciBkZXZpY2UgYW5k IHRoZSB3aGl0ZQ0KPj5zcGFjZQ0KPj4+Pj4+PiAgICBkYXRhYmFzZSBjYW4gYmUgd2lyZWQgb3Ig d2lyZWxlc3MgYW5kIHByb3ZpZGVzIElQIGNvbm5lY3Rpdml0eS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4g byBJdCBpcyBhc3N1bWVkIHRoYXQgdGhlIG1hc3RlciBkZXZpY2Ugb3IgdGhlIHdoaXRlIHNwYWNl IGRhdGFiYXNlDQo+Pj4+Pj4+ICAgIGhhdmUgTk9UIGJlZW4gY29tcHJvbWlzZWQgZnJvbSBhIHNl Y3VyaXR5IHN0YW5kcG9pbnQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRocmVhdCAxOiBVc2VyIG1vZGlm aWVzIGEgZGV2aWNlIHRvIG1hc3F1ZXJhZGUgYXMgYW5vdGhlciB2YWxpZA0KPj4+Pj4+PiAgICAg ICAgIGNlcnRpZmllZCBkZXZpY2UNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICBUaGUgbWFzdGVy IGRldmljZSBuZWVkcyB0byBhdXRoZW50aWNhdGUgaXRzZWxmIHdpdGggdGhlDQo+Pj4+d2hpdGUN Cj4+Pj4+Pj4gICAgICAgICBzcGFjZSBkYXRhYmFzZSBwcmlvciB0byByZXF1ZXN0aW5nIGNoYW5u ZWwgaW5mb3JtYXRpb24uDQo+PlRoZQ0KPj4+Pj4+PiAgICAgICAgIGF0dGFja2VyIG1heSB0cnkg dG8gZ2V0IGFjY2VzcyB0byB0aGUgc2VjcmV0cyBvZiB0aGUNCj4+bWFzdGVyDQo+Pj4+Pj4+ICAg ICAgICAgZGV2aWNlIHdoaWNoIGNhbiBiZSB1c2VkIG1hbGljaW91c2x5LiBUaGUgZWZmZWN0IG9m IHN1Y2gNCj4+YW4NCj4+Pj4+Pj4gICAgICAgICBhdHRhY2sgYmVpbmcgc3VjY2Vzc2Z1bCB3b3Vs ZCByZXN1bHQgaW4gYSBtYWxpY2lvdXMgY2xpZW50DQo+Pj4+Pj4+ICAgICAgICAgcmVwbGF5aW5n IHRoZSBzdG9sZW4gYXV0aGVudGljYXRpb24vYXV0aG9yaXphdGlvbiBzZWNyZXRzDQo+PnRvDQo+ Pj4+YQ0KPj4+Pj4+PiAgICAgICAgIHdoaXRlIHNwYWNlIGRhdGFiYXNlLg0KPj4+Pj4+Pg0KPj4+ Pj4+PiBUaHJlYXQgMjogU3Bvb2ZlZCB3aGl0ZSBzcGFjZSBkYXRhYmFzZQ0KPj4+Pj4+Pg0KPj4+ Pj4+PiAgICAgICAgIEEgbWFzdGVyIGRldmljZSBkaXNjb3ZlcnMgYSB3aGl0ZSBzcGFjZSBkYXRh YmFzZShzKSB0aHJ1DQo+Pj4+d2hpY2gNCj4+Pj4+Pj4gICAgICAgICBpdCBjYW4gcXVlcnkgZm9y IGNoYW5uZWwgaW5mb3JtYXRpb24uIFRoZSBtYXN0ZXIgZGV2aWNlDQo+Pj4+bmVlZHMNCj4+Pj4+ Pj4gICAgICAgICB0byBlbnN1cmUgdGhhdCB0aGUgd2hpdGUgc3BhY2UgZGF0YWJhc2Ugd2l0aCB3 aGljaCBpdA0KPj4+Pj4+PiAgICAgICAgIGNvbW11bmljYXRlcyB3aXRoIGlzIGFuIGF1dGhlbnRp YyBlbnRpdHkuIFRoZSB3aGl0ZSBzcGFjZQ0KPj4+Pj4+PiAgICAgICAgIGRhdGFiYXNlIG5lZWRz IHRvIHByb3ZpZGUgaXRzIGlkZW50aXR5IHRvIHRoZSBtYXN0ZXINCj4+ZGV2aWNlDQo+Pj4+Pj4+ ICAgICAgICAgd2hpY2ggY2FuIGNvbmZpcm0gdGhlIHZhbGlkaXR5L2F1dGhlbnRpY3R5IG9mIHRo ZQ0KPj5kYXRhYmFzZS4NCj4+Pj5Bbg0KPj4+Pj4+PiAgICAgICAgIGF0dGFja2VyIG1heSBhdHRl bXB0IHRvIHNwb29mIGEgd2hpdGUgc3BhY2UgZGF0YWJhc2UgYW5kDQo+Pj4+Pj4+ICAgICAgICAg cHJvdmlkZSByZXNwb25zZXMgdG8gYSBtYXN0ZXIgZGV2aWNlIHdoaWNoIGFyZSBtYWxpY2lvdXMN Cj4+YW5kDQo+Pj4+Pj4+ICAgICAgICAgcmVzdWx0IGluIHRoZSBtYXN0ZXIgZGV2aWNlIGNhdXNp bmcgaW50ZXJmZXJlbmNlIHRvIHRoZQ0KPj4+PnByaW1hcnkNCj4+Pj4+Pj4gICAgICAgICB1c2Vy IG9mIHRoZSBzcGVjdHJ1bS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhyZWF0IDM6IE1vZGlmeWluZyBh IHF1ZXJ5IHJlcXVlc3QNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICBBbiBhdHRhY2tlciBtYXkg bW9kaWZ5IHRoZSBxdWVyeSByZXF1ZXN0IHNlbnQgYnkgYSBtYXN0ZXINCj4+Pj4+Pj4gICAgICAg ICBkZXZpY2UgdG8gYSB3aGl0ZSBzcGFjZSBkYXRhYmFzZS4gVGhlIGF0dGFja2VyIG1heSBjaGFu Z2UNCj4+Pj50aGUNCj4+Pj4+Pj4gICAgICAgICBsb2NhdGlvbiBvZiB0aGUgZGV2aWNlIG9yIHRo ZSBjYXBhYmlsaXRpZXMgaW4gdGVybXMgb2YgaXRzDQo+Pj4+Pj4+ICAgICAgICAgdHJhbnNtaXQg cG93ZXIgb3IgYW50ZW5uYSBoZWlnaHQgZXRjLiB3aGljaCBjb3VsZCByZXN1bHQNCj4+aW4NCj4+ Pj50aGUNCj4+Pj4+Pj4gICAgICAgICBkYXRhYmFzZSByZXNwb25kaW5nIHdpdGggaW5jb3JyZWN0 IGluZm9ybWF0aW9uIGFib3V0DQo+Pj4+YXZhaWxhYmxlDQo+Pj4+Pj4+ICAgICAgICAgY2hhbm5l bHMgb3IgbWF4IHRyYW5zbWl0IHBvd2VyIGFsbG93ZWQuIFRoZSByZXN1bHQgb2Ygc3VjaA0KPj4+ PmFuDQo+Pj4+Pj4+ICAgICAgICAgYXR0YWNrIGlzIHRoYXQgdGhlIG1hc3RlciBkZXZpY2Ugd291 bGQgY2F1c2UgaW50ZXJlZmVyZW5jZQ0KPj4+PnRvDQo+Pj4+Pj4+ICAgICAgICAgdGhlIHByaW1h cnkgdXNlciBvZiB0aGUgc3BlY3RydW0uIEl0IGNvdWxkIGFsc28gcmVzdWx0IGluDQo+PmENCj4+ Pj4+Pj4gICAgICAgICBkZW5pYWwgb2Ygc2VydmljZSB0byB0aGUgbWFzdGVyIGRldmljZSBieSBp bmRpY2F0aW5nIHRoYXQNCj4+bm8NCj4+Pj4+Pj4gICAgICAgICBjaGFubmVscyBhcmUgYXZhaWxh YmxlLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaHJlYXQgNDogTW9kaWZ5aW5nIGEgcXVlcnkgcmVzcG9u c2UNCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICBBbiBhdHRhY2tlciBjb3VsZCBtb2RpZnkgdGhl IHF1ZXJ5IHJlc3BvbnNlIHNlbnQgYnkgdGhlDQo+Pj4+d2hpdGUNCj4+Pj4+Pj4gICAgICAgICBz cGFjZSBkYXRhYmFzZSB0byBhIG1hc3RlciBkZXZpY2UuIFRoZSBjaGFubmVsIGluZm9ybWF0aW9u DQo+Pj4+b3INCj4+Pj4+Pj4gICAgICAgICB0cmFuc21pdCBwb3dlciBhbGxvd2VkIHR5cGUgb2Yg cGFyYW1ldGVycyBjYXJyaWVkIGluIHRoZQ0KPj4+Pj4+PiAgICAgICAgIHJlc3BvbnNlIGNvdWxk IGJlIG1vZGlmaWVkIGJ5IHRoZSBhdHRhY2tlciByZXN1bHRpbmcgaW4NCj4+dGhlDQo+Pj4+Pj4+ ICAgICAgICAgbWFzdGVyIGRldmljZSB1c2luZyBjaGFubmVscyB0aGF0IGFyZSBub3QgYXZhaWxh YmxlIGF0IGENCj4+Pj4+Pj4gICAgICAgICBsb2NhdGlvbiBvciB0cmFuc21pdHRpbmcgYXQgYSBn cmVhdGVyIHBvd2VyIGxldmVsIHRoYW4NCj4+Pj5hbGxvd2VkDQo+Pj4+Pj4+ICAgICAgICAgcmVz dWx0aW5nIGluIGludGVyZmVyZW5jZSB0byB0aGUgcHJpbWFyeSB1c2VyIG9mIHRoYXQNCj4+Pj4+ Pj4gICAgICAgICBzcGVjdHJ1bS4gQWx0ZXJuYXRpdmVseSB0aGUgYXR0YWNrZXIgbWF5IGluZGlj YXRlIG5vDQo+PmNoYW5uZWwNCj4+Pj4+Pj4gICAgICAgICBhdmFpbGFiaWxpdHkgYXQgYSBsb2Nh dGlvbiByZXN1bHRpbmcgaW4gYSBkZW5pYWwgb2YNCj4+c2VydmljZQ0KPj4+PnRvDQo+Pj4+Pj4+ ICAgICAgICAgdGhlIG1hc3RlciBkZXZpY2UuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRocmVhdCA1OiBV bmF1dGhvcml6ZWQgdXNlIG9mIGNoYW5uZWxzIGJ5IGFuIHVuY2VydGlmaWVkIGRldmljZQ0KPj4+ Pj4+Pg0KPj4+Pj4+PiAgICAgICAgIEFuIGF0dGFja2VyIG1heSBiZSBhIG1hc3RlciBkZXZpY2Ug d2hpY2ggaXMgbm90IGNlcnRpZmllZA0KPj4+PmZvcg0KPj4+Pj4+PiAgICAgICAgIHVzZSBieSB0 aGUgcmVsZXZhbnQgcmVndWxhdG9yeSBib2R5LiBUaGUgYXR0YWNrZXIgbWF5DQo+Pmxpc3Rlbg0K Pj4+PnRvDQo+Pj4+Pj4+ICAgICAgICAgdGhlIGNvbW11bmljYXRpb24gYmV0d2VlbiBhIHZhbGlk IG1hc3RlciBkZXZpY2UgYW5kIHdoaXRlDQo+Pj4+c3BhY2UNCj4+Pj4+Pj4gICAgICAgICBkYXRh YmFzZSBhbmQgdXRpbGl6ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgYXZhaWxhYmxlDQo+Pj4+Y2hh bm5lbHMNCj4+Pj4+Pj4gICAgICAgICBpbiB0aGUgcmVzcG9uc2UgbWVzc2FnZSBieSB1dGlsaXpp bmcgdGhvc2UgY2hhbm5lbHMuIFRoZQ0KPj4+PnJlc3VsdA0KPj4+Pj4+PiAgICAgICAgIG9mIHN1 Y2ggYW4gYXR0YWNrIGlzIHVuYXV0aG9yaXplZCB1c2Ugb2YgY2hhbm5lbHMgYnkgYQ0KPj4+Pm1h c3Rlcg0KPj4+Pj4+PiAgICAgICAgIGRldmljZSB3aGljaCBpcyBub3QgY2VydGlmaWVkIHRvIG9w ZXJhdGUuDQo+Pj4+Pj4+ICAgICAgICAgVGhlIG1hc3RlciBkZXZpY2UgcXVlcnlpbmcgdGhlIHdo aXRlIHNwYWNlIGRhdGFiYXNlIG1heSBiZQ0KPj4+Pj4+PiAgICAgICAgIG9wZXJhdGVkIGJ5IGEg bGF3LWVuZm9yY2VtZW50IGFnZW5jeSBhbmQgdGhlDQo+PmNvbW11bmljYXRpb25zDQo+Pj4+Pj4+ ICAgICAgICAgYmV0d2VlbiB0aGUgZGV2aWNlIGFuZCB0aGUgZGF0YWJhc2UgYXJlIGludGVuZGVk IHRvIGJlDQo+PmtlcHQNCj4+Pj4+Pj4gICAgICAgICBwcml2YXRlLiBBIG1hbGljaW91cyBkZXZp Y2Ugc2hvdWxkIG5vdCBiZSBhYmxlIHRvDQo+PmVhdmVzZHJvcA0KPj4+Pm9uDQo+Pj4+Pj4+ICAg ICAgICAgc3VjaCBjb21tdW5pY2F0aW9ucy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhyZWF0IDY6IFRo aXJkIHBhcnR5IHRyYWNraW5nIG9mIHdoaXRlIHNwYWNlIGRldmljZSBsb2NhdGlvbiBhbmQNCj4+ Pj5pZGVudGl0eQ0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgIEEgd2hpdGUgc3BhY2UgZGF0YWJh c2UgbWF5IHJlcXVpcmUgYSBtYXN0ZXIgZGV2aWNlIHRvDQo+Pj4+cHJvdmlkZQ0KPj4+Pj4+PiAg ICAgICAgIGl0cyBpZGVudGl0eSBpbiBhZGRpdGlvbiB0byBpdHMgbG9jYXRpb24gaW4gdGhlIHF1 ZXJ5DQo+Pj4+cmVxdWVzdC4NCj4+Pj4+Pj4gICAgICAgICBTdWNoIGxvY2F0aW9uL2lkZW50aXR5 IGluZm9ybWF0aW9uIGNhbiBiZSBnbGVhbmVkIGJ5IGFuDQo+Pj4+Pj4+ICAgICAgICAgZWF2ZXNk cm9wcGVyLiBBIG1hc3RlciBkZXZpY2UgbWF5IHByZWZlciB0byBrZWVwIHRoZQ0KPj4+Pj4+PiAg ICAgICAgIGxvY2F0aW9uL2lkZW50aXR5IGluZm9ybWF0aW9uIHNlY3JldC4gSGVuY2UgdGhlIHBy b3RvY29sDQo+Pj4+c2hvdWxkDQo+Pj4+Pj4+ICAgICAgICAgcHJvdmlkZSBhIG1lYW5zIHRvIHBy b3RlY3QgdGhlIGxvY2F0aW9uIGFuZCBpZGVudGl0eQ0KPj4+Pj4+PiAgICAgICAgIGluZm9ybWF0 aW9uIG9mIHRoZSBtYXN0ZXIgZGV2aWNlIGFuZCBwcmV2ZW50IHRyYWNraW5nIG9mDQo+Pj4+Pj4+ ICAgICAgICAgbG9jYXRpb25zIGFzc29jaWF0ZWQgd2l0aCBhIHdoaXRlIHNwYWNlIGRhdGFiYXNl LiBJZg0KPj4+Pj4+PiAgICAgICAgIHJlZ3VsYXRpb25zIGRvIG5vdCByZXF1aXJlIHRoZSBpZGVu dGl0eSBvZiB0aGUgbWFzdGVyDQo+PmRldmljZQ0KPj4+PnRvDQo+Pj4+Pj4+ICAgICAgICAgYmUg cHJvdmlkZWQgdG8gdGhlIHdoaXRlIHNwYWNlIGRhdGFiYXNlLCB0aGUgbWFzdGVyIGlzIG5vdA0K Pj4+Pj4+PiAgICAgICAgIHJlcXVpcmVkIHRvIGluY2x1ZGUgaXRzIGlkZW50aXR5IGluIHRoZSBx dWVyeS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhyZWF0IDc6IFRlcm1pbmF0aW9uIG9m IGRldmljZSBzZXJ2aWNlIGZvciByZWFzb25zIG90aGVyIHRoYW4NCj4+Pj4+Pj4gICAgICAgICBp bmN1bWJlbnQgcHJvdGVjdGlvbg0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgIEEgd2hpdGUgc3Bh Y2UgZGF0YWJhc2UgbWF5IGluY2x1ZGUgYSBtZWNoYW5pc20gYnkgd2hpY2gNCj4+Pj5zZXJ2aWNl DQo+Pj4+Pj4+ICAgICAgICAgYW5kIGNoYW5uZWxzIGFsbG9jYXRlZCB0byBhIG1hc3RlciBkZXZp Y2UgY2FuIGJlIHJldm9rZWQuDQo+PkENCj4+Pj4+Pj4gICAgICAgICBtYWxpY2lvdXMgbm9kZSBj YW4gc2VuZCBhIHJldm9rZSBtZXNzYWdlIHRvIGEgbWFzdGVyDQo+Pj4+Pj4+ICAgICAgICAgZGV2 aWNlLiBUaGlzIHJlc3VsdHMgaW4gZGVuaWFsIG9mIHNlcnZpY2UgdG8gdGhlIG1hc3Rlcg0KPj4+ Pj4+PiAgICAgICAgIGRldmljZS4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4gcGF3cyBtYWls aW5nIGxpc3QNCj4+Pj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+Pj4+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pj4+Pj4NCj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IHBhd3MgbWFpbGluZyBs aXN0DQo+Pj4+Pj4gcGF3c0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj5wYXdzIG1haWxpbmcgbGlzdA0KPj4+ PnBhd3NAaWV0Zi5vcmcNCj4+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Bhd3MNCj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj5wYXdzIG1haWxpbmcgbGlzdA0KPj4+cGF3c0BpZXRmLm9yZw0KPj4+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+DQoNCg== From Basavaraj.Patil@nokia.com Wed Feb 8 14:02:47 2012 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 3CE6E21F84C4 for ; Wed, 8 Feb 2012 14:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.163 X-Spam-Level: X-Spam-Status: No, score=-103.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDPEb5ehe9cl for ; Wed, 8 Feb 2012 14:02:46 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 53E7921F84B8 for ; Wed, 8 Feb 2012 14:02:46 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q18M2ipO008994; Thu, 9 Feb 2012 00:02:44 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 00:02:44 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Wed, 8 Feb 2012 23:02:43 +0100 From: To: , Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YryiWQgAdV7gA= Date: Wed, 8 Feb 2012 22:02:42 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F4D@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <1F5FD0042F4D254A89F01352E44BBD7D@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 22:02:44.0140 (UTC) FILETIME=[6264B6C0:01CCE6AD] X-Nokia-AV: Clean Subject: Re: [paws] Threat model (Rev 3) 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, 08 Feb 2012 22:02:47 -0000 Inline:=20 On 2/3/12 5:03 PM, "ext Paul Lambert" wrote: > >> Threat 3: Modifying a query response > >Not a threat ... perhaps a vulnerability if restated. >Suggest as a mechanism - any modification or spoofing of paws messages >all look about the same from the threat model. It's the actor, and end >impact that is interesting. The point with this threat (or vulnerability if you wish) is to derive a requirement for the protocol to ensure integrity protection for the request/response messages. And the same applies to Threat 4. -Raj > >Paul > > >>-----Original Message----- >>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>Basavaraj.Patil@nokia.com >>Sent: Friday, February 03, 2012 11:34 AM >>To: stephen.farrell@cs.tcd.ie; paws@ietf.org >>Subject: Re: [paws] Threat model (Rev 3) >> >> >>Below is Rev 3 of the threat model based on feedback from Stephen, Nancy >>and Gabor (Thanks). >> >>-Raj >> >> >>Rev 3 (3/2/12) >> >>Threat model for the PAWS protocol >>---------------------------------- >> >>Assumptions: >>............ >> >>o It is assumed that an attacker has full access to the network medium >> between the master device and the white space database. The attacker >> may be able to eavesdrop on any communications between these >> entities. The link between the master device and the white space >> database can be wired or wireless and provides IP connectivity. >> >>o It is assumed that the master device or the white space database >> have NOT been compromised from a security standpoint. >> >>Threat 1: User modifies a device to masquerade as another valid >> certified device >> >> The master device needs to authenticate itself with the white >> space database prior to requesting channel information. The >> attacker may try to get access to the secrets of the master >> device which can be used maliciously. The effect of such an >> attack being successful would result in a malicious client >> replaying the stolen authentication/authorization secrets to a >> white space database. >> >>Threat 2: Spoofed white space database >> >> A master device discovers a white space database(s) thru which >> it can query for channel information. The master device needs >> to ensure that the white space database with which it >> communicates with is an authentic entity. The white space >> database needs to provide its identity to the master device >> which can confirm the validity/authenticty of the database. An >> attacker may attempt to spoof a white space database and >> provide responses to a master device which are malicious and >> result in the master device causing interference to the primary >> user of the spectrum. >> >>Threat 3: Modifying a query request >> >> An attacker may modify the query request sent by a master >> device to a white space database. The attacker may change the >> location of the device or the capabilities in terms of its >> transmit power or antenna height etc. which could result in the >> database responding with incorrect information about available >> channels or max transmit power allowed. The result of such an >> attack is that the master device would cause intereference to >> the primary user of the spectrum. It could also result in a >> denial of service to the master device by indicating that no >> channels are available. >> >>Threat 4: Modifying a query response >> >> An attacker could modify the query response sent by the white >> space database to a master device. The channel information or >> transmit power allowed type of parameters carried in the >> response could be modified by the attacker resulting in the >> master device using channels that are not available at a >> location or transmitting at a greater power level than allowed >> resulting in interference to the primary user of that >> spectrum. Alternatively the attacker may indicate no channel >> availability at a location resulting in a denial of service to >> the master device. >> >>Threat 5: Unauthorized use of channels by an uncertified device >> >> An attacker may be a master device which is not certified for >> use by the relevant regulatory body. The attacker may listen to >> the communication between a valid master device and white space >> database and utilize the information about available channels >> in the response message by utilizing those channels. The result >> of such an attack is unauthorized use of channels by a master >> device which is not certified to operate. >> The master device querying the white space database may be >> operated by a law-enforcement agency and the communications >> between the device and the database are intended to be kept >> private. A malicious device should not be able to eavesdrop on >> such communications. >> >>Threat 6: Third party tracking of white space device location and >>identity >> >> A white space database may require a master device to provide >> its identity in addition to its location in the query request. >> Such location/identity information can be gleaned by an >> eavesdropper. A master device may prefer to keep the >> location/identity information secret. Hence the protocol should >> provide a means to protect the location and identity >> information of the master device and prevent tracking of >> locations associated with a white space database. If >> regulations do not require the identity of the master device to >> be provided to the white space database, the master is not >> required to include its identity in the query. >> >> >>Threat 7: Termination of device service for reasons other than >> incumbent protection >> >> A white space database may include a mechanism by which service >> and channels allocated to a master device can be revoked. A >> malicious node can send a revoke message to a master >> device. This results in denial of service to the master >> device. >> >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Wed Feb 8 14:08:53 2012 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 37BFD21F852D for ; Wed, 8 Feb 2012 14:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk9Le+S2oGoa for ; Wed, 8 Feb 2012 14:08:52 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6E60821F852A for ; Wed, 8 Feb 2012 14:08:52 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q18M8ojZ026205 for ; Thu, 9 Feb 2012 00:08:51 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 00:08:49 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Wed, 8 Feb 2012 23:08:49 +0100 From: To: Thread-Topic: UC&R I-D: section 4.10 (Machine to machine) Thread-Index: AQHM5q48e+TvqWIE20CUNLD5Cmi+JA== Date: Wed, 8 Feb 2012 22:08:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 22:08:49.0988 (UTC) FILETIME=[3C74B040:01CCE6AE] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: section 4.10 (Machine to machine) 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, 08 Feb 2012 22:08:53 -0000 Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for section on the machine to machine use case (new section numbering is NOT shown, all use cases will be moved to section 4.2 Use cases in the next version). This text has been marked up from version-02 as uploaded January 26, 2012 as follows: * comments from this mail reflector beginning January 20 topic "Clarification of M2M use case" * removed "indication of channel quality" and "antenna directivity" from the channel response message. If there is a regulatory requirement for these, they should not be deleted. * added relevant comments from the Hotspot use case. Our goal is that any discussion on this text will conclude by February 15. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 4.10. Machine to Machine (M2M) In this use case, each "machine" includes a white space slave device and can be located anywhere, fixed or on the move. Each machine needs to have connectivity to the internet and or to other machines in the vicinity. Machine communication over a TVWS channel, whether to a master device or to another machine (slave device), is under the control of a master device. This deployment scenario is typically characterized by a master device with internet connectivity by some connection that does not utilize TV white space. The figure below shows an example deployment of this scenario. \|/ | | +-|---------+ | TVWS |\ /|Master Dev | \ / +-----------+ \ WS AirIF \ +----------+ +-------+ / \ (----) | Database | |Machine| \ ( ) /----------+ +-------+ \ / \ | X( Internet ) WS AirIF \ / | ( ) +-------+ (----) |Machine| +-------+ \ +-------+ WS AirIF-- |Machine| +-------+ Figure 10: Example illustration of M2M TV white space use-case A simplified operational scenario utilizing TV whitespace to provide machine to machine connectivity consists of the following steps: 1. The master device powers up with its whitespace radio in idle or listen mode only (no active transmission on the whitespace frequency band). 2. The master device has internet connectivity , determines its location (either from location determination capability or from saved value that was set during installation), and establishes a connection to a trusted white space database (see Section 3.1 abovereference is to database discovery, will be updated in next version). 3. The master/AP registers with the trusted database according to regulatory domain requirements (see Section 4.1.2). 4. Following successful registration,The master device sends its geolocation and location uncertainty information, and optionally additional information which may include (1) device ID and (2) antenna characteristics, to a trusted database, requesting a list of available whitespace channels based upon this information. 5. If the master has met all regulatory domain requirements, The database responds with a list of available white space channels that the master device may use, and optional information which may include inter alia (1) a duration of time for the use of each channel (channel validity time) (2) a maximum radiated power for each channel, (3) an indication of the quality of the spectrum for each channel and (4) directivity and other antenna informationor a notification of any additional requirements for sensing. 6. Once the master device authenticates the whitespace channel list response message from the database, the master device selects one or more available whitespace channels from the list. 7. The slave devices fitted to the machines scan the TV bands to locate the master transmissions, and associate with the master device. Further signaling can take place outside scope of PAWS to establish direct links among those slave devices that have associated with the master device. 8. Further signaling can take place outside scope of PAWS to establish direct links among those slave devices that have associated with the same master device. At all times these direct links are under the control of the master device. For example, common to all use cases, there may be a regulatory requirement for transmissions from slave to master to cease immediately if so requested by the master, or if connection to the master is lost for more than a specified period of time. When one of these conditions occurs, transmissions from slave to slave would also cease. Various mechanisms could be used to detect loss of signal from the master, for example by requiring masters to transmit regular beacons if they allow slave to slave communications. Direct slave to slave transmissions could only restart if each slave subsequently restores its connection to the same master, or each slave joins the network of another master. From gerald.chouinard@sympatico.ca Wed Feb 8 14:16:38 2012 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 E999D21F85BE for ; Wed, 8 Feb 2012 14:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZbOnOnYfry1 for ; Wed, 8 Feb 2012 14:16:38 -0800 (PST) Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by ietfa.amsl.com (Postfix) with ESMTP id B825321F85C2 for ; Wed, 8 Feb 2012 14:16:37 -0800 (PST) Received: from BLU0-SMTP77 ([65.55.116.73]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 14:16:36 -0800 X-Originating-IP: [70.26.239.61] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([70.26.239.61]) by BLU0-SMTP77.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 14:16:36 -0800 From: Gerald Chouinard To: References: Date: Wed, 8 Feb 2012 17:16:37 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHM5oq+RfFTVzSSnEya70hzTx9liJYziBRw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Feb 2012 22:16:36.0149 (UTC) FILETIME=[524F3650:01CCE6AF] Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) 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, 08 Feb 2012 22:16:39 -0000 Scott, I agree with your proposed changes except for items 8 and 11. In the case of the Wide-area or Rural internet broadband access, the geolocation of each slave device needs to be provided to the base station so that it can query the DB for the channel availability at each slave location. These slave devices could be located as far as 30 km, thus not sharing the same location as the base station as far as querying for the available channels. The network topology here is a point-to-multipoint star model (i.e., a slave, once it knows its available channels, is not supposed to go on its own and operate on any of these channels, it will continue to operate on the same channel as that of the base station since it is part of this star network and needs to be in contact with the base station). If a slave device were to operate on a different channel in a peer-to-peer fashion, it would also have to stay in touch with the master/BS and thus have double modem construction to operate on both channels at the same time. Such peer-to-peer topology is not part of this use case. In this model, the slave device does not need to know the list of available channels, it only needs to know its operating channel which has to be the same as that of the base station and a few backup channels so that, if the current operating channels is to be freed by the base station, upon a trigger from the base station to move out of the channel, the slave device knows where to fall back to continue operating with the base station. This way, the short time to free the channel to avoid interference to the incumbent can be met while the communication with the base station can continue in a transparent way to the terminal user. The base station, however, needs to query the DB for each and every of its slave devices so that it can find the cross-section of all the available channels returned by the DB for all its slave devices which will define the channels that can be used by all the slave devices (i.e., available to the BS and all its slave devices) and this will constitute the list of the operating channel and the backup channels that the BS needs to signal to its slave devices. This is the common list of channels that needs to be sent to the slave devices, not the list of available channels for each device coming from the DB. As a consequence, The text in item 8 should stay as is except for changing "BS" for "Master/BS" if it is needed for consistency. With respect to item 11, here is what I would suggest: 11. The slave or user device must transmit its new geographic location every time it changes so that the repeated process described under item 10 for the master/BS can rely on the most up-to-date geolocation of the slave or user device. One could also argue that this function of updating the geolocation information of the slave at the master/BS is nor related to the protocol to be developed and is therefore beyond the scope of PAWS. Respectfully, Gerald -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Wednesday, 08 February, 2012 12:55 To: paws@ietf.org Subject: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) Hello All, As editors of the problem statement, use cases & requirements draft we are attempting to prepare a completed draft which could be ready for working group last call before IETF83. In the coming days we will post the sections of the draft to the mailing list. Our request is that you review these sections and reply to the email with any comments. Below is the text for section on the Wide-Area or Rural use case (new section numbering is NOT shown, all use cases will be moved to section 4.2 Use cases in the next version). This text has been marked up from version-02 as uploaded January 26, 2012 as follows: * include applicable comments from Hotspot use case Our goal is that any discussion on this text will conclude by February 15. To be clear, approval of the document will go through the normal process of last calls etc.. We are simply asking for your assistance in preparing a complete & accurate document that could progress the work. So please review the text and send your comments either directly to the editor or to the mailing list. Kind Regards, Raj & Scott 4.4. Wide-Area or Rural internet broadband access In this use case, internet broadband access is provided as a Wide- Area Network (WAN) or Wireless Regional Area Network (WRAN). A typical deployment scenario is a wide area or rural area, where internet broadband access is provided to local businesses and residents from a master (i.e. BS) connected to the internet. This deployment scenario is typically characterized by one or more Fixed master(s)/BS(s), cells with relatively large radius (tens of kilometers, up to 100 km), and a number of available radio channels. Some of the masters/BSs may be deployed and operated by a single entity, i.e. there can be centralized coordination between these masters/BSs, whereas other masters/BSs may be deployed and operated by operators competing for the radio channels in a license-exempt TVWS environment where decentralized coordination using the air-interface would be required. The BS in this scenario use a TDD radio technology and transmit at or below a transmit power limit established by the local regulator. Each base station has a connection to the internet and may provides internet connectivity to multiple slave/end-user devices. End user terminals or devices may be fixed or portable. The figure below shows an example deployment of this scenario. ------- |Slave|\ \|/ ---------- |Dev 1| (TDD AirIF) | |Database| ------- \ | .---. /---------- o \ |-|---------| ( ) / o | Master | / \ o / | (BS) |========( Internet ) o / |-----------| \ / ------- (TDD AirIF) ( ) |Slave| / (----) |Dev n| ------- Figure 4: Rural internet broadband access using TV white space spectrum Once the master/BS has been professionally installed and configured, a simplified power up and operation scenario utilizing TV White Space to provide rural internet broadband access consists of the following steps: 1. The master/BS powers up; however its WS radio and all other WS capable devices will power up in idle/listen only mode (No active transmissions on the WS frequency band) 2. The master/BS has internet connectivity , determines its location (either from location determination capability or from saved value that was set during installation), and establishes a connection to a trusted white space database (see use case "TVWS database discovery" above). 3. The master/BS registers its geolocation, address, contact information, etc. associated with the owner/operator of the master/BS with the trusted database service (if not currently registered, see Section 4.2reference is to registration, will be updated in next version). Meanwhile the DB administrator may be required to store and forward the registration information to the regulatory authority. If a trusted white space database administrator is not discovered, further operation of the WRAN may be allowed according to local regulator policy (in this case operation of the WRAN is outside the scope of the PAWS protocol). 4. Following the successful registration process, the master/BS will send a query to the trusted database requesting a list of available WS channels based upon its geolocation. The complete set of parameters to be provided from the master to the database is specified by the local regulator. Parameters may include WSD location, accuracy of of that location, device antenna height, device identifier of a slave device requesting channel information. 5. If the master/BS has been previously authenticated, the database responds with a list of available white space channels that may be used and optionally a maximum transmit power (EIRP) for each channel and a duration of time the channel may be used or a notification of any additional requirement for sensing. 6. Once the master/BS authenticates the WS channel list response message from the database, the master/BS selects an available WS channel(s) from the list. The operator may disallow some channels from the list to suit local needs if required. 7. The slave or user device scans the TV bands to locate a WRAN transmission, and associates with the master/BS.insert new step 8. The slave/user device provides its geolocation to the BS which, in turn, queries the databasemaster for a list of channels available at the slaves' Geolocation providing to the master the slave's Device ID and optionally its geolocation.. 9. Once this list of available channels is received from the database by the master, the latter will decide, based on the list of available channels for all its other associated slaves whether it should continue operation on its current channel or change channel to accommodate the new slave in case this channel is not available at its location. The master will notify all its associated slaves/user devices of the new channel to move to if operation needs to change channel. If the channel that the user terminal is currently using is not included in the list of locally available channels, the master will drop its association with the slave/user device so that it ceases all operation on its current channel and indicate the new operating channel before dropping the link if a change has been decided. The slave/user device may move to the indicated new channel if so indicated or scan for another WRAN transmission on a different channel. 10. The master/BS must periodically repeat the process to request a channel list from the database, steps 4 through 6 above. The frequency to repeat the process is determined by the local regulator. If the response from the database indicates a channel being used by the master/BS is not available, the master/BS must stop transmitting on that channel immediately. 11. The slave or user device must periodically repeat the process to request a channel list from the master/BS, steps 8 and 9 above. The frequency to repeat the process is determined by the local regulator. If the response from the master/BS indicates that a channel being used by the slave or user device is not available, the slave or user device must stop transmitting on that channel immediately. _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Wed Feb 8 14:21:00 2012 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 68D0F21F85D2 for ; Wed, 8 Feb 2012 14:21:00 -0800 (PST) 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.422, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFsseOfca1iF for ; Wed, 8 Feb 2012 14:20:59 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9477621F85D1 for ; Wed, 8 Feb 2012 14:20:59 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q18MKvvg026135 for ; Thu, 9 Feb 2012 00:20:58 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 00:20:57 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Wed, 8 Feb 2012 23:20:56 +0100 From: To: Thread-Topic: Rev 4 of the Threat model Thread-Index: AQHM5q/t7ZHIrRlqRkikX+zdmw6WwA== Date: Wed, 8 Feb 2012 22:20:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.28] Content-Type: text/plain; charset="us-ascii" Content-ID: <16EA5740F8517D458620C1A9B39D5EDA@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 08 Feb 2012 22:20:57.0360 (UTC) FILETIME=[EE00D900:01CCE6AF] X-Nokia-AV: Clean Subject: [paws] Rev 4 of the Threat model 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, 08 Feb 2012 22:21:00 -0000 Hello, Please find Rev 4 of the threat model. With the objective being "Deriving security requirements for the protocol", this version of the threat model is sufficient for the stated purpose. Hence unless you have serious issues/concerns with this threat model I would suggest that we incorporate this into the security section of the use-cases and requirements I-D and move forward. -Raj Rev 4 (2/8/12) Changes:=20 1. Text for Threat 1 is updated courtesy of Joel Halpern and Brian Rosen. 2. Text for Threat 6 updated with text provided by Gabor Bajko. 3. Updated text for Threat 7 indicating that the existence of a kill-switch is an assumption. Threat model for the PAWS protocol ---------------------------------- Assumptions: ............ o It is assumed that an attacker has full access to the network medium between the master device and the white space database. The attacker may be able to eavesdrop on any communications between these entities. The link between the master device and the white space database can be wired or wireless and provides IP connectivity. o It is assumed that the master device or the white space database have NOT been compromised from a security standpoint. Threat 1: User modifies a device to masquerade as another valid certified device Regulatory environments require that devices be certified and register in ways that accurately reflect their certification. Without suitable protection mechanisms, devices could simply listen to registration exchanges, and later registering claiming to be those other devices. Such replays would allow fasle registration, violating regulatory regimes. A white space database may be operated by a commercial entity which restricts access to authorized users. A master device MAY need to identify itself to the database and be authorized to obtain information about available channels. Threat 2: Spoofed white space database A master device discovers a white space database(s) thru which it can query for channel information. The master device needs to ensure that the white space database with which it communicates with is an authentic entity. The white space database needs to provide its identity to the master device which can confirm the validity/authenticty of the database. An attacker may attempt to spoof a white space database and provide responses to a master device which are malicious and result in the master device causing interference to the primary user of the spectrum. Threat 3: Modifying a query request An attacker may modify the query request sent by a master device to a white space database. The attacker may change the location of the device or the capabilities in terms of its transmit power or antenna height etc. which could result in the database responding with incorrect information about available channels or max transmit power allowed. The result of such an attack is that the master device would cause intereference to the primary user of the spectrum. It could also result in a denial of service to the master device by indicating that no channels are available. Threat 4: Modifying a query response An attacker could modify the query response sent by the white space database to a master device. The channel information or transmit power allowed type of parameters carried in the response could be modified by the attacker resulting in the master device using channels that are not available at a location or transmitting at a greater power level than allowed resulting in interference to the primary user of that spectrum. Alternatively the attacker may indicate no channel availability at a location resulting in a denial of service to the master device. Threat 5: Unauthorized use of channels by an uncertified device An attacker may be a master device which is not certified for use by the relevant regulatory body. The attacker may listen to the communication between a valid master device and white space database and utilize the information about available channels in the response message by utilizing those channels. The result of such an attack is unauthorized use of channels by a master device which is not certified to operate. The master device querying the white space database may be operated by a law-enforcement agency and the communications between the device and the database are intended to be kept private. A malicious device should not be able to eavesdrop on such communications. Threat 6: Third party tracking of white space device location and identity A white space database in a regulatory domain may require a master device to provide its identity in addition to its location in the query request. Such location/identity information can be gleaned by an eavesdropper and used for tracking purposes. A master device may prefer to keep the location/identity information hidden from eavesdroppers, hence the protocol should provide a means to protect the location and identity information of the master device and prevent tracking of locations associated with a white space database query. When the master device sends both its identity and location to the DB, the DB is able to track it. If a regulatory domain does not require the master device to provide its identity to the white space database, the master device may decide not to send its identity, to prevent being tracked by the DB. Threat 7: Termination of device service for reasons other than incumbent protection A white space database MAY include a mechanism by which service and channels allocated to a master device can be revoked by sending an unsolicited message. A malicious node can pretend to be the white space database with which a master device has registered or obtained channel information from and send a revoke message to that device. This results in denial of service to the master device. From paul@marvell.com Wed Feb 8 14:29:00 2012 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 5AD2211E807F for ; Wed, 8 Feb 2012 14:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vhoWxBXOaed for ; Wed, 8 Feb 2012 14:28:59 -0800 (PST) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE9821F8429 for ; Wed, 8 Feb 2012 14:28:58 -0800 (PST) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKTzL3JNb81zt6azAygw8oVhLJOIV19zIs@postini.com; Wed, 08 Feb 2012 14:28:58 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 8 Feb 2012 14:28:52 -0800 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" , "jmh@joelhalpern.com" , "Brian.Rosen@neustar.biz" Date: Wed, 8 Feb 2012 14:28:51 -0800 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAHW0EAgAB73KA= Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4FBE3@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F43@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 08 Feb 2012 22:29:00 -0000 SGkgUmFqLA0KDQo+RnJvbTogQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbSBbbWFpbHRvOkJhc2F2 YXJhai5QYXRpbEBub2tpYS5jb21dDQouLi4NCj5IaSBQYXVsLA0KPg0KPk9uIDIvMy8xMiA0OjU4 IFBNLCAiZXh0IFBhdWwgTGFtYmVydCIgPHBhdWxAbWFydmVsbC5jb20+IHdyb3RlOg0KPg0KPj4N Cj4+SGkgUmFqLA0KPj4NCj4+Rmlyc3QgLSBhIHRocmVhdCBuZWVkcyBhbiBhY3RvciBvciBzb3Vy Y2UuICBXZSBzZWVtIHRvIGhhdmUgZGlmZmVyZW50DQo+PnZpZXdzIG9mIHBvc3NpYmxlIHNvdXJj ZXMuDQo+Pg0KPj4+Pj4+PiBUaHJlYXQgNzogVGVybWluYXRpb24gb2YgZGV2aWNlIHNlcnZpY2Ug Zm9yIHJlYXNvbnMgb3RoZXIgdGhhbg0KPj4+Pj4+PiAgICAgICAgIGluY3VtYmVudCBwcm90ZWN0 aW9uDQo+PlRlcm1pbmF0aW9uIG9mIGRldmljZSBzZXJ2aWNlIGlzIHRoZSBlbmQtaW1wYWN0IChh IHVzZWZ1bCBzdGFydGluZw0KPnBvaW50LA0KPj5idXQgbm90IGV4YWN0bHkgdGhlIHRocmVhdCku DQo+DQo+QXNzdW1pbmcgdGhhdCB0aGVyZSBleGlzdHMgdGhlIGFiaWxpdHkgdG8gc2VuZCBhbiB1 bnNvbGljaXRlZCBwdXNoDQo+bm90aWZpY2F0aW9uIHRvIHRoZSBtYXN0ZXIgZGV2aWNlIHRvIGN1 cnRhaWwgc2VydmljZSBmcm9tIHRoZSBkYXRhYmFzZSwNCj50aGUgdGhyZWF0IGhlcmUgaXMgdGhl IHBvc3NpYmlsaXR5IG9mIGFuIGF0dGFja2VyIHNlbmRpbmcgc3VjaCBhIG1lc3NhZ2UNCj50byBh IG1hc3RlciBkZXZpY2UuDQo+T2YgY291cnNlIHRoZSBwcm90b2NvbCBjb3VsZCBiZSBkZXNpZ25l ZCB0byBlbnN1cmUgdGhhdCB0aGUgbWFzdGVyDQo+ZGV2aWNlDQo+dmVyaWZpZXMgdGhlIG1lc3Nh Z2UgZm9yIGF1dGhlbnRpY2l0eSBldGMuLCBidXQgdGhlIHRocmVhdCBpdHNlbGYNCj5leGlzdHMu DQpbUGF1bF0NCllvdSBtaXNzZWQgbXkgcG9pbnQgYmVsb3cuICBUaGVyZSBhcmUgbWFueSBzb3Vy Y2VzIG9mIHRocmVhdHMuICBOb3QgYWxsIGNhbiBiZSBkaXJlY3RseSBtaXRpZ2F0ZWQgYnkgcHJv dG9jb2wgbWVjaGFuaXNtcywgYnV0IHRoZXJlIG1heSBiZSB3YXlzIHdpdGggYXNzb2NpYXRlZCBw b2xpY2llcywgcHJvY2VkdXJlcyBhbmQgYWdyZWVtZW50cyB0byBsaW1pdCB0aGUgaW1wYWN0Lg0K DQpJZiB3ZSBhcmUgcGVyZm9ybWluZyBhIHRocmVhdCBhbmFseXNpcyB3ZSBzaG91bGQgbG9vayBh dCB0aGUgZnVsbCBzdWl0ZSBvZiB0aHJlYXRzLg0KDQpQYXVsDQoNCg0KPj4NCj4+DQo+Pg0KPj5T b21lIG9mIHRoZSBhc3NvY2lhdGVkIHRocmVhdCBldmVudHMgYXJlOg0KPj4NCj4+IGEpIEdvdmVy bm1lbnQgKHJlbGF0ZWQgdG8gcmVndWxhdG9yeSBhdXRob3JpdHkgb3Igbm90KSB1c2VzIFdTDQo+ RGF0YWJhc2UNCj4+dG8gdGVybWluYXRlIG9yIHVuZmFpcmx5IGxpbWl0DQo+PiAgICBzcGVjdHJ1 bSBhY2Nlc3Mgb2YgZGV2aWNlcyBmb3IgcmVhc29ucyBvdGhlciB0aGFuIGluY3VtYmVudA0KPj5w cm90ZWN0aW9uLg0KPj4gYikgU2VydmljZSBwcm92aWRlciBvciBEQiBwcm92aWRlciB1c2VzIFdT IERhdGFiYXNlIHRvIHRlcm1pbmF0ZSBvcg0KPj51bmZhaXJseSBsaW1pdA0KPj4gICAgc3BlY3Ry dW0gYWNjZXNzIG9mIGRldmljZXMgZm9yIHJlYXNvbnMgb3RoZXIgdGhhbiBpbmN1bWJlbnQNCj4+ cHJvdGVjdGlvbi4NCj4+IGMpIE93bmVyIG9mIGEgTWFzdGVyIGRldmljZSB1c2VzIFdTIERhdGFi YXNlIHRvIHRlcm1pbmF0ZSBvciB1bmZhaXJseQ0KPj5saW1pdA0KPj4gICAgc3BlY3RydW0gYWNj ZXNzIG9mIGRldmljZXMgZm9yIHJlYXNvbnMgb3RoZXIgdGhhbiBpbmN1bWJlbnQNCj4+cHJvdGVj dGlvbi4NCj4+IGQpIE1hbGljaW91cyBpbmRpdmlkdWFsIGFjdHMgYXMgYSBQQVdTIGVudGl0eSAo c3Bvb2ZpbmcgREIgb3IgYXMgTWlNKQ0KPnRvDQo+PnRlcm1pbmF0ZSBvciB1bmZhaXJseSBsaW1p dA0KPj4gICAgc3BlY3RydW0gYWNjZXNzIG9mIGRldmljZXMgZm9yIHJlYXNvbnMgb3RoZXIgdGhh biBpbmN1bWJlbnQNCj5wcm90ZWN0aW9uDQo+PiBlKSBOYXR1cmFsIGRpc2FzdGVyIGtub2NrcyBv dXQgY29tbXVuaWNhdGlvbnMgdG8gdGhlIGRhdGFiYXNlDQo+cHJldmVudGluZw0KPj5zcGVjdHJ1 bSBhY2Nlc3MuDQo+Pg0KPj4NCj4+SXQgc2VlbXMgc2lsbHkgZm9yIHVzIHRvIHJ1c2ggc28gcXVp Y2tseSBpbnRvIGJ1aWxkaW5nIHRoZSBmYXN0ZXN0DQo+PnBvc3NpYmxlIGtpbGwgc3dpdGNoIGZv ciBjb21tdW5pY2F0aW9ucy4gIFB1c2ggbm90aWZpY2F0aW9ucyBhcmUgYSBjb29sDQo+Pm1lY2hh bmlzbXMsIGJ1dCB3ZSBhbHNvIG5lZWQgc29tZSBsZXZlbCBvZiBhc3N1cmFuY2UgdGhhdCB3ZSB3 aWxsIGhhdmUNCj4+Y29udGludWl0eSBvZiB1c2FnZSBvZiBhIHNldCBvZiBjaGFubmVscy4NCj4N Cj5XZSBwcmV2aW91c2x5IGRpc2N1c3NlZCB0aGUgbmVlZCBmb3IgYSBraWxsIHN3aXRjaCBhbmQg bXkgcmVjb2xsZWN0aW9uDQo+aXMNCj50aGF0IGl0IGlzIGEgbmljZS10by1oYXZlIGZlYXR1cmUg YW5kIG5vdCBzb21ldGhpbmcgdGhhdCBpcyBtYW5kYXRvcnkuDQo+UmVndWxhdG9yeSBlbnZpcm9u bWVudHMgd2lsbCBjaG9vc2UgdG8gZGVmaW5lIHdoZXRoZXIgaXQgaXMgcmVxdWlyZWQgb3INCj5u b3QuICBUaGUgdGhyZWF0IGRlc2NyaWJlZCBpbiAoNykgaXMgc2ltcGx5IGJhc2VkIG9uIHRoZSBh c3N1bXB0aW9uIG9mDQo+c3VjaCBhIGZlYXR1cmUgZXhpc3RpbmcuDQo+DQo+LVJhag0KPg0KPj5J ZGVhbGx5IHdlJ2QgaGF2ZSBzb21lIGxvb3NlciBsaW1pdHMgb24gdGhlIG9uLWNoYW5uZWwgdGlt ZXMuDQo+Pg0KPj5QYXVsDQo+Pg0KPj4NCj4+DQo+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+RnJvbTogQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbSBbbWFpbHRvOkJhc2F2YXJhai5Q YXRpbEBub2tpYS5jb21dDQo+Pj5TZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDAzLCAyMDEyIDI6MzUg UE0NCj4+PlRvOiBQYXVsIExhbWJlcnQ7IGptaEBqb2VsaGFscGVybi5jb207IEJyaWFuLlJvc2Vu QG5ldXN0YXIuYml6DQo+Pj5DYzogcGF3c0BpZXRmLm9yZw0KPj4+U3ViamVjdDogUmU6IFtwYXdz XSBUaHJlYXQgbW9kZWwgKFJldiAzKQ0KPj4+DQo+Pj4NCj4+PkhpIFBhdWwuDQo+Pj4NCj4+Pk9u IDIvMy8xMiA0OjI2IFBNLCAiZXh0IFBhdWwgTGFtYmVydCIgPHBhdWxAbWFydmVsbC5jb20+IHdy b3RlOg0KPj4+DQo+Pj4+DQo+Pj4+Pj4+IFRocmVhdCA3OiBUZXJtaW5hdGlvbiBvZiBkZXZpY2Ug c2VydmljZSBmb3IgcmVhc29ucyBvdGhlciB0aGFuDQo+Pj4+Pj4+ICAgICAgICAgaW5jdW1iZW50 IHByb3RlY3Rpb24NCj4+Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgICBBIHdoaXRlIHNwYWNlIGRhdGFi YXNlIG1heSBpbmNsdWRlIGEgbWVjaGFuaXNtIGJ5IHdoaWNoDQo+Pj4+Pj4+c2VydmljZQ0KPj4+ Pj4+PiAgICAgICAgIGFuZCBjaGFubmVscyBhbGxvY2F0ZWQgdG8gYSBtYXN0ZXIgZGV2aWNlIGNh biBiZSByZXZva2VkLg0KPkENCj4+Pj4+Pj4gICAgICAgICBtYWxpY2lvdXMgbm9kZSBjYW4gc2Vu ZCBhIHJldm9rZSBtZXNzYWdlIHRvIGEgbWFzdGVyDQo+Pj4+Pj4+ICAgICAgICAgZGV2aWNlLiBU aGlzIHJlc3VsdHMgaW4gZGVuaWFsIG9mIHNlcnZpY2UgdG8gdGhlIG1hc3Rlcg0KPj4+Pj4+PiAg ICAgICAgIGRldmljZS4NCj4+Pj4NCj4+Pj5ObyBjbHVlIHdoYXQgeW91IG1lYW4gYnkgIm1hbGlj aW91cyBub2RlIiAuLi4gdGhpcyBjb3VsZCBiZSBhDQo+RGF0YWJhc2UsDQo+Pj4+TWFzdGVyLCBy YW5kb20gTWlNLCBldGMuDQo+Pj4NCj4+Pk15IGludGVycHJldGF0aW9uIG9mIHRoZSBhZGRpdGlv bmFsIHRocmVhdCB5b3UgaGFkIHN1Z2dlc3RlZCBpbiBhDQo+Pj5wcmV2aW91cw0KPj4+ZW1haWzF oC4NCj4+PlRoZSBwb2ludCBhYm91dCB0aGlzIHRocmVhdCBpcyB0aGF0IHdlIGhhdmUgZGlzY3Vz c2VkIGFib3V0IHRoZQ0KPj4+cG9zc2liaWxpdHkgb2YgdGhlIGRhdGFiYXNlIGhhdmluZyB0aGUg Y2FwYWJpbGl0eSB0byBzZW5kIGFuDQo+dW5zb2xpY2l0ZWQNCj4+PnB1c2ggbm90aWZpY2F0aW9u ICh0byB0aGUgbWFzdGVyIGRldmljZSkgZm9yIHJldm9raW5nIHRoZSBwcmV2aW91c2x5DQo+Pj5h bGxvY2F0ZWQgY2hhbm5lbHMgYW5kIGNlYXNpbmcgb3BlcmF0aW9uLg0KPj4+U28gdGhlICJtYWxp Y2lvdXMgbm9kZSIgaW4gdGhpcyBjYXNlIGlzIGFuIGVudGl0eSB3aGljaCBwcmV0ZW5kcyB0byBi ZQ0KPj4+dGhlDQo+Pj5kYXRhYmFzZSBhbmQgc2VuZHMgc3VjaCBhIHB1c2ggbm90aWZpY2F0aW9u IG1lc3NhZ2UgdG8gdGhlIG1hc3Rlcg0KPj4+ZGV2aWNlLg0KPj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+ SSB3YXMgcmVhbGx5IHRoaW5raW5nIG1vcmUgYWJvdXQgdGhlIG1pc3VzZSBvZiB0aGUgRGF0YWJh c2UsIG9yDQo+TWFzdGVyDQo+Pj50bzoNCj4+Pj4gLSB0dXJuIG9mZiBkZXZpY2VzIHByZXN1bWVk IHRvIGJlIHZpb2xhdGluZyB0aGUgRENNQQ0KPj4+DQo+Pj5EQ01BPw0KPj4+VGhlIGFzcGVjdCBv ZiBhIGRldmljZSBiZWluZyBzd2l0Y2hlZCBvZmYgaXMgY292ZXJlZCBpbiB0aGlzIHRocmVhdC4N Cj4+Pg0KPj4+PiAtIGxpbWl0aW5nIHNwZWN0cnVtIHVzYWdlIGJhc2VkIG9uIHRoZSB0eXBlIG9y IHB1cnBvc2Ugb2YgdGhlDQo+dHJhZmZpYw0KPj4+PihlLmcuIE9ha2xhbmQgQkFSVCkNCj4+Pj4g LSBsaW1pdGF0aW9uIG9mIHNwZWN0cnVtIHVzYWdlIGJhc2VkIG9uIHBvbGl0aWNhbCBhZmZpbGlh dGlvbiwgcmFjZSwNCj4+Pj5nZW5kZXIsIGlkZW9sb2d5LA0KPj4+PiAgIGluZGl2aWR1YWwgaWRl bnRpdHksIGV0Yy4NCj4+Pg0KPj4+SSBkb24ndCBnZXQgdGhlIGFib3ZlIHR3by4gQ2FyZSB0byBl eHBhbmQgb24gdGhlc2U/DQo+Pj4NCj4+Pj4NCj4+Pj5XZSBtYXkgbm90IGJlIGFibGUgdG8gcHJl dmVudCAoYXQgYSBwcm90b2NvbCBsZXZlbCkgdW5mYWlyIGFsbG9jYXRpb24NCj4+Pm9yDQo+Pj4+ ZGlzYWJsZW1lbnQuIFdlIHNob3VsZCBhdCBsZWFzdCBiZSBhYmxlIHRvIGhhdmUgYWRlcXVhdGUg bG9nZ2luZyBhbmQNCj4+Pj5yZWNvcmRzIHRoYXQgZ2l2ZW4gYW4gZXhwZWN0YXRpb24gb2YgZmFp ciBhbGxvY2F0aW9uIC0gd2UgY2FuIGRldGVjdA0KPj4+YW5kDQo+Pj4+Y29tcGxhaW4gd2hlbiBv dXIgbW9iaWxlIGRldmljZXMgYXJlIHR1cm5lZCBvZmYuDQo+Pj4NCj4+PlNvIGRvIHdlIG5lZWQg dG8gY2FwdHVyZSB0aGlzIGluIHRoZSBmb3JtIG9mIGEgdGhyZWF0PyBEbyB3ZSB3YW50IHRvDQo+ Pj5oYXZlDQo+Pj5hIHJlcXVpcmVtZW50IHRoYXQgdGhlIHByb3RvY29sIG5lZWRzIHRvIGVuYWJs ZSBsb2dnaW5nIGFuZCByZWNvcmQNCj4+PmtlZXBpbmc/IFRoYXTCuXMgbW9yZSBvZiBhbiBpbXBs ZW1lbnRhdGlvbiBpc3N1ZS4NCj4+Pg0KPj4+LVJhag0KPj4+DQo+Pj4+DQo+Pj4+UGF1bA0KPj4+ Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+Pj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+Pj5Gcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+T2YNCj4+Pj4+Sm9lbCBNLiBIYWxwZXJuDQo+Pj4+PlNl bnQ6IEZyaWRheSwgRmVicnVhcnkgMDMsIDIwMTIgMTI6MDEgUE0NCj4+Pj4+VG86IFJvc2VuLCBC cmlhbg0KPj4+Pj5DYzogcGF3c0BpZXRmLm9yZw0KPj4+Pj5TdWJqZWN0OiBSZTogW3Bhd3NdIFRo cmVhdCBtb2RlbCAoUmV2IDMpDQo+Pj4+Pg0KPj4+Pj5JbiB0aGUgdW5hdXRob3JpemVkIHVzZSBz ZWN0aW9uLCB0aGVyZSBpcyBzdGlsbCB0aGUgdGV4dCBzYXlpbmc6DQo+Pj4+PiAgICAgICAgVGhl IGF0dGFja2VyIG1heSBsaXN0ZW4gdG8NCj4+Pj4+ICAgICAgICB0aGUgY29tbXVuaWNhdGlvbiBi ZXR3ZWVuIGEgdmFsaWQgbWFzdGVyIGRldmljZSBhbmQgd2hpdGUNCj4+PnNwYWNlDQo+Pj4+PiAg ICAgICAgZGF0YWJhc2UgYW5kIHV0aWxpemUgdGhlIGluZm9ybWF0aW9uIGFib3V0IGF2YWlsYWJs ZQ0KPmNoYW5uZWxzDQo+Pj4+PiAgICAgICAgaW4gdGhlIHJlc3BvbnNlIG1lc3NhZ2UgYnkgdXRp bGl6aW5nIHRob3NlIGNoYW5uZWxzLg0KPj4+Pj4NCj4+Pj4+SSBzdGlsbCBmaW5kIHRoaXMgdG90 YWxseSBtaW5kLWJlbmRpbmcsIGFzIGl0IGlzIGFib3V0IHRoZSBoYXJkZXN0DQo+d2F5DQo+Pj4+ PmltYWdpbmFibGUgdG8gdW5kZXJ0YWtlIHRoaXMgYXR0YWNrLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+ Pk9uIDIvMy8yMDEyIDI6NTUgUE0sIFJvc2VuLCBCcmlhbiB3cm90ZToNCj4+Pj4+PiA8YXMgaW5k aXZpZHVhbD4NCj4+Pj4+PiBXaGVyZSBkbyB5b3Ugc2VlIHRoaXMgYXNzdW1wdGlvbiBpbiB0aGUg dGhyZWF0IG1vZGVsPw0KPj4+Pj4+DQo+Pj4+Pj4gSSB0b29rIGEgcXVpY2sgbG9vayBhbmQgZGlk bid0IHNwb3QgaXQuICBJdCB3b3VsZCBiZSAiZGF0YWJhc2UNCj4+Pj4+aW5mb3JtYXRpb24gbGVh a2VkIHRvIGJhZCBndXlzIiBvciBzb21ldGhpbmcgbGlrZSBpdCwgcmlnaHQ/DQo+Pj4+Pj4NCj4+ Pj4+PiBJIGRvbid0IHRoaW5rIHRoYXQgaXMgYSB0aHJlYXQsIGFuZCBJIGRvbid0IHRoaW5rIHdl IG5lZWQgdG8NCj5wcm90ZWN0DQo+Pj4+PmFueW9uZSBmcm9tIHRoYXQgdGhyZWF0Lg0KPj4+Pj4+ DQo+Pj4+Pj4gSSB3b3VsZCBzYXksIGhvd2V2ZXIsIHRoYXQgaWYgeW91IGNvdWxkIGtub3cgdGhl IGNvbnRlbnQgb2YgdGhlDQo+Pj4+PmRhdGFiYXNlLCBhbmQgeW91IGNhbiBvYnNlcnZlIGEgcmVz cG9uc2VzIG92ZXIgYSBwZXJpb2Qgb2YgdGltZSwgeW91DQo+Pj5tYXkNCj4+Pj4+YmUgYWJsZSB0 byBpbmZlciB0aGUgbG9jYXRpb24gb2YgdGhlIHF1ZXJpZXIuDQo+Pj4+Pj4NCj4+Pj4+PiBCcmlh bg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBPbiBGZWIgMywgMjAxMiwgYXQgMjo1MSBQTSwgSm9l bCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IENhbiB3ZSBwbGVhc2UgaW5jbHVk ZSBpbiB0aGlzIGRvY3VtZW50IHNvbWUgYXJ0aWN1bGF0aW9uIG9mIHRoZQ0KPj4+Pj4+PiBjb25m aWRlbnRpYWxpdHkgYXNzdW1wdGlvbiB3ZSBhcmUgbWFraW5nIHdpdGggcmVnYXJkIHRvIHRoZQ0K Pj4+Pj53aGl0ZXNwYWNlDQo+Pj4+Pj4+IGRhdGEgaXRzZWxmPyAgSSBhbSBub3QgdHJ5aW5nIHRv IG9iamVjdCB0byB0aGUgdGhyZWF0cy4gIChBbmQgdGhlDQo+Pj4+Pj4+IHBlcnNvbmFsIGluZm9y bWF0aW9uIGNvbGxlY3Rpb24gaXNzdWVzIGFyZSBlbm91Z2ggdG8ganN1dGlmeQ0KPj4+aW5jbHVk ZQ0KPj4+Pj4+PiBjb25maWRlbnRpYWxpdHkgbWVjaGFuaXNtcyBpbiB0aGUgc29sdXRpb25zLikN Cj4+Pj4+Pj4gQnV0IEkgYW0gc3RpbGwgdHJ5aW5nIHRvIGdldCBteSBoZWFkIGFyb3VuZCB0aGlz LiAgVGhlcmUgYXJlDQo+Z29pbmcNCj4+PnRvDQo+Pj4+PmJlDQo+Pj4+Pj4+IGhvYXJkcyBvZiB3 aGl0ZXNwYWNlIGRldmljZXMuICBUaGV5IHdpbGwgYmUgZ2V0dGluZyB0aGUgZGF0YSwgYW5kDQo+ Pj4+PmVpdGhlcg0KPj4+Pj4+PiB1c2luZyBpdCB0aGVtc2VsdmVzIG9yIHJldHJhbnNtaXR0aW5n IGl0LiAgVGhlIHJlc3VsdGluZyBkYXRhIG9uZQ0KPj4+Pj4+PiB3aGl0ZXNwYWNlIGF2YWlsYWJp bGl0eSB3aWxsIGJlIHZpc2libGUgdG8gcGVvcGxlIGFuZCBvciBkZXZpY2VzDQo+Pj4+PndoaWNo DQo+Pj4+Pj4+IGFyZSBub3QgY29tcGxldGVseSBjb250cm9sbGVkIGJ5IHRoZSByZWd1bGF0b3J5 IGFnZW5jaWVzLg0KPj4+Pj4+PiBBcyBzdWNoLCB3aGF0IGlzIHRoZSByb2xlIG9mIGNvbmZpZGVu dGlhbGl0eSB3aXRoIHJlZ2FyZCB0byB0aGlzDQo+Pj4+Pj4+IGluZm9ybWF0aW9uPw0KPj4+Pj4+ Pg0KPj4+Pj4+PiBZb3VycywNCj4+Pj4+Pj4gSm9lbA0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiAyLzMv MjAxMiAyOjM0IFBNLCBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tIHdyb3RlOg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+IEJlbG93IGlzIFJldiAzIG9mIHRoZSB0aHJlYXQgbW9kZWwgYmFzZWQgb24gZmVl ZGJhY2sgZnJvbQ0KPlN0ZXBoZW4sDQo+Pj4+Pk5hbmN5DQo+Pj4+Pj4+PiBhbmQgR2Fib3IgKFRo YW5rcykuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLVJhag0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiBSZXYgMyAoMy8yLzEyKQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRocmVhdCBtb2RlbCBmb3Ig dGhlIFBBV1MgcHJvdG9jb2wNCj4+Pj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBc3N1bXB0aW9uczoNCj4+Pj4+Pj4+IC4uLi4uLi4u Li4uLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IG8gSXQgaXMgYXNzdW1lZCB0aGF0IGFuIGF0dGFja2Vy IGhhcyBmdWxsIGFjY2VzcyB0byB0aGUgbmV0d29yaw0KPj4+Pj5tZWRpdW0NCj4+Pj4+Pj4+ICAg IGJldHdlZW4gdGhlIG1hc3RlciBkZXZpY2UgYW5kIHRoZSB3aGl0ZSBzcGFjZSBkYXRhYmFzZS4g VGhlDQo+Pj4+PmF0dGFja2VyDQo+Pj4+Pj4+PiAgICBtYXkgYmUgYWJsZSB0byBlYXZlc2Ryb3Ag b24gYW55IGNvbW11bmljYXRpb25zIGJldHdlZW4gdGhlc2UNCj4+Pj4+Pj4+ICAgIGVudGl0aWVz LiBUaGUgbGluayBiZXR3ZWVuIHRoZSBtYXN0ZXIgZGV2aWNlIGFuZCB0aGUgd2hpdGUNCj4+PnNw YWNlDQo+Pj4+Pj4+PiAgICBkYXRhYmFzZSBjYW4gYmUgd2lyZWQgb3Igd2lyZWxlc3MgYW5kIHBy b3ZpZGVzIElQDQo+Y29ubmVjdGl2aXR5Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IG8gSXQgaXMgYXNz dW1lZCB0aGF0IHRoZSBtYXN0ZXIgZGV2aWNlIG9yIHRoZSB3aGl0ZSBzcGFjZQ0KPmRhdGFiYXNl DQo+Pj4+Pj4+PiAgICBoYXZlIE5PVCBiZWVuIGNvbXByb21pc2VkIGZyb20gYSBzZWN1cml0eSBz dGFuZHBvaW50Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRocmVhdCAxOiBVc2VyIG1vZGlmaWVzIGEg ZGV2aWNlIHRvIG1hc3F1ZXJhZGUgYXMgYW5vdGhlciB2YWxpZA0KPj4+Pj4+Pj4gICAgICAgICBj ZXJ0aWZpZWQgZGV2aWNlDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICBUaGUgbWFzdGVyIGRl dmljZSBuZWVkcyB0byBhdXRoZW50aWNhdGUgaXRzZWxmIHdpdGggdGhlDQo+Pj4+PndoaXRlDQo+ Pj4+Pj4+PiAgICAgICAgIHNwYWNlIGRhdGFiYXNlIHByaW9yIHRvIHJlcXVlc3RpbmcgY2hhbm5l bCBpbmZvcm1hdGlvbi4NCj4+PlRoZQ0KPj4+Pj4+Pj4gICAgICAgICBhdHRhY2tlciBtYXkgdHJ5 IHRvIGdldCBhY2Nlc3MgdG8gdGhlIHNlY3JldHMgb2YgdGhlDQo+Pj5tYXN0ZXINCj4+Pj4+Pj4+ ICAgICAgICAgZGV2aWNlIHdoaWNoIGNhbiBiZSB1c2VkIG1hbGljaW91c2x5LiBUaGUgZWZmZWN0 IG9mIHN1Y2gNCj4+PmFuDQo+Pj4+Pj4+PiAgICAgICAgIGF0dGFjayBiZWluZyBzdWNjZXNzZnVs IHdvdWxkIHJlc3VsdCBpbiBhIG1hbGljaW91cw0KPmNsaWVudA0KPj4+Pj4+Pj4gICAgICAgICBy ZXBsYXlpbmcgdGhlIHN0b2xlbiBhdXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uDQo+c2VjcmV0 cw0KPj4+dG8NCj4+Pj4+YQ0KPj4+Pj4+Pj4gICAgICAgICB3aGl0ZSBzcGFjZSBkYXRhYmFzZS4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaHJlYXQgMjogU3Bvb2ZlZCB3aGl0ZSBzcGFjZSBkYXRhYmFz ZQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgQSBtYXN0ZXIgZGV2aWNlIGRpc2NvdmVycyBh IHdoaXRlIHNwYWNlIGRhdGFiYXNlKHMpIHRocnUNCj4+Pj4+d2hpY2gNCj4+Pj4+Pj4+ICAgICAg ICAgaXQgY2FuIHF1ZXJ5IGZvciBjaGFubmVsIGluZm9ybWF0aW9uLiBUaGUgbWFzdGVyIGRldmlj ZQ0KPj4+Pj5uZWVkcw0KPj4+Pj4+Pj4gICAgICAgICB0byBlbnN1cmUgdGhhdCB0aGUgd2hpdGUg c3BhY2UgZGF0YWJhc2Ugd2l0aCB3aGljaCBpdA0KPj4+Pj4+Pj4gICAgICAgICBjb21tdW5pY2F0 ZXMgd2l0aCBpcyBhbiBhdXRoZW50aWMgZW50aXR5LiBUaGUgd2hpdGUNCj5zcGFjZQ0KPj4+Pj4+ Pj4gICAgICAgICBkYXRhYmFzZSBuZWVkcyB0byBwcm92aWRlIGl0cyBpZGVudGl0eSB0byB0aGUg bWFzdGVyDQo+Pj5kZXZpY2UNCj4+Pj4+Pj4+ICAgICAgICAgd2hpY2ggY2FuIGNvbmZpcm0gdGhl IHZhbGlkaXR5L2F1dGhlbnRpY3R5IG9mIHRoZQ0KPj4+ZGF0YWJhc2UuDQo+Pj4+PkFuDQo+Pj4+ Pj4+PiAgICAgICAgIGF0dGFja2VyIG1heSBhdHRlbXB0IHRvIHNwb29mIGEgd2hpdGUgc3BhY2Ug ZGF0YWJhc2UgYW5kDQo+Pj4+Pj4+PiAgICAgICAgIHByb3ZpZGUgcmVzcG9uc2VzIHRvIGEgbWFz dGVyIGRldmljZSB3aGljaCBhcmUgbWFsaWNpb3VzDQo+Pj5hbmQNCj4+Pj4+Pj4+ICAgICAgICAg cmVzdWx0IGluIHRoZSBtYXN0ZXIgZGV2aWNlIGNhdXNpbmcgaW50ZXJmZXJlbmNlIHRvIHRoZQ0K Pj4+Pj5wcmltYXJ5DQo+Pj4+Pj4+PiAgICAgICAgIHVzZXIgb2YgdGhlIHNwZWN0cnVtLg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IFRocmVhdCAzOiBNb2RpZnlpbmcgYSBxdWVyeSByZXF1ZXN0DQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICBBbiBhdHRhY2tlciBtYXkgbW9kaWZ5IHRoZSBxdWVyeSBy ZXF1ZXN0IHNlbnQgYnkgYQ0KPm1hc3Rlcg0KPj4+Pj4+Pj4gICAgICAgICBkZXZpY2UgdG8gYSB3 aGl0ZSBzcGFjZSBkYXRhYmFzZS4gVGhlIGF0dGFja2VyIG1heQ0KPmNoYW5nZQ0KPj4+Pj50aGUN Cj4+Pj4+Pj4+ICAgICAgICAgbG9jYXRpb24gb2YgdGhlIGRldmljZSBvciB0aGUgY2FwYWJpbGl0 aWVzIGluIHRlcm1zIG9mDQo+aXRzDQo+Pj4+Pj4+PiAgICAgICAgIHRyYW5zbWl0IHBvd2VyIG9y IGFudGVubmEgaGVpZ2h0IGV0Yy4gd2hpY2ggY291bGQgcmVzdWx0DQo+Pj5pbg0KPj4+Pj50aGUN Cj4+Pj4+Pj4+ICAgICAgICAgZGF0YWJhc2UgcmVzcG9uZGluZyB3aXRoIGluY29ycmVjdCBpbmZv cm1hdGlvbiBhYm91dA0KPj4+Pj5hdmFpbGFibGUNCj4+Pj4+Pj4+ICAgICAgICAgY2hhbm5lbHMg b3IgbWF4IHRyYW5zbWl0IHBvd2VyIGFsbG93ZWQuIFRoZSByZXN1bHQgb2YNCj5zdWNoDQo+Pj4+ PmFuDQo+Pj4+Pj4+PiAgICAgICAgIGF0dGFjayBpcyB0aGF0IHRoZSBtYXN0ZXIgZGV2aWNlIHdv dWxkIGNhdXNlDQo+aW50ZXJlZmVyZW5jZQ0KPj4+Pj50bw0KPj4+Pj4+Pj4gICAgICAgICB0aGUg cHJpbWFyeSB1c2VyIG9mIHRoZSBzcGVjdHJ1bS4gSXQgY291bGQgYWxzbyByZXN1bHQNCj5pbg0K Pj4+YQ0KPj4+Pj4+Pj4gICAgICAgICBkZW5pYWwgb2Ygc2VydmljZSB0byB0aGUgbWFzdGVyIGRl dmljZSBieSBpbmRpY2F0aW5nDQo+dGhhdA0KPj4+bm8NCj4+Pj4+Pj4+ICAgICAgICAgY2hhbm5l bHMgYXJlIGF2YWlsYWJsZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaHJlYXQgNDogTW9kaWZ5aW5n IGEgcXVlcnkgcmVzcG9uc2UNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAgICAgIEFuIGF0dGFja2Vy IGNvdWxkIG1vZGlmeSB0aGUgcXVlcnkgcmVzcG9uc2Ugc2VudCBieSB0aGUNCj4+Pj4+d2hpdGUN Cj4+Pj4+Pj4+ICAgICAgICAgc3BhY2UgZGF0YWJhc2UgdG8gYSBtYXN0ZXIgZGV2aWNlLiBUaGUg Y2hhbm5lbA0KPmluZm9ybWF0aW9uDQo+Pj4+Pm9yDQo+Pj4+Pj4+PiAgICAgICAgIHRyYW5zbWl0 IHBvd2VyIGFsbG93ZWQgdHlwZSBvZiBwYXJhbWV0ZXJzIGNhcnJpZWQgaW4gdGhlDQo+Pj4+Pj4+ PiAgICAgICAgIHJlc3BvbnNlIGNvdWxkIGJlIG1vZGlmaWVkIGJ5IHRoZSBhdHRhY2tlciByZXN1 bHRpbmcgaW4NCj4+PnRoZQ0KPj4+Pj4+Pj4gICAgICAgICBtYXN0ZXIgZGV2aWNlIHVzaW5nIGNo YW5uZWxzIHRoYXQgYXJlIG5vdCBhdmFpbGFibGUgYXQgYQ0KPj4+Pj4+Pj4gICAgICAgICBsb2Nh dGlvbiBvciB0cmFuc21pdHRpbmcgYXQgYSBncmVhdGVyIHBvd2VyIGxldmVsIHRoYW4NCj4+Pj4+ YWxsb3dlZA0KPj4+Pj4+Pj4gICAgICAgICByZXN1bHRpbmcgaW4gaW50ZXJmZXJlbmNlIHRvIHRo ZSBwcmltYXJ5IHVzZXIgb2YgdGhhdA0KPj4+Pj4+Pj4gICAgICAgICBzcGVjdHJ1bS4gQWx0ZXJu YXRpdmVseSB0aGUgYXR0YWNrZXIgbWF5IGluZGljYXRlIG5vDQo+Pj5jaGFubmVsDQo+Pj4+Pj4+ PiAgICAgICAgIGF2YWlsYWJpbGl0eSBhdCBhIGxvY2F0aW9uIHJlc3VsdGluZyBpbiBhIGRlbmlh bCBvZg0KPj4+c2VydmljZQ0KPj4+Pj50bw0KPj4+Pj4+Pj4gICAgICAgICB0aGUgbWFzdGVyIGRl dmljZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaHJlYXQgNTogVW5hdXRob3JpemVkIHVzZSBvZiBj aGFubmVscyBieSBhbiB1bmNlcnRpZmllZCBkZXZpY2UNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICAg ICAgIEFuIGF0dGFja2VyIG1heSBiZSBhIG1hc3RlciBkZXZpY2Ugd2hpY2ggaXMgbm90DQo+Y2Vy dGlmaWVkDQo+Pj4+PmZvcg0KPj4+Pj4+Pj4gICAgICAgICB1c2UgYnkgdGhlIHJlbGV2YW50IHJl Z3VsYXRvcnkgYm9keS4gVGhlIGF0dGFja2VyIG1heQ0KPj4+bGlzdGVuDQo+Pj4+PnRvDQo+Pj4+ Pj4+PiAgICAgICAgIHRoZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gYSB2YWxpZCBtYXN0ZXIgZGV2 aWNlIGFuZA0KPndoaXRlDQo+Pj4+PnNwYWNlDQo+Pj4+Pj4+PiAgICAgICAgIGRhdGFiYXNlIGFu ZCB1dGlsaXplIHRoZSBpbmZvcm1hdGlvbiBhYm91dCBhdmFpbGFibGUNCj4+Pj4+Y2hhbm5lbHMN Cj4+Pj4+Pj4+ICAgICAgICAgaW4gdGhlIHJlc3BvbnNlIG1lc3NhZ2UgYnkgdXRpbGl6aW5nIHRo b3NlIGNoYW5uZWxzLiBUaGUNCj4+Pj4+cmVzdWx0DQo+Pj4+Pj4+PiAgICAgICAgIG9mIHN1Y2gg YW4gYXR0YWNrIGlzIHVuYXV0aG9yaXplZCB1c2Ugb2YgY2hhbm5lbHMgYnkgYQ0KPj4+Pj5tYXN0 ZXINCj4+Pj4+Pj4+ICAgICAgICAgZGV2aWNlIHdoaWNoIGlzIG5vdCBjZXJ0aWZpZWQgdG8gb3Bl cmF0ZS4NCj4+Pj4+Pj4+ICAgICAgICAgVGhlIG1hc3RlciBkZXZpY2UgcXVlcnlpbmcgdGhlIHdo aXRlIHNwYWNlIGRhdGFiYXNlIG1heQ0KPmJlDQo+Pj4+Pj4+PiAgICAgICAgIG9wZXJhdGVkIGJ5 IGEgbGF3LWVuZm9yY2VtZW50IGFnZW5jeSBhbmQgdGhlDQo+Pj5jb21tdW5pY2F0aW9ucw0KPj4+ Pj4+Pj4gICAgICAgICBiZXR3ZWVuIHRoZSBkZXZpY2UgYW5kIHRoZSBkYXRhYmFzZSBhcmUgaW50 ZW5kZWQgdG8gYmUNCj4+PmtlcHQNCj4+Pj4+Pj4+ICAgICAgICAgcHJpdmF0ZS4gQSBtYWxpY2lv dXMgZGV2aWNlIHNob3VsZCBub3QgYmUgYWJsZSB0bw0KPj4+ZWF2ZXNkcm9wDQo+Pj4+Pm9uDQo+ Pj4+Pj4+PiAgICAgICAgIHN1Y2ggY29tbXVuaWNhdGlvbnMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g VGhyZWF0IDY6IFRoaXJkIHBhcnR5IHRyYWNraW5nIG9mIHdoaXRlIHNwYWNlIGRldmljZSBsb2Nh dGlvbg0KPmFuZA0KPj4+Pj5pZGVudGl0eQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgICAgICAgQSB3 aGl0ZSBzcGFjZSBkYXRhYmFzZSBtYXkgcmVxdWlyZSBhIG1hc3RlciBkZXZpY2UgdG8NCj4+Pj4+ cHJvdmlkZQ0KPj4+Pj4+Pj4gICAgICAgICBpdHMgaWRlbnRpdHkgaW4gYWRkaXRpb24gdG8gaXRz IGxvY2F0aW9uIGluIHRoZSBxdWVyeQ0KPj4+Pj5yZXF1ZXN0Lg0KPj4+Pj4+Pj4gICAgICAgICBT dWNoIGxvY2F0aW9uL2lkZW50aXR5IGluZm9ybWF0aW9uIGNhbiBiZSBnbGVhbmVkIGJ5IGFuDQo+ Pj4+Pj4+PiAgICAgICAgIGVhdmVzZHJvcHBlci4gQSBtYXN0ZXIgZGV2aWNlIG1heSBwcmVmZXIg dG8ga2VlcCB0aGUNCj4+Pj4+Pj4+ICAgICAgICAgbG9jYXRpb24vaWRlbnRpdHkgaW5mb3JtYXRp b24gc2VjcmV0LiBIZW5jZSB0aGUgcHJvdG9jb2wNCj4+Pj4+c2hvdWxkDQo+Pj4+Pj4+PiAgICAg ICAgIHByb3ZpZGUgYSBtZWFucyB0byBwcm90ZWN0IHRoZSBsb2NhdGlvbiBhbmQgaWRlbnRpdHkN Cj4+Pj4+Pj4+ICAgICAgICAgaW5mb3JtYXRpb24gb2YgdGhlIG1hc3RlciBkZXZpY2UgYW5kIHBy ZXZlbnQgdHJhY2tpbmcgb2YNCj4+Pj4+Pj4+ICAgICAgICAgbG9jYXRpb25zIGFzc29jaWF0ZWQg d2l0aCBhIHdoaXRlIHNwYWNlIGRhdGFiYXNlLiBJZg0KPj4+Pj4+Pj4gICAgICAgICByZWd1bGF0 aW9ucyBkbyBub3QgcmVxdWlyZSB0aGUgaWRlbnRpdHkgb2YgdGhlIG1hc3Rlcg0KPj4+ZGV2aWNl DQo+Pj4+PnRvDQo+Pj4+Pj4+PiAgICAgICAgIGJlIHByb3ZpZGVkIHRvIHRoZSB3aGl0ZSBzcGFj ZSBkYXRhYmFzZSwgdGhlIG1hc3RlciBpcw0KPm5vdA0KPj4+Pj4+Pj4gICAgICAgICByZXF1aXJl ZCB0byBpbmNsdWRlIGl0cyBpZGVudGl0eSBpbiB0aGUgcXVlcnkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+IFRocmVhdCA3OiBUZXJtaW5hdGlvbiBvZiBkZXZpY2Ugc2VydmljZSBmb3Ig cmVhc29ucyBvdGhlciB0aGFuDQo+Pj4+Pj4+PiAgICAgICAgIGluY3VtYmVudCBwcm90ZWN0aW9u DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgICAgICBBIHdoaXRlIHNwYWNlIGRhdGFiYXNlIG1heSBp bmNsdWRlIGEgbWVjaGFuaXNtIGJ5IHdoaWNoDQo+Pj4+PnNlcnZpY2UNCj4+Pj4+Pj4+ICAgICAg ICAgYW5kIGNoYW5uZWxzIGFsbG9jYXRlZCB0byBhIG1hc3RlciBkZXZpY2UgY2FuIGJlDQo+cmV2 b2tlZC4NCj4+PkENCj4+Pj4+Pj4+ICAgICAgICAgbWFsaWNpb3VzIG5vZGUgY2FuIHNlbmQgYSBy ZXZva2UgbWVzc2FnZSB0byBhIG1hc3Rlcg0KPj4+Pj4+Pj4gICAgICAgICBkZXZpY2UuIFRoaXMg cmVzdWx0cyBpbiBkZW5pYWwgb2Ygc2VydmljZSB0byB0aGUgbWFzdGVyDQo+Pj4+Pj4+PiAgICAg ICAgIGRldmljZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+IHBhd3MgbWFpbGluZyBs aXN0DQo+Pj4+Pj4+PiBwYXdzQGlldGYub3JnDQo+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4+Pj4+Pj4+DQo+Pj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+IHBhd3MgbWFpbGluZyBs aXN0DQo+Pj4+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj5wYXdzIG1haWxpbmcgbGlz dA0KPj4+Pj5wYXdzQGlldGYub3JnDQo+Pj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cw0KPj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+cGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj5wYXdzQGlldGYub3JnDQo+Pj4+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pg0KDQo= From gerald.chouinard@sympatico.ca Wed Feb 8 14:39:13 2012 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 8BDC111E8080 for ; Wed, 8 Feb 2012 14:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.295 X-Spam-Level: * X-Spam-Status: No, score=1.295 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, J_CHICKENPOX_75=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olb9WimalHY8 for ; Wed, 8 Feb 2012 14:39:02 -0800 (PST) Received: from blu0-omc4-s12.blu0.hotmail.com (blu0-omc4-s12.blu0.hotmail.com [65.55.111.151]) by ietfa.amsl.com (Postfix) with ESMTP id D5B9211E8097 for ; Wed, 8 Feb 2012 14:39:01 -0800 (PST) Received: from BLU0-SMTP52 ([65.55.111.137]) by blu0-omc4-s12.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 14:39:00 -0800 X-Originating-IP: [70.26.239.61] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([70.26.239.61]) by BLU0-SMTP52.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 14:38:57 -0800 From: Gerald Chouinard To: "'Peter Stanforth'" References: <6F5D89D7-21A4-40A4-88B3-CB48A94CCC88@inf-net.nl> Date: Wed, 8 Feb 2012 17:38:58 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01CCE688.8A73B000" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AczmkbsQRACSZMOTQSyIsHEpdtKLqQAHpuHw In-Reply-To: <6F5D89D7-21A4-40A4-88B3-CB48A94CCC88@inf-net.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Feb 2012 22:38:57.0978 (UTC) FILETIME=[721A11A0:01CCE6B2] Cc: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 22:39:13 -0000 ------=_NextPart_000_007B_01CCE688.8A73B000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter, =20 I agree with you that : =93Channel availability does not equate to = channel usability.=94 However, as far as I know, the DB does not have to be = concerned as to whether the channel that is available at a given point is usable = or not. It is up to the WS device operator to accept to operate or not at = a given artificially increased noise level created by licensed operation. = As far as the DB is concerned, this is =93White Space=94 since the WS = device will not create interference to the incumbent. It may be =91grey=92 for the = operator but this is beyond the realm of the DB. =20 Again, we need to be careful here with the use of the words = =91primary=92 and =91secondary=92. In the context of the ITU Radio Regulations, both = =91primary=92 and =91secondary=92 services are allocated to specific frequency bands and = can be assigned deterministically to specific services in various countries. = The differentiator with WS devices and the use of a DB accessible over = internet is that these devices are opportunistic. Devices operating in a deterministic manner do not require a DB accessible over the internet, = they just need a license issued by the local Administration. I maintain that = WS devices are =92opportunistic=92 and not =91secondary=92. =20 As far as =91sensing =ECs concerned, I agree with Teco. =20 Gerald =20 _____ =20 From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: Wednesday, 08 February, 2012 13:45 To: Peter Stanforth Cc: Gerald Chouinard; andy.sago@bt.com; jussi.kahtava@nokia.com; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) =20 =20 Op 8 feb. 2012, om 18:03 heeft Peter Stanforth het volgende geschreven: White Space is by definition grey. Specifically if we talk about TV = White Space. The current US database ensures that the secondary user cannot interfere with the primary user. There is no guarantee of reciprocity. Channel availability does not equate to channel usability. Sensing is a non issue. The whole purpose of PAWS is managing access = with a database. There is no reason to restrict devices from sensing but if the device is not under the control of a database then it is outside the = scope of PAWS. =20 wsdb can reply sensing is required for a set of channels. See CEPT = ECC-195.=20 =20 Teco Peter S. =20 From: Gerald Chouinard Date: Wed, 8 Feb 2012 10:20:52 -0500 To: "andy.sago@bt.com" , "jussi.kahtava@nokia.com" , "scott.probasco@nokia.com" , "paws@ietf.org" Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) =20 Andy, =20 I like your suggestions to broaden it to any bands that are not fully occupied and for any type of devices. However,white space should be = white and not grey: =93White Space (WS) Radio spectrum which is not fully occupied at a = specific location and time.=94 =20 Also, White Space devices should not be limited to those that need the database to operate, RF sensing or other opportunistic means may be = allowed in some cases: =93White Space device A device which opportunistically uses some part of the white space spectrum,under control of a white space database. A = white space device can be an access point, base station, a portable device or similar. In this context, a A white = space device is Insert>may be required by local regulations to query a database with its location to obtain information about available spectrum.=94 =20 Gerald =20 =20 _____ =20 From: andy.sago@bt.com [mailto:andy.sago@bt.com]=20 Sent: Wednesday, 01 February, 2012 05:34 To: jussi.kahtava@nokia.com; gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3(Introduction, Conventions and Terminology, Prior Work) =20 Scott, All =20 I agree with Jussi that we have now narrowed the definition to apply to = TV white spaces, whereas the scope of PAWS is white spaces in general. I = would question not only why the lower-priority service would always be licence-exempt, but why the higher priority service would always be licenced. To avoid this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a = revision of the Abstract that avoids the terms licence exempt or unlicensed, or = any mention of the regulatory status of the incumbent services. The Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with =93opportunistic=94 replacing =93secondary=94 = in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the = definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it simple. =20 That just leaves the definition of white space, where the existing = spectrum use has now got muddled with the potential for opportunistic use. This = can be fixed by taking the white space and white space device definitions together. From Scott, Gerald and Jussi=92s comments perhaps we could = agree on: =20 White Space (WS) =20 Radio spectrum which is not fully occupied at a specific location and = time. =20 White Space device =20 A device which opportunistically uses some part of the white space = spectrum, under control of a white space database. A white space device can be an access point, base station, a portable device or similar. In this = context, a white spacedevice is required by local regulations to query a database with its location to obtain information about available spectrum. =20 Regards =20 Andy =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) =20 That statement is valid for TV White Spaces on UHF frequencies but does = not necessarily apply to all under-utilised radio spectrum. Why would the = lower priority service by default be licence-exempt? =20 Kind regards, Jussi =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) =20 Scott, =20 Very good improvements. I would suggest to insert the notion of opportunistic use of the spectrum by white space devices in the last sentence of the definition of =93white space=94 as follows: =20 White Space =20 Radio spectrum which has been allocated and assigned for licensed use, = but is not fully occupied by that licensed use at a specific location and = time. This spectrum is then assigned allowed bylocal regulations for use to be used opportunistically as licensed-exempt spectrum under control of a white space database. =20 This way, it is understood that the database does not =93assign=94 white = space devices for them to choose from. =20 Gerald _____ =20 From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] =20 Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) =20 Hi Gerald, =20 Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower = priority opportunistic service" could indeed by used, but I am guessing that we = would need some explanation of what that means. Since we now have descriptions = of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns? =20 I also corrected "location" to "local" in previous text proposed for = "White Space". =20 Kind Regards, Scott =20 From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott , "paws@ietf.org" Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) =20 Scott, Great proposal. However, I am still a bit nervous about the definitions = of =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the = notion of secondary use is included. The secondary status is used in the ITU-R = Radio Regulations for a different purpose. In fact, it is possible that a = band has already primary and secondary services allotted to it and that the = White Space operation is a tertiary opportunistic operation where the two = first types of services are not being used. The use of =93lower priority opportunistic=94 service rather than =93secondary=94 service would be = preferable to describe white spaceallocations. =20 Gerald=20 =20 _____ =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) =20 Hi, =20 I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes to the draft = based on the email discussion. =20 Below is a copy of chapter 2.2. Terminology. I have inserted new terms = for 'licensed' and 'license-exempt' and made changes to the term 'white = space'. I have tried to work from the perspective that the document should accurately explain the subject with aim that a reader can understand the = use cases and the subsequent requirements. No doubt we could include much = more text on this topic of spectrum allocation, assignment, licensing and = usage. =20 I hope this captures the key points of the discussion. Please do reply = if something is still missing. =20 Kind Regards, Scott =20 =20 2.2. Terminology =20 Database =20 In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. =20 Device ID =20 A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. =20 Licensed Spectrum =20 Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through = auctions,award (beauty contest), acquisition from secondary market, company = merger & acquisition, first-come / first-served or by government = allocation (e.g., public service). =20 License-exempt Spectrum =20 Spectrum that is not assigned to any specific user. One example is = the 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, = license-exempt spectrum is Typically referred to as "unlicensed" spectrum. In this document = the terms license-exempt and unlicensed are used interchangeably. =20 =20 Location Based Service =20 An application or device which provides data, information or service to a user based on their location. =20 Master Device =20 A device which queries the WS Database to find out the available operating channels. =20 Protected Entity =20 A licensed user of spectrum, when the licensed spectrum = has been assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondarylicense-exempt white space = users (white space devices) for its use in a given area and time. =20 Protected Contour =20 The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. =20 Slave Device =20 A device which uses the spectrum made available by a master device. =20 TV White Space =20 TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. =20 White Space =20 Radio spectrum which has been allocated for someprimary useand assigned for licensed use, but is not fully occupied by that primary use licensed use at a specificlocation and time. This spectrum is then assigned by locationlocal regulations for use as licensed-exempt spectrum under control of a white space = database. =20 White Space Device (WSD) =20 A device which is a secondarylicense-exempt user of some = part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. =20 =20 =20 From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' Cc: "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' =20 Nancy, =20 This is not that simple. In fact, the qualifiers =93license-exempt=94 = and =93unlicensed=94 can apply to more than one thing. =20 If the qualifier applies to a frequency band, different options exist. = As an example, in the ITU-R context, an =93unlicensed=94 band is typically a = new band, say in the 300 GHz, for which no request has been made for its use. It = is therefore un-allocated to a specific service so far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to = one or many services on a primary or secondary basis, then the administrations = can thendecide under what king of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This = is also called =93unlicensed=94 in the USA. =20 If the qualifier applies to an operation, the operation can be exempt of license by the local administration, thus a =93license-exempt=94 = operation. If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type = of operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running = an =93unlicensed=94 operation. =20 If the qualifier applies to the transmission device, such device may be = a =93license-exempt=94 device if its operation does not require a specific = license or registration with the local administration such as TV receivers of = Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a device = that is not allowed in a country by, for example, buying it on eBay and = operates it, this is then an illegal device in the country and id de-facto an =93unlicensed=94 device since it has not passed through the normal = certification process. =20 Note that a =93license-exempt=94 device still has to go through a = certification process and meet the limits imposed by the local regulator for the =93license-exempt=94 operation in the given frequency band whereas an =93unlicensed=94 device may not pass the certification process since it = has not been licensed to operation in the country. =20 This is why the qualifier =93unlicensed=94 has to be treated with care = and the footnote will need to be crafted very carefully. =20 With respect to your second point, if an administration only allows =93licensed=94 operation, the situation will be much simpler to manage = since specific conditions will be attached to these licenses. =20 Gerald =20 _____ =20 From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' =20 Gabor and Gerald,=20 Since we are dealing on a global basis, can there a footnote to = "unlicensed" we can use to indicate that "according to each countries regulatory requirements" =20 How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: =20 Gabor, =20 I agree with your proposal. Thisseems to be reasonable. However one = needs to be careful with the word=91unlicensed=92 which may mean =91illegal=92 = operation of an RF device in many administrations. =20 Gerald =20 _____ =20 From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' =20 These look to be very precise definitions, however in everyday use I = rarely hear people referring to ISM band as =91license-exempt=92, in most cases = the term =91unlicensed-band=92 is used.=20 =20 Therefore, may I suggest that the draft will include the following statement: =20 The terms unlicensed and license-exempt spectrum are used in this = document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM band. =20 - Gabor =20 From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of = ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' =20 All, =20 Here is my understanding of the terms: =20 Licensed: Spectrum that is acquired by an operator over a given service = area for a given time period. This is usually done through auctions (think = of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). =20 Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small to = facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., = rural broadband in Canada) and not big Telcos that would normally work with = full licensing through auction over large service areas. =20 License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. =20 Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. =20 To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has been used for = another specific purpose. =20 Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the USA = instead of the usual =91license-exempt=92. =20 Gerald _______________________________________________ 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 ------=_NextPart_000_007B_01CCE688.8A73B000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Peter,

 

I agree with you that : = “Channel availability does not equate to channel usability.” However, as far = as I know, the DB does not have to be concerned as to whether the channel = that is available at a given point is usable or not.  It is up to the WS = device operator to accept to operate or not at a given artificially increased = noise level created by licensed operation.  As far as the DB is = concerned, this is “White Space” since the WS device will not create = interference to the incumbent. It may be ‘grey’ for the operator but this = is beyond the realm of the DB.

 

Again, we need to be careful here = with the use of the words ‘primary’ and ‘secondary’. In = the context of the ITU Radio Regulations, both ‘primary’ and = ‘secondary’ services are allocated to specific frequency bands and can be assigned deterministically to specific services in various countries. The = differentiator with WS devices and the use of a DB accessible over internet is that = these devices are opportunistic.  Devices operating in a deterministic = manner do not require a DB accessible over the internet, they just need a license = issued by the local Administration. I maintain that WS devices are = ’opportunistic’ and not ‘secondary’.

 

As far as ‘sensing ìs concerned, I agree with Teco.

 

Gerald

 

From: Teco = Boot [mailto:teco@inf-net.nl]
Sent: Wednesday, 08 = February, 2012 13:45
To: Peter Stanforth
Cc: Gerald Chouinard; andy.sago@bt.com; jussi.kahtava@nokia.com; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3(Introduction, Conventions and = Terminology, Prior Work)

 

 

Op 8 feb. 2012, om 18:03 heeft Peter Stanforth het volgende = geschreven:



White Space = is by definition grey. Specifically if we talk about TV White Space. The = current US = database ensures that the secondary user cannot interfere with the primary user. = There is no guarantee of reciprocity. Channel availability does not equate to = channel usability.

Sensing is = a non issue. The whole purpose of PAWS is managing access with a database. = There is no reason to restrict devices from sensing but if the device is not = under the control of a database then it is outside the scope of = PAWS.

 

wsdb can reply sensing is required for a set of channels. See = CEPT ECC-195. 

 

Teco



Peter = S.

 <= /o:p>

From: Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Wed, 8 Feb 2012 = 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "jussi.kahtava@nokia.com"= <jussi.kahtava@nokia.com>, = "scott.probasco@nokia.com&quo= t; <scott.probasco@nokia.com>= , "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3(Introduction, Conventions and = Terminology, Prior Work)

 <= /o:p>

Andy,

 

I like your suggestions to broaden = it to any bands that are not fully occupied and for any type of devices. However,white space should be white and not = grey:

“White Space (WS)

 Radio = spectrum which is not <delete>fully<delete> occupied at a specific = location and time.”

 

Also, White Space devices should = not be limited to those that need the database to operate, RF sensing or other = opportunistic means may be allowed in some cases:

“White = Space device

A device = which opportunistically uses some part of the white space spectrum<delete>,under control of a white space database<delete>.  A white space device can be an access = point, base station, a portable device or similar.  <delete>In this = context, a<delete> <insert>A<insert> white space = device<delete> is<delete> Insert>may be<insert> required by local = regulations to query a database with its location to obtain information about = available spectrum.”

 

Gerald

 

 

From: andy.sago@bt.com [mailto:andy.sago@bt.com]
Sent: Wednesday, 01 = February, 2012 05:34
To: jussi.kahtava@nokia.com; = gerald.chouinard@sympatico.= ca; scott.probasco@nokia.com; = paws@ietf.org
Subject: RE: [paws] Use = cases and requirements I-D: sections 1 to 3(Introduction, Conventions and = Terminology, Prior Work)

 

Scott, = All

 =

I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only why = the lower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th = Jan I proposed (= http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with “opportunistic” replacing “secondary” in later sentences in the Introduction. I have = checked and there are no further references to licensing in the document, so we don’t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document – we are defining requirements fora protocol. Keep it = simple.

 =

That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  From Scott, = Gerald and Jussi’s comments perhaps we could agree = on:

 =

White Space = (WS)

 <= /font>

Radio = spectrum which is not fully occupied at a specific location and = time.

 

White Space = device

 

A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white spacedevice is required by local regulations to query a database with = its location to obtain information about available = spectrum.

 =

Regards

 =

Andy

 =

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 = 07:31
To: gerald.chouinard@sympatico.= ca; scott.probasco@nokia.com; = paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /o:p>

That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?

 =

Kind = regards,

Jussi<= /u1:p>

 =

From: paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org]On Behalf Of ext Gerald = Chouinard
Sent: 31 January 2012 = 22:33
To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /o:p>

Scott,

 

Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of “white space” as = follows:

 

White = Space

 <= /font>

Radio = spectrum which has been allocated and assigned for licensed use, but is not fully = occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> bylocal regulations <delete>for use<delete> <insert>to = be used opportunistically<insert> as licensed-exempt spectrum under = control of a white space = database.</Insert>

 

This way, it is understood that the database does not “assign” white space devices for them to = choose from.

 

Gerald

From: scott.probasco@nokia.com [mailto:scott.proba= sco@nokia.com]
Sent: Tuesday, 31 = January, 2012 15:12
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Hi = Gerald,

 

Good to avoid = overloading the term "secondary". I have made additional proposed changes = to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need = some explanation of what that means. Since we now have descriptions of = licensed spectrum and license-exempt spectrum, I used these words. Do these = changes remove your concerns?

 

I also = corrected "location" to "local" in previous text proposed for "White Space".

 

Kind = Regards,

Scott

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>= , "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

= Scott,

= Great proposal.  However, I am still a bit nervous about the definitions = of “Protected Entity” and “White Space Devices = (WSD)” where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In = fact, it is possible that a band has already primary and secondary services allotted = to it and that the White Space operation is a tertiary opportunistic operation = where the two first types of services are not being used.  The use of “lower priority opportunistic” service rather than “secondary” service would be preferable to describe white spaceallocations.

=  

= Gerald

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of scott.probasco@nokia.com
= Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work)

 

Hi,

 

I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the = draft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.

 

I hope this captures the key points of the discussion. Please do reply if something is still missing.

 

Kind Regards,

Scott

 

 

2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio = technologies,

      the database is an entity which contains current = information about

      available spectrum at any given location and other types = of

      information.

 

   Device ID

 

     A unique number for each master device and slave device = that

      identifies the manufacturer, model number and serial = number.

 

<Insert>

   Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given = service area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, = company merger &

      acquisition,  first-come / first-served or by = government allocation

      (e.g., public service).

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the = USA, license-exempt spectrum is

      Typically referred to as "unlicensed" spectrum. = In this document the terms

      license-exempt and unlicensed are used = interchangeably.

 

</Insert>

 

   Location Based Service

 

      An application or device which provides data, information = or

      service to a user based on their = location.

 

   Master Device

 

      A device which queries the WS Database to find out the = available

      operating channels.

 

   Protected Entity

 

      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space

      devices) for its use</Delete> in a given area and = time.

 

   Protected Contour

 

      The exclusion area for a Protected Entity, held in the = database

      and expressed as a polygon with geospatial points as the = vertices.

 

   Slave Device

 

      A device which uses the spectrum made available by a = master

      device.

 

   TV White Space

 

      TV white space refers specifically to radio spectrum which = has

      been allocated for TV broadcast, but is not occupied by a = TV

      broadcast, or other licensed user (such as a wireless = microphone),

      at a specific location and time.

 

   White Space

 

      Radio spectrum which has been allocated <Delete>for someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a = specificlocation

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>

 

   White Space Device (WSD)

 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</In= sert> user of some part of white space

      spectrum.  A white space device can be an access = point, base

      station, a portable device or similar.  In this = context, a white

      space device is required to query a database with its = location to

      obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" = <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Nancy,

=  

= This is not that simple.  In fact, the qualifiers = “license-exempt” and “unlicensed” can apply to more than one = thing.

=  

= If the qualifier applies to a frequency band, different options exist. As an = example, in the ITU-R context, an “unlicensed” band is typically a = new band, say in the 300 GHz, for which no request has been made for its = use.  It is therefore un-allocated to a specific service so far and thus it is an “unlicensed” frequency band. Once the ITU-R allocates this = band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will ‘assign’ = this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus “license-exempt”such as in the 2.4 GHz ISM band. This is = also called “unlicensed” in the USA.

=  

= If the qualifier applies to an operation, the operation can be exempt of = license by the local administration, thus a “license-exempt” operation. = If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an “unlicensed” operation.

=  

= If the qualifier applies to the transmission device, such device may be a “license-exempt” device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an “unlicensed” device since it has not passed = through the normal certification process.

=  

= Note that a “license-exempt” device still has to go through a certification process and meet the limits imposed by the local regulator = for the “license-exempt” operation in the given frequency band = whereas an “unlicensed” device may not pass the certification = process since it has not been licensed to operation in the = country.

=  

= This is why the qualifier “unlicensed” has to be treated with care and = the footnote will need to be crafted very carefully.

=  

= With respect to your second point, if an administration only allows “licensed” operation, the situation will be much simpler to = manage since specific conditions will be attached to these = licenses.

=  

= Gerald

=  

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; = paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Gabor and = Gerald, 

Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use = to indicate that "according to each countries regulatory = requirements"  

How to get = around the fact that some Countries are or will be "licensed only" by = their gov'ts?  Thanks

Nancy

On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:

 

= Gabor,

=  

= I agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word‘unlicensed’ which may mean ‘illegal’ operation of an RF device in many = administrations.

=  

= Gerald

=  

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] =
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as ‘license-exempt’, in most cases the = term ‘unlicensed-band’ is used.

 

Therefore, may I suggest that the draft will include the following = statement:

 

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.

 

-          Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

All,

 

= Here is my understanding of the terms:

=  

= Licensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).

=  

= Lightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in = Canada) and not big Telcos that would normally work with full licensing through = auction over large service areas.

=  

= License-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

=  

= Unlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, this term is used to mean “license-exempt," see = above.

=  

= To my knowledge, the term “unlicensed” is used only in the = USA to describe a legal operation because the term = “license-exempt” has been used for another specific purpose.

=  

= Since the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I = would suggest the use of ‘licensed’ and = ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in = the USA instead of the usual = ‘license-exempt’.

=  

= Gerald

_______________________________________________
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

 

------=_NextPart_000_007B_01CCE688.8A73B000-- From budden@nps.edu Wed Feb 8 14:42:30 2012 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 D409011E8083 for ; Wed, 8 Feb 2012 14:42:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46fxn67zdPd6 for ; Wed, 8 Feb 2012 14:42:29 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id C470A11E8080 for ; Wed, 8 Feb 2012 14:42:29 -0800 (PST) X-ASG-Debug-ID: 1328740948-036c920f1af1100001-Z0ZA9G Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id 8j98qKtbm3yXEaFs; Wed, 08 Feb 2012 14:42:28 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 8 Feb 2012 14:42:28 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) To: Gerald Chouinard In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 8 Feb 2012 14:41:50 -0800 Message-ID: <1328740910.9169.2112.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1328740948 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.88001 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) 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, 08 Feb 2012 22:42:30 -0000 namecalling nits below.... On Wed, 2012-02-08 at 17:16 -0500, Gerald Chouinard wrote: > Scott, > > I agree with your proposed changes except for items 8 and 11. > > In the case of the Wide-area or Rural internet broadband access, the > geolocation of each slave device needs to be provided to the base station so > that it can query the DB for the channel availability at each slave > location. These slave devices could be located as far as 30 km, thus not > sharing the same location as the base station as far as querying for the > available channels. IEEE 802 uses the terms _base station_ (BS) and _subscriber station_ (SS) (not slave). > > The network topology here is a point-to-multipoint star model (i.e., a > slave, once it knows its available channels, is not supposed to go on its > own and operate on any of these channels, it will continue to operate on the > same channel as that of the base station since it is part of this star > network and needs to be in contact with the base station). In a pure IEEE 802.16 notion, this is entirely correct. > If a slave device > were to operate on a different channel in a peer-to-peer fashion, it would > also have to stay in touch with the master/BS and thus have double modem > construction to operate on both channels at the same time. Such peer-to-peer > topology is not part of this use case. But it is part of several standards and associated technologies. IEEE 802.16j (now that it's ratified, correctly termed IEEE 802.16-2009) comes to mind. > > In this model, the slave device does not need to know the list of available > channels, it only needs to know its operating channel which has to be the > same as that of the base station and a few backup channels so that, if the > current operating channels is to be freed by the base station, upon a > trigger from the base station to move out of the channel, the slave device > knows where to fall back to continue operating with the base station. This > way, the short time to free the channel to avoid interference to the > incumbent can be met while the communication with the base station can > continue in a transparent way to the terminal user. The way out of this circle is to again ape IEEE 802.16. The device in the middle is known as RS, short for relay station. Further there's a lot of 'mesh' talk where all stations would be peers. In both cases, the RS or the peers would have to assume the responsibility of a BS. > > The base station, however, needs to query the DB for each and every of its > slave devices so that it can find the cross-section of all the available > channels returned by the DB for all its slave devices which will define the > channels that can be used by all the slave devices (i.e., available to the > BS and all its slave devices) and this will constitute the list of the > operating channel and the backup channels that the BS needs to signal to its > slave devices. This is the common list of channels that needs to be sent to > the slave devices, not the list of available channels for each device coming > from the DB. > > As a consequence, The text in item 8 should stay as is except for changing > "BS" for "Master/BS" if it is needed for consistency. > > With respect to item 11, here is what I would suggest: > > 11. The slave or user device must transmit its new geographic location > every time it changes so that the repeated process described under item 10 > for the master/BS can rely on the most up-to-date geolocation of the slave > or user device. > > One could also argue that this function of updating the geolocation > information of the slave at the master/BS is nor related to the protocol to > be developed and is therefore beyond the scope of PAWS. > > Respectfully, > > Gerald > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > scott.probasco@nokia.com > Sent: Wednesday, 08 February, 2012 12:55 > To: paws@ietf.org > Subject: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet > broadbandaccess) > > Hello All, > > As editors of the problem statement, use cases & requirements draft we are > attempting to prepare a completed draft which could be ready for working > group last call before IETF83. In the coming days we will post the > sections of the draft to the mailing list. Our request is that you review > these sections and reply to the email with any comments. > > Below is the text for section on the Wide-Area or Rural use case (new > section numbering is NOT shown, all use cases will be moved to section 4.2 > Use cases in the next version). This text has been marked up from > version-02 as uploaded January 26, 2012 as follows: > > * include applicable comments from Hotspot use case > > > Our goal is that any discussion on this text will conclude by February 15. > To be clear, approval of the document will go through the normal process > of last calls etc.. We are simply asking for your assistance in preparing > a complete & accurate document that could progress the work. So please > review the text and send your comments either directly to the editor or to > the mailing list. > > Kind Regards, > Raj & Scott > > > > 4.4. Wide-Area or Rural internet broadband access > > In this use case, internet broadband access is provided as a Wide- > Area Network (WAN) or Wireless Regional Area Network (WRAN). A > typical deployment scenario is a wide area or rural area, where > internet broadband access is provided to local businesses and > residents from a master (i.e. BS) connected to the internet. This > deployment scenario is typically characterized by one or more > Fixed master(s)/BS(s), cells with relatively large radius (tens of > kilometers, up to 100 km), and a number of available radio > channels. Some of the masters/BSs may be deployed and operated by > a single entity, i.e. there can be centralized coordination > between these masters/BSs, whereas other masters/BSs may be > deployed and operated by operators competing for the radio > channels in a license-exempt TVWS environment where decentralized > coordination using the air-interface would be required. The BS in > this scenario use a TDD radio technology and transmit at or below > a transmit power limit established by the local regulator. Each > base station has a connection to the internet and may > provides > internet connectivity to multiple slave/end-user devices. End > user terminals or devices may be fixed or portable. > > The figure below shows an example deployment of this scenario. > > ------- > |Slave|\ \|/ ---------- > |Dev 1| (TDD AirIF) | |Database| > ------- \ | .---. /---------- > o \ |-|---------| ( ) / > o | Master | / \ > o / | (BS) |========( Internet ) > o / |-----------| \ / > ------- (TDD AirIF) ( ) > |Slave| / (----) > |Dev n| > ------- > > > Figure 4: Rural internet broadband access using TV white space > spectrum > > Once the master/BS has been professionally installed and configured, > a simplified power up and operation scenario utilizing TV White Space > to provide rural internet broadband access consists of the following > steps: > > 1. The master/BS powers up; however its WS radio and all other WS > capable devices will power up in idle/listen only mode (No active > transmissions on the WS frequency band) > > 2. The master/BS has internet connectivity , determines its > location (either from location determination capability or from saved > value that was set during installation), and establishes a > connection to a trusted white space database (see use > case "TVWS > database discovery" above). > > 3. The master/BS registers its geolocation, address, contact > information, etc. associated with the owner/operator of the > master/BS with the trusted database service (if > not currently > registered, see Section 4.2reference is to > registration, will be updated in next version). Meanwhile the > DB administrator may > be required to store and forward the registration information to > the regulatory authority. If a trusted white space database > administrator is not discovered, further operation of the WRAN > may be allowed according to local regulator policy (in this case > operation of the WRAN is outside the scope of the PAWS protocol). > > 4. Following the successful registration process, the > master/BS will send a > query to the trusted database requesting a list of available WS > channels based upon its geolocation. The complete set of > parameters to be provided from the master to the database is specified > by the local regulator. Parameters may include WSD location, accuracy of > of that location, device antenna height, device identifier of a slave > device requesting channel information. > > > 5. If the master/BS has been previously authenticated, the database > responds with a list of available white space channels that may > be used and optionally a maximum transmit power (EIRP) for each > channel and a duration of time the channel may be > used or a notification of any additional requirement for > sensing. > > 6. Once the master/BS authenticates the WS channel list response > message from the database, the master/BS selects an available WS > channel(s) from the list. The operator may disallow some > channels from the list to suit local needs if required. > > 7. The slave or user device scans the TV bands to locate a WRAN > transmission, and associates with the master/BS.insert > new step > > 8. The slave/user > device provides its geolocation to the BS which, in > turn, queries > the databasemaster for a list of > channels available at the slaves' > Geolocation providing to the master the slave's Device ID > and optionally its geolocation.. > > 9. Once this list of available channels is received from the > database by the master, the latter will decide, based on the list > of available channels for all its other associated slaves whether > it should continue operation on its current channel or change > channel to accommodate the new slave in case this channel is not > available at its location. The master will notify all its > associated slaves/user devices of the new channel to move to if > operation needs to change channel. If the channel that the user > terminal is currently using is not included in the list of > locally available channels, the master will drop its association > with the slave/user device so that it ceases all operation on its > current channel and indicate the new operating channel before > dropping the link if a change has been decided. The slave/user > device may move to the indicated new channel if so indicated or > scan for another WRAN transmission on a different channel. > > > 10. The master/BS must periodically repeat the process to request a > channel list from the database, steps 4 through 6 above. The frequency > to repeat the process is determined by the local regulator. If the > response from the database indicates a channel being used by the > master/BS is not available, the master/BS must stop transmitting on that > channel immediately. > > 11. The slave or user device must periodically repeat the process to > request a channel list from the master/BS, steps 8 and 9 above. The > frequency to repeat the process is determined by the local regulator. If > the response from the master/BS indicates that a channel being used by > the slave or user device is not available, the slave or user device must > stop transmitting on that channel immediately. > > > > > _______________________________________________ > 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 gerald.chouinard@sympatico.ca Wed Feb 8 14:47:00 2012 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 4F1DD11E8097 for ; Wed, 8 Feb 2012 14:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.363 X-Spam-Level: * X-Spam-Status: No, score=1.363 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_50=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruOvNlCsfv0w for ; Wed, 8 Feb 2012 14:46:47 -0800 (PST) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by ietfa.amsl.com (Postfix) with ESMTP id 0D42321F84AA for ; Wed, 8 Feb 2012 14:46:46 -0800 (PST) Received: from BLU0-SMTP55 ([65.55.116.74]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 14:46:46 -0800 X-Originating-IP: [70.26.239.61] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([70.26.239.61]) by BLU0-SMTP55.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 8 Feb 2012 14:46:43 -0800 From: Gerald Chouinard To: "'Peter Stanforth'" References: Date: Wed, 8 Feb 2012 17:46:44 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0085_01CCE689.A043FCE0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aczmg2zHZybsGYEAQYyLgbjstKToqwALz7oA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 08 Feb 2012 22:46:44.0112 (UTC) FILETIME=[87F07900:01CCE6B3] Cc: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 22:47:00 -0000 ------=_NextPart_000_0085_01CCE689.A043FCE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Peter, See my other email about 'secondary' versus 'opportunistic'. I agree with you that 'primary', 'secondary', 'deterministic and 'opportunistic' use of the spectrum has no relevance to whether the access could be free or paid (after all the primary access to the TV bands by the broadcasters is free for historical reasons while one could decide that some TVWS access could be paid ;-) ). Again, the reason why one needs a DB accessible over the internet is that the access to the spectrum is 'opportunistic'. If this was deterministic, the DB would not be needed as has been the case up to now. Gerald _____ From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Wednesday, 08 February, 2012 12:01 To: Gerald Chouinard; andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) There is no reason to assume that use of white space is by licensed exempt or unlicensed devices. This comes back to an earlier argument I made about what constitutes licensed and unlicensed? Again there is no reason that a license exempt or unlicensed device should get access to spectrum for "free" any more that a licensed device has to "pay" for spectrum access. The concept of a primary user, who has priority over a secondary user has no relevance to free or paid access. The rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the other, and an argument can be made for both. In a band occupied by a public safety user there may be no choice but to have opportunistic access but in other bands a primary user may be willing to commit to specific availability if their own use is deterministic. Peter S. From: Gerald Chouinard Date: Wed, 8 Feb 2012 10:20:52 -0500 To: "andy.sago@bt.com" , "nbravin@earthlink.net" , "paws@ietf.org" Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Andy, To resolve Nancy's concern, a new definition could be added for: TVWS White Space devices: White Space devices that operate in the TV bands. This would complement the definition of White Space devices and make it more specific. I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the White Spacedevices. The opportunistic use of the RF spectrum assumes that these devices operate while protecting existing operation in the band. There is automatically assumes the existence of primary users of the band that have priority. Such primary users would most likely be licensed to use the band and it is only the portions that happen to be unused that will be accessible to the White Space devices. The latter are unlikely to be licensed to only use the 'crumbs'. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices and then why would they need to protect these 'primary' licensed devices. This would be similar to the situation in the 2.4 GHz where a database is not needed to protect other devices. As is well understood, the databases are there to protect primary and possibly secondary licensed devices from the new opportunistic devices, not opportunistic devices among themselves. The latter case would be covered by other means such as adatabase to provide coexistence and this is, I believe, beyond the scope ofPAWS. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Wednesday, 01 February, 2012 09:58 To: nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Nancy, all Good questions. I'm not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your other questions, IMO our aim should be to provide all the necessary information in this PAWS requirements I-D to enable the PAWS protocol I-D to be developed. I don't think it's our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this very well, and regulators tend to be well coordinated or play 'follow my leader'. Thanks for pointing out the reference to licence-exempt that I had missed in 4.4 - I think the meaning would be just the same with 'in a license-exempt TVWS environment' deleted from that sentence. That would be my suggestion. Regards Andy From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: 01 February 2012 14:48 To: Sago,AJ,Andy,COD R Cc: paws@ietf.org Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6.so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain how the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could change, but, why not give the information on both for countries to understand fully what it's choices are? Thanks Andy, just some early morning thoughts.Sincerely, Nancy Begin forwarded message: From: Nancy Bravin Date: February 1, 2012 6:35:09 AM PST To: Andy Sago Cc: , , , Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Andy, All In section 4.4, license exempt is also mentioned as well. I am conflicted in a global sense when emerging countries, or countries with very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby join the existing DB companies, or will they do their own thing leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/or White spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, wrote: Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV white spaces, whereas the scope of PAWS is white spaces in general. I would question not only why the lower-priority service would always be licence-exempt, but why the higher priority service would always be licenced. To avoid this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or unlicensed, or any mention of the regulatory status of the incumbent services. The Abstract derives from the Introduction and the text could be aligned to be the same in the Introduction, with "opportunistic" replacing "secondary" in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don't need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document - we are defining requirements fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum use has now got muddled with the potential for opportunistic use. This can be fixed by taking the white space and white space device definitions together. From Scott, Gerald and Jussi's comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum, under control of a white space database. A white space device can be an access point, base station, a portable device or similar. In this context, a white spacedevice is required by local regulations to query a database with its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not necessarily apply to all under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunistic use of the spectrum by white space devices in the last sentence of the definition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but is not fully occupied by that licensed use at a specific location and time. This spectrum is then assigned allowed bylocal regulations for use to be used opportunistically as licensed-exempt spectrum under control of a white space database. This way, it is understood that the database does not "assign" white space devices for them to choose from. Gerald _____ From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do these changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White Space". Kind Regards, Scott From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott , "paws@ietf.org" Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of "Protected Entity" and "White Space Devices (WSD)" where the notion of secondary use is included. The secondary status is used in the ITU-R Radio Regulations for a different purpose. In fact, it is possible that a band has already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operationwhere the two first types of services are not being used. The use of "lower priority opportunistic" service rather than "secondary" service would be preferable to describe white spaceallocations. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes to the draft based on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the document should accurately explain the subject with aim that a reader can understand the use cases and the subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if something is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is the 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exempt spectrum is Typically referred to as "unlicensed" spectrum. In this document the terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondarylicense-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for someprimary useand assigned for licensed use, but is not fully occupied by that primary use licensed use at a specificlocation and time. This spectrum is then assigned by locationlocal regulations for use as licensed-exempt spectrum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' Cc: "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unlicensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As an example, in the ITU-R context, an "unlicensed" band is typically a new band, say in the 300 GHz, for which no request has been made for its use. It is therefore un-allocated to a specific service so far and thus it is an "unlicensed" frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrations can thendecide under what king of regime it will 'assign' this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus "license-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicensed" in the USA. If the qualifier applies to an operation, the operation can be exempt of license by the local administration, thus a "license-exempt" operation. If, however, someone decides to start an RF transmission operation in a licensed band for which he has no license or in a license-exempt band for which he does not meet the requirements such as operating according to the type of operation for which the band is exempted from a license or he operates outside the technical limits imposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an "unlicensed" operation. If the qualifier applies to the transmission device, such device may be a "license-exempt" device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id de-facto an "unlicensed" device since it has not passed through the normal certification process. Note that a "license-exempt" device still has to go through a certification process and meet the limits imposed by the local regulator for the "license-exempt" operation in the given frequency band whereas an "unlicensed" device may not pass the certification process since it has not been licensed to operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licensed" operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses. Gerald _____ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs to be careful with the word'unlicensed' which may mean 'illegal' operation of an RF device in many administrations. Gerald _____ From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as 'license-exempt', in most cases the term 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statement: The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I would suggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald _______________________________________________ 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 ------=_NextPart_000_0085_01CCE689.A043FCE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter,

 

See my other email about = ‘secondary’ versus ‘opportunistic’.

 

I agree with you that = ‘primary’, ‘secondary’, ‘deterministic and ‘opportunistic’ use of the spectrum = has no relevance to whether the access could be free or paid (after all the primary access = to the TV bands by the broadcasters is free for historical reasons while one = could decide that some TVWS access could be paid ;-)  = ).

 

Again, the reason why one needs a = DB accessible over the internet is that the access to the spectrum is = ‘opportunistic’.  If this was deterministic, the DB would not be needed as has been = the case up to now.

 

Gerald

 

From: Peter = Stanforth [mailto:peter@spectrumbridge.com]
Sent: Wednesday, 08 = February, 2012 12:01
To: Gerald Chouinard; andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

There is no = reason to assume that use of white space is by licensed exempt or unlicensed = devices. This comes back to an earlier argument I made about what constitutes = licensed and unlicensed?

Again there = is no reason that a license exempt or unlicensed device should get access to = spectrum for "free" any more that a licensed device has to = "pay" for spectrum access.

The concept = of a primary user, who has priority over a secondary user has no relevance to = free or paid access. 

The = rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a = secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the = other, and an argument can be made for both. In a band occupied by a public = safety user there may be no choice but to have opportunistic access but in = other bands a primary user may be willing to commit to specific availability if = their own use is deterministic. 

 <= /o:p>

Peter = S.

 <= /o:p>

From: Gerald = Chouinard <gerald.chouinard@sympatico.= ca>
Date: Wed, 8 Feb 2012 = 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" = <nbravin@earthlink.net>, = "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /o:p>

Andy,

 

To resolve Nancy’s concern, a new definition could be added = for:

 

TVWS White Space devices: White = Space devices that operate in the TV bands.

 

This would complement the = definition of White Space devices and make it more = specific.

 

I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the = White Spacedevices. The opportunistic use of the RF spectrum assumes that = these devices operate while protecting existing operation in the band.  = There is automatically assumes the existence of primary users of the band that = have priority. Such primary users would most likely be licensed to use the = band and it is only the portions that happen to be unused that will be accessible = to the White Space devices.  The latter are unlikely to be licensed to = only use the ‘crumbs’. Removing the concept of license-exempt could = put these new devices at the same level of priority as the primary devices and then why would = they need to protect these ‘primary’ licensed = devices.

 

This would be similar to the = situation in the 2.4 GHz where a database is not needed to protect other devices. As = is well understood, the databases are there to protect primary and possibly = secondary licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other means such = as adatabase to provide coexistence and this is, I believe, beyond the = scope ofPAWS.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 = February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Nancy= , all

 =

Good = questions. I’m not proposing to remove references to TVWS, they are entirely = appropriate within the use cases since it is the TV bands we are studying as first candidate for opportunistic access, but the charter says we are = addressing all white space in the resulting protocol. To answer your other questions, = IMO our aim should be to provide all the necessary information in this PAWS requirements I-D to enable the PAWS protocol I-D to be developed. I = don’t think it’s our job to explain different regulatory regimes or = applications (beyond use cases) in this document, ITU and others do this very well, and = regulators tend to be well coordinated or play ‘follow my = leader’.

 =

Thanks for = pointing out the reference to licence-exempt that I had missed in 4.4 -  I = think the meaning would be just the same with ‘in a license-exempt TVWS = environment’ deleted from that sentence. That would be my = suggestion.

 =

Regards

 =

Andy

 =

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February 2012 = 14:48
To: Sago,AJ,Andy,COD = R
Cc: paws@ietf.org
Subject: Fwd: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /o:p>

Hi Andy, also, = throughout the document TVWS are mentioned in 4.1,4.5, 4.6…so if you propose to = remove any reference to TVWS it will = affect

the document as a = whole, and information that seems necessary to explain how the DB and protocol = interacts with TVWS devices and

the methods of = doing so. One can envision that current rules could change, but, why not give the = information on both for countries to understand = fully

what it's choices = are? 

 <= /o:p>

Thanks Andy, just = some early morning thoughts…Sincerely, Nancy

 <= /o:p>

Begin forwarded = message:

 <= /o:p>

From: Nancy Bravin <nbravin@earthlink.net>

Date: February 1, 2012 6:35:09 AM PST

To: Andy Sago <andy.sago@bt.com>

Subject: Re: [paws] Use cases and requirements I-D: = sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /o:p>

Hi Andy, = All

 <= /o:p>

In section 4.4, = license exempt is also mentioned as = well. 

I am conflicted in = a global sense when emerging countries, or countries with very different types of = gov't want to implement

the protocol, will = they have enough information to do so? and thereby join the existing DB companies, = or will they do their own thing

leaving holes in = what one hopes will be an interoperable global protocol that deals with TVWS, = and/or White spaces in general?

 <= /o:p>

Thanks, just a = thought.

 <= /o:p>

SIncerely, = Nancy

 <= /o:p>

 <= /o:p>

On Feb 1, 2012, at = 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

 <= /o:p>

Scott, = All

 

I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only why = the lower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th = Jan I proposed (= http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with “opportunistic” replacing = “secondary” in later sentences in the Introduction. I have checked and there are no further references = to licensing in the document, so we don’t need the definitions of = licence exempt, light licensing or unlicensed. This is not a regulatory document – = we are defining requirements fora protocol. Keep it simple.

 

That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  From Scott, = Gerald and Jussi’s comments perhaps we could agree on:

 

White Space = (WS)

 <= /font>

Radio = spectrum which is not fully occupied at a specific location and = time.

 <= /font>

White Space = device

 <= /font>

A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white spacedevice is required by local regulations to query a database with = its location to obtain information about available = spectrum.

 

Regards

 

Andy<= /font>

 

From: = paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: gerald.chouinard@sympatico.= ca; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /o:p>

That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?

 

Kind = regards,

Jussi=

 

From: = paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of ext = Gerald Chouinard
Sent: 31 January 2012 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /o:p>

Scott,

 

Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of “white space” as = follows:

 

White = Space

 <= /font>

Radio = spectrum which has been allocated and assigned for licensed use, but is not fully occupied = by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> bylocal regulations <delete>for use<delete> <insert>to = be used opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>

 

This way, it is understood that the database does not “assign” white space devices for them to = choose from.

 

Gerald

From: = scott.probasco@nokia.com [mailto:scott.proba= sco@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /p>

Hi = Gerald,

 <= /font>

Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that = we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?

 <= /font>

I also = corrected "location" to "local" in previous text proposed for "White Space".

 <= /font>

Kind = Regards,

Scott

 <= /font>

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>= , "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

= Scott,

= Great proposal.  However, I am still a bit nervous about the definitions = of “Protected Entity” and “White Space Devices (WSD)” where the = notion of secondary use is included.  The secondary status is used in the ITU-R Radio = Regulations for a different purpose.  In fact, it is possible that a band has = already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operationwhere the two first types = of services are not being used.  The use of “lower priority = opportunistic” service rather than “secondary” service would be preferable = to describe white spaceallocations.

=  

= Gerald

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
= Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

Hi,

 

I changed the subject line from " Re: [paws] Discussion on 'license-exempt' = vs 'unlicensed'  ". Here I try to propose some changes to the = draft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.

 

I hope this captures the key points of the discussion. Please do reply if something is still missing.

 

Kind Regards,

Scott

 

 

2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio = technologies,

      the database is an entity which contains current = information about

      available spectrum at any given location and other types = of

      information.

 

   Device ID

 

      A unique number for each master device and slave device = that

      identifies the manufacturer, model number and serial = number.

 

<Insert>

   Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given = service area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, = company merger &

      acquisition,  first-come / first-served or by = government allocation

      (e.g., public service).

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the USA, license-exempt spectrum is

      Typically referred to as "unlicensed" spectrum. = In this document the terms

      license-exempt and unlicensed are used = interchangeably.

 

</Insert>

 

   Location Based Service

 

      An application or device which provides data, information = or

      service to a user based on their = location.

 

  Master Device

 

      A device which queries the WS Database to find out the = available

      operating channels.

 

   Protected Entity

 

      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space

      devices) for its use</Delete> in a given area and = time.

 

   Protected Contour

 

      The exclusion area for a Protected Entity, held in the = database

      and expressed as a polygon with geospatial points as the = vertices.

 

   Slave Device

 

      A device which uses the spectrum made available by a = master

      device.

 

   TV White Space

 

      TV white space refers specifically to radio spectrum which = has

      been allocated for TV broadcast, but is not occupied by a = TV

      broadcast, or other licensed user (such as a wireless = microphone),

      at a specific location and time.

 

   White Space

 

      Radio spectrum which has been allocated <Delete>for someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>

 

   White Space Device (WSD)

 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</In= sert> user of some part of white space

      spectrum.  A white space device can be an access = point, base

      station, a portable device or similar.  In this = context, a white

      space device is required to query a database with its = location to

      obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" = <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Nancy,

=  

= This is not that simple.  In fact, the qualifiers = “license-exempt” and “unlicensed” can apply to more than one = thing.

=  

= If the qualifier applies to a frequency band, different options exist. As an = example, in the ITU-R context, an “unlicensed” band is typically a = new band, say in the 300 GHz, for which no request has been made for its use.  It is = therefore un-allocated to a specific service so far and thus it is an = “unlicensed” frequency band. Once the ITU-R allocates this band to one or many = services on a primary or secondary basis, then the administrations can thendecide = under what king of regime it will ‘assign’ this band foroperation. They = may decide to allow the use of the band on the basis of licensed operation (with = different options to do the assignment: auction, first come/first served, etc.) or = allow operation with an exemption of licenses, thus = “license-exempt”such as in the 2.4 GHz ISM band. This is also called “unlicensed” in = the USA.

=  

= If the qualifier applies to an operation, the operation can be exempt of = license by the local administration, thus a “license-exempt” operation. = If, however, someone decides to start an RF transmission operation in a licensed band = for which he has no license or in a license-exempt band for which he does = not meet the requirements such as operating according to the type of operation for = which the band is exempted from a license or he operates outside the technical = limits imposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an “unlicensed” = operation.

=  

= If the qualifier applies to the transmission device, such device may be a “license-exempt” device if its operation does not require a = specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someone smuggles a = device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id = de-facto an “unlicensed” device since it has not passed through the = normal certification process.

=  

= Note that a “license-exempt” device still has to go through a = certification process and meet the limits imposed by the local regulator for the = “license-exempt” operation in the given frequency band whereas an = “unlicensed” device may not pass the certification process since it has not been licensed to = operation in the country.

=  

= This is why the qualifier “unlicensed” has to be treated with care = and the footnote will need to be crafted very carefully.

=  

= With respect to your second point, if an administration only allows = “licensed” operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses.

=  

= Gerald

=  

From: Nancy Bravin [mailto:nbravin@earthlink.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Gabor and = Gerald, 

Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use = to indicate that "according to each countries regulatory = requirements"  

How to get = around the fact that some Countries are or will be "licensed only" by = their gov'ts?  Thanks

Nancy

On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:




= Gabor,

=  

= I agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word‘unlicensed’ which may mean = ‘illegal’ operation of an RF device in many administrations.

=  

= Gerald

=  

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as ‘license-exempt’, in most = cases the term ‘unlicensed-band’ is used.

 

Therefore, may I suggest that the draft will include the following = statement:

 

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.

 

-      = ;    Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

All,

 

= Here is my understanding of the terms:

=  

= Licensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).

=  

= Lightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through = auction over large service areas.

=  

= License-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

=  

= Unlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, this term is used to mean “license-exempt," see = above.

=  

= To my knowledge, the term “unlicensed” is used only in the USA to describe a legal operation = because the term “license-exempt” has been used for another specific = purpose.

=  

= Since the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I = would suggest the use of ‘licensed’ and = ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is used in the USA instead of the usual = ‘license-exempt’.

=  

= Gerald

_______________________________________________
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

 <= /o:p>

 <= /o:p>

------=_NextPart_000_0085_01CCE689.A043FCE0-- From peter@spectrumbridge.com Wed Feb 8 15:47:56 2012 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 9E23B11E809D for ; Wed, 8 Feb 2012 15:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_20=-0.74, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZY+7+QI5BGTO for ; Wed, 8 Feb 2012 15:47:53 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5E09711E8099 for ; Wed, 8 Feb 2012 15:47:52 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 8 Feb 2012 18:48:50 -0500 From: Peter Stanforth To: Gerald Chouinard Date: Wed, 8 Feb 2012 18:47:46 -0500 Thread-Topic: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AczmvDRgfIbCQto0Tje1QZi/xJGc3A== 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.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB58711E1FA73peterspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 08 Feb 2012 23:47:56 -0000 --_000_CB58711E1FA73peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Gerald, It depends what how we define as opportunistic. We run a secondary market = place for spectrum, FCC rules allow us to act as a "Spectrum Manager" in th= is role we can provide secondary access to devices under whatever criteria = the license holder deems acceptable. We are, in everything but name, provid= ing access to white space. In some cases this is opportunistic but in other= s it is very deterministic and the attraction of the spectrum is because it= is deterministic. The key is the owner may not know exactly when or where = they need the spectrum in the future but when they make it available it is = guaranteed to be available for the timeframe published. This would not be p= ossible without a database and yet is clearly not opportunistic. The same c= ould be said for current US FCC TVWS rules. If we provide a channel list an= d a timeframe (Say for the next 4 hours) that channel list will remain avai= lable for the duration. What is missing, in the case of white space, is th= at we cannot deny access to someone else in the same location who asks the = same question, whereas in our secondary marketplace we can. So not only is = availability deterministic access is too. Peter S. From: Gerald Chouinard > Date: Wed, 8 Feb 2012 17:46:44 -0500 To: Peter Stanforth > Cc: "andy.sago@bt.com" >, "nbravin@earthlink.net" >, "paws@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Peter, See my other email about =91secondary=92 versus =91opportunistic=92. I agree with you that =91primary=92, =91secondary=92, =91deterministic and = =91opportunistic=92 use of the spectrum has no relevance to whether the acc= ess could be free or paid (after all the primary access to the TV bands by = the broadcasters is free for historical reasons while one coulddecide that = some TVWS access could be paid ;-) ). Again, the reason why one needs a DB accessible over the internet is that t= he access to the spectrum is =91opportunistic=92. If this was deterministi= c, the DB would not be needed as has been the case up to now. Gerald ________________________________ From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Wednesday, 08 February, 2012 12:01 To: Gerald Chouinard;andy.sago@bt.com; nbravin@ear= thlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) There is no reason to assume that use of white space is by licensed exempt = or unlicensed devices. This comes back to an earlier argument I made about = what constitutes licensed and unlicensed? Again there is no reason that a license exempt or unlicensed device should = get access to spectrum for "free" any more that a licensed device has to "p= ay" for spectrum access. The concept of a primary user, who has priority over a secondary user has n= o relevance to free or paid access. The rationale for white space is that the spectrum is shared and that someo= ne has primary, preferred or priority access and the database ensures that = those rights/requirements are met by anyone who uses the spectrum on a seco= ndary basis. I would go further and say that the secondary access could be = deterministic or opportunistic. There is no reason to require one or the ot= her, and an argument can be made for both. In a band occupied by a public s= afetyuser there may be no choice but to have opportunistic access but in ot= her bands a primary user may be willing to commit to specific availability = if their own use is deterministic. Peter S. From: Gerald Chouinard > Date: Wed, 8 Feb 2012 10:20:52 -0500 To: "andy.sago@bt.com" >, "nbravin@earthlink.net" >, "paws@ietf.org" > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Andy, To resolve Nancy=92s concern, a new definition could be added for: TVWS White Space devices: White Space devices that operate in the TV bands. This would complement the definition of White Space devices and make it mor= e specific. I am having second thoughts about yoursuggestion to remove the concept of c= lasses of devices from the White Spacedevices. The opportunistic use of the= RF spectrum assumes that these devices operate while protecting existing o= peration in the band. There is automatically assumes the existence of prim= ary users of the band that have priority. Such primary users would most lik= ely be licensed to use the band and it is only the portions that happen to = be unused that will be accessible to the White Space devices. The latter a= re unlikely to be licensed to only use the =91crumbs=92. Removing the conce= pt of license-exempt could put these new devices at the same level of prior= ity as the primary devices and then why would they need to protect these = =91primary=92 licensed devices. This would be similar to the situation in the 2.4 GHz where a database is n= ot needed to protect other devices. As is well understood, the databases ar= e there to protect primary and possibly secondary licensed devices from the= new opportunistic devices, not opportunistic devices among themselves. The= latter case would be covered by other means such as adatabase to provide c= oexistence and this is, I believe, beyond the scope ofPAWS. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Wednesday, 01 February, 2012 09:58 To: nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Nancy, all Good questions. I=92m not proposing to remove references to TVWS, they are = entirely appropriate within the use cases since it is the TV bands we are s= tudying as first candidate for opportunistic access, but the charter says w= e are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary informa= tion in this PAWS requirements I-D to enable the PAWS protocol I-D to be de= veloped. I don=92t think it=92s our job to explain different regulatory reg= imes or applications (beyond use cases) in this document, ITU and others do= this very well, and regulators tend to be well coordinated or play =91foll= ow my leader=92. Thanks for pointing out the reference to licence-exempt that I had missed i= n 4.4 - I think the meaning would be just the same with =91in a license-ex= empt TVWS environment=92 deleted from that sentence. That would be my sugge= stion. Regards Andy From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: 01 February 2012 14:48 To: Sago,AJ,Andy,COD R Cc: paws@ietf.org Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Intro= duction, Conventions and Terminology, Prior Work) Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6= =85so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain ho= w the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could change, = but, why not give the information on both for countries to understand fully what it's choices are? Thanks Andy, just some early morning thoughts=85Sincerely, Nancy Begin forwarded message: From: Nancy Bravin > Date: February 1, 2012 6:35:09 AM PST To: Andy Sago > Cc: >, >, >, > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Andy, All In section 4.4, license exempt is also mentioned as well. I am conflicted in a global sense when emerging countries, or countries wit= h very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby join = the existing DB companies, orwill they do their own thing leaving holes in what one hopes will be an interoperable global protocol th= at deals with TVWS, and/orWhite spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, > > wrote: Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV = white spaces, whereas the scope of PAWS is white spaces in general. I would= question not only why thelower-priority service would always be licence-ex= empt, but why the higher priority service would always be licenced. To avoi= d this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/p= aws/current/msg00576.html) a revision of the Abstract that avoids the terms= licence exempt or unlicensed, or any mention of the regulatory status of t= he incumbent services. The Abstract derives from the Introduction and the t= ext could be aligned to be the same in the Introduction, with =93opportunis= tic=94 replacing =93secondary=94 in later sentences in the Introduction. I = have checked and there are no further references to licensing in the docume= nt, so we don=92t need the definitions of licence exempt, light licensing o= r unlicensed. This is not a regulatory document =96 we are defining require= ments fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum= use has now got muddled with the potential for opportunistic use. This can= be fixed by taking the white space and white space device definitions toge= ther. From Scott, Gerald and Jussi=92s comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum= , under control of a white space database. A white space device can be an = access point, base station, a portable device or similar. In this context,= a white spacedevice is required by local regulations to query a database w= ith its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of jussi= .kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; sc= ott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not= necessarily apply to all under-utilised radio spectrum. Why would the lowe= r priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext G= erald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of =93white space=94 as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed byl= ocal regulations for use to beused opportunisticall= y as licensed-exempt spectrum under control of a white space databa= se. This way, it is understood that the database does not =93assign=94 white sp= ace devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notio= n of secondary use is included. The secondary status is used in the ITU-R = Radio Regulations for a different purpose. In fact, it is possible that a = band has already primary and secondary services allotted to it and that the= White Space operation is a tertiary opportunistic operationwhere the two f= irst types ofservices are not being used. The use of =93lower priority opp= ortunistic=94 service rather than =93secondary=94 service would be preferab= le to describe white spaceallocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for someprimary useand assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers =93license-exempt=94 and = =93unlicensed=94 can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in the ITU-R context, an =93unlicensed=94 band is typically a ne= w band, say in the 300 GHz, for which no request has been made for its use.= It is therefore un-allocated to a specific service so far and thus it is = an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to o= ne or many services on a primary or secondary basis, then the administratio= ns can thendecide under what king of regime it will =91assign=92 this band = foroperation. They may decide to allow the use of the band on the basis of = licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licen= ses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also= called =93unlicensed=94 in the USA. If the qualifier applies to an operation, the operation can be exempt of li= cense by the local administration, thus a =93license-exempt=94 operation. I= f, however, someone decides to start an RF transmission operation in a lice= nsed band for which he has no license or in a license-exempt band for which= he does not meet the requirements such as operating according to the type = of operation for which the band is exempted from a license or he operates o= utside the technical limitsimposed by this license-exempt ruling, his opera= tion is therefore illegal and he is then considered to be running an =93unl= icensed=94 operation. If the qualifier applies to the transmission device, such device may be a = =93license-exempt=94 device if its operation does not require a specific li= cense or registration with the local administration such as TV receivers of= Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a dev= ice that is not allowed in a country by, for example, buying it on eBay and= operates it, this is then an illegal device in the country and id de-facto= an =93unlicensed=94 device since it has not passed through the normal cert= ification process. Note that a =93license-exempt=94 device still has to go through a certifica= tion process and meet the limits imposed by the local regulator for the =93= license-exempt=94 operation in the given frequency band whereas an =93unlic= ensed=94 device may not pass the certification process since it has not bee= n licensed to operation in the country. This is why the qualifier =93unlicensed=94 has to be treated with care and = the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows =93lice= nsed=94 operation, the situation will be much simpler to manage since speci= fic conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word=91unlicensed=92 which may mean =91illegal=92 o= peration of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as =91license-exempt=92, in most cases t= he term =91unlicensed-band=92 is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos thatwould normally work with full lice= nsing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I wouldsuggest the use of =91licensed=92 and =91license-exempt=92 wit= h a footnote indicating that the term =91unlicensed=92 is used in the USA i= nstead of the usual =91license-exempt=92. Gerald _______________________________________________ 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 --_000_CB58711E1FA73peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Gerald,
It depends wh= at how we define as opportunistic.  We run a secondary market place fo= r spectrum, FCC rules allow us to act as a "Spectrum Manager" in = this role we can provide secondary access to devices under whatever criteri= a the license holder deems acceptable. We are, in everything but name, prov= iding access to white space. In some cases this is opportunistic but in oth= ers it is very deterministic and the attraction of the spectrum is because = it is deterministic. The key is the owner may not know exactly when or wher= e they need the spectrum in the future but when they make it available it i= s guaranteed to be available for the timeframe published. This would not be= possible without a database and yet is clearly not opportunistic. The same= could be said for current US FCC TVWS rules. If we provide a channel list = and a timeframe (Say for the next 4 hours) that channel list will remain av= ailable for the duration.  What is missing, in the case of white space= , is that we cannot deny access to someone else in the same location who as= ks the same question, whereas in our secondary marketplace we can. So not o= nly is availability deterministic access is too. 
Peter S.

From: Gera= ld Chouinard <gerald.ch= ouinard@sympatico.ca>
Date: Wed, 8 Feb 2012 17:46:44 -0500
To: = Peter Stanforth <pet= er@spectrumbridge.com>
Cc: "andy.sago@bt.com" <= ;andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "<= a href=3D"mailto:paws@ietf.org">paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3= (Introduction, Conventions and Terminology, Prior Work)

=

Peter,

 

See my other email about =91secondary= =92 versus =91opportunistic=92.

 

I agree with you that =91primary=92, = =91secondary=92, =91deterministic and =91opportunistic=92 use of the spectrum has no relevan= ce to whether the access could be free or paid (after all the primary access to t= he TV bands by the broadcasters is free for historical reasons while one could= decide that some TVWS access could be paid ;-)  ).

 

Again, the reason why one needs a DB accessible over the internet is that the access to the spectrum is =91oppor= tunistic=92.  If this was deterministic, the DB would not be needed as has been the= case up to now.

 

Gerald

 

<= /div>

From: Pete= r Stanforth [mailto:peter@spectrumbridge.co= m]
Sent: Wednesday, = 08 February, 2012 12:01
To: Gerald Chouinar= d;andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject= : Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology= , Prior Work)

 

There is no reason to assume that use of white space is by licensed exempt or unlicensed devic= es. This comes back to an earlier argument I made about what constitutes licens= ed and unlicensed?

Again there is no reason that a license exempt or unlicensed device should get access to spec= trum for "free" any more that a licensed device has to "pay"= for spectrum access.

The concept of a primary user, who has priority over a secondary user has no relevance to fr= ee or paid access. 

The rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the ot= her, and an argument can be made for both. In a band occupied by a public safety= user there may be no choice but to have opportunistic access but in other b= ands a primary user may be willing to commit to specific availability if their o= wn use is deterministic. 

 

Peter S.

 

From: Gerald Chouinard <gerald.chouinard@sympa= tico.ca>
Date: Wed= , 8 Feb 2012 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology= , Prior Work)

<= font size=3D"2" color=3D"#040100" face=3D"Calibri"> <= /p>

Andy,

 <= /p>

To resolve Nancy=92s concern, a new definition could be added for:

=  <= /p>

TVWS White Space devices: White Space = devices that operate in the TV bands.

 <= /p>

This would complement the definition o= f White Space devices and make it more specific.

 <= /p>

I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the White Spacedevices. The opportunistic use of the RF spectrum assumes that these devices operate while protecting existing operation in the band.  Ther= e is automatically assumes the existence of primary users of the band that have priority. Such primary users would most likely be licensed to use the band = and it is only the portions that happen to be unused that will be accessible to= the White Space devices.  The latter are unlikely to be licensed to only u= se the =91crumbs=92. Removing the concept of license-exempt could put these ne= w devices at the same level of priority as the primary devices and then why would the= y need to protect these =91primary=92 licensed devices.

 <= /p>

This would be similar to the situation= in the 2.4 GHz where a database is not needed to protect other devices. As is = well understood, the databases are there to protect primary and possibly seconda= ry licensed devices from the new opportunistic devices, not opportunistic devi= ces among themselves. The latter case would be covered by other means such as adatabase to provide coexistence and this is, I believe, beyond the scope ofPAWS.

 <= /p>

Gerald<= /p>

 <= /p>

From: paws-bounce= s@ietf.org [mailto:paws-bounces@ietf.org]= On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject= : Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology= , Prior Work)

 

Nancy= , all

 <= /u1:p><= o:p>

Good questions. I=92m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are studying as first candidate for opportunistic access, but the charter says we are addressing = all white space in the resulting protocol. To answer your other questions, IMO = our aim should be to provide all the necessary information in this PAWS requirements I-D to enable the PAWS protocol I-D to be developed. I don=92t= think it=92s our job to explain different regulatory regimes or applications (bey= ond use cases) in this document, ITU and others do this very well, and regulato= rs tend to be well coordinated or play =91follow my leader=92.

 

T= hanks for pointing out the reference to licence-exempt that I had missed in 4.4 -  I thin= k the meaning would be just the same with =91in a license-exempt TVWS environ= ment=92 deleted from that sentence. That would be my suggestion.

 

Reg= ards

 

Andy=

&nb= sp;

From:= Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February 2012 1= 4:48
To: Sago,AJ,Andy,COD= R
Cc: paws@ietf.org
Sub= ject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminolog= y, Prior Work)

 <= /span>

Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6=85so if you propose to remove a= ny reference to TVWS it will affect

<= div>

t= he document as a whole, and information that seems necessary to explain how the DB and protocol interac= ts with TVWS devices and

<= p class=3D"MsoNormal">the me= thods of doing so. One can envision that current rules could change, but, why not give the informa= tion on both for countries to understand fully

what it's choices are? 

 

<= p class=3D"MsoNormal">Thanks= Andy, just some early morning thoughts=85Sincerely, Nancy=

&nbs= p;

Begin forwarded message:=

<= span lang=3D"EN-GB" style=3D"font-size:12.0pt;color:#040100"> 

From: Nancy Bravin <nb= ravin@earthlink.net>

Date: February 1, 2012 6:35:09 AM PST

To: Andy Sago <andy.sago@= bt.com>

Subject: Re: [paws] Use cases and requirements I-D: secti= ons 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 

=

= Hi Andy, All

 

In section 4.4, license exempt is also mentioned as well. 

I am conflicted in a global sense when emerging countries, or countries with very different types of go= v't want to implement

the protoc= ol, will they have enough information to do so? and thereby join the existing DB companies, or= will they do their own thing

leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/or= White spaces in general?

 

Thanks, just a thought.=

 <= o:p>

SIncerely, Nancy

 

 

= On Feb 1, 2012, at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> wrote:<= /span>

 

Scott, All<= font color=3D"#040100">

 =

I agree with Jussi that we have now narrowed the definition to apply to TV white spaces, where= as the scope of PAWS is white spaces in general. I would question not only why the= lower-priority service would always be licence-exempt, but why the higher priority service would always be licenced. To avoid this issue on 27th Jan = I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html<= /a>) a revision of the Abstract that avoids the terms licence exempt or unlicens= ed, or any mention of the regulatory status of the incumbent services. The Abst= ract derives from the Introduction and the text could be aligned to be the same = in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in lat= er sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the definitions of licence ex= empt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it simple.

 <= span style=3D"color:#040100">

 

<= font size=3D"2" color=3D"#040100" face=3D"Tahoma">From: paws-bounces= @ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: = gerald.chouinard@sympatico= .ca; scott.probasco@nokia.com; paws@ietf= .org
Subject: Re: [paws] Use cases and require= ments I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work= )=

 

That statement is valid for TV White Spaces on UHF frequencies but does not necessarily apply= to all under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt?

 

Kind regards= ,=

Jussi=

 

From: scott.pro= basco@nokia.com [mailto:scott.probasco@= nokia.com] 
Sent: Tuesday, 31 January, 2012 15:12
To: = ;gerald.chouinard@s= ympatico.ca; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work= )=

 

<= u1:p>

Hi Gerald,

=  

Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descripti= ons of licensed spectrum and license-exempt spectrum, I used these words. Do th= ese changes remove your concerns?

&= nbsp;

I also corrected "location" to "local" in previous text proposed for "White Space".

&nbs= p;

Kind Regards,<= font color=3D"#040100">

Scott

 

<= font size=3D"2" color=3D"black" face=3D"Calibri">From: ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@no= kia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 

Scott,=

Great proposal.  However, I am still a bit nervous about the definitions of = =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notion of secondary= use is included.  The secondary status is used in the ITU-R Radio Regulations= for a different purpose.  In fact, it is possible that a band has already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operationwhere the two first types of= services are not being used.  The use of =93lower priority opportunist= ic=94 service rather than =93secondary=94 service would be preferable to describe= white spaceallocations.

 =

Gerald

 

From: <= /span>paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 

Hi,

<= /div>

 

<= /div>

I changed the subject line from " Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the draft based on the email discussion.

=

 

=

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licen= sed' and 'license-exempt' and made changes to the term 'white space'. I have tri= ed to work from the perspective that the document should accurately explain th= e subject with aim that a reader can understand the use cases and the subsequ= ent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage.<= /span>

 <= /span>

I hope this captures the key points of the discussion. Please do reply if something is still missing.

 

Kind Regards,

Scott

 

 

<= span style=3D"font-size:10.5pt;font-family:Calibri;color:black;font-weight:= bold">2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio technologies= ,

&nbs= p;     the database is an entity which contains current information a= bout

=       available spectrum at any given location and other types of=

 &nb= sp;    information.

 

   Device ID

 

      A unique number for each master device and slave device that

 &n= bsp;    identifies the manufacturer, model number and serial number.

 

<Inse= rt>

   Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given service = area

=       for a given time period.  This is usually done through auctions,award

=

      (beauty contest), acquisition from secondary market, company merger &

<= span style=3D"font-size:10.5pt;font-family:Calibri;color:black;font-weight:= bold">      acquisition,  first-come / first-served or by government allocation

      (e.g., public service).

=

 

=

   License-exempt Spectrum

<= div>

 

<= div>

      Spectrum that is not assigned to any specific user. One exampl= e is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the USA, license-exempt spectrum is

      Typically referred to as "unlicensed" spectrum. In t= his document the terms

<= div>

      license-exempt and unlicensed are used interchangeably.=

 =

</Insert&g= t;<= u1:p>

&nbs= p;<= u1:p>

&nbs= p;  Location Based Service

 

      An application or device which provides data, information or

 &n= bsp;    service to a user based on their location.

 

  Master Device

=  

=       A device which queries the WS Database to find out the availab= le<= u1:p>

&nbs= p;     operating channels.<= span style=3D"color:#040100">

 <= span style=3D"color:#040100">

   Protected Entity

 

      <Insert>A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A licensed</Insert&g= t; user of white space spectrum <Delete>which</Delete> is afforded=

&nbs= p;     protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white space<= /span>

      devices) for its use</Delete> in a given area and time.<= /span>

 <= /span>

 &= nbsp; Protected Contour

 

      The exclusion area for a Protected Entity, held in the databas= e

&nbs= p;     and expressed as a polygon with geospatial points as the verti= ces.

=  

=    Slave Device

<= span style=3D"font-size:10.5pt;font-family:Calibri;color:black;font-weight:= bold"> 

<= span style=3D"font-size:10.5pt;font-family:Calibri;color:black;font-weight:= bold">      A device which uses the spectrum made available by a master=

 &nb= sp;    device.

 

   TV White Space

=

 

=

      TV white space refers specifically to radio spectrum which has=

&nbs= p;     been allocated for TV broadcast, but is not occupied by a TV

 &n= bsp;    broadcast, or other licensed user (such as a wireless micropho= ne),

=       at a specific location and time.<= /font>

 <= /font>

   White Space

 

      Radio spectrum which has been allocated <Delete>for someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but

<= div>

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white sp= ace database.</Insert>

=

 

   White Space Device (WSD)

=

 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</Inse= rt> user of some part of white space<= span style=3D"color:#040100">

      spectrum.  A white space device can be an access point, b= ase=

&nb= sp;     station, a portable device or similar.  In this context, = a white

=       space device is required to query a database with its location= to=

&nb= sp;     obtain information about available spectrum.=

 =

 =

=  

<= font size=3D"2" color=3D"black" face=3D"Calibri">From: ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@ear= thlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

=  

<= st1:place w:st=3D"on">Nancy,

=

 

This is not that simple.  In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to more than one thing.

 

<= /div>

If the qualifier applies to a frequency band, different options exist. As an examp= le, in the ITU-R context, an =93unlicensed=94 band is typically a new band, say= in the 300 GHz, for which no request has been made for its use.  It is theref= ore un-allocated to a specific service so far and thus it is an =93unlicensed= =94 frequency band. Once the ITU-R allocates this band to one or many services = on a primary or secondary basis, then the administrations can thendecide under w= hat king of regime it will =91assign=92 this band foroperation. They may decide= to allow the use of the band on the basis of licensed operation (with differen= t options to do the assignment: auction, first come/first served, etc.) or al= low operation with an exemption of licenses, thus =93license-exempt=94such as i= n the 2.4 GHz ISM band. This is also called =93unlicensed=94 in the USA.

 

If the qualifier applies to an operation, the operation can be exempt of license b= y the local administration, thus a =93license-exempt=94 operation. If, howeve= r, someone decides to start an RF transmission operation in a licensed band fo= r which he has no license or in a license-exempt band for which he does not m= eet the requirements such as operating according to the type of operation for which= the band is exempted from a license or he operates outside the technical limits= imposed by this license-exempt ruling, his operation is therefore illegal a= nd he is then considered to be running an =93unlicensed=94 operation.

 

If the qualifier applies to the transmission device, such device may be a =93license-exempt=94 device if its operation does not require a specific li= cense or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someone smuggles a devic= e that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id de-facto = an =93unlicensed=94 device since it has not passed through the normal certific= ation process.

 

Note that a =93license-exempt=94 device still has to go through a certification = process and meet the limits imposed by the local regulator for the =93license-exemp= t=94 operation in the given frequency band whereas an =93unlicensed=94 device ma= y not pass the certification process since it has not been licensed to operation = in the country.

 

This is why the qualifier =93unlicensed=94 has to be treated with care and the foot= note will need to be crafted very carefully.<= /p>

 

W= ith respect to your second point, if an administration only allows =93licensed= =94 operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses.<= /font>

 

<= div>

Gerald

 

From: Nancy Bravin [mailto:nbravin@earth= link.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Gabor and Gerald, 

Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements&quo= t;  

How to ge= t around the fact that some Countries are or will be "licensed only" by their gov'ts?  Thanks

Nancy

On Jan 30, 2012, at = 4:13 PM, Gerald Chouinard wrote:




Gabor,=

 

I agree with your proposal.  Thisseems to be reasonable.  However one nee= ds to be careful with the word=91unlicensed=92 which may mean =91illegal=92 op= eration of an RF device in many administrations.

 

G= erald

 

From: <= /span>Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as =91license-exempt=92, in most cases the ter= m =91unlicensed-band=92 is used.

=

 

Therefore, may I suggest that the draft will include the following statement:

 <= /o:p>

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band.

 

-<= /span>          Gabor

 

=

<= font size=3D"2" color=3D"black" face=3D"Tahoma">From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'

=  

All,

<= /div>

 

H= ere is my understanding of the terms:

=

 

Licensed: Spectrum that is acquired by an operator over a given service area for a gi= ven time period.  This is usually done through auctions (think of the Telc= os), beauty contest, first-come / first-served or by government allocation (e.g.= , public service).

 =

Lightly licensed: Special case where thefrequency allocation is done through first-= come / first-served process for a given time frame over a relatively limited ser= vice area. The annual license fee is usually small to facilitate the deployment = of a service that would not normally be economically attractive.  Small loc= al operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through auct= ion over large service areas.

=

 

License-exempt: Operation of RF devices in a frequency band where no formal licensing proce= ss is needed such as in the 2.4 GHz ISM band. In the = USA, this term is used for a specific type of operation. The FCC should be conta= cted to clarify it.

 <= /span>

= Unlicensed: Illegal operation of an RF device that can transmit in a frequency band wit= hout a duly issued license.  In the&n= bsp;USA, this term is used to mean =93license-exempt," see above.=

 <= /font>

To my knowledge, the term =93unlicensed=94 is used only in the USA to describe a legal operation becau= se the term =93license-exempt=94 has been used for another specific purpose.

<= font size=3D"2" color=3D"navy" face=3D"Arial"> <= font color=3D"#040100">

Since the PAWS addresses the interface to the database for the international market, = it should rely on the definition of the terms recognized by the ITU-R. I would= suggest the use of =91licensed=92 and =91license-exempt=92 with a footnote = indicating that the term =91unlicensed=92 is used in the USA instead of the usual =91license-exempt=92.

 <= /span>

Gerald

=

_______________________________________________
paws mailing list
paws@ietf.org
= https://www.ietf.org= /mailman/listinfo/paws


 

_______________________________________________ paws mailing list paws@ietf.org h= ttps://www.ietf.org/mailman/listinfo/paws<= /font>

__________________________________= _____________
paws mailing list
paws@ietf.org
= https://www.ietf.org= /mailman/listinfo/paws

&= nbsp;

 

--_000_CB58711E1FA73peterspectrumbridgecom_-- From paul@marvell.com Wed Feb 8 18:28:09 2012 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 BFD5321F84FC for ; Wed, 8 Feb 2012 18:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.11 X-Spam-Level: X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXXgMLzqIBsu for ; Wed, 8 Feb 2012 18:28:09 -0800 (PST) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id A87DF21F84BF for ; Wed, 8 Feb 2012 18:28:08 -0800 (PST) Received: from sc-owa02.marvell.com ([65.219.4.130]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKTzMvM6wiY4J9tMPiF+2jb7d0s08hswdg@postini.com; Wed, 08 Feb 2012 18:28:08 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa02.marvell.com ([10.93.76.22]) with mapi; Wed, 8 Feb 2012 18:27:59 -0800 From: Paul Lambert To: Rex Buddenberg , Gerald Chouinard Date: Wed, 8 Feb 2012 18:27:58 -0800 Thread-Topic: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) Thread-Index: AczmsvUfzFLaHD2fRgOMxKTSF3JSfwAHzCXA Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4FCB8@SC-VEXCH2.marvell.com> References: <1328740910.9169.2112.camel@localhost.localdomain> In-Reply-To: <1328740910.9169.2112.camel@localhost.localdomain> 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] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) 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, 09 Feb 2012 02:28:09 -0000 >The way out of this circle is to again ape IEEE 802.16. The device in >the middle is known as RS, short for relay station. Why copy terms from a dying standard ... versus using 802.11af terminology? Paul From Gabor.Bajko@nokia.com Wed Feb 8 22:02:49 2012 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 E414221F84F7 for ; Wed, 8 Feb 2012 22:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.734 X-Spam-Level: X-Spam-Status: No, score=-2.734 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDx3f31d1RNT for ; Wed, 8 Feb 2012 22:02:48 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD0821F84F5 for ; Wed, 8 Feb 2012 22:02:47 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1962Hw0032162 for ; Thu, 9 Feb 2012 08:02:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 08:02:36 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.5]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Thu, 9 Feb 2012 07:02:35 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrYJn4ueezOOUqV6hR34bPZkJYrhEmAgAABRICAAAFcgIAAKKCAgAACkICAAAZogIAIYLFA Date: Thu, 9 Feb 2012 06:02:34 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DF0E1D@008-AM1MPN1-006.mgdnok.nokia.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F34@SC-VEXCH2.marvell.com> <7BAC95F5A7E67643AAFB2C31BEE662D01567763F43@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01567763F43@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2012 06:02:36.0329 (UTC) FILETIME=[6BE01990:01CCE6F0] X-Nokia-AV: Clean Subject: Re: [paws] Threat model (Rev 3) 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, 09 Feb 2012 06:02:50 -0000 This is a good point. But from the list provided below, only d) seems to be= a security related threat fit to be included into the security considerati= ons section of the draft. The other events look other than security related= to me. If we replace Threat 7 with the text in point d) below, I think we address = Paul's point. s/ Threat 7: Termination of device service for reasons other than incumbent= protection./ Threat 7: Malicious individual acts as a PAWS entity (spoofin= g DB or as MiM) to terminate or unfairly limit spectrum access of devices f= or reasons other than incumbent protection. - Gabor -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Paul Lambert Sent: Friday, February 03, 2012 2:58 PM To: Patil Basavaraj (Nokia-CIC/Dallas); jmh@joelhalpern.com; Brian.Rosen@ne= ustar.biz Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) Hi Raj, First - a threat needs an actor or source. We seem to have different views= of possible sources. >>>>> Threat 7: Termination of device service for reasons other than >>>>> incumbent protection Termination of device service is the end-impact (a useful starting point, b= ut not exactly the threat).=20 Some of the associated threat events are: a) Government (related to regulatory authority or not) uses WS Database to= terminate or unfairly limit spectrum access of devices for reasons other than incumbent protection. b) Service provider or DB provider uses WS Database to terminate or unfair= ly limit spectrum access of devices for reasons other than incumbent protection. c) Owner of a Master device uses WS Database to terminate or unfairly limi= t spectrum access of devices for reasons other than incumbent protection. d) Malicious individual acts as a PAWS entity (spoofing DB or as MiM) to t= erminate or unfairly limit spectrum access of devices for reasons other than incumbent protection e) Natural disaster knocks out communications to the database preventing s= pectrum access. It seems silly for us to rush so quickly into building the fastest possible= kill switch for communications. Push notifications are a cool mechanisms,= but we also need some level of assurance that we will have continuity of u= sage of a set of channels. Ideally we'd have some looser limits on the on-= channel times.=20 Paul >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Friday, February 03, 2012 2:35 PM >To: Paul Lambert; jmh@joelhalpern.com; Brian.Rosen@neustar.biz >Cc: paws@ietf.org >Subject: Re: [paws] Threat model (Rev 3) > > >Hi Paul. > >On 2/3/12 4:26 PM, "ext Paul Lambert" wrote: > >> >>>>> Threat 7: Termination of device service for reasons other than >>>>> incumbent protection >>>>> >>>>> A white space database may include a mechanism by which=20 >>>>>service >>>>> and channels allocated to a master device can be revoked. A >>>>> malicious node can send a revoke message to a master >>>>> device. This results in denial of service to the master >>>>> device. >> >>No clue what you mean by "malicious node" ... this could be a=20 >>Database, Master, random MiM, etc. > >My interpretation of the additional threat you had suggested in a=20 >previous email=D0. >The point about this threat is that we have discussed about the=20 >possibility of the database having the capability to send an=20 >unsolicited push notification (to the master device) for revoking the=20 >previously allocated channels and ceasing operation. >So the "malicious node" in this case is an entity which pretends to be=20 >the database and sends such a push notification message to the master=20 >device. > >> >> >>I was really thinking more about the misuse of the Database, or Master >to: >> - turn off devices presumed to be violating the DCMA > >DCMA? >The aspect of a device being switched off is covered in this threat. > >> - limiting spectrum usage based on the type or purpose of the traffic=20 >>(e.g. Oakland BART) >> - limitation of spectrum usage based on political affiliation, race,=20 >>gender, ideology, >> individual identity, etc. > >I don't get the above two. Care to expand on these? > >> >>We may not be able to prevent (at a protocol level) unfair allocation >or >>disablement. We should at least be able to have adequate logging and=20 >>records that given an expectation of fair allocation - we can detect >and >>complain when our mobile devices are turned off. > >So do we need to capture this in the form of a threat? Do we want to=20 >have a requirement that the protocol needs to enable logging and record=20 >keeping? That=B9s more of an implementation issue. > >-Raj > >> >>Paul >> >> >> >> >> >>>-----Original Message----- >>>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf >Of >>>Joel M. Halpern >>>Sent: Friday, February 03, 2012 12:01 PM >>>To: Rosen, Brian >>>Cc: paws@ietf.org >>>Subject: Re: [paws] Threat model (Rev 3) >>> >>>In the unauthorized use section, there is still the text saying: >>> The attacker may listen to >>> the communication between a valid master device and white >space >>> database and utilize the information about available channels >>> in the response message by utilizing those channels. >>> >>>I still find this totally mind-bending, as it is about the hardest=20 >>>way imaginable to undertake this attack. >>> >>> >>>On 2/3/2012 2:55 PM, Rosen, Brian wrote: >>>> >>>> Where do you see this assumption in the threat model? >>>> >>>> I took a quick look and didn't spot it. It would be "database >>>information leaked to bad guys" or something like it, right? >>>> >>>> I don't think that is a threat, and I don't think we need to=20 >>>> protect >>>anyone from that threat. >>>> >>>> I would say, however, that if you could know the content of the >>>database, and you can observe a responses over a period of time, you >may >>>be able to infer the location of the querier. >>>> >>>> Brian >>>> >>>> >>>> On Feb 3, 2012, at 2:51 PM, Joel M. Halpern wrote: >>>> >>>>> Can we please include in this document some articulation of the=20 >>>>> confidentiality assumption we are making with regard to the >>>whitespace >>>>> data itself? I am not trying to object to the threats. (And the=20 >>>>> personal information collection issues are enough to jsutify >include >>>>> confidentiality mechanisms in the solutions.) But I am still=20 >>>>> trying to get my head around this. There are going >to >>>be >>>>> hoards of whitespace devices. They will be getting the data, and >>>either >>>>> using it themselves or retransmitting it. The resulting data one=20 >>>>> whitespace availability will be visible to people and or devices >>>which >>>>> are not completely controlled by the regulatory agencies. >>>>> As such, what is the role of confidentiality with regard to this=20 >>>>> information? >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 2/3/2012 2:34 PM, Basavaraj.Patil@nokia.com wrote: >>>>>> >>>>>> Below is Rev 3 of the threat model based on feedback from=20 >>>>>> Stephen, >>>Nancy >>>>>> and Gabor (Thanks). >>>>>> >>>>>> -Raj >>>>>> >>>>>> >>>>>> Rev 3 (3/2/12) >>>>>> >>>>>> Threat model for the PAWS protocol >>>>>> ---------------------------------- >>>>>> >>>>>> Assumptions: >>>>>> ............ >>>>>> >>>>>> o It is assumed that an attacker has full access to the network >>>medium >>>>>> between the master device and the white space database. The >>>attacker >>>>>> may be able to eavesdrop on any communications between these >>>>>> entities. The link between the master device and the white >space >>>>>> database can be wired or wireless and provides IP connectivity. >>>>>> >>>>>> o It is assumed that the master device or the white space database >>>>>> have NOT been compromised from a security standpoint. >>>>>> >>>>>> Threat 1: User modifies a device to masquerade as another valid >>>>>> certified device >>>>>> >>>>>> The master device needs to authenticate itself with the >>>white >>>>>> space database prior to requesting channel information. >The >>>>>> attacker may try to get access to the secrets of the >master >>>>>> device which can be used maliciously. The effect of such >an >>>>>> attack being successful would result in a malicious client >>>>>> replaying the stolen authentication/authorization secrets >to >>>a >>>>>> white space database. >>>>>> >>>>>> Threat 2: Spoofed white space database >>>>>> >>>>>> A master device discovers a white space database(s) thru >>>which >>>>>> it can query for channel information. The master device >>>needs >>>>>> to ensure that the white space database with which it >>>>>> communicates with is an authentic entity. The white space >>>>>> database needs to provide its identity to the master >device >>>>>> which can confirm the validity/authenticty of the >database. >>>An >>>>>> attacker may attempt to spoof a white space database and >>>>>> provide responses to a master device which are malicious >and >>>>>> result in the master device causing interference to the >>>primary >>>>>> user of the spectrum. >>>>>> >>>>>> Threat 3: Modifying a query request >>>>>> >>>>>> An attacker may modify the query request sent by a master >>>>>> device to a white space database. The attacker may change >>>the >>>>>> location of the device or the capabilities in terms of its >>>>>> transmit power or antenna height etc. which could result >in >>>the >>>>>> database responding with incorrect information about >>>available >>>>>> channels or max transmit power allowed. The result of=20 >>>>>> such >>>an >>>>>> attack is that the master device would cause=20 >>>>>> intereference >>>to >>>>>> the primary user of the spectrum. It could also result in >a >>>>>> denial of service to the master device by indicating that >no >>>>>> channels are available. >>>>>> >>>>>> Threat 4: Modifying a query response >>>>>> >>>>>> An attacker could modify the query response sent by the >>>white >>>>>> space database to a master device. The channel=20 >>>>>> information >>>or >>>>>> transmit power allowed type of parameters carried in the >>>>>> response could be modified by the attacker resulting in >the >>>>>> master device using channels that are not available at a >>>>>> location or transmitting at a greater power level than >>>allowed >>>>>> resulting in interference to the primary user of that >>>>>> spectrum. Alternatively the attacker may indicate no >channel >>>>>> availability at a location resulting in a denial of >service >>>to >>>>>> the master device. >>>>>> >>>>>> Threat 5: Unauthorized use of channels by an uncertified device >>>>>> >>>>>> An attacker may be a master device which is not certified >>>for >>>>>> use by the relevant regulatory body. The attacker may >listen >>>to >>>>>> the communication between a valid master device and white >>>space >>>>>> database and utilize the information about available >>>channels >>>>>> in the response message by utilizing those channels. The >>>result >>>>>> of such an attack is unauthorized use of channels by a >>>master >>>>>> device which is not certified to operate. >>>>>> The master device querying the white space database may be >>>>>> operated by a law-enforcement agency and the >communications >>>>>> between the device and the database are intended to be >kept >>>>>> private. A malicious device should not be able to >eavesdrop >>>on >>>>>> such communications. >>>>>> >>>>>> Threat 6: Third party tracking of white space device location and >>>identity >>>>>> >>>>>> A white space database may require a master device to >>>provide >>>>>> its identity in addition to its location in the query >>>request. >>>>>> Such location/identity information can be gleaned by an >>>>>> eavesdropper. A master device may prefer to keep the >>>>>> location/identity information secret. Hence the protocol >>>should >>>>>> provide a means to protect the location and identity >>>>>> information of the master device and prevent tracking of >>>>>> locations associated with a white space database. If >>>>>> regulations do not require the identity of the master >device >>>to >>>>>> be provided to the white space database, the master is not >>>>>> required to include its identity in the query. >>>>>> >>>>>> >>>>>> Threat 7: Termination of device service for reasons other than >>>>>> incumbent protection >>>>>> >>>>>> A white space database may include a mechanism by which >>>service >>>>>> and channels allocated to a master device can be revoked. >A >>>>>> malicious node can send a revoke message to a master >>>>>> device. This results in denial of service to the master >>>>>> device. >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 gerald.chouinard@sympatico.ca Thu Feb 9 06:56:57 2012 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 DDDC921F86EA for ; Thu, 9 Feb 2012 06:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.35 X-Spam-Level: * X-Spam-Status: No, score=1.35 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ48Ldn8PPu3 for ; Thu, 9 Feb 2012 06:56:42 -0800 (PST) Received: from blu0-omc3-s38.blu0.hotmail.com (blu0-omc3-s38.blu0.hotmail.com [65.55.116.113]) by ietfa.amsl.com (Postfix) with ESMTP id EB7B021F86D0 for ; Thu, 9 Feb 2012 06:56:41 -0800 (PST) Received: from BLU0-SMTP13 ([65.55.116.73]) by blu0-omc3-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 06:56:41 -0800 X-Originating-IP: [174.95.124.167] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.124.167]) by BLU0-SMTP13.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 06:56:38 -0800 From: Gerald Chouinard To: "'Peter Stanforth'" References: Date: Thu, 9 Feb 2012 09:56:38 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A7_01CCE711.1F4A8720" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AczmvDRgfIbCQto0Tje1QZi/xJGc3AAfNqpg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 09 Feb 2012 14:56:38.0883 (UTC) FILETIME=[06B9D330:01CCE73B] Cc: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 09 Feb 2012 14:56:57 -0000 ------=_NextPart_000_00A7_01CCE711.1F4A8720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Peter, I agree. It depends on how the term 'opportunistic' is being defined. In my view, the qualifier 'opportunistic' relates to the use of the spectrum by devices and not to the availability of the spectrum. As you describe, the spectrum may be made available on a deterministic basis but its use by one device or another is opportunistic since it is managed by a near real-time database. For me, a deterministic use of the spectrum is an operator buying a license for a frequency band for a specific period of time such as 5 years with the possibility of extending this period. In this case, access to a database is not required. This is the current Telco model. The model that you describe seems to be an opportunistic use model where not only protection of primary and secondary incumbents would be provided but also absence of interference amongst opportunistic users is also provided, turning it into a temporary de-facto 'protected' service over a given period of time. This, to me, is still 'opportunistic'. It is just that all means are taken to make sure that the service is reliable during the given period of time. If one provides a TVWS database service and adds to it a coexistence service such as the 802.19.1 approach, you have more or less the same result. Such coexistence is however not mandatory in the TVWS and will depend on the will of the industry. Gerald _____ From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Wednesday, 08 February, 2012 18:48 To: Gerald Chouinard Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Gerald, It depends what how we define as opportunistic. We run a secondary market place for spectrum, FCC rules allow us to act as a "Spectrum Manager" in this role we can provide secondary access to devices under whatever criteria the license holder deems acceptable. We are, in everything but name, providing access to white space. In some cases this is opportunistic but in others it is very deterministic and the attraction of the spectrum is because it is deterministic. The key is the owner may not know exactly when or where they need the spectrum in the future but when they make it available it is guaranteed to be available for the timeframe published. This would not be possible without a database and yet is clearly not opportunistic. The same could be said for current US FCC TVWS rules. If we provide a channel list and a timeframe (Say for the next 4 hours) that channel list will remain available for the duration. What is missing, in the case of white space, is that we cannot deny access to someone else in the same location who asks the same question, whereas in our secondary marketplace we can. So not only is availability deterministic access is too. Peter S. From: Gerald Chouinard Date: Wed, 8 Feb 2012 17:46:44 -0500 To: Peter Stanforth Cc: "andy.sago@bt.com" , "nbravin@earthlink.net" , "paws@ietf.org" Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Peter, See my other email about 'secondary' versus 'opportunistic'. I agree with you that 'primary', 'secondary', 'deterministic and 'opportunistic' use of the spectrum has no relevance to whether the access could be free or paid (after all the primary access to the TV bands by the broadcasters is free for historical reasons while one coulddecide that some TVWS access could be paid ;-) ). Again, the reason why one needs a DB accessible over the internet is that the access to the spectrum is 'opportunistic'. If this was deterministic, the DB would not be needed as has been the case up to now. Gerald _____ From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Wednesday, 08 February, 2012 12:01 To: Gerald Chouinard;andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) There is no reason to assume that use of white space is by licensed exempt or unlicensed devices. This comes back to an earlier argument I made about what constitutes licensed and unlicensed? Again there is no reason that a license exempt or unlicensed device should get access to spectrum for "free" any more that a licensed device has to "pay" for spectrum access. The concept of a primary user, who has priority over a secondary user has no relevance to free or paid access. The rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the other, and an argument can be made for both. In a band occupied by a public safetyuser there may be no choice but to have opportunistic access but in other bands a primary user may be willing to commit to specific availability if their own use is deterministic. Peter S. From: Gerald Chouinard Date: Wed, 8 Feb 2012 10:20:52 -0500 To: "andy.sago@bt.com" , "nbravin@earthlink.net" , "paws@ietf.org" Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Andy, To resolve Nancy's concern, a new definition could be added for: TVWS White Space devices: White Space devices that operate in the TV bands. This would complement the definition of White Space devices and make it more specific. I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the White Spacedevices. The opportunistic use of the RF spectrum assumes that these devices operate while protecting existing operation in the band. There is automatically assumes the existence of primary users of the band that have priority. Such primary users would most likely be licensed to use the band and it is only the portions that happen to be unused that will be accessible to the White Space devices. The latter are unlikely to be licensed to only use the 'crumbs'. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices and then why would they need to protect these 'primary' licensed devices. This would be similar to the situation in the 2.4 GHz where a database is not needed to protect other devices. As is well understood, the databases are there to protect primary and possibly secondary licensed devices from the new opportunistic devices, not opportunistic devices among themselves. The latter case would be covered by other means such as adatabase to provide coexistence and this is, I believe, beyond the scope ofPAWS. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Wednesday, 01 February, 2012 09:58 To: nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Nancy, all Good questions. I'm not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your other questions, IMO our aim should be to provide all the necessary information in this PAWS requirements I-D to enable the PAWS protocol I-D to be developed. I don't think it's our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this very well, and regulators tend to be well coordinated or play 'follow my leader'. Thanks for pointing out the reference to licence-exempt that I had missed in 4.4 - I think the meaning would be just the same with 'in a license-exempt TVWS environment' deleted from that sentence. That would be my suggestion. Regards Andy From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: 01 February 2012 14:48 To: Sago,AJ,Andy,COD R Cc: paws@ietf.org Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6.so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain how the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could change, but, why not give the information on both for countries to understand fully what it's choices are? Thanks Andy, just some early morning thoughts.Sincerely, Nancy Begin forwarded message: From: Nancy Bravin Date: February 1, 2012 6:35:09 AM PST To: Andy Sago Cc: , , , Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Andy, All In section 4.4, license exempt is also mentioned as well. I am conflicted in a global sense when emerging countries, or countries with very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby join the existing DB companies, orwill they do their own thing leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/orWhite spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, wrote: Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV white spaces, whereas the scope of PAWS is white spaces in general. I would question not only why thelower-priority service would always be licence-exempt, but why the higher priority service would always be licenced. To avoid this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or unlicensed, or any mention of the regulatory status of the incumbent services. The Abstract derives from the Introduction and the text could be aligned to be the same in the Introduction, with "opportunistic" replacing "secondary" in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don't need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document - we are defining requirements fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum use has now got muddled with the potential for opportunistic use. This can be fixed by taking the white space and white space device definitions together. From Scott, Gerald and Jussi's comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum, under control of a white space database. A white space device can be an access point, base station, a portable device or similar. In this context, a white spacedevice is required by local regulations to query a database with its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not necessarily apply to all under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunistic use of the spectrum by white space devices in the last sentence of the definition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but is not fully occupied by that licensed use at a specific location and time. This spectrum is then assigned allowed bylocal regulations for use to beused opportunistically as licensed-exempt spectrum under control of a white space database. This way, it is understood that the database does not "assign" white space devices for them to choose from. Gerald _____ From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do these changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White Space". Kind Regards, Scott From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott , "paws@ietf.org" Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of "Protected Entity" and "White Space Devices (WSD)" where the notion of secondary use is included. The secondary status is used in the ITU-R Radio Regulations for a different purpose. In fact, it is possible that a band has already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operationwhere the two first types ofservices are not being used. The use of "lower priority opportunistic" service rather than "secondary" service would be preferable to describe white spaceallocations. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes to the draft based on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the document should accurately explain the subject with aim that a reader can understand the use cases and the subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if something is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is the 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exempt spectrum is Typically referred to as "unlicensed" spectrum. In this document the terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondarylicense-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for someprimary useand assigned for licensed use, but is not fully occupied by that primary use licensed use at a specificlocation and time. This spectrum is then assigned by locationlocal regulations for use as licensed-exempt spectrum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' Cc: "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unlicensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As an example, in the ITU-R context, an "unlicensed" band is typically a new band, say in the 300 GHz, for which no request has been made for its use. It is therefore un-allocated to a specific service so far and thus it is an "unlicensed" frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrations can thendecide under what king of regime it will 'assign' this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus "license-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicensed" in the USA. If the qualifier applies to an operation, the operation can be exempt of license by the local administration, thus a "license-exempt" operation. If, however, someone decides to start an RF transmission operation in a licensed band for which he has no license or in a license-exempt band for which he does not meet the requirements such as operating according to the type of operation for which the band is exempted from a license or he operates outside the technical limitsimposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an "unlicensed" operation. If the qualifier applies to the transmission device, such device may be a "license-exempt" device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id de-facto an "unlicensed" device since it has not passed through the normal certification process. Note that a "license-exempt" device still has to go through a certification process and meet the limits imposed by the local regulator for the "license-exempt" operation in the given frequency band whereas an "unlicensed" device may not pass the certification process since it has not been licensed to operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licensed" operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses. Gerald _____ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs to be careful with the word'unlicensed' which may mean 'illegal' operation of an RF device in many administrations. Gerald _____ From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as 'license-exempt', in most cases the term 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statement: The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I wouldsuggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald _______________________________________________ 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 ------=_NextPart_000_00A7_01CCE711.1F4A8720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter,

 

I agree.  It depends on how = the term ‘opportunistic’ is being defined. In my view, the qualifier ‘opportunistic’ = relates to the use of the spectrum by devices and not to the availability of the spectrum.  As you describe, the spectrum may be made available on a deterministic basis but its use by one device or another is = opportunistic since it is managed by a near real-time database.  For me, a = deterministic use of the spectrum is an operator buying a license for a frequency band for = a specific period of time such as 5 years with the possibility of = extending this period. In this case, access to a database is not required. This is the = current Telco model.

 

The model that you describe seems = to be an opportunistic use model where not only protection of primary and = secondary incumbents would be provided but also absence of interference amongst = opportunistic users is also provided, turning it into a temporary de-facto = ‘protected’ service over a given period of time.  This, to me, is still = ‘opportunistic’.  It is just that all means are taken to make sure that the service is = reliable during the given period of time.

 

If one provides a TVWS database = service and adds to it a coexistence service such as the 802.19.1 approach, you = have more or less the same result.  Such coexistence is however not = mandatory in the TVWS and will depend on the will of the = industry.

 

Gerald

 

From: Peter = Stanforth [mailto:peter@spectrumbridge.com]
Sent: Wednesday, 08 = February, 2012 18:48
To: Gerald Chouinard
Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Gerald,=

It depends = what how we define as opportunistic.  We run a secondary market place for = spectrum, FCC rules allow us to act as a "Spectrum Manager" in this role = we can provide secondary access to devices under whatever criteria the license = holder deems acceptable. We are, in everything but name, providing access to = white space. In some cases this is opportunistic but in others it is very deterministic and the attraction of the spectrum is because it is deterministic. The key is the owner may not know exactly when or where = they need the spectrum in the future but when they make it available it is guaranteed to be available for the timeframe published. This would not = be possible without a database and yet is clearly not opportunistic. The same could = be said for current US FCC TVWS rules. If we provide a channel list and a = timeframe (Say for the next 4 hours) that channel list will remain available for = the duration.  What is missing, in the case of white space, is that we = cannot deny access to someone else in the same location who asks the same = question, whereas in our secondary marketplace we can. So not only is availability deterministic access is too. 

Peter = S.

 <= /o:p>

From: Gerald = Chouinard <gerald.chouinard@sympatico.= ca>
Date: Wed, 8 Feb 2012 = 17:46:44 -0500
To: Peter Stanforth = <peter@spectrumbridge.com>=
Cc: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" = <nbravin@earthlink.net>, = "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /o:p>

Peter,

 

See my other email about ‘secondary’ versus = ‘opportunistic’.

 

I agree with you that ‘primary’, ‘secondary’, ‘deterministic and ‘opportunistic’ use of the spectrum has no relevance to = whether the access could be free or paid (after all the primary access to the TV = bands by the broadcasters is free for historical reasons while one coulddecide that = some TVWS access could be paid ;-)  ).

 

Again, the reason why one needs a = DB accessible over the internet is that the access to the spectrum is ‘opportunistic’.  If this was deterministic, the DB = would not be needed as has been the case up to = now.

 

Gerald

 

From: Peter Stanforth [mailto:peter@spectrumbridge.com<= /a>]
Sent: Wednesday, 08 = February, 2012 12:01
To: Gerald Chouinard;andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

There is no = reason to assume that use of white space is by licensed exempt or unlicensed = devices. This comes back to an earlier argument I made about what constitutes = licensed and unlicensed?

Again there = is no reason that a license exempt or unlicensed device should get access to = spectrum for "free" any more that a licensed device has to = "pay" for spectrum access.

The concept = of a primary user, who has priority over a secondary user has no relevance to = free or paid access. 

The = rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a = secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the = other, and an argument can be made for both. In a band occupied by a public = safetyuser there may be no choice but to have opportunistic access but in other = bands a primary user may be willing to commit to specific availability if their = own use is deterministic. 

 =

Peter = S.

 =

From: Gerald = Chouinard <gerald.chouinard@sympatico.= ca>
Date: Wed, 8 Feb 2012 = 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" = <nbravin@earthlink.net>, = "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 =

Andy,

 

To resolve Nancy’s concern, a new definition could be added = for:

 

TVWS White Space devices: White = Space devices that operate in the TV bands.

 

This would complement the = definition of White Space devices and make it more = specific.

 

I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the = White Spacedevices. The opportunistic use of the RF spectrum assumes that = these devices operate while protecting existing operation in the band.  = There is automatically assumes the existence of primary users of the band that = have priority. Such primary users would most likely be licensed to use the = band and it is only the portions that happen to be unused that will be accessible = to the White Space devices.  The latter are unlikely to be licensed to = only use the ‘crumbs’. Removing the concept of license-exempt could = put these new devices at the same level of priority as the primary devices = and then why would they need to protect these ‘primary’ licensed = devices.

 

This would be similar to the = situation in the 2.4 GHz where a database is not needed to protect other devices. As = is well understood, the databases are there to protect primary and possibly = secondary licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other means such = as adatabase to provide coexistence and this is, I believe, beyond the = scope ofPAWS.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 = February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 =

Nancy= , all

 =

Good = questions. I’m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are = studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary = information in this PAWS requirements I-D to enable the PAWS protocol I-D to be = developed. I don’t think it’s our job to explain different regulatory = regimes or applications (beyond use cases) in this document, ITU and others do this = very well, and regulators tend to be well coordinated or play ‘follow = my leader’.

 =

Thanks for = pointing out the reference to licence-exempt that I had missed in 4.4 -  I = think the meaning would be just the same with ‘in a license-exempt TVWS environment’ deleted from that sentence. That would be my = suggestion.

 =

Regards

 =

Andy

 =

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February 2012 = 14:48
To: Sago,AJ,Andy,COD = R
Cc: paws@ietf.org
Subject: Fwd: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 =

Hi Andy, also, = throughout the document TVWS are mentioned in 4.1,4.5, 4.6…so if you propose to = remove any reference to TVWS it will = affect

the document as a = whole, and information that seems necessary to explain how the DB and protocol = interacts with TVWS devices = and

the methods of = doing so. One can envision that current rules could change, but, why not give the = information on both for countries to understand = fully

what it's choices = are? 

 =

Thanks Andy, just = some early morning thoughts…Sincerely, Nancy

 =

Begin forwarded = message:

 =

From: Nancy Bravin <nbravin@earthlink.net>

Date: February 1, 2012 6:35:09 AM PST

To: Andy Sago <andy.sago@bt.com>

Subject: Re: [paws] Use cases and requirements I-D: = sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 =

Hi Andy, = All

 =

In section 4.4, = license exempt is also mentioned as = well. 

I am conflicted in = a global sense when emerging countries, or countries with very different types of = gov't want to implement

the protocol, will = they have enough information to do so? and thereby join the existing DB companies, = orwill they do their own = thing

leaving holes in = what one hopes will be an interoperable global protocol that deals with TVWS, and/orWhite spaces in = general?

 =

Thanks, just a = thought.

 =

SIncerely, = Nancy

 =

 =

On Feb 1, 2012, at = 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

 =

Scott, = All

 

I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only = why thelower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th = Jan I proposed (= http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with “opportunistic” replacing “secondary” in later sentences in the Introduction. I have = checked and there are no further references to licensing in the document, so we don’t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document – we are defining requirements fora protocol. Keep it simple.

 

That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  From Scott, = Gerald and Jussi’s comments perhaps we could agree on:

 

White Space = (WS)

 <= /font>

Radio = spectrum which is not fully occupied at a specific location and = time.

 <= /font>

White Space = device

 <= /font>

A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white spacedevice is required by local regulations to query a database with = its location to obtain information about available = spectrum.

 

Regards

 

Andy<= /font>

 

From: = paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: gerald.chouinard@sympatico.= ca; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 =

That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?

 

Kind = regards,

Jussi=

 

From: = paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of ext = Gerald Chouinard
Sent: 31 January 2012 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 =

Scott,

 

Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of “white space” as = follows:

 

White = Space

 <= /font>

Radio = spectrum which has been allocated and assigned for licensed use, but is not fully = occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> bylocal regulations <delete>for use<delete> <insert>to = beused opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>

 

This way, it is understood that the database does not “assign” white space devices for them to = choose from.

 

Gerald

From: = scott.probasco@nokia.com [mailto:scott.proba= sco@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

Hi = Gerald,

 <= /font>

Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that = we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?

 <= /font>

I also = corrected "location" to "local" in previous text proposed for "White Space".

 <= /font>

Kind = Regards,

Scott

 <= /font>

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>= , "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

= Scott,

= Great proposal.  However, I am still a bit nervous about the definitions = of “Protected Entity” and “White Space Devices = (WSD)” where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In = fact, it is possible that a band has already primary and secondary services allotted = to it and that the White Space operation is a tertiary opportunistic = operationwhere the two first types ofservices are not being used.  The use of “lower priority opportunistic” service rather than “secondary” service would be preferable to describe white spaceallocations.

=  

= Gerald

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
= Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work)

 

Hi,

 

I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the = draft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.

 

I hope this captures the key points of the discussion. Please do reply if = something is still missing.

 

Kind Regards,

Scott

 

 

2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio = technologies,

      the database is an entity which contains current = information about

      available spectrum at any given location and other types = of

      information.

 

   Device ID

 

      A unique number for each master device and slave device = that

      identifies the manufacturer, model number and serial = number.

 

<Insert>

   Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given = service area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, = company merger &

      acquisition,  first-come / first-served or by = government allocation

      (e.g., public service).

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the USA, license-exempt spectrum is

      Typically referred to as "unlicensed" spectrum. = In this document the terms

      license-exempt and unlicensed are used = interchangeably.

 

</Insert>

 

   Location Based Service

 

      An application or device which provides data, information = or

      service to a user based on their = location.

 

  Master Device

 

      A device which queries the WS Database to find out the = available

      operating channels.

 

   Protected Entity

 

      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space

      devices) for its use</Delete> in a given area and = time.

 

   Protected Contour

 

      The exclusion area for a Protected Entity, held in the = database

      and expressed as a polygon with geospatial points as the = vertices.

 

   Slave Device

 

      A device which uses the spectrum made available by a = master

      device.

 

   TV White Space

 

      TV white space refers specifically to radio spectrum which = has

      been allocated for TV broadcast, but is not occupied by a = TV

      broadcast, or other licensed user (such as a wireless = microphone),

      at a specific location and time.

 

   White Space

 

      Radio spectrum which has been allocated <Delete>for someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>

 

   White Space Device (WSD)

 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</In= sert> user of some part of white space

      spectrum.  A white space device can be an access = point, base

      station, a portable device or similar.  In this = context, a white

      space device is required to query a database with its = location to

      obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" = <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

= Nancy,

=  

= This is not that simple.  In fact, the qualifiers = “license-exempt” and “unlicensed” can apply to more than one = thing.

=  

= If the qualifier applies to a frequency band, different options exist. As an example, in = the ITU-R context, an “unlicensed” band is typically a new band, = say in the 300 GHz, for which no request has been made for its use.  It is therefore un-allocated to a specific service so far and thus it is an “unlicensed” frequency band. Once the ITU-R allocates this = band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will ‘assign’ = this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus “license-exempt”such as in the 2.4 GHz ISM band. This is = also called “unlicensed” in the USA.

=  

= If the qualifier applies to an operation, the operation can be exempt of = license by the local administration, thus a “license-exempt” operation. = If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limitsimposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an “unlicensed” operation.

=  

= If the qualifier applies to the transmission device, such device may be a “license-exempt” device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an “unlicensed” device since it has not passed = through the normal certification process.

=  

= Note that a “license-exempt” device still has to go through a certification process and meet the limits imposed by the local regulator = for the “license-exempt” operation in the given frequency band = whereas an “unlicensed” device may not pass the certification = process since it has not been licensed to operation in the = country.

=  

= This is why the qualifier “unlicensed” has to be treated with care = and the footnote will need to be crafted very carefully.

=  

= With respect to your second point, if an administration only allows “licensed” operation, the situation will be much simpler to = manage since specific conditions will be attached to these = licenses.

=  

= Gerald

=  

From: Nancy Bravin [mailto:nbravin@earthlink.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Gabor and = Gerald, 

Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use = to indicate that "according to each countries regulatory = requirements"  

How to get = around the fact that some Countries are or will be "licensed only" by = their gov'ts?  Thanks

Nancy

On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:





= Gabor,

=  

= I agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word‘unlicensed’ which may mean ‘illegal’ operation of an RF device in many = administrations.

=  

= Gerald

=  

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as ‘license-exempt’, in most = cases the term ‘unlicensed-band’ is used.

 

Therefore, may I suggest that the draft will include the following = statement:

 

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.

 

-      = ;    Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

All,

 

= Here is my understanding of the terms:

=  

= Licensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).

=  

= Lightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through = auction over large service areas.

=  

= License-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

=  

= Unlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, this term is used to mean “license-exempt," see = above.

=  

= To my knowledge, the term “unlicensed” is used only in the USA to describe a legal operation = because the term “license-exempt” has been used for another specific purpose.

=  

= Since the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I wouldsuggest the use of ‘licensed’ and = ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is = used in the USA instead of the usual ‘license-exempt’.

=  

= Gerald

_______________________________________________
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

 =

 =

------=_NextPart_000_00A7_01CCE711.1F4A8720-- From gerald.chouinard@sympatico.ca Thu Feb 9 07:05:48 2012 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 19FE221F86F3 for ; Thu, 9 Feb 2012 07:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.169 X-Spam-Level: X-Spam-Status: No, score=0.169 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUkQGcIQGuZl for ; Thu, 9 Feb 2012 07:05:46 -0800 (PST) Received: from blu0-omc3-s25.blu0.hotmail.com (blu0-omc3-s25.blu0.hotmail.com [65.55.116.100]) by ietfa.amsl.com (Postfix) with ESMTP id B973121F86DA for ; Thu, 9 Feb 2012 07:05:44 -0800 (PST) Received: from BLU0-SMTP17 ([65.55.116.74]) by blu0-omc3-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 07:05:43 -0800 X-Originating-IP: [174.95.124.167] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.124.167]) by BLU0-SMTP17.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 07:05:42 -0800 From: Gerald Chouinard To: "'Rex Buddenberg'" References: <1328740910.9169.2112.camel@localhost.localdomain> Date: Thu, 9 Feb 2012 10:05:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Aczmswcgpsu6zhTtRHOHSs4KnN96iAAiBTmw In-Reply-To: <1328740910.9169.2112.camel@localhost.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 09 Feb 2012 15:05:42.0928 (UTC) FILETIME=[4B008100:01CCE73C] Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) 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, 09 Feb 2012 15:05:49 -0000 Rex, See my comments below. Gerald -----Original Message----- From: Rex Buddenberg [mailto:budden@nps.navy.mil] Sent: Wednesday, 08 February, 2012 17:42 To: Gerald Chouinard Cc: scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) namecalling nits below.... On Wed, 2012-02-08 at 17:16 -0500, Gerald Chouinard wrote: > Scott, > > I agree with your proposed changes except for items 8 and 11. > > In the case of the Wide-area or Rural internet broadband access, the > geolocation of each slave device needs to be provided to the base station so > that it can query the DB for the channel availability at each slave > location. These slave devices could be located as far as 30 km, thus not > sharing the same location as the base station as far as querying for the > available channels. IEEE 802 uses the terms _base station_ (BS) and _subscriber station_ (SS) (not slave). [Gerald] 802.22 uses base station (BS) and customer premise equipment (CPE) > > The network topology here is a point-to-multipoint star model (i.e., a > slave, once it knows its available channels, is not supposed to go on its > own and operate on any of these channels, it will continue to operate on the > same channel as that of the base station since it is part of this star > network and needs to be in contact with the base station). In a pure IEEE 802.16 notion, this is entirely correct. > If a slave device > were to operate on a different channel in a peer-to-peer fashion, it would > also have to stay in touch with the master/BS and thus have double modem > construction to operate on both channels at the same time. Such peer-to-peer > topology is not part of this use case. But it is part of several standards and associated technologies. IEEE 802.16j (now that it's ratified, correctly termed IEEE 802.16-2009) comes to mind. [Gerald] In such case, a new use case for peer-to-peer and mesh networking for Wide-area and rural broadband access would need to be developed. This use case was developed for point-to-multipoint topology. > > In this model, the slave device does not need to know the list of available > channels, it only needs to know its operating channel which has to be the > same as that of the base station and a few backup channels so that, if the > current operating channels is to be freed by the base station, upon a > trigger from the base station to move out of the channel, the slave device > knows where to fall back to continue operating with the base station. This > way, the short time to free the channel to avoid interference to the > incumbent can be met while the communication with the base station can > continue in a transparent way to the terminal user. The way out of this circle is to again ape IEEE 802.16. The device in the middle is known as RS, short for relay station. Further there's a lot of 'mesh' talk where all stations would be peers. In both cases, the RS or the peers would have to assume the responsibility of a BS. [Gerald] Again, a new use case would need to be developed to cover this case. As a result, the model for the PAWS would still be the BS acting as the master and its associated terminals being the slaves. > > The base station, however, needs to query the DB for each and every of its > slave devices so that it can find the cross-section of all the available > channels returned by the DB for all its slave devices which will define the > channels that can be used by all the slave devices (i.e., available to the > BS and all its slave devices) and this will constitute the list of the > operating channel and the backup channels that the BS needs to signal to its > slave devices. This is the common list of channels that needs to be sent to > the slave devices, not the list of available channels for each device coming > from the DB. > > As a consequence, The text in item 8 should stay as is except for changing > "BS" for "Master/BS" if it is needed for consistency. > > With respect to item 11, here is what I would suggest: > > 11. The slave or user device must transmit its new geographic location > every time it changes so that the repeated process described under item 10 > for the master/BS can rely on the most up-to-date geolocation of the slave > or user device. > > One could also argue that this function of updating the geolocation > information of the slave at the master/BS is nor related to the protocol to > be developed and is therefore beyond the scope of PAWS. > > Respectfully, > > Gerald > > > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > scott.probasco@nokia.com > Sent: Wednesday, 08 February, 2012 12:55 > To: paws@ietf.org > Subject: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet > broadbandaccess) > > Hello All, > > As editors of the problem statement, use cases & requirements draft we are > attempting to prepare a completed draft which could be ready for working > group last call before IETF83. In the coming days we will post the > sections of the draft to the mailing list. Our request is that you review > these sections and reply to the email with any comments. > > Below is the text for section on the Wide-Area or Rural use case (new > section numbering is NOT shown, all use cases will be moved to section 4.2 > Use cases in the next version). This text has been marked up from > version-02 as uploaded January 26, 2012 as follows: > > * include applicable comments from Hotspot use case > > > Our goal is that any discussion on this text will conclude by February 15. > To be clear, approval of the document will go through the normal process > of last calls etc.. We are simply asking for your assistance in preparing > a complete & accurate document that could progress the work. So please > review the text and send your comments either directly to the editor or to > the mailing list. > > Kind Regards, > Raj & Scott > > > > 4.4. Wide-Area or Rural internet broadband access > > In this use case, internet broadband access is provided as a Wide- > Area Network (WAN) or Wireless Regional Area Network (WRAN). A > typical deployment scenario is a wide area or rural area, where > internet broadband access is provided to local businesses and > residents from a master (i.e. BS) connected to the internet. This > deployment scenario is typically characterized by one or more > Fixed master(s)/BS(s), cells with relatively large radius (tens of > kilometers, up to 100 km), and a number of available radio > channels. Some of the masters/BSs may be deployed and operated by > a single entity, i.e. there can be centralized coordination > between these masters/BSs, whereas other masters/BSs may be > deployed and operated by operators competing for the radio > channels in a license-exempt TVWS environment where decentralized > coordination using the air-interface would be required. The BS in > this scenario use a TDD radio technology and transmit at or below > a transmit power limit established by the local regulator. Each > base station has a connection to the internet and may > provides > internet connectivity to multiple slave/end-user devices. End > user terminals or devices may be fixed or portable. > > The figure below shows an example deployment of this scenario. > > ------- > |Slave|\ \|/ ---------- > |Dev 1| (TDD AirIF) | |Database| > ------- \ | .---. /---------- > o \ |-|---------| ( ) / > o | Master | / \ > o / | (BS) |========( Internet ) > o / |-----------| \ / > ------- (TDD AirIF) ( ) > |Slave| / (----) > |Dev n| > ------- > > > Figure 4: Rural internet broadband access using TV white space > spectrum > > Once the master/BS has been professionally installed and configured, > a simplified power up and operation scenario utilizing TV White Space > to provide rural internet broadband access consists of the following > steps: > > 1. The master/BS powers up; however its WS radio and all other WS > capable devices will power up in idle/listen only mode (No active > transmissions on the WS frequency band) > > 2. The master/BS has internet connectivity , determines its > location (either from location determination capability or from saved > value that was set during installation), and establishes a > connection to a trusted white space database (see use > case "TVWS > database discovery" above). > > 3. The master/BS registers its geolocation, address, contact > information, etc. associated with the owner/operator of the > master/BS with the trusted database service (if > not currently > registered, see Section 4.2reference is to > registration, will be updated in next version). Meanwhile the > DB administrator may > be required to store and forward the registration information to > the regulatory authority. If a trusted white space database > administrator is not discovered, further operation of the WRAN > may be allowed according to local regulator policy (in this case > operation of the WRAN is outside the scope of the PAWS protocol). > > 4. Following the successful registration process, the > master/BS will send a > query to the trusted database requesting a list of available WS > channels based upon its geolocation. The complete set of > parameters to be provided from the master to the database is specified > by the local regulator. Parameters may include WSD location, accuracy of > of that location, device antenna height, device identifier of a slave > device requesting channel information. > > > 5. If the master/BS has been previously authenticated, the database > responds with a list of available white space channels that may > be used and optionally a maximum transmit power (EIRP) for each > channel and a duration of time the channel may be > used or a notification of any additional requirement for > sensing. > > 6. Once the master/BS authenticates the WS channel list response > message from the database, the master/BS selects an available WS > channel(s) from the list. The operator may disallow some > channels from the list to suit local needs if required. > > 7. The slave or user device scans the TV bands to locate a WRAN > transmission, and associates with the master/BS.insert > new step > > 8. The slave/user > device provides its geolocation to the BS which, in > turn, queries > the databasemaster for a list of > channels available at the slaves' > Geolocation providing to the master the slave's Device ID > and optionally its geolocation.. > > 9. Once this list of available channels is received from the > database by the master, the latter will decide, based on the list > of available channels for all its other associated slaves whether > it should continue operation on its current channel or change > channel to accommodate the new slave in case this channel is not > available at its location. The master will notify all its > associated slaves/user devices of the new channel to move to if > operation needs to change channel. If the channel that the user > terminal is currently using is not included in the list of > locally available channels, the master will drop its association > with the slave/user device so that it ceases all operation on its > current channel and indicate the new operating channel before > dropping the link if a change has been decided. The slave/user > device may move to the indicated new channel if so indicated or > scan for another WRAN transmission on a different channel. > > > 10. The master/BS must periodically repeat the process to request a > channel list from the database, steps 4 through 6 above. The frequency > to repeat the process is determined by the local regulator. If the > response from the database indicates a channel being used by the > master/BS is not available, the master/BS must stop transmitting on that > channel immediately. > > 11. The slave or user device must periodically repeat the process to > request a channel list from the master/BS, steps 8 and 9 above. The > frequency to repeat the process is determined by the local regulator. If > the response from the master/BS indicates that a channel being used by > the slave or user device is not available, the slave or user device must > stop transmitting on that channel immediately. > > > > > _______________________________________________ > 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 gerald.chouinard@sympatico.ca Thu Feb 9 07:09:35 2012 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 501C221F86DA for ; Thu, 9 Feb 2012 07:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.084 X-Spam-Level: * X-Spam-Status: No, score=1.084 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_50=0.001, J_CHICKENPOX_21=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vKgey1JA-uT for ; Thu, 9 Feb 2012 07:09:34 -0800 (PST) Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by ietfa.amsl.com (Postfix) with ESMTP id B1CE421F86F8 for ; Thu, 9 Feb 2012 07:09:34 -0800 (PST) Received: from BLU0-SMTP30 ([65.55.116.74]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 07:09:34 -0800 X-Originating-IP: [174.95.124.167] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.124.167]) by BLU0-SMTP30.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 07:09:33 -0800 From: Gerald Chouinard To: "'Paul Lambert'" , "'Rex Buddenberg'" References: <1328740910.9169.2112.camel@localhost.localdomain> <7BAC95F5A7E67643AAFB2C31BEE662D01579A4FCB8@SC-VEXCH2.marvell.com> Date: Thu, 9 Feb 2012 10:09:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AczmsvUfzFLaHD2fRgOMxKTSF3JSfwAHzCXAABqa27A= In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4FCB8@SC-VEXCH2.marvell.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 09 Feb 2012 15:09:33.0974 (UTC) FILETIME=[D4B75360:01CCE73C] Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) 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, 09 Feb 2012 15:09:35 -0000 Paul, 802.11af is designed to address other use cases that the Wide-area or rural broadband access case. Gerald -----Original Message----- From: Paul Lambert [mailto:paul@marvell.com] Sent: Wednesday, 08 February, 2012 21:28 To: Rex Buddenberg; Gerald Chouinard Cc: paws@ietf.org Subject: RE: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) >The way out of this circle is to again ape IEEE 802.16. The device in >the middle is known as RS, short for relay station. Why copy terms from a dying standard ... versus using 802.11af terminology? Paul From nbravin@earthlink.net Thu Feb 9 07:43:27 2012 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 A7F6F21F85EE for ; Thu, 9 Feb 2012 07:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.64 X-Spam-Level: X-Spam-Status: No, score=0.64 tagged_above=-999 required=5 tests=[AWL=-2.783, BAYES_20=-0.74, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkzpcOOdY2Ss for ; Thu, 9 Feb 2012 07:43:22 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2CF21F85C5 for ; Thu, 9 Feb 2012 07:43:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XS+gq2Sd2j/4QyepOWXb4N5vx3f2bjNk0oSAjtNawzgtOROTb9DXkhOpctHSk+0x; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RvW9V-0008Ld-Aw; Thu, 09 Feb 2012 10:43:20 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1-455161390 From: Nancy Bravin In-Reply-To: Date: Thu, 9 Feb 2012 07:43:15 -0800 Message-Id: References: To: Gerald Chouinard X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad8667548fb685cec19a34050e525a7e8943350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 09 Feb 2012 15:43:27 -0000 --Apple-Mail-1-455161390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi All,=20 In this discussion are you not discussing business models and use cases = such as Jon Stine suggested? That would indicate other models that would be useful in a global sense, and not necessarily a Telco model. = Myself, I don't see many Telco models that feel they have enough = spectrum. In one example was the mention of the DOD or other spectrum owners who = would allow WS use /sharing, as long as they could, when needed, use the spectrum as planned which is not often. Many times mostly unused = spectrum merely says "hi" I am here, but its use is rare. I think it is = a more global forward looking approach, and managed by the DB's under reg's of what ever country can use this = model. It makes a good business model to lay for the future of white = space, as opposed to allowing models not associated with WSDB's at all. Whether you want = it in this part of the protocol, is another question, but it does seem = to belong and further may allow for more involvement globally from a business sense, using the = DB's./ My 2 cents for what it's worth. SIncerely, Nancy On Feb 9, 2012, at 6:56 AM, Gerald Chouinard wrote: > Peter, > =20 > I agree. It depends on how the term =91opportunistic=92 is being = defined. In my view, the qualifier =91opportunistic=92 relates to the = use of the spectrum by devices and not to the availability of the = spectrum. As you describe, the spectrum may be made available on a = deterministic basis but its use by one device or another is = opportunistic since it is managed by a near real-time database. For me, = a deterministic use of the spectrum is an operator buying a license for = a frequency band for a specific period of time such as 5 years with the = possibility of extending this period. In this case, access to a database = is not required. This is the current Telco model. > =20 > The model that you describe seems to be an opportunistic use model = where not only protection of primary and secondary incumbents would be = provided but also absence of interference amongst opportunistic users is = also provided, turning it into a temporary de-facto =91protected=92 = service over a given period of time. This, to me, is still = =91opportunistic=92. It is just that all means are taken to make sure = that the service is reliable during the given period of time. > =20 > If one provides a TVWS database service and adds to it a coexistence = service such as the 802.19.1 approach, you have more or less the same = result. Such coexistence is however not mandatory in the TVWS and will = depend on the will of the industry. > =20 > Gerald > =20 > From: Peter Stanforth [mailto:peter@spectrumbridge.com]=20 > Sent: Wednesday, 08 February, 2012 18:48 > To: Gerald Chouinard > Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Gerald, > It depends what how we define as opportunistic. We run a secondary = market place for spectrum, FCC rules allow us to act as a "Spectrum = Manager" in this role we can provide secondary access to devices under = whatever criteria the license holder deems acceptable. We are, in = everything but name, providing access to white space. In some cases this = is opportunistic but in others it is very deterministic and the = attraction of the spectrum is because it is deterministic. The key is = the owner may not know exactly when or where they need the spectrum in = the future but when they make it available it is guaranteed to be = available for the timeframe published. This would not be possible = without a database and yet is clearly not opportunistic. The same could = be said for current US FCC TVWS rules. If we provide a channel list and = a timeframe (Say for the next 4 hours) that channel list will remain = available for the duration. What is missing, in the case of white = space, is that we cannot deny access to someone else in the same = location who asks the same question, whereas in our secondary = marketplace we can. So not only is availability deterministic access is = too.=20 > Peter S. > =20 > From: Gerald Chouinard > Date: Wed, 8 Feb 2012 17:46:44 -0500 > To: Peter Stanforth > Cc: "andy.sago@bt.com" , "nbravin@earthlink.net" = , "paws@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Peter, > =20 > See my other email about =91secondary=92 versus =91opportunistic=92. > =20 > I agree with you that =91primary=92, =91secondary=92, =91deterministic = and =91opportunistic=92 use of the spectrum has no relevance to whether = the access could be free or paid (after all the primary access to the TV = bands by the broadcasters is free for historical reasons while one = coulddecide that some TVWS access could be paid ;-) ). > =20 > Again, the reason why one needs a DB accessible over the internet is = that the access to the spectrum is =91opportunistic=92. If this was = deterministic, the DB would not be needed as has been the case up to = now. > =20 > Gerald > =20 > From: Peter Stanforth [mailto:peter@spectrumbridge.com]=20 > Sent: Wednesday, 08 February, 2012 12:01 > To: Gerald Chouinard;andy.sago@bt.com; nbravin@earthlink.net; = paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > There is no reason to assume that use of white space is by licensed = exempt or unlicensed devices. This comes back to an earlier argument I = made about what constitutes licensed and unlicensed? > Again there is no reason that a license exempt or unlicensed device = should get access to spectrum for "free" any more that a licensed device = has to "pay" for spectrum access. > The concept of a primary user, who has priority over a secondary user = has no relevance to free or paid access.=20 > The rationale for white space is that the spectrum is shared and that = someone has primary, preferred or priority access and the database = ensures that those rights/requirements are met by anyone who uses the = spectrum on a secondary basis. I would go further and say that the = secondary access could be deterministic or opportunistic. There is no = reason to require one or the other, and an argument can be made for = both. In a band occupied by a public safetyuser there may be no choice = but to have opportunistic access but in other bands a primary user may = be willing to commit to specific availability if their own use is = deterministic.=20 > =20 > Peter S. > =20 > From: Gerald Chouinard > Date: Wed, 8 Feb 2012 10:20:52 -0500 > To: "andy.sago@bt.com" , "nbravin@earthlink.net" = , "paws@ietf.org" > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Andy, > =20 > To resolve Nancy=92s concern, a new definition could be added for: > =20 > TVWS White Space devices: White Space devices that operate in the TV = bands. > =20 > This would complement the definition of White Space devices and make = it more specific. > =20 > I am having second thoughts about yoursuggestion to remove the concept = of classes of devices from the White Spacedevices. The opportunistic use = of the RF spectrum assumes that these devices operate while protecting = existing operation in the band. There is automatically assumes the = existence of primary users of the band that have priority. Such primary = users would most likely be licensed to use the band and it is only the = portions that happen to be unused that will be accessible to the White = Space devices. The latter are unlikely to be licensed to only use the = =91crumbs=92. Removing the concept of license-exempt could put these new = devices at the same level of priority as the primary devices and then = why would they need to protect these =91primary=92 licensed devices. > =20 > This would be similar to the situation in the 2.4 GHz where a database = is not needed to protect other devices. As is well understood, the = databases are there to protect primary and possibly secondary licensed = devices from the new opportunistic devices, not opportunistic devices = among themselves. The latter case would be covered by other means such = as adatabase to provide coexistence and this is, I believe, beyond the = scope ofPAWS. > =20 > Gerald > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of andy.sago@bt.com > Sent: Wednesday, 01 February, 2012 09:58 > To: nbravin@earthlink.net; paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Nancy, all > =20 > Good questions. I=92m not proposing to remove references to TVWS, they = are entirely appropriate within the use cases since it is the TV bands = we are studying as first candidate for opportunistic access, but the = charter says we are addressing all white space in the resulting = protocol. To answer your other questions, IMO our aim should be to = provide all the necessary information in this PAWS requirements I-D to = enable the PAWS protocol I-D to be developed. I don=92t think it=92s our = job to explain different regulatory regimes or applications (beyond use = cases) in this document, ITU and others do this very well, and = regulators tend to be well coordinated or play =91follow my leader=92. > =20 > Thanks for pointing out the reference to licence-exempt that I had = missed in 4.4 - I think the meaning would be just the same with =91in a = license-exempt TVWS environment=92 deleted from that sentence. That = would be my suggestion. > =20 > Regards > =20 > Andy > =20 > From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 > Sent: 01 February 2012 14:48 > To: Sago,AJ,Andy,COD R > Cc: paws@ietf.org > Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, = 4.6=85so if you propose to remove any reference to TVWS it will affect > the document as a whole, and information that seems necessary to = explain how the DB and protocol interacts with TVWS devices and > the methods of doing so. One can envision that current rules could = change, but, why not give the information on both for countries to = understand fully > what it's choices are?=20 > =20 > Thanks Andy, just some early morning thoughts=85Sincerely, Nancy > =20 > Begin forwarded message: > =20 >=20 > From: Nancy Bravin > Date: February 1, 2012 6:35:09 AM PST > To: Andy Sago > Cc: , , = , > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi Andy, All > =20 > In section 4.4, license exempt is also mentioned as well.=20 > I am conflicted in a global sense when emerging countries, or = countries with very different types of gov't want to implement > the protocol, will they have enough information to do so? and thereby = join the existing DB companies, orwill they do their own thing > leaving holes in what one hopes will be an interoperable global = protocol that deals with TVWS, and/orWhite spaces in general? > =20 > Thanks, just a thought. > =20 > SIncerely, Nancy > =20 > =20 > On Feb 1, 2012, at 2:34 AM, = wrote: > =20 >=20 > Scott, All > =20 > I agree with Jussi that we have now narrowed the definition to apply = to TV white spaces, whereas the scope of PAWS is white spaces in = general. I would question not only why thelower-priority service would = always be licence-exempt, but why the higher priority service would = always be licenced. To avoid this issue on 27th Jan I proposed = (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a = revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent = services. The Abstract derives from the Introduction and the text could = be aligned to be the same in the Introduction, with =93opportunistic=94 = replacing =93secondary=94 in later sentences in the Introduction. I have = checked and there are no further references to licensing in the = document, so we don=92t need the definitions of licence exempt, light = licensing or unlicensed. This is not a regulatory document =96 we are = defining requirements fora protocol. Keep it simple. > =20 > That just leaves the definition of white space, where the existing = spectrum use has now got muddled with the potential for opportunistic = use. This can be fixed by taking the white space and white space device = definitions together. =46rom Scott, Gerald and Jussi=92s comments = perhaps we could agree on: > =20 > White Space (WS) > =20 > Radio spectrum which is not fully occupied at a specific location and = time. > =20 > White Space device > =20 > A device which opportunistically uses some part of the white space = spectrum, under control of a white space database. A white space device = can be an access point, base station, a portable device or similar. In = this context, a white spacedevice is required by local regulations to = query a database with its location to obtain information about available = spectrum. > =20 > Regards > =20 > Andy > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of jussi.kahtava@nokia.com > Sent: 01 February 2012 07:31 > To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > That statement is valid for TV White Spaces on UHF frequencies but = does not necessarily apply to all under-utilised radio spectrum. Why = would the lower priority service by default be licence-exempt? > =20 > Kind regards, > Jussi > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard > Sent: 31 January 2012 22:33 > To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Scott, > =20 > Very good improvements. I would suggest to insert the notion of = opportunistic use of the spectrum by white space devices in the last = sentence of the definition of =93white space=94 as follows: > =20 > White Space > =20 > Radio spectrum which has been allocated and assigned for licensed use, = but is not fully occupied by that licensed use at a specific location = and time. This spectrum is then assigned = allowed bylocal regulations for use = to beused opportunistically as licensed-exempt spectrum = under control of a white space database. > =20 > This way, it is understood that the database does not =93assign=94 = white space devices for them to choose from. > =20 > Gerald > From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 > Sent: Tuesday, 31 January, 2012 15:12 > To: gerald.chouinard@sympatico.ca; paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi Gerald, > =20 > Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower = priority opportunistic service" could indeed by used, but I am guessing = that we would need some explanation of what that means. Since we now = have descriptions of licensed spectrum and license-exempt spectrum, I = used these words. Do these changes remove your concerns? > =20 > I also corrected "location" to "local" in previous text proposed for = "White Space". > =20 > Kind Regards, > Scott > =20 > From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 > To: Scott , "paws@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Scott, > Great proposal. However, I am still a bit nervous about the = definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 = where the notion of secondary use is included. The secondary status is = used in the ITU-R Radio Regulations for a different purpose. In fact, = it is possible that a band has already primary and secondary services = allotted to it and that the White Space operation is a tertiary = opportunistic operationwhere the two first types ofservices are not = being used. The use of =93lower priority opportunistic=94 service = rather than =93secondary=94 service would be preferable to describe = white spaceallocations. > =20 > Gerald > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com > Sent: Tuesday, 31 January, 2012 13:56 > To: paws@ietf.org > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) > =20 > Hi, > =20 > I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes = to the draft based on the email discussion. > =20 > Below is a copy of chapter 2.2. Terminology. I have inserted new terms = for 'licensed' and 'license-exempt' and made changes to the term 'white = space'. I have tried to work from the perspective that the document = should accurately explain the subject with aim that a reader can = understand the use cases and the subsequent requirements. No doubt we = could include much more text on this topic of spectrum allocation, = assignment, licensing and usage. > =20 > I hope this captures the key points of the discussion. Please do reply = if something is still missing. > =20 > Kind Regards, > Scott > =20 > =20 > 2.2. Terminology > =20 > Database > =20 > In the context of white space and cognitive radio technologies, > the database is an entity which contains current information = about > available spectrum at any given location and other types of > information. > =20 > Device ID > =20 > A unique number for each master device and slave device that > identifies the manufacturer, model number and serial number. > =20 > > Licensed Spectrum > =20 > Spectrum that is acquired by an operator over a given service = area > for a given time period. This is usually done through = auctions,award > (beauty contest), acquisition from secondary market, company = merger & > acquisition, first-come / first-served or by government = allocation > (e.g., public service). > =20 > License-exempt Spectrum > =20 > Spectrum that is not assigned to any specific user. One example = is the 2.4 Ghz ISM band, where RF devices > operate without a formal licensing process. In the USA, = license-exempt spectrum is > Typically referred to as "unlicensed" spectrum. In this document = the terms > license-exempt and unlicensed are used interchangeably. > =20 > > =20 > Location Based Service > =20 > An application or device which provides data, information or > service to a user based on their location. > =20 > Master Device > =20 > A device which queries the WS Database to find out the available > operating channels. > =20 > Protected Entity > =20 > A licensed user of spectrum, when the licensed spectrum = has been assigned as white space spectrum. A = primaryA licensed user of white space spectrum = which is afforded > protection against interference by = secondarylicense-exempt white space = users (white space > devices) for its use in a given area and time. > =20 > Protected Contour > =20 > The exclusion area for a Protected Entity, held in the database > and expressed as a polygon with geospatial points as the = vertices. > =20 > Slave Device > =20 > A device which uses the spectrum made available by a master > device. > =20 > TV White Space > =20 > TV white space refers specifically to radio spectrum which has > been allocated for TV broadcast, but is not occupied by a TV > broadcast, or other licensed user (such as a wireless = microphone), > at a specific location and time. > =20 > White Space > =20 > Radio spectrum which has been allocated for someprimary = useand assigned for licensed use, but > is not fully occupied by that primary = use licensed use at a specificlocation > and time. This spectrum is then assigned by = locationlocal regulations for use as = licensed-exempt spectrum under control of a white space = database. > =20 > White Space Device (WSD) > =20 > A device which is a = secondarylicense-exempt user of some = part of white space > spectrum. A white space device can be an access point, base > station, a portable device or similar. In this context, a white > space device is required to query a database with its location = to > obtain information about available spectrum. > =20 > =20 > =20 > From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 > To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Nancy, > =20 > This is not that simple. In fact, the qualifiers =93license-exempt=94 = and =93unlicensed=94 can apply to more than one thing. > =20 > If the qualifier applies to a frequency band, different options exist. = As an example, in the ITU-R context, an =93unlicensed=94 band is = typically a new band, say in the 300 GHz, for which no request has been = made for its use. It is therefore un-allocated to a specific service so = far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R = allocates this band to one or many services on a primary or secondary = basis, then the administrations can thendecide under what king of regime = it will =91assign=92 this band foroperation. They may decide to allow = the use of the band on the basis of licensed operation (with different = options to do the assignment: auction, first come/first served, etc.) or = allow operation with an exemption of licenses, thus =93license-exempt=94su= ch as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in = the USA. > =20 > If the qualifier applies to an operation, the operation can be exempt = of license by the local administration, thus a =93license-exempt=94 = operation. If, however, someone decides to start an RF transmission = operation in a licensed band for which he has no license or in a = license-exempt band for which he does not meet the requirements such as = operating according to the type of operation for which the band is = exempted from a license or he operates outside the technical = limitsimposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an =93unlicensed=94 = operation. > =20 > If the qualifier applies to the transmission device, such device may = be a =93license-exempt=94 device if its operation does not require a = specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if = someone smuggles a device that is not allowed in a country by, for = example, buying it on eBay and operates it, this is then an illegal = device in the country and id de-facto an =93unlicensed=94 device since = it has not passed through the normal certification process. > =20 > Note that a =93license-exempt=94 device still has to go through a = certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band = whereas an =93unlicensed=94 device may not pass the certification = process since it has not been licensed to operation in the country. > =20 > This is why the qualifier =93unlicensed=94 has to be treated with care = and the footnote will need to be crafted very carefully. > =20 > With respect to your second point, if an administration only allows = =93licensed=94 operation, the situation will be much simpler to manage = since specific conditions will be attached to these licenses. > =20 > Gerald > =20 > From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 > Sent: Tuesday, 31 January, 2012 06:33 > To: Gerald Chouinard > Cc: Gabor.Bajko@nokia.com; paws@ietf.org > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > Gabor and Gerald,=20 > Since we are dealing on a global basis, can there a footnote to = "unlicensed" we can use to indicate that "according to each countries = regulatory requirements" =20 > How to get around the fact that some Countries are or will be = "licensed only" by their gov'ts? Thanks > Nancy > On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: >=20 >=20 >=20 >=20 >=20 > Gabor, > =20 > I agree with your proposal. Thisseems to be reasonable. However one = needs to be careful with the word=91unlicensed=92 which may mean = =91illegal=92 operation of an RF device in many administrations. > =20 > Gerald > =20 > From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 > Sent: Monday, 30 January, 2012 17:49 > To: gerald.chouinard@sympatico.ca; paws@ietf.org > Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > These look to be very precise definitions, however in everyday use I = rarely hear people referring to ISM band as =91license-exempt=92, in = most cases the term =91unlicensed-band=92 is used. > =20 > Therefore, may I suggest that the draft will include the following = statement: > =20 > The terms unlicensed and license-exempt spectrum are used in this = document interchangeably and refer to a spectrum in which no formal = licensing process is needed for RF devices to operate in, such as the = ISM band. > =20 > - Gabor > =20 > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard > Sent: Monday, January 30, 2012 12:30 PM > To: paws@ietf.org > Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' > =20 > All, > =20 > Here is my understanding of the terms: > =20 > Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). > =20 > Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos thatwould = normally work with full licensing through auction over large service = areas. > =20 > License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. > =20 > Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. > =20 > To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. > =20 > Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I wouldsuggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. > =20 > Gerald > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws >=20 >=20 >=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 > =20 > =20 --Apple-Mail-1-455161390 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = All, 

In this discussion are you not discussing = business models and use cases such as Jon Stine suggested? That would = indicate other models that
would be useful in a global sense, = and not necessarily a Telco model. Myself, I don't see many Telco models = that feel they have enough spectrum.
 In one example was = the mention of the DOD or other spectrum owners who would allow WS use = /sharing, as long as they could, when needed,
use the spectrum = as planned which is not often. Many times mostly unused spectrum merely = says "hi" I am here, but its use is rare. I think it is a more global = forward looking approach,
and managed by the DB's under reg's = of what ever country can use this model. It makes a good business model = to lay for the future of white space, as opposed
to allowing = models not associated with WSDB's at all. Whether you want it in = this part of the protocol, is another question, but it does seem to = belong and further
may allow for more involvement globally = from a business sense, using the DB's./

My 2 = cents for what it's worth.

SIncerely, = Nancy


On Feb 9, 2012, at 6:56 AM, = Gerald Chouinard wrote:

=

Peter,

 

I agree.  It depends on how = the term =91opportunistic=92 is being defined. In my view, the qualifier =91opportunistic=92 relates to the use of the spectrum by devices and not to the availability of the spectrum.  As you describe, the spectrum may be made available on a deterministic basis but its use by one device or another is = opportunistic since it is managed by a near real-time database.  For me, a = deterministic use of the spectrum is an operator buying a license for a frequency band for = a specific period of time such as 5 years with the possibility of = extending this period. In this case, access to a database is not required. This is the = current Telco model.

 

The model that you describe seems = to be an opportunistic use model where not only protection of primary and = secondary incumbents would be provided but also absence of interference amongst = opportunistic users is also provided, turning it into a temporary de-facto =91protected=92= service over a given period of time.  This, to me, is still = =91opportunistic=92.  It is just that all means are taken to make sure that the service is = reliable during the given period of time.

 

If one provides a TVWS database = service and adds to it a coexistence service such as the 802.19.1 approach, you = have more or less the same result.  Such coexistence is however not = mandatory in the TVWS and will depend on the will of the = industry.

 

Gerald

 

From: Peter Stanforth [mailto:peter@spectrumbridge.com]
Sent: Wednesday, 08 = February, 2012 18:48
To: Gerald Chouinard
Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Gerald,<= /o:p>

It depends = what how we define as opportunistic.  We run a secondary market place for = spectrum, FCC rules allow us to act as a "Spectrum Manager" in this role we can provide secondary access to devices under whatever criteria the license = holder deems acceptable. We are, in everything but name, providing access to = white space. In some cases this is opportunistic but in others it is very deterministic and the attraction of the spectrum is because it is deterministic. The key is the owner may not know exactly when or where = they need the spectrum in the future but when they make it available it is guaranteed to be available for the timeframe published. This would not = be possible without a database and yet is clearly not opportunistic. The same could = be said for current US FCC TVWS rules. If we provide a channel list and a = timeframe (Say for the next 4 hours) that channel list will remain available for = the duration.  What is missing, in the case of white space, is that we = cannot deny access to someone else in the same location who asks the same = question, whereas in our secondary marketplace we can. So not only is availability deterministic access is too. 

Peter = S.

 

From: Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Wed, 8 Feb 2012 = 17:46:44 -0500
To: Peter Stanforth = <peter@spectrumbridge.com><= br> Cc: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Peter,

 

See my other email about =91secondary=92 versus =91opportunistic=92.

 

I agree with you that =91primary=92, =91secondary=92, =91deterministic and =91opportunistic=92 use of the spectrum has no relevance to whether the access could be free or paid (after all the primary access to the TV = bands by the broadcasters is free for historical reasons while one coulddecide that = some TVWS access could be paid ;-)  ).

 

Again, the reason why one needs a = DB accessible over the internet is that the access to the spectrum is =91opportunistic=92.  If this was deterministic, the DB would not be needed as has been the case up to = now.

 

Gerald

 

From: Peter Stanforth [mailto:peter@spectrumbridge.com]
Sent: Wednesday, 08 = February, 2012 12:01
To: Gerald Chouinard;andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

There is no = reason to assume that use of white space is by licensed exempt or unlicensed = devices. This comes back to an earlier argument I made about what constitutes = licensed and unlicensed?

Again there = is no reason that a license exempt or unlicensed device should get access to = spectrum for "free" any more that a licensed device has to "pay" for spectrum access.

The concept = of a primary user, who has priority over a secondary user has no relevance to = free or paid access. 

The = rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a = secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the = other, and an argument can be made for both. In a band occupied by a public = safetyuser there may be no choice but to have opportunistic access but in other = bands a primary user may be willing to commit to specific availability if their = own use is deterministic. 

 <= /u1:p>

Peter = S.

 <= /u1:p>

From: Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Wed, 8 Feb 2012 = 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /u1:p>

Andy,

 

To resolve Nancy=92s concern, a new definition could be added = for:

 

TVWS White Space devices: White = Space devices that operate in the TV bands.

 

This would complement the = definition of White Space devices and make it more = specific.

 

I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the = White Spacedevices. The opportunistic use of the RF spectrum assumes that = these devices operate while protecting existing operation in the band.  = There is automatically assumes the existence of primary users of the band that = have priority. Such primary users would most likely be licensed to use the = band and it is only the portions that happen to be unused that will be accessible = to the White Space devices.  The latter are unlikely to be licensed to = only use the =91crumbs=92. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices = and then why would they need to protect these =91primary=92 licensed = devices.

 

This would be similar to the = situation in the 2.4 GHz where a database is not needed to protect other devices. As = is well understood, the databases are there to protect primary and possibly = secondary licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other means such = as adatabase to provide coexistence and this is, I believe, beyond the = scope ofPAWS.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 = February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= o:p>

Nancy<= /font>, all

 <= /u2:p>

Good = questions. I=92m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are = studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary = information in this PAWS requirements I-D to enable the PAWS protocol I-D to be = developed. I don=92t think it=92s our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this = very well, and regulators tend to be well coordinated or play =91follow my = leader=92.

 <= /u2:p>

Thanks for = pointing out the reference to licence-exempt that I had missed in 4.4 -  I = think the meaning would be just the same with =91in a license-exempt TVWS environment=92 deleted from that sentence. That would be my = suggestion.

 <= /u2:p>

Regards=

 <= /u2:p>

Andy

 <= /u2:p>

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February 2012 = 14:48
To: Sago,AJ,Andy,COD = R
Cc: paws@ietf.org
Subject: Fwd: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /u1:p>

Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6=85so if you propose to = remove any reference to TVWS it will = affect

the document as a whole, and information that seems necessary to explain how the DB and protocol = interacts with TVWS devices = and

the methods of doing so. One can envision that current rules could change, but, why not give the = information on both for countries to understand = fully

what it's choices = are? 

 <= /u1:p>

Thanks Andy, just some early morning thoughts=85Sincerely, Nancy

 <= /u1:p>

Begin forwarded = message:

 <= /u1:p>

From: Nancy Bravin <nbravin@earthlink.net>=

Date: February 1, 2012 6:35:09 AM PST

To: Andy Sago <andy.sago@bt.com>

Subject: Re: [paws] Use cases and requirements I-D: = sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /u1:p>

Hi Andy, = All

 <= /u1:p>

In section 4.4, license exempt is also mentioned as = well. 

I am conflicted in a global sense when emerging countries, or countries with very different types of = gov't want to implement

the protocol, will they have enough information to do so? and thereby join the existing DB companies, = orwill they do their own = thing

leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/orWhite spaces in = general?

 <= /u1:p>

Thanks, just a = thought.

 <= /u1:p>

SIncerely, Nancy

 <= /u1:p>

 <= /u1:p>

On Feb 1, 2012, at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

 <= /u1:p>

Scott, = All

 =

I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only = why thelower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th = Jan I proposed (h= ttp://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it simple.

 =

That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  =46rom Scott, = Gerald and Jussi=92s comments perhaps we could agree on:

 =

White Space = (WS)

 

Radio = spectrum which is not fully occupied at a specific location and = time.

 

White Space = device

 

A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white spacedevice is required by local regulations to query a database with = its location to obtain information about available = spectrum.

 =

Regards

 =

Andy

 =

From: <= /font>paws-bounces@ietf.org [mailto:paws-bounces@ie= tf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: gerald.chouinard@sympatico.c= a; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /u1:p>

That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?

 =

Kind = regards,

Jussi<= /font>

 =

From: <= /font>paws-bounces@ietf.org [mailto:paws-bounces@ie= tf.org] On Behalf Of ext= Gerald Chouinard
Sent: 31 January 2012 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /u1:p>

Scott,

 

Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of =93white space=94 as = follows:

 

White = Space

 

Radio = spectrum which has been allocated and assigned for licensed use, but is not fully = occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> bylocal regulations <delete>for use<delete> <insert>to = beused opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>

 

This way, it is understood that the database does not =93assign=94 white space devices for them to choose from.

 

Gerald

From: <= /font>scott.probasco@nokia.com [mailto:scott.probas= co@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

Hi = Gerald,

 

Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?

 

I also = corrected "location" to "local" in previous text proposed for "White Space".

 

Kind = Regards,

Scott

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>,= "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

S= cott,

G= reat proposal.  However, I am still a bit nervous about the definitions = of =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In = fact, it is possible that a band has already primary and secondary services allotted = to it and that the White Space operation is a tertiary opportunistic = operationwhere the two first types ofservices are not being used.  The use of =93lower priority opportunistic=94 service rather than =93secondary=94 service would be preferable to describe white spaceallocations.

&= nbsp;

G= erald

&= nbsp;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work)

 

Hi,

 

I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the draft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.

 

I hope this captures the key points of the discussion. Please do reply if = something is still missing.

 

Kind Regards,

Scott

 

 

2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio = technologies,

      the database is an entity which contains current = information about

      available spectrum at any given location and other types = of

      information.

 

   Device ID

 

      A unique number for each master device and slave device = that

      identifies the manufacturer, model number and serial = number.

 

<Insert>

   Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given = service area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, = company merger &

      acquisition,  first-come / first-served or by = government allocation

      (e.g., public service).

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the USA, license-exempt spectrum is

      Typically referred to as "unlicensed" spectrum. In this document the terms

      license-exempt and unlicensed are used = interchangeably.

 

</Insert>

 

   Location Based Service

 

      An application or device which provides data, information = or

      service to a user based on their = location.

 

  Master Device

 

      A device which queries the WS Database to find out the = available

      operating channels.

 

   Protected Entity

 

      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space

      devices) for its use</Delete> in a given area and = time.

 

   Protected Contour

 

      The exclusion area for a Protected Entity, held in the = database

      and expressed as a polygon with geospatial points as the = vertices.

 

   Slave Device

 

      A device which uses the spectrum made available by a = master

      device.

 

   TV White Space

 

      TV white space refers specifically to radio spectrum which = has

      been allocated for TV broadcast, but is not occupied by a = TV

      broadcast, or other licensed user (such as a wireless = microphone),

      at a specific location and time.

 

   White Space

 

      Radio spectrum which has been allocated <Delete>for someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>

 

   White Space Device (WSD)

 

     A device which is a = <Delete>secondary</Delete><Insert>license-exempt</Ins= ert> user of some part of white space

      spectrum.  A white space device can be an access = point, base

      station, a portable device or similar.  In this = context, a white

      space device is required to query a database with its = location to

      obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

N= ancy,

&= nbsp;

T= his is not that simple.  In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to more than one = thing.

&= nbsp;

I= f the qualifier applies to a frequency band, different options exist. As an example, in = the ITU-R context, an =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its use.  It is therefore un-allocated to a specific service so far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in the USA.

&= nbsp;

I= f the qualifier applies to an operation, the operation can be exempt of = license by the local administration, thus a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limitsimposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an =93unlicensed=94 operation.

&= nbsp;

I= f the qualifier applies to the transmission device, such device may be a =93license-exempt=94 device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an =93unlicensed=94 device since it has not passed through the normal certification process.

&= nbsp;

N= ote that a =93license-exempt=94 device still has to go through a certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band whereas an =93unlicensed=94 device may not pass the certification process since it has not been licensed to operation in the = country.

&= nbsp;

T= his is why the qualifier =93unlicensed=94 has to be treated with care and the footnote will need to be crafted very carefully.

&= nbsp;

W= ith respect to your second point, if an administration only allows =93licensed=94 operation, the situation will be much simpler to manage since specific conditions will be attached to these = licenses.

&= nbsp;

G= erald

&= nbsp;

From: Nancy Bravin [mailto:nbravin@earthlink.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Gabor and = Gerald, 

Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" =  

How to get = around the fact that some Countries are or will be "licensed only" by their gov'ts?  Thanks

Nancy

On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:





G= abor,

&= nbsp;

I= agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word=91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many = administrations.

&= nbsp;

G= erald

&= nbsp;

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.

 

Therefore, may I suggest that the draft will include the following = statement:

 

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.

 

-=       =     Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

= All,

=  

H= ere is my understanding of the terms:

&= nbsp;

L= icensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).

&= nbsp;

L= ightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through = auction over large service areas.

&= nbsp;

L= icense-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

&= nbsp;

U= nlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, this term is used to mean =93license-exempt," see = above.

&= nbsp;

T= o my knowledge, the term =93unlicensed=94 is used only in the USA to describe a = legal operation because the term =93license-exempt=94 has been used for another specific purpose.

&= nbsp;

S= ince the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I wouldsuggest the use of =91licensed=92 and =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the USA instead of the usual =91license-exempt=92.

&= nbsp;

G= erald

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws



 

_______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/m= ailman/listinfo/paws

___________= ____________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws

 <= /u1:p>

 <= /u1:p>

=

=
= --Apple-Mail-1-455161390-- From nbravin@earthlink.net Thu Feb 9 08:02:57 2012 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 287F321F8588 for ; Thu, 9 Feb 2012 08:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[AWL=-2.644, BAYES_20=-0.74, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=1.396, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9Jq6cND1rCn for ; Thu, 9 Feb 2012 08:02:53 -0800 (PST) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 976F121E8014 for ; Thu, 9 Feb 2012 08:02:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=t8KAzW7acG29z2p7UC0soggJ31vvs2TRlQb8lLv4YOZUEna9r1PAsO/kZyBX22iZ; h=Received:From:Mime-Version:Content-Type:Subject:Date:References:Cc:To:Message-Id:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RvWRd-0007aW-Mw; Thu, 09 Feb 2012 11:02:04 -0500 From: Nancy Bravin Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-2-456285657 Date: Thu, 9 Feb 2012 08:02:00 -0800 References: To: Gerald Chouinard , Peter Stanforth , Andy Sago , "John A. Stine" Message-Id: X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86b47885e36d545b15cfa362a446825e2e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: [paws] Fwd: Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 09 Feb 2012 16:02:57 -0000 --Apple-Mail-2-456285657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Sorry, DB's/and associated WS standard interface could both be used in = the appropriate setting, i.e Suburban, rural, remote, semi suburban , = etc. if that is an acceptable model as to not by pass existing, in = development, or to be developed standards.=20 Begin forwarded message: > From: Nancy Bravin > Date: February 9, 2012 7:43:15 AM PST > To: Gerald Chouinard > Cc: Peter Stanforth , Andy Sago = , paws@ietf.org, "John A. Stine" > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >=20 > Hi All,=20 >=20 > In this discussion are you not discussing business models and use = cases such as Jon Stine suggested? That would indicate other models that > would be useful in a global sense, and not necessarily a Telco model. = Myself, I don't see many Telco models that feel they have enough = spectrum. > In one example was the mention of the DOD or other spectrum owners = who would allow WS use /sharing, as long as they could, when needed, > use the spectrum as planned which is not often. Many times mostly = unused spectrum merely says "hi" I am here, but its use is rare. I think = it is a more global forward looking approach, > and managed by the DB's under reg's of what ever country can use this = model. It makes a good business model to lay for the future of white = space, as opposed > to allowing models not associated with WSDB's at all. Whether you want = it in this part of the protocol, is another question, but it does seem = to belong and further > may allow for more involvement globally from a business sense, using = the DB's./ >=20 > My 2 cents for what it's worth. >=20 > SIncerely, Nancy >=20 >=20 > On Feb 9, 2012, at 6:56 AM, Gerald Chouinard wrote: >=20 >> Peter, >> =20 >> I agree. It depends on how the term =91opportunistic=92 is being = defined. In my view, the qualifier =91opportunistic=92 relates to the = use of the spectrum by devices and not to the availability of the = spectrum. As you describe, the spectrum may be made available on a = deterministic basis but its use by one device or another is = opportunistic since it is managed by a near real-time database. For me, = a deterministic use of the spectrum is an operator buying a license for = a frequency band for a specific period of time such as 5 years with the = possibility of extending this period. In this case, access to a database = is not required. This is the current Telco model. >> =20 >> The model that you describe seems to be an opportunistic use model = where not only protection of primary and secondary incumbents would be = provided but also absence of interference amongst opportunistic users is = also provided, turning it into a temporary de-facto =91protected=92 = service over a given period of time. This, to me, is still = =91opportunistic=92. It is just that all means are taken to make sure = that the service is reliable during the given period of time. >> =20 >> If one provides a TVWS database service and adds to it a coexistence = service such as the 802.19.1 approach, you have more or less the same = result. Such coexistence is however not mandatory in the TVWS and will = depend on the will of the industry. >> =20 >> Gerald >> =20 >> From: Peter Stanforth [mailto:peter@spectrumbridge.com]=20 >> Sent: Wednesday, 08 February, 2012 18:48 >> To: Gerald Chouinard >> Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Gerald, >> It depends what how we define as opportunistic. We run a secondary = market place for spectrum, FCC rules allow us to act as a "Spectrum = Manager" in this role we can provide secondary access to devices under = whatever criteria the license holder deems acceptable. We are, in = everything but name, providing access to white space. In some cases this = is opportunistic but in others it is very deterministic and the = attraction of the spectrum is because it is deterministic. The key is = the owner may not know exactly when or where they need the spectrum in = the future but when they make it available it is guaranteed to be = available for the timeframe published. This would not be possible = without a database and yet is clearly not opportunistic. The same could = be said for current US FCC TVWS rules. If we provide a channel list and = a timeframe (Say for the next 4 hours) that channel list will remain = available for the duration. What is missing, in the case of white = space, is that we cannot deny access to someone else in the same = location who asks the same question, whereas in our secondary = marketplace we can. So not only is availability deterministic access is = too.=20 >> Peter S. >> =20 >> From: Gerald Chouinard >> Date: Wed, 8 Feb 2012 17:46:44 -0500 >> To: Peter Stanforth >> Cc: "andy.sago@bt.com" , "nbravin@earthlink.net" = , "paws@ietf.org" >> Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Peter, >> =20 >> See my other email about =91secondary=92 versus =91opportunistic=92. >> =20 >> I agree with you that =91primary=92, =91secondary=92, =91deterministic = and =91opportunistic=92 use of the spectrum has no relevance to whether = the access could be free or paid (after all the primary access to the TV = bands by the broadcasters is free for historical reasons while one = coulddecide that some TVWS access could be paid ;-) ). >> =20 >> Again, the reason why one needs a DB accessible over the internet is = that the access to the spectrum is =91opportunistic=92. If this was = deterministic, the DB would not be needed as has been the case up to = now. >> =20 >> Gerald >> =20 >> From: Peter Stanforth [mailto:peter@spectrumbridge.com]=20 >> Sent: Wednesday, 08 February, 2012 12:01 >> To: Gerald Chouinard;andy.sago@bt.com; nbravin@earthlink.net; = paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> There is no reason to assume that use of white space is by licensed = exempt or unlicensed devices. This comes back to an earlier argument I = made about what constitutes licensed and unlicensed? >> Again there is no reason that a license exempt or unlicensed device = should get access to spectrum for "free" any more that a licensed device = has to "pay" for spectrum access. >> The concept of a primary user, who has priority over a secondary user = has no relevance to free or paid access.=20 >> The rationale for white space is that the spectrum is shared and that = someone has primary, preferred or priority access and the database = ensures that those rights/requirements are met by anyone who uses the = spectrum on a secondary basis. I would go further and say that the = secondary access could be deterministic or opportunistic. There is no = reason to require one or the other, and an argument can be made for = both. In a band occupied by a public safetyuser there may be no choice = but to have opportunistic access but in other bands a primary user may = be willing to commit to specific availability if their own use is = deterministic.=20 >> =20 >> Peter S. >> =20 >> From: Gerald Chouinard >> Date: Wed, 8 Feb 2012 10:20:52 -0500 >> To: "andy.sago@bt.com" , "nbravin@earthlink.net" = , "paws@ietf.org" >> Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Andy, >> =20 >> To resolve Nancy=92s concern, a new definition could be added for: >> =20 >> TVWS White Space devices: White Space devices that operate in the TV = bands. >> =20 >> This would complement the definition of White Space devices and make = it more specific. >> =20 >> I am having second thoughts about yoursuggestion to remove the = concept of classes of devices from the White Spacedevices. The = opportunistic use of the RF spectrum assumes that these devices operate = while protecting existing operation in the band. There is automatically = assumes the existence of primary users of the band that have priority. = Such primary users would most likely be licensed to use the band and it = is only the portions that happen to be unused that will be accessible to = the White Space devices. The latter are unlikely to be licensed to only = use the =91crumbs=92. Removing the concept of license-exempt could put = these new devices at the same level of priority as the primary devices = and then why would they need to protect these =91primary=92 licensed = devices. >> =20 >> This would be similar to the situation in the 2.4 GHz where a = database is not needed to protect other devices. As is well understood, = the databases are there to protect primary and possibly secondary = licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other = means such as adatabase to provide coexistence and this is, I believe, = beyond the scope ofPAWS. >> =20 >> Gerald >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of andy.sago@bt.com >> Sent: Wednesday, 01 February, 2012 09:58 >> To: nbravin@earthlink.net; paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Nancy, all >> =20 >> Good questions. I=92m not proposing to remove references to TVWS, = they are entirely appropriate within the use cases since it is the TV = bands we are studying as first candidate for opportunistic access, but = the charter says we are addressing all white space in the resulting = protocol. To answer your other questions, IMO our aim should be to = provide all the necessary information in this PAWS requirements I-D to = enable the PAWS protocol I-D to be developed. I don=92t think it=92s our = job to explain different regulatory regimes or applications (beyond use = cases) in this document, ITU and others do this very well, and = regulators tend to be well coordinated or play =91follow my leader=92. >> =20 >> Thanks for pointing out the reference to licence-exempt that I had = missed in 4.4 - I think the meaning would be just the same with =91in a = license-exempt TVWS environment=92 deleted from that sentence. That = would be my suggestion. >> =20 >> Regards >> =20 >> Andy >> =20 >> From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 >> Sent: 01 February 2012 14:48 >> To: Sago,AJ,Andy,COD R >> Cc: paws@ietf.org >> Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, = 4.6=85so if you propose to remove any reference to TVWS it will affect >> the document as a whole, and information that seems necessary to = explain how the DB and protocol interacts with TVWS devices and >> the methods of doing so. One can envision that current rules could = change, but, why not give the information on both for countries to = understand fully >> what it's choices are?=20 >> =20 >> Thanks Andy, just some early morning thoughts=85Sincerely, Nancy >> =20 >> Begin forwarded message: >> =20 >>=20 >> From: Nancy Bravin >> Date: February 1, 2012 6:35:09 AM PST >> To: Andy Sago >> Cc: , , = , >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi Andy, All >> =20 >> In section 4.4, license exempt is also mentioned as well.=20 >> I am conflicted in a global sense when emerging countries, or = countries with very different types of gov't want to implement >> the protocol, will they have enough information to do so? and thereby = join the existing DB companies, orwill they do their own thing >> leaving holes in what one hopes will be an interoperable global = protocol that deals with TVWS, and/orWhite spaces in general? >> =20 >> Thanks, just a thought. >> =20 >> SIncerely, Nancy >> =20 >> =20 >> On Feb 1, 2012, at 2:34 AM, = wrote: >> =20 >>=20 >> Scott, All >> =20 >> I agree with Jussi that we have now narrowed the definition to apply = to TV white spaces, whereas the scope of PAWS is white spaces in = general. I would question not only why thelower-priority service would = always be licence-exempt, but why the higher priority service would = always be licenced. To avoid this issue on 27th Jan I proposed = (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a = revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent = services. The Abstract derives from the Introduction and the text could = be aligned to be the same in the Introduction, with =93opportunistic=94 = replacing =93secondary=94 in later sentences in the Introduction. I have = checked and there are no further references to licensing in the = document, so we don=92t need the definitions of licence exempt, light = licensing or unlicensed. This is not a regulatory document =96 we are = defining requirements fora protocol. Keep it simple. >> =20 >> That just leaves the definition of white space, where the existing = spectrum use has now got muddled with the potential for opportunistic = use. This can be fixed by taking the white space and white space device = definitions together. =46rom Scott, Gerald and Jussi=92s comments = perhaps we could agree on: >> =20 >> White Space (WS) >> =20 >> Radio spectrum which is not fully occupied at a specific location and = time. >> =20 >> White Space device >> =20 >> A device which opportunistically uses some part of the white space = spectrum, under control of a white space database. A white space device = can be an access point, base station, a portable device or similar. In = this context, a white spacedevice is required by local regulations to = query a database with its location to obtain information about available = spectrum. >> =20 >> Regards >> =20 >> Andy >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of jussi.kahtava@nokia.com >> Sent: 01 February 2012 07:31 >> To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> That statement is valid for TV White Spaces on UHF frequencies but = does not necessarily apply to all under-utilised radio spectrum. Why = would the lower priority service by default be licence-exempt? >> =20 >> Kind regards, >> Jussi >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard >> Sent: 31 January 2012 22:33 >> To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Scott, >> =20 >> Very good improvements. I would suggest to insert the notion of = opportunistic use of the spectrum by white space devices in the last = sentence of the definition of =93white space=94 as follows: >> =20 >> White Space >> =20 >> Radio spectrum which has been allocated and assigned for licensed = use, but is not fully occupied by that licensed use at a specific = location and time. This spectrum is then assigned = allowed bylocal regulations for use = to beused opportunistically as licensed-exempt spectrum = under control of a white space database. >> =20 >> This way, it is understood that the database does not =93assign=94 = white space devices for them to choose from. >> =20 >> Gerald >> From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 >> Sent: Tuesday, 31 January, 2012 15:12 >> To: gerald.chouinard@sympatico.ca; paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi Gerald, >> =20 >> Good to avoid overloading the term "secondary". I have made = additional proposed changes to the text below based on your suggestion. = "Lower priority opportunistic service" could indeed by used, but I am = guessing that we would need some explanation of what that means. Since = we now have descriptions of licensed spectrum and license-exempt = spectrum, I used these words. Do these changes remove your concerns? >> =20 >> I also corrected "location" to "local" in previous text proposed for = "White Space". >> =20 >> Kind Regards, >> Scott >> =20 >> From: ext Gerald Chouinard >> Date: Tue, 31 Jan 2012 14:41:36 -0500 >> To: Scott , "paws@ietf.org" >> Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Scott, >> Great proposal. However, I am still a bit nervous about the = definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 = where the notion of secondary use is included. The secondary status is = used in the ITU-R Radio Regulations for a different purpose. In fact, = it is possible that a band has already primary and secondary services = allotted to it and that the White Space operation is a tertiary = opportunistic operationwhere the two first types ofservices are not = being used. The use of =93lower priority opportunistic=94 service = rather than =93secondary=94 service would be preferable to describe = white spaceallocations. >> =20 >> Gerald >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com >> Sent: Tuesday, 31 January, 2012 13:56 >> To: paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi, >> =20 >> I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes = to the draft based on the email discussion. >> =20 >> Below is a copy of chapter 2.2. Terminology. I have inserted new = terms for 'licensed' and 'license-exempt' and made changes to the term = 'white space'. I have tried to work from the perspective that the = document should accurately explain the subject with aim that a reader = can understand the use cases and the subsequent requirements. No doubt = we could include much more text on this topic of spectrum allocation, = assignment, licensing and usage. >> =20 >> I hope this captures the key points of the discussion. Please do = reply if something is still missing. >> =20 >> Kind Regards, >> Scott >> =20 >> =20 >> 2.2. Terminology >> =20 >> Database >> =20 >> In the context of white space and cognitive radio technologies, >> the database is an entity which contains current information = about >> available spectrum at any given location and other types of >> information. >> =20 >> Device ID >> =20 >> A unique number for each master device and slave device that >> identifies the manufacturer, model number and serial number. >> =20 >> >> Licensed Spectrum >> =20 >> Spectrum that is acquired by an operator over a given service = area >> for a given time period. This is usually done through = auctions,award >> (beauty contest), acquisition from secondary market, company = merger & >> acquisition, first-come / first-served or by government = allocation >> (e.g., public service). >> =20 >> License-exempt Spectrum >> =20 >> Spectrum that is not assigned to any specific user. One example = is the 2.4 Ghz ISM band, where RF devices >> operate without a formal licensing process. In the USA, = license-exempt spectrum is >> Typically referred to as "unlicensed" spectrum. In this = document the terms >> license-exempt and unlicensed are used interchangeably. >> =20 >> >> =20 >> Location Based Service >> =20 >> An application or device which provides data, information or >> service to a user based on their location. >> =20 >> Master Device >> =20 >> A device which queries the WS Database to find out the = available >> operating channels. >> =20 >> Protected Entity >> =20 >> A licensed user of spectrum, when the licensed spectrum = has been assigned as white space spectrum. A = primaryA licensed user of white space spectrum = which is afforded >> protection against interference by = secondarylicense-exempt white space = users (white space >> devices) for its use in a given area and time. >> =20 >> Protected Contour >> =20 >> The exclusion area for a Protected Entity, held in the database >> and expressed as a polygon with geospatial points as the = vertices. >> =20 >> Slave Device >> =20 >> A device which uses the spectrum made available by a master >> device. >> =20 >> TV White Space >> =20 >> TV white space refers specifically to radio spectrum which has >> been allocated for TV broadcast, but is not occupied by a TV >> broadcast, or other licensed user (such as a wireless = microphone), >> at a specific location and time. >> =20 >> White Space >> =20 >> Radio spectrum which has been allocated for someprimary = useand assigned for licensed use, but >> is not fully occupied by that primary = use licensed use at a specificlocation >> and time. This spectrum is then assigned by = locationlocal regulations for use as = licensed-exempt spectrum under control of a white space = database. >> =20 >> White Space Device (WSD) >> =20 >> A device which is a = secondarylicense-exempt user of some = part of white space >> spectrum. A white space device can be an access point, base >> station, a portable device or similar. In this context, a = white >> space device is required to query a database with its location = to >> obtain information about available spectrum. >> =20 >> =20 >> =20 >> From: ext Gerald Chouinard >> Date: Tue, 31 Jan 2012 10:07:30 -0500 >> To: 'Nancy Bravin' >> Cc: "paws@ietf.org" >> Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> Nancy, >> =20 >> This is not that simple. In fact, the qualifiers =93license-exempt=94 = and =93unlicensed=94 can apply to more than one thing. >> =20 >> If the qualifier applies to a frequency band, different options = exist. As an example, in the ITU-R context, an =93unlicensed=94 band is = typically a new band, say in the 300 GHz, for which no request has been = made for its use. It is therefore un-allocated to a specific service so = far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R = allocates this band to one or many services on a primary or secondary = basis, then the administrations can thendecide under what king of regime = it will =91assign=92 this band foroperation. They may decide to allow = the use of the band on the basis of licensed operation (with different = options to do the assignment: auction, first come/first served, etc.) or = allow operation with an exemption of licenses, thus =93license-exempt=94su= ch as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in = the USA. >> =20 >> If the qualifier applies to an operation, the operation can be exempt = of license by the local administration, thus a =93license-exempt=94 = operation. If, however, someone decides to start an RF transmission = operation in a licensed band for which he has no license or in a = license-exempt band for which he does not meet the requirements such as = operating according to the type of operation for which the band is = exempted from a license or he operates outside the technical = limitsimposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an =93unlicensed=94 = operation. >> =20 >> If the qualifier applies to the transmission device, such device may = be a =93license-exempt=94 device if its operation does not require a = specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if = someone smuggles a device that is not allowed in a country by, for = example, buying it on eBay and operates it, this is then an illegal = device in the country and id de-facto an =93unlicensed=94 device since = it has not passed through the normal certification process. >> =20 >> Note that a =93license-exempt=94 device still has to go through a = certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band = whereas an =93unlicensed=94 device may not pass the certification = process since it has not been licensed to operation in the country. >> =20 >> This is why the qualifier =93unlicensed=94 has to be treated with = care and the footnote will need to be crafted very carefully. >> =20 >> With respect to your second point, if an administration only allows = =93licensed=94 operation, the situation will be much simpler to manage = since specific conditions will be attached to these licenses. >> =20 >> Gerald >> =20 >> From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 >> Sent: Tuesday, 31 January, 2012 06:33 >> To: Gerald Chouinard >> Cc: Gabor.Bajko@nokia.com; paws@ietf.org >> Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> Gabor and Gerald,=20 >> Since we are dealing on a global basis, can there a footnote to = "unlicensed" we can use to indicate that "according to each countries = regulatory requirements" =20 >> How to get around the fact that some Countries are or will be = "licensed only" by their gov'ts? Thanks >> Nancy >> On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: >>=20 >>=20 >>=20 >>=20 >>=20 >> Gabor, >> =20 >> I agree with your proposal. Thisseems to be reasonable. However one = needs to be careful with the word=91unlicensed=92 which may mean = =91illegal=92 operation of an RF device in many administrations. >> =20 >> Gerald >> =20 >> From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 >> Sent: Monday, 30 January, 2012 17:49 >> To: gerald.chouinard@sympatico.ca; paws@ietf.org >> Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> These look to be very precise definitions, however in everyday use I = rarely hear people referring to ISM band as =91license-exempt=92, in = most cases the term =91unlicensed-band=92 is used. >> =20 >> Therefore, may I suggest that the draft will include the following = statement: >> =20 >> The terms unlicensed and license-exempt spectrum are used in this = document interchangeably and refer to a spectrum in which no formal = licensing process is needed for RF devices to operate in, such as the = ISM band. >> =20 >> - Gabor >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard >> Sent: Monday, January 30, 2012 12:30 PM >> To: paws@ietf.org >> Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> All, >> =20 >> Here is my understanding of the terms: >> =20 >> Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). >> =20 >> Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos thatwould = normally work with full licensing through auction over large service = areas. >> =20 >> License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. >> =20 >> Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. >> =20 >> To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. >> =20 >> Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I wouldsuggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. >> =20 >> Gerald >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=20 >>=20 >>=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 >> =20 >> =20 >=20 --Apple-Mail-2-456285657 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: Nancy Bravin <nbravin@earthlink.net>
Date: February 9, 2012 7:43:15 AM PST
To: Gerald Chouinard = <gerald.chouinard@sympatico.c= a>
Cc: Peter Stanforth <peter@spectrumbridge.com>,= Andy Sago <andy.sago@bt.com>, paws@ietf.org, "John A. Stine" <jstine@mitre.org>
=
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions = and Terminology, Prior Work)

Hi = All, 

In this discussion are you not discussing = business models and use cases such as Jon Stine suggested? That would = indicate other models that
would be useful in a global sense, = and not necessarily a Telco model. Myself, I don't see many Telco models = that feel they have enough spectrum.
 In one example was = the mention of the DOD or other spectrum owners who would allow WS use = /sharing, as long as they could, when needed,
use the spectrum = as planned which is not often. Many times mostly unused spectrum merely = says "hi" I am here, but its use is rare. I think it is a more global = forward looking approach,
and managed by the DB's under reg's = of what ever country can use this model. It makes a good business model = to lay for the future of white space, as opposed
to allowing = models not associated with WSDB's at all. Whether you want it in = this part of the protocol, is another question, but it does seem to = belong and further
may allow for more involvement globally = from a business sense, using the DB's./

My 2 = cents for what it's worth.

SIncerely, = Nancy


On Feb 9, 2012, at 6:56 AM, = Gerald Chouinard wrote:

=

Peter,

 

I agree.  It depends on how = the term =91opportunistic=92 is being defined. In my view, the qualifier =91opportunistic=92 relates to the use of the spectrum by devices and not to the availability of the spectrum.  As you describe, the spectrum may be made available on a deterministic basis but its use by one device or another is = opportunistic since it is managed by a near real-time database.  For me, a = deterministic use of the spectrum is an operator buying a license for a frequency band for = a specific period of time such as 5 years with the possibility of = extending this period. In this case, access to a database is not required. This is the = current Telco model.

 

The model that you describe seems = to be an opportunistic use model where not only protection of primary and = secondary incumbents would be provided but also absence of interference amongst = opportunistic users is also provided, turning it into a temporary de-facto =91protected=92= service over a given period of time.  This, to me, is still = =91opportunistic=92.  It is just that all means are taken to make sure that the service is = reliable during the given period of time.

 

If one provides a TVWS database = service and adds to it a coexistence service such as the 802.19.1 approach, you = have more or less the same result.  Such coexistence is however not = mandatory in the TVWS and will depend on the will of the = industry.

 

Gerald

 

From: Peter Stanforth [mailto:peter@spectrumbridge.com]
Sent: Wednesday, 08 = February, 2012 18:48
To: Gerald Chouinard
Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Gerald,<= /o:p>

It depends = what how we define as opportunistic.  We run a secondary market place for = spectrum, FCC rules allow us to act as a "Spectrum Manager" in this role we can provide secondary access to devices under whatever criteria the license = holder deems acceptable. We are, in everything but name, providing access to = white space. In some cases this is opportunistic but in others it is very deterministic and the attraction of the spectrum is because it is deterministic. The key is the owner may not know exactly when or where = they need the spectrum in the future but when they make it available it is guaranteed to be available for the timeframe published. This would not = be possible without a database and yet is clearly not opportunistic. The same could = be said for current US FCC TVWS rules. If we provide a channel list and a = timeframe (Say for the next 4 hours) that channel list will remain available for = the duration.  What is missing, in the case of white space, is that we = cannot deny access to someone else in the same location who asks the same = question, whereas in our secondary marketplace we can. So not only is availability deterministic access is too. 

Peter = S.

 

From: Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Wed, 8 Feb 2012 = 17:46:44 -0500
To: Peter Stanforth = <peter@spectrumbridge.com><= br> Cc: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Peter,

 

See my other email about =91secondary=92 versus =91opportunistic=92.

 

I agree with you that =91primary=92, =91secondary=92, =91deterministic and =91opportunistic=92 use of the spectrum has no relevance to whether the access could be free or paid (after all the primary access to the TV = bands by the broadcasters is free for historical reasons while one coulddecide that = some TVWS access could be paid ;-)  ).

 

Again, the reason why one needs a = DB accessible over the internet is that the access to the spectrum is =91opportunistic=92.  If this was deterministic, the DB would not be needed as has been the case up to = now.

 

Gerald

 

From: Peter Stanforth [mailto:peter@spectrumbridge.com]
Sent: Wednesday, 08 = February, 2012 12:01
To: Gerald Chouinard;andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

There is no = reason to assume that use of white space is by licensed exempt or unlicensed = devices. This comes back to an earlier argument I made about what constitutes = licensed and unlicensed?

Again there = is no reason that a license exempt or unlicensed device should get access to = spectrum for "free" any more that a licensed device has to "pay" for spectrum access.

The concept = of a primary user, who has priority over a secondary user has no relevance to = free or paid access. 

The = rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a = secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the = other, and an argument can be made for both. In a band occupied by a public = safetyuser there may be no choice but to have opportunistic access but in other = bands a primary user may be willing to commit to specific availability if their = own use is deterministic. 

 <= /u1:p>

Peter = S.

 <= /u1:p>

From: Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Wed, 8 Feb 2012 = 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /u1:p>

Andy,

 

To resolve Nancy=92s concern, a new definition could be added = for:

 

TVWS White Space devices: White = Space devices that operate in the TV bands.

 

This would complement the = definition of White Space devices and make it more = specific.

 

I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the = White Spacedevices. The opportunistic use of the RF spectrum assumes that = these devices operate while protecting existing operation in the band.  = There is automatically assumes the existence of primary users of the band that = have priority. Such primary users would most likely be licensed to use the = band and it is only the portions that happen to be unused that will be accessible = to the White Space devices.  The latter are unlikely to be licensed to = only use the =91crumbs=92. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices = and then why would they need to protect these =91primary=92 licensed = devices.

 

This would be similar to the = situation in the 2.4 GHz where a database is not needed to protect other devices. As = is well understood, the databases are there to protect primary and possibly = secondary licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other means such = as adatabase to provide coexistence and this is, I believe, beyond the = scope ofPAWS.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 = February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= o:p>

Nancy<= /font>, all

 <= /u2:p>

Good = questions. I=92m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are = studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary = information in this PAWS requirements I-D to enable the PAWS protocol I-D to be = developed. I don=92t think it=92s our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this = very well, and regulators tend to be well coordinated or play =91follow my = leader=92.

 <= /u2:p>

Thanks for = pointing out the reference to licence-exempt that I had missed in 4.4 -  I = think the meaning would be just the same with =91in a license-exempt TVWS environment=92 deleted from that sentence. That would be my = suggestion.

 <= /u2:p>

Regards=

 <= /u2:p>

Andy

 <= /u2:p>

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February 2012 = 14:48
To: Sago,AJ,Andy,COD = R
Cc: paws@ietf.org
Subject: Fwd: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /u1:p>

Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6=85so if you propose to = remove any reference to TVWS it will = affect

the document as a whole, and information that seems necessary to explain how the DB and protocol = interacts with TVWS devices = and

the methods of doing so. One can envision that current rules could change, but, why not give the = information on both for countries to understand = fully

what it's choices = are? 

 <= /u1:p>

Thanks Andy, just some early morning thoughts=85Sincerely, Nancy

 <= /u1:p>

Begin forwarded = message:

 <= /u1:p>

From: Nancy Bravin <nbravin@earthlink.net>=

Date: February 1, 2012 6:35:09 AM PST

To: Andy Sago <andy.sago@bt.com>

Subject: Re: [paws] Use cases and requirements I-D: = sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /u1:p>

Hi Andy, = All

 <= /u1:p>

In section 4.4, license exempt is also mentioned as = well. 

I am conflicted in a global sense when emerging countries, or countries with very different types of = gov't want to implement

the protocol, will they have enough information to do so? and thereby join the existing DB companies, = orwill they do their own = thing

leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/orWhite spaces in = general?

 <= /u1:p>

Thanks, just a = thought.

 <= /u1:p>

SIncerely, Nancy

 <= /u1:p>

 <= /u1:p>

On Feb 1, 2012, at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

 <= /u1:p>

Scott, = All

 =

I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only = why thelower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th = Jan I proposed (h= ttp://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it simple.

 =

That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  =46rom Scott, = Gerald and Jussi=92s comments perhaps we could agree on:

 =

White Space = (WS)

 

Radio = spectrum which is not fully occupied at a specific location and = time.

 

White Space = device

 

A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white spacedevice is required by local regulations to query a database with = its location to obtain information about available = spectrum.

 =

Regards

 =

Andy

 =

From: <= /font>paws-bounces@ietf.org [mailto:paws-bounces@ie= tf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: gerald.chouinard@sympatico.c= a; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /u1:p>

That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?

 =

Kind = regards,

Jussi<= /font>

 =

From: <= /font>paws-bounces@ietf.org [mailto:paws-bounces@ie= tf.org] On Behalf Of ext= Gerald Chouinard
Sent: 31 January 2012 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 <= /u1:p>

Scott,

 

Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of =93white space=94 as = follows:

 

White = Space

 

Radio = spectrum which has been allocated and assigned for licensed use, but is not fully = occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> bylocal regulations <delete>for use<delete> <insert>to = beused opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>

 

This way, it is understood that the database does not =93assign=94 white space devices for them to choose from.

 

Gerald

From: <= /font>scott.probasco@nokia.com [mailto:scott.probas= co@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

Hi = Gerald,

 

Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?

 

I also = corrected "location" to "local" in previous text proposed for "White Space".

 

Kind = Regards,

Scott

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>,= "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

S= cott,

G= reat proposal.  However, I am still a bit nervous about the definitions = of =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In = fact, it is possible that a band has already primary and secondary services allotted = to it and that the White Space operation is a tertiary opportunistic = operationwhere the two first types ofservices are not being used.  The use of =93lower priority opportunistic=94 service rather than =93secondary=94 service would be preferable to describe white spaceallocations.

&= nbsp;

G= erald

&= nbsp;

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work)

 

Hi,

 

I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the draft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.

 

I hope this captures the key points of the discussion. Please do reply if = something is still missing.

 

Kind Regards,

Scott

 

 

2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio = technologies,

      the database is an entity which contains current = information about

      available spectrum at any given location and other types = of

      information.

 

   Device ID

 

      A unique number for each master device and slave device = that

      identifies the manufacturer, model number and serial = number.

 

<Insert>

   Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given = service area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, = company merger &

      acquisition,  first-come / first-served or by = government allocation

      (e.g., public service).

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the USA, license-exempt spectrum is

      Typically referred to as "unlicensed" spectrum. In this document the terms

      license-exempt and unlicensed are used = interchangeably.

 

</Insert>

 

   Location Based Service

 

      An application or device which provides data, information = or

      service to a user based on their = location.

 

  Master Device

 

      A device which queries the WS Database to find out the = available

      operating channels.

 

   Protected Entity

 

      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space

      devices) for its use</Delete> in a given area and = time.

 

   Protected Contour

 

      The exclusion area for a Protected Entity, held in the = database

      and expressed as a polygon with geospatial points as the = vertices.

 

   Slave Device

 

      A device which uses the spectrum made available by a = master

      device.

 

   TV White Space

 

      TV white space refers specifically to radio spectrum which = has

      been allocated for TV broadcast, but is not occupied by a = TV

      broadcast, or other licensed user (such as a wireless = microphone),

      at a specific location and time.

 

   White Space

 

      Radio spectrum which has been allocated <Delete>for someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>

 

   White Space Device (WSD)

 

     A device which is a = <Delete>secondary</Delete><Insert>license-exempt</Ins= ert> user of some part of white space

      spectrum.  A white space device can be an access = point, base

      station, a portable device or similar.  In this = context, a white

      space device is required to query a database with its = location to

      obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

N= ancy,

&= nbsp;

T= his is not that simple.  In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to more than one = thing.

&= nbsp;

I= f the qualifier applies to a frequency band, different options exist. As an example, in = the ITU-R context, an =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its use.  It is therefore un-allocated to a specific service so far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in the USA.

&= nbsp;

I= f the qualifier applies to an operation, the operation can be exempt of = license by the local administration, thus a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limitsimposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an =93unlicensed=94 operation.

&= nbsp;

I= f the qualifier applies to the transmission device, such device may be a =93license-exempt=94 device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an =93unlicensed=94 device since it has not passed through the normal certification process.

&= nbsp;

N= ote that a =93license-exempt=94 device still has to go through a certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band whereas an =93unlicensed=94 device may not pass the certification process since it has not been licensed to operation in the = country.

&= nbsp;

T= his is why the qualifier =93unlicensed=94 has to be treated with care and the footnote will need to be crafted very carefully.

&= nbsp;

W= ith respect to your second point, if an administration only allows =93licensed=94 operation, the situation will be much simpler to manage since specific conditions will be attached to these = licenses.

&= nbsp;

G= erald

&= nbsp;

From: Nancy Bravin [mailto:nbravin@earthlink.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Gabor and = Gerald, 

Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" =  

How to get = around the fact that some Countries are or will be "licensed only" by their gov'ts?  Thanks

Nancy

On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:





G= abor,

&= nbsp;

I= agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word=91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many = administrations.

&= nbsp;

G= erald

&= nbsp;

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.

 

Therefore, may I suggest that the draft will include the following = statement:

 

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.

 

-=       =     Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

= All,

=  

H= ere is my understanding of the terms:

&= nbsp;

L= icensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).

&= nbsp;

L= ightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through = auction over large service areas.

&= nbsp;

L= icense-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

&= nbsp;

U= nlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, this term is used to mean =93license-exempt," see = above.

&= nbsp;

T= o my knowledge, the term =93unlicensed=94 is used only in the USA to describe a = legal operation because the term =93license-exempt=94 has been used for another specific purpose.

&= nbsp;

S= ince the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I wouldsuggest the use of =91licensed=92 and =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the USA instead of the usual =91license-exempt=92.

&= nbsp;

G= erald

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws



 

_______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/m= ailman/listinfo/paws

___________= ____________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws

 <= /u1:p>

 <= /u1:p>

=

=

= --Apple-Mail-2-456285657-- From peter@spectrumbridge.com Thu Feb 9 08:08:01 2012 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 AD23421E801F for ; Thu, 9 Feb 2012 08:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.566 X-Spam-Level: * X-Spam-Status: No, score=1.566 tagged_above=-999 required=5 tests=[AWL=-3.156, BAYES_40=-0.185, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_93=0.6, SARE_FWDLOOK=1.666, SARE_LWHUGE=1.54] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vuy99R8X7wOY for ; Thu, 9 Feb 2012 08:07:57 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id D928121F8570 for ; Thu, 9 Feb 2012 08:07:54 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 9 Feb 2012 11:08:53 -0500 From: Peter Stanforth To: Nancy Bravin , Gerald Chouinard Date: Thu, 9 Feb 2012 11:07:43 -0500 Thread-Topic: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Thread-Index: AcznRR3ipwW1YwLeT76upgE8nd6daQ== 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.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB59560F1FB41peterspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 09 Feb 2012 16:08:01 -0000 --_000_CB59560F1FB41peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree this is a business issue, but there is a DB potential. I will give you some scenarios we deal with often. A construction project r= equests spectrum for a time and place in the future. They may only need it = for a day or a month. A sporting or cultural event wants some spectrum nex= t week for a day. These are not traditional telco models but they are real = scenarios and they absolutely need a certainty that they will get the acces= s they have requested. We use a spectrum management database and coordinati= on with a primary user to meet these needs. Much of the actual coordinati= on is done manually today =96 which is time consuming and expensive.I am ju= st pointing out that assuming that all the world wants is the traditional t= elco model or an opportunistic unlicensed white space model misses a huge o= pportunity for which a database is a key component in automating this and m= aking it realistic. From: Nancy Bravin > Date: Thu, 9 Feb 2012 10:43:15 -0500 To: Gerald Chouinard > Cc: Peter Stanforth >, Andy Sago >, "paws@ietf.org= " >, "John A. Sti= ne" > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Hi All, In this discussion are you not discussing business models and use cases suc= h as Jon Stine suggested? That would indicate other models that would be useful in a global sense, and not necessarily a Telco model. Mysel= f, I don't see many Telco models that feel they have enough spectrum. In one example was the mention of the DOD or other spectrum owners who wou= ld allow WS use /sharing, as long as they could, when needed, use the spectrum as planned which is not often. Many times mostly unused sp= ectrum merely says "hi" I am here, but its use is rare. I think it is a mor= e global forward looking approach, and managed by the DB's under reg's of what ever country can use this model= . It makes a good business model to lay for the future of white space, as o= pposed to allowing models not associated with WSDB's at all. Whether you want it i= n this part of the protocol, is another question, but it does seem to belon= g and further may allow for more involvement globally from a business sense, using the DB= 's./ My 2 cents for what it's worth. SIncerely, Nancy On Feb 9, 2012, at 6:56 AM, Gerald Chouinard wrote: Peter, I agree. It depends on how the term =91opportunistic=92 is being defined. = In my view, the qualifier =91opportunistic=92 relates to the use of the spe= ctrum by devices and not to the availability of the spectrum. As you descr= ibe, the spectrum may be made available on a deterministic basis but its us= e by one device or another is opportunistic since it is managed by a near r= eal-time database. For me, a deterministic use of the spectrum is an opera= tor buying a license for a frequency band for a specific period of time suc= h as 5 years with the possibility of extending this period. In this case, a= ccess to a database is not required. This is the current Telco model. The model that you describe seems to be an opportunistic use model where no= t only protection of primary and secondary incumbents would be provided but= also absence of interference amongst opportunistic users is also provided,= turning it into a temporary de-facto =91protected=92 service over a given = period of time. This, to me, is still =91opportunistic=92. It is just tha= t all means are taken to make sure that the service is reliable during the = given period of time. If one provides a TVWS database service and adds to it a coexistence servic= e such as the 802.19.1 approach, you have more or less the same result. Su= ch coexistence is however not mandatory in the TVWS and will depend on the = will of the industry. Gerald ________________________________ From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Wednesday, 08 February, 2012 18:48 To: Gerald Chouinard Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Gerald, It depends what how we define as opportunistic. We run a secondary market = place for spectrum, FCC rules allow us to act as a "Spectrum Manager" in th= is role we can provide secondary access to devices under whatever criteria = the license holder deems acceptable. We are, in everything but name, provid= ing access to whitespace. In some cases this is opportunistic but in others= it is very deterministic and the attraction of the spectrum is because it = is deterministic. The key is the owner may not know exactly when or where t= heyneed the spectrum in the future but when they make it available it is gu= aranteed to be available for the timeframe published. This would not be pos= sible without a database and yet is clearly not opportunistic. The same cou= ld be said for current US FCC TVWS rules. If we provide a channel list and = a timeframe(Say for the next 4 hours) that channel list will remain availab= le for the duration. What is missing, in the case of white space, is that = we cannot deny access to someone else in the same location who asks the sam= e question, whereas in our secondary marketplace we can. So not only is ava= ilability deterministic access is too. Peter S. From: Gerald Chouinard > Date: Wed, 8 Feb 2012 17:46:44 -0500 To: Peter Stanforth > Cc: "andy.sago@bt.com" >, "nbravin@earthlink.net" >, "paws@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Peter, See my other email about =91secondary=92 versus =91opportunistic=92. I agree with you that =91primary=92, =91secondary=92, =91deterministic and = =91opportunistic=92 use of the spectrum has no relevance to whether the acc= ess could be free or paid (after all the primary access to the TV bands by = the broadcasters is free for historical reasons while one coulddecide that = someTVWS access could be paid ;-) ). Again, the reason why one needs a DB accessible over the internet is that t= he access to the spectrum is =91opportunistic=92. If this was deterministi= c, the DB would not be needed as has been the case up to now. Gerald ________________________________ From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Wednesday, 08 February, 2012 12:01 To: Gerald Chouinard;andy.sago@bt.com; nbravin@ear= thlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) There is no reason to assume that use of white space is by licensed exempt = or unlicensed devices. This comes back to an earlier argument I made about = what constitutes licensed and unlicensed? Again there is no reason that a license exempt or unlicensed device should = get access to spectrum for "free" any more that a licensed device has to "p= ay" for spectrum access. The concept of a primary user, who has priority over a secondary user has n= o relevance to free or paid access. The rationale for white space is that the spectrum is shared and that someo= ne has primary, preferred or priority access and the database ensures that = those rights/requirements are met by anyone who uses the spectrum on a seco= ndary basis. I would go further and say that the secondary access could be = deterministic or opportunistic. There is no reason to require one or the ot= her, and an argument can be made for both. In a band occupied by a public s= afetyuser there may be no choice but to have opportunistic access but in ot= her bands a primary user may be willing to commit to specific availability = if their own use is deterministic. Peter S. From: Gerald Chouinard > Date: Wed, 8 Feb 2012 10:20:52 -0500 To: "andy.sago@bt.com" >, "nbravin@earthlink.net" >, "paws@ietf.org" > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Andy, To resolve Nancy=92s concern, a new definition could be added for: TVWS White Space devices: White Space devices that operate in the TV bands. This would complement the definition of White Space devices and make it mor= e specific. I am having second thoughts about yoursuggestion to remove the concept of c= lasses of devices from the White Spacedevices. The opportunistic use of the= RF spectrum assumes that these devices operate while protecting existing o= peration in the band. There is automatically assumes the existence of prim= ary users of the band that have priority. Such primary users would most lik= ely be licensed to use the band and it is only the portions that happen to = be unused that will be accessible to the White Space devices. The latter a= re unlikely to be licensed to only use the =91crumbs=92. Removing the conce= pt of license-exempt could put these new devices at the same level of prior= ity as the primary devices and then why would they need to protect these = =91primary=92 licensed devices. This would be similar to the situation in the 2.4 GHz where a database is n= ot needed to protect other devices. As is well understood, the databases ar= e there to protect primary and possibly secondary licensed devices from the= new opportunistic devices, not opportunistic devices among themselves. The= latter case would be covered by other means such as adatabase to provide c= oexistence and this is, I believe, beyond the scope ofPAWS. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Wednesday, 01 February, 2012 09:58 To: nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introdu= ction, Conventions and Terminology, Prior Work) Nancy, all Good questions. I=92m not proposing to remove references to TVWS, they are = entirely appropriate within the use cases since it is the TV bands we are s= tudying as first candidate for opportunistic access, but the charter says w= e are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary informa= tion in this PAWS requirements I-D to enable the PAWS protocol I-D to be de= veloped. I don=92t think it=92s our job to explain different regulatory reg= imes or applications (beyond use cases) in this document, ITU and others do= this very well, and regulators tend to be well coordinated or play =91foll= ow my leader=92. Thanks for pointing out the reference to licence-exempt that I had missed i= n 4.4 - I think the meaning would be just the same with =91in a license-ex= empt TVWS environment=92 deleted from that sentence. That would be my sugge= stion. Regards Andy From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: 01 February 2012 14:48 To: Sago,AJ,Andy,COD R Cc: paws@ietf.org Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Intro= duction, Conventions and Terminology, Prior Work) Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6= =85so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain ho= w the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could change, = but, why not give the information on both for countries to understand fully what it's choices are? Thanks Andy, just some early morning thoughts=85Sincerely, Nancy Begin forwarded message: From: Nancy Bravin > Date: February 1, 2012 6:35:09 AM PST To: Andy Sago > Cc: >, >, >, > Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Andy, All In section 4.4, license exempt is also mentioned as well. I am conflicted in a global sense when emerging countries, or countries wit= h very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby join = the existing DB companies, orwill they do their own thing leaving holes in what one hopes will be an interoperable global protocol th= at deals with TVWS, and/orWhite spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, > > wrote: Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV = white spaces, whereas the scope of PAWS is white spaces in general. I would= question not only whythelower-priority service would always be licence-exe= mpt, but why the higher priority service would always be licenced. To avoid= this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/pa= ws/current/msg00576.html) a revision of the Abstract that avoids the terms = licence exempt or unlicensed, or any mention of the regulatory status of th= e incumbent services. The Abstract derives from the Introduction and the te= xt could be aligned to be the same in the Introduction, with =93opportunist= ic=94 replacing =93secondary=94 in later sentences in the Introduction. I h= ave checked and there are no further references to licensing in the documen= t, so we don=92t need the definitions of licence exempt, light licensing or= unlicensed. This is not a regulatory document =96 we are defining requirem= ents fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum= use has now got muddled with the potential for opportunistic use. This can= be fixed by taking the white space and white space device definitions toge= ther. From Scott, Gerald and Jussi=92s comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum= , under control of a white space database. A white space device can be an = access point, base station, a portable device or similar. In this context,= a white spacedevice is required by local regulations to query a database w= ith its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of jussi= .kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; sc= ott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not= necessarily apply to all under-utilised radio spectrum. Why would the lowe= r priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext G= erald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunist= ic use of the spectrum by white space devices in the last sentence of the d= efinition of =93white space=94 as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but = is not fully occupied by that licensed use at a specific location and time.= This spectrum is then assigned allowed byl= ocal regulations for use to beused opportunisticall= y as licensed-exempt spectrum under control of a white space databa= se. This way, it is understood that the database does not =93assign=94 white sp= ace devices for them to choose from. Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional prop= osed changes to the text below based on your suggestion. "Lower priority op= portunistic service" could indeed by used, but I am guessing that we would = need some explanation of what that means. Since we now have descriptions of= licensed spectrum and license-exempt spectrum, I used these words. Do thes= e changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White= Space". Kind Regards, Scott From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott >, "paw= s@ietf.org" > Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of= =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notio= n of secondary use is included. The secondary status is used in the ITU-R = Radio Regulations for a different purpose. In fact, it is possible that a = band has already primary and secondary services allotted to it and that the= White Space operation is a tertiary opportunistic operationwhere the two f= irst types ofservices are not being used. The use of =93lower priority opp= ortunistic=94 service rather than =93secondary=94 service would be preferab= le to describe white spaceallocations. Gerald ________________________________ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt'= vs 'unlicensed' ". Here I try to propose some changes to the draft based = on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'.= I have tried to work from the perspective that the document should accurat= ely explain the subject with aim that a reader can understand the use cases= and the subsequent requirements. No doubt we could include much more text = on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if s= omething is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is th= e 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exemp= t spectrum is Typically referred to as "unlicensed" spectrum. In this document the = terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has b= een assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondary= license-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for someprimary useand assigned for licensed use, but is not fully occupied by that primary use li= censed use at a specificlocation and time. This spectrum is then assigned by location<= /Delete>local regulations for use as licensed-exempt spect= rum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard > Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' > Cc: "paws@ietf.org" > Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers =93license-exempt=94 and = =93unlicensed=94 can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As a= n example, in theITU-R context, an =93unlicensed=94 band is typically a new= band, say in the 300 GHz, for which no request has been made for its use. = It is therefore un-allocated to a specific service so far and thus it is a= n =93unlicensed=94 frequency band. Once the ITU-R allocates this band to on= e or many services on a primary or secondary basis, then the administration= s can thendecide under what king of regime it will =91assign=92 this band f= oroperation. They may decide to allow the use of the band on the basis of l= icensed operation (with different options to do the assignment: auction, fi= rst come/first served, etc.) or allow operation with an exemption of licens= es, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also = called =93unlicensed=94 in the USA. If thequalifier applies to an operation, the operation can be exempt of lic= ense by the local administration, thus a =93license-exempt=94 operation. If= , however, someone decides to start an RF transmission operation in a licen= sed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type o= f operation for which the band is exempted from a license or he operates ou= tside the technical limitsimposed by this license-exempt ruling, his operat= ion is therefore illegal and he is then considered to be running an =93unli= censed=94 operation. If the qualifier applies to the transmission device, such device may be a = =93license-exempt=94 device if its operation does not require a specific li= cense or registration with the local administration such as TV receivers of= Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a dev= ice that is not allowed in a country by, for example, buying it on eBay and= operates it, this is then an illegal device in the country and id de-facto= an =93unlicensed=94 device since it has not passed through the normal cert= ification process. Note that a =93license-exempt=94 device still has to go through a certifica= tion process and meet the limits imposed by the local regulator for the =93= license-exempt=94 operation in the given frequency band whereas an =93unlic= ensed=94 device may not pass the certification process since it has not bee= n licensed to operation in the country. This is why the qualifier =93unlicensed=94 has to be treated with care and = the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows =93lice= nsed=94 operation, the situation will be much simpler to manage since speci= fic conditions will be attached to these licenses. Gerald ________________________________ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed= " we can use to indicate that "according to each countries regulatory requi= rements" How to get around the fact that some Countries are or will be "licensed onl= y" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs= to be careful with the word=91unlicensed=92 which may mean =91illegal=92 o= peration of an RF device in many administrations. Gerald ________________________________ From: Gabor.Bajko@nokia.com [mailto:Gabor.Baj= ko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely= hear people referring to ISM band as =91license-exempt=92, in most cases t= he term =91unlicensed-band=92 is used. Therefore, may I suggest that the draft will include the following statemen= t: The terms unlicensed and license-exempt spectrum are used in this document = interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service are= a for a given time period. This is usually done through auctions (think of= the Telcos), beauty contest, first-come / first-served or by government al= location (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done throug= h first-come / first-served process for a given time frame over a relativel= y limited service area. The annual license fee is usually small to facilita= te the deployment of a service that would not normally be economically attr= active. Small local operators would be interested by this (e.g., rural bro= adband in Canada) and not big Telcos thatwould normally work with full lice= nsing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal= licensing process is needed such as in the 2.4 GHz ISM band. In the USA, t= his term is used for a specific type of operation. The FCC should be contac= ted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a freque= ncy band without a duly issued license. In the USA, this term is used to m= ean =93license-exempt," see above. To my knowledge, the term =93unlicensed=94 is used only in the USA to descr= ibe a legal operation because the term =93license-exempt=94 has been used f= or another specific purpose. Since the PAWS addresses the interface to the database for the internationa= l market, it should rely on the definition of the terms recognized by the I= TU-R. I wouldsuggest the use of =91licensed=92 and =91license-exempt=92 wit= h a footnote indicating that the term =91unlicensed=92 is used in the USA i= nstead of the usual =91license-exempt=92. Gerald _______________________________________________ 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 --_000_CB59560F1FB41peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I agree this is a business issu= e, but there is a DB potential.
I will give you some scenarios we= deal with often. A construction project requests spectrum for a time and p= lace in the future. They may only need it for a day or a month. A sporting = or cultural event  wants some spectrum next week for a day. These are = not traditional telco models but they are real scenarios and they absolutel= y need a certainty that they will get the access they have requested. We us= e a spectrum management database and coordination with a primary user to me= et these needs.   Much of the actual coordination is done manually tod= ay =96 which is time consuming and expensive.I am just pointing out that as= suming that all the world wants is the traditional telco model or an opport= unistic unlicensed white space model misses a huge opportunity for which a = database is a key component in automating this and making it realistic.

From: Nancy = Bravin <nbravin@earthlink.net>
Date: Thu, 9 Feb 2012 10= :43:15 -0500
To: Gerald Chouina= rd <gerald.chouinard@sy= mpatico.ca>
Cc: Peter St= anforth <peter@spectrumbridg= e.com>, Andy Sago <andy.sago@= bt.com>, "paws@ietf.org&qu= ot; <paws@ietf.org>, "John = A. Stine" <jstine@mitre.org= >
Subject: Re: [paws] Use ca= ses and requirements I-D: sections 1to 3 (Introduction, Conventions and Ter= minology, Prior Work)

Hi All, 

In this discussion are you not discus= sing business models and use cases such as Jon Stine suggested? That would = indicate other models that
would be useful in a global sense, and= not necessarily a Telco model. Myself, I don't see many Telco models that = feel they have enough spectrum.
 In one example was the ment= ion of the DOD or other spectrum owners who would allow WS use /sharing, as= long as they could, when needed,
use the spectrum as planned whi= ch is not often. Many times mostly unused spectrum merely says "hi&quo= t; I am here, but its use is rare. I think it is a more global forward look= ing approach,
and managed by the DB's under reg's of what ever co= untry can use this model. It makes a good business model to lay for the fut= ure of white space, as opposed
to allowing models not associated = with WSDB's at all. Whether you want it in this part of the protocol, = is another question, but it does seem to belong and further
may a= llow for more involvement globally from a business sense, using the DB's./<= /div>

My 2 cents for what it's worth.

SIncerely, Nancy


On Feb 9, 20= 12, at 6:56 AM, Gerald Chouinard wrote:

Peter,

 

I agree.  It depends on how the t= erm =91opportunistic=92 is being defined. In my view, the qualifier =91opportunistic=92 relates to the use of the spectrum by devices and not to the availability of the spectrum.  As you describe, the spectrum may be made available on a deterministic basis but its use by one device or another is opportunistic s= ince it is managed by a near real-time database.  For me, a deterministic u= se of the spectrum is an operator buying a license for a frequency band for a specific period of time such as 5 years with the possibility of extending t= his period. In this case, access to a database is not required. This is the cur= rent Telco model.

 

The model that you describe seems to b= e an opportunistic use model where not only protection of primary and secondary incumbents would be provided but also absence of interference amongst oppor= tunistic users is also provided, turning it into a temporary de-facto =91protected= =92 service over a given period of time.  This, to me, is still =91opportu= nistic=92.  It is just that all means are taken to make sure that the service is reliab= le during the given period of time.

 

If one provides a TVWS database servic= e and adds to it a coexistence service such as the 802.19.1 approach, you hav= e more or less the same result.  Such coexistence is however not mandato= ry in the TVWS and will depend on the will of the industry.<= /font>

 

Gerald

 

<= /div>

From: Pete= r Stanforth [mailto:peter@spectrumbridge.co= m]
Sent: Wednesday, = 08 February, 2012 18:48
To: Gerald Chouinar= d
Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology= , Prior Work)

 

Gerald,

It depends what how we define as opportunistic.  We run a secondary market place for spect= rum, FCC rules allow us to act as a "Spectrum Manager" in this role we= can provide secondary access to devices under whatever criteria the license hol= der deems acceptable. We are, in everything but name, providing access to white= space. In some cases this is opportunistic but in others it is very deterministic and the attraction of the spectrum is because it is deterministic. The key is the owner may not know exactly when or where they= need the spectrum in the future but when they make it available it is guaranteed to be available for the timeframe published. This would not be p= ossible without a database and yet is clearly not opportunistic. The same could be = said for current US FCC TVWS rules. If we provide a channel list and a timeframe= (Say for the next 4 hours) that channel list will remain available for the duration.  What is missing, in the case of white space, is that we can= not deny access to someone else in the same location who asks the same question= , whereas in our secondary marketplace we can. So not only is availability deterministic access is too. 

<= p class=3D"MsoNormal"><= span style=3D"font-size:10.5pt;font-family:Calibri;color:#040100">Peter S.<= o:p>

 

From: = Gerald Chouinard <gerald.chouinard@sympa= tico.ca>
Date: Wed= , 8 Feb 2012 17:46:44 -0500
To: Peter Stanforth= <peter@spectrumbridge.com>
Cc: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology= , Prior Work)

<= font size=3D"2" color=3D"#040100" face=3D"Calibri"> <= /p>

Peter,<= /p>

 <= /p>

See my other email about =91secondary=92 versus =91opportunistic=92.<= /p>

 <= /p>

I agree with you that =91primary=92, =91secondary=92, =91deterministic and =91opportunistic=92 use of the spectrum has no relevance to whether the access could be free or paid (after all the primary access to the TV bands = by the broadcasters is free for historical reasons while one coulddecide that some= TVWS access could be paid ;-)  ).

 <= /p>

Again, the reason why one needs a DB accessible over the internet is that the access to the spectrum is =91opportunistic=92.  If this was deterministic, the DB would not be needed as has been the case up to now.

 <= /p>

Gerald<= /p>

 <= /p>

From: Peter Stanforth [mailto:peter@spectrumbridge.com]
Sent: Wednesday, 08 February, 2012 12:01
To: Gerald Chouinar= d;andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject= : Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work)=

 

=

= There is= no reason to assume that use of white space is by licensed exempt or unlicensed devic= es. This comes back to an earlier argument I made about what constitutes licens= ed and unlicensed?

Again there is no reason that a license exempt or unlicensed device should get access to spec= trum for "free" any more that a licensed device has to "pay"= for spectrum access.

The concept of a primary user, who has priority over a secondary user has no relevance to fr= ee or paid access. 

The rationale fo= r white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the ot= her, and an argument can be made for both. In a band occupied by a public safety= user there may be no choice but to have opportunistic access but in other bands = a primary user may be willing to commit to specific availability if their own= use is deterministic. <= span style=3D"color:#040100">

 

Peter S.

 

From: Gerald= Chouinard <gerald.chouinard@sympa= tico.ca>
Date: Wed= , 8 Feb 2012 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology= , Prior Work)

 <= /span>

Andy,

 

To resolve Nancy=92s concern, a new definition could be added for:=

 

TVWS White Space devices: White Space devices that operate in the TV bands.<= /font>

 

This would complement the definition o= f White Space devices and make it more specific.

 

I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the White Spacedevices. The opportunistic use of the RF spectrum assumes that these devices operate while protecting existing operation in the band.  Ther= e is automatically assumes the existence of primary users of the band that have priority. Such primary users would most likely be licensed to use the band = and it is only the portions that happen to be unused that will be accessible to= the White Space devices.  The latter are unlikely to be licensed to only u= se the =91crumbs=92. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices and = then why would they need to protect these =91primary=92 licensed devices.<= /u2:p><= u1:p>

 

This would be similar to the situation= in the 2.4 GHz where a database is not needed to protect other devices. As is = well understood, the databases are there to protect primary and possibly seconda= ry licensed devices from the new opportunistic devices, not opportunistic devi= ces among themselves. The latter case would be covered by other means such as adatabase to provide coexistence and this is, I believe, beyond the scope ofPAWS.

 

Gerald

 

From: paws-bounce= s@ietf.org [mailto:paws-bounces@ietf.org]= On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject= : Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology= , Prior Work)

=  

= Nancy, all

=  

Good questions= . I=92m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are studying a= s first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your other questions, IMO our aim should be to provide all the necessary information i= n this PAWS requirements I-D to enable the PAWS protocol I-D to be developed.= I don=92t think it=92s our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this ve= ry well, and regulators tend to be well coordinated or play =91follow my leade= r=92.

 

Thanks for pointing out the reference to licence-exempt that I had missed in 4.4 -  I thin= k the meaning would be just the same with =91in a license-exempt TVWS environment=92 deleted from that sentence. That would be my suggestion.

 

Regards<= /span>

 <= /p>

Andy

=  

Fro= m: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February 2012 1= 4:48
To: Sago,AJ,Andy,COD= R
Cc: paws@ietf.org
Sub= ject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminolog= y, Prior Work)

&= nbsp;

Hi Andy, also, throughout = the document TVWS are mentioned in 4.1,4.5, 4.6=85so if you propose to remove any reference to TVWS it will affect<= /o:p>

the document as a whole, and information that seems necessary to explain how the DB and protocol interac= ts with TVWS devices and

the methods of doing so. One can envision that current rules could change, but, why not give the informa= tion on both for countries to understand fully<= o:p>

what it's choices are? =

 

Thanks Andy, just some early morning thoughts=85Sincerely, Nancy

 

Begin forwarded = message:

 

From: Nancy Bravin <nb= ravin@earthlink.net>

=

Date: February 1, 2012 6:35:09 AM PST

To: Andy Sago <andy.sago@= bt.com>

Subject: Re: [paws] Use cases and requirements I-D: secti= ons 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 

Hi Andy, All

 =

In section 4.4, license exempt is also mentioned as well. 

I am conflicted in a global sense when emerging countries, or countries with very different types of go= v't want to implement

the protocol, will they have enough information to do so? and thereby join the existing DB companies, or= will they do their own thing<= /p>

leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/orWhite spaces in general?<= /font>

 

Thanks, just a thought.=

 <= /p>

SIncerely, Nancy

<= p class=3D"MsoNormal">=  

=  <= /u2:p>

On Feb 1, 2= 012, at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> wrote:<= /span>

 

Scott, All

 

I= agree with Jussi that we have now narrowed the definition to apply to TV white spaces, where= as the scope of PAWS is white spaces in general. I would question not only why= thelower-priority service would always be licence-exempt, but why the highe= r priority service would always be licenced. To avoid this issue on 27th Jan = I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html<= /a>) a revision of the Abstract that avoids the terms licence exempt or unlicens= ed, or any mention of the regulatory status of the incumbent services. The Abst= ract derives from the Introduction and the text could be aligned to be the same = in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it simple.

White Space device

Regards

<= font size=3D"2" color=3D"#040100" face=3D"Tahoma">From: paws-bounces= @ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: = gerald.chouinard@sympatico= .ca; scott.probasco@nokia.com; paws@ietf= .org
Subject: Re: [paws] Use cases and require= ments I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work= )=

 

Tha= t statement is valid for TV White Spaces on UHF frequencies but does not necessarily apply= to all under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt?

<= /div>

 

Kind regards,

=

Jussi

<= /div>

 

White Space

<= /div>

&n= bsp;

Radio spectrum which has been allocated and assigned for licensed use, but is not fully occupied= by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> bylocal regulations <delete>for use<delete> <insert>to be= used opportunistically<insert> as licensed-exempt spectrum under control o= f a white space database.</Insert><= span style=3D"color:#040100">

 

This way, it is understood that the database does not =93assign=94 white space devices for them to choose from.

 

Gerald

From: scott.pro= basco@nokia.com [mailto:scott.probasco@= nokia.com] 
Sent: Tuesday, 31 January, 2012 15:12
To: = ;gerald.chouinard@s= ympatico.ca; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work= )=

=  

Hi Gerald,

 <= span style=3D"color:#040100">

Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descripti= ons of licensed spectrum and license-exempt spectrum, I used these words. Do th= ese changes remove your concerns?

 

I also corrected "location" to "local" in previous text proposed for "White Space".

<= /div>

 

=

Ki= nd Regards,

Scott<= /span>

 =

<= font size=3D"2" color=3D"black" face=3D"Calibri">From: ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@no= kia.com>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work)

 =

S= cott,

Great proposal.  However, I am still a bit nervous about the definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary status i= s used in the ITU-R Radio Regulations for a different purpose.  In fact,= it is possible that a band has already primary and secondary services allotted to= it and that the White Space operation is a tertiary opportunistic operationwhe= re the two first types ofservices are not being used.  The use of =93lower priority opportunistic=94 service rather than =93secondary=94 service would be preferable to describe white spaceallocations.

=

 

<= span style=3D"font-size:10.0pt;font-family:Arial;color:navy;font-weight:bol= d">Gerald

&= nbsp;

From: <= /span>paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introd= uction, Conventions and Terminology, Prior Work)<= /span>

 

Hi,<= /span>

 

= I changed the subject line from " Re: [paws] Discussion on 'license-exem= pt' vs 'unlicensed'  ". Here I try to propose some changes to the dra= ft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licen= sed' and 'license-exempt' and made changes to the term 'white space'. I have tri= ed to work from the perspective that the document should accurately explain th= e subject with aim that a reader can understand the use cases and the subsequ= ent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage.

=  

= I hope this captures the key points of the discussion. Please do reply if som= ething is still missing.

=

 

Kind Regards,

Scott

<= /div>

 

 

= 2.2.  Terminology

=

 

   Database

 

<= /div>

      In the context of white space and cognitive radio technologies= ,

=

      the database is an entity which contains current information a= bout

      available spectrum at any given location and other types of=

      information.

 

   Device ID

 

<= /div>

      A unique number for each master device and slave device that

      identifies the manufacturer, model number and serial number.

 

=

<Insert>=

   Licensed Spectrum

=

 

      Spectrum that is acquired by an operator over a given service = area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, company merger &

      acquisition,  first-come / first-served or by government allocation

<= div>

      (e.g., public service).

 

   License-exempt Spectrum

=

 

      Spectrum that is not assigned to any specific user. One exampl= e is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the USA, license-exempt spectrum is<= /p>

      Typically referred to as "unlicensed" spectrum. In t= his document the terms

      license-exempt and unlicensed are used interchangeably.=

=  

=

</Insert>

 =

   Location Based Service

<= /div>

 

      An application or device which provides data, information or

      service to a user based on their location.

 =

=   Master Device

=

 

      A device which queries the WS Database to find out the availab= le<= u2:p>

      operating channels.<= span style=3D"color:#040100">

 <= /o:p>

   Protected Entity

<= /div>

 

      <Insert>A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A licensed</Insert&g= t; user of white space spectrum <Delete>which</Delete> is afforded=

<= p class=3D"MsoNormal">=       protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white space

=       devices) for its use</Delete> in a given area and time.<= /span>

<= span style=3D"font-size:10.5pt;font-family:Calibri;color:black;font-weight:= bold"> 

   Protected Contour

=

 

      The exclusion area for a Protected Entity, held in the databas= e

=

      and expressed as a polygon with geospatial points as the verti= ces.

 

=

  Slave Device

 =

 &= nbsp;    A device which uses the spectrum made available by a master=

      device.

<= /div>

 

   TV White Space

 =

      TV white space refers specifically to radio spectrum which has=

<= p class=3D"MsoNormal">=       been allocated for TV broadcast, but is not occupied by a TV

      broadcast, or other licensed user (such as a wireless micropho= ne),

      at a specific location and time.<= /o:p>

 =

 &nb= sp; White Space

=

 <= /p>

      Radio spectrum which has been allocated <Delete>for someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but

=

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation

<= /div>

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white sp= ace database.</Insert>

 

   White Space Device (WSD)

 

     A device which is a <Delete>secondary</Delete><Insert>license-exempt</Inse= rt> user of some part of white space<= span style=3D"color:#040100">

      spectrum.  A white space device can be an access point, b= ase=

      station, a portable device or similar.  In this context, = a white

<= div>

      space device is required to query a database with its location= to=

      obtain information about available spectrum.=

 

 

 =

<= font size=3D"2" color=3D"black" face=3D"Calibri">From: ext Gerald Chouinard <g= erald.chouinard@sympatico.ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@ear= thlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

=  

=

<= st1:place w:st=3D"on">Nancy,

 <= /p>

This is not that simple.  In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to more than one thing.

 =

If the qualifier applies to a frequency band, different options exist. As an example, in the= ITU-R context, an =93unlicensed=94 band is typically a new band, say in the 300 GHz, for which no request has been made for its use.  It is therefore un-allocated to a specific service so far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrati= ons can thendecide under what king of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, f= irst come/first served, etc.) or allow operation with an exemption of licenses, = thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in the <= st1:country-region u4:st=3D"on">USA.

 

If thequalifier applies to an oper= ation, the operation can be exempt of license by the local administration, thus a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a license= d band for which he has no license or in a license-exempt band for which he d= oes not meet the requirements such as operating according to the type of operat= ion for which the band is exempted from a license or he operates outside the technical limitsimposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an =93unlicensed=94 operation.=

 

=

If the qualifier applies to the transmission device, such device may be a =93license-exempt=94 device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if someo= ne smuggles a device that is not allowed in a country by, for example, buying = it on eBay and operates it, this is then an illegal device in the country and = id de-facto an =93unlicensed=94 device since it has not passed through the normal certification process.

 

Note that a =93license-exempt=94 device still has to go through a certification process and meet the limits imposed by the local regulator fo= r the =93license-exempt=94 operation in the given frequency band whereas an =93unlicensed=94 device may not pass the certification process since it has not been licensed to operation in the country.

 

This is why the qualifier =93unlicensed=94 has to be treated with care and the footnote will need to be crafted very carefully.

 <= /o:p>

With respect to your second point, if an administration only allows =93licensed=94 operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses.=

=  =

Gerald

 

From: Nancy Bravin [mailto:nbravin@earth= link.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

Gabor and Gerald, 

Since we are deal= ing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements&quo= t;  

How to get around the fact that some Countries are or will be "licensed only" by their gov'ts?  Thanks

<= /div>

Nancy

=

On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote:=





<= div>

Gabor,

=

 

<= span style=3D"font-size:10.0pt;font-family:Arial;color:navy;font-weight:bol= d">I agree with your proposal.  Thisseems to be reasonable.  However one nee= ds to be careful with the word=91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many administrations.<= u1:p>

=  <= /b>

<= font size=3D"2" color=3D"navy" face=3D"Arial">Gerald<= font color=3D"#040100">

 =

From: <= /span>Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.ca; pa= ws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.

 =

Therefore, may I suggest that the draft will include the following statement:

 =

Th= e terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing proces= s is needed for RF devices to operate in, such as the ISM band.<= /u1:p>

 <= u1:p>

-     &nbs= p;    Gabor

 <= /o:p>

<= font size=3D"2" color=3D"black" face=3D"Tahoma">From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed'

 <= u1:p>

= All,<= /b>

<= font size=3D"2" color=3D"black" face=3D"Arial"> <= /u1:p>

Here is my understanding of the terms:

 <= /p>

Licensed: Spectrum that is acquired by an operator over a given service area for a gi= ven time period.  This is usually done through auctions (think of the Telc= os), beauty contest, first-come / first-served or by government allocation (e.g.= , public service).

<= div>

 

=

Lightly licensed: Special case where thefrequency allocation is done through first-= come / first-served process for a given time frame over a relatively limited ser= vice area. The annual license fee is usually small to facilitate the deployment = of a service that would not normally be economically attractive.  Small loc= al operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through auct= ion over large service areas.

 

<= /div>

License-exempt: Operation of RF devices in a frequency band where no formal licensing proce= ss is needed such as in the 2.4 GHz ISM band. In the = USA, this term is used for a specific type of operation. The FCC should be conta= cted to clarify it.

=  

= Unlicensed: Illegal operation of an RF device that can transmit in a frequency band wit= hout a duly issued license.  In the&n= bsp;USA, this term is used to mean =93license-exempt," see above.=

=  =

To my knowledge, the term =93unlicensed=94 is used only in the USA to describe a lega= l operation because the term =93license-exempt=94 has been used for another specific purpose.

&n= bsp;

Since the PAWS addresses the interface to the database for the international mark= et, it should rely on the definition of the terms recognized by the ITU-R. I wouldsuggest the use of =91licensed=92 and =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the USA instead of t= he usual =91license-exempt=92.

<= /div>

 

Gerald

_______________________________________________
paws mailing list
paws@ietf.org
= https://www.ietf.org= /mailman/listinfo/paws



 <= span style=3D"color:#040100">

____________________________= ___________________ paws mailing list paws@ietf.org h= ttps://www.ietf.org/mailman/listinfo/paws<= /o:p>

______________________= _________________________
paws mailing list
paws@ietf.org
= https://www.ietf.org= /mailman/listinfo/paws

<= /div>

 

=

 

=

<= /div>
--_000_CB59560F1FB41peterspectrumbridgecom_-- From nbravin@earthlink.net Thu Feb 9 08:31:19 2012 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 95AF921E801F for ; Thu, 9 Feb 2012 08:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.252 X-Spam-Level: ** X-Spam-Status: No, score=2.252 tagged_above=-999 required=5 tests=[AWL=-3.866, BAYES_40=-0.185, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_93=0.6, MIME_QP_LONG_LINE=1.396, SARE_FWDLOOK=1.666, SARE_LWHUGE=1.54] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxCnyhIdtO7Q for ; Thu, 9 Feb 2012 08:31:15 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id E3F3021F872B for ; Thu, 9 Feb 2012 08:31:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=WKnC67lP69YBPLxUpi0rD8rXoWqI55E2JJ7EAKjLwjkFnsRfc4/3Dfa6tQfvL5cJ; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RvWtl-0002WP-8P; Thu, 09 Feb 2012 11:31:10 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-4-458029302 From: Nancy Bravin In-Reply-To: Date: Thu, 9 Feb 2012 08:31:03 -0800 Message-Id: <8CB6FE65-70DE-4BB2-BF38-AFC794204E06@earthlink.net> References: To: Peter Stanforth X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86dd20be8659f3298b5a15ca197a9fd229350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: "paws@ietf.org" Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 09 Feb 2012 16:31:19 -0000 --Apple-Mail-4-458029302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks, I am not assuming that the world wants the telco model at all, I = agree, there are many out there that want other means. I have looked at the waivers from the FCC, and have seen the construction waiver to a = small company that wanted to use WS in construction of a building with a specific instrument being used, it was Granted. I am on the same page, = but I do see a need for not only the data bases, but the IEEE802 WS = groups, ITU-R, etc. to be involved as well, it is part of automating the entire system to = work. To me anyway, making the entire process more economical, more = interoperable, and at the same time each is a key component of each other business = wise.=20 Further, in threat, natural disaster,emergency situations, which can = affect any part of the whole, all become that more important in the role = that each plays. In total devastation, like the North of Japan, it was the equipment, the = backhaul, that needed replacing=85consequently, using WS standards to = DB's could have helped if such equipment was readily available and the DB's = as well. All under the control of the countries regulations of course. Sometimes this is not possible, but one can hope.=20 Sincerely, Nancy On Feb 9, 2012, at 8:07 AM, Peter Stanforth wrote: > I agree this is a business issue, but there is a DB potential. > I will give you some scenarios we deal with often. A construction = project requests spectrum for a time and place in the future. They may = only need it for a day or a month. A sporting or cultural event wants = some spectrum next week for a day. These are not traditional telco = models but they are real scenarios and they absolutely need a certainty = that they will get the access they have requested. We use a spectrum = management database and coordination with a primary user to meet these = needs. Much of the actual coordination is done manually today =96 = which is time consuming and expensive.I am just pointing out that = assuming that all the world wants is the traditional telco model or an = opportunistic unlicensed white space model misses a huge opportunity for = which a database is a key component in automating this and making it = realistic. >=20 > From: Nancy Bravin > Date: Thu, 9 Feb 2012 10:43:15 -0500 > To: Gerald Chouinard > Cc: Peter Stanforth , Andy Sago = , "paws@ietf.org" , "John A. Stine" = > Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >=20 > Hi All,=20 >=20 > In this discussion are you not discussing business models and use = cases such as Jon Stine suggested? That would indicate other models that > would be useful in a global sense, and not necessarily a Telco model. = Myself, I don't see many Telco models that feel they have enough = spectrum. > In one example was the mention of the DOD or other spectrum owners = who would allow WS use /sharing, as long as they could, when needed, > use the spectrum as planned which is not often. Many times mostly = unused spectrum merely says "hi" I am here, but its use is rare. I think = it is a more global forward looking approach, > and managed by the DB's under reg's of what ever country can use this = model. It makes a good business model to lay for the future of white = space, as opposed > to allowing models not associated with WSDB's at all. Whether you want = it in this part of the protocol, is another question, but it does seem = to belong and further > may allow for more involvement globally from a business sense, using = the DB's./ >=20 > My 2 cents for what it's worth. >=20 > SIncerely, Nancy >=20 >=20 > On Feb 9, 2012, at 6:56 AM, Gerald Chouinard wrote: >=20 >> Peter, >> =20 >> I agree. It depends on how the term =91opportunistic=92 is being = defined. In my view, the qualifier =91opportunistic=92 relates to the = use of the spectrum by devices and not to the availability of the = spectrum. As you describe, the spectrum may be made available on a = deterministic basis but its use by one device or another is = opportunistic since it is managed by a near real-time database. For me, = a deterministic use of the spectrum is an operator buying a license for = a frequency band for a specific period of time such as 5 years with the = possibility of extending this period. In this case, access to a database = is not required. This is the current Telco model. >> =20 >> The model that you describe seems to be an opportunistic use model = where not only protection of primary and secondary incumbents would be = provided but also absence of interference amongst opportunistic users is = also provided, turning it into a temporary de-facto =91protected=92 = service over a given period of time. This, to me, is still = =91opportunistic=92. It is just that all means are taken to make sure = that the service is reliable during the given period of time. >> =20 >> If one provides a TVWS database service and adds to it a coexistence = service such as the 802.19.1 approach, you have more or less the same = result. Such coexistence is however not mandatory in the TVWS and will = depend on the will of the industry. >> =20 >> Gerald >> =20 >> From: Peter Stanforth [mailto:peter@spectrumbridge.com]=20 >> Sent: Wednesday, 08 February, 2012 18:48 >> To: Gerald Chouinard >> Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Gerald, >> It depends what how we define as opportunistic. We run a secondary = market place for spectrum, FCC rules allow us to act as a "Spectrum = Manager" in this role we can provide secondary access to devices under = whatever criteria the license holder deems acceptable. We are, in = everything but name, providing access to whitespace. In some cases this = is opportunistic but in others it is very deterministic and the = attraction of the spectrum is because it is deterministic. The key is = the owner may not know exactly when or where theyneed the spectrum in = the future but when they make it available it is guaranteed to be = available for the timeframe published. This would not be possible = without a database and yet is clearly not opportunistic. The same could = be said for current US FCC TVWS rules. If we provide a channel list and = a timeframe(Say for the next 4 hours) that channel list will remain = available for the duration. What is missing, in the case of white = space, is that we cannot deny access to someone else in the same = location who asks the same question, whereas in our secondary = marketplace we can. So not only is availability deterministic access is = too.=20 >> Peter S. >> =20 >> From: Gerald Chouinard >> Date: Wed, 8 Feb 2012 17:46:44 -0500 >> To: Peter Stanforth >> Cc: "andy.sago@bt.com" , "nbravin@earthlink.net" = , "paws@ietf.org" >> Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Peter, >> =20 >> See my other email about =91secondary=92 versus =91opportunistic=92. >> =20 >> I agree with you that =91primary=92, =91secondary=92, =91deterministic = and =91opportunistic=92 use of the spectrum has no relevance to whether = the access could be free or paid (after all the primary access to the TV = bands by the broadcasters is free for historical reasons while one = coulddecide that someTVWS access could be paid ;-) ). >> =20 >> Again, the reason why one needs a DB accessible over the internet is = that the access to the spectrum is =91opportunistic=92. If this was = deterministic, the DB would not be needed as has been the case up to = now. >> =20 >> Gerald >> =20 >> From: Peter Stanforth [mailto:peter@spectrumbridge.com]=20 >> Sent: Wednesday, 08 February, 2012 12:01 >> To: Gerald Chouinard;andy.sago@bt.com; nbravin@earthlink.net; = paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> There is no reason to assume that use of white space is by licensed = exempt or unlicensed devices. This comes back to an earlier argument I = made about what constitutes licensed and unlicensed? >> Again there is no reason that a license exempt or unlicensed device = should get access to spectrum for "free" any more that a licensed device = has to "pay" for spectrum access. >> The concept of a primary user, who has priority over a secondary user = has no relevance to free or paid access.=20 >> The rationale for white space is that the spectrum is shared and that = someone has primary, preferred or priority access and the database = ensures that those rights/requirements are met by anyone who uses the = spectrum on a secondary basis. I would go further and say that the = secondary access could be deterministic or opportunistic. There is no = reason to require one or the other, and an argument can be made for = both. In a band occupied by a public safetyuser there may be no choice = but to have opportunistic access but in other bands a primary user may = be willing to commit to specific availability if their own use is = deterministic.=20 >> =20 >> Peter S. >> =20 >> From: Gerald Chouinard >> Date: Wed, 8 Feb 2012 10:20:52 -0500 >> To: "andy.sago@bt.com" , "nbravin@earthlink.net" = , "paws@ietf.org" >> Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Andy, >> =20 >> To resolve Nancy=92s concern, a new definition could be added for: >> =20 >> TVWS White Space devices: White Space devices that operate in the TV = bands. >> =20 >> This would complement the definition of White Space devices and make = it more specific. >> =20 >> I am having second thoughts about yoursuggestion to remove the = concept of classes of devices from the White Spacedevices. The = opportunistic use of the RF spectrum assumes that these devices operate = while protecting existing operation in the band. There is automatically = assumes the existence of primary users of the band that have priority. = Such primary users would most likely be licensed to use the band and it = is only the portions that happen to be unused that will be accessible to = the White Space devices. The latter are unlikely to be licensed to only = use the =91crumbs=92. Removing the concept of license-exempt could put = these new devices at the same level of priority as the primary devices = and then why would they need to protect these =91primary=92 licensed = devices. >> =20 >> This would be similar to the situation in the 2.4 GHz where a = database is not needed to protect other devices. As is well understood, = the databases are there to protect primary and possibly secondary = licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other = means such as adatabase to provide coexistence and this is, I believe, = beyond the scope ofPAWS. >> =20 >> Gerald >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of andy.sago@bt.com >> Sent: Wednesday, 01 February, 2012 09:58 >> To: nbravin@earthlink.net; paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Nancy, all >> =20 >> Good questions. I=92m not proposing to remove references to TVWS, = they are entirely appropriate within the use cases since it is the TV = bands we are studying as first candidate for opportunistic access, but = the charter says we are addressing all white space in the resulting = protocol. To answer your other questions, IMO our aim should be to = provide all the necessary information in this PAWS requirements I-D to = enable the PAWS protocol I-D to be developed. I don=92t think it=92s our = job to explain different regulatory regimes or applications (beyond use = cases) in this document, ITU and others do this very well, and = regulators tend to be well coordinated or play =91follow my leader=92. >> =20 >> Thanks for pointing out the reference to licence-exempt that I had = missed in 4.4 - I think the meaning would be just the same with =91in a = license-exempt TVWS environment=92 deleted from that sentence. That = would be my suggestion. >> =20 >> Regards >> =20 >> Andy >> =20 >> From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 >> Sent: 01 February 2012 14:48 >> To: Sago,AJ,Andy,COD R >> Cc: paws@ietf.org >> Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, = 4.6=85so if you propose to remove any reference to TVWS it will affect >> the document as a whole, and information that seems necessary to = explain how the DB and protocol interacts with TVWS devices and >> the methods of doing so. One can envision that current rules could = change, but, why not give the information on both for countries to = understand fully >> what it's choices are?=20 >> =20 >> Thanks Andy, just some early morning thoughts=85Sincerely, Nancy >> =20 >> Begin forwarded message: >> =20 >>=20 >> From: Nancy Bravin >> Date: February 1, 2012 6:35:09 AM PST >> To: Andy Sago >> Cc: , , = , >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi Andy, All >> =20 >> In section 4.4, license exempt is also mentioned as well.=20 >> I am conflicted in a global sense when emerging countries, or = countries with very different types of gov't want to implement >> the protocol, will they have enough information to do so? and thereby = join the existing DB companies, orwill they do their own thing >> leaving holes in what one hopes will be an interoperable global = protocol that deals with TVWS, and/orWhite spaces in general? >> =20 >> Thanks, just a thought. >> =20 >> SIncerely, Nancy >> =20 >> =20 >> On Feb 1, 2012, at 2:34 AM, = wrote: >> =20 >>=20 >> Scott, All >> =20 >> I agree with Jussi that we have now narrowed the definition to apply = to TV white spaces, whereas the scope of PAWS is white spaces in = general. I would question not only whythelower-priority service would = always be licence-exempt, but why the higher priority service would = always be licenced. To avoid this issue on 27th Jan I proposed = (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a = revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent = services. The Abstract derives from the Introduction and the text could = be aligned to be the same in the Introduction, with =93opportunistic=94 = replacing =93secondary=94 in later sentences in the Introduction. I have = checked and there are no further references to licensing in the = document, so we don=92t need the definitions of licence exempt, light = licensing or unlicensed. This is not a regulatory document =96 we are = defining requirements fora protocol. Keep it simple. >> =20 >> That just leaves the definition of white space, where the existing = spectrum use has now got muddled with the potential for opportunistic = use. This can be fixed by taking the white space and white space device = definitions together. =46rom Scott, Gerald and Jussi=92s comments = perhaps we could agree on: >> =20 >> White Space (WS) >> =20 >> Radio spectrum which is not fully occupied at a specific location and = time. >> =20 >> White Space device >> =20 >> A device which opportunistically uses some part of the white space = spectrum, under control of a white space database. A white space device = can be an access point, base station, a portable device or similar. In = this context, a white spacedevice is required by local regulations to = query a database with its location to obtain information about available = spectrum. >> =20 >> Regards >> =20 >> Andy >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of jussi.kahtava@nokia.com >> Sent: 01 February 2012 07:31 >> To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; = paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> That statement is valid for TV White Spaces on UHF frequencies but = does not necessarily apply to all under-utilised radio spectrum. Why = would the lower priority service by default be licence-exempt? >> =20 >> Kind regards, >> Jussi >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard >> Sent: 31 January 2012 22:33 >> To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Scott, >> =20 >> Very good improvements. I would suggest to insert the notion of = opportunistic use of the spectrum by white space devices in the last = sentence of the definition of =93white space=94 as follows: >> =20 >> White Space >> =20 >> Radio spectrum which has been allocated and assigned for licensed = use, but is not fully occupied by that licensed use at a specific = location and time. This spectrum is then assigned = allowed bylocal regulations for use = to beused opportunistically as licensed-exempt spectrum = under control of a white space database. >> =20 >> This way, it is understood that the database does not =93assign=94 = white space devices for them to choose from. >> =20 >> Gerald >> From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 >> Sent: Tuesday, 31 January, 2012 15:12 >> To: gerald.chouinard@sympatico.ca; paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi Gerald, >> =20 >> Good to avoid overloading the term "secondary". I have made = additional proposed changes to the text below based on your suggestion. = "Lower priority opportunistic service" could indeed by used, but I am = guessing that we would need some explanation of what that means. Since = we now have descriptions of licensed spectrum and license-exempt = spectrum, I used these words. Do these changes remove your concerns? >> =20 >> I also corrected "location" to "local" in previous text proposed for = "White Space". >> =20 >> Kind Regards, >> Scott >> =20 >> From: ext Gerald Chouinard >> Date: Tue, 31 Jan 2012 14:41:36 -0500 >> To: Scott , "paws@ietf.org" >> Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Scott, >> Great proposal. However, I am still a bit nervous about the = definitions of =93Protected Entity=94 and =93White Space Devices (WSD)=94 = where the notion of secondary use is included. The secondary status is = used in the ITU-R Radio Regulations for a different purpose. In fact, = it is possible that a band has already primary and secondary services = allotted to it and that the White Space operation is a tertiary = opportunistic operationwhere the two first types ofservices are not = being used. The use of =93lower priority opportunistic=94 service = rather than =93secondary=94 service would be preferable to describe = white spaceallocations. >> =20 >> Gerald >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of scott.probasco@nokia.com >> Sent: Tuesday, 31 January, 2012 13:56 >> To: paws@ietf.org >> Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work) >> =20 >> Hi, >> =20 >> I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes = to the draft based on the email discussion. >> =20 >> Below is a copy of chapter 2.2. Terminology. I have inserted new = terms for 'licensed' and 'license-exempt' and made changes to the term = 'white space'. I have tried to work from the perspective that the = document should accurately explain the subject with aim that a reader = can understand the use cases and the subsequent requirements. No doubt = we could include much more text on this topic of spectrum allocation, = assignment, licensing and usage. >> =20 >> I hope this captures the key points of the discussion. Please do = reply if something is still missing. >> =20 >> Kind Regards, >> Scott >> =20 >> =20 >> 2.2. Terminology >> =20 >> Database >> =20 >> In the context of white space and cognitive radio technologies, >> the database is an entity which contains current information = about >> available spectrum at any given location and other types of >> information. >> =20 >> Device ID >> =20 >> A unique number for each master device and slave device that >> identifies the manufacturer, model number and serial number. >> =20 >> >> Licensed Spectrum >> =20 >> Spectrum that is acquired by an operator over a given service = area >> for a given time period. This is usually done through = auctions,award >> (beauty contest), acquisition from secondary market, company = merger & >> acquisition, first-come / first-served or by government = allocation >> (e.g., public service). >> =20 >> License-exempt Spectrum >> =20 >> Spectrum that is not assigned to any specific user. One example = is the 2.4 Ghz ISM band, where RF devices >> operate without a formal licensing process. In the USA, = license-exempt spectrum is >> Typically referred to as "unlicensed" spectrum. In this = document the terms >> license-exempt and unlicensed are used interchangeably. >> =20 >> >> =20 >> Location Based Service >> =20 >> An application or device which provides data, information or >> service to a user based on their location. >> =20 >> Master Device >> =20 >> A device which queries the WS Database to find out the = available >> operating channels. >> =20 >> Protected Entity >> =20 >> A licensed user of spectrum, when the licensed spectrum = has been assigned as white space spectrum. A = primaryA licensed user of white space spectrum = which is afforded >> protection against interference by = secondarylicense-exempt white space = users (white space >> devices) for its use in a given area and time. >> =20 >> Protected Contour >> =20 >> The exclusion area for a Protected Entity, held in the database >> and expressed as a polygon with geospatial points as the = vertices. >> =20 >> Slave Device >> =20 >> A device which uses the spectrum made available by a master >> device. >> =20 >> TV White Space >> =20 >> TV white space refers specifically to radio spectrum which has >> been allocated for TV broadcast, but is not occupied by a TV >> broadcast, or other licensed user (such as a wireless = microphone), >> at a specific location and time. >> =20 >> White Space >> =20 >> Radio spectrum which has been allocated for someprimary = useand assigned for licensed use, but >> is not fully occupied by that primary = use licensed use at a specificlocation >> and time. This spectrum is then assigned by = locationlocal regulations for use as = licensed-exempt spectrum under control of a white space = database. >> =20 >> White Space Device (WSD) >> =20 >> A device which is a = secondarylicense-exempt user of some = part of white space >> spectrum. A white space device can be an access point, base >> station, a portable device or similar. In this context, a = white >> space device is required to query a database with its location = to >> obtain information about available spectrum. >> =20 >> =20 >> =20 >> From: ext Gerald Chouinard >> Date: Tue, 31 Jan 2012 10:07:30 -0500 >> To: 'Nancy Bravin' >> Cc: "paws@ietf.org" >> Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> Nancy, >> =20 >> This is not that simple. In fact, the qualifiers =93license-exempt=94 = and =93unlicensed=94 can apply to more than one thing. >> =20 >> If the qualifier applies to a frequency band, different options = exist. As an example, in theITU-R context, an =93unlicensed=94 band is = typically a new band, say in the 300 GHz, for which no request has been = made for its use. It is therefore un-allocated to a specific service so = far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R = allocates this band to one or many services on a primary or secondary = basis, then the administrations can thendecide under what king of regime = it will =91assign=92 this band foroperation. They may decide to allow = the use of the band on the basis of licensed operation (with different = options to do the assignment: auction, first come/first served, etc.) or = allow operation with an exemption of licenses, thus =93license-exempt=94su= ch as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in = the USA. >> =20 >> If thequalifier applies to an operation, the operation can be exempt = of license by the local administration, thus a =93license-exempt=94 = operation. If, however, someone decides to start an RF transmission = operation in a licensed band for which he has no license or in a = license-exempt band for which he does not meet the requirements such as = operating according to the type of operation for which the band is = exempted from a license or he operates outside the technical = limitsimposed by this license-exempt ruling, his operation is therefore = illegal and he is then considered to be running an =93unlicensed=94 = operation. >> =20 >> If the qualifier applies to the transmission device, such device may = be a =93license-exempt=94 device if its operation does not require a = specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if = someone smuggles a device that is not allowed in a country by, for = example, buying it on eBay and operates it, this is then an illegal = device in the country and id de-facto an =93unlicensed=94 device since = it has not passed through the normal certification process. >> =20 >> Note that a =93license-exempt=94 device still has to go through a = certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band = whereas an =93unlicensed=94 device may not pass the certification = process since it has not been licensed to operation in the country. >> =20 >> This is why the qualifier =93unlicensed=94 has to be treated with = care and the footnote will need to be crafted very carefully. >> =20 >> With respect to your second point, if an administration only allows = =93licensed=94 operation, the situation will be much simpler to manage = since specific conditions will be attached to these licenses. >> =20 >> Gerald >> =20 >> From: Nancy Bravin [mailto:nbravin@earthlink.net]=20 >> Sent: Tuesday, 31 January, 2012 06:33 >> To: Gerald Chouinard >> Cc: Gabor.Bajko@nokia.com; paws@ietf.org >> Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> Gabor and Gerald,=20 >> Since we are dealing on a global basis, can there a footnote to = "unlicensed" we can use to indicate that "according to each countries = regulatory requirements" =20 >> How to get around the fact that some Countries are or will be = "licensed only" by their gov'ts? Thanks >> Nancy >> On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: >>=20 >>=20 >>=20 >>=20 >>=20 >> Gabor, >> =20 >> I agree with your proposal. Thisseems to be reasonable. However one = needs to be careful with the word=91unlicensed=92 which may mean = =91illegal=92 operation of an RF device in many administrations. >> =20 >> Gerald >> =20 >> From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com]=20 >> Sent: Monday, 30 January, 2012 17:49 >> To: gerald.chouinard@sympatico.ca; paws@ietf.org >> Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> These look to be very precise definitions, however in everyday use I = rarely hear people referring to ISM band as =91license-exempt=92, in = most cases the term =91unlicensed-band=92 is used. >> =20 >> Therefore, may I suggest that the draft will include the following = statement: >> =20 >> The terms unlicensed and license-exempt spectrum are used in this = document interchangeably and refer to a spectrum in which no formal = licensing process is needed for RF devices to operate in, such as the = ISM band. >> =20 >> - Gabor >> =20 >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of ext Gerald Chouinard >> Sent: Monday, January 30, 2012 12:30 PM >> To: paws@ietf.org >> Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' >> =20 >> All, >> =20 >> Here is my understanding of the terms: >> =20 >> Licensed: Spectrum that is acquired by an operator over a given = service area for a given time period. This is usually done through = auctions (think of the Telcos), beauty contest, first-come / = first-served or by government allocation (e.g., public service). >> =20 >> Lightly licensed: Special case where thefrequency allocation is done = through first-come / first-served process for a given time frame over a = relatively limited service area. The annual license fee is usually small = to facilitate the deployment of a service that would not normally be = economically attractive. Small local operators would be interested by = this (e.g., rural broadband in Canada) and not big Telcos thatwould = normally work with full licensing through auction over large service = areas. >> =20 >> License-exempt: Operation of RF devices in a frequency band where no = formal licensing process is needed such as in the 2.4 GHz ISM band. In = the USA, this term is used for a specific type of operation. The FCC = should be contacted to clarify it. >> =20 >> Unlicensed: Illegal operation of an RF device that can transmit in a = frequency band without a duly issued license. In the USA, this term is = used to mean =93license-exempt," see above. >> =20 >> To my knowledge, the term =93unlicensed=94 is used only in the USA to = describe a legal operation because the term =93license-exempt=94 has = been used for another specific purpose. >> =20 >> Since the PAWS addresses the interface to the database for the = international market, it should rely on the definition of the terms = recognized by the ITU-R. I wouldsuggest the use of =91licensed=92 and = =91license-exempt=92 with a footnote indicating that the term = =91unlicensed=92 is used in the USA instead of the usual = =91license-exempt=92. >> =20 >> Gerald >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >>=20 >>=20 >>=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 >> =20 >> =20 >=20 --Apple-Mail-4-458029302 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
From: = Nancy Bravin <nbravin@earthlink.net>
Date: Thu, 9 Feb 2012 10:43:15 = -0500
To: Gerald Chouinard = <gerald.chouinard@sympatico.c= a>
Cc: Peter = Stanforth <peter@spectrumbridge.com>,= Andy Sago <andy.sago@bt.com>, "paws@ietf.org" <paws@ietf.org>, "John A. Stine" = <jstine@mitre.org>
Subject: Re: [paws] Use cases and = requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

Hi = All, 

In this discussion are you not discussing = business models and use cases such as Jon Stine suggested? That would = indicate other models that
would be useful in a global sense, = and not necessarily a Telco model. Myself, I don't see many Telco models = that feel they have enough spectrum.
 In one example was = the mention of the DOD or other spectrum owners who would allow WS use = /sharing, as long as they could, when needed,
use the spectrum = as planned which is not often. Many times mostly unused spectrum merely = says "hi" I am here, but its use is rare. I think it is a more global = forward looking approach,
and managed by the DB's under reg's = of what ever country can use this model. It makes a good business model = to lay for the future of white space, as opposed
to allowing = models not associated with WSDB's at all. Whether you want it in = this part of the protocol, is another question, but it does seem to = belong and further
may allow for more involvement globally = from a business sense, using the DB's./

My 2 = cents for what it's worth.

SIncerely, = Nancy


On Feb 9, 2012, at 6:56 AM, = Gerald Chouinard wrote:

Peter,
=
 
=
I agree.  It depends on how = the term =91opportunistic=92 is being defined. In my view, the qualifier =91opportunistic=92 relates to the use of the spectrum by devices and not to the availability of the spectrum.  As you describe, the spectrum may be made available on a deterministic basis but its use by one device or another is = opportunistic since it is managed by a near real-time database.  For me, a = deterministic use of the spectrum is an operator buying a license for a frequency band for = a specific period of time such as 5 years with the possibility of = extending this period. In this case, access to a database is not required. This is the = current Telco model.
 
=
The model that you describe seems = to be an opportunistic use model where not only protection of primary and = secondary incumbents would be provided but also absence of interference amongst = opportunistic users is also provided, turning it into a temporary de-facto =91protected=92= service over a given period of time.  This, to me, is still = =91opportunistic=92.  It is just that all means are taken to make sure that the service is = reliable during the given period of time.
 
=
If one provides a TVWS database = service and adds to it a coexistence service such as the 802.19.1 approach, you = have more or less the same result.  Such coexistence is however not = mandatory in the TVWS and will depend on the will of the = industry.
 
=
Gerald
=
 
=
From: Peter Stanforth [mailto:peter@spectrumbridge.com]
Sent: Wednesday, = 08 February, 2012 18:48
To: Gerald = Chouinard
Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
Gerald,<= /o:p>
It depends = what how we define as opportunistic.  We run a secondary market place for = spectrum, FCC rules allow us to act as a "Spectrum Manager" in this role we can provide secondary access to devices under whatever criteria the license = holder deems acceptable. We are, in everything but name, providing access to = whitespace. In some cases this is opportunistic but in others it is very deterministic and the attraction of the spectrum is because it is deterministic. The key is the owner may not know exactly when or where = theyneed the spectrum in the future but when they make it available it = is guaranteed to be available for the timeframe published. This would not = be possible without a database and yet is clearly not opportunistic. The same could = be said for current US FCC TVWS rules. If we provide a channel list and a = timeframe(Say for the next 4 hours) that channel list will remain = available for the duration.  What is missing, in the case of white space, is that we = cannot deny access to someone else in the same location who asks the same = question, whereas in our secondary marketplace we can. So not only is availability deterministic access is = too. 
Peter = S.
 
From: Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Wed, 8 = Feb 2012 17:46:44 -0500
To: Peter = Stanforth <peter@spectrumbridge.com><= br>Cc: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)
 
Peter,
 
See my other email about =91secondary=92 versus =91opportunistic=92.
 
I agree with you that =91primary=92, =91secondary=92, =91deterministic and =91opportunistic=92 use of the spectrum has no relevance to whether the access could be free or paid (after all the primary access to the TV = bands by the broadcasters is free for historical reasons while one coulddecide that = someTVWS access could be paid ;-)  = ).
 
Again, the reason why one needs a = DB accessible over the internet is that the access to the spectrum is =91opportunistic=92.  If this was deterministic, the DB would not be needed as has been the case up to = now.
 
Gerald
 
From: Peter Stanforth [mailto:peter@spectrumbridge.com]
Sent: Wednesday, = 08 February, 2012 12:01
To: Gerald = Chouinard;andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior = Work)
 
There is no = reason to assume that use of white space is by licensed exempt or unlicensed = devices. This comes back to an earlier argument I made about what constitutes = licensed and unlicensed?
Again there = is no reason that a license exempt or unlicensed device should get access to = spectrum for "free" any more that a licensed device has to "pay" for spectrum access.
The concept = of a primary user, who has priority over a secondary user has no relevance to = free or paid access. 
The = rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a = secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the = other, and an argument can be made for both. In a band occupied by a public = safetyuser there may be no choice but to have opportunistic access but in other = bands a primary user may be willing to commit to specific availability if their = own use is deterministic. 
 <= /u1:p>
Peter = S.
 <= /u1:p>
From: Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Wed, 8 = Feb 2012 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" <nbravin@earthlink.net>, "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)
 <= /u1:p>
Andy,
 
To resolve Nancy=92s concern, a new definition could be added = for:
 
TVWS White Space devices: White = Space devices that operate in the TV bands.
 
This would complement the = definition of White Space devices and make it more = specific.
 
I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the = White Spacedevices. The opportunistic use of the RF spectrum assumes that = these devices operate while protecting existing operation in the band.  = There is automatically assumes the existence of primary users of the band that = have priority. Such primary users would most likely be licensed to use the = band and it is only the portions that happen to be unused that will be accessible = to the White Space devices.  The latter are unlikely to be licensed to = only use the =91crumbs=92. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices = and then why would they need to protect these =91primary=92 licensed = devices.
 
This would be similar to the = situation in the 2.4 GHz where a database is not needed to protect other devices. As = is well understood, the databases are there to protect primary and possibly = secondary licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other means such = as adatabase to provide coexistence and this is, I believe, beyond the = scope ofPAWS.
 
Gerald
 
<= div class=3D"MsoNormal" align=3D"center" style=3D"text-align:center">
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)
=
 <= o:p>
Nancy<= /font>, all
 <= /u2:p>
Good = questions. I=92m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are = studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary = information in this PAWS requirements I-D to enable the PAWS protocol I-D to be = developed. I don=92t think it=92s our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this = very well, and regulators tend to be well coordinated or play =91follow my = leader=92.
 <= /u2:p>
Thanks for = pointing out the reference to licence-exempt that I had missed in 4.4 -  I = think the meaning would be just the same with =91in a license-exempt TVWS environment=92 deleted from that sentence. That would be my = suggestion.
 <= /u2:p>
Regards=
 <= /u2:p>
Andy
 <= /u2:p>
<= div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt = 0pt 0pt 0pt">
From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February = 2012 14:48
To: = Sago,AJ,Andy,COD R
Cc: = paws@ietf.org
Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)
=
 <= /u1:p>
Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6=85so if you propose to = remove any reference to TVWS it will = affect
the = document as a whole, and information that seems necessary to explain how the DB and protocol = interacts with TVWS devices = and
the methods of doing so. One can envision that current rules could change, but, why not give the = information on both for countries to understand = fully
<= div class=3D"MsoNormal">what it's choices = are? 
<= div>
 <= /u1:p>
Thanks Andy, just some early morning thoughts=85Sincerely, Nancy
=
 <= /u1:p>
Begin forwarded = message:

 <= /u1:p>

From: Nancy Bravin <nbravin@earthlink.net>=
Date: February 1, 2012 6:35:09 AM PST
To: Andy Sago <andy.sago@bt.com>
Subject: Re: [paws] Use cases and requirements I-D: = sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 <= /u1:p>
Hi Andy, = All
 <= /u1:p>
In section 4.4, license exempt is also mentioned as = well. 
=
I am conflicted in a global sense when emerging countries, or countries with very different types of = gov't want to = implement
the protocol, will they have enough information to do so? and thereby join the existing DB companies, = orwill they do their own = thing
<= div class=3D"MsoNormal">leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/orWhite spaces in = general?
 <= /u1:p>
Thanks, just a = thought.
 <= /u1:p>
SIncerely, Nancy
 <= /u1:p>
 <= /u1:p>
On = Feb 1, 2012, at 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

 <= /u1:p>

Scott, = All
 =
I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only = whythelower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th = Jan I proposed (h= ttp://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with =93opportunistic=94 replacing =93secondary=94 in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don=92t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document =96 we are defining requirements fora protocol. Keep it simple.
 =
That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  =46rom Scott, = Gerald and Jussi=92s comments perhaps we could agree on:
 =
White Space = (WS)
 
Radio = spectrum which is not fully occupied at a specific location and = time.
 
White Space = device
 
A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white spacedevice is required by local regulations to query a database with = its location to obtain information about available = spectrum.
 =
Regards
 =
Andy
 =
From: <= /font>paws-bounces@ietf.org [mailto:paws-bounces@ie= tf.org] On Behalf Of jussi.kahtava@nokia.com
= Sent: 01 February 2012 = 07:31
To: gerald.chouinard@sympatico.c= a; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 <= /u1:p>
That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?
 =
Kind = regards,
Jussi<= /font>
 =
From: <= /font>paws-bounces@ietf.org [mailto:paws-bounces@ie= tf.org] On Behalf Of ext= Gerald Chouinard
Sent: 31 January 2012 = 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 <= /u1:p>
Scott,
 
Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of =93white space=94 as = follows:
 
White = Space
 
Radio = spectrum which has been allocated and assigned for licensed use, but is not fully = occupied by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> bylocal regulations <delete>for use<delete> <insert>to = beused opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>
 
This way, it is understood that the database does not =93assign=94 white space devices for them to choose from.
 
Gerald
From: <= /font>scott.probasco@nokia.com [mailto:scott.probas= co@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 
Hi = Gerald,
 
Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?
 
I also = corrected "location" to "local" in previous text proposed for "White Space".
 
Kind = Regards,
Scott
 
From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>,= "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)
 
S= cott,
G= reat proposal.  However, I am still a bit nervous about the definitions = of =93Protected Entity=94 and =93White Space Devices (WSD)=94 where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In = fact, it is possible that a band has already primary and secondary services allotted = to it and that the White Space operation is a tertiary opportunistic = operationwhere the two first types ofservices are not being used.  The use of =93lower priority opportunistic=94 service rather than =93secondary=94 service would be preferable to describe white spaceallocations.
&= nbsp;
G= erald
&= nbsp;
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work)
 
Hi,
 
I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the draft based on the email discussion.
 
Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.
 
I hope this captures the key points of the discussion. Please do reply if = something is still missing.
 
Kind Regards,
Scott
 
 
2.2.  Terminology
 
   Database
 
      In the context of white space and cognitive radio = technologies,
      the database is an entity which contains current = information about
      available spectrum at any given location and other types = of
      information.
 
   Device ID
 
      A unique number for each master device and slave device = that
      identifies the manufacturer, model number and serial = number.
 
<Insert>
   Licensed Spectrum
 
      Spectrum that is acquired by an operator over a given = service area
      for a given time period.  This is usually done through auctions,award
      (beauty contest), acquisition from secondary market, = company merger &
      acquisition,  first-come / first-served or by = government allocation
      (e.g., public service).
 
   License-exempt Spectrum
 
      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices
      operate without a formal licensing process. In the USA, license-exempt spectrum is
      Typically referred to as "unlicensed" spectrum. In this document the terms
      license-exempt and unlicensed are used = interchangeably.
 
</Insert>
 
   Location Based Service
 
      An application or device which provides data, information = or
      service to a user based on their = location.
 
  Master Device
 
      A device which queries the WS Database to find out the = available
      operating channels.
 
   Protected Entity
 
      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded
      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space
      devices) for its use</Delete> in a given area and = time.
 
   Protected Contour
 
      The exclusion area for a Protected Entity, held in the = database
      and expressed as a polygon with geospatial points as the = vertices.
 
  Slave Device
 
      A device which uses the spectrum made available by a = master
      device.
 
   TV White Space
 
      TV white space refers specifically to radio spectrum which = has
      been allocated for TV broadcast, but is not occupied by a = TV
      broadcast, or other licensed user (such as a wireless = microphone),
      at a specific location and time.
 
   White Space
 
      Radio spectrum which has been allocated <Delete>for someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but
      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation
      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>
 
   White Space Device (WSD)
 
     A device which is a = <Delete>secondary</Delete><Insert>license-exempt</Ins= ert> user of some part of white space
      spectrum.  A white space device can be an access = point, base
      station, a portable device or similar.  In this = context, a white
      space device is required to query a database with its = location to
      obtain information about available = spectrum.
 
 
 
From: ext Gerald Chouinard <gerald.chouinard@sympatico.c= a>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
N= ancy,
&= nbsp;
T= his is not that simple.  In fact, the qualifiers =93license-exempt=94 and =93unlicensed=94 can apply to more than one = thing.
&= nbsp;
I= f the qualifier applies to a frequency band, different options exist. As an example, in = theITU-R context, an =93unlicensed=94 band is typically a new band, say = in the 300 GHz, for which no request has been made for its use.  It is therefore un-allocated to a specific service so far and thus it is an =93unlicensed=94 frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will =91assign=92 this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus =93license-exempt=94such as in the 2.4 GHz ISM band. This is also called =93unlicensed=94 in the USA.
&= nbsp;
I= f thequalifier applies to an operation, the operation can be exempt of = license by the local administration, thus a =93license-exempt=94 operation. If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limitsimposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an =93unlicensed=94 operation.
&= nbsp;
I= f the qualifier applies to the transmission device, such device may be a =93license-exempt=94 device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an =93unlicensed=94 device since it has not passed through the normal certification process.
&= nbsp;
N= ote that a =93license-exempt=94 device still has to go through a certification process and meet the limits imposed by the local regulator = for the =93license-exempt=94 operation in the given frequency band whereas an =93unlicensed=94 device may not pass the certification process since it has not been licensed to operation in the = country.
&= nbsp;
T= his is why the qualifier =93unlicensed=94 has to be treated with care and the footnote will need to be crafted very carefully.
&= nbsp;
W= ith respect to your second point, if an administration only allows =93licensed=94 operation, the situation will be much simpler to manage since specific conditions will be attached to these = licenses.
&= nbsp;
G= erald
&= nbsp;
From: Nancy Bravin [mailto:nbravin@earthlink.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
Gabor and = Gerald, 
Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" =  
How to get = around the fact that some Countries are or will be "licensed only" by their gov'ts?  Thanks
Nancy
On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:





G= abor,
&= nbsp;
I= agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word=91unlicensed=92 which may mean =91illegal=92 operation of an RF device in many = administrations.
&= nbsp;
G= erald
&= nbsp;
From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.c= a; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as =91license-exempt=92, in most cases the term =91unlicensed-band=92 is used.
 
Therefore, may I suggest that the draft will include the following = statement:
 
The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.
 

-=       =     Gabor

 
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'
 
= All,
=  
H= ere is my understanding of the terms:
&= nbsp;
L= icensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).
&= nbsp;
L= ightly licensed: Special case where thefrequency allocation is done through = first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through = auction over large service areas.
&= nbsp;
L= icense-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.
&= nbsp;
U= nlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, this term is used to mean =93license-exempt," see = above.
&= nbsp;
T= o my knowledge, the term =93unlicensed=94 is used only in the USA to describe a = legal operation because the term =93license-exempt=94 has been used for another specific purpose.
&= nbsp;
S= ince the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I wouldsuggest the use of =91licensed=92 and =91license-exempt=92 with a footnote indicating that the term =91unlicensed=92 is used in the USA instead of the usual =91license-exempt=92.
&= nbsp;
G= erald

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws



 
_______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/m= ailman/listinfo/paws
___________= ____________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/m= ailman/listinfo/paws
=
 <= /u1:p>
 <= /u1:p>


= --Apple-Mail-4-458029302-- From Basavaraj.Patil@nokia.com Thu Feb 9 09:01:13 2012 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 556E721E8036 for ; Thu, 9 Feb 2012 09:01:13 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP+E0Vd8ZvOp for ; Thu, 9 Feb 2012 09:01:12 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE8E21E8026 for ; Thu, 9 Feb 2012 09:01:11 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q19H19tm029115 for ; Thu, 9 Feb 2012 19:01:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 19:01:09 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Thu, 9 Feb 2012 18:01:08 +0100 From: To: , Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAIRosAgABTb4A= Date: Thu, 9 Feb 2012 17:01:08 +0000 Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601DF0E1D@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [173.74.226.51] Content-Type: text/plain; charset="utf-8" Content-ID: <33B984746B60EC419F97B629AA9A7E11@mgd.nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2012 17:01:09.0312 (UTC) FILETIME=[6B72D400:01CCE74C] X-Nokia-AV: Clean Subject: Re: [paws] Threat model (Rev 3) 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, 09 Feb 2012 17:01:13 -0000 DQpPa2F5LiBJdCBzb3VuZHMgYmV0dGVyLg0KUmV2aXNlZCB0ZXh0IGlzIGFzIGZvbGxvd3M6DQoN ClRocmVhdCA3OiBNYWxpY2lvdXMgaW5kaXZpZHVhbCBhY3RzIGFzIGEgUEFXUyBlbnRpdHkgKHNw b29maW5nIERCIG9yDQogICAgICAgYXMgTWlNKSB0byB0ZXJtaW5hdGUgb3IgdW5mYWlybHkgbGlt aXQgc3BlY3RydW0gYWNjZXNzIG9mIGRldmljZXMNCmZvcg0KICAgICAgIHJlYXNvbnMgb3RoZXIg dGhhbiBpbmN1bWJlbnQgcHJvdGVjdGlvbg0KDQogICAgICAgQSB3aGl0ZSBzcGFjZSBkYXRhYmFz ZSBNQVkgaW5jbHVkZSBhIG1lY2hhbmlzbSBieSB3aGljaCBzZXJ2aWNlDQogICAgICAgYW5kIGNo YW5uZWxzIGFsbG9jYXRlZCB0byBhIG1hc3RlciBkZXZpY2UgY2FuIGJlIHJldm9rZWQgYnkNCiAg ICAgICBzZW5kaW5nIGFuIHVuc29saWNpdGVkIG1lc3NhZ2UuIEEgbWFsaWNpb3VzIG5vZGUgY2Fu IHByZXRlbmQgdG8NCiAgICAgICBiZSB0aGUgd2hpdGUgc3BhY2UgZGF0YWJhc2Ugd2l0aCB3aGlj aCBhIG1hc3RlciBkZXZpY2UgaGFzDQogICAgICAgcmVnaXN0ZXJlZCBvciBvYnRhaW5lZCBjaGFu bmVsIGluZm9ybWF0aW9uIGZyb20gYW5kIHNlbmQgYQ0KICAgICAgIHJldm9rZSBtZXNzYWdlIHRv IHRoYXQgZGV2aWNlLiBUaGlzIHJlc3VsdHMgaW4gZGVuaWFsIG9mDQogICAgICAgc2VydmljZSB0 byB0aGUgbWFzdGVyIGRldmljZS4NCg0KDQotUmFqDQoNCk9uIDIvOS8xMiAxMjowMiBBTSwgImV4 dCBHYWJvci5CYWprb0Bub2tpYS5jb20iIDxHYWJvci5CYWprb0Bub2tpYS5jb20+DQp3cm90ZToN Cg0KPlRoaXMgaXMgYSBnb29kIHBvaW50LiBCdXQgZnJvbSB0aGUgbGlzdCBwcm92aWRlZCBiZWxv dywgb25seSBkKSBzZWVtcyB0bw0KPmJlIGEgc2VjdXJpdHkgcmVsYXRlZCB0aHJlYXQgZml0IHRv IGJlIGluY2x1ZGVkIGludG8gdGhlIHNlY3VyaXR5DQo+Y29uc2lkZXJhdGlvbnMgc2VjdGlvbiBv ZiB0aGUgZHJhZnQuIFRoZSBvdGhlciBldmVudHMgbG9vayBvdGhlciB0aGFuDQo+c2VjdXJpdHkg cmVsYXRlZCB0byBtZS4NCj4NCj5JZiB3ZSByZXBsYWNlIFRocmVhdCA3IHdpdGggdGhlIHRleHQg aW4gcG9pbnQgZCkgYmVsb3csIEkgdGhpbmsgd2UNCj5hZGRyZXNzIFBhdWwncyBwb2ludC4NCj4N Cj5zLyBUaHJlYXQgNzogVGVybWluYXRpb24gb2YgZGV2aWNlIHNlcnZpY2UgZm9yIHJlYXNvbnMg b3RoZXIgdGhhbg0KPmluY3VtYmVudCBwcm90ZWN0aW9uLi8gVGhyZWF0IDc6IE1hbGljaW91cyBp bmRpdmlkdWFsIGFjdHMgYXMgYSBQQVdTDQo+ZW50aXR5IChzcG9vZmluZyBEQiBvciBhcyBNaU0p IHRvIHRlcm1pbmF0ZSBvciB1bmZhaXJseSBsaW1pdCBzcGVjdHJ1bQ0KPmFjY2VzcyBvZiBkZXZp Y2VzIGZvciByZWFzb25zIG90aGVyIHRoYW4gaW5jdW1iZW50IHByb3RlY3Rpb24uDQo+DQo+LSBH YWJvcg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogcGF3cy1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj5l eHQgUGF1bCBMYW1iZXJ0DQo+U2VudDogRnJpZGF5LCBGZWJydWFyeSAwMywgMjAxMiAyOjU4IFBN DQo+VG86IFBhdGlsIEJhc2F2YXJhaiAoTm9raWEtQ0lDL0RhbGxhcyk7IGptaEBqb2VsaGFscGVy bi5jb207DQo+QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXoNCj5DYzogcGF3c0BpZXRmLm9yZw0KPlN1 YmplY3Q6IFJlOiBbcGF3c10gVGhyZWF0IG1vZGVsIChSZXYgMykNCj4NCj4NCj5IaSBSYWosDQo+ DQo+Rmlyc3QgLSBhIHRocmVhdCBuZWVkcyBhbiBhY3RvciBvciBzb3VyY2UuICBXZSBzZWVtIHRv IGhhdmUgZGlmZmVyZW50DQo+dmlld3Mgb2YgcG9zc2libGUgc291cmNlcy4NCj4NCj4+Pj4+PiBU aHJlYXQgNzogVGVybWluYXRpb24gb2YgZGV2aWNlIHNlcnZpY2UgZm9yIHJlYXNvbnMgb3RoZXIg dGhhbg0KPj4+Pj4+ICAgICAgICAgaW5jdW1iZW50IHByb3RlY3Rpb24NCj5UZXJtaW5hdGlvbiBv ZiBkZXZpY2Ugc2VydmljZSBpcyB0aGUgZW5kLWltcGFjdCAoYSB1c2VmdWwgc3RhcnRpbmcgcG9p bnQsDQo+YnV0IG5vdCBleGFjdGx5IHRoZSB0aHJlYXQpLg0KPg0KPg0KPlNvbWUgb2YgdGhlIGFz c29jaWF0ZWQgdGhyZWF0IGV2ZW50cyBhcmU6DQo+DQo+IGEpIEdvdmVybm1lbnQgKHJlbGF0ZWQg dG8gcmVndWxhdG9yeSBhdXRob3JpdHkgb3Igbm90KSB1c2VzIFdTIERhdGFiYXNlDQo+dG8gdGVy bWluYXRlIG9yIHVuZmFpcmx5IGxpbWl0DQo+ICAgIHNwZWN0cnVtIGFjY2VzcyBvZiBkZXZpY2Vz IGZvciByZWFzb25zIG90aGVyIHRoYW4gaW5jdW1iZW50DQo+cHJvdGVjdGlvbi4NCj4gYikgU2Vy dmljZSBwcm92aWRlciBvciBEQiBwcm92aWRlciB1c2VzIFdTIERhdGFiYXNlIHRvIHRlcm1pbmF0 ZSBvcg0KPnVuZmFpcmx5IGxpbWl0DQo+ICAgIHNwZWN0cnVtIGFjY2VzcyBvZiBkZXZpY2VzIGZv ciByZWFzb25zIG90aGVyIHRoYW4gaW5jdW1iZW50DQo+cHJvdGVjdGlvbi4NCj4gYykgT3duZXIg b2YgYSBNYXN0ZXIgZGV2aWNlIHVzZXMgV1MgRGF0YWJhc2UgdG8gdGVybWluYXRlIG9yIHVuZmFp cmx5DQo+bGltaXQNCj4gICAgc3BlY3RydW0gYWNjZXNzIG9mIGRldmljZXMgZm9yIHJlYXNvbnMg b3RoZXIgdGhhbiBpbmN1bWJlbnQNCj5wcm90ZWN0aW9uLg0KPiBkKSBNYWxpY2lvdXMgaW5kaXZp ZHVhbCBhY3RzIGFzIGEgUEFXUyBlbnRpdHkgKHNwb29maW5nIERCIG9yIGFzIE1pTSkgdG8NCj50 ZXJtaW5hdGUgb3IgdW5mYWlybHkgbGltaXQNCj4gICAgc3BlY3RydW0gYWNjZXNzIG9mIGRldmlj ZXMgZm9yIHJlYXNvbnMgb3RoZXIgdGhhbiBpbmN1bWJlbnQgcHJvdGVjdGlvbg0KPiBlKSBOYXR1 cmFsIGRpc2FzdGVyIGtub2NrcyBvdXQgY29tbXVuaWNhdGlvbnMgdG8gdGhlIGRhdGFiYXNlIHBy ZXZlbnRpbmcNCj5zcGVjdHJ1bSBhY2Nlc3MuDQo+DQo+DQo+SXQgc2VlbXMgc2lsbHkgZm9yIHVz IHRvIHJ1c2ggc28gcXVpY2tseSBpbnRvIGJ1aWxkaW5nIHRoZSBmYXN0ZXN0DQo+cG9zc2libGUg a2lsbCBzd2l0Y2ggZm9yIGNvbW11bmljYXRpb25zLiAgUHVzaCBub3RpZmljYXRpb25zIGFyZSBh IGNvb2wNCj5tZWNoYW5pc21zLCBidXQgd2UgYWxzbyBuZWVkIHNvbWUgbGV2ZWwgb2YgYXNzdXJh bmNlIHRoYXQgd2Ugd2lsbCBoYXZlDQo+Y29udGludWl0eSBvZiB1c2FnZSBvZiBhIHNldCBvZiBj aGFubmVscy4gIElkZWFsbHkgd2UnZCBoYXZlIHNvbWUgbG9vc2VyDQo+bGltaXRzIG9uIHRoZSBv bi1jaGFubmVsIHRpbWVzLg0KPg0KPlBhdWwNCj4NCj4NCj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+RnJvbTogQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNvbSBbbWFpbHRvOkJhc2F2 YXJhai5QYXRpbEBub2tpYS5jb21dDQo+PlNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDMsIDIwMTIg MjozNSBQTQ0KPj5UbzogUGF1bCBMYW1iZXJ0OyBqbWhAam9lbGhhbHBlcm4uY29tOyBCcmlhbi5S b3NlbkBuZXVzdGFyLmJpeg0KPj5DYzogcGF3c0BpZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogW3Bh d3NdIFRocmVhdCBtb2RlbCAoUmV2IDMpDQo+Pg0KPj4NCj4+SGkgUGF1bC4NCj4+DQo+Pk9uIDIv My8xMiA0OjI2IFBNLCAiZXh0IFBhdWwgTGFtYmVydCIgPHBhdWxAbWFydmVsbC5jb20+IHdyb3Rl Og0KPj4NCj4+Pg0KPj4+Pj4+IFRocmVhdCA3OiBUZXJtaW5hdGlvbiBvZiBkZXZpY2Ugc2Vydmlj ZSBmb3IgcmVhc29ucyBvdGhlciB0aGFuDQo+Pj4+Pj4gICAgICAgICBpbmN1bWJlbnQgcHJvdGVj dGlvbg0KPj4+Pj4+DQo+Pj4+Pj4gICAgICAgICBBIHdoaXRlIHNwYWNlIGRhdGFiYXNlIG1heSBp bmNsdWRlIGEgbWVjaGFuaXNtIGJ5IHdoaWNoDQo+Pj4+Pj5zZXJ2aWNlDQo+Pj4+Pj4gICAgICAg ICBhbmQgY2hhbm5lbHMgYWxsb2NhdGVkIHRvIGEgbWFzdGVyIGRldmljZSBjYW4gYmUgcmV2b2tl ZC4gQQ0KPj4+Pj4+ICAgICAgICAgbWFsaWNpb3VzIG5vZGUgY2FuIHNlbmQgYSByZXZva2UgbWVz c2FnZSB0byBhIG1hc3Rlcg0KPj4+Pj4+ICAgICAgICAgZGV2aWNlLiBUaGlzIHJlc3VsdHMgaW4g ZGVuaWFsIG9mIHNlcnZpY2UgdG8gdGhlIG1hc3Rlcg0KPj4+Pj4+ICAgICAgICAgZGV2aWNlLg0K Pj4+DQo+Pj5ObyBjbHVlIHdoYXQgeW91IG1lYW4gYnkgIm1hbGljaW91cyBub2RlIiAuLi4gdGhp cyBjb3VsZCBiZSBhDQo+Pj5EYXRhYmFzZSwgTWFzdGVyLCByYW5kb20gTWlNLCBldGMuDQo+Pg0K Pj5NeSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgYWRkaXRpb25hbCB0aHJlYXQgeW91IGhhZCBzdWdn ZXN0ZWQgaW4gYQ0KPj5wcmV2aW91cyBlbWFpbMWgLg0KPj5UaGUgcG9pbnQgYWJvdXQgdGhpcyB0 aHJlYXQgaXMgdGhhdCB3ZSBoYXZlIGRpc2N1c3NlZCBhYm91dCB0aGUNCj4+cG9zc2liaWxpdHkg b2YgdGhlIGRhdGFiYXNlIGhhdmluZyB0aGUgY2FwYWJpbGl0eSB0byBzZW5kIGFuDQo+PnVuc29s aWNpdGVkIHB1c2ggbm90aWZpY2F0aW9uICh0byB0aGUgbWFzdGVyIGRldmljZSkgZm9yIHJldm9r aW5nIHRoZQ0KPj5wcmV2aW91c2x5IGFsbG9jYXRlZCBjaGFubmVscyBhbmQgY2Vhc2luZyBvcGVy YXRpb24uDQo+PlNvIHRoZSAibWFsaWNpb3VzIG5vZGUiIGluIHRoaXMgY2FzZSBpcyBhbiBlbnRp dHkgd2hpY2ggcHJldGVuZHMgdG8gYmUNCj4+dGhlIGRhdGFiYXNlIGFuZCBzZW5kcyBzdWNoIGEg cHVzaCBub3RpZmljYXRpb24gbWVzc2FnZSB0byB0aGUgbWFzdGVyDQo+PmRldmljZS4NCj4+DQo+ Pj4NCj4+Pg0KPj4+SSB3YXMgcmVhbGx5IHRoaW5raW5nIG1vcmUgYWJvdXQgdGhlIG1pc3VzZSBv ZiB0aGUgRGF0YWJhc2UsIG9yIE1hc3Rlcg0KPj50bzoNCj4+PiAtIHR1cm4gb2ZmIGRldmljZXMg cHJlc3VtZWQgdG8gYmUgdmlvbGF0aW5nIHRoZSBEQ01BDQo+Pg0KPj5EQ01BPw0KPj5UaGUgYXNw ZWN0IG9mIGEgZGV2aWNlIGJlaW5nIHN3aXRjaGVkIG9mZiBpcyBjb3ZlcmVkIGluIHRoaXMgdGhy ZWF0Lg0KPj4NCj4+PiAtIGxpbWl0aW5nIHNwZWN0cnVtIHVzYWdlIGJhc2VkIG9uIHRoZSB0eXBl IG9yIHB1cnBvc2Ugb2YgdGhlIHRyYWZmaWMNCj4+PihlLmcuIE9ha2xhbmQgQkFSVCkNCj4+PiAt IGxpbWl0YXRpb24gb2Ygc3BlY3RydW0gdXNhZ2UgYmFzZWQgb24gcG9saXRpY2FsIGFmZmlsaWF0 aW9uLCByYWNlLA0KPj4+Z2VuZGVyLCBpZGVvbG9neSwNCj4+PiAgIGluZGl2aWR1YWwgaWRlbnRp dHksIGV0Yy4NCj4+DQo+PkkgZG9uJ3QgZ2V0IHRoZSBhYm92ZSB0d28uIENhcmUgdG8gZXhwYW5k IG9uIHRoZXNlPw0KPj4NCj4+Pg0KPj4+V2UgbWF5IG5vdCBiZSBhYmxlIHRvIHByZXZlbnQgKGF0 IGEgcHJvdG9jb2wgbGV2ZWwpIHVuZmFpciBhbGxvY2F0aW9uDQo+Pm9yDQo+Pj5kaXNhYmxlbWVu dC4gV2Ugc2hvdWxkIGF0IGxlYXN0IGJlIGFibGUgdG8gaGF2ZSBhZGVxdWF0ZSBsb2dnaW5nIGFu ZA0KPj4+cmVjb3JkcyB0aGF0IGdpdmVuIGFuIGV4cGVjdGF0aW9uIG9mIGZhaXIgYWxsb2NhdGlv biAtIHdlIGNhbiBkZXRlY3QNCj4+YW5kDQo+Pj5jb21wbGFpbiB3aGVuIG91ciBtb2JpbGUgZGV2 aWNlcyBhcmUgdHVybmVkIG9mZi4NCj4+DQo+PlNvIGRvIHdlIG5lZWQgdG8gY2FwdHVyZSB0aGlz IGluIHRoZSBmb3JtIG9mIGEgdGhyZWF0PyBEbyB3ZSB3YW50IHRvDQo+PmhhdmUgYSByZXF1aXJl bWVudCB0aGF0IHRoZSBwcm90b2NvbCBuZWVkcyB0byBlbmFibGUgbG9nZ2luZyBhbmQgcmVjb3Jk DQo+PmtlZXBpbmc/IFRoYXTCuXMgbW9yZSBvZiBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZS4NCj4+ DQo+Pi1SYWoNCj4+DQo+Pj4NCj4+PlBhdWwNCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj5Gcm9tOiBwYXdzLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpwYXdzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj5PZg0KPj4+Pkpv ZWwgTS4gSGFscGVybg0KPj4+PlNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDMsIDIwMTIgMTI6MDEg UE0NCj4+Pj5UbzogUm9zZW4sIEJyaWFuDQo+Pj4+Q2M6IHBhd3NAaWV0Zi5vcmcNCj4+Pj5TdWJq ZWN0OiBSZTogW3Bhd3NdIFRocmVhdCBtb2RlbCAoUmV2IDMpDQo+Pj4+DQo+Pj4+SW4gdGhlIHVu YXV0aG9yaXplZCB1c2Ugc2VjdGlvbiwgdGhlcmUgaXMgc3RpbGwgdGhlIHRleHQgc2F5aW5nOg0K Pj4+PiAgICAgICAgVGhlIGF0dGFja2VyIG1heSBsaXN0ZW4gdG8NCj4+Pj4gICAgICAgIHRoZSBj b21tdW5pY2F0aW9uIGJldHdlZW4gYSB2YWxpZCBtYXN0ZXIgZGV2aWNlIGFuZCB3aGl0ZQ0KPj5z cGFjZQ0KPj4+PiAgICAgICAgZGF0YWJhc2UgYW5kIHV0aWxpemUgdGhlIGluZm9ybWF0aW9uIGFi b3V0IGF2YWlsYWJsZSBjaGFubmVscw0KPj4+PiAgICAgICAgaW4gdGhlIHJlc3BvbnNlIG1lc3Nh Z2UgYnkgdXRpbGl6aW5nIHRob3NlIGNoYW5uZWxzLg0KPj4+Pg0KPj4+Pkkgc3RpbGwgZmluZCB0 aGlzIHRvdGFsbHkgbWluZC1iZW5kaW5nLCBhcyBpdCBpcyBhYm91dCB0aGUgaGFyZGVzdA0KPj4+ PndheSBpbWFnaW5hYmxlIHRvIHVuZGVydGFrZSB0aGlzIGF0dGFjay4NCj4+Pj4NCj4+Pj4NCj4+ Pj5PbiAyLzMvMjAxMiAyOjU1IFBNLCBSb3NlbiwgQnJpYW4gd3JvdGU6DQo+Pj4+PiA8YXMgaW5k aXZpZHVhbD4NCj4+Pj4+IFdoZXJlIGRvIHlvdSBzZWUgdGhpcyBhc3N1bXB0aW9uIGluIHRoZSB0 aHJlYXQgbW9kZWw/DQo+Pj4+Pg0KPj4+Pj4gSSB0b29rIGEgcXVpY2sgbG9vayBhbmQgZGlkbid0 IHNwb3QgaXQuICBJdCB3b3VsZCBiZSAiZGF0YWJhc2UNCj4+Pj5pbmZvcm1hdGlvbiBsZWFrZWQg dG8gYmFkIGd1eXMiIG9yIHNvbWV0aGluZyBsaWtlIGl0LCByaWdodD8NCj4+Pj4+DQo+Pj4+PiBJ IGRvbid0IHRoaW5rIHRoYXQgaXMgYSB0aHJlYXQsIGFuZCBJIGRvbid0IHRoaW5rIHdlIG5lZWQg dG8NCj4+Pj4+IHByb3RlY3QNCj4+Pj5hbnlvbmUgZnJvbSB0aGF0IHRocmVhdC4NCj4+Pj4+DQo+ Pj4+PiBJIHdvdWxkIHNheSwgaG93ZXZlciwgdGhhdCBpZiB5b3UgY291bGQga25vdyB0aGUgY29u dGVudCBvZiB0aGUNCj4+Pj5kYXRhYmFzZSwgYW5kIHlvdSBjYW4gb2JzZXJ2ZSBhIHJlc3BvbnNl cyBvdmVyIGEgcGVyaW9kIG9mIHRpbWUsIHlvdQ0KPj5tYXkNCj4+Pj5iZSBhYmxlIHRvIGluZmVy IHRoZSBsb2NhdGlvbiBvZiB0aGUgcXVlcmllci4NCj4+Pj4+DQo+Pj4+PiBCcmlhbg0KPj4+Pj4N Cj4+Pj4+DQo+Pj4+PiBPbiBGZWIgMywgMjAxMiwgYXQgMjo1MSBQTSwgSm9lbCBNLiBIYWxwZXJu IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBDYW4gd2UgcGxlYXNlIGluY2x1ZGUgaW4gdGhpcyBkb2N1 bWVudCBzb21lIGFydGljdWxhdGlvbiBvZiB0aGUNCj4+Pj4+PiBjb25maWRlbnRpYWxpdHkgYXNz dW1wdGlvbiB3ZSBhcmUgbWFraW5nIHdpdGggcmVnYXJkIHRvIHRoZQ0KPj4+PndoaXRlc3BhY2UN Cj4+Pj4+PiBkYXRhIGl0c2VsZj8gIEkgYW0gbm90IHRyeWluZyB0byBvYmplY3QgdG8gdGhlIHRo cmVhdHMuICAoQW5kIHRoZQ0KPj4+Pj4+IHBlcnNvbmFsIGluZm9ybWF0aW9uIGNvbGxlY3Rpb24g aXNzdWVzIGFyZSBlbm91Z2ggdG8ganN1dGlmeQ0KPj5pbmNsdWRlDQo+Pj4+Pj4gY29uZmlkZW50 aWFsaXR5IG1lY2hhbmlzbXMgaW4gdGhlIHNvbHV0aW9ucy4pIEJ1dCBJIGFtIHN0aWxsDQo+Pj4+ Pj4gdHJ5aW5nIHRvIGdldCBteSBoZWFkIGFyb3VuZCB0aGlzLiAgVGhlcmUgYXJlIGdvaW5nDQo+ PnRvDQo+Pj4+YmUNCj4+Pj4+PiBob2FyZHMgb2Ygd2hpdGVzcGFjZSBkZXZpY2VzLiAgVGhleSB3 aWxsIGJlIGdldHRpbmcgdGhlIGRhdGEsIGFuZA0KPj4+PmVpdGhlcg0KPj4+Pj4+IHVzaW5nIGl0 IHRoZW1zZWx2ZXMgb3IgcmV0cmFuc21pdHRpbmcgaXQuICBUaGUgcmVzdWx0aW5nIGRhdGEgb25l DQo+Pj4+Pj4gd2hpdGVzcGFjZSBhdmFpbGFiaWxpdHkgd2lsbCBiZSB2aXNpYmxlIHRvIHBlb3Bs ZSBhbmQgb3IgZGV2aWNlcw0KPj4+PndoaWNoDQo+Pj4+Pj4gYXJlIG5vdCBjb21wbGV0ZWx5IGNv bnRyb2xsZWQgYnkgdGhlIHJlZ3VsYXRvcnkgYWdlbmNpZXMuDQo+Pj4+Pj4gQXMgc3VjaCwgd2hh dCBpcyB0aGUgcm9sZSBvZiBjb25maWRlbnRpYWxpdHkgd2l0aCByZWdhcmQgdG8gdGhpcw0KPj4+ Pj4+IGluZm9ybWF0aW9uPw0KPj4+Pj4+DQo+Pj4+Pj4gWW91cnMsDQo+Pj4+Pj4gSm9lbA0KPj4+ Pj4+DQo+Pj4+Pj4gT24gMi8zLzIwMTIgMjozNCBQTSwgQmFzYXZhcmFqLlBhdGlsQG5va2lhLmNv bSB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4gQmVsb3cgaXMgUmV2IDMgb2YgdGhlIHRocmVhdCBt b2RlbCBiYXNlZCBvbiBmZWVkYmFjayBmcm9tDQo+Pj4+Pj4+IFN0ZXBoZW4sDQo+Pj4+TmFuY3kN Cj4+Pj4+Pj4gYW5kIEdhYm9yIChUaGFua3MpLg0KPj4+Pj4+Pg0KPj4+Pj4+PiAtUmFqDQo+Pj4+ Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IFJldiAzICgzLzIvMTIpDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRo cmVhdCBtb2RlbCBmb3IgdGhlIFBBV1MgcHJvdG9jb2wNCj4+Pj4+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4+Pg0KPj4+Pj4+PiBBc3N1bXB0aW9uczoNCj4+Pj4+ Pj4gLi4uLi4uLi4uLi4uDQo+Pj4+Pj4+DQo+Pj4+Pj4+IG8gSXQgaXMgYXNzdW1lZCB0aGF0IGFu IGF0dGFja2VyIGhhcyBmdWxsIGFjY2VzcyB0byB0aGUgbmV0d29yaw0KPj4+Pm1lZGl1bQ0KPj4+ Pj4+PiAgICBiZXR3ZWVuIHRoZSBtYXN0ZXIgZGV2aWNlIGFuZCB0aGUgd2hpdGUgc3BhY2UgZGF0 YWJhc2UuIFRoZQ0KPj4+PmF0dGFja2VyDQo+Pj4+Pj4+ICAgIG1heSBiZSBhYmxlIHRvIGVhdmVz ZHJvcCBvbiBhbnkgY29tbXVuaWNhdGlvbnMgYmV0d2VlbiB0aGVzZQ0KPj4+Pj4+PiAgICBlbnRp dGllcy4gVGhlIGxpbmsgYmV0d2VlbiB0aGUgbWFzdGVyIGRldmljZSBhbmQgdGhlIHdoaXRlDQo+ PnNwYWNlDQo+Pj4+Pj4+ICAgIGRhdGFiYXNlIGNhbiBiZSB3aXJlZCBvciB3aXJlbGVzcyBhbmQg cHJvdmlkZXMgSVAgY29ubmVjdGl2aXR5Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBvIEl0IGlzIGFzc3Vt ZWQgdGhhdCB0aGUgbWFzdGVyIGRldmljZSBvciB0aGUgd2hpdGUgc3BhY2UgZGF0YWJhc2UNCj4+ Pj4+Pj4gICAgaGF2ZSBOT1QgYmVlbiBjb21wcm9taXNlZCBmcm9tIGEgc2VjdXJpdHkgc3RhbmRw b2ludC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhyZWF0IDE6IFVzZXIgbW9kaWZpZXMgYSBkZXZpY2Ug dG8gbWFzcXVlcmFkZSBhcyBhbm90aGVyIHZhbGlkDQo+Pj4+Pj4+ICAgICAgICAgY2VydGlmaWVk IGRldmljZQ0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgIFRoZSBtYXN0ZXIgZGV2aWNlIG5lZWRz IHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYgd2l0aCB0aGUNCj4+Pj53aGl0ZQ0KPj4+Pj4+PiAgICAg ICAgIHNwYWNlIGRhdGFiYXNlIHByaW9yIHRvIHJlcXVlc3RpbmcgY2hhbm5lbCBpbmZvcm1hdGlv bi4NCj4+VGhlDQo+Pj4+Pj4+ICAgICAgICAgYXR0YWNrZXIgbWF5IHRyeSB0byBnZXQgYWNjZXNz IHRvIHRoZSBzZWNyZXRzIG9mIHRoZQ0KPj5tYXN0ZXINCj4+Pj4+Pj4gICAgICAgICBkZXZpY2Ug d2hpY2ggY2FuIGJlIHVzZWQgbWFsaWNpb3VzbHkuIFRoZSBlZmZlY3Qgb2Ygc3VjaA0KPj5hbg0K Pj4+Pj4+PiAgICAgICAgIGF0dGFjayBiZWluZyBzdWNjZXNzZnVsIHdvdWxkIHJlc3VsdCBpbiBh IG1hbGljaW91cyBjbGllbnQNCj4+Pj4+Pj4gICAgICAgICByZXBsYXlpbmcgdGhlIHN0b2xlbiBh dXRoZW50aWNhdGlvbi9hdXRob3JpemF0aW9uIHNlY3JldHMNCj4+dG8NCj4+Pj5hDQo+Pj4+Pj4+ ICAgICAgICAgd2hpdGUgc3BhY2UgZGF0YWJhc2UuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRocmVhdCAy OiBTcG9vZmVkIHdoaXRlIHNwYWNlIGRhdGFiYXNlDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAg QSBtYXN0ZXIgZGV2aWNlIGRpc2NvdmVycyBhIHdoaXRlIHNwYWNlIGRhdGFiYXNlKHMpIHRocnUN Cj4+Pj53aGljaA0KPj4+Pj4+PiAgICAgICAgIGl0IGNhbiBxdWVyeSBmb3IgY2hhbm5lbCBpbmZv cm1hdGlvbi4gVGhlIG1hc3RlciBkZXZpY2UNCj4+Pj5uZWVkcw0KPj4+Pj4+PiAgICAgICAgIHRv IGVuc3VyZSB0aGF0IHRoZSB3aGl0ZSBzcGFjZSBkYXRhYmFzZSB3aXRoIHdoaWNoIGl0DQo+Pj4+ Pj4+ICAgICAgICAgY29tbXVuaWNhdGVzIHdpdGggaXMgYW4gYXV0aGVudGljIGVudGl0eS4gVGhl IHdoaXRlIHNwYWNlDQo+Pj4+Pj4+ICAgICAgICAgZGF0YWJhc2UgbmVlZHMgdG8gcHJvdmlkZSBp dHMgaWRlbnRpdHkgdG8gdGhlIG1hc3Rlcg0KPj5kZXZpY2UNCj4+Pj4+Pj4gICAgICAgICB3aGlj aCBjYW4gY29uZmlybSB0aGUgdmFsaWRpdHkvYXV0aGVudGljdHkgb2YgdGhlDQo+PmRhdGFiYXNl Lg0KPj4+PkFuDQo+Pj4+Pj4+ICAgICAgICAgYXR0YWNrZXIgbWF5IGF0dGVtcHQgdG8gc3Bvb2Yg YSB3aGl0ZSBzcGFjZSBkYXRhYmFzZSBhbmQNCj4+Pj4+Pj4gICAgICAgICBwcm92aWRlIHJlc3Bv bnNlcyB0byBhIG1hc3RlciBkZXZpY2Ugd2hpY2ggYXJlIG1hbGljaW91cw0KPj5hbmQNCj4+Pj4+ Pj4gICAgICAgICByZXN1bHQgaW4gdGhlIG1hc3RlciBkZXZpY2UgY2F1c2luZyBpbnRlcmZlcmVu Y2UgdG8gdGhlDQo+Pj4+cHJpbWFyeQ0KPj4+Pj4+PiAgICAgICAgIHVzZXIgb2YgdGhlIHNwZWN0 cnVtLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaHJlYXQgMzogTW9kaWZ5aW5nIGEgcXVlcnkgcmVxdWVz dA0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgIEFuIGF0dGFja2VyIG1heSBtb2RpZnkgdGhlIHF1 ZXJ5IHJlcXVlc3Qgc2VudCBieSBhIG1hc3Rlcg0KPj4+Pj4+PiAgICAgICAgIGRldmljZSB0byBh IHdoaXRlIHNwYWNlIGRhdGFiYXNlLiBUaGUgYXR0YWNrZXIgbWF5IGNoYW5nZQ0KPj4+PnRoZQ0K Pj4+Pj4+PiAgICAgICAgIGxvY2F0aW9uIG9mIHRoZSBkZXZpY2Ugb3IgdGhlIGNhcGFiaWxpdGll cyBpbiB0ZXJtcyBvZiBpdHMNCj4+Pj4+Pj4gICAgICAgICB0cmFuc21pdCBwb3dlciBvciBhbnRl bm5hIGhlaWdodCBldGMuIHdoaWNoIGNvdWxkIHJlc3VsdA0KPj5pbg0KPj4+PnRoZQ0KPj4+Pj4+ PiAgICAgICAgIGRhdGFiYXNlIHJlc3BvbmRpbmcgd2l0aCBpbmNvcnJlY3QgaW5mb3JtYXRpb24g YWJvdXQNCj4+Pj5hdmFpbGFibGUNCj4+Pj4+Pj4gICAgICAgICBjaGFubmVscyBvciBtYXggdHJh bnNtaXQgcG93ZXIgYWxsb3dlZC4gVGhlIHJlc3VsdCBvZg0KPj4+Pj4+PiBzdWNoDQo+Pj4+YW4N Cj4+Pj4+Pj4gICAgICAgICBhdHRhY2sgaXMgdGhhdCB0aGUgbWFzdGVyIGRldmljZSB3b3VsZCBj YXVzZQ0KPj4+Pj4+PiBpbnRlcmVmZXJlbmNlDQo+Pj4+dG8NCj4+Pj4+Pj4gICAgICAgICB0aGUg cHJpbWFyeSB1c2VyIG9mIHRoZSBzcGVjdHJ1bS4gSXQgY291bGQgYWxzbyByZXN1bHQgaW4NCj4+ YQ0KPj4+Pj4+PiAgICAgICAgIGRlbmlhbCBvZiBzZXJ2aWNlIHRvIHRoZSBtYXN0ZXIgZGV2aWNl IGJ5IGluZGljYXRpbmcgdGhhdA0KPj5ubw0KPj4+Pj4+PiAgICAgICAgIGNoYW5uZWxzIGFyZSBh dmFpbGFibGUuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRocmVhdCA0OiBNb2RpZnlpbmcgYSBxdWVyeSBy ZXNwb25zZQ0KPj4+Pj4+Pg0KPj4+Pj4+PiAgICAgICAgIEFuIGF0dGFja2VyIGNvdWxkIG1vZGlm eSB0aGUgcXVlcnkgcmVzcG9uc2Ugc2VudCBieSB0aGUNCj4+Pj53aGl0ZQ0KPj4+Pj4+PiAgICAg ICAgIHNwYWNlIGRhdGFiYXNlIHRvIGEgbWFzdGVyIGRldmljZS4gVGhlIGNoYW5uZWwNCj4+Pj4+ Pj4gaW5mb3JtYXRpb24NCj4+Pj5vcg0KPj4+Pj4+PiAgICAgICAgIHRyYW5zbWl0IHBvd2VyIGFs bG93ZWQgdHlwZSBvZiBwYXJhbWV0ZXJzIGNhcnJpZWQgaW4gdGhlDQo+Pj4+Pj4+ICAgICAgICAg cmVzcG9uc2UgY291bGQgYmUgbW9kaWZpZWQgYnkgdGhlIGF0dGFja2VyIHJlc3VsdGluZyBpbg0K Pj50aGUNCj4+Pj4+Pj4gICAgICAgICBtYXN0ZXIgZGV2aWNlIHVzaW5nIGNoYW5uZWxzIHRoYXQg YXJlIG5vdCBhdmFpbGFibGUgYXQgYQ0KPj4+Pj4+PiAgICAgICAgIGxvY2F0aW9uIG9yIHRyYW5z bWl0dGluZyBhdCBhIGdyZWF0ZXIgcG93ZXIgbGV2ZWwgdGhhbg0KPj4+PmFsbG93ZWQNCj4+Pj4+ Pj4gICAgICAgICByZXN1bHRpbmcgaW4gaW50ZXJmZXJlbmNlIHRvIHRoZSBwcmltYXJ5IHVzZXIg b2YgdGhhdA0KPj4+Pj4+PiAgICAgICAgIHNwZWN0cnVtLiBBbHRlcm5hdGl2ZWx5IHRoZSBhdHRh Y2tlciBtYXkgaW5kaWNhdGUgbm8NCj4+Y2hhbm5lbA0KPj4+Pj4+PiAgICAgICAgIGF2YWlsYWJp bGl0eSBhdCBhIGxvY2F0aW9uIHJlc3VsdGluZyBpbiBhIGRlbmlhbCBvZg0KPj5zZXJ2aWNlDQo+ Pj4+dG8NCj4+Pj4+Pj4gICAgICAgICB0aGUgbWFzdGVyIGRldmljZS4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gVGhyZWF0IDU6IFVuYXV0aG9yaXplZCB1c2Ugb2YgY2hhbm5lbHMgYnkgYW4gdW5jZXJ0aWZp ZWQgZGV2aWNlDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgQW4gYXR0YWNrZXIgbWF5IGJlIGEg bWFzdGVyIGRldmljZSB3aGljaCBpcyBub3QgY2VydGlmaWVkDQo+Pj4+Zm9yDQo+Pj4+Pj4+ICAg ICAgICAgdXNlIGJ5IHRoZSByZWxldmFudCByZWd1bGF0b3J5IGJvZHkuIFRoZSBhdHRhY2tlciBt YXkNCj4+bGlzdGVuDQo+Pj4+dG8NCj4+Pj4+Pj4gICAgICAgICB0aGUgY29tbXVuaWNhdGlvbiBi ZXR3ZWVuIGEgdmFsaWQgbWFzdGVyIGRldmljZSBhbmQgd2hpdGUNCj4+Pj5zcGFjZQ0KPj4+Pj4+ PiAgICAgICAgIGRhdGFiYXNlIGFuZCB1dGlsaXplIHRoZSBpbmZvcm1hdGlvbiBhYm91dCBhdmFp bGFibGUNCj4+Pj5jaGFubmVscw0KPj4+Pj4+PiAgICAgICAgIGluIHRoZSByZXNwb25zZSBtZXNz YWdlIGJ5IHV0aWxpemluZyB0aG9zZSBjaGFubmVscy4gVGhlDQo+Pj4+cmVzdWx0DQo+Pj4+Pj4+ ICAgICAgICAgb2Ygc3VjaCBhbiBhdHRhY2sgaXMgdW5hdXRob3JpemVkIHVzZSBvZiBjaGFubmVs cyBieSBhDQo+Pj4+bWFzdGVyDQo+Pj4+Pj4+ICAgICAgICAgZGV2aWNlIHdoaWNoIGlzIG5vdCBj ZXJ0aWZpZWQgdG8gb3BlcmF0ZS4NCj4+Pj4+Pj4gICAgICAgICBUaGUgbWFzdGVyIGRldmljZSBx dWVyeWluZyB0aGUgd2hpdGUgc3BhY2UgZGF0YWJhc2UgbWF5IGJlDQo+Pj4+Pj4+ICAgICAgICAg b3BlcmF0ZWQgYnkgYSBsYXctZW5mb3JjZW1lbnQgYWdlbmN5IGFuZCB0aGUNCj4+Y29tbXVuaWNh dGlvbnMNCj4+Pj4+Pj4gICAgICAgICBiZXR3ZWVuIHRoZSBkZXZpY2UgYW5kIHRoZSBkYXRhYmFz ZSBhcmUgaW50ZW5kZWQgdG8gYmUNCj4+a2VwdA0KPj4+Pj4+PiAgICAgICAgIHByaXZhdGUuIEEg bWFsaWNpb3VzIGRldmljZSBzaG91bGQgbm90IGJlIGFibGUgdG8NCj4+ZWF2ZXNkcm9wDQo+Pj4+ b24NCj4+Pj4+Pj4gICAgICAgICBzdWNoIGNvbW11bmljYXRpb25zLg0KPj4+Pj4+Pg0KPj4+Pj4+ PiBUaHJlYXQgNjogVGhpcmQgcGFydHkgdHJhY2tpbmcgb2Ygd2hpdGUgc3BhY2UgZGV2aWNlIGxv Y2F0aW9uIGFuZA0KPj4+PmlkZW50aXR5DQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAgICAgQSB3aGl0 ZSBzcGFjZSBkYXRhYmFzZSBtYXkgcmVxdWlyZSBhIG1hc3RlciBkZXZpY2UgdG8NCj4+Pj5wcm92 aWRlDQo+Pj4+Pj4+ICAgICAgICAgaXRzIGlkZW50aXR5IGluIGFkZGl0aW9uIHRvIGl0cyBsb2Nh dGlvbiBpbiB0aGUgcXVlcnkNCj4+Pj5yZXF1ZXN0Lg0KPj4+Pj4+PiAgICAgICAgIFN1Y2ggbG9j YXRpb24vaWRlbnRpdHkgaW5mb3JtYXRpb24gY2FuIGJlIGdsZWFuZWQgYnkgYW4NCj4+Pj4+Pj4g ICAgICAgICBlYXZlc2Ryb3BwZXIuIEEgbWFzdGVyIGRldmljZSBtYXkgcHJlZmVyIHRvIGtlZXAg dGhlDQo+Pj4+Pj4+ICAgICAgICAgbG9jYXRpb24vaWRlbnRpdHkgaW5mb3JtYXRpb24gc2VjcmV0 LiBIZW5jZSB0aGUgcHJvdG9jb2wNCj4+Pj5zaG91bGQNCj4+Pj4+Pj4gICAgICAgICBwcm92aWRl IGEgbWVhbnMgdG8gcHJvdGVjdCB0aGUgbG9jYXRpb24gYW5kIGlkZW50aXR5DQo+Pj4+Pj4+ICAg ICAgICAgaW5mb3JtYXRpb24gb2YgdGhlIG1hc3RlciBkZXZpY2UgYW5kIHByZXZlbnQgdHJhY2tp bmcgb2YNCj4+Pj4+Pj4gICAgICAgICBsb2NhdGlvbnMgYXNzb2NpYXRlZCB3aXRoIGEgd2hpdGUg c3BhY2UgZGF0YWJhc2UuIElmDQo+Pj4+Pj4+ICAgICAgICAgcmVndWxhdGlvbnMgZG8gbm90IHJl cXVpcmUgdGhlIGlkZW50aXR5IG9mIHRoZSBtYXN0ZXINCj4+ZGV2aWNlDQo+Pj4+dG8NCj4+Pj4+ Pj4gICAgICAgICBiZSBwcm92aWRlZCB0byB0aGUgd2hpdGUgc3BhY2UgZGF0YWJhc2UsIHRoZSBt YXN0ZXIgaXMgbm90DQo+Pj4+Pj4+ICAgICAgICAgcmVxdWlyZWQgdG8gaW5jbHVkZSBpdHMgaWRl bnRpdHkgaW4gdGhlIHF1ZXJ5Lg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaHJlYXQgNzog VGVybWluYXRpb24gb2YgZGV2aWNlIHNlcnZpY2UgZm9yIHJlYXNvbnMgb3RoZXIgdGhhbg0KPj4+ Pj4+PiAgICAgICAgIGluY3VtYmVudCBwcm90ZWN0aW9uDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICAgICAg ICAgQSB3aGl0ZSBzcGFjZSBkYXRhYmFzZSBtYXkgaW5jbHVkZSBhIG1lY2hhbmlzbSBieSB3aGlj aA0KPj4+PnNlcnZpY2UNCj4+Pj4+Pj4gICAgICAgICBhbmQgY2hhbm5lbHMgYWxsb2NhdGVkIHRv IGEgbWFzdGVyIGRldmljZSBjYW4gYmUgcmV2b2tlZC4NCj4+QQ0KPj4+Pj4+PiAgICAgICAgIG1h bGljaW91cyBub2RlIGNhbiBzZW5kIGEgcmV2b2tlIG1lc3NhZ2UgdG8gYSBtYXN0ZXINCj4+Pj4+ Pj4gICAgICAgICBkZXZpY2UuIFRoaXMgcmVzdWx0cyBpbiBkZW5pYWwgb2Ygc2VydmljZSB0byB0 aGUgbWFzdGVyDQo+Pj4+Pj4+ICAgICAgICAgZGV2aWNlLg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBwYXdzQGlldGYub3JnDQo+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+Pj4+Pg0KPj4+Pj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4g cGF3cyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBwYXdzQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PnBhd3MgbWFp bGluZyBsaXN0DQo+Pj4+cGF3c0BpZXRmLm9yZw0KPj4+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PnBhd3MgbWFpbGluZyBsaXN0DQo+Pj5wYXdzQGlldGYub3JnDQo+ Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4NCj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnBhd3MgbWFpbGluZyBs aXN0DQo+cGF3c0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcGF3cw0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+cGF3cyBtYWlsaW5nIGxpc3QNCj5wYXdzQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoNCg== From Basavaraj.Patil@nokia.com Thu Feb 9 09:04:58 2012 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 0692821E803B for ; Thu, 9 Feb 2012 09:04:58 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lJ3MMo8w+5G for ; Thu, 9 Feb 2012 09:04:57 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 485BF21E8035 for ; Thu, 9 Feb 2012 09:04:57 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q19H4sJY031497; Thu, 9 Feb 2012 19:04:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 19:04:54 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Thu, 9 Feb 2012 18:04:53 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAHW0EAgAB73KCAAMPrgA== Date: Thu, 9 Feb 2012 17:04:53 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4FBE3@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [173.74.226.51] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2012 17:04:54.0292 (UTC) FILETIME=[F18C0D40:01CCE74C] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 09 Feb 2012 17:04:58 -0000 On 2/8/12 4:28 PM, "ext Paul Lambert" wrote: >[Paul] >You missed my point below. There are many sources of threats. Not all >can be directly mitigated by protocol mechanisms, but there may be ways >with associated policies, procedures and agreements to limit the impact. > >If we are performing a threat analysis we should look at the full suite >of threats. The list in the current threat models text that I proposed is by no means exhaustive=8A Or intended to be. The intent is to derive a key set of security requirements for the protocol. The focus is on those threats that are relevant to the device-2-database protocol rather than to the much more expansive topic of white space technology. -Raj =20 From gerald.chouinard@sympatico.ca Thu Feb 9 10:27:39 2012 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 110BF21F8535 for ; Thu, 9 Feb 2012 10:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.492 X-Spam-Level: *** X-Spam-Status: No, score=3.492 tagged_above=-999 required=5 tests=[AWL=-2.220, BAYES_50=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_93=0.6, MSGID_FROM_MTA_HEADER=0.803, SARE_FWDLOOK=1.666, SARE_LWHUGE=1.54] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 339BSkqPcTKb for ; Thu, 9 Feb 2012 10:27:22 -0800 (PST) Received: from blu0-omc3-s5.blu0.hotmail.com (blu0-omc3-s5.blu0.hotmail.com [65.55.116.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB921E8021 for ; Thu, 9 Feb 2012 10:11:56 -0800 (PST) Received: from BLU0-SMTP22 ([65.55.116.73]) by blu0-omc3-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 10:11:49 -0800 X-Originating-IP: [174.95.124.167] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.124.167]) by BLU0-SMTP22.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 10:11:45 -0800 From: Gerald Chouinard To: "'Peter Stanforth'" , "'Nancy Bravin'" References: Date: Thu, 9 Feb 2012 13:11:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D1_01CCE72C.6177A4F0" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcznRR3ipwW1YwLeT76upgE8nd6daQAD82mA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 09 Feb 2012 18:11:46.0189 (UTC) FILETIME=[48D2F3D0:01CCE756] Cc: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) 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, 09 Feb 2012 18:27:39 -0000 ------=_NextPart_000_00D1_01CCE72C.6177A4F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Peter, I see your point. In my view, opportunistic use of the spectrum does not necessarily imply that it has to be license-exempt, it means that the use is limited in time and that the user does not keep the spectrum assignment beyond its use. Beyond protecting the primary and secondary operations assigned to the band, such opportunistic use can also be protected from interference from other lower priority users such as license-exempt users. This would likely imply a different type of license and it is up to the local regulators to issue such temporary license. As far as the database is concerned, the regulator would then need to register such temporary use in the database so that other devices, such as the license-exempt devices, protect this operation for the time it is active according to its temporary license. This would mean a near real-time updating for the database but as far as the protocol to access such database by the license-exempt master devices, this should be totally transparent. Gerald _____ From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Thursday, 09 February, 2012 11:08 To: Nancy Bravin; Gerald Chouinard Cc: Andy Sago; paws@ietf.org; John A. Stine Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) I agree this is a business issue, but there is a DB potential. I will give you some scenarios we deal with often. A construction project requests spectrum for a time and place in the future. They may only need it for a day or a month. A sporting or cultural event wants some spectrum next week for a day. These are not traditional telco models but they are real scenarios and they absolutely need a certainty that they will get the access they have requested. We use a spectrum management database and coordination with a primary user to meet these needs. Much of the actual coordination is done manually today - which is time consuming and expensive.I am just pointing out that assuming that all the world wants is the traditional telco model or an opportunistic unlicensed white space model misses a huge opportunity for which a database is a key component in automating this and making it realistic. From: Nancy Bravin Date: Thu, 9 Feb 2012 10:43:15 -0500 To: Gerald Chouinard Cc: Peter Stanforth , Andy Sago , "paws@ietf.org" , "John A. Stine" Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Hi All, In this discussion are you not discussing business models and use cases such as Jon Stine suggested? That would indicate other models that would be useful in a global sense, and not necessarily a Telco model. Myself, I don't see many Telco models that feel they have enough spectrum. In one example was the mention of the DOD or other spectrum owners who would allow WS use /sharing, as long as they could, when needed, use the spectrum as planned which is not often. Many times mostly unused spectrum merely says "hi" I am here, but its use is rare. I think it is a more global forward looking approach, and managed by the DB's under reg's of what ever country can use this model. It makes a good business model to lay for the future of white space, as opposed to allowing models not associated with WSDB's at all. Whether you want it in this part of the protocol, is another question, but it does seem to belong and further may allow for more involvement globally from a business sense, using the DB's./ My 2 cents for what it's worth. SIncerely, Nancy On Feb 9, 2012, at 6:56 AM, Gerald Chouinard wrote: Peter, I agree. It depends on how the term 'opportunistic' is being defined. In my view, the qualifier 'opportunistic' relates to the use of the spectrum by devices and not to the availability of the spectrum. As you describe, the spectrum may be made available on a deterministic basis but its use by one device or another is opportunistic since it is managed by a near real-time database. For me, a deterministic use of the spectrum is an operator buying a license for a frequency band for a specific period of time such as 5 years with the possibility of extending this period. In this case, access to a database is not required. This is the current Telco model. The model that you describe seems to be an opportunistic use model where not only protection of primary and secondary incumbents would be provided but also absence of interference amongst opportunistic users is also provided, turning it into a temporary de-facto 'protected' service over a given period of time. This, to me, is still 'opportunistic'. It is just that all means are taken to make sure that the service is reliable during the given period of time. If one provides a TVWS database service and adds to it a coexistence service such as the 802.19.1 approach, you have more or less the same result. Such coexistence is however not mandatory in the TVWS and will depend on the will of the industry. Gerald _____ From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Wednesday, 08 February, 2012 18:48 To: Gerald Chouinard Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Gerald, It depends what how we define as opportunistic. We run a secondary market place for spectrum, FCC rules allow us to act as a "Spectrum Manager" in this role we can provide secondary access to devices under whatever criteria the license holder deems acceptable. We are, in everything but name, providing access to whitespace. In some cases this is opportunistic but in others it is very deterministic and the attraction of the spectrum is because it is deterministic. The key is the owner may not know exactly when or where theyneed the spectrum in the future but when they make it available it is guaranteed to be available for the timeframe published. This would not be possible without a database and yet is clearly not opportunistic. The same could be said for current US FCC TVWS rules. If we provide a channel list and a timeframe(Say for the next 4 hours) that channel list will remain available for the duration. What is missing, in the case of white space, is that we cannot deny access to someone else in the same location who asks the same question, whereas in our secondary marketplace we can. So not only is availability deterministic access is too. Peter S. From: Gerald Chouinard Date: Wed, 8 Feb 2012 17:46:44 -0500 To: Peter Stanforth Cc: "andy.sago@bt.com" , "nbravin@earthlink.net" , "paws@ietf.org" Subject: RE: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Peter, See my other email about 'secondary' versus 'opportunistic'. I agree with you that 'primary', 'secondary', 'deterministic and 'opportunistic' use of the spectrum has no relevance to whether the access could be free or paid (after all the primary access to the TV bands by the broadcasters is free for historical reasons while one coulddecide that someTVWS access could be paid ;-) ). Again, the reason why one needs a DB accessible over the internet is that the access to the spectrum is 'opportunistic'. If this was deterministic, the DB would not be needed as has been the case up to now. Gerald _____ From: Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Wednesday, 08 February, 2012 12:01 To: Gerald Chouinard;andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) There is no reason to assume that use of white space is by licensed exempt or unlicensed devices. This comes back to an earlier argument I made about what constitutes licensed and unlicensed? Again there is no reason that a license exempt or unlicensed device should get access to spectrum for "free" any more that a licensed device has to "pay" for spectrum access. The concept of a primary user, who has priority over a secondary user has no relevance to free or paid access. The rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the other, and an argument can be made for both. In a band occupied by a public safetyuser there may be no choice but to have opportunistic access but in other bands a primary user may be willing to commit to specific availability if their own use is deterministic. Peter S. From: Gerald Chouinard Date: Wed, 8 Feb 2012 10:20:52 -0500 To: "andy.sago@bt.com" , "nbravin@earthlink.net" , "paws@ietf.org" Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Andy, To resolve Nancy's concern, a new definition could be added for: TVWS White Space devices: White Space devices that operate in the TV bands. This would complement the definition of White Space devices and make it more specific. I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the White Spacedevices. The opportunistic use of the RF spectrum assumes that these devices operate while protecting existing operation in the band. There is automatically assumes the existence of primary users of the band that have priority. Such primary users would most likely be licensed to use the band and it is only the portions that happen to be unused that will be accessible to the White Space devices. The latter are unlikely to be licensed to only use the 'crumbs'. Removing the concept of license-exempt could put these new devices at the same level of priority as the primary devices and then why would they need to protect these 'primary' licensed devices. This would be similar to the situation in the 2.4 GHz where a database is not needed to protect other devices. As is well understood, the databases are there to protect primary and possibly secondary licensed devices from the new opportunistic devices, not opportunistic devices among themselves. The latter case would be covered by other means such as adatabase to provide coexistence and this is, I believe, beyond the scope ofPAWS. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of andy.sago@bt.com Sent: Wednesday, 01 February, 2012 09:58 To: nbravin@earthlink.net; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1to 3 (Introduction, Conventions and Terminology, Prior Work) Nancy, all Good questions. I'm not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your other questions, IMO our aim should be to provide all the necessary information in this PAWS requirements I-D to enable the PAWS protocol I-D to be developed. I don't think it's our job to explain different regulatory regimes or applications (beyond use cases) in this document, ITU and others do this very well, and regulators tend to be well coordinated or play 'follow my leader'. Thanks for pointing out the reference to licence-exempt that I had missed in 4.4 - I think the meaning would be just the same with 'in a license-exempt TVWS environment' deleted from that sentence. That would be my suggestion. Regards Andy From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: 01 February 2012 14:48 To: Sago,AJ,Andy,COD R Cc: paws@ietf.org Subject: Fwd: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Andy, also, throughout the document TVWS are mentioned in 4.1,4.5, 4.6.so if you propose to remove any reference to TVWS it will affect the document as a whole, and information that seems necessary to explain how the DB and protocol interacts with TVWS devices and the methods of doing so. One can envision that current rules could change, but, why not give the information on both for countries to understand fully what it's choices are? Thanks Andy, just some early morning thoughts.Sincerely, Nancy Begin forwarded message: From: Nancy Bravin Date: February 1, 2012 6:35:09 AM PST To: Andy Sago Cc: , , , Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Andy, All In section 4.4, license exempt is also mentioned as well. I am conflicted in a global sense when emerging countries, or countries with very different types of gov't want to implement the protocol, will they have enough information to do so? and thereby join the existing DB companies, orwill they do their own thing leaving holes in what one hopes will be an interoperable global protocol that deals with TVWS, and/orWhite spaces in general? Thanks, just a thought. SIncerely, Nancy On Feb 1, 2012, at 2:34 AM, wrote: Scott, All I agree with Jussi that we have now narrowed the definition to apply to TV white spaces, whereas the scope of PAWS is white spaces in general. I would question not only whythelower-priority service would always be licence-exempt, but why the higher priority service would always be licenced. To avoid this issue on 27th Jan I proposed (http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or unlicensed, or any mention of the regulatory status of the incumbent services. The Abstract derives from the Introduction and the text could be aligned to be the same in the Introduction, with "opportunistic" replacing "secondary" in later sentences in the Introduction. I have checked and there are no further references to licensing in the document, so we don't need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document - we are defining requirements fora protocol. Keep it simple. That just leaves the definition of white space, where the existing spectrum use has now got muddled with the potential for opportunistic use. This can be fixed by taking the white space and white space device definitions together. From Scott, Gerald and Jussi's comments perhaps we could agree on: White Space (WS) Radio spectrum which is not fully occupied at a specific location and time. White Space device A device which opportunistically uses some part of the white space spectrum, under control of a white space database. A white space device can be an access point, base station, a portable device or similar. In this context, a white spacedevice is required by local regulations to query a database with its location to obtain information about available spectrum. Regards Andy From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of jussi.kahtava@nokia.com Sent: 01 February 2012 07:31 To: gerald.chouinard@sympatico.ca; scott.probasco@nokia.com; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) That statement is valid for TV White Spaces on UHF frequencies but does not necessarily apply to all under-utilised radio spectrum. Why would the lower priority service by default be licence-exempt? Kind regards, Jussi From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: 31 January 2012 22:33 To: Probasco Scott (Nokia-CIC/Dallas); paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Very good improvements. I would suggest to insert the notion of opportunistic use of the spectrum by white space devices in the last sentence of the definition of "white space" as follows: White Space Radio spectrum which has been allocated and assigned for licensed use, but is not fully occupied by that licensed use at a specific location and time. This spectrum is then assigned allowed bylocal regulations for use to beused opportunistically as licensed-exempt spectrum under control of a white space database. This way, it is understood that the database does not "assign" white space devices for them to choose from. Gerald _____ From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: Tuesday, 31 January, 2012 15:12 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi Gerald, Good to avoid overloading the term "secondary". I have made additional proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that we would need some explanation of what that means. Since we now have descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do these changes remove your concerns? I also corrected "location" to "local" in previous text proposed for "White Space". Kind Regards, Scott From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 14:41:36 -0500 To: Scott , "paws@ietf.org" Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Scott, Great proposal. However, I am still a bit nervous about the definitions of "Protected Entity" and "White Space Devices (WSD)" where the notion of secondary use is included. The secondary status is used in the ITU-R Radio Regulations for a different purpose. In fact, it is possible that a band has already primary and secondary services allotted to it and that the White Space operation is a tertiary opportunistic operationwhere the two first types ofservices are not being used. The use of "lower priority opportunistic" service rather than "secondary" service would be preferable to describe white spaceallocations. Gerald _____ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com Sent: Tuesday, 31 January, 2012 13:56 To: paws@ietf.org Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior Work) Hi, I changed the subject line from " Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' ". Here I try to propose some changes to the draft based on the email discussion. Below is a copy of chapter 2.2. Terminology. I have inserted new terms for 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have tried to work from the perspective that the document should accurately explain the subject with aim that a reader can understand the use cases and the subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and usage. I hope this captures the key points of the discussion. Please do reply if something is still missing. Kind Regards, Scott 2.2. Terminology Database In the context of white space and cognitive radio technologies, the database is an entity which contains current information about available spectrum at any given location and other types of information. Device ID A unique number for each master device and slave device that identifies the manufacturer, model number and serial number. Licensed Spectrum Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions,award (beauty contest), acquisition from secondary market, company merger & acquisition, first-come / first-served or by government allocation (e.g., public service). License-exempt Spectrum Spectrum that is not assigned to any specific user. One example is the 2.4 Ghz ISM band, where RF devices operate without a formal licensing process. In the USA, license-exempt spectrum is Typically referred to as "unlicensed" spectrum. In this document the terms license-exempt and unlicensed are used interchangeably. Location Based Service An application or device which provides data, information or service to a user based on their location. Master Device A device which queries the WS Database to find out the available operating channels. Protected Entity A licensed user of spectrum, when the licensed spectrum has been assigned as white space spectrum. A primaryA licensed user of white space spectrum which is afforded protection against interference by secondarylicense-exempt white space users (white space devices) for its use in a given area and time. Protected Contour The exclusion area for a Protected Entity, held in the database and expressed as a polygon with geospatial points as the vertices. Slave Device A device which uses the spectrum made available by a master device. TV White Space TV white space refers specifically to radio spectrum which has been allocated for TV broadcast, but is not occupied by a TV broadcast, or other licensed user (such as a wireless microphone), at a specific location and time. White Space Radio spectrum which has been allocated for someprimary useand assigned for licensed use, but is not fully occupied by that primary use licensed use at a specificlocation and time. This spectrum is then assigned by locationlocal regulations for use as licensed-exempt spectrum under control of a white space database. White Space Device (WSD) A device which is a secondarylicense-exempt user of some part of white space spectrum. A white space device can be an access point, base station, a portable device or similar. In this context, a white space device is required to query a database with its location to obtain information about available spectrum. From: ext Gerald Chouinard Date: Tue, 31 Jan 2012 10:07:30 -0500 To: 'Nancy Bravin' Cc: "paws@ietf.org" Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Nancy, This is not that simple. In fact, the qualifiers "license-exempt" and "unlicensed" can apply to more than one thing. If the qualifier applies to a frequency band, different options exist. As an example, in theITU-R context, an "unlicensed" band is typically a new band, say in the 300 GHz, for which no request has been made for its use. It is therefore un-allocated to a specific service so far and thus it is an "unlicensed" frequency band. Once the ITU-R allocates this band to one or many services on a primary or secondary basis, then the administrations can thendecide under what king of regime it will 'assign' this band foroperation. They may decide to allow the use of the band on the basis of licensed operation (with different options to do the assignment: auction, first come/first served, etc.) or allow operation with an exemption of licenses, thus "license-exempt"such as in the 2.4 GHz ISM band. This is also called "unlicensed" in the USA. If thequalifier applies to an operation, the operation can be exempt of license by the local administration, thus a "license-exempt" operation. If, however, someone decides to start an RF transmission operation in a licensed band for which he has no license or in a license-exempt band for which he does not meet the requirements such as operating according to the type of operation for which the band is exempted from a license or he operates outside the technical limitsimposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an "unlicensed" operation. If the qualifier applies to the transmission device, such device may be a "license-exempt" device if its operation does not require a specific license or registration with the local administration such as TV receivers of Wi-Fi devices in the 2.4 GHz ISM band. However, if someone smuggles a device that is not allowed in a country by, for example, buying it on eBay and operates it, this is then an illegal device in the country and id de-facto an "unlicensed" device since it has not passed through the normal certification process. Note that a "license-exempt" device still has to go through a certification process and meet the limits imposed by the local regulator for the "license-exempt" operation in the given frequency band whereas an "unlicensed" device may not pass the certification process since it has not been licensed to operation in the country. This is why the qualifier "unlicensed" has to be treated with care and the footnote will need to be crafted very carefully. With respect to your second point, if an administration only allows "licensed" operation, the situation will be much simpler to manage since specific conditions will be attached to these licenses. Gerald _____ From: Nancy Bravin [mailto:nbravin@earthlink.net] Sent: Tuesday, 31 January, 2012 06:33 To: Gerald Chouinard Cc: Gabor.Bajko@nokia.com; paws@ietf.org Subject: Re: [paws] Discussion on 'license-exempt' vs 'unlicensed' Gabor and Gerald, Since we are dealing on a global basis, can there a footnote to "unlicensed" we can use to indicate that "according to each countries regulatory requirements" How to get around the fact that some Countries are or will be "licensed only" by their gov'ts? Thanks Nancy On Jan 30, 2012, at 4:13 PM, Gerald Chouinard wrote: Gabor, I agree with your proposal. Thisseems to be reasonable. However one needs to be careful with the word'unlicensed' which may mean 'illegal' operation of an RF device in many administrations. Gerald _____ From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] Sent: Monday, 30 January, 2012 17:49 To: gerald.chouinard@sympatico.ca; paws@ietf.org Subject: RE: [paws] Discussion on 'license-exempt' vs 'unlicensed' These look to be very precise definitions, however in everyday use I rarely hear people referring to ISM band as 'license-exempt', in most cases the term 'unlicensed-band' is used. Therefore, may I suggest that the draft will include the following statement: The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing process is needed for RF devices to operate in, such as the ISM band. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard Sent: Monday, January 30, 2012 12:30 PM To: paws@ietf.org Subject: [paws] Discussion on 'license-exempt' vs 'unlicensed' All, Here is my understanding of the terms: Licensed: Spectrum that is acquired by an operator over a given service area for a given time period. This is usually done through auctions (think of the Telcos), beauty contest, first-come / first-served or by government allocation (e.g., public service). Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited service area. The annual license fee is usually small to facilitate the deployment of a service that would not normally be economically attractive. Small local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through auction over large service areas. License-exempt: Operation of RF devices in a frequency band where no formal licensing process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be contacted to clarify it. Unlicensed: Illegal operation of an RF device that can transmit in a frequency band without a duly issued license. In the USA, this term is used to mean "license-exempt," see above. To my knowledge, the term "unlicensed" is used only in the USA to describe a legal operation because the term "license-exempt" has been used for another specific purpose. Since the PAWS addresses the interface to the database for the international market, it should rely on the definition of the terms recognized by the ITU-R. I wouldsuggest the use of 'licensed' and 'license-exempt' with a footnote indicating that the term 'unlicensed' is used in the USA instead of the usual 'license-exempt'. Gerald _______________________________________________ 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 ------=_NextPart_000_00D1_01CCE72C.6177A4F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Peter,

 

I see your point. In my view, = opportunistic use of the spectrum does not necessarily imply that it has to be = license-exempt, it means that the use is limited in time and that the user does not keep = the spectrum assignment beyond its use. Beyond protecting the primary and = secondary operations assigned to the band, such opportunistic use can also be = protected from interference from other lower priority users such as license-exempt = users. This would likely imply a different type of license and it is up to the = local regulators to issue such temporary license.

 

As far as the database is = concerned, the regulator would then need to register such temporary use in the database = so that other devices, such as the license-exempt devices, protect this = operation for the time it is active according to its temporary license. This would = mean a near real-time updating for the database but as far as the protocol to = access such database by the license-exempt master devices, this should be = totally transparent.

 

Gerald

 

From: Peter = Stanforth [mailto:peter@spectrumbridge.com]
Sent: Thursday, 09 = February, 2012 11:08
To: Nancy Bravin; Gerald = Chouinard
Cc: Andy Sago; = paws@ietf.org; John A. Stine
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

I agree = this is a business issue, but there is a DB = potential.

I will give = you some scenarios we deal with often. A construction project requests spectrum = for a time and place in the future. They may only need it for a day or a = month. A sporting or cultural event  wants some spectrum next week for a = day. These are not traditional telco models but they are real scenarios and they absolutely need a certainty that they will get the access they have = requested. We use a spectrum management database and coordination with a primary = user to meet these needs.   Much of the actual coordination is done = manually today – which is time consuming and expensive.I am just pointing out = that assuming that all the world wants is the traditional telco model or an opportunistic unlicensed white space model misses a huge opportunity for = which a database is a key component in automating this and making it = realistic.

 <= /o:p>

From: Nancy = Bravin <nbravin@earthlink.net>
Date: Thu, 9 Feb 2012 = 10:43:15 -0500
To: Gerald Chouinard = <gerald.chouinard@sympatico.= ca>
Cc: Peter Stanforth = <peter@spectrumbridge.com>= , Andy Sago <andy.sago@bt.com>, = "paws@ietf.org" <paws@ietf.org>, "John A. = Stine" <jstine@mitre.org>
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 <= /o:p>

Hi = All, 

 <= /o:p>

In this = discussion are you not discussing business models and use cases such as Jon Stine suggested? That would indicate other models = that

would be = useful in a global sense, and not necessarily a Telco model. Myself, I don't see = many Telco models that feel they have enough spectrum.

 In = one example was the mention of the DOD or other spectrum owners who would allow WS = use /sharing, as long as they could, when = needed,

use the = spectrum as planned which is not often. Many times mostly unused spectrum merely = says "hi" I am here, but its use is rare. I think it is a more = global forward looking approach,

and managed = by the DB's under reg's of what ever country can use this model. It makes a = good business model to lay for the future of white space, as = opposed

to allowing = models not associated with WSDB's at all. Whether you want it in this part = of the protocol, is another question, but it does seem to belong and = further

may allow = for more involvement globally from a business sense, using the = DB's./

 <= /o:p>

My 2 cents = for what it's worth.

 <= /o:p>

SIncerely, = Nancy

 <= /o:p>

 <= /o:p>

On Feb 9, = 2012, at 6:56 AM, Gerald Chouinard wrote:



Peter,

 

I agree.  It depends on how = the term ‘opportunistic’ is being defined. In my view, the qualifier ‘opportunistic’ relates to the use of the spectrum by = devices and not to the availability of the spectrum.  As you describe, the = spectrum may be made available on a deterministic basis but its use by one device = or another is opportunistic since it is managed by a near real-time = database.  For me, a deterministic use of the spectrum is an operator buying = a license for a frequency band for a specific period of time such as 5 = years with the possibility of extending this period. In this case, access to a = database is not required. This is the current Telco = model.

 

The model that you describe seems = to be an opportunistic use model where not only protection of primary and = secondary incumbents would be provided but also absence of interference amongst opportunistic users is also provided, turning it into a temporary = de-facto ‘protected’ service over a given period of time.  This, = to me, is still ‘opportunistic’.  It is just that all means = are taken to make sure that the service is reliable during the given period of = time.

 

If one provides a TVWS database = service and adds to it a coexistence service such as the 802.19.1 approach, you have = more or less the same result.  Such coexistence is however not mandatory = in the TVWS and will depend on the will of the = industry.

 

Gerald

 

From: Peter Stanforth [mailto:peter@spectrumbridge.com<= /a>]
Sent: Wednesday, 08 = February, 2012 18:48
To: Gerald Chouinard
Cc: andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 

Gerald,

It depends = what how we define as opportunistic.  We run a secondary market place for = spectrum, FCC rules allow us to act as a "Spectrum Manager" in this role = we can provide secondary access to devices under whatever criteria the license = holder deems acceptable. We are, in everything but name, providing access to whitespace. In some cases this is opportunistic but in others it is very deterministic and the attraction of the spectrum is because it is deterministic. The key is the owner may not know exactly when or where = theyneed the spectrum in the future but when they make it available it is = guaranteed to be available for the timeframe published. This would not be possible = without a database and yet is clearly not opportunistic. The same could be said = for current US FCC TVWS rules. If we provide a channel list and a = timeframe(Say for the next 4 hours) that channel list will remain available for the = duration.  What is missing, in the case of white space, is that we cannot = deny access to someone else in the same location who asks the same question, = whereas in our secondary marketplace we can. So not only is availability = deterministic access is too. 

Peter = S.

 =

From: Gerald = Chouinard <gerald.chouinard@sympatico.= ca>
Date: Wed, 8 Feb 2012 = 17:46:44 -0500
To: Peter Stanforth = <peter@spectrumbridge.com>=
Cc: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" = <nbravin@earthlink.net>, = "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 =

Peter,

 

See my other email about ‘secondary’ versus = ‘opportunistic’.

 

I agree with you that ‘primary’, ‘secondary’, ‘deterministic and ‘opportunistic’ use of the spectrum has no relevance to = whether the access could be free or paid (after all the primary access to the TV = bands by the broadcasters is free for historical reasons while one coulddecide = that someTVWS access could be paid ;-)  = ).

 

Again, the reason why one needs a = DB accessible over the internet is that the access to the spectrum is ‘opportunistic’.  If this was deterministic, the DB = would not be needed as has been the case up to = now.

 

Gerald

 

From: Peter Stanforth [mailto:peter@spectrumbridge.com<= /a>]
Sent: Wednesday, 08 = February, 2012 12:01
To: Gerald Chouinard;andy.sago@bt.com; nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 =

There is no = reason to assume that use of white space is by licensed exempt or unlicensed = devices. This comes back to an earlier argument I made about what constitutes = licensed and unlicensed?

Again there = is no reason that a license exempt or unlicensed device should get access to = spectrum for "free" any more that a licensed device has to = "pay" for spectrum access.

The concept = of a primary user, who has priority over a secondary user has no relevance to = free or paid access. 

The = rationale for white space is that the spectrum is shared and that someone has primary, preferred or priority access and the database ensures that those rights/requirements are met by anyone who uses the spectrum on a = secondary basis. I would go further and say that the secondary access could be deterministic or opportunistic. There is no reason to require one or the = other, and an argument can be made for both. In a band occupied by a public = safetyuser there may be no choice but to have opportunistic access but in other = bands a primary user may be willing to commit to specific availability if their = own use is deterministic. 

 =

Peter = S.

 =

From: Gerald = Chouinard <gerald.chouinard@sympatico.= ca>
Date: Wed, 8 Feb 2012 = 10:20:52 -0500
To: "andy.sago@bt.com" <andy.sago@bt.com>, "nbravin@earthlink.net" = <nbravin@earthlink.net>, = "paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 =

Andy,

 

To resolve Nancy’s concern, a new definition could be added = for:

 

TVWS White Space devices: White = Space devices that operate in the TV bands.

 

This would complement the = definition of White Space devices and make it more = specific.

 

I am having second thoughts about yoursuggestion to remove the concept of classes of devices from the = White Spacedevices. The opportunistic use of the RF spectrum assumes that = these devices operate while protecting existing operation in the band.  = There is automatically assumes the existence of primary users of the band that = have priority. Such primary users would most likely be licensed to use the = band and it is only the portions that happen to be unused that will be accessible = to the White Space devices.  The latter are unlikely to be licensed to = only use the ‘crumbs’. Removing the concept of license-exempt could = put these new devices at the same level of priority as the primary devices and = then why would they need to protect these ‘primary’ licensed = devices.

 

This would be similar to the = situation in the 2.4 GHz where a database is not needed to protect other devices. As = is well understood, the databases are there to protect primary and possibly = secondary licensed devices from the new opportunistic devices, not opportunistic = devices among themselves. The latter case would be covered by other means such = as adatabase to provide coexistence and this is, I believe, beyond the = scope ofPAWS.

 

Gerald

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] = On Behalf Of andy.sago@bt.com
Sent: Wednesday, 01 = February, 2012 09:58
To: nbravin@earthlink.net; paws@ietf.org
Subject: Re: [paws] Use = cases and requirements I-D: sections 1to 3 (Introduction, Conventions and = Terminology, Prior Work)

 =

Nancy= , all

 =

Good = questions. I’m not proposing to remove references to TVWS, they are entirely appropriate within the use cases since it is the TV bands we are = studying as first candidate for opportunistic access, but the charter says we are addressing all white space in the resulting protocol. To answer your = other questions, IMO our aim should be to provide all the necessary = information in this PAWS requirements I-D to enable the PAWS protocol I-D to be = developed. I don’t think it’s our job to explain different regulatory = regimes or applications (beyond use cases) in this document, ITU and others do this = very well, and regulators tend to be well coordinated or play ‘follow = my leader’.

 =

Thanks for = pointing out the reference to licence-exempt that I had missed in 4.4 -  I = think the meaning would be just the same with ‘in a license-exempt TVWS environment’ deleted from that sentence. That would be my = suggestion.

 =

Regards

 =

Andy

 =

From: Nancy Bravin [mailto:nbravin@earthlink.net]
Sent: 01 February 2012 = 14:48
To: Sago,AJ,Andy,COD = R
Cc: paws@ietf.org
Subject: Fwd: [paws] Use = cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and = Terminology, Prior Work)

 =

Hi Andy, also, = throughout the document TVWS are mentioned in 4.1,4.5, 4.6…so if you propose to = remove any reference to TVWS it will = affect

the document as a = whole, and information that seems necessary to explain how the DB and protocol = interacts with TVWS devices = and

the methods of = doing so. One can envision that current rules could change, but, why not give the = information on both for countries to understand = fully

=

what it's choices = are? 

 =

Thanks Andy, just = some early morning thoughts…Sincerely, Nancy

 =

Begin forwarded = message:<= /p>

 =

From: Nancy Bravin <nbravin@earthlink.net>

Date: February 1, 2012 6:35:09 AM PST

To: Andy Sago <andy.sago@bt.com>

Subject: Re: [paws] Use cases and requirements I-D: = sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 =

Hi Andy, = All

 =

In section 4.4, = license exempt is also mentioned as = well. 

I am conflicted in = a global sense when emerging countries, or countries with very different types of = gov't want to = implement=

the protocol, will = they have enough information to do so? and thereby join the existing DB companies, = orwill they do their own = thing

=

leaving holes in = what one hopes will be an interoperable global protocol that deals with TVWS, and/orWhite spaces in = general?<= /p>

 =

Thanks, just a = thought.<= /p>

 =

SIncerely, = Nancy

 =

 =

On Feb 1, 2012, at = 2:34 AM, <andy.sago@bt.com> <andy.sago@bt.com> = wrote:

 =

Scott, = All

 

I agree = with Jussi that we have now narrowed the definition to apply to TV white spaces, = whereas the scope of PAWS is white spaces in general. I would question not only whythelower-priority service would always be licence-exempt, but why the = higher priority service would always be licenced. To avoid this issue on 27th = Jan I proposed (= http://www.ietf.org/mail-archive/web/paws/current/msg00576.html) a revision of the Abstract that avoids the terms licence exempt or = unlicensed, or any mention of the regulatory status of the incumbent services. The = Abstract derives from the Introduction and the text could be aligned to be the = same in the Introduction, with “opportunistic” replacing “secondary” in later sentences in the Introduction. I have = checked and there are no further references to licensing in the document, so we don’t need the definitions of licence exempt, light licensing or unlicensed. This is not a regulatory document – we are defining requirements fora protocol. Keep it simple.

 

That just = leaves the definition of white space, where the existing spectrum use has now got = muddled with the potential for opportunistic use. This can be fixed by taking = the white space and white space device definitions together.  From Scott, = Gerald and Jussi’s comments perhaps we could agree on:

 

White Space = (WS)

 <= /font>

Radio = spectrum which is not fully occupied at a specific location and = time.

 <= /font>

White Space = device

 <= /font>

A device = which opportunistically uses some part of the white space spectrum, under = control of a white space database.  A white space device can be an access = point, base station, a portable device or similar.  In this context, a white spacedevice is required by local regulations to query a database with = its location to obtain information about available = spectrum.

 

Regards

 

Andy<= /font>

 

From: = paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of jussi.kahtava@nokia.com
Sent: 01 February 2012 07:31
To: gerald.chouinard@sympatico.= ca; scott.probasco@nokia.com; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 =

That = statement is valid for TV White Spaces on UHF frequencies but does not necessarily = apply to all under-utilised radio spectrum. Why would the lower priority service = by default be licence-exempt?

 

Kind = regards,

Jussi=

 

From: = paws-bounces@ietf.org [mailto:paws-bounces@i= etf.org] On Behalf Of ext = Gerald Chouinard
Sent: 31 January 2012 22:33
To: Probasco Scott = (Nokia-CIC/Dallas); paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 =

Scott,

 

Very good improvements. I would = suggest to insert the notion of opportunistic use of the spectrum by white space = devices in the last sentence of the definition of “white space” as = follows:

 

White = Space

 <= /font>

Radio = spectrum which has been allocated and assigned for licensed use, but is not fully occupied = by that licensed use at a specific location and time. This spectrum is then <delete>assigned<delete> <insert>allowed<insert> bylocal regulations <delete>for use<delete> <insert>to = beused opportunistically<insert> as licensed-exempt spectrum under = control of a white space database.</Insert>

 

This way, it is understood that the database does not “assign” white space devices for them to = choose from.

 

Gerald

From: = scott.probasco@nokia.com [mailto:scott.proba= sco@nokia.com] 
Sent: Tuesday, 31 January, 2012 = 15:12
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: Re: [paws] Use cases and = requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 =

Hi = Gerald,

 <= /font>

Good to avoid overloading the term "secondary". I have made additional = proposed changes to the text below based on your suggestion. "Lower priority opportunistic service" could indeed by used, but I am guessing that = we would need some explanation of what that means. Since we now have = descriptions of licensed spectrum and license-exempt spectrum, I used these words. Do = these changes remove your concerns?

 <= /font>

I also = corrected "location" to "local" in previous text proposed for "White Space".

 <= /font>

Kind = Regards,

Scott

 <= /font>

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 14:41:36 -0500
To: Scott <scott.probasco@nokia.com>= , "paws@ietf.org" <paws@ietf.org>
Subject: RE: [paws] Use cases and requirements I-D: sections 1 to 3 (Introduction, Conventions and Terminology, Prior = Work)

 

= Scott,

= Great proposal.  However, I am still a bit nervous about the definitions = of “Protected Entity” and “White Space Devices = (WSD)” where the notion of secondary use is included.  The secondary = status is used in the ITU-R Radio Regulations for a different purpose.  In = fact, it is possible that a band has already primary and secondary services allotted = to it and that the White Space operation is a tertiary opportunistic = operationwhere the two first types ofservices are not being used.  The use of “lower priority opportunistic” service rather than “secondary” service would be preferable to describe white spaceallocations.

=  

= Gerald

=  

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of scott.probasco@nokia.com
= Sent: Tuesday, 31 January, 2012 13:56
To: paws@ietf.org
Subject: Re: [paws] Use cases and requirements I-D: sections 1 to 3 = (Introduction, Conventions and Terminology, Prior Work)

 

Hi,

 

I changed the subject line from " Re: [paws] Discussion on = 'license-exempt' vs 'unlicensed'  ". Here I try to propose some changes to the = draft based on the email discussion.

 

Below is a copy of chapter 2.2. Terminology. I have inserted new terms for = 'licensed' and 'license-exempt' and made changes to the term 'white space'. I have = tried to work from the perspective that the document should accurately explain = the subject with aim that a reader can understand the use cases and the = subsequent requirements. No doubt we could include much more text on this topic of spectrum allocation, assignment, licensing and = usage.

 

I hope this captures the key points of the discussion. Please do reply if something is still missing.

 

Kind Regards,

Scott

 

 

2.2.  Terminology

 

   Database

 

      In the context of white space and cognitive radio = technologies,

      the database is an entity which contains current = information about

      available spectrum at any given location and other types = of

      information.

 

   Device ID

 

      A unique number for each master device and slave device = that

      identifies the manufacturer, model number and serial = number.

 

<Insert>

   Licensed Spectrum

 

      Spectrum that is acquired by an operator over a given = service area

      for a given time period.  This is usually done through auctions,award

      (beauty contest), acquisition from secondary market, = company merger &

      acquisition,  first-come / first-served or by = government allocation

      (e.g., public service).

 

   License-exempt Spectrum

 

      Spectrum that is not assigned to any specific user. One = example is the 2.4 Ghz ISM band, where RF devices

      operate without a formal licensing process. In the USA, license-exempt spectrum is

      Typically referred to as "unlicensed" spectrum. = In this document the terms

      license-exempt and unlicensed are used = interchangeably.

 

</Insert>

 

   Location Based Service

 

      An application or device which provides data, information = or

      service to a user based on their = location.

 

  Master Device

 

      A device which queries the WS Database to find out the = available

      operating channels.

 

   Protected Entity=

 

      <Insert>A licensed user of spectrum, when the = licensed spectrum has been assigned as white space spectrum.</Insert> <Delete>A primary</Delete><Insert>A = licensed</Insert> user of white space spectrum <Delete>which</Delete> is = afforded

      protection against interference by <Delete>secondary</Delete><Insert>license-exempt white space</Insert> users <Delete>(white = space

      devices) for its use</Delete> in a given area and = time.

 

   Protected Contour

 

      The exclusion area for a Protected Entity, held in the = database

      and expressed as a polygon with geospatial points as the = vertices.

 

  Slave Device

 

      A device which uses the spectrum made available by a = master

      device.

 

   TV White Space

 

      TV white space refers specifically to radio spectrum which = has

      been allocated for TV broadcast, but is not occupied by a = TV

      broadcast, or other licensed user (such as a wireless = microphone),

      at a specific location and time.

 

   White Space

 

      Radio spectrum which has been allocated <Delete>for someprimary use</Delete><Insert>and assigned for licensed use</Insert>, but

      is not fully occupied by that <Delete>primary use</Delete><Insert> licensed use </Insert> at a specificlocation=

      and time. <Insert>This spectrum is then assigned by <Delete>location</Delete><Insert>local</Insert> regulations for use as licensed-exempt spectrum under control of a white = space database.</Insert>

 

   White Space Device (WSD)

 

     A device which is a = <Delete>secondary</Delete><Insert>license-exempt</In= sert> user of some part of white space

      spectrum.  A white space device can be an access = point, base

      station, a portable device or similar.  In this = context, a white

      space device is required to query a database with its = location to

      obtain information about available = spectrum.

 

 

 

From: ext Gerald Chouinard <gerald.chouinard@sympatico.= ca>
Date: Tue, 31 Jan 2012 10:07:30 -0500
To: 'Nancy Bravin' <nbravin@earthlink.net>
Cc: "paws@ietf.org" = <paws@ietf.org>
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

= Nancy,

=  

= This is not that simple.  In fact, the qualifiers = “license-exempt” and “unlicensed” can apply to more than one = thing.

=  

= If the qualifier applies to a frequency band, different options exist. As an = example, in theITU-R context, an “unlicensed” band is typically a new = band, say in the 300 GHz, for which no request has been made for its = use.  It is therefore un-allocated to a specific service so far and thus it is an “unlicensed” frequency band. Once the ITU-R allocates this = band to one or many services on a primary or secondary basis, then the = administrations can thendecide under what king of regime it will ‘assign’ = this band foroperation. They may decide to allow the use of the band on the basis = of licensed operation (with different options to do the assignment: = auction, first come/first served, etc.) or allow operation with an exemption of = licenses, thus “license-exempt”such as in the 2.4 GHz ISM band. This is = also called “unlicensed” in the USA.

=  

= If thequalifier applies to an operation, the operation can be exempt of = license by the local administration, thus a “license-exempt” operation. = If, however, someone decides to start an RF transmission operation in a = licensed band for which he has no license or in a license-exempt band for which = he does not meet the requirements such as operating according to the type of = operation for which the band is exempted from a license or he operates outside the technical limitsimposed by this license-exempt ruling, his operation is therefore illegal and he is then considered to be running an “unlicensed” operation.

=  

= If the qualifier applies to the transmission device, such device may be a “license-exempt” device if its operation does not require a specific license or registration with the local administration such as = TV receivers of Wi-Fi devices in the 2.4 GHz ISM band.  However, if = someone smuggles a device that is not allowed in a country by, for example, = buying it on eBay and operates it, this is then an illegal device in the country = and id de-facto an “unlicensed” device since it has not passed = through the normal certification process.

=  

= Note that a “license-exempt” device still has to go through a certification process and meet the limits imposed by the local regulator = for the “license-exempt” operation in the given frequency band = whereas an “unlicensed” device may not pass the certification process = since it has not been licensed to operation in the = country.

=  

= This is why the qualifier “unlicensed” has to be treated with care = and the footnote will need to be crafted very carefully.

=  

= With respect to your second point, if an administration only allows “licensed” operation, the situation will be much simpler to = manage since specific conditions will be attached to these = licenses.

=  

= Gerald

=  

From: Nancy Bravin [mailto:nbravin@earthlink.net] 
Sent: Tuesday, 31 January, 2012 06:33
To: Gerald Chouinard
Cc: Gabor.Bajko@nokia.com; paws@ietf.org
Subject: Re: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

Gabor and = Gerald, 

Since we are = dealing on a global basis, can there a footnote to "unlicensed" we can use = to indicate that "according to each countries regulatory = requirements"  

How to get = around the fact that some Countries are or will be "licensed only" by = their gov'ts?  Thanks

Nancy

On Jan 30, 2012, = at 4:13 PM, Gerald Chouinard wrote:






= Gabor,

=  

= I agree with your proposal.  Thisseems to be reasonable.  However one = needs to be careful with the word‘unlicensed’ which may mean ‘illegal’ operation of an RF device in many = administrations.

=  

= Gerald

=  

From: Gabor.Bajko@nokia.com [mailto:Gabor.Bajko@nokia.com] 
Sent: Monday, 30 January, 2012 17:49
To: gerald.chouinard@sympatico.= ca; paws@ietf.org
Subject: RE: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

These look to be very precise definitions, however in everyday use I rarely = hear people referring to ISM band as ‘license-exempt’, in most = cases the term ‘unlicensed-band’ is used.

 

Therefore, may I suggest that the draft will include the following = statement:

 

The terms unlicensed and license-exempt spectrum are used in this document interchangeably and refer to a spectrum in which no formal licensing = process is needed for RF devices to operate in, such as the ISM = band.

 

-      = ;    Gabor

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Gerald Chouinard
Sent: Monday, January 30, 2012 12:30 PM
To: paws@ietf.org
Subject: [paws] Discussion on 'license-exempt' vs = 'unlicensed'

 

All,

 

= Here is my understanding of the terms:

=  

= Licensed: Spectrum that is acquired by an operator over a given service area for a = given time period.  This is usually done through auctions (think of the = Telcos), beauty contest, first-come / first-served or by government allocation = (e.g., public service).=

=  

= Lightly licensed: Special case where thefrequency allocation is done through first-come / first-served process for a given time frame over a relatively limited = service area. The annual license fee is usually small to facilitate the = deployment of a service that would not normally be economically attractive.  Small = local operators would be interested by this (e.g., rural broadband in Canada) and not big Telcos thatwould normally work with full licensing through = auction over large service areas.

=  

= License-exempt: Operation of RF devices in a frequency band where no formal licensing = process is needed such as in the 2.4 GHz ISM band. In the USA, this term is used for a specific type of operation. The FCC should be = contacted to clarify it.

=  

= Unlicensed: Illegal operation of an RF device that can transmit in a frequency band = without a duly issued license.  In the USA, this term is used to mean “license-exempt," see = above.

=  

= To my knowledge, the term “unlicensed” is used only in the USA to describe a legal operation = because the term “license-exempt” has been used for another specific = purpose.

=  

= Since the PAWS addresses the interface to the database for the international = market, it should rely on the definition of the terms recognized by the ITU-R. I wouldsuggest the use of ‘licensed’ and = ‘license-exempt’ with a footnote indicating that the term ‘unlicensed’ is = used in the USA instead of the usual ‘license-exempt’.

=  

= Gerald

_______________________________________________
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

 =

 =

 <= /o:p>

------=_NextPart_000_00D1_01CCE72C.6177A4F0-- From Gabor.Bajko@nokia.com Thu Feb 9 11:57:45 2012 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 03CCB21E8057 for ; Thu, 9 Feb 2012 11:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.877 X-Spam-Level: X-Spam-Status: No, score=-2.877 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3Hgu3Gw2jzD for ; Thu, 9 Feb 2012 11:57:44 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id E341B21E8056 for ; Thu, 9 Feb 2012 11:57:43 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q19JvgcS021841 for ; Thu, 9 Feb 2012 21:57:43 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Feb 2012 21:57:42 +0200 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.5]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Thu, 9 Feb 2012 20:57:41 +0100 From: To: Thread-Topic: Paris remote participation Thread-Index: AcznZExuRYMOJ6k1S7qj/PFzWFf1NQ== Date: Thu, 9 Feb 2012 19:57:40 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601DF122C@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.21.95.63] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DF122C008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2012 19:57:42.0094 (UTC) FILETIME=[153D16E0:01CCE765] X-Nokia-AV: Clean Subject: [paws] Paris remote participation 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, 09 Feb 2012 19:57:45 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DF122C008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I have requested for one 2.5h slot in the Paris meeting. I am wondering how many remote participants and from what timezones we can = expect to have. Last time in the Taipei meeting we had quite a few remote p= articipants. If there will be remote participants, I'll ask for the Meetech= o web collaboration tool support. Thanks, Gabor --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DF122C008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I have requested for one 2.5h slot in the Paris meet= ing.

I am wondering how many remote participants and from= what timezones we can expect to have. Last time in the Taipei meeting we h= ad quite a few remote participants. If there will be remote participants, I= ’ll ask for the Meetecho web collaboration tool support.

 

Thanks, Gabor

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601DF122C008AM1MPN1006mg_-- From paul@marvell.com Thu Feb 9 13:36:41 2012 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 39FAB21F865E for ; Thu, 9 Feb 2012 13:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.404 X-Spam-Level: X-Spam-Status: No, score=-6.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ4SWVOrTvAt for ; Thu, 9 Feb 2012 13:36:40 -0800 (PST) Received: from na3sys009aog113.obsmtp.com (na3sys009aog113.obsmtp.com [74.125.149.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3B921F865D for ; Thu, 9 Feb 2012 13:36:40 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob113.postini.com ([74.125.148.12]) with SMTP ID DSNKTzQ8ZP+yVx7zXC4IpFh07jU+N7AiE8aD@postini.com; Thu, 09 Feb 2012 13:36:40 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Thu, 9 Feb 2012 13:32:23 -0800 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" Date: Thu, 9 Feb 2012 13:32:22 -0800 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAHW0EAgAB73KCAAMPrgIAAvpPQ Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4FE7B@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4FBE3@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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 09 Feb 2012 21:36:41 -0000 >The list in the current threat models text that I proposed is by no >means >exhaustive=A9 Or intended to be. The intent is to derive a key set of >security requirements for the protocol. The focus is on those threats >that >are relevant to the device-2-database protocol rather than to the much >more expansive topic of white space technology. Yes, but ... Without determining if there are technical mitigation mechanisms we should = not be rejecting threats. The threats should all be examined and we should= explicitly determine what is in scope versus unilaterally as part of the e= diting process. As an interesting example - if there is a natural disaster, should there be= protocol mechanisms to enable use of emergency services without direct Int= ernet connectivity to the DB? Loss of service (emergency and normal) usage of WS is a threat that should = be listed and may or may not be addressed by technical or procedural mechan= isms. =20 Paul From scott.probasco@nokia.com Fri Feb 10 08:19:06 2012 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 9EB1B21F86F2 for ; Fri, 10 Feb 2012 08:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjBW2nj4G1yN for ; Fri, 10 Feb 2012 08:19:05 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id B022121F86F1 for ; Fri, 10 Feb 2012 08:19:04 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1AGIuTl018990; Fri, 10 Feb 2012 18:18:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 18:18:56 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Fri, 10 Feb 2012 17:18:56 +0100 From: To: , , Thread-Topic: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) Thread-Index: AQHM6A+vyCTX+hz1fUy/W/y9ZWc5fw== Date: Fri, 10 Feb 2012 16:18:55 +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.14.0.111121 x-originating-ip: [10.241.49.205] Content-Type: text/plain; charset="us-ascii" Content-ID: <2F44586AB2F41E42B087405D54AC1624@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2012 16:18:56.0505 (UTC) FILETIME=[B030E690:01CCE80F] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) 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, 10 Feb 2012 16:19:06 -0000 Hi, Thank you Gerald, Rex and Paul for the review and comments. The completed PAWS standard will support white space deployment of multiple radio standards. In this case I believe it makes sense to try and use terminology which is not specific to a particular radio technology. Kind Regards, Scott On 2/9/12 9:09 AM, "ext Gerald Chouinard" wrote: >Paul, > >802.11af is designed to address other use cases that the Wide-area or >rural >broadband access case. > >Gerald > > >-----Original Message----- >From: Paul Lambert [mailto:paul@marvell.com] >Sent: Wednesday, 08 February, 2012 21:28 >To: Rex Buddenberg; Gerald Chouinard >Cc: paws@ietf.org >Subject: RE: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet >broadbandaccess) > >>The way out of this circle is to again ape IEEE 802.16. The device in >>the middle is known as RS, short for relay station. > >Why copy terms from a dying standard ... versus using 802.11af >terminology? > > > >Paul > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Fri Feb 10 08:19:06 2012 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 9EB8B21F86FC for ; Fri, 10 Feb 2012 08:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkPiLD63Nt2y for ; Fri, 10 Feb 2012 08:19:05 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 920F421F86E4 for ; Fri, 10 Feb 2012 08:18:57 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1AGItmK027555; Fri, 10 Feb 2012 18:18:55 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.21]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 18:18:54 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-012.mgdnok.nokia.com ([65.54.30.21]) with mapi id 14.01.0355.003; Fri, 10 Feb 2012 17:18:54 +0100 From: To: , Thread-Topic: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) Thread-Index: AQHM5q+lCX/7ce/YikW1Wo/ekw40kpYzh44AgAES5gCAAUIygA== Date: Fri, 10 Feb 2012 16:18:53 +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.14.0.111121 x-originating-ip: [10.241.49.205] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2012 16:18:54.0947 (UTC) FILETIME=[AF432B30:01CCE80F] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) 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, 10 Feb 2012 16:19:06 -0000 Hi, Thank you Gerald and Rex for the review and comments. Regarding updating the geolocation of the slave at the master device, and question if this is in scope of PAWS, I propose we could accept Gerald's corrections to steps 8 & 11. If this function is indeed out of scope for PAWS then I believe we will find there are no related requirements identified to be included in section 6. Regarding the relay concept, this is included in the "Rapid deployed network for emergency scenario" use case, see Figure 7 in v-02. As this will allow for appropriate requirements to be identified and included in section 6, are you okay to not include this in the Wide-area use case? Kind Regards, Scott On 2/9/12 9:05 AM, "ext Gerald Chouinard" wrote: >Rex, > >See my comments below. > >Gerald > >-----Original Message----- >From: Rex Buddenberg [mailto:budden@nps.navy.mil] >Sent: Wednesday, 08 February, 2012 17:42 >To: Gerald Chouinard >Cc: scott.probasco@nokia.com; paws@ietf.org >Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet >broadbandaccess) > >namecalling nits below.... > >On Wed, 2012-02-08 at 17:16 -0500, Gerald Chouinard wrote: >> Scott, >>=20 >> I agree with your proposed changes except for items 8 and 11. >>=20 >> In the case of the Wide-area or Rural internet broadband access, the >> geolocation of each slave device needs to be provided to the base >>station >so >> that it can query the DB for the channel availability at each slave >> location. These slave devices could be located as far as 30 km, thus >>not >> sharing the same location as the base station as far as querying for the >> available channels. > >IEEE 802 uses the terms _base station_ (BS) and _subscriber station_ >(SS) (not slave). >[Gerald] 802.22 uses base station (BS) and customer premise equipment >(CPE) >>=20 >> The network topology here is a point-to-multipoint star model (i.e., a >> slave, once it knows its available channels, is not supposed to go on >>its >> own and operate on any of these channels, it will continue to operate on >the >> same channel as that of the base station since it is part of this star >> network and needs to be in contact with the base station). > >In a pure IEEE 802.16 notion, this is entirely correct. > >> If a slave device >> were to operate on a different channel in a peer-to-peer fashion, it >>would >> also have to stay in touch with the master/BS and thus have double modem >> construction to operate on both channels at the same time. Such >peer-to-peer >> topology is not part of this use case. > >But it is part of several standards and associated technologies. IEEE >802.16j (now that it's ratified, correctly termed IEEE 802.16-2009) >comes to mind. >[Gerald] In such case, a new use case for peer-to-peer and mesh networking >for Wide-area and rural broadband access would need to be developed. This >use case was developed for point-to-multipoint topology. > >>=20 >> In this model, the slave device does not need to know the list of >available >> channels, it only needs to know its operating channel which has to be >>the >> same as that of the base station and a few backup channels so that, if >>the >> current operating channels is to be freed by the base station, upon a >> trigger from the base station to move out of the channel, the slave >>device >> knows where to fall back to continue operating with the base station. >This >> way, the short time to free the channel to avoid interference to the >> incumbent can be met while the communication with the base station can >> continue in a transparent way to the terminal user. > >The way out of this circle is to again ape IEEE 802.16. The device in >the middle is known as RS, short for relay station. >Further there's a lot of 'mesh' talk where all stations would be >peers. =20 >In both cases, the RS or the peers would have to assume the >responsibility of a BS. >[Gerald] Again, a new use case would need to be developed to cover this >case. As a result, the model for the PAWS would still be the BS acting as >the master and its associated terminals being the slaves. >=20 >>=20 >> The base station, however, needs to query the DB for each and every of >>its >> slave devices so that it can find the cross-section of all the available >> channels returned by the DB for all its slave devices which will define >the >> channels that can be used by all the slave devices (i.e., available to >>the >> BS and all its slave devices) and this will constitute the list of the >> operating channel and the backup channels that the BS needs to signal to >its >> slave devices. This is the common list of channels that needs to be >>sent >to >> the slave devices, not the list of available channels for each device >coming >> from the DB. >>=20 >> As a consequence, The text in item 8 should stay as is except for >>changing >> "BS" for "Master/BS" if it is needed for consistency. >>=20 >> With respect to item 11, here is what I would suggest: >>=20 >> 11. The slave or user device must transmit its new geographic location >> every time it changes so that the repeated process described under item >>10 >> for the master/BS can rely on the most up-to-date geolocation of the >>slave >> or user device. >>=20 >> One could also argue that this function of updating the geolocation >> information of the slave at the master/BS is nor related to the protocol >to >> be developed and is therefore beyond the scope of PAWS. >>=20 >> Respectfully, >>=20 >> Gerald >>=20 >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> scott.probasco@nokia.com >> Sent: Wednesday, 08 February, 2012 12:55 >> To: paws@ietf.org >> Subject: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet >> broadbandaccess) >>=20 >> Hello All, >>=20 >> As editors of the problem statement, use cases & requirements draft we >>are >> attempting to prepare a completed draft which could be ready for working >> group last call before IETF83. In the coming days we will post the >> sections of the draft to the mailing list. Our request is that you >>review >> these sections and reply to the email with any comments. >>=20 >> Below is the text for section on the Wide-Area or Rural use case (new >> section numbering is NOT shown, all use cases will be moved to section >>4.2 >> Use cases in the next version). This text has been marked up from >> version-02 as uploaded January 26, 2012 as follows: >>=20 >> * include applicable comments from Hotspot use case >>=20 >>=20 >> Our goal is that any discussion on this text will conclude by February >>15. >> To be clear, approval of the document will go through the normal process >> of last calls etc.. We are simply asking for your assistance in >>preparing >> a complete & accurate document that could progress the work. So please >> review the text and send your comments either directly to the editor or >>to >> the mailing list. >>=20 >> Kind Regards, >> Raj & Scott >>=20 >>=20 >>=20 >> 4.4. Wide-Area or Rural internet broadband access >>=20 >> In this use case, internet broadband access is provided as a Wide- >> Area Network (WAN) or Wireless Regional Area Network (WRAN). A >> typical deployment scenario is a wide area or rural area, where >> internet broadband access is provided to local businesses and >> residents from a master (i.e. BS) connected to the internet. This >> deployment scenario is typically characterized by one or more >> Fixed master(s)/BS(s), cells with relatively large radius (tens of >> kilometers, up to 100 km), and a number of available radio >> channels. Some of the masters/BSs may be deployed and operated by >> a single entity, i.e. there can be centralized coordination >> between these masters/BSs, whereas other masters/BSs may be >> deployed and operated by operators competing for the radio >> channels in a license-exempt TVWS environment where decentralized >> coordination using the air-interface would be required. The BS in >> this scenario use a TDD radio technology and transmit at or below >> a transmit power limit established by the local regulator. Each >> base station has a connection to the internet and >>may >> provides >> internet connectivity to multiple slave/end-user devices. End >> user terminals or devices may be fixed or portable. >>=20 >> The figure below shows an example deployment of this scenario. >>=20 >> ------- >> |Slave|\ \|/ ---------- >> |Dev 1| (TDD AirIF) | |Database| >> ------- \ | .---. /---------- >> o \ |-|---------| ( ) / >> o | Master | / \ >> o / | (BS) |=3D=3D=3D=3D=3D=3D=3D=3D( Inte= rnet ) >> o / |-----------| \ / >> ------- (TDD AirIF) ( ) >> |Slave| / (----) >> |Dev n| >> ------- >>=20 >>=20 >> Figure 4: Rural internet broadband access using TV white space >> spectrum >>=20 >> Once the master/BS has been professionally installed and configured, >> a simplified power up and operation scenario utilizing TV White Space >> to provide rural internet broadband access consists of the following >> steps: >>=20 >> 1. The master/BS powers up; however its WS radio and all other WS >> capable devices will power up in idle/listen only mode (No active >> transmissions on the WS frequency band) >>=20 >> 2. The master/BS has internet connectivity , determines its >> location (either from location determination capability or from saved >> value that was set during installation), and establishes a >> connection to a trusted white space database (see use >> case "TVWS >> database discovery" above). >>=20 >> 3. The master/BS registers its geolocation, address, contact >> information, etc. associated with the owner/operator of the >> master/BS with the trusted database service (if >> not currently >> registered, see Section 4.2reference is to >> registration, will be updated in next version). Meanwhile the >> DB administrator may >> be required to store and forward the registration information to >> the regulatory authority. If a trusted white space database >> administrator is not discovered, further operation of the WRAN >> may be allowed according to local regulator policy (in this case >> operation of the WRAN is outside the scope of the PAWS protocol). >>=20 >> 4. Following the successful registration process, >>the >> master/BS will send a >> query to the trusted database requesting a list of available WS >> channels based upon its geolocation. The complete set of >> parameters to be provided from the master to the database is specified >> by the local regulator. Parameters may include WSD location, accuracy of >> of that location, device antenna height, device identifier of a slave >> device requesting channel information. >>=20 >>=20 >> 5. If the master/BS has been previously authenticated, the database >> responds with a list of available white space channels that may >> be used and optionally a maximum transmit power (EIRP) for each >> channel and a duration of time the channel may >>be >> used or a notification of any additional requirement for >> sensing. >>=20 >> 6. Once the master/BS authenticates the WS channel list response >> message from the database, the master/BS selects an available WS >> channel(s) from the list. The operator may disallow some >> channels from the list to suit local needs if required. >>=20 >> 7. The slave or user device scans the TV bands to locate a WRAN >> transmission, and associates with the master/BS.insert >> new step >>=20 >> 8. The slave/user >> device provides its geolocation to the BS which, in >> turn, queries >> the databasemaster for a list >>of >> channels available at the slaves' >> Geolocation providing to the master the slave's Device ID >> and optionally its geolocation.. >>=20 >> 9. Once this list of available channels is received from the >> database by the master, the latter will decide, based on the list >> of available channels for all its other associated slaves whether >> it should continue operation on its current channel or change >> channel to accommodate the new slave in case this channel is not >> available at its location. The master will notify all its >> associated slaves/user devices of the new channel to move to if >> operation needs to change channel. If the channel that the user >> terminal is currently using is not included in the list of >> locally available channels, the master will drop its association >> with the slave/user device so that it ceases all operation on its >> current channel and indicate the new operating channel before >> dropping the link if a change has been decided. The slave/user >> device may move to the indicated new channel if so indicated or >> scan for another WRAN transmission on a different channel. >>=20 >> >> 10. The master/BS must periodically repeat the process to request a >> channel list from the database, steps 4 through 6 above. The frequency >> to repeat the process is determined by the local regulator. If the >> response from the database indicates a channel being used by the >> master/BS is not available, the master/BS must stop transmitting on that >> channel immediately. >>=20 >> 11. The slave or user device must periodically repeat the process to >> request a channel list from the master/BS, steps 8 and 9 above. The >> frequency to repeat the process is determined by the local regulator. If >> the response from the master/BS indicates that a channel being used by >> the slave or user device is not available, the slave or user device must >> stop transmitting on that channel immediately. >> >>=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 > > > From Basavaraj.Patil@nokia.com Fri Feb 10 10:10:05 2012 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 F0CA421F87B8 for ; Fri, 10 Feb 2012 10:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.224 X-Spam-Level: X-Spam-Status: No, score=-103.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hGx2ipTsNce for ; Fri, 10 Feb 2012 10:10:04 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5980F21F87B7 for ; Fri, 10 Feb 2012 10:10:02 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1AI9w3W014869; Fri, 10 Feb 2012 20:09:59 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 20:09:58 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Fri, 10 Feb 2012 19:09:57 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAHW0EAgAB73KCAAMPrgIAAvpPQgADl8oA= Date: Fri, 10 Feb 2012 18:09:57 +0000 Message-ID: In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4FE7B@SC-VEXCH2.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [173.74.226.51] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <2EF4AC83D00C494D94E1AE68E9C2F2C7@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2012 18:09:58.0493 (UTC) FILETIME=[330B98D0:01CCE81F] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 10 Feb 2012 18:10:05 -0000 HI Paul, On 2/9/12 3:32 PM, "ext Paul Lambert" wrote: > >>The list in the current threat models text that I proposed is by no >>means >>exhaustive=A9 Or intended to be. The intent is to derive a key set of >>security requirements for the protocol. The focus is on those threats >>that >>are relevant to the device-2-database protocol rather than to the much >>more expansive topic of white space technology. > >Yes, but ... > >Without determining if there are technical mitigation mechanisms we >should not be rejecting threats. The threats should all be examined and >we should explicitly determine what is in scope versus unilaterally as >part of the editing process. No doubt. I don't think there is any unilateral proposal here. I am happy to incorporate all relevant threats through the consensus process and discussion on the mailing list. The threat model has evolved from Rev 1 to Rev 4 as a result of feedback from you and others. > >As an interesting example - if there is a natural disaster, should there >be protocol mechanisms to enable use of emergency services without direct >Internet connectivity to the DB? Would you consider this as a threat or a feature that the protocol needs to be concerned with regarding reachability of the database? > >Loss of service (emergency and normal) usage of WS is a threat that >should be listed and may or may not be addressed by technical or >procedural mechanisms. If you can elaborate or (preferably) provide the text describing the threat and consequences, I would be happy to include it. -Raj > >Paul From gerald.chouinard@sympatico.ca Fri Feb 10 10:59:35 2012 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 0095921F8814 for ; Fri, 10 Feb 2012 10:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.49 X-Spam-Level: * X-Spam-Status: No, score=1.49 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_50=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_46=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04kvYbQf4Bj1 for ; Fri, 10 Feb 2012 10:59:33 -0800 (PST) Received: from blu0-omc3-s7.blu0.hotmail.com (blu0-omc3-s7.blu0.hotmail.com [65.55.116.82]) by ietfa.amsl.com (Postfix) with ESMTP id 946C821F880B for ; Fri, 10 Feb 2012 10:59:33 -0800 (PST) Received: from BLU0-SMTP83 ([65.55.116.72]) by blu0-omc3-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 10:59:32 -0800 X-Originating-IP: [70.26.236.41] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([70.26.236.41]) by BLU0-SMTP83.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 10:59:31 -0800 From: Gerald Chouinard To: References: Date: Fri, 10 Feb 2012 13:59:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHM5q+lCX/7ce/YikW1Wo/ekw40kpYzh44AgAES5gCAAUIygIAAogQQ In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 10 Feb 2012 18:59:31.0806 (UTC) FILETIME=[1F4727E0:01CCE826] Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) 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, 10 Feb 2012 18:59:35 -0000 Scott, Fine with me. Gerald -----Original Message----- From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: Friday, 10 February, 2012 11:19 To: gerald.chouinard@sympatico.ca; budden@nps.navy.mil Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet broadbandaccess) Hi, Thank you Gerald and Rex for the review and comments. Regarding updating the geolocation of the slave at the master device, and question if this is in scope of PAWS, I propose we could accept Gerald's corrections to steps 8 & 11. If this function is indeed out of scope for PAWS then I believe we will find there are no related requirements identified to be included in section 6. Regarding the relay concept, this is included in the "Rapid deployed network for emergency scenario" use case, see Figure 7 in v-02. As this will allow for appropriate requirements to be identified and included in section 6, are you okay to not include this in the Wide-area use case? Kind Regards, Scott On 2/9/12 9:05 AM, "ext Gerald Chouinard" wrote: >Rex, > >See my comments below. > >Gerald > >-----Original Message----- >From: Rex Buddenberg [mailto:budden@nps.navy.mil] >Sent: Wednesday, 08 February, 2012 17:42 >To: Gerald Chouinard >Cc: scott.probasco@nokia.com; paws@ietf.org >Subject: Re: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet >broadbandaccess) > >namecalling nits below.... > >On Wed, 2012-02-08 at 17:16 -0500, Gerald Chouinard wrote: >> Scott, >> >> I agree with your proposed changes except for items 8 and 11. >> >> In the case of the Wide-area or Rural internet broadband access, the >> geolocation of each slave device needs to be provided to the base >>station >so >> that it can query the DB for the channel availability at each slave >> location. These slave devices could be located as far as 30 km, thus >>not >> sharing the same location as the base station as far as querying for the >> available channels. > >IEEE 802 uses the terms _base station_ (BS) and _subscriber station_ >(SS) (not slave). >[Gerald] 802.22 uses base station (BS) and customer premise equipment >(CPE) >> >> The network topology here is a point-to-multipoint star model (i.e., a >> slave, once it knows its available channels, is not supposed to go on >>its >> own and operate on any of these channels, it will continue to operate on >the >> same channel as that of the base station since it is part of this star >> network and needs to be in contact with the base station). > >In a pure IEEE 802.16 notion, this is entirely correct. > >> If a slave device >> were to operate on a different channel in a peer-to-peer fashion, it >>would >> also have to stay in touch with the master/BS and thus have double modem >> construction to operate on both channels at the same time. Such >peer-to-peer >> topology is not part of this use case. > >But it is part of several standards and associated technologies. IEEE >802.16j (now that it's ratified, correctly termed IEEE 802.16-2009) >comes to mind. >[Gerald] In such case, a new use case for peer-to-peer and mesh networking >for Wide-area and rural broadband access would need to be developed. This >use case was developed for point-to-multipoint topology. > >> >> In this model, the slave device does not need to know the list of >available >> channels, it only needs to know its operating channel which has to be >>the >> same as that of the base station and a few backup channels so that, if >>the >> current operating channels is to be freed by the base station, upon a >> trigger from the base station to move out of the channel, the slave >>device >> knows where to fall back to continue operating with the base station. >This >> way, the short time to free the channel to avoid interference to the >> incumbent can be met while the communication with the base station can >> continue in a transparent way to the terminal user. > >The way out of this circle is to again ape IEEE 802.16. The device in >the middle is known as RS, short for relay station. >Further there's a lot of 'mesh' talk where all stations would be >peers. >In both cases, the RS or the peers would have to assume the >responsibility of a BS. >[Gerald] Again, a new use case would need to be developed to cover this >case. As a result, the model for the PAWS would still be the BS acting as >the master and its associated terminals being the slaves. > >> >> The base station, however, needs to query the DB for each and every of >>its >> slave devices so that it can find the cross-section of all the available >> channels returned by the DB for all its slave devices which will define >the >> channels that can be used by all the slave devices (i.e., available to >>the >> BS and all its slave devices) and this will constitute the list of the >> operating channel and the backup channels that the BS needs to signal to >its >> slave devices. This is the common list of channels that needs to be >>sent >to >> the slave devices, not the list of available channels for each device >coming >> from the DB. >> >> As a consequence, The text in item 8 should stay as is except for >>changing >> "BS" for "Master/BS" if it is needed for consistency. >> >> With respect to item 11, here is what I would suggest: >> >> 11. The slave or user device must transmit its new geographic location >> every time it changes so that the repeated process described under item >>10 >> for the master/BS can rely on the most up-to-date geolocation of the >>slave >> or user device. >> >> One could also argue that this function of updating the geolocation >> information of the slave at the master/BS is nor related to the protocol >to >> be developed and is therefore beyond the scope of PAWS. >> >> Respectfully, >> >> Gerald >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> scott.probasco@nokia.com >> Sent: Wednesday, 08 February, 2012 12:55 >> To: paws@ietf.org >> Subject: [paws] UC&R I-D: section 4.4 (Wide-Area or Rural internet >> broadbandaccess) >> >> Hello All, >> >> As editors of the problem statement, use cases & requirements draft we >>are >> attempting to prepare a completed draft which could be ready for working >> group last call before IETF83. In the coming days we will post the >> sections of the draft to the mailing list. Our request is that you >>review >> these sections and reply to the email with any comments. >> >> Below is the text for section on the Wide-Area or Rural use case (new >> section numbering is NOT shown, all use cases will be moved to section >>4.2 >> Use cases in the next version). This text has been marked up from >> version-02 as uploaded January 26, 2012 as follows: >> >> * include applicable comments from Hotspot use case >> >> >> Our goal is that any discussion on this text will conclude by February >>15. >> To be clear, approval of the document will go through the normal process >> of last calls etc.. We are simply asking for your assistance in >>preparing >> a complete & accurate document that could progress the work. So please >> review the text and send your comments either directly to the editor or >>to >> the mailing list. >> >> Kind Regards, >> Raj & Scott >> >> >> >> 4.4. Wide-Area or Rural internet broadband access >> >> In this use case, internet broadband access is provided as a Wide- >> Area Network (WAN) or Wireless Regional Area Network (WRAN). A >> typical deployment scenario is a wide area or rural area, where >> internet broadband access is provided to local businesses and >> residents from a master (i.e. BS) connected to the internet. This >> deployment scenario is typically characterized by one or more >> Fixed master(s)/BS(s), cells with relatively large radius (tens of >> kilometers, up to 100 km), and a number of available radio >> channels. Some of the masters/BSs may be deployed and operated by >> a single entity, i.e. there can be centralized coordination >> between these masters/BSs, whereas other masters/BSs may be >> deployed and operated by operators competing for the radio >> channels in a license-exempt TVWS environment where decentralized >> coordination using the air-interface would be required. The BS in >> this scenario use a TDD radio technology and transmit at or below >> a transmit power limit established by the local regulator. Each >> base station has a connection to the internet and >>may >> provides >> internet connectivity to multiple slave/end-user devices. End >> user terminals or devices may be fixed or portable. >> >> The figure below shows an example deployment of this scenario. >> >> ------- >> |Slave|\ \|/ ---------- >> |Dev 1| (TDD AirIF) | |Database| >> ------- \ | .---. /---------- >> o \ |-|---------| ( ) / >> o | Master | / \ >> o / | (BS) |========( Internet ) >> o / |-----------| \ / >> ------- (TDD AirIF) ( ) >> |Slave| / (----) >> |Dev n| >> ------- >> >> >> Figure 4: Rural internet broadband access using TV white space >> spectrum >> >> Once the master/BS has been professionally installed and configured, >> a simplified power up and operation scenario utilizing TV White Space >> to provide rural internet broadband access consists of the following >> steps: >> >> 1. The master/BS powers up; however its WS radio and all other WS >> capable devices will power up in idle/listen only mode (No active >> transmissions on the WS frequency band) >> >> 2. The master/BS has internet connectivity , determines its >> location (either from location determination capability or from saved >> value that was set during installation), and establishes a >> connection to a trusted white space database (see use >> case "TVWS >> database discovery" above). >> >> 3. The master/BS registers its geolocation, address, contact >> information, etc. associated with the owner/operator of the >> master/BS with the trusted database service (if >> not currently >> registered, see Section 4.2reference is to >> registration, will be updated in next version). Meanwhile the >> DB administrator may >> be required to store and forward the registration information to >> the regulatory authority. If a trusted white space database >> administrator is not discovered, further operation of the WRAN >> may be allowed according to local regulator policy (in this case >> operation of the WRAN is outside the scope of the PAWS protocol). >> >> 4. Following the successful registration process, >>the >> master/BS will send a >> query to the trusted database requesting a list of available WS >> channels based upon its geolocation. The complete set of >> parameters to be provided from the master to the database is specified >> by the local regulator. Parameters may include WSD location, accuracy of >> of that location, device antenna height, device identifier of a slave >> device requesting channel information. >> >> >> 5. If the master/BS has been previously authenticated, the database >> responds with a list of available white space channels that may >> be used and optionally a maximum transmit power (EIRP) for each >> channel and a duration of time the channel may >>be >> used or a notification of any additional requirement for >> sensing. >> >> 6. Once the master/BS authenticates the WS channel list response >> message from the database, the master/BS selects an available WS >> channel(s) from the list. The operator may disallow some >> channels from the list to suit local needs if required. >> >> 7. The slave or user device scans the TV bands to locate a WRAN >> transmission, and associates with the master/BS.insert >> new step >> >> 8. The slave/user >> device provides its geolocation to the BS which, in >> turn, queries >> the databasemaster for a list >>of >> channels available at the slaves' >> Geolocation providing to the master the slave's Device ID >> and optionally its geolocation.. >> >> 9. Once this list of available channels is received from the >> database by the master, the latter will decide, based on the list >> of available channels for all its other associated slaves whether >> it should continue operation on its current channel or change >> channel to accommodate the new slave in case this channel is not >> available at its location. The master will notify all its >> associated slaves/user devices of the new channel to move to if >> operation needs to change channel. If the channel that the user >> terminal is currently using is not included in the list of >> locally available channels, the master will drop its association >> with the slave/user device so that it ceases all operation on its >> current channel and indicate the new operating channel before >> dropping the link if a change has been decided. The slave/user >> device may move to the indicated new channel if so indicated or >> scan for another WRAN transmission on a different channel. >> >> >> 10. The master/BS must periodically repeat the process to request a >> channel list from the database, steps 4 through 6 above. The frequency >> to repeat the process is determined by the local regulator. If the >> response from the database indicates a channel being used by the >> master/BS is not available, the master/BS must stop transmitting on that >> channel immediately. >> >> 11. The slave or user device must periodically repeat the process to >> request a channel list from the master/BS, steps 8 and 9 above. The >> frequency to repeat the process is determined by the local regulator. If >> the response from the master/BS indicates that a channel being used by >> the slave or user device is not available, the slave or user device must >> stop transmitting on that channel immediately. >> >> >> >> >> _______________________________________________ >> 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 Fri Feb 10 11:26:46 2012 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 A8C6B21F87D0 for ; Fri, 10 Feb 2012 11:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwCzNXmstX+C for ; Fri, 10 Feb 2012 11:26:45 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id A1B1D21F87B4 for ; Fri, 10 Feb 2012 11:26:45 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1AJQeuH001786 for ; Fri, 10 Feb 2012 21:26:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.61]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 21:26:39 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-006.mgdnok.nokia.com ([65.54.30.61]) with mapi id 14.01.0355.003; Fri, 10 Feb 2012 20:26:39 +0100 From: To: Thread-Topic: UC&R I-D: Section 4.6 White space serving as backhaul Thread-Index: AQHM6CnoR5NuqK1HHku9u6gYzYF9HA== Date: Fri, 10 Feb 2012 19:26:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [173.74.226.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2012 19:26:39.0791 (UTC) FILETIME=[E9A1F3F0:01CCE829] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: Section 4.6 White space serving as backhaul 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, 10 Feb 2012 19:26:46 -0000 Hello, I have revised Section 4.6 of the I-D which describes the use case wherein white space is used as a backhaul to provide Internet connectivity via WiFi. Please review the proposed text and comment by Feb 17th. Once we have consensus on the use case and text, we will incorporate it into the I-D. -Raj and Scott 4.6. White space serving as backhaul In this use case internet connectivity service is provided to users over a more commonly wireless standard such as WiFi with white space entities providing backhaul connectivity to the Internet. In a typical deployment scenario an end user has a device with a radio such as WiFi. An Internet service provider or a small business owner wants to provide WiFi internet connectivity service to their customers. The location where Internet connectivity service via WiFi is to be provided is within the coverage area of a white space master (e.g. Hotspot or Wide-Area/Rural network). The service provider installs a white space slave device and connects it to the WiFi access point(s). WiFi access points with an integrated white space slave component may also be used. This deployment scenario is typically characterized by a WS master/AP/BS providing local coverage. The master/AP has a connection to the internet and provides internet connectivity to slave devices that are within its coverage area. The WS slave device is 'bridged' to a WiFi network thereby enabling Internet connectivity service to wi-fi devices. The WS Master/AP/BS which has some form of Internet connectivity (wired or wireless) queries the database and obtains available channel information. It then provides service using those channels to slave devices which are within its coverage area. The figure below shows an example deployment of this scenario. \|/ white \|/ \|/ WiFi \|/ | space | | | | | | |-|----| |--------| |-|---------| |-|------|-| | WiFi | | | | WS Master | | WS Slave | | Dev | |internet|------| (AP/BS) | | Bridge | |------| | | | | |to WiFi AP| |--------| |-----------| |----------| \|/ | |-|----| | WiFi | | Dev | |------| Figure 6: TVWS for backhaul Once the bridged device (WS+WiFi) is connected to a master and WS network, a simplified operation scenario of backhaul for WiFi consists of the following steps: 1. A bridged device (WS+WiFi) is connected to a master device operating in the WS spectrum. The bridged device operates as a slave device in either Hotspot or Wide-Area/Rural internet use cases described above. 2. Once the slave device is connected to the master, the WiFi access point has Internet connectivity as well. 3. End users attach to the WiFi network via their WiFi enabled devices and receive internet connectivity. From budden@nps.edu Fri Feb 10 12:29:30 2012 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 2168B21F8534 for ; Fri, 10 Feb 2012 12:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aDASMFAI1tPS for ; Fri, 10 Feb 2012 12:29:29 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 8204A21F852D for ; Fri, 10 Feb 2012 12:29:29 -0800 (PST) X-ASG-Debug-ID: 1328905768-036c920f201003c0001-Z0ZA9G Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id qBpoSiwez33UQnM2; Fri, 10 Feb 2012 12:29:28 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 12:29:27 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] Threat model (Rev 3) To: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 10 Feb 2012 12:28:50 -0800 Message-ID: <1328905730.9169.2187.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1328905768 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.88174 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 10 Feb 2012 20:29:30 -0000 Raj, I'll try ... The public safety users of spectrum are very concerned with an issue they call 'talk around'. It's not at all defined, but certainly includes a definition in which internet infrastructure or simply (in a single segment net) a base station does not exist. In IEEE 802 terminology, two erstwhile subscriber stations need to communicate. The prism through which most public safety folks look at this is the LMR radio ... if I have the same freq as the guy over there that I can see then I can talk with him. Once this migrates to internet, the information power is amplified enormously, but what happens if I can't see a DNS server or a SIP server or ...? The PAWS concern is 'what if I can't see the white space server in order to get a freq allocation to use'. A suitable use case would be a sizable disaster where a lot of internet infrastructure ceases to function. Emergency services users need to reconstitute quickly and they will need radio WANs to do that. We can estimate that a lot of radio WAN gear that has been unused suddenly needs to be pressed into action. And the radio WANs need frequency authorizations to function. That work? On Fri, 2012-02-10 at 18:09 +0000, Basavaraj.Patil@nokia.com wrote: > HI Paul, > > On 2/9/12 3:32 PM, "ext Paul Lambert" wrote: > > > > >>The list in the current threat models text that I proposed is by no > >>means > >>exhaustiveŠ Or intended to be. The intent is to derive a key set of > >>security requirements for the protocol. The focus is on those threats > >>that > >>are relevant to the device-2-database protocol rather than to the much > >>more expansive topic of white space technology. > > > >Yes, but ... > > > >Without determining if there are technical mitigation mechanisms we > >should not be rejecting threats. The threats should all be examined and > >we should explicitly determine what is in scope versus unilaterally as > >part of the editing process. > > No doubt. I don't think there is any unilateral proposal here. I am happy > to incorporate all relevant threats through the consensus process and > discussion on the mailing list. The threat model has evolved from Rev 1 to > Rev 4 as a result of feedback from you and others. > > > > >As an interesting example - if there is a natural disaster, should there > >be protocol mechanisms to enable use of emergency services without direct > >Internet connectivity to the DB? > > Would you consider this as a threat or a feature that the protocol needs > to be concerned with regarding reachability of the database? > > > > >Loss of service (emergency and normal) usage of WS is a threat that > >should be listed and may or may not be addressed by technical or > >procedural mechanisms. > > If you can elaborate or (preferably) provide the text describing the > threat and consequences, I would be happy to include it. > > -Raj > > > > >Paul > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Fri Feb 10 13:00:51 2012 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 AF16E21F8861 for ; Fri, 10 Feb 2012 13:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9LjKzNQOP8i for ; Fri, 10 Feb 2012 13:00:50 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 70D3421F8863 for ; Fri, 10 Feb 2012 13:00:50 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1AL0mK4002908; Fri, 10 Feb 2012 23:00:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 10 Feb 2012 23:00:47 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Fri, 10 Feb 2012 22:00:47 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAHW0EAgAB73KCAAMPrgIAAvpPQgADl8oCAAItbAP//pGCA Date: Fri, 10 Feb 2012 21:00:46 +0000 Message-ID: In-Reply-To: <1328905730.9169.2187.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [173.74.226.51] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <59E661DF612F3B4F957CFFC46B9B4A02@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2012 21:00:47.0533 (UTC) FILETIME=[0FF2FDD0:01CCE837] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 10 Feb 2012 21:00:51 -0000 Hi Rex, Thanks for the description. I understand the use case itself better now. However I am still trying to parse the threat. In the case of a natural disaster, I can imagine all types of radio equipment being pressed into use. So the statement: "And the radio WANs need frequency authorizations to function." Is the threat then the inability to reach the entity that authorizes the use of spectrum? Is the reachability and inability to obtain authorization a result of a malicious node preventing such communication? Rgds, -Raj On 2/10/12 2:28 PM, "ext Rex Buddenberg" wrote: >Raj,=20 > >I'll try ... > >The public safety users of spectrum are very concerned with an issue >they call 'talk around'. It's not at all defined, but certainly >includes a definition in which internet infrastructure or simply (in a >single segment net) a base station does not exist. In IEEE 802 >terminology, two erstwhile subscriber stations need to communicate. > >The prism through which most public safety folks look at this is the LMR >radio ... if I have the same freq as the guy over there that I can see >then I can talk with him. > Once this migrates to internet, the information power is amplified >enormously, but what happens if I can't see a DNS server or a SIP server >or ...? The PAWS concern is 'what if I can't see the white space server >in order to get a freq allocation to use'. > > > >A suitable use case would be a sizable disaster where a lot of internet >infrastructure ceases to function. Emergency services users need to >reconstitute quickly and they will need radio WANs to do that. We can >estimate that a lot of radio WAN gear that has been unused suddenly >needs to be pressed into action. And the radio WANs need frequency >authorizations to function. > > >That work? > >On Fri, 2012-02-10 at 18:09 +0000, Basavaraj.Patil@nokia.com wrote: >> HI Paul, >>=20 >> On 2/9/12 3:32 PM, "ext Paul Lambert" wrote: >>=20 >> > >> >>The list in the current threat models text that I proposed is by no >> >>means >> >>exhaustive=A9 Or intended to be. The intent is to derive a key set of >> >>security requirements for the protocol. The focus is on those threats >> >>that >> >>are relevant to the device-2-database protocol rather than to the much >> >>more expansive topic of white space technology. >> > >> >Yes, but ... >> > >> >Without determining if there are technical mitigation mechanisms we >> >should not be rejecting threats. The threats should all be examined >>and >> >we should explicitly determine what is in scope versus unilaterally as >> >part of the editing process. >>=20 >> No doubt. I don't think there is any unilateral proposal here. I am >>happy >> to incorporate all relevant threats through the consensus process and >> discussion on the mailing list. The threat model has evolved from Rev 1 >>to >> Rev 4 as a result of feedback from you and others. >>=20 >> > >> >As an interesting example - if there is a natural disaster, should >>there >> >be protocol mechanisms to enable use of emergency services without >>direct >> >Internet connectivity to the DB? >>=20 >> Would you consider this as a threat or a feature that the protocol needs >> to be concerned with regarding reachability of the database? >>=20 >> > >> >Loss of service (emergency and normal) usage of WS is a threat that >> >should be listed and may or may not be addressed by technical or >> >procedural mechanisms. >>=20 >> If you can elaborate or (preferably) provide the text describing the >> threat and consequences, I would be happy to include it. >>=20 >> -Raj >>=20 >> > >> >Paul >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > > From budden@nps.edu Fri Feb 10 13:17:26 2012 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 C8BA821F8555 for ; Fri, 10 Feb 2012 13:17:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.434 X-Spam-Level: X-Spam-Status: No, score=-2.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1xULRa8tkQS for ; Fri, 10 Feb 2012 13:17:26 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAEE21F8531 for ; Fri, 10 Feb 2012 13:17:26 -0800 (PST) X-ASG-Debug-ID: 1328908646-036c920f1b100ad0001-Z0ZA9G Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id fwNo3RBshq8hGSJ1; Fri, 10 Feb 2012 13:17:26 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 Feb 2012 13:17:25 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] Threat model (Rev 3) To: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 10 Feb 2012 13:16:47 -0800 Message-ID: <1328908607.9169.2190.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1328908646 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.88176 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 10 Feb 2012 21:17:26 -0000 On Fri, 2012-02-10 at 21:00 +0000, Basavaraj.Patil@nokia.com wrote: > Hi Rex, > > Thanks for the description. I understand the use case itself better now. > However I am still trying to parse the threat. > In the case of a natural disaster, I can imagine all types of radio > equipment being pressed into use. > So the statement: > "And the radio WANs need frequency authorizations to function." > > Is the threat then the inability to reach the entity that authorizes the > use of spectrum? Yes. > Is the reachability and inability to obtain authorization a result of a > malicious node preventing such communication? I did not consider this in the use case. What I was considering was that the disaster itself prevented comms, including those to the whitespace data server ... but not sure it would make a difference. However I would, in all use cases, consider authenticity of the data communicated (both ways) to be a requirement. > > Rgds, > -Raj > > > > On 2/10/12 2:28 PM, "ext Rex Buddenberg" wrote: > > >Raj, > > > >I'll try ... > > > >The public safety users of spectrum are very concerned with an issue > >they call 'talk around'. It's not at all defined, but certainly > >includes a definition in which internet infrastructure or simply (in a > >single segment net) a base station does not exist. In IEEE 802 > >terminology, two erstwhile subscriber stations need to communicate. > > > >The prism through which most public safety folks look at this is the LMR > >radio ... if I have the same freq as the guy over there that I can see > >then I can talk with him. > > Once this migrates to internet, the information power is amplified > >enormously, but what happens if I can't see a DNS server or a SIP server > >or ...? The PAWS concern is 'what if I can't see the white space server > >in order to get a freq allocation to use'. > > > > > > > >A suitable use case would be a sizable disaster where a lot of internet > >infrastructure ceases to function. Emergency services users need to > >reconstitute quickly and they will need radio WANs to do that. We can > >estimate that a lot of radio WAN gear that has been unused suddenly > >needs to be pressed into action. And the radio WANs need frequency > >authorizations to function. > > > > > >That work? > > > >On Fri, 2012-02-10 at 18:09 +0000, Basavaraj.Patil@nokia.com wrote: > >> HI Paul, > >> > >> On 2/9/12 3:32 PM, "ext Paul Lambert" wrote: > >> > >> > > >> >>The list in the current threat models text that I proposed is by no > >> >>means > >> >>exhaustiveŠ Or intended to be. The intent is to derive a key set of > >> >>security requirements for the protocol. The focus is on those threats > >> >>that > >> >>are relevant to the device-2-database protocol rather than to the much > >> >>more expansive topic of white space technology. > >> > > >> >Yes, but ... > >> > > >> >Without determining if there are technical mitigation mechanisms we > >> >should not be rejecting threats. The threats should all be examined > >>and > >> >we should explicitly determine what is in scope versus unilaterally as > >> >part of the editing process. > >> > >> No doubt. I don't think there is any unilateral proposal here. I am > >>happy > >> to incorporate all relevant threats through the consensus process and > >> discussion on the mailing list. The threat model has evolved from Rev 1 > >>to > >> Rev 4 as a result of feedback from you and others. > >> > >> > > >> >As an interesting example - if there is a natural disaster, should > >>there > >> >be protocol mechanisms to enable use of emergency services without > >>direct > >> >Internet connectivity to the DB? > >> > >> Would you consider this as a threat or a feature that the protocol needs > >> to be concerned with regarding reachability of the database? > >> > >> > > >> >Loss of service (emergency and normal) usage of WS is a threat that > >> >should be listed and may or may not be addressed by technical or > >> >procedural mechanisms. > >> > >> If you can elaborate or (preferably) provide the text describing the > >> threat and consequences, I would be happy to include it. > >> > >> -Raj > >> > >> > > >> >Paul > >> > >> _______________________________________________ > >> paws mailing list > >> paws@ietf.org > >> https://www.ietf.org/mailman/listinfo/paws > > > > > From paul@marvell.com Fri Feb 10 13:59:06 2012 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 8F90321F8633 for ; Fri, 10 Feb 2012 13:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntpY7vrsV9l7 for ; Fri, 10 Feb 2012 13:59:06 -0800 (PST) Received: from na3sys009aog122.obsmtp.com (na3sys009aog122.obsmtp.com [74.125.149.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3A11B21F862F for ; Fri, 10 Feb 2012 13:58:58 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob122.postini.com ([74.125.148.12]) with SMTP ID DSNKTzWTHeaHazNGIeilEWLo3h/EySsgj8J7@postini.com; Fri, 10 Feb 2012 13:58:58 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 10 Feb 2012 13:57:16 -0800 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" Date: Fri, 10 Feb 2012 13:57:15 -0800 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAHW0EAgAB73KCAAMPrgIAAvpPQgADl8oCAAHp9kA== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579A50186@SC-VEXCH2.marvell.com> References: <7BAC95F5A7E67643AAFB2C31BEE662D01579A4FE7B@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] Threat model (Rev 3) 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, 10 Feb 2012 21:59:06 -0000 >>As an interesting example - if there is a natural disaster, should >there >>be protocol mechanisms to enable use of emergency services without >direct >>Internet connectivity to the DB? > >Would you consider this as a threat or a feature that the protocol needs >to be concerned with regarding reachability of the database? A threat analysis provides requirements that might be met with specific fea= tures of technical proposals. Too often we carry implicit ideas on the fea= tures and implementation (like FCC rules, or TLS+509 for all security requi= rements) that impact our view of the problem area.=20 Here specifically (the disaster scenario), we should allow devices (perhaps= only empowered emergency service devices) to continue to use spectrum when= the database is not available due to a natural disaster.=20 Since we are all looking at what this would mean for a protocol mechanism -= the implication is that we need to support more than one type of policy fo= r enabling transmission. The ".. stop immediately if you've not been enabl= ed in the last 60 seconds ..." model may be one approach, but if we are try= ing to plan for the future and develop a robust communication technology, t= hen we need to have protocol mechanism that indicates differences in the ap= plication of policies. Some policies should allow more lenient interpretat= ion of the temporary spectrum usage authorization provided by the DB. WE s= hould not hard code current FCC rules into devices, but have some ability t= o=20 I'm not at this time proposing a specific mechanism at this time ... just t= he requirement (in the form of threat models). > >> >>Loss of service (emergency and normal) usage of WS is a threat that >>should be listed and may or may not be addressed by technical or >>procedural mechanisms. > >If you can elaborate or (preferably) provide the text describing the >threat and consequences, I would be happy to include it. I did before ... time permitting I'll resubmit. Paul > >-Raj > >> >>Paul From paul@marvell.com Fri Feb 10 14:04:27 2012 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 2BA2521F8602 for ; Fri, 10 Feb 2012 14:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mAxMK9eDIzqq for ; Fri, 10 Feb 2012 14:04:26 -0800 (PST) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3D91221F84F4 for ; Fri, 10 Feb 2012 14:04:25 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKTzWUYPhYHRB5pQzPw1i2bEbaY4btvf4N@postini.com; Fri, 10 Feb 2012 14:04:25 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 10 Feb 2012 14:01:57 -0800 From: Paul Lambert To: Rex Buddenberg , "Basavaraj.Patil@nokia.com" Date: Fri, 10 Feb 2012 14:01:56 -0800 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AczoOWO9RWRLLQpXQnuLhQZyoF51rAABaXxw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579A50189@SC-VEXCH2.marvell.com> References: <1328908607.9169.2190.camel@localhost.localdomain> In-Reply-To: <1328908607.9169.2190.camel@localhost.localdomain> 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" Subject: Re: [paws] Threat model (Rev 3) 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, 10 Feb 2012 22:04:27 -0000 Pk9uIEZyaSwgMjAxMi0wMi0xMCBhdCAyMTowMCArMDAwMCwgQmFzYXZhcmFqLlBhdGlsQG5va2lh LmNvbSB3cm90ZToNCj4+IEhpIFJleCwNCj4+DQo+PiBUaGFua3MgZm9yIHRoZSBkZXNjcmlwdGlv bi4gSSB1bmRlcnN0YW5kIHRoZSB1c2UgY2FzZSBpdHNlbGYgYmV0dGVyDQo+bm93Lg0KPj4gSG93 ZXZlciBJIGFtIHN0aWxsIHRyeWluZyB0byBwYXJzZSB0aGUgdGhyZWF0Lg0KPj4gSW4gdGhlIGNh c2Ugb2YgYSBuYXR1cmFsIGRpc2FzdGVyLCBJIGNhbiBpbWFnaW5lIGFsbCB0eXBlcyBvZiByYWRp bw0KPj4gZXF1aXBtZW50IGJlaW5nIHByZXNzZWQgaW50byB1c2UuDQo+PiBTbyB0aGUgc3RhdGVt ZW50Og0KPj4gIkFuZCB0aGUgcmFkaW8gV0FOcyBuZWVkIGZyZXF1ZW5jeSBhdXRob3JpemF0aW9u cyB0byBmdW5jdGlvbi4iDQo+Pg0KPj4gSXMgdGhlIHRocmVhdCB0aGVuIHRoZSBpbmFiaWxpdHkg dG8gcmVhY2ggdGhlIGVudGl0eSB0aGF0IGF1dGhvcml6ZXMNCj50aGUNCj4+IHVzZSBvZiBzcGVj dHJ1bT8NCj4NCj5ZZXMuDQoNCkhvd2V2ZXIgLSBhIG1hbGljaW91cyBub2RlIGJsb2NraW5nIGNv bW11bmljYXRpb24gaXMgYSBkaWZmZXJlbnQgdGhyZWF0IHRoYW4gYSBuYXR1cmFsIGRpc2FzdGVy Lg0KDQpJbiBhIG5hdHVyYWwgZGlzYXN0ZXIgKG9yIHBlcmNlaXZlZCBkaXNhc3RlcikgIGl0IG1h eSBiZSBwb3NzaWJsZSB0byBhbGxvdyBzb21lIGRldmljZXMgKGxpa2UgZW1lcmdlbmN5IHNlcnZp Y2VzKSBtb3JlIGxlZS13YXkgdG8gbm90IHNodXQgZG93biBpbW1lZGlhdGVseSB3aGVuIGEgZGF0 YWJhc2UgaXMgbm90IGFjY2Vzc2libGUuICBTb21lIGxldmVsIG9mIGRlZmF1bHQgY2FwYWJpbGl0 aWVzIGFuZCBjaGFubmVscyBjb3VsZCBiZSBwcm92aWRlZC4gIEF1dGhvcml6YXRpb24gb3IgZW5h YmxlbWVudCB1c2luZyBhIGxvd2VyIGR1dHkgY3ljbGUgKG5vIHB1c2gsIGxvd2VyIHRpbWUgbGlt aXRzKSBtaWdodCBiZSBwb3NzaWJsZS4NCg0KDQo+DQo+PiBJcyB0aGUgcmVhY2hhYmlsaXR5IGFu ZCBpbmFiaWxpdHkgdG8gb2J0YWluIGF1dGhvcml6YXRpb24gYSByZXN1bHQgb2YNCj5hDQo+PiBt YWxpY2lvdXMgbm9kZSBwcmV2ZW50aW5nIHN1Y2ggY29tbXVuaWNhdGlvbj8NCj4NCj5JIGRpZCBu b3QgY29uc2lkZXIgdGhpcyBpbiB0aGUgdXNlIGNhc2UuICBXaGF0IEkgd2FzIGNvbnNpZGVyaW5n IHdhcw0KPnRoYXQgdGhlIGRpc2FzdGVyIGl0c2VsZiBwcmV2ZW50ZWQgY29tbXMsIGluY2x1ZGlu ZyB0aG9zZSB0byB0aGUNCj53aGl0ZXNwYWNlIGRhdGEgc2VydmVyIC4uLiBidXQgbm90IHN1cmUg aXQgd291bGQgbWFrZSBhIGRpZmZlcmVuY2UuDQo+SG93ZXZlciBJIHdvdWxkLCBpbiBhbGwgdXNl IGNhc2VzLCBjb25zaWRlciBhdXRoZW50aWNpdHkgb2YgdGhlIGRhdGENCj5jb21tdW5pY2F0ZWQg KGJvdGggd2F5cykgdG8gYmUgYSByZXF1aXJlbWVudC4NCg0KQm90aCBwcmV2ZW50IGFjY2VzcyAu Li4gYnV0IGFyZSBkaWZmZXJlbnQgc2NlbmFyaW9zLiANCg0KDQpQYXVsDQoNCg0KPg0KPj4NCj4+ IFJnZHMsDQo+PiAtUmFqDQo+Pg0KPj4NCj4+DQo+PiBPbiAyLzEwLzEyIDI6MjggUE0sICJleHQg UmV4IEJ1ZGRlbmJlcmciIDxidWRkZW5AbnBzLm5hdnkubWlsPiB3cm90ZToNCj4+DQo+PiA+UmFq LA0KPj4gPg0KPj4gPkknbGwgdHJ5IC4uLg0KPj4gPg0KPj4gPlRoZSBwdWJsaWMgc2FmZXR5IHVz ZXJzIG9mIHNwZWN0cnVtIGFyZSB2ZXJ5IGNvbmNlcm5lZCB3aXRoIGFuIGlzc3VlDQo+PiA+dGhl eSBjYWxsICd0YWxrIGFyb3VuZCcuICBJdCdzIG5vdCBhdCBhbGwgZGVmaW5lZCwgYnV0IGNlcnRh aW5seQ0KPj4gPmluY2x1ZGVzIGEgZGVmaW5pdGlvbiBpbiB3aGljaCBpbnRlcm5ldCBpbmZyYXN0 cnVjdHVyZSAgb3Igc2ltcGx5IChpbg0KPmENCj4+ID5zaW5nbGUgc2VnbWVudCBuZXQpIGEgYmFz ZSBzdGF0aW9uIGRvZXMgbm90IGV4aXN0LiAgSW4gSUVFRSA4MDINCj4+ID50ZXJtaW5vbG9neSwg dHdvIGVyc3R3aGlsZSBzdWJzY3JpYmVyIHN0YXRpb25zIG5lZWQgdG8gY29tbXVuaWNhdGUuDQo+ PiA+DQo+PiA+VGhlIHByaXNtIHRocm91Z2ggd2hpY2ggbW9zdCBwdWJsaWMgc2FmZXR5IGZvbGtz IGxvb2sgYXQgdGhpcyBpcyB0aGUNCj5MTVINCj4+ID5yYWRpbyAuLi4gaWYgSSBoYXZlIHRoZSBz YW1lIGZyZXEgYXMgdGhlIGd1eSBvdmVyIHRoZXJlIHRoYXQgSSBjYW4NCj5zZWUNCj4+ID50aGVu IEkgY2FuIHRhbGsgd2l0aCBoaW0uDQo+PiA+CU9uY2UgdGhpcyBtaWdyYXRlcyB0byBpbnRlcm5l dCwgdGhlIGluZm9ybWF0aW9uIHBvd2VyIGlzIGFtcGxpZmllZA0KPj4gPmVub3Jtb3VzbHksIGJ1 dCB3aGF0IGhhcHBlbnMgaWYgSSBjYW4ndCBzZWUgYSBETlMgc2VydmVyIG9yIGEgU0lQDQo+c2Vy dmVyDQo+PiA+b3IgLi4uPyAgVGhlIFBBV1MgY29uY2VybiBpcyAnd2hhdCBpZiBJIGNhbid0IHNl ZSB0aGUgd2hpdGUgc3BhY2UNCj5zZXJ2ZXINCj4+ID5pbiBvcmRlciB0byBnZXQgYSBmcmVxIGFs bG9jYXRpb24gdG8gdXNlJy4NCj4+ID4NCj4+ID4NCj4+ID4NCj4+ID5BIHN1aXRhYmxlIHVzZSBj YXNlIHdvdWxkIGJlIGEgc2l6YWJsZSBkaXNhc3RlciB3aGVyZSBhIGxvdCBvZg0KPmludGVybmV0 DQo+PiA+aW5mcmFzdHJ1Y3R1cmUgY2Vhc2VzIHRvIGZ1bmN0aW9uLiAgRW1lcmdlbmN5IHNlcnZp Y2VzIHVzZXJzIG5lZWQgdG8NCj4+ID5yZWNvbnN0aXR1dGUgcXVpY2tseSBhbmQgdGhleSB3aWxs IG5lZWQgcmFkaW8gV0FOcyB0byBkbyB0aGF0LiAgV2UNCj5jYW4NCj4+ID5lc3RpbWF0ZSB0aGF0 IGEgbG90IG9mIHJhZGlvIFdBTiBnZWFyIHRoYXQgaGFzIGJlZW4gdW51c2VkIHN1ZGRlbmx5DQo+ PiA+bmVlZHMgdG8gYmUgcHJlc3NlZCBpbnRvIGFjdGlvbi4gICBBbmQgdGhlIHJhZGlvIFdBTnMg bmVlZCBmcmVxdWVuY3kNCj4+ID5hdXRob3JpemF0aW9ucyB0byBmdW5jdGlvbi4NCj4+ID4NCj4+ ID4NCj4+ID5UaGF0IHdvcms/DQo+PiA+DQo+PiA+T24gRnJpLCAyMDEyLTAyLTEwIGF0IDE4OjA5 ICswMDAwLCBCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tIHdyb3RlOg0KPj4gPj4gSEkgUGF1bCwN Cj4+ID4+DQo+PiA+PiBPbiAyLzkvMTIgMzozMiBQTSwgImV4dCBQYXVsIExhbWJlcnQiIDxwYXVs QG1hcnZlbGwuY29tPiB3cm90ZToNCj4+ID4+DQo+PiA+PiA+DQo+PiA+PiA+PlRoZSBsaXN0IGlu IHRoZSBjdXJyZW50IHRocmVhdCBtb2RlbHMgdGV4dCB0aGF0IEkgcHJvcG9zZWQgaXMgYnkNCj5u bw0KPj4gPj4gPj5tZWFucw0KPj4gPj4gPj5leGhhdXN0aXZlxaAgT3IgaW50ZW5kZWQgdG8gYmUu IFRoZSBpbnRlbnQgaXMgdG8gZGVyaXZlIGEga2V5IHNldA0KPm9mDQo+PiA+PiA+PnNlY3VyaXR5 IHJlcXVpcmVtZW50cyBmb3IgdGhlIHByb3RvY29sLiBUaGUgZm9jdXMgaXMgb24gdGhvc2UNCj50 aHJlYXRzDQo+PiA+PiA+PnRoYXQNCj4+ID4+ID4+YXJlIHJlbGV2YW50IHRvIHRoZSBkZXZpY2Ut Mi1kYXRhYmFzZSBwcm90b2NvbCByYXRoZXIgdGhhbiB0byB0aGUNCj5tdWNoDQo+PiA+PiA+Pm1v cmUgZXhwYW5zaXZlIHRvcGljIG9mIHdoaXRlIHNwYWNlIHRlY2hub2xvZ3kuDQo+PiA+PiA+DQo+ PiA+PiA+WWVzLCBidXQgLi4uDQo+PiA+PiA+DQo+PiA+PiA+V2l0aG91dCBkZXRlcm1pbmluZyBp ZiB0aGVyZSBhcmUgdGVjaG5pY2FsIG1pdGlnYXRpb24gbWVjaGFuaXNtcw0KPndlDQo+PiA+PiA+ c2hvdWxkIG5vdCBiZSByZWplY3RpbmcgdGhyZWF0cy4gIFRoZSB0aHJlYXRzIHNob3VsZCBhbGwg YmUNCj5leGFtaW5lZA0KPj4gPj5hbmQNCj4+ID4+ID53ZSBzaG91bGQgZXhwbGljaXRseSBkZXRl cm1pbmUgd2hhdCBpcyBpbiBzY29wZSB2ZXJzdXMNCj51bmlsYXRlcmFsbHkgYXMNCj4+ID4+ID5w YXJ0IG9mIHRoZSBlZGl0aW5nIHByb2Nlc3MuDQo+PiA+Pg0KPj4gPj4gTm8gZG91YnQuIEkgZG9u J3QgdGhpbmsgdGhlcmUgaXMgYW55IHVuaWxhdGVyYWwgcHJvcG9zYWwgaGVyZS4gSSBhbQ0KPj4g Pj5oYXBweQ0KPj4gPj4gdG8gaW5jb3Jwb3JhdGUgYWxsIHJlbGV2YW50IHRocmVhdHMgdGhyb3Vn aCB0aGUgY29uc2Vuc3VzIHByb2Nlc3MNCj5hbmQNCj4+ID4+IGRpc2N1c3Npb24gb24gdGhlIG1h aWxpbmcgbGlzdC4gVGhlIHRocmVhdCBtb2RlbCBoYXMgZXZvbHZlZCBmcm9tDQo+UmV2IDENCj4+ ID4+dG8NCj4+ID4+IFJldiA0IGFzIGEgcmVzdWx0IG9mIGZlZWRiYWNrIGZyb20geW91IGFuZCBv dGhlcnMuDQo+PiA+Pg0KPj4gPj4gPg0KPj4gPj4gPkFzIGFuIGludGVyZXN0aW5nIGV4YW1wbGUg LSBpZiB0aGVyZSBpcyBhIG5hdHVyYWwgZGlzYXN0ZXIsIHNob3VsZA0KPj4gPj50aGVyZQ0KPj4g Pj4gPmJlIHByb3RvY29sIG1lY2hhbmlzbXMgdG8gZW5hYmxlIHVzZSBvZiBlbWVyZ2VuY3kgc2Vy dmljZXMgd2l0aG91dA0KPj4gPj5kaXJlY3QNCj4+ID4+ID5JbnRlcm5ldCBjb25uZWN0aXZpdHkg dG8gdGhlIERCPw0KPj4gPj4NCj4+ID4+IFdvdWxkIHlvdSBjb25zaWRlciB0aGlzIGFzIGEgdGhy ZWF0IG9yIGEgZmVhdHVyZSB0aGF0IHRoZSBwcm90b2NvbA0KPm5lZWRzDQo+PiA+PiB0byBiZSBj b25jZXJuZWQgd2l0aCByZWdhcmRpbmcgcmVhY2hhYmlsaXR5IG9mIHRoZSBkYXRhYmFzZT8NCj4+ ID4+DQo+PiA+PiA+DQo+PiA+PiA+TG9zcyBvZiBzZXJ2aWNlIChlbWVyZ2VuY3kgYW5kIG5vcm1h bCkgdXNhZ2Ugb2YgV1MgaXMgYSB0aHJlYXQNCj50aGF0DQo+PiA+PiA+c2hvdWxkIGJlIGxpc3Rl ZCBhbmQgbWF5IG9yIG1heSBub3QgYmUgYWRkcmVzc2VkIGJ5IHRlY2huaWNhbCBvcg0KPj4gPj4g PnByb2NlZHVyYWwgbWVjaGFuaXNtcy4NCj4+ID4+DQo+PiA+PiBJZiB5b3UgY2FuIGVsYWJvcmF0 ZSBvciAocHJlZmVyYWJseSkgcHJvdmlkZSB0aGUgdGV4dCBkZXNjcmliaW5nDQo+dGhlDQo+PiA+ PiB0aHJlYXQgYW5kIGNvbnNlcXVlbmNlcywgSSB3b3VsZCBiZSBoYXBweSB0byBpbmNsdWRlIGl0 Lg0KPj4gPj4NCj4+ID4+IC1SYWoNCj4+ID4+DQo+PiA+PiA+DQo+PiA+PiA+UGF1bA0KPj4gPj4N Cj4+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiA+PiBwYXdzIG1haWxpbmcgbGlzdA0KPj4gPj4gcGF3c0BpZXRmLm9yZw0KPj4gPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQo+PiA+DQo+PiA+DQo+Pg0KPg0K DQo= From Basavaraj.Patil@nokia.com Fri Feb 10 15:00:53 2012 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 B4BD821F86A0 for ; Fri, 10 Feb 2012 15:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.242 X-Spam-Level: X-Spam-Status: No, score=-103.242 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zfv8Sguzbt84 for ; Fri, 10 Feb 2012 15:00:50 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id CCB4E21F8679 for ; Fri, 10 Feb 2012 15:00:46 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (vaebh101.europe.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1AN0i4P030745; Sat, 11 Feb 2012 01:00:45 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.57]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 11 Feb 2012 01:00:44 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-002.mgdnok.nokia.com ([65.54.30.57]) with mapi id 14.01.0355.003; Sat, 11 Feb 2012 00:00:43 +0100 From: To: Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAHW0EAgAB73KCAAMPrgIAAvpPQgADl8oCAAItbAP//pGCAgABpBoD//7bAgA== Date: Fri, 10 Feb 2012 23:00:43 +0000 Message-ID: In-Reply-To: <1328908607.9169.2190.camel@localhost.localdomain> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [173.74.226.51] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 10 Feb 2012 23:00:44.0502 (UTC) FILETIME=[D1AD4F60:01CCE847] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 10 Feb 2012 23:00:54 -0000 Hi Paul/Rex, How about adding the following threat to the list: Threat 8: Natural disaster resulting in inability to obtain authorization for=20 spectrum use by emergency responders In the case of a sizable natural disaster a lot of internet infrastructure ceases to function. Emergency services users need to reconstitute quickly and will rely on establishing radio WANs. The potential for lot of radio WAN gear that has been unused suddenly needs to be pressed into action. And the radio WANs need frequency authorizations to function. Regulatory entities may also authorize usage of additional spectrum in the affected areas. The white space radio entities may need to establish communication with a database and obtain authorizations. Alternatively there may be other mechanisms which allow the use of spectrum by emergency service equipment without strict authorization or with liberal interpretation of the regulatory policy for white space usage. Please suggest additional text or changes as needed. -Raj On 2/10/12 3:16 PM, "ext Rex Buddenberg" wrote: >On Fri, 2012-02-10 at 21:00 +0000, Basavaraj.Patil@nokia.com wrote: >> Hi Rex, >>=20 >> Thanks for the description. I understand the use case itself better now. >> However I am still trying to parse the threat. >> In the case of a natural disaster, I can imagine all types of radio >> equipment being pressed into use. >> So the statement: >> "And the radio WANs need frequency authorizations to function." >>=20 >> Is the threat then the inability to reach the entity that authorizes the >> use of spectrum? > >Yes. =20 > >> Is the reachability and inability to obtain authorization a result of a >> malicious node preventing such communication? > >I did not consider this in the use case. What I was considering was >that the disaster itself prevented comms, including those to the >whitespace data server ... but not sure it would make a difference. >However I would, in all use cases, consider authenticity of the data >communicated (both ways) to be a requirement. > >>=20 >> Rgds, >> -Raj >>=20 >>=20 >>=20 >> On 2/10/12 2:28 PM, "ext Rex Buddenberg" wrote: >>=20 >> >Raj,=20 >> > >> >I'll try ... >> > >> >The public safety users of spectrum are very concerned with an issue >> >they call 'talk around'. It's not at all defined, but certainly >> >includes a definition in which internet infrastructure or simply (in a >> >single segment net) a base station does not exist. In IEEE 802 >> >terminology, two erstwhile subscriber stations need to communicate. >> > >> >The prism through which most public safety folks look at this is the >>LMR >> >radio ... if I have the same freq as the guy over there that I can see >> >then I can talk with him. >> > Once this migrates to internet, the information power is amplified >> >enormously, but what happens if I can't see a DNS server or a SIP >>server >> >or ...? The PAWS concern is 'what if I can't see the white space >>server >> >in order to get a freq allocation to use'. >> > >> > >> > >> >A suitable use case would be a sizable disaster where a lot of internet >> >infrastructure ceases to function. Emergency services users need to >> >reconstitute quickly and they will need radio WANs to do that. We can >> >estimate that a lot of radio WAN gear that has been unused suddenly >> >needs to be pressed into action. And the radio WANs need frequency >> >authorizations to function. >> > >> > >> >That work? >> > >> >On Fri, 2012-02-10 at 18:09 +0000, Basavaraj.Patil@nokia.com wrote: >> >> HI Paul, >> >>=20 >> >> On 2/9/12 3:32 PM, "ext Paul Lambert" wrote: >> >>=20 >> >> > >> >> >>The list in the current threat models text that I proposed is by no >> >> >>means >> >> >>exhaustive=A9 Or intended to be. The intent is to derive a key set = of >> >> >>security requirements for the protocol. The focus is on those >>threats >> >> >>that >> >> >>are relevant to the device-2-database protocol rather than to the >>much >> >> >>more expansive topic of white space technology. >> >> > >> >> >Yes, but ... >> >> > >> >> >Without determining if there are technical mitigation mechanisms we >> >> >should not be rejecting threats. The threats should all be examined >> >>and >> >> >we should explicitly determine what is in scope versus unilaterally >>as >> >> >part of the editing process. >> >>=20 >> >> No doubt. I don't think there is any unilateral proposal here. I am >> >>happy >> >> to incorporate all relevant threats through the consensus process and >> >> discussion on the mailing list. The threat model has evolved from >>Rev 1 >> >>to >> >> Rev 4 as a result of feedback from you and others. >> >>=20 >> >> > >> >> >As an interesting example - if there is a natural disaster, should >> >>there >> >> >be protocol mechanisms to enable use of emergency services without >> >>direct >> >> >Internet connectivity to the DB? >> >>=20 >> >> Would you consider this as a threat or a feature that the protocol >>needs >> >> to be concerned with regarding reachability of the database? >> >>=20 >> >> > >> >> >Loss of service (emergency and normal) usage of WS is a threat that >> >> >should be listed and may or may not be addressed by technical or >> >> >procedural mechanisms. >> >>=20 >> >> If you can elaborate or (preferably) provide the text describing the >> >> threat and consequences, I would be happy to include it. >> >>=20 >> >> -Raj >> >>=20 >> >> > >> >> >Paul >> >>=20 >> >> _______________________________________________ >> >> paws mailing list >> >> paws@ietf.org >> >> https://www.ietf.org/mailman/listinfo/paws >> > >> > >>=20 > > From paul@marvell.com Fri Feb 10 15:09:48 2012 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 9D7B221F85CE for ; Fri, 10 Feb 2012 15:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zd6nS+kpnoK2 for ; Fri, 10 Feb 2012 15:09:47 -0800 (PST) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id B59F421F85C6 for ; Fri, 10 Feb 2012 15:09:46 -0800 (PST) Received: from SC-OWA01.marvell.com ([65.219.4.129]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKTzWjshS5ve0NeM1K/A8Nu5dZjNmhuXCH@postini.com; Fri, 10 Feb 2012 15:09:46 PST Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 10 Feb 2012 15:08:01 -0800 From: Paul Lambert To: "Basavaraj.Patil@nokia.com" , "budden@nps.navy.mil" Date: Fri, 10 Feb 2012 15:08:00 -0800 Thread-Topic: [paws] Threat model (Rev 3) Thread-Index: AQHM4qrIvhb43zi+eEmvIC/JCfhS15YrhEmAgAABRICAAAFcgIAAKKCA//+d/YCAAHaq4IAHW0EAgAB73KCAAMPrgIAAvpPQgADl8oCAAItbAP//pGCAgABpBoD//7bAgAAPEfQg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01579A501CD@SC-VEXCH2.marvell.com> References: <1328908607.9169.2190.camel@localhost.localdomain> 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="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Threat model (Rev 3) 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, 10 Feb 2012 23:09:48 -0000 ThanKs ... that catching the concept .. Paul >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Friday, February 10, 2012 3:01 PM >To: budden@nps.navy.mil >Cc: Paul Lambert; paws@ietf.org >Subject: Re: [paws] Threat model (Rev 3) > > >Hi Paul/Rex, > >How about adding the following threat to the list: > >Threat 8: Natural disaster resulting in inability to obtain >authorization >for > spectrum use by emergency responders > >In the case of a sizable natural disaster a lot of internet >infrastructure ceases to function. Emergency services users need to >reconstitute quickly and will rely on establishing radio WANs. The >potential for lot of radio WAN gear that has been unused suddenly >needs to be pressed into action. And the radio WANs need frequency >authorizations to function. Regulatory entities may also authorize >usage of additional spectrum in the affected areas. The white space >radio entities may need to establish communication with a database and >obtain authorizations. Alternatively there may be other mechanisms >which allow the use of spectrum by emergency service equipment without >strict authorization or with liberal interpretation of the regulatory >policy for white space usage. > >Please suggest additional text or changes as needed. > >-Raj > > > > >On 2/10/12 3:16 PM, "ext Rex Buddenberg" wrote: > >>On Fri, 2012-02-10 at 21:00 +0000, Basavaraj.Patil@nokia.com wrote: >>> Hi Rex, >>> >>> Thanks for the description. I understand the use case itself better >now. >>> However I am still trying to parse the threat. >>> In the case of a natural disaster, I can imagine all types of radio >>> equipment being pressed into use. >>> So the statement: >>> "And the radio WANs need frequency authorizations to function." >>> >>> Is the threat then the inability to reach the entity that authorizes >the >>> use of spectrum? >> >>Yes. >> >>> Is the reachability and inability to obtain authorization a result of >a >>> malicious node preventing such communication? >> >>I did not consider this in the use case. What I was considering was >>that the disaster itself prevented comms, including those to the >>whitespace data server ... but not sure it would make a difference. >>However I would, in all use cases, consider authenticity of the data >>communicated (both ways) to be a requirement. >> >>> >>> Rgds, >>> -Raj >>> >>> >>> >>> On 2/10/12 2:28 PM, "ext Rex Buddenberg" wrote: >>> >>> >Raj, >>> > >>> >I'll try ... >>> > >>> >The public safety users of spectrum are very concerned with an issue >>> >they call 'talk around'. It's not at all defined, but certainly >>> >includes a definition in which internet infrastructure or simply >(in a >>> >single segment net) a base station does not exist. In IEEE 802 >>> >terminology, two erstwhile subscriber stations need to communicate. >>> > >>> >The prism through which most public safety folks look at this is the >>>LMR >>> >radio ... if I have the same freq as the guy over there that I can >see >>> >then I can talk with him. >>> > Once this migrates to internet, the information power is amplified >>> >enormously, but what happens if I can't see a DNS server or a SIP >>>server >>> >or ...? The PAWS concern is 'what if I can't see the white space >>>server >>> >in order to get a freq allocation to use'. >>> > >>> > >>> > >>> >A suitable use case would be a sizable disaster where a lot of >internet >>> >infrastructure ceases to function. Emergency services users need to >>> >reconstitute quickly and they will need radio WANs to do that. We >can >>> >estimate that a lot of radio WAN gear that has been unused suddenly >>> >needs to be pressed into action. And the radio WANs need frequency >>> >authorizations to function. >>> > >>> > >>> >That work? >>> > >>> >On Fri, 2012-02-10 at 18:09 +0000, Basavaraj.Patil@nokia.com wrote: >>> >> HI Paul, >>> >> >>> >> On 2/9/12 3:32 PM, "ext Paul Lambert" wrote: >>> >> >>> >> > >>> >> >>The list in the current threat models text that I proposed is by >no >>> >> >>means >>> >> >>exhaustive=A9 Or intended to be. The intent is to derive a key set >of >>> >> >>security requirements for the protocol. The focus is on those >>>threats >>> >> >>that >>> >> >>are relevant to the device-2-database protocol rather than to >the >>>much >>> >> >>more expansive topic of white space technology. >>> >> > >>> >> >Yes, but ... >>> >> > >>> >> >Without determining if there are technical mitigation mechanisms >we >>> >> >should not be rejecting threats. The threats should all be >examined >>> >>and >>> >> >we should explicitly determine what is in scope versus >unilaterally >>>as >>> >> >part of the editing process. >>> >> >>> >> No doubt. I don't think there is any unilateral proposal here. I >am >>> >>happy >>> >> to incorporate all relevant threats through the consensus process >and >>> >> discussion on the mailing list. The threat model has evolved from >>>Rev 1 >>> >>to >>> >> Rev 4 as a result of feedback from you and others. >>> >> >>> >> > >>> >> >As an interesting example - if there is a natural disaster, >should >>> >>there >>> >> >be protocol mechanisms to enable use of emergency services >without >>> >>direct >>> >> >Internet connectivity to the DB? >>> >> >>> >> Would you consider this as a threat or a feature that the protocol >>>needs >>> >> to be concerned with regarding reachability of the database? >>> >> >>> >> > >>> >> >Loss of service (emergency and normal) usage of WS is a threat >that >>> >> >should be listed and may or may not be addressed by technical or >>> >> >procedural mechanisms. >>> >> >>> >> If you can elaborate or (preferably) provide the text describing >the >>> >> threat and consequences, I would be happy to include it. >>> >> >>> >> -Raj >>> >> >>> >> > >>> >> >Paul >>> >> >>> >> _______________________________________________ >>> >> paws mailing list >>> >> paws@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/paws >>> > >>> > >>> >> >> From teco@inf-net.nl Sat Feb 11 04:17:29 2012 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 6950021F8489 for ; Sat, 11 Feb 2012 04:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-v8aFMjLPF3 for ; Sat, 11 Feb 2012 04:17:28 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 283FF21F8473 for ; Sat, 11 Feb 2012 04:17:23 -0800 (PST) Received: by eaal12 with SMTP id l12so1191242eaa.31 for ; Sat, 11 Feb 2012 04:17:22 -0800 (PST) Received: by 10.213.13.205 with SMTP id d13mr1582558eba.149.1328962640473; Sat, 11 Feb 2012 04:17:20 -0800 (PST) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id n56sm34572546eeh.6.2012.02.11.04.17.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Feb 2012 04:17:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Sat, 11 Feb 2012 13:17:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <06AF75B8-C617-4822-8EE2-2742B59E7293@inf-net.nl> References: To: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmEO06O5K1oK1qDCeUJQ0PA8K9l+D2ua6KhwV2DAua/qVKqMH53RKgKLu6VK3tbTHHduGEe Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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, 11 Feb 2012 12:17:29 -0000 Sure this added threat is important for ws users. Not only for=20 emergency responders, all users are affected by communication=20 breakdown between wsd and wsdb. Question is: is this a thread on the protocol, or on the whole=20 ws system? I think the latter. If included, I suggest the title: "Inability to obtain authorization for white spectrum use". And some text like this: The white space model makes use of a more centralized white space database an a communication protocol between the white space devices and the white space database. In cases where communication with the white space database fails, the white space devices cannot utilize white space spectrum. Emergency services, which require more spectrum precisely=20 on locations where network infrastructure is malfunctioning=20 or overloaded, backup communication channels and distributed=20 white space databases are needed to overcome such circumstances. The first responders use case already suggests the required backup facilities (satcom link). It is also deployed that way, but=20 I have to agree not everyone pays enough attention (and $=80=A5) to it. So yes, adding this threat description may help spending enough money for it. Or help when we make decisions on wsdb discovery. Teco Op 11 feb. 2012, om 00:00 heeft = het volgende geschreven: >=20 > Hi Paul/Rex, >=20 > How about adding the following threat to the list: >=20 > Threat 8: Natural disaster resulting in inability to obtain = authorization > for=20 > spectrum use by emergency responders >=20 > In the case of a sizable natural disaster a lot of internet > infrastructure ceases to function. Emergency services users need to > reconstitute quickly and will rely on establishing radio WANs. The > potential for lot of radio WAN gear that has been unused suddenly > needs to be pressed into action. And the radio WANs need frequency > authorizations to function. Regulatory entities may also authorize > usage of additional spectrum in the affected areas. The white space > radio entities may need to establish communication with a database and > obtain authorizations. Alternatively there may be other mechanisms > which allow the use of spectrum by emergency service equipment without > strict authorization or with liberal interpretation of the regulatory > policy for white space usage. >=20 > Please suggest additional text or changes as needed. >=20 > -Raj >=20 >=20 >=20 >=20 > On 2/10/12 3:16 PM, "ext Rex Buddenberg" wrote: >=20 >> On Fri, 2012-02-10 at 21:00 +0000, Basavaraj.Patil@nokia.com wrote: >>> Hi Rex, >>>=20 >>> Thanks for the description. I understand the use case itself better = now. >>> However I am still trying to parse the threat. >>> In the case of a natural disaster, I can imagine all types of radio >>> equipment being pressed into use. >>> So the statement: >>> "And the radio WANs need frequency authorizations to function." >>>=20 >>> Is the threat then the inability to reach the entity that authorizes = the >>> use of spectrum? >>=20 >> Yes. =20 >>=20 >>> Is the reachability and inability to obtain authorization a result = of a >>> malicious node preventing such communication? >>=20 >> I did not consider this in the use case. What I was considering was >> that the disaster itself prevented comms, including those to the >> whitespace data server ... but not sure it would make a difference. >> However I would, in all use cases, consider authenticity of the data >> communicated (both ways) to be a requirement. >>=20 >>>=20 >>> Rgds, >>> -Raj >>>=20 >>>=20 >>>=20 >>> On 2/10/12 2:28 PM, "ext Rex Buddenberg" = wrote: >>>=20 >>>> Raj,=20 >>>>=20 >>>> I'll try ... >>>>=20 >>>> The public safety users of spectrum are very concerned with an = issue >>>> they call 'talk around'. It's not at all defined, but certainly >>>> includes a definition in which internet infrastructure or simply = (in a >>>> single segment net) a base station does not exist. In IEEE 802 >>>> terminology, two erstwhile subscriber stations need to communicate. >>>>=20 >>>> The prism through which most public safety folks look at this is = the >>> LMR >>>> radio ... if I have the same freq as the guy over there that I can = see >>>> then I can talk with him. >>>> Once this migrates to internet, the information power is = amplified >>>> enormously, but what happens if I can't see a DNS server or a SIP >>> server >>>> or ...? The PAWS concern is 'what if I can't see the white space >>> server >>>> in order to get a freq allocation to use'. >>>>=20 >>>>=20 >>>>=20 >>>> A suitable use case would be a sizable disaster where a lot of = internet >>>> infrastructure ceases to function. Emergency services users need = to >>>> reconstitute quickly and they will need radio WANs to do that. We = can >>>> estimate that a lot of radio WAN gear that has been unused suddenly >>>> needs to be pressed into action. And the radio WANs need = frequency >>>> authorizations to function. >>>>=20 >>>>=20 >>>> That work? >>>>=20 >>>> On Fri, 2012-02-10 at 18:09 +0000, Basavaraj.Patil@nokia.com wrote: >>>>> HI Paul, >>>>>=20 >>>>> On 2/9/12 3:32 PM, "ext Paul Lambert" wrote: >>>>>=20 >>>>>>=20 >>>>>>> The list in the current threat models text that I proposed is by = no >>>>>>> means >>>>>>> exhaustive=8A Or intended to be. The intent is to derive a key = set of >>>>>>> security requirements for the protocol. The focus is on those >>> threats >>>>>>> that >>>>>>> are relevant to the device-2-database protocol rather than to = the >>> much >>>>>>> more expansive topic of white space technology. >>>>>>=20 >>>>>> Yes, but ... >>>>>>=20 >>>>>> Without determining if there are technical mitigation mechanisms = we >>>>>> should not be rejecting threats. The threats should all be = examined >>>>> and >>>>>> we should explicitly determine what is in scope versus = unilaterally >>> as >>>>>> part of the editing process. >>>>>=20 >>>>> No doubt. I don't think there is any unilateral proposal here. I = am >>>>> happy >>>>> to incorporate all relevant threats through the consensus process = and >>>>> discussion on the mailing list. The threat model has evolved from >>> Rev 1 >>>>> to >>>>> Rev 4 as a result of feedback from you and others. >>>>>=20 >>>>>>=20 >>>>>> As an interesting example - if there is a natural disaster, = should >>>>> there >>>>>> be protocol mechanisms to enable use of emergency services = without >>>>> direct >>>>>> Internet connectivity to the DB? >>>>>=20 >>>>> Would you consider this as a threat or a feature that the protocol >>> needs >>>>> to be concerned with regarding reachability of the database? >>>>>=20 >>>>>>=20 >>>>>> Loss of service (emergency and normal) usage of WS is a threat = that >>>>>> should be listed and may or may not be addressed by technical or >>>>>> procedural mechanisms. >>>>>=20 >>>>> If you can elaborate or (preferably) provide the text describing = the >>>>> threat and consequences, I would be happy to include it. >>>>>=20 >>>>> -Raj >>>>>=20 >>>>>>=20 >>>>>> Paul >>>>>=20 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From nbravin@earthlink.net Sun Feb 12 05:42:36 2012 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 DF51421F872A for ; Sun, 12 Feb 2012 05:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTCvDc3k6vDR for ; Sun, 12 Feb 2012 05:42:35 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id BA7D821F8729 for ; Sun, 12 Feb 2012 05:42:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IPENdmdScq6lpMo/N1pzwuzpK9krO0o/w8hlD5HzdwUXkoBh52wHA41CGZcXQ0iR; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1RwZhJ-00082K-Mw; Sun, 12 Feb 2012 08:42:34 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: <06AF75B8-C617-4822-8EE2-2742B59E7293@inf-net.nl> Date: Sun, 12 Feb 2012 05:42:32 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3B2EAA86-3EBC-466A-BCEE-44ACF788C196@earthlink.net> References: <06AF75B8-C617-4822-8EE2-2742B59E7293@inf-net.nl> To: Basavaraj.Patil@nokia.com, scott.probasco@nokia.com X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad868184af6412bbb59b945a7c2a84b1cb3d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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: Sun, 12 Feb 2012 13:42:37 -0000 In addition, the protocol should cover if one or more of the DB's are = unable to provide services as well.=20 Nancy On Feb 11, 2012, at 4:17 AM, Teco Boot wrote: > Sure this added threat is important for ws users. Not only for=20 > emergency responders, all users are affected by communication=20 > breakdown between wsd and wsdb. >=20 > Question is: is this a thread on the protocol, or on the whole=20 > ws system? I think the latter. >=20 > If included, I suggest the title: "Inability to obtain authorization > for white spectrum use". >=20 > And some text like this: > The white space model makes use of a more centralized white > space database an a communication protocol between the > white space devices and the white space database. In cases > where communication with the white space database fails, > the white space devices cannot utilize white space spectrum. > Emergency services, which require more spectrum precisely=20 > on locations where network infrastructure is malfunctioning=20 > or overloaded, backup communication channels and distributed=20 > white space databases are needed to overcome such circumstances. >=20 >=20 > The first responders use case already suggests the required > backup facilities (satcom link). It is also deployed that way, but=20 > I have to agree not everyone pays enough attention (and $=80=A5) to = it. >=20 > So yes, adding this threat description may help spending enough money > for it. Or help when we make decisions on wsdb discovery. >=20 > Teco >=20 >=20 > Op 11 feb. 2012, om 00:00 heeft = het volgende geschreven: >=20 >>=20 >> Hi Paul/Rex, >>=20 >> How about adding the following threat to the list: >>=20 >> Threat 8: Natural disaster resulting in inability to obtain = authorization >> for=20 >> spectrum use by emergency responders >>=20 >> In the case of a sizable natural disaster a lot of internet >> infrastructure ceases to function. Emergency services users need to >> reconstitute quickly and will rely on establishing radio WANs. The >> potential for lot of radio WAN gear that has been unused suddenly >> needs to be pressed into action. And the radio WANs need frequency >> authorizations to function. Regulatory entities may also authorize >> usage of additional spectrum in the affected areas. The white space >> radio entities may need to establish communication with a database = and >> obtain authorizations. Alternatively there may be other mechanisms >> which allow the use of spectrum by emergency service equipment = without >> strict authorization or with liberal interpretation of the regulatory >> policy for white space usage. >>=20 >> Please suggest additional text or changes as needed. >>=20 >> -Raj >>=20 >>=20 >>=20 >>=20 >> On 2/10/12 3:16 PM, "ext Rex Buddenberg" wrote: >>=20 >>> On Fri, 2012-02-10 at 21:00 +0000, Basavaraj.Patil@nokia.com wrote: >>>> Hi Rex, >>>>=20 >>>> Thanks for the description. I understand the use case itself better = now. >>>> However I am still trying to parse the threat. >>>> In the case of a natural disaster, I can imagine all types of radio >>>> equipment being pressed into use. >>>> So the statement: >>>> "And the radio WANs need frequency authorizations to function." >>>>=20 >>>> Is the threat then the inability to reach the entity that = authorizes the >>>> use of spectrum? >>>=20 >>> Yes. =20 >>>=20 >>>> Is the reachability and inability to obtain authorization a result = of a >>>> malicious node preventing such communication? >>>=20 >>> I did not consider this in the use case. What I was considering was >>> that the disaster itself prevented comms, including those to the >>> whitespace data server ... but not sure it would make a difference. >>> However I would, in all use cases, consider authenticity of the data >>> communicated (both ways) to be a requirement. >>>=20 >>>>=20 >>>> Rgds, >>>> -Raj >>>>=20 >>>>=20 >>>>=20 >>>> On 2/10/12 2:28 PM, "ext Rex Buddenberg" = wrote: >>>>=20 >>>>> Raj,=20 >>>>>=20 >>>>> I'll try ... >>>>>=20 >>>>> The public safety users of spectrum are very concerned with an = issue >>>>> they call 'talk around'. It's not at all defined, but certainly >>>>> includes a definition in which internet infrastructure or simply = (in a >>>>> single segment net) a base station does not exist. In IEEE 802 >>>>> terminology, two erstwhile subscriber stations need to = communicate. >>>>>=20 >>>>> The prism through which most public safety folks look at this is = the >>>> LMR >>>>> radio ... if I have the same freq as the guy over there that I can = see >>>>> then I can talk with him. >>>>> Once this migrates to internet, the information power is = amplified >>>>> enormously, but what happens if I can't see a DNS server or a SIP >>>> server >>>>> or ...? The PAWS concern is 'what if I can't see the white space >>>> server >>>>> in order to get a freq allocation to use'. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A suitable use case would be a sizable disaster where a lot of = internet >>>>> infrastructure ceases to function. Emergency services users need = to >>>>> reconstitute quickly and they will need radio WANs to do that. We = can >>>>> estimate that a lot of radio WAN gear that has been unused = suddenly >>>>> needs to be pressed into action. And the radio WANs need = frequency >>>>> authorizations to function. >>>>>=20 >>>>>=20 >>>>> That work? >>>>>=20 >>>>> On Fri, 2012-02-10 at 18:09 +0000, Basavaraj.Patil@nokia.com = wrote: >>>>>> HI Paul, >>>>>>=20 >>>>>> On 2/9/12 3:32 PM, "ext Paul Lambert" wrote: >>>>>>=20 >>>>>>>=20 >>>>>>>> The list in the current threat models text that I proposed is = by no >>>>>>>> means >>>>>>>> exhaustive=8A Or intended to be. The intent is to derive a key = set of >>>>>>>> security requirements for the protocol. The focus is on those >>>> threats >>>>>>>> that >>>>>>>> are relevant to the device-2-database protocol rather than to = the >>>> much >>>>>>>> more expansive topic of white space technology. >>>>>>>=20 >>>>>>> Yes, but ... >>>>>>>=20 >>>>>>> Without determining if there are technical mitigation mechanisms = we >>>>>>> should not be rejecting threats. The threats should all be = examined >>>>>> and >>>>>>> we should explicitly determine what is in scope versus = unilaterally >>>> as >>>>>>> part of the editing process. >>>>>>=20 >>>>>> No doubt. I don't think there is any unilateral proposal here. I = am >>>>>> happy >>>>>> to incorporate all relevant threats through the consensus process = and >>>>>> discussion on the mailing list. The threat model has evolved from >>>> Rev 1 >>>>>> to >>>>>> Rev 4 as a result of feedback from you and others. >>>>>>=20 >>>>>>>=20 >>>>>>> As an interesting example - if there is a natural disaster, = should >>>>>> there >>>>>>> be protocol mechanisms to enable use of emergency services = without >>>>>> direct >>>>>>> Internet connectivity to the DB? >>>>>>=20 >>>>>> Would you consider this as a threat or a feature that the = protocol >>>> needs >>>>>> to be concerned with regarding reachability of the database? >>>>>>=20 >>>>>>>=20 >>>>>>> Loss of service (emergency and normal) usage of WS is a threat = that >>>>>>> should be listed and may or may not be addressed by technical or >>>>>>> procedural mechanisms. >>>>>>=20 >>>>>> If you can elaborate or (preferably) provide the text describing = the >>>>>> threat and consequences, I would be happy to include it. >>>>>>=20 >>>>>> -Raj >>>>>>=20 >>>>>>>=20 >>>>>>> Paul >>>>>>=20 >>>>>> _______________________________________________ >>>>>> paws mailing list >>>>>> paws@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>=20 >>>>>=20 >>>>=20 >>>=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 From budden@nps.edu Mon Feb 13 09:00:34 2012 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 1A6AE21F8717 for ; Mon, 13 Feb 2012 09:00:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzpju2ZcM-Mc for ; Mon, 13 Feb 2012 09:00:32 -0800 (PST) Received: from mule.nps.edu (mule.nps.edu [205.155.65.106]) by ietfa.amsl.com (Postfix) with ESMTP id E215321F871C for ; Mon, 13 Feb 2012 09:00:31 -0800 (PST) X-ASG-Debug-ID: 1329152430-036c920f1b108b80001-Z0ZA9G Received: from hercules.ern.nps.edu (hercules.ern.nps.edu [172.20.24.111]) by mule.nps.edu with ESMTP id SSSElch0epBVI27i; Mon, 13 Feb 2012 09:00:30 -0800 (PST) X-Barracuda-Envelope-From: budden@nps.edu Received: from [172.20.58.67] (172.20.58.67) by smtp.nps.edu (172.20.24.111) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 13 Feb 2012 09:00:30 -0800 From: Rex Buddenberg X-ASG-Orig-Subj: Re: [paws] Threat model (Rev 3) To: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 13 Feb 2012 08:59:52 -0800 Message-ID: <1329152392.9169.2192.camel@localhost.localdomain> MIME-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: hercules.ern.nps.edu[172.20.24.111] X-Barracuda-Start-Time: 1329152430 X-Barracuda-URL: http://205.155.65.106:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at nps.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.88445 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Cc: paws@ietf.org Subject: Re: [paws] Threat model (Rev 3) 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: Mon, 13 Feb 2012 17:00:34 -0000 Raj, Since I recognize a great deal of pasting here, I don't think I could object. Seriously, looks like you've captured. On Fri, 2012-02-10 at 23:00 +0000, Basavaraj.Patil@nokia.com wrote: > Hi Paul/Rex, > > How about adding the following threat to the list: > > Threat 8: Natural disaster resulting in inability to obtain authorization > for > spectrum use by emergency responders > > In the case of a sizable natural disaster a lot of internet > infrastructure ceases to function. Emergency services users need to > reconstitute quickly and will rely on establishing radio WANs. The > potential for lot of radio WAN gear that has been unused suddenly > needs to be pressed into action. And the radio WANs need frequency > authorizations to function. Regulatory entities may also authorize > usage of additional spectrum in the affected areas. The white space > radio entities may need to establish communication with a database and > obtain authorizations. Alternatively there may be other mechanisms > which allow the use of spectrum by emergency service equipment without > strict authorization or with liberal interpretation of the regulatory > policy for white space usage. > > Please suggest additional text or changes as needed. > > -Raj > > > > > On 2/10/12 3:16 PM, "ext Rex Buddenberg" wrote: > > >On Fri, 2012-02-10 at 21:00 +0000, Basavaraj.Patil@nokia.com wrote: > >> Hi Rex, > >> > >> Thanks for the description. I understand the use case itself better now. > >> However I am still trying to parse the threat. > >> In the case of a natural disaster, I can imagine all types of radio > >> equipment being pressed into use. > >> So the statement: > >> "And the radio WANs need frequency authorizations to function." > >> > >> Is the threat then the inability to reach the entity that authorizes the > >> use of spectrum? > > > >Yes. > > > >> Is the reachability and inability to obtain authorization a result of a > >> malicious node preventing such communication? > > > >I did not consider this in the use case. What I was considering was > >that the disaster itself prevented comms, including those to the > >whitespace data server ... but not sure it would make a difference. > >However I would, in all use cases, consider authenticity of the data > >communicated (both ways) to be a requirement. > > > >> > >> Rgds, > >> -Raj > >> > >> > >> > >> On 2/10/12 2:28 PM, "ext Rex Buddenberg" wrote: > >> > >> >Raj, > >> > > >> >I'll try ... > >> > > >> >The public safety users of spectrum are very concerned with an issue > >> >they call 'talk around'. It's not at all defined, but certainly > >> >includes a definition in which internet infrastructure or simply (in a > >> >single segment net) a base station does not exist. In IEEE 802 > >> >terminology, two erstwhile subscriber stations need to communicate. > >> > > >> >The prism through which most public safety folks look at this is the > >>LMR > >> >radio ... if I have the same freq as the guy over there that I can see > >> >then I can talk with him. > >> > Once this migrates to internet, the information power is amplified > >> >enormously, but what happens if I can't see a DNS server or a SIP > >>server > >> >or ...? The PAWS concern is 'what if I can't see the white space > >>server > >> >in order to get a freq allocation to use'. > >> > > >> > > >> > > >> >A suitable use case would be a sizable disaster where a lot of internet > >> >infrastructure ceases to function. Emergency services users need to > >> >reconstitute quickly and they will need radio WANs to do that. We can > >> >estimate that a lot of radio WAN gear that has been unused suddenly > >> >needs to be pressed into action. And the radio WANs need frequency > >> >authorizations to function. > >> > > >> > > >> >That work? > >> > > >> >On Fri, 2012-02-10 at 18:09 +0000, Basavaraj.Patil@nokia.com wrote: > >> >> HI Paul, > >> >> > >> >> On 2/9/12 3:32 PM, "ext Paul Lambert" wrote: > >> >> > >> >> > > >> >> >>The list in the current threat models text that I proposed is by no > >> >> >>means > >> >> >>exhaustiveŠ Or intended to be. The intent is to derive a key set of > >> >> >>security requirements for the protocol. The focus is on those > >>threats > >> >> >>that > >> >> >>are relevant to the device-2-database protocol rather than to the > >>much > >> >> >>more expansive topic of white space technology. > >> >> > > >> >> >Yes, but ... > >> >> > > >> >> >Without determining if there are technical mitigation mechanisms we > >> >> >should not be rejecting threats. The threats should all be examined > >> >>and > >> >> >we should explicitly determine what is in scope versus unilaterally > >>as > >> >> >part of the editing process. > >> >> > >> >> No doubt. I don't think there is any unilateral proposal here. I am > >> >>happy > >> >> to incorporate all relevant threats through the consensus process and > >> >> discussion on the mailing list. The threat model has evolved from > >>Rev 1 > >> >>to > >> >> Rev 4 as a result of feedback from you and others. > >> >> > >> >> > > >> >> >As an interesting example - if there is a natural disaster, should > >> >>there > >> >> >be protocol mechanisms to enable use of emergency services without > >> >>direct > >> >> >Internet connectivity to the DB? > >> >> > >> >> Would you consider this as a threat or a feature that the protocol > >>needs > >> >> to be concerned with regarding reachability of the database? > >> >> > >> >> > > >> >> >Loss of service (emergency and normal) usage of WS is a threat that > >> >> >should be listed and may or may not be addressed by technical or > >> >> >procedural mechanisms. > >> >> > >> >> If you can elaborate or (preferably) provide the text describing the > >> >> threat and consequences, I would be happy to include it. > >> >> > >> >> -Raj > >> >> > >> >> > > >> >> >Paul > >> >> > >> >> _______________________________________________ > >> >> paws mailing list > >> >> paws@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/paws > >> > > >> > > >> > > > > > From Basavaraj.Patil@nokia.com Mon Feb 13 10:06:35 2012 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 07CA721F86DF for ; Mon, 13 Feb 2012 10:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.71 X-Spam-Level: X-Spam-Status: No, score=-102.71 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raqDYNxjdMmE for ; Mon, 13 Feb 2012 10:06:34 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1157C21F86DE for ; Mon, 13 Feb 2012 10:06:33 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1DI6M6H024319 for ; Mon, 13 Feb 2012 20:06:33 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 20:06:31 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Mon, 13 Feb 2012 19:06:30 +0100 From: To: Thread-Topic: UC&R I-D: Threat model (Rev 5) Thread-Index: AQHM6no1lbrYCG2XsUiw8yLUB+Whag== Date: Mon, 13 Feb 2012 18:06:29 +0000 Message-ID: <55B69094-ADAA-403B-82E7-9FD058F4DF5C@nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [72.64.95.66] Content-Type: text/plain; charset="us-ascii" Content-ID: <1CF55714F958A64A8F94CA4B4A5B6B4D@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2012 18:06:31.0419 (UTC) FILETIME=[36DBDCB0:01CCEA7A] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: Threat model (Rev 5) 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: Mon, 13 Feb 2012 18:06:35 -0000 Please find Rev 5 of the threat model. If we have consensus on this version= , I will incorporate it as part of the security considerations section of t= he I-D. -Raj Rev 5 (2/13/12) Changes:=20 1. Added threat 8 with feedback from Rex B., Paul L. Nancy B. and, Teco Boo= t Threat model for the PAWS protocol ---------------------------------- Assumptions: ............ o It is assumed that an attacker has full access to the network medium between the master device and the white space database. The attacker may be able to eavesdrop on any communications between these entities. The link between the master device and the white space database can be wired or wireless and provides IP connectivity. o It is assumed that the master device or the white space database have NOT been compromised from a security standpoint. Threat 1: User modifies a device to masquerade as another valid certified device Regulatory environments require that devices be certified and register in ways that accurately reflect their certification. Without suitable protection mechanisms, devices could simply listen to registration exchanges, and later registering claiming to be those other devices. Such replays would allow fasle registration, violating regulatory regimes.=20 A white space database may be operated by a commercial entity which restricts access to authorized users. A master device MAY need to identify itself to the database and be authorized to obtain information about available channels. Threat 2: Spoofed white space database A master device discovers a white space database(s) thru which it can query for channel information. The master device needs to ensure that the white space database with which it communicates with is an authentic entity. The white space database needs to provide its identity to the master device which can confirm the validity/authenticty of the database. An attacker may attempt to spoof a white space database and provide responses to a master device which are malicious and result in the master device causing interference to the primary user of the spectrum. Threat 3: Modifying a query request An attacker may modify the query request sent by a master device to a white space database. The attacker may change the location of the device or the capabilities in terms of its transmit power or antenna height etc. which could result in the database responding with incorrect information about available channels or max transmit power allowed. The result of such an attack is that the master device would cause intereference to the primary user of the spectrum. It could also result in a denial of service to the master device by indicating that no channels are available. =20 Threat 4: Modifying a query response An attacker could modify the query response sent by the white space database to a master device. The channel information or transmit power allowed type of parameters carried in the response could be modified by the attacker resulting in the master device using channels that are not available at a location or transmitting at a greater power level than allowed resulting in interference to the primary user of that spectrum. Alternatively the attacker may indicate no channel availability at a location resulting in a denial of service to the master device. Threat 5: Unauthorized use of channels by an uncertified device An attacker may be a master device which is not certified for use by the relevant regulatory body. The attacker may listen to the communication between a valid master device and white space database and utilize the information about available channels in the response message by utilizing those channels. The result of such an attack is unauthorized use of channels by a master device which is not certified to operate.=20 The master device querying the white space database may be operated by a law-enforcement agency and the communications between the device and the database are intended to be kept private. A malicious device should not be able to eavesdrop on such communications. Threat 6: Third party tracking of white space device location and identity A white space database in a regulatory domain may require a master device to provide its identity in addition to its location in the query request. Such location/identity information can be gleaned by an eavesdropper and used for tracking purposes. A master device may prefer to keep the location/identity information hidden from eavesdroppers, hence the protocol should provide a means to protect the location and identity information of the master device and prevent tracking of locations associated with a white space database query.=20 When the master device sends both its identity and location to the D= B, the DB is able to track it. If a regulatory domain does not require the master device to provide its identity to the white space databas= e, the master device may decide not to send its identity, to prevent being tracked by the DB. =20 Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or as MiM) to terminate or unfairly limit spectrum access of devices fo= r reasons other than incumbent protection=20 A white space database MAY include a mechanism by which service and channels allocated to a master device can be revoked by sending an unsolicited message. A malicious node can pretend to be the white space database with which a master device has registered or obtained channel information from and send a revoke message to that device. This results in denial of service to the master device.=20 Threat 8: Natural disaster resulting in inability to obtain authorization for white space spectrum use by emergency responders In the case of a sizable natural disaster a lot of internet infrastructure ceases to function. Emergency services users need to reconstitute quickly and will rely on establishing radio WANs. The potential for lot of radio WAN gear that has been unused suddenly needs to be pressed into action. And the radio WANs need frequency authorizations to function. Regulatory entities may also authorize usage of additional spectrum in the affected areas. The white space radio entities may need to establish communication with a database and obtain authorizations. In cases where communication with the white space database fails, the white space devices cannot utilize white space spectrum. Emergency services, which require more spectrum precisely at locations where network infrastructure is malfunctioning or overloaded, backup communication channels and distributed white space databases are needed to overcome such circumstances.Alternatively there may be other mechanisms which allow the use of spectrum by emergency service equipment without strict authorization or with liberal interpretation of the regulatory policy for white space usage. =20 From teco@inf-net.nl Mon Feb 13 12:10:36 2012 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 3CB1F21F875D for ; Mon, 13 Feb 2012 12:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w85OO-htjr80 for ; Mon, 13 Feb 2012 12:10:34 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C038F21F8755 for ; Mon, 13 Feb 2012 12:10:33 -0800 (PST) Received: by eekc41 with SMTP id c41so1987354eek.31 for ; Mon, 13 Feb 2012 12:10:28 -0800 (PST) Received: by 10.213.34.196 with SMTP id m4mr2990186ebd.51.1329163828083; Mon, 13 Feb 2012 12:10:28 -0800 (PST) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id z47sm64441895eeh.9.2012.02.13.12.10.27 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 12:10:27 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Teco Boot In-Reply-To: <55B69094-ADAA-403B-82E7-9FD058F4DF5C@nokia.com> Date: Mon, 13 Feb 2012 21:10:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55B69094-ADAA-403B-82E7-9FD058F4DF5C@nokia.com> To: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkToGGey16olsyt+JOCMgRwnyXfcfnhX85kjgsumCwm7n7nG3pRsdJJpC3ls9zaE23Hbf9f Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Threat model (Rev 5) 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: Mon, 13 Feb 2012 20:10:36 -0000 Raj, others, I posted comments on your first outline.=20 http://www.ietf.org/mail-archive/web/paws/current/msg00765.html Does it make sense? Thanks, Teco Op 13 feb. 2012, om 19:06 heeft = het volgende geschreven: >=20 > Please find Rev 5 of the threat model. If we have consensus on this = version, I will incorporate it as part of the security considerations = section of the I-D. >=20 > -Raj >=20 >=20 > Rev 5 (2/13/12) >=20 > Changes:=20 >=20 > 1. Added threat 8 with feedback from Rex B., Paul L. Nancy B. and, = Teco Boot >=20 >=20 >=20 > Threat model for the PAWS protocol > ---------------------------------- >=20 > Assumptions: > ............ >=20 > o It is assumed that an attacker has full access to the network medium > between the master device and the white space database. The attacker > may be able to eavesdrop on any communications between these > entities. The link between the master device and the white space > database can be wired or wireless and provides IP connectivity. >=20 > o It is assumed that the master device or the white space database > have NOT been compromised from a security standpoint. >=20 > Threat 1: User modifies a device to masquerade as another valid > certified device >=20 > Regulatory environments require that devices be certified and > register in ways that accurately reflect their certification. > Without suitable protection mechanisms, devices could simply > listen to registration exchanges, and later registering > claiming to be those other devices. Such replays would allow > fasle registration, violating regulatory regimes.=20 > A white space database may be operated by a commercial entity > which restricts access to authorized users. A master device > MAY need to identify itself to the database and be authorized to > obtain information about available channels. >=20 > Threat 2: Spoofed white space database >=20 > A master device discovers a white space database(s) thru which > it can query for channel information. The master device needs > to ensure that the white space database with which it > communicates with is an authentic entity. The white space > database needs to provide its identity to the master device > which can confirm the validity/authenticty of the database. An > attacker may attempt to spoof a white space database and > provide responses to a master device which are malicious and > result in the master device causing interference to the primary > user of the spectrum. >=20 > Threat 3: Modifying a query request >=20 > An attacker may modify the query request sent by a master > device to a white space database. The attacker may change the > location of the device or the capabilities in terms of its > transmit power or antenna height etc. which could result in the > database responding with incorrect information about available > channels or max transmit power allowed. The result of such an > attack is that the master device would cause intereference to > the primary user of the spectrum. It could also result in a > denial of service to the master device by indicating that no > channels are available. =20 >=20 > Threat 4: Modifying a query response >=20 > An attacker could modify the query response sent by the white > space database to a master device. The channel information or > transmit power allowed type of parameters carried in the > response could be modified by the attacker resulting in the > master device using channels that are not available at a > location or transmitting at a greater power level than allowed > resulting in interference to the primary user of that > spectrum. Alternatively the attacker may indicate no channel > availability at a location resulting in a denial of service to > the master device. >=20 > Threat 5: Unauthorized use of channels by an uncertified device >=20 > An attacker may be a master device which is not certified for > use by the relevant regulatory body. The attacker may listen to > the communication between a valid master device and white space > database and utilize the information about available channels > in the response message by utilizing those channels. The result > of such an attack is unauthorized use of channels by a master > device which is not certified to operate.=20 > The master device querying the white space database may be > operated by a law-enforcement agency and the communications > between the device and the database are intended to be kept > private. A malicious device should not be able to eavesdrop on > such communications. >=20 > Threat 6: Third party tracking of white space device location and = identity >=20 > A white space database in a regulatory domain may require a > master device to provide its identity in addition to its > location in the query request. Such location/identity > information can be gleaned by an eavesdropper and used for > tracking purposes. A master device may prefer to keep the > location/identity information hidden from eavesdroppers, hence > the protocol should provide a means to protect the location and > identity information of the master device and prevent tracking > of locations associated with a white space database query.=20 > When the master device sends both its identity and location to = the DB, > the DB is able to track it. If a regulatory domain does not = require > the master device to provide its identity to the white space = database, > the master device may decide not to send its identity, to = prevent > being tracked by the DB. =20 >=20 > Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or > as MiM) to terminate or unfairly limit spectrum access of = devices for > reasons other than incumbent protection=20 >=20 > A white space database MAY include a mechanism by which service > and channels allocated to a master device can be revoked by > sending an unsolicited message. A malicious node can pretend to > be the white space database with which a master device has > registered or obtained channel information from and send a > revoke message to that device. This results in denial of > service to the master device.=20 >=20 > Threat 8: Natural disaster resulting in inability to obtain = authorization > for white space spectrum use by emergency responders >=20 > In the case of a sizable natural disaster a lot of internet > infrastructure ceases to function. Emergency services users > need to reconstitute quickly and will rely on establishing > radio WANs. The potential for lot of radio WAN gear that has > been unused suddenly needs to be pressed into action. And > the radio WANs need frequency authorizations to > function. Regulatory entities may also authorize usage of > additional spectrum in the affected areas. The white space > radio entities may need to establish communication with a > database and obtain authorizations. In cases where > communication with the white space database fails, the white > space devices cannot utilize white space spectrum. Emergency > services, which require more spectrum precisely at locations > where network infrastructure is malfunctioning or > overloaded, backup communication channels and distributed > white space databases are needed to overcome such > circumstances.Alternatively there may be other mechanisms > which allow the use of spectrum by emergency service > equipment without strict authorization or with liberal > interpretation of the regulatory policy for white space > usage. =20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Basavaraj.Patil@nokia.com Mon Feb 13 12:32:59 2012 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 7D21221F84B5 for ; Mon, 13 Feb 2012 12:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPUG7-szkePj for ; Mon, 13 Feb 2012 12:32:58 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 746AC21F8453 for ; Mon, 13 Feb 2012 12:32:58 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1DKWoTH024352; Mon, 13 Feb 2012 22:32:53 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 Feb 2012 22:32:50 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Mon, 13 Feb 2012 21:32:50 +0100 From: To: Thread-Topic: [paws] UC&R I-D: Threat model (Rev 5) Thread-Index: AQHM6no1lbrYCG2XsUiw8yLUB+WhapY7MVWA//+hugA= Date: Mon, 13 Feb 2012 20:32:49 +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.14.0.111121 x-originating-ip: [72.64.95.66] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2012 20:32:50.0818 (UTC) FILETIME=[A7C9D620:01CCEA8E] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Threat model (Rev 5) 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: Mon, 13 Feb 2012 20:32:59 -0000 Yes. I did see your comment and incorporated it into Threat 8. -Raj On 2/13/12 2:10 PM, "ext Teco Boot" wrote: >Raj, others, > >I posted comments on your first outline. >http://www.ietf.org/mail-archive/web/paws/current/msg00765.html >Does it make sense? > >Thanks, Teco > >Op 13 feb. 2012, om 19:06 heeft > het volgende geschreven: > >>=20 >> Please find Rev 5 of the threat model. If we have consensus on this >>version, I will incorporate it as part of the security considerations >>section of the I-D. >>=20 >> -Raj >>=20 >>=20 >> Rev 5 (2/13/12) >>=20 >> Changes:=20 >>=20 >> 1. Added threat 8 with feedback from Rex B., Paul L. Nancy B. and, Teco >>Boot >>=20 >>=20 >>=20 >> Threat model for the PAWS protocol >> ---------------------------------- >>=20 >> Assumptions: >> ............ >>=20 >> o It is assumed that an attacker has full access to the network medium >> between the master device and the white space database. The attacker >> may be able to eavesdrop on any communications between these >> entities. The link between the master device and the white space >> database can be wired or wireless and provides IP connectivity. >>=20 >> o It is assumed that the master device or the white space database >> have NOT been compromised from a security standpoint. >>=20 >> Threat 1: User modifies a device to masquerade as another valid >> certified device >>=20 >> Regulatory environments require that devices be certified and >> register in ways that accurately reflect their certification. >> Without suitable protection mechanisms, devices could simply >> listen to registration exchanges, and later registering >> claiming to be those other devices. Such replays would allow >> fasle registration, violating regulatory regimes. >> A white space database may be operated by a commercial entity >> which restricts access to authorized users. A master device >> MAY need to identify itself to the database and be authorized to >> obtain information about available channels. >>=20 >> Threat 2: Spoofed white space database >>=20 >> A master device discovers a white space database(s) thru which >> it can query for channel information. The master device needs >> to ensure that the white space database with which it >> communicates with is an authentic entity. The white space >> database needs to provide its identity to the master device >> which can confirm the validity/authenticty of the database. An >> attacker may attempt to spoof a white space database and >> provide responses to a master device which are malicious and >> result in the master device causing interference to the primary >> user of the spectrum. >>=20 >> Threat 3: Modifying a query request >>=20 >> An attacker may modify the query request sent by a master >> device to a white space database. The attacker may change the >> location of the device or the capabilities in terms of its >> transmit power or antenna height etc. which could result in the >> database responding with incorrect information about available >> channels or max transmit power allowed. The result of such an >> attack is that the master device would cause intereference to >> the primary user of the spectrum. It could also result in a >> denial of service to the master device by indicating that no >> channels are available. >>=20 >> Threat 4: Modifying a query response >>=20 >> An attacker could modify the query response sent by the white >> space database to a master device. The channel information or >> transmit power allowed type of parameters carried in the >> response could be modified by the attacker resulting in the >> master device using channels that are not available at a >> location or transmitting at a greater power level than allowed >> resulting in interference to the primary user of that >> spectrum. Alternatively the attacker may indicate no channel >> availability at a location resulting in a denial of service to >> the master device. >>=20 >> Threat 5: Unauthorized use of channels by an uncertified device >>=20 >> An attacker may be a master device which is not certified for >> use by the relevant regulatory body. The attacker may listen to >> the communication between a valid master device and white space >> database and utilize the information about available channels >> in the response message by utilizing those channels. The result >> of such an attack is unauthorized use of channels by a master >> device which is not certified to operate. >> The master device querying the white space database may be >> operated by a law-enforcement agency and the communications >> between the device and the database are intended to be kept >> private. A malicious device should not be able to eavesdrop on >> such communications. >>=20 >> Threat 6: Third party tracking of white space device location and >>identity >>=20 >> A white space database in a regulatory domain may require a >> master device to provide its identity in addition to its >> location in the query request. Such location/identity >> information can be gleaned by an eavesdropper and used for >> tracking purposes. A master device may prefer to keep the >> location/identity information hidden from eavesdroppers, hence >> the protocol should provide a means to protect the location and >> identity information of the master device and prevent tracking >> of locations associated with a white space database query. >> When the master device sends both its identity and location to >>the DB, >> the DB is able to track it. If a regulatory domain does not >>require >> the master device to provide its identity to the white space >>database, >> the master device may decide not to send its identity, to prevent >> being tracked by the DB. >>=20 >> Threat 7: Malicious individual acts as a PAWS entity (spoofing DB or >> as MiM) to terminate or unfairly limit spectrum access of devices >>for >> reasons other than incumbent protection >>=20 >> A white space database MAY include a mechanism by which service >> and channels allocated to a master device can be revoked by >> sending an unsolicited message. A malicious node can pretend to >> be the white space database with which a master device has >> registered or obtained channel information from and send a >> revoke message to that device. This results in denial of >> service to the master device. >>=20 >> Threat 8: Natural disaster resulting in inability to obtain >>authorization >> for white space spectrum use by emergency responders >>=20 >> In the case of a sizable natural disaster a lot of internet >> infrastructure ceases to function. Emergency services users >> need to reconstitute quickly and will rely on establishing >> radio WANs. The potential for lot of radio WAN gear that has >> been unused suddenly needs to be pressed into action. And >> the radio WANs need frequency authorizations to >> function. Regulatory entities may also authorize usage of >> additional spectrum in the affected areas. The white space >> radio entities may need to establish communication with a >> database and obtain authorizations. In cases where >> communication with the white space database fails, the white >> space devices cannot utilize white space spectrum. Emergency >> services, which require more spectrum precisely at locations >> where network infrastructure is malfunctioning or >> overloaded, backup communication channels and distributed >> white space databases are needed to overcome such >> circumstances.Alternatively there may be other mechanisms >> which allow the use of spectrum by emergency service >> equipment without strict authorization or with liberal >> interpretation of the regulatory policy for white space >> usage. =20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws > From Basavaraj.Patil@nokia.com Wed Feb 15 13:37:58 2012 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 30E7621F8501 for ; Wed, 15 Feb 2012 13:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.684 X-Spam-Level: X-Spam-Status: No, score=-102.684 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3jdGckmLU2H for ; Wed, 15 Feb 2012 13:37:54 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 17D1D21E80B9 for ; Wed, 15 Feb 2012 13:37:53 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1FLbmOI022305 for ; Wed, 15 Feb 2012 23:37:52 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.58]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Feb 2012 23:37:50 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-003.mgdnok.nokia.com ([65.54.30.58]) with mapi id 14.01.0355.003; Wed, 15 Feb 2012 22:37:50 +0100 From: To: Thread-Topic: UC&R I-D: Security requirements Thread-Index: AQHM7CoQ79jNBhlTZkuzVF9Vqw/cXA== Date: Wed, 15 Feb 2012 21:37:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.137] Content-Type: text/plain; charset="us-ascii" Content-ID: <5EA38A63DFA8DB44B1D864AB56949168@nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Feb 2012 21:37:50.0368 (UTC) FILETIME=[10ED7200:01CCEC2A] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: Security requirements 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, 15 Feb 2012 21:37:58 -0000 Hello,=20 The following are the security requirements for the device-2-database protocol that have been derived from the threat model: (http://www.ietf.org/mail-archive/web/paws/current/msg00768.html). -Raj Threat1 to Reqt1 -> The protocol MUST provide the ability for the WSDB to authenticate the master device. =20 Threat 2 to Reqt2 -> The protocol MUST provide the ability for the master device to verify the authenticity of the WSDB that it is interacting with. =20 Threat 3 to Reqt3 -> The messages sent by the master device to the WSDB MUST be integrity protected. =20 Threat 4 to Reqt4 -> The messages sent by the WSDB to the master device MUST be integrity protected. =20 Threat 5 to Reqt5-> The protocol MUST provide the capability for messages sent by the master device and WSDB to be encrypted. =20 Threat 6 to Reqt6-> A Master device MAY not include its identity in messages sent to the WSDB when not required by the regulatory domain. From scott.probasco@nokia.com Tue Feb 21 08:46:26 2012 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 CA65121F8671 for ; Tue, 21 Feb 2012 08:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.132 X-Spam-Level: X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, J_BACKHAIR_22=1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuKUbUg7Scvi for ; Tue, 21 Feb 2012 08:46:25 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id BC67321F86DB for ; Tue, 21 Feb 2012 08:46:25 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1LGkJrM015397; Tue, 21 Feb 2012 18:46:21 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 18:46:19 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Tue, 21 Feb 2012 17:46:18 +0100 From: To: , Thread-Topic: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) Thread-Index: AQHM4cbBM1LY84Ao6UaXhXGJCbWG9JYp8MrggB1G9wA= Date: Tue, 21 Feb 2012 16:46:18 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140654A1703@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.53.9] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2012 16:46:19.0691 (UTC) FILETIME=[56266FB0:01CCF0B8] X-Nokia-AV: Clean Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) 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, 21 Feb 2012 16:46:26 -0000 Hi Andy, All, Following up on your keen observation about registration as a pre-requisite. It may not be required in all regulatory domains, and also not for all device types. If there are no objections, I will make the following correction: Registration ismay be preliminary to creating a radio network using white space; in some regulatory domains, for some device types, it is a prerequisite to the use cases below. The radio network is created by a master device. Kind Regards, Scott On 2/2/12 1:02 PM, "ext andy.sago@bt.com" wrote: >Scott > >The Device Registration use case at 4.1.2 is shown as a pre-requisite, >but may not be required in all regulatory domains. I take your point >though that at present we only have firm requirements from the FCC. > >I guess that the left most device in the diagram in 4.1.2 should be >labelled slave, not master. > >There is a conflict between the use case (elsewhere) that allows for WS >backhaul, and step 1 of database discovery in 4.1.1. It is possible for a >master to send a service request to the database over the WS, if it does >so as a slave to another master on that master's allowed frequencies. We >could correct step 1 to reflect this as follows: > >1. The master device is connected to the internet by any means other >than using the TV white space radio. An >exception is where the master device also has slave capabilities and is >already connected to the internet as a slave of the white space radio >network of another master. > >Regards > >Andy > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >scott.probasco@nokia.com >Sent: 02 February 2012 16:22 >To: paws@ietf.org >Subject: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device >registration with trusted database) > >Hello All, > >As editors of the problem statement, use cases & requirements draft we >are attempting to prepare a completed draft which could be ready for >working group last call before IETF83. In the coming days we will post >the sections of the draft to the mailing list. Our request is that you >review these sections and reply to the email with any comments. > >Below is the text for sections on protocol services (new section >numbering). This text has been marked up from version-02 as uploaded >January 26, 2012 to include the previous comments on the mail reflector >about use cases vs. protocol services, plus a few suggestions from the >editor (removing 'TV' since PAWS applies to all white space, correcting >for the fact that we only know at this time the FCC's specific >requirements for registration). > >Our goal is that any discussion on this text will conclude by February 9. >To be clear, approval of the document will go through the normal process >of last calls etc.. We are simply asking for your assistance in preparing >a complete & accurate document that could progress the work. So please >review the text and send your comments either directly to the editor or >to the mailing list. > >Kind Regards, >Raj & Scott > > > > > >4.1 Protocol Services > >A complete protocol solution must provide all services that are essential >to enable the white space paradigm. Before a white space device can >request service from a white space database, such as a query for a list >of available channels, the white space device must first locate or >"discover" a suitable database. Additionally, some regulatory authorities >require the white space device to register with the database as a first >step. This section describes the services required from the protocol. > > >4.1.1. TVWSWhite space database >discovery > >This use caseWhite space database >discovery is preliminary to creating a radio network using >TV > white space; it is a prerequisite to >otherthe use cases >below. The radio > network is created by a master device. Before the master device can > transmit in TV white space spectrum, it must contact >a trusted > database where the device can learn if any channels are available for > it to use. The master device will need to discover a trusted > database in the relvant regulatory domain, using the following steps: > > 1. The master device is connected to the internet by any means other > than using the TV white space radio. > > 2. The master device constructs and sends a service request over the > Internet to discover availability of trusted databases in the > local regulatory domain and waits for responses. > > 3. If no acceptable response is received within a pre-configured > time limit, the master device concludes that no trusted database > is available. If at least one response is received, the master > device evaluates the response(s) to determine if a trusted > database can be identified where the master device is able to > register and receive service from the database. > > Optionally the radio device is pre-programmed with the internet > address of at least one trusted database. The device can establish > contact with a trusted database using one of the pre-programmed > internet addresses and establish a TV white space >network (as > described in one of the following use cases). > > Optionally the initial query will be made to a listing approved by > the national regulator for the domain of operation (e.g. a website > either hosted by or under control of the national regulator) which > maintains a list of TVWS databases and their internet >addresses. The > query results in the list of databases and their internet addresses > being sent to the master, which then evaluates the repsonse to > determine if a trusted database can be identified where the master > device is able to register and receive service from the database. > > >4.1.2. Device registration with trusted Database > > This use caseRegistration is >preliminary to creating a radio network using TV > white space; it is a prerequisite to >otherthe use cases >below. The radio > network is created by a master device. Before the master device can > transmit in TV white space spectrum, it must contact >a trusted > database where the device can learn if any channels are available for > it to use. Before the database will provide information on available > TVradio channels, the master device >must register with the trusted > database. Specific requirements for registration come from > individual regulatory domains and may be different. > > The figure below shows an example deployment of this scenario. > > > > \|/ ---------- > | |Database| > | .---. /--------- > |-|---------| ( ) / > \|/ | Master | / \ > | / | |=3D=3D=3D=3D=3D=3D=3D=3D( Intern= et ) > | / |-----------| \ / > +-|----+ (TDD AirIF) ( ) > |Master| / (----) > | | / > +------+ > > Figure 2: Example illustration of registration requirement in >TV > white space use-case > > A simplified operational scenario showing registration consists of > the following steps: > > 1. The master device must register with >theits most current and up-to- > date information. Typically the master device will register > prior to operating in TV white space for the >first time after > power up, after changing location by a predetermined distance, > and after regular time intervals. > > 2. The master device shall provide to the database during > registration all information required according to local >regulatory requirements. This information may include, but is not limited >to, a minimum of the Device ID, serial number >assigned by the manufacturer and the device's >location, device antenna height above ground, name of the >individual or business that owns the device, name of a contact person >responsible for the device's operation, address for the > contact person, email address for the contact person and phone >number of the contact person. > > > 3. Depending upon regulatory domain requirements, the device may > also provide device antenna height above ground, name of the > individual or business that owns the device, name of a contact > person responsible for the device's operation, address for the > contact person, email address for the contact person and phone > number of the contact person to the database during registration. > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From andy.sago@bt.com Tue Feb 21 08:53:46 2012 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 4308321F886E for ; Tue, 21 Feb 2012 08:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, J_BACKHAIR_22=1, J_CHICKENPOX_21=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bEmWQ0iVYyHv for ; Tue, 21 Feb 2012 08:53:44 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id C804121F8873 for ; Tue, 21 Feb 2012 08:53:43 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Feb 2012 16:53:39 +0000 Received: from EMV62-UKRD.domain1.systemhost.net ([169.254.1.213]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Tue, 21 Feb 2012 16:53:40 +0000 From: To: , Date: Tue, 21 Feb 2012 16:53:38 +0000 Thread-Topic: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) Thread-Index: AQHM4cbBM1LY84Ao6UaXhXGJCbWG9JYp8MrggB1G9wCAAHZZsA== Message-ID: <619CDADDCCD2B44380834BE8BF6F714140682E7B5B@EMV62-UKRD.domain1.systemhost.net> References: <619CDADDCCD2B44380834BE8BF6F714140654A1703@EMV62-UKRD.domain1.systemhost.net> In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) 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, 21 Feb 2012 16:53:46 -0000 Scott Good for me. A consequential revision would be consistent in the (old) 4.1.= 1 on database discovery. At step 3 it says "If at least one response is rec= eived, the master device evaluates the response(s) to determine if a truste= d database can be identified where the master device is able to register an= d receive service from the database." I suggest the intent is the same and = the application consistent across regulatory domains if "register and recei= ve service" is changed to "receive service". Regards Andy -----Original Message----- From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: 21 February 2012 16:46 To: Sago,AJ,Andy,COD R; paws@ietf.org Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device = registration with trusted database) Hi Andy, All, Following up on your keen observation about registration as a pre-requisite= . It may not be required in all regulatory domains, and also not for all de= vice types. If there are no objections, I will make the following correctio= n: Registration ismay be preliminary to crea= ting a radio network using white space; in some regulatory domains,= for some device types, it is a prerequisite to the use cases belo= w. The radio network is created by a master device. Kind Regards, Scott On 2/2/12 1:02 PM, "ext andy.sago@bt.com" wrote: >Scott > >The Device Registration use case at 4.1.2 is shown as a pre-requisite,=20 >but may not be required in all regulatory domains. I take your point=20 >though that at present we only have firm requirements from the FCC. > >I guess that the left most device in the diagram in 4.1.2 should be=20 >labelled slave, not master. > >There is a conflict between the use case (elsewhere) that allows for WS=20 >backhaul, and step 1 of database discovery in 4.1.1. It is possible for=20 >a master to send a service request to the database over the WS, if it=20 >does so as a slave to another master on that master's allowed=20 >frequencies. We could correct step 1 to reflect this as follows: > >1. The master device is connected to the internet by any means other=20 >than using the TV white space radio. An=20 >exception is where the master device also has slave capabilities and is=20 >already connected to the internet as a slave of the white space radio=20 >network of another master. > >Regards > >Andy > >-----Original Message----- >From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of=20 >scott.probasco@nokia.com >Sent: 02 February 2012 16:22 >To: paws@ietf.org >Subject: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device=20 >registration with trusted database) > >Hello All, > >As editors of the problem statement, use cases & requirements draft we=20 >are attempting to prepare a completed draft which could be ready for=20 >working group last call before IETF83. In the coming days we will post=20 >the sections of the draft to the mailing list. Our request is that you=20 >review these sections and reply to the email with any comments. > >Below is the text for sections on protocol services (new section=20 >numbering). This text has been marked up from version-02 as uploaded=20 >January 26, 2012 to include the previous comments on the mail reflector=20 >about use cases vs. protocol services, plus a few suggestions from the=20 >editor (removing 'TV' since PAWS applies to all white space, correcting=20 >for the fact that we only know at this time the FCC's specific=20 >requirements for registration). > >Our goal is that any discussion on this text will conclude by February 9. >To be clear, approval of the document will go through the normal=20 >process of last calls etc.. We are simply asking for your assistance in=20 >preparing a complete & accurate document that could progress the work.=20 >So please review the text and send your comments either directly to the=20 >editor or to the mailing list. > >Kind Regards, >Raj & Scott > > > > > >4.1 Protocol Services > >A complete protocol solution must provide all services that are=20 >essential to enable the white space paradigm. Before a white space=20 >device can request service from a white space database, such as a query=20 >for a list of available channels, the white space device must first=20 >locate or "discover" a suitable database. Additionally, some regulatory=20 >authorities require the white space device to register with the=20 >database as a first step. This section describes the services required fro= m the protocol. > > >4.1.1. TVWSWhite space database=20 >discovery > >This use caseWhite space database=20 >discovery is preliminary to creating a radio network using=20 >TV > white space; it is a prerequisite to=20 >otherthe use cases=20 >below. The radio > network is created by a master device. Before the master device can > transmit in TV white space spectrum, it must=20 >contact a trusted > database where the device can learn if any channels are available for > it to use. The master device will need to discover a trusted > database in the relvant regulatory domain, using the following steps: > > 1. The master device is connected to the internet by any means other > than using the TV white space radio. > > 2. The master device constructs and sends a service request over the > Internet to discover availability of trusted databases in the > local regulatory domain and waits for responses. > > 3. If no acceptable response is received within a pre-configured > time limit, the master device concludes that no trusted database > is available. If at least one response is received, the master > device evaluates the response(s) to determine if a trusted > database can be identified where the master device is able to > register and receive service from the database. > > Optionally the radio device is pre-programmed with the internet > address of at least one trusted database. The device can establish > contact with a trusted database using one of the pre-programmed > internet addresses and establish a TV white space=20 >network (as > described in one of the following use cases). > > Optionally the initial query will be made to a listing approved by > the national regulator for the domain of operation (e.g. a website > either hosted by or under control of the national regulator) which > maintains a list of TVWS databases and their=20 >internet addresses. The > query results in the list of databases and their internet addresses > being sent to the master, which then evaluates the repsonse to > determine if a trusted database can be identified where the master > device is able to register and receive service from the database. > > >4.1.2. Device registration with trusted Database > > This use caseRegistration is=20 >preliminary to creating a radio network using TV > white space; it is a prerequisite to=20 >otherthe use cases=20 >below. The radio > network is created by a master device. Before the master device can > transmit in TV white space spectrum, it must=20 >contact a trusted > database where the device can learn if any channels are available for > it to use. Before the database will provide information on available > TVradio channels, the master=20 >device must register with the trusted > database. Specific requirements for registration come from > individual regulatory domains and may be different. > > The figure below shows an example deployment of this scenario. > > > > \|/ ---------- > | |Database| > | .---. /--------- > |-|---------| ( ) / > \|/ | Master | / \ > | / | |=3D=3D=3D=3D=3D=3D=3D=3D( Intern= et ) > | / |-----------| \ / > +-|----+ (TDD AirIF) ( ) > |Master| / (----) > | | / > +------+ > > Figure 2: Example illustration of registration requirement in=20 >TV > white space use-case > > A simplified operational scenario showing registration consists of > the following steps: > > 1. The master device must register with=20 >theits most current and up-to- > date information. Typically the master device will register > prior to operating in TV white space for the=20 >first time after > power up, after changing location by a predetermined distance, > and after regular time intervals. > > 2. The master device shall provide to the database during > registration all information required according to local=20 >regulatory requirements. This information may include, but is not=20 >limited to, a minimum of the Device ID,=20 >serial number assigned by the manufacturer and the=20 >device's location, device antenna height above ground, name of=20 >the individual or business that owns the device, name of a contact=20 >person responsible for the device's operation, address for the > contact person, email address for the contact person and phone=20 >number of the contact person. > > > 3. Depending upon regulatory domain requirements, the device may > also provide device antenna height above ground, name of the > individual or business that owns the device, name of a contact > person responsible for the device's operation, address for the > contact person, email address for the contact person and phone > number of the contact person to the database during registration. > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Tue Feb 21 09:00:07 2012 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 6EB5E21F8698 for ; Tue, 21 Feb 2012 09:00:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, J_BACKHAIR_22=1, J_CHICKENPOX_21=0.6, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUn-cXRJiiCA for ; Tue, 21 Feb 2012 09:00:03 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE5321F8620 for ; Tue, 21 Feb 2012 09:00:03 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1LGxNmH029085; Tue, 21 Feb 2012 18:59:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 18:59:16 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Tue, 21 Feb 2012 17:59:13 +0100 From: To: , Thread-Topic: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) Thread-Index: AQHM4cbBM1LY84Ao6UaXhXGJCbWG9JYp8MrggB1G9wCAAHZZsP//jT0A Date: Tue, 21 Feb 2012 16:59:13 +0000 Message-ID: In-Reply-To: <619CDADDCCD2B44380834BE8BF6F714140682E7B5B@EMV62-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.53.9] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2012 16:59:16.0958 (UTC) FILETIME=[256FF7E0:01CCF0BA] X-Nokia-AV: Clean Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device registration with trusted database) 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, 21 Feb 2012 17:00:07 -0000 Hi Andy, I agree with you. Kind Regards, Scott On 2/21/12 10:53 AM, "ext andy.sago@bt.com" wrote: >Scott > >Good for me. A consequential revision would be consistent in the (old) >4.1.1 on database discovery. At step 3 it says "If at least one response >is received, the master device evaluates the response(s) to determine if >a trusted database can be identified where the master device is able to >register and receive service from the database." I suggest the intent is >the same and the application consistent across regulatory domains if >"register and receive service" is changed to "receive service". > >Regards > >Andy > >-----Original Message----- >From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] >Sent: 21 February 2012 16:46 >To: Sago,AJ,Andy,COD R; paws@ietf.org >Subject: Re: [paws] UC&R I-D: section 4.1 (TVWS database discovery, >device registration with trusted database) > >Hi Andy, All, > >Following up on your keen observation about registration as a >pre-requisite. It may not be required in all regulatory domains, and also >not for all device types. If there are no objections, I will make the >following correction: > >Registration ismay be preliminary to >creating a radio network using white space; in some regulatory >domains, for some device types, it is a prerequisite to the use >cases below. The radio network is created by a master device. > > >Kind Regards, >Scott > >On 2/2/12 1:02 PM, "ext andy.sago@bt.com" wrote: > >>Scott >> >>The Device Registration use case at 4.1.2 is shown as a pre-requisite, >>but may not be required in all regulatory domains. I take your point >>though that at present we only have firm requirements from the FCC. >> >>I guess that the left most device in the diagram in 4.1.2 should be >>labelled slave, not master. >> >>There is a conflict between the use case (elsewhere) that allows for WS >>backhaul, and step 1 of database discovery in 4.1.1. It is possible for >>a master to send a service request to the database over the WS, if it >>does so as a slave to another master on that master's allowed >>frequencies. We could correct step 1 to reflect this as follows: >> >>1. The master device is connected to the internet by any means other >>than using the TV white space radio. An >>exception is where the master device also has slave capabilities and is >>already connected to the internet as a slave of the white space radio >>network of another master. >> >>Regards >> >>Andy >> >>-----Original Message----- >>From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>scott.probasco@nokia.com >>Sent: 02 February 2012 16:22 >>To: paws@ietf.org >>Subject: [paws] UC&R I-D: section 4.1 (TVWS database discovery, device >>registration with trusted database) >> >>Hello All, >> >>As editors of the problem statement, use cases & requirements draft we >>are attempting to prepare a completed draft which could be ready for >>working group last call before IETF83. In the coming days we will post >>the sections of the draft to the mailing list. Our request is that you >>review these sections and reply to the email with any comments. >> >>Below is the text for sections on protocol services (new section >>numbering). This text has been marked up from version-02 as uploaded >>January 26, 2012 to include the previous comments on the mail reflector >>about use cases vs. protocol services, plus a few suggestions from the >>editor (removing 'TV' since PAWS applies to all white space, correcting >>for the fact that we only know at this time the FCC's specific >>requirements for registration). >> >>Our goal is that any discussion on this text will conclude by February 9. >>To be clear, approval of the document will go through the normal >>process of last calls etc.. We are simply asking for your assistance in >>preparing a complete & accurate document that could progress the work. >>So please review the text and send your comments either directly to the >>editor or to the mailing list. >> >>Kind Regards, >>Raj & Scott >> >> >> >> >> >>4.1 Protocol Services >> >>A complete protocol solution must provide all services that are >>essential to enable the white space paradigm. Before a white space >>device can request service from a white space database, such as a query >>for a list of available channels, the white space device must first >>locate or "discover" a suitable database. Additionally, some regulatory >>authorities require the white space device to register with the >>database as a first step. This section describes the services required >>from the protocol. >> >> >>4.1.1. TVWSWhite space database >>discovery >> >>This use caseWhite space database >>discovery is preliminary to creating a radio network using >>TV >> white space; it is a prerequisite to >>otherthe use cases >>below. The radio >> network is created by a master device. Before the master device can >> transmit in TV white space spectrum, it must >>contact a trusted >> database where the device can learn if any channels are available for >> it to use. The master device will need to discover a trusted >> database in the relvant regulatory domain, using the following steps: >> >> 1. The master device is connected to the internet by any means other >> than using the TV white space radio. >> >> 2. The master device constructs and sends a service request over the >> Internet to discover availability of trusted databases in the >> local regulatory domain and waits for responses. >> >> 3. If no acceptable response is received within a pre-configured >> time limit, the master device concludes that no trusted database >> is available. If at least one response is received, the master >> device evaluates the response(s) to determine if a trusted >> database can be identified where the master device is able to >> register and receive service from the database. >> >> Optionally the radio device is pre-programmed with the internet >> address of at least one trusted database. The device can establish >> contact with a trusted database using one of the pre-programmed >> internet addresses and establish a TV white space >>network (as >> described in one of the following use cases). >> >> Optionally the initial query will be made to a listing approved by >> the national regulator for the domain of operation (e.g. a website >> either hosted by or under control of the national regulator) which >> maintains a list of TVWS databases and their >>internet addresses. The >> query results in the list of databases and their internet addresses >> being sent to the master, which then evaluates the repsonse to >> determine if a trusted database can be identified where the master >> device is able to register and receive service from the database. >> >> >>4.1.2. Device registration with trusted Database >> >> This use caseRegistration is >>preliminary to creating a radio network using TV >> white space; it is a prerequisite to >>otherthe use cases >>below. The radio >> network is created by a master device. Before the master device can >> transmit in TV white space spectrum, it must >>contact a trusted >> database where the device can learn if any channels are available for >> it to use. Before the database will provide information on available >> TVradio channels, the master >>device must register with the trusted >> database. Specific requirements for registration come from >> individual regulatory domains and may be different. >> >> The figure below shows an example deployment of this scenario. >> >> >> >> \|/ ---------- >> | |Database| >> | .---. /--------- >> |-|---------| ( ) / >> \|/ | Master | / \ >> | / | |=3D=3D=3D=3D=3D=3D=3D=3D( Inter= net ) >> | / |-----------| \ / >> +-|----+ (TDD AirIF) ( ) >> |Master| / (----) >> | | / >> +------+ >> >> Figure 2: Example illustration of registration requirement in >>TV >> white space use-case >> >> A simplified operational scenario showing registration consists of >> the following steps: >> >> 1. The master device must register with >>theits most current and up-to- >> date information. Typically the master device will register >> prior to operating in TV white space for the >>first time after >> power up, after changing location by a predetermined distance, >> and after regular time intervals. >> >> 2. The master device shall provide to the database during >> registration all information required according to local >>regulatory requirements. This information may include, but is not >>limited to, a minimum of the Device ID, >>serial number assigned by the manufacturer and the >>device's location, device antenna height above ground, name of >>the individual or business that owns the device, name of a contact >>person responsible for the device's operation, address for the >> contact person, email address for the contact person and phone >>number of the contact person. >> >> >> 3. Depending upon regulatory domain requirements, the device may >> also provide device antenna height above ground, name of the >> individual or business that owns the device, name of a contact >> person responsible for the device's operation, address for the >> contact person, email address for the contact person and phone >> number of the contact person to the database during registration. >> >> >>_______________________________________________ >>paws mailing list >>paws@ietf.org >>https://www.ietf.org/mailman/listinfo/paws > From scott.probasco@nokia.com Tue Feb 21 15:54:23 2012 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 310A021F86FF for ; Tue, 21 Feb 2012 15:54:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=-0.605, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFBwKNOlEDgY for ; Tue, 21 Feb 2012 15:54:20 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 23DC221F8703 for ; Tue, 21 Feb 2012 15:54:17 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1LNrt2K024201 for ; Wed, 22 Feb 2012 01:54:15 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Feb 2012 01:53:57 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.01.0355.003; Wed, 22 Feb 2012 00:53:57 +0100 From: To: Thread-Topic: UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90Q== Date: Tue, 21 Feb 2012 23:53:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="Windows-1252" Content-ID: <25956FC653801942880BCD9B39967CEC@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2012 23:53:57.0833 (UTC) FILETIME=[13983390:01CCF0F4] X-Nokia-AV: Clean Subject: [paws] UC&R I-D: Requirements 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, 21 Feb 2012 23:54:23 -0000 Hello All, I have revised Section 6 of the I-D which describes the Data Model Requirements, Protocol Requirements and Operational Requirements. This includes the requirements from the threat model (http://www.ietf.org/mail-archive/web/paws/current/msg00771.html). The requirements are ordered "top down" to follow the previous sections of the document: requirements derived from discovery are followed by requirements derived from registration are followed by requirements derived from hotspot, etc... Please review the proposed text, we hope to have your comments by Feb 28th. Kind Regards, Raj & Scott D. Data Model Requirements: =20 requirements related to discovery function D.1: The Data Model MUST support specifying the location of the WSD, the uncertainty in meters, the height & its uncertainty, and confidence in percentage for the location determination. The Data Model MUST support both North American Datum of 1983 and WGS84. =20 D.2: The Data Model MUST support specifying the URI address of a white space database. =20 D.3: The Data Model MUST support specifying the URI address of a national listing service. =20 D.4: The Data Model MUST support specifying regulatory domain and its corresponding data requirements. =20 =20 requirements related to registration function D.5: The Data Model MUST support specifying an ID of the transmitter device. This ID would contain the ID of the transmitter device that has been certified by a regulatory body for its regulatory domain. The Data Model MUST support a device class. =20 D.6: The Data Model MUST support specifying a manufacturer=B9s serial numbe= r for a master device. =20 D.7: The Data Model MUST support specifying the antenna and radiation related parameters of the device, such as: =20 - antenna height =20 - antenna gain =20 - maximum output power, EIRP (dBm) =20 - antenna radiation pattern (directional dependence of the strength of the radio signal from the antenna) =20 - spectrum mask with lowest and highest possible frequency =20 - spectrum mask in dBr from peak transmit power in EIRP, with specific power limit at any frequency linearly interpolated between adjacent points of the spectrum mask measurement resolution bandwidth for EIRP measurements. =20 =20 D.8: The Data Model MUST support specifying owner and operator contact information for a transmitter. This includes the name of the transmitter owner, name of transmitter operator, postal address, email address and phone number of the transmitter operator. =20 =20 requirements related to hotspot use case D.9: The Data Model MUST support specifying a list of available channels. The Data Model MUST support specification of this information by channel numbers and by start and stop frequencies. The Data Model MUST support a channel availability schedule and maximum power level for each channel in the list. =20 requirements related to mobility use case D.10: The Data Model MUST support specifying channel availability information for a single location and an area (e.g. a polygon defined by multiple location points or a geometric shape such as a circle). =20 =20 P. Protocol Requirements: =20 requirements related to discovery function P.1: The protocol MUST provide a message sequence for the master device to discover a white space database that provides service at its current location. =20 P.2: The protocol MUST support access of a database directly. The protocol MUST support access of a database using a listing approved by a national regulator. =20 P.3: The protocol MUST support determination of regulatory domain governing its current location. requirements related to threat model =20 P.4: The protocol MUST provide the ability for the database to authenticate the master device. =20 P.5: The protocol MUST provide the ability for the master device to verify the authenticity of the database with which it is interacting. =20 P.6: The messages sent by the master device to the database MUST be integrity protected. =20 P.7: The messages sent by the database to the master device MUST be integrity protected. =20 P.8: The protocol MUST provide the capability for messages sent by the master device and database to be encrypted. =20 =20 =20 requirements related to registration function P.9: The protocol MUST support the master device registering with the database. =20 P.10: The registration signaling MAY include the Device ID, manufacturer=B9= s serial number, device location, device antenna characteristic information, name of individual or business that owns the device, name, address, email address and phone number of a contact person who is responsible for device operation. =20 P.11: The protocol MUST support a registration acknowledgement including appropriate result codes. =20 =20 requirements related to hotspot use case P.12: The protocol MUST support a channel query request from the master device to the database. The channel query request message MUST include parameters as required by local regulatory requirement. These parameters MAY include device location, device ID, manufacturer=B9s serial number, and antenna characteristic information. =20 P.13: The protocol MUST support a channel query response from the database to the master device. The channel query response message MUST include parameters as required by local regulatory requirement. These parameters MAY include available channels, duration of time for their use, associated maximum power levels, any additional sensing requirements. =20 P.14: The protocol MUST support a channel query request from the slave device to the master device. The channel query request message MUST include parameters as required by local regulatory requirement. These parameters MAY include device ID and slave device location. =20 P.15: The protocol MUST support a validation request from the master to the database to validate a slave device. The validation request MUST include the slave device ID. =20 P.16: The protocol MUST support a validation response from the database to the master. The validation response MUST include a response code. =20 P.17: The protocol MUST support a channel query response from the master device to the slave device. The channel query response message MUST include parameters as required by local regulatory requirement, including a response code and sufficient information to decode an enabling signal. =20 P.18: The protocol MUST support an enabling signal sent from the master to the slave. This signal MUST allow the slave device to validate that a previously received available channel list is still valid or not. This signal MUST be encoded to allow the slave device to determine the identity if the sending master device. =20 =20 P.19: The protocol between the master device and the database MUST support the capability to change channel availability lists on short notice. =20 requirements related to mobility use case P.20: The protocol between the master device and the database MUST support a channel availability request which specifies a geographic location as an area as well as a point. =20 =20 O. Operational Requirements: =20 requirements related to discovery function O.1: The database and the master device MUST be connected to the Internet. =20 O.2: A master device MUST be able to determine its location including uncertainty and confidence level. A fixed master device MAY use a location programmed at installation or have the capability determine its location to the required accuracy. A mobile master device MUST have the capability to determine its location to the required accuracy. =20 O.3: The master device MUST identify a database for use. The master device MAY select a database for service by discovery at runtime or the master device MAY select a database for service by means of a pre-programmed URI address. =20 O.4: The master device MUST implement at least one connection method to access the database. The master device MAY contact a database directly for service (e.g. as defined by FCC) or the master device MAY contact a listing server first followed by contact to a database (e.g. As defined by Ofcom). =20 O.5: The master device MUST obtain an indication the regulatory domain governing operation at its current location, i.e. the master device MUST know if it operates under regulations from FCC, Ofcom, etc=8A =20 =20 requirements related to registration function O.6: The master device MAY register with the database according to local regulatory policy. Not all master devices will be required to register. Specific events will initiate registration, these events are determined by regulator policy (e.g. at power up, after movement, etc=8A). =20 O.7: The master device MUST register with its most current and up-to-date information. =20 =20 requirements related to hotspot use case O.8: A master device MUST query the database for the available channels based on its current location before starting radio transmission in white space. Parameters provided to the database MAY include device location, accuracy of the location, antenna characteristic information, device identifier of any slave device requesting channel information. =20 O.9: The database MUST respond to an available channel list request from an authenticated and authorized device and MAY also provide time constraints, maximum output power, start and stop frequencies for each channel in the list and any additional requirements for sensing. =20 O.10: After connecting to a master device=B9s radio network a slave device MUST query the master device for a list of available channels. The slave MUST include parameters required by local regulatory policy, e.g. device ID, device location. =20 O.11: According to local regulatory policy, the master device MAY query the database with parameters received from the slave device. =20 O.12: The database MUST respond to a query from the master device containing parameters from a slave device. =20 O.13: After the master device has received a response from the database, the master device MUST respond to the slave device. If all regulatory requirements are met the response will contain an available channel list. If regulatory requirements are not met, the response MUST contain at least a response code. =20 O.14: If a master device has provided an available channel list to a slave device the master device MAY send a periodic enabling signal to allow the slave device to confirm it is still within reception range of the master device. =20 O.15: The enabling signal MUST be encoded so that the receiving slave can determine the identity of the sending master. =20 O.16: Periodically, at an interval according to local regulations, the slave device MUST either receive and enabling signal or MUST successfully repeat the channel request process or MUST cease transmission on the channel. =20 O.17: A master device MUST repeat the query the database for the available channels as often as required by the regulation (eg, FCC requires once per day) to verify that the operating channels continue to remain available. =20 O.18: A master device which changes its location more than a threshold distance specified by local regulatory policy during its operation, MUST query the database for available operating channels each time it moves more than the threshold distance (e.g., FCC specifies 100m) from the location it previously made the query. =20 requirements related to wran use case O.19: If slave devices change their location during operation by more than a limit specified by the local regulator, the slave device MUST query the master device for available operating channels. =20 requirements related to rapid deployed network use case O.20: According to local regulator policy, a master device may contact a database via proxy service of another master device. =20 requirements related to mobility use case O.21: A master device MUST be able to query the whitespace database for channel availability information for a specific expected coverage area around its current location. =20 requirements related to threat model O.22: A Master device MAY not include its identity in messages sent to the database when not required by the regulatory =20 =20 From lei.zhu@huawei.com Tue Feb 21 22:42:10 2012 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 EF30621E807A for ; Tue, 21 Feb 2012 22:42:10 -0800 (PST) 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_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJYDEB2YAhP3 for ; Tue, 21 Feb 2012 22:42:09 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4D99321E8046 for ; Tue, 21 Feb 2012 22:42:08 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZS00DYG7W0XW@szxga05-in.huawei.com> for paws@ietf.org; Wed, 22 Feb 2012 14:40:48 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LZS00A1J7W007@szxga05-in.huawei.com> for paws@ietf.org; Wed, 22 Feb 2012 14:40:48 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHH54158; Wed, 22 Feb 2012 14:40:48 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 22 Feb 2012 14:40:46 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.8]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Wed, 22 Feb 2012 14:40:45 +0800 Date: Wed, 22 Feb 2012 06:40:43 +0000 From: ZhuLei In-reply-to: X-Originating-IP: [10.108.64.160] To: "scott.probasco@nokia.com" , "paws@ietf.org" Message-id: <470F27D1263A1B4EB73491ED995DE625147955A6@szxeml504-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: UC&R I-D: Requirements Thread-index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZISuoA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Subject: Re: [paws] UC&R I-D: Requirements 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, 22 Feb 2012 06:42:11 -0000 SSBoYWQgYSBjb21tZW50IG9uIGZyYW1ld29yayBvZiBpdCBhbmQgcHJvYmFibHkgZGlzY3VzcyBp dCBiZWZvcmUgdG91Y2hpbmcgdGltZWxpbmUuIA0KDQpJdCBpcyBhIGVhc3kgdG8gdGhpbmsgYWJv dXQgdGhlIGRpc3RyaWJ1dGVkIG9yIGhpZXJhcmNoaWNhbCBpbXBsZW1lbnRhdGlvbiBvZiBwYXdz IGZvciBzb21lIHJlYXNvbnMuIE9uZSBpcyB0aGF0IHRoZSBkYXRhYmFzZSBkb21pbmF0ZWQgYnkg YSByZWd1bGF0b3Igd2hpY2ggbWF5IGRpc3RyaWJ1dGUgcmVzcG9uc2liaWxpdGllcyBvZiBkaWZm ZXJlbnQgYXJlYXMgb3IgcmVnaW9ucyB0byBicmFuY2hlcyBvZiBoZXIuIFRoaXMgbmVlZCBhbGxv d3Mgc3Vic2V0IG9mIGRhdGFiYXNlIHdvcmtpbmcgYnkgbWFpbnRhaW5pbmcgYXZhaWxhYmxlIGNo YW5uZWwgbGlzdHMgZGF0YWJhc2UgaW4gcGFydGljdWxhciBhcmVhIG9yIGZvciBzb21lIHB1cnBv c2VzLiANCg0KQXMgZGlzY3Vzc2VkIGluIHRoaXMgbWFpbCBsaXN0LCBkYXRhYmFzZSBpcyBpbiBj aGFyZ2Ugb2Ygc3RvcmluZyBhbmQgbWFpbnRhaW5pbmcgd2hpdGUgc3BhY2UgY2hhbm5lbCBpbmZv cm1hdGlvbiBmb3IgYSBsYXJnZSBhcmVhIChlLmcuIGEgY291bnRyeSkgYW5kIGl0IG1heSBiZSBv cGVyYXRlZCBieSByZWd1bGF0b3J5IGJvZHksIGluIHRoZSBjdXJyZW50IHN5c3RlbSBhcmNoaXRl Y3R1cmUgYWxsIHRoZSBtYXN0ZXIgZGV2aWNlcyBxdWVyeSB3aGl0ZSBzcGFjZSBkaXJlY3RseSBm cm9tIGRhdGFiYXNlLCBidXQgaW4gaWYgYW4gZW50aXR5IGlzIGFkZGVkIGJldHdlZW4gbWFzdGVy IGRldmljZSBhbmQgZGF0YWJhc2UsIGFuZCB0aGlzIGVudGl0eSBpcyBpbiBjaGFyZ2Ugb2YgYWxs b2NhdGluZyB3aGl0ZSBzcGFjZSBmb3IgbWFzdGVyIGRldmljZXMsIHRoZSBhcHBsaWNhdGlvbiBv ZiB3aGl0ZSBzcGFjZSB3aWxsIGJlIG1vcmUgZmxleGlibGUuIEZvciBleGFtcGxlLCBhIHdoaXRl IHNwYWNlIHVzZXIgb3ducyBhIGxvdCBvZiBtYXN0ZXIgZGV2aWNlcyBhbmQgaXQgd2FudHMgdG8g ZXN0YWJsaXNoIHdpcmVsZXNzIG5ldHdvcmsgdXNpbmcgdGhlc2UgbWFzdGVyIGRldmljZSwgaXQg Y2FuIHNldCBhIGNvb3JkaW5hdGluZyBkYXRhYmFzZSB3aGljaCBnZXRzIHdoaXRlIHNwYWNlIGlu IGl0cyBhcmVhIGZyb20gZGF0YWJhc2UgYW5kIGFsbCBvZiBpdHMgbWFzdGVyIGRldmljZXMgcXVl cnkgd2hpdGUgc3BhY2UgZnJvbSB0aGUgY29vcmRpbmF0aW5nIGRhdGFiYXNlLCBiZWNhdXNlIHRo ZSBtYXN0ZXIgZGV2aWNlcyBkb27igJl0IHF1ZXJ5IHdoaXRlIHNwYWNlIGZyb20gZGF0YWJhc2Ug c28gdGhlIGJ1cmRlbiBvZiBkYXRhYmFzZSB3aWxsIGJlIHJlZHVjZWQsIGFuZCBiZWNhdXNlIHRo ZSB3aGl0ZSBzcGFjZSB1c2VyIG93bnMgdGhlIGNvb3JkaW5hdGluZyBkYXRhYmFzZSBzbyBpdCBj YW4gaW1wbGVtZW50IGl0cyBwb2xpY3kgb2YgdXNpbmcgc3BlY3RydW0uDQoNCk1hc3RlciBkZXZp Y2UgY2FuIGdldCB3aGl0ZSBzcGFjZSBmcm9tIHRoZSBjb29yZGluYXRpbmcgZGF0YWJhc2UganVz dCBsaWtlIGdldHRpbmcgd2hpdGUgc3BhY2UgZnJvbSBkYXRhYmFzZTsgdGhlIGNvb3JkaW5hdGlu ZyBkYXRhYmFzZSBjYW4gYmUgbWFpbnRhaW5lZCBhbmQgb3BlcmF0ZWQgYnkgcmVndWxhdG9yeSBi b2R5IChlLmcuIEZDQykuDQoNClNvLCBoZXJlLCBhbiBvcHRpb25hbCBzeXN0ZW0gZnJhbWV3b3Jr IGlzIHByb3Bvc2VkLCBjb21wYXJlZCB3aXRoIHRoZSBjb21tb25seSBkaXNjdXNzZWQgb25lIGEg bmFtZWQgY29vcmRpbmF0aW5nIGRhdGFiYXNlIGlzIGFkZGVkLg0KICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLSsNCiAgICArLS0tLS0tLS0tLS0tLSsgICAgICAgfENvb3Jk aW5hdGluICB8ICAgICAgICArLS0tLS0tLS0tLS0rDQogICAgfE1hc3RlciBEZXZpY2UrLS0rLS0t LStEYXRhYmFzZSAgICAgKy0tLS0rLS0tK0RhdGFiYXNlICAgfA0KICAgICstLS0tLS0tLS0tLS0t KyBXUyAgICArLS0tLS0tLS0tLS0tLSsgICBXUyAgICstLS0tLS0tLS0tLSsNCg0KRmlndXJlIDEg QW4gYWRkaXRpb25hbCBhcmNoaXRlY3R1cmUgb2Ygd2hpdGUgc3BhY2UgZGF0YWJhc2UgcXVlcnlp bmcgc3lzdGVtDQoNCiAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN CiAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICstLS0tLS0tKyAgIHwNCiAgICAgICAgICAg ICB8ICstLS0tLS0tLSsgICAgIHxNYXN0ZXIgfCAgIHwNCiAgICAgICAgICAgICB8IHxEYXRhYmFz ZXwgICAgIHxEZXZpY2VzfCAgIHwNCiAgICAgICAgICAgICB8ICstLS0tLS0tLSsgICAgICstLS0t LS0tKyAgIHwNCiAgICAgICAgICAgICB8Q29vcmRpbmF0aW5nIERhdGFiYXNlICAgICAgIHwNCiAg ICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCkZpZ3VyZSAyIExvZ2lj YWwgRnVuY3Rpb24gb2YgQ29vcmRpbmF0aW5nIERhdGFiYXNlDQoNCkJlc3QgcmVnYXJkcywNClpo dSBMZWkNCkhVQVdFSSBURUNITk9MT0dJRVMgQ08uLExURC4gDQoNCkFkZHJlc3M6IEh1YXdlaSBC dWlsZGluZywgTm8zIFhpbnhpIFJvYWQNClNoYW5nRGkgSW5mb3JtYXRpb24gSW5kdXJzdHJ5IEJh c2UsIEhhaWRpYW4gRGlzdHJpY3QNCkJlaWppbmcgMTAwMDg1LCBDaGluYQ0KVGVsOiArODYtMTAt ODI4MzYzMDENCkZheDogKzg2LTEwLTgyODM2OTIwDQpNb2JpbGU6ICs4Ni0xMzkxMDE1NzAyMA0K RS1tYWlsOiBsZWkuemh1QGh1YXdlaS5jb20NCnd3dy5odWF3ZWkuY29tDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50 aWFsIGluZm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCANCmlzIGludGVuZGVkIG9ubHkgZm9y IHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkg dXNlIG9mIHRoZSANCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5j bHVkaW5nLCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgDQpkaXNjbG9zdXJl LCByZXByb2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0 aGUgaW50ZW5kZWQgDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUg dGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSANCnBob25l IG9yIGVtYWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCg0KLS0tLS3pgq7ku7bljp/k u7YtLS0tLQ0K5Y+R5Lu25Lq6OiBwYXdzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwYXdzLWJv dW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBzY290dC5wcm9iYXNjb0Bub2tpYS5jb20NCuWPkemAgeaX tumXtDogMjAxMuW5tDLmnIgyMuaXpSA3OjU0DQrmlLbku7bkuro6IHBhd3NAaWV0Zi5vcmcNCuS4 u+mimDogW3Bhd3NdIFVDJlIgSS1EOiBSZXF1aXJlbWVudHMNCg0KSGVsbG8gQWxsLA0KDQpJIGhh dmUgcmV2aXNlZCBTZWN0aW9uIDYgb2YgdGhlIEktRCB3aGljaCBkZXNjcmliZXMgdGhlIERhdGEg TW9kZWwNClJlcXVpcmVtZW50cywgUHJvdG9jb2wgUmVxdWlyZW1lbnRzIGFuZCBPcGVyYXRpb25h bCBSZXF1aXJlbWVudHMuIFRoaXMNCmluY2x1ZGVzIHRoZSByZXF1aXJlbWVudHMgZnJvbSB0aGUg dGhyZWF0IG1vZGVsDQooaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3Bhd3Mv Y3VycmVudC9tc2cwMDc3MS5odG1sKS4NCg0KVGhlIHJlcXVpcmVtZW50cyBhcmUgb3JkZXJlZCAi dG9wIGRvd24iIHRvIGZvbGxvdyB0aGUgcHJldmlvdXMgc2VjdGlvbnMgb2YNCnRoZSBkb2N1bWVu dDogcmVxdWlyZW1lbnRzIGRlcml2ZWQgZnJvbSBkaXNjb3ZlcnkgYXJlIGZvbGxvd2VkIGJ5DQpy ZXF1aXJlbWVudHMgZGVyaXZlZCBmcm9tIHJlZ2lzdHJhdGlvbiBhcmUgZm9sbG93ZWQgYnkgcmVx dWlyZW1lbnRzDQpkZXJpdmVkIGZyb20gaG90c3BvdCwgZXRjLi4uDQoNClBsZWFzZSByZXZpZXcg dGhlIHByb3Bvc2VkIHRleHQsIHdlIGhvcGUgdG8gaGF2ZSB5b3VyIGNvbW1lbnRzIGJ5IEZlYiAy OHRoLg0KDQpLaW5kIFJlZ2FyZHMsDQoNClJhaiAmIFNjb3R0DQoNCg0KDQoNCkQuIERhdGEgTW9k ZWwgUmVxdWlyZW1lbnRzOg0KIA0KDQo8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8g ZGlzY292ZXJ5IGZ1bmN0aW9uPC9FZC4gTm90ZT4NCkQuMTogVGhlIERhdGEgTW9kZWwgTVVTVCBz dXBwb3J0IHNwZWNpZnlpbmcgdGhlIGxvY2F0aW9uIG9mIHRoZSBXU0QsIHRoZQ0KdW5jZXJ0YWlu dHkgaW4gbWV0ZXJzLCB0aGUgaGVpZ2h0ICYgaXRzIHVuY2VydGFpbnR5LCBhbmQgY29uZmlkZW5j ZSBpbg0KcGVyY2VudGFnZSBmb3IgdGhlIGxvY2F0aW9uIGRldGVybWluYXRpb24uIFRoZSBEYXRh IE1vZGVsIE1VU1Qgc3VwcG9ydA0KYm90aCBOb3J0aCBBbWVyaWNhbiBEYXR1bSBvZiAxOTgzIGFu ZCBXR1M4NC4NCg0KIA0KRC4yOiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWlu ZyB0aGUgVVJJIGFkZHJlc3Mgb2YgYSB3aGl0ZQ0Kc3BhY2UgZGF0YWJhc2UuDQoNCiANCkQuMzog VGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgdGhlIFVSSSBhZGRyZXNzIG9m IGEgbmF0aW9uYWwNCmxpc3Rpbmcgc2VydmljZS4NCg0KIA0KRC40OiBUaGUgRGF0YSBNb2RlbCBN VVNUIHN1cHBvcnQgc3BlY2lmeWluZyAgcmVndWxhdG9yeSBkb21haW4gYW5kIGl0cw0KY29ycmVz cG9uZGluZyBkYXRhIHJlcXVpcmVtZW50cy4NCiANCiANCg0KPEVkLiBOb3RlPnJlcXVpcmVtZW50 cyByZWxhdGVkIHRvIHJlZ2lzdHJhdGlvbiBmdW5jdGlvbjwvRWQuIE5vdGU+DQpELjU6IFRoZSBE YXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIGFuIElEIG9mIHRoZSB0cmFuc21pdHRl cg0KZGV2aWNlLiBUaGlzIElEIHdvdWxkIGNvbnRhaW4gdGhlIElEIG9mIHRoZSB0cmFuc21pdHRl ciBkZXZpY2UgdGhhdCBoYXMNCmJlZW4gY2VydGlmaWVkIGJ5IGEgcmVndWxhdG9yeSBib2R5IGZv ciBpdHMgcmVndWxhdG9yeSBkb21haW4uIFRoZSBEYXRhDQpNb2RlbCBNVVNUIHN1cHBvcnQgYSBk ZXZpY2UgY2xhc3MuDQoNCg0KIA0KRC42OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3Bl Y2lmeWluZyBhIG1hbnVmYWN0dXJlcsK5cyBzZXJpYWwgbnVtYmVyDQpmb3IgYSBtYXN0ZXIgZGV2 aWNlLg0KDQogDQpELjc6ICBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyB0 aGUgYW50ZW5uYSBhbmQgcmFkaWF0aW9uDQpyZWxhdGVkIHBhcmFtZXRlcnMgb2YgdGhlIGRldmlj ZSwgc3VjaCBhczoNCiANCiAgIC0gYW50ZW5uYSBoZWlnaHQNCiANCiAgIC0gYW50ZW5uYSBnYWlu DQogDQogICAtIG1heGltdW0gb3V0cHV0IHBvd2VyLCBFSVJQIChkQm0pDQogDQogICAtIGFudGVu bmEgcmFkaWF0aW9uIHBhdHRlcm4gKGRpcmVjdGlvbmFsIGRlcGVuZGVuY2UNCiAgICAgb2YgdGhl IHN0cmVuZ3RoIG9mIHRoZSByYWRpbyBzaWduYWwgZnJvbSB0aGUgYW50ZW5uYSkNCiANCiAgIC0g c3BlY3RydW0gbWFzayB3aXRoIGxvd2VzdCBhbmQgaGlnaGVzdCBwb3NzaWJsZSBmcmVxdWVuY3kN CiANCiAgIC0gc3BlY3RydW0gbWFzayBpbiBkQnIgZnJvbSBwZWFrIHRyYW5zbWl0IHBvd2VyIGlu IEVJUlAsDQogICAgIHdpdGggc3BlY2lmaWMgcG93ZXIgbGltaXQgYXQgYW55IGZyZXF1ZW5jeSBs aW5lYXJseQ0KICAgICBpbnRlcnBvbGF0ZWQgYmV0d2VlbiBhZGphY2VudCBwb2ludHMgb2YgdGhl IHNwZWN0cnVtIG1hc2sNCiAgICAgbWVhc3VyZW1lbnQgcmVzb2x1dGlvbiBiYW5kd2lkdGggZm9y IEVJUlAgbWVhc3VyZW1lbnRzLg0KDQogDQogDQpELjg6IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3Vw cG9ydCBzcGVjaWZ5aW5nIG93bmVyIGFuZCBvcGVyYXRvciBjb250YWN0DQppbmZvcm1hdGlvbiBm b3IgYSB0cmFuc21pdHRlci4gVGhpcyBpbmNsdWRlcyB0aGUgbmFtZSBvZiB0aGUgdHJhbnNtaXR0 ZXINCm93bmVyLCBuYW1lIG9mIHRyYW5zbWl0dGVyIG9wZXJhdG9yLCBwb3N0YWwgYWRkcmVzcywg ZW1haWwgYWRkcmVzcyBhbmQNCnBob25lIG51bWJlciBvZiB0aGUgdHJhbnNtaXR0ZXIgb3BlcmF0 b3IuDQoNCg0KIA0KIA0KPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGhvdHNwb3Qg dXNlIGNhc2U8L0VkLiBOb3RlPg0KRC45OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3Bl Y2lmeWluZyBhIGxpc3Qgb2YgYXZhaWxhYmxlIGNoYW5uZWxzLg0KVGhlIERhdGEgTW9kZWwgTVVT VCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBjaGFubmVsDQpu dW1iZXJzIGFuZCBieSBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcy4gVGhlIERhdGEgTW9kZWwg TVVTVCBzdXBwb3J0IGENCmNoYW5uZWwgYXZhaWxhYmlsaXR5IHNjaGVkdWxlIGFuZCBtYXhpbXVt IHBvd2VyIGxldmVsIGZvciBlYWNoIGNoYW5uZWwgaW4NCnRoZSBsaXN0Lg0KDQoNCiANCjxFZC4g Tm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBtb2JpbGl0eSB1c2UgY2FzZTwvRWQuIE5vdGU+ DQpELjEwOiAgVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgY2hhbm5lbCBh dmFpbGFiaWxpdHkNCmluZm9ybWF0aW9uIGZvciBhIHNpbmdsZSBsb2NhdGlvbiBhbmQgYW4gYXJl YSAoZS5nLiBhIHBvbHlnb24gZGVmaW5lZCBieQ0KbXVsdGlwbGUgbG9jYXRpb24gcG9pbnRzIG9y IGEgZ2VvbWV0cmljIHNoYXBlIHN1Y2ggYXMgYSBjaXJjbGUpLg0KDQoNCg0KIA0KIA0KUC4gUHJv dG9jb2wgUmVxdWlyZW1lbnRzOg0KDQogDQo8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQg dG8gZGlzY292ZXJ5IGZ1bmN0aW9uPC9FZC4gTm90ZT4NClAuMTogVGhlIHByb3RvY29sIE1VU1Qg cHJvdmlkZSBhIG1lc3NhZ2Ugc2VxdWVuY2UgZm9yIHRoZSBtYXN0ZXIgZGV2aWNlIHRvDQpkaXNj b3ZlciBhIHdoaXRlIHNwYWNlIGRhdGFiYXNlIHRoYXQgcHJvdmlkZXMgc2VydmljZSBhdCBpdHMg Y3VycmVudA0KbG9jYXRpb24uDQoNCiANClAuMjogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBh Y2Nlc3Mgb2YgYSBkYXRhYmFzZSBkaXJlY3RseS4gVGhlIHByb3RvY29sDQpNVVNUIHN1cHBvcnQg YWNjZXNzIG9mIGEgZGF0YWJhc2UgdXNpbmcgYSBsaXN0aW5nIGFwcHJvdmVkIGJ5IGEgbmF0aW9u YWwNCnJlZ3VsYXRvci4NCg0KIA0KUC4zOiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGRldGVy bWluYXRpb24gb2YgcmVndWxhdG9yeSBkb21haW4NCmdvdmVybmluZyBpdHMgY3VycmVudCBsb2Nh dGlvbi4NCg0KDQo8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gdGhyZWF0IG1vZGVs PC9FZC4gTm90ZT4NCg0KIA0KUC40OiBUaGUgcHJvdG9jb2wgTVVTVCBwcm92aWRlIHRoZSBhYmls aXR5IGZvciB0aGUgZGF0YWJhc2UgdG8NCmF1dGhlbnRpY2F0ZSB0aGUgbWFzdGVyIGRldmljZS4N Cg0KIA0KUC41OiBUaGUgcHJvdG9jb2wgTVVTVCBwcm92aWRlIHRoZSBhYmlsaXR5IGZvciB0aGUg bWFzdGVyIGRldmljZSB0byB2ZXJpZnkNCnRoZSBhdXRoZW50aWNpdHkgb2YgdGhlIGRhdGFiYXNl IHdpdGggd2hpY2ggaXQgaXMgaW50ZXJhY3RpbmcuDQoNCiANClAuNjogVGhlIG1lc3NhZ2VzIHNl bnQgYnkgdGhlIG1hc3RlciBkZXZpY2UgdG8gdGhlIGRhdGFiYXNlIE1VU1QgYmUNCmludGVncml0 eSBwcm90ZWN0ZWQuDQoNCiANClAuNzogVGhlIG1lc3NhZ2VzIHNlbnQgYnkgdGhlIGRhdGFiYXNl IHRvIHRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgYmUNCmludGVncml0eSBwcm90ZWN0ZWQuDQoNCiAN ClAuODogVGhlIHByb3RvY29sIE1VU1QgcHJvdmlkZSB0aGUgY2FwYWJpbGl0eSBmb3IgbWVzc2Fn ZXMgc2VudCBieSB0aGUNCm1hc3RlciBkZXZpY2UgYW5kIGRhdGFiYXNlIHRvIGJlIGVuY3J5cHRl ZC4NCg0KDQoNCiANCiANCiANCjxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byByZWdp c3RyYXRpb24gZnVuY3Rpb248L0VkLiBOb3RlPg0KUC45OiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBw b3J0IHRoZSBtYXN0ZXIgZGV2aWNlIHJlZ2lzdGVyaW5nIHdpdGggdGhlDQpkYXRhYmFzZS4NCg0K IA0KUC4xMDogVGhlIHJlZ2lzdHJhdGlvbiBzaWduYWxpbmcgTUFZIGluY2x1ZGUgdGhlIERldmlj ZSBJRCwgbWFudWZhY3R1cmVywrlzDQpzZXJpYWwgbnVtYmVyLCBkZXZpY2UgbG9jYXRpb24sIGRl dmljZSBhbnRlbm5hIGNoYXJhY3RlcmlzdGljIGluZm9ybWF0aW9uLA0KbmFtZSBvZiBpbmRpdmlk dWFsIG9yIGJ1c2luZXNzIHRoYXQgb3ducyB0aGUgZGV2aWNlLCBuYW1lLCBhZGRyZXNzLCBlbWFp bA0KYWRkcmVzcyBhbmQgcGhvbmUgbnVtYmVyIG9mIGEgY29udGFjdCBwZXJzb24gd2hvIGlzIHJl c3BvbnNpYmxlIGZvciBkZXZpY2UNCm9wZXJhdGlvbi4NCg0KIA0KUC4xMTogVGhlIHByb3RvY29s IE1VU1Qgc3VwcG9ydCBhIHJlZ2lzdHJhdGlvbiBhY2tub3dsZWRnZW1lbnQgaW5jbHVkaW5nDQph cHByb3ByaWF0ZSByZXN1bHQgY29kZXMuDQoNCg0KIA0KIA0KPEVkLiBOb3RlPnJlcXVpcmVtZW50 cyByZWxhdGVkIHRvIGhvdHNwb3QgdXNlIGNhc2U8L0VkLiBOb3RlPg0KUC4xMjogVGhlIHByb3Rv Y29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgcXVlcnkgcmVxdWVzdCBmcm9tIHRoZSBtYXN0ZXIN CmRldmljZSB0byB0aGUgZGF0YWJhc2UuIFRoZSBjaGFubmVsIHF1ZXJ5IHJlcXVlc3QgbWVzc2Fn ZSBNVVNUIGluY2x1ZGUNCnBhcmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9y eSByZXF1aXJlbWVudC4gVGhlc2UgcGFyYW1ldGVycw0KTUFZIGluY2x1ZGUgZGV2aWNlIGxvY2F0 aW9uLCBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcsK5cyBzZXJpYWwgbnVtYmVyLCBhbmQNCmFudGVu bmEgY2hhcmFjdGVyaXN0aWMgaW5mb3JtYXRpb24uDQoNCiANClAuMTM6IFRoZSBwcm90b2NvbCBN VVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlc3BvbnNlIGZyb20gdGhlIGRhdGFiYXNlDQp0 byB0aGUgbWFzdGVyIGRldmljZS4gVGhlIGNoYW5uZWwgcXVlcnkgcmVzcG9uc2UgbWVzc2FnZSBN VVNUIGluY2x1ZGUNCnBhcmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSBy ZXF1aXJlbWVudC4gVGhlc2UgcGFyYW1ldGVycw0KTUFZIGluY2x1ZGUgYXZhaWxhYmxlIGNoYW5u ZWxzLCBkdXJhdGlvbiBvZiB0aW1lIGZvciB0aGVpciB1c2UsIGFzc29jaWF0ZWQNCm1heGltdW0g cG93ZXIgbGV2ZWxzLCBhbnkgYWRkaXRpb25hbCBzZW5zaW5nIHJlcXVpcmVtZW50cy4NCiANCg0K UC4xNDogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgcXVlcnkgcmVxdWVzdCBm cm9tIHRoZSBzbGF2ZQ0KZGV2aWNlIHRvIHRoZSBtYXN0ZXIgZGV2aWNlLiBUaGUgY2hhbm5lbCBx dWVyeSByZXF1ZXN0IG1lc3NhZ2UgTVVTVA0KaW5jbHVkZSBwYXJhbWV0ZXJzIGFzIHJlcXVpcmVk IGJ5IGxvY2FsIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnQuIFRoZXNlDQpwYXJhbWV0ZXJzIE1BWSBp bmNsdWRlIGRldmljZSBJRCBhbmQgc2xhdmUgZGV2aWNlIGxvY2F0aW9uLg0KIA0KDQpQLjE1OiBU aGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgdmFsaWRhdGlvbiByZXF1ZXN0IGZyb20gdGhlIG1h c3RlciB0bw0KdGhlIGRhdGFiYXNlIHRvIHZhbGlkYXRlIGEgc2xhdmUgZGV2aWNlLiBUaGUgdmFs aWRhdGlvbiByZXF1ZXN0IE1VU1QNCmluY2x1ZGUgdGhlIHNsYXZlIGRldmljZSBJRC4NCg0KIA0K UC4xNjogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIHZhbGlkYXRpb24gcmVzcG9uc2UgZnJv bSB0aGUgZGF0YWJhc2UgdG8NCnRoZSBtYXN0ZXIuIFRoZSB2YWxpZGF0aW9uIHJlc3BvbnNlIE1V U1QgaW5jbHVkZSBhIHJlc3BvbnNlIGNvZGUuDQoNCiANClAuMTc6IFRoZSBwcm90b2NvbCBNVVNU IHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlc3BvbnNlIGZyb20gdGhlIG1hc3Rlcg0KZGV2aWNl IHRvIHRoZSBzbGF2ZSBkZXZpY2UuIFRoZSBjaGFubmVsIHF1ZXJ5IHJlc3BvbnNlIG1lc3NhZ2Ug TVVTVA0KaW5jbHVkZSBwYXJhbWV0ZXJzIGFzIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkg cmVxdWlyZW1lbnQsIGluY2x1ZGluZw0KYSByZXNwb25zZSBjb2RlIGFuZCBzdWZmaWNpZW50IGlu Zm9ybWF0aW9uIHRvIGRlY29kZSBhbiBlbmFibGluZyBzaWduYWwuDQogDQoNClAuMTg6IFRoZSBw cm90b2NvbCBNVVNUIHN1cHBvcnQgYW4gZW5hYmxpbmcgc2lnbmFsIHNlbnQgZnJvbSB0aGUgbWFz dGVyIHRvDQp0aGUgc2xhdmUuIFRoaXMgc2lnbmFsIE1VU1QgYWxsb3cgdGhlIHNsYXZlIGRldmlj ZSB0byB2YWxpZGF0ZSB0aGF0IGENCnByZXZpb3VzbHkgcmVjZWl2ZWQgYXZhaWxhYmxlIGNoYW5u ZWwgbGlzdCBpcyBzdGlsbCB2YWxpZCBvciBub3QuIFRoaXMNCnNpZ25hbCBNVVNUIGJlIGVuY29k ZWQgdG8gYWxsb3cgdGhlIHNsYXZlIGRldmljZSB0byBkZXRlcm1pbmUgdGhlIGlkZW50aXR5DQpp ZiB0aGUgc2VuZGluZyBtYXN0ZXIgZGV2aWNlLg0KIA0KIA0KDQpQLjE5OiBUaGUgcHJvdG9jb2wg YmV0d2VlbiB0aGUgbWFzdGVyIGRldmljZSBhbmQgdGhlIGRhdGFiYXNlIE1VU1Qgc3VwcG9ydA0K dGhlIGNhcGFiaWxpdHkgdG8gY2hhbmdlIGNoYW5uZWwgYXZhaWxhYmlsaXR5IGxpc3RzIG9uIHNo b3J0IG5vdGljZS4NCg0KDQogDQo8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gbW9i aWxpdHkgdXNlIGNhc2U8L0VkLiBOb3RlPg0KUC4yMDogVGhlIHByb3RvY29sIGJldHdlZW4gdGhl IG1hc3RlciBkZXZpY2UgYW5kIHRoZSBkYXRhYmFzZSBNVVNUIHN1cHBvcnQNCmEgY2hhbm5lbCBh dmFpbGFiaWxpdHkgcmVxdWVzdCB3aGljaCBzcGVjaWZpZXMgYSBnZW9ncmFwaGljIGxvY2F0aW9u IGFzIGFuDQphcmVhIGFzIHdlbGwgYXMgYSBwb2ludC4NCg0KDQoNCiANCiANCk8uIE9wZXJhdGlv bmFsIFJlcXVpcmVtZW50czoNCiANCg0KPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRv IGRpc2NvdmVyeSBmdW5jdGlvbjwvRWQuIE5vdGU+DQoNCk8uMTogVGhlIGRhdGFiYXNlIGFuZCB0 aGUgbWFzdGVyIGRldmljZSBNVVNUIGJlIGNvbm5lY3RlZCB0byB0aGUgSW50ZXJuZXQuDQogDQoN Ck8uMjogIEEgbWFzdGVyIGRldmljZSBNVVNUIGJlIGFibGUgdG8gZGV0ZXJtaW5lIGl0cyBsb2Nh dGlvbiBpbmNsdWRpbmcNCnVuY2VydGFpbnR5IGFuZCBjb25maWRlbmNlIGxldmVsLiBBIGZpeGVk IG1hc3RlciBkZXZpY2UgTUFZIHVzZSBhIGxvY2F0aW9uDQpwcm9ncmFtbWVkIGF0IGluc3RhbGxh dGlvbiBvciBoYXZlIHRoZSBjYXBhYmlsaXR5IGRldGVybWluZSBpdHMgbG9jYXRpb24NCnRvIHRo ZSByZXF1aXJlZCBhY2N1cmFjeS4gQSBtb2JpbGUgbWFzdGVyIGRldmljZSBNVVNUIGhhdmUgdGhl IGNhcGFiaWxpdHkNCnRvIGRldGVybWluZSBpdHMgbG9jYXRpb24gdG8gdGhlIHJlcXVpcmVkIGFj Y3VyYWN5Lg0KDQogDQpPLjM6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgaWRlbnRpZnkgYSBkYXRh YmFzZSBmb3IgdXNlLiBUaGUgbWFzdGVyIGRldmljZQ0KTUFZIHNlbGVjdCBhIGRhdGFiYXNlIGZv ciBzZXJ2aWNlIGJ5IGRpc2NvdmVyeSBhdCBydW50aW1lIG9yIHRoZSBtYXN0ZXINCmRldmljZSBN QVkgc2VsZWN0IGEgZGF0YWJhc2UgZm9yIHNlcnZpY2UgYnkgbWVhbnMgb2YgYSBwcmUtcHJvZ3Jh bW1lZCBVUkkNCmFkZHJlc3MuDQoNCiANCk8uNDogVGhlIG1hc3RlciBkZXZpY2UgTVVTVCBpbXBs ZW1lbnQgYXQgbGVhc3Qgb25lIGNvbm5lY3Rpb24gbWV0aG9kIHRvDQphY2Nlc3MgdGhlIGRhdGFi YXNlLiBUaGUgbWFzdGVyIGRldmljZSBNQVkgY29udGFjdCBhIGRhdGFiYXNlIGRpcmVjdGx5IGZv cg0Kc2VydmljZSAoZS5nLiBhcyBkZWZpbmVkIGJ5IEZDQykgb3IgdGhlIG1hc3RlciBkZXZpY2Ug TUFZIGNvbnRhY3QgYQ0KbGlzdGluZyBzZXJ2ZXIgZmlyc3QgZm9sbG93ZWQgYnkgY29udGFjdCB0 byBhIGRhdGFiYXNlIChlLmcuIEFzIGRlZmluZWQgYnkNCk9mY29tKS4NCiANCg0KTy41OiBUaGUg bWFzdGVyIGRldmljZSBNVVNUIG9idGFpbiBhbiBpbmRpY2F0aW9uIHRoZSByZWd1bGF0b3J5IGRv bWFpbg0KZ292ZXJuaW5nIG9wZXJhdGlvbiBhdCBpdHMgY3VycmVudCBsb2NhdGlvbiwgaS5lLiB0 aGUgbWFzdGVyIGRldmljZSBNVVNUDQprbm93IGlmIGl0IG9wZXJhdGVzIHVuZGVyIHJlZ3VsYXRp b25zIGZyb20gRkNDLCBPZmNvbSwgZXRjxaANCiANCiANCg0KDQo8RWQuIE5vdGU+cmVxdWlyZW1l bnRzIHJlbGF0ZWQgdG8gcmVnaXN0cmF0aW9uIGZ1bmN0aW9uPC9FZC4gTm90ZT4NCk8uNjogVGhl IG1hc3RlciBkZXZpY2UgTUFZIHJlZ2lzdGVyIHdpdGggdGhlIGRhdGFiYXNlIGFjY29yZGluZyB0 byBsb2NhbA0KcmVndWxhdG9yeSBwb2xpY3kuIE5vdCBhbGwgbWFzdGVyIGRldmljZXMgd2lsbCBi ZSByZXF1aXJlZCB0byByZWdpc3Rlci4NClNwZWNpZmljIGV2ZW50cyB3aWxsIGluaXRpYXRlIHJl Z2lzdHJhdGlvbiwgdGhlc2UgZXZlbnRzIGFyZSBkZXRlcm1pbmVkIGJ5DQpyZWd1bGF0b3IgcG9s aWN5IChlLmcuIGF0IHBvd2VyIHVwLCBhZnRlciBtb3ZlbWVudCwgZXRjxaApLg0KIA0KDQpPLjc6 IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgcmVnaXN0ZXIgd2l0aCBpdHMgbW9zdCBjdXJyZW50IGFu ZCB1cC10by1kYXRlDQppbmZvcm1hdGlvbi4NCg0KIA0KIA0KDQo8RWQuIE5vdGU+cmVxdWlyZW1l bnRzIHJlbGF0ZWQgdG8gaG90c3BvdCB1c2UgY2FzZTwvRWQuIE5vdGU+DQpPLjg6IEEgbWFzdGVy IGRldmljZSBNVVNUIHF1ZXJ5IHRoZSBkYXRhYmFzZSBmb3IgdGhlIGF2YWlsYWJsZSBjaGFubmVs cw0KYmFzZWQgb24gaXRzIGN1cnJlbnQgbG9jYXRpb24gYmVmb3JlIHN0YXJ0aW5nIHJhZGlvIHRy YW5zbWlzc2lvbiBpbiB3aGl0ZQ0Kc3BhY2UuIFBhcmFtZXRlcnMgcHJvdmlkZWQgdG8gdGhlIGRh dGFiYXNlIE1BWSBpbmNsdWRlIGRldmljZSBsb2NhdGlvbiwNCmFjY3VyYWN5IG9mIHRoZSBsb2Nh dGlvbiwgYW50ZW5uYSBjaGFyYWN0ZXJpc3RpYyBpbmZvcm1hdGlvbiwgZGV2aWNlDQppZGVudGlm aWVyIG9mIGFueSBzbGF2ZSBkZXZpY2UgcmVxdWVzdGluZyBjaGFubmVsIGluZm9ybWF0aW9uLg0K IA0KDQpPLjk6IFRoZSBkYXRhYmFzZSBNVVNUIHJlc3BvbmQgdG8gYW4gYXZhaWxhYmxlIGNoYW5u ZWwgbGlzdCByZXF1ZXN0IGZyb20NCmFuIGF1dGhlbnRpY2F0ZWQgYW5kIGF1dGhvcml6ZWQgZGV2 aWNlIGFuZCBNQVkgYWxzbyBwcm92aWRlIHRpbWUNCmNvbnN0cmFpbnRzLCBtYXhpbXVtIG91dHB1 dCBwb3dlciwgc3RhcnQgYW5kIHN0b3AgZnJlcXVlbmNpZXMgZm9yIGVhY2gNCmNoYW5uZWwgaW4g dGhlIGxpc3QgYW5kIGFueSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBmb3Igc2Vuc2luZy4NCiAN Cg0KTy4xMDogQWZ0ZXIgY29ubmVjdGluZyB0byBhIG1hc3RlciBkZXZpY2XCuXMgcmFkaW8gbmV0 d29yayBhIHNsYXZlIGRldmljZQ0KTVVTVCBxdWVyeSB0aGUgbWFzdGVyIGRldmljZSBmb3IgYSBs aXN0IG9mIGF2YWlsYWJsZSBjaGFubmVscy4gVGhlIHNsYXZlDQpNVVNUIGluY2x1ZGUgcGFyYW1l dGVycyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgZS5nLiBkZXZpY2UNCklE LCBkZXZpY2UgbG9jYXRpb24uDQogDQoNCk8uMTE6IEFjY29yZGluZyB0byBsb2NhbCByZWd1bGF0 b3J5IHBvbGljeSwgdGhlIG1hc3RlciBkZXZpY2UgTUFZIHF1ZXJ5DQp0aGUgZGF0YWJhc2Ugd2l0 aCBwYXJhbWV0ZXJzIHJlY2VpdmVkIGZyb20gdGhlIHNsYXZlIGRldmljZS4NCiANCg0KTy4xMjog VGhlIGRhdGFiYXNlIE1VU1QgcmVzcG9uZCB0byBhIHF1ZXJ5IGZyb20gdGhlIG1hc3RlciBkZXZp Y2UNCmNvbnRhaW5pbmcgcGFyYW1ldGVycyBmcm9tIGEgc2xhdmUgZGV2aWNlLg0KIA0KDQpPLjEz OiBBZnRlciB0aGUgbWFzdGVyIGRldmljZSBoYXMgcmVjZWl2ZWQgYSByZXNwb25zZSBmcm9tIHRo ZSBkYXRhYmFzZSwNCnRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgcmVzcG9uZCB0byB0aGUgc2xhdmUg ZGV2aWNlLiBJZiBhbGwgcmVndWxhdG9yeQ0KcmVxdWlyZW1lbnRzIGFyZSBtZXQgdGhlIHJlc3Bv bnNlIHdpbGwgY29udGFpbiBhbiBhdmFpbGFibGUgY2hhbm5lbCBsaXN0Lg0KSWYgcmVndWxhdG9y eSByZXF1aXJlbWVudHMgYXJlIG5vdCBtZXQsIHRoZSByZXNwb25zZSBNVVNUIGNvbnRhaW4gYXQg bGVhc3QNCmEgcmVzcG9uc2UgY29kZS4NCiANCg0KTy4xNDogSWYgYSBtYXN0ZXIgZGV2aWNlIGhh cyBwcm92aWRlZCBhbiBhdmFpbGFibGUgY2hhbm5lbCBsaXN0IHRvIGEgc2xhdmUNCmRldmljZSB0 aGUgbWFzdGVyIGRldmljZSBNQVkgc2VuZCBhIHBlcmlvZGljIGVuYWJsaW5nIHNpZ25hbCB0byBh bGxvdyB0aGUNCnNsYXZlIGRldmljZSB0byBjb25maXJtIGl0IGlzIHN0aWxsIHdpdGhpbiByZWNl cHRpb24gcmFuZ2Ugb2YgdGhlIG1hc3Rlcg0KZGV2aWNlLg0KIA0KDQpPLjE1OiBUaGUgZW5hYmxp bmcgc2lnbmFsIE1VU1QgYmUgZW5jb2RlZCBzbyB0aGF0IHRoZSByZWNlaXZpbmcgc2xhdmUgY2Fu DQpkZXRlcm1pbmUgdGhlIGlkZW50aXR5IG9mIHRoZSBzZW5kaW5nIG1hc3Rlci4NCiANCg0KTy4x NjogUGVyaW9kaWNhbGx5LCBhdCBhbiBpbnRlcnZhbCBhY2NvcmRpbmcgdG8gbG9jYWwgcmVndWxh dGlvbnMsIHRoZQ0Kc2xhdmUgZGV2aWNlIE1VU1QgZWl0aGVyIHJlY2VpdmUgYW5kIGVuYWJsaW5n IHNpZ25hbCBvciBNVVNUIHN1Y2Nlc3NmdWxseQ0KcmVwZWF0IHRoZSBjaGFubmVsIHJlcXVlc3Qg cHJvY2VzcyBvciBNVVNUIGNlYXNlIHRyYW5zbWlzc2lvbiBvbiB0aGUNCmNoYW5uZWwuDQogDQoN Ck8uMTc6IEEgbWFzdGVyIGRldmljZSBNVVNUIHJlcGVhdCB0aGUgcXVlcnkgdGhlIGRhdGFiYXNl IGZvciB0aGUgYXZhaWxhYmxlDQpjaGFubmVscyBhcyBvZnRlbiBhcyByZXF1aXJlZCBieSB0aGUg cmVndWxhdGlvbiAoZWcsIEZDQyByZXF1aXJlcyBvbmNlIHBlcg0KZGF5KSB0byB2ZXJpZnkgdGhh dCB0aGUgb3BlcmF0aW5nIGNoYW5uZWxzIGNvbnRpbnVlIHRvIHJlbWFpbiBhdmFpbGFibGUuDQog DQoNCk8uMTg6IEEgbWFzdGVyIGRldmljZSB3aGljaCBjaGFuZ2VzIGl0cyBsb2NhdGlvbiBtb3Jl IHRoYW4gYSB0aHJlc2hvbGQNCmRpc3RhbmNlIHNwZWNpZmllZCBieSBsb2NhbCByZWd1bGF0b3J5 IHBvbGljeSBkdXJpbmcgaXRzIG9wZXJhdGlvbiwgTVVTVA0KcXVlcnkgdGhlIGRhdGFiYXNlIGZv ciBhdmFpbGFibGUgb3BlcmF0aW5nIGNoYW5uZWxzIGVhY2ggdGltZSBpdCBtb3Zlcw0KbW9yZSB0 aGFuIHRoZSB0aHJlc2hvbGQgZGlzdGFuY2UgKGUuZy4sIEZDQyBzcGVjaWZpZXMgMTAwbSkgZnJv bSB0aGUNCmxvY2F0aW9uIGl0IHByZXZpb3VzbHkgbWFkZSB0aGUgcXVlcnkuDQogDQoNCg0KPEVk LiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIHdyYW4gdXNlIGNhc2U8L0VkLiBOb3RlPg0K Ty4xOTogSWYgc2xhdmUgZGV2aWNlcyBjaGFuZ2UgdGhlaXIgbG9jYXRpb24gZHVyaW5nIG9wZXJh dGlvbiBieSBtb3JlIHRoYW4NCmEgbGltaXQgc3BlY2lmaWVkIGJ5IHRoZSBsb2NhbCByZWd1bGF0 b3IsIHRoZSBzbGF2ZSBkZXZpY2UgTVVTVCBxdWVyeSB0aGUNCm1hc3RlciBkZXZpY2UgZm9yIGF2 YWlsYWJsZSBvcGVyYXRpbmcgY2hhbm5lbHMuDQogDQoNCg0KPEVkLiBOb3RlPnJlcXVpcmVtZW50 cyByZWxhdGVkIHRvIHJhcGlkIGRlcGxveWVkIG5ldHdvcmsgdXNlIGNhc2U8L0VkLg0KTm90ZT4N Ck8uMjA6IEFjY29yZGluZyB0byBsb2NhbCByZWd1bGF0b3IgcG9saWN5LCBhIG1hc3RlciBkZXZp Y2UgbWF5IGNvbnRhY3QgYQ0KZGF0YWJhc2UgdmlhIHByb3h5IHNlcnZpY2Ugb2YgYW5vdGhlciBt YXN0ZXIgZGV2aWNlLg0KIA0KDQoNCjxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBt b2JpbGl0eSB1c2UgY2FzZTwvRWQuIE5vdGU+DQpPLjIxOiBBIG1hc3RlciBkZXZpY2UgTVVTVCBi ZSBhYmxlIHRvIHF1ZXJ5IHRoZSB3aGl0ZXNwYWNlIGRhdGFiYXNlIGZvcg0KY2hhbm5lbCBhdmFp bGFiaWxpdHkgaW5mb3JtYXRpb24gZm9yIGEgc3BlY2lmaWMgZXhwZWN0ZWQgY292ZXJhZ2UgYXJl YQ0KYXJvdW5kIGl0cyBjdXJyZW50IGxvY2F0aW9uLg0KIA0KDQoNCjxFZC4gTm90ZT5yZXF1aXJl bWVudHMgcmVsYXRlZCB0byB0aHJlYXQgbW9kZWw8L0VkLiBOb3RlPg0KTy4yMjogQSBNYXN0ZXIg ZGV2aWNlIE1BWSBub3QgaW5jbHVkZSBpdHMgaWRlbnRpdHkgaW4NCm1lc3NhZ2VzIHNlbnQgdG8g dGhlIGRhdGFiYXNlIHdoZW4gbm90IHJlcXVpcmVkIGJ5IHRoZSByZWd1bGF0b3J5DQogDQogDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwYXdzIG1h aWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wYXdzDQo= From teco@inf-net.nl Tue Feb 21 23:34:44 2012 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 9960021E806D for ; Tue, 21 Feb 2012 23:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kYs8vGr71vG for ; Tue, 21 Feb 2012 23:34:43 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D72D621E8043 for ; Tue, 21 Feb 2012 23:34:41 -0800 (PST) Received: by eaal12 with SMTP id l12so2884300eaa.31 for ; Tue, 21 Feb 2012 23:34:41 -0800 (PST) Received-SPF: pass (google.com: domain of teco@inf-net.nl designates 10.14.94.134 as permitted sender) client-ip=10.14.94.134; Authentication-Results: mr.google.com; spf=pass (google.com: domain of teco@inf-net.nl designates 10.14.94.134 as permitted sender) smtp.mail=teco@inf-net.nl Received: from mr.google.com ([10.14.94.134]) by 10.14.94.134 with SMTP id n6mr14688104eef.63.1329896081221 (num_hops = 1); Tue, 21 Feb 2012 23:34:41 -0800 (PST) Received: by 10.14.94.134 with SMTP id n6mr11717668eef.63.1329896080227; Tue, 21 Feb 2012 23:34:40 -0800 (PST) Received: from [10.175.173.4] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id s48sm97144758eem.0.2012.02.21.23.34.39 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Feb 2012 23:34:39 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Wed, 22 Feb 2012 08:34:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <449B85CE-11EF-4C84-A0D5-67225BDB6F50@inf-net.nl> References: To: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnuI8mDHOfGHDPZt9A20PtjDidHWVutiTeFVOSgRSt0ZzPDJuxRd/BaE51zaovfiAeJhLP8 Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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, 22 Feb 2012 07:34:44 -0000 Scott, Ray, The P.* are mostly MUST requirements for the protocol. That's fine. Except P.10, this is a MAY operational requirement. The protocol=20 MUST support it. I'm fine with the rest of it. Is noted somewhere that we (IETF) do our best to support as many=20 regulator rules as possible, and leave setting up requirements for=20 actual deployment up to the mandated authorities? This makes the=20 O.* requirements informational. Thanks, Teco Op 22 feb. 2012, om 00:53 heeft = het volgende geschreven: > Hello All, >=20 > I have revised Section 6 of the I-D which describes the Data Model > Requirements, Protocol Requirements and Operational Requirements. This > includes the requirements from the threat model > (http://www.ietf.org/mail-archive/web/paws/current/msg00771.html). >=20 > The requirements are ordered "top down" to follow the previous = sections of > the document: requirements derived from discovery are followed by > requirements derived from registration are followed by requirements > derived from hotspot, etc... >=20 > Please review the proposed text, we hope to have your comments by Feb = 28th. >=20 > Kind Regards, >=20 > Raj & Scott >=20 >=20 >=20 >=20 > D. Data Model Requirements: >=20 >=20 > requirements related to discovery function > D.1: The Data Model MUST support specifying the location of the WSD, = the > uncertainty in meters, the height & its uncertainty, and confidence in > percentage for the location determination. The Data Model MUST support > both North American Datum of 1983 and WGS84. >=20 >=20 > D.2: The Data Model MUST support specifying the URI address of a white > space database. >=20 >=20 > D.3: The Data Model MUST support specifying the URI address of a = national > listing service. >=20 >=20 > D.4: The Data Model MUST support specifying regulatory domain and its > corresponding data requirements. >=20 >=20 >=20 > requirements related to registration function > D.5: The Data Model MUST support specifying an ID of the transmitter > device. This ID would contain the ID of the transmitter device that = has > been certified by a regulatory body for its regulatory domain. The = Data > Model MUST support a device class. >=20 >=20 >=20 > D.6: The Data Model MUST support specifying a manufacturer=B9s serial = number > for a master device. >=20 >=20 > D.7: The Data Model MUST support specifying the antenna and radiation > related parameters of the device, such as: >=20 > - antenna height >=20 > - antenna gain >=20 > - maximum output power, EIRP (dBm) >=20 > - antenna radiation pattern (directional dependence > of the strength of the radio signal from the antenna) >=20 > - spectrum mask with lowest and highest possible frequency >=20 > - spectrum mask in dBr from peak transmit power in EIRP, > with specific power limit at any frequency linearly > interpolated between adjacent points of the spectrum mask > measurement resolution bandwidth for EIRP measurements. >=20 >=20 >=20 > D.8: The Data Model MUST support specifying owner and operator contact > information for a transmitter. This includes the name of the = transmitter > owner, name of transmitter operator, postal address, email address and > phone number of the transmitter operator. >=20 >=20 >=20 >=20 > requirements related to hotspot use case > D.9: The Data Model MUST support specifying a list of available = channels. > The Data Model MUST support specification of this information by = channel > numbers and by start and stop frequencies. The Data Model MUST support = a > channel availability schedule and maximum power level for each channel = in > the list. >=20 >=20 >=20 > requirements related to mobility use case > D.10: The Data Model MUST support specifying channel availability > information for a single location and an area (e.g. a polygon defined = by > multiple location points or a geometric shape such as a circle). >=20 >=20 >=20 >=20 >=20 > P. Protocol Requirements: >=20 >=20 > requirements related to discovery function > P.1: The protocol MUST provide a message sequence for the master = device to > discover a white space database that provides service at its current > location. >=20 >=20 > P.2: The protocol MUST support access of a database directly. The = protocol > MUST support access of a database using a listing approved by a = national > regulator. >=20 >=20 > P.3: The protocol MUST support determination of regulatory domain > governing its current location. >=20 >=20 > requirements related to threat model >=20 >=20 > P.4: The protocol MUST provide the ability for the database to > authenticate the master device. >=20 >=20 > P.5: The protocol MUST provide the ability for the master device to = verify > the authenticity of the database with which it is interacting. >=20 >=20 > P.6: The messages sent by the master device to the database MUST be > integrity protected. >=20 >=20 > P.7: The messages sent by the database to the master device MUST be > integrity protected. >=20 >=20 > P.8: The protocol MUST provide the capability for messages sent by the > master device and database to be encrypted. >=20 >=20 >=20 >=20 >=20 >=20 > requirements related to registration function > P.9: The protocol MUST support the master device registering with the > database. >=20 >=20 > P.10: The registration signaling MAY include the Device ID, = manufacturer=B9s > serial number, device location, device antenna characteristic = information, > name of individual or business that owns the device, name, address, = email > address and phone number of a contact person who is responsible for = device > operation. >=20 >=20 > P.11: The protocol MUST support a registration acknowledgement = including > appropriate result codes. >=20 >=20 >=20 >=20 > requirements related to hotspot use case > P.12: The protocol MUST support a channel query request from the = master > device to the database. The channel query request message MUST include > parameters as required by local regulatory requirement. These = parameters > MAY include device location, device ID, manufacturer=B9s serial = number, and > antenna characteristic information. >=20 >=20 > P.13: The protocol MUST support a channel query response from the = database > to the master device. The channel query response message MUST include > parameters as required by local regulatory requirement. These = parameters > MAY include available channels, duration of time for their use, = associated > maximum power levels, any additional sensing requirements. >=20 >=20 > P.14: The protocol MUST support a channel query request from the slave > device to the master device. The channel query request message MUST > include parameters as required by local regulatory requirement. These > parameters MAY include device ID and slave device location. >=20 >=20 > P.15: The protocol MUST support a validation request from the master = to > the database to validate a slave device. The validation request MUST > include the slave device ID. >=20 >=20 > P.16: The protocol MUST support a validation response from the = database to > the master. The validation response MUST include a response code. >=20 >=20 > P.17: The protocol MUST support a channel query response from the = master > device to the slave device. The channel query response message MUST > include parameters as required by local regulatory requirement, = including > a response code and sufficient information to decode an enabling = signal. >=20 >=20 > P.18: The protocol MUST support an enabling signal sent from the = master to > the slave. This signal MUST allow the slave device to validate that a > previously received available channel list is still valid or not. This > signal MUST be encoded to allow the slave device to determine the = identity > if the sending master device. >=20 >=20 >=20 > P.19: The protocol between the master device and the database MUST = support > the capability to change channel availability lists on short notice. >=20 >=20 >=20 > requirements related to mobility use case > P.20: The protocol between the master device and the database MUST = support > a channel availability request which specifies a geographic location = as an > area as well as a point. >=20 >=20 >=20 >=20 >=20 > O. Operational Requirements: >=20 >=20 > requirements related to discovery function >=20 > O.1: The database and the master device MUST be connected to the = Internet. >=20 >=20 > O.2: A master device MUST be able to determine its location including > uncertainty and confidence level. A fixed master device MAY use a = location > programmed at installation or have the capability determine its = location > to the required accuracy. A mobile master device MUST have the = capability > to determine its location to the required accuracy. >=20 >=20 > O.3: The master device MUST identify a database for use. The master = device > MAY select a database for service by discovery at runtime or the = master > device MAY select a database for service by means of a pre-programmed = URI > address. >=20 >=20 > O.4: The master device MUST implement at least one connection method = to > access the database. The master device MAY contact a database directly = for > service (e.g. as defined by FCC) or the master device MAY contact a > listing server first followed by contact to a database (e.g. As = defined by > Ofcom). >=20 >=20 > O.5: The master device MUST obtain an indication the regulatory domain > governing operation at its current location, i.e. the master device = MUST > know if it operates under regulations from FCC, Ofcom, etc=8A >=20 >=20 >=20 >=20 > requirements related to registration function > O.6: The master device MAY register with the database according to = local > regulatory policy. Not all master devices will be required to = register. > Specific events will initiate registration, these events are = determined by > regulator policy (e.g. at power up, after movement, etc=8A). >=20 >=20 > O.7: The master device MUST register with its most current and = up-to-date > information. >=20 >=20 >=20 >=20 > requirements related to hotspot use case > O.8: A master device MUST query the database for the available = channels > based on its current location before starting radio transmission in = white > space. Parameters provided to the database MAY include device = location, > accuracy of the location, antenna characteristic information, device > identifier of any slave device requesting channel information. >=20 >=20 > O.9: The database MUST respond to an available channel list request = from > an authenticated and authorized device and MAY also provide time > constraints, maximum output power, start and stop frequencies for each > channel in the list and any additional requirements for sensing. >=20 >=20 > O.10: After connecting to a master device=B9s radio network a slave = device > MUST query the master device for a list of available channels. The = slave > MUST include parameters required by local regulatory policy, e.g. = device > ID, device location. >=20 >=20 > O.11: According to local regulatory policy, the master device MAY = query > the database with parameters received from the slave device. >=20 >=20 > O.12: The database MUST respond to a query from the master device > containing parameters from a slave device. >=20 >=20 > O.13: After the master device has received a response from the = database, > the master device MUST respond to the slave device. If all regulatory > requirements are met the response will contain an available channel = list. > If regulatory requirements are not met, the response MUST contain at = least > a response code. >=20 >=20 > O.14: If a master device has provided an available channel list to a = slave > device the master device MAY send a periodic enabling signal to allow = the > slave device to confirm it is still within reception range of the = master > device. >=20 >=20 > O.15: The enabling signal MUST be encoded so that the receiving slave = can > determine the identity of the sending master. >=20 >=20 > O.16: Periodically, at an interval according to local regulations, the > slave device MUST either receive and enabling signal or MUST = successfully > repeat the channel request process or MUST cease transmission on the > channel. >=20 >=20 > O.17: A master device MUST repeat the query the database for the = available > channels as often as required by the regulation (eg, FCC requires once = per > day) to verify that the operating channels continue to remain = available. >=20 >=20 > O.18: A master device which changes its location more than a threshold > distance specified by local regulatory policy during its operation, = MUST > query the database for available operating channels each time it moves > more than the threshold distance (e.g., FCC specifies 100m) from the > location it previously made the query. >=20 >=20 >=20 > requirements related to wran use case > O.19: If slave devices change their location during operation by more = than > a limit specified by the local regulator, the slave device MUST query = the > master device for available operating channels. >=20 >=20 >=20 > requirements related to rapid deployed network use case Note> > O.20: According to local regulator policy, a master device may contact = a > database via proxy service of another master device. >=20 >=20 >=20 > requirements related to mobility use case > O.21: A master device MUST be able to query the whitespace database = for > channel availability information for a specific expected coverage area > around its current location. >=20 >=20 >=20 > requirements related to threat model > O.22: A Master device MAY not include its identity in > messages sent to the database when not required by the regulatory >=20 >=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Fri Feb 24 10:49:57 2012 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 12FB221F8745 for ; Fri, 24 Feb 2012 10:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_50=0.001, J_BACKHAIR_44=1, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdI6Tu8AWqjT for ; Fri, 24 Feb 2012 10:49:55 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0287121F8744 for ; Fri, 24 Feb 2012 10:49:54 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1OInJo4031075; Fri, 24 Feb 2012 20:49:19 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.56]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 20:49:19 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-001.mgdnok.nokia.com ([65.54.30.56]) with mapi id 14.01.0355.003; Fri, 24 Feb 2012 19:49:13 +0100 From: To: , , Thread-Topic: UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZISuoAgAOnygA= Date: Fri, 24 Feb 2012 18:49:12 +0000 Message-ID: In-Reply-To: <470F27D1263A1B4EB73491ED995DE625147955A6@szxeml504-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.53.191] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2012 18:49:19.0607 (UTC) FILETIME=[04298070:01CCF325] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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, 24 Feb 2012 18:49:57 -0000 SGVsbG8gTGVpLA0KDQpJIGRvIHN1cHBvcnQgdGhlIGNvbmNlcHQgeW91IGRlc2NyaWJlIGJlbG93 LCB3aGVyZSBhIGRldmljZSBtYXkgZnVuY3Rpb24NCnRvIGNvb3JkaW5hdGUgdGhlIG9wZXJhdGlv biBvZiBtdWx0aXBsZSBtYXN0ZXJzLiBUaGlua2luZyBzdHJpY3RseSBhYm91dA0KdGhlIGNvbm5l Y3Rpb25zIHJlcXVpcmVkIHRvIGltcGxlbWVudCB0aGlzIHNlcnZpY2UsIEkgYmVsaWV2ZSByZXF1 aXJlbWVudA0KTy4yMCBtYXkgc3VwcG9ydCB0aGUgY29uY2VwdCB5b3UgZGVzY3JpYmUuDQoNClJl dmlld2luZyB0aGUgb3BlcmF0aW9uYWwgc3lzdGVtIGZyYW1ld29yayB5b3UgZGVzY3JpYmUgYmVs b3csIHRoaXMgc2VlbXMNCnRvIG1lIHRvIGJlIHZlcnkgc2ltaWxhciB0byBwcmV2aW91cyBkaXNj dXNzaW9ucyBpbiB0aGlzIHdvcmsgZ3JvdXAgd2hpY2gNCndlcmUgZGV0ZXJtaW5lZCB0byBiZSBv dXQgb2Ygc2NvcGUuIEJlZm9yZSBjb25zaWRlcmluZyBpZiBhZGRpdGlvbmFsIHVzZQ0KY2FzZXMg b3IgcmVxdWlyZW1lbnRzIGFyZSBhcHByb3ByaWF0ZSwgSSBwcm9wb3NlIHRvIGFzayB0aGUgd29y a2luZyBncm91cA0KbGVhZGVycyB0byBjb21tZW50IG9uIHRoZSBzY29wZSBvZiB0aGlzIGZyYW1l d29yay4NCg0KS2luZCBSZWdhcmRzLA0KU2NvdHQNCiANCg0KT24gMi8yMi8xMiAxMjo0MCBBTSwg ImV4dCBaaHVMZWkiIDxsZWkuemh1QGh1YXdlaS5jb20+IHdyb3RlOg0KDQo+SSBoYWQgYSBjb21t ZW50IG9uIGZyYW1ld29yayBvZiBpdCBhbmQgcHJvYmFibHkgZGlzY3VzcyBpdCBiZWZvcmUNCj50 b3VjaGluZyB0aW1lbGluZS4NCj4NCj5JdCBpcyBhIGVhc3kgdG8gdGhpbmsgYWJvdXQgdGhlIGRp c3RyaWJ1dGVkIG9yIGhpZXJhcmNoaWNhbA0KPmltcGxlbWVudGF0aW9uIG9mIHBhd3MgZm9yIHNv bWUgcmVhc29ucy4gT25lIGlzIHRoYXQgdGhlIGRhdGFiYXNlDQo+ZG9taW5hdGVkIGJ5IGEgcmVn dWxhdG9yIHdoaWNoIG1heSBkaXN0cmlidXRlIHJlc3BvbnNpYmlsaXRpZXMgb2YNCj5kaWZmZXJl bnQgYXJlYXMgb3IgcmVnaW9ucyB0byBicmFuY2hlcyBvZiBoZXIuIFRoaXMgbmVlZCBhbGxvd3Mg c3Vic2V0IG9mDQo+ZGF0YWJhc2Ugd29ya2luZyBieSBtYWludGFpbmluZyBhdmFpbGFibGUgY2hh bm5lbCBsaXN0cyBkYXRhYmFzZSBpbg0KPnBhcnRpY3VsYXIgYXJlYSBvciBmb3Igc29tZSBwdXJw b3Nlcy4NCj4NCj5BcyBkaXNjdXNzZWQgaW4gdGhpcyBtYWlsIGxpc3QsIGRhdGFiYXNlIGlzIGlu IGNoYXJnZSBvZiBzdG9yaW5nIGFuZA0KPm1haW50YWluaW5nIHdoaXRlIHNwYWNlIGNoYW5uZWwg aW5mb3JtYXRpb24gZm9yIGEgbGFyZ2UgYXJlYSAoZS5nLiBhDQo+Y291bnRyeSkgYW5kIGl0IG1h eSBiZSBvcGVyYXRlZCBieSByZWd1bGF0b3J5IGJvZHksIGluIHRoZSBjdXJyZW50IHN5c3RlbQ0K PmFyY2hpdGVjdHVyZSBhbGwgdGhlIG1hc3RlciBkZXZpY2VzIHF1ZXJ5IHdoaXRlIHNwYWNlIGRp cmVjdGx5IGZyb20NCj5kYXRhYmFzZSwgYnV0IGluIGlmIGFuIGVudGl0eSBpcyBhZGRlZCBiZXR3 ZWVuIG1hc3RlciBkZXZpY2UgYW5kDQo+ZGF0YWJhc2UsIGFuZCB0aGlzIGVudGl0eSBpcyBpbiBj aGFyZ2Ugb2YgYWxsb2NhdGluZyB3aGl0ZSBzcGFjZSBmb3INCj5tYXN0ZXIgZGV2aWNlcywgdGhl IGFwcGxpY2F0aW9uIG9mIHdoaXRlIHNwYWNlIHdpbGwgYmUgbW9yZSBmbGV4aWJsZS4gRm9yDQo+ ZXhhbXBsZSwgYSB3aGl0ZSBzcGFjZSB1c2VyIG93bnMgYSBsb3Qgb2YgbWFzdGVyIGRldmljZXMg YW5kIGl0IHdhbnRzIHRvDQo+ZXN0YWJsaXNoIHdpcmVsZXNzIG5ldHdvcmsgdXNpbmcgdGhlc2Ug bWFzdGVyIGRldmljZSwgaXQgY2FuIHNldCBhDQo+Y29vcmRpbmF0aW5nIGRhdGFiYXNlIHdoaWNo IGdldHMgd2hpdGUgc3BhY2UgaW4gaXRzIGFyZWEgZnJvbSBkYXRhYmFzZQ0KPmFuZCBhbGwgb2Yg aXRzIG1hc3RlciBkZXZpY2VzIHF1ZXJ5IHdoaXRlIHNwYWNlIGZyb20gdGhlIGNvb3JkaW5hdGlu Zw0KPmRhdGFiYXNlLCBiZWNhdXNlIHRoZSBtYXN0ZXIgZGV2aWNlcyBkb27igJl0IHF1ZXJ5IHdo aXRlIHNwYWNlIGZyb20NCj5kYXRhYmFzZSBzbyB0aGUgYnVyZGVuIG9mIGRhdGFiYXNlIHdpbGwg YmUgcmVkdWNlZCwgYW5kIGJlY2F1c2UgdGhlIHdoaXRlDQo+c3BhY2UgdXNlciBvd25zIHRoZSBj b29yZGluYXRpbmcgZGF0YWJhc2Ugc28gaXQgY2FuIGltcGxlbWVudCBpdHMgcG9saWN5DQo+b2Yg dXNpbmcgc3BlY3RydW0uDQo+DQo+TWFzdGVyIGRldmljZSBjYW4gZ2V0IHdoaXRlIHNwYWNlIGZy b20gdGhlIGNvb3JkaW5hdGluZyBkYXRhYmFzZSBqdXN0DQo+bGlrZSBnZXR0aW5nIHdoaXRlIHNw YWNlIGZyb20gZGF0YWJhc2U7IHRoZSBjb29yZGluYXRpbmcgZGF0YWJhc2UgY2FuIGJlDQo+bWFp bnRhaW5lZCBhbmQgb3BlcmF0ZWQgYnkgcmVndWxhdG9yeSBib2R5IChlLmcuIEZDQykuDQo+DQo+ U28sIGhlcmUsIGFuIG9wdGlvbmFsIHN5c3RlbSBmcmFtZXdvcmsgaXMgcHJvcG9zZWQsIGNvbXBh cmVkIHdpdGggdGhlDQo+Y29tbW9ubHkgZGlzY3Vzc2VkIG9uZSBhIG5hbWVkIGNvb3JkaW5hdGlu ZyBkYXRhYmFzZSBpcyBhZGRlZC4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tKw0KPiAgICArLS0tLS0tLS0tLS0tLSsgICAgICAgfENvb3JkaW5hdGluICB8ICAgICAg ICArLS0tLS0tLS0tLS0rDQo+ICAgIHxNYXN0ZXIgRGV2aWNlKy0tKy0tLS0rRGF0YWJhc2UgICAg ICstLS0tKy0tLStEYXRhYmFzZSAgIHwNCj4gICAgKy0tLS0tLS0tLS0tLS0rIFdTICAgICstLS0t LS0tLS0tLS0tKyAgIFdTICAgKy0tLS0tLS0tLS0tKw0KPg0KPkZpZ3VyZSAxIEFuIGFkZGl0aW9u YWwgYXJjaGl0ZWN0dXJlIG9mIHdoaXRlIHNwYWNlIGRhdGFiYXNlIHF1ZXJ5aW5nDQo+c3lzdGVt DQo+DQo+ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPiAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICstLS0tLS0tKyAgIHwNCj4gICAgICAgICAgICAgfCAr LS0tLS0tLS0rICAgICB8TWFzdGVyIHwgICB8DQo+ICAgICAgICAgICAgIHwgfERhdGFiYXNlfCAg ICAgfERldmljZXN8ICAgfA0KPiAgICAgICAgICAgICB8ICstLS0tLS0tLSsgICAgICstLS0tLS0t KyAgIHwNCj4gICAgICAgICAgICAgfENvb3JkaW5hdGluZyBEYXRhYmFzZSAgICAgICB8DQo+ICAg ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPkZpZ3VyZSAyIExvZ2lj YWwgRnVuY3Rpb24gb2YgQ29vcmRpbmF0aW5nIERhdGFiYXNlDQo+DQo+QmVzdCByZWdhcmRzLA0K PlpodSBMZWkNCj5IVUFXRUkgVEVDSE5PTE9HSUVTIENPLixMVEQuDQo+DQo+QWRkcmVzczogSHVh d2VpIEJ1aWxkaW5nLCBObzMgWGlueGkgUm9hZA0KPlNoYW5nRGkgSW5mb3JtYXRpb24gSW5kdXJz dHJ5IEJhc2UsIEhhaWRpYW4gRGlzdHJpY3QNCj5CZWlqaW5nIDEwMDA4NSwgQ2hpbmENCj5UZWw6 ICs4Ni0xMC04MjgzNjMwMQ0KPkZheDogKzg2LTEwLTgyODM2OTIwDQo+TW9iaWxlOiArODYtMTM5 MTAxNTcwMjANCj5FLW1haWw6IGxlaS56aHVAaHVhd2VpLmNvbQ0KPnd3dy5odWF3ZWkuY29tDQo+ LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPlRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMg Y29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbQ0KPkhVQVdFSSwgd2hpY2ggDQo+ aXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBp cyBsaXN0ZWQgYWJvdmUuDQo+QW55IHVzZSBvZiB0aGUgDQo+aW5mb3JtYXRpb24gY29udGFpbmVk IGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywNCj50b3Rh bCBvciBwYXJ0aWFsIA0KPmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlv bikgYnkgcGVyc29ucyBvdGhlciB0aGFuIHRoZQ0KPmludGVuZGVkIA0KPnJlY2lwaWVudChzKSBp cyBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNl DQo+bm90aWZ5IHRoZSBzZW5kZXIgYnkNCj5waG9uZSBvciBlbWFpbCBpbW1lZGlhdGVseSBhbmQg ZGVsZXRlIGl0IQ0KPg0KPg0KPi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCj7lj5Hku7bkuro6IHBh d3MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGo DQo+c2NvdHQucHJvYmFzY29Abm9raWEuY29tDQo+5Y+R6YCB5pe26Ze0OiAyMDEy5bm0MuaciDIy 5pelIDc6NTQNCj7mlLbku7bkuro6IHBhd3NAaWV0Zi5vcmcNCj7kuLvpopg6IFtwYXdzXSBVQyZS IEktRDogUmVxdWlyZW1lbnRzDQo+DQo+SGVsbG8gQWxsLA0KPg0KPkkgaGF2ZSByZXZpc2VkIFNl Y3Rpb24gNiBvZiB0aGUgSS1EIHdoaWNoIGRlc2NyaWJlcyB0aGUgRGF0YSBNb2RlbA0KPlJlcXVp cmVtZW50cywgUHJvdG9jb2wgUmVxdWlyZW1lbnRzIGFuZCBPcGVyYXRpb25hbCBSZXF1aXJlbWVu dHMuIFRoaXMNCj5pbmNsdWRlcyB0aGUgcmVxdWlyZW1lbnRzIGZyb20gdGhlIHRocmVhdCBtb2Rl bA0KPihodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvcGF3cy9jdXJyZW50L21z ZzAwNzcxLmh0bWwpLg0KPg0KPlRoZSByZXF1aXJlbWVudHMgYXJlIG9yZGVyZWQgInRvcCBkb3du IiB0byBmb2xsb3cgdGhlIHByZXZpb3VzIHNlY3Rpb25zIG9mDQo+dGhlIGRvY3VtZW50OiByZXF1 aXJlbWVudHMgZGVyaXZlZCBmcm9tIGRpc2NvdmVyeSBhcmUgZm9sbG93ZWQgYnkNCj5yZXF1aXJl bWVudHMgZGVyaXZlZCBmcm9tIHJlZ2lzdHJhdGlvbiBhcmUgZm9sbG93ZWQgYnkgcmVxdWlyZW1l bnRzDQo+ZGVyaXZlZCBmcm9tIGhvdHNwb3QsIGV0Yy4uLg0KPg0KPlBsZWFzZSByZXZpZXcgdGhl IHByb3Bvc2VkIHRleHQsIHdlIGhvcGUgdG8gaGF2ZSB5b3VyIGNvbW1lbnRzIGJ5IEZlYg0KPjI4 dGguDQo+DQo+S2luZCBSZWdhcmRzLA0KPg0KPlJhaiAmIFNjb3R0DQo+DQo+DQo+DQo+DQo+RC4g RGF0YSBNb2RlbCBSZXF1aXJlbWVudHM6DQo+IA0KPg0KPjxFZC4gTm90ZT5yZXF1aXJlbWVudHMg cmVsYXRlZCB0byBkaXNjb3ZlcnkgZnVuY3Rpb248L0VkLiBOb3RlPg0KPkQuMTogVGhlIERhdGEg TW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgdGhlIGxvY2F0aW9uIG9mIHRoZSBXU0QsIHRo ZQ0KPnVuY2VydGFpbnR5IGluIG1ldGVycywgdGhlIGhlaWdodCAmIGl0cyB1bmNlcnRhaW50eSwg YW5kIGNvbmZpZGVuY2UgaW4NCj5wZXJjZW50YWdlIGZvciB0aGUgbG9jYXRpb24gZGV0ZXJtaW5h dGlvbi4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0DQo+Ym90aCBOb3J0aCBBbWVyaWNhbiBE YXR1bSBvZiAxOTgzIGFuZCBXR1M4NC4NCj4NCj4gDQo+RC4yOiBUaGUgRGF0YSBNb2RlbCBNVVNU IHN1cHBvcnQgc3BlY2lmeWluZyB0aGUgVVJJIGFkZHJlc3Mgb2YgYSB3aGl0ZQ0KPnNwYWNlIGRh dGFiYXNlLg0KPg0KPiANCj5ELjM6IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5 aW5nIHRoZSBVUkkgYWRkcmVzcyBvZiBhIG5hdGlvbmFsDQo+bGlzdGluZyBzZXJ2aWNlLg0KPg0K PiANCj5ELjQ6IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nICByZWd1bGF0 b3J5IGRvbWFpbiBhbmQgaXRzDQo+Y29ycmVzcG9uZGluZyBkYXRhIHJlcXVpcmVtZW50cy4NCj4g DQo+IA0KPg0KPjxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byByZWdpc3RyYXRpb24g ZnVuY3Rpb248L0VkLiBOb3RlPg0KPkQuNTogVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNw ZWNpZnlpbmcgYW4gSUQgb2YgdGhlIHRyYW5zbWl0dGVyDQo+ZGV2aWNlLiBUaGlzIElEIHdvdWxk IGNvbnRhaW4gdGhlIElEIG9mIHRoZSB0cmFuc21pdHRlciBkZXZpY2UgdGhhdCBoYXMNCj5iZWVu IGNlcnRpZmllZCBieSBhIHJlZ3VsYXRvcnkgYm9keSBmb3IgaXRzIHJlZ3VsYXRvcnkgZG9tYWlu LiBUaGUgRGF0YQ0KPk1vZGVsIE1VU1Qgc3VwcG9ydCBhIGRldmljZSBjbGFzcy4NCj4NCj4NCj4g DQo+RC42OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhIG1hbnVmYWN0 dXJlcsK5cyBzZXJpYWwgbnVtYmVyDQo+Zm9yIGEgbWFzdGVyIGRldmljZS4NCj4NCj4gDQo+RC43 OiAgVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgdGhlIGFudGVubmEgYW5k IHJhZGlhdGlvbg0KPnJlbGF0ZWQgcGFyYW1ldGVycyBvZiB0aGUgZGV2aWNlLCBzdWNoIGFzOg0K PiANCj4gICAtIGFudGVubmEgaGVpZ2h0DQo+IA0KPiAgIC0gYW50ZW5uYSBnYWluDQo+IA0KPiAg IC0gbWF4aW11bSBvdXRwdXQgcG93ZXIsIEVJUlAgKGRCbSkNCj4gDQo+ICAgLSBhbnRlbm5hIHJh ZGlhdGlvbiBwYXR0ZXJuIChkaXJlY3Rpb25hbCBkZXBlbmRlbmNlDQo+ICAgICBvZiB0aGUgc3Ry ZW5ndGggb2YgdGhlIHJhZGlvIHNpZ25hbCBmcm9tIHRoZSBhbnRlbm5hKQ0KPiANCj4gICAtIHNw ZWN0cnVtIG1hc2sgd2l0aCBsb3dlc3QgYW5kIGhpZ2hlc3QgcG9zc2libGUgZnJlcXVlbmN5DQo+ IA0KPiAgIC0gc3BlY3RydW0gbWFzayBpbiBkQnIgZnJvbSBwZWFrIHRyYW5zbWl0IHBvd2VyIGlu IEVJUlAsDQo+ICAgICB3aXRoIHNwZWNpZmljIHBvd2VyIGxpbWl0IGF0IGFueSBmcmVxdWVuY3kg bGluZWFybHkNCj4gICAgIGludGVycG9sYXRlZCBiZXR3ZWVuIGFkamFjZW50IHBvaW50cyBvZiB0 aGUgc3BlY3RydW0gbWFzaw0KPiAgICAgbWVhc3VyZW1lbnQgcmVzb2x1dGlvbiBiYW5kd2lkdGgg Zm9yIEVJUlAgbWVhc3VyZW1lbnRzLg0KPg0KPiANCj4gDQo+RC44OiBUaGUgRGF0YSBNb2RlbCBN VVNUIHN1cHBvcnQgc3BlY2lmeWluZyBvd25lciBhbmQgb3BlcmF0b3IgY29udGFjdA0KPmluZm9y bWF0aW9uIGZvciBhIHRyYW5zbWl0dGVyLiBUaGlzIGluY2x1ZGVzIHRoZSBuYW1lIG9mIHRoZSB0 cmFuc21pdHRlcg0KPm93bmVyLCBuYW1lIG9mIHRyYW5zbWl0dGVyIG9wZXJhdG9yLCBwb3N0YWwg YWRkcmVzcywgZW1haWwgYWRkcmVzcyBhbmQNCj5waG9uZSBudW1iZXIgb2YgdGhlIHRyYW5zbWl0 dGVyIG9wZXJhdG9yLg0KPg0KPg0KPiANCj4gDQo+PEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxh dGVkIHRvIGhvdHNwb3QgdXNlIGNhc2U8L0VkLiBOb3RlPg0KPkQuOTogVGhlIERhdGEgTW9kZWwg TVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgYSBsaXN0IG9mIGF2YWlsYWJsZSBjaGFubmVscy4NCj5U aGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0aGlzIGluZm9ybWF0 aW9uIGJ5IGNoYW5uZWwNCj5udW1iZXJzIGFuZCBieSBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2ll cy4gVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IGENCj5jaGFubmVsIGF2YWlsYWJpbGl0eSBz Y2hlZHVsZSBhbmQgbWF4aW11bSBwb3dlciBsZXZlbCBmb3IgZWFjaCBjaGFubmVsIGluDQo+dGhl IGxpc3QuDQo+DQo+DQo+IA0KPjxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBtb2Jp bGl0eSB1c2UgY2FzZTwvRWQuIE5vdGU+DQo+RC4xMDogIFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3Vw cG9ydCBzcGVjaWZ5aW5nIGNoYW5uZWwgYXZhaWxhYmlsaXR5DQo+aW5mb3JtYXRpb24gZm9yIGEg c2luZ2xlIGxvY2F0aW9uIGFuZCBhbiBhcmVhIChlLmcuIGEgcG9seWdvbiBkZWZpbmVkIGJ5DQo+ bXVsdGlwbGUgbG9jYXRpb24gcG9pbnRzIG9yIGEgZ2VvbWV0cmljIHNoYXBlIHN1Y2ggYXMgYSBj aXJjbGUpLg0KPg0KPg0KPg0KPiANCj4gDQo+UC4gUHJvdG9jb2wgUmVxdWlyZW1lbnRzOg0KPg0K PiANCj48RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gZGlzY292ZXJ5IGZ1bmN0aW9u PC9FZC4gTm90ZT4NCj5QLjE6IFRoZSBwcm90b2NvbCBNVVNUIHByb3ZpZGUgYSBtZXNzYWdlIHNl cXVlbmNlIGZvciB0aGUgbWFzdGVyIGRldmljZSB0bw0KPmRpc2NvdmVyIGEgd2hpdGUgc3BhY2Ug ZGF0YWJhc2UgdGhhdCBwcm92aWRlcyBzZXJ2aWNlIGF0IGl0cyBjdXJyZW50DQo+bG9jYXRpb24u DQo+DQo+IA0KPlAuMjogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhY2Nlc3Mgb2YgYSBkYXRh YmFzZSBkaXJlY3RseS4gVGhlIHByb3RvY29sDQo+TVVTVCBzdXBwb3J0IGFjY2VzcyBvZiBhIGRh dGFiYXNlIHVzaW5nIGEgbGlzdGluZyBhcHByb3ZlZCBieSBhIG5hdGlvbmFsDQo+cmVndWxhdG9y Lg0KPg0KPiANCj5QLjM6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgZGV0ZXJtaW5hdGlvbiBv ZiByZWd1bGF0b3J5IGRvbWFpbg0KPmdvdmVybmluZyBpdHMgY3VycmVudCBsb2NhdGlvbi4NCj4N Cj4NCj48RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gdGhyZWF0IG1vZGVsPC9FZC4g Tm90ZT4NCj4NCj4gDQo+UC40OiBUaGUgcHJvdG9jb2wgTVVTVCBwcm92aWRlIHRoZSBhYmlsaXR5 IGZvciB0aGUgZGF0YWJhc2UgdG8NCj5hdXRoZW50aWNhdGUgdGhlIG1hc3RlciBkZXZpY2UuDQo+ DQo+IA0KPlAuNTogVGhlIHByb3RvY29sIE1VU1QgcHJvdmlkZSB0aGUgYWJpbGl0eSBmb3IgdGhl IG1hc3RlciBkZXZpY2UgdG8gdmVyaWZ5DQo+dGhlIGF1dGhlbnRpY2l0eSBvZiB0aGUgZGF0YWJh c2Ugd2l0aCB3aGljaCBpdCBpcyBpbnRlcmFjdGluZy4NCj4NCj4gDQo+UC42OiBUaGUgbWVzc2Fn ZXMgc2VudCBieSB0aGUgbWFzdGVyIGRldmljZSB0byB0aGUgZGF0YWJhc2UgTVVTVCBiZQ0KPmlu dGVncml0eSBwcm90ZWN0ZWQuDQo+DQo+IA0KPlAuNzogVGhlIG1lc3NhZ2VzIHNlbnQgYnkgdGhl IGRhdGFiYXNlIHRvIHRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgYmUNCj5pbnRlZ3JpdHkgcHJvdGVj dGVkLg0KPg0KPiANCj5QLjg6IFRoZSBwcm90b2NvbCBNVVNUIHByb3ZpZGUgdGhlIGNhcGFiaWxp dHkgZm9yIG1lc3NhZ2VzIHNlbnQgYnkgdGhlDQo+bWFzdGVyIGRldmljZSBhbmQgZGF0YWJhc2Ug dG8gYmUgZW5jcnlwdGVkLg0KPg0KPg0KPg0KPiANCj4gDQo+IA0KPjxFZC4gTm90ZT5yZXF1aXJl bWVudHMgcmVsYXRlZCB0byByZWdpc3RyYXRpb24gZnVuY3Rpb248L0VkLiBOb3RlPg0KPlAuOTog VGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCB0aGUgbWFzdGVyIGRldmljZSByZWdpc3RlcmluZyB3 aXRoIHRoZQ0KPmRhdGFiYXNlLg0KPg0KPiANCj5QLjEwOiBUaGUgcmVnaXN0cmF0aW9uIHNpZ25h bGluZyBNQVkgaW5jbHVkZSB0aGUgRGV2aWNlIElELCBtYW51ZmFjdHVyZXLCuXMNCj5zZXJpYWwg bnVtYmVyLCBkZXZpY2UgbG9jYXRpb24sIGRldmljZSBhbnRlbm5hIGNoYXJhY3RlcmlzdGljIGlu Zm9ybWF0aW9uLA0KPm5hbWUgb2YgaW5kaXZpZHVhbCBvciBidXNpbmVzcyB0aGF0IG93bnMgdGhl IGRldmljZSwgbmFtZSwgYWRkcmVzcywgZW1haWwNCj5hZGRyZXNzIGFuZCBwaG9uZSBudW1iZXIg b2YgYSBjb250YWN0IHBlcnNvbiB3aG8gaXMgcmVzcG9uc2libGUgZm9yIGRldmljZQ0KPm9wZXJh dGlvbi4NCj4NCj4gDQo+UC4xMTogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIHJlZ2lzdHJh dGlvbiBhY2tub3dsZWRnZW1lbnQgaW5jbHVkaW5nDQo+YXBwcm9wcmlhdGUgcmVzdWx0IGNvZGVz Lg0KPg0KPg0KPiANCj4gDQo+PEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGhvdHNw b3QgdXNlIGNhc2U8L0VkLiBOb3RlPg0KPlAuMTI6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQg YSBjaGFubmVsIHF1ZXJ5IHJlcXVlc3QgZnJvbSB0aGUgbWFzdGVyDQo+ZGV2aWNlIHRvIHRoZSBk YXRhYmFzZS4gVGhlIGNoYW5uZWwgcXVlcnkgcmVxdWVzdCBtZXNzYWdlIE1VU1QgaW5jbHVkZQ0K PnBhcmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4g VGhlc2UgcGFyYW1ldGVycw0KPk1BWSBpbmNsdWRlIGRldmljZSBsb2NhdGlvbiwgZGV2aWNlIElE LCBtYW51ZmFjdHVyZXLCuXMgc2VyaWFsIG51bWJlciwgYW5kDQo+YW50ZW5uYSBjaGFyYWN0ZXJp c3RpYyBpbmZvcm1hdGlvbi4NCj4NCj4gDQo+UC4xMzogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9y dCBhIGNoYW5uZWwgcXVlcnkgcmVzcG9uc2UgZnJvbSB0aGUgZGF0YWJhc2UNCj50byB0aGUgbWFz dGVyIGRldmljZS4gVGhlIGNoYW5uZWwgcXVlcnkgcmVzcG9uc2UgbWVzc2FnZSBNVVNUIGluY2x1 ZGUNCj5wYXJhbWV0ZXJzIGFzIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkgcmVxdWlyZW1l bnQuIFRoZXNlIHBhcmFtZXRlcnMNCj5NQVkgaW5jbHVkZSBhdmFpbGFibGUgY2hhbm5lbHMsIGR1 cmF0aW9uIG9mIHRpbWUgZm9yIHRoZWlyIHVzZSwgYXNzb2NpYXRlZA0KPm1heGltdW0gcG93ZXIg bGV2ZWxzLCBhbnkgYWRkaXRpb25hbCBzZW5zaW5nIHJlcXVpcmVtZW50cy4NCj4gDQo+DQo+UC4x NDogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgcXVlcnkgcmVxdWVzdCBmcm9t IHRoZSBzbGF2ZQ0KPmRldmljZSB0byB0aGUgbWFzdGVyIGRldmljZS4gVGhlIGNoYW5uZWwgcXVl cnkgcmVxdWVzdCBtZXNzYWdlIE1VU1QNCj5pbmNsdWRlIHBhcmFtZXRlcnMgYXMgcmVxdWlyZWQg YnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4gVGhlc2UNCj5wYXJhbWV0ZXJzIE1BWSBp bmNsdWRlIGRldmljZSBJRCBhbmQgc2xhdmUgZGV2aWNlIGxvY2F0aW9uLg0KPiANCj4NCj5QLjE1 OiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgdmFsaWRhdGlvbiByZXF1ZXN0IGZyb20gdGhl IG1hc3RlciB0bw0KPnRoZSBkYXRhYmFzZSB0byB2YWxpZGF0ZSBhIHNsYXZlIGRldmljZS4gVGhl IHZhbGlkYXRpb24gcmVxdWVzdCBNVVNUDQo+aW5jbHVkZSB0aGUgc2xhdmUgZGV2aWNlIElELg0K Pg0KPiANCj5QLjE2OiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgdmFsaWRhdGlvbiByZXNw b25zZSBmcm9tIHRoZSBkYXRhYmFzZSB0bw0KPnRoZSBtYXN0ZXIuIFRoZSB2YWxpZGF0aW9uIHJl c3BvbnNlIE1VU1QgaW5jbHVkZSBhIHJlc3BvbnNlIGNvZGUuDQo+DQo+IA0KPlAuMTc6IFRoZSBw cm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlc3BvbnNlIGZyb20gdGhlIG1h c3Rlcg0KPmRldmljZSB0byB0aGUgc2xhdmUgZGV2aWNlLiBUaGUgY2hhbm5lbCBxdWVyeSByZXNw b25zZSBtZXNzYWdlIE1VU1QNCj5pbmNsdWRlIHBhcmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9j YWwgcmVndWxhdG9yeSByZXF1aXJlbWVudCwgaW5jbHVkaW5nDQo+YSByZXNwb25zZSBjb2RlIGFu ZCBzdWZmaWNpZW50IGluZm9ybWF0aW9uIHRvIGRlY29kZSBhbiBlbmFibGluZyBzaWduYWwuDQo+ IA0KPg0KPlAuMTg6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYW4gZW5hYmxpbmcgc2lnbmFs IHNlbnQgZnJvbSB0aGUgbWFzdGVyIHRvDQo+dGhlIHNsYXZlLiBUaGlzIHNpZ25hbCBNVVNUIGFs bG93IHRoZSBzbGF2ZSBkZXZpY2UgdG8gdmFsaWRhdGUgdGhhdCBhDQo+cHJldmlvdXNseSByZWNl aXZlZCBhdmFpbGFibGUgY2hhbm5lbCBsaXN0IGlzIHN0aWxsIHZhbGlkIG9yIG5vdC4gVGhpcw0K PnNpZ25hbCBNVVNUIGJlIGVuY29kZWQgdG8gYWxsb3cgdGhlIHNsYXZlIGRldmljZSB0byBkZXRl cm1pbmUgdGhlIGlkZW50aXR5DQo+aWYgdGhlIHNlbmRpbmcgbWFzdGVyIGRldmljZS4NCj4gDQo+ IA0KPg0KPlAuMTk6IFRoZSBwcm90b2NvbCBiZXR3ZWVuIHRoZSBtYXN0ZXIgZGV2aWNlIGFuZCB0 aGUgZGF0YWJhc2UgTVVTVCBzdXBwb3J0DQo+dGhlIGNhcGFiaWxpdHkgdG8gY2hhbmdlIGNoYW5u ZWwgYXZhaWxhYmlsaXR5IGxpc3RzIG9uIHNob3J0IG5vdGljZS4NCj4NCj4NCj4gDQo+PEVkLiBO b3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIG1vYmlsaXR5IHVzZSBjYXNlPC9FZC4gTm90ZT4N Cj5QLjIwOiBUaGUgcHJvdG9jb2wgYmV0d2VlbiB0aGUgbWFzdGVyIGRldmljZSBhbmQgdGhlIGRh dGFiYXNlIE1VU1Qgc3VwcG9ydA0KPmEgY2hhbm5lbCBhdmFpbGFiaWxpdHkgcmVxdWVzdCB3aGlj aCBzcGVjaWZpZXMgYSBnZW9ncmFwaGljIGxvY2F0aW9uIGFzIGFuDQo+YXJlYSBhcyB3ZWxsIGFz IGEgcG9pbnQuDQo+DQo+DQo+DQo+IA0KPiANCj5PLiBPcGVyYXRpb25hbCBSZXF1aXJlbWVudHM6 DQo+IA0KPg0KPjxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBkaXNjb3ZlcnkgZnVu Y3Rpb248L0VkLiBOb3RlPg0KPg0KPk8uMTogVGhlIGRhdGFiYXNlIGFuZCB0aGUgbWFzdGVyIGRl dmljZSBNVVNUIGJlIGNvbm5lY3RlZCB0byB0aGUgSW50ZXJuZXQuDQo+IA0KPg0KPk8uMjogIEEg bWFzdGVyIGRldmljZSBNVVNUIGJlIGFibGUgdG8gZGV0ZXJtaW5lIGl0cyBsb2NhdGlvbiBpbmNs dWRpbmcNCj51bmNlcnRhaW50eSBhbmQgY29uZmlkZW5jZSBsZXZlbC4gQSBmaXhlZCBtYXN0ZXIg ZGV2aWNlIE1BWSB1c2UgYSBsb2NhdGlvbg0KPnByb2dyYW1tZWQgYXQgaW5zdGFsbGF0aW9uIG9y IGhhdmUgdGhlIGNhcGFiaWxpdHkgZGV0ZXJtaW5lIGl0cyBsb2NhdGlvbg0KPnRvIHRoZSByZXF1 aXJlZCBhY2N1cmFjeS4gQSBtb2JpbGUgbWFzdGVyIGRldmljZSBNVVNUIGhhdmUgdGhlIGNhcGFi aWxpdHkNCj50byBkZXRlcm1pbmUgaXRzIGxvY2F0aW9uIHRvIHRoZSByZXF1aXJlZCBhY2N1cmFj eS4NCj4NCj4gDQo+Ty4zOiBUaGUgbWFzdGVyIGRldmljZSBNVVNUIGlkZW50aWZ5IGEgZGF0YWJh c2UgZm9yIHVzZS4gVGhlIG1hc3RlciBkZXZpY2UNCj5NQVkgc2VsZWN0IGEgZGF0YWJhc2UgZm9y IHNlcnZpY2UgYnkgZGlzY292ZXJ5IGF0IHJ1bnRpbWUgb3IgdGhlIG1hc3Rlcg0KPmRldmljZSBN QVkgc2VsZWN0IGEgZGF0YWJhc2UgZm9yIHNlcnZpY2UgYnkgbWVhbnMgb2YgYSBwcmUtcHJvZ3Jh bW1lZCBVUkkNCj5hZGRyZXNzLg0KPg0KPiANCj5PLjQ6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1Qg aW1wbGVtZW50IGF0IGxlYXN0IG9uZSBjb25uZWN0aW9uIG1ldGhvZCB0bw0KPmFjY2VzcyB0aGUg ZGF0YWJhc2UuIFRoZSBtYXN0ZXIgZGV2aWNlIE1BWSBjb250YWN0IGEgZGF0YWJhc2UgZGlyZWN0 bHkgZm9yDQo+c2VydmljZSAoZS5nLiBhcyBkZWZpbmVkIGJ5IEZDQykgb3IgdGhlIG1hc3RlciBk ZXZpY2UgTUFZIGNvbnRhY3QgYQ0KPmxpc3Rpbmcgc2VydmVyIGZpcnN0IGZvbGxvd2VkIGJ5IGNv bnRhY3QgdG8gYSBkYXRhYmFzZSAoZS5nLiBBcyBkZWZpbmVkIGJ5DQo+T2Zjb20pLg0KPiANCj4N Cj5PLjU6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1Qgb2J0YWluIGFuIGluZGljYXRpb24gdGhlIHJl Z3VsYXRvcnkgZG9tYWluDQo+Z292ZXJuaW5nIG9wZXJhdGlvbiBhdCBpdHMgY3VycmVudCBsb2Nh dGlvbiwgaS5lLiB0aGUgbWFzdGVyIGRldmljZSBNVVNUDQo+a25vdyBpZiBpdCBvcGVyYXRlcyB1 bmRlciByZWd1bGF0aW9ucyBmcm9tIEZDQywgT2Zjb20sIGV0Y8WgDQo+IA0KPiANCj4NCj4NCj48 RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gcmVnaXN0cmF0aW9uIGZ1bmN0aW9uPC9F ZC4gTm90ZT4NCj5PLjY6IFRoZSBtYXN0ZXIgZGV2aWNlIE1BWSByZWdpc3RlciB3aXRoIHRoZSBk YXRhYmFzZSBhY2NvcmRpbmcgdG8gbG9jYWwNCj5yZWd1bGF0b3J5IHBvbGljeS4gTm90IGFsbCBt YXN0ZXIgZGV2aWNlcyB3aWxsIGJlIHJlcXVpcmVkIHRvIHJlZ2lzdGVyLg0KPlNwZWNpZmljIGV2 ZW50cyB3aWxsIGluaXRpYXRlIHJlZ2lzdHJhdGlvbiwgdGhlc2UgZXZlbnRzIGFyZSBkZXRlcm1p bmVkIGJ5DQo+cmVndWxhdG9yIHBvbGljeSAoZS5nLiBhdCBwb3dlciB1cCwgYWZ0ZXIgbW92ZW1l bnQsIGV0Y8WgKS4NCj4gDQo+DQo+Ty43OiBUaGUgbWFzdGVyIGRldmljZSBNVVNUIHJlZ2lzdGVy IHdpdGggaXRzIG1vc3QgY3VycmVudCBhbmQgdXAtdG8tZGF0ZQ0KPmluZm9ybWF0aW9uLg0KPg0K PiANCj4gDQo+DQo+PEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGhvdHNwb3QgdXNl IGNhc2U8L0VkLiBOb3RlPg0KPk8uODogQSBtYXN0ZXIgZGV2aWNlIE1VU1QgcXVlcnkgdGhlIGRh dGFiYXNlIGZvciB0aGUgYXZhaWxhYmxlIGNoYW5uZWxzDQo+YmFzZWQgb24gaXRzIGN1cnJlbnQg bG9jYXRpb24gYmVmb3JlIHN0YXJ0aW5nIHJhZGlvIHRyYW5zbWlzc2lvbiBpbiB3aGl0ZQ0KPnNw YWNlLiBQYXJhbWV0ZXJzIHByb3ZpZGVkIHRvIHRoZSBkYXRhYmFzZSBNQVkgaW5jbHVkZSBkZXZp Y2UgbG9jYXRpb24sDQo+YWNjdXJhY3kgb2YgdGhlIGxvY2F0aW9uLCBhbnRlbm5hIGNoYXJhY3Rl cmlzdGljIGluZm9ybWF0aW9uLCBkZXZpY2UNCj5pZGVudGlmaWVyIG9mIGFueSBzbGF2ZSBkZXZp Y2UgcmVxdWVzdGluZyBjaGFubmVsIGluZm9ybWF0aW9uLg0KPiANCj4NCj5PLjk6IFRoZSBkYXRh YmFzZSBNVVNUIHJlc3BvbmQgdG8gYW4gYXZhaWxhYmxlIGNoYW5uZWwgbGlzdCByZXF1ZXN0IGZy b20NCj5hbiBhdXRoZW50aWNhdGVkIGFuZCBhdXRob3JpemVkIGRldmljZSBhbmQgTUFZIGFsc28g cHJvdmlkZSB0aW1lDQo+Y29uc3RyYWludHMsIG1heGltdW0gb3V0cHV0IHBvd2VyLCBzdGFydCBh bmQgc3RvcCBmcmVxdWVuY2llcyBmb3IgZWFjaA0KPmNoYW5uZWwgaW4gdGhlIGxpc3QgYW5kIGFu eSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBmb3Igc2Vuc2luZy4NCj4gDQo+DQo+Ty4xMDogQWZ0 ZXIgY29ubmVjdGluZyB0byBhIG1hc3RlciBkZXZpY2XCuXMgcmFkaW8gbmV0d29yayBhIHNsYXZl IGRldmljZQ0KPk1VU1QgcXVlcnkgdGhlIG1hc3RlciBkZXZpY2UgZm9yIGEgbGlzdCBvZiBhdmFp bGFibGUgY2hhbm5lbHMuIFRoZSBzbGF2ZQ0KPk1VU1QgaW5jbHVkZSBwYXJhbWV0ZXJzIHJlcXVp cmVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkgcG9saWN5LCBlLmcuIGRldmljZQ0KPklELCBkZXZpY2Ug bG9jYXRpb24uDQo+IA0KPg0KPk8uMTE6IEFjY29yZGluZyB0byBsb2NhbCByZWd1bGF0b3J5IHBv bGljeSwgdGhlIG1hc3RlciBkZXZpY2UgTUFZIHF1ZXJ5DQo+dGhlIGRhdGFiYXNlIHdpdGggcGFy YW1ldGVycyByZWNlaXZlZCBmcm9tIHRoZSBzbGF2ZSBkZXZpY2UuDQo+IA0KPg0KPk8uMTI6IFRo ZSBkYXRhYmFzZSBNVVNUIHJlc3BvbmQgdG8gYSBxdWVyeSBmcm9tIHRoZSBtYXN0ZXIgZGV2aWNl DQo+Y29udGFpbmluZyBwYXJhbWV0ZXJzIGZyb20gYSBzbGF2ZSBkZXZpY2UuDQo+IA0KPg0KPk8u MTM6IEFmdGVyIHRoZSBtYXN0ZXIgZGV2aWNlIGhhcyByZWNlaXZlZCBhIHJlc3BvbnNlIGZyb20g dGhlIGRhdGFiYXNlLA0KPnRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgcmVzcG9uZCB0byB0aGUgc2xh dmUgZGV2aWNlLiBJZiBhbGwgcmVndWxhdG9yeQ0KPnJlcXVpcmVtZW50cyBhcmUgbWV0IHRoZSBy ZXNwb25zZSB3aWxsIGNvbnRhaW4gYW4gYXZhaWxhYmxlIGNoYW5uZWwgbGlzdC4NCj5JZiByZWd1 bGF0b3J5IHJlcXVpcmVtZW50cyBhcmUgbm90IG1ldCwgdGhlIHJlc3BvbnNlIE1VU1QgY29udGFp biBhdCBsZWFzdA0KPmEgcmVzcG9uc2UgY29kZS4NCj4gDQo+DQo+Ty4xNDogSWYgYSBtYXN0ZXIg ZGV2aWNlIGhhcyBwcm92aWRlZCBhbiBhdmFpbGFibGUgY2hhbm5lbCBsaXN0IHRvIGEgc2xhdmUN Cj5kZXZpY2UgdGhlIG1hc3RlciBkZXZpY2UgTUFZIHNlbmQgYSBwZXJpb2RpYyBlbmFibGluZyBz aWduYWwgdG8gYWxsb3cgdGhlDQo+c2xhdmUgZGV2aWNlIHRvIGNvbmZpcm0gaXQgaXMgc3RpbGwg d2l0aGluIHJlY2VwdGlvbiByYW5nZSBvZiB0aGUgbWFzdGVyDQo+ZGV2aWNlLg0KPiANCj4NCj5P LjE1OiBUaGUgZW5hYmxpbmcgc2lnbmFsIE1VU1QgYmUgZW5jb2RlZCBzbyB0aGF0IHRoZSByZWNl aXZpbmcgc2xhdmUgY2FuDQo+ZGV0ZXJtaW5lIHRoZSBpZGVudGl0eSBvZiB0aGUgc2VuZGluZyBt YXN0ZXIuDQo+IA0KPg0KPk8uMTY6IFBlcmlvZGljYWxseSwgYXQgYW4gaW50ZXJ2YWwgYWNjb3Jk aW5nIHRvIGxvY2FsIHJlZ3VsYXRpb25zLCB0aGUNCj5zbGF2ZSBkZXZpY2UgTVVTVCBlaXRoZXIg cmVjZWl2ZSBhbmQgZW5hYmxpbmcgc2lnbmFsIG9yIE1VU1Qgc3VjY2Vzc2Z1bGx5DQo+cmVwZWF0 IHRoZSBjaGFubmVsIHJlcXVlc3QgcHJvY2VzcyBvciBNVVNUIGNlYXNlIHRyYW5zbWlzc2lvbiBv biB0aGUNCj5jaGFubmVsLg0KPiANCj4NCj5PLjE3OiBBIG1hc3RlciBkZXZpY2UgTVVTVCByZXBl YXQgdGhlIHF1ZXJ5IHRoZSBkYXRhYmFzZSBmb3IgdGhlIGF2YWlsYWJsZQ0KPmNoYW5uZWxzIGFz IG9mdGVuIGFzIHJlcXVpcmVkIGJ5IHRoZSByZWd1bGF0aW9uIChlZywgRkNDIHJlcXVpcmVzIG9u Y2UgcGVyDQo+ZGF5KSB0byB2ZXJpZnkgdGhhdCB0aGUgb3BlcmF0aW5nIGNoYW5uZWxzIGNvbnRp bnVlIHRvIHJlbWFpbiBhdmFpbGFibGUuDQo+IA0KPg0KPk8uMTg6IEEgbWFzdGVyIGRldmljZSB3 aGljaCBjaGFuZ2VzIGl0cyBsb2NhdGlvbiBtb3JlIHRoYW4gYSB0aHJlc2hvbGQNCj5kaXN0YW5j ZSBzcGVjaWZpZWQgYnkgbG9jYWwgcmVndWxhdG9yeSBwb2xpY3kgZHVyaW5nIGl0cyBvcGVyYXRp b24sIE1VU1QNCj5xdWVyeSB0aGUgZGF0YWJhc2UgZm9yIGF2YWlsYWJsZSBvcGVyYXRpbmcgY2hh bm5lbHMgZWFjaCB0aW1lIGl0IG1vdmVzDQo+bW9yZSB0aGFuIHRoZSB0aHJlc2hvbGQgZGlzdGFu Y2UgKGUuZy4sIEZDQyBzcGVjaWZpZXMgMTAwbSkgZnJvbSB0aGUNCj5sb2NhdGlvbiBpdCBwcmV2 aW91c2x5IG1hZGUgdGhlIHF1ZXJ5Lg0KPiANCj4NCj4NCj48RWQuIE5vdGU+cmVxdWlyZW1lbnRz IHJlbGF0ZWQgdG8gd3JhbiB1c2UgY2FzZTwvRWQuIE5vdGU+DQo+Ty4xOTogSWYgc2xhdmUgZGV2 aWNlcyBjaGFuZ2UgdGhlaXIgbG9jYXRpb24gZHVyaW5nIG9wZXJhdGlvbiBieSBtb3JlIHRoYW4N Cj5hIGxpbWl0IHNwZWNpZmllZCBieSB0aGUgbG9jYWwgcmVndWxhdG9yLCB0aGUgc2xhdmUgZGV2 aWNlIE1VU1QgcXVlcnkgdGhlDQo+bWFzdGVyIGRldmljZSBmb3IgYXZhaWxhYmxlIG9wZXJhdGlu ZyBjaGFubmVscy4NCj4gDQo+DQo+DQo+PEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRv IHJhcGlkIGRlcGxveWVkIG5ldHdvcmsgdXNlIGNhc2U8L0VkLg0KPk5vdGU+DQo+Ty4yMDogQWNj b3JkaW5nIHRvIGxvY2FsIHJlZ3VsYXRvciBwb2xpY3ksIGEgbWFzdGVyIGRldmljZSBtYXkgY29u dGFjdCBhDQo+ZGF0YWJhc2UgdmlhIHByb3h5IHNlcnZpY2Ugb2YgYW5vdGhlciBtYXN0ZXIgZGV2 aWNlLg0KPiANCj4NCj4NCj48RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gbW9iaWxp dHkgdXNlIGNhc2U8L0VkLiBOb3RlPg0KPk8uMjE6IEEgbWFzdGVyIGRldmljZSBNVVNUIGJlIGFi bGUgdG8gcXVlcnkgdGhlIHdoaXRlc3BhY2UgZGF0YWJhc2UgZm9yDQo+Y2hhbm5lbCBhdmFpbGFi aWxpdHkgaW5mb3JtYXRpb24gZm9yIGEgc3BlY2lmaWMgZXhwZWN0ZWQgY292ZXJhZ2UgYXJlYQ0K PmFyb3VuZCBpdHMgY3VycmVudCBsb2NhdGlvbi4NCj4gDQo+DQo+DQo+PEVkLiBOb3RlPnJlcXVp cmVtZW50cyByZWxhdGVkIHRvIHRocmVhdCBtb2RlbDwvRWQuIE5vdGU+DQo+Ty4yMjogQSBNYXN0 ZXIgZGV2aWNlIE1BWSBub3QgaW5jbHVkZSBpdHMgaWRlbnRpdHkgaW4NCj5tZXNzYWdlcyBzZW50 IHRvIHRoZSBkYXRhYmFzZSB3aGVuIG5vdCByZXF1aXJlZCBieSB0aGUgcmVndWxhdG9yeQ0KPiAN Cj4gDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj5wYXdzIG1haWxpbmcgbGlzdA0KPnBhd3NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg0K From scott.probasco@nokia.com Fri Feb 24 10:58:44 2012 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 BBFC721F87F9 for ; Fri, 24 Feb 2012 10:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[AWL=1.908, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lju4kxBWXiXU for ; Fri, 24 Feb 2012 10:58:43 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE2D21F87EA for ; Fri, 24 Feb 2012 10:58:42 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1OIwatS018933; Fri, 24 Feb 2012 20:58:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 20:58:39 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Fri, 24 Feb 2012 19:58:39 +0100 From: To: Thread-Topic: [paws] UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZIdjEAgAN/KwA= Date: Fri, 24 Feb 2012 18:58:38 +0000 Message-ID: In-Reply-To: <449B85CE-11EF-4C84-A0D5-67225BDB6F50@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.53.191] Content-Type: text/plain; charset="utf-8" Content-ID: <94CA8D245DDA4844AD2BCF02811FEC76@mgd.nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2012 18:58:39.0800 (UTC) FILETIME=[52102B80:01CCF326] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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, 24 Feb 2012 18:58:44 -0000 SGVsbG8gVGVjbywNCg0KU2luY2UgUEFXUyBpcyBhIGdsb2JhbCBzdGFuZGFyZCwgcmVnaXN0cmF0 aW9uIGZvciBhbGwgcmVndWxhdG9yeSBkb21haW5zDQptdXN0IGJlIHN1cHBvcnRlZC4gV2hpbGUg dGhlIEZDQyBkb2VzIHJlcXVpcmUgYWxsIG9mIHRoZSB2YXJpYWJsZXMgbGlzdGVkDQppbiBQLjEw LCBvdGhlciByZWd1bGF0b3J5IGRvbWFpbnMgbWF5IG5vdCByZXF1aXJlIGVhY2ggb2YgdGhvc2Ug dmFyaWFibGVzLg0KU28gZm9yIHJlcXVpcmVtZW50cyBvbiB0aGUgcHJvdG9jb2wsIHVzaW5nIE1B WSBlbmFibGVzIHRoZSBGQ0MgdG8gcmVxdWlyZQ0KdGhlc2UgdmFyaWFibGVzIHdoaWxlIGFsbG93 aW5nIG90aGVyIHJlZ3VsYXRvcnMgdG8gc2VsZWN0IGEgc3Vic2V0LCBvcg0KZXZlbiBkaWZmZXJl bnQsIHZhcmlhYmxlcy4NCg0KV2l0aCB0aGlzIGV4cGxhbmF0aW9uLCBhcmUgeW91IG9rYXkgd2l0 aCBNQVkgaW4gUC4xMD8NCg0KS2luZCBSZWdhcmRzLA0KU2NvdHQNCg0KDQoNCk9uIDIvMjIvMTIg MTozNCBBTSwgImV4dCBUZWNvIEJvb3QiIDx0ZWNvQGluZi1uZXQubmw+IHdyb3RlOg0KDQo+U2Nv dHQsIFJheSwNCj4NCj5UaGUgUC4qIGFyZSBtb3N0bHkgTVVTVCByZXF1aXJlbWVudHMgZm9yIHRo ZSBwcm90b2NvbC4gVGhhdCdzIGZpbmUuDQo+RXhjZXB0IFAuMTAsIHRoaXMgaXMgYSBNQVkgb3Bl cmF0aW9uYWwgcmVxdWlyZW1lbnQuIFRoZSBwcm90b2NvbA0KPk1VU1Qgc3VwcG9ydCBpdC4NCj4N Cj5JJ20gZmluZSB3aXRoIHRoZSByZXN0IG9mIGl0Lg0KPg0KPklzIG5vdGVkIHNvbWV3aGVyZSB0 aGF0IHdlIChJRVRGKSBkbyBvdXIgYmVzdCB0byBzdXBwb3J0IGFzIG1hbnkNCj5yZWd1bGF0b3Ig cnVsZXMgYXMgcG9zc2libGUsIGFuZCBsZWF2ZSBzZXR0aW5nIHVwIHJlcXVpcmVtZW50cyBmb3IN Cj5hY3R1YWwgZGVwbG95bWVudCB1cCB0byB0aGUgbWFuZGF0ZWQgYXV0aG9yaXRpZXM/IFRoaXMg bWFrZXMgdGhlDQo+Ty4qIHJlcXVpcmVtZW50cyBpbmZvcm1hdGlvbmFsLg0KPg0KPlRoYW5rcywg VGVjbw0KPg0KPg0KPk9wIDIyIGZlYi4gMjAxMiwgb20gMDA6NTMgaGVlZnQgPHNjb3R0LnByb2Jh c2NvQG5va2lhLmNvbT4NCj48c2NvdHQucHJvYmFzY29Abm9raWEuY29tPiBoZXQgdm9sZ2VuZGUg Z2VzY2hyZXZlbjoNCj4NCj4+IEhlbGxvIEFsbCwNCj4+IA0KPj4gSSBoYXZlIHJldmlzZWQgU2Vj dGlvbiA2IG9mIHRoZSBJLUQgd2hpY2ggZGVzY3JpYmVzIHRoZSBEYXRhIE1vZGVsDQo+PiBSZXF1 aXJlbWVudHMsIFByb3RvY29sIFJlcXVpcmVtZW50cyBhbmQgT3BlcmF0aW9uYWwgUmVxdWlyZW1l bnRzLiBUaGlzDQo+PiBpbmNsdWRlcyB0aGUgcmVxdWlyZW1lbnRzIGZyb20gdGhlIHRocmVhdCBt b2RlbA0KPj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wYXdzL2N1cnJl bnQvbXNnMDA3NzEuaHRtbCkuDQo+PiANCj4+IFRoZSByZXF1aXJlbWVudHMgYXJlIG9yZGVyZWQg InRvcCBkb3duIiB0byBmb2xsb3cgdGhlIHByZXZpb3VzIHNlY3Rpb25zDQo+Pm9mDQo+PiB0aGUg ZG9jdW1lbnQ6IHJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20gZGlzY292ZXJ5IGFyZSBmb2xsb3dl ZCBieQ0KPj4gcmVxdWlyZW1lbnRzIGRlcml2ZWQgZnJvbSByZWdpc3RyYXRpb24gYXJlIGZvbGxv d2VkIGJ5IHJlcXVpcmVtZW50cw0KPj4gZGVyaXZlZCBmcm9tIGhvdHNwb3QsIGV0Yy4uLg0KPj4g DQo+PiBQbGVhc2UgcmV2aWV3IHRoZSBwcm9wb3NlZCB0ZXh0LCB3ZSBob3BlIHRvIGhhdmUgeW91 ciBjb21tZW50cyBieSBGZWINCj4+Mjh0aC4NCj4+IA0KPj4gS2luZCBSZWdhcmRzLA0KPj4gDQo+ PiBSYWogJiBTY290dA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBELiBEYXRhIE1vZGVsIFJlcXVp cmVtZW50czoNCj4+IA0KPj4gDQo+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8g ZGlzY292ZXJ5IGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+IEQuMTogVGhlIERhdGEgTW9kZWwgTVVT VCBzdXBwb3J0IHNwZWNpZnlpbmcgdGhlIGxvY2F0aW9uIG9mIHRoZSBXU0QsIHRoZQ0KPj4gdW5j ZXJ0YWludHkgaW4gbWV0ZXJzLCB0aGUgaGVpZ2h0ICYgaXRzIHVuY2VydGFpbnR5LCBhbmQgY29u ZmlkZW5jZSBpbg0KPj4gcGVyY2VudGFnZSBmb3IgdGhlIGxvY2F0aW9uIGRldGVybWluYXRpb24u IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydA0KPj4gYm90aCBOb3J0aCBBbWVyaWNhbiBEYXR1 bSBvZiAxOTgzIGFuZCBXR1M4NC4NCj4+IA0KPj4gDQo+PiBELjI6IFRoZSBEYXRhIE1vZGVsIE1V U1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIHRoZSBVUkkgYWRkcmVzcyBvZiBhIHdoaXRlDQo+PiBzcGFj ZSBkYXRhYmFzZS4NCj4+IA0KPj4gDQo+PiBELjM6IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9y dCBzcGVjaWZ5aW5nIHRoZSBVUkkgYWRkcmVzcyBvZiBhDQo+Pm5hdGlvbmFsDQo+PiBsaXN0aW5n IHNlcnZpY2UuDQo+PiANCj4+IA0KPj4gRC40OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQg c3BlY2lmeWluZyAgcmVndWxhdG9yeSBkb21haW4gYW5kIGl0cw0KPj4gY29ycmVzcG9uZGluZyBk YXRhIHJlcXVpcmVtZW50cy4NCj4+IA0KPj4gDQo+PiANCj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVu dHMgcmVsYXRlZCB0byByZWdpc3RyYXRpb24gZnVuY3Rpb248L0VkLiBOb3RlPg0KPj4gRC41OiBU aGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhbiBJRCBvZiB0aGUgdHJhbnNt aXR0ZXINCj4+IGRldmljZS4gVGhpcyBJRCB3b3VsZCBjb250YWluIHRoZSBJRCBvZiB0aGUgdHJh bnNtaXR0ZXIgZGV2aWNlIHRoYXQgaGFzDQo+PiBiZWVuIGNlcnRpZmllZCBieSBhIHJlZ3VsYXRv cnkgYm9keSBmb3IgaXRzIHJlZ3VsYXRvcnkgZG9tYWluLiBUaGUgRGF0YQ0KPj4gTW9kZWwgTVVT VCBzdXBwb3J0IGEgZGV2aWNlIGNsYXNzLg0KPj4gDQo+PiANCj4+IA0KPj4gRC42OiBUaGUgRGF0 YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhIG1hbnVmYWN0dXJlcsK5cyBzZXJpYWwN Cj4+bnVtYmVyDQo+PiBmb3IgYSBtYXN0ZXIgZGV2aWNlLg0KPj4gDQo+PiANCj4+IEQuNzogIFRo ZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIHRoZSBhbnRlbm5hIGFuZCByYWRp YXRpb24NCj4+IHJlbGF0ZWQgcGFyYW1ldGVycyBvZiB0aGUgZGV2aWNlLCBzdWNoIGFzOg0KPj4g DQo+PiAgIC0gYW50ZW5uYSBoZWlnaHQNCj4+IA0KPj4gICAtIGFudGVubmEgZ2Fpbg0KPj4gDQo+ PiAgIC0gbWF4aW11bSBvdXRwdXQgcG93ZXIsIEVJUlAgKGRCbSkNCj4+IA0KPj4gICAtIGFudGVu bmEgcmFkaWF0aW9uIHBhdHRlcm4gKGRpcmVjdGlvbmFsIGRlcGVuZGVuY2UNCj4+ICAgICBvZiB0 aGUgc3RyZW5ndGggb2YgdGhlIHJhZGlvIHNpZ25hbCBmcm9tIHRoZSBhbnRlbm5hKQ0KPj4gDQo+ PiAgIC0gc3BlY3RydW0gbWFzayB3aXRoIGxvd2VzdCBhbmQgaGlnaGVzdCBwb3NzaWJsZSBmcmVx dWVuY3kNCj4+IA0KPj4gICAtIHNwZWN0cnVtIG1hc2sgaW4gZEJyIGZyb20gcGVhayB0cmFuc21p dCBwb3dlciBpbiBFSVJQLA0KPj4gICAgIHdpdGggc3BlY2lmaWMgcG93ZXIgbGltaXQgYXQgYW55 IGZyZXF1ZW5jeSBsaW5lYXJseQ0KPj4gICAgIGludGVycG9sYXRlZCBiZXR3ZWVuIGFkamFjZW50 IHBvaW50cyBvZiB0aGUgc3BlY3RydW0gbWFzaw0KPj4gICAgIG1lYXN1cmVtZW50IHJlc29sdXRp b24gYmFuZHdpZHRoIGZvciBFSVJQIG1lYXN1cmVtZW50cy4NCj4+IA0KPj4gDQo+PiANCj4+IEQu ODogVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgb3duZXIgYW5kIG9wZXJh dG9yIGNvbnRhY3QNCj4+IGluZm9ybWF0aW9uIGZvciBhIHRyYW5zbWl0dGVyLiBUaGlzIGluY2x1 ZGVzIHRoZSBuYW1lIG9mIHRoZSB0cmFuc21pdHRlcg0KPj4gb3duZXIsIG5hbWUgb2YgdHJhbnNt aXR0ZXIgb3BlcmF0b3IsIHBvc3RhbCBhZGRyZXNzLCBlbWFpbCBhZGRyZXNzIGFuZA0KPj4gcGhv bmUgbnVtYmVyIG9mIHRoZSB0cmFuc21pdHRlciBvcGVyYXRvci4NCj4+IA0KPj4gDQo+PiANCj4+ IA0KPj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGhvdHNwb3QgdXNlIGNhc2U8 L0VkLiBOb3RlPg0KPj4gRC45OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWlu ZyBhIGxpc3Qgb2YgYXZhaWxhYmxlDQo+PmNoYW5uZWxzLg0KPj4gVGhlIERhdGEgTW9kZWwgTVVT VCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBjaGFubmVsDQo+ PiBudW1iZXJzIGFuZCBieSBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcy4gVGhlIERhdGEgTW9k ZWwgTVVTVCBzdXBwb3J0IGENCj4+IGNoYW5uZWwgYXZhaWxhYmlsaXR5IHNjaGVkdWxlIGFuZCBt YXhpbXVtIHBvd2VyIGxldmVsIGZvciBlYWNoIGNoYW5uZWwNCj4+aW4NCj4+IHRoZSBsaXN0Lg0K Pj4gDQo+PiANCj4+IA0KPj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIG1vYmls aXR5IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+IEQuMTA6ICBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1 cHBvcnQgc3BlY2lmeWluZyBjaGFubmVsIGF2YWlsYWJpbGl0eQ0KPj4gaW5mb3JtYXRpb24gZm9y IGEgc2luZ2xlIGxvY2F0aW9uIGFuZCBhbiBhcmVhIChlLmcuIGEgcG9seWdvbiBkZWZpbmVkIGJ5 DQo+PiBtdWx0aXBsZSBsb2NhdGlvbiBwb2ludHMgb3IgYSBnZW9tZXRyaWMgc2hhcGUgc3VjaCBh cyBhIGNpcmNsZSkuDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gUC4gUHJvdG9jb2wgUmVx dWlyZW1lbnRzOg0KPj4gDQo+PiANCj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0 byBkaXNjb3ZlcnkgZnVuY3Rpb248L0VkLiBOb3RlPg0KPj4gUC4xOiBUaGUgcHJvdG9jb2wgTVVT VCBwcm92aWRlIGEgbWVzc2FnZSBzZXF1ZW5jZSBmb3IgdGhlIG1hc3RlciBkZXZpY2UNCj4+dG8N Cj4+IGRpc2NvdmVyIGEgd2hpdGUgc3BhY2UgZGF0YWJhc2UgdGhhdCBwcm92aWRlcyBzZXJ2aWNl IGF0IGl0cyBjdXJyZW50DQo+PiBsb2NhdGlvbi4NCj4+IA0KPj4gDQo+PiBQLjI6IFRoZSBwcm90 b2NvbCBNVVNUIHN1cHBvcnQgYWNjZXNzIG9mIGEgZGF0YWJhc2UgZGlyZWN0bHkuIFRoZQ0KPj5w cm90b2NvbA0KPj4gTVVTVCBzdXBwb3J0IGFjY2VzcyBvZiBhIGRhdGFiYXNlIHVzaW5nIGEgbGlz dGluZyBhcHByb3ZlZCBieSBhIG5hdGlvbmFsDQo+PiByZWd1bGF0b3IuDQo+PiANCj4+IA0KPj4g UC4zOiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGRldGVybWluYXRpb24gb2YgcmVndWxhdG9y eSBkb21haW4NCj4+IGdvdmVybmluZyBpdHMgY3VycmVudCBsb2NhdGlvbi4NCj4+IA0KPj4gDQo+ PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gdGhyZWF0IG1vZGVsPC9FZC4gTm90 ZT4NCj4+IA0KPj4gDQo+PiBQLjQ6IFRoZSBwcm90b2NvbCBNVVNUIHByb3ZpZGUgdGhlIGFiaWxp dHkgZm9yIHRoZSBkYXRhYmFzZSB0bw0KPj4gYXV0aGVudGljYXRlIHRoZSBtYXN0ZXIgZGV2aWNl Lg0KPj4gDQo+PiANCj4+IFAuNTogVGhlIHByb3RvY29sIE1VU1QgcHJvdmlkZSB0aGUgYWJpbGl0 eSBmb3IgdGhlIG1hc3RlciBkZXZpY2UgdG8NCj4+dmVyaWZ5DQo+PiB0aGUgYXV0aGVudGljaXR5 IG9mIHRoZSBkYXRhYmFzZSB3aXRoIHdoaWNoIGl0IGlzIGludGVyYWN0aW5nLg0KPj4gDQo+PiAN Cj4+IFAuNjogVGhlIG1lc3NhZ2VzIHNlbnQgYnkgdGhlIG1hc3RlciBkZXZpY2UgdG8gdGhlIGRh dGFiYXNlIE1VU1QgYmUNCj4+IGludGVncml0eSBwcm90ZWN0ZWQuDQo+PiANCj4+IA0KPj4gUC43 OiBUaGUgbWVzc2FnZXMgc2VudCBieSB0aGUgZGF0YWJhc2UgdG8gdGhlIG1hc3RlciBkZXZpY2Ug TVVTVCBiZQ0KPj4gaW50ZWdyaXR5IHByb3RlY3RlZC4NCj4+IA0KPj4gDQo+PiBQLjg6IFRoZSBw cm90b2NvbCBNVVNUIHByb3ZpZGUgdGhlIGNhcGFiaWxpdHkgZm9yIG1lc3NhZ2VzIHNlbnQgYnkg dGhlDQo+PiBtYXN0ZXIgZGV2aWNlIGFuZCBkYXRhYmFzZSB0byBiZSBlbmNyeXB0ZWQuDQo+PiAN Cj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0 ZWQgdG8gcmVnaXN0cmF0aW9uIGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+IFAuOTogVGhlIHByb3Rv Y29sIE1VU1Qgc3VwcG9ydCB0aGUgbWFzdGVyIGRldmljZSByZWdpc3RlcmluZyB3aXRoIHRoZQ0K Pj4gZGF0YWJhc2UuDQo+PiANCj4+IA0KPj4gUC4xMDogVGhlIHJlZ2lzdHJhdGlvbiBzaWduYWxp bmcgTUFZIGluY2x1ZGUgdGhlIERldmljZSBJRCwNCj4+bWFudWZhY3R1cmVywrlzDQo+PiBzZXJp YWwgbnVtYmVyLCBkZXZpY2UgbG9jYXRpb24sIGRldmljZSBhbnRlbm5hIGNoYXJhY3RlcmlzdGlj DQo+PmluZm9ybWF0aW9uLA0KPj4gbmFtZSBvZiBpbmRpdmlkdWFsIG9yIGJ1c2luZXNzIHRoYXQg b3ducyB0aGUgZGV2aWNlLCBuYW1lLCBhZGRyZXNzLA0KPj5lbWFpbA0KPj4gYWRkcmVzcyBhbmQg cGhvbmUgbnVtYmVyIG9mIGEgY29udGFjdCBwZXJzb24gd2hvIGlzIHJlc3BvbnNpYmxlIGZvcg0K Pj5kZXZpY2UNCj4+IG9wZXJhdGlvbi4NCj4+IA0KPj4gDQo+PiBQLjExOiBUaGUgcHJvdG9jb2wg TVVTVCBzdXBwb3J0IGEgcmVnaXN0cmF0aW9uIGFja25vd2xlZGdlbWVudCBpbmNsdWRpbmcNCj4+ IGFwcHJvcHJpYXRlIHJlc3VsdCBjb2Rlcy4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gPEVkLiBO b3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGhvdHNwb3QgdXNlIGNhc2U8L0VkLiBOb3RlPg0K Pj4gUC4xMjogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgcXVlcnkgcmVxdWVz dCBmcm9tIHRoZSBtYXN0ZXINCj4+IGRldmljZSB0byB0aGUgZGF0YWJhc2UuIFRoZSBjaGFubmVs IHF1ZXJ5IHJlcXVlc3QgbWVzc2FnZSBNVVNUIGluY2x1ZGUNCj4+IHBhcmFtZXRlcnMgYXMgcmVx dWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4gVGhlc2UgcGFyYW1ldGVycw0K Pj4gTUFZIGluY2x1ZGUgZGV2aWNlIGxvY2F0aW9uLCBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcsK5 cyBzZXJpYWwgbnVtYmVyLA0KPj5hbmQNCj4+IGFudGVubmEgY2hhcmFjdGVyaXN0aWMgaW5mb3Jt YXRpb24uDQo+PiANCj4+IA0KPj4gUC4xMzogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNo YW5uZWwgcXVlcnkgcmVzcG9uc2UgZnJvbSB0aGUNCj4+ZGF0YWJhc2UNCj4+IHRvIHRoZSBtYXN0 ZXIgZGV2aWNlLiBUaGUgY2hhbm5lbCBxdWVyeSByZXNwb25zZSBtZXNzYWdlIE1VU1QgaW5jbHVk ZQ0KPj4gcGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVt ZW50LiBUaGVzZSBwYXJhbWV0ZXJzDQo+PiBNQVkgaW5jbHVkZSBhdmFpbGFibGUgY2hhbm5lbHMs IGR1cmF0aW9uIG9mIHRpbWUgZm9yIHRoZWlyIHVzZSwNCj4+YXNzb2NpYXRlZA0KPj4gbWF4aW11 bSBwb3dlciBsZXZlbHMsIGFueSBhZGRpdGlvbmFsIHNlbnNpbmcgcmVxdWlyZW1lbnRzLg0KPj4g DQo+PiANCj4+IFAuMTQ6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5 IHJlcXVlc3QgZnJvbSB0aGUgc2xhdmUNCj4+IGRldmljZSB0byB0aGUgbWFzdGVyIGRldmljZS4g VGhlIGNoYW5uZWwgcXVlcnkgcmVxdWVzdCBtZXNzYWdlIE1VU1QNCj4+IGluY2x1ZGUgcGFyYW1l dGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVtZW50LiBUaGVzZQ0K Pj4gcGFyYW1ldGVycyBNQVkgaW5jbHVkZSBkZXZpY2UgSUQgYW5kIHNsYXZlIGRldmljZSBsb2Nh dGlvbi4NCj4+IA0KPj4gDQo+PiBQLjE1OiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgdmFs aWRhdGlvbiByZXF1ZXN0IGZyb20gdGhlIG1hc3RlciB0bw0KPj4gdGhlIGRhdGFiYXNlIHRvIHZh bGlkYXRlIGEgc2xhdmUgZGV2aWNlLiBUaGUgdmFsaWRhdGlvbiByZXF1ZXN0IE1VU1QNCj4+IGlu Y2x1ZGUgdGhlIHNsYXZlIGRldmljZSBJRC4NCj4+IA0KPj4gDQo+PiBQLjE2OiBUaGUgcHJvdG9j b2wgTVVTVCBzdXBwb3J0IGEgdmFsaWRhdGlvbiByZXNwb25zZSBmcm9tIHRoZSBkYXRhYmFzZQ0K Pj50bw0KPj4gdGhlIG1hc3Rlci4gVGhlIHZhbGlkYXRpb24gcmVzcG9uc2UgTVVTVCBpbmNsdWRl IGEgcmVzcG9uc2UgY29kZS4NCj4+IA0KPj4gDQo+PiBQLjE3OiBUaGUgcHJvdG9jb2wgTVVTVCBz dXBwb3J0IGEgY2hhbm5lbCBxdWVyeSByZXNwb25zZSBmcm9tIHRoZSBtYXN0ZXINCj4+IGRldmlj ZSB0byB0aGUgc2xhdmUgZGV2aWNlLiBUaGUgY2hhbm5lbCBxdWVyeSByZXNwb25zZSBtZXNzYWdl IE1VU1QNCj4+IGluY2x1ZGUgcGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0 b3J5IHJlcXVpcmVtZW50LA0KPj5pbmNsdWRpbmcNCj4+IGEgcmVzcG9uc2UgY29kZSBhbmQgc3Vm ZmljaWVudCBpbmZvcm1hdGlvbiB0byBkZWNvZGUgYW4gZW5hYmxpbmcgc2lnbmFsLg0KPj4gDQo+ PiANCj4+IFAuMTg6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYW4gZW5hYmxpbmcgc2lnbmFs IHNlbnQgZnJvbSB0aGUgbWFzdGVyDQo+PnRvDQo+PiB0aGUgc2xhdmUuIFRoaXMgc2lnbmFsIE1V U1QgYWxsb3cgdGhlIHNsYXZlIGRldmljZSB0byB2YWxpZGF0ZSB0aGF0IGENCj4+IHByZXZpb3Vz bHkgcmVjZWl2ZWQgYXZhaWxhYmxlIGNoYW5uZWwgbGlzdCBpcyBzdGlsbCB2YWxpZCBvciBub3Qu IFRoaXMNCj4+IHNpZ25hbCBNVVNUIGJlIGVuY29kZWQgdG8gYWxsb3cgdGhlIHNsYXZlIGRldmlj ZSB0byBkZXRlcm1pbmUgdGhlDQo+PmlkZW50aXR5DQo+PiBpZiB0aGUgc2VuZGluZyBtYXN0ZXIg ZGV2aWNlLg0KPj4gDQo+PiANCj4+IA0KPj4gUC4xOTogVGhlIHByb3RvY29sIGJldHdlZW4gdGhl IG1hc3RlciBkZXZpY2UgYW5kIHRoZSBkYXRhYmFzZSBNVVNUDQo+PnN1cHBvcnQNCj4+IHRoZSBj YXBhYmlsaXR5IHRvIGNoYW5nZSBjaGFubmVsIGF2YWlsYWJpbGl0eSBsaXN0cyBvbiBzaG9ydCBu b3RpY2UuDQo+PiANCj4+IA0KPj4gDQo+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQg dG8gbW9iaWxpdHkgdXNlIGNhc2U8L0VkLiBOb3RlPg0KPj4gUC4yMDogVGhlIHByb3RvY29sIGJl dHdlZW4gdGhlIG1hc3RlciBkZXZpY2UgYW5kIHRoZSBkYXRhYmFzZSBNVVNUDQo+PnN1cHBvcnQN Cj4+IGEgY2hhbm5lbCBhdmFpbGFiaWxpdHkgcmVxdWVzdCB3aGljaCBzcGVjaWZpZXMgYSBnZW9n cmFwaGljIGxvY2F0aW9uIGFzDQo+PmFuDQo+PiBhcmVhIGFzIHdlbGwgYXMgYSBwb2ludC4NCj4+ IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiBPLiBPcGVyYXRpb25hbCBSZXF1aXJlbWVudHM6DQo+ PiANCj4+IA0KPj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGRpc2NvdmVyeSBm dW5jdGlvbjwvRWQuIE5vdGU+DQo+PiANCj4+IE8uMTogVGhlIGRhdGFiYXNlIGFuZCB0aGUgbWFz dGVyIGRldmljZSBNVVNUIGJlIGNvbm5lY3RlZCB0byB0aGUNCj4+SW50ZXJuZXQuDQo+PiANCj4+ IA0KPj4gTy4yOiAgQSBtYXN0ZXIgZGV2aWNlIE1VU1QgYmUgYWJsZSB0byBkZXRlcm1pbmUgaXRz IGxvY2F0aW9uIGluY2x1ZGluZw0KPj4gdW5jZXJ0YWludHkgYW5kIGNvbmZpZGVuY2UgbGV2ZWwu IEEgZml4ZWQgbWFzdGVyIGRldmljZSBNQVkgdXNlIGENCj4+bG9jYXRpb24NCj4+IHByb2dyYW1t ZWQgYXQgaW5zdGFsbGF0aW9uIG9yIGhhdmUgdGhlIGNhcGFiaWxpdHkgZGV0ZXJtaW5lIGl0cyBs b2NhdGlvbg0KPj4gdG8gdGhlIHJlcXVpcmVkIGFjY3VyYWN5LiBBIG1vYmlsZSBtYXN0ZXIgZGV2 aWNlIE1VU1QgaGF2ZSB0aGUNCj4+Y2FwYWJpbGl0eQ0KPj4gdG8gZGV0ZXJtaW5lIGl0cyBsb2Nh dGlvbiB0byB0aGUgcmVxdWlyZWQgYWNjdXJhY3kuDQo+PiANCj4+IA0KPj4gTy4zOiBUaGUgbWFz dGVyIGRldmljZSBNVVNUIGlkZW50aWZ5IGEgZGF0YWJhc2UgZm9yIHVzZS4gVGhlIG1hc3Rlcg0K Pj5kZXZpY2UNCj4+IE1BWSBzZWxlY3QgYSBkYXRhYmFzZSBmb3Igc2VydmljZSBieSBkaXNjb3Zl cnkgYXQgcnVudGltZSBvciB0aGUgbWFzdGVyDQo+PiBkZXZpY2UgTUFZIHNlbGVjdCBhIGRhdGFi YXNlIGZvciBzZXJ2aWNlIGJ5IG1lYW5zIG9mIGEgcHJlLXByb2dyYW1tZWQNCj4+VVJJDQo+PiBh ZGRyZXNzLg0KPj4gDQo+PiANCj4+IE8uNDogVGhlIG1hc3RlciBkZXZpY2UgTVVTVCBpbXBsZW1l bnQgYXQgbGVhc3Qgb25lIGNvbm5lY3Rpb24gbWV0aG9kIHRvDQo+PiBhY2Nlc3MgdGhlIGRhdGFi YXNlLiBUaGUgbWFzdGVyIGRldmljZSBNQVkgY29udGFjdCBhIGRhdGFiYXNlIGRpcmVjdGx5DQo+ PmZvcg0KPj4gc2VydmljZSAoZS5nLiBhcyBkZWZpbmVkIGJ5IEZDQykgb3IgdGhlIG1hc3RlciBk ZXZpY2UgTUFZIGNvbnRhY3QgYQ0KPj4gbGlzdGluZyBzZXJ2ZXIgZmlyc3QgZm9sbG93ZWQgYnkg Y29udGFjdCB0byBhIGRhdGFiYXNlIChlLmcuIEFzIGRlZmluZWQNCj4+YnkNCj4+IE9mY29tKS4N Cj4+IA0KPj4gDQo+PiBPLjU6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1Qgb2J0YWluIGFuIGluZGlj YXRpb24gdGhlIHJlZ3VsYXRvcnkgZG9tYWluDQo+PiBnb3Zlcm5pbmcgb3BlcmF0aW9uIGF0IGl0 cyBjdXJyZW50IGxvY2F0aW9uLCBpLmUuIHRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QNCj4+IGtub3cg aWYgaXQgb3BlcmF0ZXMgdW5kZXIgcmVndWxhdGlvbnMgZnJvbSBGQ0MsIE9mY29tLCBldGPFoA0K Pj4gDQo+PiANCj4+IA0KPj4gDQo+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8g cmVnaXN0cmF0aW9uIGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+IE8uNjogVGhlIG1hc3RlciBkZXZp Y2UgTUFZIHJlZ2lzdGVyIHdpdGggdGhlIGRhdGFiYXNlIGFjY29yZGluZyB0byBsb2NhbA0KPj4g cmVndWxhdG9yeSBwb2xpY3kuIE5vdCBhbGwgbWFzdGVyIGRldmljZXMgd2lsbCBiZSByZXF1aXJl ZCB0byByZWdpc3Rlci4NCj4+IFNwZWNpZmljIGV2ZW50cyB3aWxsIGluaXRpYXRlIHJlZ2lzdHJh dGlvbiwgdGhlc2UgZXZlbnRzIGFyZSBkZXRlcm1pbmVkDQo+PmJ5DQo+PiByZWd1bGF0b3IgcG9s aWN5IChlLmcuIGF0IHBvd2VyIHVwLCBhZnRlciBtb3ZlbWVudCwgZXRjxaApLg0KPj4gDQo+PiAN Cj4+IE8uNzogVGhlIG1hc3RlciBkZXZpY2UgTVVTVCByZWdpc3RlciB3aXRoIGl0cyBtb3N0IGN1 cnJlbnQgYW5kDQo+PnVwLXRvLWRhdGUNCj4+IGluZm9ybWF0aW9uLg0KPj4gDQo+PiANCj4+IA0K Pj4gDQo+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gaG90c3BvdCB1c2UgY2Fz ZTwvRWQuIE5vdGU+DQo+PiBPLjg6IEEgbWFzdGVyIGRldmljZSBNVVNUIHF1ZXJ5IHRoZSBkYXRh YmFzZSBmb3IgdGhlIGF2YWlsYWJsZSBjaGFubmVscw0KPj4gYmFzZWQgb24gaXRzIGN1cnJlbnQg bG9jYXRpb24gYmVmb3JlIHN0YXJ0aW5nIHJhZGlvIHRyYW5zbWlzc2lvbiBpbg0KPj53aGl0ZQ0K Pj4gc3BhY2UuIFBhcmFtZXRlcnMgcHJvdmlkZWQgdG8gdGhlIGRhdGFiYXNlIE1BWSBpbmNsdWRl IGRldmljZSBsb2NhdGlvbiwNCj4+IGFjY3VyYWN5IG9mIHRoZSBsb2NhdGlvbiwgYW50ZW5uYSBj aGFyYWN0ZXJpc3RpYyBpbmZvcm1hdGlvbiwgZGV2aWNlDQo+PiBpZGVudGlmaWVyIG9mIGFueSBz bGF2ZSBkZXZpY2UgcmVxdWVzdGluZyBjaGFubmVsIGluZm9ybWF0aW9uLg0KPj4gDQo+PiANCj4+ IE8uOTogVGhlIGRhdGFiYXNlIE1VU1QgcmVzcG9uZCB0byBhbiBhdmFpbGFibGUgY2hhbm5lbCBs aXN0IHJlcXVlc3QgZnJvbQ0KPj4gYW4gYXV0aGVudGljYXRlZCBhbmQgYXV0aG9yaXplZCBkZXZp Y2UgYW5kIE1BWSBhbHNvIHByb3ZpZGUgdGltZQ0KPj4gY29uc3RyYWludHMsIG1heGltdW0gb3V0 cHV0IHBvd2VyLCBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcyBmb3IgZWFjaA0KPj4gY2hhbm5l bCBpbiB0aGUgbGlzdCBhbmQgYW55IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIGZvciBzZW5zaW5n Lg0KPj4gDQo+PiANCj4+IE8uMTA6IEFmdGVyIGNvbm5lY3RpbmcgdG8gYSBtYXN0ZXIgZGV2aWNl wrlzIHJhZGlvIG5ldHdvcmsgYSBzbGF2ZSBkZXZpY2UNCj4+IE1VU1QgcXVlcnkgdGhlIG1hc3Rl ciBkZXZpY2UgZm9yIGEgbGlzdCBvZiBhdmFpbGFibGUgY2hhbm5lbHMuIFRoZSBzbGF2ZQ0KPj4g TVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSBwb2xp Y3ksIGUuZy4gZGV2aWNlDQo+PiBJRCwgZGV2aWNlIGxvY2F0aW9uLg0KPj4gDQo+PiANCj4+IE8u MTE6IEFjY29yZGluZyB0byBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgdGhlIG1hc3RlciBkZXZp Y2UgTUFZIHF1ZXJ5DQo+PiB0aGUgZGF0YWJhc2Ugd2l0aCBwYXJhbWV0ZXJzIHJlY2VpdmVkIGZy b20gdGhlIHNsYXZlIGRldmljZS4NCj4+IA0KPj4gDQo+PiBPLjEyOiBUaGUgZGF0YWJhc2UgTVVT VCByZXNwb25kIHRvIGEgcXVlcnkgZnJvbSB0aGUgbWFzdGVyIGRldmljZQ0KPj4gY29udGFpbmlu ZyBwYXJhbWV0ZXJzIGZyb20gYSBzbGF2ZSBkZXZpY2UuDQo+PiANCj4+IA0KPj4gTy4xMzogQWZ0 ZXIgdGhlIG1hc3RlciBkZXZpY2UgaGFzIHJlY2VpdmVkIGEgcmVzcG9uc2UgZnJvbSB0aGUgZGF0 YWJhc2UsDQo+PiB0aGUgbWFzdGVyIGRldmljZSBNVVNUIHJlc3BvbmQgdG8gdGhlIHNsYXZlIGRl dmljZS4gSWYgYWxsIHJlZ3VsYXRvcnkNCj4+IHJlcXVpcmVtZW50cyBhcmUgbWV0IHRoZSByZXNw b25zZSB3aWxsIGNvbnRhaW4gYW4gYXZhaWxhYmxlIGNoYW5uZWwNCj4+bGlzdC4NCj4+IElmIHJl Z3VsYXRvcnkgcmVxdWlyZW1lbnRzIGFyZSBub3QgbWV0LCB0aGUgcmVzcG9uc2UgTVVTVCBjb250 YWluIGF0DQo+PmxlYXN0DQo+PiBhIHJlc3BvbnNlIGNvZGUuDQo+PiANCj4+IA0KPj4gTy4xNDog SWYgYSBtYXN0ZXIgZGV2aWNlIGhhcyBwcm92aWRlZCBhbiBhdmFpbGFibGUgY2hhbm5lbCBsaXN0 IHRvIGENCj4+c2xhdmUNCj4+IGRldmljZSB0aGUgbWFzdGVyIGRldmljZSBNQVkgc2VuZCBhIHBl cmlvZGljIGVuYWJsaW5nIHNpZ25hbCB0byBhbGxvdw0KPj50aGUNCj4+IHNsYXZlIGRldmljZSB0 byBjb25maXJtIGl0IGlzIHN0aWxsIHdpdGhpbiByZWNlcHRpb24gcmFuZ2Ugb2YgdGhlIG1hc3Rl cg0KPj4gZGV2aWNlLg0KPj4gDQo+PiANCj4+IE8uMTU6IFRoZSBlbmFibGluZyBzaWduYWwgTVVT VCBiZSBlbmNvZGVkIHNvIHRoYXQgdGhlIHJlY2VpdmluZyBzbGF2ZQ0KPj5jYW4NCj4+IGRldGVy bWluZSB0aGUgaWRlbnRpdHkgb2YgdGhlIHNlbmRpbmcgbWFzdGVyLg0KPj4gDQo+PiANCj4+IE8u MTY6IFBlcmlvZGljYWxseSwgYXQgYW4gaW50ZXJ2YWwgYWNjb3JkaW5nIHRvIGxvY2FsIHJlZ3Vs YXRpb25zLCB0aGUNCj4+IHNsYXZlIGRldmljZSBNVVNUIGVpdGhlciByZWNlaXZlIGFuZCBlbmFi bGluZyBzaWduYWwgb3IgTVVTVA0KPj5zdWNjZXNzZnVsbHkNCj4+IHJlcGVhdCB0aGUgY2hhbm5l bCByZXF1ZXN0IHByb2Nlc3Mgb3IgTVVTVCBjZWFzZSB0cmFuc21pc3Npb24gb24gdGhlDQo+PiBj aGFubmVsLg0KPj4gDQo+PiANCj4+IE8uMTc6IEEgbWFzdGVyIGRldmljZSBNVVNUIHJlcGVhdCB0 aGUgcXVlcnkgdGhlIGRhdGFiYXNlIGZvciB0aGUNCj4+YXZhaWxhYmxlDQo+PiBjaGFubmVscyBh cyBvZnRlbiBhcyByZXF1aXJlZCBieSB0aGUgcmVndWxhdGlvbiAoZWcsIEZDQyByZXF1aXJlcyBv bmNlDQo+PnBlcg0KPj4gZGF5KSB0byB2ZXJpZnkgdGhhdCB0aGUgb3BlcmF0aW5nIGNoYW5uZWxz IGNvbnRpbnVlIHRvIHJlbWFpbiBhdmFpbGFibGUuDQo+PiANCj4+IA0KPj4gTy4xODogQSBtYXN0 ZXIgZGV2aWNlIHdoaWNoIGNoYW5nZXMgaXRzIGxvY2F0aW9uIG1vcmUgdGhhbiBhIHRocmVzaG9s ZA0KPj4gZGlzdGFuY2Ugc3BlY2lmaWVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkgcG9saWN5IGR1cmlu ZyBpdHMgb3BlcmF0aW9uLCBNVVNUDQo+PiBxdWVyeSB0aGUgZGF0YWJhc2UgZm9yIGF2YWlsYWJs ZSBvcGVyYXRpbmcgY2hhbm5lbHMgZWFjaCB0aW1lIGl0IG1vdmVzDQo+PiBtb3JlIHRoYW4gdGhl IHRocmVzaG9sZCBkaXN0YW5jZSAoZS5nLiwgRkNDIHNwZWNpZmllcyAxMDBtKSBmcm9tIHRoZQ0K Pj4gbG9jYXRpb24gaXQgcHJldmlvdXNseSBtYWRlIHRoZSBxdWVyeS4NCj4+IA0KPj4gDQo+PiAN Cj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byB3cmFuIHVzZSBjYXNlPC9FZC4g Tm90ZT4NCj4+IE8uMTk6IElmIHNsYXZlIGRldmljZXMgY2hhbmdlIHRoZWlyIGxvY2F0aW9uIGR1 cmluZyBvcGVyYXRpb24gYnkgbW9yZQ0KPj50aGFuDQo+PiBhIGxpbWl0IHNwZWNpZmllZCBieSB0 aGUgbG9jYWwgcmVndWxhdG9yLCB0aGUgc2xhdmUgZGV2aWNlIE1VU1QgcXVlcnkNCj4+dGhlDQo+ PiBtYXN0ZXIgZGV2aWNlIGZvciBhdmFpbGFibGUgb3BlcmF0aW5nIGNoYW5uZWxzLg0KPj4gDQo+ PiANCj4+IA0KPj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIHJhcGlkIGRlcGxv eWVkIG5ldHdvcmsgdXNlIGNhc2U8L0VkLg0KPj4gTm90ZT4NCj4+IE8uMjA6IEFjY29yZGluZyB0 byBsb2NhbCByZWd1bGF0b3IgcG9saWN5LCBhIG1hc3RlciBkZXZpY2UgbWF5IGNvbnRhY3QgYQ0K Pj4gZGF0YWJhc2UgdmlhIHByb3h5IHNlcnZpY2Ugb2YgYW5vdGhlciBtYXN0ZXIgZGV2aWNlLg0K Pj4gDQo+PiANCj4+IA0KPj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIG1vYmls aXR5IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+IE8uMjE6IEEgbWFzdGVyIGRldmljZSBNVVNUIGJl IGFibGUgdG8gcXVlcnkgdGhlIHdoaXRlc3BhY2UgZGF0YWJhc2UgZm9yDQo+PiBjaGFubmVsIGF2 YWlsYWJpbGl0eSBpbmZvcm1hdGlvbiBmb3IgYSBzcGVjaWZpYyBleHBlY3RlZCBjb3ZlcmFnZSBh cmVhDQo+PiBhcm91bmQgaXRzIGN1cnJlbnQgbG9jYXRpb24uDQo+PiANCj4+IA0KPj4gDQo+PiA8 RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gdGhyZWF0IG1vZGVsPC9FZC4gTm90ZT4N Cj4+IE8uMjI6IEEgTWFzdGVyIGRldmljZSBNQVkgbm90IGluY2x1ZGUgaXRzIGlkZW50aXR5IGlu DQo+PiBtZXNzYWdlcyBzZW50IHRvIHRoZSBkYXRhYmFzZSB3aGVuIG5vdCByZXF1aXJlZCBieSB0 aGUgcmVndWxhdG9yeQ0KPj4gDQo+PiANCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+PiBwYXdzQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4N Cg0K From gerald.chouinard@sympatico.ca Fri Feb 24 11:36:28 2012 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 4CCB721F86EB for ; Fri, 24 Feb 2012 11:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.523 X-Spam-Level: * X-Spam-Status: No, score=1.523 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdgUWGZxK4cl for ; Fri, 24 Feb 2012 11:36:24 -0800 (PST) Received: from blu0-omc3-s35.blu0.hotmail.com (blu0-omc3-s35.blu0.hotmail.com [65.55.116.110]) by ietfa.amsl.com (Postfix) with ESMTP id DEC4821F854C for ; Fri, 24 Feb 2012 11:36:22 -0800 (PST) Received: from BLU0-SMTP26 ([65.55.116.72]) by blu0-omc3-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 11:36:22 -0800 X-Originating-IP: [174.95.184.234] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([174.95.184.234]) by BLU0-SMTP26.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 11:36:20 -0800 From: Gerald Chouinard To: References: Date: Fri, 24 Feb 2012 14:36:22 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002D_01CCF301.AE62A900" X-Mailer: Microsoft Office Outlook 11 Thread-Index: AQHM8KvNja+uMv9rp0CzgALGeXgGBpZMdOJw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 24 Feb 2012 19:36:20.0942 (UTC) FILETIME=[95CF0EE0:01CCF32B] Cc: paws@ietf.org, 'apurva mody' Subject: Re: [paws] draft update to PAWS UC&R 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, 24 Feb 2012 19:36:28 -0000 ------=_NextPart_000_002D_01CCF301.AE62A900 Content-Type: multipart/alternative; boundary="----=_NextPart_001_002E_01CCF301.AE62A900" ------=_NextPart_001_002E_01CCF301.AE62A900 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Scott, Attached is a polished-up version of section 4.2.2 on "Wide-Area or Rural internet broadband access". Besides some minor typos, I have tried to clarify that items 1 to 6 are for the master/BS initial operation. I have added the concept of an optional verification of an available channel list that would apply over an area around the BS so that the CPEs, when they try to associate with the BS, would use a channel that in known not to interfere with incumbents at their location. Items 7 and 8 relate to the actions to be taken by the slave/user devices. Item 9 now deals with the process at the master/BS to add a new slave/user device to the network. Three different cases are covered for the master/BS to take a decision. Item 10 now deals with the 'steady state', i.e., the repeated query process at the master/BS to maintain the association with its slave/user devices. (It used to be covered in both items 9 and 10.) It now covers the cases where: a) the operating channel is available to all devices, thus no change; b) the operating channel is no longer available to the master/BS, in such case, it needs to alert its associated terminals and move to the new operating channel; c) if one of the slave/user devices can no longer operate on the current channel, then the master/BS may decide to either: c1) drop association with that terminal or, c2) move to another available channel in the list to accommodate that terminal as long as that channel is available to the master/BS and all other associated slave/user terminals. This should clarify the decisions that need to be made at the master/BS in all cases and make the text clearer. Respectfully submitted, Gerald _____ From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com] Sent: Tuesday, 21 February, 2012 10:17 To: Basavaraj.Patil@nokia.com; scott.probasco@nokia.com Subject: draft update to PAWS UC&R Hi, Attached is a draft version-03 update of the use case & requirements. This is not an official release; in order to avoid confusion I have removed the heading & some boiler-plate text at the beginning of this draft. In order to improve the quality of the draft, I am asking a few of the people who have been active in the discussions if you have some time to review this interim document for accuracy, to verify that it reflects the results of the email reflector discussion. Your review of the entire document is warmly welcomed, but if you are pressed for time, a focused review on those sections where you have provided comments is much appreciated. Note that Chapter 6 "Requirements" is not yet updated, I will be posting this section to the reflector for comments shortly. If you find any errors or omissions in implementation please let me know and I will correct those. If you find technical errors or corrections, first let's discuss how we can review those comments on the email reflector and reach consensus there. Then I can update the draft. Also attached for your reference is a spreadsheet that identifies the specific email discussions that I have implemented. There is some overlap in these threads due to the "opportunistic" nature of the email discussions. Kind Regards, Scott ------=_NextPart_001_002E_01CCF301.AE62A900 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott,

 

Attached is a polished-up version = of section 4.2.2 on “Wide-Area or Rural internet = broadband access”.

 

Besides some minor typos, I have tried to clarify that items 1 = to 6 are for the master/BS initial operation. I have added the concept of an = optional verification of an available channel list that would apply over an area = around the BS so that the CPEs, when they try to associate with the BS, would = use a channel that in known not to interfere with incumbents at their = location.

 

Items 7 and 8 relate to the actions to be taken by the = slave/user devices.

 

Item 9 now deals with the process at the master/BS to add a new slave/user device to the network. Three different cases are covered for = the master/BS to take a decision.

 

Item 10 now deals with the ‘steady state’, i.e., the repeated query process at the master/BS to maintain the association with = its slave/user devices. (It used to be covered in both items 9 and 10.) It = now covers the cases where: a) the operating channel is available to all = devices, thus no change; b) the operating channel is no longer available to the master/BS, in such case, it needs to alert its associated terminals and = move to the new operating channel; c) if one of the slave/user devices can no = longer operate on the current channel, then the master/BS may decide to either: c1) = drop association with that terminal or, c2) move to another available channel = in the list to accommodate that terminal as long as that channel is available = to the master/BS and all other associated slave/user = terminals.

 

This should clarify the decisions that need to be made at the = master/BS in all cases and make the text clearer.

 

Respectfully submitted,

 

Gerald

 

 

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]
Sent: Tuesday, 21 = February, 2012 10:17
To: = Basavaraj.Patil@nokia.com; scott.probasco@nokia.com
Subject: draft update to = PAWS UC&R

 

Hi,=

 

Attached is a = draft version-03 update of the use case & requirements. This is not an = official release; in order to avoid confusion I have removed the heading & = some boiler-plate text at the beginning of this draft. In order to improve = the quality of the draft, I am asking a few of the people who have been = active in the discussions if you have some time to review this interim document = for accuracy, to verify that it reflects the results of the email reflector discussion. Your review of the entire document is warmly welcomed, but = if you are pressed for time, a focused review on those sections where you have = provided comments is much appreciated. Note that Chapter 6 = "Requirements" is not yet updated, I will be posting this section to the reflector for = comments shortly. 

 

If you find = any errors or omissions in implementation please let me know and I will correct = those. If you find technical errors or corrections, first let's discuss how we can = review those comments on the email reflector and reach consensus there. Then I = can update the draft.

 

Also attached = for your reference is a spreadsheet that identifies the specific email = discussions that I have implemented. There is some overlap in these threads due to the "opportunistic" nature of the email = discussions.

 

Kind = Regards,

Scott

------=_NextPart_001_002E_01CCF301.AE62A900-- ------=_NextPart_000_002D_01CCF301.AE62A900 Content-Type: application/msword; name="UC&R-version-03a-GC.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="UC&R-version-03a-GC.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAWAAAAAAAAAAA EAAAWgAAAAEAAAD+////AAAAAFkAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAI2AJBAAA8BK/AAAAAAAAEAAAAAAABgAAJykAAA4AYmpiam2lbaUAAAAAAAAAAAAAAAAAAAAA AAAJBBYANEoAAA/PAAAPzwAAJyEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAO4DAAAAAAAA7gMAAO4D AAAAAAAA7gMAAAAAAADuAwAAAAAAAO4DAAAAAAAA7gMAABQAAAAAAAAAAAAAAAIEAAAAAAAACi4A AAAAAAAKLgAAAAAAAAouAAAAAAAACi4AADwAAABGLgAARAAAAAIEAAAAAAAA4TUAAD4BAACWLgAA AAAAAJYuAAAAAAAAli4AAAAAAACWLgAAAAAAAJYuAAAAAAAAli4AAAAAAACWLgAAAAAAAJYuAAAA AAAAMjUAAAIAAAA0NQAAAAAAADQ1AAAAAAAANDUAAAAAAAA0NQAAAAAAADQ1AAAAAAAANDUAACQA AAAfNwAAaAIAAIc5AABwAAAAWDUAABUAAAAAAAAAAAAAAAAAAAAAAAAA7gMAAAAAAACWLgAAAAAA AAAAAAAAAAAAAAAAAAAAAACWLgAAAAAAAJYuAAAAAAAAli4AAAAAAACWLgAAAAAAAFg1AAAAAAAA AAAAAAAAAADuAwAAAAAAAO4DAAAAAAAAli4AAAAAAAAAAAAAAAAAAJYuAAAAAAAAbTUAADgAAAAO MwAAAAAAAA4zAAAAAAAADjMAAAAAAACWLgAAvgAAAO4DAAAAAAAAli4AAAAAAADuAwAAAAAAAJYu AAAAAAAAMjUAAAAAAAAAAAAAAAAAAA4zAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAli4AAAAAAAAyNQAAAAAAAAAAAAAAAAAADjMAAAAAAAAAAAAA AAAAAA4zAAAAAAAA7gMAAAAAAADuAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADjMAAAAAAACWLgAAAAAAAIouAAAMAAAAMJstYiTz zAEAAAAAAAAAAAouAAAAAAAAVC8AAIIDAAAOMwAAAAAAAAAAAAAAAAAAMjUAAAAAAAClNQAAPAAA AOE1AAAAAAAADjMAAAAAAAD3OQAAAAAAANYyAAAuAAAA9zkAAAAAAAAOMwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAPc5AAAAAAAAAAAAAAAAAADuAwAAAAAAAA4zAAAkAgAAli4AAAAAAACWLgAAAAAAAA4z AAAAAAAAli4AAAAAAACWLgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAli4A AAAAAACWLgAAAAAAAJYuAAAAAAAAWDUAAAAAAABYNQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAABDMAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJYuAAAA AAAAli4AAAAAAACWLgAAAAAAAOE1AAAAAAAAli4AAAAAAACWLgAAAAAAAJYuAAAAAAAAli4AAAAA AAAAAAAAAAAAAAIEAAAAAAAAAgQAAAAAAAACBAAA5BMAAOYXAAAkFgAAAgQAAAAAAAACBAAAAAAA AAIEAAAAAAAA5hcAAAAAAAACBAAAAAAAAAIEAAAAAAAAAgQAAAAAAADuAwAAAAAAAO4DAAAAAAAA 7gMAAAAAAADuAwAAAAAAAO4DAAAAAAAA7gMAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1JbnRl cm5ldC1EcmFmdCAgICBQQVdTOiBQcm9ibGVtLCB1c2VzIGFuZCByZXF1aXJlbWVudHMgICAgIEZl YnJ1YXJ5IDIwMTINDQ0NDQ0NDQ0NDQ0NDQ0NDQ00LjIuMi4gIFdpZGUtQXJlYSBvciBSdXJhbCBp bnRlcm5ldCBicm9hZGJhbmQgYWNjZXNzDQ0gICBJbiB0aGlzIHVzZSBjYXNlLCBpbnRlcm5ldCBi cm9hZGJhbmQgYWNjZXNzIGlzIHByb3ZpZGVkIGFzIGEgV2lkZS0NICAgQXJlYSBOZXR3b3JrIChX QU4pIG9yIFdpcmVsZXNzIFJlZ2lvbmFsIEFyZWEgTmV0d29yayAoV1JBTikuICBBDSAgIHR5cGlj YWwgZGVwbG95bWVudCBzY2VuYXJpbyBpcyBhIHdpZGUgYXJlYSBvciBydXJhbCBhcmVhLCB3aGVy ZQ0gICBpbnRlcm5ldCBicm9hZGJhbmQgYWNjZXNzIGlzIHByb3ZpZGVkIHRvIGxvY2FsIGJ1c2lu ZXNzZXMgYW5kDSAgIHJlc2lkZW50cyBmcm9tIGEgbWFzdGVyIChpLmUuLCAgQlMpIGNvbm5lY3Rl ZCB0byB0aGUgaW50ZXJuZXQuICBUaGlzDSAgIGRlcGxveW1lbnQgc2NlbmFyaW8gaXMgdHlwaWNh bGx5IGNoYXJhY3Rlcml6ZWQgYnkgb25lIG9yIG1vcmUgZml4ZWQNICAgbWFzdGVyKHMpL0JTKHMp LCBjZWxscyB3aXRoIHJlbGF0aXZlbHkgbGFyZ2UgcmFkaXVzICh0ZW5zIG9mDSAgIGtpbG9tZXRl cnMsIHVwIHRvIDEwMCBrbSksIGFuZCBhIG51bWJlciBvZiBhdmFpbGFibGUgcmFkaW8gY2hhbm5l bHMuDSAgIFNvbWUgb2YgdGhlIG1hc3RlcnMvQlNzIG1heSBiZSBkZXBsb3llZCBhbmQgb3BlcmF0 ZWQgYnkgYSBzaW5nbGUNICAgZW50aXR5LCBpLmUuLCB0aGVyZSBjYW4gYmUgY2VudHJhbGl6ZWQg Y29vcmRpbmF0aW9uIGJldHdlZW4gdGhlc2UNICAgbWFzdGVycy9CU3MsIHdoZXJlYXMgb3RoZXIg bWFzdGVycy9CU3MgbWF5IGJlIGRlcGxveWVkIGFuZCBvcGVyYXRlZA0gICBieSBvcGVyYXRvcnMg Y29tcGV0aW5nIGZvciB0aGUgcmFkaW8gY2hhbm5lbHMgd2hlcmUgZGVjZW50cmFsaXplZA0gICBj b29yZGluYXRpb24gdXNpbmcgdGhlIGFpci1pbnRlcmZhY2Ugd291bGQgYmUgcmVxdWlyZWQuICBU aGUgQlMgaW4NICAgdGhpcyBzY2VuYXJpbyB1c2VzIGEgVEREIHJhZGlvIHRlY2hub2xvZ3kgYW5k IHRyYW5zbWl0cyBhdCBvciBiZWxvdyBhDSAgIHRyYW5zbWl0IHBvd2VyIChFSVJQKSBsaW1pdCBl c3RhYmxpc2hlZCBieSB0aGUgbG9jYWwgcmVndWxhdG9yLiAgRWFjaCBiYXNlDSAgIHN0YXRpb24g aGFzIGEgY29ubmVjdGlvbiB0byB0aGUgaW50ZXJuZXQgYW5kIG1heSBwcm92aWRlIGludGVybmV0 DSAgIGNvbm5lY3Rpdml0eSB0byBtdWx0aXBsZSBzbGF2ZXMvIGVuZC11c2VyIGRldmljZXMuICBF bmQtIHVzZXIgdGVybWluYWxzDSAgIG9yIGRldmljZXMgbWF5IGJlIGZpeGVkIG9yIHBvcnRhYmxl Lg0NICAgVGhlIGZpZ3VyZSBiZWxvdyBzaG93cyBhbiBleGFtcGxlIGRlcGxveW1lbnQgb2YgdGhp cyBzY2VuYXJpby4NDQ0NDQ0NDQ0NDQ0NDQ1Qcm9iYXNjbyAmIFBhdGlsICAgICAgICAgRXhwaXJl cyBBdWd1c3QgMTksIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAxNV0NDA1JbnRlcm5ldC1EcmFm dCAgICBQQVdTOiBQcm9ibGVtLCB1c2VzIGFuZCByZXF1aXJlbWVudHMgICAgIEZlYnJ1YXJ5IDIw MTINDQ0gICAgICAtLS0tLS0tDSAgICAgIHxTbGF2ZXxcICAgICAgICAgICAgICAgIFx8LyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLQ0gICAgICB8RGV2IDF8IChUREQgQWly SUYpICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHxEYXRhYmFzZXwNICAgICAg LS0tLS0tLSAgICAgICAgICBcICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAuLS0tLiAgIC8t LS0tLS0tLS0tDSAgICAgICAgIG8gICAgICAgICAgICAgIFwgICAgfC18LS0tLS0tLS0tfCAgICAg ICAgICAoICAgICApIC8NICAgICAgICAgbyAgICAgICAgICAgICAgICAgICB8ICAgTWFzdGVyICB8 ICAgICAgICAgLyAgICAgICBcDSAgICAgICAgIG8gICAgICAgICAgICAgICAvICAgfCAgIChCUykg ICAgfD09PT09PT09KCBJbnRlcm5ldCApDSAgICAgICAgIG8gICAgICAgICAgICAgIC8gICAgfC0t LS0tLS0tLS0tfCAgICAgICAgIFwgICAgICAgIC8NICAgICAgLS0tLS0tLSAgKFRERCBBaXJJRikg ICAgICAgICAgICAgICAgICAgICAgICAgICggICAgICApDSAgICAgIHxTbGF2ZXwgLyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKC0tLS0pDSAgICAgIHxEZXYgbnwNICAgICAg LS0tLS0tLQ0NDSAgICAgIEZpZ3VyZSA0OiBSdXJhbCBpbnRlcm5ldCBicm9hZGJhbmQgYWNjZXNz IHVzaW5nIFRWIHdoaXRlIHNwYWNlDSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHNw ZWN0cnVtDQ0gICBPbmNlIHRoZSBtYXN0ZXIvQlMgaGFzIGJlZW4gcHJvZmVzc2lvbmFsbHkgaW5z dGFsbGVkIGFuZCBjb25maWd1cmVkLA0gICBhIHNpbXBsaWZpZWQgcG93ZXIgdXAgYW5kIG9wZXJh dGlvbiBzY2VuYXJpbyB1dGlsaXppbmcgVFYgV2hpdGUgU3BhY2UNICAgdG8gcHJvdmlkZSBydXJh bCBpbnRlcm5ldCBicm9hZGJhbmQgYWNjZXNzIGNvbnNpc3RzIG9mIHRoZSBmb2xsb3dpbmcNICAg c3RlcHM6DQ0gICAxLiAgIFRoZSBtYXN0ZXIvQlMgcG93ZXJzIHVwOyBob3dldmVyIGl0cyBXUyBy YWRpbyBhbmQgYWxsIG90aGVyIFdTDSAgICAgICAgY2FwYWJsZSBkZXZpY2VzIHdpbGwgcG93ZXIg dXAgaW4gaWRsZS9saXN0ZW4gLW9ubHkgbW9kZSAoTm5vDSAgICAgICAgYWN0aXZlIHRyYW5zbWlz c2lvbnMgb24gdGhlIFdTIGZyZXF1ZW5jeSBiYW5kKS4NDSAgIDIuICAgVGhlIG1hc3Rlci9CUyBo YXMgaW50ZXJuZXQgY29ubmVjdGl2aXR5LCBkZXRlcm1pbmVzIGl0J3MNICAgICAgICBsb2NhdGlv biAoZWl0aGVyIGZyb20gbG9jYXRpb24gZGV0ZXJtaW5hdGlvbiBjYXBhYmlsaXR5IG9yIGZyb20g YQ0gICAgICAgIHNhdmVkIHZhbHVlIHRoYXQgd2FzIHNldCBkdXJpbmcgaW5zdGFsbGF0aW9uKSwg YW5kIGVzdGFibGlzaGVzIGENICAgICAgICBjb25uZWN0aW9uIHRvIGEgdHJ1c3RlZCB3aGl0ZSBz cGFjZSBkYXRhYmFzZSAoc2VlICJXaGl0ZSBzU3BhY2UNICAgICAgICBkYXRhYmFzZSBkaXNjb3Zl cnkiIGFib3ZlKS4NDSAgIDMuICAgVGhlIG1hc3Rlci9CUyByZWdpc3RlcnMgd2l0aCB0aGUgdHJ1 c3RlZCBkYXRhYmFzZSBzZXJ2aWNlIChzZWUNICAgICAgICBTZWN0aW9uIDQuMS4yKS4gIE1lYW53 aGlsZSB0aGUgREIgYWRtaW5pc3RyYXRvciBtYXkgYmUgcmVxdWlyZWQNICAgICAgICB0byBzdG9y ZSBhbmQgZm9yd2FyZCB0aGUgcmVnaXN0cmF0aW9uIGluZm9ybWF0aW9uIHRvIHRoZQ0gICAgICAg IHJlZ3VsYXRvcnkgYXV0aG9yaXR5LiAgSWYgYSB0cnVzdGVkIHdoaXRlIHNwYWNlIGRhdGFiYXNl DSAgICAgICAgYWRtaW5pc3RyYXRvciBzZXJ2aWNlIGlzIG5vdCBkaXNjb3ZlcmVkLCBmdXJ0aGVy IG9wZXJhdGlvbiBvZiB0aGUgV1JBTg0gICAgICAgIG1heSBiZSBhbGxvd2VkIGFjY29yZGluZyB0 byBsb2NhbCByZWd1bGF0b3IgcG9saWN5IChpbiB0aGlzIGNhc2UNICAgICAgICBvcGVyYXRpb24g b2YgdGhlIFdSQU4gaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIFBBV1MNICAgICAgICBwcm90 b2NvbCkuDQ0gICA0LiAgIEZvbGxvd2luZyB0aGUgc3VjY2Vzc2Z1bCByZWdpc3RyYXRpb24gcHJv Y2VzcywgdGhlIG1hc3Rlci9CUw0gICAgICAgIHdpbGwgc2VuZCBhIHF1ZXJ5IHRvIHRoZSB0cnVz dGVkIGRhdGFiYXNlIHJlcXVlc3RpbmcgYSBsaXN0IG9mDSAgICAgICAgYXZhaWxhYmxlIFdTIGNo YW5uZWxzIGJhc2VkIHVwb24gaXRzIGdlb2xvY2F0aW9uLiAgVGhlIGNvbXBsZXRlDSAgICAgICAg c2V0IG9mIHBhcmFtZXRlcnMgdG8gYmUgcHJvdmlkZWQgZnJvbSB0aGUgbWFzdGVyIHRvIHRoZSBk YXRhYmFzZQ0gICAgICAgIGlzIHNwZWNpZmllZCBieSB0aGUgbG9jYWwgcmVndWxhdG9yLiAgUGFy YW1ldGVycyBtYXkgaW5jbHVkZSBXU0QgaWRlbnRpZmllciwgDSAgICAgICAgbG9jYXRpb24sIGFj Y3VyYWN5IG9mIHRoYXQgbG9jYXRpb24sIGRldmljZSBhbnRlbm5hIGhlaWdodCwgZXRjLg0gICAg ICAgIGRldmljZSBpZGVudGlmaWVyIG9mIGEgc2xhdmUgZGV2aWNlIHJlcXVlc3RpbmcgY2hhbm5l bA0NDQ1Qcm9iYXNjbyAmIFBhdGlsICAgICAgICAgRXhwaXJlcyBBdWd1c3QgMTksIDIwMTIgICAg ICAgICAgICAgICBbUGFnZSAxNl0NDA1JbnRlcm5ldC1EcmFmdCAgICBQQVdTOiBQcm9ibGVtLCB1 c2VzIGFuZCByZXF1aXJlbWVudHMgICAgIEZlYnJ1YXJ5IDIwMTINDQ0gICAgICAgIGluZm9ybWF0 aW9uLg0NICAgNS4gICBJZiB0aGUgbWFzdGVyL0JTIGhhcyBiZWVuIHByZXZpb3VzbHkgYXV0aGVu dGljYXRlZCwgdGhlIGRhdGFiYXNlDSAgICAgICAgcmVzcG9uZHMgd2l0aCBhIGxpc3Qgb2YgYXZh aWxhYmxlIHdoaXRlIHNwYWNlIGNoYW5uZWxzIHRoYXQgbWF5DSAgICAgICAgYmUgdXNlZCBieSB0 aGUgbWFzdGVyL0JTIGFuZCBvcHRpb25hbGx5IGEgbWF4aW11bSB0cmFuc21pdCBwb3dlciAoRUlS UCkgZm9yIGVhY2gNICAgICAgICBjaGFubmVsLCBhIGR1cmF0aW9uIG9mIHRpbWUgdGhlIGNoYW5u ZWwgbWF5IGJlIHVzZWQgb3IgYQ0gICAgICAgIG5vdGlmaWNhdGlvbiBvZiBhbnkgYWRkaXRpb25h bCByZXF1aXJlbWVudCBmb3Igc2Vuc2luZy4NDSAgIDYuICAgT25jZSB0aGUgbWFzdGVyL0JTIGF1 dGhlbnRpY2F0ZXMgdGhlIFdTIGNoYW5uZWwgbGlzdCByZXNwb25zZQ0gICAgICAgIG1lc3NhZ2Ug ZnJvbSB0aGUgZGF0YWJhc2UsIHRoZSBtYXN0ZXIvQlMgc2VsZWN0cyBhbiBhdmFpbGFibGUgV1MN ICAgICAgICBjaGFubmVsKHMpIGZyb20gdGhlIGxpc3QuICBTdWNoIHNlbGVjdGlvbiBtYXkgYmUg aW1wcm92ZWQgYmFzZWQgb24gYSBzZXQgb2YgcXVlcmllcyB0byB0aGUgREIgaW52b2x2aW5nIGEg bnVtYmVyIG9mIGh5cG90aGV0aWNhbCBzbGF2ZSBvciB1c2VyIGRldmljZXMgbG9jYXRlZCBhdCB2 YXJpb3VzIGxvY2F0aW9ucyBvdmVyIHRoZSBleHBlY3RlZCBzZXJ2aWNlIGFyZWEgc28gdGhhdCB0 aGUgZmluYWwgaW50ZXJzZWN0aW9uIG9mIHRoZXNlIHJlc3VsdGluZyBXUyBjaGFubmVsIGxpc3Rz IGFsbG93cyB0aGUgc2VsZWN0aW9uIG9mIGEgY2hhbm5lbCB0aGF0IGlzIGxpa2VseSBhdmFpbGFi bGUgb3ZlciB0aGUgZW50aXJlIHNlcnZpY2UgYXJlYSB0byBhdm9pZCBwb3RlbnRpYWwgaW50ZXJm ZXJlbmNlIGF0IHRoZSB0aW1lIG9mIHNsYXZlL3VzZXIgdGVybWluYWwgYXNzb2NpYXRpb24uIFRo ZSBvcGVyYXRvciBtYXkgYWxzbyBkaXNhbGxvdyBzb21lDSAgICAgICAgY2hhbm5lbHMgZnJvbSB0 aGUgbGlzdCB0byBzdWl0IGxvY2FsIG5lZWRzIGlmIHJlcXVpcmVkLg0NICAgNy4gICBUaGUgc2xh dmUgb3IgdXNlciBkZXZpY2Ugc2NhbnMgdGhlIFRWIGJhbmRzIHRvIGxvY2F0ZSBhIFdSQU4NICAg ICAgICB0cmFuc21pc3Npb24sIGFuZCBhc3NvY2lhdGVzIHdpdGggdGhlIG1hc3Rlci9CUy4NDSAg IDguICAgVGhlIHNsYXZlL3VzZXIgZGV2aWNlIHByb3ZpZGVzIGl0cyBnZW9sb2NhdGlvbiB0byB0 aGUgQlMgd2hpY2gsDSAgICAgICAgaW4gdHVybiwgcXVlcmllcyB0aGUgZGF0YWJhc2UgZm9yIGEg bGlzdCBvZiBjaGFubmVscyBhdmFpbGFibGUNICAgICAgICBhdCB0aGUgc2xhdmWScycgZ2VvbG9j YXRpb24uDQ0gICA5LiAgIE9uY2UgdGhpcyBsaXN0IG9mIGF2YWlsYWJsZSBjaGFubmVscyBpcyBy ZWNlaXZlZCBmcm9tIHRoZQ0gICAgICAgIGRhdGFiYXNlIGJ5IHRoZSBtYXN0ZXIsIHRoZSBsYXR0 ZXIgd2lsbCBkZWNpZGUsIGJhc2VkIG9uIHRoZWlzDSAgICAgICAgbGlzdCBvZiBhdmFpbGFibGUg Y2hhbm5lbHMgYW5kIG9uIHRoZSBsaXN0cyBmb3IgYWxsIGl0cyBvdGhlciBhc3NvY2lhdGVkIHNs YXZlcy91c2VyIGRldmljZXMNICAgICAgICB3aGV0aGVyIGl0IHNob3VsZDogYSkgY29udGludWUg b3BlcmF0aW9uIG9uIGl0cyBjdXJyZW50IGNoYW5uZWwgaWYgdGhpcyBjaGFubmVsIGlzIGF2YWls YWJsZSB0byBhbGwgc2xhdmVzL3VzZXIgZGV2aWNlcywgYikgY29udGludWUgb3BlcmF0aW9uIG9u IGl0cyBjdXJyZW50IGNoYW5uZWwgYW5kIG5vdCBhbGxvdyBhc3NvY2lhdGlvbiB3aXRoIHRoZSBu ZXcgc2xhdmUvdXNlciBkZXZpY2UgaW4gY2FzZSB0aGlzIGNoYW5uZWwNICAgICAgICBpcyBub3Qg YXZhaWxhYmxlIGF0IGl0cyBsb2NhdGlvbiBvciBjKQ0gICAgICAgIGNoYW5nZSBjaGFubmVsIHRv IGFjY29tbW9kYXRlIHRoZSBuZXcgc2xhdmUgaW4gY2FzZSB0aGlzIGNoYW5uZWwNICAgICAgICBp cyBub3QgYXZhaWxhYmxlIGF0IGl0cyBsb2NhdGlvbi4gIEluIHRoZSBsYXR0ZXIgY2FzZSwgdFRo ZSBtYXN0ZXIgd2lsbCBub3RpZnkgYWxsDSAgICAgICAgaXRzIGFzc29jaWF0ZWQgc2xhdmVzL3Vz ZXIgZGV2aWNlcyBvZiB0aGUgbmV3IGNoYW5uZWwgdG8gd2hpY2ggdGhleSBoYXZlIHRvIG1vdmUg dG8NICAgICAgICBpZiBvcGVyYXRpb24gbmVlZHMgdG8gY2hhbmdlIGNoYW5uZWwuDQ0gICAxMC4g IFRoZSBtYXN0ZXIvQlMgbXVzdCBwZXJpb2RpY2FsbHkgcmVwZWF0IHRoZSBwcm9jZXNzIHRvIHJl cXVlc3QgYQ0gICAgICAgIGxpc3Qgb2YgYXZhaWxhYmxlIGNoYW5uZWxzIGZyb20gdGhlIGRhdGFi YXNlIGZvciBpdHNlbGYgYW5kIGZvciBhbGwgaXRzIGFzc29jaWF0ZWQgc2xhdmVzL3VzZXIgZGV2 aWNlcy4gIElmIHRoZSByZXNwb25zZSBmcm9tIHRoZSBkYXRhYmFzZSBpbmRpY2F0ZXMgdGhhdCB0 aGUgY2hhbm5lbCBiZWluZyB1c2VkIGJ5IHRoZSBtYXN0ZXIvQlMgaXMgbm8gbG9uZ2VyIGF2YWls YWJsZSBmb3IgaXRzIHVzZSwgdGhlDSAgICAgICAgbWFzdGVyL0JTIG11c3QgaW5kaWNhdGUgdGhl IG5ldyBvcGVyYXRpbmcgY2hhbm5lbCB0byBhbGwgaXRzIHNsYXZlL3VzZXIgdGVybWluYWxzLCBz dG9wIHRyYW5zbWl0dGluZyBvbiB0aGUgY3VycmVudCBjaGFubmVsIGFuZCBtb3ZlIHRvIHRoZSBu ZXcgb3BlcmF0aW5nIGNoYW5uZWwgaW1tZWRpYXRlbHkuIElmIHRoZSBjaGFubmVsIHRoYXQgdGhl YQ0gICAgICAgIHNsYXZlL3VzZXIgdGVybWluYWwgaXMgY3VycmVudGx5IHVzaW5nIGlzIG5vdCBs b25nZXIgaW5jbHVkZWQgaW4gdGhlIGxpc3Qgb2YgDSAgICAgICAgbG9jYWxseSBhdmFpbGFibGUg Y2hhbm5lbHMsIHRoZSBtYXN0ZXIgd2lsbCBtYXkgZWl0aGVyIGRyb3AgaXRzIGFzc29jaWF0aW9u DSAgICAgICAgd2l0aCB0aGUgc2xhdmUvdXNlciBkZXZpY2Ugc28gdGhhdCBpdCB0aGlzIGRldmlj ZSBjZWFzZXMgYWxsIG9wZXJhdGlvbiBvbg0gICAgICAgIGl0cyBjdXJyZW50IGNoYW5uZWwgb3Ig dGhlIG1hc3RlciBtYXkgZGVjaWRlIHRvIG1vdmUgdGhlIGVudGlyZSBjZWxsIHRvIGFub3RoZXIg Y2hhbm5lbCB0byBhY2NvbW1vZGF0ZSB0aGUgc2xhdmUvdXNlciB0ZXJtaW5hbCBhbmQgaW5kaWNh dGUgdGhlIG5ldyBvcGVyYXRpbmcgY2hhbm5lbCB0byBhbGwgaXRzIHNsYXZlL3VzZXIgZGV2aWNl cw0gICAgICAgIGJlZm9yZSBkcm9wcGluZyB0aGUgbGluayBpZiBhIGNoYW5nZSBoYXMgYmVlbiBk ZWNpZGVkLiAgVGhlDSAgICAgICAgc2xhdmUvdXNlciBkZXZpY2VzIG1heSB0aGVuIG1vdmUgdG8g dGhlIGluZGljYXRlZCBpZGVudGlmaWVkIG5ldyBvcGVyYXRpbmcgY2hhbm5lbCBpZiBzbw0gICAg ICAgIGluZGljYXRlZCBvciBzY2FuIGZvciBhbm90aGVyIFdSQU4gdHJhbnNtaXNzaW9uIG9uIGEg ZGlmZmVyZW50DSAgICAgICAgY2hhbm5lbC4NDSAgIDEwLiAgVGhlIG1hc3Rlci9CUyBtdXN0IHBl cmlvZGljYWxseSByZXBlYXQgdGhlIHByb2Nlc3MgdG8gcmVxdWVzdCBhDSAgICAgICAgY2hhbm5l bCBsaXN0IGZyb20gdGhlIGRhdGFiYXNlLCBzdGVwcyA0IHRocm91Z2ggNiBhYm92ZS4gIFRoZQ0g ICAgICAgIGZyZXF1ZW5jeSB0byByZXBlYXQgdGhlIHByb2Nlc3MgaXMgZGV0ZXJtaW5lZCBieSB0 aGUgbG9jYWwNICAgICAgICByZWd1bGF0b3IuICBJZiB0aGUgcmVzcG9uc2UgZnJvbSB0aGUgZGF0 YWJhc2UgaW5kaWNhdGVzIGENICAgICAgICBjaGFubmVsIGJlaW5nIHVzZWQgYnkgdGhlIG1hc3Rl ci9CUyBpcyBub3QgYXZhaWxhYmxlLCB0aGUNICAgICAgICBtYXN0ZXIvQlMgbXVzdCBzdG9wIHRy YW5zbWl0dGluZyBvbiB0aGF0IGNoYW5uZWwgaW1tZWRpYXRlbHkuDQ0gICAxMS4gIFRoZSBzbGF2 ZS8gb3IgdXNlciBkZXZpY2UgbXVzdCB0cmFuc21pdCBpdHMgbmV3IGdlb2dyYXBoaWMNICAgICAg ICBsb2NhdGlvbiBldmVyeSB0aW1lIGl0IGNoYW5nZXMgc28gdGhhdCB0aGUgcmVwZWF0ZWQgcHJv Y2Vzcw0gICAgICAgIGRlc2NyaWJlZCB1bmRlciBpdGVtIDEwIGZvciB0aGUgbWFzdGVyL0JTIGNh biByZWx5IG9uIHRoZSBtb3N0DSAgICAgICAgdXAtdG8tZGF0ZSBnZW9sb2NhdGlvbiBvZiB0aGUg c2xhdmUvIG9yIHVzZXIgZGV2aWNlLg0NDQ0NDQ1Qcm9iYXNjbyAmIFBhdGlsICAgICAgICAgRXhw aXJlcyBBdWd1c3QgMTksIDIwMTIgICAgICAgICAgICAgICBbUGFnZSAxN10NDQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAATAgAAE0IAABOCAAATwgAAFkI AABaCAAAWwgAAL4JAAC/CQAACAsAAAkLAAAkDAAAJQwAAEkMAABKDAAAawwAAGwMAABwDAAAcQwA AHIMAAANDQAADg0AAA8NAAAQDQAAFA0AACYNAAAnDQAAKA0AAI0SAACOEgAAjxIAAJoSAACbEgAA nBIAANQSAADVEgAAXxMAAGETAABuEwAAbxMAAPn18er18er54PnW+cz5zPnCzMLM+bj5qJL5uJL5 fHL5fHL5cvlo+WgAAAAAEwEIgQRIAQAFaNfCAqcWaCo5jAATAQiBBEgBAAVoNMMCpxZoYnFTACsA CIEVaLp+pQAWaLp+pQAXaGJxUwBjSAEAZGgAAAAAZGgAAAAAZGg0wwKnKwAIgRVoun6lABZoun6l ABdoYnFTAGNIAQBkaAAAAABkaAAAAABkaDLDAqcfAQiBBEgBAAVoMsMCpxVoun6lABZoYnFTABdo YnFTABMBCIEESAEABWgywwKnFmhicVMAEwEIgQRIAQAFaEHDAqcWaNoDGQATAQiBBEgBAAVoMcMC pxZoYnFTABMBCIEESAEABWgwwwKnFmhicVMAEwEIgQRIAQAFaC/DAqcWaGJxUwAMFWi6fqUAFmjp Nj4AAAYWaLp+pQAABhZo6TY+AAAMFWi6fqUAFmi6fqUAKAAGAAABCAAASggAAEsIAABMCAAATQgA AE4IAABPCAAAUAgAAFEIAABSCAAAUwgAAFQIAABVCAAAVggAAFcIAABYCAAAWQgAAFoIAABbCAAA kAgAAJEIAADXCAAAGgkAAF0JAACeCQAA5gkAAC0KAABtCgAAtQoAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkKjmMAAAdAAYAACcpAAD+AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQG1CgAA+QoAAD4LAACFCwAAygsAABAMAABZ DAAApwwAAOwMAAA3DQAAXw0AAGANAACiDQAAow0AAKQNAAClDQAApg0AAKcNAACoDQAAqQ0AAKoN AACrDQAArA0AAK0NAACuDQAArw0AALANAAD5DQAA+w0AAEQOAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAAAAAAAEDwBnZCo5jAAAHUQOAABFDgAARg4AAFQOAACdDgAA5g4AAC8P AABtDwAAqg8AAOkPAAAnEAAAZBAAAKAQAACuEAAAvBAAAL0QAAC+EAAAAxEAAC0RAAAuEQAAdhEA AL8RAAAHEgAAERIAABISAABZEgAAnhIAANYSAADXEgAAGBMAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD6AAAAAAAAAAAAAAAAAAAAAAQPAGdkKjmMAAAdGBMAAGITAACrEwAA8xMAABcUAAAYFAAAXxQA AKcUAADoFAAAKRUAAHgVAADBFQAAABYAABMWAAAUFgAAWRYAAKAWAADoFgAAMRcAAIcXAADQFwAA DxgAABAYAAARGAAAEhgAAFsYAABdGAAAphgAAKcYAACoGAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAAAAAAABA8AZ2QqOYwAAB1vEwAA7BMAAO0TAADuEwAAMRUAAD8VAABGFQAA RxUAAHkXAACGFwAAyhcAAM8XAADYFwAADxgAALAYAAC8GAAAXxkAAHAZAADcGgAA8hoAAPsaAAAU GwAAHxsAACgbAABXGwAAhxsAAI4bAACTGwAA+ePZ+cO5rPmi+Zj5gvmC+Xj5bmRuWlBaUEZQABMB CIEESAEABWjgwgKnFmgqOYwAEwEIgQRIAQAFaN/CAqcWaCo5jAATAQiBBEgBAAVo3sICpxZoKjmM ABMBCIEESAEABWjjwgKnFmgqOYwAEwEIgQRIAQAFaN3CAqcWaCo5jAATAQiBBEgBAAVoQsMCpxZo 2gMZACsACIEVaLp+pQAWaLp+pQAXaNoDGQBjSAEAZGgAAAAAZGgAAAAAZGhAwwKnEwEIgQRIAQAF aEDDAqcWaNoDGQATAQiBBEgBAAVoO8MCpxZo2gMZABkBCIEESAEABWg5wwKnFWi6fqUAFmhicVMA EwEIgQRIAQAFaDnDAqcWaGJxUwArAAiBFWi6fqUAFmi6fqUAF2hicVMAY0gBAGRoAAAAAGRoAAAA AGRoOcMCpxMBCIEESAEABWg1wwKnFmhicVMAKwAIgRVoun6lABZoun6lABdoYnFTAGNIAQBkaAAA AABkaAAAAABkaDXDAqcMFWi6fqUAFmi6fqUAG6gYAAC9GAAAvhgAAAcZAABPGQAAqBkAAOkZAAAp GgAAKhoAAHAaAAC5GgAAoxwAAOMcAADkHAAAKR0AAGIdAABjHQAAqx0AAPIdAAAXHgAAGB4AAFoe AAChHgAABh8AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA +gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAQPAGdkKjmMAAAXkxsAAKYbAAC5GwAAuxsAANUbAADWGwAALhwAAGMc AABoHAAAfRwAAH4cAAB/HAAAkBwAAJUcAAAGHgAABx4AAAgeAAAJHgAAnR4AAJ4eAACgHgAAxB4A ANUeAAD4HgAABR8AAB8fAAAjHwAATh8AAHcfAAB4HwAA9evh6+Hr183Xw/W817yyvJy8hny8fLxy vGi8XlQAAAAAAAAAAAAAAAAAAAAAAAAAEwEIgQRIAQAFaO7CAqcWaC9nXQATAQiBBEgBAAVo68IC pxZoL2ddABMBCIEESAEABWjnwgKnFmgvZ10AEwEIgQRIAQAFaPLCAqcWaFQihQATAQiBBEgBAAVo 6sICpxZoL2ddACsACIEVaLp+pQAWaLp+pQAXaC9nXQBjSAEAZGgAAAAAZGgAAAAAZGjqwgKnKwAI gRVoun6lABZoun6lABdoVk4hAGNIAQBkaAAAAABkaAAAAABkaEfDAqcTAQiBBEgBAAVoR8MCpxZo Vk4hAAwVaLp+pQAWaLp+pQAAEwEIgQRIAQAFaOTCAqcWaCo5jAATAQiBBEgBAAVoQ8MCpxZo2gMZ ABMBCIEESAEABWjlwgKnFmgqOYwAEwEIgQRIAQAFaOPCAqcWaCo5jAATAQiBBEgBAAVo4cICpxZo KjmMABMBCIEESAEABWjgwgKnFmgqOYwAAB14HwAAfR8AAIofAACzHwAAtB8AAOAfAADlHwAA7R8A ACsgAAAtIAAALiAAAC8gAAAwIAAAZCAAAKIgAAClIAAAuiAAALsgAAAWIQAAKSEAAC0hAAAwIQAA OSEAAF0hAABeIQAAYSEAAGIhAABmIQAAaCEAAPXr3tTK9crew8rUysOtw/WXw43Dd8Nhw1dNV00A AAAAAAAAAAAAEwEIgQRIAQAFaPjCAqcWaFQihQATAQiBBEgBAAVo98ICpxZoVCKFACsACIEVaLp+ pQAWaLp+pQAXaC9nXQBjSAEAZGgAAAAAZGgAAAAAZGjuwgKnKwAIgRVoun6lABZoun6lABdoL2dd AGNIAQBkaAAAAABkaAAAAABkaO/CAqcTAQiBBEgBAAVo78ICpxZoL2ddACsACIEVaLp+pQAWaLp+ pQAXaC9nXQBjSAEAZGgAAAAAZGgAAAAAZGjtwgKnKwAIgRVoun6lABZoun6lABdoL2ddAGNIAQBk aAAAAABkaAAAAABkaOzCAqcMFWi6fqUAFmi6fqUAABMBCIEESAEABWjowgKnFmgvZ10AEwEIgQRI AQAFaOzCAqcWaC9nXQAZAQiBBEgBAAVo7MICpxVoun6lABZoL2ddABMBCIEESAEABWjrwgKnFmgv Z10AEwEIgQRIAQAFaO3CAqcWaC9nXQAAHAYfAAACIAAAMSAAAHogAADVIAAAMSEAAF8hAABgIQAA twAAAAAAAAAAAAAAALIAAAAAAAAAAAAAAACtAAAAAAAAAAAAAAAArQAAAAAAAAAAAAAAAK0AAAAA AAAAAAAAAACtAAAAAAAAAAAAAAAAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Rw8AQyQBRcaAAAABAPfCAqcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAABnZCo5jAAABA8AZ2QqOYwAAAQPAGdkL2ddAABHDwBDJAFF xoAAAAEA7MICpwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAGdkL2ddAAAHYCEAAKghAACaIgAAaiMAALcAAAAAAAAAAAAAAABvAAAA AAAAAAAAAAAAJwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEcPAEMkAUXGgAAA AQD3wgKnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAZ2TXKvAAAEcPAEMkAUXGgAAAAQAAwwKnAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZ2TXKvAAAEcPAEMkAUXG gAAAAQD4wgKnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAZ2RUIoUAAANoIQAAtSEAAMshAADcIQAAFiIAABciAAAZIgAARSIAAE0i AAB3IgAAfiIAAIgiAACUIgAAsSIAAPQiAAD1IgAADCMAABUjAAAeIwAAKiMAAC0jAAAuIwAAOyMA AEQjAABPIwAAUCMAAFEjAABlIwAAaCMAAGkjAAByIwAAeCMAAKAjAACnIwAAviMAAL8jAADvIwAA 8ujy6N7Xyt7KwMq2yqyiysDKmKKYopjKmMrXgnjXbtd415jXAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAEwEIgQRIAQAFaO/CAqcWaC9nXQATAQiBBEgBAAVo+cICpxZoVCKFACsA CIEVaLp+pQAWaLp+pQAXaFQihQBjSAEAZGgAAAAAZGgAAAAAZGj5wgKnEwEIgQRIAQAFaAHDAqcW aNcq8AATAQiBBEgBAAVoWcMCpxZo52/kABMBCIEESAEABWhYwwKnFmjnb+QAEwEIgQRIAQAFaFXD AqcWaOdv5AATAQiBBEgBAAVoZMMCpxZoniChABkBCIEESAEABWgAwwKnFWi6fqUAFmjXKvAADBVo un6lABZoun6lAAATAQiBBEgBAAVoAMMCpxZo1yrwABMBCIEESAEABWj4wgKnFmhUIoUAGQEIgQRI AQAFaPjCAqcVaLp+pQAWaFQihQAAJGojAADAIwAAFCQAAGYkAAAyJQAAdiUAANclAAAeJgAALyYA ADAmAAB4JgAAviYAAAEnAABDJwAAhScAAMsnAADMJwAADygAAFMoAACaKAAA1ygAANgoAADZKAAA 2igAANsoAADcKAAA3SgAACYpAAAnKQAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAQPAGdkKjmMAAAc7yMAAPQjAAD+IwAA/yMAAD8kAABCJAAATSQAAE4kAACCJAAA oyQAALMkAADjJAAA7CQAAO0kAAATJQAAKiUAADElAABSJQAAbyUAAI8lAACQJQAAlSUAAJolAACm JQAAsCUAALolAAC7JQAAvyUAAMklAADRJQAA6d/Sy+nf0svfwd+3rcuto8uNy6PLg8ttY1bLg8sA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABkBCIEESAEABWj6wgKnFWi6fqUAFmhUIoUAEwEIgQRIAQAF aPrCAqcWaFQihQArAAiBFWi6fqUAFmi6fqUAF2hUIoUAY0gBAGRoAAAAAGRoAAAAAGRo+sICpxMB CIEESAEABWhTwwKnFmjnb+QAKwAIgRVoun6lABZoun6lABdo52/kAGNIAQBkaAAAAABkaAAAAABk aFLDAqcTAQiBBEgBAAVoUsMCpxZo52/kABMBCIEESAEABWhRwwKnFmjnb+QAEwEIgQRIAQAFaFHD AqcWaFZOIQATAQiBBEgBAAVoZcMCpxZoniChAAwVaLp+pQAWaLp+pQAAGQEIgQRIAQAFaFDDAqcV aLp+pQAWaFZOIQATAQiBBEgBAAVoUMMCpxZoVk4hACsACIEVaLp+pQAWaLp+pQAXaFZOIQBjSAEA ZGgAAAAAZGgAAAAAZGhQwwKnAB3RJQAA6SUAADMmAAA0JgAAgCYAAIgmAAC6JgAAFScAAMknAADd JwAA3icAAOInAABzKAAAhSgAAMUoAADGKAAAyigAANgoAADZKAAA2ygAANwoAAAnKQAA6eLMtqC2 4origGriauKAauJmYlviAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwVaLp+pQAWaOk2PgAABhZo6TY+AAAGFmi6 fqUAACsACIEVaLp+pQAWaLp+pQAXaNcq8ABjSAEAZGgAAAAAZGgAAAAAZGgDwwKnEwEIgQRIAQAF aAPDAqcWaNcq8AArAAiBFWi6fqUAFmi6fqUAF2jXKvAAY0gBAGRoAAAAAGRoAAAAAGRoAMMCpysA CIEVaLp+pQAWaLp+pQAXaFQihQBjSAEAZGgAAAAAZGgAAAAAZGj2wgKnKwAIgRVoun6lABZoun6l ABdoVCKFAGNIAQBkaAAAAABkaAAAAABkaPrCAqcrAAiBFWi6fqUAFmi6fqUAF2jXKvAAY0gBAGRo AAAAAGRoAAAAAGRo+sICpwwVaLp+pQAWaLp+pQAAKwAIgRVoun6lABZoun6lABdo52/kAGNIAQBk aAAAAABkaAAAAABkaFPDAqcAFTIAMZBoATpwKjmMAB+w0C8gsOA9IbAnBSKwJwUjkKAFJJCgBSWw AAAXsNACGLDQAgyQ0AIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAhgIQABIAAQCcAA8ABAAAAAMAAAAAAAQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARAAAQPH/AgBEAAwEAAAAAAAA AAAGAE4AbwByAG0AYQBsAAAAAgAAABwAQ0oYAF9IAQRhShgAbUgJBG5IEQRzSAkEdEgRBAAAAAAA AAAAAAAAAAAAAAAAAEQAQUDy/6EARAAMBQAAAAAAAAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIA YQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAABSAGlA8/+zAFIADAUAAAAAAAAAAAwAVABhAGIAbABl ACAATgBvAHIAbQBhAGwAAAAcABf2AwAANNYGAAEKA2wANNYGAAEFAwAAYfYDAAACAAsAAAAoAGtA 9P/BACgAAAUAAAAAAAAAAAcATgBvACAATABpAHMAdAAAAAIAAAAAAAAARABaQAEA8gBEAAwEAADU V3kAAAAKAFAAbABhAGkAbgAgAFQAZQB4AHQAAAACAA8AFABDShQAT0oEAFFKBABeSgQAYUoUAAAA AAAnIQAACQAASgAABwD/////AAAAAAEAAABKAAAASwAAAEwAAABPAAAAWwAAAJAAAACRAAAA1wAA ABoBAABdAQAAngEAAOYBAAAtAgAAbQIAALUCAAD5AgAAPgMAAIUDAADKAwAAEAQAAFkEAACnBAAA 7AQAADcFAABfBQAAYAUAAKIFAACjBQAApAUAAKUFAACmBQAApwUAAKgFAACpBQAAqgUAAKsFAACs BQAArQUAAK4FAACvBQAAsAUAAPkFAAD7BQAARAYAAEUGAABGBgAAVAYAAJ0GAADmBgAALwcAAG0H AACqBwAA6QcAACcIAABkCAAAoAgAAK4IAAC8CAAAvQgAAL4IAAADCQAALQkAAC4JAAB2CQAAvwkA AAcKAAARCgAAEgoAAFkKAACeCgAA1goAANcKAAAYCwAAYgsAAKsLAADzCwAAFwwAABgMAABfDAAA pwwAAOgMAAApDQAAeA0AAMENAAAADgAAEw4AABQOAABZDgAAoA4AAOgOAAAxDwAAhw8AANAPAAAP EAAAEBAAABEQAAASEAAAWxAAAF0QAACmEAAApxAAAKgQAAC9EAAAvhAAAAcRAABPEQAAqBEAAOkR AAApEgAAKhIAAHASAAC5EgAAoxQAAOMUAADkFAAAKRUAAGIVAABjFQAAqxUAAPIVAAAXFgAAGBYA AFoWAAChFgAABhcAAAIYAAAxGAAAehgAANUYAAAxGQAAqBkAAJoaAABqGwAAwBsAABQcAABmHAAA Mh0AAHYdAADXHQAAHh4AAC8eAAAwHgAAeB4AAL4eAAABHwAAQx8AAIUfAADLHwAAzB8AAA8gAABT IAAAmiAAANcgAADYIAAA3CAAAN0gAAAmIQAAKSEAAJoAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACaAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAH mgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5oAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJoAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmgAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJoAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAAeaAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJoAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACaAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmgAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAB5oAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmgAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAB5oAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAgHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACaAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACa AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJoA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5pAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAeaAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5oAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmkAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAQB5pAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAEAeaAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAHmkAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5oAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAAeaAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmgAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAB5oAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeaAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAgHmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5gAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmgAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAIB5oAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAIB5oAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAACAeaAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJoAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAB5oAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAAeYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmgAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAB5gAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmgAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAABwAAAAABAAAASgAAAEsAAABMAAAA TQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAAWQAAAFoAAABb AAAAkAAAAJEAAADXAAAAGgEAAF0BAACeAQAA5gEAAC0CAABtAgAAtQIAAPkCAAA+AwAAhQMAAMoD AAAQBAAAWQQAAKcEAADsBAAANwUAAF8FAABgBQAAogUAAKMFAACkBQAApQUAAKYFAACnBQAAqAUA AKkFAACqBQAAqwUAAKwFAACtBQAArgUAAK8FAACwBQAA+QUAAPsFAABEBgAARQYAAEYGAABUBgAA nQYAAOYGAAAvBwAAbQcAAKoHAADpBwAAJwgAAGQIAACgCAAArggAALwIAAC9CAAAvggAAAMJAAAt CQAALgkAAHYJAAC/CQAABwoAABEKAAASCgAAWQoAAJ4KAADWCgAA1woAABgLAABiCwAAqwsAAPML AAAXDAAAGAwAAF8MAACnDAAA6AwAACkNAAB4DQAAwQ0AAAAOAAATDgAAFA4AAFkOAACgDgAA6A4A ADEPAACHDwAA0A8AAA8QAAAQEAAAERAAABIQAABbEAAAXRAAAKYQAACnEAAAqBAAAL0QAAC+EAAA BxEAAE8RAACoEQAA6REAACkSAAAqEgAAcBIAALkSAACjFAAA4xQAAOQUAAApFQAAYhUAAGMVAACr FQAA8hUAABcWAAAYFgAAWhYAAKEWAAAGFwAAAhgAADEYAAB6GAAA1RgAADEZAABfGQAAYBkAAKgZ AACaGgAAahsAAMAbAAAUHAAAZhwAADIdAAB2HQAA1x0AAB4eAAAvHgAAMB4AAHgeAAC+HgAAAR8A AEMfAACFHwAAyx8AAMwfAAAPIAAAUyAAAJogAADXIAAA2CAAANkgAADaIAAA2yAAANwgAADdIAAA JiEAACkhAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAABmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAA AAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAA AACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAA AJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA AAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA AA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA DzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAP MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAgAmAAAAA8w AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAA AAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAQAJgAAAAPMAAA AAAAAACAAAAAgAAAAAAAAAAAEACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAABAAmAAAAA8wAAAA AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAA AAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAA AACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAA AIAAAACAAAAAAAAAAAAIAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAA gAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACA AAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAA AACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAACACYAAAADzAAAAAAAAAAgAAA AIAAAAAAAAAAAAgAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAA gAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACA AAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAA AAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAA AAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAA AAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAAAA AAAAAAAABgAAbxMAAJMbAAB4HwAAaCEAAO8jAADRJQAAJykAABUAAAAbAAAAHQAAAB4AAAAhAAAA IwAAACQAAAAABgAAtQoAAEQOAAAYEwAAqBgAAAYfAABgIQAAaiMAACcpAAAWAAAAGAAAABkAAAAa AAAAHAAAAB8AAAAgAAAAIgAAAAAGAAAnKQAAFwAAAAAAAADMAgAAzwIAAEkDAABMAwAAZAMAAGcD AACwBQAAuAUAALsFAADABQAAsAYAALUGAAA7CAAAQAgAAM0OAADYDgAAEhAAABoQAAAdEAAAIhAA AI4VAACZFQAAChYAABUWAACtIAAAuCAAAN0gAADlIAAA6CAAAO0gAAApIQAABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAAAAAAYAAA AGcAAAAdAQAAJAEAAGABAABoAQAAoQEAAKoBAADpAQAA8wEAADACAAA6AgAAcAIAAHoCAAD8AgAA AgMAAEEDAABMAwAAiAMAAIoDAADNAwAA2QMAABMEAAAXBAAAXAQAAGQEAACqBAAAsQQAAO8EAAD7 BAAAOgUAADwFAAA4BwAAOQcAAHYHAAB3BwAAswcAALQHAADyBwAA8wcAAC0IAAA3CAAAJAkAACwJ AAB5CQAAegkAAMIJAADECQAACgoAAA8KAAA7CgAAPgoAAGEKAABoCgAApgoAAKwKAAAgCwAAKAsA AGoLAABvCwAAswsAAL0LAAD7CwAAAwwAAGcMAAB2DAAArwwAALEMAADwDAAA+gwAAD8NAABGDQAA gA0AAIMNAADJDQAA0g0AAAgOAAAQDgAAYQ4AAGUOAACoDgAAsQ4AAPAOAADzDgAAOQ8AADsPAACP DwAAlw8AAA8RAAAXEQAAVxEAAFkRAACwEQAAtxEAAPERAAD9EQAAeBIAAH8SAADBEgAAyxIAAKsU AACzFAAAMRUAAD0VAACzFQAAtRUAAPoVAAD8FQAAYhYAAGoWAACpFgAArRYAAAoYAAAMGAAAORgA AD8YAADdGAAA4BgAALAZAAC0GQAAohoAAKsaAAByGwAAfBsAAMgbAADPGwAAHBwAACAcAABuHAAA cRwAADodAABAHQAAfh0AAIgdAADpHQAA6x0AACYeAAAtHgAAxh4AAM8eAAAJHwAAEh8AABcgAAAf IAAAWyAAAGQgAACiIAAArCAAACkhAAAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAH ADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAAAAAACMFAAA6BQAA8hUAACAWAAA6 HQAAch0AACkhAAAHAAUABwAFAAcABQAHAAAAAAApIQAABwCDAAAABAAAAAgAAADlAAAAAAAAAIIA AACdTgAAmBYBAN0TAwDGbAMA3EsFAAs3BwAveAcAHmsIADwPDAD1DA0AC1wNAFofEgDXOBUAiFsV APEsGADFXBgAen8YANoDGQDXahsAcX0bADoJIABWTiEA1xgkAOIbJACuHykA0gcsAMQ6LAC+AS4A gw8uAAl/LgCtfy4AODQvAIYFNABDfTcAZQQ5AGEeOQDxOzkAIQM8APcLPADrRD0AJjQ+AOk2PgBM aUUAzT5GAF1PRgCrW0cAzB9IAM0cSQBDM0kAPXpRAE1YUgBicVMAMHVYANQ0XAAvZ10A8FleAAcH YAAbDmEAQhhhAA83YwDiY2cA2BZrAGtoawDTYWwAkQZvAOhhcAD1OncA5j93AMhQeQB1LX8AWg2C AEImggAYFYMAyEWEAFQihQAqOYwA4EePAEw3kgD8OJQAtX+VAGxCmQA/CpsAniChABQWpAAOR6QA un6lAGFOpwD7OKoAb02qAEhTrAD4PK4AZFewAPIAtQDtJL0AJXu9ABxlvgB3DcAAJ0LAAE5lwQBn CskA6TvKAJcOywC9RcwAxG7SAJhy0wBnX9QAmGHUAIt91QBdW9oAtGraAF424wDnb+QASAfmAAcW 6gDuMesASErrAO9K7QAUOe4A1gvwANcq8ABTI/EAR3XxAAUt8wA+XPMABRP0APwj9ACLaPcAMmv6 AMkq+wDYBf4AnnT/AP9AAYABAFsAAABbAAAAgJGXAgEAAABbAAAAAAAAAFsAAAAAAAAAAhAAAAAA AAAAJyEAAJAAABAAQAAA//8CAAAABwBVAG4AawBuAG8AdwBuABAARwBlAHIAYQBsAGQAIABDAGgA bwB1AGkAbgBhAHIAZAD//wIACAAAAAAAAAAAAAAAAAAAAAAAAAABAP//AgAAAAAAAAD//wAAAgD/ /wAAAAD//wAAAgD//wAAAAAFAAAARxaQAQAAAgIGAwUEBQIDBId6ACAAAACACAAAAAAAAAD/AQAA AAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAANRaQAQIABQUBAgEHBgIFBwAAAAAA AAAQAAAAAAAAAAAAAACAAAAAAFMAeQBtAGIAbwBsAAAAMyaQAQAAAgsGBAICAgICBId6ACAAAACA CAAAAAAAAAD/AQAAAAAAAEEAcgBpAGEAbAAAAEc1kAGACgICBgkEAgUIAwS/AgCg+/zHaBAAAAAA AAAAnwACAAAAAABNAFMAIABNAGkAbgBjAGgAbwAAAC3/M/8gAA5mHWcAAD81kAEAAAIHAwkCAgUC BASHegAgAAAAgAgAAAAAAAAA/wEAAAAAAABDAG8AdQByAGkAZQByACAATgBlAHcAAAAiAAQAcQiI GADw0AIAAGgBAAAAAGzDAqdswwKnAAAAAAIAAwAAAPIEAAA1HAAAAQAQAAAABAADEDwAAADyBAAA NRwAAAEAEAAAADwAAAAAAAAA4QIA8BAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwWgBbQA tACBgTI0AAAQABkAZAAAABkAAAAXIQAAFyEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAABMoMRAPAQAAgAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAEhYAAAAACjw/w8BAAE/AADkBAAAvgEAAP///3////9///// f////3////9/////f6tbRwAAAAAAMgAAAAAAAAAAAAAAAAABAAAA//8SAAAAAAAAAAMAIAAgACAA AAAAAAAAEABHAGUAcgBhAGwAZAAgAEMAaABvAHUAaQBuAGEAcgBkABAARwBlAHIAYQBsAGQAIABD AGgAbwB1AGkAbgBhAHIAZAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAA AAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAIQBAAARAAAAAQAAAJAAAAACAAAA mAAAAAMAAACkAAAABAAAALAAAAAFAAAAzAAAAAYAAADYAAAABwAAAOQAAAAIAAAA+AAAAAkAAAAU AQAAEgAAACABAAAKAAAAQAEAAAwAAABMAQAADQAAAFgBAAAOAAAAZAEAAA8AAABsAQAAEAAAAHQB AAATAAAAfAEAAAIAAADkBAAAHgAAAAQAAAAgICAAHgAAAAQAAAAAAAAAHgAAABQAAABHZXJhbGQg Q2hvdWluYXJkAAAAAB4AAAAEAAAAAAAAAB4AAAAEAAAAAAAAAB4AAAAMAAAATm9ybWFsLmRvdAAA HgAAABQAAABHZXJhbGQgQ2hvdWluYXJkAAAAAB4AAAAEAAAAMgAAAB4AAAAYAAAATWljcm9zb2Z0 IE9mZmljZSBXb3JkAAAAQAAAAADSSWsAAAAAQAAAAABYqUUk88wBQAAAAABYqUUk88wBAwAAAAEA AAADAAAA8gQAAAMAAAA1HAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAA AAAAAAABAAAAAtXN1ZwuGxCTlwgAKyz5rjAAAADsAAAADAAAAAEAAABoAAAADwAAAHAAAAAFAAAA fAAAAAYAAACEAAAAEQAAAIwAAAAXAAAAlAAAAAsAAACcAAAAEAAAAKQAAAATAAAArAAAABYAAAC0 AAAADQAAALwAAAAMAAAAzAAAAAIAAADkBAAAHgAAAAQAAABDUkMAAwAAADwAAAADAAAAEAAAAAMA AAAXIQAAAwAAAA8nCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAABAAA ACAgIAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAA AAgAAAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAk AAAAJQAAAP7///8nAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIA AAAzAAAANAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAA AEEAAABCAAAA/v///0QAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAAD+////TAAAAE0AAABOAAAA TwAAAFAAAABRAAAAUgAAAP7////9////VQAAAP7////+/////v////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJAgAA AAAAwAAAAAAAAEYAAAAAAAAAAAAAAAAQ8ztiJPPMAVcAAACAAAAAAAAAADEAVABhAGIAbABlAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAIB//// /wUAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJgAAAPc5AAAAAAAA VwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAABoAAgEBAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAANEoAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEMAAAAAEAAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQBy AHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASwAAAAAQAAAAAAAAAQBDAG8AbQBwAE8AYgBq AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABGHwAA AE1pY3Jvc29mdCBPZmZpY2UgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRv Y3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFIAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADA AAAAAAAARgAAAAAAAAAAAAAAAFAUT5Yr88wBXAAAAAACAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgH/////BQAA AP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAmAAAA9zkAAAAAAABXAG8A cgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAGgACAQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA0SgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAQwAAAAAQAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJ AAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcA AAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAA AP7///8nAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAA NAAAADUAAAA2AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABC AAAA/v///0QAAABFAAAARgAAAEcAAABIAAAASQAAAEoAAAD+//////////////////////////// /////////////////////////////////////////////1sAAAD9/////v////7////+//////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////8BAAAA/v///wMAAAAEAAAABQAAAAYAAAAHAAAA/v////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////wUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBu AGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAGQBAAAAAAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAcQAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARh8AAABNaWNy b3NvZnQgT2ZmaWNlIFdvcmQgRG9jdW1lbnQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVu dC44APQ5snEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAA AAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmuMAEAAOwAAAAMAAAAAQAA AGgAAAAPAAAAcAAAAAUAAAB8AAAABgAAAIQAAAARAAAAjAAAABcAAACUAAAACwAAAJwAAAAQAAAA pAAAABMAAACsAAAAFgAAALQAAAANAAAAvAAAAAwAAADMAAAAAgAAAOQEAAAeAAAABAAAAENSQwAD AAAAPAAAAAMAAAAQAAAAAwAAABchAAADAAAADycLAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsA AAAAAAAAHhAAAAEAAAAEAAAAICAgAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAANAAA AAMAAAAAAAAAIAAAAAEAAAAkAAAAAAAAgCwAAAAAAAAAAgAAALAEAAATAAAACQQAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= ------=_NextPart_000_002D_01CCF301.AE62A900 Content-Type: text/plain; name="UC&R-version-03a-GC.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="UC&R-version-03a-GC.txt" Internet-Draft PAWS: Problem, uses and requirements February 2012 4.2.2. Wide-Area or Rural internet broadband access In this use case, internet broadband access is provided as a Wide- Area Network (WAN) or Wireless Regional Area Network (WRAN). A typical deployment scenario is a wide area or rural area, where internet broadband access is provided to local businesses and residents from a master (i.e., BS) connected to the internet. This deployment scenario is typically characterized by one or more fixed master(s)/BS(s), cells with relatively large radius (tens of kilometers, up to 100 km), and a number of available radio channels. Some of the masters/BSs may be deployed and operated by a single entity, i.e., there can be centralized coordination between these masters/BSs, whereas other masters/BSs may be deployed and operated by operators competing for the radio channels where decentralized coordination using the air-interface would be required. The BS in this scenario uses a TDD radio technology and transmits at or below a transmit power (EIRP) limit established by the local regulator. Each = base station has a connection to the internet and may provide internet connectivity to multiple slaves/ user devices. End-user terminals or devices may be fixed or portable. The figure below shows an example deployment of this scenario. Probasco & Patil Expires August 19, 2012 [Page 15] Internet-Draft PAWS: Problem, uses and requirements February 2012 ------- |Slave|\ \|/ ---------- |Dev 1| (TDD AirIF) | |Database| ------- \ | .---. /---------- o \ |-|---------| ( ) / o | Master | / \ o / | (BS) |=3D=3D=3D=3D=3D=3D=3D=3D( = Internet ) o / |-----------| \ / ------- (TDD AirIF) ( ) |Slave| / (----) |Dev n| ------- Figure 4: Rural internet broadband access using TV white space spectrum Once the master/BS has been professionally installed and configured, a simplified power up and operation scenario utilizing TV White Space to provide rural internet broadband access consists of the following steps: 1. The master/BS powers up; however its WS radio and all other WS capable devices will power up in idle/listen-only mode (no active transmissions on the WS frequency band). 2. The master/BS has internet connectivity, determines it's location (either from location determination capability or from = a saved value that was set during installation), and establishes a connection to a trusted white space database (see "White Space database discovery" above). 3. The master/BS registers with the trusted database service (see Section 4.1.2). Meanwhile the DB administrator may be required to store and forward the registration information to the regulatory authority. If a trusted white space database service is not discovered, further operation of the WRAN may be allowed according to local regulator policy (in this case operation of the WRAN is outside the scope of the PAWS protocol). 4. Following the successful registration process, the master/BS will send a query to the trusted database requesting a list of available WS channels based upon its geolocation. The complete set of parameters to be provided from the master to the database is specified by the local regulator. Parameters may include WSD = identifier,=20 location, accuracy of that location, device antenna height, etc. =20 Probasco & Patil Expires August 19, 2012 [Page 16] Internet-Draft PAWS: Problem, uses and requirements February 2012 =20 5. If the master/BS has been previously authenticated, the database responds with a list of available white space channels that may be used by the master/BS and optionally a maximum transmit power = (EIRP) for each channel, a duration of time the channel may be used or a notification of any additional requirement for sensing. 6. Once the master/BS authenticates the WS channel list response message from the database, the master/BS selects an available WS channel(s) from the list. Such selection may be improved based = on a set of queries to the DB involving a number of hypothetical slave = or user devices located at various locations over the expected service = area so that the final intersection of these resulting WS channel lists = allows the selection of a channel that is likely available over the = entire service area to avoid potential interference at the time of = slave/user terminal association. The operator may also disallow some channels from the list to suit local needs if required. 7. The slave or user device scans the TV bands to locate a WRAN transmission, and associates with the master/BS. 8. The slave/user device provides its geolocation to the BS which, in turn, queries the database for a list of channels available at the slave=92s geolocation. 9. Once this list of available channels is received from the database by the master, the latter will decide, based on this list of available channels and on the lists for all its other = associated slaves/user devices whether it should: a) continue operation on its current channel = if this channel is available to all slaves/user devices, b) continue = operation on its current channel and not allow association with the new = slave/user device in case this channel is not available at its location or c) change channel to accommodate the new slave. In the latter = case, the master will notify all its associated slaves/user devices of the new channel to which = they have to move . 10. The master/BS must periodically repeat the process to request a list of available channels from the database for itself and for = all its associated slaves/user devices. If the response from the = database indicates that the channel being used by the master/BS is no = longer available for its use, the master/BS must indicate the new operating channel to all its = slave/user terminals, stop transmitting on the current channel and move = to the new operating channel immediately. If the channel that a slave/user terminal is currently using is not longer included in = the list of=20 locally available channels, the master may either drop its = association with the slave/user device so that this device ceases all = operation on its current channel or the master may decide to move the entire = cell to another channel to accommodate the slave/user terminal and = indicate the new operating channel to all its slave/user devices before dropping the link. The slave/user devices may then move to the identified new operating = channel or scan for another WRAN transmission on a different channel. The frequency to repeat the process is determined by the local regulator. . 11. The slave/user device must transmit its new geographic location every time it changes so that the repeated process described under item 10 can rely on the most up-to-date geolocation of the slave/user device. Probasco & Patil Expires August 19, 2012 [Page 17] ------=_NextPart_000_002D_01CCF301.AE62A900-- From scott.probasco@nokia.com Fri Feb 24 11:57:42 2012 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 2E28D21F87EA for ; Fri, 24 Feb 2012 11:57:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.137 X-Spam-Level: X-Spam-Status: No, score=-4.137 tagged_above=-999 required=5 tests=[AWL=1.861, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oga7jqnuqZMW for ; Fri, 24 Feb 2012 11:57:39 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8649021F87E4 for ; Fri, 24 Feb 2012 11:57:39 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1OJvZUS004055; Fri, 24 Feb 2012 21:57:37 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 24 Feb 2012 21:57:35 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Fri, 24 Feb 2012 20:57:34 +0100 From: To: Thread-Topic: draft update to PAWS UC&R Thread-Index: AQHM8KvNja+uMv9rp0CzgALGeXgGBpZMdOJwgAAGdHA= Date: Fri, 24 Feb 2012 19:57:34 +0000 Message-ID: <88BE24FD9280884487DEAE0CE1FD3A5B0FDD70E8@008-AM1MPN1-026.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-version: 3.3.8.1 x-tituslabs-classifications-30: TLPropertyRoot=Nokia;Confidentiality=Nokia Internal Use Only;Project=None; x-tituslabs-classificationhash-30: VgNFIFU9Hx+/nZJb9Kg7IhLPPWv250esEB8225cG0KeN8NdvaecHV/fAw2Qe987DB8HSX8o3wekZUs7vxUnLzRhkkHM+wi502DNBataKkjmUgwKblwcko6IFTIwqmvlq6uRaZRouYTlVX6BlxAS5MEk85I5dr6f9u+XNoTWqiNaiJ8MHo5Pvd0PTsOCTY2iWcyUq7LxNBWM3afOjaL77OTyLthisWJzLpm/pQw5VN2E= x-headerinfofordlp: None x-originating-ip: [10.241.53.191] Content-Type: multipart/alternative; boundary="_000_88BE24FD9280884487DEAE0CE1FD3A5B0FDD70E8008AM1MPN1026mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2012 19:57:35.0624 (UTC) FILETIME=[8D941880:01CCF32E] X-Nokia-AV: Clean Cc: paws@ietf.org, apurva_mody@yahoo.com Subject: Re: [paws] draft update to PAWS UC&R 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, 24 Feb 2012 19:57:42 -0000 --_000_88BE24FD9280884487DEAE0CE1FD3A5B0FDD70E8008AM1MPN1026mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gerald, Your corrections are good improvements, thank you. I will include these to = the draft assuming no objections. Kind Regards, Scott From: ext Gerald Chouinard [mailto:gerald.chouinard@sympatico.ca] Sent: Friday, February 24, 2012 1:36 PM To: Probasco Scott (Nokia-CIC/Dallas) Cc: paws@ietf.org; 'apurva mody' Subject: RE: draft update to PAWS UC&R Scott, Attached is a polished-up version of section 4.2.2 on "Wide-Area or Rural i= nternet broadband access". Besides some minor typos, I have tried to clarify that items 1 to 6 are for= the master/BS initial operation. I have added the concept of an optional v= erification of an available channel list that would apply over an area arou= nd the BS so that the CPEs, when they try to associate with the BS, would u= se a channel that in known not to interfere with incumbents at their locati= on. Items 7 and 8 relate to the actions to be taken by the slave/user devices. Item 9 now deals with the process at the master/BS to add a new slave/user = device to the network. Three different cases are covered for the master/BS = to take a decision. Item 10 now deals with the 'steady state', i.e., the repeated query process= at the master/BS to maintain the association with its slave/user devices. = (It used to be covered in both items 9 and 10.) It now covers the cases whe= re: a) the operating channel is available to all devices, thus no change; b= ) the operating channel is no longer available to the master/BS, in such ca= se, it needs to alert its associated terminals and move to the new operatin= g channel; c) if one of the slave/user devices can no longer operate on the= current channel, then the master/BS may decide to either: c1) drop associa= tion with that terminal or, c2) move to another available channel in the li= st to accommodate that terminal as long as that channel is available to the= master/BS and all other associated slave/user terminals. This should clarify the decisions that need to be made at the master/BS in = all cases and make the text clearer. Respectfully submitted, Gerald ________________________________ From: scott.probasco@nokia.com [mailto:sco= tt.probasco@nokia.com] Sent: Tuesday, 21 February, 2012 10:17 To: Basavaraj.Patil@nokia.com; scott.prob= asco@nokia.com Subject: draft update to PAWS UC&R Hi, Attached is a draft version-03 update of the use case & requirements. This = is not an official release; in order to avoid confusion I have removed the = heading & some boiler-plate text at the beginning of this draft. In order t= o improve the quality of the draft, I am asking a few of the people who hav= e been active in the discussions if you have some time to review this inter= im document for accuracy, to verify that it reflects the results of the ema= il reflector discussion. Your review of the entire document is warmly welco= med, but if you are pressed for time, a focused review on those sections wh= ere you have provided comments is much appreciated. Note that Chapter 6 "Re= quirements" is not yet updated, I will be posting this section to the refle= ctor for comments shortly. If you find any errors or omissions in implementation please let me know an= d I will correct those. If you find technical errors or corrections, first = let's discuss how we can review those comments on the email reflector and r= each consensus there. Then I can update the draft. Also attached for your reference is a spreadsheet that identifies the speci= fic email discussions that I have implemented. There is some overlap in the= se threads due to the "opportunistic" nature of the email discussions. Kind Regards, Scott --_000_88BE24FD9280884487DEAE0CE1FD3A5B0FDD70E8008AM1MPN1026mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gerald,

 <= /p>

Your corrections are good= improvements, thank you. I will include these to the draft assuming no obj= ections.

 <= /p>

Kind Regards,<= /span>

Scott

 <= /p>

From: ext Gera= ld Chouinard [mailto:gerald.chouinard@sympatico.ca]
Sent: Friday, February 24, 2012 1:36 PM
To: Probasco Scott (Nokia-CIC/Dallas)
Cc: paws@ietf.org; 'apurva mody'
Subject: RE: draft update to PAWS UC&R

 

Scott,

 

Attached is a polished-up vers= ion of section 4.2.2 on “Wide-Area or Rural internet broadband= access”.

 

Besides some minor typos, I have tried to clarify th= at items 1 to 6 are for the master/BS initial operation. I have added the c= oncept of an optional verification of an available channel list that would = apply over an area around the BS so that the CPEs, when they try to associate with the BS, would use a channel= that in known not to interfere with incumbents at their location.

 

Items 7 and 8 relate to the actions to be taken by t= he slave/user devices.

 

Item 9 now deals with the process at the master/BS t= o add a new slave/user device to the network. Three different cases are cov= ered for the master/BS to take a decision.

 

Item 10 now deals with the ‘steady state’= ;, i.e., the repeated query process at the master/BS to maintain the associ= ation with its slave/user devices. (It used to be covered in both items 9 a= nd 10.) It now covers the cases where: a) the operating channel is available to all devices, thus no change; b) the oper= ating channel is no longer available to the master/BS, in such case, it nee= ds to alert its associated terminals and move to the new operating channel;= c) if one of the slave/user devices can no longer operate on the current channel, then the master/BS may decid= e to either: c1) drop association with that terminal or, c2) move to anothe= r available channel in the list to accommodate that terminal as long as tha= t channel is available to the master/BS and all other associated slave/user terminals.

 

This should clarify the decisions that need to be ma= de at the master/BS in all cases and make the text clearer.

 

Respectfully submitted,

 

Gerald

 

 

From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]
Sent: Tuesday, 21 February, 2012 10:17
To: Basavaraj.Patil@nok= ia.com; scott.probasco@nokia.com Subject: draft update to PAWS UC&R

 

Hi,

 

Attached is a draft version= -03 update of the use case & requirements. This is not an official rele= ase; in order to avoid confusion I have removed the heading & some boiler-plate text at the beginning of this draft. In order to i= mprove the quality of the draft, I am asking a few of the people who have b= een active in the discussions if you have some time to review this interim = document for accuracy, to verify that it reflects the results of the email reflector discussion. Your review of = the entire document is warmly welcomed, but if you are pressed for time, a = focused review on those sections where you have provided comments is much a= ppreciated. Note that Chapter 6 "Requirements" is not yet updated, I will be posting this sectio= n to the reflector for comments shortly. 

 

If you find any errors or o= missions in implementation please let me know and I will correct those. If = you find technical errors or corrections, first let's discuss how we can review those comments on the email reflector and reach consensu= s there. Then I can update the draft.

 

Also attached for your refe= rence is a spreadsheet that identifies the specific email discussions that = I have implemented. There is some overlap in these threads due to the "opportunistic" nature of the email discussions.=

 

Kind Regards,

Scott

--_000_88BE24FD9280884487DEAE0CE1FD3A5B0FDD70E8008AM1MPN1026mg_-- From jstine@mitre.org Fri Feb 24 14:37:40 2012 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 578EC21F869C for ; Fri, 24 Feb 2012 14:37:40 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CroEpOjiBQQV for ; Fri, 24 Feb 2012 14:37:39 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 84C3A21F8672 for ; Fri, 24 Feb 2012 14:37:39 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6104B21B0A27 for ; Fri, 24 Feb 2012 17:37:38 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 54C5521B09C0 for ; Fri, 24 Feb 2012 17:37:38 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Fri, 24 Feb 2012 17:37:38 -0500 From: "Stine, John A." To: "paws@ietf.org" Thread-Topic: Requirements and Multiple Data Models Thread-Index: AczzROhZZN7L5dMiSouUb+D1PsKhFg== Date: Fri, 24 Feb 2012 22:37:37 +0000 Message-ID: <2782C93FD2244441893673F3F91281921144B1@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [paws] Requirements and Multiple Data Models 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, 24 Feb 2012 22:37:40 -0000 I wrote previously about the goodness of dividing data models into at least= two halves, the data that describes the spectrum use and the data that is = necessary for the business processes of resolving what spectrum a device ma= y use. On further thought, I believe we should divide the data into three = parts, the data required for messaging and trust, the particular administra= tive data required by a regulatory domain, and the data defining the spectr= um. The purpose of separating these data models is to allow growth of the = whitespace concept. =20 The motivation for separating out the messaging data is to allow the messag= ing data to be very broadly applied to all types of whitespace management f= or all regulatory domains. This part of the standard would be expanded as = new capabilities are added. The purpose for separating out the administrative data is to allow each reg= ulatory domain to specify and to modify their data requirements without hav= ing international ramifications. We may want this data model to convey par= ticular regulatory requirements obtaining and keeping authorization to use = channels. The purpose for separating out the spectrum data is to make it independent = of any particular business processes. This is very important for expansion= where the spectrum data model is used to trade spectrum, arbitrate coexist= ence, or give policy to cognitive radios. The spectrum models may be chang= ed in whole based on whether and how spectrum coexistence is managed.=20 Using the requirements sent out earlier this week in=20 http://www.ietf.org/mail-archive/web/paws/current/msg00775.html this is my take on how the requirements would affect the different data mod= els. The data requirements D2, D3, and D4 would be part of the messaging data mo= del. The data requirements D5, D6, and D8 would be part of the administrat= ive data. The data requirements D1, D7, D9, and D10 would be part of the sp= ectrum use model. =20 The data elements implied by the protocol requirements, P1, P2, P3, P4, P5,= P6, P7, P8, P9, P11, P15, P16, and P18 would be included in the messaging = data model. The data implied by the protocol requirement P12 (less locatio= n), P14 (less location), P17, and P19 would be included in the administrati= on data models. The data implied by the protocol requirements p13, P19, an= d P20 would be included in the spectrum data model. Location would be defi= ned in the spectrum data model. The data implied by the operational requirements O1, O2, O4, O5, and O20, w= ould be part of the messaging data model. The data implied by the operatio= nal requirements O6, O7, O10, O11, O12, O13 (the response code), O14, O15, = O16, O17, O18 (less location), O19 (less location) and O22 would be part of= the administration data model. The data implied by the operational requir= ements O2, O8, O9, O11, O13 (the channel list) and O21 would be part of the= spectrum data model. To clarify the use of three data models I would make changes to the require= ments. Data Requirements "D11: The Data Model MUST be subdivided into three parts, messaging, admin= istration, and spectrum. There shall be one schema for the messaging part.= There may be multiple schemas for the administration and spectrum parts d= ifferentiated by regulatory domain." I would modify all the data requirements, less D2, D3, and D4, to explicitl= y state "as required by the regulatory domain." Also some data requirement= s might be softened and listed as examples, for example in D1, I doubt that= the North American Datum of 1983 would be relevant to European administrat= ions. Protocol Requirements In general, I would add to the requirements an explicit mention of the diff= erent data schemas and would specify messaging to resolve the schemas that = are used. Possibly before P3, I would add the requirement: P.X The protocol MUST support the use of multiple administrative and spect= rum data models. And, then extend P.3 as follows: P.3 The protocol MUST support determination of the regulatory domain govern= ing its current location and the administration and spectrum data models th= at are to be used. Other protocol requirements may be softened to acknowledge that requirement= s vary by regulatory domain. There would likely be some additional changes in the operational requiremen= ts but before I suggest any I would prefer to get some feedback. If this i= s acceptable, I would be glad to prepare a revised list of requirements wit= h the tweaks to support the separate data models and differentiation by reg= ulatory domain. John Stine From nbravin@earthlink.net Fri Feb 24 17:23:13 2012 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 268B411E8074 for ; Fri, 24 Feb 2012 17:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuSRXJtJHAXM for ; Fri, 24 Feb 2012 17:23:12 -0800 (PST) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id 42E7211E8072 for ; Fri, 24 Feb 2012 17:23:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=fQKyuxebRqDcig8+RsauRGs2M0UlTgpIa4+fezQStM73gP9I6HFoqPb0kLvn23Oz; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [98.150.41.129] (helo=[10.0.1.2]) by elasmtp-junco.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1S16Lv-0006R0-BI; Fri, 24 Feb 2012 20:23:11 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nancy Bravin In-Reply-To: <2782C93FD2244441893673F3F91281921144B1@IMCMBX01.MITRE.ORG> Date: Fri, 24 Feb 2012 17:23:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4F9330A8-5147-4402-A886-DCB1BCB19298@earthlink.net> References: <2782C93FD2244441893673F3F91281921144B1@IMCMBX01.MITRE.ORG> To: "Stine, John A." X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86a9372f6088680e9341393eab0fd639e5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 98.150.41.129 Cc: "paws@ietf.org" Subject: Re: [paws] Requirements and Multiple Data Models 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, 25 Feb 2012 01:23:13 -0000 John, all =46rom a business strategy point of view it allows for more innovation = with the ability to have more things in scope of the DB's, the = management of, and its parts as described below. It seems to broaden the horizon of what will be possible into a sensible = path. No longer will coexistence be out of scope, or the many possible = uses that one can only dream of at this moment that a DB group can do, or the many = different uses that could be used in whitespace.=20 My 2 cents.. SIncerely, Nancy On Feb 24, 2012, at 2:37 PM, Stine, John A. wrote: > I wrote previously about the goodness of dividing data models into at = least two halves, the data that describes the spectrum use and the data = that is necessary for the business processes of resolving what spectrum = a device may use. On further thought, I believe we should divide the = data into three parts, the data required for messaging and trust, the = particular administrative data required by a regulatory domain, and the = data defining the spectrum. The purpose of separating these data models = is to allow growth of the whitespace concept. =20 >=20 > The motivation for separating out the messaging data is to allow the = messaging data to be very broadly applied to all types of whitespace = management for all regulatory domains. This part of the standard would = be expanded as new capabilities are added. >=20 > The purpose for separating out the administrative data is to allow = each regulatory domain to specify and to modify their data requirements = without having international ramifications. We may want this data model = to convey particular regulatory requirements obtaining and keeping = authorization to use channels. >=20 > The purpose for separating out the spectrum data is to make it = independent of any particular business processes. This is very = important for expansion where the spectrum data model is used to trade = spectrum, arbitrate coexistence, or give policy to cognitive radios. = The spectrum models may be changed in whole based on whether and how = spectrum coexistence is managed.=20 >=20 > Using the requirements sent out earlier this week in=20 >=20 > http://www.ietf.org/mail-archive/web/paws/current/msg00775.html >=20 > this is my take on how the requirements would affect the different = data models. >=20 > The data requirements D2, D3, and D4 would be part of the messaging = data model. The data requirements D5, D6, and D8 would be part of the = administrative data. The data requirements D1, D7, D9, and D10 would be = part of the spectrum use model. =20 >=20 > The data elements implied by the protocol requirements, P1, P2, P3, = P4, P5, P6, P7, P8, P9, P11, P15, P16, and P18 would be included in the = messaging data model. The data implied by the protocol requirement P12 = (less location), P14 (less location), P17, and P19 would be included in = the administration data models. The data implied by the protocol = requirements p13, P19, and P20 would be included in the spectrum data = model. Location would be defined in the spectrum data model. >=20 > The data implied by the operational requirements O1, O2, O4, O5, and = O20, would be part of the messaging data model. The data implied by the = operational requirements O6, O7, O10, O11, O12, O13 (the response code), = O14, O15, O16, O17, O18 (less location), O19 (less location) and O22 = would be part of the administration data model. The data implied by the = operational requirements O2, O8, O9, O11, O13 (the channel list) and O21 = would be part of the spectrum data model. >=20 > To clarify the use of three data models I would make changes to the = requirements. >=20 > Data Requirements >=20 > >=20 > "D11: The Data Model MUST be subdivided into three parts, messaging, = administration, and spectrum. There shall be one schema for the = messaging part. There may be multiple schemas for the administration = and spectrum parts differentiated by regulatory domain." >=20 > I would modify all the data requirements, less D2, D3, and D4, to = explicitly state "as required by the regulatory domain." Also some data = requirements might be softened and listed as examples, for example in = D1, I doubt that the North American Datum of 1983 would be relevant to = European administrations. >=20 > Protocol Requirements >=20 > In general, I would add to the requirements an explicit mention of the = different data schemas and would specify messaging to resolve the = schemas that are used. >=20 > Possibly before P3, I would add the requirement: >=20 > P.X The protocol MUST support the use of multiple administrative and = spectrum data models. >=20 > And, then extend P.3 as follows: >=20 > P.3 The protocol MUST support determination of the regulatory domain = governing its current location and the administration and spectrum data = models that are to be used. >=20 > Other protocol requirements may be softened to acknowledge that = requirements vary by regulatory domain. >=20 > There would likely be some additional changes in the operational = requirements but before I suggest any I would prefer to get some = feedback. If this is acceptable, I would be glad to prepare a revised = list of requirements with the tweaks to support the separate data models = and differentiation by regulatory domain. >=20 > John Stine >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From teco@inf-net.nl Sun Feb 26 13:41:15 2012 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 2EF0321F8534 for ; Sun, 26 Feb 2012 13:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=-1.407, BAYES_50=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxHL85DGEDgF for ; Sun, 26 Feb 2012 13:41:13 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEDB21F84C5 for ; Sun, 26 Feb 2012 13:41:12 -0800 (PST) Received: by eeke51 with SMTP id e51so577669eek.31 for ; Sun, 26 Feb 2012 13:41:11 -0800 (PST) Received-SPF: pass (google.com: domain of teco@inf-net.nl designates 10.14.101.6 as permitted sender) client-ip=10.14.101.6; Authentication-Results: mr.google.com; spf=pass (google.com: domain of teco@inf-net.nl designates 10.14.101.6 as permitted sender) smtp.mail=teco@inf-net.nl Received: from mr.google.com ([10.14.101.6]) by 10.14.101.6 with SMTP id a6mr6633722eeg.27.1330292471906 (num_hops = 1); Sun, 26 Feb 2012 13:41:11 -0800 (PST) Received: by 10.14.101.6 with SMTP id a6mr4983438eeg.27.1330292471718; Sun, 26 Feb 2012 13:41:11 -0800 (PST) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id r5sm37490680eef.6.2012.02.26.13.41.10 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 26 Feb 2012 13:41:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Sun, 26 Feb 2012 22:41:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <550B1C32-C5EB-43DB-8406-F3E57A94A0C2@inf-net.nl> References: To: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkD6VDfEBWfF/PJAgQpZUS35Wtoa2IdL0acL42OKq7mS/XEWeoEBYQFAIOM6H2eNs86Dixa Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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: Sun, 26 Feb 2012 21:41:15 -0000 Hi Scott, I still think it is a MUST for the protocol, and a MAY for usage. Thanks, Teco Op 24 feb. 2012, om 19:58 heeft = het volgende geschreven: > Hello Teco, >=20 > Since PAWS is a global standard, registration for all regulatory = domains > must be supported. While the FCC does require all of the variables = listed > in P.10, other regulatory domains may not require each of those = variables. > So for requirements on the protocol, using MAY enables the FCC to = require > these variables while allowing other regulators to select a subset, or > even different, variables. >=20 > With this explanation, are you okay with MAY in P.10? >=20 > Kind Regards, > Scott >=20 >=20 >=20 > On 2/22/12 1:34 AM, "ext Teco Boot" wrote: >=20 >> Scott, Ray, >>=20 >> The P.* are mostly MUST requirements for the protocol. That's fine. >> Except P.10, this is a MAY operational requirement. The protocol >> MUST support it. >>=20 >> I'm fine with the rest of it. >>=20 >> Is noted somewhere that we (IETF) do our best to support as many >> regulator rules as possible, and leave setting up requirements for >> actual deployment up to the mandated authorities? This makes the >> O.* requirements informational. >>=20 >> Thanks, Teco >>=20 >>=20 >> Op 22 feb. 2012, om 00:53 heeft >> het volgende geschreven: >>=20 >>> Hello All, >>>=20 >>> I have revised Section 6 of the I-D which describes the Data Model >>> Requirements, Protocol Requirements and Operational Requirements. = This >>> includes the requirements from the threat model >>> (http://www.ietf.org/mail-archive/web/paws/current/msg00771.html). >>>=20 >>> The requirements are ordered "top down" to follow the previous = sections >>> of >>> the document: requirements derived from discovery are followed by >>> requirements derived from registration are followed by requirements >>> derived from hotspot, etc... >>>=20 >>> Please review the proposed text, we hope to have your comments by = Feb >>> 28th. >>>=20 >>> Kind Regards, >>>=20 >>> Raj & Scott >>>=20 >>>=20 >>>=20 >>>=20 >>> D. Data Model Requirements: >>>=20 >>>=20 >>> requirements related to discovery function >>> D.1: The Data Model MUST support specifying the location of the WSD, = the >>> uncertainty in meters, the height & its uncertainty, and confidence = in >>> percentage for the location determination. The Data Model MUST = support >>> both North American Datum of 1983 and WGS84. >>>=20 >>>=20 >>> D.2: The Data Model MUST support specifying the URI address of a = white >>> space database. >>>=20 >>>=20 >>> D.3: The Data Model MUST support specifying the URI address of a >>> national >>> listing service. >>>=20 >>>=20 >>> D.4: The Data Model MUST support specifying regulatory domain and = its >>> corresponding data requirements. >>>=20 >>>=20 >>>=20 >>> requirements related to registration function >>> D.5: The Data Model MUST support specifying an ID of the transmitter >>> device. This ID would contain the ID of the transmitter device that = has >>> been certified by a regulatory body for its regulatory domain. The = Data >>> Model MUST support a device class. >>>=20 >>>=20 >>>=20 >>> D.6: The Data Model MUST support specifying a manufacturer=B9s = serial >>> number >>> for a master device. >>>=20 >>>=20 >>> D.7: The Data Model MUST support specifying the antenna and = radiation >>> related parameters of the device, such as: >>>=20 >>> - antenna height >>>=20 >>> - antenna gain >>>=20 >>> - maximum output power, EIRP (dBm) >>>=20 >>> - antenna radiation pattern (directional dependence >>> of the strength of the radio signal from the antenna) >>>=20 >>> - spectrum mask with lowest and highest possible frequency >>>=20 >>> - spectrum mask in dBr from peak transmit power in EIRP, >>> with specific power limit at any frequency linearly >>> interpolated between adjacent points of the spectrum mask >>> measurement resolution bandwidth for EIRP measurements. >>>=20 >>>=20 >>>=20 >>> D.8: The Data Model MUST support specifying owner and operator = contact >>> information for a transmitter. This includes the name of the = transmitter >>> owner, name of transmitter operator, postal address, email address = and >>> phone number of the transmitter operator. >>>=20 >>>=20 >>>=20 >>>=20 >>> requirements related to hotspot use case >>> D.9: The Data Model MUST support specifying a list of available >>> channels. >>> The Data Model MUST support specification of this information by = channel >>> numbers and by start and stop frequencies. The Data Model MUST = support a >>> channel availability schedule and maximum power level for each = channel >>> in >>> the list. >>>=20 >>>=20 >>>=20 >>> requirements related to mobility use case >>> D.10: The Data Model MUST support specifying channel availability >>> information for a single location and an area (e.g. a polygon = defined by >>> multiple location points or a geometric shape such as a circle). >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> P. Protocol Requirements: >>>=20 >>>=20 >>> requirements related to discovery function >>> P.1: The protocol MUST provide a message sequence for the master = device >>> to >>> discover a white space database that provides service at its current >>> location. >>>=20 >>>=20 >>> P.2: The protocol MUST support access of a database directly. The >>> protocol >>> MUST support access of a database using a listing approved by a = national >>> regulator. >>>=20 >>>=20 >>> P.3: The protocol MUST support determination of regulatory domain >>> governing its current location. >>>=20 >>>=20 >>> requirements related to threat model >>>=20 >>>=20 >>> P.4: The protocol MUST provide the ability for the database to >>> authenticate the master device. >>>=20 >>>=20 >>> P.5: The protocol MUST provide the ability for the master device to >>> verify >>> the authenticity of the database with which it is interacting. >>>=20 >>>=20 >>> P.6: The messages sent by the master device to the database MUST be >>> integrity protected. >>>=20 >>>=20 >>> P.7: The messages sent by the database to the master device MUST be >>> integrity protected. >>>=20 >>>=20 >>> P.8: The protocol MUST provide the capability for messages sent by = the >>> master device and database to be encrypted. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> requirements related to registration function >>> P.9: The protocol MUST support the master device registering with = the >>> database. >>>=20 >>>=20 >>> P.10: The registration signaling MAY include the Device ID, >>> manufacturer=B9s >>> serial number, device location, device antenna characteristic >>> information, >>> name of individual or business that owns the device, name, address, >>> email >>> address and phone number of a contact person who is responsible for >>> device >>> operation. >>>=20 >>>=20 >>> P.11: The protocol MUST support a registration acknowledgement = including >>> appropriate result codes. >>>=20 >>>=20 >>>=20 >>>=20 >>> requirements related to hotspot use case >>> P.12: The protocol MUST support a channel query request from the = master >>> device to the database. The channel query request message MUST = include >>> parameters as required by local regulatory requirement. These = parameters >>> MAY include device location, device ID, manufacturer=B9s serial = number, >>> and >>> antenna characteristic information. >>>=20 >>>=20 >>> P.13: The protocol MUST support a channel query response from the >>> database >>> to the master device. The channel query response message MUST = include >>> parameters as required by local regulatory requirement. These = parameters >>> MAY include available channels, duration of time for their use, >>> associated >>> maximum power levels, any additional sensing requirements. >>>=20 >>>=20 >>> P.14: The protocol MUST support a channel query request from the = slave >>> device to the master device. The channel query request message MUST >>> include parameters as required by local regulatory requirement. = These >>> parameters MAY include device ID and slave device location. >>>=20 >>>=20 >>> P.15: The protocol MUST support a validation request from the master = to >>> the database to validate a slave device. The validation request MUST >>> include the slave device ID. >>>=20 >>>=20 >>> P.16: The protocol MUST support a validation response from the = database >>> to >>> the master. The validation response MUST include a response code. >>>=20 >>>=20 >>> P.17: The protocol MUST support a channel query response from the = master >>> device to the slave device. The channel query response message MUST >>> include parameters as required by local regulatory requirement, >>> including >>> a response code and sufficient information to decode an enabling = signal. >>>=20 >>>=20 >>> P.18: The protocol MUST support an enabling signal sent from the = master >>> to >>> the slave. This signal MUST allow the slave device to validate that = a >>> previously received available channel list is still valid or not. = This >>> signal MUST be encoded to allow the slave device to determine the >>> identity >>> if the sending master device. >>>=20 >>>=20 >>>=20 >>> P.19: The protocol between the master device and the database MUST >>> support >>> the capability to change channel availability lists on short notice. >>>=20 >>>=20 >>>=20 >>> requirements related to mobility use case >>> P.20: The protocol between the master device and the database MUST >>> support >>> a channel availability request which specifies a geographic location = as >>> an >>> area as well as a point. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> O. Operational Requirements: >>>=20 >>>=20 >>> requirements related to discovery function >>>=20 >>> O.1: The database and the master device MUST be connected to the >>> Internet. >>>=20 >>>=20 >>> O.2: A master device MUST be able to determine its location = including >>> uncertainty and confidence level. A fixed master device MAY use a >>> location >>> programmed at installation or have the capability determine its = location >>> to the required accuracy. A mobile master device MUST have the >>> capability >>> to determine its location to the required accuracy. >>>=20 >>>=20 >>> O.3: The master device MUST identify a database for use. The master >>> device >>> MAY select a database for service by discovery at runtime or the = master >>> device MAY select a database for service by means of a = pre-programmed >>> URI >>> address. >>>=20 >>>=20 >>> O.4: The master device MUST implement at least one connection method = to >>> access the database. The master device MAY contact a database = directly >>> for >>> service (e.g. as defined by FCC) or the master device MAY contact a >>> listing server first followed by contact to a database (e.g. As = defined >>> by >>> Ofcom). >>>=20 >>>=20 >>> O.5: The master device MUST obtain an indication the regulatory = domain >>> governing operation at its current location, i.e. the master device = MUST >>> know if it operates under regulations from FCC, Ofcom, etc=8A >>>=20 >>>=20 >>>=20 >>>=20 >>> requirements related to registration function >>> O.6: The master device MAY register with the database according to = local >>> regulatory policy. Not all master devices will be required to = register. >>> Specific events will initiate registration, these events are = determined >>> by >>> regulator policy (e.g. at power up, after movement, etc=8A). >>>=20 >>>=20 >>> O.7: The master device MUST register with its most current and >>> up-to-date >>> information. >>>=20 >>>=20 >>>=20 >>>=20 >>> requirements related to hotspot use case >>> O.8: A master device MUST query the database for the available = channels >>> based on its current location before starting radio transmission in >>> white >>> space. Parameters provided to the database MAY include device = location, >>> accuracy of the location, antenna characteristic information, device >>> identifier of any slave device requesting channel information. >>>=20 >>>=20 >>> O.9: The database MUST respond to an available channel list request = from >>> an authenticated and authorized device and MAY also provide time >>> constraints, maximum output power, start and stop frequencies for = each >>> channel in the list and any additional requirements for sensing. >>>=20 >>>=20 >>> O.10: After connecting to a master device=B9s radio network a slave = device >>> MUST query the master device for a list of available channels. The = slave >>> MUST include parameters required by local regulatory policy, e.g. = device >>> ID, device location. >>>=20 >>>=20 >>> O.11: According to local regulatory policy, the master device MAY = query >>> the database with parameters received from the slave device. >>>=20 >>>=20 >>> O.12: The database MUST respond to a query from the master device >>> containing parameters from a slave device. >>>=20 >>>=20 >>> O.13: After the master device has received a response from the = database, >>> the master device MUST respond to the slave device. If all = regulatory >>> requirements are met the response will contain an available channel >>> list. >>> If regulatory requirements are not met, the response MUST contain at >>> least >>> a response code. >>>=20 >>>=20 >>> O.14: If a master device has provided an available channel list to a >>> slave >>> device the master device MAY send a periodic enabling signal to = allow >>> the >>> slave device to confirm it is still within reception range of the = master >>> device. >>>=20 >>>=20 >>> O.15: The enabling signal MUST be encoded so that the receiving = slave >>> can >>> determine the identity of the sending master. >>>=20 >>>=20 >>> O.16: Periodically, at an interval according to local regulations, = the >>> slave device MUST either receive and enabling signal or MUST >>> successfully >>> repeat the channel request process or MUST cease transmission on the >>> channel. >>>=20 >>>=20 >>> O.17: A master device MUST repeat the query the database for the >>> available >>> channels as often as required by the regulation (eg, FCC requires = once >>> per >>> day) to verify that the operating channels continue to remain = available. >>>=20 >>>=20 >>> O.18: A master device which changes its location more than a = threshold >>> distance specified by local regulatory policy during its operation, = MUST >>> query the database for available operating channels each time it = moves >>> more than the threshold distance (e.g., FCC specifies 100m) from the >>> location it previously made the query. >>>=20 >>>=20 >>>=20 >>> requirements related to wran use case >>> O.19: If slave devices change their location during operation by = more >>> than >>> a limit specified by the local regulator, the slave device MUST = query >>> the >>> master device for available operating channels. >>>=20 >>>=20 >>>=20 >>> requirements related to rapid deployed network use = case>> Note> >>> O.20: According to local regulator policy, a master device may = contact a >>> database via proxy service of another master device. >>>=20 >>>=20 >>>=20 >>> requirements related to mobility use case >>> O.21: A master device MUST be able to query the whitespace database = for >>> channel availability information for a specific expected coverage = area >>> around its current location. >>>=20 >>>=20 >>>=20 >>> requirements related to threat model >>> O.22: A Master device MAY not include its identity in >>> messages sent to the database when not required by the regulatory >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> paws mailing list >>> paws@ietf.org >>> https://www.ietf.org/mailman/listinfo/paws >>=20 >=20 From scott.probasco@nokia.com Mon Feb 27 05:32:32 2012 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 33C9C21F8633 for ; Mon, 27 Feb 2012 05:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.182 X-Spam-Level: X-Spam-Status: No, score=-4.182 tagged_above=-999 required=5 tests=[AWL=1.817, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYqdZGizzIOs for ; Mon, 27 Feb 2012 05:32:30 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1920C21F85DA for ; Mon, 27 Feb 2012 05:32:29 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1RDWQcY026547; Mon, 27 Feb 2012 15:32:27 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.25]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 15:32:24 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-009.mgdnok.nokia.com ([65.54.30.25]) with mapi id 14.01.0355.003; Mon, 27 Feb 2012 14:32:24 +0100 From: To: Thread-Topic: [paws] UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZIdjEAgAN/KwCAA7asgIAApSwA Date: Mon, 27 Feb 2012 13:32:22 +0000 Message-ID: In-Reply-To: <550B1C32-C5EB-43DB-8406-F3E57A94A0C2@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="utf-8" Content-ID: <62779436FF293D43860BA53DD844A6A1@mgd.nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 13:32:24.0307 (UTC) FILETIME=[3D663C30:01CCF554] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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: Mon, 27 Feb 2012 13:32:32 -0000 SGkgVGVjbywNCg0KSWYgd2UgbG9vayBhdCBQLjkgYW5kIFAuMTAgdG9nZXRoZXIsIFAuOSBzYXlz IHRoYXQgcmVnaXN0cmF0aW9uIGlzIGEgTVVTVA0KLS0gdGhlIHByb3RvY29sIHN1cHBvcnRzIHJl Z2lzdHJhdGlvbiB3aXRob3V0IHF1ZXN0aW9uLiBQLjEwIHNheXMgdGhlDQpzaWduYWxpbmcgZm9y IHJlZ2lzdHJhdGlvbiBNQVkgY29udGFpbiBhbnkgb2Ygc2V2ZXJhbCB2YXJpYWJsZXMgKGFsc28N CmFsbG93cyBtb3JlIHZhcmlhYmxlcyB0byBiZSBpbmNsdWRlZCBpZiByZXF1aXJlZCBieSBsb2Nh bCByZWd1bGF0aW9ucykuDQpUaGUgbGlzdCBjdXJyZW50bHkgaWRlbnRpZmllcyBhbGwgdmFyaWFi bGVzIHJlcXVpcmVkIGZvciByZWdpc3RyYXRpb24gaW4NCnRoZSBVUy4gTm93IGlmIHdlIGxvb2sg YXQgdGhlIERhdGEgTW9kZWwgcmVxdWlyZW1lbnRzLCBlYWNoIHZhcmlhYmxlDQppZGVudGlmaWVk IHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBzZXJ2aWNlIE1BWSBjb250YWluICh0aGVzZSBhcmUgaW4g RC41LA0KRC42LCBELjEsIEQuNyBhbmQgRC44KSBNVVNUIGJlIGluY2x1ZGVkIGluIHRoZSBEYXRh IE1vZGVsLiBUaGUgcHJvdG9jb2wNCk1VU1Qgc3VwcG9ydCByZWdpc3RyYXRpb24sIGFuZCB0aGUg RGF0YSBNb2RlbCBpbiB0aGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0DQp0aGUgdmFyaWFibGVzIGlk ZW50aWZpZWQgZm9yIHJlZ2lzdHJhdGlvbiBzZXJ2aWNlLg0KDQpUaGUgY3VycmVudCB1c2Ugb2Yg TVVTVCBpbiBQLjkgYW5kIE1BWSBpbiBQLjEwIGhhcyB0aGUgZWZmZWN0IHRoYXQgV1NEcyBpbg0K dGhlIFVTIGFyZSBhbGxvd2VkIHRvIHJlZ2lzdGVyIChiZWNhdXNlIHRoZSBwcm90b2NvbCBzdXBw b3J0cw0KcmVnaXN0cmF0aW9uKSBhbmQgYXJlIGFsbG93ZWQgdG8gdXNlIHRoZSB2YXJpYWJsZXMg ZGVmaW5lZCBieSB0aGUgRkNDDQooYmVjYXVzZSB0aGUgcmVnaXN0cmF0aW9uIHNpZ25hbGluZyBN QVkgaW5jbHVkZSB0aG9zZSB2YXJpYWJsZXMpLiBUaGlzDQphbHNvIGhhcyB0aGUgZWZmZWN0IHRo YXQgV1NEcyBpbiB0aGUgVUsgKG9yIGVsc2V3aGVyZSBpbiB0aGUgd29ybGQpIGFyZQ0KYWxsb3dl ZCB0byByZWdpc3RlciBpZiB0aGlzIGlzIGEgbG9jYWwgcmVxdWlyZW1lbnQgKGJlY2F1c2UgdGhl IHByb3RvY29sDQpzdXBwb3J0cyByZWdpc3RyYXRpb24pIGFuZCBhcmUgYWxsb3dlZCB0byB1c2Ug KG9yIG5vdCB1c2UpIHRoZSB2YXJpYWJsZXMNCmRlZmluZWQgYnkgdGhlIEZDQyAoYmVjYXVzZSB0 aGUgcmVnaXN0cmF0aW9uIHNpZ25hbGluZyBNQVkgaW5jbHVkZSB0aG9zZQ0KdmFyaWFibGVzKS4g Tm90aGluZyB0byBwcmV2ZW50IGFkZGluZyBtb3JlIHZhcmlhYmxlcyBpZiBuZWVkZWQgYnkgT2Zj b20sDQpJREEsIGV0Yy4uLg0KDQpBbm90aGVyIHBvc3NpYmlsaXR5IGlzIHRvIGNoYW5nZSB0aGUg d29yZGluZyBvZiBQLjEwIHRvIHJlYWQNClAuMTA6IFRoZSByZWdpc3RyYXRpb24gc2lnbmFsaW5n IE1VU1QgaW5jbHVkZSB0aGUgZm9sbG93aW5nIG9wdGlvbmFsDQp2YXJpYWJsZXM6IHRoZSBEZXZp Y2UgSUQsIG1hbnVmYWN0dXJlcsK5cyBzZXJpYWwgbnVtYmVyLCBkZXZpY2UgbG9jYXRpb24sDQpk ZXZpY2UgYW50ZW5uYSBjaGFyYWN0ZXJpc3RpYyBpbmZvcm1hdGlvbiwgbmFtZSBvZiBpbmRpdmlk dWFsIG9yIGJ1c2luZXNzDQp0aGF0IG93bnMgdGhlIGRldmljZSwgbmFtZSwgYWRkcmVzcywgZW1h aWwgYWRkcmVzcyBhbmQgcGhvbmUgbnVtYmVyIG9mIGENCmNvbnRhY3QgcGVyc29uIHdobyBpcyBy ZXNwb25zaWJsZSBmb3IgZGV2aWNlIG9wZXJhdGlvbi4NCg0KV2hhdCBkbyB5b3UgdGhpbms/DQoN CktpbmQgUmVnYXJkcywNClNjb3R0DQoNCg0KDQoNCg0KDQpPbiAyLzI2LzEyIDM6NDEgUE0sICJl eHQgVGVjbyBCb290IiA8dGVjb0BpbmYtbmV0Lm5sPiB3cm90ZToNCg0KPkhpIFNjb3R0LA0KPg0K Pkkgc3RpbGwgdGhpbmsgaXQgaXMgYSBNVVNUIGZvciB0aGUgcHJvdG9jb2wsIGFuZCBhIE1BWSBm b3IgdXNhZ2UuDQo+DQo+VGhhbmtzLCBUZWNvDQo+DQo+T3AgMjQgZmViLiAyMDEyLCBvbSAxOTo1 OCBoZWVmdCA8c2NvdHQucHJvYmFzY29Abm9raWEuY29tPg0KPjxzY290dC5wcm9iYXNjb0Bub2tp YS5jb20+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KPg0KPj4gSGVsbG8gVGVjbywNCj4+IA0K Pj4gU2luY2UgUEFXUyBpcyBhIGdsb2JhbCBzdGFuZGFyZCwgcmVnaXN0cmF0aW9uIGZvciBhbGwg cmVndWxhdG9yeSBkb21haW5zDQo+PiBtdXN0IGJlIHN1cHBvcnRlZC4gV2hpbGUgdGhlIEZDQyBk b2VzIHJlcXVpcmUgYWxsIG9mIHRoZSB2YXJpYWJsZXMNCj4+bGlzdGVkDQo+PiBpbiBQLjEwLCBv dGhlciByZWd1bGF0b3J5IGRvbWFpbnMgbWF5IG5vdCByZXF1aXJlIGVhY2ggb2YgdGhvc2UNCj4+ dmFyaWFibGVzLg0KPj4gU28gZm9yIHJlcXVpcmVtZW50cyBvbiB0aGUgcHJvdG9jb2wsIHVzaW5n IE1BWSBlbmFibGVzIHRoZSBGQ0MgdG8NCj4+cmVxdWlyZQ0KPj4gdGhlc2UgdmFyaWFibGVzIHdo aWxlIGFsbG93aW5nIG90aGVyIHJlZ3VsYXRvcnMgdG8gc2VsZWN0IGEgc3Vic2V0LCBvcg0KPj4g ZXZlbiBkaWZmZXJlbnQsIHZhcmlhYmxlcy4NCj4+IA0KPj4gV2l0aCB0aGlzIGV4cGxhbmF0aW9u LCBhcmUgeW91IG9rYXkgd2l0aCBNQVkgaW4gUC4xMD8NCj4+IA0KPj4gS2luZCBSZWdhcmRzLA0K Pj4gU2NvdHQNCj4+IA0KPj4gDQo+PiANCj4+IE9uIDIvMjIvMTIgMTozNCBBTSwgImV4dCBUZWNv IEJvb3QiIDx0ZWNvQGluZi1uZXQubmw+IHdyb3RlOg0KPj4gDQo+Pj4gU2NvdHQsIFJheSwNCj4+ PiANCj4+PiBUaGUgUC4qIGFyZSBtb3N0bHkgTVVTVCByZXF1aXJlbWVudHMgZm9yIHRoZSBwcm90 b2NvbC4gVGhhdCdzIGZpbmUuDQo+Pj4gRXhjZXB0IFAuMTAsIHRoaXMgaXMgYSBNQVkgb3BlcmF0 aW9uYWwgcmVxdWlyZW1lbnQuIFRoZSBwcm90b2NvbA0KPj4+IE1VU1Qgc3VwcG9ydCBpdC4NCj4+ PiANCj4+PiBJJ20gZmluZSB3aXRoIHRoZSByZXN0IG9mIGl0Lg0KPj4+IA0KPj4+IElzIG5vdGVk IHNvbWV3aGVyZSB0aGF0IHdlIChJRVRGKSBkbyBvdXIgYmVzdCB0byBzdXBwb3J0IGFzIG1hbnkN Cj4+PiByZWd1bGF0b3IgcnVsZXMgYXMgcG9zc2libGUsIGFuZCBsZWF2ZSBzZXR0aW5nIHVwIHJl cXVpcmVtZW50cyBmb3INCj4+PiBhY3R1YWwgZGVwbG95bWVudCB1cCB0byB0aGUgbWFuZGF0ZWQg YXV0aG9yaXRpZXM/IFRoaXMgbWFrZXMgdGhlDQo+Pj4gTy4qIHJlcXVpcmVtZW50cyBpbmZvcm1h dGlvbmFsLg0KPj4+IA0KPj4+IFRoYW5rcywgVGVjbw0KPj4+IA0KPj4+IA0KPj4+IE9wIDIyIGZl Yi4gMjAxMiwgb20gMDA6NTMgaGVlZnQgPHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbT4NCj4+PiA8 c2NvdHQucHJvYmFzY29Abm9raWEuY29tPiBoZXQgdm9sZ2VuZGUgZ2VzY2hyZXZlbjoNCj4+PiAN Cj4+Pj4gSGVsbG8gQWxsLA0KPj4+PiANCj4+Pj4gSSBoYXZlIHJldmlzZWQgU2VjdGlvbiA2IG9m IHRoZSBJLUQgd2hpY2ggZGVzY3JpYmVzIHRoZSBEYXRhIE1vZGVsDQo+Pj4+IFJlcXVpcmVtZW50 cywgUHJvdG9jb2wgUmVxdWlyZW1lbnRzIGFuZCBPcGVyYXRpb25hbCBSZXF1aXJlbWVudHMuIFRo aXMNCj4+Pj4gaW5jbHVkZXMgdGhlIHJlcXVpcmVtZW50cyBmcm9tIHRoZSB0aHJlYXQgbW9kZWwN Cj4+Pj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wYXdzL2N1cnJlbnQv bXNnMDA3NzEuaHRtbCkuDQo+Pj4+IA0KPj4+PiBUaGUgcmVxdWlyZW1lbnRzIGFyZSBvcmRlcmVk ICJ0b3AgZG93biIgdG8gZm9sbG93IHRoZSBwcmV2aW91cw0KPj4+PnNlY3Rpb25zDQo+Pj4+IG9m DQo+Pj4+IHRoZSBkb2N1bWVudDogcmVxdWlyZW1lbnRzIGRlcml2ZWQgZnJvbSBkaXNjb3Zlcnkg YXJlIGZvbGxvd2VkIGJ5DQo+Pj4+IHJlcXVpcmVtZW50cyBkZXJpdmVkIGZyb20gcmVnaXN0cmF0 aW9uIGFyZSBmb2xsb3dlZCBieSByZXF1aXJlbWVudHMNCj4+Pj4gZGVyaXZlZCBmcm9tIGhvdHNw b3QsIGV0Yy4uLg0KPj4+PiANCj4+Pj4gUGxlYXNlIHJldmlldyB0aGUgcHJvcG9zZWQgdGV4dCwg d2UgaG9wZSB0byBoYXZlIHlvdXIgY29tbWVudHMgYnkgRmViDQo+Pj4+IDI4dGguDQo+Pj4+IA0K Pj4+PiBLaW5kIFJlZ2FyZHMsDQo+Pj4+IA0KPj4+PiBSYWogJiBTY290dA0KPj4+PiANCj4+Pj4g DQo+Pj4+IA0KPj4+PiANCj4+Pj4gRC4gRGF0YSBNb2RlbCBSZXF1aXJlbWVudHM6DQo+Pj4+IA0K Pj4+PiANCj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGRpc2NvdmVyeSBm dW5jdGlvbjwvRWQuIE5vdGU+DQo+Pj4+IEQuMTogVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0 IHNwZWNpZnlpbmcgdGhlIGxvY2F0aW9uIG9mIHRoZSBXU0QsDQo+Pj4+dGhlDQo+Pj4+IHVuY2Vy dGFpbnR5IGluIG1ldGVycywgdGhlIGhlaWdodCAmIGl0cyB1bmNlcnRhaW50eSwgYW5kIGNvbmZp ZGVuY2UgaW4NCj4+Pj4gcGVyY2VudGFnZSBmb3IgdGhlIGxvY2F0aW9uIGRldGVybWluYXRpb24u IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydA0KPj4+PiBib3RoIE5vcnRoIEFtZXJpY2FuIERh dHVtIG9mIDE5ODMgYW5kIFdHUzg0Lg0KPj4+PiANCj4+Pj4gDQo+Pj4+IEQuMjogVGhlIERhdGEg TW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgdGhlIFVSSSBhZGRyZXNzIG9mIGEgd2hpdGUN Cj4+Pj4gc3BhY2UgZGF0YWJhc2UuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gRC4zOiBUaGUgRGF0YSBN b2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyB0aGUgVVJJIGFkZHJlc3Mgb2YgYQ0KPj4+PiBu YXRpb25hbA0KPj4+PiBsaXN0aW5nIHNlcnZpY2UuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gRC40OiBU aGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyAgcmVndWxhdG9yeSBkb21haW4g YW5kIGl0cw0KPj4+PiBjb3JyZXNwb25kaW5nIGRhdGEgcmVxdWlyZW1lbnRzLg0KPj4+PiANCj4+ Pj4gDQo+Pj4+IA0KPj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gcmVnaXN0 cmF0aW9uIGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+Pj4gRC41OiBUaGUgRGF0YSBNb2RlbCBNVVNU IHN1cHBvcnQgc3BlY2lmeWluZyBhbiBJRCBvZiB0aGUgdHJhbnNtaXR0ZXINCj4+Pj4gZGV2aWNl LiBUaGlzIElEIHdvdWxkIGNvbnRhaW4gdGhlIElEIG9mIHRoZSB0cmFuc21pdHRlciBkZXZpY2Ug dGhhdA0KPj4+Pmhhcw0KPj4+PiBiZWVuIGNlcnRpZmllZCBieSBhIHJlZ3VsYXRvcnkgYm9keSBm b3IgaXRzIHJlZ3VsYXRvcnkgZG9tYWluLiBUaGUNCj4+Pj5EYXRhDQo+Pj4+IE1vZGVsIE1VU1Qg c3VwcG9ydCBhIGRldmljZSBjbGFzcy4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gRC42OiBU aGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhIG1hbnVmYWN0dXJlcsK5cyBz ZXJpYWwNCj4+Pj4gbnVtYmVyDQo+Pj4+IGZvciBhIG1hc3RlciBkZXZpY2UuDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gRC43OiAgVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgdGhl IGFudGVubmEgYW5kIHJhZGlhdGlvbg0KPj4+PiByZWxhdGVkIHBhcmFtZXRlcnMgb2YgdGhlIGRl dmljZSwgc3VjaCBhczoNCj4+Pj4gDQo+Pj4+ICAtIGFudGVubmEgaGVpZ2h0DQo+Pj4+IA0KPj4+ PiAgLSBhbnRlbm5hIGdhaW4NCj4+Pj4gDQo+Pj4+ICAtIG1heGltdW0gb3V0cHV0IHBvd2VyLCBF SVJQIChkQm0pDQo+Pj4+IA0KPj4+PiAgLSBhbnRlbm5hIHJhZGlhdGlvbiBwYXR0ZXJuIChkaXJl Y3Rpb25hbCBkZXBlbmRlbmNlDQo+Pj4+ICAgIG9mIHRoZSBzdHJlbmd0aCBvZiB0aGUgcmFkaW8g c2lnbmFsIGZyb20gdGhlIGFudGVubmEpDQo+Pj4+IA0KPj4+PiAgLSBzcGVjdHJ1bSBtYXNrIHdp dGggbG93ZXN0IGFuZCBoaWdoZXN0IHBvc3NpYmxlIGZyZXF1ZW5jeQ0KPj4+PiANCj4+Pj4gIC0g c3BlY3RydW0gbWFzayBpbiBkQnIgZnJvbSBwZWFrIHRyYW5zbWl0IHBvd2VyIGluIEVJUlAsDQo+ Pj4+ICAgIHdpdGggc3BlY2lmaWMgcG93ZXIgbGltaXQgYXQgYW55IGZyZXF1ZW5jeSBsaW5lYXJs eQ0KPj4+PiAgICBpbnRlcnBvbGF0ZWQgYmV0d2VlbiBhZGphY2VudCBwb2ludHMgb2YgdGhlIHNw ZWN0cnVtIG1hc2sNCj4+Pj4gICAgbWVhc3VyZW1lbnQgcmVzb2x1dGlvbiBiYW5kd2lkdGggZm9y IEVJUlAgbWVhc3VyZW1lbnRzLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBELjg6IFRoZSBE YXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIG93bmVyIGFuZCBvcGVyYXRvciBjb250 YWN0DQo+Pj4+IGluZm9ybWF0aW9uIGZvciBhIHRyYW5zbWl0dGVyLiBUaGlzIGluY2x1ZGVzIHRo ZSBuYW1lIG9mIHRoZQ0KPj4+PnRyYW5zbWl0dGVyDQo+Pj4+IG93bmVyLCBuYW1lIG9mIHRyYW5z bWl0dGVyIG9wZXJhdG9yLCBwb3N0YWwgYWRkcmVzcywgZW1haWwgYWRkcmVzcyBhbmQNCj4+Pj4g cGhvbmUgbnVtYmVyIG9mIHRoZSB0cmFuc21pdHRlciBvcGVyYXRvci4NCj4+Pj4gDQo+Pj4+IA0K Pj4+PiANCj4+Pj4gDQo+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBob3Rz cG90IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+Pj4gRC45OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1 cHBvcnQgc3BlY2lmeWluZyBhIGxpc3Qgb2YgYXZhaWxhYmxlDQo+Pj4+IGNoYW5uZWxzLg0KPj4+ PiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0aGlzIGluZm9y bWF0aW9uIGJ5DQo+Pj4+Y2hhbm5lbA0KPj4+PiBudW1iZXJzIGFuZCBieSBzdGFydCBhbmQgc3Rv cCBmcmVxdWVuY2llcy4gVGhlIERhdGEgTW9kZWwgTVVTVA0KPj4+PnN1cHBvcnQgYQ0KPj4+PiBj aGFubmVsIGF2YWlsYWJpbGl0eSBzY2hlZHVsZSBhbmQgbWF4aW11bSBwb3dlciBsZXZlbCBmb3Ig ZWFjaCBjaGFubmVsDQo+Pj4+IGluDQo+Pj4+IHRoZSBsaXN0Lg0KPj4+PiANCj4+Pj4gDQo+Pj4+ IA0KPj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gbW9iaWxpdHkgdXNlIGNh c2U8L0VkLiBOb3RlPg0KPj4+PiBELjEwOiAgVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNw ZWNpZnlpbmcgY2hhbm5lbCBhdmFpbGFiaWxpdHkNCj4+Pj4gaW5mb3JtYXRpb24gZm9yIGEgc2lu Z2xlIGxvY2F0aW9uIGFuZCBhbiBhcmVhIChlLmcuIGEgcG9seWdvbiBkZWZpbmVkDQo+Pj4+YnkN Cj4+Pj4gbXVsdGlwbGUgbG9jYXRpb24gcG9pbnRzIG9yIGEgZ2VvbWV0cmljIHNoYXBlIHN1Y2gg YXMgYSBjaXJjbGUpLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IFAu IFByb3RvY29sIFJlcXVpcmVtZW50czoNCj4+Pj4gDQo+Pj4+IA0KPj4+PiA8RWQuIE5vdGU+cmVx dWlyZW1lbnRzIHJlbGF0ZWQgdG8gZGlzY292ZXJ5IGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+Pj4g UC4xOiBUaGUgcHJvdG9jb2wgTVVTVCBwcm92aWRlIGEgbWVzc2FnZSBzZXF1ZW5jZSBmb3IgdGhl IG1hc3Rlcg0KPj4+PmRldmljZQ0KPj4+PiB0bw0KPj4+PiBkaXNjb3ZlciBhIHdoaXRlIHNwYWNl IGRhdGFiYXNlIHRoYXQgcHJvdmlkZXMgc2VydmljZSBhdCBpdHMgY3VycmVudA0KPj4+PiBsb2Nh dGlvbi4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBQLjI6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQg YWNjZXNzIG9mIGEgZGF0YWJhc2UgZGlyZWN0bHkuIFRoZQ0KPj4+PiBwcm90b2NvbA0KPj4+PiBN VVNUIHN1cHBvcnQgYWNjZXNzIG9mIGEgZGF0YWJhc2UgdXNpbmcgYSBsaXN0aW5nIGFwcHJvdmVk IGJ5IGENCj4+Pj5uYXRpb25hbA0KPj4+PiByZWd1bGF0b3IuDQo+Pj4+IA0KPj4+PiANCj4+Pj4g UC4zOiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGRldGVybWluYXRpb24gb2YgcmVndWxhdG9y eSBkb21haW4NCj4+Pj4gZ292ZXJuaW5nIGl0cyBjdXJyZW50IGxvY2F0aW9uLg0KPj4+PiANCj4+ Pj4gDQo+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byB0aHJlYXQgbW9kZWw8 L0VkLiBOb3RlPg0KPj4+PiANCj4+Pj4gDQo+Pj4+IFAuNDogVGhlIHByb3RvY29sIE1VU1QgcHJv dmlkZSB0aGUgYWJpbGl0eSBmb3IgdGhlIGRhdGFiYXNlIHRvDQo+Pj4+IGF1dGhlbnRpY2F0ZSB0 aGUgbWFzdGVyIGRldmljZS4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBQLjU6IFRoZSBwcm90b2NvbCBN VVNUIHByb3ZpZGUgdGhlIGFiaWxpdHkgZm9yIHRoZSBtYXN0ZXIgZGV2aWNlIHRvDQo+Pj4+IHZl cmlmeQ0KPj4+PiB0aGUgYXV0aGVudGljaXR5IG9mIHRoZSBkYXRhYmFzZSB3aXRoIHdoaWNoIGl0 IGlzIGludGVyYWN0aW5nLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IFAuNjogVGhlIG1lc3NhZ2VzIHNl bnQgYnkgdGhlIG1hc3RlciBkZXZpY2UgdG8gdGhlIGRhdGFiYXNlIE1VU1QgYmUNCj4+Pj4gaW50 ZWdyaXR5IHByb3RlY3RlZC4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBQLjc6IFRoZSBtZXNzYWdlcyBz ZW50IGJ5IHRoZSBkYXRhYmFzZSB0byB0aGUgbWFzdGVyIGRldmljZSBNVVNUIGJlDQo+Pj4+IGlu dGVncml0eSBwcm90ZWN0ZWQuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gUC44OiBUaGUgcHJvdG9jb2wg TVVTVCBwcm92aWRlIHRoZSBjYXBhYmlsaXR5IGZvciBtZXNzYWdlcyBzZW50IGJ5IHRoZQ0KPj4+ PiBtYXN0ZXIgZGV2aWNlIGFuZCBkYXRhYmFzZSB0byBiZSBlbmNyeXB0ZWQuDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVu dHMgcmVsYXRlZCB0byByZWdpc3RyYXRpb24gZnVuY3Rpb248L0VkLiBOb3RlPg0KPj4+PiBQLjk6 IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgdGhlIG1hc3RlciBkZXZpY2UgcmVnaXN0ZXJpbmcg d2l0aCB0aGUNCj4+Pj4gZGF0YWJhc2UuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gUC4xMDogVGhlIHJl Z2lzdHJhdGlvbiBzaWduYWxpbmcgTUFZIGluY2x1ZGUgdGhlIERldmljZSBJRCwNCj4+Pj4gbWFu dWZhY3R1cmVywrlzDQo+Pj4+IHNlcmlhbCBudW1iZXIsIGRldmljZSBsb2NhdGlvbiwgZGV2aWNl IGFudGVubmEgY2hhcmFjdGVyaXN0aWMNCj4+Pj4gaW5mb3JtYXRpb24sDQo+Pj4+IG5hbWUgb2Yg aW5kaXZpZHVhbCBvciBidXNpbmVzcyB0aGF0IG93bnMgdGhlIGRldmljZSwgbmFtZSwgYWRkcmVz cywNCj4+Pj4gZW1haWwNCj4+Pj4gYWRkcmVzcyBhbmQgcGhvbmUgbnVtYmVyIG9mIGEgY29udGFj dCBwZXJzb24gd2hvIGlzIHJlc3BvbnNpYmxlIGZvcg0KPj4+PiBkZXZpY2UNCj4+Pj4gb3BlcmF0 aW9uLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IFAuMTE6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQg YSByZWdpc3RyYXRpb24gYWNrbm93bGVkZ2VtZW50DQo+Pj4+aW5jbHVkaW5nDQo+Pj4+IGFwcHJv cHJpYXRlIHJlc3VsdCBjb2Rlcy4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IDxF ZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBob3RzcG90IHVzZSBjYXNlPC9FZC4gTm90 ZT4NCj4+Pj4gUC4xMjogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgcXVlcnkg cmVxdWVzdCBmcm9tIHRoZQ0KPj4+Pm1hc3Rlcg0KPj4+PiBkZXZpY2UgdG8gdGhlIGRhdGFiYXNl LiBUaGUgY2hhbm5lbCBxdWVyeSByZXF1ZXN0IG1lc3NhZ2UgTVVTVCBpbmNsdWRlDQo+Pj4+IHBh cmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4gVGhl c2UNCj4+Pj5wYXJhbWV0ZXJzDQo+Pj4+IE1BWSBpbmNsdWRlIGRldmljZSBsb2NhdGlvbiwgZGV2 aWNlIElELCBtYW51ZmFjdHVyZXLCuXMgc2VyaWFsIG51bWJlciwNCj4+Pj4gYW5kDQo+Pj4+IGFu dGVubmEgY2hhcmFjdGVyaXN0aWMgaW5mb3JtYXRpb24uDQo+Pj4+IA0KPj4+PiANCj4+Pj4gUC4x MzogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgcXVlcnkgcmVzcG9uc2UgZnJv bSB0aGUNCj4+Pj4gZGF0YWJhc2UNCj4+Pj4gdG8gdGhlIG1hc3RlciBkZXZpY2UuIFRoZSBjaGFu bmVsIHF1ZXJ5IHJlc3BvbnNlIG1lc3NhZ2UgTVVTVCBpbmNsdWRlDQo+Pj4+IHBhcmFtZXRlcnMg YXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4gVGhlc2UNCj4+Pj5w YXJhbWV0ZXJzDQo+Pj4+IE1BWSBpbmNsdWRlIGF2YWlsYWJsZSBjaGFubmVscywgZHVyYXRpb24g b2YgdGltZSBmb3IgdGhlaXIgdXNlLA0KPj4+PiBhc3NvY2lhdGVkDQo+Pj4+IG1heGltdW0gcG93 ZXIgbGV2ZWxzLCBhbnkgYWRkaXRpb25hbCBzZW5zaW5nIHJlcXVpcmVtZW50cy4NCj4+Pj4gDQo+ Pj4+IA0KPj4+PiBQLjE0OiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCBxdWVy eSByZXF1ZXN0IGZyb20gdGhlIHNsYXZlDQo+Pj4+IGRldmljZSB0byB0aGUgbWFzdGVyIGRldmlj ZS4gVGhlIGNoYW5uZWwgcXVlcnkgcmVxdWVzdCBtZXNzYWdlIE1VU1QNCj4+Pj4gaW5jbHVkZSBw YXJhbWV0ZXJzIGFzIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnQuIFRo ZXNlDQo+Pj4+IHBhcmFtZXRlcnMgTUFZIGluY2x1ZGUgZGV2aWNlIElEIGFuZCBzbGF2ZSBkZXZp Y2UgbG9jYXRpb24uDQo+Pj4+IA0KPj4+PiANCj4+Pj4gUC4xNTogVGhlIHByb3RvY29sIE1VU1Qg c3VwcG9ydCBhIHZhbGlkYXRpb24gcmVxdWVzdCBmcm9tIHRoZSBtYXN0ZXINCj4+Pj50bw0KPj4+ PiB0aGUgZGF0YWJhc2UgdG8gdmFsaWRhdGUgYSBzbGF2ZSBkZXZpY2UuIFRoZSB2YWxpZGF0aW9u IHJlcXVlc3QgTVVTVA0KPj4+PiBpbmNsdWRlIHRoZSBzbGF2ZSBkZXZpY2UgSUQuDQo+Pj4+IA0K Pj4+PiANCj4+Pj4gUC4xNjogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIHZhbGlkYXRpb24g cmVzcG9uc2UgZnJvbSB0aGUNCj4+Pj5kYXRhYmFzZQ0KPj4+PiB0bw0KPj4+PiB0aGUgbWFzdGVy LiBUaGUgdmFsaWRhdGlvbiByZXNwb25zZSBNVVNUIGluY2x1ZGUgYSByZXNwb25zZSBjb2RlLg0K Pj4+PiANCj4+Pj4gDQo+Pj4+IFAuMTc6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFu bmVsIHF1ZXJ5IHJlc3BvbnNlIGZyb20gdGhlDQo+Pj4+bWFzdGVyDQo+Pj4+IGRldmljZSB0byB0 aGUgc2xhdmUgZGV2aWNlLiBUaGUgY2hhbm5lbCBxdWVyeSByZXNwb25zZSBtZXNzYWdlIE1VU1QN Cj4+Pj4gaW5jbHVkZSBwYXJhbWV0ZXJzIGFzIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkg cmVxdWlyZW1lbnQsDQo+Pj4+IGluY2x1ZGluZw0KPj4+PiBhIHJlc3BvbnNlIGNvZGUgYW5kIHN1 ZmZpY2llbnQgaW5mb3JtYXRpb24gdG8gZGVjb2RlIGFuIGVuYWJsaW5nDQo+Pj4+c2lnbmFsLg0K Pj4+PiANCj4+Pj4gDQo+Pj4+IFAuMTg6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYW4gZW5h Ymxpbmcgc2lnbmFsIHNlbnQgZnJvbSB0aGUNCj4+Pj5tYXN0ZXINCj4+Pj4gdG8NCj4+Pj4gdGhl IHNsYXZlLiBUaGlzIHNpZ25hbCBNVVNUIGFsbG93IHRoZSBzbGF2ZSBkZXZpY2UgdG8gdmFsaWRh dGUgdGhhdCBhDQo+Pj4+IHByZXZpb3VzbHkgcmVjZWl2ZWQgYXZhaWxhYmxlIGNoYW5uZWwgbGlz dCBpcyBzdGlsbCB2YWxpZCBvciBub3QuIFRoaXMNCj4+Pj4gc2lnbmFsIE1VU1QgYmUgZW5jb2Rl ZCB0byBhbGxvdyB0aGUgc2xhdmUgZGV2aWNlIHRvIGRldGVybWluZSB0aGUNCj4+Pj4gaWRlbnRp dHkNCj4+Pj4gaWYgdGhlIHNlbmRpbmcgbWFzdGVyIGRldmljZS4NCj4+Pj4gDQo+Pj4+IA0KPj4+ PiANCj4+Pj4gUC4xOTogVGhlIHByb3RvY29sIGJldHdlZW4gdGhlIG1hc3RlciBkZXZpY2UgYW5k IHRoZSBkYXRhYmFzZSBNVVNUDQo+Pj4+IHN1cHBvcnQNCj4+Pj4gdGhlIGNhcGFiaWxpdHkgdG8g Y2hhbmdlIGNoYW5uZWwgYXZhaWxhYmlsaXR5IGxpc3RzIG9uIHNob3J0IG5vdGljZS4NCj4+Pj4g DQo+Pj4+IA0KPj4+PiANCj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIG1v YmlsaXR5IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+Pj4gUC4yMDogVGhlIHByb3RvY29sIGJldHdl ZW4gdGhlIG1hc3RlciBkZXZpY2UgYW5kIHRoZSBkYXRhYmFzZSBNVVNUDQo+Pj4+IHN1cHBvcnQN Cj4+Pj4gYSBjaGFubmVsIGF2YWlsYWJpbGl0eSByZXF1ZXN0IHdoaWNoIHNwZWNpZmllcyBhIGdl b2dyYXBoaWMgbG9jYXRpb24NCj4+Pj5hcw0KPj4+PiBhbg0KPj4+PiBhcmVhIGFzIHdlbGwgYXMg YSBwb2ludC4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPLiBPcGVy YXRpb25hbCBSZXF1aXJlbWVudHM6DQo+Pj4+IA0KPj4+PiANCj4+Pj4gPEVkLiBOb3RlPnJlcXVp cmVtZW50cyByZWxhdGVkIHRvIGRpc2NvdmVyeSBmdW5jdGlvbjwvRWQuIE5vdGU+DQo+Pj4+IA0K Pj4+PiBPLjE6IFRoZSBkYXRhYmFzZSBhbmQgdGhlIG1hc3RlciBkZXZpY2UgTVVTVCBiZSBjb25u ZWN0ZWQgdG8gdGhlDQo+Pj4+IEludGVybmV0Lg0KPj4+PiANCj4+Pj4gDQo+Pj4+IE8uMjogIEEg bWFzdGVyIGRldmljZSBNVVNUIGJlIGFibGUgdG8gZGV0ZXJtaW5lIGl0cyBsb2NhdGlvbiBpbmNs dWRpbmcNCj4+Pj4gdW5jZXJ0YWludHkgYW5kIGNvbmZpZGVuY2UgbGV2ZWwuIEEgZml4ZWQgbWFz dGVyIGRldmljZSBNQVkgdXNlIGENCj4+Pj4gbG9jYXRpb24NCj4+Pj4gcHJvZ3JhbW1lZCBhdCBp bnN0YWxsYXRpb24gb3IgaGF2ZSB0aGUgY2FwYWJpbGl0eSBkZXRlcm1pbmUgaXRzDQo+Pj4+bG9j YXRpb24NCj4+Pj4gdG8gdGhlIHJlcXVpcmVkIGFjY3VyYWN5LiBBIG1vYmlsZSBtYXN0ZXIgZGV2 aWNlIE1VU1QgaGF2ZSB0aGUNCj4+Pj4gY2FwYWJpbGl0eQ0KPj4+PiB0byBkZXRlcm1pbmUgaXRz IGxvY2F0aW9uIHRvIHRoZSByZXF1aXJlZCBhY2N1cmFjeS4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBP LjM6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgaWRlbnRpZnkgYSBkYXRhYmFzZSBmb3IgdXNlLiBU aGUgbWFzdGVyDQo+Pj4+IGRldmljZQ0KPj4+PiBNQVkgc2VsZWN0IGEgZGF0YWJhc2UgZm9yIHNl cnZpY2UgYnkgZGlzY292ZXJ5IGF0IHJ1bnRpbWUgb3IgdGhlDQo+Pj4+bWFzdGVyDQo+Pj4+IGRl dmljZSBNQVkgc2VsZWN0IGEgZGF0YWJhc2UgZm9yIHNlcnZpY2UgYnkgbWVhbnMgb2YgYSBwcmUt cHJvZ3JhbW1lZA0KPj4+PiBVUkkNCj4+Pj4gYWRkcmVzcy4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBP LjQ6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgaW1wbGVtZW50IGF0IGxlYXN0IG9uZSBjb25uZWN0 aW9uIG1ldGhvZA0KPj4+PnRvDQo+Pj4+IGFjY2VzcyB0aGUgZGF0YWJhc2UuIFRoZSBtYXN0ZXIg ZGV2aWNlIE1BWSBjb250YWN0IGEgZGF0YWJhc2UgZGlyZWN0bHkNCj4+Pj4gZm9yDQo+Pj4+IHNl cnZpY2UgKGUuZy4gYXMgZGVmaW5lZCBieSBGQ0MpIG9yIHRoZSBtYXN0ZXIgZGV2aWNlIE1BWSBj b250YWN0IGENCj4+Pj4gbGlzdGluZyBzZXJ2ZXIgZmlyc3QgZm9sbG93ZWQgYnkgY29udGFjdCB0 byBhIGRhdGFiYXNlIChlLmcuIEFzDQo+Pj4+ZGVmaW5lZA0KPj4+PiBieQ0KPj4+PiBPZmNvbSku DQo+Pj4+IA0KPj4+PiANCj4+Pj4gTy41OiBUaGUgbWFzdGVyIGRldmljZSBNVVNUIG9idGFpbiBh biBpbmRpY2F0aW9uIHRoZSByZWd1bGF0b3J5IGRvbWFpbg0KPj4+PiBnb3Zlcm5pbmcgb3BlcmF0 aW9uIGF0IGl0cyBjdXJyZW50IGxvY2F0aW9uLCBpLmUuIHRoZSBtYXN0ZXIgZGV2aWNlDQo+Pj4+ TVVTVA0KPj4+PiBrbm93IGlmIGl0IG9wZXJhdGVzIHVuZGVyIHJlZ3VsYXRpb25zIGZyb20gRkND LCBPZmNvbSwgZXRjxaANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IDxFZC4gTm90 ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byByZWdpc3RyYXRpb24gZnVuY3Rpb248L0VkLiBOb3Rl Pg0KPj4+PiBPLjY6IFRoZSBtYXN0ZXIgZGV2aWNlIE1BWSByZWdpc3RlciB3aXRoIHRoZSBkYXRh YmFzZSBhY2NvcmRpbmcgdG8NCj4+Pj5sb2NhbA0KPj4+PiByZWd1bGF0b3J5IHBvbGljeS4gTm90 IGFsbCBtYXN0ZXIgZGV2aWNlcyB3aWxsIGJlIHJlcXVpcmVkIHRvDQo+Pj4+cmVnaXN0ZXIuDQo+ Pj4+IFNwZWNpZmljIGV2ZW50cyB3aWxsIGluaXRpYXRlIHJlZ2lzdHJhdGlvbiwgdGhlc2UgZXZl bnRzIGFyZQ0KPj4+PmRldGVybWluZWQNCj4+Pj4gYnkNCj4+Pj4gcmVndWxhdG9yIHBvbGljeSAo ZS5nLiBhdCBwb3dlciB1cCwgYWZ0ZXIgbW92ZW1lbnQsIGV0Y8WgKS4NCj4+Pj4gDQo+Pj4+IA0K Pj4+PiBPLjc6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgcmVnaXN0ZXIgd2l0aCBpdHMgbW9zdCBj dXJyZW50IGFuZA0KPj4+PiB1cC10by1kYXRlDQo+Pj4+IGluZm9ybWF0aW9uLg0KPj4+PiANCj4+ Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRv IGhvdHNwb3QgdXNlIGNhc2U8L0VkLiBOb3RlPg0KPj4+PiBPLjg6IEEgbWFzdGVyIGRldmljZSBN VVNUIHF1ZXJ5IHRoZSBkYXRhYmFzZSBmb3IgdGhlIGF2YWlsYWJsZQ0KPj4+PmNoYW5uZWxzDQo+ Pj4+IGJhc2VkIG9uIGl0cyBjdXJyZW50IGxvY2F0aW9uIGJlZm9yZSBzdGFydGluZyByYWRpbyB0 cmFuc21pc3Npb24gaW4NCj4+Pj4gd2hpdGUNCj4+Pj4gc3BhY2UuIFBhcmFtZXRlcnMgcHJvdmlk ZWQgdG8gdGhlIGRhdGFiYXNlIE1BWSBpbmNsdWRlIGRldmljZQ0KPj4+PmxvY2F0aW9uLA0KPj4+ PiBhY2N1cmFjeSBvZiB0aGUgbG9jYXRpb24sIGFudGVubmEgY2hhcmFjdGVyaXN0aWMgaW5mb3Jt YXRpb24sIGRldmljZQ0KPj4+PiBpZGVudGlmaWVyIG9mIGFueSBzbGF2ZSBkZXZpY2UgcmVxdWVz dGluZyBjaGFubmVsIGluZm9ybWF0aW9uLg0KPj4+PiANCj4+Pj4gDQo+Pj4+IE8uOTogVGhlIGRh dGFiYXNlIE1VU1QgcmVzcG9uZCB0byBhbiBhdmFpbGFibGUgY2hhbm5lbCBsaXN0IHJlcXVlc3QN Cj4+Pj5mcm9tDQo+Pj4+IGFuIGF1dGhlbnRpY2F0ZWQgYW5kIGF1dGhvcml6ZWQgZGV2aWNlIGFu ZCBNQVkgYWxzbyBwcm92aWRlIHRpbWUNCj4+Pj4gY29uc3RyYWludHMsIG1heGltdW0gb3V0cHV0 IHBvd2VyLCBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcyBmb3IgZWFjaA0KPj4+PiBjaGFubmVs IGluIHRoZSBsaXN0IGFuZCBhbnkgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgZm9yIHNlbnNpbmcu DQo+Pj4+IA0KPj4+PiANCj4+Pj4gTy4xMDogQWZ0ZXIgY29ubmVjdGluZyB0byBhIG1hc3RlciBk ZXZpY2XCuXMgcmFkaW8gbmV0d29yayBhIHNsYXZlDQo+Pj4+ZGV2aWNlDQo+Pj4+IE1VU1QgcXVl cnkgdGhlIG1hc3RlciBkZXZpY2UgZm9yIGEgbGlzdCBvZiBhdmFpbGFibGUgY2hhbm5lbHMuIFRo ZQ0KPj4+PnNsYXZlDQo+Pj4+IE1VU1QgaW5jbHVkZSBwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5IGxv Y2FsIHJlZ3VsYXRvcnkgcG9saWN5LCBlLmcuDQo+Pj4+ZGV2aWNlDQo+Pj4+IElELCBkZXZpY2Ug bG9jYXRpb24uDQo+Pj4+IA0KPj4+PiANCj4+Pj4gTy4xMTogQWNjb3JkaW5nIHRvIGxvY2FsIHJl Z3VsYXRvcnkgcG9saWN5LCB0aGUgbWFzdGVyIGRldmljZSBNQVkNCj4+Pj5xdWVyeQ0KPj4+PiB0 aGUgZGF0YWJhc2Ugd2l0aCBwYXJhbWV0ZXJzIHJlY2VpdmVkIGZyb20gdGhlIHNsYXZlIGRldmlj ZS4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPLjEyOiBUaGUgZGF0YWJhc2UgTVVTVCByZXNwb25kIHRv IGEgcXVlcnkgZnJvbSB0aGUgbWFzdGVyIGRldmljZQ0KPj4+PiBjb250YWluaW5nIHBhcmFtZXRl cnMgZnJvbSBhIHNsYXZlIGRldmljZS4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPLjEzOiBBZnRlciB0 aGUgbWFzdGVyIGRldmljZSBoYXMgcmVjZWl2ZWQgYSByZXNwb25zZSBmcm9tIHRoZQ0KPj4+PmRh dGFiYXNlLA0KPj4+PiB0aGUgbWFzdGVyIGRldmljZSBNVVNUIHJlc3BvbmQgdG8gdGhlIHNsYXZl IGRldmljZS4gSWYgYWxsIHJlZ3VsYXRvcnkNCj4+Pj4gcmVxdWlyZW1lbnRzIGFyZSBtZXQgdGhl IHJlc3BvbnNlIHdpbGwgY29udGFpbiBhbiBhdmFpbGFibGUgY2hhbm5lbA0KPj4+PiBsaXN0Lg0K Pj4+PiBJZiByZWd1bGF0b3J5IHJlcXVpcmVtZW50cyBhcmUgbm90IG1ldCwgdGhlIHJlc3BvbnNl IE1VU1QgY29udGFpbiBhdA0KPj4+PiBsZWFzdA0KPj4+PiBhIHJlc3BvbnNlIGNvZGUuDQo+Pj4+ IA0KPj4+PiANCj4+Pj4gTy4xNDogSWYgYSBtYXN0ZXIgZGV2aWNlIGhhcyBwcm92aWRlZCBhbiBh dmFpbGFibGUgY2hhbm5lbCBsaXN0IHRvIGENCj4+Pj4gc2xhdmUNCj4+Pj4gZGV2aWNlIHRoZSBt YXN0ZXIgZGV2aWNlIE1BWSBzZW5kIGEgcGVyaW9kaWMgZW5hYmxpbmcgc2lnbmFsIHRvIGFsbG93 DQo+Pj4+IHRoZQ0KPj4+PiBzbGF2ZSBkZXZpY2UgdG8gY29uZmlybSBpdCBpcyBzdGlsbCB3aXRo aW4gcmVjZXB0aW9uIHJhbmdlIG9mIHRoZQ0KPj4+Pm1hc3Rlcg0KPj4+PiBkZXZpY2UuDQo+Pj4+ IA0KPj4+PiANCj4+Pj4gTy4xNTogVGhlIGVuYWJsaW5nIHNpZ25hbCBNVVNUIGJlIGVuY29kZWQg c28gdGhhdCB0aGUgcmVjZWl2aW5nIHNsYXZlDQo+Pj4+IGNhbg0KPj4+PiBkZXRlcm1pbmUgdGhl IGlkZW50aXR5IG9mIHRoZSBzZW5kaW5nIG1hc3Rlci4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPLjE2 OiBQZXJpb2RpY2FsbHksIGF0IGFuIGludGVydmFsIGFjY29yZGluZyB0byBsb2NhbCByZWd1bGF0 aW9ucywgdGhlDQo+Pj4+IHNsYXZlIGRldmljZSBNVVNUIGVpdGhlciByZWNlaXZlIGFuZCBlbmFi bGluZyBzaWduYWwgb3IgTVVTVA0KPj4+PiBzdWNjZXNzZnVsbHkNCj4+Pj4gcmVwZWF0IHRoZSBj aGFubmVsIHJlcXVlc3QgcHJvY2VzcyBvciBNVVNUIGNlYXNlIHRyYW5zbWlzc2lvbiBvbiB0aGUN Cj4+Pj4gY2hhbm5lbC4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBPLjE3OiBBIG1hc3RlciBkZXZpY2Ug TVVTVCByZXBlYXQgdGhlIHF1ZXJ5IHRoZSBkYXRhYmFzZSBmb3IgdGhlDQo+Pj4+IGF2YWlsYWJs ZQ0KPj4+PiBjaGFubmVscyBhcyBvZnRlbiBhcyByZXF1aXJlZCBieSB0aGUgcmVndWxhdGlvbiAo ZWcsIEZDQyByZXF1aXJlcyBvbmNlDQo+Pj4+IHBlcg0KPj4+PiBkYXkpIHRvIHZlcmlmeSB0aGF0 IHRoZSBvcGVyYXRpbmcgY2hhbm5lbHMgY29udGludWUgdG8gcmVtYWluDQo+Pj4+YXZhaWxhYmxl Lg0KPj4+PiANCj4+Pj4gDQo+Pj4+IE8uMTg6IEEgbWFzdGVyIGRldmljZSB3aGljaCBjaGFuZ2Vz IGl0cyBsb2NhdGlvbiBtb3JlIHRoYW4gYSB0aHJlc2hvbGQNCj4+Pj4gZGlzdGFuY2Ugc3BlY2lm aWVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkgcG9saWN5IGR1cmluZyBpdHMgb3BlcmF0aW9uLA0KPj4+ Pk1VU1QNCj4+Pj4gcXVlcnkgdGhlIGRhdGFiYXNlIGZvciBhdmFpbGFibGUgb3BlcmF0aW5nIGNo YW5uZWxzIGVhY2ggdGltZSBpdCBtb3Zlcw0KPj4+PiBtb3JlIHRoYW4gdGhlIHRocmVzaG9sZCBk aXN0YW5jZSAoZS5nLiwgRkNDIHNwZWNpZmllcyAxMDBtKSBmcm9tIHRoZQ0KPj4+PiBsb2NhdGlv biBpdCBwcmV2aW91c2x5IG1hZGUgdGhlIHF1ZXJ5Lg0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+ PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gd3JhbiB1c2UgY2FzZTwvRWQuIE5v dGU+DQo+Pj4+IE8uMTk6IElmIHNsYXZlIGRldmljZXMgY2hhbmdlIHRoZWlyIGxvY2F0aW9uIGR1 cmluZyBvcGVyYXRpb24gYnkgbW9yZQ0KPj4+PiB0aGFuDQo+Pj4+IGEgbGltaXQgc3BlY2lmaWVk IGJ5IHRoZSBsb2NhbCByZWd1bGF0b3IsIHRoZSBzbGF2ZSBkZXZpY2UgTVVTVCBxdWVyeQ0KPj4+ PiB0aGUNCj4+Pj4gbWFzdGVyIGRldmljZSBmb3IgYXZhaWxhYmxlIG9wZXJhdGluZyBjaGFubmVs cy4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxh dGVkIHRvIHJhcGlkIGRlcGxveWVkIG5ldHdvcmsgdXNlIGNhc2U8L0VkLg0KPj4+PiBOb3RlPg0K Pj4+PiBPLjIwOiBBY2NvcmRpbmcgdG8gbG9jYWwgcmVndWxhdG9yIHBvbGljeSwgYSBtYXN0ZXIg ZGV2aWNlIG1heQ0KPj4+PmNvbnRhY3QgYQ0KPj4+PiBkYXRhYmFzZSB2aWEgcHJveHkgc2Vydmlj ZSBvZiBhbm90aGVyIG1hc3RlciBkZXZpY2UuDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IDxF ZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBtb2JpbGl0eSB1c2UgY2FzZTwvRWQuIE5v dGU+DQo+Pj4+IE8uMjE6IEEgbWFzdGVyIGRldmljZSBNVVNUIGJlIGFibGUgdG8gcXVlcnkgdGhl IHdoaXRlc3BhY2UgZGF0YWJhc2UNCj4+Pj5mb3INCj4+Pj4gY2hhbm5lbCBhdmFpbGFiaWxpdHkg aW5mb3JtYXRpb24gZm9yIGEgc3BlY2lmaWMgZXhwZWN0ZWQgY292ZXJhZ2UgYXJlYQ0KPj4+PiBh cm91bmQgaXRzIGN1cnJlbnQgbG9jYXRpb24uDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IDxF ZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byB0aHJlYXQgbW9kZWw8L0VkLiBOb3RlPg0K Pj4+PiBPLjIyOiBBIE1hc3RlciBkZXZpY2UgTUFZIG5vdCBpbmNsdWRlIGl0cyBpZGVudGl0eSBp bg0KPj4+PiBtZXNzYWdlcyBzZW50IHRvIHRoZSBkYXRhYmFzZSB3aGVuIG5vdCByZXF1aXJlZCBi eSB0aGUgcmVndWxhdG9yeQ0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBwYXdzIG1haWxpbmcgbGlz dA0KPj4+PiBwYXdzQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcGF3cw0KPj4+IA0KPj4gDQo+DQoNCg== From teco@inf-net.nl Mon Feb 27 12:25:18 2012 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 67A2B21F86F9 for ; Mon, 27 Feb 2012 12:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.005 X-Spam-Level: X-Spam-Status: No, score=-3.005 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sl1tanp0Rlc for ; Mon, 27 Feb 2012 12:25:16 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 502AF21F8525 for ; Mon, 27 Feb 2012 12:25:16 -0800 (PST) Received: by eeke51 with SMTP id e51so993750eek.31 for ; Mon, 27 Feb 2012 12:25:15 -0800 (PST) Received-SPF: pass (google.com: domain of teco@inf-net.nl designates 10.213.35.9 as permitted sender) client-ip=10.213.35.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of teco@inf-net.nl designates 10.213.35.9 as permitted sender) smtp.mail=teco@inf-net.nl Received: from mr.google.com ([10.213.35.9]) by 10.213.35.9 with SMTP id n9mr4547475ebd.106.1330374315459 (num_hops = 1); Mon, 27 Feb 2012 12:25:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=P5ddN3gl8/n82NCA/ksP28TwhmiDLTRlJwenJrXCshc=; b=lUOZ6JWp/4g3PHFRTO8p+uiAauyfaiQFQrfWFGMnXFenBLC0+HI04tIV1sTqAerYVK yAqaniO5AXwArI6+iffR0tO+eI8nvJOCQKGacuEwhEVR5/vuwJo0iN2igwAL6BmWNom/ v8paX2PucQGR0pDECjjOaZHRlHtRxBMoD9Sbg= Received: by 10.213.35.9 with SMTP id n9mr3403305ebd.106.1330374315211; Mon, 27 Feb 2012 12:25:15 -0800 (PST) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id y14sm61622052eef.10.2012.02.27.12.25.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Feb 2012 12:25:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Mon, 27 Feb 2012 21:25:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <85ECAC97-3742-4683-97FE-9CB536D2AC7F@inf-net.nl> References: To: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQktqGbWZ2id1ghvBKlMfCeSW+ByEmJ+yVMC3uU+HsksJ/YlLgAy/bGtAIYK1C0m+M6Zxk+W Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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: Mon, 27 Feb 2012 20:25:18 -0000 Hello Scott, I understand your point. But I want to keep things simple. The=20 P.* requirements are for the protocol, it MUST support optional variables. The O.* requirements explain how these are used. This is the MAY,=20 right?=20 Having performed some tests today with an emergency responders=20 network, I saw some high traffic load. Something like this: 1 <\self_explaining_variable_name> I could think of an efficiency requirement, for the rapid deployed=20 network use case. Thanks, Teco Op 27 feb. 2012, om 14:32 heeft = het volgende geschreven: > Hi Teco, >=20 > If we look at P.9 and P.10 together, P.9 says that registration is a = MUST > -- the protocol supports registration without question. P.10 says the > signaling for registration MAY contain any of several variables (also > allows more variables to be included if required by local = regulations). > The list currently identifies all variables required for registration = in > the US. Now if we look at the Data Model requirements, each variable > identified that the registration service MAY contain (these are in = D.5, > D.6, D.1, D.7 and D.8) MUST be included in the Data Model. The = protocol > MUST support registration, and the Data Model in the protocol MUST = support > the variables identified for registration service. >=20 > The current use of MUST in P.9 and MAY in P.10 has the effect that = WSDs in > the US are allowed to register (because the protocol supports > registration) and are allowed to use the variables defined by the FCC > (because the registration signaling MAY include those variables). This > also has the effect that WSDs in the UK (or elsewhere in the world) = are > allowed to register if this is a local requirement (because the = protocol > supports registration) and are allowed to use (or not use) the = variables > defined by the FCC (because the registration signaling MAY include = those > variables). Nothing to prevent adding more variables if needed by = Ofcom, > IDA, etc... >=20 > Another possibility is to change the wording of P.10 to read > P.10: The registration signaling MUST include the following optional > variables: the Device ID, manufacturer=B9s serial number, device = location, > device antenna characteristic information, name of individual or = business > that owns the device, name, address, email address and phone number of = a > contact person who is responsible for device operation. >=20 > What do you think? >=20 > Kind Regards, > Scott >=20 >=20 >=20 >=20 >=20 >=20 > On 2/26/12 3:41 PM, "ext Teco Boot" wrote: >=20 >> Hi Scott, >>=20 >> I still think it is a MUST for the protocol, and a MAY for usage. >>=20 >> Thanks, Teco >>=20 >> Op 24 feb. 2012, om 19:58 heeft >> het volgende geschreven: >>=20 >>> Hello Teco, >>>=20 >>> Since PAWS is a global standard, registration for all regulatory = domains >>> must be supported. While the FCC does require all of the variables >>> listed >>> in P.10, other regulatory domains may not require each of those >>> variables. >>> So for requirements on the protocol, using MAY enables the FCC to >>> require >>> these variables while allowing other regulators to select a subset, = or >>> even different, variables. >>>=20 >>> With this explanation, are you okay with MAY in P.10? >>>=20 >>> Kind Regards, >>> Scott >>>=20 >>>=20 >>>=20 >>> On 2/22/12 1:34 AM, "ext Teco Boot" wrote: >>>=20 >>>> Scott, Ray, >>>>=20 >>>> The P.* are mostly MUST requirements for the protocol. That's fine. >>>> Except P.10, this is a MAY operational requirement. The protocol >>>> MUST support it. >>>>=20 >>>> I'm fine with the rest of it. >>>>=20 >>>> Is noted somewhere that we (IETF) do our best to support as many >>>> regulator rules as possible, and leave setting up requirements for >>>> actual deployment up to the mandated authorities? This makes the >>>> O.* requirements informational. >>>>=20 >>>> Thanks, Teco >>>>=20 >>>>=20 >>>> Op 22 feb. 2012, om 00:53 heeft >>>> het volgende geschreven: >>>>=20 >>>>> Hello All, >>>>>=20 >>>>> I have revised Section 6 of the I-D which describes the Data Model >>>>> Requirements, Protocol Requirements and Operational Requirements. = This >>>>> includes the requirements from the threat model >>>>> (http://www.ietf.org/mail-archive/web/paws/current/msg00771.html). >>>>>=20 >>>>> The requirements are ordered "top down" to follow the previous >>>>> sections >>>>> of >>>>> the document: requirements derived from discovery are followed by >>>>> requirements derived from registration are followed by = requirements >>>>> derived from hotspot, etc... >>>>>=20 >>>>> Please review the proposed text, we hope to have your comments by = Feb >>>>> 28th. >>>>>=20 >>>>> Kind Regards, >>>>>=20 >>>>> Raj & Scott >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> D. Data Model Requirements: >>>>>=20 >>>>>=20 >>>>> requirements related to discovery function >>>>> D.1: The Data Model MUST support specifying the location of the = WSD, >>>>> the >>>>> uncertainty in meters, the height & its uncertainty, and = confidence in >>>>> percentage for the location determination. The Data Model MUST = support >>>>> both North American Datum of 1983 and WGS84. >>>>>=20 >>>>>=20 >>>>> D.2: The Data Model MUST support specifying the URI address of a = white >>>>> space database. >>>>>=20 >>>>>=20 >>>>> D.3: The Data Model MUST support specifying the URI address of a >>>>> national >>>>> listing service. >>>>>=20 >>>>>=20 >>>>> D.4: The Data Model MUST support specifying regulatory domain and = its >>>>> corresponding data requirements. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to registration function >>>>> D.5: The Data Model MUST support specifying an ID of the = transmitter >>>>> device. This ID would contain the ID of the transmitter device = that >>>>> has >>>>> been certified by a regulatory body for its regulatory domain. The >>>>> Data >>>>> Model MUST support a device class. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> D.6: The Data Model MUST support specifying a manufacturer=B9s = serial >>>>> number >>>>> for a master device. >>>>>=20 >>>>>=20 >>>>> D.7: The Data Model MUST support specifying the antenna and = radiation >>>>> related parameters of the device, such as: >>>>>=20 >>>>> - antenna height >>>>>=20 >>>>> - antenna gain >>>>>=20 >>>>> - maximum output power, EIRP (dBm) >>>>>=20 >>>>> - antenna radiation pattern (directional dependence >>>>> of the strength of the radio signal from the antenna) >>>>>=20 >>>>> - spectrum mask with lowest and highest possible frequency >>>>>=20 >>>>> - spectrum mask in dBr from peak transmit power in EIRP, >>>>> with specific power limit at any frequency linearly >>>>> interpolated between adjacent points of the spectrum mask >>>>> measurement resolution bandwidth for EIRP measurements. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> D.8: The Data Model MUST support specifying owner and operator = contact >>>>> information for a transmitter. This includes the name of the >>>>> transmitter >>>>> owner, name of transmitter operator, postal address, email address = and >>>>> phone number of the transmitter operator. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to hotspot use case >>>>> D.9: The Data Model MUST support specifying a list of available >>>>> channels. >>>>> The Data Model MUST support specification of this information by >>>>> channel >>>>> numbers and by start and stop frequencies. The Data Model MUST >>>>> support a >>>>> channel availability schedule and maximum power level for each = channel >>>>> in >>>>> the list. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to mobility use case >>>>> D.10: The Data Model MUST support specifying channel availability >>>>> information for a single location and an area (e.g. a polygon = defined >>>>> by >>>>> multiple location points or a geometric shape such as a circle). >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> P. Protocol Requirements: >>>>>=20 >>>>>=20 >>>>> requirements related to discovery function >>>>> P.1: The protocol MUST provide a message sequence for the master >>>>> device >>>>> to >>>>> discover a white space database that provides service at its = current >>>>> location. >>>>>=20 >>>>>=20 >>>>> P.2: The protocol MUST support access of a database directly. The >>>>> protocol >>>>> MUST support access of a database using a listing approved by a >>>>> national >>>>> regulator. >>>>>=20 >>>>>=20 >>>>> P.3: The protocol MUST support determination of regulatory domain >>>>> governing its current location. >>>>>=20 >>>>>=20 >>>>> requirements related to threat model >>>>>=20 >>>>>=20 >>>>> P.4: The protocol MUST provide the ability for the database to >>>>> authenticate the master device. >>>>>=20 >>>>>=20 >>>>> P.5: The protocol MUST provide the ability for the master device = to >>>>> verify >>>>> the authenticity of the database with which it is interacting. >>>>>=20 >>>>>=20 >>>>> P.6: The messages sent by the master device to the database MUST = be >>>>> integrity protected. >>>>>=20 >>>>>=20 >>>>> P.7: The messages sent by the database to the master device MUST = be >>>>> integrity protected. >>>>>=20 >>>>>=20 >>>>> P.8: The protocol MUST provide the capability for messages sent by = the >>>>> master device and database to be encrypted. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to registration function >>>>> P.9: The protocol MUST support the master device registering with = the >>>>> database. >>>>>=20 >>>>>=20 >>>>> P.10: The registration signaling MAY include the Device ID, >>>>> manufacturer=B9s >>>>> serial number, device location, device antenna characteristic >>>>> information, >>>>> name of individual or business that owns the device, name, = address, >>>>> email >>>>> address and phone number of a contact person who is responsible = for >>>>> device >>>>> operation. >>>>>=20 >>>>>=20 >>>>> P.11: The protocol MUST support a registration acknowledgement >>>>> including >>>>> appropriate result codes. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to hotspot use case >>>>> P.12: The protocol MUST support a channel query request from the >>>>> master >>>>> device to the database. The channel query request message MUST = include >>>>> parameters as required by local regulatory requirement. These >>>>> parameters >>>>> MAY include device location, device ID, manufacturer=B9s serial = number, >>>>> and >>>>> antenna characteristic information. >>>>>=20 >>>>>=20 >>>>> P.13: The protocol MUST support a channel query response from the >>>>> database >>>>> to the master device. The channel query response message MUST = include >>>>> parameters as required by local regulatory requirement. These >>>>> parameters >>>>> MAY include available channels, duration of time for their use, >>>>> associated >>>>> maximum power levels, any additional sensing requirements. >>>>>=20 >>>>>=20 >>>>> P.14: The protocol MUST support a channel query request from the = slave >>>>> device to the master device. The channel query request message = MUST >>>>> include parameters as required by local regulatory requirement. = These >>>>> parameters MAY include device ID and slave device location. >>>>>=20 >>>>>=20 >>>>> P.15: The protocol MUST support a validation request from the = master >>>>> to >>>>> the database to validate a slave device. The validation request = MUST >>>>> include the slave device ID. >>>>>=20 >>>>>=20 >>>>> P.16: The protocol MUST support a validation response from the >>>>> database >>>>> to >>>>> the master. The validation response MUST include a response code. >>>>>=20 >>>>>=20 >>>>> P.17: The protocol MUST support a channel query response from the >>>>> master >>>>> device to the slave device. The channel query response message = MUST >>>>> include parameters as required by local regulatory requirement, >>>>> including >>>>> a response code and sufficient information to decode an enabling >>>>> signal. >>>>>=20 >>>>>=20 >>>>> P.18: The protocol MUST support an enabling signal sent from the >>>>> master >>>>> to >>>>> the slave. This signal MUST allow the slave device to validate = that a >>>>> previously received available channel list is still valid or not. = This >>>>> signal MUST be encoded to allow the slave device to determine the >>>>> identity >>>>> if the sending master device. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> P.19: The protocol between the master device and the database MUST >>>>> support >>>>> the capability to change channel availability lists on short = notice. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to mobility use case >>>>> P.20: The protocol between the master device and the database MUST >>>>> support >>>>> a channel availability request which specifies a geographic = location >>>>> as >>>>> an >>>>> area as well as a point. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> O. Operational Requirements: >>>>>=20 >>>>>=20 >>>>> requirements related to discovery function >>>>>=20 >>>>> O.1: The database and the master device MUST be connected to the >>>>> Internet. >>>>>=20 >>>>>=20 >>>>> O.2: A master device MUST be able to determine its location = including >>>>> uncertainty and confidence level. A fixed master device MAY use a >>>>> location >>>>> programmed at installation or have the capability determine its >>>>> location >>>>> to the required accuracy. A mobile master device MUST have the >>>>> capability >>>>> to determine its location to the required accuracy. >>>>>=20 >>>>>=20 >>>>> O.3: The master device MUST identify a database for use. The = master >>>>> device >>>>> MAY select a database for service by discovery at runtime or the >>>>> master >>>>> device MAY select a database for service by means of a = pre-programmed >>>>> URI >>>>> address. >>>>>=20 >>>>>=20 >>>>> O.4: The master device MUST implement at least one connection = method >>>>> to >>>>> access the database. The master device MAY contact a database = directly >>>>> for >>>>> service (e.g. as defined by FCC) or the master device MAY contact = a >>>>> listing server first followed by contact to a database (e.g. As >>>>> defined >>>>> by >>>>> Ofcom). >>>>>=20 >>>>>=20 >>>>> O.5: The master device MUST obtain an indication the regulatory = domain >>>>> governing operation at its current location, i.e. the master = device >>>>> MUST >>>>> know if it operates under regulations from FCC, Ofcom, etc=8A >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to registration function >>>>> O.6: The master device MAY register with the database according to >>>>> local >>>>> regulatory policy. Not all master devices will be required to >>>>> register. >>>>> Specific events will initiate registration, these events are >>>>> determined >>>>> by >>>>> regulator policy (e.g. at power up, after movement, etc=8A). >>>>>=20 >>>>>=20 >>>>> O.7: The master device MUST register with its most current and >>>>> up-to-date >>>>> information. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to hotspot use case >>>>> O.8: A master device MUST query the database for the available >>>>> channels >>>>> based on its current location before starting radio transmission = in >>>>> white >>>>> space. Parameters provided to the database MAY include device >>>>> location, >>>>> accuracy of the location, antenna characteristic information, = device >>>>> identifier of any slave device requesting channel information. >>>>>=20 >>>>>=20 >>>>> O.9: The database MUST respond to an available channel list = request >>>>> from >>>>> an authenticated and authorized device and MAY also provide time >>>>> constraints, maximum output power, start and stop frequencies for = each >>>>> channel in the list and any additional requirements for sensing. >>>>>=20 >>>>>=20 >>>>> O.10: After connecting to a master device=B9s radio network a = slave >>>>> device >>>>> MUST query the master device for a list of available channels. The >>>>> slave >>>>> MUST include parameters required by local regulatory policy, e.g. >>>>> device >>>>> ID, device location. >>>>>=20 >>>>>=20 >>>>> O.11: According to local regulatory policy, the master device MAY >>>>> query >>>>> the database with parameters received from the slave device. >>>>>=20 >>>>>=20 >>>>> O.12: The database MUST respond to a query from the master device >>>>> containing parameters from a slave device. >>>>>=20 >>>>>=20 >>>>> O.13: After the master device has received a response from the >>>>> database, >>>>> the master device MUST respond to the slave device. If all = regulatory >>>>> requirements are met the response will contain an available = channel >>>>> list. >>>>> If regulatory requirements are not met, the response MUST contain = at >>>>> least >>>>> a response code. >>>>>=20 >>>>>=20 >>>>> O.14: If a master device has provided an available channel list to = a >>>>> slave >>>>> device the master device MAY send a periodic enabling signal to = allow >>>>> the >>>>> slave device to confirm it is still within reception range of the >>>>> master >>>>> device. >>>>>=20 >>>>>=20 >>>>> O.15: The enabling signal MUST be encoded so that the receiving = slave >>>>> can >>>>> determine the identity of the sending master. >>>>>=20 >>>>>=20 >>>>> O.16: Periodically, at an interval according to local regulations, = the >>>>> slave device MUST either receive and enabling signal or MUST >>>>> successfully >>>>> repeat the channel request process or MUST cease transmission on = the >>>>> channel. >>>>>=20 >>>>>=20 >>>>> O.17: A master device MUST repeat the query the database for the >>>>> available >>>>> channels as often as required by the regulation (eg, FCC requires = once >>>>> per >>>>> day) to verify that the operating channels continue to remain >>>>> available. >>>>>=20 >>>>>=20 >>>>> O.18: A master device which changes its location more than a = threshold >>>>> distance specified by local regulatory policy during its = operation, >>>>> MUST >>>>> query the database for available operating channels each time it = moves >>>>> more than the threshold distance (e.g., FCC specifies 100m) from = the >>>>> location it previously made the query. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to wran use case >>>>> O.19: If slave devices change their location during operation by = more >>>>> than >>>>> a limit specified by the local regulator, the slave device MUST = query >>>>> the >>>>> master device for available operating channels. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to rapid deployed network use = case>>>> Note> >>>>> O.20: According to local regulator policy, a master device may >>>>> contact a >>>>> database via proxy service of another master device. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to mobility use case >>>>> O.21: A master device MUST be able to query the whitespace = database >>>>> for >>>>> channel availability information for a specific expected coverage = area >>>>> around its current location. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> requirements related to threat model >>>>> O.22: A Master device MAY not include its identity in >>>>> messages sent to the database when not required by the regulatory >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> paws mailing list >>>>> paws@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/paws >>>>=20 >>>=20 >>=20 >=20 From scott.probasco@nokia.com Mon Feb 27 12:46:50 2012 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 5D0CB11E8074 for ; Mon, 27 Feb 2012 12:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.224 X-Spam-Level: X-Spam-Status: No, score=-4.224 tagged_above=-999 required=5 tests=[AWL=1.775, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtcY4-N9e7TI for ; Mon, 27 Feb 2012 12:46:48 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7256E11E8072 for ; Mon, 27 Feb 2012 12:46:48 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1RKkj5T001055; Mon, 27 Feb 2012 22:46:46 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 22:46:44 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Mon, 27 Feb 2012 21:46:44 +0100 From: To: Thread-Topic: [paws] UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZIdjEAgAN/KwCAA7asgIAApSwAgADX9ID//6FlgA== Date: Mon, 27 Feb 2012 20:46:43 +0000 Message-ID: In-Reply-To: <85ECAC97-3742-4683-97FE-9CB536D2AC7F@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="utf-8" Content-ID: <6CD2EEC58B783547AE097EC470AA80DE@mgd.nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 20:46:44.0732 (UTC) FILETIME=[EA9F83C0:01CCF590] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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: Mon, 27 Feb 2012 20:46:50 -0000 SGkgVGVjbywNCg0KV2UgY291bGQgY2hhbmdlIE8uNyB0byBzb21ldGhpbmcgbGlrZToNCg0KTy43 OiBUaGUgbWFzdGVyIGRldmljZSBNVVNUIHJlZ2lzdGVyIHdpdGggaXRzIG1vc3QgY3VycmVudCBh bmQgdXAtdG8tZGF0ZQ0KaW5mb3JtYXRpb24sIGFuZCBNVVNUIGluY2x1ZGUgYWxsIHZhcmlhYmxl cyBtYW5kYXRlZCBieSBsb2NhbCByZWd1bGF0b3INCnBvbGljeS4NCg0KV291bGQgdGhpcyB3b3Jr Pw0KDQpLaW5kIFJlZ2FyZHMsDQpTY290dA0KDQoNCg0KT24gMi8yNy8xMiAyOjI1IFBNLCAiZXh0 IFRlY28gQm9vdCIgPHRlY29AaW5mLW5ldC5ubD4gd3JvdGU6DQoNCj5IZWxsbyBTY290dCwNCj4N Cj5JIHVuZGVyc3RhbmQgeW91ciBwb2ludC4gQnV0IEkgd2FudCB0byBrZWVwIHRoaW5ncyBzaW1w bGUuIFRoZQ0KPlAuKiByZXF1aXJlbWVudHMgYXJlIGZvciB0aGUgcHJvdG9jb2wsIGl0IE1VU1Qg c3VwcG9ydCBvcHRpb25hbA0KPnZhcmlhYmxlcy4NCj5UaGUgTy4qIHJlcXVpcmVtZW50cyBleHBs YWluIGhvdyB0aGVzZSBhcmUgdXNlZC4gVGhpcyBpcyB0aGUgTUFZLA0KPnJpZ2h0PyANCj4NCj5I YXZpbmcgcGVyZm9ybWVkIHNvbWUgdGVzdHMgdG9kYXkgd2l0aCBhbiBlbWVyZ2VuY3kgcmVzcG9u ZGVycw0KPm5ldHdvcmssIEkgc2F3IHNvbWUgaGlnaCB0cmFmZmljIGxvYWQuIFNvbWV0aGluZyBs aWtlIHRoaXM6DQo+ICAgICA8c2VsZl9leHBsYWluaW5nX3ZhcmlhYmxlX25hbWU+DQo+ICAgICAg ICAgMQ0KPiAgICAgPFxzZWxmX2V4cGxhaW5pbmdfdmFyaWFibGVfbmFtZT4NCj5JIGNvdWxkIHRo aW5rIG9mIGFuIGVmZmljaWVuY3kgcmVxdWlyZW1lbnQsIGZvciB0aGUgcmFwaWQgZGVwbG95ZWQN Cj5uZXR3b3JrIHVzZSBjYXNlLg0KPg0KPlRoYW5rcywgVGVjbw0KPg0KPg0KPk9wIDI3IGZlYi4g MjAxMiwgb20gMTQ6MzIgaGVlZnQgPHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbT4NCj48c2NvdHQu cHJvYmFzY29Abm9raWEuY29tPiBoZXQgdm9sZ2VuZGUgZ2VzY2hyZXZlbjoNCj4NCj4+IEhpIFRl Y28sDQo+PiANCj4+IElmIHdlIGxvb2sgYXQgUC45IGFuZCBQLjEwIHRvZ2V0aGVyLCBQLjkgc2F5 cyB0aGF0IHJlZ2lzdHJhdGlvbiBpcyBhDQo+Pk1VU1QNCj4+IC0tIHRoZSBwcm90b2NvbCBzdXBw b3J0cyByZWdpc3RyYXRpb24gd2l0aG91dCBxdWVzdGlvbi4gUC4xMCBzYXlzIHRoZQ0KPj4gc2ln bmFsaW5nIGZvciByZWdpc3RyYXRpb24gTUFZIGNvbnRhaW4gYW55IG9mIHNldmVyYWwgdmFyaWFi bGVzIChhbHNvDQo+PiBhbGxvd3MgbW9yZSB2YXJpYWJsZXMgdG8gYmUgaW5jbHVkZWQgaWYgcmVx dWlyZWQgYnkgbG9jYWwgcmVndWxhdGlvbnMpLg0KPj4gVGhlIGxpc3QgY3VycmVudGx5IGlkZW50 aWZpZXMgYWxsIHZhcmlhYmxlcyByZXF1aXJlZCBmb3IgcmVnaXN0cmF0aW9uIGluDQo+PiB0aGUg VVMuIE5vdyBpZiB3ZSBsb29rIGF0IHRoZSBEYXRhIE1vZGVsIHJlcXVpcmVtZW50cywgZWFjaCB2 YXJpYWJsZQ0KPj4gaWRlbnRpZmllZCB0aGF0IHRoZSByZWdpc3RyYXRpb24gc2VydmljZSBNQVkg Y29udGFpbiAodGhlc2UgYXJlIGluIEQuNSwNCj4+IEQuNiwgRC4xLCBELjcgYW5kIEQuOCkgTVVT VCBiZSBpbmNsdWRlZCBpbiB0aGUgRGF0YSBNb2RlbC4gVGhlIHByb3RvY29sDQo+PiBNVVNUIHN1 cHBvcnQgcmVnaXN0cmF0aW9uLCBhbmQgdGhlIERhdGEgTW9kZWwgaW4gdGhlIHByb3RvY29sIE1V U1QNCj4+c3VwcG9ydA0KPj4gdGhlIHZhcmlhYmxlcyBpZGVudGlmaWVkIGZvciByZWdpc3RyYXRp b24gc2VydmljZS4NCj4+IA0KPj4gVGhlIGN1cnJlbnQgdXNlIG9mIE1VU1QgaW4gUC45IGFuZCBN QVkgaW4gUC4xMCBoYXMgdGhlIGVmZmVjdCB0aGF0IFdTRHMNCj4+aW4NCj4+IHRoZSBVUyBhcmUg YWxsb3dlZCB0byByZWdpc3RlciAoYmVjYXVzZSB0aGUgcHJvdG9jb2wgc3VwcG9ydHMNCj4+IHJl Z2lzdHJhdGlvbikgYW5kIGFyZSBhbGxvd2VkIHRvIHVzZSB0aGUgdmFyaWFibGVzIGRlZmluZWQg YnkgdGhlIEZDQw0KPj4gKGJlY2F1c2UgdGhlIHJlZ2lzdHJhdGlvbiBzaWduYWxpbmcgTUFZIGlu Y2x1ZGUgdGhvc2UgdmFyaWFibGVzKS4gVGhpcw0KPj4gYWxzbyBoYXMgdGhlIGVmZmVjdCB0aGF0 IFdTRHMgaW4gdGhlIFVLIChvciBlbHNld2hlcmUgaW4gdGhlIHdvcmxkKSBhcmUNCj4+IGFsbG93 ZWQgdG8gcmVnaXN0ZXIgaWYgdGhpcyBpcyBhIGxvY2FsIHJlcXVpcmVtZW50IChiZWNhdXNlIHRo ZSBwcm90b2NvbA0KPj4gc3VwcG9ydHMgcmVnaXN0cmF0aW9uKSBhbmQgYXJlIGFsbG93ZWQgdG8g dXNlIChvciBub3QgdXNlKSB0aGUgdmFyaWFibGVzDQo+PiBkZWZpbmVkIGJ5IHRoZSBGQ0MgKGJl Y2F1c2UgdGhlIHJlZ2lzdHJhdGlvbiBzaWduYWxpbmcgTUFZIGluY2x1ZGUgdGhvc2UNCj4+IHZh cmlhYmxlcykuIE5vdGhpbmcgdG8gcHJldmVudCBhZGRpbmcgbW9yZSB2YXJpYWJsZXMgaWYgbmVl ZGVkIGJ5IE9mY29tLA0KPj4gSURBLCBldGMuLi4NCj4+IA0KPj4gQW5vdGhlciBwb3NzaWJpbGl0 eSBpcyB0byBjaGFuZ2UgdGhlIHdvcmRpbmcgb2YgUC4xMCB0byByZWFkDQo+PiBQLjEwOiBUaGUg cmVnaXN0cmF0aW9uIHNpZ25hbGluZyBNVVNUIGluY2x1ZGUgdGhlIGZvbGxvd2luZyBvcHRpb25h bA0KPj4gdmFyaWFibGVzOiB0aGUgRGV2aWNlIElELCBtYW51ZmFjdHVyZXLCuXMgc2VyaWFsIG51 bWJlciwgZGV2aWNlIGxvY2F0aW9uLA0KPj4gZGV2aWNlIGFudGVubmEgY2hhcmFjdGVyaXN0aWMg aW5mb3JtYXRpb24sIG5hbWUgb2YgaW5kaXZpZHVhbCBvcg0KPj5idXNpbmVzcw0KPj4gdGhhdCBv d25zIHRoZSBkZXZpY2UsIG5hbWUsIGFkZHJlc3MsIGVtYWlsIGFkZHJlc3MgYW5kIHBob25lIG51 bWJlciBvZiBhDQo+PiBjb250YWN0IHBlcnNvbiB3aG8gaXMgcmVzcG9uc2libGUgZm9yIGRldmlj ZSBvcGVyYXRpb24uDQo+PiANCj4+IFdoYXQgZG8geW91IHRoaW5rPw0KPj4gDQo+PiBLaW5kIFJl Z2FyZHMsDQo+PiBTY290dA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gT24gMi8y Ni8xMiAzOjQxIFBNLCAiZXh0IFRlY28gQm9vdCIgPHRlY29AaW5mLW5ldC5ubD4gd3JvdGU6DQo+ PiANCj4+PiBIaSBTY290dCwNCj4+PiANCj4+PiBJIHN0aWxsIHRoaW5rIGl0IGlzIGEgTVVTVCBm b3IgdGhlIHByb3RvY29sLCBhbmQgYSBNQVkgZm9yIHVzYWdlLg0KPj4+IA0KPj4+IFRoYW5rcywg VGVjbw0KPj4+IA0KPj4+IE9wIDI0IGZlYi4gMjAxMiwgb20gMTk6NTggaGVlZnQgPHNjb3R0LnBy b2Jhc2NvQG5va2lhLmNvbT4NCj4+PiA8c2NvdHQucHJvYmFzY29Abm9raWEuY29tPiBoZXQgdm9s Z2VuZGUgZ2VzY2hyZXZlbjoNCj4+PiANCj4+Pj4gSGVsbG8gVGVjbywNCj4+Pj4gDQo+Pj4+IFNp bmNlIFBBV1MgaXMgYSBnbG9iYWwgc3RhbmRhcmQsIHJlZ2lzdHJhdGlvbiBmb3IgYWxsIHJlZ3Vs YXRvcnkNCj4+Pj5kb21haW5zDQo+Pj4+IG11c3QgYmUgc3VwcG9ydGVkLiBXaGlsZSB0aGUgRkND IGRvZXMgcmVxdWlyZSBhbGwgb2YgdGhlIHZhcmlhYmxlcw0KPj4+PiBsaXN0ZWQNCj4+Pj4gaW4g UC4xMCwgb3RoZXIgcmVndWxhdG9yeSBkb21haW5zIG1heSBub3QgcmVxdWlyZSBlYWNoIG9mIHRo b3NlDQo+Pj4+IHZhcmlhYmxlcy4NCj4+Pj4gU28gZm9yIHJlcXVpcmVtZW50cyBvbiB0aGUgcHJv dG9jb2wsIHVzaW5nIE1BWSBlbmFibGVzIHRoZSBGQ0MgdG8NCj4+Pj4gcmVxdWlyZQ0KPj4+PiB0 aGVzZSB2YXJpYWJsZXMgd2hpbGUgYWxsb3dpbmcgb3RoZXIgcmVndWxhdG9ycyB0byBzZWxlY3Qg YSBzdWJzZXQsIG9yDQo+Pj4+IGV2ZW4gZGlmZmVyZW50LCB2YXJpYWJsZXMuDQo+Pj4+IA0KPj4+ PiBXaXRoIHRoaXMgZXhwbGFuYXRpb24sIGFyZSB5b3Ugb2theSB3aXRoIE1BWSBpbiBQLjEwPw0K Pj4+PiANCj4+Pj4gS2luZCBSZWdhcmRzLA0KPj4+PiBTY290dA0KPj4+PiANCj4+Pj4gDQo+Pj4+ IA0KPj4+PiBPbiAyLzIyLzEyIDE6MzQgQU0sICJleHQgVGVjbyBCb290IiA8dGVjb0BpbmYtbmV0 Lm5sPiB3cm90ZToNCj4+Pj4gDQo+Pj4+PiBTY290dCwgUmF5LA0KPj4+Pj4gDQo+Pj4+PiBUaGUg UC4qIGFyZSBtb3N0bHkgTVVTVCByZXF1aXJlbWVudHMgZm9yIHRoZSBwcm90b2NvbC4gVGhhdCdz IGZpbmUuDQo+Pj4+PiBFeGNlcHQgUC4xMCwgdGhpcyBpcyBhIE1BWSBvcGVyYXRpb25hbCByZXF1 aXJlbWVudC4gVGhlIHByb3RvY29sDQo+Pj4+PiBNVVNUIHN1cHBvcnQgaXQuDQo+Pj4+PiANCj4+ Pj4+IEknbSBmaW5lIHdpdGggdGhlIHJlc3Qgb2YgaXQuDQo+Pj4+PiANCj4+Pj4+IElzIG5vdGVk IHNvbWV3aGVyZSB0aGF0IHdlIChJRVRGKSBkbyBvdXIgYmVzdCB0byBzdXBwb3J0IGFzIG1hbnkN Cj4+Pj4+IHJlZ3VsYXRvciBydWxlcyBhcyBwb3NzaWJsZSwgYW5kIGxlYXZlIHNldHRpbmcgdXAg cmVxdWlyZW1lbnRzIGZvcg0KPj4+Pj4gYWN0dWFsIGRlcGxveW1lbnQgdXAgdG8gdGhlIG1hbmRh dGVkIGF1dGhvcml0aWVzPyBUaGlzIG1ha2VzIHRoZQ0KPj4+Pj4gTy4qIHJlcXVpcmVtZW50cyBp bmZvcm1hdGlvbmFsLg0KPj4+Pj4gDQo+Pj4+PiBUaGFua3MsIFRlY28NCj4+Pj4+IA0KPj4+Pj4g DQo+Pj4+PiBPcCAyMiBmZWIuIDIwMTIsIG9tIDAwOjUzIGhlZWZ0IDxzY290dC5wcm9iYXNjb0Bu b2tpYS5jb20+DQo+Pj4+PiA8c2NvdHQucHJvYmFzY29Abm9raWEuY29tPiBoZXQgdm9sZ2VuZGUg Z2VzY2hyZXZlbjoNCj4+Pj4+IA0KPj4+Pj4+IEhlbGxvIEFsbCwNCj4+Pj4+PiANCj4+Pj4+PiBJ IGhhdmUgcmV2aXNlZCBTZWN0aW9uIDYgb2YgdGhlIEktRCB3aGljaCBkZXNjcmliZXMgdGhlIERh dGEgTW9kZWwNCj4+Pj4+PiBSZXF1aXJlbWVudHMsIFByb3RvY29sIFJlcXVpcmVtZW50cyBhbmQg T3BlcmF0aW9uYWwgUmVxdWlyZW1lbnRzLg0KPj4+Pj4+VGhpcw0KPj4+Pj4+IGluY2x1ZGVzIHRo ZSByZXF1aXJlbWVudHMgZnJvbSB0aGUgdGhyZWF0IG1vZGVsDQo+Pj4+Pj4gKGh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wYXdzL2N1cnJlbnQvbXNnMDA3NzEuaHRtbCkuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gVGhlIHJlcXVpcmVtZW50cyBhcmUgb3JkZXJlZCAidG9wIGRvd24iIHRv IGZvbGxvdyB0aGUgcHJldmlvdXMNCj4+Pj4+PiBzZWN0aW9ucw0KPj4+Pj4+IG9mDQo+Pj4+Pj4g dGhlIGRvY3VtZW50OiByZXF1aXJlbWVudHMgZGVyaXZlZCBmcm9tIGRpc2NvdmVyeSBhcmUgZm9s bG93ZWQgYnkNCj4+Pj4+PiByZXF1aXJlbWVudHMgZGVyaXZlZCBmcm9tIHJlZ2lzdHJhdGlvbiBh cmUgZm9sbG93ZWQgYnkgcmVxdWlyZW1lbnRzDQo+Pj4+Pj4gZGVyaXZlZCBmcm9tIGhvdHNwb3Qs IGV0Yy4uLg0KPj4+Pj4+IA0KPj4+Pj4+IFBsZWFzZSByZXZpZXcgdGhlIHByb3Bvc2VkIHRleHQs IHdlIGhvcGUgdG8gaGF2ZSB5b3VyIGNvbW1lbnRzIGJ5DQo+Pj4+Pj5GZWINCj4+Pj4+PiAyOHRo Lg0KPj4+Pj4+IA0KPj4+Pj4+IEtpbmQgUmVnYXJkcywNCj4+Pj4+PiANCj4+Pj4+PiBSYWogJiBT Y290dA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IEQuIERhdGEg TW9kZWwgUmVxdWlyZW1lbnRzOg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IDxFZC4gTm90ZT5y ZXF1aXJlbWVudHMgcmVsYXRlZCB0byBkaXNjb3ZlcnkgZnVuY3Rpb248L0VkLiBOb3RlPg0KPj4+ Pj4+IEQuMTogVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgdGhlIGxvY2F0 aW9uIG9mIHRoZSBXU0QsDQo+Pj4+Pj4gdGhlDQo+Pj4+Pj4gdW5jZXJ0YWludHkgaW4gbWV0ZXJz LCB0aGUgaGVpZ2h0ICYgaXRzIHVuY2VydGFpbnR5LCBhbmQgY29uZmlkZW5jZQ0KPj4+Pj4+aW4N Cj4+Pj4+PiBwZXJjZW50YWdlIGZvciB0aGUgbG9jYXRpb24gZGV0ZXJtaW5hdGlvbi4gVGhlIERh dGEgTW9kZWwgTVVTVA0KPj4+Pj4+c3VwcG9ydA0KPj4+Pj4+IGJvdGggTm9ydGggQW1lcmljYW4g RGF0dW0gb2YgMTk4MyBhbmQgV0dTODQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gRC4yOiBU aGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyB0aGUgVVJJIGFkZHJlc3Mgb2Yg YQ0KPj4+Pj4+d2hpdGUNCj4+Pj4+PiBzcGFjZSBkYXRhYmFzZS4NCj4+Pj4+PiANCj4+Pj4+PiAN Cj4+Pj4+PiBELjM6IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIHRoZSBV UkkgYWRkcmVzcyBvZiBhDQo+Pj4+Pj4gbmF0aW9uYWwNCj4+Pj4+PiBsaXN0aW5nIHNlcnZpY2Uu DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gRC40OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBv cnQgc3BlY2lmeWluZyAgcmVndWxhdG9yeSBkb21haW4gYW5kDQo+Pj4+Pj5pdHMNCj4+Pj4+PiBj b3JyZXNwb25kaW5nIGRhdGEgcmVxdWlyZW1lbnRzLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+ IA0KPj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byByZWdpc3RyYXRpb24g ZnVuY3Rpb248L0VkLiBOb3RlPg0KPj4+Pj4+IEQuNTogVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBw b3J0IHNwZWNpZnlpbmcgYW4gSUQgb2YgdGhlIHRyYW5zbWl0dGVyDQo+Pj4+Pj4gZGV2aWNlLiBU aGlzIElEIHdvdWxkIGNvbnRhaW4gdGhlIElEIG9mIHRoZSB0cmFuc21pdHRlciBkZXZpY2UgdGhh dA0KPj4+Pj4+IGhhcw0KPj4+Pj4+IGJlZW4gY2VydGlmaWVkIGJ5IGEgcmVndWxhdG9yeSBib2R5 IGZvciBpdHMgcmVndWxhdG9yeSBkb21haW4uIFRoZQ0KPj4+Pj4+IERhdGENCj4+Pj4+PiBNb2Rl bCBNVVNUIHN1cHBvcnQgYSBkZXZpY2UgY2xhc3MuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g DQo+Pj4+Pj4gRC42OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhIG1h bnVmYWN0dXJlcsK5cyBzZXJpYWwNCj4+Pj4+PiBudW1iZXINCj4+Pj4+PiBmb3IgYSBtYXN0ZXIg ZGV2aWNlLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IEQuNzogIFRoZSBEYXRhIE1vZGVsIE1V U1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIHRoZSBhbnRlbm5hIGFuZA0KPj4+Pj4+cmFkaWF0aW9uDQo+ Pj4+Pj4gcmVsYXRlZCBwYXJhbWV0ZXJzIG9mIHRoZSBkZXZpY2UsIHN1Y2ggYXM6DQo+Pj4+Pj4g DQo+Pj4+Pj4gLSBhbnRlbm5hIGhlaWdodA0KPj4+Pj4+IA0KPj4+Pj4+IC0gYW50ZW5uYSBnYWlu DQo+Pj4+Pj4gDQo+Pj4+Pj4gLSBtYXhpbXVtIG91dHB1dCBwb3dlciwgRUlSUCAoZEJtKQ0KPj4+ Pj4+IA0KPj4+Pj4+IC0gYW50ZW5uYSByYWRpYXRpb24gcGF0dGVybiAoZGlyZWN0aW9uYWwgZGVw ZW5kZW5jZQ0KPj4+Pj4+ICAgb2YgdGhlIHN0cmVuZ3RoIG9mIHRoZSByYWRpbyBzaWduYWwgZnJv bSB0aGUgYW50ZW5uYSkNCj4+Pj4+PiANCj4+Pj4+PiAtIHNwZWN0cnVtIG1hc2sgd2l0aCBsb3dl c3QgYW5kIGhpZ2hlc3QgcG9zc2libGUgZnJlcXVlbmN5DQo+Pj4+Pj4gDQo+Pj4+Pj4gLSBzcGVj dHJ1bSBtYXNrIGluIGRCciBmcm9tIHBlYWsgdHJhbnNtaXQgcG93ZXIgaW4gRUlSUCwNCj4+Pj4+ PiAgIHdpdGggc3BlY2lmaWMgcG93ZXIgbGltaXQgYXQgYW55IGZyZXF1ZW5jeSBsaW5lYXJseQ0K Pj4+Pj4+ICAgaW50ZXJwb2xhdGVkIGJldHdlZW4gYWRqYWNlbnQgcG9pbnRzIG9mIHRoZSBzcGVj dHJ1bSBtYXNrDQo+Pj4+Pj4gICBtZWFzdXJlbWVudCByZXNvbHV0aW9uIGJhbmR3aWR0aCBmb3Ig RUlSUCBtZWFzdXJlbWVudHMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gRC44 OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBvd25lciBhbmQgb3BlcmF0 b3INCj4+Pj4+PmNvbnRhY3QNCj4+Pj4+PiBpbmZvcm1hdGlvbiBmb3IgYSB0cmFuc21pdHRlci4g VGhpcyBpbmNsdWRlcyB0aGUgbmFtZSBvZiB0aGUNCj4+Pj4+PiB0cmFuc21pdHRlcg0KPj4+Pj4+ IG93bmVyLCBuYW1lIG9mIHRyYW5zbWl0dGVyIG9wZXJhdG9yLCBwb3N0YWwgYWRkcmVzcywgZW1h aWwgYWRkcmVzcw0KPj4+Pj4+YW5kDQo+Pj4+Pj4gcGhvbmUgbnVtYmVyIG9mIHRoZSB0cmFuc21p dHRlciBvcGVyYXRvci4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+ PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gaG90c3BvdCB1c2UgY2FzZTwvRWQu IE5vdGU+DQo+Pj4+Pj4gRC45OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWlu ZyBhIGxpc3Qgb2YgYXZhaWxhYmxlDQo+Pj4+Pj4gY2hhbm5lbHMuDQo+Pj4+Pj4gVGhlIERhdGEg TW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBieQ0K Pj4+Pj4+IGNoYW5uZWwNCj4+Pj4+PiBudW1iZXJzIGFuZCBieSBzdGFydCBhbmQgc3RvcCBmcmVx dWVuY2llcy4gVGhlIERhdGEgTW9kZWwgTVVTVA0KPj4+Pj4+IHN1cHBvcnQgYQ0KPj4+Pj4+IGNo YW5uZWwgYXZhaWxhYmlsaXR5IHNjaGVkdWxlIGFuZCBtYXhpbXVtIHBvd2VyIGxldmVsIGZvciBl YWNoDQo+Pj4+Pj5jaGFubmVsDQo+Pj4+Pj4gaW4NCj4+Pj4+PiB0aGUgbGlzdC4NCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQg dG8gbW9iaWxpdHkgdXNlIGNhc2U8L0VkLiBOb3RlPg0KPj4+Pj4+IEQuMTA6ICBUaGUgRGF0YSBN b2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBjaGFubmVsIGF2YWlsYWJpbGl0eQ0KPj4+Pj4+ IGluZm9ybWF0aW9uIGZvciBhIHNpbmdsZSBsb2NhdGlvbiBhbmQgYW4gYXJlYSAoZS5nLiBhIHBv bHlnb24NCj4+Pj4+PmRlZmluZWQNCj4+Pj4+PiBieQ0KPj4+Pj4+IG11bHRpcGxlIGxvY2F0aW9u IHBvaW50cyBvciBhIGdlb21ldHJpYyBzaGFwZSBzdWNoIGFzIGEgY2lyY2xlKS4NCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBQLiBQcm90b2NvbCBS ZXF1aXJlbWVudHM6DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVt ZW50cyByZWxhdGVkIHRvIGRpc2NvdmVyeSBmdW5jdGlvbjwvRWQuIE5vdGU+DQo+Pj4+Pj4gUC4x OiBUaGUgcHJvdG9jb2wgTVVTVCBwcm92aWRlIGEgbWVzc2FnZSBzZXF1ZW5jZSBmb3IgdGhlIG1h c3Rlcg0KPj4+Pj4+IGRldmljZQ0KPj4+Pj4+IHRvDQo+Pj4+Pj4gZGlzY292ZXIgYSB3aGl0ZSBz cGFjZSBkYXRhYmFzZSB0aGF0IHByb3ZpZGVzIHNlcnZpY2UgYXQgaXRzIGN1cnJlbnQNCj4+Pj4+ PiBsb2NhdGlvbi4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBQLjI6IFRoZSBwcm90b2NvbCBN VVNUIHN1cHBvcnQgYWNjZXNzIG9mIGEgZGF0YWJhc2UgZGlyZWN0bHkuIFRoZQ0KPj4+Pj4+IHBy b3RvY29sDQo+Pj4+Pj4gTVVTVCBzdXBwb3J0IGFjY2VzcyBvZiBhIGRhdGFiYXNlIHVzaW5nIGEg bGlzdGluZyBhcHByb3ZlZCBieSBhDQo+Pj4+Pj4gbmF0aW9uYWwNCj4+Pj4+PiByZWd1bGF0b3Iu DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUC4zOiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0 IGRldGVybWluYXRpb24gb2YgcmVndWxhdG9yeSBkb21haW4NCj4+Pj4+PiBnb3Zlcm5pbmcgaXRz IGN1cnJlbnQgbG9jYXRpb24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gPEVkLiBOb3RlPnJl cXVpcmVtZW50cyByZWxhdGVkIHRvIHRocmVhdCBtb2RlbDwvRWQuIE5vdGU+DQo+Pj4+Pj4gDQo+ Pj4+Pj4gDQo+Pj4+Pj4gUC40OiBUaGUgcHJvdG9jb2wgTVVTVCBwcm92aWRlIHRoZSBhYmlsaXR5 IGZvciB0aGUgZGF0YWJhc2UgdG8NCj4+Pj4+PiBhdXRoZW50aWNhdGUgdGhlIG1hc3RlciBkZXZp Y2UuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUC41OiBUaGUgcHJvdG9jb2wgTVVTVCBwcm92 aWRlIHRoZSBhYmlsaXR5IGZvciB0aGUgbWFzdGVyIGRldmljZSB0bw0KPj4+Pj4+IHZlcmlmeQ0K Pj4+Pj4+IHRoZSBhdXRoZW50aWNpdHkgb2YgdGhlIGRhdGFiYXNlIHdpdGggd2hpY2ggaXQgaXMg aW50ZXJhY3RpbmcuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUC42OiBUaGUgbWVzc2FnZXMg c2VudCBieSB0aGUgbWFzdGVyIGRldmljZSB0byB0aGUgZGF0YWJhc2UgTVVTVCBiZQ0KPj4+Pj4+ IGludGVncml0eSBwcm90ZWN0ZWQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUC43OiBUaGUg bWVzc2FnZXMgc2VudCBieSB0aGUgZGF0YWJhc2UgdG8gdGhlIG1hc3RlciBkZXZpY2UgTVVTVCBi ZQ0KPj4+Pj4+IGludGVncml0eSBwcm90ZWN0ZWQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g UC44OiBUaGUgcHJvdG9jb2wgTVVTVCBwcm92aWRlIHRoZSBjYXBhYmlsaXR5IGZvciBtZXNzYWdl cyBzZW50IGJ5DQo+Pj4+Pj50aGUNCj4+Pj4+PiBtYXN0ZXIgZGV2aWNlIGFuZCBkYXRhYmFzZSB0 byBiZSBlbmNyeXB0ZWQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+ Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIHJl Z2lzdHJhdGlvbiBmdW5jdGlvbjwvRWQuIE5vdGU+DQo+Pj4+Pj4gUC45OiBUaGUgcHJvdG9jb2wg TVVTVCBzdXBwb3J0IHRoZSBtYXN0ZXIgZGV2aWNlIHJlZ2lzdGVyaW5nIHdpdGgNCj4+Pj4+PnRo ZQ0KPj4+Pj4+IGRhdGFiYXNlLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IFAuMTA6IFRoZSBy ZWdpc3RyYXRpb24gc2lnbmFsaW5nIE1BWSBpbmNsdWRlIHRoZSBEZXZpY2UgSUQsDQo+Pj4+Pj4g bWFudWZhY3R1cmVywrlzDQo+Pj4+Pj4gc2VyaWFsIG51bWJlciwgZGV2aWNlIGxvY2F0aW9uLCBk ZXZpY2UgYW50ZW5uYSBjaGFyYWN0ZXJpc3RpYw0KPj4+Pj4+IGluZm9ybWF0aW9uLA0KPj4+Pj4+ IG5hbWUgb2YgaW5kaXZpZHVhbCBvciBidXNpbmVzcyB0aGF0IG93bnMgdGhlIGRldmljZSwgbmFt ZSwgYWRkcmVzcywNCj4+Pj4+PiBlbWFpbA0KPj4+Pj4+IGFkZHJlc3MgYW5kIHBob25lIG51bWJl ciBvZiBhIGNvbnRhY3QgcGVyc29uIHdobyBpcyByZXNwb25zaWJsZSBmb3INCj4+Pj4+PiBkZXZp Y2UNCj4+Pj4+PiBvcGVyYXRpb24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUC4xMTogVGhl IHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIHJlZ2lzdHJhdGlvbiBhY2tub3dsZWRnZW1lbnQNCj4+ Pj4+PiBpbmNsdWRpbmcNCj4+Pj4+PiBhcHByb3ByaWF0ZSByZXN1bHQgY29kZXMuDQo+Pj4+Pj4g DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50 cyByZWxhdGVkIHRvIGhvdHNwb3QgdXNlIGNhc2U8L0VkLiBOb3RlPg0KPj4+Pj4+IFAuMTI6IFRo ZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlcXVlc3QgZnJvbSB0aGUN Cj4+Pj4+PiBtYXN0ZXINCj4+Pj4+PiBkZXZpY2UgdG8gdGhlIGRhdGFiYXNlLiBUaGUgY2hhbm5l bCBxdWVyeSByZXF1ZXN0IG1lc3NhZ2UgTVVTVA0KPj4+Pj4+aW5jbHVkZQ0KPj4+Pj4+IHBhcmFt ZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4gVGhlc2UN Cj4+Pj4+PiBwYXJhbWV0ZXJzDQo+Pj4+Pj4gTUFZIGluY2x1ZGUgZGV2aWNlIGxvY2F0aW9uLCBk ZXZpY2UgSUQsIG1hbnVmYWN0dXJlcsK5cyBzZXJpYWwNCj4+Pj4+Pm51bWJlciwNCj4+Pj4+PiBh bmQNCj4+Pj4+PiBhbnRlbm5hIGNoYXJhY3RlcmlzdGljIGluZm9ybWF0aW9uLg0KPj4+Pj4+IA0K Pj4+Pj4+IA0KPj4+Pj4+IFAuMTM6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVs IHF1ZXJ5IHJlc3BvbnNlIGZyb20gdGhlDQo+Pj4+Pj4gZGF0YWJhc2UNCj4+Pj4+PiB0byB0aGUg bWFzdGVyIGRldmljZS4gVGhlIGNoYW5uZWwgcXVlcnkgcmVzcG9uc2UgbWVzc2FnZSBNVVNUDQo+ Pj4+Pj5pbmNsdWRlDQo+Pj4+Pj4gcGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1 bGF0b3J5IHJlcXVpcmVtZW50LiBUaGVzZQ0KPj4+Pj4+IHBhcmFtZXRlcnMNCj4+Pj4+PiBNQVkg aW5jbHVkZSBhdmFpbGFibGUgY2hhbm5lbHMsIGR1cmF0aW9uIG9mIHRpbWUgZm9yIHRoZWlyIHVz ZSwNCj4+Pj4+PiBhc3NvY2lhdGVkDQo+Pj4+Pj4gbWF4aW11bSBwb3dlciBsZXZlbHMsIGFueSBh ZGRpdGlvbmFsIHNlbnNpbmcgcmVxdWlyZW1lbnRzLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+ IFAuMTQ6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlcXVlc3Qg ZnJvbSB0aGUNCj4+Pj4+PnNsYXZlDQo+Pj4+Pj4gZGV2aWNlIHRvIHRoZSBtYXN0ZXIgZGV2aWNl LiBUaGUgY2hhbm5lbCBxdWVyeSByZXF1ZXN0IG1lc3NhZ2UgTVVTVA0KPj4+Pj4+IGluY2x1ZGUg cGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVtZW50Lg0K Pj4+Pj4+VGhlc2UNCj4+Pj4+PiBwYXJhbWV0ZXJzIE1BWSBpbmNsdWRlIGRldmljZSBJRCBhbmQg c2xhdmUgZGV2aWNlIGxvY2F0aW9uLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IFAuMTU6IFRo ZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSB2YWxpZGF0aW9uIHJlcXVlc3QgZnJvbSB0aGUgbWFz dGVyDQo+Pj4+Pj4gdG8NCj4+Pj4+PiB0aGUgZGF0YWJhc2UgdG8gdmFsaWRhdGUgYSBzbGF2ZSBk ZXZpY2UuIFRoZSB2YWxpZGF0aW9uIHJlcXVlc3QgTVVTVA0KPj4+Pj4+IGluY2x1ZGUgdGhlIHNs YXZlIGRldmljZSBJRC4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBQLjE2OiBUaGUgcHJvdG9j b2wgTVVTVCBzdXBwb3J0IGEgdmFsaWRhdGlvbiByZXNwb25zZSBmcm9tIHRoZQ0KPj4+Pj4+IGRh dGFiYXNlDQo+Pj4+Pj4gdG8NCj4+Pj4+PiB0aGUgbWFzdGVyLiBUaGUgdmFsaWRhdGlvbiByZXNw b25zZSBNVVNUIGluY2x1ZGUgYSByZXNwb25zZSBjb2RlLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+ Pj4+IFAuMTc6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlc3Bv bnNlIGZyb20gdGhlDQo+Pj4+Pj4gbWFzdGVyDQo+Pj4+Pj4gZGV2aWNlIHRvIHRoZSBzbGF2ZSBk ZXZpY2UuIFRoZSBjaGFubmVsIHF1ZXJ5IHJlc3BvbnNlIG1lc3NhZ2UgTVVTVA0KPj4+Pj4+IGlu Y2x1ZGUgcGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVt ZW50LA0KPj4+Pj4+IGluY2x1ZGluZw0KPj4+Pj4+IGEgcmVzcG9uc2UgY29kZSBhbmQgc3VmZmlj aWVudCBpbmZvcm1hdGlvbiB0byBkZWNvZGUgYW4gZW5hYmxpbmcNCj4+Pj4+PiBzaWduYWwuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUC4xODogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBh biBlbmFibGluZyBzaWduYWwgc2VudCBmcm9tIHRoZQ0KPj4+Pj4+IG1hc3Rlcg0KPj4+Pj4+IHRv DQo+Pj4+Pj4gdGhlIHNsYXZlLiBUaGlzIHNpZ25hbCBNVVNUIGFsbG93IHRoZSBzbGF2ZSBkZXZp Y2UgdG8gdmFsaWRhdGUgdGhhdA0KPj4+Pj4+YQ0KPj4+Pj4+IHByZXZpb3VzbHkgcmVjZWl2ZWQg YXZhaWxhYmxlIGNoYW5uZWwgbGlzdCBpcyBzdGlsbCB2YWxpZCBvciBub3QuDQo+Pj4+Pj5UaGlz DQo+Pj4+Pj4gc2lnbmFsIE1VU1QgYmUgZW5jb2RlZCB0byBhbGxvdyB0aGUgc2xhdmUgZGV2aWNl IHRvIGRldGVybWluZSB0aGUNCj4+Pj4+PiBpZGVudGl0eQ0KPj4+Pj4+IGlmIHRoZSBzZW5kaW5n IG1hc3RlciBkZXZpY2UuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gUC4xOTog VGhlIHByb3RvY29sIGJldHdlZW4gdGhlIG1hc3RlciBkZXZpY2UgYW5kIHRoZSBkYXRhYmFzZSBN VVNUDQo+Pj4+Pj4gc3VwcG9ydA0KPj4+Pj4+IHRoZSBjYXBhYmlsaXR5IHRvIGNoYW5nZSBjaGFu bmVsIGF2YWlsYWJpbGl0eSBsaXN0cyBvbiBzaG9ydCBub3RpY2UuDQo+Pj4+Pj4gDQo+Pj4+Pj4g DQo+Pj4+Pj4gDQo+Pj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIG1vYmls aXR5IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+Pj4+PiBQLjIwOiBUaGUgcHJvdG9jb2wgYmV0d2Vl biB0aGUgbWFzdGVyIGRldmljZSBhbmQgdGhlIGRhdGFiYXNlIE1VU1QNCj4+Pj4+PiBzdXBwb3J0 DQo+Pj4+Pj4gYSBjaGFubmVsIGF2YWlsYWJpbGl0eSByZXF1ZXN0IHdoaWNoIHNwZWNpZmllcyBh IGdlb2dyYXBoaWMgbG9jYXRpb24NCj4+Pj4+PiBhcw0KPj4+Pj4+IGFuDQo+Pj4+Pj4gYXJlYSBh cyB3ZWxsIGFzIGEgcG9pbnQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+ Pj4+Pj4gDQo+Pj4+Pj4gTy4gT3BlcmF0aW9uYWwgUmVxdWlyZW1lbnRzOg0KPj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBkaXNjb3Zlcnkg ZnVuY3Rpb248L0VkLiBOb3RlPg0KPj4+Pj4+IA0KPj4+Pj4+IE8uMTogVGhlIGRhdGFiYXNlIGFu ZCB0aGUgbWFzdGVyIGRldmljZSBNVVNUIGJlIGNvbm5lY3RlZCB0byB0aGUNCj4+Pj4+PiBJbnRl cm5ldC4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPLjI6ICBBIG1hc3RlciBkZXZpY2UgTVVT VCBiZSBhYmxlIHRvIGRldGVybWluZSBpdHMgbG9jYXRpb24NCj4+Pj4+PmluY2x1ZGluZw0KPj4+ Pj4+IHVuY2VydGFpbnR5IGFuZCBjb25maWRlbmNlIGxldmVsLiBBIGZpeGVkIG1hc3RlciBkZXZp Y2UgTUFZIHVzZSBhDQo+Pj4+Pj4gbG9jYXRpb24NCj4+Pj4+PiBwcm9ncmFtbWVkIGF0IGluc3Rh bGxhdGlvbiBvciBoYXZlIHRoZSBjYXBhYmlsaXR5IGRldGVybWluZSBpdHMNCj4+Pj4+PiBsb2Nh dGlvbg0KPj4+Pj4+IHRvIHRoZSByZXF1aXJlZCBhY2N1cmFjeS4gQSBtb2JpbGUgbWFzdGVyIGRl dmljZSBNVVNUIGhhdmUgdGhlDQo+Pj4+Pj4gY2FwYWJpbGl0eQ0KPj4+Pj4+IHRvIGRldGVybWlu ZSBpdHMgbG9jYXRpb24gdG8gdGhlIHJlcXVpcmVkIGFjY3VyYWN5Lg0KPj4+Pj4+IA0KPj4+Pj4+ IA0KPj4+Pj4+IE8uMzogVGhlIG1hc3RlciBkZXZpY2UgTVVTVCBpZGVudGlmeSBhIGRhdGFiYXNl IGZvciB1c2UuIFRoZSBtYXN0ZXINCj4+Pj4+PiBkZXZpY2UNCj4+Pj4+PiBNQVkgc2VsZWN0IGEg ZGF0YWJhc2UgZm9yIHNlcnZpY2UgYnkgZGlzY292ZXJ5IGF0IHJ1bnRpbWUgb3IgdGhlDQo+Pj4+ Pj4gbWFzdGVyDQo+Pj4+Pj4gZGV2aWNlIE1BWSBzZWxlY3QgYSBkYXRhYmFzZSBmb3Igc2Vydmlj ZSBieSBtZWFucyBvZiBhDQo+Pj4+Pj5wcmUtcHJvZ3JhbW1lZA0KPj4+Pj4+IFVSSQ0KPj4+Pj4+ IGFkZHJlc3MuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gTy40OiBUaGUgbWFzdGVyIGRldmlj ZSBNVVNUIGltcGxlbWVudCBhdCBsZWFzdCBvbmUgY29ubmVjdGlvbiBtZXRob2QNCj4+Pj4+PiB0 bw0KPj4+Pj4+IGFjY2VzcyB0aGUgZGF0YWJhc2UuIFRoZSBtYXN0ZXIgZGV2aWNlIE1BWSBjb250 YWN0IGEgZGF0YWJhc2UNCj4+Pj4+PmRpcmVjdGx5DQo+Pj4+Pj4gZm9yDQo+Pj4+Pj4gc2Vydmlj ZSAoZS5nLiBhcyBkZWZpbmVkIGJ5IEZDQykgb3IgdGhlIG1hc3RlciBkZXZpY2UgTUFZIGNvbnRh Y3QgYQ0KPj4+Pj4+IGxpc3Rpbmcgc2VydmVyIGZpcnN0IGZvbGxvd2VkIGJ5IGNvbnRhY3QgdG8g YSBkYXRhYmFzZSAoZS5nLiBBcw0KPj4+Pj4+IGRlZmluZWQNCj4+Pj4+PiBieQ0KPj4+Pj4+IE9m Y29tKS4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPLjU6IFRoZSBtYXN0ZXIgZGV2aWNlIE1V U1Qgb2J0YWluIGFuIGluZGljYXRpb24gdGhlIHJlZ3VsYXRvcnkNCj4+Pj4+PmRvbWFpbg0KPj4+ Pj4+IGdvdmVybmluZyBvcGVyYXRpb24gYXQgaXRzIGN1cnJlbnQgbG9jYXRpb24sIGkuZS4gdGhl IG1hc3RlciBkZXZpY2UNCj4+Pj4+PiBNVVNUDQo+Pj4+Pj4ga25vdyBpZiBpdCBvcGVyYXRlcyB1 bmRlciByZWd1bGF0aW9ucyBmcm9tIEZDQywgT2Zjb20sIGV0Y8WgDQo+Pj4+Pj4gDQo+Pj4+Pj4g DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVk IHRvIHJlZ2lzdHJhdGlvbiBmdW5jdGlvbjwvRWQuIE5vdGU+DQo+Pj4+Pj4gTy42OiBUaGUgbWFz dGVyIGRldmljZSBNQVkgcmVnaXN0ZXIgd2l0aCB0aGUgZGF0YWJhc2UgYWNjb3JkaW5nIHRvDQo+ Pj4+Pj4gbG9jYWwNCj4+Pj4+PiByZWd1bGF0b3J5IHBvbGljeS4gTm90IGFsbCBtYXN0ZXIgZGV2 aWNlcyB3aWxsIGJlIHJlcXVpcmVkIHRvDQo+Pj4+Pj4gcmVnaXN0ZXIuDQo+Pj4+Pj4gU3BlY2lm aWMgZXZlbnRzIHdpbGwgaW5pdGlhdGUgcmVnaXN0cmF0aW9uLCB0aGVzZSBldmVudHMgYXJlDQo+ Pj4+Pj4gZGV0ZXJtaW5lZA0KPj4+Pj4+IGJ5DQo+Pj4+Pj4gcmVndWxhdG9yIHBvbGljeSAoZS5n LiBhdCBwb3dlciB1cCwgYWZ0ZXIgbW92ZW1lbnQsIGV0Y8WgKS4NCj4+Pj4+PiANCj4+Pj4+PiAN Cj4+Pj4+PiBPLjc6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgcmVnaXN0ZXIgd2l0aCBpdHMgbW9z dCBjdXJyZW50IGFuZA0KPj4+Pj4+IHVwLXRvLWRhdGUNCj4+Pj4+PiBpbmZvcm1hdGlvbi4NCj4+ Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiA8RWQuIE5vdGU+cmVxdWly ZW1lbnRzIHJlbGF0ZWQgdG8gaG90c3BvdCB1c2UgY2FzZTwvRWQuIE5vdGU+DQo+Pj4+Pj4gTy44 OiBBIG1hc3RlciBkZXZpY2UgTVVTVCBxdWVyeSB0aGUgZGF0YWJhc2UgZm9yIHRoZSBhdmFpbGFi bGUNCj4+Pj4+PiBjaGFubmVscw0KPj4+Pj4+IGJhc2VkIG9uIGl0cyBjdXJyZW50IGxvY2F0aW9u IGJlZm9yZSBzdGFydGluZyByYWRpbyB0cmFuc21pc3Npb24gaW4NCj4+Pj4+PiB3aGl0ZQ0KPj4+ Pj4+IHNwYWNlLiBQYXJhbWV0ZXJzIHByb3ZpZGVkIHRvIHRoZSBkYXRhYmFzZSBNQVkgaW5jbHVk ZSBkZXZpY2UNCj4+Pj4+PiBsb2NhdGlvbiwNCj4+Pj4+PiBhY2N1cmFjeSBvZiB0aGUgbG9jYXRp b24sIGFudGVubmEgY2hhcmFjdGVyaXN0aWMgaW5mb3JtYXRpb24sIGRldmljZQ0KPj4+Pj4+IGlk ZW50aWZpZXIgb2YgYW55IHNsYXZlIGRldmljZSByZXF1ZXN0aW5nIGNoYW5uZWwgaW5mb3JtYXRp b24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gTy45OiBUaGUgZGF0YWJhc2UgTVVTVCByZXNw b25kIHRvIGFuIGF2YWlsYWJsZSBjaGFubmVsIGxpc3QgcmVxdWVzdA0KPj4+Pj4+IGZyb20NCj4+ Pj4+PiBhbiBhdXRoZW50aWNhdGVkIGFuZCBhdXRob3JpemVkIGRldmljZSBhbmQgTUFZIGFsc28g cHJvdmlkZSB0aW1lDQo+Pj4+Pj4gY29uc3RyYWludHMsIG1heGltdW0gb3V0cHV0IHBvd2VyLCBz dGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcyBmb3INCj4+Pj4+PmVhY2gNCj4+Pj4+PiBjaGFubmVs IGluIHRoZSBsaXN0IGFuZCBhbnkgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgZm9yIHNlbnNpbmcu DQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gTy4xMDogQWZ0ZXIgY29ubmVjdGluZyB0byBhIG1h c3RlciBkZXZpY2XCuXMgcmFkaW8gbmV0d29yayBhIHNsYXZlDQo+Pj4+Pj4gZGV2aWNlDQo+Pj4+ Pj4gTVVTVCBxdWVyeSB0aGUgbWFzdGVyIGRldmljZSBmb3IgYSBsaXN0IG9mIGF2YWlsYWJsZSBj aGFubmVscy4gVGhlDQo+Pj4+Pj4gc2xhdmUNCj4+Pj4+PiBNVVNUIGluY2x1ZGUgcGFyYW1ldGVy cyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgZS5nLg0KPj4+Pj4+IGRldmlj ZQ0KPj4+Pj4+IElELCBkZXZpY2UgbG9jYXRpb24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g Ty4xMTogQWNjb3JkaW5nIHRvIGxvY2FsIHJlZ3VsYXRvcnkgcG9saWN5LCB0aGUgbWFzdGVyIGRl dmljZSBNQVkNCj4+Pj4+PiBxdWVyeQ0KPj4+Pj4+IHRoZSBkYXRhYmFzZSB3aXRoIHBhcmFtZXRl cnMgcmVjZWl2ZWQgZnJvbSB0aGUgc2xhdmUgZGV2aWNlLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+ Pj4+IE8uMTI6IFRoZSBkYXRhYmFzZSBNVVNUIHJlc3BvbmQgdG8gYSBxdWVyeSBmcm9tIHRoZSBt YXN0ZXIgZGV2aWNlDQo+Pj4+Pj4gY29udGFpbmluZyBwYXJhbWV0ZXJzIGZyb20gYSBzbGF2ZSBk ZXZpY2UuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gTy4xMzogQWZ0ZXIgdGhlIG1hc3RlciBk ZXZpY2UgaGFzIHJlY2VpdmVkIGEgcmVzcG9uc2UgZnJvbSB0aGUNCj4+Pj4+PiBkYXRhYmFzZSwN Cj4+Pj4+PiB0aGUgbWFzdGVyIGRldmljZSBNVVNUIHJlc3BvbmQgdG8gdGhlIHNsYXZlIGRldmlj ZS4gSWYgYWxsDQo+Pj4+Pj5yZWd1bGF0b3J5DQo+Pj4+Pj4gcmVxdWlyZW1lbnRzIGFyZSBtZXQg dGhlIHJlc3BvbnNlIHdpbGwgY29udGFpbiBhbiBhdmFpbGFibGUgY2hhbm5lbA0KPj4+Pj4+IGxp c3QuDQo+Pj4+Pj4gSWYgcmVndWxhdG9yeSByZXF1aXJlbWVudHMgYXJlIG5vdCBtZXQsIHRoZSBy ZXNwb25zZSBNVVNUIGNvbnRhaW4gYXQNCj4+Pj4+PiBsZWFzdA0KPj4+Pj4+IGEgcmVzcG9uc2Ug Y29kZS4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBPLjE0OiBJZiBhIG1hc3RlciBkZXZpY2Ug aGFzIHByb3ZpZGVkIGFuIGF2YWlsYWJsZSBjaGFubmVsIGxpc3QgdG8gYQ0KPj4+Pj4+IHNsYXZl DQo+Pj4+Pj4gZGV2aWNlIHRoZSBtYXN0ZXIgZGV2aWNlIE1BWSBzZW5kIGEgcGVyaW9kaWMgZW5h Ymxpbmcgc2lnbmFsIHRvDQo+Pj4+Pj5hbGxvdw0KPj4+Pj4+IHRoZQ0KPj4+Pj4+IHNsYXZlIGRl dmljZSB0byBjb25maXJtIGl0IGlzIHN0aWxsIHdpdGhpbiByZWNlcHRpb24gcmFuZ2Ugb2YgdGhl DQo+Pj4+Pj4gbWFzdGVyDQo+Pj4+Pj4gZGV2aWNlLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+ IE8uMTU6IFRoZSBlbmFibGluZyBzaWduYWwgTVVTVCBiZSBlbmNvZGVkIHNvIHRoYXQgdGhlIHJl Y2VpdmluZw0KPj4+Pj4+c2xhdmUNCj4+Pj4+PiBjYW4NCj4+Pj4+PiBkZXRlcm1pbmUgdGhlIGlk ZW50aXR5IG9mIHRoZSBzZW5kaW5nIG1hc3Rlci4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBP LjE2OiBQZXJpb2RpY2FsbHksIGF0IGFuIGludGVydmFsIGFjY29yZGluZyB0byBsb2NhbCByZWd1 bGF0aW9ucywNCj4+Pj4+PnRoZQ0KPj4+Pj4+IHNsYXZlIGRldmljZSBNVVNUIGVpdGhlciByZWNl aXZlIGFuZCBlbmFibGluZyBzaWduYWwgb3IgTVVTVA0KPj4+Pj4+IHN1Y2Nlc3NmdWxseQ0KPj4+ Pj4+IHJlcGVhdCB0aGUgY2hhbm5lbCByZXF1ZXN0IHByb2Nlc3Mgb3IgTVVTVCBjZWFzZSB0cmFu c21pc3Npb24gb24gdGhlDQo+Pj4+Pj4gY2hhbm5lbC4NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+ PiBPLjE3OiBBIG1hc3RlciBkZXZpY2UgTVVTVCByZXBlYXQgdGhlIHF1ZXJ5IHRoZSBkYXRhYmFz ZSBmb3IgdGhlDQo+Pj4+Pj4gYXZhaWxhYmxlDQo+Pj4+Pj4gY2hhbm5lbHMgYXMgb2Z0ZW4gYXMg cmVxdWlyZWQgYnkgdGhlIHJlZ3VsYXRpb24gKGVnLCBGQ0MgcmVxdWlyZXMNCj4+Pj4+Pm9uY2UN Cj4+Pj4+PiBwZXINCj4+Pj4+PiBkYXkpIHRvIHZlcmlmeSB0aGF0IHRoZSBvcGVyYXRpbmcgY2hh bm5lbHMgY29udGludWUgdG8gcmVtYWluDQo+Pj4+Pj4gYXZhaWxhYmxlLg0KPj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+IE8uMTg6IEEgbWFzdGVyIGRldmljZSB3aGljaCBjaGFuZ2VzIGl0cyBsb2Nh dGlvbiBtb3JlIHRoYW4gYQ0KPj4+Pj4+dGhyZXNob2xkDQo+Pj4+Pj4gZGlzdGFuY2Ugc3BlY2lm aWVkIGJ5IGxvY2FsIHJlZ3VsYXRvcnkgcG9saWN5IGR1cmluZyBpdHMgb3BlcmF0aW9uLA0KPj4+ Pj4+IE1VU1QNCj4+Pj4+PiBxdWVyeSB0aGUgZGF0YWJhc2UgZm9yIGF2YWlsYWJsZSBvcGVyYXRp bmcgY2hhbm5lbHMgZWFjaCB0aW1lIGl0DQo+Pj4+Pj5tb3Zlcw0KPj4+Pj4+IG1vcmUgdGhhbiB0 aGUgdGhyZXNob2xkIGRpc3RhbmNlIChlLmcuLCBGQ0Mgc3BlY2lmaWVzIDEwMG0pIGZyb20gdGhl DQo+Pj4+Pj4gbG9jYXRpb24gaXQgcHJldmlvdXNseSBtYWRlIHRoZSBxdWVyeS4NCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQg dG8gd3JhbiB1c2UgY2FzZTwvRWQuIE5vdGU+DQo+Pj4+Pj4gTy4xOTogSWYgc2xhdmUgZGV2aWNl cyBjaGFuZ2UgdGhlaXIgbG9jYXRpb24gZHVyaW5nIG9wZXJhdGlvbiBieQ0KPj4+Pj4+bW9yZQ0K Pj4+Pj4+IHRoYW4NCj4+Pj4+PiBhIGxpbWl0IHNwZWNpZmllZCBieSB0aGUgbG9jYWwgcmVndWxh dG9yLCB0aGUgc2xhdmUgZGV2aWNlIE1VU1QNCj4+Pj4+PnF1ZXJ5DQo+Pj4+Pj4gdGhlDQo+Pj4+ Pj4gbWFzdGVyIGRldmljZSBmb3IgYXZhaWxhYmxlIG9wZXJhdGluZyBjaGFubmVscy4NCj4+Pj4+ PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0 ZWQgdG8gcmFwaWQgZGVwbG95ZWQgbmV0d29yayB1c2UNCj4+Pj4+PmNhc2U8L0VkLg0KPj4+Pj4+ IE5vdGU+DQo+Pj4+Pj4gTy4yMDogQWNjb3JkaW5nIHRvIGxvY2FsIHJlZ3VsYXRvciBwb2xpY3ks IGEgbWFzdGVyIGRldmljZSBtYXkNCj4+Pj4+PiBjb250YWN0IGENCj4+Pj4+PiBkYXRhYmFzZSB2 aWEgcHJveHkgc2VydmljZSBvZiBhbm90aGVyIG1hc3RlciBkZXZpY2UuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIG1v YmlsaXR5IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+Pj4+PiBPLjIxOiBBIG1hc3RlciBkZXZpY2Ug TVVTVCBiZSBhYmxlIHRvIHF1ZXJ5IHRoZSB3aGl0ZXNwYWNlIGRhdGFiYXNlDQo+Pj4+Pj4gZm9y DQo+Pj4+Pj4gY2hhbm5lbCBhdmFpbGFiaWxpdHkgaW5mb3JtYXRpb24gZm9yIGEgc3BlY2lmaWMg ZXhwZWN0ZWQgY292ZXJhZ2UNCj4+Pj4+PmFyZWENCj4+Pj4+PiBhcm91bmQgaXRzIGN1cnJlbnQg bG9jYXRpb24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gPEVkLiBOb3RlPnJl cXVpcmVtZW50cyByZWxhdGVkIHRvIHRocmVhdCBtb2RlbDwvRWQuIE5vdGU+DQo+Pj4+Pj4gTy4y MjogQSBNYXN0ZXIgZGV2aWNlIE1BWSBub3QgaW5jbHVkZSBpdHMgaWRlbnRpdHkgaW4NCj4+Pj4+ PiBtZXNzYWdlcyBzZW50IHRvIHRoZSBkYXRhYmFzZSB3aGVuIG5vdCByZXF1aXJlZCBieSB0aGUg cmVndWxhdG9yeQ0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gcGF3cyBtYWlsaW5n IGxpc3QNCj4+Pj4+PiBwYXdzQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYXdzDQo+Pj4+PiANCj4+Pj4gDQo+Pj4gDQo+PiANCj4NCg0K From jstine@mitre.org Mon Feb 27 13:13:20 2012 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 46A0021E8042 for ; Mon, 27 Feb 2012 13:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.591 X-Spam-Level: X-Spam-Status: No, score=-5.591 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-fiBD3HpMU1 for ; Mon, 27 Feb 2012 13:13:19 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5B221E803A for ; Mon, 27 Feb 2012 13:13:19 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A6DD221B132B for ; Mon, 27 Feb 2012 16:13:18 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9C5AB21B0DA8 for ; Mon, 27 Feb 2012 16:13:18 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Mon, 27 Feb 2012 16:13:18 -0500 From: "Stine, John A." To: "paws@ietf.org" Thread-Topic: Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXA== Date: Mon, 27 Feb 2012 21:13:17 +0000 Message-ID: <2782C93FD2244441893673F3F9128192114D0B@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [paws] Further explanation of partitioned data models 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: Mon, 27 Feb 2012 21:13:20 -0000 >From the lack of response to my email last week, I assume folks just don't = understand why I am recommending the division of the data model. Please le= t me explain in a different way. Last December, at the SDR Forum, Julius Knapp, the Director of the OET at t= he FCC, hosted a panel attended by five of the ten database administrators.= In that panel, he asked the panelists what was in it for them. Several r= esponded that they hoped they could provide a service to those looking for = spectrum and to help broker these arrangements. =20 This is not the model of TVWS. At present, the urgency of the paws effort = surrounds a narrower goal of enabling TVWS devices to obtain channels they = can use. I do not want to make any suggestions that would prevent us from = achieving this goal first. I do want to make an effort to prevent what is = done from becoming an impediment to a bigger role for whitespace database a= dministration in the future, one of managing coexistence and brokering spec= trum reuse. In all methods of using a database where a device negotiates with a databas= e, the types of messages that will be used are likely to be similar:=20 - This is who I am, what rules should I apply in negotiating for spectrum? = =20 - This is the spectrum I am looking for, what do you have?=20 - This is the spectrum that meets your query criteria. =20 - etc. The methods developed for trust are also reusable. This is the reason for = having a portion of the data model remain the same for all expansions. The differences between a TVWS scenario and a brokering scenario are likely= to be additional messaging and different data, both for the business of br= okering and for defining the spectrum authorization. For example, in the b= rokering use case there needs to be a spectrum data model that allows a pri= mary spectrum user to release spectrum into the market, (e.g., provide thei= r contours ) and to specify the terms of use. My concern is that if the da= ta model of TVWS comingles the data of messaging, administration, and spect= rum; that this sort of expansion of paws would require increasing the size = of the data model and would make expanding its capability more difficult bo= th because of the impact of this expansion on legacy uses and because of th= e confusion of using large schemas that have similar but different data ele= ments. =20 My solution is to divide the data model into three parts. The data documen= t of messages would use the namespace of three schemas. In the TVWS editio= n, this would also allow different administrative and spectrum schemas for = different regulatory domains. In end, the data for TVWS management would n= ot be any different, it would just be defined in three schemas In the initial exchanges between a device and a database, there would be ag= reement on which schemas to use. This is equivalent to resolving the regul= atory domain. The messaging that follows would be the exact same, with the= exact same data as the messaging if a comingled data model were used. If the division is done well, then, in the long term, others can create sch= emas for administration and spectrum definition that meets their business n= eeds without having to do so through paws. They would be able expand the w= ay the paws protocol is used without having to revise paws. I hope this better explains my intent. It would also be helpful to underst= and why anyone thinks this should not be done. John From teco@inf-net.nl Mon Feb 27 13:23:11 2012 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 E1ED521E804F for ; Mon, 27 Feb 2012 13:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.005 X-Spam-Level: X-Spam-Status: No, score=-3.005 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKbDPwdxWmOd for ; Mon, 27 Feb 2012 13:23:10 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B451421E804D for ; Mon, 27 Feb 2012 13:23:09 -0800 (PST) Received: by eeke51 with SMTP id e51so1008876eek.31 for ; Mon, 27 Feb 2012 13:23:08 -0800 (PST) Received-SPF: pass (google.com: domain of teco@inf-net.nl designates 10.213.34.196 as permitted sender) client-ip=10.213.34.196; Authentication-Results: mr.google.com; spf=pass (google.com: domain of teco@inf-net.nl designates 10.213.34.196 as permitted sender) smtp.mail=teco@inf-net.nl Received: from mr.google.com ([10.213.34.196]) by 10.213.34.196 with SMTP id m4mr4625852ebd.51.1330377788980 (num_hops = 1); Mon, 27 Feb 2012 13:23:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=zO77uSMJP1XjBUhJ2m/rokUvWm2uj05kmot0VL5JxTU=; b=cHnVjVhpHN7jrDc/34gqBQklxjaznjK6dL9K0HkuFKVSv4KkxS1P2j9ojBrov/xm5i 91FCEqHGnqlEpr51lZyV+QAsspmlzdG3u3phJl8YrO5SOYZFKkFC2MWWqRS90LrRDcbw IdTWGmWGGwSiTOW1A4Rh05VU42WvPpSOXQAXM= Received: by 10.213.34.196 with SMTP id m4mr3455074ebd.51.1330377788742; Mon, 27 Feb 2012 13:23:08 -0800 (PST) Received: from [192.168.178.14] (524A158D.cm-4-3a.dynamic.ziggo.nl. [82.74.21.141]) by mx.google.com with ESMTPS id z7sm15414116eef.9.2012.02.27.13.23.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Feb 2012 13:23:08 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Teco Boot In-Reply-To: Date: Mon, 27 Feb 2012 22:23:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4C3A6C42-0D46-4A94-81AE-6D7B258B2462@inf-net.nl> References: To: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlTL/MSiXhidB2rKsEMcJBLHoZP5WEyayKhXZrYRMEKAEgVrHlPKjoFkeWSelwD0aDdwG1h Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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: Mon, 27 Feb 2012 21:23:12 -0000 Hi Scott, Op 27 feb. 2012, om 21:46 heeft = het volgende geschreven: > Hi Teco, >=20 > We could change O.7 to something like: >=20 > O.7: The master device MUST register with its most current and = up-to-date > information, and MUST include all variables mandated by local = regulator > policy. >=20 > Would this work? Yes, this is fine. And remove P.10? Thanks, Teco >=20 > Kind Regards, > Scott >=20 >=20 >=20 > On 2/27/12 2:25 PM, "ext Teco Boot" wrote: >=20 >> Hello Scott, >>=20 >> I understand your point. But I want to keep things simple. The >> P.* requirements are for the protocol, it MUST support optional >> variables. >> The O.* requirements explain how these are used. This is the MAY, >> right?=20 >>=20 >> Having performed some tests today with an emergency responders >> network, I saw some high traffic load. Something like this: >> >> 1 >> <\self_explaining_variable_name> >> I could think of an efficiency requirement, for the rapid deployed >> network use case. >>=20 >> Thanks, Teco >>=20 >>=20 >> Op 27 feb. 2012, om 14:32 heeft >> het volgende geschreven: >>=20 >>> Hi Teco, >>>=20 >>> If we look at P.9 and P.10 together, P.9 says that registration is a >>> MUST >>> -- the protocol supports registration without question. P.10 says = the >>> signaling for registration MAY contain any of several variables = (also >>> allows more variables to be included if required by local = regulations). >>> The list currently identifies all variables required for = registration in >>> the US. Now if we look at the Data Model requirements, each variable >>> identified that the registration service MAY contain (these are in = D.5, >>> D.6, D.1, D.7 and D.8) MUST be included in the Data Model. The = protocol >>> MUST support registration, and the Data Model in the protocol MUST >>> support >>> the variables identified for registration service. >>>=20 >>> The current use of MUST in P.9 and MAY in P.10 has the effect that = WSDs >>> in >>> the US are allowed to register (because the protocol supports >>> registration) and are allowed to use the variables defined by the = FCC >>> (because the registration signaling MAY include those variables). = This >>> also has the effect that WSDs in the UK (or elsewhere in the world) = are >>> allowed to register if this is a local requirement (because the = protocol >>> supports registration) and are allowed to use (or not use) the = variables >>> defined by the FCC (because the registration signaling MAY include = those >>> variables). Nothing to prevent adding more variables if needed by = Ofcom, >>> IDA, etc... >>>=20 >>> Another possibility is to change the wording of P.10 to read >>> P.10: The registration signaling MUST include the following optional >>> variables: the Device ID, manufacturer=B9s serial number, device = location, >>> device antenna characteristic information, name of individual or >>> business >>> that owns the device, name, address, email address and phone number = of a >>> contact person who is responsible for device operation. >>>=20 >>> What do you think? >>>=20 >>> Kind Regards, >>> Scott >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On 2/26/12 3:41 PM, "ext Teco Boot" wrote: >>>=20 >>>> Hi Scott, >>>>=20 >>>> I still think it is a MUST for the protocol, and a MAY for usage. >>>>=20 >>>> Thanks, Teco >>>>=20 >>>> Op 24 feb. 2012, om 19:58 heeft >>>> het volgende geschreven: >>>>=20 >>>>> Hello Teco, >>>>>=20 >>>>> Since PAWS is a global standard, registration for all regulatory >>>>> domains >>>>> must be supported. While the FCC does require all of the variables >>>>> listed >>>>> in P.10, other regulatory domains may not require each of those >>>>> variables. >>>>> So for requirements on the protocol, using MAY enables the FCC to >>>>> require >>>>> these variables while allowing other regulators to select a = subset, or >>>>> even different, variables. >>>>>=20 >>>>> With this explanation, are you okay with MAY in P.10? >>>>>=20 >>>>> Kind Regards, >>>>> Scott >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 2/22/12 1:34 AM, "ext Teco Boot" wrote: >>>>>=20 >>>>>> Scott, Ray, >>>>>>=20 >>>>>> The P.* are mostly MUST requirements for the protocol. That's = fine. >>>>>> Except P.10, this is a MAY operational requirement. The protocol >>>>>> MUST support it. >>>>>>=20 >>>>>> I'm fine with the rest of it. >>>>>>=20 >>>>>> Is noted somewhere that we (IETF) do our best to support as many >>>>>> regulator rules as possible, and leave setting up requirements = for >>>>>> actual deployment up to the mandated authorities? This makes the >>>>>> O.* requirements informational. >>>>>>=20 >>>>>> Thanks, Teco >>>>>>=20 >>>>>>=20 >>>>>> Op 22 feb. 2012, om 00:53 heeft >>>>>> het volgende geschreven: >>>>>>=20 >>>>>>> Hello All, >>>>>>>=20 >>>>>>> I have revised Section 6 of the I-D which describes the Data = Model >>>>>>> Requirements, Protocol Requirements and Operational = Requirements. >>>>>>> This >>>>>>> includes the requirements from the threat model >>>>>>> = (http://www.ietf.org/mail-archive/web/paws/current/msg00771.html). >>>>>>>=20 >>>>>>> The requirements are ordered "top down" to follow the previous >>>>>>> sections >>>>>>> of >>>>>>> the document: requirements derived from discovery are followed = by >>>>>>> requirements derived from registration are followed by = requirements >>>>>>> derived from hotspot, etc... >>>>>>>=20 >>>>>>> Please review the proposed text, we hope to have your comments = by >>>>>>> Feb >>>>>>> 28th. >>>>>>>=20 >>>>>>> Kind Regards, >>>>>>>=20 >>>>>>> Raj & Scott >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> D. Data Model Requirements: >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to discovery function >>>>>>> D.1: The Data Model MUST support specifying the location of the = WSD, >>>>>>> the >>>>>>> uncertainty in meters, the height & its uncertainty, and = confidence >>>>>>> in >>>>>>> percentage for the location determination. The Data Model MUST >>>>>>> support >>>>>>> both North American Datum of 1983 and WGS84. >>>>>>>=20 >>>>>>>=20 >>>>>>> D.2: The Data Model MUST support specifying the URI address of a >>>>>>> white >>>>>>> space database. >>>>>>>=20 >>>>>>>=20 >>>>>>> D.3: The Data Model MUST support specifying the URI address of a >>>>>>> national >>>>>>> listing service. >>>>>>>=20 >>>>>>>=20 >>>>>>> D.4: The Data Model MUST support specifying regulatory domain = and >>>>>>> its >>>>>>> corresponding data requirements. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to registration function >>>>>>> D.5: The Data Model MUST support specifying an ID of the = transmitter >>>>>>> device. This ID would contain the ID of the transmitter device = that >>>>>>> has >>>>>>> been certified by a regulatory body for its regulatory domain. = The >>>>>>> Data >>>>>>> Model MUST support a device class. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> D.6: The Data Model MUST support specifying a manufacturer=B9s = serial >>>>>>> number >>>>>>> for a master device. >>>>>>>=20 >>>>>>>=20 >>>>>>> D.7: The Data Model MUST support specifying the antenna and >>>>>>> radiation >>>>>>> related parameters of the device, such as: >>>>>>>=20 >>>>>>> - antenna height >>>>>>>=20 >>>>>>> - antenna gain >>>>>>>=20 >>>>>>> - maximum output power, EIRP (dBm) >>>>>>>=20 >>>>>>> - antenna radiation pattern (directional dependence >>>>>>> of the strength of the radio signal from the antenna) >>>>>>>=20 >>>>>>> - spectrum mask with lowest and highest possible frequency >>>>>>>=20 >>>>>>> - spectrum mask in dBr from peak transmit power in EIRP, >>>>>>> with specific power limit at any frequency linearly >>>>>>> interpolated between adjacent points of the spectrum mask >>>>>>> measurement resolution bandwidth for EIRP measurements. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> D.8: The Data Model MUST support specifying owner and operator >>>>>>> contact >>>>>>> information for a transmitter. This includes the name of the >>>>>>> transmitter >>>>>>> owner, name of transmitter operator, postal address, email = address >>>>>>> and >>>>>>> phone number of the transmitter operator. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to hotspot use case >>>>>>> D.9: The Data Model MUST support specifying a list of available >>>>>>> channels. >>>>>>> The Data Model MUST support specification of this information by >>>>>>> channel >>>>>>> numbers and by start and stop frequencies. The Data Model MUST >>>>>>> support a >>>>>>> channel availability schedule and maximum power level for each >>>>>>> channel >>>>>>> in >>>>>>> the list. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to mobility use case >>>>>>> D.10: The Data Model MUST support specifying channel = availability >>>>>>> information for a single location and an area (e.g. a polygon >>>>>>> defined >>>>>>> by >>>>>>> multiple location points or a geometric shape such as a circle). >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> P. Protocol Requirements: >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to discovery function >>>>>>> P.1: The protocol MUST provide a message sequence for the master >>>>>>> device >>>>>>> to >>>>>>> discover a white space database that provides service at its = current >>>>>>> location. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.2: The protocol MUST support access of a database directly. = The >>>>>>> protocol >>>>>>> MUST support access of a database using a listing approved by a >>>>>>> national >>>>>>> regulator. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.3: The protocol MUST support determination of regulatory = domain >>>>>>> governing its current location. >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to threat model >>>>>>>=20 >>>>>>>=20 >>>>>>> P.4: The protocol MUST provide the ability for the database to >>>>>>> authenticate the master device. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.5: The protocol MUST provide the ability for the master device = to >>>>>>> verify >>>>>>> the authenticity of the database with which it is interacting. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.6: The messages sent by the master device to the database MUST = be >>>>>>> integrity protected. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.7: The messages sent by the database to the master device MUST = be >>>>>>> integrity protected. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.8: The protocol MUST provide the capability for messages sent = by >>>>>>> the >>>>>>> master device and database to be encrypted. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to registration function >>>>>>> P.9: The protocol MUST support the master device registering = with >>>>>>> the >>>>>>> database. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.10: The registration signaling MAY include the Device ID, >>>>>>> manufacturer=B9s >>>>>>> serial number, device location, device antenna characteristic >>>>>>> information, >>>>>>> name of individual or business that owns the device, name, = address, >>>>>>> email >>>>>>> address and phone number of a contact person who is responsible = for >>>>>>> device >>>>>>> operation. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.11: The protocol MUST support a registration acknowledgement >>>>>>> including >>>>>>> appropriate result codes. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to hotspot use case >>>>>>> P.12: The protocol MUST support a channel query request from the >>>>>>> master >>>>>>> device to the database. The channel query request message MUST >>>>>>> include >>>>>>> parameters as required by local regulatory requirement. These >>>>>>> parameters >>>>>>> MAY include device location, device ID, manufacturer=B9s serial >>>>>>> number, >>>>>>> and >>>>>>> antenna characteristic information. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.13: The protocol MUST support a channel query response from = the >>>>>>> database >>>>>>> to the master device. The channel query response message MUST >>>>>>> include >>>>>>> parameters as required by local regulatory requirement. These >>>>>>> parameters >>>>>>> MAY include available channels, duration of time for their use, >>>>>>> associated >>>>>>> maximum power levels, any additional sensing requirements. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.14: The protocol MUST support a channel query request from the >>>>>>> slave >>>>>>> device to the master device. The channel query request message = MUST >>>>>>> include parameters as required by local regulatory requirement. >>>>>>> These >>>>>>> parameters MAY include device ID and slave device location. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.15: The protocol MUST support a validation request from the = master >>>>>>> to >>>>>>> the database to validate a slave device. The validation request = MUST >>>>>>> include the slave device ID. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.16: The protocol MUST support a validation response from the >>>>>>> database >>>>>>> to >>>>>>> the master. The validation response MUST include a response = code. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.17: The protocol MUST support a channel query response from = the >>>>>>> master >>>>>>> device to the slave device. The channel query response message = MUST >>>>>>> include parameters as required by local regulatory requirement, >>>>>>> including >>>>>>> a response code and sufficient information to decode an enabling >>>>>>> signal. >>>>>>>=20 >>>>>>>=20 >>>>>>> P.18: The protocol MUST support an enabling signal sent from the >>>>>>> master >>>>>>> to >>>>>>> the slave. This signal MUST allow the slave device to validate = that >>>>>>> a >>>>>>> previously received available channel list is still valid or = not. >>>>>>> This >>>>>>> signal MUST be encoded to allow the slave device to determine = the >>>>>>> identity >>>>>>> if the sending master device. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> P.19: The protocol between the master device and the database = MUST >>>>>>> support >>>>>>> the capability to change channel availability lists on short = notice. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to mobility use case >>>>>>> P.20: The protocol between the master device and the database = MUST >>>>>>> support >>>>>>> a channel availability request which specifies a geographic = location >>>>>>> as >>>>>>> an >>>>>>> area as well as a point. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> O. Operational Requirements: >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to discovery function >>>>>>>=20 >>>>>>> O.1: The database and the master device MUST be connected to the >>>>>>> Internet. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.2: A master device MUST be able to determine its location >>>>>>> including >>>>>>> uncertainty and confidence level. A fixed master device MAY use = a >>>>>>> location >>>>>>> programmed at installation or have the capability determine its >>>>>>> location >>>>>>> to the required accuracy. A mobile master device MUST have the >>>>>>> capability >>>>>>> to determine its location to the required accuracy. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.3: The master device MUST identify a database for use. The = master >>>>>>> device >>>>>>> MAY select a database for service by discovery at runtime or the >>>>>>> master >>>>>>> device MAY select a database for service by means of a >>>>>>> pre-programmed >>>>>>> URI >>>>>>> address. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.4: The master device MUST implement at least one connection = method >>>>>>> to >>>>>>> access the database. The master device MAY contact a database >>>>>>> directly >>>>>>> for >>>>>>> service (e.g. as defined by FCC) or the master device MAY = contact a >>>>>>> listing server first followed by contact to a database (e.g. As >>>>>>> defined >>>>>>> by >>>>>>> Ofcom). >>>>>>>=20 >>>>>>>=20 >>>>>>> O.5: The master device MUST obtain an indication the regulatory >>>>>>> domain >>>>>>> governing operation at its current location, i.e. the master = device >>>>>>> MUST >>>>>>> know if it operates under regulations from FCC, Ofcom, etc=8A >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to registration function >>>>>>> O.6: The master device MAY register with the database according = to >>>>>>> local >>>>>>> regulatory policy. Not all master devices will be required to >>>>>>> register. >>>>>>> Specific events will initiate registration, these events are >>>>>>> determined >>>>>>> by >>>>>>> regulator policy (e.g. at power up, after movement, etc=8A). >>>>>>>=20 >>>>>>>=20 >>>>>>> O.7: The master device MUST register with its most current and >>>>>>> up-to-date >>>>>>> information. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to hotspot use case >>>>>>> O.8: A master device MUST query the database for the available >>>>>>> channels >>>>>>> based on its current location before starting radio transmission = in >>>>>>> white >>>>>>> space. Parameters provided to the database MAY include device >>>>>>> location, >>>>>>> accuracy of the location, antenna characteristic information, = device >>>>>>> identifier of any slave device requesting channel information. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.9: The database MUST respond to an available channel list = request >>>>>>> from >>>>>>> an authenticated and authorized device and MAY also provide time >>>>>>> constraints, maximum output power, start and stop frequencies = for >>>>>>> each >>>>>>> channel in the list and any additional requirements for sensing. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.10: After connecting to a master device=B9s radio network a = slave >>>>>>> device >>>>>>> MUST query the master device for a list of available channels. = The >>>>>>> slave >>>>>>> MUST include parameters required by local regulatory policy, = e.g. >>>>>>> device >>>>>>> ID, device location. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.11: According to local regulatory policy, the master device = MAY >>>>>>> query >>>>>>> the database with parameters received from the slave device. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.12: The database MUST respond to a query from the master = device >>>>>>> containing parameters from a slave device. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.13: After the master device has received a response from the >>>>>>> database, >>>>>>> the master device MUST respond to the slave device. If all >>>>>>> regulatory >>>>>>> requirements are met the response will contain an available = channel >>>>>>> list. >>>>>>> If regulatory requirements are not met, the response MUST = contain at >>>>>>> least >>>>>>> a response code. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.14: If a master device has provided an available channel list = to a >>>>>>> slave >>>>>>> device the master device MAY send a periodic enabling signal to >>>>>>> allow >>>>>>> the >>>>>>> slave device to confirm it is still within reception range of = the >>>>>>> master >>>>>>> device. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.15: The enabling signal MUST be encoded so that the receiving >>>>>>> slave >>>>>>> can >>>>>>> determine the identity of the sending master. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.16: Periodically, at an interval according to local = regulations, >>>>>>> the >>>>>>> slave device MUST either receive and enabling signal or MUST >>>>>>> successfully >>>>>>> repeat the channel request process or MUST cease transmission on = the >>>>>>> channel. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.17: A master device MUST repeat the query the database for the >>>>>>> available >>>>>>> channels as often as required by the regulation (eg, FCC = requires >>>>>>> once >>>>>>> per >>>>>>> day) to verify that the operating channels continue to remain >>>>>>> available. >>>>>>>=20 >>>>>>>=20 >>>>>>> O.18: A master device which changes its location more than a >>>>>>> threshold >>>>>>> distance specified by local regulatory policy during its = operation, >>>>>>> MUST >>>>>>> query the database for available operating channels each time it >>>>>>> moves >>>>>>> more than the threshold distance (e.g., FCC specifies 100m) from = the >>>>>>> location it previously made the query. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to wran use case >>>>>>> O.19: If slave devices change their location during operation by >>>>>>> more >>>>>>> than >>>>>>> a limit specified by the local regulator, the slave device MUST >>>>>>> query >>>>>>> the >>>>>>> master device for available operating channels. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to rapid deployed network use >>>>>>> case>>>>>> Note> >>>>>>> O.20: According to local regulator policy, a master device may >>>>>>> contact a >>>>>>> database via proxy service of another master device. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to mobility use case >>>>>>> O.21: A master device MUST be able to query the whitespace = database >>>>>>> for >>>>>>> channel availability information for a specific expected = coverage >>>>>>> area >>>>>>> around its current location. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> requirements related to threat model >>>>>>> O.22: A Master device MAY not include its identity in >>>>>>> messages sent to the database when not required by the = regulatory >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> paws mailing list >>>>>>> paws@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 From peter@spectrumbridge.com Mon Feb 27 13:26:03 2012 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 45D7221E8042 for ; Mon, 27 Feb 2012 13:26:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTIqdTF6ZYIB for ; Mon, 27 Feb 2012 13:26:02 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 4431A21E803B for ; Mon, 27 Feb 2012 13:26:01 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 27 Feb 2012 16:26:41 -0500 From: Peter Stanforth To: "Stine, John A." , "paws@ietf.org" Date: Mon, 27 Feb 2012 16:25:58 -0500 Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1ln8JB8nnK1XARPuBNZSJrSOANw== Message-ID: In-Reply-To: <2782C93FD2244441893673F3F9128192114D0B@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [paws] Further explanation of partitioned data models 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: Mon, 27 Feb 2012 21:26:03 -0000 John, I may be guilty of being one of those panelists you mention, and we also run a secondary marketplace for spectrum, so I speak as someone who has a vested interest in what happens beyond TVWS. I agree with your insight on the potential, both for access to additional spectrum as well as for different business models. I also agree with your summary of the type of negotiation that is likely. Speaking for Spectrum Bridge we can see a way to address those opportunities within the current PAWS construct and don't necessarily need to break anything out. I would want to understand this proposal better as I have two concerns. First it seems difficult to achieve this without significantly complicating the process. Second I am not sure that the result may be worse than where we are today, in that it might confine me to certain modes of operation or not. The only quick, and simple, analogy I can give is Boingo. They have a revenue generating service offered on top of unlicensed WiFi. They do so without any impact on the underlying WiFi MAC/PHY protocols. Our (SBI) concern has been that the PAWS protocol/requirements do not preclude us from being able to offer enhanced and differentiated services and so far we have not been able to identify an issue. I would be happy to continue the discussion in parallel to the initial PAWS effort and would not rule out such a breakup in the future but I think the majority are hoping to get something finished to address TVWS without too much expansion. Regards Peter Stanforth CTO Spectrum Bridge Inc. On MonFeb/27/12 Mon Feb 27, 4:13 PM, "Stine, John A." wrote: >From the lack of response to my email last week, I assume folks just >don't understand why I am recommending the division of the data model. >Please let me explain in a different way. > >Last December, at the SDR Forum, Julius Knapp, the Director of the OET at >the FCC, hosted a panel attended by five of the ten database >administrators. In that panel, he asked the panelists what was in it for >them. Several responded that they hoped they could provide a service to >those looking for spectrum and to help broker these arrangements. > >This is not the model of TVWS. At present, the urgency of the paws >effort surrounds a narrower goal of enabling TVWS devices to obtain >channels they can use. I do not want to make any suggestions that would >prevent us from achieving this goal first. I do want to make an effort >to prevent what is done from becoming an impediment to a bigger role for >whitespace database administration in the future, one of managing >coexistence and brokering spectrum reuse. > >In all methods of using a database where a device negotiates with a >database, the types of messages that will be used are likely to be >similar:=20 >- This is who I am, what rules should I apply in negotiating for >spectrum? =20 >- This is the spectrum I am looking for, what do you have? >- This is the spectrum that meets your query criteria. >- etc. >The methods developed for trust are also reusable. This is the reason >for having a portion of the data model remain the same for all expansions. > >The differences between a TVWS scenario and a brokering scenario are >likely to be additional messaging and different data, both for the >business of brokering and for defining the spectrum authorization. For >example, in the brokering use case there needs to be a spectrum data >model that allows a primary spectrum user to release spectrum into the >market, (e.g., provide their contours ) and to specify the terms of use. >My concern is that if the data model of TVWS comingles the data of >messaging, administration, and spectrum; that this sort of expansion of >paws would require increasing the size of the data model and would make >expanding its capability more difficult both because of the impact of >this expansion on legacy uses and because of the confusion of using large >schemas that have similar but different data elements. > >My solution is to divide the data model into three parts. The data >document of messages would use the namespace of three schemas. In the >TVWS edition, this would also allow different administrative and spectrum >schemas for different regulatory domains. In end, the data for TVWS >management would not be any different, it would just be defined in three >schemas > >In the initial exchanges between a device and a database, there would be >agreement on which schemas to use. This is equivalent to resolving the >regulatory domain. The messaging that follows would be the exact same, >with the exact same data as the messaging if a comingled data model were >used. > >If the division is done well, then, in the long term, others can create >schemas for administration and spectrum definition that meets their >business needs without having to do so through paws. They would be able >expand the way the paws protocol is used without having to revise paws. > >I hope this better explains my intent. It would also be helpful to >understand why anyone thinks this should not be done. > >John >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Feb 27 13:36:31 2012 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 400BD21F8645 for ; Mon, 27 Feb 2012 13:36:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUfEXhe-tmTr for ; Mon, 27 Feb 2012 13:36:30 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAD121F8549 for ; Mon, 27 Feb 2012 13:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1330378626; x=1645733423; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Z7bGjO9+bOxlP3E/NkGAi b3vKGbKgjs9vc9eIT7ivRo=; b=YaWYYs7AqE4CaYYZ151CdPTuvH/Ky127Ru/pu H1u86cTOhLswWLKJEJkm8Zgz9FQQ8PDx4kkOfA7N7QaQYgPfw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.5664067; Mon, 27 Feb 2012 16:37:05 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 27 Feb 2012 16:36:25 -0500 From: "Rosen, Brian" To: "Stine, John A." Date: Mon, 27 Feb 2012 16:36:23 -0500 Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1l9qC6XKzp11IRf68SOaOTYYT/A== Message-ID: <3D628074-0010-46AC-BB4B-CD215B90BD37@neustar.biz> References: <2782C93FD2244441893673F3F9128192114D0B@IMCMBX01.MITRE.ORG> In-Reply-To: <2782C93FD2244441893673F3F9128192114D0B@IMCMBX01.MITRE.ORG> 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: f5kNfm9gpOVmue/++rPMXw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Further explanation of partitioned data models 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: Mon, 27 Feb 2012 21:36:31 -0000 Discussions of spectrum coexistence is explicitly out of scope, and we have= a big enough job to do without increasing scope. The scope is also limited to the problem of a device requesting spectrum, a= nd discussions of provisioning ("releasing new spectrum") is out of scope. = Only the device-to-database query and its response is in scope. If we ever get to coexistence work, the additional messaging is some form o= f "use this explicit spectrum, I'm suggesting that you use it= , even if you could use other spectrum" or "of the choices yo= u gave me, I'll use this part, and please try and keep other users out of m= y way". Either is a simple expansion of the basic query (location and band= in, spectrum choices out). As such, I don't think we have to do anything = in anticipation of such a future capability. I do think the notion of authentication of the device and the database is i= n scope, and I certainly think exchange of credentials or equivalent prece= des spectrum query, so I suspect we're separating that part anyway. I cert= ainly think we're trying to return spectrum choices that depend on location= , device characteristics and things like time of day, and we're trying to d= esign a protocol that will work for any country that decides to open spectr= um for whitespace use and on any band they decide to do so. So long as we = have enough data elements in the query to allow any of the algorithms that = the regulators decide on to determine the available spectrum from the input= query and provisioning information in the database, as well as have suffic= ient flexibility in the response of available spectrum to cover all the lim= its the regulators want to have, we should be okay. So far, I don't see an= y problems staying within the model we have been talking about. Brian On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: > From the lack of response to my email last week, I assume folks just don'= t understand why I am recommending the division of the data model. Please = let me explain in a different way. >=20 > Last December, at the SDR Forum, Julius Knapp, the Director of the OET at= the FCC, hosted a panel attended by five of the ten database administrator= s. In that panel, he asked the panelists what was in it for them. Several= responded that they hoped they could provide a service to those looking fo= r spectrum and to help broker these arrangements. =20 >=20 > This is not the model of TVWS. At present, the urgency of the paws effor= t surrounds a narrower goal of enabling TVWS devices to obtain channels the= y can use. I do not want to make any suggestions that would prevent us fro= m achieving this goal first. I do want to make an effort to prevent what i= s done from becoming an impediment to a bigger role for whitespace database= administration in the future, one of managing coexistence and brokering sp= ectrum reuse. >=20 > In all methods of using a database where a device negotiates with a datab= ase, the types of messages that will be used are likely to be similar:=20 > - This is who I am, what rules should I apply in negotiating for spectrum= ? =20 > - This is the spectrum I am looking for, what do you have?=20 > - This is the spectrum that meets your query criteria. =20 > - etc. > The methods developed for trust are also reusable. This is the reason fo= r having a portion of the data model remain the same for all expansions. >=20 > The differences between a TVWS scenario and a brokering scenario are like= ly to be additional messaging and different data, both for the business of = brokering and for defining the spectrum authorization. For example, in the= brokering use case there needs to be a spectrum data model that allows a p= rimary spectrum user to release spectrum into the market, (e.g., provide th= eir contours ) and to specify the terms of use. My concern is that if the = data model of TVWS comingles the data of messaging, administration, and spe= ctrum; that this sort of expansion of paws would require increasing the siz= e of the data model and would make expanding its capability more difficult = both because of the impact of this expansion on legacy uses and because of = the confusion of using large schemas that have similar but different data e= lements. =20 >=20 > My solution is to divide the data model into three parts. The data docum= ent of messages would use the namespace of three schemas. In the TVWS edit= ion, this would also allow different administrative and spectrum schemas fo= r different regulatory domains. In end, the data for TVWS management would= not be any different, it would just be defined in three schemas >=20 > In the initial exchanges between a device and a database, there would be = agreement on which schemas to use. This is equivalent to resolving the reg= ulatory domain. The messaging that follows would be the exact same, with t= he exact same data as the messaging if a comingled data model were used. >=20 > If the division is done well, then, in the long term, others can create s= chemas for administration and spectrum definition that meets their business= needs without having to do so through paws. They would be able expand the= way the paws protocol is used without having to revise paws. >=20 > I hope this better explains my intent. It would also be helpful to under= stand why anyone thinks this should not be done. >=20 > John > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Feb 27 13:38:58 2012 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 90B9421E8025 for ; Mon, 27 Feb 2012 13:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.937 X-Spam-Level: X-Spam-Status: No, score=-5.937 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2FLLq2wUbyM for ; Mon, 27 Feb 2012 13:38:56 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 77F4B21E800C for ; Mon, 27 Feb 2012 13:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1330378775; x=1645733423; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=aRcPQrZEGXc/YzLWtDzSA 0Ffxl0mRKImxwspRciopMA=; b=LZV6zoe5u0RX8oem4W7dZxMpMgu9HBar+CD5i 43YJfk+UD2We/6mvT46lxpBNiCRSujNAl2erkIofzZGUJYwfw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.5664166; Mon, 27 Feb 2012 16:39:34 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 27 Feb 2012 16:38:54 -0500 From: "Rosen, Brian" To: " " Date: Mon, 27 Feb 2012 16:38:52 -0500 Thread-Topic: [paws] UC&R I-D: Requirements Thread-Index: Acz1mDNpSBDf26akTmaisTKXy78dQw== Message-ID: <2EF37C85-94DC-406C-912B-7118FED4B0C8@neustar.biz> References: 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: +Hynx3lTjYq8f1TQ0+eCpQ== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] UC&R I-D: Requirements 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: Mon, 27 Feb 2012 21:38:58 -0000 I have a small issue here. Device characteristics don't typically change, so having them in some form = of registration transaction makes sense in an engineering sense. However, = some regulators don't seem to understand that, and there are circumstances = where you have to send some of the device information with the spectrum que= ry. We should be flexible enough to handle that. Brian On Feb 27, 2012, at 3:46 PM, wrote: > Hi Teco, > > We could change O.7 to something like: > > O.7: The master device MUST register with its most current and up-to-date > information, and MUST include all variables mandated by local regulator > policy. > > Would this work? > > Kind Regards, > Scott > > > > On 2/27/12 2:25 PM, "ext Teco Boot" wrote: > >> Hello Scott, >> >> I understand your point. But I want to keep things simple. The >> P.* requirements are for the protocol, it MUST support optional >> variables. >> The O.* requirements explain how these are used. This is the MAY, >> right? >> >> Having performed some tests today with an emergency responders >> network, I saw some high traffic load. Something like this: >> >> 1 >> <\self_explaining_variable_name> >> I could think of an efficiency requirement, for the rapid deployed >> network use case. >> >> Thanks, Teco >> >> >> Op 27 feb. 2012, om 14:32 heeft >> het volgende geschreven: >> >>> Hi Teco, >>> >>> If we look at P.9 and P.10 together, P.9 says that registration is a >>> MUST >>> -- the protocol supports registration without question. P.10 says the >>> signaling for registration MAY contain any of several variables (also >>> allows more variables to be included if required by local regulations). >>> The list currently identifies all variables required for registration i= n >>> the US. Now if we look at the Data Model requirements, each variable >>> identified that the registration service MAY contain (these are in D.5, >>> D.6, D.1, D.7 and D.8) MUST be included in the Data Model. The protocol >>> MUST support registration, and the Data Model in the protocol MUST >>> support >>> the variables identified for registration service. >>> >>> The current use of MUST in P.9 and MAY in P.10 has the effect that WSDs >>> in >>> the US are allowed to register (because the protocol supports >>> registration) and are allowed to use the variables defined by the FCC >>> (because the registration signaling MAY include those variables). This >>> also has the effect that WSDs in the UK (or elsewhere in the world) are >>> allowed to register if this is a local requirement (because the protoco= l >>> supports registration) and are allowed to use (or not use) the variable= s >>> defined by the FCC (because the registration signaling MAY include thos= e >>> variables). Nothing to prevent adding more variables if needed by Ofcom= , >>> IDA, etc... >>> >>> Another possibility is to change the wording of P.10 to read >>> P.10: The registration signaling MUST include the following optional >>> variables: the Device ID, manufacturer=B9s serial number, device locati= on, >>> device antenna characteristic information, name of individual or >>> business >>> that owns the device, name, address, email address and phone number of = a >>> contact person who is responsible for device operation. >>> >>> What do you think? >>> >>> Kind Regards, >>> Scott >>> >>> >>> >>> >>> >>> >>> On 2/26/12 3:41 PM, "ext Teco Boot" wrote: >>> >>>> Hi Scott, >>>> >>>> I still think it is a MUST for the protocol, and a MAY for usage. >>>> >>>> Thanks, Teco >>>> >>>> Op 24 feb. 2012, om 19:58 heeft >>>> het volgende geschreven: >>>> >>>>> Hello Teco, >>>>> >>>>> Since PAWS is a global standard, registration for all regulatory >>>>> domains >>>>> must be supported. While the FCC does require all of the variables >>>>> listed >>>>> in P.10, other regulatory domains may not require each of those >>>>> variables. >>>>> So for requirements on the protocol, using MAY enables the FCC to >>>>> require >>>>> these variables while allowing other regulators to select a subset, o= r >>>>> even different, variables. >>>>> >>>>> With this explanation, are you okay with MAY in P.10? >>>>> >>>>> Kind Regards, >>>>> Scott >>>>> >>>>> >>>>> >>>>> On 2/22/12 1:34 AM, "ext Teco Boot" wrote: >>>>> >>>>>> Scott, Ray, >>>>>> >>>>>> The P.* are mostly MUST requirements for the protocol. That's fine. >>>>>> Except P.10, this is a MAY operational requirement. The protocol >>>>>> MUST support it. >>>>>> >>>>>> I'm fine with the rest of it. >>>>>> >>>>>> Is noted somewhere that we (IETF) do our best to support as many >>>>>> regulator rules as possible, and leave setting up requirements for >>>>>> actual deployment up to the mandated authorities? This makes the >>>>>> O.* requirements informational. >>>>>> >>>>>> Thanks, Teco >>>>>> >>>>>> >>>>>> Op 22 feb. 2012, om 00:53 heeft >>>>>> het volgende geschreven: >>>>>> >>>>>>> Hello All, >>>>>>> >>>>>>> I have revised Section 6 of the I-D which describes the Data Model >>>>>>> Requirements, Protocol Requirements and Operational Requirements. >>>>>>> This >>>>>>> includes the requirements from the threat model >>>>>>> (http://www.ietf.org/mail-archive/web/paws/current/msg00771.html). >>>>>>> >>>>>>> The requirements are ordered "top down" to follow the previous >>>>>>> sections >>>>>>> of >>>>>>> the document: requirements derived from discovery are followed by >>>>>>> requirements derived from registration are followed by requirements >>>>>>> derived from hotspot, etc... >>>>>>> >>>>>>> Please review the proposed text, we hope to have your comments by >>>>>>> Feb >>>>>>> 28th. >>>>>>> >>>>>>> Kind Regards, >>>>>>> >>>>>>> Raj & Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> D. Data Model Requirements: >>>>>>> >>>>>>> >>>>>>> requirements related to discovery function >>>>>>> D.1: The Data Model MUST support specifying the location of the WSD= , >>>>>>> the >>>>>>> uncertainty in meters, the height & its uncertainty, and confidence >>>>>>> in >>>>>>> percentage for the location determination. The Data Model MUST >>>>>>> support >>>>>>> both North American Datum of 1983 and WGS84. >>>>>>> >>>>>>> >>>>>>> D.2: The Data Model MUST support specifying the URI address of a >>>>>>> white >>>>>>> space database. >>>>>>> >>>>>>> >>>>>>> D.3: The Data Model MUST support specifying the URI address of a >>>>>>> national >>>>>>> listing service. >>>>>>> >>>>>>> >>>>>>> D.4: The Data Model MUST support specifying regulatory domain and >>>>>>> its >>>>>>> corresponding data requirements. >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to registration function >>>>>>> D.5: The Data Model MUST support specifying an ID of the transmitte= r >>>>>>> device. This ID would contain the ID of the transmitter device that >>>>>>> has >>>>>>> been certified by a regulatory body for its regulatory domain. The >>>>>>> Data >>>>>>> Model MUST support a device class. >>>>>>> >>>>>>> >>>>>>> >>>>>>> D.6: The Data Model MUST support specifying a manufacturer=B9s seri= al >>>>>>> number >>>>>>> for a master device. >>>>>>> >>>>>>> >>>>>>> D.7: The Data Model MUST support specifying the antenna and >>>>>>> radiation >>>>>>> related parameters of the device, such as: >>>>>>> >>>>>>> - antenna height >>>>>>> >>>>>>> - antenna gain >>>>>>> >>>>>>> - maximum output power, EIRP (dBm) >>>>>>> >>>>>>> - antenna radiation pattern (directional dependence >>>>>>> of the strength of the radio signal from the antenna) >>>>>>> >>>>>>> - spectrum mask with lowest and highest possible frequency >>>>>>> >>>>>>> - spectrum mask in dBr from peak transmit power in EIRP, >>>>>>> with specific power limit at any frequency linearly >>>>>>> interpolated between adjacent points of the spectrum mask >>>>>>> measurement resolution bandwidth for EIRP measurements. >>>>>>> >>>>>>> >>>>>>> >>>>>>> D.8: The Data Model MUST support specifying owner and operator >>>>>>> contact >>>>>>> information for a transmitter. This includes the name of the >>>>>>> transmitter >>>>>>> owner, name of transmitter operator, postal address, email address >>>>>>> and >>>>>>> phone number of the transmitter operator. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to hotspot use case >>>>>>> D.9: The Data Model MUST support specifying a list of available >>>>>>> channels. >>>>>>> The Data Model MUST support specification of this information by >>>>>>> channel >>>>>>> numbers and by start and stop frequencies. The Data Model MUST >>>>>>> support a >>>>>>> channel availability schedule and maximum power level for each >>>>>>> channel >>>>>>> in >>>>>>> the list. >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to mobility use case >>>>>>> D.10: The Data Model MUST support specifying channel availability >>>>>>> information for a single location and an area (e.g. a polygon >>>>>>> defined >>>>>>> by >>>>>>> multiple location points or a geometric shape such as a circle). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> P. Protocol Requirements: >>>>>>> >>>>>>> >>>>>>> requirements related to discovery function >>>>>>> P.1: The protocol MUST provide a message sequence for the master >>>>>>> device >>>>>>> to >>>>>>> discover a white space database that provides service at its curren= t >>>>>>> location. >>>>>>> >>>>>>> >>>>>>> P.2: The protocol MUST support access of a database directly. The >>>>>>> protocol >>>>>>> MUST support access of a database using a listing approved by a >>>>>>> national >>>>>>> regulator. >>>>>>> >>>>>>> >>>>>>> P.3: The protocol MUST support determination of regulatory domain >>>>>>> governing its current location. >>>>>>> >>>>>>> >>>>>>> requirements related to threat model >>>>>>> >>>>>>> >>>>>>> P.4: The protocol MUST provide the ability for the database to >>>>>>> authenticate the master device. >>>>>>> >>>>>>> >>>>>>> P.5: The protocol MUST provide the ability for the master device to >>>>>>> verify >>>>>>> the authenticity of the database with which it is interacting. >>>>>>> >>>>>>> >>>>>>> P.6: The messages sent by the master device to the database MUST be >>>>>>> integrity protected. >>>>>>> >>>>>>> >>>>>>> P.7: The messages sent by the database to the master device MUST be >>>>>>> integrity protected. >>>>>>> >>>>>>> >>>>>>> P.8: The protocol MUST provide the capability for messages sent by >>>>>>> the >>>>>>> master device and database to be encrypted. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to registration function >>>>>>> P.9: The protocol MUST support the master device registering with >>>>>>> the >>>>>>> database. >>>>>>> >>>>>>> >>>>>>> P.10: The registration signaling MAY include the Device ID, >>>>>>> manufacturer=B9s >>>>>>> serial number, device location, device antenna characteristic >>>>>>> information, >>>>>>> name of individual or business that owns the device, name, address, >>>>>>> email >>>>>>> address and phone number of a contact person who is responsible for >>>>>>> device >>>>>>> operation. >>>>>>> >>>>>>> >>>>>>> P.11: The protocol MUST support a registration acknowledgement >>>>>>> including >>>>>>> appropriate result codes. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to hotspot use case >>>>>>> P.12: The protocol MUST support a channel query request from the >>>>>>> master >>>>>>> device to the database. The channel query request message MUST >>>>>>> include >>>>>>> parameters as required by local regulatory requirement. These >>>>>>> parameters >>>>>>> MAY include device location, device ID, manufacturer=B9s serial >>>>>>> number, >>>>>>> and >>>>>>> antenna characteristic information. >>>>>>> >>>>>>> >>>>>>> P.13: The protocol MUST support a channel query response from the >>>>>>> database >>>>>>> to the master device. The channel query response message MUST >>>>>>> include >>>>>>> parameters as required by local regulatory requirement. These >>>>>>> parameters >>>>>>> MAY include available channels, duration of time for their use, >>>>>>> associated >>>>>>> maximum power levels, any additional sensing requirements. >>>>>>> >>>>>>> >>>>>>> P.14: The protocol MUST support a channel query request from the >>>>>>> slave >>>>>>> device to the master device. The channel query request message MUST >>>>>>> include parameters as required by local regulatory requirement. >>>>>>> These >>>>>>> parameters MAY include device ID and slave device location. >>>>>>> >>>>>>> >>>>>>> P.15: The protocol MUST support a validation request from the maste= r >>>>>>> to >>>>>>> the database to validate a slave device. The validation request MUS= T >>>>>>> include the slave device ID. >>>>>>> >>>>>>> >>>>>>> P.16: The protocol MUST support a validation response from the >>>>>>> database >>>>>>> to >>>>>>> the master. The validation response MUST include a response code. >>>>>>> >>>>>>> >>>>>>> P.17: The protocol MUST support a channel query response from the >>>>>>> master >>>>>>> device to the slave device. The channel query response message MUST >>>>>>> include parameters as required by local regulatory requirement, >>>>>>> including >>>>>>> a response code and sufficient information to decode an enabling >>>>>>> signal. >>>>>>> >>>>>>> >>>>>>> P.18: The protocol MUST support an enabling signal sent from the >>>>>>> master >>>>>>> to >>>>>>> the slave. This signal MUST allow the slave device to validate that >>>>>>> a >>>>>>> previously received available channel list is still valid or not. >>>>>>> This >>>>>>> signal MUST be encoded to allow the slave device to determine the >>>>>>> identity >>>>>>> if the sending master device. >>>>>>> >>>>>>> >>>>>>> >>>>>>> P.19: The protocol between the master device and the database MUST >>>>>>> support >>>>>>> the capability to change channel availability lists on short notice= . >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to mobility use case >>>>>>> P.20: The protocol between the master device and the database MUST >>>>>>> support >>>>>>> a channel availability request which specifies a geographic locatio= n >>>>>>> as >>>>>>> an >>>>>>> area as well as a point. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> O. Operational Requirements: >>>>>>> >>>>>>> >>>>>>> requirements related to discovery function >>>>>>> >>>>>>> O.1: The database and the master device MUST be connected to the >>>>>>> Internet. >>>>>>> >>>>>>> >>>>>>> O.2: A master device MUST be able to determine its location >>>>>>> including >>>>>>> uncertainty and confidence level. A fixed master device MAY use a >>>>>>> location >>>>>>> programmed at installation or have the capability determine its >>>>>>> location >>>>>>> to the required accuracy. A mobile master device MUST have the >>>>>>> capability >>>>>>> to determine its location to the required accuracy. >>>>>>> >>>>>>> >>>>>>> O.3: The master device MUST identify a database for use. The master >>>>>>> device >>>>>>> MAY select a database for service by discovery at runtime or the >>>>>>> master >>>>>>> device MAY select a database for service by means of a >>>>>>> pre-programmed >>>>>>> URI >>>>>>> address. >>>>>>> >>>>>>> >>>>>>> O.4: The master device MUST implement at least one connection metho= d >>>>>>> to >>>>>>> access the database. The master device MAY contact a database >>>>>>> directly >>>>>>> for >>>>>>> service (e.g. as defined by FCC) or the master device MAY contact a >>>>>>> listing server first followed by contact to a database (e.g. As >>>>>>> defined >>>>>>> by >>>>>>> Ofcom). >>>>>>> >>>>>>> >>>>>>> O.5: The master device MUST obtain an indication the regulatory >>>>>>> domain >>>>>>> governing operation at its current location, i.e. the master device >>>>>>> MUST >>>>>>> know if it operates under regulations from FCC, Ofcom, etc=8A >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to registration function >>>>>>> O.6: The master device MAY register with the database according to >>>>>>> local >>>>>>> regulatory policy. Not all master devices will be required to >>>>>>> register. >>>>>>> Specific events will initiate registration, these events are >>>>>>> determined >>>>>>> by >>>>>>> regulator policy (e.g. at power up, after movement, etc=8A). >>>>>>> >>>>>>> >>>>>>> O.7: The master device MUST register with its most current and >>>>>>> up-to-date >>>>>>> information. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to hotspot use case >>>>>>> O.8: A master device MUST query the database for the available >>>>>>> channels >>>>>>> based on its current location before starting radio transmission in >>>>>>> white >>>>>>> space. Parameters provided to the database MAY include device >>>>>>> location, >>>>>>> accuracy of the location, antenna characteristic information, devic= e >>>>>>> identifier of any slave device requesting channel information. >>>>>>> >>>>>>> >>>>>>> O.9: The database MUST respond to an available channel list request >>>>>>> from >>>>>>> an authenticated and authorized device and MAY also provide time >>>>>>> constraints, maximum output power, start and stop frequencies for >>>>>>> each >>>>>>> channel in the list and any additional requirements for sensing. >>>>>>> >>>>>>> >>>>>>> O.10: After connecting to a master device=B9s radio network a slave >>>>>>> device >>>>>>> MUST query the master device for a list of available channels. The >>>>>>> slave >>>>>>> MUST include parameters required by local regulatory policy, e.g. >>>>>>> device >>>>>>> ID, device location. >>>>>>> >>>>>>> >>>>>>> O.11: According to local regulatory policy, the master device MAY >>>>>>> query >>>>>>> the database with parameters received from the slave device. >>>>>>> >>>>>>> >>>>>>> O.12: The database MUST respond to a query from the master device >>>>>>> containing parameters from a slave device. >>>>>>> >>>>>>> >>>>>>> O.13: After the master device has received a response from the >>>>>>> database, >>>>>>> the master device MUST respond to the slave device. If all >>>>>>> regulatory >>>>>>> requirements are met the response will contain an available channel >>>>>>> list. >>>>>>> If regulatory requirements are not met, the response MUST contain a= t >>>>>>> least >>>>>>> a response code. >>>>>>> >>>>>>> >>>>>>> O.14: If a master device has provided an available channel list to = a >>>>>>> slave >>>>>>> device the master device MAY send a periodic enabling signal to >>>>>>> allow >>>>>>> the >>>>>>> slave device to confirm it is still within reception range of the >>>>>>> master >>>>>>> device. >>>>>>> >>>>>>> >>>>>>> O.15: The enabling signal MUST be encoded so that the receiving >>>>>>> slave >>>>>>> can >>>>>>> determine the identity of the sending master. >>>>>>> >>>>>>> >>>>>>> O.16: Periodically, at an interval according to local regulations, >>>>>>> the >>>>>>> slave device MUST either receive and enabling signal or MUST >>>>>>> successfully >>>>>>> repeat the channel request process or MUST cease transmission on th= e >>>>>>> channel. >>>>>>> >>>>>>> >>>>>>> O.17: A master device MUST repeat the query the database for the >>>>>>> available >>>>>>> channels as often as required by the regulation (eg, FCC requires >>>>>>> once >>>>>>> per >>>>>>> day) to verify that the operating channels continue to remain >>>>>>> available. >>>>>>> >>>>>>> >>>>>>> O.18: A master device which changes its location more than a >>>>>>> threshold >>>>>>> distance specified by local regulatory policy during its operation, >>>>>>> MUST >>>>>>> query the database for available operating channels each time it >>>>>>> moves >>>>>>> more than the threshold distance (e.g., FCC specifies 100m) from th= e >>>>>>> location it previously made the query. >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to wran use case >>>>>>> O.19: If slave devices change their location during operation by >>>>>>> more >>>>>>> than >>>>>>> a limit specified by the local regulator, the slave device MUST >>>>>>> query >>>>>>> the >>>>>>> master device for available operating channels. >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to rapid deployed network use >>>>>>> case>>>>>> Note> >>>>>>> O.20: According to local regulator policy, a master device may >>>>>>> contact a >>>>>>> database via proxy service of another master device. >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to mobility use case >>>>>>> O.21: A master device MUST be able to query the whitespace database >>>>>>> for >>>>>>> channel availability information for a specific expected coverage >>>>>>> area >>>>>>> around its current location. >>>>>>> >>>>>>> >>>>>>> >>>>>>> requirements related to threat model >>>>>>> O.22: A Master device MAY not include its identity in >>>>>>> messages sent to the database when not required by the regulatory >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 d.joslyn@spectrumbridge.com Mon Feb 27 13:39:36 2012 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 B331921F8487 for ; Mon, 27 Feb 2012 13:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjInBmOgku7b for ; Mon, 27 Feb 2012 13:39:36 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 79FC521F8478 for ; Mon, 27 Feb 2012 13:39:35 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 27 Feb 2012 16:40:16 -0500 From: Don Joslyn To: "scott.probasco@nokia.com" , "paws@ietf.org" Date: Mon, 27 Feb 2012 16:40:19 -0500 Thread-Topic: UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZRTfyw Message-ID: <8375F6DAEFB09F48815203F1FE23B797113C9BA079@shelby> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_8375F6DAEFB09F48815203F1FE23B797113C9BA079shelby_" MIME-Version: 1.0 Subject: Re: [paws] UC&R I-D: Requirements 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: Mon, 27 Feb 2012 21:39:37 -0000 --_002_8375F6DAEFB09F48815203F1FE23B797113C9BA079shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Spectrum Bridge offers the following feedback to the latest PAWS Requiremen= ts posted by Scott Probasco on 2/21/12, UC&R I-D Requirements - Section 6 r= evisions of the I-D which describes the Data Model, Protocol and Operationa= l Requirements: We reviewed the latest PAWS requirements, comparing them to the published F= CC requirements that established the requirements used by Spectrum Bridge t= o implement its certified TVWS database. We believe that the currently writ= ten PAWS Data Model, Protocol and Operational requirements align well with = our current FCC certified implementation (see attached spreadsheet), and th= us we support the PAWS requirements as written in the 2/21/22 from Scott Pr= obasco, with a single exception, O.22. We do not agree with O.22 because we= believe that a device should ALWAYS include its unique identity in message= s sent to the database. Regards, Don Joslyn Spectrum Bridge, Inc. --_002_8375F6DAEFB09F48815203F1FE23B797113C9BA079shelby_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="SBI PAWS Feedback.xlsx" Content-Description: SBI PAWS Feedback.xlsx Content-Disposition: attachment; filename="SBI PAWS Feedback.xlsx"; size=17091; creation-date="Fri, 24 Feb 2012 09:10:50 GMT"; modification-date="Mon, 27 Feb 2012 13:25:49 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDUxMNBlAEAAOQFAAATANwBW0NvbnRlbnRfVHlwZXNdLnhtbCCi2AEooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAArJTLTsMwEEX3SPxD5C1KXFgghJqy4LGESoUPMPaksZrYlmco7d8zSUgFKI2E 0k2iPHzv3PEZz+92dZVsIaL1LheX2Uwk4LQ31q1z8fb6lN6IBEk5oyrvIBd7QHG3OD+bv+4DYMKr HeaiJAq3UqIuoVaY+QCOvxQ+1or4Ma5lUHqj1iCvZrNrqb0jcJRSoyEW8wco1EdFyeOOX3eVvFsn kvvuv8YqFyqEympFXKjcOvPHJPVFYTUYrz9qls4wRFAGSwCqqyxEy45xBUQcDIVczF84dLQGkqWK 9KxqdpC7ShIngO56mXGGSUW0YheNynFDpH0FONnqd95OtHceaG+ECv8X7XsDM17Z7gGWNuCIw3jv xnvy6ePm3fvNqbvS0JDVyrq+7iEIGKFl9AElAze5AGiINmDSwJIQycKhZ0PeDGCTvcUWZXubTuFv NA76fQ8G6NhO5J7XP0T1yaM2Ar72dTOpeOqAvW6f70ifsVQRzIr4ZFiffPx+ao/VcWBN+wj/h62f yWb1AGGyPaMXXwAAAP//AwBQSwMEFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAzgFfcmVscy8ucmVs cyCiygEooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAIySz07DMAzG70i8Q+T76m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b 3u7maVQfHGIvTsO6KEGxM2J712p4rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwj YjQdTxQL8exypZEwUcphaNGTGahl3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxA nhM7y3blQ2YLqc/bqJpCy0mDFfOc0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip +L3OPOKnhOFNZPhhwcUPVF8AAAD//wMAUEsDBBQABgAIAAAAIQCBPpSX9AAAALoCAAAaAAgBeGwv X3JlbHMvd29ya2Jvb2sueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACsks9KxDAQxu+C7xDmbtOuIiKb7kWEvWp9gJBMm7JtEjLjn769oaLbhWW99BL4Zsj3/TKZ7e5r HMQHJuqDV1AVJQj0JtjedwremuebBxDE2ls9BI8KJiTY1ddX2xccNOdL5PpIIrt4UuCY46OUZByO mooQ0edOG9KoOcvUyajNQXcoN2V5L9PSA+oTT7G3CtLe3oJoppiT//cObdsbfArmfUTPZyIk8TTk B4hGpw5ZwY8uMiPI8/GbNeM5jwWP6bOU81ldYqjWZPgM6UAOkY8cfyWSc+cizN2aMOR0QvvKKa/b 8luW5d/JyJONq78BAAD//wMAUEsDBBQABgAIAAAAIQAdRSVzTQEAABoCAAAPAAAAeGwvd29ya2Jv b2sueG1sjFFdT8IwFH038T80fZdtFRQJGwlRIi/GRITnst6xhq5d2s7Bv/e2ZKhvPt2e+3F6z7nz xalR5Ausk0bnNBullIAujZD6kNPPzepuSonzXAuujIacnsHRRXF7M++NPe6NORIk0C6ntfftLElc WUPD3ci0oLFSGdtwj9AeEtda4MLVAL5RCUvTh6ThUtMLw8z+h8NUlSzh2ZRdA9pfSCwo7nF9V8vW 0WJeSQXbiyLC2/aNN7j3SVGiuPMvQnoQOR0jND38SdiuXXZSheokfaBJcRX5bomAinfKb1DewI5+ sTFjsTNYsZXQu5+hAMlpJ7UwfU7ZGK09D+gJQR8rOyl8HZgyds29gjzUPqfT7D4NayS/2KN/+EuM REdxH8s1WQGIPS+PeK7g8BpV4OnsTOLDrkUWeYbhkqsSNYUQGjM2eWST2DGctfgGAAD//wMAUEsD BBQABgAIAAAAIQA1dM6luBQAADdFAAAUAAAAeGwvc2hhcmVkU3RyaW5ncy54bWzcXNuOHMeRfReg f0j0w64IDHtISbYlLTnCkGPaA1iagWdkQo/VVdndteyuKtdlhuOn/Y39lH3dT/GX+JyIzKxLVveQ tCwslhAkdl0yIyLjcuJSevH9+/3O3Nm6ycvi5eL58tnC2CIts7zYvFz8dPvm6TcL07RJkSW7srAv Fw+2WXx/9vlnL5qmNXi3aF4utm1bfXd62qRbu0+aZVnZAnfWZb1PWvysN6dNVdska7bWtvvd6ZfP nv32dJ/kxcKkZVe02PfbrxemK/K/dva1u/LVt4uzF01+9qI9u1g+f3Hanr045U9/6cv40lfxpa/j S7+JL/02vvS7+NI38aVvp5euY1KvlxGp18uI1OtlROr1MiL1ehmRer2MSL1eRqReL+dIfTZDfiRq sDTDwPOIg6uY9auY9auY9auY9auY9auY9auY9auY9auYdZAasY5rMet12ZZpuZuK6SJpk+m1q8rW SQsrSqLHb2za1Xn7MH3lJpbY7daavW2aZAMDNHnR2nqdpNasbHtvbWFa3L/f5q01TcXrmb3L8R/Y p9zKQNgqaawprM0a05Z40TTc3mZL86pst/IYzKzObRNeq21TlUWDK3zPvZbZXQ7HgN+6wO5haUie 23LfwQFg9dTWLUzZ5K3JsWOye0fKsXNiVhCGWecZ3vF0JV27LSELSOrOGrgIoWdXpiI6IaipbNrW 3d6sAlfKJPwKJAwiy8JR4lfdJw+BcvDS1nkKaii8JOWRiCSUbvx1m+Bma7ZJY5pyb01V56Cjtjuh odnmlbnP2+2JwVWuDCb9ohDGui73eKW8y+kjIZtaTgAMjzZIahxC2RrH8N/wJoQk++2TorD1MtaG yMzOSW2Q+H2+2xke3YPQBx7+/l//3RgvvJOxKP35gNQWAsX+yQbnhEOzyZ1tsrqsKjCwNDeUQW03 neMfdKa7DocGcTdU592DwRkWbb7Ok9XO4r66dgjWQIa1/WuXU03szu7xGM5nzfVynEM41VPIUknn oQptTb7Pd0mN1SHgQOWMWCJPcw45pOV+j4ChetNgid4+DtmEyM9RCyZau6FR+q3BTbT3z7aZntJ1 Urd5bOI/ltMH/5In5o+3t9c3pzc3fzKvYSWQH8iNl7ywTVrnFRV1ugjtjc7G/FDCHM0PP93cmqar qrJu4QBsmq8fxNrw2E9/vjRJlkFT5QCSsZtwlhJx+M9sUMjpJjuzw1EPbOFTN/FKWELBs5L4QPxB Do1Ky1p9lNgcvYlXO9G4T90xgX0XHRxsCwdZ/+//wCHAMYKjotuvbC3+ic808CTOvD91q/IeNi/8 qBuDPaRl0WLrkT3RIyYGhlM0+7zFtvR08KvOJtUfFAksFkZG3zB41MgeJybc7lcxftMTU5WAczuv KicGkC0PP4XAaguk50Uwt4344TL2YMBpUVj9QAVLt3SKoOMO1CSrfEfLHDoaFUwDNYMH8i5PyE2g JkCX5gu7hDdLwODuYQPXlNl1XsAtrR7gb3ZtXg1frEo4ABgKpb2x8ICMGabZJhXiZZdu6dgSk+Z1 urNPZs+cHovYQI1SAwICsYvejLrwdwVisw9yIzVigMzyJi0RYfHSKKT7qCaByi0smqmhnsELFtHB Ioo2iOIDaPSOI7PQq32u5uucNZ3/wO42pKugTX/iXl4eVFF/nAcFgb3gyESdGS4ZalKev9O9AB4Y lSkqHI+ijRDiEcfmXKciKSCGhqKCIpCc6Bx4MewhLhYBKYoPAFDTLe68i5/euOU2guIme4dtcPwx LR+zN7eYV0GumybVUOqztIzlwLA8pA4igPbWDxWQQ8R4vLnXrZgpRQI4YSiTHCAf8TvNrjzCDk2+ AQThyz+c/+zdoMjuQlHh5cXJcS9+4hGr9xrhQgIMUACiwvkQKIJGxLF06HZ6Z5oXWQ7I18F1wmms OngiRlqxUfjdIVDTl04+xsWCBhcMFHRBy0vCaQ16TU7YRfNx0Ea9+RxiOXwyjJhDTJa+K8r7nc02 AtqcZCnnpIJeARMDqnB/uE4Ql9lm9qzGKui1QEQq/lwxH0EXYLli51hFnDEEpZA0w0eE8QpOk9Xp BqCK44MHB1wd4VHYO498R8a9f3Pwj6iBkdUiVar6t4cq5kQdKc0H6Btt6XHd+qfkqflaL1AvO8aV SMDCKbV8dCRuiV9Poi62Q5UdKQ0ssXM5An19DljjgkRem66xsKGmKVOqIpKG5H2+R1pYlfeImTt7 Z3dYICkeaGi5Zt509MQIOHJJSubRISoaUbHlmOFMJTdR5maHhMqb5ofLX1f59cTvFPryQlDTiGiv 5JFKQlJRDeqYpO7gqqGKzAwP2fzE2Kmw7i2ipyFZqrYzS0qc9MZPbR++ZS4v5tiI6mYfzMaHmdoM se7FEbX0wu46neocpVE57xilU9WcEjsO8k72Q3H9Wr7hZBhhxkJQfezWSI9z4rQh7AfFmaWk8BAA CeoPtG4FBXPCiwqfR4QXLagwUQo81Conu6HQKC2EZd1fgxDqI+W9+NyhWEdqLSABiUkNxFJ2DSoe tU0tCmAIE5rv9D5RkmmGfkARlDlE+4k4ilIC1mRzRWkQjxTtDpPiIT/yRTCm1RwmWJpDwmlKXj1S ljnpRjXkkXSHNZjRUnLA3DhEKbEJjxZ4ZwBYIW9q9SaECS8kTQpZbGAJEMkaqyCQCwqgM8R+OZuK BrzyqcT20GaUqnpvp9mJlmakwsrsclMnFbKWkKtJcumyVuSZ9xYHLfmmZKURLxRykJyviY4F7DMH oMhCi31Oay9ZBC1sO7vozBqu0IeY2m/JkIxgrJ5i8g4weYO6H6oYkxd8XRQgzOe5WLQ1dYfsjuUL rfx+wnJ7i+IIc0OxqKc4Uch3v4cJDEpgH8zvHmUBogTStrOo9EC1oHkqR8YxAMttqeaVpgr5++M4 JBOP5gdCyVAjTVvYPsXppeNqFg2cXChWvHn9+slh8fQrD6tuAETrvCbCLumOIAvI3T8KVRjQoVue j7a8WqOcOl/mmBwQC5DlSgr+cMhMilzlnkY8wNmuftfXEULKQkHPFRUQIJbQMa4zsyeTFbor5P26 EhLrrsjAt9sUR9UoHIb8ToxwhOJWm87m5sOKnrpxTY6wnuSoJHCPQlkos9DsuuppWz6FJY5K4JGm nc/Rr1kMmQuW7JCu9259CEA1Gy2cjD5uTlCodeNVgJ6WpWhi3STLgfq12tewkYuDGZaUlgZVa58h wV6Qx2rAGNFzNPlJUhSckjTUZDxiJAB/PIl20NN3ESBlmi+Q+yhkOh9KljysGUCBSM63Q2GKA3Ql YsZeFgXnQ6v31BLm+ZivOEmSIamb9qjYsnGE8yrFk+yaklUXClDTFdgY2xwsJrIMoRlK2bVV12qi cqLnJCGwacsKOqqFQUYHqoBNUM7q+RUDoGnLG5Pshq/CjUhW4/yIpDuRbM7XcPvBi0Gg4gNGdsVq t2oOwsN9Wb+Dkxgdh4i019vRy7J5oliFRzkVdaOOUdeThTxcH2TbjhvxVVGijipunj7AglnUDalL KN14/Ys4Rxs3aqPhWtRDwrUos8G1KE3AtQiQ41qEM3EtyinPU/QtBFlB/Ac5nPF4ULVe8MFhiGca yc+ByIBYh+cXSea4vbgNw1Lj45ZQkktBeECAmtBIa6JdVRNjHtl97VEw/jrNXDzb2tYckzO1di4/ 4t1cQimBqgYRaWQ77M4isIuxha2lP+g4PexAllz72LpApFxb6Q6LC8lhcY81HksHycYknFBwwYcf dnNi8EOZzEVWQW8sVrHXm2PoJ53mWOI4DmY44AewY++q8ZqxUEsRfni20tKEkyGWZ31nGtojZaGK TpI8jc6DPAceWPIprqYKJBmh1GBSyONAquP2H6c6EQHXTgzQHfgeIBUsKE0G5GEGMfCAORN86HmP JC5nbiEPgSlirOLVpywiCsijaDwRYa47ttxrW1kQQDZ9dJDIgciA4xck6t9LgVtDJ1ABADDA4M2I z1mMMthxxvscgSvQyBIBB7F0MA3gui09PEODbnNigM7AmoQxZnHoj0H1AIoenkjKDPlLJ8hx7lBj jwjYCkYCUXTgt8RC2iX24edRPjU90/QSTVWgPB9IAPfgE6BZ4AL/gd1uyx0AACJxQip9SncsWrGa SWXkugHvnujZHpBoHzlnWBVoINkSYO8eLTmCUk8lj3eGToH3KmZPcmOeP3u2f9IXiwPPWLbqixL7 hKgGywqtkSwR4aL8HwNeUZqNa9EgFfzY0DJwiprhYzdUegM9Tn5BdtK7DRwTb6ApPj4K0jsJrYcs sT+CcTShZh87h0gSx+I6288CXKZ+m5NE4v9TeJU+C2APEfb8HljYTRIJNMakFsxiROeUDE5ffidT YC8XOEW+bhdnZta04T9ldAc200tBms5ujMz3nCkL726cTA724mX+hCHjPSe2gJalm53A2Us/Pqkx yZnNpjBTVs6gMxPUVmPwc57Dc/PDKH3TBA/P859r/Kv5G8tmGCp9vjg9e4EWPXiqN6uXizf48wx/ eLl+Az+iz71G0XpV57y6TjCT9KCXv+QFmWm1egEt87LmxVPZpj1jSsBo77Et7V5zHD/r9whVOOQ9 ZmqFzl+AoHl5MRkcN4ChBTQbj7CQKsJ3k5EhIucTPcwJQh7M4L7BrOAqSd/pPT+bC5YPHNwtVrzg 6M7xYSZ4YPQoXLz2aS1HYVwasDRahMVD92UHH+1RFSnu3xwOxrj8QXAD8dOKo5SpjmRBbxGqpDvq m4SrMtMyDQ+0l4EbSlqaIIx5jfsFTvLsmKzgPbT1ne7QHnO2BFIGR/MWoEEHRKDNqN0x7LrGzw1C LMCMm3CCKrisnDLQCewg50t2tVlx7mvzMKWsRBxS7QjZqPMBMt9I+LfBMCB29ZM0sLCduUEn//ux rrRnI0LzUIwrC9A9GfYZv3pczeBRB8M5vtAMAMcCHh1sr/y+LqcZ60e8+CtoAacM0JAPA3bSmmfb QDQ2zN8FFZ3VhT+ictZseQJymAgFGUqc35uR6DGpjzIET1V169+bWGV+lKE41Onc2MOmRF3UFmW3 2R4/VyqgjEJqcU0iVf20YRHFGaHMRTrqvSM5rhxSKsekBUdsMf01Vg55NSvlLk5UyjVSLjsdlWBQ moY7mnl1hdFn9JchD6YA4zDMvgO9zvmf3p7/fDPr+x/1uBGnYVh0SsyNhc9c/s6s/zW+lgce0Jdz uW9vMFGjdNC/zQbVX8LFce8O0FrGx2Xaj2kzhjgEvz1CwL8uqh8Ioo/Q80sIBFh4s20f2ej/I+P/ luyr/xCgONAHVpYltq8ZoJCBAcYgVUzRqyHE9Olo0F6f98v0gTrzQ2Bjxe8gfkT3cGvO9wiHLBvg WcyWwASef/vNV7L12z/cfPP1rEe9heYeWnswlf14ffT4Ir61InYJpzsohkt7x83zaCTXjzkQF8TP CQMjX4dy83GhHGhsEgBnHZoTPA1f4B6M4BytYUd+jpIbh1jvnukNhiOL/J35rAQoZVimlzh1NDc6 eywL8toCtRoWARTJM+gONHGqiDJ6tESitc7fIxaPCJE2AeMdDt9/1AIWfYcS4YSfYCAY65AM4NSW w0PkdtACP0Cdw+0BpQPPSFOGtOxLDE3Pts7mNsBKH7uH+qU+OPMoY9YBRVAxAVaPRj2PlM84eKxp 8xJmiYgLrDJaGj1yDkMAugTewYHfC5+whFT0Du7BPY1yNb7UQLNOn9M5M4ktOB5Edz7IOnAQhMCq gKUcRX6s3LVz0ASEY5LuCgsy7MRIl3GueQqT1V71SJfl2xctC0tXWZH5YMppvvpCcR93F+FLEN+R o8Wyw+PnsaBzUNdB/d4FfEV8aFTp3Pt3n39mxn+ewgK0yach6sgD/MRo5rZ3HOPO2O8v/3xtvshe 7Z/MvOK37DmoEmaBBd6QVjqKrshjMpRJ0QdmgHDsoB9niw18u/utTS43shP6G275mY3pweX7M6jg O9VjttRdR26LGM2/4zMKN5ZLlcT+D48uhQCWvUKjXj4gs8m7kNtiMY404j4lcuJQstdp52yl9EU4 irap7yFiwBVjyPINlVSpYURyxn64Jcn+Ex8Jos7hP3dw8z5DDqd2fdWhAuQ+LggJmaqQZH7FoODh 6lnjJEXhvRgarIsWVnCk4gHtFjflEIWFm1eXUhh+DTA4pQdpijT6WYeFwRCRqxPgrrQsHzXgERDx sN1i6Lul+EFUuTgZ3cBPrrcAC7MAY6F5rnCLtJSfDlD48EJqLo0r2UP5cGscnYV376pkuIT+FuSV wY+FDv+kdsm6f8iq4chQBdTo4FJ+bBQKxUuRGUoAHco7Sp97CtMcFTIYOkLYQQhEPl4I55Jiu80G ZXAKRa08OiWW7sdvuQeZSn7sGR00b38wIzNcjMBPr4f/V0/m889eIbm06wTT875n7TUGttSgx4Fq oowzK2DM4ZlD6JkogXyZivtQIi817wp5WiNBSXdS4o2WiIKoepw1o6vaLHL0+gR3BdMS3ZK4OIph aokDgOZyYr8Jq2m0GYJ0by5iP41jnqt5AcyzLYyESpd8q9tJk1Lq04PPNRrzBdwdIQd2QKXTidVp dvZEjNEzKF9QsWzrKZ2aLoU8YhW/nasPU5vAdm5HxyUd+vClWcsJJ+EoU6A+V5BQu46e9zFU4wG7 Zr5QT5zM+VoAryQTfpEGSPiAmo2m5uG//HSYcxXtA754++KNINnbv7xC6s/qrLk01+7rX3ONRInN A39n9hYGrZYGYRyeAKKFxNRr6TgaPDVAxe2HIZhjWZP6bPhhShtfjSH+ycgeJlewB+CvNMvg0t1M TsgSvaR0sEbbhdLXWJq3LH6LWzu4CsAZ+o2wG6c1kUGow+9dtJxF3UlTBArEpjOUprD34ciEEG3F hFBApsIOU06EhqlizdcqfpxU8uG3YU1g8nBkv7fIQ+pMBq0vXnGQEtniNBKj7SXzjxwn9MOHwFg+ SwOarkg+PBXSULAroAEQLRg4RciACjNlLBlEuuXnn91oWc3XKFd1+Q4HA1gDg7ynDAlcBc338TEq O5L1mdUZoLRXAAJXUGaMPodas+zoKq2Dbj+wlMya6/xnL4tT/I9Pzv4hAAAAAP//AwBQSwMEFAAG AAgAAAAhANU4Oz3wAAAAXQIAACMAAAB4bC93b3Jrc2hlZXRzL19yZWxzL3NoZWV0MS54bWwucmVs c6ySwUoDMRCG74LvEOZusqkgIs32UoRetT5AzM7uhm4mIYnVvr1TBHVLxUtvmfnJNx/DLFcfYRJ7 zMVHMqBlAwLJxc7TYOBl+3hzD6JUS52dIqGBAxZYtddXyyecbOVPZfSpCKZQMTDWmh6UKm7EYIuM CYmTPuZgK5d5UMm6nR1QLZrmTuXfDGhnTLHpDORNdwtie0g8+X927HvvcB3dW0CqZ0YoF8MxKsy0 ecBqQMrvppbsCuq8xuKSGvswrbN95x3PRLqvXlE/uZb8/stJX9IpZU8V8zPWyl7zDZ1k6qTW8tXT UVLNjqL9BAAA//8DAFBLAwQUAAYACAAAACEA6aYluIIGAABTGwAAEwAAAHhsL3RoZW1lL3RoZW1l MS54bWzsWU9v2zYUvw/YdyB0b20nthsHdYrYsZutTRvEboceaZmWWFOiQNJJfRva44ABw7phlwG7 7TBsK9ACu3SfJluHrQP6FfZISrIYy0vSBhvW1YdEIn98/9/jI3X12oOIoUMiJOVx26tdrnqIxD4f 0zhoe3eG/UsbHpIKx2PMeEza3pxI79rW++9dxZsqJBFBsD6Wm7jthUolm5WK9GEYy8s8ITHMTbiI sIJXEVTGAh8B3YhV1qrVZiXCNPZQjCMge3syoT5BQ03S28qI9xi8xkrqAZ+JgSZNnBUGO57WNELO ZZcJdIhZ2wM+Y340JA+UhxiWCibaXtX8vMrW1QreTBcxtWJtYV3f/NJ16YLxdM3wFMEoZ1rr11tX dnL6BsDUMq7X63V7tZyeAWDfB02tLEWa9f5GrZPRLIDs4zLtbrVRrbv4Av31JZlbnU6n0UplsUQN yD7Wl/Ab1WZ9e83BG5DFN5bw9c52t9t08AZk8c0lfP9Kq1l38QYUMhpPl9Daof1+Sj2HTDjbLYVv AHyjmsIXKIiGPLo0iwmP1apYi/B9LvoA0ECGFY2Rmidkgn2I4i6ORoJizQBvElyYsUO+XBrSvJD0 BU1U2/swwZARC3qvnn//6vlT9Or5k+OHz44f/nT86NHxwx8tLWfhLo6D4sKX337259cfoz+efvPy 8RfleFnE//rDJ7/8/Hk5EDJoIdGLL5/89uzJi68+/f27xyXwbYFHRfiQRkSiW+QIHfAIdDOGcSUn I3G+FcMQU2cFDoF2CemeCh3grTlmZbgOcY13V0DxKANen913ZB2EYqZoCecbYeQA9zhnHS5KDXBD 8ypYeDiLg3LmYlbEHWB8WMa7i2PHtb1ZAlUzC0rH9t2QOGLuMxwrHJCYKKTn+JSQEu3uUerYdY/6 gks+UegeRR1MS00ypCMnkBaLdmkEfpmX6Qyudmyzdxd1OCvTeoccukhICMxKhB8S5pjxOp4pHJWR HOKIFQ1+E6uwTMjBXPhFXE8q8HRAGEe9MZGybM1tAfoWnH4DQ70qdfsem0cuUig6LaN5E3NeRO7w aTfEUVKGHdA4LGI/kFMIUYz2uSqD73E3Q/Q7+AHHK919lxLH3acXgjs0cERaBIiemQntSyjUTv2N aPx3xZhRqMY2Bt4V47a3DVtTWUrsnijBq3D/wcK7g2fxPoFYX9543tXdd3XXe+vr7qpcPmu1XRRY qL26ebB9semSo5VN8oQyNlBzRm5K0ydL2CzGfRjU68wBkeSHpiSEx7S4O7hAYLMGCa4+oiochDiB HrvmaSKBTEkHEiVcwtnODJfS1njo05U9GTb0mcHWA4nVHh/b4XU9nB0NcjJmywnM+TNjtK4JnJXZ +pWUKKj9OsxqWqgzc6sZ0Uypc7jlKoMPl1WDwdya0IUg6F3Ayk04omvWcDbBjIy13e0GnLnFeOEi XSRDPCapj7Teyz6qGSdlsWIuAyB2Snykz3mnWK3AraXJvgG3szipyK6+gl3mvTfxUhbBCy/pvD2R jiwuJieL0VHbazXWGh7ycdL2JnCshccoAa9L3fhhFsDdkK+EDftTk9lk+cKbrUwxNwlqcFNh7b6k sFMHEiHVDpahDQ0zlYYAizUnK/9aA8x6UQrYSH8NKdY3IBj+NSnAjq5ryWRCfFV0dmFE286+pqWU zxQRg3B8hEZsJg4wuF+HKugzphJuJ0xF0C9wlaatbabc4pwmXfECy+DsOGZJiNNyq1M0y2QLN3mc y2DeCuKBbqWyG+XOr4pJ+QtSpRjG/zNV9H4C1wXrY+0BH25yBUY6X9seFyrkUIWSkPp9AY2DqR0Q LXAdC9MQVHCfbP4Lcqj/25yzNExaw6lPHdAACQr7kQoFIftQlkz0nUKslu5dliRLCZmIKogrEyv2 iBwSNtQ1sKn3dg+FEOqmmqRlwOBOxp/7nmbQKNBNTjHfnBqS7702B/7pzscmMyjl1mHT0GT2z0Us 2VXterM823uLiuiJRZtVz7ICmBW2glaa9q8pwjm3WluxljRea2TCgReXNYbBvCFK4NIH6T+w/1Hh M/txQm+oQ34AtRXBtwZNDMIGovqSbTyQLpB2cASNkx20waRJWdOmrZO2WrZZX3Cnm/M9YWwt2Vn8 fU5j582Zy87JxYs0dmphx9Z2bKWpwbMnUxSGJtlBxjjGfNUqfnjio/vg6B244p8xJU0wwWclgaH1 HJg8gOS3HM3Srb8AAAD//wMAUEsDBBQABgAIAAAAIQD+nV9Q4wIAAOkOAAANAAAAeGwvc3R5bGVz LnhtbMRXTY/TMBC9I/EfLN/ZtEVbCkqyAqRKSICQtkhcncZJLfkjcpyS8usZ20nabkrZlLT00Dqu /WbmzfNkHD7UgqMt1SVTMsLTuwlGVK5VymQe4e+r5asFRqUhMiVcSRrhHS3xQ/zyRViaHaePG0oN AghZRnhjTPEuCMr1hgpS3qmCSvgnU1oQA486D8pCU5KWdpPgwWwymQeCMInjMFPSlGitKmki/KaZ iMPyF9oSDn5NcRCHa8WVRgbgwRE3I4mgfsVHwlmimV2WEcH4zk/P7ITzqFknmFTaTgbWpDd82o7O kwgv4TOBj90xlrHEunTjwBY2AM8fkymtaRrhxRMKV2SjBLELewwekXXo/5i4x5xchW0nh2vIyBFU AnOM807HM6tjmIjDghhDtVzCA2rGq10BKpZwqCzjgV/3l9W5Jrvp7P5gg9sHdhOlUzjE7Ql6DZb9 VBxymhmwoFm+sb9GFfCdKGOUgEHKSK4k4TAM2h3tb38nlAI49RFOVZVwCkY8l6QyqjmRAeDfCP4Z zvgwT0fZhAvkrSnnjzawH1nH4BSCqzMkK7EU5hOcFiiMtmK0Q8hkM/Rs+QfL4iGaxz6AnVlNDMdF ddYZ+IfdiBQF373nLJeC2kpro4TC6R/RT02KFa3dvI2kzob7OsWdr97aB6fMRh1DfT+DNmIsM0jt qXz2rC9BADaSESIDm21Or4t2A556sVzAE5B6Mgdw7I55arFBoEPV1MeCrI+Uzx72XvcjZsAWoVNK PWN9FJ7G033P0zafT0/BiKzdP5e1Y1+Ww9VxoaW9Vs5kazD2BVhjVLzBfv7/TP/xjQgXI8PW9gYC bQ0e9IKcDxXdmXQNxrqAUte3QKdy0A4dNUNdW4NsZx7hr/Zexw+qc1Ixbpjs+pR9IwSYab1vrdxl yhBoIF3T1VmB0pDSjFTcrLo/I7wff6Epq8TbbtU3tlXGQUR4P/5s+9zp3PXIrlt1d9T4NwAAAP// AwBQSwMEFAAGAAgAAAAhALMD9olBCQAARioAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0MS54bWyk Wttu4zgSfV9g/sHQ+8amLo4TxBm0LAxmHhZYzG2f1baSGG1bhq3uTP/9VpFFsapIazPYl3ZHPCye up2SbD39+NfxMPvWXa77/rTOzN0im3Wnbb/bn17X2R+///TPVTa7Du1p1x76U7fOvnfX7MfnH/7x 9N5fvlzfum6YgYXTdZ29DcP5cT6/bt+6Y3u968/dCVZe+suxHeDPy+v8er507c5uOh7m+WKxnB/b /SlzFh4vH7HRv7zst13Tb78eu9PgjFy6QzsA/+vb/nzNnp92e1hDh2aX7mWdfTKPzbLI5s9P9ug/ 9937lf1/NrSff+sO3XbodhCBbIaefe77Lwj8BS4tcOs82vuT9ezfl9mue2m/HoZf+/efu/3r2wBG Ktyy7Q9wDvw7O+4xttns2P7lTtjvhrd1tror8+p+ZfIqm22/Xof++B+3YGi725jTRvh8p/XiLl9V plr+j50F7YTPcSdYuQ7fD5BKIDRxakl74dPvXcCOqb1z57GNVNMO7fPTpX+fQVpx37nFIjGPYA8+ c6gzd7gLo8XY0C3vIBrD2377pe4xlJDPLdqo0QhshA+4jGn+9myK/Gn+DZKzJdAmASrvJaZJYIwJ huZAemSO0ZLMx1zdJv57f7b+JLz4hAbX2T1zoiglv42DLG0NoOcNuyDIQVoVOQPQZFiXi7t7H1ei RyH7hFaALq76uC4ko5ogPPSlZk0YyOtoxuQK1BCIY4piPEw4h3UiI59yzjvhqko4YUa7rn4IIpwI Z1vMhjDciXIl7TSEsYIiGEME/wZjRKuwhxp0jB3kgUWrrCSZDVkRhB8kpiFMTHj5twgjWhFW4asd RBBWkA1Z4YQrVW4NYWLC0DY8wqgXxcILxCdcBYKwe6xAVX8177tSU6P9bLsxCtOkMOEQUQ44OD9e wIhW0VW5rgkyWcCEEeFVjdAQJg4vJI4ztnIMQu17DJdVfJey1GqR+hAX11y0n2NMoXNPIJ4EJpAi wAa81HxZOdhlxVeNghoxoVhUsjfeAsNUoUclFxwqLNs6dgbXFRklLDViAhkdPW8BsjeC4M5BJqDx KA4qAkhyxrmiOPP4ubEj+qlSIapRk0c60UzAVfSaYSrlV5PAGHOLMc4PxdhUYbLRHQPce/kbDxRr tgHIAKXkhDThxmNqfhsn//Dv6DabYK7QCWMbzF5p+BWZAxTnjxEsbo9wnHvOtZGUGgJ1AhINE8JA kEczVcgEeeKO4hhTBBmQzqGQS+ewPpPh54VH+s9jbJRO1FiW4DIXk7j8yBBvcmMCWfIohSqCUkiX cAAEl7w0GpoLYGoMnVG6W3sQ9ysaQh7EDFWBseSCQp7gQvouuATZsk7XhkCCi2rNjQdJyQlsKH5k ijE25lb4UN4TlEn1BeVIaggkKCvQxhCIkakCFyIcY4wJYixijM8pCcL2spJzo8JXe9AkYQ/ihAMX RziFCf0t+eKciQOMT00oxCLAqrVrD5rmS5YY36XqzcYbYpjqFl+cEAm+NDgEX1V4dU6gab4EYlyW qjEbb4hhbvKVE8j3f46XdXxV3dUeNM2XLDEuy9C8MtdgiMVuhvccZTXeruW4rDmp0qo9aJoTWeKc QuNJTnKejfFxU0PWXygJp0n4ZQYSnuZCIM4lNJ7kAtUzFR9cVvHJVSnXOYGmORGIcwrNJTnJ+RHl LDFHclWudU6gaU4E4pxCA0lOKOChBy0nNo5z0ndwcpxty6i2CTTNKZ4Uy1CQkhNq9AQnknDBKaon Ak1ziofBfSgCwQliwjn52raXVR3d65x50CQXD2KBvr/R+4XUeV1HdllzCi3r+s2DpjnFen9/o98K qeURp4Sm34c2IU4f0XR7EHjH43Sjtou0XtvLOj66pj1IxEcR3ngQ5xJq2s3vBMYUASSLDE6bKPwC lzVxXfgeJIiHpFlSGw9ixFeh8Ik4ncYwxoTTJHGp/Db7k89mBaoma3FwC5KffDj44LOZtQgzkNFl z77kttNq9mxGu+KvQwql1VME2UOo/nqVhBg+RvnMQ1dbVrU9yvo/YqInA8JAQY+YlZKZZsTgLxb8 e+wiofHsXsEuq7LKI71w8g2CORKIHrm8IYCOIJOrzmo8SoDCcZI5CjQrE/WlX0H6zSeB/tq5JpBg Ho6jwiBDjNMqpElQKuUg0EJnl3UwlW7UBBKUdIt6Q5ySot0kMKYIZSF5J4YGzBw/yEqSehHKoKuu UgkkeCtOG2+I8w6+SUqJmcEpJWaGrqa6dKBpSmRI1uUNDS7TQ8Ne1nkNJig+7v59mozD8Pm1CvUh 44MKrKqf9W1JAi1SFgSaKDnQNCUyxFMWUi8pJYSep4xu0Dkl/S1vDS7gGBOUQoW4hiSMiJIWkgTG sHt4yRsY6VBy3rissssaiULpQIJ3VP1kiIcyVImkJCfM2Ig0MsDQKKL6l866dKBpKmSI2Xm4lVU5 IEYqTvPFg9sqKjAHmqZChjiVKJsxxuThMBk6OE1nkzcGLqtsPqjbm7p0oGneZIjzvpHNKjEWWIHZ ZU0ptL0rMAJNUvKGOKUbUaqk4vus2suaShgaRMWNg2kqDsN71CxCmEXGqmmpt8uaUxjAxOkDUu8N sfCYRXBOcpJKbyc5TxkJNW/EB9XvdfUBxSeMjFNwTnKalvwqIfkPSjtrAk3nLpZ8swjOSU7Tml8l NN8sIlIJ0Q/n2QRvvCWRvKATkhQKbZiNY3GT/vKkmUXUaA41HSGyJMjcan4p5VElJSTdLIIWU3kn NF0R31SxppvFrfZHQU1EiHRWRCj6haVyKBGhiExCsfXvHg0ZEsXPvtSSOYXjGONbT5FjrhEOL1KN 78rUlbvygFeE5aVSZ9gG9fj/PG5ai+pdHpXRDWHYyzz8iiSIWhqSZV2feG1nyePJfq5ylSRWo0dJ XMXpyAqbfR9hLTQJTBm8k8ynlX0Jy+E+JpQqMeWrMVMn+JxpGeYLMY0xhj1hS6pS8H0dweuBgWIZ hgVRFKtasnCvCmYZpJ0oxpiYonvF0L04d25fu3+1l9f96To7dC8QPvj1N5td3PuF9v8DvmXmfhP+ 3A/w8qD/6w1esuzgvbHFHZz60veD/wNaAu3+1g1fz7P+socXKO17k+vs3F+GS7sf4ITH/W6dXX7Z 2XcQD91ru/3eXNp3eB80rOW2u8Y3QJ//CwAA//8DAFBLAwQUAAYACAAAACEAhhIqjFwCAAB8BAAA GwAAAHhsL2RyYXdpbmdzL3ZtbERyYXdpbmcxLnZtbIxUUWvbMBB+H+w/CPUhL3FjJ7QNqm0oHX3b Butgj0WxlFitrDPWxXH663eSnbQdY8zEsXz36dN93x3Oh8Yyup0XfcH3nRO+qnUjfdKYqgMPW0wq aETfWP7504SEfyFhuzWVFuPjbc/wH3v0UGnLSzonB+Fr2Worj7BH1gs9YMG1MhjTIW9UI9sPGaYk yoKv+CJSLD5wlHk/UuKx1cyogj8NKV1PuEyXnFUAnfLmVRd8mV2n6Tz+c0YcLZ0cMFQWayXWBW/m dsx3I9aOj0FPxdFJ2MGLZs9gnMejJdbGoO7GyhiVEojYrpPKaIdRKrwUHMOBFTinKwx1Fryj1UnP OwFnNe+V+FV6c83ZuPHig7yxiFkL3qABJ+TGg92jvg2iGtntjEus3qLI0qsWb6cIQiuyyxA4GIW1 WK7DutZmVxNydXV5E95fE+OUHkQWyXrjzcZYg0dRG6W0u208JIdOtkksQmDYPWNbY20FFrqCX2zp 0lnQTnZpbECRcrlHOPsZ0NQjgi/f8LHNwUzyT8GBgYsOTqwbK6sX4tz4at9p6vfk49n9P5x24PRb f5AGbgMDm4wLGpQJzSD3EmlRhPJmYc4Yy5XpT8Cwj/Jm50Twc1bmC8pGXL7oxUQ7vg/i3ob2f6Gx Zd83z8T+Mzb9G+A0SiwfxFfo9S+D9b221o+aQ/iRhvUv4TtX1dCNhbFsztZ0p3O2jL/V9XrOruYs W+eLQbyHEuEdKXogn8sHab2OgFNklDmIH3Ao05AJi1PwniapcWUW4tM6pOLrWV9ABwPiqJMp9Mkp fwMAAP//AwBQSwMEFAAGAAgAAAAhAMcVQn5hAQAASA4AACcAAAB4bC9wcmludGVyU2V0dGluZ3Mv cHJpbnRlclNldHRpbmdzMS5iaW7sVMFOwkAUnAIxQmLs0SM3r40m3g1CAgI2LdEevDT0pTSWbtNu Dfgl/oh/48mjP4FvoY2kNyM39r00M2+6nc1O03ogZBBYoYsnxgwv6LGWQDInVq9xxW0xs+GiXkYL J5+Iz9wNGgYMfHfEacB4Dm87e40mT2N2ktxqr/+XUVoobCheCaVege0MH7+sajocXmytzEvVgLp2 ZRmtVsXr2CyFRdvE830Ti97vUpVbvd4/zLcOi/t3FN9w6zqeBPbfvzq1xYI7mY0UN9E1/v79DpO0 kG4sJG4LKXBXpDGtMBUJwfZTymwRR/M17EwsU1nklGHUG/fnIhFLERCmD9M+PMdz6JWynMrHB36c EyYURP5snfIqZedQLuJCRiLBjWUFacQbhORGb4QxScnOanYoVCtY8oMoCftBSOpwB6pFG5gN3Ek9 xwPZa5vdH1jnoBPQCegEdAI6AZ3AESbwAwAA//8DAFBLAwQUAAYACAAAACEAcoepeMABAABSBQAA EAAAAHhsL2NvbW1lbnRzMS54bWzEVE1r20AQvQfyH4Y9N1o7h2KCpUAMhkApAbstPY61o2jb/VB3 1q7dX9+RZJukzTEkIMTu7Nt5mjdPM7/dewc7SmxjKNW0mCigUEdjw2OpvqyXVzMFnDEYdDFQqQ7E 6ra6vJjX0XsKmUESBC5Vm3N3ozXXLXnkInYU5KSJyWOWbXrU3CVCwy1R9k5fTyYftUcbVDXHbW5j 4tOiMsWPyO4Q5no8qU4LgRx5P1nO5w0kakp1N1Uw4u9NqSaSN9NeQEmeB3nxH9ihK9VM6f6miwls MLQnQc+mfTAtY8gjaI1t9NgHG/TWHcbodR/QQ7bcF37DHdaiilTGlHakemW0cOqe9Mi7kTuvzF19 J/6P55U5Xq4PrmB1dw/1NiXpvuhifedodEJuLUsrfm1tGiIiL1hxyHKxgJpSto0lA+uv31ZgMOMG mUDa2TmLIvtvm9sB+iQDF5cXb6To5/iugppIDCHml5SFf4X9MCCPOhnYHHrd3k6qB5ReontXvZ7Y jqMn6KJ8UwwQG1GLnrlQZtDgq8XZgif3FbAigobIbLD+KV50Wx+gxxvKaB0X5xr1OEv0cfzIH/5s EJ12XP0FAAD//wMAUEsDBBQABgAIAAAAIQBWnhsEQgEAAGECAAARAAgBZG9jUHJvcHMvY29yZS54 bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEkltLwzAYhu8F/0PJfZu2mzpL 24HKrhwIThTvQvJtizYHkmjXf296WO2Y4GXyvnny5CP58iCq4BuM5UoWKIliFICkinG5K9DLZhUu UGAdkYxUSkKBGrBoWV5e5FRnVBl4MkqDcRxs4EnSZlQXaO+czjC2dA+C2Mg3pA+3ygji/NLssCb0 k+wAp3F8jQU4wogjuAWGeiSiAcnoiNRfpuoAjGKoQIB0FidRgn+7Doywfx7okklTcNdo/6ZBd8pm tA/H9sHysVjXdVTPOg3vn+C39eNz99SQy3ZWFFCZM5pRA8QpU7LoQ9mqkTmebLYDrIh1az/rLQd2 10x655nndfo9FFjghbJe/5i8zu4fNitUpnGShnESpvNNssjSeTa/fW+vPjnfCvYbYhD4l5iG6U1H vDolHgFljs8+RfkDAAD//wMAUEsDBBQABgAIAAAAIQB40ck9mgEAACYDAAAQAAgBZG9jUHJvcHMv YXBwLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyS0WvbMBDG3wf7H4ze GzlhjBFklTZd6WBjAafdsyqfYxFZEtLFJPvrd7bx4qx7qp9O9318+ul84vbU2qyDmIx3BVsucpaB 074ybl+w593jzReWJVSuUtY7KNgZEruVHz+IbfQBIhpIGUW4VLAGMaw5T7qBVqUFyY6U2sdWIR3j nvu6NhoevD624JCv8vwzhxOCq6C6CX8D2Zi47vC9oZXXPV962Z0DAUtxF4I1WiG9Uv4wOvrka8y+ njRYweeiILoS9DEaPMtc8PlRlFpZ2FCwrJVNIPilIZ5A9UPbKhOTFB2uO9DoY5bMbxrbimWvKkGP U7BORaMcElZvGw9DbUPCKH/5eEgNACbByTA2h3Lundfmk1wOBiqujX3ACELCNeLOoIX0s96qiP8h Xs6JB4aRd8Qp779ljwDVq9KHN5TDw+m+f27Y+DYod5ZlIEM8ttl9NNWepjgJ4rtxh/Qcdv5BIUwz vm6KslERKvotk35piCcab7R9yKZRbg/V5Hkr9BvxMq69XK4WOX3DIkw9wS8LLv8AAAD//wMAUEsB Ai0AFAAGAAgAAAAhANTEw0GUAQAA5AUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVz XS54bWxQSwECLQAUAAYACAAAACEAtVUwI/UAAABMAgAACwAAAAAAAAAAAAAAAAChAwAAX3JlbHMv LnJlbHNQSwECLQAUAAYACAAAACEAgT6Ul/QAAAC6AgAAGgAAAAAAAAAAAAAAAACNBgAAeGwvX3Jl bHMvd29ya2Jvb2sueG1sLnJlbHNQSwECLQAUAAYACAAAACEAHUUlc00BAAAaAgAADwAAAAAAAAAA AAAAAADBCAAAeGwvd29ya2Jvb2sueG1sUEsBAi0AFAAGAAgAAAAhADV0zqW4FAAAN0UAABQAAAAA AAAAAAAAAAAAOwoAAHhsL3NoYXJlZFN0cmluZ3MueG1sUEsBAi0AFAAGAAgAAAAhANU4Oz3wAAAA XQIAACMAAAAAAAAAAAAAAAAAJR8AAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhAOmmJbiCBgAAUxsAABMAAAAAAAAAAAAAAAAAViAAAHhsL3RoZW1lL3Ro ZW1lMS54bWxQSwECLQAUAAYACAAAACEA/p1fUOMCAADpDgAADQAAAAAAAAAAAAAAAAAJJwAAeGwv c3R5bGVzLnhtbFBLAQItABQABgAIAAAAIQCzA/aJQQkAAEYqAAAYAAAAAAAAAAAAAAAAABcqAAB4 bC93b3Jrc2hlZXRzL3NoZWV0MS54bWxQSwECLQAUAAYACAAAACEAhhIqjFwCAAB8BAAAGwAAAAAA AAAAAAAAAACOMwAAeGwvZHJhd2luZ3Mvdm1sRHJhd2luZzEudm1sUEsBAi0AFAAGAAgAAAAhAMcV Qn5hAQAASA4AACcAAAAAAAAAAAAAAAAAIzYAAHhsL3ByaW50ZXJTZXR0aW5ncy9wcmludGVyU2V0 dGluZ3MxLmJpblBLAQItABQABgAIAAAAIQByh6l4wAEAAFIFAAAQAAAAAAAAAAAAAAAAAMk3AAB4 bC9jb21tZW50czEueG1sUEsBAi0AFAAGAAgAAAAhAFaeGwRCAQAAYQIAABEAAAAAAAAAAAAAAAAA tzkAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAHjRyT2aAQAAJgMAABAAAAAAAAAA AAAAAAAAMDwAAGRvY1Byb3BzL2FwcC54bWxQSwUGAAAAAA4ADgCtAwAAAD8AAAAA --_002_8375F6DAEFB09F48815203F1FE23B797113C9BA079shelby_-- From Basavaraj.Patil@nokia.com Mon Feb 27 13:57:48 2012 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 C68BF21E802F for ; Mon, 27 Feb 2012 13:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.602 X-Spam-Level: X-Spam-Status: No, score=-104.602 tagged_above=-999 required=5 tests=[AWL=1.841, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-7WM9qKr2WZ for ; Mon, 27 Feb 2012 13:57:45 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9CA21F8611 for ; Mon, 27 Feb 2012 13:57:44 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1RLvghr010196; Mon, 27 Feb 2012 23:57:43 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 27 Feb 2012 23:57:42 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Mon, 27 Feb 2012 22:57:41 +0100 From: To: , Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXP//lxwA Date: Mon, 27 Feb 2012 21:57:41 +0000 Message-ID: In-Reply-To: <2782C93FD2244441893673F3F9128192114D0B@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.133] Content-Type: text/plain; charset="us-ascii" Content-ID: <7E1522DBA46C7C44A3F175FC3997DAEF@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 21:57:42.0821 (UTC) FILETIME=[D4A45550:01CCF59A] X-Nokia-AV: Clean Subject: Re: [paws] Further explanation of partitioned data models 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: Mon, 27 Feb 2012 21:57:48 -0000 Hi John, What you write below is a potential path that white space technology and dynamic spectrum allocation could take. However it is still pretty nascent at this time. What the FCC has approved for now is the availability of some spectrum (TVWS) for use as per the guidelines/regulations specified. Use of this spectrum requires a device to query a database to determine available channels prior to use. This is a clear scoped problem that can be solved via the device-2-database protocol that PAWS is working on. As Brian (co-chair) said, it is better to focus on this narrow scope and get it done. Subsequently the working group may consider expanding its charter to look at the bigger picture of co-existence, spectrum negotiation/brokering etc. -Raj On 2/27/12 3:13 PM, "ext Stine, John A." wrote: >From the lack of response to my email last week, I assume folks just >don't understand why I am recommending the division of the data model. >Please let me explain in a different way. > >Last December, at the SDR Forum, Julius Knapp, the Director of the OET at >the FCC, hosted a panel attended by five of the ten database >administrators. In that panel, he asked the panelists what was in it for >them. Several responded that they hoped they could provide a service to >those looking for spectrum and to help broker these arrangements. > >This is not the model of TVWS. At present, the urgency of the paws >effort surrounds a narrower goal of enabling TVWS devices to obtain >channels they can use. I do not want to make any suggestions that would >prevent us from achieving this goal first. I do want to make an effort >to prevent what is done from becoming an impediment to a bigger role for >whitespace database administration in the future, one of managing >coexistence and brokering spectrum reuse. > >In all methods of using a database where a device negotiates with a >database, the types of messages that will be used are likely to be >similar:=20 >- This is who I am, what rules should I apply in negotiating for >spectrum? =20 >- This is the spectrum I am looking for, what do you have? >- This is the spectrum that meets your query criteria. >- etc. >The methods developed for trust are also reusable. This is the reason >for having a portion of the data model remain the same for all expansions. > >The differences between a TVWS scenario and a brokering scenario are >likely to be additional messaging and different data, both for the >business of brokering and for defining the spectrum authorization. For >example, in the brokering use case there needs to be a spectrum data >model that allows a primary spectrum user to release spectrum into the >market, (e.g., provide their contours ) and to specify the terms of use. >My concern is that if the data model of TVWS comingles the data of >messaging, administration, and spectrum; that this sort of expansion of >paws would require increasing the size of the data model and would make >expanding its capability more difficult both because of the impact of >this expansion on legacy uses and because of the confusion of using large >schemas that have similar but different data elements. > >My solution is to divide the data model into three parts. The data >document of messages would use the namespace of three schemas. In the >TVWS edition, this would also allow different administrative and spectrum >schemas for different regulatory domains. In end, the data for TVWS >management would not be any different, it would just be defined in three >schemas > >In the initial exchanges between a device and a database, there would be >agreement on which schemas to use. This is equivalent to resolving the >regulatory domain. The messaging that follows would be the exact same, >with the exact same data as the messaging if a comingled data model were >used. > >If the division is done well, then, in the long term, others can create >schemas for administration and spectrum definition that meets their >business needs without having to do so through paws. They would be able >expand the way the paws protocol is used without having to revise paws. > >I hope this better explains my intent. It would also be helpful to >understand why anyone thinks this should not be done. > >John >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Mon Feb 27 14:06:54 2012 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 B5DF621E8029 for ; Mon, 27 Feb 2012 14:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.264 X-Spam-Level: X-Spam-Status: No, score=-4.264 tagged_above=-999 required=5 tests=[AWL=1.735, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uiNzC2ptMymZ for ; Mon, 27 Feb 2012 14:06:53 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9717A21E8025 for ; Mon, 27 Feb 2012 14:06:52 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1RM6n0X004333; Tue, 28 Feb 2012 00:06:50 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 00:06:48 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Mon, 27 Feb 2012 23:06:48 +0100 From: To: Thread-Topic: [paws] UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZIdjEAgAN/KwCAA7asgIAApSwAgADX9ID//6FlgIAAbscA//+nk4A= Date: Mon, 27 Feb 2012 22:06:47 +0000 Message-ID: In-Reply-To: <4C3A6C42-0D46-4A94-81AE-6D7B258B2462@inf-net.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="utf-8" Content-ID: <74B7035D31BC7842A6272F4B3E453D74@mgd.nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 22:06:49.0047 (UTC) FILETIME=[1A37CE70:01CCF59C] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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: Mon, 27 Feb 2012 22:06:54 -0000 SGkgVGVjbywNCg0KT0ssIGNoYW5nZSBPLjcgYXMgaW5kaWNhdGVkIGFuZCByZW1vdmUgUC4xMC4g SSBiZWxpZXZlIHRoaXMgd29ya3MuDQoNCktpbmQgUmVnYXJkcywNClNjb3R0DQoNCk9uIDIvMjcv MTIgMzoyMyBQTSwgImV4dCBUZWNvIEJvb3QiIDx0ZWNvQGluZi1uZXQubmw+IHdyb3RlOg0KDQo+ SGkgU2NvdHQsDQo+DQo+T3AgMjcgZmViLiAyMDEyLCBvbSAyMTo0NiBoZWVmdCA8c2NvdHQucHJv YmFzY29Abm9raWEuY29tPg0KPjxzY290dC5wcm9iYXNjb0Bub2tpYS5jb20+IGhldCB2b2xnZW5k ZSBnZXNjaHJldmVuOg0KPg0KPj4gSGkgVGVjbywNCj4+IA0KPj4gV2UgY291bGQgY2hhbmdlIE8u NyB0byBzb21ldGhpbmcgbGlrZToNCj4+IA0KPj4gTy43OiBUaGUgbWFzdGVyIGRldmljZSBNVVNU IHJlZ2lzdGVyIHdpdGggaXRzIG1vc3QgY3VycmVudCBhbmQNCj4+dXAtdG8tZGF0ZQ0KPj4gaW5m b3JtYXRpb24sIGFuZCBNVVNUIGluY2x1ZGUgYWxsIHZhcmlhYmxlcyBtYW5kYXRlZCBieSBsb2Nh bCByZWd1bGF0b3INCj4+IHBvbGljeS4NCj4+IA0KPj4gV291bGQgdGhpcyB3b3JrPw0KPlllcywg dGhpcyBpcyBmaW5lLg0KPkFuZCByZW1vdmUgUC4xMD8NCj4NCj5UaGFua3MsIFRlY28NCj4NCj4+ IA0KPj4gS2luZCBSZWdhcmRzLA0KPj4gU2NvdHQNCj4+IA0KPj4gDQo+PiANCj4+IE9uIDIvMjcv MTIgMjoyNSBQTSwgImV4dCBUZWNvIEJvb3QiIDx0ZWNvQGluZi1uZXQubmw+IHdyb3RlOg0KPj4g DQo+Pj4gSGVsbG8gU2NvdHQsDQo+Pj4gDQo+Pj4gSSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQuIEJ1 dCBJIHdhbnQgdG8ga2VlcCB0aGluZ3Mgc2ltcGxlLiBUaGUNCj4+PiBQLiogcmVxdWlyZW1lbnRz IGFyZSBmb3IgdGhlIHByb3RvY29sLCBpdCBNVVNUIHN1cHBvcnQgb3B0aW9uYWwNCj4+PiB2YXJp YWJsZXMuDQo+Pj4gVGhlIE8uKiByZXF1aXJlbWVudHMgZXhwbGFpbiBob3cgdGhlc2UgYXJlIHVz ZWQuIFRoaXMgaXMgdGhlIE1BWSwNCj4+PiByaWdodD8gDQo+Pj4gDQo+Pj4gSGF2aW5nIHBlcmZv cm1lZCBzb21lIHRlc3RzIHRvZGF5IHdpdGggYW4gZW1lcmdlbmN5IHJlc3BvbmRlcnMNCj4+PiBu ZXR3b3JrLCBJIHNhdyBzb21lIGhpZ2ggdHJhZmZpYyBsb2FkLiBTb21ldGhpbmcgbGlrZSB0aGlz Og0KPj4+ICAgIDxzZWxmX2V4cGxhaW5pbmdfdmFyaWFibGVfbmFtZT4NCj4+PiAgICAgICAgMQ0K Pj4+ICAgIDxcc2VsZl9leHBsYWluaW5nX3ZhcmlhYmxlX25hbWU+DQo+Pj4gSSBjb3VsZCB0aGlu ayBvZiBhbiBlZmZpY2llbmN5IHJlcXVpcmVtZW50LCBmb3IgdGhlIHJhcGlkIGRlcGxveWVkDQo+ Pj4gbmV0d29yayB1c2UgY2FzZS4NCj4+PiANCj4+PiBUaGFua3MsIFRlY28NCj4+PiANCj4+PiAN Cj4+PiBPcCAyNyBmZWIuIDIwMTIsIG9tIDE0OjMyIGhlZWZ0IDxzY290dC5wcm9iYXNjb0Bub2tp YS5jb20+DQo+Pj4gPHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbT4gaGV0IHZvbGdlbmRlIGdlc2No cmV2ZW46DQo+Pj4gDQo+Pj4+IEhpIFRlY28sDQo+Pj4+IA0KPj4+PiBJZiB3ZSBsb29rIGF0IFAu OSBhbmQgUC4xMCB0b2dldGhlciwgUC45IHNheXMgdGhhdCByZWdpc3RyYXRpb24gaXMgYQ0KPj4+ PiBNVVNUDQo+Pj4+IC0tIHRoZSBwcm90b2NvbCBzdXBwb3J0cyByZWdpc3RyYXRpb24gd2l0aG91 dCBxdWVzdGlvbi4gUC4xMCBzYXlzIHRoZQ0KPj4+PiBzaWduYWxpbmcgZm9yIHJlZ2lzdHJhdGlv biBNQVkgY29udGFpbiBhbnkgb2Ygc2V2ZXJhbCB2YXJpYWJsZXMgKGFsc28NCj4+Pj4gYWxsb3dz IG1vcmUgdmFyaWFibGVzIHRvIGJlIGluY2x1ZGVkIGlmIHJlcXVpcmVkIGJ5IGxvY2FsDQo+Pj4+ cmVndWxhdGlvbnMpLg0KPj4+PiBUaGUgbGlzdCBjdXJyZW50bHkgaWRlbnRpZmllcyBhbGwgdmFy aWFibGVzIHJlcXVpcmVkIGZvciByZWdpc3RyYXRpb24NCj4+Pj5pbg0KPj4+PiB0aGUgVVMuIE5v dyBpZiB3ZSBsb29rIGF0IHRoZSBEYXRhIE1vZGVsIHJlcXVpcmVtZW50cywgZWFjaCB2YXJpYWJs ZQ0KPj4+PiBpZGVudGlmaWVkIHRoYXQgdGhlIHJlZ2lzdHJhdGlvbiBzZXJ2aWNlIE1BWSBjb250 YWluICh0aGVzZSBhcmUgaW4NCj4+Pj5ELjUsDQo+Pj4+IEQuNiwgRC4xLCBELjcgYW5kIEQuOCkg TVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgRGF0YSBNb2RlbC4gVGhlDQo+Pj4+cHJvdG9jb2wNCj4+ Pj4gTVVTVCBzdXBwb3J0IHJlZ2lzdHJhdGlvbiwgYW5kIHRoZSBEYXRhIE1vZGVsIGluIHRoZSBw cm90b2NvbCBNVVNUDQo+Pj4+IHN1cHBvcnQNCj4+Pj4gdGhlIHZhcmlhYmxlcyBpZGVudGlmaWVk IGZvciByZWdpc3RyYXRpb24gc2VydmljZS4NCj4+Pj4gDQo+Pj4+IFRoZSBjdXJyZW50IHVzZSBv ZiBNVVNUIGluIFAuOSBhbmQgTUFZIGluIFAuMTAgaGFzIHRoZSBlZmZlY3QgdGhhdA0KPj4+PldT RHMNCj4+Pj4gaW4NCj4+Pj4gdGhlIFVTIGFyZSBhbGxvd2VkIHRvIHJlZ2lzdGVyIChiZWNhdXNl IHRoZSBwcm90b2NvbCBzdXBwb3J0cw0KPj4+PiByZWdpc3RyYXRpb24pIGFuZCBhcmUgYWxsb3dl ZCB0byB1c2UgdGhlIHZhcmlhYmxlcyBkZWZpbmVkIGJ5IHRoZSBGQ0MNCj4+Pj4gKGJlY2F1c2Ug dGhlIHJlZ2lzdHJhdGlvbiBzaWduYWxpbmcgTUFZIGluY2x1ZGUgdGhvc2UgdmFyaWFibGVzKS4g VGhpcw0KPj4+PiBhbHNvIGhhcyB0aGUgZWZmZWN0IHRoYXQgV1NEcyBpbiB0aGUgVUsgKG9yIGVs c2V3aGVyZSBpbiB0aGUgd29ybGQpDQo+Pj4+YXJlDQo+Pj4+IGFsbG93ZWQgdG8gcmVnaXN0ZXIg aWYgdGhpcyBpcyBhIGxvY2FsIHJlcXVpcmVtZW50IChiZWNhdXNlIHRoZQ0KPj4+PnByb3RvY29s DQo+Pj4+IHN1cHBvcnRzIHJlZ2lzdHJhdGlvbikgYW5kIGFyZSBhbGxvd2VkIHRvIHVzZSAob3Ig bm90IHVzZSkgdGhlDQo+Pj4+dmFyaWFibGVzDQo+Pj4+IGRlZmluZWQgYnkgdGhlIEZDQyAoYmVj YXVzZSB0aGUgcmVnaXN0cmF0aW9uIHNpZ25hbGluZyBNQVkgaW5jbHVkZQ0KPj4+PnRob3NlDQo+ Pj4+IHZhcmlhYmxlcykuIE5vdGhpbmcgdG8gcHJldmVudCBhZGRpbmcgbW9yZSB2YXJpYWJsZXMg aWYgbmVlZGVkIGJ5DQo+Pj4+T2Zjb20sDQo+Pj4+IElEQSwgZXRjLi4uDQo+Pj4+IA0KPj4+PiBB bm90aGVyIHBvc3NpYmlsaXR5IGlzIHRvIGNoYW5nZSB0aGUgd29yZGluZyBvZiBQLjEwIHRvIHJl YWQNCj4+Pj4gUC4xMDogVGhlIHJlZ2lzdHJhdGlvbiBzaWduYWxpbmcgTVVTVCBpbmNsdWRlIHRo ZSBmb2xsb3dpbmcgb3B0aW9uYWwNCj4+Pj4gdmFyaWFibGVzOiB0aGUgRGV2aWNlIElELCBtYW51 ZmFjdHVyZXLCuXMgc2VyaWFsIG51bWJlciwgZGV2aWNlDQo+Pj4+bG9jYXRpb24sDQo+Pj4+IGRl dmljZSBhbnRlbm5hIGNoYXJhY3RlcmlzdGljIGluZm9ybWF0aW9uLCBuYW1lIG9mIGluZGl2aWR1 YWwgb3INCj4+Pj4gYnVzaW5lc3MNCj4+Pj4gdGhhdCBvd25zIHRoZSBkZXZpY2UsIG5hbWUsIGFk ZHJlc3MsIGVtYWlsIGFkZHJlc3MgYW5kIHBob25lIG51bWJlcg0KPj4+Pm9mIGENCj4+Pj4gY29u dGFjdCBwZXJzb24gd2hvIGlzIHJlc3BvbnNpYmxlIGZvciBkZXZpY2Ugb3BlcmF0aW9uLg0KPj4+ PiANCj4+Pj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+Pj4+IA0KPj4+PiBLaW5kIFJlZ2FyZHMsDQo+ Pj4+IFNjb3R0DQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gDQo+Pj4+ IE9uIDIvMjYvMTIgMzo0MSBQTSwgImV4dCBUZWNvIEJvb3QiIDx0ZWNvQGluZi1uZXQubmw+IHdy b3RlOg0KPj4+PiANCj4+Pj4+IEhpIFNjb3R0LA0KPj4+Pj4gDQo+Pj4+PiBJIHN0aWxsIHRoaW5r IGl0IGlzIGEgTVVTVCBmb3IgdGhlIHByb3RvY29sLCBhbmQgYSBNQVkgZm9yIHVzYWdlLg0KPj4+ Pj4gDQo+Pj4+PiBUaGFua3MsIFRlY28NCj4+Pj4+IA0KPj4+Pj4gT3AgMjQgZmViLiAyMDEyLCBv bSAxOTo1OCBoZWVmdCA8c2NvdHQucHJvYmFzY29Abm9raWEuY29tPg0KPj4+Pj4gPHNjb3R0LnBy b2Jhc2NvQG5va2lhLmNvbT4gaGV0IHZvbGdlbmRlIGdlc2NocmV2ZW46DQo+Pj4+PiANCj4+Pj4+ PiBIZWxsbyBUZWNvLA0KPj4+Pj4+IA0KPj4+Pj4+IFNpbmNlIFBBV1MgaXMgYSBnbG9iYWwgc3Rh bmRhcmQsIHJlZ2lzdHJhdGlvbiBmb3IgYWxsIHJlZ3VsYXRvcnkNCj4+Pj4+PiBkb21haW5zDQo+ Pj4+Pj4gbXVzdCBiZSBzdXBwb3J0ZWQuIFdoaWxlIHRoZSBGQ0MgZG9lcyByZXF1aXJlIGFsbCBv ZiB0aGUgdmFyaWFibGVzDQo+Pj4+Pj4gbGlzdGVkDQo+Pj4+Pj4gaW4gUC4xMCwgb3RoZXIgcmVn dWxhdG9yeSBkb21haW5zIG1heSBub3QgcmVxdWlyZSBlYWNoIG9mIHRob3NlDQo+Pj4+Pj4gdmFy aWFibGVzLg0KPj4+Pj4+IFNvIGZvciByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sLCB1c2lu ZyBNQVkgZW5hYmxlcyB0aGUgRkNDIHRvDQo+Pj4+Pj4gcmVxdWlyZQ0KPj4+Pj4+IHRoZXNlIHZh cmlhYmxlcyB3aGlsZSBhbGxvd2luZyBvdGhlciByZWd1bGF0b3JzIHRvIHNlbGVjdCBhIHN1YnNl dCwNCj4+Pj4+Pm9yDQo+Pj4+Pj4gZXZlbiBkaWZmZXJlbnQsIHZhcmlhYmxlcy4NCj4+Pj4+PiAN Cj4+Pj4+PiBXaXRoIHRoaXMgZXhwbGFuYXRpb24sIGFyZSB5b3Ugb2theSB3aXRoIE1BWSBpbiBQ LjEwPw0KPj4+Pj4+IA0KPj4+Pj4+IEtpbmQgUmVnYXJkcywNCj4+Pj4+PiBTY290dA0KPj4+Pj4+ IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IE9uIDIvMjIvMTIgMTozNCBBTSwgImV4dCBUZWNv IEJvb3QiIDx0ZWNvQGluZi1uZXQubmw+IHdyb3RlOg0KPj4+Pj4+IA0KPj4+Pj4+PiBTY290dCwg UmF5LA0KPj4+Pj4+PiANCj4+Pj4+Pj4gVGhlIFAuKiBhcmUgbW9zdGx5IE1VU1QgcmVxdWlyZW1l bnRzIGZvciB0aGUgcHJvdG9jb2wuIFRoYXQncyBmaW5lLg0KPj4+Pj4+PiBFeGNlcHQgUC4xMCwg dGhpcyBpcyBhIE1BWSBvcGVyYXRpb25hbCByZXF1aXJlbWVudC4gVGhlIHByb3RvY29sDQo+Pj4+ Pj4+IE1VU1Qgc3VwcG9ydCBpdC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IEknbSBmaW5lIHdpdGggdGhl IHJlc3Qgb2YgaXQuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJcyBub3RlZCBzb21ld2hlcmUgdGhhdCB3 ZSAoSUVURikgZG8gb3VyIGJlc3QgdG8gc3VwcG9ydCBhcyBtYW55DQo+Pj4+Pj4+IHJlZ3VsYXRv ciBydWxlcyBhcyBwb3NzaWJsZSwgYW5kIGxlYXZlIHNldHRpbmcgdXAgcmVxdWlyZW1lbnRzIGZv cg0KPj4+Pj4+PiBhY3R1YWwgZGVwbG95bWVudCB1cCB0byB0aGUgbWFuZGF0ZWQgYXV0aG9yaXRp ZXM/IFRoaXMgbWFrZXMgdGhlDQo+Pj4+Pj4+IE8uKiByZXF1aXJlbWVudHMgaW5mb3JtYXRpb25h bC4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFRoYW5rcywgVGVjbw0KPj4+Pj4+PiANCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IE9wIDIyIGZlYi4gMjAxMiwgb20gMDA6NTMgaGVlZnQgPHNjb3R0LnByb2Jhc2NvQG5v a2lhLmNvbT4NCj4+Pj4+Pj4gPHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbT4gaGV0IHZvbGdlbmRl IGdlc2NocmV2ZW46DQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gSGVsbG8gQWxsLA0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiBJIGhhdmUgcmV2aXNlZCBTZWN0aW9uIDYgb2YgdGhlIEktRCB3aGljaCBkZXNjcmli ZXMgdGhlIERhdGEgTW9kZWwNCj4+Pj4+Pj4+IFJlcXVpcmVtZW50cywgUHJvdG9jb2wgUmVxdWly ZW1lbnRzIGFuZCBPcGVyYXRpb25hbCBSZXF1aXJlbWVudHMuDQo+Pj4+Pj4+PiBUaGlzDQo+Pj4+ Pj4+PiBpbmNsdWRlcyB0aGUgcmVxdWlyZW1lbnRzIGZyb20gdGhlIHRocmVhdCBtb2RlbA0KPj4+ Pj4+Pj4gKGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wYXdzL2N1cnJlbnQv bXNnMDA3NzEuaHRtbCkuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRoZSByZXF1aXJlbWVudHMgYXJl IG9yZGVyZWQgInRvcCBkb3duIiB0byBmb2xsb3cgdGhlIHByZXZpb3VzDQo+Pj4+Pj4+PiBzZWN0 aW9ucw0KPj4+Pj4+Pj4gb2YNCj4+Pj4+Pj4+IHRoZSBkb2N1bWVudDogcmVxdWlyZW1lbnRzIGRl cml2ZWQgZnJvbSBkaXNjb3ZlcnkgYXJlIGZvbGxvd2VkIGJ5DQo+Pj4+Pj4+PiByZXF1aXJlbWVu dHMgZGVyaXZlZCBmcm9tIHJlZ2lzdHJhdGlvbiBhcmUgZm9sbG93ZWQgYnkNCj4+Pj4+Pj4+cmVx dWlyZW1lbnRzDQo+Pj4+Pj4+PiBkZXJpdmVkIGZyb20gaG90c3BvdCwgZXRjLi4uDQo+Pj4+Pj4+ PiANCj4+Pj4+Pj4+IFBsZWFzZSByZXZpZXcgdGhlIHByb3Bvc2VkIHRleHQsIHdlIGhvcGUgdG8g aGF2ZSB5b3VyIGNvbW1lbnRzIGJ5DQo+Pj4+Pj4+PiBGZWINCj4+Pj4+Pj4+IDI4dGguDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IEtpbmQgUmVnYXJkcywNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gUmFqICYg U2NvdHQNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4gRC4gRGF0YSBNb2RlbCBSZXF1aXJlbWVudHM6DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGRpc2NvdmVyeSBmdW5jdGlv bjwvRWQuIE5vdGU+DQo+Pj4+Pj4+PiBELjE6IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBz cGVjaWZ5aW5nIHRoZSBsb2NhdGlvbiBvZiB0aGUNCj4+Pj4+Pj4+V1NELA0KPj4+Pj4+Pj4gdGhl DQo+Pj4+Pj4+PiB1bmNlcnRhaW50eSBpbiBtZXRlcnMsIHRoZSBoZWlnaHQgJiBpdHMgdW5jZXJ0 YWludHksIGFuZA0KPj4+Pj4+Pj5jb25maWRlbmNlDQo+Pj4+Pj4+PiBpbg0KPj4+Pj4+Pj4gcGVy Y2VudGFnZSBmb3IgdGhlIGxvY2F0aW9uIGRldGVybWluYXRpb24uIFRoZSBEYXRhIE1vZGVsIE1V U1QNCj4+Pj4+Pj4+IHN1cHBvcnQNCj4+Pj4+Pj4+IGJvdGggTm9ydGggQW1lcmljYW4gRGF0dW0g b2YgMTk4MyBhbmQgV0dTODQuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gRC4yOiBU aGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyB0aGUgVVJJIGFkZHJlc3Mgb2Yg YQ0KPj4+Pj4+Pj4gd2hpdGUNCj4+Pj4+Pj4+IHNwYWNlIGRhdGFiYXNlLg0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+IEQuMzogVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNp ZnlpbmcgdGhlIFVSSSBhZGRyZXNzIG9mIGENCj4+Pj4+Pj4+IG5hdGlvbmFsDQo+Pj4+Pj4+PiBs aXN0aW5nIHNlcnZpY2UuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gRC40OiBUaGUg RGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyAgcmVndWxhdG9yeSBkb21haW4gYW5k DQo+Pj4+Pj4+PiBpdHMNCj4+Pj4+Pj4+IGNvcnJlc3BvbmRpbmcgZGF0YSByZXF1aXJlbWVudHMu DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiA8RWQuIE5vdGU+cmVx dWlyZW1lbnRzIHJlbGF0ZWQgdG8gcmVnaXN0cmF0aW9uIGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+ Pj4+Pj4+IEQuNTogVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgYW4gSUQg b2YgdGhlDQo+Pj4+Pj4+PnRyYW5zbWl0dGVyDQo+Pj4+Pj4+PiBkZXZpY2UuIFRoaXMgSUQgd291 bGQgY29udGFpbiB0aGUgSUQgb2YgdGhlIHRyYW5zbWl0dGVyIGRldmljZQ0KPj4+Pj4+Pj50aGF0 DQo+Pj4+Pj4+PiBoYXMNCj4+Pj4+Pj4+IGJlZW4gY2VydGlmaWVkIGJ5IGEgcmVndWxhdG9yeSBi b2R5IGZvciBpdHMgcmVndWxhdG9yeSBkb21haW4uIFRoZQ0KPj4+Pj4+Pj4gRGF0YQ0KPj4+Pj4+ Pj4gTW9kZWwgTVVTVCBzdXBwb3J0IGEgZGV2aWNlIGNsYXNzLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gRC42OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQg c3BlY2lmeWluZyBhIG1hbnVmYWN0dXJlcsK5cw0KPj4+Pj4+Pj5zZXJpYWwNCj4+Pj4+Pj4+IG51 bWJlcg0KPj4+Pj4+Pj4gZm9yIGEgbWFzdGVyIGRldmljZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g DQo+Pj4+Pj4+PiBELjc6ICBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyB0 aGUgYW50ZW5uYSBhbmQNCj4+Pj4+Pj4+IHJhZGlhdGlvbg0KPj4+Pj4+Pj4gcmVsYXRlZCBwYXJh bWV0ZXJzIG9mIHRoZSBkZXZpY2UsIHN1Y2ggYXM6DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IC0gYW50 ZW5uYSBoZWlnaHQNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gLSBhbnRlbm5hIGdhaW4NCj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4gLSBtYXhpbXVtIG91dHB1dCBwb3dlciwgRUlSUCAoZEJtKQ0KPj4+Pj4+Pj4g DQo+Pj4+Pj4+PiAtIGFudGVubmEgcmFkaWF0aW9uIHBhdHRlcm4gKGRpcmVjdGlvbmFsIGRlcGVu ZGVuY2UNCj4+Pj4+Pj4+ICBvZiB0aGUgc3RyZW5ndGggb2YgdGhlIHJhZGlvIHNpZ25hbCBmcm9t IHRoZSBhbnRlbm5hKQ0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAtIHNwZWN0cnVtIG1hc2sgd2l0aCBs b3dlc3QgYW5kIGhpZ2hlc3QgcG9zc2libGUgZnJlcXVlbmN5DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ IC0gc3BlY3RydW0gbWFzayBpbiBkQnIgZnJvbSBwZWFrIHRyYW5zbWl0IHBvd2VyIGluIEVJUlAs DQo+Pj4+Pj4+PiAgd2l0aCBzcGVjaWZpYyBwb3dlciBsaW1pdCBhdCBhbnkgZnJlcXVlbmN5IGxp bmVhcmx5DQo+Pj4+Pj4+PiAgaW50ZXJwb2xhdGVkIGJldHdlZW4gYWRqYWNlbnQgcG9pbnRzIG9m IHRoZSBzcGVjdHJ1bSBtYXNrDQo+Pj4+Pj4+PiAgbWVhc3VyZW1lbnQgcmVzb2x1dGlvbiBiYW5k d2lkdGggZm9yIEVJUlAgbWVhc3VyZW1lbnRzLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4gRC44OiBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWlu ZyBvd25lciBhbmQgb3BlcmF0b3INCj4+Pj4+Pj4+IGNvbnRhY3QNCj4+Pj4+Pj4+IGluZm9ybWF0 aW9uIGZvciBhIHRyYW5zbWl0dGVyLiBUaGlzIGluY2x1ZGVzIHRoZSBuYW1lIG9mIHRoZQ0KPj4+ Pj4+Pj4gdHJhbnNtaXR0ZXINCj4+Pj4+Pj4+IG93bmVyLCBuYW1lIG9mIHRyYW5zbWl0dGVyIG9w ZXJhdG9yLCBwb3N0YWwgYWRkcmVzcywgZW1haWwgYWRkcmVzcw0KPj4+Pj4+Pj4gYW5kDQo+Pj4+ Pj4+PiBwaG9uZSBudW1iZXIgb2YgdGhlIHRyYW5zbWl0dGVyIG9wZXJhdG9yLg0KPj4+Pj4+Pj4g DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiA8RWQuIE5vdGU+cmVx dWlyZW1lbnRzIHJlbGF0ZWQgdG8gaG90c3BvdCB1c2UgY2FzZTwvRWQuIE5vdGU+DQo+Pj4+Pj4+ PiBELjk6IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIGEgbGlzdCBvZiBh dmFpbGFibGUNCj4+Pj4+Pj4+IGNoYW5uZWxzLg0KPj4+Pj4+Pj4gVGhlIERhdGEgTW9kZWwgTVVT VCBzdXBwb3J0IHNwZWNpZmljYXRpb24gb2YgdGhpcyBpbmZvcm1hdGlvbiBieQ0KPj4+Pj4+Pj4g Y2hhbm5lbA0KPj4+Pj4+Pj4gbnVtYmVycyBhbmQgYnkgc3RhcnQgYW5kIHN0b3AgZnJlcXVlbmNp ZXMuIFRoZSBEYXRhIE1vZGVsIE1VU1QNCj4+Pj4+Pj4+IHN1cHBvcnQgYQ0KPj4+Pj4+Pj4gY2hh bm5lbCBhdmFpbGFiaWxpdHkgc2NoZWR1bGUgYW5kIG1heGltdW0gcG93ZXIgbGV2ZWwgZm9yIGVh Y2gNCj4+Pj4+Pj4+IGNoYW5uZWwNCj4+Pj4+Pj4+IGluDQo+Pj4+Pj4+PiB0aGUgbGlzdC4NCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJl bWVudHMgcmVsYXRlZCB0byBtb2JpbGl0eSB1c2UgY2FzZTwvRWQuIE5vdGU+DQo+Pj4+Pj4+PiBE LjEwOiAgVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgY2hhbm5lbCBhdmFp bGFiaWxpdHkNCj4+Pj4+Pj4+IGluZm9ybWF0aW9uIGZvciBhIHNpbmdsZSBsb2NhdGlvbiBhbmQg YW4gYXJlYSAoZS5nLiBhIHBvbHlnb24NCj4+Pj4+Pj4+IGRlZmluZWQNCj4+Pj4+Pj4+IGJ5DQo+ Pj4+Pj4+PiBtdWx0aXBsZSBsb2NhdGlvbiBwb2ludHMgb3IgYSBnZW9tZXRyaWMgc2hhcGUgc3Vj aCBhcyBhIGNpcmNsZSkuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gUC4gUHJvdG9jb2wgUmVxdWlyZW1lbnRzOg0KPj4+Pj4+ Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0 byBkaXNjb3ZlcnkgZnVuY3Rpb248L0VkLiBOb3RlPg0KPj4+Pj4+Pj4gUC4xOiBUaGUgcHJvdG9j b2wgTVVTVCBwcm92aWRlIGEgbWVzc2FnZSBzZXF1ZW5jZSBmb3IgdGhlIG1hc3Rlcg0KPj4+Pj4+ Pj4gZGV2aWNlDQo+Pj4+Pj4+PiB0bw0KPj4+Pj4+Pj4gZGlzY292ZXIgYSB3aGl0ZSBzcGFjZSBk YXRhYmFzZSB0aGF0IHByb3ZpZGVzIHNlcnZpY2UgYXQgaXRzDQo+Pj4+Pj4+PmN1cnJlbnQNCj4+ Pj4+Pj4+IGxvY2F0aW9uLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFAuMjogVGhl IHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhY2Nlc3Mgb2YgYSBkYXRhYmFzZSBkaXJlY3RseS4gVGhl DQo+Pj4+Pj4+PiBwcm90b2NvbA0KPj4+Pj4+Pj4gTVVTVCBzdXBwb3J0IGFjY2VzcyBvZiBhIGRh dGFiYXNlIHVzaW5nIGEgbGlzdGluZyBhcHByb3ZlZCBieSBhDQo+Pj4+Pj4+PiBuYXRpb25hbA0K Pj4+Pj4+Pj4gcmVndWxhdG9yLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFAuMzog VGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBkZXRlcm1pbmF0aW9uIG9mIHJlZ3VsYXRvcnkgZG9t YWluDQo+Pj4+Pj4+PiBnb3Zlcm5pbmcgaXRzIGN1cnJlbnQgbG9jYXRpb24uDQo+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIHRo cmVhdCBtb2RlbDwvRWQuIE5vdGU+DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gUC40 OiBUaGUgcHJvdG9jb2wgTVVTVCBwcm92aWRlIHRoZSBhYmlsaXR5IGZvciB0aGUgZGF0YWJhc2Ug dG8NCj4+Pj4+Pj4+IGF1dGhlbnRpY2F0ZSB0aGUgbWFzdGVyIGRldmljZS4NCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBQLjU6IFRoZSBwcm90b2NvbCBNVVNUIHByb3ZpZGUgdGhlIGFi aWxpdHkgZm9yIHRoZSBtYXN0ZXIgZGV2aWNlDQo+Pj4+Pj4+PnRvDQo+Pj4+Pj4+PiB2ZXJpZnkN Cj4+Pj4+Pj4+IHRoZSBhdXRoZW50aWNpdHkgb2YgdGhlIGRhdGFiYXNlIHdpdGggd2hpY2ggaXQg aXMgaW50ZXJhY3RpbmcuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gUC42OiBUaGUg bWVzc2FnZXMgc2VudCBieSB0aGUgbWFzdGVyIGRldmljZSB0byB0aGUgZGF0YWJhc2UgTVVTVA0K Pj4+Pj4+Pj5iZQ0KPj4+Pj4+Pj4gaW50ZWdyaXR5IHByb3RlY3RlZC4NCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4gDQo+Pj4+Pj4+PiBQLjc6IFRoZSBtZXNzYWdlcyBzZW50IGJ5IHRoZSBkYXRhYmFzZSB0 byB0aGUgbWFzdGVyIGRldmljZSBNVVNUDQo+Pj4+Pj4+PmJlDQo+Pj4+Pj4+PiBpbnRlZ3JpdHkg cHJvdGVjdGVkLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFAuODogVGhlIHByb3Rv Y29sIE1VU1QgcHJvdmlkZSB0aGUgY2FwYWJpbGl0eSBmb3IgbWVzc2FnZXMgc2VudCBieQ0KPj4+ Pj4+Pj4gdGhlDQo+Pj4+Pj4+PiBtYXN0ZXIgZGV2aWNlIGFuZCBkYXRhYmFzZSB0byBiZSBlbmNy eXB0ZWQuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQg dG8gcmVnaXN0cmF0aW9uIGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+Pj4+Pj4+IFAuOTogVGhlIHBy b3RvY29sIE1VU1Qgc3VwcG9ydCB0aGUgbWFzdGVyIGRldmljZSByZWdpc3RlcmluZyB3aXRoDQo+ Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+IGRhdGFiYXNlLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+IFAuMTA6IFRoZSByZWdpc3RyYXRpb24gc2lnbmFsaW5nIE1BWSBpbmNsdWRlIHRoZSBE ZXZpY2UgSUQsDQo+Pj4+Pj4+PiBtYW51ZmFjdHVyZXLCuXMNCj4+Pj4+Pj4+IHNlcmlhbCBudW1i ZXIsIGRldmljZSBsb2NhdGlvbiwgZGV2aWNlIGFudGVubmEgY2hhcmFjdGVyaXN0aWMNCj4+Pj4+ Pj4+IGluZm9ybWF0aW9uLA0KPj4+Pj4+Pj4gbmFtZSBvZiBpbmRpdmlkdWFsIG9yIGJ1c2luZXNz IHRoYXQgb3ducyB0aGUgZGV2aWNlLCBuYW1lLA0KPj4+Pj4+Pj5hZGRyZXNzLA0KPj4+Pj4+Pj4g ZW1haWwNCj4+Pj4+Pj4+IGFkZHJlc3MgYW5kIHBob25lIG51bWJlciBvZiBhIGNvbnRhY3QgcGVy c29uIHdobyBpcyByZXNwb25zaWJsZQ0KPj4+Pj4+Pj5mb3INCj4+Pj4+Pj4+IGRldmljZQ0KPj4+ Pj4+Pj4gb3BlcmF0aW9uLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFAuMTE6IFRo ZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSByZWdpc3RyYXRpb24gYWNrbm93bGVkZ2VtZW50DQo+ Pj4+Pj4+PiBpbmNsdWRpbmcNCj4+Pj4+Pj4+IGFwcHJvcHJpYXRlIHJlc3VsdCBjb2Rlcy4NCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gPEVkLiBO b3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGhvdHNwb3QgdXNlIGNhc2U8L0VkLiBOb3RlPg0K Pj4+Pj4+Pj4gUC4xMjogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhIGNoYW5uZWwgcXVlcnkg cmVxdWVzdCBmcm9tIHRoZQ0KPj4+Pj4+Pj4gbWFzdGVyDQo+Pj4+Pj4+PiBkZXZpY2UgdG8gdGhl IGRhdGFiYXNlLiBUaGUgY2hhbm5lbCBxdWVyeSByZXF1ZXN0IG1lc3NhZ2UgTVVTVA0KPj4+Pj4+ Pj4gaW5jbHVkZQ0KPj4+Pj4+Pj4gcGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1 bGF0b3J5IHJlcXVpcmVtZW50LiBUaGVzZQ0KPj4+Pj4+Pj4gcGFyYW1ldGVycw0KPj4+Pj4+Pj4g TUFZIGluY2x1ZGUgZGV2aWNlIGxvY2F0aW9uLCBkZXZpY2UgSUQsIG1hbnVmYWN0dXJlcsK5cyBz ZXJpYWwNCj4+Pj4+Pj4+IG51bWJlciwNCj4+Pj4+Pj4+IGFuZA0KPj4+Pj4+Pj4gYW50ZW5uYSBj aGFyYWN0ZXJpc3RpYyBpbmZvcm1hdGlvbi4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBQLjEzOiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgY2hhbm5lbCBxdWVyeSByZXNwb25z ZSBmcm9tIHRoZQ0KPj4+Pj4+Pj4gZGF0YWJhc2UNCj4+Pj4+Pj4+IHRvIHRoZSBtYXN0ZXIgZGV2 aWNlLiBUaGUgY2hhbm5lbCBxdWVyeSByZXNwb25zZSBtZXNzYWdlIE1VU1QNCj4+Pj4+Pj4+IGlu Y2x1ZGUNCj4+Pj4+Pj4+IHBhcmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9y eSByZXF1aXJlbWVudC4gVGhlc2UNCj4+Pj4+Pj4+IHBhcmFtZXRlcnMNCj4+Pj4+Pj4+IE1BWSBp bmNsdWRlIGF2YWlsYWJsZSBjaGFubmVscywgZHVyYXRpb24gb2YgdGltZSBmb3IgdGhlaXIgdXNl LA0KPj4+Pj4+Pj4gYXNzb2NpYXRlZA0KPj4+Pj4+Pj4gbWF4aW11bSBwb3dlciBsZXZlbHMsIGFu eSBhZGRpdGlvbmFsIHNlbnNpbmcgcmVxdWlyZW1lbnRzLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+IFAuMTQ6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5 IHJlcXVlc3QgZnJvbSB0aGUNCj4+Pj4+Pj4+IHNsYXZlDQo+Pj4+Pj4+PiBkZXZpY2UgdG8gdGhl IG1hc3RlciBkZXZpY2UuIFRoZSBjaGFubmVsIHF1ZXJ5IHJlcXVlc3QgbWVzc2FnZQ0KPj4+Pj4+ Pj5NVVNUDQo+Pj4+Pj4+PiBpbmNsdWRlIHBhcmFtZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwg cmVndWxhdG9yeSByZXF1aXJlbWVudC4NCj4+Pj4+Pj4+IFRoZXNlDQo+Pj4+Pj4+PiBwYXJhbWV0 ZXJzIE1BWSBpbmNsdWRlIGRldmljZSBJRCBhbmQgc2xhdmUgZGV2aWNlIGxvY2F0aW9uLg0KPj4+ Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFAuMTU6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBv cnQgYSB2YWxpZGF0aW9uIHJlcXVlc3QgZnJvbSB0aGUNCj4+Pj4+Pj4+bWFzdGVyDQo+Pj4+Pj4+ PiB0bw0KPj4+Pj4+Pj4gdGhlIGRhdGFiYXNlIHRvIHZhbGlkYXRlIGEgc2xhdmUgZGV2aWNlLiBU aGUgdmFsaWRhdGlvbiByZXF1ZXN0DQo+Pj4+Pj4+Pk1VU1QNCj4+Pj4+Pj4+IGluY2x1ZGUgdGhl IHNsYXZlIGRldmljZSBJRC4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBQLjE2OiBU aGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgdmFsaWRhdGlvbiByZXNwb25zZSBmcm9tIHRoZQ0K Pj4+Pj4+Pj4gZGF0YWJhc2UNCj4+Pj4+Pj4+IHRvDQo+Pj4+Pj4+PiB0aGUgbWFzdGVyLiBUaGUg dmFsaWRhdGlvbiByZXNwb25zZSBNVVNUIGluY2x1ZGUgYSByZXNwb25zZSBjb2RlLg0KPj4+Pj4+ Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFAuMTc6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQg YSBjaGFubmVsIHF1ZXJ5IHJlc3BvbnNlIGZyb20gdGhlDQo+Pj4+Pj4+PiBtYXN0ZXINCj4+Pj4+ Pj4+IGRldmljZSB0byB0aGUgc2xhdmUgZGV2aWNlLiBUaGUgY2hhbm5lbCBxdWVyeSByZXNwb25z ZSBtZXNzYWdlDQo+Pj4+Pj4+Pk1VU1QNCj4+Pj4+Pj4+IGluY2x1ZGUgcGFyYW1ldGVycyBhcyBy ZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVtZW50LA0KPj4+Pj4+Pj4gaW5jbHVk aW5nDQo+Pj4+Pj4+PiBhIHJlc3BvbnNlIGNvZGUgYW5kIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24g dG8gZGVjb2RlIGFuIGVuYWJsaW5nDQo+Pj4+Pj4+PiBzaWduYWwuDQo+Pj4+Pj4+PiANCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4gUC4xODogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhbiBlbmFibGlu ZyBzaWduYWwgc2VudCBmcm9tIHRoZQ0KPj4+Pj4+Pj4gbWFzdGVyDQo+Pj4+Pj4+PiB0bw0KPj4+ Pj4+Pj4gdGhlIHNsYXZlLiBUaGlzIHNpZ25hbCBNVVNUIGFsbG93IHRoZSBzbGF2ZSBkZXZpY2Ug dG8gdmFsaWRhdGUNCj4+Pj4+Pj4+dGhhdA0KPj4+Pj4+Pj4gYQ0KPj4+Pj4+Pj4gcHJldmlvdXNs eSByZWNlaXZlZCBhdmFpbGFibGUgY2hhbm5lbCBsaXN0IGlzIHN0aWxsIHZhbGlkIG9yIG5vdC4N Cj4+Pj4+Pj4+IFRoaXMNCj4+Pj4+Pj4+IHNpZ25hbCBNVVNUIGJlIGVuY29kZWQgdG8gYWxsb3cg dGhlIHNsYXZlIGRldmljZSB0byBkZXRlcm1pbmUgdGhlDQo+Pj4+Pj4+PiBpZGVudGl0eQ0KPj4+ Pj4+Pj4gaWYgdGhlIHNlbmRpbmcgbWFzdGVyIGRldmljZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFAuMTk6IFRoZSBwcm90b2NvbCBiZXR3ZWVuIHRoZSBtYXN0 ZXIgZGV2aWNlIGFuZCB0aGUgZGF0YWJhc2UgTVVTVA0KPj4+Pj4+Pj4gc3VwcG9ydA0KPj4+Pj4+ Pj4gdGhlIGNhcGFiaWxpdHkgdG8gY2hhbmdlIGNoYW5uZWwgYXZhaWxhYmlsaXR5IGxpc3RzIG9u IHNob3J0DQo+Pj4+Pj4+Pm5vdGljZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAN Cj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBtb2JpbGl0eSB1c2Ug Y2FzZTwvRWQuIE5vdGU+DQo+Pj4+Pj4+PiBQLjIwOiBUaGUgcHJvdG9jb2wgYmV0d2VlbiB0aGUg bWFzdGVyIGRldmljZSBhbmQgdGhlIGRhdGFiYXNlIE1VU1QNCj4+Pj4+Pj4+IHN1cHBvcnQNCj4+ Pj4+Pj4+IGEgY2hhbm5lbCBhdmFpbGFiaWxpdHkgcmVxdWVzdCB3aGljaCBzcGVjaWZpZXMgYSBn ZW9ncmFwaGljDQo+Pj4+Pj4+PmxvY2F0aW9uDQo+Pj4+Pj4+PiBhcw0KPj4+Pj4+Pj4gYW4NCj4+ Pj4+Pj4+IGFyZWEgYXMgd2VsbCBhcyBhIHBvaW50Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IE8uIE9wZXJhdGlvbmFsIFJl cXVpcmVtZW50czoNCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiA8RWQuIE5vdGU+cmVx dWlyZW1lbnRzIHJlbGF0ZWQgdG8gZGlzY292ZXJ5IGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4gTy4xOiBUaGUgZGF0YWJhc2UgYW5kIHRoZSBtYXN0ZXIgZGV2aWNlIE1V U1QgYmUgY29ubmVjdGVkIHRvIHRoZQ0KPj4+Pj4+Pj4gSW50ZXJuZXQuDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gTy4yOiAgQSBtYXN0ZXIgZGV2aWNlIE1VU1QgYmUgYWJsZSB0byBk ZXRlcm1pbmUgaXRzIGxvY2F0aW9uDQo+Pj4+Pj4+PiBpbmNsdWRpbmcNCj4+Pj4+Pj4+IHVuY2Vy dGFpbnR5IGFuZCBjb25maWRlbmNlIGxldmVsLiBBIGZpeGVkIG1hc3RlciBkZXZpY2UgTUFZIHVz ZSBhDQo+Pj4+Pj4+PiBsb2NhdGlvbg0KPj4+Pj4+Pj4gcHJvZ3JhbW1lZCBhdCBpbnN0YWxsYXRp b24gb3IgaGF2ZSB0aGUgY2FwYWJpbGl0eSBkZXRlcm1pbmUgaXRzDQo+Pj4+Pj4+PiBsb2NhdGlv bg0KPj4+Pj4+Pj4gdG8gdGhlIHJlcXVpcmVkIGFjY3VyYWN5LiBBIG1vYmlsZSBtYXN0ZXIgZGV2 aWNlIE1VU1QgaGF2ZSB0aGUNCj4+Pj4+Pj4+IGNhcGFiaWxpdHkNCj4+Pj4+Pj4+IHRvIGRldGVy bWluZSBpdHMgbG9jYXRpb24gdG8gdGhlIHJlcXVpcmVkIGFjY3VyYWN5Lg0KPj4+Pj4+Pj4gDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+IE8uMzogVGhlIG1hc3RlciBkZXZpY2UgTVVTVCBpZGVudGlmeSBh IGRhdGFiYXNlIGZvciB1c2UuIFRoZQ0KPj4+Pj4+Pj5tYXN0ZXINCj4+Pj4+Pj4+IGRldmljZQ0K Pj4+Pj4+Pj4gTUFZIHNlbGVjdCBhIGRhdGFiYXNlIGZvciBzZXJ2aWNlIGJ5IGRpc2NvdmVyeSBh dCBydW50aW1lIG9yIHRoZQ0KPj4+Pj4+Pj4gbWFzdGVyDQo+Pj4+Pj4+PiBkZXZpY2UgTUFZIHNl bGVjdCBhIGRhdGFiYXNlIGZvciBzZXJ2aWNlIGJ5IG1lYW5zIG9mIGENCj4+Pj4+Pj4+IHByZS1w cm9ncmFtbWVkDQo+Pj4+Pj4+PiBVUkkNCj4+Pj4+Pj4+IGFkZHJlc3MuDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gTy40OiBUaGUgbWFzdGVyIGRldmljZSBNVVNUIGltcGxlbWVudCBh dCBsZWFzdCBvbmUgY29ubmVjdGlvbg0KPj4+Pj4+Pj5tZXRob2QNCj4+Pj4+Pj4+IHRvDQo+Pj4+ Pj4+PiBhY2Nlc3MgdGhlIGRhdGFiYXNlLiBUaGUgbWFzdGVyIGRldmljZSBNQVkgY29udGFjdCBh IGRhdGFiYXNlDQo+Pj4+Pj4+PiBkaXJlY3RseQ0KPj4+Pj4+Pj4gZm9yDQo+Pj4+Pj4+PiBzZXJ2 aWNlIChlLmcuIGFzIGRlZmluZWQgYnkgRkNDKSBvciB0aGUgbWFzdGVyIGRldmljZSBNQVkgY29u dGFjdA0KPj4+Pj4+Pj5hDQo+Pj4+Pj4+PiBsaXN0aW5nIHNlcnZlciBmaXJzdCBmb2xsb3dlZCBi eSBjb250YWN0IHRvIGEgZGF0YWJhc2UgKGUuZy4gQXMNCj4+Pj4+Pj4+IGRlZmluZWQNCj4+Pj4+ Pj4+IGJ5DQo+Pj4+Pj4+PiBPZmNvbSkuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g Ty41OiBUaGUgbWFzdGVyIGRldmljZSBNVVNUIG9idGFpbiBhbiBpbmRpY2F0aW9uIHRoZSByZWd1 bGF0b3J5DQo+Pj4+Pj4+PiBkb21haW4NCj4+Pj4+Pj4+IGdvdmVybmluZyBvcGVyYXRpb24gYXQg aXRzIGN1cnJlbnQgbG9jYXRpb24sIGkuZS4gdGhlIG1hc3Rlcg0KPj4+Pj4+Pj5kZXZpY2UNCj4+ Pj4+Pj4+IE1VU1QNCj4+Pj4+Pj4+IGtub3cgaWYgaXQgb3BlcmF0ZXMgdW5kZXIgcmVndWxhdGlv bnMgZnJvbSBGQ0MsIE9mY29tLCBldGPFoA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8g cmVnaXN0cmF0aW9uIGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+Pj4+Pj4+IE8uNjogVGhlIG1hc3Rl ciBkZXZpY2UgTUFZIHJlZ2lzdGVyIHdpdGggdGhlIGRhdGFiYXNlIGFjY29yZGluZyB0bw0KPj4+ Pj4+Pj4gbG9jYWwNCj4+Pj4+Pj4+IHJlZ3VsYXRvcnkgcG9saWN5LiBOb3QgYWxsIG1hc3RlciBk ZXZpY2VzIHdpbGwgYmUgcmVxdWlyZWQgdG8NCj4+Pj4+Pj4+IHJlZ2lzdGVyLg0KPj4+Pj4+Pj4g U3BlY2lmaWMgZXZlbnRzIHdpbGwgaW5pdGlhdGUgcmVnaXN0cmF0aW9uLCB0aGVzZSBldmVudHMg YXJlDQo+Pj4+Pj4+PiBkZXRlcm1pbmVkDQo+Pj4+Pj4+PiBieQ0KPj4+Pj4+Pj4gcmVndWxhdG9y IHBvbGljeSAoZS5nLiBhdCBwb3dlciB1cCwgYWZ0ZXIgbW92ZW1lbnQsIGV0Y8WgKS4NCj4+Pj4+ Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBPLjc6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgcmVn aXN0ZXIgd2l0aCBpdHMgbW9zdCBjdXJyZW50IGFuZA0KPj4+Pj4+Pj4gdXAtdG8tZGF0ZQ0KPj4+ Pj4+Pj4gaW5mb3JtYXRpb24uDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBob3RzcG90 IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+Pj4+Pj4+IE8uODogQSBtYXN0ZXIgZGV2aWNlIE1VU1Qg cXVlcnkgdGhlIGRhdGFiYXNlIGZvciB0aGUgYXZhaWxhYmxlDQo+Pj4+Pj4+PiBjaGFubmVscw0K Pj4+Pj4+Pj4gYmFzZWQgb24gaXRzIGN1cnJlbnQgbG9jYXRpb24gYmVmb3JlIHN0YXJ0aW5nIHJh ZGlvIHRyYW5zbWlzc2lvbg0KPj4+Pj4+Pj5pbg0KPj4+Pj4+Pj4gd2hpdGUNCj4+Pj4+Pj4+IHNw YWNlLiBQYXJhbWV0ZXJzIHByb3ZpZGVkIHRvIHRoZSBkYXRhYmFzZSBNQVkgaW5jbHVkZSBkZXZp Y2UNCj4+Pj4+Pj4+IGxvY2F0aW9uLA0KPj4+Pj4+Pj4gYWNjdXJhY3kgb2YgdGhlIGxvY2F0aW9u LCBhbnRlbm5hIGNoYXJhY3RlcmlzdGljIGluZm9ybWF0aW9uLA0KPj4+Pj4+Pj5kZXZpY2UNCj4+ Pj4+Pj4+IGlkZW50aWZpZXIgb2YgYW55IHNsYXZlIGRldmljZSByZXF1ZXN0aW5nIGNoYW5uZWwg aW5mb3JtYXRpb24uDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gTy45OiBUaGUgZGF0 YWJhc2UgTVVTVCByZXNwb25kIHRvIGFuIGF2YWlsYWJsZSBjaGFubmVsIGxpc3QNCj4+Pj4+Pj4+ cmVxdWVzdA0KPj4+Pj4+Pj4gZnJvbQ0KPj4+Pj4+Pj4gYW4gYXV0aGVudGljYXRlZCBhbmQgYXV0 aG9yaXplZCBkZXZpY2UgYW5kIE1BWSBhbHNvIHByb3ZpZGUgdGltZQ0KPj4+Pj4+Pj4gY29uc3Ry YWludHMsIG1heGltdW0gb3V0cHV0IHBvd2VyLCBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcyBm b3INCj4+Pj4+Pj4+IGVhY2gNCj4+Pj4+Pj4+IGNoYW5uZWwgaW4gdGhlIGxpc3QgYW5kIGFueSBh ZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBmb3Igc2Vuc2luZy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g DQo+Pj4+Pj4+PiBPLjEwOiBBZnRlciBjb25uZWN0aW5nIHRvIGEgbWFzdGVyIGRldmljZcK5cyBy YWRpbyBuZXR3b3JrIGEgc2xhdmUNCj4+Pj4+Pj4+IGRldmljZQ0KPj4+Pj4+Pj4gTVVTVCBxdWVy eSB0aGUgbWFzdGVyIGRldmljZSBmb3IgYSBsaXN0IG9mIGF2YWlsYWJsZSBjaGFubmVscy4gVGhl DQo+Pj4+Pj4+PiBzbGF2ZQ0KPj4+Pj4+Pj4gTVVTVCBpbmNsdWRlIHBhcmFtZXRlcnMgcmVxdWly ZWQgYnkgbG9jYWwgcmVndWxhdG9yeSBwb2xpY3ksIGUuZy4NCj4+Pj4+Pj4+IGRldmljZQ0KPj4+ Pj4+Pj4gSUQsIGRldmljZSBsb2NhdGlvbi4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+ PiBPLjExOiBBY2NvcmRpbmcgdG8gbG9jYWwgcmVndWxhdG9yeSBwb2xpY3ksIHRoZSBtYXN0ZXIg ZGV2aWNlIE1BWQ0KPj4+Pj4+Pj4gcXVlcnkNCj4+Pj4+Pj4+IHRoZSBkYXRhYmFzZSB3aXRoIHBh cmFtZXRlcnMgcmVjZWl2ZWQgZnJvbSB0aGUgc2xhdmUgZGV2aWNlLg0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IE8uMTI6IFRoZSBkYXRhYmFzZSBNVVNUIHJlc3BvbmQgdG8gYSBxdWVy eSBmcm9tIHRoZSBtYXN0ZXIgZGV2aWNlDQo+Pj4+Pj4+PiBjb250YWluaW5nIHBhcmFtZXRlcnMg ZnJvbSBhIHNsYXZlIGRldmljZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBPLjEz OiBBZnRlciB0aGUgbWFzdGVyIGRldmljZSBoYXMgcmVjZWl2ZWQgYSByZXNwb25zZSBmcm9tIHRo ZQ0KPj4+Pj4+Pj4gZGF0YWJhc2UsDQo+Pj4+Pj4+PiB0aGUgbWFzdGVyIGRldmljZSBNVVNUIHJl c3BvbmQgdG8gdGhlIHNsYXZlIGRldmljZS4gSWYgYWxsDQo+Pj4+Pj4+PiByZWd1bGF0b3J5DQo+ Pj4+Pj4+PiByZXF1aXJlbWVudHMgYXJlIG1ldCB0aGUgcmVzcG9uc2Ugd2lsbCBjb250YWluIGFu IGF2YWlsYWJsZQ0KPj4+Pj4+Pj5jaGFubmVsDQo+Pj4+Pj4+PiBsaXN0Lg0KPj4+Pj4+Pj4gSWYg cmVndWxhdG9yeSByZXF1aXJlbWVudHMgYXJlIG5vdCBtZXQsIHRoZSByZXNwb25zZSBNVVNUIGNv bnRhaW4NCj4+Pj4+Pj4+YXQNCj4+Pj4+Pj4+IGxlYXN0DQo+Pj4+Pj4+PiBhIHJlc3BvbnNlIGNv ZGUuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gTy4xNDogSWYgYSBtYXN0ZXIgZGV2 aWNlIGhhcyBwcm92aWRlZCBhbiBhdmFpbGFibGUgY2hhbm5lbCBsaXN0DQo+Pj4+Pj4+PnRvIGEN Cj4+Pj4+Pj4+IHNsYXZlDQo+Pj4+Pj4+PiBkZXZpY2UgdGhlIG1hc3RlciBkZXZpY2UgTUFZIHNl bmQgYSBwZXJpb2RpYyBlbmFibGluZyBzaWduYWwgdG8NCj4+Pj4+Pj4+IGFsbG93DQo+Pj4+Pj4+ PiB0aGUNCj4+Pj4+Pj4+IHNsYXZlIGRldmljZSB0byBjb25maXJtIGl0IGlzIHN0aWxsIHdpdGhp biByZWNlcHRpb24gcmFuZ2Ugb2YgdGhlDQo+Pj4+Pj4+PiBtYXN0ZXINCj4+Pj4+Pj4+IGRldmlj ZS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBPLjE1OiBUaGUgZW5hYmxpbmcgc2ln bmFsIE1VU1QgYmUgZW5jb2RlZCBzbyB0aGF0IHRoZSByZWNlaXZpbmcNCj4+Pj4+Pj4+IHNsYXZl DQo+Pj4+Pj4+PiBjYW4NCj4+Pj4+Pj4+IGRldGVybWluZSB0aGUgaWRlbnRpdHkgb2YgdGhlIHNl bmRpbmcgbWFzdGVyLg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IE8uMTY6IFBlcmlv ZGljYWxseSwgYXQgYW4gaW50ZXJ2YWwgYWNjb3JkaW5nIHRvIGxvY2FsIHJlZ3VsYXRpb25zLA0K Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+PiBzbGF2ZSBkZXZpY2UgTVVTVCBlaXRoZXIgcmVjZWl2ZSBh bmQgZW5hYmxpbmcgc2lnbmFsIG9yIE1VU1QNCj4+Pj4+Pj4+IHN1Y2Nlc3NmdWxseQ0KPj4+Pj4+ Pj4gcmVwZWF0IHRoZSBjaGFubmVsIHJlcXVlc3QgcHJvY2VzcyBvciBNVVNUIGNlYXNlIHRyYW5z bWlzc2lvbiBvbg0KPj4+Pj4+Pj50aGUNCj4+Pj4+Pj4+IGNoYW5uZWwuDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4gTy4xNzogQSBtYXN0ZXIgZGV2aWNlIE1VU1QgcmVwZWF0IHRoZSBx dWVyeSB0aGUgZGF0YWJhc2UgZm9yIHRoZQ0KPj4+Pj4+Pj4gYXZhaWxhYmxlDQo+Pj4+Pj4+PiBj aGFubmVscyBhcyBvZnRlbiBhcyByZXF1aXJlZCBieSB0aGUgcmVndWxhdGlvbiAoZWcsIEZDQyBy ZXF1aXJlcw0KPj4+Pj4+Pj4gb25jZQ0KPj4+Pj4+Pj4gcGVyDQo+Pj4+Pj4+PiBkYXkpIHRvIHZl cmlmeSB0aGF0IHRoZSBvcGVyYXRpbmcgY2hhbm5lbHMgY29udGludWUgdG8gcmVtYWluDQo+Pj4+ Pj4+PiBhdmFpbGFibGUuDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gTy4xODogQSBt YXN0ZXIgZGV2aWNlIHdoaWNoIGNoYW5nZXMgaXRzIGxvY2F0aW9uIG1vcmUgdGhhbiBhDQo+Pj4+ Pj4+PiB0aHJlc2hvbGQNCj4+Pj4+Pj4+IGRpc3RhbmNlIHNwZWNpZmllZCBieSBsb2NhbCByZWd1 bGF0b3J5IHBvbGljeSBkdXJpbmcgaXRzDQo+Pj4+Pj4+Pm9wZXJhdGlvbiwNCj4+Pj4+Pj4+IE1V U1QNCj4+Pj4+Pj4+IHF1ZXJ5IHRoZSBkYXRhYmFzZSBmb3IgYXZhaWxhYmxlIG9wZXJhdGluZyBj aGFubmVscyBlYWNoIHRpbWUgaXQNCj4+Pj4+Pj4+IG1vdmVzDQo+Pj4+Pj4+PiBtb3JlIHRoYW4g dGhlIHRocmVzaG9sZCBkaXN0YW5jZSAoZS5nLiwgRkNDIHNwZWNpZmllcyAxMDBtKSBmcm9tDQo+ Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4gbG9jYXRpb24gaXQgcHJldmlvdXNseSBtYWRlIHRoZSBxdWVy eS4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IDxFZC4gTm90ZT5y ZXF1aXJlbWVudHMgcmVsYXRlZCB0byB3cmFuIHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+Pj4+Pj4+ IE8uMTk6IElmIHNsYXZlIGRldmljZXMgY2hhbmdlIHRoZWlyIGxvY2F0aW9uIGR1cmluZyBvcGVy YXRpb24gYnkNCj4+Pj4+Pj4+IG1vcmUNCj4+Pj4+Pj4+IHRoYW4NCj4+Pj4+Pj4+IGEgbGltaXQg c3BlY2lmaWVkIGJ5IHRoZSBsb2NhbCByZWd1bGF0b3IsIHRoZSBzbGF2ZSBkZXZpY2UgTVVTVA0K Pj4+Pj4+Pj4gcXVlcnkNCj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4gbWFzdGVyIGRldmljZSBmb3Ig YXZhaWxhYmxlIG9wZXJhdGluZyBjaGFubmVscy4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byByYXBpZCBk ZXBsb3llZCBuZXR3b3JrIHVzZQ0KPj4+Pj4+Pj4gY2FzZTwvRWQuDQo+Pj4+Pj4+PiBOb3RlPg0K Pj4+Pj4+Pj4gTy4yMDogQWNjb3JkaW5nIHRvIGxvY2FsIHJlZ3VsYXRvciBwb2xpY3ksIGEgbWFz dGVyIGRldmljZSBtYXkNCj4+Pj4+Pj4+IGNvbnRhY3QgYQ0KPj4+Pj4+Pj4gZGF0YWJhc2Ugdmlh IHByb3h5IHNlcnZpY2Ugb2YgYW5vdGhlciBtYXN0ZXIgZGV2aWNlLg0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVk IHRvIG1vYmlsaXR5IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+Pj4+Pj4+IE8uMjE6IEEgbWFzdGVy IGRldmljZSBNVVNUIGJlIGFibGUgdG8gcXVlcnkgdGhlIHdoaXRlc3BhY2UNCj4+Pj4+Pj4+ZGF0 YWJhc2UNCj4+Pj4+Pj4+IGZvcg0KPj4+Pj4+Pj4gY2hhbm5lbCBhdmFpbGFiaWxpdHkgaW5mb3Jt YXRpb24gZm9yIGEgc3BlY2lmaWMgZXhwZWN0ZWQgY292ZXJhZ2UNCj4+Pj4+Pj4+IGFyZWENCj4+ Pj4+Pj4+IGFyb3VuZCBpdHMgY3VycmVudCBsb2NhdGlvbi4NCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4g DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byB0 aHJlYXQgbW9kZWw8L0VkLiBOb3RlPg0KPj4+Pj4+Pj4gTy4yMjogQSBNYXN0ZXIgZGV2aWNlIE1B WSBub3QgaW5jbHVkZSBpdHMgaWRlbnRpdHkgaW4NCj4+Pj4+Pj4+IG1lc3NhZ2VzIHNlbnQgdG8g dGhlIGRhdGFiYXNlIHdoZW4gbm90IHJlcXVpcmVkIGJ5IHRoZSByZWd1bGF0b3J5DQo+Pj4+Pj4+ PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gcGF3cyBtYWlsaW5nIGxpc3QNCj4+ Pj4+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGF3cw0KPj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+IA0KPj4+PiANCj4+PiAN Cj4+IA0KPg0KDQo= From scott.probasco@nokia.com Mon Feb 27 14:08:45 2012 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 414DA21E8029 for ; Mon, 27 Feb 2012 14:08:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.303 X-Spam-Level: X-Spam-Status: No, score=-4.303 tagged_above=-999 required=5 tests=[AWL=1.696, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUjFKFofbk3h for ; Mon, 27 Feb 2012 14:08:43 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id E14C321E8025 for ; Mon, 27 Feb 2012 14:08:42 -0800 (PST) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1RM8fnf008646; Tue, 28 Feb 2012 00:08:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.26]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 00:08:40 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-010.mgdnok.nokia.com ([65.54.30.26]) with mapi id 14.01.0355.003; Mon, 27 Feb 2012 23:08:40 +0100 From: To: Thread-Topic: [paws] UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZIdjEAgAN/KwCAA7asgIAApSwAgADX9ID//6FlgIAAcywA//+jugA= Date: Mon, 27 Feb 2012 22:08:38 +0000 Message-ID: In-Reply-To: <2EF37C85-94DC-406C-912B-7118FED4B0C8@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.243.0.216] Content-Type: text/plain; charset="utf-8" Content-ID: <94B6D236543DB0439516E8E6AD759599@mgd.nokia.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Feb 2012 22:08:40.0948 (UTC) FILETIME=[5CEA8B40:01CCF59C] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] UC&R I-D: Requirements 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: Mon, 27 Feb 2012 22:08:45 -0000 SGkgQnJpYW4sDQoNCkkgYWdyZWUgd2Ugc2hvdWxkIGJlIGZsZXhpYmxlIGVub3VnaCB0byBzZW5k IGRldmljZSBpbmZvcm1hdGlvbiB3aXRoIHRoZQ0Kc3BlY3RydW0gcXVlcnkgd2hlbiByZXF1ZXN0 ZWQgYnkgdGhlIGxvY2FsIHJlZ3VsYXRvci4gRG9lcyBQLjEyIGFkZHJlc3MNCnRoaXMgYWNjdXJh dGVseT8NCg0KS2luZCBSZWdhcmRzLA0KU2NvdHQNCg0KDQoNCk9uIDIvMjcvMTIgMzozOCBQTSwg ImV4dCBSb3NlbiwgQnJpYW4iIDxCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpej4gd3JvdGU6DQoNCj48 YXMgaW5kaXZpZHVhbD4NCj5JIGhhdmUgYSBzbWFsbCBpc3N1ZSBoZXJlLg0KPg0KPkRldmljZSBj aGFyYWN0ZXJpc3RpY3MgZG9uJ3QgdHlwaWNhbGx5IGNoYW5nZSwgc28gaGF2aW5nIHRoZW0gaW4g c29tZQ0KPmZvcm0gb2YgcmVnaXN0cmF0aW9uIHRyYW5zYWN0aW9uIG1ha2VzIHNlbnNlIGluIGFu IGVuZ2luZWVyaW5nIHNlbnNlLg0KPkhvd2V2ZXIsIHNvbWUgcmVndWxhdG9ycyBkb24ndCBzZWVt IHRvIHVuZGVyc3RhbmQgdGhhdCwgYW5kIHRoZXJlIGFyZQ0KPmNpcmN1bXN0YW5jZXMgd2hlcmUg eW91IGhhdmUgdG8gc2VuZCBzb21lIG9mIHRoZSBkZXZpY2UgaW5mb3JtYXRpb24gd2l0aA0KPnRo ZSBzcGVjdHJ1bSBxdWVyeS4gIFdlIHNob3VsZCBiZSBmbGV4aWJsZSBlbm91Z2ggdG8gaGFuZGxl IHRoYXQuDQo+DQo+QnJpYW4NCj4NCj5PbiBGZWIgMjcsIDIwMTIsIGF0IDM6NDYgUE0sIDxzY290 dC5wcm9iYXNjb0Bub2tpYS5jb20+DQo+PHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbT4gd3JvdGU6 DQo+DQo+PiBIaSBUZWNvLA0KPj4NCj4+IFdlIGNvdWxkIGNoYW5nZSBPLjcgdG8gc29tZXRoaW5n IGxpa2U6DQo+Pg0KPj4gTy43OiBUaGUgbWFzdGVyIGRldmljZSBNVVNUIHJlZ2lzdGVyIHdpdGgg aXRzIG1vc3QgY3VycmVudCBhbmQNCj4+dXAtdG8tZGF0ZQ0KPj4gaW5mb3JtYXRpb24sIGFuZCBN VVNUIGluY2x1ZGUgYWxsIHZhcmlhYmxlcyBtYW5kYXRlZCBieSBsb2NhbCByZWd1bGF0b3INCj4+ IHBvbGljeS4NCj4+DQo+PiBXb3VsZCB0aGlzIHdvcms/DQo+Pg0KPj4gS2luZCBSZWdhcmRzLA0K Pj4gU2NvdHQNCj4+DQo+Pg0KPj4NCj4+IE9uIDIvMjcvMTIgMjoyNSBQTSwgImV4dCBUZWNvIEJv b3QiIDx0ZWNvQGluZi1uZXQubmw+IHdyb3RlOg0KPj4NCj4+PiBIZWxsbyBTY290dCwNCj4+Pg0K Pj4+IEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50LiBCdXQgSSB3YW50IHRvIGtlZXAgdGhpbmdzIHNp bXBsZS4gVGhlDQo+Pj4gUC4qIHJlcXVpcmVtZW50cyBhcmUgZm9yIHRoZSBwcm90b2NvbCwgaXQg TVVTVCBzdXBwb3J0IG9wdGlvbmFsDQo+Pj4gdmFyaWFibGVzLg0KPj4+IFRoZSBPLiogcmVxdWly ZW1lbnRzIGV4cGxhaW4gaG93IHRoZXNlIGFyZSB1c2VkLiBUaGlzIGlzIHRoZSBNQVksDQo+Pj4g cmlnaHQ/DQo+Pj4NCj4+PiBIYXZpbmcgcGVyZm9ybWVkIHNvbWUgdGVzdHMgdG9kYXkgd2l0aCBh biBlbWVyZ2VuY3kgcmVzcG9uZGVycw0KPj4+IG5ldHdvcmssIEkgc2F3IHNvbWUgaGlnaCB0cmFm ZmljIGxvYWQuIFNvbWV0aGluZyBsaWtlIHRoaXM6DQo+Pj4gICAgPHNlbGZfZXhwbGFpbmluZ192 YXJpYWJsZV9uYW1lPg0KPj4+ICAgICAgICAxDQo+Pj4gICAgPFxzZWxmX2V4cGxhaW5pbmdfdmFy aWFibGVfbmFtZT4NCj4+PiBJIGNvdWxkIHRoaW5rIG9mIGFuIGVmZmljaWVuY3kgcmVxdWlyZW1l bnQsIGZvciB0aGUgcmFwaWQgZGVwbG95ZWQNCj4+PiBuZXR3b3JrIHVzZSBjYXNlLg0KPj4+DQo+ Pj4gVGhhbmtzLCBUZWNvDQo+Pj4NCj4+Pg0KPj4+IE9wIDI3IGZlYi4gMjAxMiwgb20gMTQ6MzIg aGVlZnQgPHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbT4NCj4+PiA8c2NvdHQucHJvYmFzY29Abm9r aWEuY29tPiBoZXQgdm9sZ2VuZGUgZ2VzY2hyZXZlbjoNCj4+Pg0KPj4+PiBIaSBUZWNvLA0KPj4+ Pg0KPj4+PiBJZiB3ZSBsb29rIGF0IFAuOSBhbmQgUC4xMCB0b2dldGhlciwgUC45IHNheXMgdGhh dCByZWdpc3RyYXRpb24gaXMgYQ0KPj4+PiBNVVNUDQo+Pj4+IC0tIHRoZSBwcm90b2NvbCBzdXBw b3J0cyByZWdpc3RyYXRpb24gd2l0aG91dCBxdWVzdGlvbi4gUC4xMCBzYXlzIHRoZQ0KPj4+PiBz aWduYWxpbmcgZm9yIHJlZ2lzdHJhdGlvbiBNQVkgY29udGFpbiBhbnkgb2Ygc2V2ZXJhbCB2YXJp YWJsZXMgKGFsc28NCj4+Pj4gYWxsb3dzIG1vcmUgdmFyaWFibGVzIHRvIGJlIGluY2x1ZGVkIGlm IHJlcXVpcmVkIGJ5IGxvY2FsDQo+Pj4+cmVndWxhdGlvbnMpLg0KPj4+PiBUaGUgbGlzdCBjdXJy ZW50bHkgaWRlbnRpZmllcyBhbGwgdmFyaWFibGVzIHJlcXVpcmVkIGZvciByZWdpc3RyYXRpb24N Cj4+Pj5pbg0KPj4+PiB0aGUgVVMuIE5vdyBpZiB3ZSBsb29rIGF0IHRoZSBEYXRhIE1vZGVsIHJl cXVpcmVtZW50cywgZWFjaCB2YXJpYWJsZQ0KPj4+PiBpZGVudGlmaWVkIHRoYXQgdGhlIHJlZ2lz dHJhdGlvbiBzZXJ2aWNlIE1BWSBjb250YWluICh0aGVzZSBhcmUgaW4NCj4+Pj5ELjUsDQo+Pj4+ IEQuNiwgRC4xLCBELjcgYW5kIEQuOCkgTVVTVCBiZSBpbmNsdWRlZCBpbiB0aGUgRGF0YSBNb2Rl bC4gVGhlDQo+Pj4+cHJvdG9jb2wNCj4+Pj4gTVVTVCBzdXBwb3J0IHJlZ2lzdHJhdGlvbiwgYW5k IHRoZSBEYXRhIE1vZGVsIGluIHRoZSBwcm90b2NvbCBNVVNUDQo+Pj4+IHN1cHBvcnQNCj4+Pj4g dGhlIHZhcmlhYmxlcyBpZGVudGlmaWVkIGZvciByZWdpc3RyYXRpb24gc2VydmljZS4NCj4+Pj4N Cj4+Pj4gVGhlIGN1cnJlbnQgdXNlIG9mIE1VU1QgaW4gUC45IGFuZCBNQVkgaW4gUC4xMCBoYXMg dGhlIGVmZmVjdCB0aGF0DQo+Pj4+V1NEcw0KPj4+PiBpbg0KPj4+PiB0aGUgVVMgYXJlIGFsbG93 ZWQgdG8gcmVnaXN0ZXIgKGJlY2F1c2UgdGhlIHByb3RvY29sIHN1cHBvcnRzDQo+Pj4+IHJlZ2lz dHJhdGlvbikgYW5kIGFyZSBhbGxvd2VkIHRvIHVzZSB0aGUgdmFyaWFibGVzIGRlZmluZWQgYnkg dGhlIEZDQw0KPj4+PiAoYmVjYXVzZSB0aGUgcmVnaXN0cmF0aW9uIHNpZ25hbGluZyBNQVkgaW5j bHVkZSB0aG9zZSB2YXJpYWJsZXMpLiBUaGlzDQo+Pj4+IGFsc28gaGFzIHRoZSBlZmZlY3QgdGhh dCBXU0RzIGluIHRoZSBVSyAob3IgZWxzZXdoZXJlIGluIHRoZSB3b3JsZCkNCj4+Pj5hcmUNCj4+ Pj4gYWxsb3dlZCB0byByZWdpc3RlciBpZiB0aGlzIGlzIGEgbG9jYWwgcmVxdWlyZW1lbnQgKGJl Y2F1c2UgdGhlDQo+Pj4+cHJvdG9jb2wNCj4+Pj4gc3VwcG9ydHMgcmVnaXN0cmF0aW9uKSBhbmQg YXJlIGFsbG93ZWQgdG8gdXNlIChvciBub3QgdXNlKSB0aGUNCj4+Pj52YXJpYWJsZXMNCj4+Pj4g ZGVmaW5lZCBieSB0aGUgRkNDIChiZWNhdXNlIHRoZSByZWdpc3RyYXRpb24gc2lnbmFsaW5nIE1B WSBpbmNsdWRlDQo+Pj4+dGhvc2UNCj4+Pj4gdmFyaWFibGVzKS4gTm90aGluZyB0byBwcmV2ZW50 IGFkZGluZyBtb3JlIHZhcmlhYmxlcyBpZiBuZWVkZWQgYnkNCj4+Pj5PZmNvbSwNCj4+Pj4gSURB LCBldGMuLi4NCj4+Pj4NCj4+Pj4gQW5vdGhlciBwb3NzaWJpbGl0eSBpcyB0byBjaGFuZ2UgdGhl IHdvcmRpbmcgb2YgUC4xMCB0byByZWFkDQo+Pj4+IFAuMTA6IFRoZSByZWdpc3RyYXRpb24gc2ln bmFsaW5nIE1VU1QgaW5jbHVkZSB0aGUgZm9sbG93aW5nIG9wdGlvbmFsDQo+Pj4+IHZhcmlhYmxl czogdGhlIERldmljZSBJRCwgbWFudWZhY3R1cmVywrlzIHNlcmlhbCBudW1iZXIsIGRldmljZQ0K Pj4+PmxvY2F0aW9uLA0KPj4+PiBkZXZpY2UgYW50ZW5uYSBjaGFyYWN0ZXJpc3RpYyBpbmZvcm1h dGlvbiwgbmFtZSBvZiBpbmRpdmlkdWFsIG9yDQo+Pj4+IGJ1c2luZXNzDQo+Pj4+IHRoYXQgb3du cyB0aGUgZGV2aWNlLCBuYW1lLCBhZGRyZXNzLCBlbWFpbCBhZGRyZXNzIGFuZCBwaG9uZSBudW1i ZXINCj4+Pj5vZiBhDQo+Pj4+IGNvbnRhY3QgcGVyc29uIHdobyBpcyByZXNwb25zaWJsZSBmb3Ig ZGV2aWNlIG9wZXJhdGlvbi4NCj4+Pj4NCj4+Pj4gV2hhdCBkbyB5b3UgdGhpbms/DQo+Pj4+DQo+ Pj4+IEtpbmQgUmVnYXJkcywNCj4+Pj4gU2NvdHQNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pj4NCj4+Pj4gT24gMi8yNi8xMiAzOjQxIFBNLCAiZXh0IFRlY28gQm9vdCIgPHRlY29A aW5mLW5ldC5ubD4gd3JvdGU6DQo+Pj4+DQo+Pj4+PiBIaSBTY290dCwNCj4+Pj4+DQo+Pj4+PiBJ IHN0aWxsIHRoaW5rIGl0IGlzIGEgTVVTVCBmb3IgdGhlIHByb3RvY29sLCBhbmQgYSBNQVkgZm9y IHVzYWdlLg0KPj4+Pj4NCj4+Pj4+IFRoYW5rcywgVGVjbw0KPj4+Pj4NCj4+Pj4+IE9wIDI0IGZl Yi4gMjAxMiwgb20gMTk6NTggaGVlZnQgPHNjb3R0LnByb2Jhc2NvQG5va2lhLmNvbT4NCj4+Pj4+ IDxzY290dC5wcm9iYXNjb0Bub2tpYS5jb20+IGhldCB2b2xnZW5kZSBnZXNjaHJldmVuOg0KPj4+ Pj4NCj4+Pj4+PiBIZWxsbyBUZWNvLA0KPj4+Pj4+DQo+Pj4+Pj4gU2luY2UgUEFXUyBpcyBhIGds b2JhbCBzdGFuZGFyZCwgcmVnaXN0cmF0aW9uIGZvciBhbGwgcmVndWxhdG9yeQ0KPj4+Pj4+IGRv bWFpbnMNCj4+Pj4+PiBtdXN0IGJlIHN1cHBvcnRlZC4gV2hpbGUgdGhlIEZDQyBkb2VzIHJlcXVp cmUgYWxsIG9mIHRoZSB2YXJpYWJsZXMNCj4+Pj4+PiBsaXN0ZWQNCj4+Pj4+PiBpbiBQLjEwLCBv dGhlciByZWd1bGF0b3J5IGRvbWFpbnMgbWF5IG5vdCByZXF1aXJlIGVhY2ggb2YgdGhvc2UNCj4+ Pj4+PiB2YXJpYWJsZXMuDQo+Pj4+Pj4gU28gZm9yIHJlcXVpcmVtZW50cyBvbiB0aGUgcHJvdG9j b2wsIHVzaW5nIE1BWSBlbmFibGVzIHRoZSBGQ0MgdG8NCj4+Pj4+PiByZXF1aXJlDQo+Pj4+Pj4g dGhlc2UgdmFyaWFibGVzIHdoaWxlIGFsbG93aW5nIG90aGVyIHJlZ3VsYXRvcnMgdG8gc2VsZWN0 IGEgc3Vic2V0LA0KPj4+Pj4+b3INCj4+Pj4+PiBldmVuIGRpZmZlcmVudCwgdmFyaWFibGVzLg0K Pj4+Pj4+DQo+Pj4+Pj4gV2l0aCB0aGlzIGV4cGxhbmF0aW9uLCBhcmUgeW91IG9rYXkgd2l0aCBN QVkgaW4gUC4xMD8NCj4+Pj4+Pg0KPj4+Pj4+IEtpbmQgUmVnYXJkcywNCj4+Pj4+PiBTY290dA0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IE9uIDIvMjIvMTIgMTozNCBBTSwgImV4dCBU ZWNvIEJvb3QiIDx0ZWNvQGluZi1uZXQubmw+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4+IFNjb3R0 LCBSYXksDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoZSBQLiogYXJlIG1vc3RseSBNVVNUIHJlcXVpcmVt ZW50cyBmb3IgdGhlIHByb3RvY29sLiBUaGF0J3MgZmluZS4NCj4+Pj4+Pj4gRXhjZXB0IFAuMTAs IHRoaXMgaXMgYSBNQVkgb3BlcmF0aW9uYWwgcmVxdWlyZW1lbnQuIFRoZSBwcm90b2NvbA0KPj4+ Pj4+PiBNVVNUIHN1cHBvcnQgaXQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IEknbSBmaW5lIHdpdGggdGhl IHJlc3Qgb2YgaXQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IElzIG5vdGVkIHNvbWV3aGVyZSB0aGF0IHdl IChJRVRGKSBkbyBvdXIgYmVzdCB0byBzdXBwb3J0IGFzIG1hbnkNCj4+Pj4+Pj4gcmVndWxhdG9y IHJ1bGVzIGFzIHBvc3NpYmxlLCBhbmQgbGVhdmUgc2V0dGluZyB1cCByZXF1aXJlbWVudHMgZm9y DQo+Pj4+Pj4+IGFjdHVhbCBkZXBsb3ltZW50IHVwIHRvIHRoZSBtYW5kYXRlZCBhdXRob3JpdGll cz8gVGhpcyBtYWtlcyB0aGUNCj4+Pj4+Pj4gTy4qIHJlcXVpcmVtZW50cyBpbmZvcm1hdGlvbmFs Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUaGFua3MsIFRlY28NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4gT3AgMjIgZmViLiAyMDEyLCBvbSAwMDo1MyBoZWVmdCA8c2NvdHQucHJvYmFzY29Abm9raWEu Y29tPg0KPj4+Pj4+PiA8c2NvdHQucHJvYmFzY29Abm9raWEuY29tPiBoZXQgdm9sZ2VuZGUgZ2Vz Y2hyZXZlbjoNCj4+Pj4+Pj4NCj4+Pj4+Pj4+IEhlbGxvIEFsbCwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+ PiBJIGhhdmUgcmV2aXNlZCBTZWN0aW9uIDYgb2YgdGhlIEktRCB3aGljaCBkZXNjcmliZXMgdGhl IERhdGEgTW9kZWwNCj4+Pj4+Pj4+IFJlcXVpcmVtZW50cywgUHJvdG9jb2wgUmVxdWlyZW1lbnRz IGFuZCBPcGVyYXRpb25hbCBSZXF1aXJlbWVudHMuDQo+Pj4+Pj4+PiBUaGlzDQo+Pj4+Pj4+PiBp bmNsdWRlcyB0aGUgcmVxdWlyZW1lbnRzIGZyb20gdGhlIHRocmVhdCBtb2RlbA0KPj4+Pj4+Pj4g KGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9wYXdzL2N1cnJlbnQvbXNnMDA3 NzEuaHRtbCkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVGhlIHJlcXVpcmVtZW50cyBhcmUgb3JkZXJl ZCAidG9wIGRvd24iIHRvIGZvbGxvdyB0aGUgcHJldmlvdXMNCj4+Pj4+Pj4+IHNlY3Rpb25zDQo+ Pj4+Pj4+PiBvZg0KPj4+Pj4+Pj4gdGhlIGRvY3VtZW50OiByZXF1aXJlbWVudHMgZGVyaXZlZCBm cm9tIGRpc2NvdmVyeSBhcmUgZm9sbG93ZWQgYnkNCj4+Pj4+Pj4+IHJlcXVpcmVtZW50cyBkZXJp dmVkIGZyb20gcmVnaXN0cmF0aW9uIGFyZSBmb2xsb3dlZCBieQ0KPj4+Pj4+Pj5yZXF1aXJlbWVu dHMNCj4+Pj4+Pj4+IGRlcml2ZWQgZnJvbSBob3RzcG90LCBldGMuLi4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiBQbGVhc2UgcmV2aWV3IHRoZSBwcm9wb3NlZCB0ZXh0LCB3ZSBob3BlIHRvIGhhdmUgeW91 ciBjb21tZW50cyBieQ0KPj4+Pj4+Pj4gRmViDQo+Pj4+Pj4+PiAyOHRoLg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IEtpbmQgUmVnYXJkcywNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBSYWogJiBTY290dA0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEQuIERhdGEgTW9k ZWwgUmVxdWlyZW1lbnRzOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiA8RWQuIE5vdGU+ cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gZGlzY292ZXJ5IGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+ Pj4+Pj4+IEQuMTogVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlpbmcgdGhlIGxv Y2F0aW9uIG9mIHRoZQ0KPj4+Pj4+Pj5XU0QsDQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+IHVuY2Vy dGFpbnR5IGluIG1ldGVycywgdGhlIGhlaWdodCAmIGl0cyB1bmNlcnRhaW50eSwgYW5kDQo+Pj4+ Pj4+PmNvbmZpZGVuY2UNCj4+Pj4+Pj4+IGluDQo+Pj4+Pj4+PiBwZXJjZW50YWdlIGZvciB0aGUg bG9jYXRpb24gZGV0ZXJtaW5hdGlvbi4gVGhlIERhdGEgTW9kZWwgTVVTVA0KPj4+Pj4+Pj4gc3Vw cG9ydA0KPj4+Pj4+Pj4gYm90aCBOb3J0aCBBbWVyaWNhbiBEYXR1bSBvZiAxOTgzIGFuZCBXR1M4 NC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRC4yOiBUaGUgRGF0YSBNb2RlbCBNVVNU IHN1cHBvcnQgc3BlY2lmeWluZyB0aGUgVVJJIGFkZHJlc3Mgb2YgYQ0KPj4+Pj4+Pj4gd2hpdGUN Cj4+Pj4+Pj4+IHNwYWNlIGRhdGFiYXNlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBE LjM6IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIHRoZSBVUkkgYWRkcmVz cyBvZiBhDQo+Pj4+Pj4+PiBuYXRpb25hbA0KPj4+Pj4+Pj4gbGlzdGluZyBzZXJ2aWNlLg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBELjQ6IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9y dCBzcGVjaWZ5aW5nICByZWd1bGF0b3J5IGRvbWFpbiBhbmQNCj4+Pj4+Pj4+IGl0cw0KPj4+Pj4+ Pj4gY29ycmVzcG9uZGluZyBkYXRhIHJlcXVpcmVtZW50cy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byByZWdp c3RyYXRpb24gZnVuY3Rpb248L0VkLiBOb3RlPg0KPj4+Pj4+Pj4gRC41OiBUaGUgRGF0YSBNb2Rl bCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBhbiBJRCBvZiB0aGUNCj4+Pj4+Pj4+dHJhbnNtaXR0 ZXINCj4+Pj4+Pj4+IGRldmljZS4gVGhpcyBJRCB3b3VsZCBjb250YWluIHRoZSBJRCBvZiB0aGUg dHJhbnNtaXR0ZXIgZGV2aWNlDQo+Pj4+Pj4+PnRoYXQNCj4+Pj4+Pj4+IGhhcw0KPj4+Pj4+Pj4g YmVlbiBjZXJ0aWZpZWQgYnkgYSByZWd1bGF0b3J5IGJvZHkgZm9yIGl0cyByZWd1bGF0b3J5IGRv bWFpbi4gVGhlDQo+Pj4+Pj4+PiBEYXRhDQo+Pj4+Pj4+PiBNb2RlbCBNVVNUIHN1cHBvcnQgYSBk ZXZpY2UgY2xhc3MuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBELjY6 IFRoZSBEYXRhIE1vZGVsIE1VU1Qgc3VwcG9ydCBzcGVjaWZ5aW5nIGEgbWFudWZhY3R1cmVywrlz DQo+Pj4+Pj4+PnNlcmlhbA0KPj4+Pj4+Pj4gbnVtYmVyDQo+Pj4+Pj4+PiBmb3IgYSBtYXN0ZXIg ZGV2aWNlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBELjc6ICBUaGUgRGF0YSBNb2Rl bCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyB0aGUgYW50ZW5uYSBhbmQNCj4+Pj4+Pj4+IHJhZGlh dGlvbg0KPj4+Pj4+Pj4gcmVsYXRlZCBwYXJhbWV0ZXJzIG9mIHRoZSBkZXZpY2UsIHN1Y2ggYXM6 DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLSBhbnRlbm5hIGhlaWdodA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IC0gYW50ZW5uYSBnYWluDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gLSBtYXhpbXVtIG91dHB1dCBwb3dl ciwgRUlSUCAoZEJtKQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IC0gYW50ZW5uYSByYWRpYXRpb24gcGF0 dGVybiAoZGlyZWN0aW9uYWwgZGVwZW5kZW5jZQ0KPj4+Pj4+Pj4gIG9mIHRoZSBzdHJlbmd0aCBv ZiB0aGUgcmFkaW8gc2lnbmFsIGZyb20gdGhlIGFudGVubmEpDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g LSBzcGVjdHJ1bSBtYXNrIHdpdGggbG93ZXN0IGFuZCBoaWdoZXN0IHBvc3NpYmxlIGZyZXF1ZW5j eQ0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IC0gc3BlY3RydW0gbWFzayBpbiBkQnIgZnJvbSBwZWFrIHRy YW5zbWl0IHBvd2VyIGluIEVJUlAsDQo+Pj4+Pj4+PiAgd2l0aCBzcGVjaWZpYyBwb3dlciBsaW1p dCBhdCBhbnkgZnJlcXVlbmN5IGxpbmVhcmx5DQo+Pj4+Pj4+PiAgaW50ZXJwb2xhdGVkIGJldHdl ZW4gYWRqYWNlbnQgcG9pbnRzIG9mIHRoZSBzcGVjdHJ1bSBtYXNrDQo+Pj4+Pj4+PiAgbWVhc3Vy ZW1lbnQgcmVzb2x1dGlvbiBiYW5kd2lkdGggZm9yIEVJUlAgbWVhc3VyZW1lbnRzLg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRC44OiBUaGUgRGF0YSBNb2RlbCBNVVNU IHN1cHBvcnQgc3BlY2lmeWluZyBvd25lciBhbmQgb3BlcmF0b3INCj4+Pj4+Pj4+IGNvbnRhY3QN Cj4+Pj4+Pj4+IGluZm9ybWF0aW9uIGZvciBhIHRyYW5zbWl0dGVyLiBUaGlzIGluY2x1ZGVzIHRo ZSBuYW1lIG9mIHRoZQ0KPj4+Pj4+Pj4gdHJhbnNtaXR0ZXINCj4+Pj4+Pj4+IG93bmVyLCBuYW1l IG9mIHRyYW5zbWl0dGVyIG9wZXJhdG9yLCBwb3N0YWwgYWRkcmVzcywgZW1haWwgYWRkcmVzcw0K Pj4+Pj4+Pj4gYW5kDQo+Pj4+Pj4+PiBwaG9uZSBudW1iZXIgb2YgdGhlIHRyYW5zbWl0dGVyIG9w ZXJhdG9yLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byBob3RzcG90IHVzZSBjYXNlPC9FZC4g Tm90ZT4NCj4+Pj4+Pj4+IEQuOTogVGhlIERhdGEgTW9kZWwgTVVTVCBzdXBwb3J0IHNwZWNpZnlp bmcgYSBsaXN0IG9mIGF2YWlsYWJsZQ0KPj4+Pj4+Pj4gY2hhbm5lbHMuDQo+Pj4+Pj4+PiBUaGUg RGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmaWNhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9u IGJ5DQo+Pj4+Pj4+PiBjaGFubmVsDQo+Pj4+Pj4+PiBudW1iZXJzIGFuZCBieSBzdGFydCBhbmQg c3RvcCBmcmVxdWVuY2llcy4gVGhlIERhdGEgTW9kZWwgTVVTVA0KPj4+Pj4+Pj4gc3VwcG9ydCBh DQo+Pj4+Pj4+PiBjaGFubmVsIGF2YWlsYWJpbGl0eSBzY2hlZHVsZSBhbmQgbWF4aW11bSBwb3dl ciBsZXZlbCBmb3IgZWFjaA0KPj4+Pj4+Pj4gY2hhbm5lbA0KPj4+Pj4+Pj4gaW4NCj4+Pj4+Pj4+ IHRoZSBsaXN0Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gPEVkLiBO b3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIG1vYmlsaXR5IHVzZSBjYXNlPC9FZC4gTm90ZT4N Cj4+Pj4+Pj4+IEQuMTA6ICBUaGUgRGF0YSBNb2RlbCBNVVNUIHN1cHBvcnQgc3BlY2lmeWluZyBj aGFubmVsIGF2YWlsYWJpbGl0eQ0KPj4+Pj4+Pj4gaW5mb3JtYXRpb24gZm9yIGEgc2luZ2xlIGxv Y2F0aW9uIGFuZCBhbiBhcmVhIChlLmcuIGEgcG9seWdvbg0KPj4+Pj4+Pj4gZGVmaW5lZA0KPj4+ Pj4+Pj4gYnkNCj4+Pj4+Pj4+IG11bHRpcGxlIGxvY2F0aW9uIHBvaW50cyBvciBhIGdlb21ldHJp YyBzaGFwZSBzdWNoIGFzIGEgY2lyY2xlKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gUC4gUHJvdG9jb2wgUmVxdWlyZW1lbnRzOg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0 ZWQgdG8gZGlzY292ZXJ5IGZ1bmN0aW9uPC9FZC4gTm90ZT4NCj4+Pj4+Pj4+IFAuMTogVGhlIHBy b3RvY29sIE1VU1QgcHJvdmlkZSBhIG1lc3NhZ2Ugc2VxdWVuY2UgZm9yIHRoZSBtYXN0ZXINCj4+ Pj4+Pj4+IGRldmljZQ0KPj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+IGRpc2NvdmVyIGEgd2hpdGUgc3Bh Y2UgZGF0YWJhc2UgdGhhdCBwcm92aWRlcyBzZXJ2aWNlIGF0IGl0cw0KPj4+Pj4+Pj5jdXJyZW50 DQo+Pj4+Pj4+PiBsb2NhdGlvbi4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gUC4yOiBU aGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGFjY2VzcyBvZiBhIGRhdGFiYXNlIGRpcmVjdGx5LiBU aGUNCj4+Pj4+Pj4+IHByb3RvY29sDQo+Pj4+Pj4+PiBNVVNUIHN1cHBvcnQgYWNjZXNzIG9mIGEg ZGF0YWJhc2UgdXNpbmcgYSBsaXN0aW5nIGFwcHJvdmVkIGJ5IGENCj4+Pj4+Pj4+IG5hdGlvbmFs DQo+Pj4+Pj4+PiByZWd1bGF0b3IuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFAuMzog VGhlIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBkZXRlcm1pbmF0aW9uIG9mIHJlZ3VsYXRvcnkgZG9t YWluDQo+Pj4+Pj4+PiBnb3Zlcm5pbmcgaXRzIGN1cnJlbnQgbG9jYXRpb24uDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4NCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byB0aHJl YXQgbW9kZWw8L0VkLiBOb3RlPg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBQLjQ6IFRo ZSBwcm90b2NvbCBNVVNUIHByb3ZpZGUgdGhlIGFiaWxpdHkgZm9yIHRoZSBkYXRhYmFzZSB0bw0K Pj4+Pj4+Pj4gYXV0aGVudGljYXRlIHRoZSBtYXN0ZXIgZGV2aWNlLg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+PiBQLjU6IFRoZSBwcm90b2NvbCBNVVNUIHByb3ZpZGUgdGhlIGFiaWxpdHkg Zm9yIHRoZSBtYXN0ZXIgZGV2aWNlDQo+Pj4+Pj4+PnRvDQo+Pj4+Pj4+PiB2ZXJpZnkNCj4+Pj4+ Pj4+IHRoZSBhdXRoZW50aWNpdHkgb2YgdGhlIGRhdGFiYXNlIHdpdGggd2hpY2ggaXQgaXMgaW50 ZXJhY3RpbmcuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFAuNjogVGhlIG1lc3NhZ2Vz IHNlbnQgYnkgdGhlIG1hc3RlciBkZXZpY2UgdG8gdGhlIGRhdGFiYXNlIE1VU1QNCj4+Pj4+Pj4+ YmUNCj4+Pj4+Pj4+IGludGVncml0eSBwcm90ZWN0ZWQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+IFAuNzogVGhlIG1lc3NhZ2VzIHNlbnQgYnkgdGhlIGRhdGFiYXNlIHRvIHRoZSBtYXN0 ZXIgZGV2aWNlIE1VU1QNCj4+Pj4+Pj4+YmUNCj4+Pj4+Pj4+IGludGVncml0eSBwcm90ZWN0ZWQu DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFAuODogVGhlIHByb3RvY29sIE1VU1QgcHJv dmlkZSB0aGUgY2FwYWJpbGl0eSBmb3IgbWVzc2FnZXMgc2VudCBieQ0KPj4+Pj4+Pj4gdGhlDQo+ Pj4+Pj4+PiBtYXN0ZXIgZGV2aWNlIGFuZCBkYXRhYmFzZSB0byBiZSBlbmNyeXB0ZWQuDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gcmVnaXN0cmF0aW9uIGZ1 bmN0aW9uPC9FZC4gTm90ZT4NCj4+Pj4+Pj4+IFAuOTogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9y dCB0aGUgbWFzdGVyIGRldmljZSByZWdpc3RlcmluZyB3aXRoDQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+ Pj4+IGRhdGFiYXNlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBQLjEwOiBUaGUgcmVn aXN0cmF0aW9uIHNpZ25hbGluZyBNQVkgaW5jbHVkZSB0aGUgRGV2aWNlIElELA0KPj4+Pj4+Pj4g bWFudWZhY3R1cmVywrlzDQo+Pj4+Pj4+PiBzZXJpYWwgbnVtYmVyLCBkZXZpY2UgbG9jYXRpb24s IGRldmljZSBhbnRlbm5hIGNoYXJhY3RlcmlzdGljDQo+Pj4+Pj4+PiBpbmZvcm1hdGlvbiwNCj4+ Pj4+Pj4+IG5hbWUgb2YgaW5kaXZpZHVhbCBvciBidXNpbmVzcyB0aGF0IG93bnMgdGhlIGRldmlj ZSwgbmFtZSwNCj4+Pj4+Pj4+YWRkcmVzcywNCj4+Pj4+Pj4+IGVtYWlsDQo+Pj4+Pj4+PiBhZGRy ZXNzIGFuZCBwaG9uZSBudW1iZXIgb2YgYSBjb250YWN0IHBlcnNvbiB3aG8gaXMgcmVzcG9uc2li bGUNCj4+Pj4+Pj4+Zm9yDQo+Pj4+Pj4+PiBkZXZpY2UNCj4+Pj4+Pj4+IG9wZXJhdGlvbi4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gUC4xMTogVGhlIHByb3RvY29sIE1VU1Qgc3VwcG9y dCBhIHJlZ2lzdHJhdGlvbiBhY2tub3dsZWRnZW1lbnQNCj4+Pj4+Pj4+IGluY2x1ZGluZw0KPj4+ Pj4+Pj4gYXBwcm9wcmlhdGUgcmVzdWx0IGNvZGVzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0 byBob3RzcG90IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+Pj4+Pj4+IFAuMTI6IFRoZSBwcm90b2Nv bCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlcXVlc3QgZnJvbSB0aGUNCj4+Pj4+Pj4+ IG1hc3Rlcg0KPj4+Pj4+Pj4gZGV2aWNlIHRvIHRoZSBkYXRhYmFzZS4gVGhlIGNoYW5uZWwgcXVl cnkgcmVxdWVzdCBtZXNzYWdlIE1VU1QNCj4+Pj4+Pj4+IGluY2x1ZGUNCj4+Pj4+Pj4+IHBhcmFt ZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4gVGhlc2UN Cj4+Pj4+Pj4+IHBhcmFtZXRlcnMNCj4+Pj4+Pj4+IE1BWSBpbmNsdWRlIGRldmljZSBsb2NhdGlv biwgZGV2aWNlIElELCBtYW51ZmFjdHVyZXLCuXMgc2VyaWFsDQo+Pj4+Pj4+PiBudW1iZXIsDQo+ Pj4+Pj4+PiBhbmQNCj4+Pj4+Pj4+IGFudGVubmEgY2hhcmFjdGVyaXN0aWMgaW5mb3JtYXRpb24u DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFAuMTM6IFRoZSBwcm90b2NvbCBNVVNUIHN1 cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlc3BvbnNlIGZyb20gdGhlDQo+Pj4+Pj4+PiBkYXRhYmFz ZQ0KPj4+Pj4+Pj4gdG8gdGhlIG1hc3RlciBkZXZpY2UuIFRoZSBjaGFubmVsIHF1ZXJ5IHJlc3Bv bnNlIG1lc3NhZ2UgTVVTVA0KPj4+Pj4+Pj4gaW5jbHVkZQ0KPj4+Pj4+Pj4gcGFyYW1ldGVycyBh cyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVtZW50LiBUaGVzZQ0KPj4+Pj4+ Pj4gcGFyYW1ldGVycw0KPj4+Pj4+Pj4gTUFZIGluY2x1ZGUgYXZhaWxhYmxlIGNoYW5uZWxzLCBk dXJhdGlvbiBvZiB0aW1lIGZvciB0aGVpciB1c2UsDQo+Pj4+Pj4+PiBhc3NvY2lhdGVkDQo+Pj4+ Pj4+PiBtYXhpbXVtIHBvd2VyIGxldmVscywgYW55IGFkZGl0aW9uYWwgc2Vuc2luZyByZXF1aXJl bWVudHMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFAuMTQ6IFRoZSBwcm90b2NvbCBN VVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlcXVlc3QgZnJvbSB0aGUNCj4+Pj4+Pj4+IHNs YXZlDQo+Pj4+Pj4+PiBkZXZpY2UgdG8gdGhlIG1hc3RlciBkZXZpY2UuIFRoZSBjaGFubmVsIHF1 ZXJ5IHJlcXVlc3QgbWVzc2FnZQ0KPj4+Pj4+Pj5NVVNUDQo+Pj4+Pj4+PiBpbmNsdWRlIHBhcmFt ZXRlcnMgYXMgcmVxdWlyZWQgYnkgbG9jYWwgcmVndWxhdG9yeSByZXF1aXJlbWVudC4NCj4+Pj4+ Pj4+IFRoZXNlDQo+Pj4+Pj4+PiBwYXJhbWV0ZXJzIE1BWSBpbmNsdWRlIGRldmljZSBJRCBhbmQg c2xhdmUgZGV2aWNlIGxvY2F0aW9uLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBQLjE1 OiBUaGUgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IGEgdmFsaWRhdGlvbiByZXF1ZXN0IGZyb20gdGhl DQo+Pj4+Pj4+Pm1hc3Rlcg0KPj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+IHRoZSBkYXRhYmFzZSB0byB2 YWxpZGF0ZSBhIHNsYXZlIGRldmljZS4gVGhlIHZhbGlkYXRpb24gcmVxdWVzdA0KPj4+Pj4+Pj5N VVNUDQo+Pj4+Pj4+PiBpbmNsdWRlIHRoZSBzbGF2ZSBkZXZpY2UgSUQuDQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IFAuMTY6IFRoZSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYSB2YWxpZGF0 aW9uIHJlc3BvbnNlIGZyb20gdGhlDQo+Pj4+Pj4+PiBkYXRhYmFzZQ0KPj4+Pj4+Pj4gdG8NCj4+ Pj4+Pj4+IHRoZSBtYXN0ZXIuIFRoZSB2YWxpZGF0aW9uIHJlc3BvbnNlIE1VU1QgaW5jbHVkZSBh IHJlc3BvbnNlIGNvZGUuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFAuMTc6IFRoZSBw cm90b2NvbCBNVVNUIHN1cHBvcnQgYSBjaGFubmVsIHF1ZXJ5IHJlc3BvbnNlIGZyb20gdGhlDQo+ Pj4+Pj4+PiBtYXN0ZXINCj4+Pj4+Pj4+IGRldmljZSB0byB0aGUgc2xhdmUgZGV2aWNlLiBUaGUg Y2hhbm5lbCBxdWVyeSByZXNwb25zZSBtZXNzYWdlDQo+Pj4+Pj4+Pk1VU1QNCj4+Pj4+Pj4+IGlu Y2x1ZGUgcGFyYW1ldGVycyBhcyByZXF1aXJlZCBieSBsb2NhbCByZWd1bGF0b3J5IHJlcXVpcmVt ZW50LA0KPj4+Pj4+Pj4gaW5jbHVkaW5nDQo+Pj4+Pj4+PiBhIHJlc3BvbnNlIGNvZGUgYW5kIHN1 ZmZpY2llbnQgaW5mb3JtYXRpb24gdG8gZGVjb2RlIGFuIGVuYWJsaW5nDQo+Pj4+Pj4+PiBzaWdu YWwuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFAuMTg6IFRoZSBwcm90b2NvbCBNVVNU IHN1cHBvcnQgYW4gZW5hYmxpbmcgc2lnbmFsIHNlbnQgZnJvbSB0aGUNCj4+Pj4+Pj4+IG1hc3Rl cg0KPj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+IHRoZSBzbGF2ZS4gVGhpcyBzaWduYWwgTVVTVCBhbGxv dyB0aGUgc2xhdmUgZGV2aWNlIHRvIHZhbGlkYXRlDQo+Pj4+Pj4+PnRoYXQNCj4+Pj4+Pj4+IGEN Cj4+Pj4+Pj4+IHByZXZpb3VzbHkgcmVjZWl2ZWQgYXZhaWxhYmxlIGNoYW5uZWwgbGlzdCBpcyBz dGlsbCB2YWxpZCBvciBub3QuDQo+Pj4+Pj4+PiBUaGlzDQo+Pj4+Pj4+PiBzaWduYWwgTVVTVCBi ZSBlbmNvZGVkIHRvIGFsbG93IHRoZSBzbGF2ZSBkZXZpY2UgdG8gZGV0ZXJtaW5lIHRoZQ0KPj4+ Pj4+Pj4gaWRlbnRpdHkNCj4+Pj4+Pj4+IGlmIHRoZSBzZW5kaW5nIG1hc3RlciBkZXZpY2UuDQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBQLjE5OiBUaGUgcHJvdG9jb2wg YmV0d2VlbiB0aGUgbWFzdGVyIGRldmljZSBhbmQgdGhlIGRhdGFiYXNlIE1VU1QNCj4+Pj4+Pj4+ IHN1cHBvcnQNCj4+Pj4+Pj4+IHRoZSBjYXBhYmlsaXR5IHRvIGNoYW5nZSBjaGFubmVsIGF2YWls YWJpbGl0eSBsaXN0cyBvbiBzaG9ydA0KPj4+Pj4+Pj5ub3RpY2UuDQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiA8RWQuIE5vdGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8g bW9iaWxpdHkgdXNlIGNhc2U8L0VkLiBOb3RlPg0KPj4+Pj4+Pj4gUC4yMDogVGhlIHByb3RvY29s IGJldHdlZW4gdGhlIG1hc3RlciBkZXZpY2UgYW5kIHRoZSBkYXRhYmFzZSBNVVNUDQo+Pj4+Pj4+ PiBzdXBwb3J0DQo+Pj4+Pj4+PiBhIGNoYW5uZWwgYXZhaWxhYmlsaXR5IHJlcXVlc3Qgd2hpY2gg c3BlY2lmaWVzIGEgZ2VvZ3JhcGhpYw0KPj4+Pj4+Pj5sb2NhdGlvbg0KPj4+Pj4+Pj4gYXMNCj4+ Pj4+Pj4+IGFuDQo+Pj4+Pj4+PiBhcmVhIGFzIHdlbGwgYXMgYSBwb2ludC4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTy4gT3BlcmF0 aW9uYWwgUmVxdWlyZW1lbnRzOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiA8RWQuIE5v dGU+cmVxdWlyZW1lbnRzIHJlbGF0ZWQgdG8gZGlzY292ZXJ5IGZ1bmN0aW9uPC9FZC4gTm90ZT4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBPLjE6IFRoZSBkYXRhYmFzZSBhbmQgdGhlIG1hc3RlciBkZXZp Y2UgTVVTVCBiZSBjb25uZWN0ZWQgdG8gdGhlDQo+Pj4+Pj4+PiBJbnRlcm5ldC4NCj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTy4yOiAgQSBtYXN0ZXIgZGV2aWNlIE1VU1QgYmUgYWJsZSB0 byBkZXRlcm1pbmUgaXRzIGxvY2F0aW9uDQo+Pj4+Pj4+PiBpbmNsdWRpbmcNCj4+Pj4+Pj4+IHVu Y2VydGFpbnR5IGFuZCBjb25maWRlbmNlIGxldmVsLiBBIGZpeGVkIG1hc3RlciBkZXZpY2UgTUFZ IHVzZSBhDQo+Pj4+Pj4+PiBsb2NhdGlvbg0KPj4+Pj4+Pj4gcHJvZ3JhbW1lZCBhdCBpbnN0YWxs YXRpb24gb3IgaGF2ZSB0aGUgY2FwYWJpbGl0eSBkZXRlcm1pbmUgaXRzDQo+Pj4+Pj4+PiBsb2Nh dGlvbg0KPj4+Pj4+Pj4gdG8gdGhlIHJlcXVpcmVkIGFjY3VyYWN5LiBBIG1vYmlsZSBtYXN0ZXIg ZGV2aWNlIE1VU1QgaGF2ZSB0aGUNCj4+Pj4+Pj4+IGNhcGFiaWxpdHkNCj4+Pj4+Pj4+IHRvIGRl dGVybWluZSBpdHMgbG9jYXRpb24gdG8gdGhlIHJlcXVpcmVkIGFjY3VyYWN5Lg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBPLjM6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgaWRlbnRpZnkg YSBkYXRhYmFzZSBmb3IgdXNlLiBUaGUNCj4+Pj4+Pj4+bWFzdGVyDQo+Pj4+Pj4+PiBkZXZpY2UN Cj4+Pj4+Pj4+IE1BWSBzZWxlY3QgYSBkYXRhYmFzZSBmb3Igc2VydmljZSBieSBkaXNjb3Zlcnkg YXQgcnVudGltZSBvciB0aGUNCj4+Pj4+Pj4+IG1hc3Rlcg0KPj4+Pj4+Pj4gZGV2aWNlIE1BWSBz ZWxlY3QgYSBkYXRhYmFzZSBmb3Igc2VydmljZSBieSBtZWFucyBvZiBhDQo+Pj4+Pj4+PiBwcmUt cHJvZ3JhbW1lZA0KPj4+Pj4+Pj4gVVJJDQo+Pj4+Pj4+PiBhZGRyZXNzLg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBPLjQ6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgaW1wbGVtZW50IGF0 IGxlYXN0IG9uZSBjb25uZWN0aW9uDQo+Pj4+Pj4+Pm1ldGhvZA0KPj4+Pj4+Pj4gdG8NCj4+Pj4+ Pj4+IGFjY2VzcyB0aGUgZGF0YWJhc2UuIFRoZSBtYXN0ZXIgZGV2aWNlIE1BWSBjb250YWN0IGEg ZGF0YWJhc2UNCj4+Pj4+Pj4+IGRpcmVjdGx5DQo+Pj4+Pj4+PiBmb3INCj4+Pj4+Pj4+IHNlcnZp Y2UgKGUuZy4gYXMgZGVmaW5lZCBieSBGQ0MpIG9yIHRoZSBtYXN0ZXIgZGV2aWNlIE1BWSBjb250 YWN0DQo+Pj4+Pj4+PmENCj4+Pj4+Pj4+IGxpc3Rpbmcgc2VydmVyIGZpcnN0IGZvbGxvd2VkIGJ5 IGNvbnRhY3QgdG8gYSBkYXRhYmFzZSAoZS5nLiBBcw0KPj4+Pj4+Pj4gZGVmaW5lZA0KPj4+Pj4+ Pj4gYnkNCj4+Pj4+Pj4+IE9mY29tKS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTy41 OiBUaGUgbWFzdGVyIGRldmljZSBNVVNUIG9idGFpbiBhbiBpbmRpY2F0aW9uIHRoZSByZWd1bGF0 b3J5DQo+Pj4+Pj4+PiBkb21haW4NCj4+Pj4+Pj4+IGdvdmVybmluZyBvcGVyYXRpb24gYXQgaXRz IGN1cnJlbnQgbG9jYXRpb24sIGkuZS4gdGhlIG1hc3Rlcg0KPj4+Pj4+Pj5kZXZpY2UNCj4+Pj4+ Pj4+IE1VU1QNCj4+Pj4+Pj4+IGtub3cgaWYgaXQgb3BlcmF0ZXMgdW5kZXIgcmVndWxhdGlvbnMg ZnJvbSBGQ0MsIE9mY29tLCBldGPFoA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byByZWdpc3Ry YXRpb24gZnVuY3Rpb248L0VkLiBOb3RlPg0KPj4+Pj4+Pj4gTy42OiBUaGUgbWFzdGVyIGRldmlj ZSBNQVkgcmVnaXN0ZXIgd2l0aCB0aGUgZGF0YWJhc2UgYWNjb3JkaW5nIHRvDQo+Pj4+Pj4+PiBs b2NhbA0KPj4+Pj4+Pj4gcmVndWxhdG9yeSBwb2xpY3kuIE5vdCBhbGwgbWFzdGVyIGRldmljZXMg d2lsbCBiZSByZXF1aXJlZCB0bw0KPj4+Pj4+Pj4gcmVnaXN0ZXIuDQo+Pj4+Pj4+PiBTcGVjaWZp YyBldmVudHMgd2lsbCBpbml0aWF0ZSByZWdpc3RyYXRpb24sIHRoZXNlIGV2ZW50cyBhcmUNCj4+ Pj4+Pj4+IGRldGVybWluZWQNCj4+Pj4+Pj4+IGJ5DQo+Pj4+Pj4+PiByZWd1bGF0b3IgcG9saWN5 IChlLmcuIGF0IHBvd2VyIHVwLCBhZnRlciBtb3ZlbWVudCwgZXRjxaApLg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBPLjc6IFRoZSBtYXN0ZXIgZGV2aWNlIE1VU1QgcmVnaXN0ZXIgd2l0 aCBpdHMgbW9zdCBjdXJyZW50IGFuZA0KPj4+Pj4+Pj4gdXAtdG8tZGF0ZQ0KPj4+Pj4+Pj4gaW5m b3JtYXRpb24uDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gPEVkLiBOb3RlPnJlcXVpcmVtZW50cyByZWxhdGVkIHRvIGhvdHNwb3QgdXNlIGNhc2U8L0Vk LiBOb3RlPg0KPj4+Pj4+Pj4gTy44OiBBIG1hc3RlciBkZXZpY2UgTVVTVCBxdWVyeSB0aGUgZGF0 YWJhc2UgZm9yIHRoZSBhdmFpbGFibGUNCj4+Pj4+Pj4+IGNoYW5uZWxzDQo+Pj4+Pj4+PiBiYXNl ZCBvbiBpdHMgY3VycmVudCBsb2NhdGlvbiBiZWZvcmUgc3RhcnRpbmcgcmFkaW8gdHJhbnNtaXNz aW9uDQo+Pj4+Pj4+PmluDQo+Pj4+Pj4+PiB3aGl0ZQ0KPj4+Pj4+Pj4gc3BhY2UuIFBhcmFtZXRl cnMgcHJvdmlkZWQgdG8gdGhlIGRhdGFiYXNlIE1BWSBpbmNsdWRlIGRldmljZQ0KPj4+Pj4+Pj4g bG9jYXRpb24sDQo+Pj4+Pj4+PiBhY2N1cmFjeSBvZiB0aGUgbG9jYXRpb24sIGFudGVubmEgY2hh cmFjdGVyaXN0aWMgaW5mb3JtYXRpb24sDQo+Pj4+Pj4+PmRldmljZQ0KPj4+Pj4+Pj4gaWRlbnRp ZmllciBvZiBhbnkgc2xhdmUgZGV2aWNlIHJlcXVlc3RpbmcgY2hhbm5lbCBpbmZvcm1hdGlvbi4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTy45OiBUaGUgZGF0YWJhc2UgTVVTVCByZXNw b25kIHRvIGFuIGF2YWlsYWJsZSBjaGFubmVsIGxpc3QNCj4+Pj4+Pj4+cmVxdWVzdA0KPj4+Pj4+ Pj4gZnJvbQ0KPj4+Pj4+Pj4gYW4gYXV0aGVudGljYXRlZCBhbmQgYXV0aG9yaXplZCBkZXZpY2Ug YW5kIE1BWSBhbHNvIHByb3ZpZGUgdGltZQ0KPj4+Pj4+Pj4gY29uc3RyYWludHMsIG1heGltdW0g b3V0cHV0IHBvd2VyLCBzdGFydCBhbmQgc3RvcCBmcmVxdWVuY2llcyBmb3INCj4+Pj4+Pj4+IGVh Y2gNCj4+Pj4+Pj4+IGNoYW5uZWwgaW4gdGhlIGxpc3QgYW5kIGFueSBhZGRpdGlvbmFsIHJlcXVp cmVtZW50cyBmb3Igc2Vuc2luZy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTy4xMDog QWZ0ZXIgY29ubmVjdGluZyB0byBhIG1hc3RlciBkZXZpY2XCuXMgcmFkaW8gbmV0d29yayBhIHNs YXZlDQo+Pj4+Pj4+PiBkZXZpY2UNCj4+Pj4+Pj4+IE1VU1QgcXVlcnkgdGhlIG1hc3RlciBkZXZp Y2UgZm9yIGEgbGlzdCBvZiBhdmFpbGFibGUgY2hhbm5lbHMuIFRoZQ0KPj4+Pj4+Pj4gc2xhdmUN Cj4+Pj4+Pj4+IE1VU1QgaW5jbHVkZSBwYXJhbWV0ZXJzIHJlcXVpcmVkIGJ5IGxvY2FsIHJlZ3Vs YXRvcnkgcG9saWN5LCBlLmcuDQo+Pj4+Pj4+PiBkZXZpY2UNCj4+Pj4+Pj4+IElELCBkZXZpY2Ug bG9jYXRpb24uDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE8uMTE6IEFjY29yZGluZyB0 byBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSwgdGhlIG1hc3RlciBkZXZpY2UgTUFZDQo+Pj4+Pj4+ PiBxdWVyeQ0KPj4+Pj4+Pj4gdGhlIGRhdGFiYXNlIHdpdGggcGFyYW1ldGVycyByZWNlaXZlZCBm cm9tIHRoZSBzbGF2ZSBkZXZpY2UuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE8uMTI6 IFRoZSBkYXRhYmFzZSBNVVNUIHJlc3BvbmQgdG8gYSBxdWVyeSBmcm9tIHRoZSBtYXN0ZXIgZGV2 aWNlDQo+Pj4+Pj4+PiBjb250YWluaW5nIHBhcmFtZXRlcnMgZnJvbSBhIHNsYXZlIGRldmljZS4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTy4xMzogQWZ0ZXIgdGhlIG1hc3RlciBkZXZp Y2UgaGFzIHJlY2VpdmVkIGEgcmVzcG9uc2UgZnJvbSB0aGUNCj4+Pj4+Pj4+IGRhdGFiYXNlLA0K Pj4+Pj4+Pj4gdGhlIG1hc3RlciBkZXZpY2UgTVVTVCByZXNwb25kIHRvIHRoZSBzbGF2ZSBkZXZp Y2UuIElmIGFsbA0KPj4+Pj4+Pj4gcmVndWxhdG9yeQ0KPj4+Pj4+Pj4gcmVxdWlyZW1lbnRzIGFy ZSBtZXQgdGhlIHJlc3BvbnNlIHdpbGwgY29udGFpbiBhbiBhdmFpbGFibGUNCj4+Pj4+Pj4+Y2hh bm5lbA0KPj4+Pj4+Pj4gbGlzdC4NCj4+Pj4+Pj4+IElmIHJlZ3VsYXRvcnkgcmVxdWlyZW1lbnRz IGFyZSBub3QgbWV0LCB0aGUgcmVzcG9uc2UgTVVTVCBjb250YWluDQo+Pj4+Pj4+PmF0DQo+Pj4+ Pj4+PiBsZWFzdA0KPj4+Pj4+Pj4gYSByZXNwb25zZSBjb2RlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ DQo+Pj4+Pj4+PiBPLjE0OiBJZiBhIG1hc3RlciBkZXZpY2UgaGFzIHByb3ZpZGVkIGFuIGF2YWls YWJsZSBjaGFubmVsIGxpc3QNCj4+Pj4+Pj4+dG8gYQ0KPj4+Pj4+Pj4gc2xhdmUNCj4+Pj4+Pj4+ IGRldmljZSB0aGUgbWFzdGVyIGRldmljZSBNQVkgc2VuZCBhIHBlcmlvZGljIGVuYWJsaW5nIHNp Z25hbCB0bw0KPj4+Pj4+Pj4gYWxsb3cNCj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4gc2xhdmUgZGV2 aWNlIHRvIGNvbmZpcm0gaXQgaXMgc3RpbGwgd2l0aGluIHJlY2VwdGlvbiByYW5nZSBvZiB0aGUN Cj4+Pj4+Pj4+IG1hc3Rlcg0KPj4+Pj4+Pj4gZGV2aWNlLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBPLjE1OiBUaGUgZW5hYmxpbmcgc2lnbmFsIE1VU1QgYmUgZW5jb2RlZCBzbyB0aGF0 IHRoZSByZWNlaXZpbmcNCj4+Pj4+Pj4+IHNsYXZlDQo+Pj4+Pj4+PiBjYW4NCj4+Pj4+Pj4+IGRl dGVybWluZSB0aGUgaWRlbnRpdHkgb2YgdGhlIHNlbmRpbmcgbWFzdGVyLg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBPLjE2OiBQZXJpb2RpY2FsbHksIGF0IGFuIGludGVydmFsIGFjY29y ZGluZyB0byBsb2NhbCByZWd1bGF0aW9ucywNCj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4gc2xhdmUg ZGV2aWNlIE1VU1QgZWl0aGVyIHJlY2VpdmUgYW5kIGVuYWJsaW5nIHNpZ25hbCBvciBNVVNUDQo+ Pj4+Pj4+PiBzdWNjZXNzZnVsbHkNCj4+Pj4+Pj4+IHJlcGVhdCB0aGUgY2hhbm5lbCByZXF1ZXN0 IHByb2Nlc3Mgb3IgTVVTVCBjZWFzZSB0cmFuc21pc3Npb24gb24NCj4+Pj4+Pj4+dGhlDQo+Pj4+ Pj4+PiBjaGFubmVsLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBPLjE3OiBBIG1hc3Rl ciBkZXZpY2UgTVVTVCByZXBlYXQgdGhlIHF1ZXJ5IHRoZSBkYXRhYmFzZSBmb3IgdGhlDQo+Pj4+ Pj4+PiBhdmFpbGFibGUNCj4+Pj4+Pj4+IGNoYW5uZWxzIGFzIG9mdGVuIGFzIHJlcXVpcmVkIGJ5 IHRoZSByZWd1bGF0aW9uIChlZywgRkNDIHJlcXVpcmVzDQo+Pj4+Pj4+PiBvbmNlDQo+Pj4+Pj4+ PiBwZXINCj4+Pj4+Pj4+IGRheSkgdG8gdmVyaWZ5IHRoYXQgdGhlIG9wZXJhdGluZyBjaGFubmVs cyBjb250aW51ZSB0byByZW1haW4NCj4+Pj4+Pj4+IGF2YWlsYWJsZS4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4gTy4xODogQSBtYXN0ZXIgZGV2aWNlIHdoaWNoIGNoYW5nZXMgaXRzIGxv Y2F0aW9uIG1vcmUgdGhhbiBhDQo+Pj4+Pj4+PiB0aHJlc2hvbGQNCj4+Pj4+Pj4+IGRpc3RhbmNl IHNwZWNpZmllZCBieSBsb2NhbCByZWd1bGF0b3J5IHBvbGljeSBkdXJpbmcgaXRzDQo+Pj4+Pj4+ Pm9wZXJhdGlvbiwNCj4+Pj4+Pj4+IE1VU1QNCj4+Pj4+Pj4+IHF1ZXJ5IHRoZSBkYXRhYmFzZSBm b3IgYXZhaWxhYmxlIG9wZXJhdGluZyBjaGFubmVscyBlYWNoIHRpbWUgaXQNCj4+Pj4+Pj4+IG1v dmVzDQo+Pj4+Pj4+PiBtb3JlIHRoYW4gdGhlIHRocmVzaG9sZCBkaXN0YW5jZSAoZS5nLiwgRkND IHNwZWNpZmllcyAxMDBtKSBmcm9tDQo+Pj4+Pj4+PnRoZQ0KPj4+Pj4+Pj4gbG9jYXRpb24gaXQg cHJldmlvdXNseSBtYWRlIHRoZSBxdWVyeS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMgcmVsYXRlZCB0byB3cmFuIHVzZSBjYXNl PC9FZC4gTm90ZT4NCj4+Pj4+Pj4+IE8uMTk6IElmIHNsYXZlIGRldmljZXMgY2hhbmdlIHRoZWly IGxvY2F0aW9uIGR1cmluZyBvcGVyYXRpb24gYnkNCj4+Pj4+Pj4+IG1vcmUNCj4+Pj4+Pj4+IHRo YW4NCj4+Pj4+Pj4+IGEgbGltaXQgc3BlY2lmaWVkIGJ5IHRoZSBsb2NhbCByZWd1bGF0b3IsIHRo ZSBzbGF2ZSBkZXZpY2UgTVVTVA0KPj4+Pj4+Pj4gcXVlcnkNCj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+ Pj4gbWFzdGVyIGRldmljZSBmb3IgYXZhaWxhYmxlIG9wZXJhdGluZyBjaGFubmVscy4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMg cmVsYXRlZCB0byByYXBpZCBkZXBsb3llZCBuZXR3b3JrIHVzZQ0KPj4+Pj4+Pj4gY2FzZTwvRWQu DQo+Pj4+Pj4+PiBOb3RlPg0KPj4+Pj4+Pj4gTy4yMDogQWNjb3JkaW5nIHRvIGxvY2FsIHJlZ3Vs YXRvciBwb2xpY3ksIGEgbWFzdGVyIGRldmljZSBtYXkNCj4+Pj4+Pj4+IGNvbnRhY3QgYQ0KPj4+ Pj4+Pj4gZGF0YWJhc2UgdmlhIHByb3h5IHNlcnZpY2Ugb2YgYW5vdGhlciBtYXN0ZXIgZGV2aWNl Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gPEVkLiBOb3RlPnJlcXVp cmVtZW50cyByZWxhdGVkIHRvIG1vYmlsaXR5IHVzZSBjYXNlPC9FZC4gTm90ZT4NCj4+Pj4+Pj4+ IE8uMjE6IEEgbWFzdGVyIGRldmljZSBNVVNUIGJlIGFibGUgdG8gcXVlcnkgdGhlIHdoaXRlc3Bh Y2UNCj4+Pj4+Pj4+ZGF0YWJhc2UNCj4+Pj4+Pj4+IGZvcg0KPj4+Pj4+Pj4gY2hhbm5lbCBhdmFp bGFiaWxpdHkgaW5mb3JtYXRpb24gZm9yIGEgc3BlY2lmaWMgZXhwZWN0ZWQgY292ZXJhZ2UNCj4+ Pj4+Pj4+IGFyZWENCj4+Pj4+Pj4+IGFyb3VuZCBpdHMgY3VycmVudCBsb2NhdGlvbi4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IDxFZC4gTm90ZT5yZXF1aXJlbWVudHMg cmVsYXRlZCB0byB0aHJlYXQgbW9kZWw8L0VkLiBOb3RlPg0KPj4+Pj4+Pj4gTy4yMjogQSBNYXN0 ZXIgZGV2aWNlIE1BWSBub3QgaW5jbHVkZSBpdHMgaWRlbnRpdHkgaW4NCj4+Pj4+Pj4+IG1lc3Nh Z2VzIHNlbnQgdG8gdGhlIGRhdGFiYXNlIHdoZW4gbm90IHJlcXVpcmVkIGJ5IHRoZSByZWd1bGF0 b3J5DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4gcGF3cyBtYWlsaW5n IGxpc3QNCj4+Pj4+Pj4+IHBhd3NAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KPj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pg0KPj4+Pg0K Pj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+PiBwYXdzQGlldGYub3JnDQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4NCg0K From jstine@mitre.org Mon Feb 27 14:11:15 2012 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 6A19121E802A for ; Mon, 27 Feb 2012 14:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.269 X-Spam-Level: X-Spam-Status: No, score=-6.269 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enB5AkrvAcwN for ; Mon, 27 Feb 2012 14:11:14 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4C14721E8015 for ; Mon, 27 Feb 2012 14:11:14 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AC47B21B1359 for ; Mon, 27 Feb 2012 17:11:13 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9AD9A21B1321 for ; Mon, 27 Feb 2012 17:11:13 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Mon, 27 Feb 2012 17:11:13 -0500 From: "Stine, John A." To: "paws@ietf.org" Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXAAK668AAApamWAAE0F7UA== Date: Mon, 27 Feb 2012 22:11:12 +0000 Message-ID: <2782C93FD2244441893673F3F9128192114DB0@IMCMBX01.MITRE.ORG> References: <2782C93FD2244441893673F3F9128192114D0B@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [paws] FW: Further explanation of partitioned data models 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: Mon, 27 Feb 2012 22:11:15 -0000 -----Original Message----- From: Stine, John A.=20 Sent: Monday, February 27, 2012 5:03 PM To: 'Peter Stanforth' Subject: RE: [paws] Further explanation of partitioned data models Peter, Thank you for the response. I fully understand the groups intent to get so= mething done right away so that the TVWS market can start moving. I made t= his suggestion thinking it would be a very mild change not really contribut= ing to a lot of work. I am not advocating adding capabilities outside the = scope of this initial effort, just promoting the division of the data model= to make later expansion easier. The only additional effort I can think of= would be to provide the means within PAWS for a database administrator to = specify the particular schemas to use. That is it. Your opinion that the PAWS work would not affect your business model carrie= s a lot of weight. It would be interesting to know the amount of communica= tions you would have with customers that would not involve PAWS at all. Co= nsidering your overlay view of building on top of PAWS, if coexistence mana= gement were found to be necessary for effective use of whitespace, would yo= ur approach allow you to collaborate with the other database administrators= for that objective. John -----Original Message----- From: Peter Stanforth [mailto:peter@spectrumbridge.com]=20 Sent: Monday, February 27, 2012 4:26 PM To: Stine, John A.; paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models John, I may be guilty of being one of those panelists you mention, and we also run a secondary marketplace for spectrum, so I speak as someone who has a vested interest in what happens beyond TVWS. I agree with your insight on the potential, both for access to additional spectrum as well as for different business models. I also agree with your summary of the type of negotiation that is likely. Speaking for Spectrum Bridge we can see a way to address those opportunities within the current PAWS construct and don't necessarily need to break anything out. I would want to understand this proposal better as I have two concerns. First it seems difficult to achieve this without significantly complicating the process. Second I am not sure that the result may be worse than where we are today, in that it might confine me to certain modes of operation or not. The only quick, and simple, analogy I can give is Boingo. They have a revenue generating service offered on top of unlicensed WiFi. They do so without any impact on the underlying WiFi MAC/PHY protocols. Our (SBI) concern has been that the PAWS protocol/requirements do not preclude us from being able to offer enhanced and differentiated services and so far we have not been able to identify an issue. I would be happy to continue the discussion in parallel to the initial PAWS effort and would not rule out such a breakup in the future but I think the majority are hoping to get something finished to address TVWS without too much expansion. Regards Peter Stanforth CTO Spectrum Bridge Inc. On MonFeb/27/12 Mon Feb 27, 4:13 PM, "Stine, John A." wrote: >From the lack of response to my email last week, I assume folks just >don't understand why I am recommending the division of the data model. >Please let me explain in a different way. > >Last December, at the SDR Forum, Julius Knapp, the Director of the OET at >the FCC, hosted a panel attended by five of the ten database >administrators. In that panel, he asked the panelists what was in it for >them. Several responded that they hoped they could provide a service to >those looking for spectrum and to help broker these arrangements. > >This is not the model of TVWS. At present, the urgency of the paws >effort surrounds a narrower goal of enabling TVWS devices to obtain >channels they can use. I do not want to make any suggestions that would >prevent us from achieving this goal first. I do want to make an effort >to prevent what is done from becoming an impediment to a bigger role for >whitespace database administration in the future, one of managing >coexistence and brokering spectrum reuse. > >In all methods of using a database where a device negotiates with a >database, the types of messages that will be used are likely to be >similar:=20 >- This is who I am, what rules should I apply in negotiating for >spectrum? =20 >- This is the spectrum I am looking for, what do you have? >- This is the spectrum that meets your query criteria. >- etc. >The methods developed for trust are also reusable. This is the reason >for having a portion of the data model remain the same for all expansions. > >The differences between a TVWS scenario and a brokering scenario are >likely to be additional messaging and different data, both for the >business of brokering and for defining the spectrum authorization. For >example, in the brokering use case there needs to be a spectrum data >model that allows a primary spectrum user to release spectrum into the >market, (e.g., provide their contours ) and to specify the terms of use. >My concern is that if the data model of TVWS comingles the data of >messaging, administration, and spectrum; that this sort of expansion of >paws would require increasing the size of the data model and would make >expanding its capability more difficult both because of the impact of >this expansion on legacy uses and because of the confusion of using large >schemas that have similar but different data elements. > >My solution is to divide the data model into three parts. The data >document of messages would use the namespace of three schemas. In the >TVWS edition, this would also allow different administrative and spectrum >schemas for different regulatory domains. In end, the data for TVWS >management would not be any different, it would just be defined in three >schemas > >In the initial exchanges between a device and a database, there would be >agreement on which schemas to use. This is equivalent to resolving the >regulatory domain. The messaging that follows would be the exact same, >with the exact same data as the messaging if a comingled data model were >used. > >If the division is done well, then, in the long term, others can create >schemas for administration and spectrum definition that meets their >business needs without having to do so through paws. They would be able >expand the way the paws protocol is used without having to revise paws. > >I hope this better explains my intent. It would also be helpful to >understand why anyone thinks this should not be done. > >John >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Mon Feb 27 14:14:12 2012 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 46A6021E8034 for ; Mon, 27 Feb 2012 14:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.664 X-Spam-Level: X-Spam-Status: No, score=-5.664 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2TuPZCCwpcc for ; Mon, 27 Feb 2012 14:14:10 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 4746721E8015 for ; Mon, 27 Feb 2012 14:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1330380889; x=1645733423; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=Fmhlo/v60xybdaY0sbVKY 3U4dyBvf5kWpnL4SRBaSBM=; b=BT9Dy5UlmogqxgQolKVpWQYAmcaX1/ETQ7IHF ZMIM7kqPGu4f2f3ZxDfxo6aQZO1vyNWH9DUXxRd5kypaGOqsw== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.5665306; Mon, 27 Feb 2012 17:14:48 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 27 Feb 2012 17:14:08 -0500 From: "Rosen, Brian" To: "" Date: Mon, 27 Feb 2012 17:14:06 -0500 Thread-Topic: [paws] UC&R I-D: Requirements Thread-Index: Acz1nR+BFKwuclMxR+2AhDECbfb0oQ== Message-ID: <727ED02F-EB57-4475-9792-7B54F3DCAF8A@neustar.biz> References: 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: oKJYnfJy0R/EmDLT2HB8gQ== Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] UC&R I-D: Requirements 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: Mon, 27 Feb 2012 22:14:12 -0000 Guilty of not reading the doc carefully enough. Why yes it does. Brian On Feb 27, 2012, at 5:08 PM, wrote: > Hi Brian, > > I agree we should be flexible enough to send device information with the > spectrum query when requested by the local regulator. Does P.12 address > this accurately? > > Kind Regards, > Scott > > > > On 2/27/12 3:38 PM, "ext Rosen, Brian" wrote: > >> >> I have a small issue here. >> >> Device characteristics don't typically change, so having them in some >> form of registration transaction makes sense in an engineering sense. >> However, some regulators don't seem to understand that, and there are >> circumstances where you have to send some of the device information with >> the spectrum query. We should be flexible enough to handle that. >> >> Brian >> >> On Feb 27, 2012, at 3:46 PM, >> wrote: >> >>> Hi Teco, >>> >>> We could change O.7 to something like: >>> >>> O.7: The master device MUST register with its most current and >>> up-to-date >>> information, and MUST include all variables mandated by local regulator >>> policy. >>> >>> Would this work? >>> >>> Kind Regards, >>> Scott >>> >>> >>> >>> On 2/27/12 2:25 PM, "ext Teco Boot" wrote: >>> >>>> Hello Scott, >>>> >>>> I understand your point. But I want to keep things simple. The >>>> P.* requirements are for the protocol, it MUST support optional >>>> variables. >>>> The O.* requirements explain how these are used. This is the MAY, >>>> right? >>>> >>>> Having performed some tests today with an emergency responders >>>> network, I saw some high traffic load. Something like this: >>>> >>>> 1 >>>> <\self_explaining_variable_name> >>>> I could think of an efficiency requirement, for the rapid deployed >>>> network use case. >>>> >>>> Thanks, Teco >>>> >>>> >>>> Op 27 feb. 2012, om 14:32 heeft >>>> het volgende geschreven: >>>> >>>>> Hi Teco, >>>>> >>>>> If we look at P.9 and P.10 together, P.9 says that registration is a >>>>> MUST >>>>> -- the protocol supports registration without question. P.10 says the >>>>> signaling for registration MAY contain any of several variables (also >>>>> allows more variables to be included if required by local >>>>> regulations). >>>>> The list currently identifies all variables required for registration >>>>> in >>>>> the US. Now if we look at the Data Model requirements, each variable >>>>> identified that the registration service MAY contain (these are in >>>>> D.5, >>>>> D.6, D.1, D.7 and D.8) MUST be included in the Data Model. The >>>>> protocol >>>>> MUST support registration, and the Data Model in the protocol MUST >>>>> support >>>>> the variables identified for registration service. >>>>> >>>>> The current use of MUST in P.9 and MAY in P.10 has the effect that >>>>> WSDs >>>>> in >>>>> the US are allowed to register (because the protocol supports >>>>> registration) and are allowed to use the variables defined by the FCC >>>>> (because the registration signaling MAY include those variables). Thi= s >>>>> also has the effect that WSDs in the UK (or elsewhere in the world) >>>>> are >>>>> allowed to register if this is a local requirement (because the >>>>> protocol >>>>> supports registration) and are allowed to use (or not use) the >>>>> variables >>>>> defined by the FCC (because the registration signaling MAY include >>>>> those >>>>> variables). Nothing to prevent adding more variables if needed by >>>>> Ofcom, >>>>> IDA, etc... >>>>> >>>>> Another possibility is to change the wording of P.10 to read >>>>> P.10: The registration signaling MUST include the following optional >>>>> variables: the Device ID, manufacturer=B9s serial number, device >>>>> location, >>>>> device antenna characteristic information, name of individual or >>>>> business >>>>> that owns the device, name, address, email address and phone number >>>>> of a >>>>> contact person who is responsible for device operation. >>>>> >>>>> What do you think? >>>>> >>>>> Kind Regards, >>>>> Scott >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 2/26/12 3:41 PM, "ext Teco Boot" wrote: >>>>> >>>>>> Hi Scott, >>>>>> >>>>>> I still think it is a MUST for the protocol, and a MAY for usage. >>>>>> >>>>>> Thanks, Teco >>>>>> >>>>>> Op 24 feb. 2012, om 19:58 heeft >>>>>> het volgende geschreven: >>>>>> >>>>>>> Hello Teco, >>>>>>> >>>>>>> Since PAWS is a global standard, registration for all regulatory >>>>>>> domains >>>>>>> must be supported. While the FCC does require all of the variables >>>>>>> listed >>>>>>> in P.10, other regulatory domains may not require each of those >>>>>>> variables. >>>>>>> So for requirements on the protocol, using MAY enables the FCC to >>>>>>> require >>>>>>> these variables while allowing other regulators to select a subset, >>>>>>> or >>>>>>> even different, variables. >>>>>>> >>>>>>> With this explanation, are you okay with MAY in P.10? >>>>>>> >>>>>>> Kind Regards, >>>>>>> Scott >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2/22/12 1:34 AM, "ext Teco Boot" wrote: >>>>>>> >>>>>>>> Scott, Ray, >>>>>>>> >>>>>>>> The P.* are mostly MUST requirements for the protocol. That's fine= . >>>>>>>> Except P.10, this is a MAY operational requirement. The protocol >>>>>>>> MUST support it. >>>>>>>> >>>>>>>> I'm fine with the rest of it. >>>>>>>> >>>>>>>> Is noted somewhere that we (IETF) do our best to support as many >>>>>>>> regulator rules as possible, and leave setting up requirements for >>>>>>>> actual deployment up to the mandated authorities? This makes the >>>>>>>> O.* requirements informational. >>>>>>>> >>>>>>>> Thanks, Teco >>>>>>>> >>>>>>>> >>>>>>>> Op 22 feb. 2012, om 00:53 heeft >>>>>>>> het volgende geschreven: >>>>>>>> >>>>>>>>> Hello All, >>>>>>>>> >>>>>>>>> I have revised Section 6 of the I-D which describes the Data Mode= l >>>>>>>>> Requirements, Protocol Requirements and Operational Requirements. >>>>>>>>> This >>>>>>>>> includes the requirements from the threat model >>>>>>>>> (http://www.ietf.org/mail-archive/web/paws/current/msg00771.html)= . >>>>>>>>> >>>>>>>>> The requirements are ordered "top down" to follow the previous >>>>>>>>> sections >>>>>>>>> of >>>>>>>>> the document: requirements derived from discovery are followed by >>>>>>>>> requirements derived from registration are followed by >>>>>>>>> requirements >>>>>>>>> derived from hotspot, etc... >>>>>>>>> >>>>>>>>> Please review the proposed text, we hope to have your comments by >>>>>>>>> Feb >>>>>>>>> 28th. >>>>>>>>> >>>>>>>>> Kind Regards, >>>>>>>>> >>>>>>>>> Raj & Scott >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> D. Data Model Requirements: >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to discovery function >>>>>>>>> D.1: The Data Model MUST support specifying the location of the >>>>>>>>> WSD, >>>>>>>>> the >>>>>>>>> uncertainty in meters, the height & its uncertainty, and >>>>>>>>> confidence >>>>>>>>> in >>>>>>>>> percentage for the location determination. The Data Model MUST >>>>>>>>> support >>>>>>>>> both North American Datum of 1983 and WGS84. >>>>>>>>> >>>>>>>>> >>>>>>>>> D.2: The Data Model MUST support specifying the URI address of a >>>>>>>>> white >>>>>>>>> space database. >>>>>>>>> >>>>>>>>> >>>>>>>>> D.3: The Data Model MUST support specifying the URI address of a >>>>>>>>> national >>>>>>>>> listing service. >>>>>>>>> >>>>>>>>> >>>>>>>>> D.4: The Data Model MUST support specifying regulatory domain an= d >>>>>>>>> its >>>>>>>>> corresponding data requirements. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to registration function >>>>>>>>> D.5: The Data Model MUST support specifying an ID of the >>>>>>>>> transmitter >>>>>>>>> device. This ID would contain the ID of the transmitter device >>>>>>>>> that >>>>>>>>> has >>>>>>>>> been certified by a regulatory body for its regulatory domain. Th= e >>>>>>>>> Data >>>>>>>>> Model MUST support a device class. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> D.6: The Data Model MUST support specifying a manufacturer=B9s >>>>>>>>> serial >>>>>>>>> number >>>>>>>>> for a master device. >>>>>>>>> >>>>>>>>> >>>>>>>>> D.7: The Data Model MUST support specifying the antenna and >>>>>>>>> radiation >>>>>>>>> related parameters of the device, such as: >>>>>>>>> >>>>>>>>> - antenna height >>>>>>>>> >>>>>>>>> - antenna gain >>>>>>>>> >>>>>>>>> - maximum output power, EIRP (dBm) >>>>>>>>> >>>>>>>>> - antenna radiation pattern (directional dependence >>>>>>>>> of the strength of the radio signal from the antenna) >>>>>>>>> >>>>>>>>> - spectrum mask with lowest and highest possible frequency >>>>>>>>> >>>>>>>>> - spectrum mask in dBr from peak transmit power in EIRP, >>>>>>>>> with specific power limit at any frequency linearly >>>>>>>>> interpolated between adjacent points of the spectrum mask >>>>>>>>> measurement resolution bandwidth for EIRP measurements. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> D.8: The Data Model MUST support specifying owner and operator >>>>>>>>> contact >>>>>>>>> information for a transmitter. This includes the name of the >>>>>>>>> transmitter >>>>>>>>> owner, name of transmitter operator, postal address, email addres= s >>>>>>>>> and >>>>>>>>> phone number of the transmitter operator. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to hotspot use case >>>>>>>>> D.9: The Data Model MUST support specifying a list of available >>>>>>>>> channels. >>>>>>>>> The Data Model MUST support specification of this information by >>>>>>>>> channel >>>>>>>>> numbers and by start and stop frequencies. The Data Model MUST >>>>>>>>> support a >>>>>>>>> channel availability schedule and maximum power level for each >>>>>>>>> channel >>>>>>>>> in >>>>>>>>> the list. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to mobility use case >>>>>>>>> D.10: The Data Model MUST support specifying channel availabilit= y >>>>>>>>> information for a single location and an area (e.g. a polygon >>>>>>>>> defined >>>>>>>>> by >>>>>>>>> multiple location points or a geometric shape such as a circle). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> P. Protocol Requirements: >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to discovery function >>>>>>>>> P.1: The protocol MUST provide a message sequence for the master >>>>>>>>> device >>>>>>>>> to >>>>>>>>> discover a white space database that provides service at its >>>>>>>>> current >>>>>>>>> location. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.2: The protocol MUST support access of a database directly. The >>>>>>>>> protocol >>>>>>>>> MUST support access of a database using a listing approved by a >>>>>>>>> national >>>>>>>>> regulator. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.3: The protocol MUST support determination of regulatory domain >>>>>>>>> governing its current location. >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to threat model >>>>>>>>> >>>>>>>>> >>>>>>>>> P.4: The protocol MUST provide the ability for the database to >>>>>>>>> authenticate the master device. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.5: The protocol MUST provide the ability for the master device >>>>>>>>> to >>>>>>>>> verify >>>>>>>>> the authenticity of the database with which it is interacting. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.6: The messages sent by the master device to the database MUST >>>>>>>>> be >>>>>>>>> integrity protected. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.7: The messages sent by the database to the master device MUST >>>>>>>>> be >>>>>>>>> integrity protected. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.8: The protocol MUST provide the capability for messages sent b= y >>>>>>>>> the >>>>>>>>> master device and database to be encrypted. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to registration function >>>>>>>>> P.9: The protocol MUST support the master device registering with >>>>>>>>> the >>>>>>>>> database. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.10: The registration signaling MAY include the Device ID, >>>>>>>>> manufacturer=B9s >>>>>>>>> serial number, device location, device antenna characteristic >>>>>>>>> information, >>>>>>>>> name of individual or business that owns the device, name, >>>>>>>>> address, >>>>>>>>> email >>>>>>>>> address and phone number of a contact person who is responsible >>>>>>>>> for >>>>>>>>> device >>>>>>>>> operation. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.11: The protocol MUST support a registration acknowledgement >>>>>>>>> including >>>>>>>>> appropriate result codes. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to hotspot use case >>>>>>>>> P.12: The protocol MUST support a channel query request from the >>>>>>>>> master >>>>>>>>> device to the database. The channel query request message MUST >>>>>>>>> include >>>>>>>>> parameters as required by local regulatory requirement. These >>>>>>>>> parameters >>>>>>>>> MAY include device location, device ID, manufacturer=B9s serial >>>>>>>>> number, >>>>>>>>> and >>>>>>>>> antenna characteristic information. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.13: The protocol MUST support a channel query response from the >>>>>>>>> database >>>>>>>>> to the master device. The channel query response message MUST >>>>>>>>> include >>>>>>>>> parameters as required by local regulatory requirement. These >>>>>>>>> parameters >>>>>>>>> MAY include available channels, duration of time for their use, >>>>>>>>> associated >>>>>>>>> maximum power levels, any additional sensing requirements. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.14: The protocol MUST support a channel query request from the >>>>>>>>> slave >>>>>>>>> device to the master device. The channel query request message >>>>>>>>> MUST >>>>>>>>> include parameters as required by local regulatory requirement. >>>>>>>>> These >>>>>>>>> parameters MAY include device ID and slave device location. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.15: The protocol MUST support a validation request from the >>>>>>>>> master >>>>>>>>> to >>>>>>>>> the database to validate a slave device. The validation request >>>>>>>>> MUST >>>>>>>>> include the slave device ID. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.16: The protocol MUST support a validation response from the >>>>>>>>> database >>>>>>>>> to >>>>>>>>> the master. The validation response MUST include a response code. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.17: The protocol MUST support a channel query response from the >>>>>>>>> master >>>>>>>>> device to the slave device. The channel query response message >>>>>>>>> MUST >>>>>>>>> include parameters as required by local regulatory requirement, >>>>>>>>> including >>>>>>>>> a response code and sufficient information to decode an enabling >>>>>>>>> signal. >>>>>>>>> >>>>>>>>> >>>>>>>>> P.18: The protocol MUST support an enabling signal sent from the >>>>>>>>> master >>>>>>>>> to >>>>>>>>> the slave. This signal MUST allow the slave device to validate >>>>>>>>> that >>>>>>>>> a >>>>>>>>> previously received available channel list is still valid or not. >>>>>>>>> This >>>>>>>>> signal MUST be encoded to allow the slave device to determine the >>>>>>>>> identity >>>>>>>>> if the sending master device. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> P.19: The protocol between the master device and the database MUS= T >>>>>>>>> support >>>>>>>>> the capability to change channel availability lists on short >>>>>>>>> notice. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to mobility use case >>>>>>>>> P.20: The protocol between the master device and the database MUS= T >>>>>>>>> support >>>>>>>>> a channel availability request which specifies a geographic >>>>>>>>> location >>>>>>>>> as >>>>>>>>> an >>>>>>>>> area as well as a point. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> O. Operational Requirements: >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to discovery function >>>>>>>>> >>>>>>>>> O.1: The database and the master device MUST be connected to the >>>>>>>>> Internet. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.2: A master device MUST be able to determine its location >>>>>>>>> including >>>>>>>>> uncertainty and confidence level. A fixed master device MAY use a >>>>>>>>> location >>>>>>>>> programmed at installation or have the capability determine its >>>>>>>>> location >>>>>>>>> to the required accuracy. A mobile master device MUST have the >>>>>>>>> capability >>>>>>>>> to determine its location to the required accuracy. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.3: The master device MUST identify a database for use. The >>>>>>>>> master >>>>>>>>> device >>>>>>>>> MAY select a database for service by discovery at runtime or the >>>>>>>>> master >>>>>>>>> device MAY select a database for service by means of a >>>>>>>>> pre-programmed >>>>>>>>> URI >>>>>>>>> address. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.4: The master device MUST implement at least one connection >>>>>>>>> method >>>>>>>>> to >>>>>>>>> access the database. The master device MAY contact a database >>>>>>>>> directly >>>>>>>>> for >>>>>>>>> service (e.g. as defined by FCC) or the master device MAY contact >>>>>>>>> a >>>>>>>>> listing server first followed by contact to a database (e.g. As >>>>>>>>> defined >>>>>>>>> by >>>>>>>>> Ofcom). >>>>>>>>> >>>>>>>>> >>>>>>>>> O.5: The master device MUST obtain an indication the regulatory >>>>>>>>> domain >>>>>>>>> governing operation at its current location, i.e. the master >>>>>>>>> device >>>>>>>>> MUST >>>>>>>>> know if it operates under regulations from FCC, Ofcom, etc=8A >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to registration function >>>>>>>>> O.6: The master device MAY register with the database according t= o >>>>>>>>> local >>>>>>>>> regulatory policy. Not all master devices will be required to >>>>>>>>> register. >>>>>>>>> Specific events will initiate registration, these events are >>>>>>>>> determined >>>>>>>>> by >>>>>>>>> regulator policy (e.g. at power up, after movement, etc=8A). >>>>>>>>> >>>>>>>>> >>>>>>>>> O.7: The master device MUST register with its most current and >>>>>>>>> up-to-date >>>>>>>>> information. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to hotspot use case >>>>>>>>> O.8: A master device MUST query the database for the available >>>>>>>>> channels >>>>>>>>> based on its current location before starting radio transmission >>>>>>>>> in >>>>>>>>> white >>>>>>>>> space. Parameters provided to the database MAY include device >>>>>>>>> location, >>>>>>>>> accuracy of the location, antenna characteristic information, >>>>>>>>> device >>>>>>>>> identifier of any slave device requesting channel information. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.9: The database MUST respond to an available channel list >>>>>>>>> request >>>>>>>>> from >>>>>>>>> an authenticated and authorized device and MAY also provide time >>>>>>>>> constraints, maximum output power, start and stop frequencies for >>>>>>>>> each >>>>>>>>> channel in the list and any additional requirements for sensing. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.10: After connecting to a master device=B9s radio network a sla= ve >>>>>>>>> device >>>>>>>>> MUST query the master device for a list of available channels. Th= e >>>>>>>>> slave >>>>>>>>> MUST include parameters required by local regulatory policy, e.g. >>>>>>>>> device >>>>>>>>> ID, device location. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.11: According to local regulatory policy, the master device MAY >>>>>>>>> query >>>>>>>>> the database with parameters received from the slave device. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.12: The database MUST respond to a query from the master device >>>>>>>>> containing parameters from a slave device. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.13: After the master device has received a response from the >>>>>>>>> database, >>>>>>>>> the master device MUST respond to the slave device. If all >>>>>>>>> regulatory >>>>>>>>> requirements are met the response will contain an available >>>>>>>>> channel >>>>>>>>> list. >>>>>>>>> If regulatory requirements are not met, the response MUST contain >>>>>>>>> at >>>>>>>>> least >>>>>>>>> a response code. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.14: If a master device has provided an available channel list >>>>>>>>> to a >>>>>>>>> slave >>>>>>>>> device the master device MAY send a periodic enabling signal to >>>>>>>>> allow >>>>>>>>> the >>>>>>>>> slave device to confirm it is still within reception range of the >>>>>>>>> master >>>>>>>>> device. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.15: The enabling signal MUST be encoded so that the receiving >>>>>>>>> slave >>>>>>>>> can >>>>>>>>> determine the identity of the sending master. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.16: Periodically, at an interval according to local regulations= , >>>>>>>>> the >>>>>>>>> slave device MUST either receive and enabling signal or MUST >>>>>>>>> successfully >>>>>>>>> repeat the channel request process or MUST cease transmission on >>>>>>>>> the >>>>>>>>> channel. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.17: A master device MUST repeat the query the database for the >>>>>>>>> available >>>>>>>>> channels as often as required by the regulation (eg, FCC requires >>>>>>>>> once >>>>>>>>> per >>>>>>>>> day) to verify that the operating channels continue to remain >>>>>>>>> available. >>>>>>>>> >>>>>>>>> >>>>>>>>> O.18: A master device which changes its location more than a >>>>>>>>> threshold >>>>>>>>> distance specified by local regulatory policy during its >>>>>>>>> operation, >>>>>>>>> MUST >>>>>>>>> query the database for available operating channels each time it >>>>>>>>> moves >>>>>>>>> more than the threshold distance (e.g., FCC specifies 100m) from >>>>>>>>> the >>>>>>>>> location it previously made the query. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to wran use case >>>>>>>>> O.19: If slave devices change their location during operation by >>>>>>>>> more >>>>>>>>> than >>>>>>>>> a limit specified by the local regulator, the slave device MUST >>>>>>>>> query >>>>>>>>> the >>>>>>>>> master device for available operating channels. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to rapid deployed network use >>>>>>>>> case>>>>>>>> Note> >>>>>>>>> O.20: According to local regulator policy, a master device may >>>>>>>>> contact a >>>>>>>>> database via proxy service of another master device. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to mobility use case >>>>>>>>> O.21: A master device MUST be able to query the whitespace >>>>>>>>> database >>>>>>>>> for >>>>>>>>> channel availability information for a specific expected coverage >>>>>>>>> area >>>>>>>>> around its current location. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> requirements related to threat model >>>>>>>>> O.22: A Master device MAY not include its identity in >>>>>>>>> messages sent to the database when not required by the regulatory >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 jstine@mitre.org Mon Feb 27 14:47:42 2012 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 8136121E8036 for ; Mon, 27 Feb 2012 14:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.304 X-Spam-Level: X-Spam-Status: No, score=-6.304 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tk+-qKSgmLsu for ; Mon, 27 Feb 2012 14:47:41 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7948B21E801E for ; Mon, 27 Feb 2012 14:47:41 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F3DFE21B1312; Mon, 27 Feb 2012 17:47:40 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DD85A21B07A1; Mon, 27 Feb 2012 17:47:40 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Mon, 27 Feb 2012 17:47:40 -0500 From: "Stine, John A." To: "Rosen, Brian" Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXAALSNGAAAmAxuA= Date: Mon, 27 Feb 2012 22:47:40 +0000 Message-ID: <2782C93FD2244441893673F3F9128192114DE5@IMCMBX01.MITRE.ORG> References: <2782C93FD2244441893673F3F9128192114D0B@IMCMBX01.MITRE.ORG> <3D628074-0010-46AC-BB4B-CD215B90BD37@neustar.biz> In-Reply-To: <3D628074-0010-46AC-BB4B-CD215B90BD37@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Further explanation of partitioned data models 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: Mon, 27 Feb 2012 22:47:42 -0000 Brian, I want to make it very clear that I am not advocating that in this go arou= nd that you add anything that increase the scope toward managing coexistenc= e or adding spectrum to the database. I used those as examples of future u= pgrades. I am just making recommendations that you don't do something now = that makes it more difficult to do something different in the future. I agree with your personal comment that most of your messaging would remai= n the same. However, I do not believe the administrative (i.e., regulatory= )data and spectrum use data that you will come up with for TV whitespace w= ill be rich enough to account for the many ways of sharing spectrum in the = future and the coordination that must take place. Trying to make it so now= will cause the very problem you are objecting to. It will complicate this = first effort. Proceeding on the assumption that it can be upgraded easily,= I believe, will be the original sin of PAWS and make upgrade very difficul= t. The first iteration of PAWS will affect other standards and those stand= ards will serve as inertia to upgrades. Creating a PAWS standard that allo= ws for the use of different data models simply keeps this from being a prob= lem. The legacy data model can be used with the legacy standard. A new da= ta model can be used with a new standard or a different band or different r= egulations. Consider this problem. In future upgrades, if coexistence were ever manag= ed, how would the different database administrators collaborate in defining= the boundaries between the TVWS users? Right now it is going to be the wi= ld west. Short range unlicensed is a different problem than long range unl= icensed. With the larger spaces of the TVWS frequencies there will be grea= ter potential for overlap of users and so interference among users. =20 John -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Monday, February 27, 2012 4:36 PM To: Stine, John A. Cc: paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models Discussions of spectrum coexistence is explicitly out of scope, and we have= a big enough job to do without increasing scope. The scope is also limited to the problem of a device requesting spectrum, a= nd discussions of provisioning ("releasing new spectrum") is out of scope. = Only the device-to-database query and its response is in scope. If we ever get to coexistence work, the additional messaging is some form o= f "use this explicit spectrum, I'm suggesting that you use it= , even if you could use other spectrum" or "of the choices yo= u gave me, I'll use this part, and please try and keep other users out of m= y way". Either is a simple expansion of the basic query (location and band= in, spectrum choices out). As such, I don't think we have to do anything = in anticipation of such a future capability. I do think the notion of authentication of the device and the database is i= n scope, and I certainly think exchange of credentials or equivalent prece= des spectrum query, so I suspect we're separating that part anyway. I cert= ainly think we're trying to return spectrum choices that depend on location= , device characteristics and things like time of day, and we're trying to d= esign a protocol that will work for any country that decides to open spectr= um for whitespace use and on any band they decide to do so. So long as we = have enough data elements in the query to allow any of the algorithms that = the regulators decide on to determine the available spectrum from the input= query and provisioning information in the database, as well as have suffic= ient flexibility in the response of available spectrum to cover all the lim= its the regulators want to have, we should be okay. So far, I don't see an= y problems staying within the model we have been talking about. Brian On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: > From the lack of response to my email last week, I assume folks just don'= t understand why I am recommending the division of the data model. Please = let me explain in a different way. >=20 > Last December, at the SDR Forum, Julius Knapp, the Director of the OET at= the FCC, hosted a panel attended by five of the ten database administrator= s. In that panel, he asked the panelists what was in it for them. Several= responded that they hoped they could provide a service to those looking fo= r spectrum and to help broker these arrangements. =20 >=20 > This is not the model of TVWS. At present, the urgency of the paws effor= t surrounds a narrower goal of enabling TVWS devices to obtain channels the= y can use. I do not want to make any suggestions that would prevent us fro= m achieving this goal first. I do want to make an effort to prevent what i= s done from becoming an impediment to a bigger role for whitespace database= administration in the future, one of managing coexistence and brokering sp= ectrum reuse. >=20 > In all methods of using a database where a device negotiates with a datab= ase, the types of messages that will be used are likely to be similar:=20 > - This is who I am, what rules should I apply in negotiating for spectrum= ? =20 > - This is the spectrum I am looking for, what do you have?=20 > - This is the spectrum that meets your query criteria. =20 > - etc. > The methods developed for trust are also reusable. This is the reason fo= r having a portion of the data model remain the same for all expansions. >=20 > The differences between a TVWS scenario and a brokering scenario are like= ly to be additional messaging and different data, both for the business of = brokering and for defining the spectrum authorization. For example, in the= brokering use case there needs to be a spectrum data model that allows a p= rimary spectrum user to release spectrum into the market, (e.g., provide th= eir contours ) and to specify the terms of use. My concern is that if the = data model of TVWS comingles the data of messaging, administration, and spe= ctrum; that this sort of expansion of paws would require increasing the siz= e of the data model and would make expanding its capability more difficult = both because of the impact of this expansion on legacy uses and because of = the confusion of using large schemas that have similar but different data e= lements. =20 >=20 > My solution is to divide the data model into three parts. The data docum= ent of messages would use the namespace of three schemas. In the TVWS edit= ion, this would also allow different administrative and spectrum schemas fo= r different regulatory domains. In end, the data for TVWS management would= not be any different, it would just be defined in three schemas >=20 > In the initial exchanges between a device and a database, there would be = agreement on which schemas to use. This is equivalent to resolving the reg= ulatory domain. The messaging that follows would be the exact same, with t= he exact same data as the messaging if a comingled data model were used. >=20 > If the division is done well, then, in the long term, others can create s= chemas for administration and spectrum definition that meets their business= needs without having to do so through paws. They would be able expand the= way the paws protocol is used without having to revise paws. >=20 > I hope this better explains my intent. It would also be helpful to under= stand why anyone thinks this should not be done. >=20 > John > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From scott.probasco@nokia.com Mon Feb 27 20:41:17 2012 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 BFB4021E8012 for ; Mon, 27 Feb 2012 20:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.562 X-Spam-Level: X-Spam-Status: No, score=-4.562 tagged_above=-999 required=5 tests=[AWL=1.881, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F95taVMexcsx for ; Mon, 27 Feb 2012 20:41:14 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id B737F21E8011 for ; Mon, 27 Feb 2012 20:41:13 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1S4exQ5028441; Tue, 28 Feb 2012 06:41:09 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 06:41:04 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.01.0355.003; Tue, 28 Feb 2012 05:41:03 +0100 From: To: , Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXP//9bGAgAAT6gD///4kAA== Date: Tue, 28 Feb 2012 04:41:02 +0000 Message-ID: In-Reply-To: <2782C93FD2244441893673F3F9128192114DE5@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.241.164.215] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 04:41:04.0154 (UTC) FILETIME=[2DC2AFA0:01CCF5D3] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models 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, 28 Feb 2012 04:41:17 -0000 Hi, As a way forward, how about two additional requirements D.X The Data Model MUST be extensible. P.X The protocol MUST be extensible. This captures the desire to extend both the Data Model and the protocol in the future, without identifying a specific solution at this time. Kind Regards, Scott On 2/27/12 4:47 PM, "ext Stine, John A." wrote: >Brian, > > I want to make it very clear that I am not advocating that in this go >around that you add anything that increase the scope toward managing >coexistence or adding spectrum to the database. I used those as examples >of future upgrades. I am just making recommendations that you don't do >something now that makes it more difficult to do something different in >the future. > > I agree with your personal comment that most of your messaging would >remain the same. However, I do not believe the administrative (i.e., >regulatory )data and spectrum use data that you will come up with for TV >whitespace will be rich enough to account for the many ways of sharing >spectrum in the future and the coordination that must take place. Trying >to make it so now will cause the very problem you are objecting to. It >will complicate this first effort. Proceeding on the assumption that it >can be upgraded easily, I believe, will be the original sin of PAWS and >make upgrade very difficult. The first iteration of PAWS will affect >other standards and those standards will serve as inertia to upgrades. >Creating a PAWS standard that allows for the use of different data models >simply keeps this from being a problem. The legacy data model can be >used with the legacy standard. A new data model can be used with a new >standard or a different band or different regulations. > > Consider this problem. In future upgrades, if coexistence were ever >managed, how would the different database administrators collaborate in >defining the boundaries between the TVWS users? Right now it is going to >be the wild west. Short range unlicensed is a different problem than >long range unlicensed. With the larger spaces of the TVWS frequencies >there will be greater potential for overlap of users and so interference >among users. =20 > >John > >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: Monday, February 27, 2012 4:36 PM >To: Stine, John A. >Cc: paws@ietf.org >Subject: Re: [paws] Further explanation of partitioned data models > > >Discussions of spectrum coexistence is explicitly out of scope, and we >have a big enough job to do without increasing scope. >The scope is also limited to the problem of a device requesting spectrum, >and discussions of provisioning ("releasing new spectrum") is out of >scope. Only the device-to-database query and its response is in scope. > > >If we ever get to coexistence work, the additional messaging is some form >of "use this explicit spectrum, I'm suggesting that you use >it, even if you could use other spectrum" or "of the >choices you gave me, I'll use this part, and please try and keep other >users out of my way". Either is a simple expansion of the basic query >(location and band in, spectrum choices out). As such, I don't think we >have to do anything in anticipation of such a future capability. > >I do think the notion of authentication of the device and the database is >in scope, and I certainly think exchange of credentials or equivalent >precedes spectrum query, so I suspect we're separating that part anyway. >I certainly think we're trying to return spectrum choices that depend on >location, device characteristics and things like time of day, and we're >trying to design a protocol that will work for any country that decides >to open spectrum for whitespace use and on any band they decide to do so. > So long as we have enough data elements in the query to allow any of the >algorithms that the regulators decide on to determine the available >spectrum from the input query and provisioning information in the >database, as well as have sufficient flexibility in the response of >available spectrum to cover all the limits the regulators want to have, >we should be okay. So far, I don't see any problems staying within the >model we have been talking about. > >Brian > >On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: > >> From the lack of response to my email last week, I assume folks just >>don't understand why I am recommending the division of the data model. >>Please let me explain in a different way. >>=20 >> Last December, at the SDR Forum, Julius Knapp, the Director of the OET >>at the FCC, hosted a panel attended by five of the ten database >>administrators. In that panel, he asked the panelists what was in it >>for them. Several responded that they hoped they could provide a >>service to those looking for spectrum and to help broker these >>arrangements. =20 >>=20 >> This is not the model of TVWS. At present, the urgency of the paws >>effort surrounds a narrower goal of enabling TVWS devices to obtain >>channels they can use. I do not want to make any suggestions that would >>prevent us from achieving this goal first. I do want to make an effort >>to prevent what is done from becoming an impediment to a bigger role for >>whitespace database administration in the future, one of managing >>coexistence and brokering spectrum reuse. >>=20 >> In all methods of using a database where a device negotiates with a >>database, the types of messages that will be used are likely to be >>similar:=20 >> - This is who I am, what rules should I apply in negotiating for >>spectrum? =20 >> - This is the spectrum I am looking for, what do you have? >> - This is the spectrum that meets your query criteria. >> - etc. >> The methods developed for trust are also reusable. This is the reason >>for having a portion of the data model remain the same for all >>expansions. >>=20 >> The differences between a TVWS scenario and a brokering scenario are >>likely to be additional messaging and different data, both for the >>business of brokering and for defining the spectrum authorization. For >>example, in the brokering use case there needs to be a spectrum data >>model that allows a primary spectrum user to release spectrum into the >>market, (e.g., provide their contours ) and to specify the terms of use. >> My concern is that if the data model of TVWS comingles the data of >>messaging, administration, and spectrum; that this sort of expansion of >>paws would require increasing the size of the data model and would make >>expanding its capability more difficult both because of the impact of >>this expansion on legacy uses and because of the confusion of using >>large schemas that have similar but different data elements. >>=20 >> My solution is to divide the data model into three parts. The data >>document of messages would use the namespace of three schemas. In the >>TVWS edition, this would also allow different administrative and >>spectrum schemas for different regulatory domains. In end, the data for >>TVWS management would not be any different, it would just be defined in >>three schemas >>=20 >> In the initial exchanges between a device and a database, there would >>be agreement on which schemas to use. This is equivalent to resolving >>the regulatory domain. The messaging that follows would be the exact >>same, with the exact same data as the messaging if a comingled data >>model were used. >>=20 >> If the division is done well, then, in the long term, others can create >>schemas for administration and spectrum definition that meets their >>business needs without having to do so through paws. They would be able >>expand the way the paws protocol is used without having to revise paws. >>=20 >> I hope this better explains my intent. It would also be helpful to >>understand why anyone thinks this should not be done. >>=20 >> John >> _______________________________________________ >> 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 lei.zhu@huawei.com Tue Feb 28 01:29:26 2012 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 BE80021F84F1 for ; Tue, 28 Feb 2012 01:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[AWL=-2.049, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3le42zyl9iP for ; Tue, 28 Feb 2012 01:29:25 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7DD21F84DD for ; Tue, 28 Feb 2012 01:29:24 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0300M3PJOF9E@szxga05-in.huawei.com> for paws@ietf.org; Tue, 28 Feb 2012 17:29:03 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0300JBMJODKW@szxga05-in.huawei.com> for paws@ietf.org; Tue, 28 Feb 2012 17:29:02 +0800 (CST) Received: from szxeml212-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHC63691; Tue, 28 Feb 2012 17:29:02 +0800 Received: from SZXEML425-HUB.china.huawei.com (10.72.61.33) by szxeml212-edg.china.huawei.com (172.24.2.181) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 28 Feb 2012 17:28:53 +0800 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.8]) by szxeml425-hub.china.huawei.com ([10.72.61.33]) with mapi id 14.01.0323.003; Tue, 28 Feb 2012 17:28:57 +0800 Date: Tue, 28 Feb 2012 09:28:56 +0000 From: ZhuLei In-reply-to: X-Originating-IP: [10.108.64.160] To: "scott.probasco@nokia.com" , "jstine@mitre.org" , "Brian.Rosen@neustar.biz" Message-id: <470F27D1263A1B4EB73491ED995DE625147A7245@szxeml504-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [paws] Further explanation of partitioned data models Thread-index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXP//gFiAgAAT6wCAAGK6AP//KmLQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2782C93FD2244441893673F3F9128192114DE5@IMCMBX01.MITRE.ORG> Cc: "paws@ietf.org" Subject: Re: [paws] Further explanation of partitioned data models 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, 28 Feb 2012 09:29:26 -0000 SGkgYWxsLA0KDQpJIHRoaW5rIHRoYXQgSSBwaWNrZWQgdXAgdGhpcyBjb25jZXB0IG9mIHByb3Rv Y29sIGRlc2lnbiBhIGNvdXBsZSBvZiBtb250aHMgYmVmb3JlLiBXaGF0IEkgd2FudCB0byByZWNh bGwgaXMgdGhhdCBJIGFzc3VtZWQgdGhlIGZyYW1ld29yayBvZiBwcm90b2NvbCBpcyBleHRlbnNp YmxlLg0KDQpCciwNClpodSBMZWkNCg0KLS0tLS3Tyrz+1K28/i0tLS0tDQq3orz+yMs6IHBhd3Mt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBzY290 dC5wcm9iYXNjb0Bub2tpYS5jb20NCreiy83KsbzkOiAyMDEyxOoy1MIyOMjVIDEyOjQxDQrK1bz+ yMs6IGpzdGluZUBtaXRyZS5vcmc7IEJyaWFuLlJvc2VuQG5ldXN0YXIuYml6DQqzrcvNOiBwYXdz QGlldGYub3JnDQrW98ziOiBSZTogW3Bhd3NdIEZ1cnRoZXIgZXhwbGFuYXRpb24gb2YgcGFydGl0 aW9uZWQgZGF0YSBtb2RlbHMNCg0KSGksDQoNCkFzIGEgd2F5IGZvcndhcmQsIGhvdyBhYm91dCB0 d28gYWRkaXRpb25hbCByZXF1aXJlbWVudHMNCg0KRC5YIFRoZSBEYXRhIE1vZGVsIE1VU1QgYmUg ZXh0ZW5zaWJsZS4NCg0KUC5YIFRoZSBwcm90b2NvbCBNVVNUIGJlIGV4dGVuc2libGUuDQoNClRo aXMgY2FwdHVyZXMgdGhlIGRlc2lyZSB0byBleHRlbmQgYm90aCB0aGUgRGF0YSBNb2RlbCBhbmQg dGhlIHByb3RvY29sIGluDQp0aGUgZnV0dXJlLCB3aXRob3V0IGlkZW50aWZ5aW5nIGEgc3BlY2lm aWMgc29sdXRpb24gYXQgdGhpcyB0aW1lLg0KDQpLaW5kIFJlZ2FyZHMsDQpTY290dA0KDQoNCg0K DQpPbiAyLzI3LzEyIDQ6NDcgUE0sICJleHQgU3RpbmUsIEpvaG4gQS4iIDxqc3RpbmVAbWl0cmUu b3JnPiB3cm90ZToNCg0KPkJyaWFuLA0KPg0KPglJIHdhbnQgdG8gbWFrZSBpdCB2ZXJ5IGNsZWFy IHRoYXQgSSBhbSBub3QgYWR2b2NhdGluZyB0aGF0IGluIHRoaXMgZ28NCj5hcm91bmQgdGhhdCB5 b3UgYWRkIGFueXRoaW5nIHRoYXQgaW5jcmVhc2UgdGhlIHNjb3BlIHRvd2FyZCBtYW5hZ2luZw0K PmNvZXhpc3RlbmNlIG9yIGFkZGluZyBzcGVjdHJ1bSB0byB0aGUgZGF0YWJhc2UuICBJIHVzZWQg dGhvc2UgYXMgZXhhbXBsZXMNCj5vZiBmdXR1cmUgdXBncmFkZXMuICBJIGFtIGp1c3QgbWFraW5n IHJlY29tbWVuZGF0aW9ucyB0aGF0IHlvdSBkb24ndCBkbw0KPnNvbWV0aGluZyBub3cgdGhhdCBt YWtlcyBpdCBtb3JlIGRpZmZpY3VsdCB0byBkbyBzb21ldGhpbmcgZGlmZmVyZW50IGluDQo+dGhl IGZ1dHVyZS4NCj4NCj4JSSBhZ3JlZSB3aXRoIHlvdXIgcGVyc29uYWwgY29tbWVudCB0aGF0IG1v c3Qgb2YgeW91ciBtZXNzYWdpbmcgd291bGQNCj5yZW1haW4gdGhlIHNhbWUuICBIb3dldmVyLCBJ IGRvIG5vdCBiZWxpZXZlIHRoZSBhZG1pbmlzdHJhdGl2ZSAoaS5lLiwNCj5yZWd1bGF0b3J5IClk YXRhIGFuZCBzcGVjdHJ1bSB1c2UgZGF0YSB0aGF0IHlvdSB3aWxsIGNvbWUgdXAgd2l0aCBmb3Ig VFYNCj53aGl0ZXNwYWNlIHdpbGwgYmUgcmljaCBlbm91Z2ggdG8gYWNjb3VudCBmb3IgdGhlIG1h bnkgd2F5cyBvZiBzaGFyaW5nDQo+c3BlY3RydW0gaW4gdGhlIGZ1dHVyZSBhbmQgdGhlIGNvb3Jk aW5hdGlvbiB0aGF0IG11c3QgdGFrZSBwbGFjZS4gIFRyeWluZw0KPnRvIG1ha2UgaXQgc28gbm93 IHdpbGwgY2F1c2UgdGhlIHZlcnkgcHJvYmxlbSB5b3UgYXJlIG9iamVjdGluZyB0by4gSXQNCj53 aWxsIGNvbXBsaWNhdGUgdGhpcyBmaXJzdCBlZmZvcnQuICBQcm9jZWVkaW5nIG9uIHRoZSBhc3N1 bXB0aW9uIHRoYXQgaXQNCj5jYW4gYmUgdXBncmFkZWQgZWFzaWx5LCBJIGJlbGlldmUsIHdpbGwg YmUgdGhlIG9yaWdpbmFsIHNpbiBvZiBQQVdTIGFuZA0KPm1ha2UgdXBncmFkZSB2ZXJ5IGRpZmZp Y3VsdC4gIFRoZSBmaXJzdCBpdGVyYXRpb24gb2YgUEFXUyB3aWxsIGFmZmVjdA0KPm90aGVyIHN0 YW5kYXJkcyBhbmQgdGhvc2Ugc3RhbmRhcmRzIHdpbGwgc2VydmUgYXMgaW5lcnRpYSB0byB1cGdy YWRlcy4NCj5DcmVhdGluZyBhIFBBV1Mgc3RhbmRhcmQgdGhhdCBhbGxvd3MgZm9yIHRoZSB1c2Ug b2YgZGlmZmVyZW50IGRhdGEgbW9kZWxzDQo+c2ltcGx5IGtlZXBzIHRoaXMgZnJvbSBiZWluZyBh IHByb2JsZW0uICBUaGUgbGVnYWN5IGRhdGEgbW9kZWwgY2FuIGJlDQo+dXNlZCB3aXRoIHRoZSBs ZWdhY3kgc3RhbmRhcmQuICBBIG5ldyBkYXRhIG1vZGVsIGNhbiBiZSB1c2VkIHdpdGggYSBuZXcN Cj5zdGFuZGFyZCBvciBhIGRpZmZlcmVudCBiYW5kIG9yIGRpZmZlcmVudCByZWd1bGF0aW9ucy4N Cj4NCj4JQ29uc2lkZXIgdGhpcyBwcm9ibGVtLiAgSW4gZnV0dXJlIHVwZ3JhZGVzLCBpZiBjb2V4 aXN0ZW5jZSB3ZXJlIGV2ZXINCj5tYW5hZ2VkLCBob3cgd291bGQgdGhlIGRpZmZlcmVudCBkYXRh YmFzZSBhZG1pbmlzdHJhdG9ycyBjb2xsYWJvcmF0ZSBpbg0KPmRlZmluaW5nIHRoZSBib3VuZGFy aWVzIGJldHdlZW4gdGhlIFRWV1MgdXNlcnM/ICBSaWdodCBub3cgaXQgaXMgZ29pbmcgdG8NCj5i ZSB0aGUgd2lsZCB3ZXN0LiAgU2hvcnQgcmFuZ2UgdW5saWNlbnNlZCBpcyBhIGRpZmZlcmVudCBw cm9ibGVtIHRoYW4NCj5sb25nIHJhbmdlIHVubGljZW5zZWQuICBXaXRoIHRoZSBsYXJnZXIgc3Bh Y2VzIG9mIHRoZSBUVldTIGZyZXF1ZW5jaWVzDQo+dGhlcmUgd2lsbCBiZSBncmVhdGVyIHBvdGVu dGlhbCBmb3Igb3ZlcmxhcCBvZiB1c2VycyBhbmQgc28gaW50ZXJmZXJlbmNlDQo+YW1vbmcgdXNl cnMuICANCj4NCj5Kb2huDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBS b3NlbiwgQnJpYW4gW21haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpel0NCj5TZW50OiBNb25k YXksIEZlYnJ1YXJ5IDI3LCAyMDEyIDQ6MzYgUE0NCj5UbzogU3RpbmUsIEpvaG4gQS4NCj5DYzog cGF3c0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbcGF3c10gRnVydGhlciBleHBsYW5hdGlvbiBv ZiBwYXJ0aXRpb25lZCBkYXRhIG1vZGVscw0KPg0KPjxBcyBjaGFpcj4NCj5EaXNjdXNzaW9ucyBv ZiBzcGVjdHJ1bSBjb2V4aXN0ZW5jZSBpcyBleHBsaWNpdGx5IG91dCBvZiBzY29wZSwgYW5kIHdl DQo+aGF2ZSBhIGJpZyBlbm91Z2ggam9iIHRvIGRvIHdpdGhvdXQgaW5jcmVhc2luZyBzY29wZS4N Cj5UaGUgc2NvcGUgaXMgYWxzbyBsaW1pdGVkIHRvIHRoZSBwcm9ibGVtIG9mIGEgZGV2aWNlIHJl cXVlc3Rpbmcgc3BlY3RydW0sDQo+YW5kIGRpc2N1c3Npb25zIG9mIHByb3Zpc2lvbmluZyAoInJl bGVhc2luZyBuZXcgc3BlY3RydW0iKSBpcyBvdXQgb2YNCj5zY29wZS4gIE9ubHkgdGhlIGRldmlj ZS10by1kYXRhYmFzZSBxdWVyeSBhbmQgaXRzIHJlc3BvbnNlIGlzIGluIHNjb3BlLg0KPg0KPjxh cyBpbmRpdmlkdWFsPg0KPklmIHdlIGV2ZXIgZ2V0IHRvIGNvZXhpc3RlbmNlIHdvcmssIHRoZSBh ZGRpdGlvbmFsIG1lc3NhZ2luZyBpcyBzb21lIGZvcm0NCj5vZiA8REIgdG8gZGV2aWNlPiJ1c2Ug dGhpcyBleHBsaWNpdCBzcGVjdHJ1bSwgSSdtIHN1Z2dlc3RpbmcgdGhhdCB5b3UgdXNlDQo+aXQs IGV2ZW4gaWYgeW91IGNvdWxkIHVzZSBvdGhlciBzcGVjdHJ1bSIgb3IgPGRldmljZSB0byBkYj4i b2YgdGhlDQo+Y2hvaWNlcyB5b3UgZ2F2ZSBtZSwgSSdsbCB1c2UgdGhpcyBwYXJ0LCBhbmQgcGxl YXNlIHRyeSBhbmQga2VlcCBvdGhlcg0KPnVzZXJzIG91dCBvZiBteSB3YXkiLiAgRWl0aGVyIGlz IGEgc2ltcGxlIGV4cGFuc2lvbiBvZiB0aGUgYmFzaWMgcXVlcnkNCj4obG9jYXRpb24gYW5kIGJh bmQgaW4sIHNwZWN0cnVtIGNob2ljZXMgb3V0KS4gIEFzIHN1Y2gsIEkgZG9uJ3QgdGhpbmsgd2UN Cj5oYXZlIHRvIGRvIGFueXRoaW5nIGluIGFudGljaXBhdGlvbiBvZiBzdWNoIGEgZnV0dXJlIGNh cGFiaWxpdHkuDQo+DQo+SSBkbyB0aGluayB0aGUgbm90aW9uIG9mIGF1dGhlbnRpY2F0aW9uIG9m IHRoZSBkZXZpY2UgYW5kIHRoZSBkYXRhYmFzZSBpcw0KPmluIHNjb3BlLCBhbmQgSSBjZXJ0YWlu bHkgdGhpbmsgZXhjaGFuZ2Ugb2YgIGNyZWRlbnRpYWxzIG9yIGVxdWl2YWxlbnQNCj5wcmVjZWRl cyBzcGVjdHJ1bSBxdWVyeSwgc28gSSBzdXNwZWN0IHdlJ3JlIHNlcGFyYXRpbmcgdGhhdCBwYXJ0 IGFueXdheS4NCj5JIGNlcnRhaW5seSB0aGluayB3ZSdyZSB0cnlpbmcgdG8gcmV0dXJuIHNwZWN0 cnVtIGNob2ljZXMgdGhhdCBkZXBlbmQgb24NCj5sb2NhdGlvbiwgZGV2aWNlIGNoYXJhY3Rlcmlz dGljcyBhbmQgdGhpbmdzIGxpa2UgdGltZSBvZiBkYXksIGFuZCB3ZSdyZQ0KPnRyeWluZyB0byBk ZXNpZ24gYSBwcm90b2NvbCB0aGF0IHdpbGwgd29yayBmb3IgYW55IGNvdW50cnkgdGhhdCBkZWNp ZGVzDQo+dG8gb3BlbiBzcGVjdHJ1bSBmb3Igd2hpdGVzcGFjZSB1c2UgYW5kIG9uIGFueSBiYW5k IHRoZXkgZGVjaWRlIHRvIGRvIHNvLg0KPiBTbyBsb25nIGFzIHdlIGhhdmUgZW5vdWdoIGRhdGEg ZWxlbWVudHMgaW4gdGhlIHF1ZXJ5IHRvIGFsbG93IGFueSBvZiB0aGUNCj5hbGdvcml0aG1zIHRo YXQgdGhlIHJlZ3VsYXRvcnMgZGVjaWRlIG9uIHRvIGRldGVybWluZSB0aGUgYXZhaWxhYmxlDQo+ c3BlY3RydW0gZnJvbSB0aGUgaW5wdXQgcXVlcnkgYW5kIHByb3Zpc2lvbmluZyBpbmZvcm1hdGlv biBpbiB0aGUNCj5kYXRhYmFzZSwgYXMgd2VsbCBhcyBoYXZlIHN1ZmZpY2llbnQgZmxleGliaWxp dHkgaW4gdGhlIHJlc3BvbnNlIG9mDQo+YXZhaWxhYmxlIHNwZWN0cnVtIHRvIGNvdmVyIGFsbCB0 aGUgbGltaXRzIHRoZSByZWd1bGF0b3JzIHdhbnQgdG8gaGF2ZSwNCj53ZSBzaG91bGQgYmUgb2th eS4gIFNvIGZhciwgSSBkb24ndCBzZWUgYW55IHByb2JsZW1zIHN0YXlpbmcgd2l0aGluIHRoZQ0K Pm1vZGVsIHdlIGhhdmUgYmVlbiB0YWxraW5nIGFib3V0Lg0KPg0KPkJyaWFuDQo+DQo+T24gRmVi IDI3LCAyMDEyLCBhdCA0OjEzIFBNLCBTdGluZSwgSm9obiBBLiB3cm90ZToNCj4NCj4+IEZyb20g dGhlIGxhY2sgb2YgcmVzcG9uc2UgdG8gbXkgZW1haWwgbGFzdCB3ZWVrLCBJIGFzc3VtZSBmb2xr cyBqdXN0DQo+PmRvbid0IHVuZGVyc3RhbmQgd2h5IEkgYW0gcmVjb21tZW5kaW5nIHRoZSBkaXZp c2lvbiBvZiB0aGUgZGF0YSBtb2RlbC4NCj4+UGxlYXNlIGxldCBtZSBleHBsYWluIGluIGEgZGlm ZmVyZW50IHdheS4NCj4+IA0KPj4gTGFzdCBEZWNlbWJlciwgYXQgdGhlIFNEUiBGb3J1bSwgSnVs aXVzIEtuYXBwLCB0aGUgRGlyZWN0b3Igb2YgdGhlIE9FVA0KPj5hdCB0aGUgRkNDLCBob3N0ZWQg YSBwYW5lbCBhdHRlbmRlZCBieSBmaXZlIG9mIHRoZSB0ZW4gZGF0YWJhc2UNCj4+YWRtaW5pc3Ry YXRvcnMuICBJbiB0aGF0IHBhbmVsLCBoZSBhc2tlZCB0aGUgcGFuZWxpc3RzIHdoYXQgd2FzIGlu IGl0DQo+PmZvciB0aGVtLiAgU2V2ZXJhbCByZXNwb25kZWQgdGhhdCB0aGV5IGhvcGVkIHRoZXkg Y291bGQgcHJvdmlkZSBhDQo+PnNlcnZpY2UgdG8gdGhvc2UgbG9va2luZyBmb3Igc3BlY3RydW0g YW5kIHRvIGhlbHAgYnJva2VyIHRoZXNlDQo+PmFycmFuZ2VtZW50cy4gIA0KPj4gDQo+PiBUaGlz IGlzIG5vdCB0aGUgbW9kZWwgb2YgVFZXUy4gIEF0IHByZXNlbnQsIHRoZSB1cmdlbmN5IG9mIHRo ZSBwYXdzDQo+PmVmZm9ydCBzdXJyb3VuZHMgYSBuYXJyb3dlciBnb2FsIG9mIGVuYWJsaW5nIFRW V1MgZGV2aWNlcyB0byBvYnRhaW4NCj4+Y2hhbm5lbHMgdGhleSBjYW4gdXNlLiAgSSBkbyBub3Qg d2FudCB0byBtYWtlIGFueSBzdWdnZXN0aW9ucyB0aGF0IHdvdWxkDQo+PnByZXZlbnQgdXMgZnJv bSBhY2hpZXZpbmcgdGhpcyBnb2FsIGZpcnN0LiAgSSBkbyB3YW50IHRvIG1ha2UgYW4gZWZmb3J0 DQo+PnRvIHByZXZlbnQgd2hhdCBpcyBkb25lIGZyb20gYmVjb21pbmcgYW4gaW1wZWRpbWVudCB0 byBhIGJpZ2dlciByb2xlIGZvcg0KPj53aGl0ZXNwYWNlIGRhdGFiYXNlIGFkbWluaXN0cmF0aW9u IGluIHRoZSBmdXR1cmUsIG9uZSBvZiBtYW5hZ2luZw0KPj5jb2V4aXN0ZW5jZSBhbmQgYnJva2Vy aW5nIHNwZWN0cnVtIHJldXNlLg0KPj4gDQo+PiBJbiBhbGwgbWV0aG9kcyBvZiB1c2luZyBhIGRh dGFiYXNlIHdoZXJlIGEgZGV2aWNlIG5lZ290aWF0ZXMgd2l0aCBhDQo+PmRhdGFiYXNlLCB0aGUg dHlwZXMgb2YgbWVzc2FnZXMgdGhhdCB3aWxsIGJlIHVzZWQgYXJlIGxpa2VseSB0byBiZQ0KPj5z aW1pbGFyOiANCj4+IC0gVGhpcyBpcyB3aG8gSSBhbSwgd2hhdCBydWxlcyBzaG91bGQgSSBhcHBs eSBpbiBuZWdvdGlhdGluZyBmb3INCj4+c3BlY3RydW0/ICANCj4+IC0gVGhpcyBpcyB0aGUgc3Bl Y3RydW0gSSBhbSBsb29raW5nIGZvciwgd2hhdCBkbyB5b3UgaGF2ZT8NCj4+IC0gVGhpcyBpcyB0 aGUgc3BlY3RydW0gdGhhdCBtZWV0cyB5b3VyIHF1ZXJ5IGNyaXRlcmlhLg0KPj4gLSBldGMuDQo+ PiBUaGUgbWV0aG9kcyBkZXZlbG9wZWQgZm9yIHRydXN0IGFyZSBhbHNvIHJldXNhYmxlLiAgVGhp cyBpcyB0aGUgcmVhc29uDQo+PmZvciBoYXZpbmcgYSBwb3J0aW9uIG9mIHRoZSBkYXRhIG1vZGVs IHJlbWFpbiB0aGUgc2FtZSBmb3IgYWxsDQo+PmV4cGFuc2lvbnMuDQo+PiANCj4+IFRoZSBkaWZm ZXJlbmNlcyBiZXR3ZWVuIGEgVFZXUyBzY2VuYXJpbyBhbmQgYSBicm9rZXJpbmcgc2NlbmFyaW8g YXJlDQo+Pmxpa2VseSB0byBiZSBhZGRpdGlvbmFsIG1lc3NhZ2luZyBhbmQgZGlmZmVyZW50IGRh dGEsIGJvdGggZm9yIHRoZQ0KPj5idXNpbmVzcyBvZiBicm9rZXJpbmcgYW5kIGZvciBkZWZpbmlu ZyB0aGUgc3BlY3RydW0gYXV0aG9yaXphdGlvbi4gIEZvcg0KPj5leGFtcGxlLCBpbiB0aGUgYnJv a2VyaW5nIHVzZSBjYXNlIHRoZXJlIG5lZWRzIHRvIGJlIGEgc3BlY3RydW0gZGF0YQ0KPj5tb2Rl bCB0aGF0IGFsbG93cyBhIHByaW1hcnkgc3BlY3RydW0gdXNlciB0byByZWxlYXNlIHNwZWN0cnVt IGludG8gdGhlDQo+Pm1hcmtldCwgKGUuZy4sIHByb3ZpZGUgdGhlaXIgY29udG91cnMgKSBhbmQg dG8gc3BlY2lmeSB0aGUgdGVybXMgb2YgdXNlLg0KPj4gTXkgY29uY2VybiBpcyB0aGF0IGlmIHRo ZSBkYXRhIG1vZGVsIG9mIFRWV1MgY29taW5nbGVzIHRoZSBkYXRhIG9mDQo+Pm1lc3NhZ2luZywg YWRtaW5pc3RyYXRpb24sIGFuZCBzcGVjdHJ1bTsgdGhhdCB0aGlzIHNvcnQgb2YgZXhwYW5zaW9u IG9mDQo+PnBhd3Mgd291bGQgcmVxdWlyZSBpbmNyZWFzaW5nIHRoZSBzaXplIG9mIHRoZSBkYXRh IG1vZGVsIGFuZCB3b3VsZCBtYWtlDQo+PmV4cGFuZGluZyBpdHMgY2FwYWJpbGl0eSBtb3JlIGRp ZmZpY3VsdCBib3RoIGJlY2F1c2Ugb2YgdGhlIGltcGFjdCBvZg0KPj50aGlzIGV4cGFuc2lvbiBv biBsZWdhY3kgdXNlcyBhbmQgYmVjYXVzZSBvZiB0aGUgY29uZnVzaW9uIG9mIHVzaW5nDQo+Pmxh cmdlIHNjaGVtYXMgdGhhdCBoYXZlIHNpbWlsYXIgYnV0IGRpZmZlcmVudCBkYXRhIGVsZW1lbnRz Lg0KPj4gDQo+PiBNeSBzb2x1dGlvbiBpcyB0byBkaXZpZGUgdGhlIGRhdGEgbW9kZWwgaW50byB0 aHJlZSBwYXJ0cy4gIFRoZSBkYXRhDQo+PmRvY3VtZW50IG9mIG1lc3NhZ2VzIHdvdWxkIHVzZSB0 aGUgbmFtZXNwYWNlIG9mIHRocmVlIHNjaGVtYXMuICBJbiB0aGUNCj4+VFZXUyBlZGl0aW9uLCB0 aGlzIHdvdWxkIGFsc28gYWxsb3cgZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIGFuZA0KPj5zcGVj dHJ1bSBzY2hlbWFzIGZvciBkaWZmZXJlbnQgcmVndWxhdG9yeSBkb21haW5zLiAgSW4gZW5kLCB0 aGUgZGF0YSBmb3INCj4+VFZXUyBtYW5hZ2VtZW50IHdvdWxkIG5vdCBiZSBhbnkgZGlmZmVyZW50 LCBpdCB3b3VsZCBqdXN0IGJlIGRlZmluZWQgaW4NCj4+dGhyZWUgc2NoZW1hcw0KPj4gDQo+PiBJ biB0aGUgaW5pdGlhbCBleGNoYW5nZXMgYmV0d2VlbiBhIGRldmljZSBhbmQgYSBkYXRhYmFzZSwg dGhlcmUgd291bGQNCj4+YmUgYWdyZWVtZW50IG9uIHdoaWNoIHNjaGVtYXMgdG8gdXNlLiAgVGhp cyBpcyBlcXVpdmFsZW50IHRvIHJlc29sdmluZw0KPj50aGUgcmVndWxhdG9yeSBkb21haW4uICBU aGUgbWVzc2FnaW5nIHRoYXQgZm9sbG93cyB3b3VsZCBiZSB0aGUgZXhhY3QNCj4+c2FtZSwgd2l0 aCB0aGUgZXhhY3Qgc2FtZSBkYXRhIGFzIHRoZSBtZXNzYWdpbmcgaWYgYSBjb21pbmdsZWQgZGF0 YQ0KPj5tb2RlbCB3ZXJlIHVzZWQuDQo+PiANCj4+IElmIHRoZSBkaXZpc2lvbiBpcyBkb25lIHdl bGwsIHRoZW4sIGluIHRoZSBsb25nIHRlcm0sIG90aGVycyBjYW4gY3JlYXRlDQo+PnNjaGVtYXMg Zm9yIGFkbWluaXN0cmF0aW9uIGFuZCBzcGVjdHJ1bSBkZWZpbml0aW9uIHRoYXQgbWVldHMgdGhl aXINCj4+YnVzaW5lc3MgbmVlZHMgd2l0aG91dCBoYXZpbmcgdG8gZG8gc28gdGhyb3VnaCBwYXdz LiAgVGhleSB3b3VsZCBiZSBhYmxlDQo+PmV4cGFuZCB0aGUgd2F5IHRoZSBwYXdzIHByb3RvY29s IGlzIHVzZWQgd2l0aG91dCBoYXZpbmcgdG8gcmV2aXNlIHBhd3MuDQo+PiANCj4+IEkgaG9wZSB0 aGlzIGJldHRlciBleHBsYWlucyBteSBpbnRlbnQuICBJdCB3b3VsZCBhbHNvIGJlIGhlbHBmdWwg dG8NCj4+dW5kZXJzdGFuZCB3aHkgYW55b25lIHRoaW5rcyB0aGlzIHNob3VsZCBub3QgYmUgZG9u ZS4NCj4+IA0KPj4gSm9obg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+IHBhd3MgbWFpbGluZyBsaXN0DQo+PiBwYXdzQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCj4NCj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnBhd3MgbWFpbGluZyBsaXN0 DQo+cGF3c0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cGF3cw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K cGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcGF3cw0K From jstine@mitre.org Tue Feb 28 03:11:58 2012 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 1420D21F85F2 for ; Tue, 28 Feb 2012 03:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASbtJAyYbPo4 for ; Tue, 28 Feb 2012 03:11:56 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id ABEC821F85EC for ; Tue, 28 Feb 2012 03:11:56 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8A73721B0281; Tue, 28 Feb 2012 06:11:55 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7518821B0235; Tue, 28 Feb 2012 06:11:55 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.01.0339.001; Tue, 28 Feb 2012 06:11:55 -0500 From: "Stine, John A." To: "scott.probasco@nokia.com" , "Brian.Rosen@neustar.biz" Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXAALSNGAAAmAxuAABVPlAAACnDBQ Date: Tue, 28 Feb 2012 11:11:55 +0000 Message-ID: <2782C93FD2244441893673F3F9128192115030@IMCMBX01.MITRE.ORG> References: <2782C93FD2244441893673F3F9128192114DE5@IMCMBX01.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Further explanation of partitioned data models 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, 28 Feb 2012 11:11:58 -0000 Hi, For now this should be fine. I hope I have made my point well so extensib= ility does not become interpreted to mean add more messaging and add more e= lements to the data model. Modularity is a powerful means to enable extens= ibility. John=20 -----Original Message----- From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Monday, February 27, 2012 11:41 PM To: Stine, John A.; Brian.Rosen@neustar.biz Cc: paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models Hi, As a way forward, how about two additional requirements D.X The Data Model MUST be extensible. P.X The protocol MUST be extensible. This captures the desire to extend both the Data Model and the protocol in the future, without identifying a specific solution at this time. Kind Regards, Scott On 2/27/12 4:47 PM, "ext Stine, John A." wrote: >Brian, > > I want to make it very clear that I am not advocating that in this go >around that you add anything that increase the scope toward managing >coexistence or adding spectrum to the database. I used those as examples >of future upgrades. I am just making recommendations that you don't do >something now that makes it more difficult to do something different in >the future. > > I agree with your personal comment that most of your messaging would >remain the same. However, I do not believe the administrative (i.e., >regulatory )data and spectrum use data that you will come up with for TV >whitespace will be rich enough to account for the many ways of sharing >spectrum in the future and the coordination that must take place. Trying >to make it so now will cause the very problem you are objecting to. It >will complicate this first effort. Proceeding on the assumption that it >can be upgraded easily, I believe, will be the original sin of PAWS and >make upgrade very difficult. The first iteration of PAWS will affect >other standards and those standards will serve as inertia to upgrades. >Creating a PAWS standard that allows for the use of different data models >simply keeps this from being a problem. The legacy data model can be >used with the legacy standard. A new data model can be used with a new >standard or a different band or different regulations. > > Consider this problem. In future upgrades, if coexistence were ever >managed, how would the different database administrators collaborate in >defining the boundaries between the TVWS users? Right now it is going to >be the wild west. Short range unlicensed is a different problem than >long range unlicensed. With the larger spaces of the TVWS frequencies >there will be greater potential for overlap of users and so interference >among users. =20 > >John > >-----Original Message----- >From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >Sent: Monday, February 27, 2012 4:36 PM >To: Stine, John A. >Cc: paws@ietf.org >Subject: Re: [paws] Further explanation of partitioned data models > > >Discussions of spectrum coexistence is explicitly out of scope, and we >have a big enough job to do without increasing scope. >The scope is also limited to the problem of a device requesting spectrum, >and discussions of provisioning ("releasing new spectrum") is out of >scope. Only the device-to-database query and its response is in scope. > > >If we ever get to coexistence work, the additional messaging is some form >of "use this explicit spectrum, I'm suggesting that you use >it, even if you could use other spectrum" or "of the >choices you gave me, I'll use this part, and please try and keep other >users out of my way". Either is a simple expansion of the basic query >(location and band in, spectrum choices out). As such, I don't think we >have to do anything in anticipation of such a future capability. > >I do think the notion of authentication of the device and the database is >in scope, and I certainly think exchange of credentials or equivalent >precedes spectrum query, so I suspect we're separating that part anyway. >I certainly think we're trying to return spectrum choices that depend on >location, device characteristics and things like time of day, and we're >trying to design a protocol that will work for any country that decides >to open spectrum for whitespace use and on any band they decide to do so. > So long as we have enough data elements in the query to allow any of the >algorithms that the regulators decide on to determine the available >spectrum from the input query and provisioning information in the >database, as well as have sufficient flexibility in the response of >available spectrum to cover all the limits the regulators want to have, >we should be okay. So far, I don't see any problems staying within the >model we have been talking about. > >Brian > >On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: > >> From the lack of response to my email last week, I assume folks just >>don't understand why I am recommending the division of the data model. >>Please let me explain in a different way. >>=20 >> Last December, at the SDR Forum, Julius Knapp, the Director of the OET >>at the FCC, hosted a panel attended by five of the ten database >>administrators. In that panel, he asked the panelists what was in it >>for them. Several responded that they hoped they could provide a >>service to those looking for spectrum and to help broker these >>arrangements. =20 >>=20 >> This is not the model of TVWS. At present, the urgency of the paws >>effort surrounds a narrower goal of enabling TVWS devices to obtain >>channels they can use. I do not want to make any suggestions that would >>prevent us from achieving this goal first. I do want to make an effort >>to prevent what is done from becoming an impediment to a bigger role for >>whitespace database administration in the future, one of managing >>coexistence and brokering spectrum reuse. >>=20 >> In all methods of using a database where a device negotiates with a >>database, the types of messages that will be used are likely to be >>similar:=20 >> - This is who I am, what rules should I apply in negotiating for >>spectrum? =20 >> - This is the spectrum I am looking for, what do you have? >> - This is the spectrum that meets your query criteria. >> - etc. >> The methods developed for trust are also reusable. This is the reason >>for having a portion of the data model remain the same for all >>expansions. >>=20 >> The differences between a TVWS scenario and a brokering scenario are >>likely to be additional messaging and different data, both for the >>business of brokering and for defining the spectrum authorization. For >>example, in the brokering use case there needs to be a spectrum data >>model that allows a primary spectrum user to release spectrum into the >>market, (e.g., provide their contours ) and to specify the terms of use. >> My concern is that if the data model of TVWS comingles the data of >>messaging, administration, and spectrum; that this sort of expansion of >>paws would require increasing the size of the data model and would make >>expanding its capability more difficult both because of the impact of >>this expansion on legacy uses and because of the confusion of using >>large schemas that have similar but different data elements. >>=20 >> My solution is to divide the data model into three parts. The data >>document of messages would use the namespace of three schemas. In the >>TVWS edition, this would also allow different administrative and >>spectrum schemas for different regulatory domains. In end, the data for >>TVWS management would not be any different, it would just be defined in >>three schemas >>=20 >> In the initial exchanges between a device and a database, there would >>be agreement on which schemas to use. This is equivalent to resolving >>the regulatory domain. The messaging that follows would be the exact >>same, with the exact same data as the messaging if a comingled data >>model were used. >>=20 >> If the division is done well, then, in the long term, others can create >>schemas for administration and spectrum definition that meets their >>business needs without having to do so through paws. They would be able >>expand the way the paws protocol is used without having to revise paws. >>=20 >> I hope this better explains my intent. It would also be helpful to >>understand why anyone thinks this should not be done. >>=20 >> John >> _______________________________________________ >> 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 scott.probasco@nokia.com Tue Feb 28 06:13:11 2012 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 E8EEB21F8686 for ; Tue, 28 Feb 2012 06:13:11 -0800 (PST) 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_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1u7NNZeWBvw for ; Tue, 28 Feb 2012 06:13:11 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6DE21F8685 for ; Tue, 28 Feb 2012 06:13:10 -0800 (PST) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1SED7tU026767; Tue, 28 Feb 2012 16:13:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 16:13:08 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.01.0355.003; Tue, 28 Feb 2012 15:13:07 +0100 From: To: , Thread-Topic: UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZRTfywgACg7wA= Date: Tue, 28 Feb 2012 14:13:06 +0000 Message-ID: In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797113C9BA079@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [50.11.3.60] Content-Type: text/plain; charset="us-ascii" Content-ID: <283E0CF380E6DE48B770C11C2670150F@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 14:13:08.0026 (UTC) FILETIME=[1861E9A0:01CCF623] X-Nokia-AV: Clean Subject: Re: [paws] UC&R I-D: Requirements 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, 28 Feb 2012 14:13:12 -0000 Hello Don, Thank you for providing this analysis. It is very good to know that our progress thus far is well aligned with a working and certified database. I propose that we change O.22 as follows: O.22: A Master device MUST include its identity in messages sent to the database. Kind Regards, Scott On 2/27/12 3:40 PM, "ext Don Joslyn" wrote: >Spectrum Bridge offers the following feedback to the latest PAWS >Requirements posted by Scott Probasco on 2/21/12, UC&R I-D Requirements - >Section 6 revisions of the I-D which describes the Data Model, Protocol >and Operational Requirements: > >We reviewed the latest PAWS requirements, comparing them to the published >FCC requirements that established the requirements used by Spectrum >Bridge to implement its certified TVWS database. We believe that the >currently written PAWS Data Model, Protocol and Operational requirements >align well with our current FCC certified implementation (see attached >spreadsheet), and thus we support the PAWS requirements as written in the >2/21/22 from Scott Probasco, with a single exception, O.22. We do not >agree with O.22 because we believe that a device should ALWAYS include >its unique identity in messages sent to the database. > >Regards, > >Don Joslyn >Spectrum Bridge, Inc. From d.joslyn@spectrumbridge.com Tue Feb 28 07:11:33 2012 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 C955C21F86CE for ; Tue, 28 Feb 2012 07:11:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWOPJi4ekp0g for ; Tue, 28 Feb 2012 07:11:33 -0800 (PST) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id C9B4D21F86D0 for ; Tue, 28 Feb 2012 07:11:32 -0800 (PST) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 28 Feb 2012 10:12:13 -0500 From: Don Joslyn To: "scott.probasco@nokia.com" , "paws@ietf.org" Date: Tue, 28 Feb 2012 10:12:18 -0500 Thread-Topic: UC&R I-D: Requirements Thread-Index: AQHM8PQSrQm6sVmPsEWUycgK5ap90ZZRTfywgACg7wCAAIXJ4A== Message-ID: <8375F6DAEFB09F48815203F1FE23B797113C9BA0A6@shelby> References: <8375F6DAEFB09F48815203F1FE23B797113C9BA079@shelby> 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] UC&R I-D: Requirements 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, 28 Feb 2012 15:11:34 -0000 Thank you, Scott. Regards, Don -----Original Message----- From: scott.probasco@nokia.com [mailto:scott.probasco@nokia.com]=20 Sent: Tuesday, February 28, 2012 9:13 AM To: Don Joslyn; paws@ietf.org Cc: Peter Stanforth Subject: Re: UC&R I-D: Requirements Hello Don, Thank you for providing this analysis. It is very good to know that our progress thus far is well aligned with a working and certified database. I propose that we change O.22 as follows: O.22: A Master device MUST include its identity in messages sent to the database. Kind Regards, Scott On 2/27/12 3:40 PM, "ext Don Joslyn" wrote: >Spectrum Bridge offers the following feedback to the latest PAWS >Requirements posted by Scott Probasco on 2/21/12, UC&R I-D Requirements - >Section 6 revisions of the I-D which describes the Data Model, Protocol >and Operational Requirements: > >We reviewed the latest PAWS requirements, comparing them to the published >FCC requirements that established the requirements used by Spectrum >Bridge to implement its certified TVWS database. We believe that the >currently written PAWS Data Model, Protocol and Operational requirements >align well with our current FCC certified implementation (see attached >spreadsheet), and thus we support the PAWS requirements as written in the >2/21/22 from Scott Probasco, with a single exception, O.22. We do not >agree with O.22 because we believe that a device should ALWAYS include >its unique identity in messages sent to the database. > >Regards, > >Don Joslyn >Spectrum Bridge, Inc. From Basavaraj.Patil@nokia.com Tue Feb 28 09:45:08 2012 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 EC08121F85FD for ; Tue, 28 Feb 2012 09:45:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.65 X-Spam-Level: X-Spam-Status: No, score=-104.65 tagged_above=-999 required=5 tests=[AWL=1.793, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gB5GKAYodvVb for ; Tue, 28 Feb 2012 09:45:08 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id BF22B21F869A for ; Tue, 28 Feb 2012 09:45:07 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1SHiuXJ018288; Tue, 28 Feb 2012 19:44:59 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 19:44:57 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.01.0355.003; Tue, 28 Feb 2012 18:44:56 +0100 From: To: , , Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXP//9bGAgAAT6gD///4kAIAA2xaA Date: Tue, 28 Feb 2012 17:44:56 +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.14.0.111121 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 17:44:58.0008 (UTC) FILETIME=[B01F4180:01CCF640] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models 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, 28 Feb 2012 17:45:09 -0000 Inline: On 2/27/12 10:41 PM, "ext scott.probasco@nokia.com" wrote: >Hi, > >As a way forward, how about two additional requirements > >D.X The Data Model MUST be extensible. > >P.X The protocol MUST be extensible. > >This captures the desire to extend both the Data Model and the protocol in >the future, without identifying a specific solution at this time. The above requirements are overly broad and tends to result in protocol bloat.=20 Extensibility is something to be kept in mind with the cognizance that the WS technology will evolve but I would refrain from adding the above requirements to the I-D. -Raj > >Kind Regards, >Scott > > > > >On 2/27/12 4:47 PM, "ext Stine, John A." wrote: > >>Brian, >> >> I want to make it very clear that I am not advocating that in this go >>around that you add anything that increase the scope toward managing >>coexistence or adding spectrum to the database. I used those as examples >>of future upgrades. I am just making recommendations that you don't do >>something now that makes it more difficult to do something different in >>the future. >> >> I agree with your personal comment that most of your messaging would >>remain the same. However, I do not believe the administrative (i.e., >>regulatory )data and spectrum use data that you will come up with for TV >>whitespace will be rich enough to account for the many ways of sharing >>spectrum in the future and the coordination that must take place. Trying >>to make it so now will cause the very problem you are objecting to. It >>will complicate this first effort. Proceeding on the assumption that it >>can be upgraded easily, I believe, will be the original sin of PAWS and >>make upgrade very difficult. The first iteration of PAWS will affect >>other standards and those standards will serve as inertia to upgrades. >>Creating a PAWS standard that allows for the use of different data models >>simply keeps this from being a problem. The legacy data model can be >>used with the legacy standard. A new data model can be used with a new >>standard or a different band or different regulations. >> >> Consider this problem. In future upgrades, if coexistence were ever >>managed, how would the different database administrators collaborate in >>defining the boundaries between the TVWS users? Right now it is going to >>be the wild west. Short range unlicensed is a different problem than >>long range unlicensed. With the larger spaces of the TVWS frequencies >>there will be greater potential for overlap of users and so interference >>among users. =20 >> >>John >> >>-----Original Message----- >>From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>Sent: Monday, February 27, 2012 4:36 PM >>To: Stine, John A. >>Cc: paws@ietf.org >>Subject: Re: [paws] Further explanation of partitioned data models >> >> >>Discussions of spectrum coexistence is explicitly out of scope, and we >>have a big enough job to do without increasing scope. >>The scope is also limited to the problem of a device requesting spectrum, >>and discussions of provisioning ("releasing new spectrum") is out of >>scope. Only the device-to-database query and its response is in scope. >> >> >>If we ever get to coexistence work, the additional messaging is some form >>of "use this explicit spectrum, I'm suggesting that you use >>it, even if you could use other spectrum" or "of the >>choices you gave me, I'll use this part, and please try and keep other >>users out of my way". Either is a simple expansion of the basic query >>(location and band in, spectrum choices out). As such, I don't think we >>have to do anything in anticipation of such a future capability. >> >>I do think the notion of authentication of the device and the database is >>in scope, and I certainly think exchange of credentials or equivalent >>precedes spectrum query, so I suspect we're separating that part anyway. >>I certainly think we're trying to return spectrum choices that depend on >>location, device characteristics and things like time of day, and we're >>trying to design a protocol that will work for any country that decides >>to open spectrum for whitespace use and on any band they decide to do so. >> So long as we have enough data elements in the query to allow any of the >>algorithms that the regulators decide on to determine the available >>spectrum from the input query and provisioning information in the >>database, as well as have sufficient flexibility in the response of >>available spectrum to cover all the limits the regulators want to have, >>we should be okay. So far, I don't see any problems staying within the >>model we have been talking about. >> >>Brian >> >>On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: >> >>> From the lack of response to my email last week, I assume folks just >>>don't understand why I am recommending the division of the data model. >>>Please let me explain in a different way. >>>=20 >>> Last December, at the SDR Forum, Julius Knapp, the Director of the OET >>>at the FCC, hosted a panel attended by five of the ten database >>>administrators. In that panel, he asked the panelists what was in it >>>for them. Several responded that they hoped they could provide a >>>service to those looking for spectrum and to help broker these >>>arrangements. =20 >>>=20 >>> This is not the model of TVWS. At present, the urgency of the paws >>>effort surrounds a narrower goal of enabling TVWS devices to obtain >>>channels they can use. I do not want to make any suggestions that would >>>prevent us from achieving this goal first. I do want to make an effort >>>to prevent what is done from becoming an impediment to a bigger role for >>>whitespace database administration in the future, one of managing >>>coexistence and brokering spectrum reuse. >>>=20 >>> In all methods of using a database where a device negotiates with a >>>database, the types of messages that will be used are likely to be >>>similar:=20 >>> - This is who I am, what rules should I apply in negotiating for >>>spectrum? =20 >>> - This is the spectrum I am looking for, what do you have? >>> - This is the spectrum that meets your query criteria. >>> - etc. >>> The methods developed for trust are also reusable. This is the reason >>>for having a portion of the data model remain the same for all >>>expansions. >>>=20 >>> The differences between a TVWS scenario and a brokering scenario are >>>likely to be additional messaging and different data, both for the >>>business of brokering and for defining the spectrum authorization. For >>>example, in the brokering use case there needs to be a spectrum data >>>model that allows a primary spectrum user to release spectrum into the >>>market, (e.g., provide their contours ) and to specify the terms of use. >>> My concern is that if the data model of TVWS comingles the data of >>>messaging, administration, and spectrum; that this sort of expansion of >>>paws would require increasing the size of the data model and would make >>>expanding its capability more difficult both because of the impact of >>>this expansion on legacy uses and because of the confusion of using >>>large schemas that have similar but different data elements. >>>=20 >>> My solution is to divide the data model into three parts. The data >>>document of messages would use the namespace of three schemas. In the >>>TVWS edition, this would also allow different administrative and >>>spectrum schemas for different regulatory domains. In end, the data for >>>TVWS management would not be any different, it would just be defined in >>>three schemas >>>=20 >>> In the initial exchanges between a device and a database, there would >>>be agreement on which schemas to use. This is equivalent to resolving >>>the regulatory domain. The messaging that follows would be the exact >>>same, with the exact same data as the messaging if a comingled data >>>model were used. >>>=20 >>> If the division is done well, then, in the long term, others can create >>>schemas for administration and spectrum definition that meets their >>>business needs without having to do so through paws. They would be able >>>expand the way the paws protocol is used without having to revise paws. >>>=20 >>> I hope this better explains my intent. It would also be helpful to >>>understand why anyone thinks this should not be done. >>>=20 >>> John >>> _______________________________________________ >>> 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 jstine@mitre.org Tue Feb 28 10:02:15 2012 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 9453B21F86F9 for ; Tue, 28 Feb 2012 10:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYs8rvx6KFew for ; Tue, 28 Feb 2012 10:02:14 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6391521F86C5 for ; Tue, 28 Feb 2012 10:02:14 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8CFDC21B179F; Tue, 28 Feb 2012 13:02:13 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 741CF21B14AB; Tue, 28 Feb 2012 13:02:13 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 28 Feb 2012 13:02:13 -0500 From: "Stine, John A." To: "Basavaraj.Patil@nokia.com" Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXP//9bGAgAAT6gD///4kAIAA2xaA//+JajA= Date: Tue, 28 Feb 2012 18:02:12 +0000 Message-ID: <2782C93FD2244441893673F3F91281921153C7@IMCMBX01.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Further explanation of partitioned data models 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, 28 Feb 2012 18:02:15 -0000 How about this D.X The data model MUST provide a modular design separating out messaging = specific, administrative specific, and spectrum specific parts into separat= e modules. P.X The protocol MUST support determination of which administrative specif= ic and spectrum specific modules are used. This is very specific and it is NOT requiring any increase in scope. John -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Tuesday, February 28, 2012 12:45 PM To: scott.probasco@nokia.com; Stine, John A.; Brian.Rosen@neustar.biz Cc: paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models Inline: On 2/27/12 10:41 PM, "ext scott.probasco@nokia.com" wrote: >Hi, > >As a way forward, how about two additional requirements > >D.X The Data Model MUST be extensible. > >P.X The protocol MUST be extensible. > >This captures the desire to extend both the Data Model and the protocol in >the future, without identifying a specific solution at this time. The above requirements are overly broad and tends to result in protocol bloat.=20 Extensibility is something to be kept in mind with the cognizance that the WS technology will evolve but I would refrain from adding the above requirements to the I-D. -Raj > >Kind Regards, >Scott > > > > >On 2/27/12 4:47 PM, "ext Stine, John A." wrote: > >>Brian, >> >> I want to make it very clear that I am not advocating that in this go >>around that you add anything that increase the scope toward managing >>coexistence or adding spectrum to the database. I used those as examples >>of future upgrades. I am just making recommendations that you don't do >>something now that makes it more difficult to do something different in >>the future. >> >> I agree with your personal comment that most of your messaging would >>remain the same. However, I do not believe the administrative (i.e., >>regulatory )data and spectrum use data that you will come up with for TV >>whitespace will be rich enough to account for the many ways of sharing >>spectrum in the future and the coordination that must take place. Trying >>to make it so now will cause the very problem you are objecting to. It >>will complicate this first effort. Proceeding on the assumption that it >>can be upgraded easily, I believe, will be the original sin of PAWS and >>make upgrade very difficult. The first iteration of PAWS will affect >>other standards and those standards will serve as inertia to upgrades. >>Creating a PAWS standard that allows for the use of different data models >>simply keeps this from being a problem. The legacy data model can be >>used with the legacy standard. A new data model can be used with a new >>standard or a different band or different regulations. >> >> Consider this problem. In future upgrades, if coexistence were ever >>managed, how would the different database administrators collaborate in >>defining the boundaries between the TVWS users? Right now it is going to >>be the wild west. Short range unlicensed is a different problem than >>long range unlicensed. With the larger spaces of the TVWS frequencies >>there will be greater potential for overlap of users and so interference >>among users. =20 >> >>John >> >>-----Original Message----- >>From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>Sent: Monday, February 27, 2012 4:36 PM >>To: Stine, John A. >>Cc: paws@ietf.org >>Subject: Re: [paws] Further explanation of partitioned data models >> >> >>Discussions of spectrum coexistence is explicitly out of scope, and we >>have a big enough job to do without increasing scope. >>The scope is also limited to the problem of a device requesting spectrum, >>and discussions of provisioning ("releasing new spectrum") is out of >>scope. Only the device-to-database query and its response is in scope. >> >> >>If we ever get to coexistence work, the additional messaging is some form >>of "use this explicit spectrum, I'm suggesting that you use >>it, even if you could use other spectrum" or "of the >>choices you gave me, I'll use this part, and please try and keep other >>users out of my way". Either is a simple expansion of the basic query >>(location and band in, spectrum choices out). As such, I don't think we >>have to do anything in anticipation of such a future capability. >> >>I do think the notion of authentication of the device and the database is >>in scope, and I certainly think exchange of credentials or equivalent >>precedes spectrum query, so I suspect we're separating that part anyway. >>I certainly think we're trying to return spectrum choices that depend on >>location, device characteristics and things like time of day, and we're >>trying to design a protocol that will work for any country that decides >>to open spectrum for whitespace use and on any band they decide to do so. >> So long as we have enough data elements in the query to allow any of the >>algorithms that the regulators decide on to determine the available >>spectrum from the input query and provisioning information in the >>database, as well as have sufficient flexibility in the response of >>available spectrum to cover all the limits the regulators want to have, >>we should be okay. So far, I don't see any problems staying within the >>model we have been talking about. >> >>Brian >> >>On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: >> >>> From the lack of response to my email last week, I assume folks just >>>don't understand why I am recommending the division of the data model. >>>Please let me explain in a different way. >>>=20 >>> Last December, at the SDR Forum, Julius Knapp, the Director of the OET >>>at the FCC, hosted a panel attended by five of the ten database >>>administrators. In that panel, he asked the panelists what was in it >>>for them. Several responded that they hoped they could provide a >>>service to those looking for spectrum and to help broker these >>>arrangements. =20 >>>=20 >>> This is not the model of TVWS. At present, the urgency of the paws >>>effort surrounds a narrower goal of enabling TVWS devices to obtain >>>channels they can use. I do not want to make any suggestions that would >>>prevent us from achieving this goal first. I do want to make an effort >>>to prevent what is done from becoming an impediment to a bigger role for >>>whitespace database administration in the future, one of managing >>>coexistence and brokering spectrum reuse. >>>=20 >>> In all methods of using a database where a device negotiates with a >>>database, the types of messages that will be used are likely to be >>>similar:=20 >>> - This is who I am, what rules should I apply in negotiating for >>>spectrum? =20 >>> - This is the spectrum I am looking for, what do you have? >>> - This is the spectrum that meets your query criteria. >>> - etc. >>> The methods developed for trust are also reusable. This is the reason >>>for having a portion of the data model remain the same for all >>>expansions. >>>=20 >>> The differences between a TVWS scenario and a brokering scenario are >>>likely to be additional messaging and different data, both for the >>>business of brokering and for defining the spectrum authorization. For >>>example, in the brokering use case there needs to be a spectrum data >>>model that allows a primary spectrum user to release spectrum into the >>>market, (e.g., provide their contours ) and to specify the terms of use. >>> My concern is that if the data model of TVWS comingles the data of >>>messaging, administration, and spectrum; that this sort of expansion of >>>paws would require increasing the size of the data model and would make >>>expanding its capability more difficult both because of the impact of >>>this expansion on legacy uses and because of the confusion of using >>>large schemas that have similar but different data elements. >>>=20 >>> My solution is to divide the data model into three parts. The data >>>document of messages would use the namespace of three schemas. In the >>>TVWS edition, this would also allow different administrative and >>>spectrum schemas for different regulatory domains. In end, the data for >>>TVWS management would not be any different, it would just be defined in >>>three schemas >>>=20 >>> In the initial exchanges between a device and a database, there would >>>be agreement on which schemas to use. This is equivalent to resolving >>>the regulatory domain. The messaging that follows would be the exact >>>same, with the exact same data as the messaging if a comingled data >>>model were used. >>>=20 >>> If the division is done well, then, in the long term, others can create >>>schemas for administration and spectrum definition that meets their >>>business needs without having to do so through paws. They would be able >>>expand the way the paws protocol is used without having to revise paws. >>>=20 >>> I hope this better explains my intent. It would also be helpful to >>>understand why anyone thinks this should not be done. >>>=20 >>> John >>> _______________________________________________ >>> 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 Feb 28 10:16:46 2012 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 11FDC21F85BB for ; Tue, 28 Feb 2012 10:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.742 X-Spam-Level: X-Spam-Status: No, score=-104.742 tagged_above=-999 required=5 tests=[AWL=1.701, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEjjXrPlpDEQ for ; Tue, 28 Feb 2012 10:16:45 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id DB0A521F85D9 for ; Tue, 28 Feb 2012 10:16:44 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1SIGf3F030464; Tue, 28 Feb 2012 20:16:43 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 20:16:42 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Tue, 28 Feb 2012 19:16:41 +0100 From: To: Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXP//9bGAgAAT6gD///4kAIAA2xaA//+JajCAAH9hgA== Date: Tue, 28 Feb 2012 18:16:41 +0000 Message-ID: In-Reply-To: <2782C93FD2244441893673F3F91281921153C7@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <786D76084CF4394FA3F5BF5EF494B991@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 18:16:42.0615 (UTC) FILETIME=[1F5B3870:01CCF645] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models 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, 28 Feb 2012 18:16:46 -0000 Hi John, Rather than stating that the data model MUST be modular or the protocol MUST support determination of which administrative and spectrum specific modules are used, I would propose these to be included as guidelines to be used in the design of the data model and protocol. In addition to having a set of requirements, we could add guidelines as well to abet the solutions. -Raj On 2/28/12 12:02 PM, "ext Stine, John A." wrote: >How about this > >D.X The data model MUST provide a modular design separating out >messaging specific, administrative specific, and spectrum specific parts >into separate modules. > >P.X The protocol MUST support determination of which administrative >specific and spectrum specific modules are used. > >This is very specific and it is NOT requiring any increase in scope. > >John > >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Tuesday, February 28, 2012 12:45 PM >To: scott.probasco@nokia.com; Stine, John A.; Brian.Rosen@neustar.biz >Cc: paws@ietf.org >Subject: Re: [paws] Further explanation of partitioned data models > >Inline: > >On 2/27/12 10:41 PM, "ext scott.probasco@nokia.com" > wrote: > >>Hi, >> >>As a way forward, how about two additional requirements >> >>D.X The Data Model MUST be extensible. >> >>P.X The protocol MUST be extensible. >> >>This captures the desire to extend both the Data Model and the protocol >>in >>the future, without identifying a specific solution at this time. > >The above requirements are overly broad and tends to result in protocol >bloat.=20 >Extensibility is something to be kept in mind with the cognizance that the >WS technology will evolve but I would refrain from adding the above >requirements to the I-D. > >-Raj > >> >>Kind Regards, >>Scott >> >> >> >> >>On 2/27/12 4:47 PM, "ext Stine, John A." wrote: >> >>>Brian, >>> >>> I want to make it very clear that I am not advocating that in this go >>>around that you add anything that increase the scope toward managing >>>coexistence or adding spectrum to the database. I used those as >>>examples >>>of future upgrades. I am just making recommendations that you don't do >>>something now that makes it more difficult to do something different in >>>the future. >>> >>> I agree with your personal comment that most of your messaging would >>>remain the same. However, I do not believe the administrative (i.e., >>>regulatory )data and spectrum use data that you will come up with for TV >>>whitespace will be rich enough to account for the many ways of sharing >>>spectrum in the future and the coordination that must take place. >>>Trying >>>to make it so now will cause the very problem you are objecting to. It >>>will complicate this first effort. Proceeding on the assumption that it >>>can be upgraded easily, I believe, will be the original sin of PAWS and >>>make upgrade very difficult. The first iteration of PAWS will affect >>>other standards and those standards will serve as inertia to upgrades. >>>Creating a PAWS standard that allows for the use of different data >>>models >>>simply keeps this from being a problem. The legacy data model can be >>>used with the legacy standard. A new data model can be used with a new >>>standard or a different band or different regulations. >>> >>> Consider this problem. In future upgrades, if coexistence were ever >>>managed, how would the different database administrators collaborate in >>>defining the boundaries between the TVWS users? Right now it is going >>>to >>>be the wild west. Short range unlicensed is a different problem than >>>long range unlicensed. With the larger spaces of the TVWS frequencies >>>there will be greater potential for overlap of users and so interference >>>among users. =20 >>> >>>John >>> >>>-----Original Message----- >>>From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>Sent: Monday, February 27, 2012 4:36 PM >>>To: Stine, John A. >>>Cc: paws@ietf.org >>>Subject: Re: [paws] Further explanation of partitioned data models >>> >>> >>>Discussions of spectrum coexistence is explicitly out of scope, and we >>>have a big enough job to do without increasing scope. >>>The scope is also limited to the problem of a device requesting >>>spectrum, >>>and discussions of provisioning ("releasing new spectrum") is out of >>>scope. Only the device-to-database query and its response is in scope. >>> >>> >>>If we ever get to coexistence work, the additional messaging is some >>>form >>>of "use this explicit spectrum, I'm suggesting that you >>>use >>>it, even if you could use other spectrum" or "of the >>>choices you gave me, I'll use this part, and please try and keep other >>>users out of my way". Either is a simple expansion of the basic query >>>(location and band in, spectrum choices out). As such, I don't think we >>>have to do anything in anticipation of such a future capability. >>> >>>I do think the notion of authentication of the device and the database >>>is >>>in scope, and I certainly think exchange of credentials or equivalent >>>precedes spectrum query, so I suspect we're separating that part anyway. >>>I certainly think we're trying to return spectrum choices that depend on >>>location, device characteristics and things like time of day, and we're >>>trying to design a protocol that will work for any country that decides >>>to open spectrum for whitespace use and on any band they decide to do >>>so. >>> So long as we have enough data elements in the query to allow any of >>>the >>>algorithms that the regulators decide on to determine the available >>>spectrum from the input query and provisioning information in the >>>database, as well as have sufficient flexibility in the response of >>>available spectrum to cover all the limits the regulators want to have, >>>we should be okay. So far, I don't see any problems staying within the >>>model we have been talking about. >>> >>>Brian >>> >>>On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: >>> >>>> From the lack of response to my email last week, I assume folks just >>>>don't understand why I am recommending the division of the data model. >>>>Please let me explain in a different way. >>>>=20 >>>> Last December, at the SDR Forum, Julius Knapp, the Director of the OET >>>>at the FCC, hosted a panel attended by five of the ten database >>>>administrators. In that panel, he asked the panelists what was in it >>>>for them. Several responded that they hoped they could provide a >>>>service to those looking for spectrum and to help broker these >>>>arrangements. =20 >>>>=20 >>>> This is not the model of TVWS. At present, the urgency of the paws >>>>effort surrounds a narrower goal of enabling TVWS devices to obtain >>>>channels they can use. I do not want to make any suggestions that >>>>would >>>>prevent us from achieving this goal first. I do want to make an effort >>>>to prevent what is done from becoming an impediment to a bigger role >>>>for >>>>whitespace database administration in the future, one of managing >>>>coexistence and brokering spectrum reuse. >>>>=20 >>>> In all methods of using a database where a device negotiates with a >>>>database, the types of messages that will be used are likely to be >>>>similar:=20 >>>> - This is who I am, what rules should I apply in negotiating for >>>>spectrum? =20 >>>> - This is the spectrum I am looking for, what do you have? >>>> - This is the spectrum that meets your query criteria. >>>> - etc. >>>> The methods developed for trust are also reusable. This is the reason >>>>for having a portion of the data model remain the same for all >>>>expansions. >>>>=20 >>>> The differences between a TVWS scenario and a brokering scenario are >>>>likely to be additional messaging and different data, both for the >>>>business of brokering and for defining the spectrum authorization. For >>>>example, in the brokering use case there needs to be a spectrum data >>>>model that allows a primary spectrum user to release spectrum into the >>>>market, (e.g., provide their contours ) and to specify the terms of >>>>use. >>>> My concern is that if the data model of TVWS comingles the data of >>>>messaging, administration, and spectrum; that this sort of expansion of >>>>paws would require increasing the size of the data model and would make >>>>expanding its capability more difficult both because of the impact of >>>>this expansion on legacy uses and because of the confusion of using >>>>large schemas that have similar but different data elements. >>>>=20 >>>> My solution is to divide the data model into three parts. The data >>>>document of messages would use the namespace of three schemas. In the >>>>TVWS edition, this would also allow different administrative and >>>>spectrum schemas for different regulatory domains. In end, the data >>>>for >>>>TVWS management would not be any different, it would just be defined in >>>>three schemas >>>>=20 >>>> In the initial exchanges between a device and a database, there would >>>>be agreement on which schemas to use. This is equivalent to resolving >>>>the regulatory domain. The messaging that follows would be the exact >>>>same, with the exact same data as the messaging if a comingled data >>>>model were used. >>>>=20 >>>> If the division is done well, then, in the long term, others can >>>>create >>>>schemas for administration and spectrum definition that meets their >>>>business needs without having to do so through paws. They would be >>>>able >>>>expand the way the paws protocol is used without having to revise paws. >>>>=20 >>>> I hope this better explains my intent. It would also be helpful to >>>>understand why anyone thinks this should not be done. >>>>=20 >>>> John >>>> _______________________________________________ >>>> 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 jstine@mitre.org Tue Feb 28 10:38:27 2012 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 C062221F86C5 for ; Tue, 28 Feb 2012 10:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.356 X-Spam-Level: X-Spam-Status: No, score=-6.356 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG+QPd0nzudh for ; Tue, 28 Feb 2012 10:38:26 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 33EC521F86C2 for ; Tue, 28 Feb 2012 10:38:25 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9E53221B1669; Tue, 28 Feb 2012 13:38:24 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8F54521B0456; Tue, 28 Feb 2012 13:38:24 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS01.MITRE.ORG ([129.83.29.78]) with mapi id 14.01.0339.001; Tue, 28 Feb 2012 13:38:24 -0500 From: "Stine, John A." To: "Basavaraj.Patil@nokia.com" Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXP//9bGAgAAT6gD///4kAIAA2xaA//+JajCAAH9hgP//iMxw Date: Tue, 28 Feb 2012 18:38:23 +0000 Message-ID: <2782C93FD2244441893673F3F912819211541F@IMCMBX01.MITRE.ORG> References: <2782C93FD2244441893673F3F91281921153C7@IMCMBX01.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Further explanation of partitioned data models 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, 28 Feb 2012 18:38:27 -0000 Hi Raj, That would be fine. =20 John -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Tuesday, February 28, 2012 1:17 PM To: Stine, John A. Cc: paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models Hi John, Rather than stating that the data model MUST be modular or the protocol MUST support determination of which administrative and spectrum specific modules are used, I would propose these to be included as guidelines to be used in the design of the data model and protocol. In addition to having a set of requirements, we could add guidelines as well to abet the solutions. -Raj On 2/28/12 12:02 PM, "ext Stine, John A." wrote: >How about this > >D.X The data model MUST provide a modular design separating out >messaging specific, administrative specific, and spectrum specific parts >into separate modules. > >P.X The protocol MUST support determination of which administrative >specific and spectrum specific modules are used. > >This is very specific and it is NOT requiring any increase in scope. > >John > >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Tuesday, February 28, 2012 12:45 PM >To: scott.probasco@nokia.com; Stine, John A.; Brian.Rosen@neustar.biz >Cc: paws@ietf.org >Subject: Re: [paws] Further explanation of partitioned data models > >Inline: > >On 2/27/12 10:41 PM, "ext scott.probasco@nokia.com" > wrote: > >>Hi, >> >>As a way forward, how about two additional requirements >> >>D.X The Data Model MUST be extensible. >> >>P.X The protocol MUST be extensible. >> >>This captures the desire to extend both the Data Model and the protocol >>in >>the future, without identifying a specific solution at this time. > >The above requirements are overly broad and tends to result in protocol >bloat.=20 >Extensibility is something to be kept in mind with the cognizance that the >WS technology will evolve but I would refrain from adding the above >requirements to the I-D. > >-Raj > >> >>Kind Regards, >>Scott >> >> >> >> >>On 2/27/12 4:47 PM, "ext Stine, John A." wrote: >> >>>Brian, >>> >>> I want to make it very clear that I am not advocating that in this go >>>around that you add anything that increase the scope toward managing >>>coexistence or adding spectrum to the database. I used those as >>>examples >>>of future upgrades. I am just making recommendations that you don't do >>>something now that makes it more difficult to do something different in >>>the future. >>> >>> I agree with your personal comment that most of your messaging would >>>remain the same. However, I do not believe the administrative (i.e., >>>regulatory )data and spectrum use data that you will come up with for TV >>>whitespace will be rich enough to account for the many ways of sharing >>>spectrum in the future and the coordination that must take place. >>>Trying >>>to make it so now will cause the very problem you are objecting to. It >>>will complicate this first effort. Proceeding on the assumption that it >>>can be upgraded easily, I believe, will be the original sin of PAWS and >>>make upgrade very difficult. The first iteration of PAWS will affect >>>other standards and those standards will serve as inertia to upgrades. >>>Creating a PAWS standard that allows for the use of different data >>>models >>>simply keeps this from being a problem. The legacy data model can be >>>used with the legacy standard. A new data model can be used with a new >>>standard or a different band or different regulations. >>> >>> Consider this problem. In future upgrades, if coexistence were ever >>>managed, how would the different database administrators collaborate in >>>defining the boundaries between the TVWS users? Right now it is going >>>to >>>be the wild west. Short range unlicensed is a different problem than >>>long range unlicensed. With the larger spaces of the TVWS frequencies >>>there will be greater potential for overlap of users and so interference >>>among users. =20 >>> >>>John >>> >>>-----Original Message----- >>>From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>Sent: Monday, February 27, 2012 4:36 PM >>>To: Stine, John A. >>>Cc: paws@ietf.org >>>Subject: Re: [paws] Further explanation of partitioned data models >>> >>> >>>Discussions of spectrum coexistence is explicitly out of scope, and we >>>have a big enough job to do without increasing scope. >>>The scope is also limited to the problem of a device requesting >>>spectrum, >>>and discussions of provisioning ("releasing new spectrum") is out of >>>scope. Only the device-to-database query and its response is in scope. >>> >>> >>>If we ever get to coexistence work, the additional messaging is some >>>form >>>of "use this explicit spectrum, I'm suggesting that you >>>use >>>it, even if you could use other spectrum" or "of the >>>choices you gave me, I'll use this part, and please try and keep other >>>users out of my way". Either is a simple expansion of the basic query >>>(location and band in, spectrum choices out). As such, I don't think we >>>have to do anything in anticipation of such a future capability. >>> >>>I do think the notion of authentication of the device and the database >>>is >>>in scope, and I certainly think exchange of credentials or equivalent >>>precedes spectrum query, so I suspect we're separating that part anyway. >>>I certainly think we're trying to return spectrum choices that depend on >>>location, device characteristics and things like time of day, and we're >>>trying to design a protocol that will work for any country that decides >>>to open spectrum for whitespace use and on any band they decide to do >>>so. >>> So long as we have enough data elements in the query to allow any of >>>the >>>algorithms that the regulators decide on to determine the available >>>spectrum from the input query and provisioning information in the >>>database, as well as have sufficient flexibility in the response of >>>available spectrum to cover all the limits the regulators want to have, >>>we should be okay. So far, I don't see any problems staying within the >>>model we have been talking about. >>> >>>Brian >>> >>>On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: >>> >>>> From the lack of response to my email last week, I assume folks just >>>>don't understand why I am recommending the division of the data model. >>>>Please let me explain in a different way. >>>>=20 >>>> Last December, at the SDR Forum, Julius Knapp, the Director of the OET >>>>at the FCC, hosted a panel attended by five of the ten database >>>>administrators. In that panel, he asked the panelists what was in it >>>>for them. Several responded that they hoped they could provide a >>>>service to those looking for spectrum and to help broker these >>>>arrangements. =20 >>>>=20 >>>> This is not the model of TVWS. At present, the urgency of the paws >>>>effort surrounds a narrower goal of enabling TVWS devices to obtain >>>>channels they can use. I do not want to make any suggestions that >>>>would >>>>prevent us from achieving this goal first. I do want to make an effort >>>>to prevent what is done from becoming an impediment to a bigger role >>>>for >>>>whitespace database administration in the future, one of managing >>>>coexistence and brokering spectrum reuse. >>>>=20 >>>> In all methods of using a database where a device negotiates with a >>>>database, the types of messages that will be used are likely to be >>>>similar:=20 >>>> - This is who I am, what rules should I apply in negotiating for >>>>spectrum? =20 >>>> - This is the spectrum I am looking for, what do you have? >>>> - This is the spectrum that meets your query criteria. >>>> - etc. >>>> The methods developed for trust are also reusable. This is the reason >>>>for having a portion of the data model remain the same for all >>>>expansions. >>>>=20 >>>> The differences between a TVWS scenario and a brokering scenario are >>>>likely to be additional messaging and different data, both for the >>>>business of brokering and for defining the spectrum authorization. For >>>>example, in the brokering use case there needs to be a spectrum data >>>>model that allows a primary spectrum user to release spectrum into the >>>>market, (e.g., provide their contours ) and to specify the terms of >>>>use. >>>> My concern is that if the data model of TVWS comingles the data of >>>>messaging, administration, and spectrum; that this sort of expansion of >>>>paws would require increasing the size of the data model and would make >>>>expanding its capability more difficult both because of the impact of >>>>this expansion on legacy uses and because of the confusion of using >>>>large schemas that have similar but different data elements. >>>>=20 >>>> My solution is to divide the data model into three parts. The data >>>>document of messages would use the namespace of three schemas. In the >>>>TVWS edition, this would also allow different administrative and >>>>spectrum schemas for different regulatory domains. In end, the data >>>>for >>>>TVWS management would not be any different, it would just be defined in >>>>three schemas >>>>=20 >>>> In the initial exchanges between a device and a database, there would >>>>be agreement on which schemas to use. This is equivalent to resolving >>>>the regulatory domain. The messaging that follows would be the exact >>>>same, with the exact same data as the messaging if a comingled data >>>>model were used. >>>>=20 >>>> If the division is done well, then, in the long term, others can >>>>create >>>>schemas for administration and spectrum definition that meets their >>>>business needs without having to do so through paws. They would be >>>>able >>>>expand the way the paws protocol is used without having to revise paws. >>>>=20 >>>> I hope this better explains my intent. It would also be helpful to >>>>understand why anyone thinks this should not be done. >>>>=20 >>>> John >>>> _______________________________________________ >>>> 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 Feb 28 13:51:41 2012 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 A4A9821E802D for ; Tue, 28 Feb 2012 13:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.864 X-Spam-Level: X-Spam-Status: No, score=-104.864 tagged_above=-999 required=5 tests=[AWL=1.579, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoNkHAoqF6um for ; Tue, 28 Feb 2012 13:51:40 -0800 (PST) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 33D6B21E802C for ; Tue, 28 Feb 2012 13:51:39 -0800 (PST) Received: from vaebh104.NOE.Nokia.com (vaebh104.europe.nokia.com [10.160.244.30]) by mgw-sa02.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1SLpb45008152; Tue, 28 Feb 2012 23:51:37 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 28 Feb 2012 23:51:37 +0200 Received: from 008-AM1MPN1-073.mgdnok.nokia.com ([169.254.3.165]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Tue, 28 Feb 2012 22:51:36 +0100 From: To: Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXP//9bGAgAAT6gD///4kAIAA2xaA//+JajCAAH9hgP//iMxwABZrDQA= Date: Tue, 28 Feb 2012 21:51:36 +0000 Message-ID: In-Reply-To: <2782C93FD2244441893673F3F912819211541F@IMCMBX01.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.59.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <54E6849DB640254CBE122EBCE6AA73DB@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 28 Feb 2012 21:51:37.0252 (UTC) FILETIME=[2528AE40:01CCF663] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models 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, 28 Feb 2012 21:51:41 -0000 How about adding the following as a subsection to the requirements section: " Sec x.y Guidelines for protocol and data model design The current scope of the working group is limited and are reflected in the requirements captured in Section y.z. However white space technology itself is expected to evolve and address other aspects such as co-existence and interference avoidance, spectrum brokering, alternative spectrum bands, etc. The design of the data model and protocol should be cognizant of the evolving nature of white space technology and consider the following set of guidelines in the development of the data model and protocol: 1. The data model SHOULD provide a modular design separating out messaging specific, administrative specific, and spectrum specific parts into separate modules. 2. The protocol SHOULD support determination of which administrative specific and spectrum specific modules are used. " -Raj On 2/28/12 12:38 PM, "ext Stine, John A." wrote: >Hi Raj, > > That would be fine. > >John > >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Tuesday, February 28, 2012 1:17 PM >To: Stine, John A. >Cc: paws@ietf.org >Subject: Re: [paws] Further explanation of partitioned data models > > >Hi John, > >Rather than stating that the data model MUST be modular or the protocol >MUST support determination of which administrative and spectrum specific >modules are used, I would propose these to be included as guidelines to be >used in the design of the data model and protocol. >In addition to having a set of requirements, we could add guidelines as >well to abet the solutions. > >-Raj > >On 2/28/12 12:02 PM, "ext Stine, John A." wrote: > >>How about this >> >>D.X The data model MUST provide a modular design separating out >>messaging specific, administrative specific, and spectrum specific parts >>into separate modules. >> >>P.X The protocol MUST support determination of which administrative >>specific and spectrum specific modules are used. >> >>This is very specific and it is NOT requiring any increase in scope. >> >>John >> >>-----Original Message----- >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>Sent: Tuesday, February 28, 2012 12:45 PM >>To: scott.probasco@nokia.com; Stine, John A.; Brian.Rosen@neustar.biz >>Cc: paws@ietf.org >>Subject: Re: [paws] Further explanation of partitioned data models >> >>Inline: >> >>On 2/27/12 10:41 PM, "ext scott.probasco@nokia.com" >> wrote: >> >>>Hi, >>> >>>As a way forward, how about two additional requirements >>> >>>D.X The Data Model MUST be extensible. >>> >>>P.X The protocol MUST be extensible. >>> >>>This captures the desire to extend both the Data Model and the protocol >>>in >>>the future, without identifying a specific solution at this time. >> >>The above requirements are overly broad and tends to result in protocol >>bloat.=20 >>Extensibility is something to be kept in mind with the cognizance that >>the >>WS technology will evolve but I would refrain from adding the above >>requirements to the I-D. >> >>-Raj >> >>> >>>Kind Regards, >>>Scott >>> >>> >>> >>> >>>On 2/27/12 4:47 PM, "ext Stine, John A." wrote: >>> >>>>Brian, >>>> >>>> I want to make it very clear that I am not advocating that in this go >>>>around that you add anything that increase the scope toward managing >>>>coexistence or adding spectrum to the database. I used those as >>>>examples >>>>of future upgrades. I am just making recommendations that you don't do >>>>something now that makes it more difficult to do something different in >>>>the future. >>>> >>>> I agree with your personal comment that most of your messaging would >>>>remain the same. However, I do not believe the administrative (i.e., >>>>regulatory )data and spectrum use data that you will come up with for >>>>TV >>>>whitespace will be rich enough to account for the many ways of sharing >>>>spectrum in the future and the coordination that must take place. >>>>Trying >>>>to make it so now will cause the very problem you are objecting to. It >>>>will complicate this first effort. Proceeding on the assumption that >>>>it >>>>can be upgraded easily, I believe, will be the original sin of PAWS and >>>>make upgrade very difficult. The first iteration of PAWS will affect >>>>other standards and those standards will serve as inertia to upgrades. >>>>Creating a PAWS standard that allows for the use of different data >>>>models >>>>simply keeps this from being a problem. The legacy data model can be >>>>used with the legacy standard. A new data model can be used with a new >>>>standard or a different band or different regulations. >>>> >>>> Consider this problem. In future upgrades, if coexistence were ever >>>>managed, how would the different database administrators collaborate in >>>>defining the boundaries between the TVWS users? Right now it is going >>>>to >>>>be the wild west. Short range unlicensed is a different problem than >>>>long range unlicensed. With the larger spaces of the TVWS frequencies >>>>there will be greater potential for overlap of users and so >>>>interference >>>>among users. =20 >>>> >>>>John >>>> >>>>-----Original Message----- >>>>From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>Sent: Monday, February 27, 2012 4:36 PM >>>>To: Stine, John A. >>>>Cc: paws@ietf.org >>>>Subject: Re: [paws] Further explanation of partitioned data models >>>> >>>> >>>>Discussions of spectrum coexistence is explicitly out of scope, and we >>>>have a big enough job to do without increasing scope. >>>>The scope is also limited to the problem of a device requesting >>>>spectrum, >>>>and discussions of provisioning ("releasing new spectrum") is out of >>>>scope. Only the device-to-database query and its response is in scope. >>>> >>>> >>>>If we ever get to coexistence work, the additional messaging is some >>>>form >>>>of "use this explicit spectrum, I'm suggesting that you >>>>use >>>>it, even if you could use other spectrum" or "of the >>>>choices you gave me, I'll use this part, and please try and keep other >>>>users out of my way". Either is a simple expansion of the basic query >>>>(location and band in, spectrum choices out). As such, I don't think >>>>we >>>>have to do anything in anticipation of such a future capability. >>>> >>>>I do think the notion of authentication of the device and the database >>>>is >>>>in scope, and I certainly think exchange of credentials or equivalent >>>>precedes spectrum query, so I suspect we're separating that part >>>>anyway. >>>>I certainly think we're trying to return spectrum choices that depend >>>>on >>>>location, device characteristics and things like time of day, and we're >>>>trying to design a protocol that will work for any country that decides >>>>to open spectrum for whitespace use and on any band they decide to do >>>>so. >>>> So long as we have enough data elements in the query to allow any of >>>>the >>>>algorithms that the regulators decide on to determine the available >>>>spectrum from the input query and provisioning information in the >>>>database, as well as have sufficient flexibility in the response of >>>>available spectrum to cover all the limits the regulators want to have, >>>>we should be okay. So far, I don't see any problems staying within the >>>>model we have been talking about. >>>> >>>>Brian >>>> >>>>On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: >>>> >>>>> From the lack of response to my email last week, I assume folks just >>>>>don't understand why I am recommending the division of the data model. >>>>>Please let me explain in a different way. >>>>>=20 >>>>> Last December, at the SDR Forum, Julius Knapp, the Director of the >>>>>OET >>>>>at the FCC, hosted a panel attended by five of the ten database >>>>>administrators. In that panel, he asked the panelists what was in it >>>>>for them. Several responded that they hoped they could provide a >>>>>service to those looking for spectrum and to help broker these >>>>>arrangements.=20 >>>>>=20 >>>>> This is not the model of TVWS. At present, the urgency of the paws >>>>>effort surrounds a narrower goal of enabling TVWS devices to obtain >>>>>channels they can use. I do not want to make any suggestions that >>>>>would >>>>>prevent us from achieving this goal first. I do want to make an >>>>>effort >>>>>to prevent what is done from becoming an impediment to a bigger role >>>>>for >>>>>whitespace database administration in the future, one of managing >>>>>coexistence and brokering spectrum reuse. >>>>>=20 >>>>> In all methods of using a database where a device negotiates with a >>>>>database, the types of messages that will be used are likely to be >>>>>similar:=20 >>>>> - This is who I am, what rules should I apply in negotiating for >>>>>spectrum? =20 >>>>> - This is the spectrum I am looking for, what do you have? >>>>> - This is the spectrum that meets your query criteria. >>>>> - etc. >>>>> The methods developed for trust are also reusable. This is the >>>>>reason >>>>>for having a portion of the data model remain the same for all >>>>>expansions. >>>>>=20 >>>>> The differences between a TVWS scenario and a brokering scenario are >>>>>likely to be additional messaging and different data, both for the >>>>>business of brokering and for defining the spectrum authorization. >>>>>For >>>>>example, in the brokering use case there needs to be a spectrum data >>>>>model that allows a primary spectrum user to release spectrum into the >>>>>market, (e.g., provide their contours ) and to specify the terms of >>>>>use. >>>>> My concern is that if the data model of TVWS comingles the data of >>>>>messaging, administration, and spectrum; that this sort of expansion >>>>>of >>>>>paws would require increasing the size of the data model and would >>>>>make >>>>>expanding its capability more difficult both because of the impact of >>>>>this expansion on legacy uses and because of the confusion of using >>>>>large schemas that have similar but different data elements. >>>>>=20 >>>>> My solution is to divide the data model into three parts. The data >>>>>document of messages would use the namespace of three schemas. In the >>>>>TVWS edition, this would also allow different administrative and >>>>>spectrum schemas for different regulatory domains. In end, the data >>>>>for >>>>>TVWS management would not be any different, it would just be defined >>>>>in >>>>>three schemas >>>>>=20 >>>>> In the initial exchanges between a device and a database, there would >>>>>be agreement on which schemas to use. This is equivalent to resolving >>>>>the regulatory domain. The messaging that follows would be the exact >>>>>same, with the exact same data as the messaging if a comingled data >>>>>model were used. >>>>>=20 >>>>> If the division is done well, then, in the long term, others can >>>>>create >>>>>schemas for administration and spectrum definition that meets their >>>>>business needs without having to do so through paws. They would be >>>>>able >>>>>expand the way the paws protocol is used without having to revise >>>>>paws. >>>>>=20 >>>>> I hope this better explains my intent. It would also be helpful to >>>>>understand why anyone thinks this should not be done. >>>>>=20 >>>>> John >>>>> _______________________________________________ >>>>> 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 jstine@mitre.org Tue Feb 28 14:08:06 2012 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 0E55721E803F for ; Tue, 28 Feb 2012 14:08:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1Z+IAtqC0xw for ; Tue, 28 Feb 2012 14:08:00 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD5221E802D for ; Tue, 28 Feb 2012 14:08:00 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1939A21B04A6; Tue, 28 Feb 2012 17:08:00 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id DAEE221B0497; Tue, 28 Feb 2012 17:07:59 -0500 (EST) Received: from IMCMBX01.MITRE.ORG ([169.254.1.10]) by IMCCAS02.MITRE.ORG ([129.83.29.79]) with mapi id 14.01.0339.001; Tue, 28 Feb 2012 17:07:59 -0500 From: "Stine, John A." To: "Basavaraj.Patil@nokia.com" Thread-Topic: [paws] Further explanation of partitioned data models Thread-Index: Acz1lJ9eeI3tcX6CR/OsHevKOQTVXP//9bGAgAAT6gD///4kAIAA2xaA//+JajCAAH9hgP//iMxwABZrDQD//4bfAA== Date: Tue, 28 Feb 2012 22:07:58 +0000 Message-ID: <2782C93FD2244441893673F3F91281921155C2@IMCMBX01.MITRE.ORG> References: <2782C93FD2244441893673F3F912819211541F@IMCMBX01.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Further explanation of partitioned data models 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, 28 Feb 2012 22:08:06 -0000 Raj, That is great! Thank you. John -----Original Message----- From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com]=20 Sent: Tuesday, February 28, 2012 4:52 PM To: Stine, John A. Cc: paws@ietf.org Subject: Re: [paws] Further explanation of partitioned data models How about adding the following as a subsection to the requirements section: " Sec x.y Guidelines for protocol and data model design The current scope of the working group is limited and are reflected in the requirements captured in Section y.z. However white space technology itself is expected to evolve and address other aspects such as co-existence and interference avoidance, spectrum brokering, alternative spectrum bands, etc. The design of the data model and protocol should be cognizant of the evolving nature of white space technology and consider the following set of guidelines in the development of the data model and protocol: 1. The data model SHOULD provide a modular design separating out messaging specific, administrative specific, and spectrum specific parts into separate modules. 2. The protocol SHOULD support determination of which administrative specific and spectrum specific modules are used. " -Raj On 2/28/12 12:38 PM, "ext Stine, John A." wrote: >Hi Raj, > > That would be fine. > >John > >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: Tuesday, February 28, 2012 1:17 PM >To: Stine, John A. >Cc: paws@ietf.org >Subject: Re: [paws] Further explanation of partitioned data models > > >Hi John, > >Rather than stating that the data model MUST be modular or the protocol >MUST support determination of which administrative and spectrum specific >modules are used, I would propose these to be included as guidelines to be >used in the design of the data model and protocol. >In addition to having a set of requirements, we could add guidelines as >well to abet the solutions. > >-Raj > >On 2/28/12 12:02 PM, "ext Stine, John A." wrote: > >>How about this >> >>D.X The data model MUST provide a modular design separating out >>messaging specific, administrative specific, and spectrum specific parts >>into separate modules. >> >>P.X The protocol MUST support determination of which administrative >>specific and spectrum specific modules are used. >> >>This is very specific and it is NOT requiring any increase in scope. >> >>John >> >>-----Original Message----- >>From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >>Sent: Tuesday, February 28, 2012 12:45 PM >>To: scott.probasco@nokia.com; Stine, John A.; Brian.Rosen@neustar.biz >>Cc: paws@ietf.org >>Subject: Re: [paws] Further explanation of partitioned data models >> >>Inline: >> >>On 2/27/12 10:41 PM, "ext scott.probasco@nokia.com" >> wrote: >> >>>Hi, >>> >>>As a way forward, how about two additional requirements >>> >>>D.X The Data Model MUST be extensible. >>> >>>P.X The protocol MUST be extensible. >>> >>>This captures the desire to extend both the Data Model and the protocol >>>in >>>the future, without identifying a specific solution at this time. >> >>The above requirements are overly broad and tends to result in protocol >>bloat.=20 >>Extensibility is something to be kept in mind with the cognizance that >>the >>WS technology will evolve but I would refrain from adding the above >>requirements to the I-D. >> >>-Raj >> >>> >>>Kind Regards, >>>Scott >>> >>> >>> >>> >>>On 2/27/12 4:47 PM, "ext Stine, John A." wrote: >>> >>>>Brian, >>>> >>>> I want to make it very clear that I am not advocating that in this go >>>>around that you add anything that increase the scope toward managing >>>>coexistence or adding spectrum to the database. I used those as >>>>examples >>>>of future upgrades. I am just making recommendations that you don't do >>>>something now that makes it more difficult to do something different in >>>>the future. >>>> >>>> I agree with your personal comment that most of your messaging would >>>>remain the same. However, I do not believe the administrative (i.e., >>>>regulatory )data and spectrum use data that you will come up with for >>>>TV >>>>whitespace will be rich enough to account for the many ways of sharing >>>>spectrum in the future and the coordination that must take place. >>>>Trying >>>>to make it so now will cause the very problem you are objecting to. It >>>>will complicate this first effort. Proceeding on the assumption that >>>>it >>>>can be upgraded easily, I believe, will be the original sin of PAWS and >>>>make upgrade very difficult. The first iteration of PAWS will affect >>>>other standards and those standards will serve as inertia to upgrades. >>>>Creating a PAWS standard that allows for the use of different data >>>>models >>>>simply keeps this from being a problem. The legacy data model can be >>>>used with the legacy standard. A new data model can be used with a new >>>>standard or a different band or different regulations. >>>> >>>> Consider this problem. In future upgrades, if coexistence were ever >>>>managed, how would the different database administrators collaborate in >>>>defining the boundaries between the TVWS users? Right now it is going >>>>to >>>>be the wild west. Short range unlicensed is a different problem than >>>>long range unlicensed. With the larger spaces of the TVWS frequencies >>>>there will be greater potential for overlap of users and so >>>>interference >>>>among users. =20 >>>> >>>>John >>>> >>>>-----Original Message----- >>>>From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] >>>>Sent: Monday, February 27, 2012 4:36 PM >>>>To: Stine, John A. >>>>Cc: paws@ietf.org >>>>Subject: Re: [paws] Further explanation of partitioned data models >>>> >>>> >>>>Discussions of spectrum coexistence is explicitly out of scope, and we >>>>have a big enough job to do without increasing scope. >>>>The scope is also limited to the problem of a device requesting >>>>spectrum, >>>>and discussions of provisioning ("releasing new spectrum") is out of >>>>scope. Only the device-to-database query and its response is in scope. >>>> >>>> >>>>If we ever get to coexistence work, the additional messaging is some >>>>form >>>>of "use this explicit spectrum, I'm suggesting that you >>>>use >>>>it, even if you could use other spectrum" or "of the >>>>choices you gave me, I'll use this part, and please try and keep other >>>>users out of my way". Either is a simple expansion of the basic query >>>>(location and band in, spectrum choices out). As such, I don't think >>>>we >>>>have to do anything in anticipation of such a future capability. >>>> >>>>I do think the notion of authentication of the device and the database >>>>is >>>>in scope, and I certainly think exchange of credentials or equivalent >>>>precedes spectrum query, so I suspect we're separating that part >>>>anyway. >>>>I certainly think we're trying to return spectrum choices that depend >>>>on >>>>location, device characteristics and things like time of day, and we're >>>>trying to design a protocol that will work for any country that decides >>>>to open spectrum for whitespace use and on any band they decide to do >>>>so. >>>> So long as we have enough data elements in the query to allow any of >>>>the >>>>algorithms that the regulators decide on to determine the available >>>>spectrum from the input query and provisioning information in the >>>>database, as well as have sufficient flexibility in the response of >>>>available spectrum to cover all the limits the regulators want to have, >>>>we should be okay. So far, I don't see any problems staying within the >>>>model we have been talking about. >>>> >>>>Brian >>>> >>>>On Feb 27, 2012, at 4:13 PM, Stine, John A. wrote: >>>> >>>>> From the lack of response to my email last week, I assume folks just >>>>>don't understand why I am recommending the division of the data model. >>>>>Please let me explain in a different way. >>>>>=20 >>>>> Last December, at the SDR Forum, Julius Knapp, the Director of the >>>>>OET >>>>>at the FCC, hosted a panel attended by five of the ten database >>>>>administrators. In that panel, he asked the panelists what was in it >>>>>for them. Several responded that they hoped they could provide a >>>>>service to those looking for spectrum and to help broker these >>>>>arrangements.=20 >>>>>=20 >>>>> This is not the model of TVWS. At present, the urgency of the paws >>>>>effort surrounds a narrower goal of enabling TVWS devices to obtain >>>>>channels they can use. I do not want to make any suggestions that >>>>>would >>>>>prevent us from achieving this goal first. I do want to make an >>>>>effort >>>>>to prevent what is done from becoming an impediment to a bigger role >>>>>for >>>>>whitespace database administration in the future, one of managing >>>>>coexistence and brokering spectrum reuse. >>>>>=20 >>>>> In all methods of using a database where a device negotiates with a >>>>>database, the types of messages that will be used are likely to be >>>>>similar:=20 >>>>> - This is who I am, what rules should I apply in negotiating for >>>>>spectrum? =20 >>>>> - This is the spectrum I am looking for, what do you have? >>>>> - This is the spectrum that meets your query criteria. >>>>> - etc. >>>>> The methods developed for trust are also reusable. This is the >>>>>reason >>>>>for having a portion of the data model remain the same for all >>>>>expansions. >>>>>=20 >>>>> The differences between a TVWS scenario and a brokering scenario are >>>>>likely to be additional messaging and different data, both for the >>>>>business of brokering and for defining the spectrum authorization. >>>>>For >>>>>example, in the brokering use case there needs to be a spectrum data >>>>>model that allows a primary spectrum user to release spectrum into the >>>>>market, (e.g., provide their contours ) and to specify the terms of >>>>>use. >>>>> My concern is that if the data model of TVWS comingles the data of >>>>>messaging, administration, and spectrum; that this sort of expansion >>>>>of >>>>>paws would require increasing the size of the data model and would >>>>>make >>>>>expanding its capability more difficult both because of the impact of >>>>>this expansion on legacy uses and because of the confusion of using >>>>>large schemas that have similar but different data elements. >>>>>=20 >>>>> My solution is to divide the data model into three parts. The data >>>>>document of messages would use the namespace of three schemas. In the >>>>>TVWS edition, this would also allow different administrative and >>>>>spectrum schemas for different regulatory domains. In end, the data >>>>>for >>>>>TVWS management would not be any different, it would just be defined >>>>>in >>>>>three schemas >>>>>=20 >>>>> In the initial exchanges between a device and a database, there would >>>>>be agreement on which schemas to use. This is equivalent to resolving >>>>>the regulatory domain. The messaging that follows would be the exact >>>>>same, with the exact same data as the messaging if a comingled data >>>>>model were used. >>>>>=20 >>>>> If the division is done well, then, in the long term, others can >>>>>create >>>>>schemas for administration and spectrum definition that meets their >>>>>business needs without having to do so through paws. They would be >>>>>able >>>>>expand the way the paws protocol is used without having to revise >>>>>paws. >>>>>=20 >>>>> I hope this better explains my intent. It would also be helpful to >>>>>understand why anyone thinks this should not be done. >>>>>=20 >>>>> John >>>>> _______________________________________________ >>>>> 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 internet-drafts@ietf.org Wed Feb 29 13:39:32 2012 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 AD6BC21F84C9; Wed, 29 Feb 2012 13:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVVvJE9V9m4c; Wed, 29 Feb 2012 13:39:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2AA21F86A6; Wed, 29 Feb 2012 13:39:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120229213908.28635.64443.idtracker@ietfa.amsl.com> Date: Wed, 29 Feb 2012 13:39:08 -0800 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt 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, 29 Feb 2012 21:39:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Workin= g Group of the IETF. Title : Protocol to Access White Space database: PS, use cases a= nd rqmts Author(s) : Scott Probasco Basavaraj Patil Filename : draft-ietf-paws-problem-stmt-usecases-rqmts-03.txt Pages : 41 Date : 2012-02-29 Portions of the radio spectrum that are assigned to a particular use but are unused or unoccupied at specific locations and times are defined as "white space". The concept of allowing additional transmissions (which may or may not be licensed) in white space is a technique to "unlock" existing spectrum for new use. An obvious requirement is that these additional transmissions do not interfere with the assigned use of the spectrum. One approach to using the white space spectrum at a given time and location is to verify with a database for available channels. This document describes the concept of TV White Spaces. It also describes the problems that need to be addressed to enable white space spectrum for additional uses, without causing interference to currently assigned use, by querying a database which stores information about the channel availability at any given location and time. A number of possible use cases of white space spectrum and technology as well as a set of requirements for the database query protocol are also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r= qmts-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-rq= mts-03.txt From scott.probasco@nokia.com Wed Feb 29 13:58:53 2012 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 C209021E8084 for ; Wed, 29 Feb 2012 13:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.68 X-Spam-Level: X-Spam-Status: No, score=-4.68 tagged_above=-999 required=5 tests=[AWL=1.919, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EhbOADZ5xFEg for ; Wed, 29 Feb 2012 13:58:52 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id E5DB621E8083 for ; Wed, 29 Feb 2012 13:58:51 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q1TLwoYa025516; Wed, 29 Feb 2012 23:58:50 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Feb 2012 23:58:50 +0200 Received: from 008-AM1MPN1-026.mgdnok.nokia.com ([169.254.6.199]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.01.0355.003; Wed, 29 Feb 2012 22:58:49 +0100 From: To: , Thread-Topic: Latest version of Use Cases & Requirements I-D Thread-Index: AQHM9y1QacNjlAuNJUiwuASfjndBCg== Date: Wed, 29 Feb 2012 21:58:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [172.19.60.138] Content-Type: text/plain; charset="us-ascii" Content-ID: <4566E8A69A53804DAC44E54B161F8638@mgd.nokia.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 29 Feb 2012 21:58:50.0383 (UTC) FILETIME=[51BCF9F0:01CCF72D] X-Nokia-AV: Clean Subject: [paws] Latest version of Use Cases & Requirements I-D 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, 29 Feb 2012 21:58:53 -0000 Hello, Rev 3 of the PS, Use cases and requirements I-D has now been posted. Thanks to all the people who provided comments and feedback on almost all sections of the document. We believe the I-D is ready for working group last call at this time and hence would like to request the chairs to initiate the call. Revision 3: http://www.ietf.org/internet-drafts/draft-ietf-paws-problem-stmt-usecases-r qmts-03.txt Diff from Revision 2: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-problem-stmt-usecases-= rq mts-03 Regards, Scott & Raj