From Gabor.Bajko@nokia.com Mon Apr 1 09:19:11 2013 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 5F0FE21E8041 for ; Mon, 1 Apr 2013 09:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UoVsCZRmveM2 for ; Mon, 1 Apr 2013 09:19:09 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id B3D3021E8037 for ; Mon, 1 Apr 2013 09:19:09 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r31GIofW007005; Mon, 1 Apr 2013 19:19:08 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.47]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Apr 2013 19:18:53 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.176]) by 008-AM1MMR1-013.mgdnok.nokia.com ([2002:4136:1e2f::4136:1e2f]) with mapi id 14.02.0328.011; Mon, 1 Apr 2013 16:18:53 +0000 From: To: Thread-Topic: [paws] Orlando minutes posted Thread-Index: Ac4mdoSXUPol/oEoQQyDA2ufXLSyDQFUUiEAAMsslhA= Date: Mon, 1 Apr 2013 16:18:53 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476021D92DA@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476021B109B@008-AM1MPN1-006.mgdnok.nokia.com> <51545FC6.8080900@qti.qualcomm.com> In-Reply-To: <51545FC6.8080900@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.143.158.145] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476021D92DA008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Apr 2013 16:18:53.0978 (UTC) FILETIME=[9A874FA0:01CE2EF4] X-Nokia-AV: Clean Cc: paws@ietf.org Subject: Re: [paws] Orlando minutes posted 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, 01 Apr 2013 16:19:11 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021D92DA008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Corrections done, thanks Pete for taking the time to review the minutes. - = Gabor From: ext Pete Resnick [mailto:presnick@qti.qualcomm.com] Sent: Thursday, March 28, 2013 8:21 AM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: paws@ietf.org Subject: Re: [paws] Orlando minutes posted On 3/21/13 3:56 PM, Gabor.Bajko@nokia.com wro= te: http://www.ietf.org/proceedings/86/minutes/minutes-86-paws Small updates regarding OFCOM: It shouldn't look like OFCOM was participati= ng in some official liaison-like capacity. That isn't how things work in th= e IETF meetings. So: OLD Chair reviewed the agenda; one remote participant: OFCOM - Cesar - will pro= vide a status update. NEW Chair reviewed the agenda; one remote participant: Cesar - will provide a s= tatus update on OFCOM. OLD First time for Ofcom participation in PAWS NEW First time for Cesar to participate in IETF OLD Request - Ofcom to review current use case document. NEW Request - Cesar to review current use case document. OLD Ofcom: would have a website that will have list of all websites of the DB p= roviders. NEW Andy: OFCOM was planning to have a website that will have list of all websi= tes of the DB providers. --- I haven't done a scrub of the rest of the minutes, but on first glance they= look fine. (Thanks Dorothy.) Other WG participants: Please review the minutes to make sure everything wa= s captured correctly. The minutes taker and the chairs should not have *all= * of the responsibility. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021D92DA008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Corrections done, than= ks Pete for taking the time to review the minutes. - Gabor

 

From: ext Pete Resnick [mailto:presnick@qti.qualcomm.co= m]
Sent: Thursday, March 28, 2013 8:21 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: paws@ietf.org
Subject: Re: [paws] Orlando minutes posted

 

On 3/21/13 3:56 PM, Gabor.Bajko@nokia.com wrote:

http://www.ietf.org/proceedings/86/minutes/minutes-86-pa= ws


Small updates regarding OFCOM: It shouldn't look like OFCOM was participati= ng in some official liaison-like capacity. That isn't how things work in th= e IETF meetings. So:

OLD
Chair reviewed the agenda; one remote participant: OFCOM – Cesar R= 11; will provide a status update.
NEW
Chair reviewed the agenda; one remote participant: Cesar – will provi= de a status update on OFCOM.

OLD
First time for Ofcom participation in PAWS
NEW
First time for Cesar to participate in IETF

OLD
Request – Ofcom to review current use case document.
NEW
Request – Cesar to review current use case document.

OLD
Ofcom: would have a website that will have list of all websites of the DB p= roviders.
NEW
Andy: OFCOM was planning to have a website that will have list of all websi= tes of the DB providers.

---

I haven't done a scrub of the rest of the minutes, but on first glance they= look fine. (Thanks Dorothy.)

Other WG participants: Please review the minutes to make sure everything wa= s captured correctly. The minutes taker and the chairs should not have *all= * of the responsibility.

pr

-- 
Pete Resnick <http:/=
/www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--_000_1ECAFF543A2FED4EA2BEB6CACE08E476021D92DA008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Mon Apr 1 10:05:33 2013 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 5B40821F8CC9 for ; Mon, 1 Apr 2013 10:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RHO8A1+hNgI9 for ; Mon, 1 Apr 2013 10:05:31 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id C450B21F874E for ; Mon, 1 Apr 2013 10:05:31 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r31H5SY7010693; Mon, 1 Apr 2013 20:05:28 +0300 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); Mon, 1 Apr 2013 20:05:27 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.176]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0328.011; Mon, 1 Apr 2013 17:05:26 +0000 From: To: , Thread-Topic: [paws] Database Discovery: static provisioning Thread-Index: AQHOKw4FgoYwaySD+EaDW+rIrIIsnZjBl8Sg Date: Mon, 1 Apr 2013 17:05:26 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476021DA338@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: [50.143.158.145] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E476021DA338008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 01 Apr 2013 17:05:27.0350 (UTC) FILETIME=[1B820D60:01CE2EFB] X-Nokia-AV: Clean Subject: Re: [paws] Database Discovery: static provisioning 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, 01 Apr 2013 17:05:33 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021DA338008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince, This is a good start, however I think it may worth adding some more context= to it. For instance, that some regulators certify a limited number of data= bases for operation in WS; that some regulators plan to maintain a website = listing all approved databases, others may not. The document also needs to address how to keep the preconfigured list of da= tabases up-to-date. Eg, when a preconfigured certified DB, which the master used to contact, is= going to shut down/go out of business/close down. In case a listing web site exists, should the master every now and then che= ck if its preconfigured list of DBs matches with the list on the web site, = and update accordingly. Master error handling: if one of the DB on in its preconfigured list is con= tacted, and there is no response, or there is an error response (eg 102 uns= upported), what should the master do next. What if none of the preconfigured DBs work. The behavior to some of the points above may be obvious, but I think it sti= ll needs to be spelled out. - gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Vincent Chen Sent: Wednesday, March 27, 2013 10:10 AM To: paws@ietf.org Subject: [paws] Database Discovery: static provisioning All, At the F2F, it was decided to update the language in the draft-ietf-paws-pr= otocol to explicitly allow static provisioning, while leaving room to adopt= dynamic provisioning, when it's defined. Here is the proposed language. Comments are welcomed. Thanks -vince ------------------------------ 4.1. Database Discovery The Device MUST determine the URI for the Database before it can send PAWS messages. The Device MAY be provisioned statically with the URI of one or more Databases. The Device SHOULD be provisioned with the URI of all the databases for which it is certified or otherwise permitted to operate. The Database MAY redirect a PAWS request by returning a HTTP 3xx response, as defined by HTTP/1.1 [RFC2616]. The Database MUST provide the redirect URI in the Location header of the 3xx response, and the Device MUST handle redirects by using the Location header provided by the Database. When redirecting, the Device MUST observe the delay indicated by the Retry-After header. The Device MUST authenticate the Database that returns the redirect response before following the redirect. Additionally, the Device MUST authenticate the Database indicated in the redirect. Because the Device may communicate with the Database without user interaction and because the Device authenticates the Database, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation, which is an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods. The Device MAY obtain the URI of one or more Databases dynamically from authorized and authenticated entities. The Device SHOULD use dynamic provisioning of Database URI when the mechanism is defined. --_000_1ECAFF543A2FED4EA2BEB6CACE08E476021DA338008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince,<= /p>

 <= /p>

This is a good start, how= ever I think it may worth adding some more context to it. For instance, tha= t some regulators certify a limited number of databases for operation in WS; that some regulators plan to maintain a website listi= ng all approved databases, others may not.

 <= /p>

The document also needs t= o address how to keep the preconfigured list of databases up-to-date.

Eg, when a preconfigured = certified DB, which the master used to contact, is going to shut down/go ou= t of business/close down.

In case a listing web sit= e exists, should the master every now and then check if its preconfigured l= ist of DBs matches with the list on the web site, and update accordingly.

Master error handling: if= one of the DB on in its preconfigured list is contacted, and there is no r= esponse, or there is an error response (eg 102 unsupported), what should the master do next.

What if none of the preco= nfigured DBs work.

 <= /p>

The behavior to some of t= he points above may be obvious, but I think it still needs to be spelled ou= t.

 <= /p>

- =          gabor<= /span>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Vincent Chen
Sent: Wednesday, March 27, 2013 10:10 AM
To: paws@ietf.org
Subject: [paws] Database Discovery: static provisioning

 

All,

 

At the F2F, it was decided to update the language in= the draft-ietf-paws-protocol to explicitly allow static provisioning, whil= e leaving room to adopt dynamic provisioning, when it's defined.=

 

Here is the proposed language. Comments are welcomed= . Thanks

 

-vince

 

------------------------------


 

4.1.  Database Discovery

 

   The Device MUST determine the URI for t= he Database before it can send

   PAWS messages.  The Device MAY be = provisioned statically with the URI

   of one or more Databases.  The Dev= ice SHOULD be provisioned with the

   URI of all the databases for which it i= s certified or otherwise

   permitted to operate.

 

   The Database MAY redirect a PAWS reques= t by returning a HTTP 3xx

   response, as defined by HTTP/1.1 [RFC26= 16].  The Database MUST

   provide the redirect URI in the Locatio= n header of the 3xx response,

   and the Device MUST handle redirects by= using the Location header

   provided by the Database.  When re= directing, the Device MUST observe

   the delay indicated by the Retry-After = header.  The Device MUST

   authenticate the Database that returns = the redirect response before

   following the redirect.  Additiona= lly, the Device MUST authenticate

   the Database indicated in the redirect.=  Because the Device may

   communicate with the Database without u= ser interaction and because

   the Device authenticates the Database, = when the response code is 301

   (Moved Permanently), the Device MAY red= irect without asking a user

   for confirmation, which is an exception= to the HTTP/1.1 [RFC2616]

   requirements for HTTP POST methods.

 

   The Device MAY obtain the URI of one or= more Databases dynamically

   from authorized and authenticated entit= ies.  The Device SHOULD use

   dynamic provisioning of Database URI wh= en the mechanism is defined.

 

--_000_1ECAFF543A2FED4EA2BEB6CACE08E476021DA338008AM1MPN1006mg_-- From vchen@google.com Thu Apr 4 12:25:40 2013 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 286BE21F8EF7 for ; Thu, 4 Apr 2013 12:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 lycQgOmnoCHL for ; Thu, 4 Apr 2013 12:25:39 -0700 (PDT) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id CB27C21F8ED8 for ; Thu, 4 Apr 2013 12:25:38 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id k13so3053311wgh.17 for ; Thu, 04 Apr 2013 12:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GU5scdW4NFAHhKohZ0m1ro/ItI1ci2/TxqPuZHfMxus=; b=bF/HxAjqlvApKemGO/rVAjkMGH3KsXklNII1ep/+UA5aF9kCxXVqgRUlucB9xj28uW s2EduAdL+U1szf7H/Wd9wms6J4xA38FiFAKD6ZW8zruq5In/dNVEjeZvqdeDmzKoqjg4 KJG5zqFVGyJ8FKg/FCRV11booh+xFrzEwG5WrSOjYOHLsj5mh+nkeKlXU9RNVYvVJrAn CzSieUp/Ug+ktbtbF2zz+qGVhZNDuYCXRIYUPDfUf87xpTlCRBV5HXhcS+rPoPl9yzxv 4J7bJSk9flr9/NQ6zCmejHLIzccH8QwFmBbhkpAX5wN9hduCezvDZPW+NU6hARx0yn+N BRsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=GU5scdW4NFAHhKohZ0m1ro/ItI1ci2/TxqPuZHfMxus=; b=jjY2ijNAGisGyXEvMDTmiDolRo8nGxuYWlk/rGi8V1ld74sjAitu7JfS9dwzzQ9dG0 3OapQZeWPM2R/cfHPNueAphnUpa+9RHR8aBiERFrFYIzGHTFUmilmfnuN2zv52XdkeDB /yi+aKOIRzDzpgRkfWPmNDRIdpyA02Yuv3KaEPZQ2NMIlhsgKGJUqh8LP5jZ4rBe0qCX ibQSRSXmuKDkHq4qUpt13Pc3Nu9/kCSqNPxOxiUqpEuBvgn2vYhOVCpjVCXZBJ+fdwR+ jr88NXC5ps0jaXWvhpRFDPUFg3usXw8/V+vZ4j/rn7KsJXuW6l5fLpxIKrV8XGQw9dyy jOtA== MIME-Version: 1.0 X-Received: by 10.180.19.39 with SMTP id b7mr31826767wie.15.1365103537799; Thu, 04 Apr 2013 12:25:37 -0700 (PDT) Received: by 10.194.89.202 with HTTP; Thu, 4 Apr 2013 12:25:37 -0700 (PDT) In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476021DA338@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E476021DA338@008-AM1MPN1-006.mgdnok.nokia.com> Date: Thu, 4 Apr 2013 12:25:37 -0700 Message-ID: From: Vincent Chen To: "gabor.bajko@nokia.com" Content-Type: multipart/alternative; boundary=bcaec53d5ed973e42804d98def40 X-Gm-Message-State: ALoCoQkJBy+Is9st7M/hagyBlGw0S0HD5N/+BYrDNTIjXl0MpoDuBIHrRuVFBU+rRhjq2Y18pzN+HkquijX9dLZOSgJvUCwHo16hDd8M7KViApDjOEas/PAyVleCo5IGDIG0KOYb72/1fSF6Mk7wBu6hUQcylq8SgqDvBeiZMCLGJBqfOz4NZmDyN7ySPdAAbkEtb1wtS0Hq Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery: static provisioning 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, 04 Apr 2013 19:25:40 -0000 --bcaec53d5ed973e42804d98def40 Content-Type: text/plain; charset=ISO-8859-1 Gabor, Acknowledged. I'll take another stab at the additional points on how to maintain the lists. On Mon, Apr 1, 2013 at 10:05 AM, wrote: > Vince,**** > > ** ** > > This is a good start, however I think it may worth adding some more > context to it. For instance, that some regulators certify a limited number > of databases for operation in WS; that some regulators plan to maintain a > website listing all approved databases, others may not.**** > > ** ** > > The document also needs to address how to keep the preconfigured list of > databases up-to-date. **** > > Eg, when a preconfigured certified DB, which the master used to contact, > is going to shut down/go out of business/close down.**** > > In case a listing web site exists, should the master every now and then > check if its preconfigured list of DBs matches with the list on the web > site, and update accordingly.**** > > Master error handling: if one of the DB on in its preconfigured list is > contacted, and there is no response, or there is an error response (eg 102 > unsupported), what should the master do next. **** > > What if none of the preconfigured DBs work.**** > > ** ** > > The behavior to some of the points above may be obvious, but I think it > still needs to be spelled out.**** > > ** ** > > **- **gabor**** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] *On Behalf > Of *ext Vincent Chen > *Sent:* Wednesday, March 27, 2013 10:10 AM > *To:* paws@ietf.org > *Subject:* [paws] Database Discovery: static provisioning**** > > ** ** > > All,**** > > ** ** > > At the F2F, it was decided to update the language in the > draft-ietf-paws-protocol to explicitly allow static provisioning, while > leaving room to adopt dynamic provisioning, when it's defined.**** > > ** ** > > Here is the proposed language. Comments are welcomed. Thanks**** > > ** ** > > -vince**** > > ** ** > > ------------------------------**** > > > **** > > ** ** > > 4.1. Database Discovery**** > > ** ** > > The Device MUST determine the URI for the Database before it can send** > ** > > PAWS messages. The Device MAY be provisioned statically with the URI** > ** > > of one or more Databases. The Device SHOULD be provisioned with the*** > * > > URI of all the databases for which it is certified or otherwise**** > > permitted to operate.**** > > ** ** > > The Database MAY redirect a PAWS request by returning a HTTP 3xx**** > > response, as defined by HTTP/1.1 [RFC2616]. The Database MUST**** > > provide the redirect URI in the Location header of the 3xx response,*** > * > > and the Device MUST handle redirects by using the Location header**** > > provided by the Database. When redirecting, the Device MUST observe*** > * > > the delay indicated by the Retry-After header. The Device MUST**** > > authenticate the Database that returns the redirect response before**** > > following the redirect. Additionally, the Device MUST authenticate**** > > the Database indicated in the redirect. Because the Device may**** > > communicate with the Database without user interaction and because**** > > the Device authenticates the Database, when the response code is 301*** > * > > (Moved Permanently), the Device MAY redirect without asking a user**** > > for confirmation, which is an exception to the HTTP/1.1 [RFC2616]**** > > requirements for HTTP POST methods.**** > > ** ** > > The Device MAY obtain the URI of one or more Databases dynamically**** > > from authorized and authenticated entities. The Device SHOULD use**** > > dynamic provisioning of Database URI when the mechanism is defined.**** > > ** ** > -- -vince --bcaec53d5ed973e42804d98def40 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Gabor,

Acknowledged. I'll take anot= her stab at the additional points on how to maintain the lists.
=


On Mon, Apr 1= , 2013 at 10:05 AM, <Gabor.Bajko@nokia.com> wrote:

Vince,

=A0<= /p>

This is a good start, how= ever I think it may worth adding some more context to it. For instance, tha= t some regulators certify a limited number of databases for operation in WS; that some regulators plan to maintain a website listi= ng all approved databases, others may not.

=A0<= /p>

The document also needs t= o address how to keep the preconfigured list of databases up-to-date.

Eg, when a preconfigured = certified DB, which the master used to contact, is going to shut down/go ou= t of business/close down.

In case a listing web sit= e exists, should the master every now and then check if its preconfigured l= ist of DBs matches with the list on the web site, and update accordingly.

Master error handling: if= one of the DB on in its preconfigured list is contacted, and there is no r= esponse, or there is an error response (eg 102 unsupported), what should the master do next.

What if none of the preco= nfigured DBs work.

=A0<= /p>

The behavior to some of t= he points above may be obvious, but I think it still needs to be spelled ou= t.

=A0<= /p>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 gabor<= /span>

=A0<= /p>

From: paws-bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of ext Vincent Chen
Sent: Wednesday, March 27, 2013 10:10 AM
To: paws@ietf.org=
Subject: [paws] Database Discovery: static provisioning

=A0

All,

=A0

At the F2F, it was decided to update the language in= the draft-ietf-paws-protocol to explicitly allow static provisioning, whil= e leaving room to adopt dynamic provisioning, when it's defined.=

=A0

Here is the proposed language. Comments are welcomed= . Thanks

=A0

-vince

=A0

------------------------------


=A0

4.1. =A0Database Discovery

=A0

=A0 =A0The Device MUST determine the URI for the Dat= abase before it can send

=A0 =A0PAWS messages. =A0The Device MAY be provision= ed statically with the URI

=A0 =A0of one or more Databases. =A0The Device SHOUL= D be provisioned with the

=A0 =A0URI of all the databases for which it is cert= ified or otherwise

=A0 =A0permitted to operate.

=A0

=A0 =A0The Database MAY redirect a PAWS request by r= eturning a HTTP 3xx

=A0 =A0response, as defined by HTTP/1.1 [RFC2616]. = =A0The Database MUST

=A0 =A0provide the redirect URI in the Location head= er of the 3xx response,

=A0 =A0and the Device MUST handle redirects by using= the Location header

=A0 =A0provided by the Database. =A0When redirecting= , the Device MUST observe

=A0 =A0the delay indicated by the Retry-After header= . =A0The Device MUST

=A0 =A0authenticate the Database that returns the re= direct response before

=A0 =A0following the redirect. =A0Additionally, the = Device MUST authenticate

=A0 =A0the Database indicated in the redirect. =A0Be= cause the Device may

=A0 =A0communicate with the Database without user in= teraction and because

=A0 =A0the Device authenticates the Database, when t= he response code is 301

=A0 =A0(Moved Permanently), the Device MAY redirect = without asking a user

=A0 =A0for confirmation, which is an exception to th= e HTTP/1.1 [RFC2616]

=A0 =A0requirements for HTTP POST methods.=

=A0

=A0 =A0The Device MAY obtain the URI of one or more = Databases dynamically

=A0 =A0from authorized and authenticated entities. = =A0The Device SHOULD use

=A0 =A0dynamic provisioning of Database URI when the= mechanism is defined.

=A0




--
-vince
--bcaec53d5ed973e42804d98def40-- From Cesar.Gutierrez@ofcom.org.uk Mon Apr 8 05:32:43 2013 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 4AB5421F939C for ; Mon, 8 Apr 2013 05:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 x8SmVUElqer7 for ; Mon, 8 Apr 2013 05:32:42 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.169]) by ietfa.amsl.com (Postfix) with ESMTP id 2B62821F8A09 for ; Mon, 8 Apr 2013 05:32:41 -0700 (PDT) Received: from [85.158.138.51:52334] by server-9.bemta-3.messagelabs.com id 2D/F6-32531-7E8B2615; Mon, 08 Apr 2013 12:32:39 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-14.tower-174.messagelabs.com!1365424356!21748180!1 X-Originating-IP: [194.33.160.63] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18316 invoked from network); 8 Apr 2013 12:32:38 -0000 Received: from unknown (HELO WOK-INTRA-EDG01.intra.ofcom.local) (194.33.160.63) by server-14.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 8 Apr 2013 12:32:38 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG01.intra.ofcom.local (10.130.239.19) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 8 Apr 2013 13:33:53 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([::1]) with mapi id 14.01.0289.001; Mon, 8 Apr 2013 13:34:47 +0100 From: Cesar Gutierrez To: Vincent Chen Thread-Topic: [paws] Database Discovery: static provisioning Thread-Index: AQHOKw5LvBPAa3LBTEuoiSsQiLQXK5jBj1UAgATeKYCABeAlIA== Date: Mon, 8 Apr 2013 12:34:46 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655AE96BBF3@WOK-INTRA-EXC02.intra.ofcom.local> References: <1ECAFF543A2FED4EA2BEB6CACE08E476021DA338@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/alternative; boundary="_000_5D3E853BEE49C848BB63047C794C8655AE96BBF3WOKINTRAEXC02in_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Reza Karimi , "johnny.dixon@bt.com" Subject: Re: [paws] Database Discovery: static provisioning 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, 08 Apr 2013 12:32:43 -0000 --_000_5D3E853BEE49C848BB63047C794C8655AE96BBF3WOKINTRAEXC02in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince, Gabor, It is perhaps useful for this discussion, and for the development of the di= scovery protocol, to distribute to the PAWS group the UK requirements in th= is area. These requirements are captured in the draft of the ETSI Harmonise= d Standard: * At start up and before initiating any transmissions the Master WSD= shall locate and consult a listing of approved WSDBs relevant to its geogr= aphical domain. [The Master WSD shall not transmit if it cannot consult the= list]. * In order for the master WSD to continue to use an approved WSDB, i= t shall also reconsult this listing in accordance with the periodicity, N m= inutes relevant to its geographical domain of operation. N will be specifie= d in the same listing as the approved WSDBs. * A master WSD shall not request operational parameters from (i.e., = query) a WSDB that is not on the list of approved WSDBs relevant to its geo= graphical domain. * Once the time specified (N) has expired, the master WSD shall cons= ult the listing of approved WSDBs again relevant to its geographical domain= before contacting a WSDB. * If the list is not accessible after the time specified by N has ex= pired, the WSD shall o continue to use the list that it already holds, and o reconsult the weblisting at least as frequently as once every 2 hours t= hereafter but not more frequently than once per hour until such time as whe= n the list can be accessed Secondly, I wonder whether it would be better to keep the UE behaviour with= regards to discovery and update of database list out of this protocol spec= ification. That is, the draft-ietf-paws-protocol would make the assumption = that the device has the URI of an approved database and not would worry abo= ut how it got it. It looks to me that some of the requirements you discuss = below could be left implementation dependent, and others would be addressed= by the database discovery protocol. Regards, Cesar From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: 04 April 2013 20:26 To: gabor.bajko@nokia.com Cc: paws@ietf.org Subject: Re: [paws] Database Discovery: static provisioning Gabor, Acknowledged. I'll take another stab at the additional points on how to mai= ntain the lists. On Mon, Apr 1, 2013 at 10:05 AM, > wrote: Vince, This is a good start, however I think it may worth adding some more context= to it. For instance, that some regulators certify a limited number of data= bases for operation in WS; that some regulators plan to maintain a website = listing all approved databases, others may not. The document also needs to address how to keep the preconfigured list of da= tabases up-to-date. Eg, when a preconfigured certified DB, which the master used to contact, is= going to shut down/go out of business/close down. In case a listing web site exists, should the master every now and then che= ck if its preconfigured list of DBs matches with the list on the web site, = and update accordingly. Master error handling: if one of the DB on in its preconfigured list is con= tacted, and there is no response, or there is an error response (eg 102 uns= upported), what should the master do next. What if none of the preconfigured DBs work. The behavior to some of the points above may be obvious, but I think it sti= ll needs to be spelled out. - gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Vincent Chen Sent: Wednesday, March 27, 2013 10:10 AM To: paws@ietf.org Subject: [paws] Database Discovery: static provisioning All, At the F2F, it was decided to update the language in the draft-ietf-paws-pr= otocol to explicitly allow static provisioning, while leaving room to adopt= dynamic provisioning, when it's defined. Here is the proposed language. Comments are welcomed. Thanks -vince ------------------------------ 4.1. Database Discovery The Device MUST determine the URI for the Database before it can send PAWS messages. The Device MAY be provisioned statically with the URI of one or more Databases. The Device SHOULD be provisioned with the URI of all the databases for which it is certified or otherwise permitted to operate. The Database MAY redirect a PAWS request by returning a HTTP 3xx response, as defined by HTTP/1.1 [RFC2616]. The Database MUST provide the redirect URI in the Location header of the 3xx response, and the Device MUST handle redirects by using the Location header provided by the Database. When redirecting, the Device MUST observe the delay indicated by the Retry-After header. The Device MUST authenticate the Database that returns the redirect response before following the redirect. Additionally, the Device MUST authenticate the Database indicated in the redirect. Because the Device may communicate with the Database without user interaction and because the Device authenticates the Database, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation, which is an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods. The Device MAY obtain the URI of one or more Databases dynamically from authorized and authenticated entities. The Device SHOULD use dynamic provisioning of Database URI when the mechanism is defined. -- -vince ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_5D3E853BEE49C848BB63047C794C8655AE96BBF3WOKINTRAEXC02in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince, Gabor,

 

It is perhaps useful fo= r this discussion, and for the development of the discovery protocol, to di= stribute to the PAWS group the UK requirements in this area. These requirements are captured in the draft of the ETSI Harmonised Standa= rd:

 

&midd= ot;   = ;     At start up and before in= itiating any transmissions the Master WSD shall locate and consult a listin= g of approved WSDBs relevant to its geographical domain. [The Master WSD shall not transmit if it cannot consult the list].<= /p>

&midd= ot;   = ;     In order for the master W= SD to continue to use an approved WSDB, it shall also reconsult this listin= g in accordance with the periodicity, N minutes relevant to its geographical domain of operation. N will be specified in the same l= isting as the approved WSDBs.

&midd= ot;   = ;     A master WSD shall not re= quest operational parameters from (i.e., query) a WSDB that is not on the l= ist of approved WSDBs relevant to its geographical domain.

&midd= ot;   = ;     Once the time specified (= N) has expired, the master WSD shall consult the listing of approved WSDBs = again relevant to its geographical domain before contacting a WSDB.

&midd= ot;   = ;     If the list is not access= ible after the time specified by N has expired, the WSD shall

o   continue to use the list = that it already holds, and

o   reconsult the weblisting = at least as frequently as once every 2 hours thereafter but not more freque= ntly than once per hour until such time as when the list can be accessed

 

Secondly, I wonder whet= her it would be better to keep the UE behaviour with regards to discovery a= nd update of database list out of this protocol specification. That is, the draft-ietf-paws-protocol would make the assumption that the d= evice has the URI of an approved database and not would worry about how it = got it. It looks to me that some of the requirements you discuss below coul= d be left implementation dependent, and others would be addressed by the database discovery protocol.

 

Regards,

Cesar

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of Vincent Chen
Sent: 04 April 2013 20:26
To: gabor.bajko@nokia.com
Cc: paws@ietf.org
Subject: Re: [paws] Database Discovery: static provisioning

 

Gabor,

 

Acknowledged. I'll take another stab at the addition= al points on how to maintain the lists.

 

On Mon, Apr 1, 2013 at 10:05 AM, <Gabor.Bajko@nokia.com> w= rote:

Vince,

 

This is a good start, however I think it may worth adding some more cont= ext to it. For instance, that some regulators certify a limited number of databases for operation in WS; that some regulators plan to main= tain a website listing all approved databases, others may not.

 

The document also needs to address how to keep the preconfigured list of= databases up-to-date.

Eg, when a preconfigured certified DB, which the master used to contact,= is going to shut down/go out of business/close down.

In case a listing web site exists, should the master every now and then = check if its preconfigured list of DBs matches with the list on the web site, and update accordingly.

Master error handling: if one of the DB on in its preconfigured list is = contacted, and there is no response, or there is an error response (eg 102 unsupported), what should the master do next.

What if none of the preconfigured DBs work.<= /span>

 

The behavior to some of the points above may be obvious, but I think it = still needs to be spelled out.

 

-     &nb= sp;    gabor

 

From: paws-bounces@iet= f.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Vincent Chen
Sent: Wednesday, March 27, 2013 10:10 AM
To: paws@ietf.org=
Subject: [paws] Database Discovery: static provisioning

 

All,

 

At the F2F, it was d= ecided to update the language in the draft-ietf-paws-protocol to explicitly= allow static provisioning, while leaving room to adopt dynamic provisionin= g, when it's defined.

 

Here is the proposed= language. Comments are welcomed. Thanks

 

-vince

 

--------------------= ----------


 

4.1.  Database = Discovery

 

   The Dev= ice MUST determine the URI for the Database before it can send

   PAWS me= ssages.  The Device MAY be provisioned statically with the URI<= /p>

   of one = or more Databases.  The Device SHOULD be provisioned with the

   URI of = all the databases for which it is certified or otherwise

   permitt= ed to operate.

 

   The Dat= abase MAY redirect a PAWS request by returning a HTTP 3xx

   respons= e, as defined by HTTP/1.1 [RFC2616].  The Database MUST

   provide= the redirect URI in the Location header of the 3xx response,

   and the= Device MUST handle redirects by using the Location header

   provide= d by the Database.  When redirecting, the Device MUST observe

   the del= ay indicated by the Retry-After header.  The Device MUST

   authent= icate the Database that returns the redirect response before

   followi= ng the redirect.  Additionally, the Device MUST authenticate

   the Dat= abase indicated in the redirect.  Because the Device may

   communi= cate with the Database without user interaction and because

   the Dev= ice authenticates the Database, when the response code is 301

   (Moved = Permanently), the Device MAY redirect without asking a user

   for con= firmation, which is an exception to the HTTP/1.1 [RFC2616]

   require= ments for HTTP POST methods.

 

   The Dev= ice MAY obtain the URI of one or more Databases dynamically

   from au= thorized and authenticated entities.  The Device SHOULD use

   dynamic= provisioning of Database URI when the mechanism is defined.

 



 

--
-vince



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_5D3E853BEE49C848BB63047C794C8655AE96BBF3WOKINTRAEXC02in_-- From Cesar.Gutierrez@ofcom.org.uk Mon Apr 8 09:55:36 2013 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 6362F21F9401 for ; Mon, 8 Apr 2013 09:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.097 X-Spam-Level: X-Spam-Status: No, score=-5.097 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=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 KNn8TAiA39Hr for ; Mon, 8 Apr 2013 09:55:35 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0921F9397 for ; Mon, 8 Apr 2013 09:55:34 -0700 (PDT) Received: from [85.158.143.99:60006] by server-1.bemta-4.messagelabs.com id 7C/82-06203-486F2615; Mon, 08 Apr 2013 16:55:32 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-10.tower-216.messagelabs.com!1365440130!21090035!1 X-Originating-IP: [194.33.160.63] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24444 invoked from network); 8 Apr 2013 16:55:31 -0000 Received: from unknown (HELO WOK-INTRA-EDG01.intra.ofcom.local) (194.33.160.63) by server-10.tower-216.messagelabs.com with AES128-SHA encrypted SMTP; 8 Apr 2013 16:55:31 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG01.intra.ofcom.local (10.130.239.19) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 8 Apr 2013 17:56:47 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([::1]) with mapi id 14.01.0289.001; Mon, 8 Apr 2013 17:57:42 +0100 From: Cesar Gutierrez To: Vincent Chen , "paws@ietf.org" Thread-Topic: Extensibility for Ofcom Thread-Index: AQHOIHNmt1XIIptGdkaE4YjIqJua/5jMr6eA Date: Mon, 8 Apr 2013 16:57:41 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655AE96BCA6@WOK-INTRA-EXC02.intra.ofcom.local> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/mixed; boundary="_004_5D3E853BEE49C848BB63047C794C8655AE96BCA6WOKINTRAEXC02in_" MIME-Version: 1.0 Cc: Reza Karimi , "johnny.dixon@bt.com" Subject: Re: [paws] Extensibility for Ofcom 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, 08 Apr 2013 16:55:36 -0000 --_004_5D3E853BEE49C848BB63047C794C8655AE96BCA6WOKINTRAEXC02in_ Content-Type: multipart/alternative; boundary="_000_5D3E853BEE49C848BB63047C794C8655AE96BCA6WOKINTRAEXC02in_" --_000_5D3E853BEE49C848BB63047C794C8655AE96BCA6WOKINTRAEXC02in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince and all, The attached is the list of the parameters that need to be incorporated to = existing IETF PAWS protocol functionalities in order to cover the requireme= nts in the current draft of the ETSI Harmonised Standard. I would be gratef= ul if IETF PAWS members could review and comment. Please note that this list does not address support for the current databa= se discovery requirement in ETSI HS. It does not address either the device = update function (or kill switch, or PUSH) that was briefly discussed at th= e meeting in Orlando. We are still discussing this function in ETSI and the= UK, and I expect to bring it to consideration of IETF PAWS members in the = coming weeks. Thanks and regards, Cesar From: Vincent Chen [mailto:vchen@google.com] Sent: 14 March 2013 05:17 To: Cesar Gutierrez; paws@ietf.org Subject: Extensibility for Ofcom Cesar, Thanks for joining the call for the IETF/PAWS. I want to follow up with you on the parameter names and values that we shou= ld consider adding to the draft to support Ofcom White Space rules. In part= icular: - What is the "unique device identifier" intended to be? Is there a separa= te certification ID apart from the serial number? - What should be the parameter name for "device class"? What are the possi= ble values and what do they mean? - What should be the parameter name for "technology ID"? What are the poss= ible vales and what do they mean? Are you aware of other parameters that must be defined for Ofcom? Thanks for your help. -- -vince ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_5D3E853BEE49C848BB63047C794C8655AE96BCA6WOKINTRAEXC02in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince and all,

 

The attached is the lis= t of the parameters that need to be incorporated to existing IETF PAWS prot= ocol functionalities in order to cover the requirements in the current draft of the ETSI Harmonised Standard. I would be grateful = if IETF PAWS members could review and comment.

 

Please note that this l= ist  does not address support for the current database discovery requi= rement in ETSI HS. It does not address either the device update function (or kill switch, or PUSH)  that was briefly discussed at the= meeting in Orlando. We are still discussing this function in ETSI and the = UK, and I expect to bring it to consideration of IETF PAWS members in the c= oming weeks.

 

Thanks and regards,

Cesar

 

 

 

 

From: Vincent Chen [mailto:vchen@google.com]
Sent: 14 March 2013 05:17
To: Cesar Gutierrez; paws@ietf.org
Subject: Extensibility for Ofcom

 

Cesar,

 

Thanks for joining the call for the IETF/PAWS.

 

I want to follow up with you on the parameter names = and values that we should consider adding to the draft to support Ofcom Whi= te Space rules. In particular:

 

 - What is the "unique device identifier&q= uot; intended to be? Is there a separate certification ID apart from the se= rial number?

 

 - What should be the parameter name for "= device class"? What are the possible values and what do they mean?

 

 - What should be the parameter name for "= technology ID"? What are the possible vales and what do they mean?

 

Are you aware of other parameters that must be defin= ed for Ofcom?

 

Thanks for your help.

 

--
-vince



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_5D3E853BEE49C848BB63047C794C8655AE96BCA6WOKINTRAEXC02in_-- --_004_5D3E853BEE49C848BB63047C794C8655AE96BCA6WOKINTRAEXC02in_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="Parameters for IETF PAWS.DOCX" Content-Description: Parameters for IETF PAWS.DOCX Content-Disposition: attachment; filename="Parameters for IETF PAWS.DOCX"; size=13376; creation-date="Mon, 08 Apr 2013 16:56:57 GMT"; modification-date="Mon, 08 Apr 2013 16:56:57 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQBvGmuQfgEAACgGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 lM1qwzAQhO+FvoPRtdhKeiil2M6hP8c20PQBFGmdiNqSkDZ/b9+145hSEocm+GIwZr+ZHY+UTrZV Ga3BB21NxsbJiEVgpFXaLDL2NXuLH1kUUBglSmsgYzsIbJLf3qSznYMQ0bQJGVsiuifOg1xCJUJi HRj6UlhfCaRXv+BOyG+xAH4/Gj1waQ2CwRhrBsvTDzLgtYJoKjy+i4p0+MZ6xQtr0ViEkBCORc/7 uVo6Y8K5UkuBZJyvjfojGtui0BKUlauKpJIa57yVEAKtVpVJh76r0TxPX6AQqxKj1y1528fhoQz/ U23XTGiycRaW2oUehf61Wmcn4+m268dckE5HroQ2B/8nfQTclUP8oz33rDwYNVBJDuQ+CxTV1FsX OBXy6ppCXT4FKqauOvCooWvP6fQBkTo9wBkJLblv/eacIp174M1zfHUGDeasZEF3wUzMS7ha78jV 0KLPmtjA/HOw9H/B+4x0/ZPWXxDG4caqp4+0jjf3fP4DAAD//wMAUEsDBBQABgAIAAAAIQAekRq3 8wAAAE4CAAALAAgCX3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusD hJnsAXcOzKTavr2jILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfO sGlub9YvPJGUoTyMMaui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1p Z+9AtcdYNl/WDl03Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9f i46FLAmhCYnP83x1nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAA IQARF6DZFAEAADkEAAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKyTy07DMBBF90j8gzV74qRAQahONwipWwgf4CaTh0g8 kT088vdYkRJSqMLGG0tzLd97PGPv9l9dKz7QuoaMgiSKQaDJqWhMpeA1e7q6B+FYm0K3ZFDBgA72 6eXF7hlbzf6Qq5veCe9inIKauX+Q0uU1dtpF1KPxOyXZTrMvbSV7nb/pCuUmjrfSLj0gPfEUh0KB PRTXILKh98n/e1NZNjk+Uv7eoeEzEfITjy/I7C/nvK22FbKChRh5WpDnQe5CgrBvEP4gjKUc12SN YROSwf3pxKSsISRBEXho/YOaR+HGei1+GzK+JMOZPraLSczSGsRtSAg0hSFedmFS1hBuQiKURPyL YZYmCHny4dNvAAAA//8DAFBLAwQUAAYACAAAACEATrjbuFUIAACbWgAAEQAAAHdvcmQvZG9jdW1l bnQueG1s7Fxtb+I4EP5+0v2HKJ+vJZS2B2jpiitwu9JehRZW1X40iYHc+iVyDJT99Td2Xo4AaSEl FLb+ZLCT8XgeO/N4PMmHj0+UWHMsQp+zll29dGwLM5d7Ppu07G/D3kXdtkKJmIcIZ7hlL3Fof7z7 /bcPi6bH3RnFTFoggoXNObROpQyalUroTjFF4SUPMIPGMRcUSfgrJhWKxI9ZcOFyGiDpj3ziy2Xl ynFu7VgMb9kzwZqxiAvqu4KHfCzVLU0+HvsujovkDrFLv9GdnVhl3WNFYAI6cBZO/SBMpNGi0mCI 00TI/LlBzClJrlsEu/TmCbQAPCiJ1F5w4QWCuzgMobYTNaYSq85zfccGVCLSO3ZRIdtnoglFPkvF qNmxhn8K3iWAV4n6rihR/w8EbHEHc2nEvaUq5YjERV/EPwZySbC1aM4RadlDNCL4b+F7diVuDvoC Ggkey57gdIifJEzjOkzjRVP4k+lm7ZSLn23mQtGyYTZO1BB0x8F3uNNxblLRj1C/aNlallwGMD40 kzxt/sL5D7hC6+Vctx3VUNGSUt2VpkrPCZT3nETyrhp/ViMhmepaLek6W+1c3265utG42lJbq9+u qJH0LpWFYIV7X2EwTr1Ru260tX1UVR/M4DhXnRun0Usqh7quXa11el0Nj3S1td14YG5sGT0SkB0Z x3tCiQniC4M9+/3awWM0I4Dgupp9VbWiEKCuNAoD5MIagG7QWGLQunqlxw/DjS4QPc5kqNpD1/eH 8FgCFCn6l4tPbRb6asBT9WOzRc+vUQSpFgbQxr2m5szYTulz+F7BuHd9JBDFMD6LQannmJ5pYAKl VDTrYoS24qSnFgzV4ARzvDycvnBX+5MiCKlVbhCKnkLlITQIsOsDhSgKk3rqGpTKRmkIvrbIGlLO ryR0sv7xtLxRecvlgUsc5iOhyI52wzsQjCzrOB7ByPZ7YgQDDLhGLYDX83FXKIYROeswwIQMJBIy onuqRVO5iHvEwzvUFEgUUqzjH8RmY+TKmcDicyczC4B0bNWzyzQvPxYp+eWwLQPGDp7DlrmDQ1f4 geSiBCBfzV3ODEj9zDsE1V9dbt3h4LPVfbBqTtW6adQzMO22oF5NTgwM8m4gBWwoC1hfb73Tx3aR vfBZmT8zJeGPIQKviTQkDwJl1Shwsd3Bvg0R4B4mhgHsHT4qAqphAJrcnlYccBPIUhgADNpn2LNG S4uucO8CvsgwAXDERSK+CdJq/2OYwPaoeGIjKLWvUmUagoY/hgkcmwmU4TTUdqT74OnN40Y8zuz/ Xz48Wl8meTZbpXRlAGn2/xAwO+yKLMX7m/2/it3nH8aeynrqshnNULK8hb1fMPTVZxcmeqDSR8rK Uzgr6+bNyLJdzSpn6FIf0pMgt+qeoDB7hpSn3n4LRmXLvJ9wW57NyobUsAfDHjTdeTmVyzwic9LI EuaiggqGPRTIw0sMCKWJOBw8y3Hdum/laiL2ILE7ZZzwydKcOJgTh1xGXzM5BwcIcZuYw74xh1JC P+akwZw0HP/thtPy+9FJwz2SeMLFsoQAm4kXrGeSmtOG95trYDz/vp7/5YSsMtaTiReYeMEv8NJC GUuDoqchl4j89WjYwubrq2dxlqpex5NiRgfwvQBvRrIvfeXFofY7JjJxggPECXxmffr5h9VvPw4s 8IOSu5xkFp2KzKY5YLlBG5OWeAAseoQjWcD45v0ElR8gAIHnv4SQPcY6xouKp57s/DbMF9z7A6c+ Q+R+ihjDxs/v/wGLUwnxGD9/HlkExs/v8FWYzUVVyqHAO/Pz/wEAAP//7Fdta9swEP4rwp8LdWq3 jcMSCK2zFbYS6kA/K7Zsa9iSkM51s1+/k+x0TuNB6cu+rGCQpZN0p3vudI9q+lPqb0thuEfaWWl/ NiWr2dwbSE4XX07bmV5r16p963qQdg3K2hlo3EQbnt3NPd+fRkEYLe2+bmitjwc3bmw5Ca5Xsed2 wO1wn9TqsO09rm7n3ll0ObEbwU6hadkj9Tqb9hPVXsmxirtrltOmgmPJ2g4NdLuDtTOjaMpFgTvS HBgaODnzrbreA9ispABj5SblI+5Cycsd2c6UljKPtXVddzyjWFUlQDX0at9bNypaxJvkJr6t6eN3 mVLgUlyVVBTMAg0d3FbruG2xyHr/q6cYwGXj0AWBf/5a6MZC5hPPLl0HSWkhSxRLQTd1kpYsa6qP ANIPL/4rIN0V5G69d8p5ixMXpGagmTkh6+V9QjDDQKayOkg8TMIXZFYUnX3i8ZY72OKxqiSFVzg/ mF74n95/o/fJY125eotFXWFOMP3AvMWm5IbgByUjhtaM0O7/AKW/1aaPrptvqph4j3xALR/3IlFU o/OQwZyQbQPkmfc00o0nphZehctl6AjYO99347Y1ImOaWApCNCuaioLUO5LJmuL1yIHUdEe2iDvJ G5FackJk7sIhYw88ZcTyJCK1G6p6/kJKJlCEq1MqhAS7gWECSMuhdDOfeWCc2wzj59+4aHGH5dow uBG5fJGJY/TL0jaMLdtsK8fchsavpuF5PLXXlYN8wIgH9NeFJizW+7AxRDCWsYwgJjfxZtXVqxzd bhqlpAYLCh0BcEsNrkLQHMDxLQn8CTmfRgeH60ocZvHeKEvGrycX02A1ZmcvcTT8FUsMkqP1Qcgf qkpQPnggOAcWyS+0DR8f1ijnvBL/J5HvWJDUHINr7lVUZCalinVcXRU/qNUDUuHkMHQ1QvOixKn7 7lYCyPpPv2L5QFoyiskx9y59pzOX0j1C+m7RgOv2LxIkDvYhYp8seIXaOc5DmUy/ap6hpOKCrTmk aHqABasjjZ03XLRsZbZzP7ikqfFEi98AAAD//wMAUEsDBBQABgAIAAAAIQCNp5tKkgEAAGsEAAAS AAAAd29yZC9mb290bm90ZXMueG1szFPLbsIwELxX6j9EvoMDrRCKCFwQZ0TbD3AdB6zaXst2SPn7 rhOc0ocQ6qmXWPua2dndLFbvWmVH4bwEU5LJOCeZMBwqafYleXnejOYk84GZiikwoiQn4clqeX+3 aIsaIBgIwmeIYXxxxPAhBFtQ6vlBaObHYIXBYA1Os4Cm21PN3FtjRxy0ZUG+SiXDiU7zfEbOMFCS xpniDDHSkjvwUIdYUkBdSy7OT6pwt/D2lWvgjRYmdIzUCYU9gPEHaX1C039FQ4mHBHK8JuKoVcpr 7S1slWMtLkSrvu0WXGUdcOE9etd9cECc5Ne4zwOMEEPFLS185UydaCbNABPP49v+h+WNcXm056YR 6lMIzmJ5cUxZW4STRSQvLHMsgCPoklVJRpMu0aKJ11rtSpLn68ls/rCJGZ1rLWrWqPAzsr1wRTa7 dfHxlnGcIJazOgg8I7z+tlAyKpk+DsauUehgTQBClws6lPcYqc8+hL6Y0H3TD/KrPg4mSNN09/eU MJLW/F9K/bXla7JxEmkGfvkBAAD//wMAUEsDBBQABgAIAAAAIQAz2f9AkgEAAGUEAAARAAAAd29y ZC9lbmRub3Rlcy54bWzMVMtuwyAQvFfqP1jcE5y0iiorTi5RzlHafgDFOEEFFgGOm7/vYhv3qSjq qRcj9jGzs7tmuX7TKjsJ5yWYksymOcmE4VBJcyjJ89N28kAyH5ipmAIjSnIWnqxXtzfLthCmMhCE zxDC+OKE3mMItqDU86PQzE/BCoPOGpxmAa/uQDVzr42dcNCWBfkilQxnOs/zBRlgoCSNM8UAMdGS O/BQh5hSQF1LLoYjZbhrePvMDfBGCxM6RuqEwhrA+KO0PqHpv6KhxGMCOV0ScdIqxbX2GrbKsRbn oVVfdguusg648B6tm945Is7yS9xDAyPEmHFNCV85UyWaSTPCxO34Nv9xeFMcHu25aYT6EIK9WH3s UtYW4WwRyAvLHAvgCJpkVZLJrIuzeMVdrfYlyfPNbPFwt40RnWkjatao8NOz+2SKZHbn4uEt49hA TGd1ELhFuPttoWQUMr8fL/tGoYE1AQhdLemY3mOkOnsX2mJA9x1+j9/UcTBBmqZbvseEkJTm/1Lo ryVfEI1tSO/D6h0AAP//AwBQSwMEFAAGAAgAAAAhAJa1reKWBgAAUBsAABUAAAB3b3JkL3RoZW1l L3RoZW1lMS54bWzsWU9v2zYUvw/YdyB0b2MndhoHdYrYsZstTRvEboceaYmW2FCiQNJJfRva44AB w7phhxXYbYdhW4EW2KX7NNk6bB3Qr7BHUpLFWF6SNtiKrT4kEvnj+/8eH6mr1+7HDB0SISlP2l79 cs1DJPF5QJOw7d0e9i+teUgqnASY8YS0vSmR3rWN99+7itdVRGKCYH0i13Hbi5RK15eWpA/DWF7m KUlgbsxFjBW8inApEPgI6MZsablWW12KMU08lOAYyN4aj6lP0FCT9DZy4j0Gr4mSesBnYqBJE2eF wQYHdY2QU9llAh1i1vaAT8CPhuS+8hDDUsFE26uZn7e0cXUJr2eLmFqwtrSub37ZumxBcLBseIpw VDCt9xutK1sFfQNgah7X6/W6vXpBzwCw74OmVpYyzUZ/rd7JaZZA9nGedrfWrDVcfIn+ypzMrU6n 02xlsliiBmQfG3P4tdpqY3PZwRuQxTfn8I3OZre76uANyOJX5/D9K63Vhos3oIjR5GAOrR3a72fU C8iYs+1K+BrA12oZfIaCaCiiS7MY80QtirUY3+OiDwANZFjRBKlpSsbYhyju4ngkKNYM8DrBpRk7 5Mu5Ic0LSV/QVLW9D1MMGTGj9+r596+eP0XHD54dP/jp+OHD4wc/WkLOqm2chOVVL7/97M/HH6M/ nn7z8tEX1XhZxv/6wye//Px5NRDSZybOiy+f/PbsyYuvPv39u0cV8E2BR2X4kMZEopvkCO3zGBQz VnElJyNxvhXDCNPyis0klDjBmksF/Z6KHPTNKWaZdxw5OsS14B0B5aMKeH1yzxF4EImJohWcd6LY Ae5yzjpcVFphR/MqmXk4ScJq5mJSxu1jfFjFu4sTx7+9SQp1Mw9LR/FuRBwx9xhOFA5JQhTSc/yA kArt7lLq2HWX+oJLPlboLkUdTCtNMqQjJ5pmi7ZpDH6ZVukM/nZss3sHdTir0nqLHLpIyArMKoQf EuaY8TqeKBxXkRzimJUNfgOrqErIwVT4ZVxPKvB0SBhHvYBIWbXmlgB9S07fwVCxKt2+y6axixSK HlTRvIE5LyO3+EE3wnFahR3QJCpjP5AHEKIY7XFVBd/lbobod/ADTha6+w4ljrtPrwa3aeiINAsQ PTMR2pdQqp0KHNPk78oxo1CPbQxcXDmGAvji68cVkfW2FuJN2JOqMmH7RPldhDtZdLtcBPTtr7lb eJLsEQjz+Y3nXcl9V3K9/3zJXZTPZy20s9oKZVf3DbYpNi1yvLBDHlPGBmrKyA1pmmQJ+0TQh0G9 zpwOSXFiSiN4zOq6gwsFNmuQ4OojqqJBhFNosOueJhLKjHQoUcolHOzMcCVtjYcmXdljYVMfGGw9 kFjt8sAOr+jh/FxQkDG7TWgOnzmjFU3grMxWrmREQe3XYVbXQp2ZW92IZkqdw61QGXw4rxoMFtaE BgRB2wJWXoXzuWYNBxPMSKDtbvfe3C3GCxfpIhnhgGQ+0nrP+6hunJTHirkJgNip8JE+5J1itRK3 lib7BtzO4qQyu8YCdrn33sRLeQTPvKTz9kQ6sqScnCxBR22v1VxuesjHadsbw5kWHuMUvC51z4dZ CBdDvhI27E9NZpPlM2+2csXcJKjDNYW1+5zCTh1IhVRbWEY2NMxUFgIs0Zys/MtNMOtFKWAj/TWk WFmDYPjXpAA7uq4l4zHxVdnZpRFtO/ualVI+UUQMouAIjdhE7GNwvw5V0CegEq4mTEXQL3CPpq1t ptzinCVd+fbK4Ow4ZmmEs3KrUzTPZAs3eVzIYN5K4oFulbIb5c6vikn5C1KlHMb/M1X0fgI3BSuB 9oAP17gCI52vbY8LFXGoQmlE/b6AxsHUDogWuIuFaQgquEw2/wU51P9tzlkaJq3hwKf2aYgEhf1I RYKQPShLJvpOIVbP9i5LkmWETESVxJWpFXtEDgkb6hq4qvd2D0UQ6qaaZGXA4E7Gn/ueZdAo1E1O Od+cGlLsvTYH/unOxyYzKOXWYdPQ5PYvRKzYVe16szzfe8uK6IlZm9XIswKYlbaCVpb2rynCObda W7HmNF5u5sKBF+c1hsGiIUrhvgfpP7D/UeEz+2VCb6hDvg+1FcGHBk0Mwgai+pJtPJAukHZwBI2T HbTBpElZ02atk7ZavllfcKdb8D1hbC3ZWfx9TmMXzZnLzsnFizR2ZmHH1nZsoanBsydTFIbG+UHG OMZ80ip/deKje+DoLbjfnzAlTTDBNyWBofUcmDyA5LcczdKNvwAAAP//AwBQSwMEFAAGAAgAAAAh ALSsnTqyAwAAPgkAABEAAAB3b3JkL3NldHRpbmdzLnhtbJxW247bNhB9L9B/MPRcr3W3JMQb2Ja1 SbHbFnX6AZRE28SSIkHS1jpf36EkRqtWDYI+mTwz52g4HM74w8c3Rhc3LBXhzcbxHlxngZuK16Q5 b5y/vhTLxFkojZoaUd7gjXPHyvn4+PNPH9pMYa3BTS1AolEZ3zhX2WSqumCG1JKRSnLFT3pZcZbx 04lUePhxBobcOBetRbZaDaQHLnADaicuGdLqgcvzqmfmvLoy3OiV77rxSmKKNASsLkQoq8b+rxp8 6mJFbt87xI1R69d67vc8h+O2XNbfGD8SniEIySusFGSW0f64DJHGyij6Izp9Pp9JKZG8vxN5hGv7 yjlbtJnAsoKEbpzEdVYGh+/y01EjjcGqBKa0q4GKYgRfb7OzRIwhuLMe6Tg1PqEr1V9QedRcgNMN QXxrf5CsJWpB5EmS+hOX5CtvNKJHgSoArbPnWWeiBEX30TEf2Qeo0Ltl+H281QVJVGksB8E9qEtO rVfNf+N6z5mQkMyeceJcN1zjP6Q5r90BgdQbZ+lNnQa4C241evdc3NSj0LD5h84UtTITIjwMgXSX SHh/tTJRmcWfEKc9husmaRCm2z44Yx0tbuzvgmjWsnNzd8jTlON5frRO5zh+HrlpMWcJvGi9zWct W9dzZ9WCvZ/vD3OccB9ut+GcJY7WSbGesyRxnNuimp7nv7OTRu4uno0tTdwiGKpuqpYWUR7PRrD1 gryYPc92u0738VzUu9gNi9m87ZLoECeznDQMgtlb2B2C4jAbW+5BcLMR5F6czKsVSRgdugiguE0S oPpYZlqhqfB+VcCLWrD+Te8RKyVBixfTLKFkWVbK1x1prL3E0LTxe8vxWlrjctkbFEOUFvBqrQH6 ZG+p4fHn+NQJ0xckz6Nyd1Esk7MoNKBfv6mZfoblk+RX0au2EonPTQ2w/aAXhoMeafQzYRZX1/Jo WQ30zHema1P/fpNGcDUmqM00jDlsMvSMxmaGm+XTzri2WUXl0YxC/IKE6PtdefY2DiXni/ZMQ9Ww q5F87Tbl2R9sfmeDnbF1G1SZk4H3sDAO/RK8hsWIBRYLRiy0WDhikcWiEYstFhvscochAVPgFUaO XRr8xCnlLa4/WXDj/Avqk6AuSGC4VzMkoMB41gHD1FCLW4bfYALhmmj4lyFIzdAb/Alx/a6YB2+Y CfyqJ75GyTiLCbqokUZA765qQoarg5E2jaXNalwRKMjjnZXj2HjoA6dE6SMWMGE0l3Dkbq790imP f3we/wYAAP//AwBQSwMEFAAGAAgAAAAhAErYipK7AAAABAEAABQAAAB3b3JkL3dlYlNldHRpbmdz LnhtbIzOwWrDMAzG8Xth7xB0X531MEpIUiijL9D1AVxHaQyxZCRt3vb0NWyX3XoUn/jx7w9faW0+ UTQyDfCybaFBCjxFug1weT8976FR8zT5lQkH+EaFw/i06UtX8HpGs/qpTVVIOxlgMcudcxoWTF63 nJHqNrMkb/WUm+N5jgHfOHwkJHO7tn11gqu3WqBLzAp/WnlEKyxTFg6oWkPS+uslHwnG2sjZYoo/ eGI5ChdFcWPv/rWPdwAAAP//AwBQSwMEFAAGAAgAAAAhAJVdb8lLAQAAdwIAABEACAFkb2NQcm9w cy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySX2vDIBTF3wf7 DsH3RNM/o0iSwjb6tMJgHRt7E71tZdGIuqb99tOkzVK2h4Eveo6/e+7VYnlUdXIA62SjS5RnBCWg eSOk3pXodbNKFyhxnmnB6kZDiU7g0LK6vSm4obyx8GwbA9ZLcEkgaUe5KdHee0MxdnwPirksOHQQ t41VzIet3WHD+CfbAZ4QcocVeCaYZzgCUzMQ0Rkp+IA0X7buAIJjqEGB9g7nWY5/vB6scn9e6JSR U0l/MqGnc9wxW/BeHNxHJwdj27ZZO+1ihPw5fl8/vXStplLHWXFAVSE45RaYb2zFwTFb4NFJnF7N nF+HQW8liPvTxfRbiF4LBxlfqJoVeLwNVbqm+lIgkhCT9k1dlLfpw+NmhaoJyacpmYW1yec0n1FC PmKmq/sxdn+gzsn+Q5xHIllcEy+Aqkt8/VWqbwAAAP//AwBQSwMEFAAGAAgAAAAhAFuLKGd6CAAA 7kIAAA8AAAB3b3JkL3N0eWxlcy54bWzsW21v2zgM/n7A/QfD37c2SZu0xbKhL+t1wF66pb377NhK Y9Sxcraztvv1R1G2othxTMYucAfcp8ayxIcUyYdKKr778LyInJ8iSUMZj93e20PXEbEvgzB+GLv3 d9dvTlwnzbw48CIZi7H7IlL3w/vff3v3dJZmL5FIHRAQp2fJ2J1n2fLs4CD152LhpW/lUsTwbiaT hZfBY/JwIGez0BdX0l8tRJwd9A8PhweJiLwMwNN5uEzdXNoTRdqTTIJlIn2RpqDtItLyFl4Yu+9B vUD6V2LmraIsVY/JbZI/5k/451rGWeo8nXmpH4Z3oDiYuAhjmdycx2nowhvhpdl5GnpbX87VrK1v /DSzpF2EQegeKMT0F8j86UVjt98vRi6VBhtjkRc/FGMifvPHha3J2IWh+4kamoLcseslbybnStgB mln8tcxdbhgPT6jK0vNh40CMN8sEOBD8oYRGoXJ0fzQsHn6sIhjwVpnMQVAAgNli4bG04+BX8PJE Rwm8FbPP0n8UwSSDF2MXsWDw/tNtEsokzF7G7umpwoTBiViEN2EQCBWU+dh9PA8D8ddcxPepCNbj 368xxHKJvlzFGag/HGEURGnw8dkXSxViIDr2lIe/qgWREptaOKjQKlxrowdKqDj4dwHZ0z7cijIX nkojB/XfCYRWr1oD9ZVFtgEol6XroL2Io/YijtuLwOBttxej9loAebb1iI4NKyrpTs2kr4PP3ofB 6Y6QVSsqUdS4ohI0jSsqMdK4ohISjSsqEdC4ouLwxhUV/zauqLhz5wrfQ+IqR9EAd4OU2HdhFgm1 ficB9VpSXV5qnFsv8R4Sbzl3VGEtq72LLCeraUZTFel0f7KcZImMHxp3BKqzSt29OfnjYjn30hBO NA1b32+59XfeNBLOH0kYNEId6+Cr2IQHk60l7DbyfDGXUSAS5048a48y1n+VzkSfMhqVa+nWz+HD PHMmcyy5jWDDmk2v3wkt/3OY4h7sTKZhjSlNwkk+HNbEZb3wLyIIV4tiawinkaHmc4abSxCo4u4t OlIuqmZXoxXKARQTdLngm4DyCfrr4sKXr3xM0V+Xoj3lE/TXhWtP+Rgfu/3LZporL3l0SOk1Yufu pYxkMltFRQ400sOIncEGgmYCO4mNfBJJjNgZvEGfzrnvwzc3SpyyfbHmUQYK2x0aBZONbgvbKSXa 6zEsYjuohNVnYLXjWgYQm3R/iJ+h+uGJWwyQpc1ZszGdBzU7ACWIdIb+vpJZ8xm6X8N5VJRPMfxc kgqHhjaoyTwqWh5Put4xfNyu8DGA2lVABlC7UsgAqomP+jOPqYl0kPbFkYHFpmVTxTDsyMw8YjOz AeKVgI7qJuH8VZO99bFQrZsEFLaDqnWTgML2TqmWmbpJwOqsbhKwaqpGvY9sTuUYxa6bNpA5CRAs 6oa8CUDdkDcBqBvyJgC1J+9mkO7Im4DF5gbDqTZ5E4BwCuervgGyyZsAxOYGzXb5b0ZF3UMpu7/c dkDeBBS2g6rkTUBhe6eOvAlYOIUTCSUsQ3UErG7ImwDUDXkTgLohbwJQN+RNAOqGvAlA7cm7GaQ7 8iZgsbnBcKpN3gQgNj0YIJu8CUA4hcMNW8kbs/7VyZuAwnZQlbwJKGzvlAjVHFIJWGwHlbAMeROw cAonGHIsDG6OUd2QN8GibsibANQNeROAuiFvAlB78m4G6Y68CVhsbjCcapM3AYhNDwbIJm8CEJsb tpI3JuOrkzcBhe2gKnkTUNjeKRGq4TkCFttBJSxD3gQsjJfW5E0Awin7AnEs6oa8CRZ1Q94EoG7I mwDUnrybQbojbwIWmxsMp9rkTQBi04MBssmbAMTmhq3kjTny6uRNQGE7qEreBBS2d0qEasibgMV2 UAnLUB0BqxvyJgBhYLYmbwIQTtkDCLOI46ZuyJtgUTfkTQBqT97NIN2RNwGLzQ2GU23yJgCx6cEA 2eRNAGJzg7pnC/dFyddTezVBQL1nUNxqIAP2a5xEBcwN/CFmIoFOJtF8O6QlYGEhA7EmPKgmXkj5 6NAudg9qAoQMFU6jUOKV7he8pWM1IgxGOzoJ7r5dOje6AaayDkNq8+YNdA/Z7ULYnqQah0DP7GUJ LTvL4ma5kgYNQqqvK28Bwj60T9AQlLf1qMWqzwcmYlNVPoz/t81R8TP0vAXFnMPD65Oj448n2iLo FVNCko3usLF7noS6awjbvqxnPy0eQLDVhIWaVW3x52CMDy1XO2zJb9SbS054n75sWc21e7Ru3fNR 2Jhfv18f0vS8jUugWv8avTN11XyHzngVfacTHJyiN7mqIHR/oUpNGpprWzg7m0baXfDhU6w8Ct2D +C86HTnBs6fFwvtLEUVfPHRuJpf1UyMxy/Tb3iGW25Koqcwyuahfn+BtdNRkmwAIEVsZ/aiMgE81 ex+vFlORQDvZjv3/KlWZwra3zfjXF2u1u00Cg/aYHtRdr9fNxIXJRHSzKmUVZfCNbldAfaYe9PJ9 U615qAy+thO2GiXQxYArN9P35HRwdHqu39T1N2JQ5N2NR+Zhe3cjeogcVxfQigo9tCo/dVyhMaot NW+++TV29e9o0A1R9D766lryuq8SGFBH3V5rTUTutbqI170Wh9ADG4ibwoVcq/XyP/dbrlPH3v7/ cpJvFDmTTKqMQq0ok79qL4XhbVlkJxDE+2Oxt1rSJZQfvayaXFQygOK4UT2vesOTwfVG+gEr6ITw pgW+ulWuq95SQsk8Ou4N9BKYW8zBUFQkh1NOD/tDNUX5OZeXltuWTSZD129TWteT2EZR9lcp8PtE nUDKhwxrD8se0a+c9f6WyG1rTUf/VZ3EdFC9N175LLM9ZK8l3JiuhuxMD3NCVktab+n/Ibs+E1ND 1trDcsjqV21DVkv5t4ZskfPp+38AAAD//wMAUEsDBBQABgAIAAAAIQC1sjWCpQEAAA8FAAASAAAA d29yZC9mb250VGFibGUueG1svJNNTsMwEIX3SNwh8h7ipAFKRVq1hS5ZIDjANHUaS/6JPKaB2zOx QxdUlVohSKRIeeO8jD+/eZh9aJXshENpTcmya84SYSq7kWZbsrfX1dWYJejBbEBZI0r2KZDNppcX D92ktsZjQt8bnLiSNd63kzTFqhEa8Nq2wlCttk6Dp1e3TW1dy0o82updC+PTnPPb1AkFnv6NjWyR DW7dKW6ddZvW2UogUrNaRT8N0rDp0F3STQxo6noJSq6dDIUWjEWRUW0HqmQ85yt+Q8/+Lviof7K0 d6gacCj8fiGPcg1aqs9vFTuJGAut9FXzre/ASVgrEUsot1R4xzUv2VPGOc9XKxaVrGQFCfPlXsmp qXjdD2tGe4WOhxoLPmFJdh98SCGf4avQZxrP54DEq9QCk2fRJS9WQ0R1SCTnt0Tihnj0ZEZnEXHB NxA8lQg1ns/3+6edLEm5GxfZsP+ziESf04nM6aDUkWQsiEMRkjHk42+TcYzD6D84LEHTiMAREn0S YiL6ZJw3I+cnYt5HOX/6MSOcF4sDEmEiaLJ+MyPDsOD0CwAA//8DAFBLAwQUAAYACAAAACEAhEtH TucBAADiAwAAEAAIAWRvY1Byb3BzL2FwcC54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAACcU8Fu2zAMvQ/YPxi+N0qytQsCRsWQouhhXQLEbc+aTCfCbEmQ2KDZ14+yE8fZeqpP 75E09fRIwe1bU2d7DNE4u8gno3GeodWuNHa7yJ+K+6tZnkVStlS1s7jIDxjzW/n5E6yD8xjIYMy4 hY2LfEfk50JEvcNGxRGnLWcqFxpFTMNWuKoyGu+cfm3QkpiOxzcC3whtieWV7xvmXcf5nj7atHQ6 6YvPxcGzYAkFNr5WhPJnklOPSkcNiD4KhSNVF6ZBOZ1xvGewVluMcgKiA/DiQsn8yxREB2G5U0Fp Ygvlt+trEAMO372vjVbE5spHo4OLrqJs1dqQpf9BDEuArdmgfg2GDnIMYkjhh7Gs5AZEB1hZUNug /O4or2ew0arGJd9fVqqOCOIcgAdUabZrZVgv7Gm+R00uZNH84elO8+yXiphcW+R7FYyyxO6lso60 uPaRgiwM1dybcx1v4bBsiM3X5CHXMrgsTMFOAycu1bUnxFXFN6V3xE6GYlsNndSBnAHsz/in69I1 XtmDXN0vV488vSNNdv+OT75wd2ltjkZeBgejfzG023ileUKzGc/ovASDDGx4VbDkqZ76nQPwwJ6H Oh3K/9otlqea/xNprZ67Jysn09GYv3aPTjFe1v4tyb8AAAD//wMAUEsBAi0AFAAGAAgAAAAhAG8a a5B+AQAAKAYAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYA CAAAACEAHpEat/MAAABOAgAACwAAAAAAAAAAAAAAAAC3AwAAX3JlbHMvLnJlbHNQSwECLQAUAAYA CAAAACEAEReg2RQBAAA5BAAAHAAAAAAAAAAAAAAAAADbBgAAd29yZC9fcmVscy9kb2N1bWVudC54 bWwucmVsc1BLAQItABQABgAIAAAAIQBOuNu4VQgAAJtaAAARAAAAAAAAAAAAAAAAADEJAAB3b3Jk L2RvY3VtZW50LnhtbFBLAQItABQABgAIAAAAIQCNp5tKkgEAAGsEAAASAAAAAAAAAAAAAAAAALUR AAB3b3JkL2Zvb3Rub3Rlcy54bWxQSwECLQAUAAYACAAAACEAM9n/QJIBAABlBAAAEQAAAAAAAAAA AAAAAAB3EwAAd29yZC9lbmRub3Rlcy54bWxQSwECLQAUAAYACAAAACEAlrWt4pYGAABQGwAAFQAA AAAAAAAAAAAAAAA4FQAAd29yZC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhALSsnTqy AwAAPgkAABEAAAAAAAAAAAAAAAAAARwAAHdvcmQvc2V0dGluZ3MueG1sUEsBAi0AFAAGAAgAAAAh AErYipK7AAAABAEAABQAAAAAAAAAAAAAAAAA4h8AAHdvcmQvd2ViU2V0dGluZ3MueG1sUEsBAi0A FAAGAAgAAAAhAJVdb8lLAQAAdwIAABEAAAAAAAAAAAAAAAAAzyAAAGRvY1Byb3BzL2NvcmUueG1s UEsBAi0AFAAGAAgAAAAhAFuLKGd6CAAA7kIAAA8AAAAAAAAAAAAAAAAAUSMAAHdvcmQvc3R5bGVz LnhtbFBLAQItABQABgAIAAAAIQC1sjWCpQEAAA8FAAASAAAAAAAAAAAAAAAAAPgrAAB3b3JkL2Zv bnRUYWJsZS54bWxQSwECLQAUAAYACAAAACEAhEtHTucBAADiAwAAEAAAAAAAAAAAAAAAAADNLQAA ZG9jUHJvcHMvYXBwLnhtbFBLBQYAAAAADQANAEADAADqMAAAAAA= --_004_5D3E853BEE49C848BB63047C794C8655AE96BCA6WOKINTRAEXC02in_-- From buddenbergr@gmail.com Mon Apr 8 11:15:20 2013 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 BCC1E21F9130 for ; Mon, 8 Apr 2013 11:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=1.685, 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 2e5275BVAZEj for ; Mon, 8 Apr 2013 11:15:19 -0700 (PDT) Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by ietfa.amsl.com (Postfix) with ESMTP id 085B121F85F3 for ; Mon, 8 Apr 2013 11:15:19 -0700 (PDT) Received: by mail-pa0-f41.google.com with SMTP id kx1so3421312pab.28 for ; Mon, 08 Apr 2013 11:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=6kbsjLyd5rjBT/SwFR9ivbpmOjygiRuRMjpHCOWoWRw=; b=oGz6QkkpFcfEWcotX3Kt+gd5lhx+wCxXsjxnl44NcfbdyfHlsNmP/ix2wcWtJKjhj/ fpG+et3yrlP15wtAQbUYTOu6PEo0Kyxv04OpNz7b6bh7eQyxkRFKxnI/52O0fdOjC8nV OPerLY12vbtejwBdIIieXQp78RLb7yuIFPlV5UCGG+aN8rzYKNwz4EDCEe4vVr8CkIBu NmDLi2UcRkPJv5JDbdi5xPbseeelw/r9BaXfqnfniadFm7s5ELFDtP5z1GTdz/XP16h4 rNPbJYOJPFjG0lj2XwtYL3q4cB9Aqjo1MnZgMVDAxEE4q2k1Ai+gNR8Fsr4M3dR/5fHk tGuA== X-Received: by 10.66.163.37 with SMTP id yf5mr38231583pab.115.1365444918649; Mon, 08 Apr 2013 11:15:18 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPS id m9sm32463424paa.17.2013.04.08.11.15.16 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 11:15:17 -0700 (PDT) Message-ID: <1365444914.1741.244.camel@localhost> From: Rex Buddenberg To: Cesar Gutierrez Date: Mon, 08 Apr 2013 11:15:14 -0700 In-Reply-To: <5D3E853BEE49C848BB63047C794C8655AE96BCA6@WOK-INTRA-EXC02.intra.ofcom.local> References: <5D3E853BEE49C848BB63047C794C8655AE96BCA6@WOK-INTRA-EXC02.intra.ofcom.local> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" , Reza Karimi , "johnny.dixon@bt.com" Subject: Re: [paws] Extensibility for Ofcom 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, 08 Apr 2013 18:15:20 -0000 maxTotalBW maxNominalChannelBW ETSIENmaxLocationChange Please tell me what these parameters mean. I'm mentally bouncing the page against a use case where we have a broadband (500kHz or so) device that is attempting to get an allocation in a traditionally narrowband (e.g. VHF) space where (in US) the licenses are for 25kHz, 12.5KHz or 6.25KHz. The broadband device would need multiple narrowband allocations all cheek-by-jowl. A lot of the VHF space is allocated, but a good deal is not used much. For example, in the county where I live, the county has over 200 narrowband VHF licenses. At some time in the future, it's entirely conceivable that white space governance could extend into this area ... beyond the existing mindset of TV spectrum. How would such a broadband device request a chunk of broadband spectrum? Can it be expressed with these parameters? Is PAWS at least extensible to accommodate such a request in the future? On Mon, 2013-04-08 at 16:57 +0000, Cesar Gutierrez wrote: > Vince and all, > > > > The attached is the list of the parameters that need to be > incorporated to existing IETF PAWS protocol functionalities in order > to cover the requirements in the current draft of the ETSI Harmonised > Standard. I would be grateful if IETF PAWS members could review and > comment. > > > > Please note that this list does not address support for the current > database discovery requirement in ETSI HS. It does not address either > the device update function (or kill switch, or PUSH) that was briefly > discussed at the meeting in Orlando. We are still discussing this > function in ETSI and the UK, and I expect to bring it to consideration > of IETF PAWS members in the coming weeks. > > > > Thanks and regards, > > Cesar > > > > > > > > > > From: Vincent Chen [mailto:vchen@google.com] > Sent: 14 March 2013 05:17 > To: Cesar Gutierrez; paws@ietf.org > Subject: Extensibility for Ofcom > > > > > Cesar, > > > > > Thanks for joining the call for the IETF/PAWS. > > > > > > I want to follow up with you on the parameter names and values that we > should consider adding to the draft to support Ofcom White Space > rules. In particular: > > > > > > - What is the "unique device identifier" intended to be? Is there a > separate certification ID apart from the serial number? > > > > > > - What should be the parameter name for "device class"? What are the > possible values and what do they mean? > > > > > > - What should be the parameter name for "technology ID"? What are the > possible vales and what do they mean? > > > > > > Are you aware of other parameters that must be defined for Ofcom? > > > > > > Thanks for your help. > > > > > > -- > -vince > > > > > ______________________________________________________________________ > > ****************************************************************************************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the > use of the addressee only. > > If you have received this email in error please notify the originator > of the message and delete it from your system. > > This email has been scanned for viruses. However, you open any > attachments at your own risk. > > Any views expressed in this message are those of the individual sender > and do not represent the views or opinions of Ofcom unless expressly > stated otherwise. > ****************************************************************************************************************** > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From vchen@google.com Mon Apr 8 17:51:14 2013 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 A9EF521F8D2A for ; Mon, 8 Apr 2013 17:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 DZ1jc+vsWWkv for ; Mon, 8 Apr 2013 17:51:02 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id A2C2D21F8DBF for ; Mon, 8 Apr 2013 17:50:59 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so6595170wgh.32 for ; Mon, 08 Apr 2013 17:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IJV6n6P5njaZziMOD8pagkBLPDnIAVPKe7BESrJU1jc=; b=V8AJgnaYvloomnVbXW9zBRmO2auLJOaRc3H1RnjruMg/VF17Fnte68QEmN4IcCvKDl /qtLEzJXtkEcVIjJt9tliPHaOLncJjMaFvlVoBJw8AtFMp355QHCaXPUOIUt1Ic8aoxg h6JyvKu3yHbQOR9Dv7+MT1FylIRjtYE/S+SDtjnPB9CeEKksQiqL3fKYqUrBx+eiz1KY 5ucjPuXAJ2iU6JtGvr7OfaTiDOHfnphUy6EatN0rjtquAXBVVSL58vfvMIQZmNRBA7r7 1p6cQJZnyLUP9vhq66cReuypQkOJhRYWg5QDJ9EDPgqrL8IQVcNHGWJ1QwQfbEbwVIB2 nsPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=IJV6n6P5njaZziMOD8pagkBLPDnIAVPKe7BESrJU1jc=; b=iaX+IKS9/WptRTzrRVkrqJhmxBzjSWEvGkfyUSDk3A8gFBSF6jPfu3gclf4l+lu45s +FA8288ybcg3l+WHj5LeiAYxALmKWUXT1UkfgFn92SBtUYHYLXOv+/BxxAtZ3buwxsE8 O23uAcQXCI8tQ9xDgRkC+OoOMSxIVvpGkQRXhnS/cXNVU1jp0hMzFntyJ/KbaNwkr+DQ EI9fpkyu62MgY5qLhKzSCEVqHyeb8VSEa/RJ72PJUwOesm6obeWOVcNL+6H4kMqpAdrd 5xM1VsgpgrwGZ1iapwz91LQPfl/tgGu0o/UH7kYtTDnFiPfcy6yiGr0xN2vssTR3osox cFjA== MIME-Version: 1.0 X-Received: by 10.180.24.65 with SMTP id s1mr16386284wif.0.1365468658297; Mon, 08 Apr 2013 17:50:58 -0700 (PDT) Received: by 10.194.55.138 with HTTP; Mon, 8 Apr 2013 17:50:58 -0700 (PDT) In-Reply-To: <1365444914.1741.244.camel@localhost> References: <5D3E853BEE49C848BB63047C794C8655AE96BCA6@WOK-INTRA-EXC02.intra.ofcom.local> <1365444914.1741.244.camel@localhost> Date: Mon, 8 Apr 2013 17:50:58 -0700 Message-ID: From: Vincent Chen To: Rex Buddenberg Content-Type: multipart/alternative; boundary=f46d043bdf2a5485f004d9e2f205 X-Gm-Message-State: ALoCoQldz+YZ0B5GFToxwxZalliVRzvesej6n3uQeQWay27FllQRMJwj2gnmYukgBdaK6o391zVK6qgTD12Il9uTGXPAdkaBmCk4IPb+0ErXT8UjR33Z7D2vwk+YnBDOTviebjtAELQvbCcbxZMQe8QDsRMuX1Wv/d6OlIa/NkRlBGQqp4EYg2D2gcAmbogQ5cJLactpJ1th Cc: "paws@ietf.org" , "johnny.dixon@bt.com" , Reza Karimi Subject: Re: [paws] Extensibility for Ofcom 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, 09 Apr 2013 00:51:14 -0000 --f46d043bdf2a5485f004d9e2f205 Content-Type: text/plain; charset=ISO-8859-1 Rex, What is not expressed in the doc is that maxTotalBW and maxNominalChannelBW are responses from the Database to the Device as additional constraints. As Cesar indicated earlier: - maxTotalBW: Device can use a maximum of specified bandwidth, which can be contiguous or not - maxNominalChannelBW: The maximum width of any single contiguous block of spectrum (We might want to rename the second to maxContiguousBW) For example: 1. Device asks for available spectrum, providing its location and device descriptor fields (which can include technology ID, etc.) 2. Database returns available spectrum in terms of start and stop frequencies and max allowable power levels within those frequencies. Database response may also include the constraints: - maxTotalBW - maxNominalChannelBW 3. Devices selects spectrum it will use based on what's available and these additional constraints. Hope that makes more sense? -vince On Mon, Apr 8, 2013 at 11:15 AM, Rex Buddenberg wrote: > maxTotalBW > maxNominalChannelBW > ETSIENmaxLocationChange > > > Please tell me what these parameters mean. > > I'm mentally bouncing the page against a use case where we have a > broadband (500kHz or so) device that is attempting to get an allocation > in a traditionally narrowband (e.g. VHF) space where (in US) the > licenses are for 25kHz, 12.5KHz or 6.25KHz. The broadband device would > need multiple narrowband allocations all cheek-by-jowl. > > A lot of the VHF space is allocated, but a good deal is not used much. > For example, in the county where I live, the county has over 200 > narrowband VHF licenses. At some time in the future, it's entirely > conceivable that white space governance could extend into this area ... > beyond the existing mindset of TV spectrum. > > How would such a broadband device request a chunk of broadband spectrum? > Can it be expressed with these parameters? Is PAWS at least extensible > to accommodate such a request in the future? > > > > > > > On Mon, 2013-04-08 at 16:57 +0000, Cesar Gutierrez wrote: > > Vince and all, > > > > > > > > The attached is the list of the parameters that need to be > > incorporated to existing IETF PAWS protocol functionalities in order > > to cover the requirements in the current draft of the ETSI Harmonised > > Standard. I would be grateful if IETF PAWS members could review and > > comment. > > > > > > > > Please note that this list does not address support for the current > > database discovery requirement in ETSI HS. It does not address either > > the device update function (or kill switch, or PUSH) that was briefly > > discussed at the meeting in Orlando. We are still discussing this > > function in ETSI and the UK, and I expect to bring it to consideration > > of IETF PAWS members in the coming weeks. > > > > > > > > Thanks and regards, > > > > Cesar > > > > > > > > > > > > > > > > > > > > From: Vincent Chen [mailto:vchen@google.com] > > Sent: 14 March 2013 05:17 > > To: Cesar Gutierrez; paws@ietf.org > > Subject: Extensibility for Ofcom > > > > > > > > > > Cesar, > > > > > > > > > > Thanks for joining the call for the IETF/PAWS. > > > > > > > > > > > > I want to follow up with you on the parameter names and values that we > > should consider adding to the draft to support Ofcom White Space > > rules. In particular: > > > > > > > > > > > > - What is the "unique device identifier" intended to be? Is there a > > separate certification ID apart from the serial number? > > > > > > > > > > > > - What should be the parameter name for "device class"? What are the > > possible values and what do they mean? > > > > > > > > > > > > - What should be the parameter name for "technology ID"? What are the > > possible vales and what do they mean? > > > > > > > > > > > > Are you aware of other parameters that must be defined for Ofcom? > > > > > > > > > > > > Thanks for your help. > > > > > > > > > > > > -- > > -vince > > > > > > > > > > ______________________________________________________________________ > > > > > ****************************************************************************************************************** > > For more information visit www.ofcom.org.uk > > > > This email (and any attachments) is confidential and intended for the > > use of the addressee only. > > > > If you have received this email in error please notify the originator > > of the message and delete it from your system. > > > > This email has been scanned for viruses. However, you open any > > attachments at your own risk. > > > > Any views expressed in this message are those of the individual sender > > and do not represent the views or opinions of Ofcom unless expressly > > stated otherwise. > > > ****************************************************************************************************************** > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > -- -vince --f46d043bdf2a5485f004d9e2f205 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Rex,

What is not expressed in the= doc is that maxTotalBW and maxNominalChannelBW are responses from the Data= base to the Device as additional constraints.
As Cesar indi= cated earlier:

=A0 - maxTotalBW: Device can use a = maximum of specified bandwidth, which can be contiguous or not
=A0 - maxNominalChannelBW: The maximum width of any sing= le contiguous block of spectrum

(We might want to rename the second to maxC= ontiguousBW)

For example:
=A01. Device asks for available spectrum, providing its location= and device descriptor fields (which can include technology ID, etc.)
=

=A02. Database returns available spectrum i= n terms of start and stop frequencies and max allowable power levels within= those frequencies.
=A0 =A0 Database response may also include the constraints:
=A0 =A0 =A0 - maxTotalBW
=A0 =A0 =A0 - maxNomin= alChannelBW

=A03. Devices selects spec= trum it will use based on what's available and these additional constra= ints.

Hope that makes more sense?

-vince



On Mon, Apr 8, 2013 at 11:1= 5 AM, Rex Buddenberg <buddenbergr@gmail.com> wrote:
maxTotalBW
maxNominalChannelBW
ETSIENmaxLocationChange


Please tell me what these parameters mean.

I'm mentally bouncing the page against a use case where we have a
broadband (500kHz or so) device that is attempting to get an allocation
in a traditionally narrowband (e.g. VHF) space where (in US) the
licenses are for 25kHz, 12.5KHz or 6.25KHz. =A0The broadband device would need multiple narrowband allocations all cheek-by-jowl.

A lot of the VHF space is allocated, but a good deal is not used much.
For example, in the county where I live, the county has over 200
narrowband VHF licenses. =A0At some time in the future, it's entirely conceivable that white space governance could extend into this area ...
beyond the existing mindset of TV spectrum.

How would such a broadband device request a chunk of broadband spectrum? Can it be expressed with these parameters? =A0Is PAWS at least extensible to accommodate such a request in the future?






On Mon, 2013-04-08 at 16:57 +0000, Cesar Gutierrez wrote:
> Vince and all,
>
>
>
> The attached is the list of the parameters that need to be
> incorporated to existing IETF PAWS protocol functionalities in order > to cover the requirements in the current draft of the ETSI Harmonised<= br> > Standard. I would be grateful if IETF PAWS members could review and > comment.
>
>
>
> Please note that this list =A0does not address support for the current=
> database discovery requirement in ETSI HS. It does not address either<= br> > the device update function (or kill switch, or PUSH) =A0that was brief= ly
> discussed at the meeting in Orlando. We are still discussing this
> function in ETSI and the UK, and I expect to bring it to consideration=
> of IETF PAWS members in the coming weeks.
>
>
>
> Thanks and regards,
>
> Cesar
>
>
>
>
>
>
>
>
>
> From: Vincent Chen [mailto:vchen@g= oogle.com]
> Sent: 14 March 2013 05:17
> To: Cesar Gutierrez; paws@ietf.org
> Subject: Extensibility for Ofcom
>
>
>
>
> Cesar,
>
>
>
>
> Thanks for joining the call for the IETF/PAWS.
>
>
>
>
>
> I want to follow up with you on the parameter names and values that we=
> should consider adding to the draft to support Ofcom White Space
> rules. In particular:
>
>
>
>
>
> =A0- What is the "unique device identifier" intended to be? = Is there a
> separate certification ID apart from the serial number?
>
>
>
>
>
> =A0- What should be the parameter name for "device class"? W= hat are the
> possible values and what do they mean?
>
>
>
>
>
> =A0- What should be the parameter name for "technology ID"? = What are the
> possible vales and what do they mean?
>
>
>
>
>
> Are you aware of other parameters that must be defined for Ofcom?
>
>
>
>
>
> Thanks for your help.
>
>
>
>
>
> --
> -vince
>
>
>
>
> __________________________________________________________= ____________
>
> **********************************************************************= ********************************************
> For more information visit www.ofcom.org.uk
>
> This email (and any attachments) is confidential and intended for the<= br> > use of the addressee only.
>
> If you have received this email in error please notify the originator<= br> > of the message and delete it from your system.
>
> This email has been scanned for viruses. However, you open any
> attachments at your own risk.
>
> Any views expressed in this message are those of the individual sender=
> and do not represent the views or opinions of Ofcom unless expressly > stated otherwise.
> **********************************************************************= ********************************************
> _______________________________________________
> paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailman/listinfo/paws





--
-vince
--f46d043bdf2a5485f004d9e2f205-- From buddenbergr@gmail.com Mon Apr 8 18:12:25 2013 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 42F2321F8E63 for ; Mon, 8 Apr 2013 18:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.343, 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 BDbhtx9Fvy6q for ; Mon, 8 Apr 2013 18:12:24 -0700 (PDT) Received: from mail-pd0-f176.google.com (mail-pd0-f176.google.com [209.85.192.176]) by ietfa.amsl.com (Postfix) with ESMTP id E538B21F8DA0 for ; Mon, 8 Apr 2013 18:12:23 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id r11so3516732pdi.35 for ; Mon, 08 Apr 2013 18:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:subject:from:to:cc:date:in-reply-to :references:content-type:x-mailer:mime-version :content-transfer-encoding; bh=dJuVhLTZWGcLgKKAcl75MPqzH0kbZ/mDORqUI8S3JJY=; b=1DKaiLIz16vOSMywNo3LjSXg4Lb4YKVHJAvUXDEH0K/UwELBvEzjNdv5toWYO2pMM9 LhTmyMycnbteTS2uiSNDQ6RLeo1BUkGCY+oTHMjszrqgQBEduVx1zAHHrFMFZ9qj5tlX BGkFWupkm/eUj9Rgm/ehJEaaSJew4D1f/h9Ej7HtSb1KRcoQwjnRxgX3R7dPT9GGT6dG yfqFh+RN+XcI0DUTDQbp7BfN7zsZ5xfHFVpJ21SeWUPtrlbbFQHVmUDk0HtQx3aIrd7d t6dTwzpwVzFNmzU+lyKVm54ctglst8lm5SuCp34F1Wl997EJWzI4RANeZ7SP8EIMl4LZ 7O2g== X-Received: by 10.67.10.228 with SMTP id ed4mr28595340pad.41.1365469943413; Mon, 08 Apr 2013 18:12:23 -0700 (PDT) Received: from [192.168.1.5] (c-50-131-118-52.hsd1.ca.comcast.net. [50.131.118.52]) by mx.google.com with ESMTPS id dr6sm699024pac.11.2013.04.08.18.12.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 18:12:22 -0700 (PDT) Message-ID: <1365469938.1741.267.camel@localhost> From: Rex Buddenberg To: Vincent Chen Date: Mon, 08 Apr 2013 18:12:18 -0700 In-Reply-To: References: <5D3E853BEE49C848BB63047C794C8655AE96BCA6@WOK-INTRA-EXC02.intra.ofcom.local> <1365444914.1741.244.camel@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.3 (3.6.3-2.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Cc: "paws@ietf.org" , "johnny.dixon@bt.com" , Reza Karimi Subject: Re: [paws] Extensibility for Ofcom 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, 09 Apr 2013 01:12:25 -0000 Vince, I think it's there... > (We might want to rename the second to maxContiguousBW) this sentence gives me warm fuzzies. I recognize the diff between policy and mechanism and that my question is laced with policy issues. But I think we will want policies that facilitate transformation of narrowband slices into broadband slabs. And that transformation should be supported and facilitated by the PAWS mechanism. btw, are you old enough to recognize that this is a parallel discussion to that in CIDR? Thanks. On Mon, 2013-04-08 at 17:50 -0700, Vincent Chen wrote: > Rex, > > > What is not expressed in the doc is that maxTotalBW and > maxNominalChannelBW are responses from the Database to the Device as > additional constraints. > As Cesar indicated earlier: > > > - maxTotalBW: Device can use a maximum of specified bandwidth, which > can be contiguous or not > - maxNominalChannelBW: The maximum width of any single contiguous > block of spectrum > > > (We might want to rename the second to maxContiguousBW) > > > For example: > 1. Device asks for available spectrum, providing its location and > device descriptor fields (which can include technology ID, etc.) > > > 2. Database returns available spectrum in terms of start and stop > frequencies and max allowable power levels within those frequencies. > Database response may also include the constraints: > - maxTotalBW > - maxNominalChannelBW > > > 3. Devices selects spectrum it will use based on what's available and > these additional constraints. > > > Hope that makes more sense? > > > -vince > > > > > On Mon, Apr 8, 2013 at 11:15 AM, Rex Buddenberg > wrote: > maxTotalBW > maxNominalChannelBW > ETSIENmaxLocationChange > > > Please tell me what these parameters mean. > > I'm mentally bouncing the page against a use case where we > have a > broadband (500kHz or so) device that is attempting to get an > allocation > in a traditionally narrowband (e.g. VHF) space where (in US) > the > licenses are for 25kHz, 12.5KHz or 6.25KHz. The broadband > device would > need multiple narrowband allocations all cheek-by-jowl. > > A lot of the VHF space is allocated, but a good deal is not > used much. > For example, in the county where I live, the county has over > 200 > narrowband VHF licenses. At some time in the future, it's > entirely > conceivable that white space governance could extend into this > area ... > beyond the existing mindset of TV spectrum. > > How would such a broadband device request a chunk of broadband > spectrum? > Can it be expressed with these parameters? Is PAWS at least > extensible > to accommodate such a request in the future? > > > > > > > On Mon, 2013-04-08 at 16:57 +0000, Cesar Gutierrez wrote: > > Vince and all, > > > > > > > > The attached is the list of the parameters that need to be > > incorporated to existing IETF PAWS protocol functionalities > in order > > to cover the requirements in the current draft of the ETSI > Harmonised > > Standard. I would be grateful if IETF PAWS members could > review and > > comment. > > > > > > > > Please note that this list does not address support for the > current > > database discovery requirement in ETSI HS. It does not > address either > > the device update function (or kill switch, or PUSH) that > was briefly > > discussed at the meeting in Orlando. We are still discussing > this > > function in ETSI and the UK, and I expect to bring it to > consideration > > of IETF PAWS members in the coming weeks. > > > > > > > > Thanks and regards, > > > > Cesar > > > > > > > > > > > > > > > > > > > > From: Vincent Chen [mailto:vchen@google.com] > > Sent: 14 March 2013 05:17 > > To: Cesar Gutierrez; paws@ietf.org > > Subject: Extensibility for Ofcom > > > > > > > > > > Cesar, > > > > > > > > > > Thanks for joining the call for the IETF/PAWS. > > > > > > > > > > > > I want to follow up with you on the parameter names and > values that we > > should consider adding to the draft to support Ofcom White > Space > > rules. In particular: > > > > > > > > > > > > - What is the "unique device identifier" intended to be? Is > there a > > separate certification ID apart from the serial number? > > > > > > > > > > > > - What should be the parameter name for "device class"? > What are the > > possible values and what do they mean? > > > > > > > > > > > > - What should be the parameter name for "technology ID"? > What are the > > possible vales and what do they mean? > > > > > > > > > > > > Are you aware of other parameters that must be defined for > Ofcom? > > > > > > > > > > > > Thanks for your help. > > > > > > > > > > > > -- > > -vince > > > > > > > > > > > > ______________________________________________________________________ > > > > > ****************************************************************************************************************** > > For more information visit www.ofcom.org.uk > > > > This email (and any attachments) is confidential and > intended for the > > use of the addressee only. > > > > If you have received this email in error please notify the > originator > > of the message and delete it from your system. > > > > This email has been scanned for viruses. However, you open > any > > attachments at your own risk. > > > > Any views expressed in this message are those of the > individual sender > > and do not represent the views or opinions of Ofcom unless > expressly > > stated otherwise. > > > ****************************************************************************************************************** > > > _______________________________________________ > > paws mailing list > > paws@ietf.org > > https://www.ietf.org/mailman/listinfo/paws > > > > > > > -- > -vince From iesg-secretary@ietf.org Tue Apr 9 07:11:05 2013 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 41FF021F8F33; Tue, 9 Apr 2013 07:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 WSY+12AVRaU4; Tue, 9 Apr 2013 07:11:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FBE21F8F16; Tue, 9 Apr 2013 07:11:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130409141104.13048.29361.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 07:11:04 -0700 Cc: paws mailing list , paws chair , RFC Editor Subject: [paws] Document Action: 'Protocol to Access White Space (PAWS) Database: Use Cases and Requirements' to Informational RFC (draft-ietf-paws-problem-stmt-usecases-rqmts-15.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: Tue, 09 Apr 2013 14:11:05 -0000 The IESG has approved the following document: - 'Protocol to Access White Space (PAWS) Database: Use Cases and Requirements' (draft-ietf-paws-problem-stmt-usecases-rqmts-15.txt) as Informational RFC This document is the product of the Protocol to Access WS database Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ Technical Summary 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. This document includes the problem statement for the development of a protocol to access a database of whitespace information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented. Working Group Summary This document went through significant change during the WG process. Early in the WG process, there were disagreements on what the rules mean and what requirements should be derived from them. Those disagreements were resolved and the document was submitted to the IESG for publication. At that time, many issues were raised during AD Review. Unfortunately, at about the same time, the original authors (Probasco and Patil) changed employment and were unable to continue as document editors. A new editor was found and a few rounds of changes were undertaken. Discussion took place between the AD and the WG, resulting in the draft that got Last Called. Last Call comments required several changes, and those issues have also been addressed. The WG has consensus on the present document. Document Quality This document specifies only requirements, not the protocol, so implementations are n/a. The document was reviewed by people who are familiar with the regulatory rules in the white-space area. Select IEEE 802 groups were notified of the existence of this draft and the Last Call. Personnel Document Shepherd is Gabor Bajko. Responsible AD is Pete Resnick. RFC Editor Notes Section 4.1: OLD Common steps may occur in master-slave networks include the NEW Common steps that may occur in master-slave networks include the Section 4.3: OLD Once the bridged device (WS + Wi-Fi) is connected to a master and WS NEW Once the bridged device (Slave Bridge + Wi-Fi) is connected to a master and WS OLD 1. A bridged slave device (WS + Wi-Fi) is connected to a master NEW 1. A bridged slave device (Slave Bridge + Wi-Fi) is connected to a master Author's Addresses: (Note: If you have some way to confirm contact information for all authors, please do.) OLD Basavaraj Patil NEW Basavaraj Patil Cisco Systems From iesg-secretary@ietf.org Tue Apr 9 07:11:05 2013 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 C5DC321F8F69 for ; Tue, 9 Apr 2013 07:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 A9gEMC95jyml; Tue, 9 Apr 2013 07:11:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A18E821F8F1E; Tue, 9 Apr 2013 07:11:04 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 X-IETF-Draft-string: draft-ietf-paws-problem-stmt-usecases-rqmts X-IETF-Draft-revision: 15 Message-ID: <20130409141104.13048.47647.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 07:11:04 -0700 Cc: paws mailing list , paws chair , RFC Editor Subject: [paws] Document Action: 'Protocol to Access White Space (PAWS) Database: Use Cases and Requirements' to Informational RFC (draft-ietf-paws-problem-stmt-usecases-rqmts-15.txt) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 14:11:05 -0000 The IESG has approved the following document: - 'Protocol to Access White Space (PAWS) Database: Use Cases and Requirements' (draft-ietf-paws-problem-stmt-usecases-rqmts-15.txt) as Informational RFC This document is the product of the Protocol to Access WS database Working Group. The IESG contact persons are Pete Resnick and Barry Leiba. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-paws-problem-stmt-usecases-rqmts/ Technical Summary 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. This document includes the problem statement for the development of a protocol to access a database of whitespace information followed by use cases and requirements for that protocol. Finally, requirements associated with the protocol are presented. Working Group Summary This document went through significant change during the WG process. Early in the WG process, there were disagreements on what the rules mean and what requirements should be derived from them. Those disagreements were resolved and the document was submitted to the IESG for publication. At that time, many issues were raised during AD Review. Unfortunately, at about the same time, the original authors (Probasco and Patil) changed employment and were unable to continue as document editors. A new editor was found and a few rounds of changes were undertaken. Discussion took place between the AD and the WG, resulting in the draft that got Last Called. Last Call comments required several changes, and those issues have also been addressed. The WG has consensus on the present document. Document Quality This document specifies only requirements, not the protocol, so implementations are n/a. The document was reviewed by people who are familiar with the regulatory rules in the white-space area. Select IEEE 802 groups were notified of the existence of this draft and the Last Call. Personnel Document Shepherd is Gabor Bajko. Responsible AD is Pete Resnick. RFC Editor Notes Section 4.1: OLD Common steps may occur in master-slave networks include the NEW Common steps that may occur in master-slave networks include the Section 4.3: OLD Once the bridged device (WS + Wi-Fi) is connected to a master and WS NEW Once the bridged device (Slave Bridge + Wi-Fi) is connected to a master and WS OLD 1. A bridged slave device (WS + Wi-Fi) is connected to a master NEW 1. A bridged slave device (Slave Bridge + Wi-Fi) is connected to a master Author's Addresses: (Note: If you have some way to confirm contact information for all authors, please do.) OLD Basavaraj Patil NEW Basavaraj Patil Cisco Systems From vchen@google.com Wed Apr 10 12:30:23 2013 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 084A921F90CE for ; Wed, 10 Apr 2013 12:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 SiOE44vnEalR for ; Wed, 10 Apr 2013 12:30:21 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id F2C1F21F90B8 for ; Wed, 10 Apr 2013 12:30:20 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id d46so638011wer.2 for ; Wed, 10 Apr 2013 12:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nQYN8QUCn8hcrPM54U22dvep3gHg3eX48DczF8sYqT0=; b=n4/rht6KFQr2M8YriVrIdKo1yVM3kYdS6XNEbGbvf+8RjFL7xHx6HgES1H956JzOd1 jKIMu0R7eJQNQLtD8+54MB9QB1cCd1Z4OJr0dtoUkYLx5mIcxKQnEyyv9qcmhtfx5Cn6 QZrFmgmXepjmX2ICfI8TcmZNSSd31UzRVPBKkP3Kla9osTxAj8BzSCWkd6dMEy/hRps2 FQ0R53ky6UJV5gw5Qdk546pe2MQ3tYbrkyG2WAi/KzdCtrhiOb/1yYmrkyrRx3Jajjq8 JsydkIiG2iLvOpopAM6XrY6Ewjr5/9dXsbyVgzwSsrQdh31o3uqIhe7km2mdx9ikK+1a trzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=nQYN8QUCn8hcrPM54U22dvep3gHg3eX48DczF8sYqT0=; b=YVJLCb+EZUgrIQqACieGMY88vklo5PGuQanR686HWMMJH18G9wIVOHgwmNtv9SdoCl EO3FVAimx6YKyTR/0n2fpwF2n0qOrBt2eY1Abf9ICucou126kHCtDybzm6jhgyuEAr3d KCF7V6g5M3YxiNJ4bfVhA5jWYD3Zrvd9GKtFl7xbTZjFjWbynmEV+CL7xCUGaKx+pMsG LLNQr6cBqapO3UTmXF9mCYMYnQwihwmlkLrFiUtjkxZOLNSXUh47XAxTqe/7rdwk8Fsz nBbaTwpLuJhkDdxd8ptH16fdyf6ViJcXDNyrmpLKkivtvfeoCoxH9/iJ3uC0XE53GgXp o+Qw== MIME-Version: 1.0 X-Received: by 10.180.82.33 with SMTP id f1mr28878095wiy.13.1365622219947; Wed, 10 Apr 2013 12:30:19 -0700 (PDT) Received: by 10.194.55.138 with HTTP; Wed, 10 Apr 2013 12:30:19 -0700 (PDT) In-Reply-To: <5D3E853BEE49C848BB63047C794C8655AE96BBF3@WOK-INTRA-EXC02.intra.ofcom.local> References: <1ECAFF543A2FED4EA2BEB6CACE08E476021DA338@008-AM1MPN1-006.mgdnok.nokia.com> <5D3E853BEE49C848BB63047C794C8655AE96BBF3@WOK-INTRA-EXC02.intra.ofcom.local> Date: Wed, 10 Apr 2013 12:30:19 -0700 Message-ID: From: Vincent Chen To: Cesar Gutierrez Content-Type: multipart/alternative; boundary=f46d041826da5286c804da06b3f9 X-Gm-Message-State: ALoCoQmWrZswUGLQfAYEn2usAjyErEqJiXMYoz2Gny8AZHQOlE1HjXflSrzahWGIIA2kPO4Lj6yFiVOIVaUr6UR1tKoFVWQwRdm/sCzk9+/+hJVq5xobgjG3H9R9ODcELAFpogfcxPJpE6xce5hCjkFgY7H811+huF6pbC4h/9mtk5tAwD6+DWcGKuElpGOAwDsg3+mMTUP5 Cc: "paws@ietf.org" , Reza Karimi , "johnny.dixon@bt.com" Subject: Re: [paws] Database Discovery: static provisioning 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, 10 Apr 2013 19:30:23 -0000 --f46d041826da5286c804da06b3f9 Content-Type: text/plain; charset=ISO-8859-1 Cesar, Thanks for your input. I agree that we should not get into details of dynamic discovery in the current protocol specification. We do, however, probably need to put in enough details on preconfiguration to have the specification be sufficiently stand-alone. In the meantime, I've taken another stab at this section addressing some of the concerns raised by Gabor. Comments are welcomed from all. -vince -------------------------------- 4.1. Database Discovery Different regulators may have different requirements for the approval and operation of databases, such as: o A regulator may only allow a limited number of certified databases to operate. It also may require the certification of each device- to-database pairing. o A regulator may maintain a trusted website that lists all approved databases. It also may mandate how devices use the listing service. o A regulator may allow each database to define its own terms of use, so that, for example, an approved device may not be able to access all approved databases. Prior to sending PAWS messages, a Device MUST determine the URI for a Database that provides service at its current location. o A Device SHOULD support operation in any regulatory environment. Preconfiguration The Device MAY be provisioned statically with the URI of one or more Databases. For operation in regulatory domains that do not have a listing server, the Device SHOULD be provisioned with the URI of all the databases for which it is certified or otherwise permitted to operate. The Device also MAY be provisioned with the URI of listing servers approved by regulators. To adapt to changes to the list of certified or approved databases, the Device SHOULD be able to update its preconfigured lists of databases and listing servers. When the preconfigured list of databases is provided by a listing service, the Device SHOULD check the service periodically to update its list. The time between such updates SHALL be no longer than one week, or any update interval required by the applicable regulatory domain, whichever is shorter. Dynamic Discovery The Device MAY obtain the URI of one or more Databases dynamically from authorized and authenticated entities. The Device SHOULD use dynamic provisioning of Database URIs when the mechanism is defined. The Device MUST use dynamic provisioning in regulatory domains that do not allow static provisioning. Error Handling Whether the Device's list of databases is preconfigured or obtained dynamically, the Device SHOULD select an alternate database from the list if: o A database is unreachable or does not respond. o A database returns an UNSUPPORTED error (see Error Codes (Section 5.13)), which may indicate that the database does not support the regulatory domain where the device is located. If a suitable database cannot be contacted, the Device MUST NOT operate in white space spectrum. If the Device is already operating when it fails to contact a suitable database, and if the applicable regulatory domain provides a grace period, the Device may continue to operate during such period, but must cease operation at or before the expiration of the grace period. If a grace period is not provided by the applicable regulatory domain, an operating Device that fails to contact a suitable database MUST cease operation immediately. Redirects The Database MAY redirect a PAWS request by returning a HTTP 3xx response (as defined by HTTP/1.1 [RFC2616]). The Database MUST provide the redirect URI in the Location header of the 3xx response, and the Device MUST handle redirects by using the Location header provided by the Database. When redirecting, the Device MUST observe the delay indicated by the Retry-After header. The Device MUST authenticate the Database that returns the redirect response before following the redirect. Also, the Device MUST authenticate the Database indicated in the redirect. Since the Device may communicate with a Database (which it authenticated) without user interaction, when the response code is 301 (Moved Permanently), the Device MAY redirect without asking a user for confirmation (note that this represents an exception to the HTTP/1.1 [RFC2616] requirements for HTTP POST methods). --f46d041826da5286c804da06b3f9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Cesar,

Thanks for your input. I a= gree that we should not get into details of dynamic discovery in the curren= t protocol specification.
We do, however, probably need to = put in enough details on preconfiguration to have the specification be suff= iciently stand-alone.

In the meantime, I've taken another sta= b at this section addressing some of the concerns raised by Gabor.
Comments are welcomed from all.

-vince

-------------------------------= -

4.1. =A0Database Discovery

=A0 =A0Different regulators may have different require= ments for the approval
=A0 =A0and operation of databases, such as:

= =A0 =A0o =A0A regulator may only allow a limited number of certified databa= ses
=A0 =A0 =A0 to operate. =A0It also may require the certificat= ion of each device-
=A0 =A0 =A0 to-database pairing.
=A0 =A0o =A0A regulator may= maintain a trusted website that lists all approved
=A0 =A0 =A0 d= atabases. =A0It also may mandate how devices use the listing
=A0 = =A0 =A0 service.
=A0 =A0o =A0A regulator may allow each database to define its own term= s of
=A0 =A0 =A0 use, so that, for example, an approved device ma= y not be able to
=A0 =A0 =A0 access all approved databases.
=

=A0 =A0Prior to sending PAWS messages, a Device MUST determine the URI= for a
=A0 =A0Database that provides service at its current locat= ion.

=A0 =A0o =A0A Device SHOULD support operation= in any regulatory environment.

=A0 =A0Preconfiguration

=A0 = =A0The Device MAY be provisioned statically with the URI of one or more
=A0 =A0Databases. =A0For operation in regulatory domains that do not= have a
=A0 =A0listing server, the Device SHOULD be provisioned with the URI o= f all
=A0 =A0the databases for which it is certified or otherwise= permitted to
=A0 =A0operate. =A0The Device also MAY be provision= ed with the URI of listing
=A0 =A0servers approved by regulators. =A0To adapt to changes to the l= ist of
=A0 =A0certified or approved databases, the Device SHOULD = be able to update
=A0 =A0its preconfigured lists of databases= and listing servers. =A0When the
=A0 =A0preconfigured list of databases is provided by a listing servic= e, the
=A0 =A0Device SHOULD check the service periodically to upd= ate its list. =A0The
=A0 =A0time between such updates SHALL be no= longer than one week, or any
=A0 =A0update interval required by the applicable regulatory domain,
=A0 =A0whichever is shorter.

=A0 =A0Dynam= ic Discovery

=A0 =A0The Device MAY obtain the URI = of one or more Databases dynamically
=A0 =A0from authorized and authenticated entities. =A0The Device SHOUL= D use
=A0 =A0dynamic provisioning of Database URIs when the mecha= nism is defined.
=A0 =A0The Device MUST use dynamic provisioning = in regulatory domains that
=A0 =A0do not allow static provisioning.

=A0 = =A0Error Handling

=A0 =A0Whether the Device's = list of databases is preconfigured or obtained
=A0 =A0dynamically= , the Device SHOULD select an alternate database from the
=A0 =A0list if:

=A0 =A0o =A0A database is unr= eachable or does not respond.
=A0 =A0o =A0A database returns an U= NSUPPORTED error (see Error Codes
=A0 =A0 =A0 (Section 5.13)), wh= ich may indicate that the database does not
=A0 =A0 =A0 support the regulatory domain where the device is located.=

=A0 =A0If a suitable database cannot be contacted= , the Device MUST NOT
=A0 =A0operate in white space spectrum. =A0= If the Device is already operating
=A0 =A0when it fails to contact a suitable database, and if the applic= able
=A0 =A0regulatory domain provides a grace period, the Device= may continue to
=A0 =A0operate during such period, but must ceas= e operation at or before the
=A0 =A0expiration of the grace period. =A0If a grace period is not pro= vided by
=A0 =A0the applicable regulatory domain, an operating De= vice that fails to
=A0 =A0contact a suitable database MUST cease = operation immediately.

=A0 =A0Redirects

=A0 =A0The Da= tabase MAY redirect a PAWS request by returning a HTTP 3xx
=A0 = =A0response (as defined by HTTP/1.1 [RFC2616]). =A0The Database MUST
<= div>=A0 =A0provide the redirect URI in the Location header of the 3xx respo= nse,
=A0 =A0and the Device MUST handle redirects by using the Location head= er
=A0 =A0provided by the Database. =A0When redirecting, the Devi= ce MUST observe
=A0 =A0the delay indicated by the Retry-After hea= der. =A0The Device MUST
=A0 =A0authenticate the Database that returns the redirect response be= fore
=A0 =A0following the redirect. =A0Also, the Device MUST auth= enticate the
=A0 =A0Database indicated in the redirect. =A0Since = the Device may communicate
=A0 =A0with a Database (which it authenticated) without user interacti= on,
=A0 =A0when the response code is 301 (Moved Permanently), the= Device MAY
=A0 =A0redirect without asking a user for confirm= ation (note that this
=A0 =A0represents an exception to the HTTP/1.1 [RFC2616] requirements = for
=A0 =A0HTTP POST methods).

--f46d041826da5286c804da06b3f9-- From Cesar.Gutierrez@ofcom.org.uk Tue Apr 16 06:18:00 2013 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 CB34421F9387 for ; Tue, 16 Apr 2013 06:18:00 -0700 (PDT) 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=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 bH0sbNguxiOd for ; Tue, 16 Apr 2013 06:18:00 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.151]) by ietfa.amsl.com (Postfix) with ESMTP id E1B5621F9376 for ; Tue, 16 Apr 2013 06:17:58 -0700 (PDT) Received: from [85.158.139.211:4904] by server-15.bemta-5.messagelabs.com id 2B/F6-22815-58F4D615; Tue, 16 Apr 2013 13:17:57 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-3.tower-206.messagelabs.com!1366118276!19100262!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23721 invoked from network); 16 Apr 2013 13:17:56 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-3.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 16 Apr 2013 13:17:56 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 16 Apr 2013 14:20:14 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([::1]) with mapi id 14.01.0289.001; Tue, 16 Apr 2013 14:20:14 +0100 From: Cesar Gutierrez To: "paws@ietf.org" Thread-Topic: Device update function - ETSI/UK regulatory requirement Thread-Index: Ac46hSC6Ps1OFLeIR9uE/BxoEtWBTw== Date: Tue, 16 Apr 2013 13:20:14 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/mixed; boundary="_002_5D3E853BEE49C848BB63047C794C8655AE96EF20WOKINTRAEXC02in_" MIME-Version: 1.0 Cc: Reza Karimi , "johnny.dixon@bt.com" Subject: [paws] Device update function - ETSI/UK regulatory requirement 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, 16 Apr 2013 13:18:00 -0000 --_002_5D3E853BEE49C848BB63047C794C8655AE96EF20WOKINTRAEXC02in_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, At the meeting in Orlando we discussed a device update function (or kill sw= itch, or PUSH). This arises from the UK regulatory requirement that a datab= ase should be able to contact any device within a short time. After review = of PAWS use case document with regards to this, I think our UK requirement = is neatly captured in requirement P.16 "The protocol MUST support the capab= ility for the database to inform master devices of changes to spectrum avai= lability information" This requirement is already part of the current draft of the ETSI Harmonise= d Standard. Its main elements are summarised below, and the full text is a= ttached: +++++++++++ DEFINITION The master WSD update is the process by which a database informs a master W= SD that its operational parameters, and those of the slave WSDs attached it= , are still valid or are no longer valid REQUIREMENTS - A master WSD shall support WSD update function. For this, a master WSD = shall either *be able to receive an update from the Controller Database WSDB wit= hin Tping seconds (push update), or *send an update request to the Controller Database WSDB every Tping= seconds (pull update). - A master WSD shall support a Tping value of [60] seconds or higher. - A master WSD shall cease transmission, and shall instruct the slaves atta= ched to it to cease transmission, if it receives update from the WSDB that = the operational parameters are no longer valid. - A master WSD shall cease transmission, and shall instruct the slaves atta= ched to it to cease transmission, if it loses connection with the WSDB ++++++++++ It is worth signalling that, at least among UK stakeholders, there is wide = support for the pull method and little support for the push method. This is= consistent with the view that it will be very difficult to implement the p= ush functionality over the internet. As a first step, I would like to ask the PAWS WG to consider support for th= is functionality in the specification. Secondly, it would be good to have v= iews of how a pull mechanism could be implemented in the PAWS protocol. We = have had early discussions about this off-line, and I think the alternative= s are 1) to adapt one of the existing procedures (SPECTRUM_USE_NOTIFY and "= Device Validation" are possible candidates), and 2) create a new, dedicated= procedure. Thanks and regards, Cesar ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_002_5D3E853BEE49C848BB63047C794C8655AE96EF20WOKINTRAEXC02in_ Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="EN301598v0018_MasterWSDupdate.docx" Content-Description: EN301598v0018_MasterWSDupdate.docx Content-Disposition: attachment; filename="EN301598v0018_MasterWSDupdate.docx"; size=14057; creation-date="Tue, 16 Apr 2013 13:14:47 GMT"; modification-date="Tue, 16 Apr 2013 13:14:00 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQAwySgMcgEAAKUFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMluwjAQvVfqP0S+Vomhh6qqCBy6HFuk0g8w9gSsepPHbH/fSaBR1UKQClwiJeO3+OXZg9HammwJ EbV3JesXPZaBk15pNyvZx+Qlv2cZJuGUMN5ByTaAbDS8vhpMNgEwI7TDks1TCg+co5yDFVj4AI4m lY9WJHqNMx6E/BQz4Le93h2X3iVwKU81BxsOnqASC5Oy5zV93jqJYJBlj9uFtVbJRAhGS5HIKV86 9Usl3ykUhGzW4FwHvCEbjO9VqCeHBXa4N4omagXZWMT0KizZ4CsfFVdeLiztoeim2ePTV5WW0OJr thC9BETK3JqinVih3bf/gz7cwk4hEvL8RlrqoyYwbQzg+R1sebvkKaxx9AE5leNkfajrp0Dl9D8C xKSh7c/B/BFSovQvsfkdc9f2myomOnTAm2f/5AwamqOSFZ3LiZgaOFnvT/1b6qMmVjB9v1j6P8i7 jLT9kz7+I4zvO6tG72kdby7Z4RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03 Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1 nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQCzvosdCQEAALYD AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKyTz0rEMBDG74LvEOZu0666iGy6FxH2qvUB0nb6B5ukJLNq396hsNsuLvXS S2C+kO/7zTDZ7X9MJ77Qh9ZZBUkUg0BbuLK1tYKP7PXuCUQgbUvdOYsKBgywT29vdm/YaeJHoWn7 INjFBgUNUf8sZSgaNDpErkfLN5XzRhOXvpa9Lj51jXITx1vp5x6QXniKQ6nAH8p7ENnQc/L/3q6q 2gJfXHE0aOlKhAxIxJ0F9tS+RlJwUiLmBHkdYbMqAg0dz3ACGOul+GTNeHs0OXqewURwlpYgtmtC EK8HTgBjKcczWWJ4XJOhcpYynXczjrO0BPGwJsQ35u9/VnImnkDkxW9LfwEAAP//AwBQSwMEFAAG AAgAAAAhANbl1fmcDAAAioAAABEAAAB3b3JkL2RvY3VtZW50LnhtbOxdW2/bNhR+H7D/QPhpBVrf 6rSZ0aRIlwQo0BVFmmEPwzDQEh1xlUiNpKymv37nUBdLsnyJkThqwyfHkkXxdvid832HzJu3X6OQ LJjSXIqT3qg/7BEmPOlzcXPS++P68sVxj2hDhU9DKdhJ75bp3tvTn396k0596SURE4ZAEUJPF3A3 MCaeDgbaC1hEdV/GTMDNuVQRNfBV3Qwiqr4k8QtPRjE1fMZDbm4H4+HwVS8vRp70EiWmeREvIu4p qeXc4CNTOZ9zj+UfxRNql/dmT57nVbZvHCgWQh2k0AGPdVFatG9p0MSgKGSxqRGLKCx+l8a7vM1X NIXxiMKs2qlUfqykx7SGq+fZzbLE0XDTu/MOxCLKJ3apQv2dRU0iykVZDM6OxviXg9eHwRtk7x5g UcuGQF+cwlyaSf8WP2OSTmEu+lcnveHw8nhydAHzL790zuY0CU3lzmDlkePxcDyZlI98grkxHDYu Vsqp3/lU+bEt+ZPCjy+MxR/ZV2Pfhl8+cMG0/SbBcuahTD8lwjNQzwUNoYyevUcTIz/H1GPnF2vv fGze8f9NtLniN4F5L/zGTQ2FwYDD1RkDk4LuHo3BXNMpnRsGDR0d228h1O6kN56UX66SEC5gdbKK cVtyyObQlaPJyHZwQMWNNXl7wdbfQJPPQn4jrI3nbZtRzfAFWUkyMfjlwyIsqvoyu6GynlOXUhgN 9xjV5kxzetK75hHT5CNLyZWMKMyedOrp1cu2BvpbUex4kpWrv/2GxdluhrbDrwYwOfBl8BlnL51J +QVXmc+GKhwT7uOQwB+CRtAP/1xL7+XR+PVkfPxqlNcWbtpJV5suOPSHb0c6tevpFAcbahsrppla sN7ppD/uH/VfE2ypydpta9itutNZPia1uqFdnV0OX55fWGPvUK/+DhOTqY53KiLj6oT48/P5wett FP/C7mybOGF1kJgXvkxFY/4W1nphF6XMVu0LVLcmdvsYrAzAoy0ap0nsU8NqvYtrIlaoBqp1yLuq LXlFlzuEROzNEfL1cITosURIvGCn6F4ImSPZfa2B2/Hw4Q1pXR3Q7nPY6o9qMxOQtZhrtQl4n+az oVYWpbB2MNG54BgD1KrnDGdP1/I+LYJqj/NVzxDmzUZvMjgTuv2xXfzM3Hffxc/cfQZ3syUw/9tB 7TpgBJ2LDFEI18TAlTziJLNbkgbcCwjFH70jXGB4r+ErRPzoS+GjJqCGcHD9gQFQNsamIYmpAg8c fqKfEyAU4EdSMyLntngd0oV9LZRkDAUCwYcC4IeKAf/AQyApaMh9IhURkgAXcQOvspf6dRB2trun 7dbCQgd620LTDfBSgt64hipdAb0r9l/CFcOwXtcqeDDTeSTa5I48yQ5g1vTiurnS47jmhMzOXlc3 W7IWs86q6KMDCnihkziWwABVoGyONB04e31CLgFITMARilYfZRwQr8EKHMw4RBJlg8XDJa+W+yVw 731JC9ooBKpVPuDMqk4sOlewQpSm0/VO7VqzmjFCZyEjRhLFPMbBRaOicAznSkbWd/sNWF4lwxBM 5pwaihwxScGEuKi7ZrAMKSnnFwpdZ3MbA7+pYxaGlqm9KxXb2QXq9LoGqndB/W61CXh2pjIJAMbL TiWdzLSneGxwtGDpyfHPnMYgHjSa3T7WwPP9MCPdHj4RzTwpfE1+iRMd5Mby7DlGLrUecoCST6oi 5i7lLeenrdjODYTOP9gyqZnwawbRAg/Y7CewYiwxVUFsxrRBwEXSpQ1ZGazKt/WlpKXnHLCifFvo zw5Y25j1bvVKxZ3YDqwQ32X05LN+bQ05GKi6WMvFWpi/0hTDC2dmbaLK2lhrA4VB3XKPq/l3Sl65 OGov7gHVncTqQ3+9Gv5dRlUQRgWQH8eUW/g35Pg57rpzyvFdFn4PJG5g3RQVOuKQ5itFJplmzDYX 2qgEEk4xRLDCaUU0hciB2/ihrQw+x5s5ladXiDwr6FrtFktu126tItsRCdY5Yc4J29cJO635W1lK Q0A1mTEmIKkB7AoyvUkkffac8D7rwzUK4hEw4LPEQA6CIbFMmYI0BcxqzMwzpZjubMly2DMB2lPV gjXJrBcfza8bkgjIbZg+TghT6kbbhKZxzvaWDzi7c3a3r921x/YZMOWSbZ5wtGTPwQINQePMkct/ 7vSlTH+xtI6Li5Za4hNgi3N9CSEHQClzBcFDJBv12F28ukqeHcpVDpV22ozl1KqnoFbxec0cWhSX J6JVARKXMB0nJQ9fQjRo35C+a8AvXidgYe5vA88fcilzPJHjiSat+w6/M/2rDFh9toBd8GBfmGSv 68EqRKOwvxZjTMHQBiUEtOA2Q0K9TeSC7P11Zul0ZVQgnUPdSM57Wg41sjkN+8kBzdmNlTYrKr1L dMyWixX31+bePB27eSQH64c+luPX46Me0DrLTcd4Yf9Nx/mzze0qGzdSPtp2yYev1VoprtitPO6P mikXu2cfHKT+xRbmdjr1g4QcQgAuwex+F/ABTYq6Bvp+lW2a2S5Mu+3yXb29B8ujclYMB2jlidDb Dtd5lWfO53u5iuTGh59vOBvuuoHs4WsFVrzcadkfPcIRA8XAZUcRbclyKSz20Q8dcOqdU+/2Ve/q qnkmaPuM4T4wICMQXiqog3vA7DWbV1KK6yGCU4NPPRjelBr2NtH7pRO93UEb9+IDr/U2gQQH+g65 uh02WSINkW+yhIOe3CbLhhyzu3veLdbXJQdvcZvaA5wiHRhkJ5vSWJGkyj2X38OWS4cyXTnOaYXF +wG3XHLTWDVbG/0EmMuS5K+catCaSuNQF2dMuc3fHW1gBcIVs3lijH8L6paJIO44tgc4pfue5QBH JK5omRXmv3/4Y9v2IxLdQW7lGfcbD7x3m+G6uBmujUps27OGItX97HsD4hFyO9YRlE7Gvv//LnHP uOVk7CZutbMjSzAb12Xdu2yiP4iAV4hi7e34bA8Fzs8hroWuB9MLnD7t9OnsP9Xsc9JHRZ+GlJLa DO6sKTp9GjOvtv4XJedUHsSp/B8AAP//7FhRb9s4DP4rhJ+LLG3TLguWAL1rNwzYFUFS4J4VmbZ1 syWfRMfrfv2RstMmTXfNXrZgKAIEJiXRokjq4+fwDdrJWpXT5GyYvJm9byfh259hV/emnfi5lzGC r1U5CbXSOE1qjwH9GpPZXYHw9/IamjpVhGACEGtq7zSGAKt7aAujC1AQSrXupmpnM+MrfpOhIk4X W8bmUKlA6KM9KhSBIdDKAi8gYxsE8sqGyhBLOSitnU/liRzPDKAb79ESuBq9IuOsKqFWXlXIRsMA 3rMzNJN/doj/a3GrZn99MOlimgyH47Ph2WiUbFRz/4zyGjPVlLQ/Mt9SRcvduX1BrG/xK8UDFuGz sRii5Nbos9K188Zq2px7HwrVkFvKYV/ffHfk9ulI+k8TaGHygj7Z9MmgRE4Oq52sMHOeg3jKYWdR ZXw8LI2jVPLuOCFGD8KiKVkh2+lyxETLJWZ8BKfvxhdiolA2Z9u9IvpG7PJVaXJbSUj6PFupgPKC zpJrSITP63IzftkN9BnnP3DcJR+R0+IqGDVN7kyFAW6xhYWrlJV367Cv7pN5Y/bl9JZs6MLleVHM h53gSzx//q4kXUeDs8HF4C3/828ng3lHx7VXteoiP1vgv43xKJEPO1v+aUX3iyrrB0vpgBp5mnQq aGP2E54T4X+LpLiy4fllv6x8jtMTKbmrLawKhSpL0Hy4D+gTAkNLxC5j4RQCMjzxZVug7UEwFUBK HQQn+CfItI9vg9e6+D7EvNbF0VX4dl28VBOZ4UavK4sALoPUBC0XcmzVtto666B0NueGz6NGWdQ1 kQEy76rXwuFL/RVQDu9xjhVQSu5eF2hT9JjOVY5/eFRf+k5pG2o6olQoZk3IWMLgEkqmC1C5FE/A DHDAOqVJCmXVEFhHULtWzDLatPYElOCQkp6ZAYgZGilPG84UUYuRSPBsB3u48/XOZTdeTprua272 c+ZMS1nct+MHt5nHGgKanQAfniHD3t8f4v6NTX8b558n7pAjccZsiHu8coW67/cqwr+FsD/c33Fa pPOP9BqU57VkuFviTwomPeEsFpq5Ie+RegrfzxrP6/1uXu6E5BCWsM/CO86HmuYPV8YWIe9TeMnj ov0wHl3cjJNI0/OlfAdpmbyevhteJvxc8PPl+HzcZUCd/6Vibbia9aOubfFCsh/FlSNy1aPc0+N+ coGKq3+avB2OxXzmXGTcvZg3FMWe+GtXCuftP7TInOhZ6vRHb4TUC2eeG9K8y/PLuIgPjOGWHY+f NVYuvY8PvKQRDjb7DwAA//8DAFBLAwQUAAYACAAAACEAlrWt4pYGAABQGwAAFQAAAHdvcmQvdGhl bWUvdGhlbWUxLnhtbOxZT2/bNhS/D9h3IHRvYyd2Ggd1itixmy1NG8Ruhx5piZbYUKJA0kl9G9rj gAHDumGHFdhth2FbgRbYpfs02TpsHdCvsEdSksVYXpI22IqtPiQS+eP7/x4fqavX7scMHRIhKU/a Xv1yzUMk8XlAk7Dt3R72L615SCqcBJjxhLS9KZHetY3337uK11VEYoJgfSLXcduLlErXl5akD8NY XuYpSWBuzEWMFbyKcCkQ+AjoxmxpuVZbXYoxTTyU4BjI3hqPqU/QUJP0NnLiPQaviZJ6wGdioEkT Z4XBBgd1jZBT2WUCHWLW9oBPwI+G5L7yEMNSwUTbq5mft7RxdQmvZ4uYWrC2tK5vftm6bEFwsGx4 inBUMK33G60rWwV9A2BqHtfr9bq9ekHPALDvg6ZWljLNRn+t3slplkD2cZ52t9asNVx8if7KnMyt TqfTbGWyWKIGZB8bc/i12mpjc9nBG5DFN+fwjc5mt7vq4A3I4lfn8P0rrdWGizegiNHkYA6tHdrv Z9QLyJiz7Ur4GsDXahl8hoJoKKJLsxjzRC2KtRjf46IPAA1kWNEEqWlKxtiHKO7ieCQo1gzwOsGl GTvky7khzQtJX9BUtb0PUwwZMaP36vn3r54/RccPnh0/+On44cPjBz9aQs6qbZyE5VUvv/3sz8cf oz+efvPy0RfVeFnG//rDJ7/8/Hk1ENJnJs6LL5/89uzJi68+/f27RxXwTYFHZfiQxkSim+QI7fMY FDNWcSUnI3G+FcMI0/KKzSSUOMGaSwX9nooc9M0pZpl3HDk6xLXgHQHlowp4fXLPEXgQiYmiFZx3 otgB7nLOOlxUWmFH8yqZeThJwmrmYlLG7WN8WMW7ixPHv71JCnUzD0tH8W5EHDH3GE4UDklCFNJz /ICQCu3uUurYdZf6gks+VuguRR1MK00ypCMnmmaLtmkMfplW6Qz+dmyzewd1OKvSeoscukjICswq hB8S5pjxOp4oHFeRHOKYlQ1+A6uoSsjBVPhlXE8q8HRIGEe9gEhZteaWAH1LTt/BULEq3b7LprGL FIoeVNG8gTkvI7f4QTfCcVqFHdAkKmM/kAcQohjtcVUF3+Vuhuh38ANOFrr7DiWOu0+vBrdp6Ig0 CxA9MxHal1CqnQoc0+TvyjGjUI9tDFxcOYYC+OLrxxWR9bYW4k3Yk6oyYftE+V2EO1l0u1wE9O2v uVt4kuwRCPP5jeddyX1Xcr3/fMldlM9nLbSz2gplV/cNtik2LXK8sEMeU8YGasrIDWmaZAn7RNCH Qb3OnA5JcWJKI3jM6rqDCwU2a5Dg6iOqokGEU2iw654mEsqMdChRyiUc7MxwJW2NhyZd2WNhUx8Y bD2QWO3ywA6v6OH8XFCQMbtNaA6fOaMVTeCszFauZERB7ddhVtdCnZlb3YhmSp3DrVAZfDivGgwW 1oQGBEHbAlZehfO5Zg0HE8xIoO1u997cLcYLF+kiGeGAZD7Ses/7qG6clMeKuQmA2KnwkT7knWK1 EreWJvsG3M7ipDK7xgJ2uffexEt5BM+8pPP2RDqypJycLEFHba/VXG56yMdp2xvDmRYe4xS8LnXP h1kIF0O+EjbsT01mk+Uzb7ZyxdwkqMM1hbX7nMJOHUiFVFtYRjY0zFQWAizRnKz8y00w60UpYCP9 NaRYWYNg+NekADu6riXjMfFV2dmlEW07+5qVUj5RRAyi4AiN2ETsY3C/DlXQJ6ASriZMRdAvcI+m rW2m3OKcJV359srg7DhmaYSzcqtTNM9kCzd5XMhg3krigW6Vshvlzq+KSfkLUqUcxv8zVfR+AjcF K4H2gA/XuAIjna9tjwsVcahCaUT9voDGwdQOiBa4i4VpCCq4TDb/BTnU/23OWRomreHAp/ZpiASF /UhFgpA9KEsm+k4hVs/2LkuSZYRMRJXElakVe0QOCRvqGriq93YPRRDqpppkZcDgTsaf+55l0CjU TU4535waUuy9Ngf+6c7HJjMo5dZh09Dk9i9ErNhV7XqzPN97y4roiVmb1cizApiVtoJWlvavKcI5 t1pbseY0Xm7mwoEX5zWGwaIhSuG+B+k/sP9R4TP7ZUJvqEO+D7UVwYcGTQzCBqL6km08kC6QdnAE jZMdtMGkSVnTZq2Ttlq+WV9wp1vwPWFsLdlZ/H1OYxfNmcvOycWLNHZmYcfWdmyhqcGzJ1MUhsb5 QcY4xnzSKn914qN74OgtuN+fMCVNMME3JYGh9RyYPIDktxzN0o2/AAAA//8DAFBLAwQUAAYACAAA ACEAKowdrFYDAAD2BwAAEQAAAHdvcmQvc2V0dGluZ3MueG1snFXbjts2EH0v0H8Q9FyvdbctRBvY 1ipNsdsWddp3SqJtYnkDSVvrfn2HkhitUTUI+mTqnJnDuXH84eMbo94VK00EL/zwIfA9zBvREn4q /D+/VIu172mDeIuo4Ljwb1j7Hx9//OFDl2tsDJhpDyS4zkXhXxTPdXPGDOkFI40SWhzNohEsF8cj afD4448eqvDPxsh8uRydHoTEHNSOQjFk9INQp+XgWYrmwjA3yygIsqXCFBkIWJ+J1E6N/V81uOrs RK7fSuLKqLPrwuBblmO6nVDtV4/vCc86SCUarDVUltEhXYYIdzKafo/OUM9nUiukbu9EHqFtfwvB vC6XWDVQUOh5EPhLS8DF4ngwyGCgtcSU9kPQUIzg+i4/KcQYgqYNSO+j8JXY0fmL4A5MCH/dci5A w3an8EflFh/RhZovqD4YIcHuiiCNVTTSzRkp1BisDhI1cOdecKMEdXat+FWYvWBSQVmGUGGkJDJD BJq02oYPI9z+IYRxbkGwjoIoSQYPy05MkEW7OJ1ldkEZRHNMGEbpajPHxGG62pazzD4q909zTJau 1tVqjvnvqDdpsMtmI9isgyoeq3mf6aZKy2z2nu02CcJqLoLtdrXZZ7NMFcTlbD67LEiq2Rrs1ulT tp5T222SOJ6NoAzDuJyNoFon6VOvthxaDr1nuX3Cvyt3qmB+PDYM2R6xWhHkvdhHDgPD8lq97gh3 fI1h2eD3zOFSO3KxGAjNEKUVzKgj4H0PTEu0LPGxF6YvSJ0m5b4dLFezKLyIX76q2XeI1SclLnJQ 7RSSn3kLsLswTJJRj3DzTJjD9aU+OC8Ob/0ddeHtb1dlBZdTgbrcwHrGtkLPiJ/ci8B88WlnTbu8 oepgVzh+QVLCYwST+hQWPiWnswntHjDw1SL12n/Up2jkop6DL8v1H6ixmYH1eLAGwxGsxsOExQ6L JyxxWDJhqcPSCcscllnsfIPlBsvrFValO1r8KCgVHW5/dmDh/wsaiqDPSGLoq91aMGAi74FxjWnv muM32Jy4JQb+HSVpGXor/ChI+x6N1hTdxMXc2VolayzvUK9FBsEe7lt15wytg018H0uXt7ghMJCH G6unJfkwBE6JNgcsYZ8aoSDlftH+1CtPf9iP/wAAAP//AwBQSwMEFAAGAAgAAAAhAErYipK7AAAA BAEAABQAAAB3b3JkL3dlYlNldHRpbmdzLnhtbIzOwWrDMAzG8Xth7xB0X531MEpIUiijL9D1AVxH aQyxZCRt3vb0NWyX3XoUn/jx7w9faW0+UTQyDfCybaFBCjxFug1weT8976FR8zT5lQkH+EaFw/i0 6UtX8HpGs/qpTVVIOxlgMcudcxoWTF63nJHqNrMkb/WUm+N5jgHfOHwkJHO7tn11gqu3WqBLzAp/ WnlEKyxTFg6oWkPS+uslHwnG2sjZYoo/eGI5ChdFcWPv/rWPdwAAAP//AwBQSwMEFAAGAAgAAAAh ABbHtZQyBwAAPzoAAA8AAAB3b3JkL3N0eWxlcy54bWy0m1FT2zgQx99v5r6Dx+9tIGmTlmnoUFpa ZtoeJTD3rNgK0dSxcpZSoJ/+pJUtHDu2d7H7ROxY+9vVrv5rQHr3/mGTBL94poRM5+Hxy6Mw4Gkk Y5HezcPbm4sXb8JAaZbGLJEpn4ePXIXvT//+6939idKPCVeBMZCqk2werrXenoxGKlrzDVMv5Zan 5ruVzDZMm8vsbiRXKxHxjzLabXiqR+Ojo+ko4wnTBq7WYqvC3No9xtq9zOJtJiOulPF2kzh7GybS 8NS4F8voI1+xXaKVvcyusvwyv4IfFzLVKrg/YSoS4sY4bkLciFRmX85SJULzDWdKnynBDn65tk8d /CZSumTtg4hFOLJE9dvY/MWSeTgeF3fOrQd79xKW3hX3ePri84eyJ/PQ3Lpd2FtLY3cesuzF4swa G0GYxc9SuNu94M0VuLJlkZk4Y4atNDcJNPmwRhNhEz2eTYuL611ibrCdljkEDBhY2ay5rMy4yavJ 8sJVifmWr77K6CePF9p8MQ+BZW7eXl5lQmZCP87Dt28t09xc8I34IuKY26LM792maxHzf9c8vVU8 frr/4wJKLLcYyV2qjfvTGVRBouJPDxHf2hIzplNmM/zdDkisWVXigEM78eSNu1Ghws3/CuSxy+FB ypozu4wC8L8VBFHveoPGNqJyAGCX5Oukv4lX/U287m8CirffXMz6e2HEs29GXG2UqhKfVC0jV3zl eZi8bSlZO6JWRZ0jakXTOaJWI50jaiXROaJWAZ0jagnvHFHLb+eIWjpbR0QMhKtaRROYDdTCvhE6 4XZ8qwAd95S6vNUEVyxjdxnbrgPbWKtut4nlYrfUOFdBTp8vlgudyfSuc0ZMd7ZL99ma/GmzXTMl zBtNx9SPe079DVsmPPicibgT9doVXy0meDE52MKuEhbxtUxingU3/MFllDD+uwwW7i2j07meaf0q 7tY6WKyh5XbCpg2T3jwTzv5XoWAOWhfTtCGULuOoHE4b6rLZ+Dcei92mmBrE28jU6TkhzRUEuNg+ Ra9siuqrqzMKmwBMCK5d0EMA+wj/XXOh27c5xvjvWtEz7SP8d43rmfahPtrzS1aajyz7GaCW14y8 ds9lIrPVLinWQKc8zMgr2CNwIZAXsbePEokZeQXvyWdwFkXmNzdMnZJz8aSjBAo5HY4Ciw0fCzkp Fdk7JkRETlCFNSaw+mktAUQW3Wv+S9g/PFGbAai0f9fsXM6ThhkwLQj1Dv1jJ3X3O/S4QfOwlMvU /LlE8QBHmzSsPCwtryfX7wg57tf4CKB+HZAA6tcKCaCG+mh+5/E9EQ/p3xwJLLIs+y4GZYdW5hlZ mT2I1gIG6puI96+G1dtcC/W+iaCQE1TvmwgKOTuVXub7JoI1WN9EsBq6RnOOyppKCYrcN8sg/yaA iGgY8UaAhhFvBGgY8UaA+ot3N2Q48UawyNrgNbUs3ggQPEL5Vd+DyuKNAJG1wald/jejou+BlfZf bgcQbwSFnKC6eCMo5Ow0iTeCBY9QKqHC8lKHYA0j3gjQMOKNAA0j3gjQMOKNAA0j3ghQf/Huhgwn 3ggWWRu8ppbFGwEiy4MHlcUbAYJHKNpwULxh1f9x8UZQyAmqizeCQs5ORVD9SyqCRU5QheXFG8GC RyjFkLOguClBDSPeiIiGEW8EaBjxRoCGEW8EqL94d0OGE28Ei6wNXlPL4o0AkeXBg8rijQCRteGg eMNi/OPijaCQE1QXbwSFnJ2KoHqdQ7DICaqwvHgjWFAvvcUbAYJHnguiRDSMeCMiGka8EaBhxBsB 6i/e3ZDhxBvBImuD19SyeCNAZHnwoLJ4I0BkbTgo3rBG/rh4IyjkBNXFG0EhZ6ciqF68ESxygios L3UI1jDijQBBYfYWbwQIHnkGCFYRJU3DiDciomHEGwHqL97dkOHEG8Eia4PX1LJ4I0BkefCgsngj QGRtsPtszX5R9PbU44YiwO4zKHY1oIHjhiRhgXmA13zFM3OSiXfvDukJLCIkEBvKAxviByl/BriN 3ZOGAkGjxDIRErZ0P8IundJBhMms5STBzT/nwRd3AKY2Dkpqf+eNOT1UPi4Ex5PswSHjp37cmiM7 22JnubVmDgjZc135ESA4h3ZpDgTlx3rsYHvOxzwIh6ry2/B/25wKn82Zt7h45ujo4s2r15/euIjM WTFrJNs7HTYPzzLhTg3Bsa/SdaSKC2O4dAgLPKvHEq1NMJE5ctUSS76j3m9ygv301cgatt1DdE9n PooY8+33Ty9p7rm9TaDO/wa/td1q3uIzbEVvTUIAj7hJrjtoTn+BS10e+m1b8LReJi5d5sNlajNq Tg/Cv+hc5cQPzJk135/zJPnGILlabpsfTfhKu2+Pj6DdVkwtpdZy0zw+g93o4MkhA6ZEys64SxuE +dQw9+lus+SZOU7WMv/fpW1TcOxtv/7dxlqXbr+AjfewPLCz/uRb8Umd/g8AAP//AwBQSwMEFAAG AAgAAAAhAMekr+tHAQAAdwIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAIySX0vDMBTF3wW/Q8l7m2YdQ0LbgcqeHAhOFN9CcrcFmz8kcd2+ vWm71Q598PHmnPzuuTcpl0fVJAdwXhpdIZLlKAHNjZB6V6HXzSq9Q4kPTAvWGA0VOoFHy/r2puSW cuPg2RkLLkjwSSRpT7mt0D4ESzH2fA+K+Sw6dBS3xikWYul22DL+yXaAZ3m+wAoCEyww3AFTOxLR GSn4iLRfrukBgmNoQIEOHpOM4B9vAKf8nxd6ZeJUMpxsnOkcd8oWfBBH99HL0di2bdYWfYyYn+D3 9dNLP2oqdbcrDqguBafcAQvG1Rw8cyWenHTba5gP67jorQRxf7qYfgud18FBdi9Uz0o8LWOXfqih FYgkxqTDUBflrXh43KxQPctJkebzlCw2pKCE0Dz/6DJd3e9iDwfqnOz/xPk18QKo+8TXX6X+BgAA //8DAFBLAwQUAAYACAAAACEAwyRmXpkDAADBIwAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbOxa3W6b MBS+n7R3iLhvgYQEGpVWbZNKnbZq0jrtmoDTWMM2MiZpbvsye4Q9Vl9hxxhYgPQnJBe58E0Ixz7H 9sf57M+G88snEveWiKeYUd+wTy2jh2jIIkwffePnw+2JZ/RSEdAoiBlFvrFGqXF58fnT+WpMMzJD HCr2IAZNx0soXgiRjE0zDReIBOkpSxCFwjnjJBBwyx9NEvDfWXISMpIEAs9wjMXa7FvWyCjCMN/I OB0XIU4IDjlL2VxIlzGbz3GIikvpwT/SrvKcsDAjiIq8RZOjGPrAaLrASVpGI12jwRAXZZDlW4NY krist0o+0lrEgxXgTGLV7RXjUcJZiNIUrBNVWEW0rbfaLgCUISqPj3Sh3mbZExJgWoWR6dF4/tXD O4WHZ6q2TRnq/0AAiwtIpmCWCh6E4j4jvdrdXeQbVl6FpjiCsmUQQ6JaQ9dyrkeGKZ1JFgv8FS1R /LBOUFlnsZ5xHH2TZbEsU3UFSeKyxnRi3VwNhp4qiZeyAMNFtgh/RRKH8NezzizLsvM+ABW4KN1t 5Qc8uCWVcZbFMRJVxAf0VBW9PP+t7F/CMkqM5kX15DuXo8FUDlOafcPt5z1ZBPQxZ+RgZMkQ5mpc VObKh98yKlJwC9IQY9/4sSYzBlm2Gi+uALeaAVMIHKF5AMgUwfIoEBTGLnuwiYTdQmKQW4BEwB3J +QMgw3bFxXacbsDcsIxjxHv3aLWBTsMapr7RMC12Q63fQm14eNRenv/silvfhgSSWbFrQv2C9JOL AkyTVU7VbbsBpJKoTjCILA6aVh0I1/e8bgAdjnFOK3eOgXEw83QDpkkkNR81rPszTvFrM6GOg3HO oOMUXmeXQq1u241xILBaS9oxMG5odZzKD8c4twXNMTBu6HacqxvcKhRAw7o/42Bn0Eio42DcyOk4 hdfZ1YVxIKE2hOy7ulYpp01d6wyup/bAHqp1vauu9dwr68z1nEodwIPSulbr2v05r3Wt3Hu9sV3S uhb2sNt3klrXqi3nbrJN69p3GKd17auM07q2C+O0rm0xbkdd28/PSjd1resOpiPP21PX2pPJzW1/ ONW6Vp76bl9l9XltF85rXdvifH27pHXtq4zTurYL47SufYdxWte+yjita7swTuvaFuPauhZe5sNh KfzK7w7U+ezGie6dfDOff4BQvoaHmvKYt+am5O9Wt76UrtDqNrdBrpq3uuVfGpRu6qo+vbn4BwAA //8DAFBLAwQUAAYACAAAACEAJqNKsSACAAAvCAAAEgAAAHdvcmQvZm9udFRhYmxlLnhtbNSV246b MBCG7yv1HZDvuxiHHLXJKkuTy160W/XaISZYwjbykLB5+46BHLbxdhNpu1KDOOS3GYaPf8b3D8+q CHbCgjR6SqI7SgKhU7OWejMlP5+WX0YkgIrrNS+MFlOyF0AeZp8/3deTzOgKArxfw8ROSV5V5SQM Ic2F4nBnSqFxLDNW8Qr/2k1oskym4qtJt0roKmSUDkIrCl7hsyGXJZAuWn1NtNrYdWlNKgAwWVW0 8RSXmsy67IJ6ornCrH/s1coUjV5ybUBEOLTjxZTQPm4RZbgP6QDPfTokoQuQ5tyCqI4TWStnXMli f1CtUVy3A6Ws0vyg77iVfFWIdgjkBge2sKL4wO5HWiVC6C8VdjGn91JJmzijs7tQwTjHyJh+2H6e CxBPUgkIvok6+N5k7ib8SYQhhQHtIYkYd4ZXsZ8IfR8iC0yczZfLE5EEleEojjrlRGTcKV4izftH bZzriSRma6WwjonXHwx90aNj5OC8wZDJLTSUWQvrM0gmn8X60h2vsuh9BItfWEiu8sFLon8w2Ons 94W3Uvi2Mu30/6JQEl7IlZVeEIwuGys4S8RoDjz6QXgLBGoJcBOJhesQ7LxAYhTmyVG5qUDGTaFd XyBz7GT+1snoIzaKGN//sP1jDg6Dr1F8SHEkXKEh+CuOcK2ybZmudd7miNsXkbkrQbY4a5nOEZTG jxdtAhf0Zun5S8t80xHdagKz3wAAAP//AwBQSwMEFAAGAAgAAAAhAMTf8b6GAQAA0wIAABAACAFk b2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnJJBT+Mw EIXvSPsfotypk3ZBBU1drYrQHmCL1ABny54kFo5t2QbRf79jQkNWeyOnmTfOy5svhu37YIo3DFE7 uynrRVUWaKVT2nab8rG5PV+XRUzCKmGcxU15xFhu+Y8zeAjOY0gaY0EWNm7KPiV/zViUPQ4iLmhs adK6MIhEbeiYa1st8cbJ1wFtYsuqumT4ntAqVOd+MixHx+u39F1T5WTOF5+ao6fAHBocvBEJ+Z8c xyyUSwOwSYXGJWEaPSBfkTw18CA6jHwJbCzg2QUV+c96DWwsYdeLIGQigny5WpM+E+CX90ZLkQgu v9cyuOjaVOw/MBTZANj8CBCaA8rXoNORV8DmLdxpS1HqK2BjRdmC6ILwfeQXOeDUwUEKgzsCwFth IgL7EmDnBi/ske9vd/t7SvvZZvuX+Ogbd5Mxfb73rzjb9Vmn/uCFzHDWVT3fejaCA8FBRWucDL8E +E2/Jpj8VSJmO1SnM/8PMsen8Y7yermo6PkAd9Jo++ny8L8AAAD//wMAUEsBAi0AFAAGAAgAAAAh ADDJKAxyAQAApQUAABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAU AAYACAAAACEAHpEat/MAAABOAgAACwAAAAAAAAAAAAAAAACrAwAAX3JlbHMvLnJlbHNQSwECLQAU AAYACAAAACEAs76LHQkBAAC2AwAAHAAAAAAAAAAAAAAAAADPBgAAd29yZC9fcmVscy9kb2N1bWVu dC54bWwucmVsc1BLAQItABQABgAIAAAAIQDW5dX5nAwAAIqAAAARAAAAAAAAAAAAAAAAABoJAAB3 b3JkL2RvY3VtZW50LnhtbFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAAAAAAAAAAAAA AOUVAAB3b3JkL3RoZW1lL3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAKowdrFYDAAD2BwAAEQAA AAAAAAAAAAAAAACuHAAAd29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAStiKkrsAAAAE AQAAFAAAAAAAAAAAAAAAAAAzIAAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEA Fse1lDIHAAA/OgAADwAAAAAAAAAAAAAAAAAgIQAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgA AAAhAMekr+tHAQAAdwIAABEAAAAAAAAAAAAAAAAAfygAAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0A FAAGAAgAAAAhAMMkZl6ZAwAAwSMAABIAAAAAAAAAAAAAAAAA/SoAAHdvcmQvbnVtYmVyaW5nLnht bFBLAQItABQABgAIAAAAIQAmo0qxIAIAAC8IAAASAAAAAAAAAAAAAAAAAMYuAAB3b3JkL2ZvbnRU YWJsZS54bWxQSwECLQAUAAYACAAAACEAxN/xvoYBAADTAgAAEAAAAAAAAAAAAAAAAAAWMQAAZG9j UHJvcHMvYXBwLnhtbFBLBQYAAAAADAAMAAEDAADSMwAAAAA= --_002_5D3E853BEE49C848BB63047C794C8655AE96EF20WOKINTRAEXC02in_-- From brian.rosen@neustar.biz Tue Apr 16 07:18:38 2013 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 A9DFE21F973B for ; Tue, 16 Apr 2013 07:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbdATvGWCQKP for ; Tue, 16 Apr 2013 07:18:37 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7349021F96F2 for ; Tue, 16 Apr 2013 07:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1366122375; x=1681474822; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=P1g2p9iikO Tip/dasFMhJpuL+17aeGAQB8nBMkdAyDY=; b=jBnf0zbesg+B21rTYRgwhS+sM2 7Maet87cmwgzszq9OIoDHHoebXzhWoI5UW/mjJui4kJjBZMweseXj/hSOP/g== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.23329139; Tue, 16 Apr 2013 10:26:14 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 16 Apr 2013 10:18:32 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.77]) by stntexhc10.cis.neustar.com ([169.254.4.194]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 10:18:29 -0400 From: "Rosen, Brian" To: Cesar Gutierrez Thread-Topic: [paws] Device update function - ETSI/UK regulatory requirement Thread-Index: AQHOOq1Dj70aMRaErEOAKczmgaQrmw== Date: Tue, 16 Apr 2013 14:18:28 +0000 Message-ID: References: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.133.239] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 5YAD8z0GzLjjc09Iq3K8cw== Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , Reza Karimi , "johnny.dixon@bt.com" Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement 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, 16 Apr 2013 14:18:38 -0000 We already have the notion of an expiry time on the spectrum allocation. I= f you make that short (60 seconds), then the client has to come back to the= database to get a refresh. No further pull mechanism is needed. Its not = clear that doing something better helps a lot. The server has to get the l= ocation of the client and determine if any changes in spectrum have occurre= d. That's a full geospatial query, with some possibilities of maintaining = caches of recently changed curves. =20 A push is hard in many environments because NATs, firewalls and other middl= e boxes make it difficult to establish a connection from outside to inside.= We could maintain a very simple ping from client to server that just kept= the path open, and then use that to send the push notification. Maintaining pull mechanisms with circa 60 second timeouts is fine as long a= s the number of clients is small. A million clients on one server might wo= rk without this level of interactivity, with it and we're as much as two or= ders of magnitude less capacity. There are always problems like avalanche = restart due to power failures, so it's probably not really this bad, but it= 's a pretty big problem. Brian On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez = wrote: > All, >=20 > At the meeting in Orlando we discussed a device update function (or kill = switch, or PUSH). This arises from the UK regulatory requirement that a dat= abase should be able to contact any device within a short time. After revie= w of PAWS use case document with regards to this, I think our UK requiremen= t is neatly captured in requirement P.16 "The protocol MUST support the cap= ability for the database to inform master devices of changes to spectrum av= ailability information" >=20 > This requirement is already part of the current draft of the ETSI Harmoni= sed Standard. Its main elements are summarised below, and the full text is= attached: >=20 > +++++++++++ > DEFINITION > The master WSD update is the process by which a database informs a master= WSD that its operational parameters, and those of the slave WSDs attached = it, are still valid or are no longer valid > REQUIREMENTS > - A master WSD shall support WSD update function. For this, a master WSD= shall either > *be able to receive an update from the Controller Database WSDB wi= thin Tping seconds (push update), or > *send an update request to the Controller Database WSDB every Tpin= g seconds (pull update). > - A master WSD shall support a Tping value of [60] seconds or higher. > - A master WSD shall cease transmission, and shall instruct the slaves at= tached to it to cease transmission, if it receives update from the WSDB tha= t the operational parameters are no longer valid. > - A master WSD shall cease transmission, and shall instruct the slaves at= tached to it to cease transmission, if it loses connection with the WSDB > ++++++++++ >=20 > It is worth signalling that, at least among UK stakeholders, there is wid= e support for the pull method and little support for the push method. This = is consistent with the view that it will be very difficult to implement the= push functionality over the internet. >=20 > As a first step, I would like to ask the PAWS WG to consider support for = this functionality in the specification. Secondly, it would be good to have= views of how a pull mechanism could be implemented in the PAWS protocol. W= e have had early discussions about this off-line, and I think the alternati= ves are 1) to adapt one of the existing procedures (SPECTRUM_USE_NOTIFY and= "Device Validation" are possible candidates), and 2) create a new, dedicat= ed procedure. >=20 > Thanks and regards, > Cesar >=20 >=20 >=20 > ________________________________ >=20 > *************************************************************************= ***************************************** > For more information visit www.ofcom.org.uk >=20 > This email (and any attachments) is confidential and intended for the use= of the addressee only. >=20 > If you have received this email in error please notify the originator of = the message and delete it from your system. >=20 > This email has been scanned for viruses. However, you open any attachment= s at your own risk. >=20 > Any views expressed in this message are those of the individual sender an= d do not represent the views or opinions of Ofcom unless expressly stated o= therwise. > *************************************************************************= ***************************************** > _____________________________________= __________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Cesar.Gutierrez@ofcom.org.uk Tue Apr 16 07:54:23 2013 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 3C03A21F8DDD for ; Tue, 16 Apr 2013 07:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.098 X-Spam-Level: X-Spam-Status: No, score=-3.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=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 S9VoFR7SRAw2 for ; Tue, 16 Apr 2013 07:54:21 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.168]) by ietfa.amsl.com (Postfix) with ESMTP id A0D7F21F8E72 for ; Tue, 16 Apr 2013 07:54:18 -0700 (PDT) Received: from [85.158.138.51:9730] by server-8.bemta-3.messagelabs.com id 3A/9E-20604-9166D615; Tue, 16 Apr 2013 14:54:17 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-3.tower-174.messagelabs.com!1366123978!20448634!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11001 invoked from network); 16 Apr 2013 14:52:59 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-3.tower-174.messagelabs.com with AES128-SHA encrypted SMTP; 16 Apr 2013 14:52:59 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 16 Apr 2013 15:55:16 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([::1]) with mapi id 14.01.0289.001; Tue, 16 Apr 2013 15:55:17 +0100 From: Cesar Gutierrez To: "Rosen, Brian" Thread-Topic: [paws] Device update function - ETSI/UK regulatory requirement Thread-Index: Ac46hSC6Ps1OFLeIR9uE/BxoEtWBTwAH8E0AAAKT+DA= Date: Tue, 16 Apr 2013 14:55:16 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655AE96F11D@WOK-INTRA-EXC02.intra.ofcom.local> References: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , Reza Karimi , "johnny.dixon@bt.com" Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement 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, 16 Apr 2013 14:54:23 -0000 Brian, A "pull" update function should be light and simple in my view. No need to = provide location or device characteristics to the database, this procedure = assumes that none of this has changed. This is how I think it could work: 1) The master device sends its DeviceID - and nothing else - to the databas= e 2) The database looks up the IDs and finds out whether WS availability for = this master and its slaves has changed since the last update 3) If no change, the database replies an ACK. If change, the database repli= es a NACK (this could be enhanced to take individual slaves into account) I am fine if database operators prefer to implement this via expiry timer += full geospatial query, but it looks burdensome to me. The refresh time will be set by the database and communicated to the master= . The requirement in ETSI is that devices should be able to support the fun= ctionality with a refresh time of 60 seconds or higher. In practice, it is = unlikely to be that low under normal operating conditions. Thanks, Cesar -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: 16 April 2013 15:18 To: Cesar Gutierrez Cc: paws@ietf.org; Reza Karimi; johnny.dixon@bt.com Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement We already have the notion of an expiry time on the spectrum allocation. I= f you make that short (60 seconds), then the client has to come back to the= database to get a refresh. No further pull mechanism is needed. Its not = clear that doing something better helps a lot. The server has to get the l= ocation of the client and determine if any changes in spectrum have occurre= d. That's a full geospatial query, with some possibilities of maintaining = caches of recently changed curves. A push is hard in many environments because NATs, firewalls and other middl= e boxes make it difficult to establish a connection from outside to inside.= We could maintain a very simple ping from client to server that just kept= the path open, and then use that to send the push notification. Maintaining pull mechanisms with circa 60 second timeouts is fine as long a= s the number of clients is small. A million clients on one server might wo= rk without this level of interactivity, with it and we're as much as two or= ders of magnitude less capacity. There are always problems like avalanche = restart due to power failures, so it's probably not really this bad, but it= 's a pretty big problem. Brian On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez = wrote: > All, > > At the meeting in Orlando we discussed a device update function (or kill = switch, or PUSH). This arises from the UK regulatory requirement that a dat= abase should be able to contact any device within a short time. After revie= w of PAWS use case document with regards to this, I think our UK requiremen= t is neatly captured in requirement P.16 "The protocol MUST support the cap= ability for the database to inform master devices of changes to spectrum av= ailability information" > > This requirement is already part of the current draft of the ETSI Harmoni= sed Standard. Its main elements are summarised below, and the full text is= attached: > > +++++++++++ > DEFINITION > The master WSD update is the process by which a database informs a > master WSD that its operational parameters, and those of the slave > WSDs attached it, are still valid or are no longer valid REQUIREMENTS > - A master WSD shall support WSD update function. For this, a master WSD= shall either > *be able to receive an update from the Controller Database WSDB wi= thin Tping seconds (push update), or > *send an update request to the Controller Database WSDB every Tpin= g seconds (pull update). > - A master WSD shall support a Tping value of [60] seconds or higher. > - A master WSD shall cease transmission, and shall instruct the slaves at= tached to it to cease transmission, if it receives update from the WSDB tha= t the operational parameters are no longer valid. > - A master WSD shall cease transmission, and shall instruct the slaves > attached to it to cease transmission, if it loses connection with the > WSDB > ++++++++++ > > It is worth signalling that, at least among UK stakeholders, there is wid= e support for the pull method and little support for the push method. This = is consistent with the view that it will be very difficult to implement the= push functionality over the internet. > > As a first step, I would like to ask the PAWS WG to consider support for = this functionality in the specification. Secondly, it would be good to have= views of how a pull mechanism could be implemented in the PAWS protocol. W= e have had early discussions about this off-line, and I think the alternati= ves are 1) to adapt one of the existing procedures (SPECTRUM_USE_NOTIFY and= "Device Validation" are possible candidates), and 2) create a new, dedicat= ed procedure. > > Thanks and regards, > Cesar > > > > ________________________________ > > ********************************************************************** > ******************************************** > For more information visit www.ofcom.org.uk > > This email (and any attachments) is confidential and intended for the use= of the addressee only. > > If you have received this email in error please notify the originator of = the message and delete it from your system. > > This email has been scanned for viruses. However, you open any attachment= s at your own risk. > > Any views expressed in this message are those of the individual sender an= d do not represent the views or opinions of Ofcom unless expressly stated o= therwise. > ********************************************************************** > ******************************************** > __________________________________ > _____________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** From peter@spectrumbridge.com Tue Apr 16 08:22:21 2013 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 3146521F9748 for ; Tue, 16 Apr 2013 08:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54o9rB8V1EqV for ; Tue, 16 Apr 2013 08:22:20 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id CF5D921F8E94 for ; Tue, 16 Apr 2013 08:22:19 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Tue, 16 Apr 2013 11:22:18 -0400 From: Peter Stanforth To: "Rosen, Brian" Date: Tue, 16 Apr 2013 11:25:10 -0400 Thread-Topic: [paws] Device update function - ETSI/UK regulatory requirement Thread-Index: Ac46ti6h7USM4cJMRpWyg8nQGj5zVA== Message-ID: References: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> 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" , "johnny.dixon@bt.com" , Reza Karimi Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement 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, 16 Apr 2013 15:22:21 -0000 Brian Big difference between a simple "Am I ok?" and a reauthentication and chann= el request. The former could be very light weight and make DB processing a lot simpler On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" wrot= e: > We already have the notion of an expiry time on the spectrum allocation. = If you make that short (60 seconds), then the client has to come back to t= he database to get a refresh. No further pull mechanism is needed. Its no= t clear that doing something better helps a lot. The server has to get the= location of the client and determine if any changes in spectrum have occur= red. That's a full geospatial query, with some possibilities of maintainin= g caches of recently changed curves. =20 >=20 > A push is hard in many environments because NATs, firewalls and other mid= dle boxes make it difficult to establish a connection from outside to insid= e. We could maintain a very simple ping from client to server that just ke= pt the path open, and then use that to send the push notification. >=20 > Maintaining pull mechanisms with circa 60 second timeouts is fine as long= as the number of clients is small. A million clients on one server might = work without this level of interactivity, with it and we're as much as two = orders of magnitude less capacity. There are always problems like avalanch= e restart due to power failures, so it's probably not really this bad, but = it's a pretty big problem. >=20 > Brian > On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez wrote: >=20 >> All, >>=20 >> At the meeting in Orlando we discussed a device update function (or kill= switch, or PUSH). This arises from the UK regulatory requirement that a da= tabase should be able to contact any device within a short time. After revi= ew of PAWS use case document with regards to this, I think our UK requireme= nt is neatly captured in requirement P.16 "The protocol MUST support the ca= pability for the database to inform master devices of changes to spectrum a= vailability information" >>=20 >> This requirement is already part of the current draft of the ETSI Harmon= ised Standard. Its main elements are summarised below, and the full text i= s attached: >>=20 >> +++++++++++ >> DEFINITION >> The master WSD update is the process by which a database informs a maste= r WSD that its operational parameters, and those of the slave WSDs attached= it, are still valid or are no longer valid >> REQUIREMENTS >> - A master WSD shall support WSD update function. For this, a master WS= D shall either >> *be able to receive an update from the Controller Database WSDB wi= thin Tping seconds (push update), or >> *send an update request to the Controller Database WSDB every Tpin= g seconds (pull update). >> - A master WSD shall support a Tping value of [60] seconds or higher. >> - A master WSD shall cease transmission, and shall instruct the slaves a= ttached to it to cease transmission, if it receives update from the WSDB th= at the operational parameters are no longer valid. >> - A master WSD shall cease transmission, and shall instruct the slaves a= ttached to it to cease transmission, if it loses connection with the WSDB >> ++++++++++ >>=20 >> It is worth signalling that, at least among UK stakeholders, there is wi= de support for the pull method and little support for the push method. This= is consistent with the view that it will be very difficult to implement th= e push functionality over the internet. >>=20 >> As a first step, I would like to ask the PAWS WG to consider support for= this functionality in the specification. Secondly, it would be good to hav= e views of how a pull mechanism could be implemented in the PAWS protocol. = We have had early discussions about this off-line, and I think the alternat= ives are 1) to adapt one of the existing procedures (SPECTRUM_USE_NOTIFY an= d "Device Validation" are possible candidates), and 2) create a new, dedica= ted procedure. >>=20 >> Thanks and regards, >> Cesar >>=20 >>=20 >>=20 >> ________________________________ >>=20 >> ************************************************************************= ****************************************** >> For more information visit www.ofcom.org.uk >>=20 >> This email (and any attachments) is confidential and intended for the us= e of the addressee only. >>=20 >> If you have received this email in error please notify the originator of= the message and delete it from your system. >>=20 >> This email has been scanned for viruses. However, you open any attachmen= ts at your own risk. >>=20 >> Any views expressed in this message are those of the individual sender a= nd do not represent the views or opinions of Ofcom unless expressly stated = otherwise. >> ************************************************************************= ****************************************** >> ____________________________________= ___________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Tue Apr 16 08:29:06 2013 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 44B1121F9746 for ; Tue, 16 Apr 2013 08:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riFTgGbqdA+l for ; Tue, 16 Apr 2013 08:29:05 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id F0B8221F9721 for ; Tue, 16 Apr 2013 08:29:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1366126053; x=1681481421; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=X0XF4qRJfT nyedwt6MIzDdiNBVtPJ/76DkgZfBaeB5U=; b=iF2sMhEFJvk9qb0sTb/JqP+lNN H98I6Uw/WmmfRbKPdLihATORLWUvqFHS5hd83evqcna83gg9AikycVa6RkIw== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.18602724; Tue, 16 Apr 2013 11:27:31 -0400 Received: from STNTEXHC11.cis.neustar.com (10.31.58.70) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 16 Apr 2013 11:28:59 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.77]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Tue, 16 Apr 2013 11:28:55 -0400 From: "Rosen, Brian" To: Peter Stanforth Thread-Topic: [paws] Device update function - ETSI/UK regulatory requirement Thread-Index: AQHOOq1Dj70aMRaErEOAKczmgaQrm5jZOt0AgAABCwA= Date: Tue, 16 Apr 2013 15:28:55 +0000 Message-ID: References: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.133.239] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: idQ+UmHOXij+jo9c5jJpJg== Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , "johnny.dixon@bt.com" , Reza Karimi Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement 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, 16 Apr 2013 15:29:06 -0000 Not really. Use a cache. If nothing changed, reply so and move on. If it's really 60 seconds, then you are maintaining the SSL connection, so = you don't need a complete reauth. OTOH, if you are maintaining an SSL connection, then a push is pretty easy. Brian On Apr 16, 2013, at 11:25 AM, Peter Stanforth wrote: > Brian > Big difference between a simple "Am I ok?" and a reauthentication and cha= nnel request. > The former could be very light weight and make DB processing a lot simple= r >=20 > On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" wr= ote: >=20 >> We already have the notion of an expiry time on the spectrum allocation.= If you make that short (60 seconds), then the client has to come back to = the database to get a refresh. No further pull mechanism is needed. Its n= ot clear that doing something better helps a lot. The server has to get th= e location of the client and determine if any changes in spectrum have occu= rred. That's a full geospatial query, with some possibilities of maintaini= ng caches of recently changed curves. =20 >>=20 >> A push is hard in many environments because NATs, firewalls and other mi= ddle boxes make it difficult to establish a connection from outside to insi= de. We could maintain a very simple ping from client to server that just k= ept the path open, and then use that to send the push notification. >>=20 >> Maintaining pull mechanisms with circa 60 second timeouts is fine as lon= g as the number of clients is small. A million clients on one server might= work without this level of interactivity, with it and we're as much as two= orders of magnitude less capacity. There are always problems like avalanc= he restart due to power failures, so it's probably not really this bad, but= it's a pretty big problem. >>=20 >> Brian >> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez wrote: >>=20 >>> All, >>>=20 >>> At the meeting in Orlando we discussed a device update function (or kil= l switch, or PUSH). This arises from the UK regulatory requirement that a d= atabase should be able to contact any device within a short time. After rev= iew of PAWS use case document with regards to this, I think our UK requirem= ent is neatly captured in requirement P.16 "The protocol MUST support the c= apability for the database to inform master devices of changes to spectrum = availability information" >>>=20 >>> This requirement is already part of the current draft of the ETSI Harmo= nised Standard. Its main elements are summarised below, and the full text = is attached: >>>=20 >>> +++++++++++ >>> DEFINITION >>> The master WSD update is the process by which a database informs a mast= er WSD that its operational parameters, and those of the slave WSDs attache= d it, are still valid or are no longer valid >>> REQUIREMENTS >>> - A master WSD shall support WSD update function. For this, a master W= SD shall either >>> *be able to receive an update from the Controller Database WSDB wi= thin Tping seconds (push update), or >>> *send an update request to the Controller Database WSDB every Tpin= g seconds (pull update). >>> - A master WSD shall support a Tping value of [60] seconds or higher. >>> - A master WSD shall cease transmission, and shall instruct the slaves = attached to it to cease transmission, if it receives update from the WSDB t= hat the operational parameters are no longer valid. >>> - A master WSD shall cease transmission, and shall instruct the slaves = attached to it to cease transmission, if it loses connection with the WSDB >>> ++++++++++ >>>=20 >>> It is worth signalling that, at least among UK stakeholders, there is w= ide support for the pull method and little support for the push method. Thi= s is consistent with the view that it will be very difficult to implement t= he push functionality over the internet. >>>=20 >>> As a first step, I would like to ask the PAWS WG to consider support fo= r this functionality in the specification. Secondly, it would be good to ha= ve views of how a pull mechanism could be implemented in the PAWS protocol.= We have had early discussions about this off-line, and I think the alterna= tives are 1) to adapt one of the existing procedures (SPECTRUM_USE_NOTIFY a= nd "Device Validation" are possible candidates), and 2) create a new, dedic= ated procedure. >>>=20 >>> Thanks and regards, >>> Cesar >>>=20 >>>=20 >>>=20 >>> ________________________________ >>>=20 >>> ***********************************************************************= ******************************************* >>> For more information visit www.ofcom.org.uk >>>=20 >>> This email (and any attachments) is confidential and intended for the u= se of the addressee only. >>>=20 >>> If you have received this email in error please notify the originator o= f the message and delete it from your system. >>>=20 >>> This email has been scanned for viruses. However, you open any attachme= nts at your own risk. >>>=20 >>> Any views expressed in this message are those of the individual sender = and do not represent the views or opinions of Ofcom unless expressly stated= otherwise. >>> ***********************************************************************= ******************************************* >>> ___________________________________= ____________ >>> 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 vchen@google.com Wed Apr 17 15:36:39 2013 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 12AEE21E80E4 for ; Wed, 17 Apr 2013 15:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 vFxQNSObY5D5 for ; Wed, 17 Apr 2013 15:36:37 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2156121E80E1 for ; Wed, 17 Apr 2013 15:36:36 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id m1so1630760wea.13 for ; Wed, 17 Apr 2013 15:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NBzKm4RiOs+tQQCCT4/1Sswd0EkMzRJirgmH9KHvqdw=; b=V33xVo4CSKivVm887y/Fn0n+gkYlB/0YTCeanorpKOfA40reQXl1t3eqpYRGMtokzn 6q2+1mTeEPlk0DHydHtwB3DBhZlLJ1whDhim00S2o6VHHVuoMerRi2mQ3EkPf1p4/QnH DvVPUsTHxcMbBpImf+5RnhiCOMuTHXNV1mlcmjbY6np8x4XG3ykpccgtj1sR5PFdKhr1 +dPywR5OfmHasyE8/mCmnX0xY3WSZmi/V4bEWnaOVPHT+erItKEtGGdwmwWxPxzWBiAD 6rcJ6GBcmwFceb2i9WxaxoHYH/5WzZrgR2fYMZdl5hHxMzIyNXpPAVbPBoyqK5eX6nZR kOYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=NBzKm4RiOs+tQQCCT4/1Sswd0EkMzRJirgmH9KHvqdw=; b=T8vzx+CArqbWLhZRPEzKfCs3n299XGdoJVfxhrb9OAUpg6NYQwco8ovWGEIEixuwJU uVXcCWnsCfGqFJjlJnbB1fRmFnfOxV4Iy3nMU1z2Vhzc83oU1uvU9JU/h/dGoX5Ske/Z vC69TSa9zZKiqE4jtRmYB1Z+Oho1P/PhckGEX9+8xJsHdkuT3dKZSt52AKqP+X/3wSzR wGiUTYSwVwpt67R++O83L9W5jtMDNHNmMpC2P+O3RL30octJ4CA+04lmRBs/CI2fiKxS D405QTDfI2vWojuIR6AzY9PfBy1XaSxtUvGvqrxs5VaLbYQQ6dafBJPw+/DirQwXW9LA AReQ== MIME-Version: 1.0 X-Received: by 10.180.39.207 with SMTP id r15mr14161134wik.16.1366238195936; Wed, 17 Apr 2013 15:36:35 -0700 (PDT) Received: by 10.194.104.200 with HTTP; Wed, 17 Apr 2013 15:36:35 -0700 (PDT) In-Reply-To: References: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> Date: Wed, 17 Apr 2013 15:36:35 -0700 Message-ID: From: Vincent Chen To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=001a11c23f3059035504da961e25 X-Gm-Message-State: ALoCoQlZ4BnpVjcD25DWudGVRWahnLi8L0I7a8V3sosO5CEmqqNbcsYw3qDcaz6CgucjRCC/th0tXYQZUXNKvdgLft26RGmPGXTTxQjR4pYNbBzq+mS//1DFBT9QwCXYVcUbopeqfVoetqri+a5vtgnN7TT1+q17fhezLo+2gF/57Ne8VTGTsEdMMVpMTDo7iLO294UcknRz Cc: "paws@ietf.org" , "johnny.dixon@bt.com" , Reza Karimi Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement 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, 17 Apr 2013 22:36:39 -0000 --001a11c23f3059035504da961e25 Content-Type: text/plain; charset=ISO-8859-1 All, For scalability and redundancy reasons, a "stateless" system is much preferred. That means not having answers depend on priory history of queries. This allows running many server instances to service requests. It also means that each request can go to any serving machine. There also may be reasons why caching might not work: - The answer is not totally dependent on only the device characteristics. In the US, for example, there are dynamic registrations, so the Database might have to run through most of the computation anyways to determine whether anything has changed. - For devices that use GPS, the location might jitter just a bit from time to time, so the difference might cause cache misses To keep the API simple, I wouldn't recommend adding another call when the existing one already works. ---------------------- Query Volume ---------------------- As for the polling period. I think we should look at what this actually means: - At 60-seconds polling period for only 1 million devices.....that's almost 1.5 Billion queries per day! Note that a large search engine like Baidu only handles 5B queries per day. So....I would be very cautious about trying to set the polling period too low. It would be requiring a significant amount of resources to provide a capability that would be used rarely, perhaps 0.001% of the time (once a month)? At the F2F, there was a suggestion that actual management could be a staged process, e.g., - By default the required update period is 1 or 2 hours - When needed, the update period for devices within a specified geographic region could be lowered to 60 seconds, allowing investigation - When investigation is complete (and/or after a timeout), update period is reset to default This seems more reasonable to me (IMHO), and the current proposed protocol with expiry will handle this just fine, I think. -vince On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian wrote: > Not really. Use a cache. If nothing changed, reply so and move on. > > If it's really 60 seconds, then you are maintaining the SSL connection, so > you don't need a complete reauth. > OTOH, if you are maintaining an SSL connection, then a push is pretty easy. > > Brian > > On Apr 16, 2013, at 11:25 AM, Peter Stanforth > wrote: > > > Brian > > Big difference between a simple "Am I ok?" and a reauthentication and > channel request. > > The former could be very light weight and make DB processing a lot > simpler > > > > On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" > wrote: > > > >> We already have the notion of an expiry time on the spectrum > allocation. If you make that short (60 seconds), then the client has to > come back to the database to get a refresh. No further pull mechanism is > needed. Its not clear that doing something better helps a lot. The server > has to get the location of the client and determine if any changes in > spectrum have occurred. That's a full geospatial query, with some > possibilities of maintaining caches of recently changed curves. > >> > >> A push is hard in many environments because NATs, firewalls and other > middle boxes make it difficult to establish a connection from outside to > inside. We could maintain a very simple ping from client to server that > just kept the path open, and then use that to send the push notification. > >> > >> Maintaining pull mechanisms with circa 60 second timeouts is fine as > long as the number of clients is small. A million clients on one server > might work without this level of interactivity, with it and we're as much > as two orders of magnitude less capacity. There are always problems like > avalanche restart due to power failures, so it's probably not really this > bad, but it's a pretty big problem. > >> > >> Brian > >> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez < > Cesar.Gutierrez@ofcom.org.uk> wrote: > >> > >>> All, > >>> > >>> At the meeting in Orlando we discussed a device update function (or > kill switch, or PUSH). This arises from the UK regulatory requirement that > a database should be able to contact any device within a short time. After > review of PAWS use case document with regards to this, I think our UK > requirement is neatly captured in requirement P.16 "The protocol MUST > support the capability for the database to inform master devices of changes > to spectrum availability information" > >>> > >>> This requirement is already part of the current draft of the ETSI > Harmonised Standard. Its main elements are summarised below, and the full > text is attached: > >>> > >>> +++++++++++ > >>> DEFINITION > >>> The master WSD update is the process by which a database informs a > master WSD that its operational parameters, and those of the slave WSDs > attached it, are still valid or are no longer valid > >>> REQUIREMENTS > >>> - A master WSD shall support WSD update function. For this, a master > WSD shall either > >>> *be able to receive an update from the Controller Database WSDB > within Tping seconds (push update), or > >>> *send an update request to the Controller Database WSDB every > Tping seconds (pull update). > >>> - A master WSD shall support a Tping value of [60] seconds or higher. > >>> - A master WSD shall cease transmission, and shall instruct the slaves > attached to it to cease transmission, if it receives update from the WSDB > that the operational parameters are no longer valid. > >>> - A master WSD shall cease transmission, and shall instruct the slaves > attached to it to cease transmission, if it loses connection with the WSDB > >>> ++++++++++ > >>> > >>> It is worth signalling that, at least among UK stakeholders, there is > wide support for the pull method and little support for the push method. > This is consistent with the view that it will be very difficult to > implement the push functionality over the internet. > >>> > >>> As a first step, I would like to ask the PAWS WG to consider support > for this functionality in the specification. Secondly, it would be good to > have views of how a pull mechanism could be implemented in the PAWS > protocol. We have had early discussions about this off-line, and I think > the alternatives are 1) to adapt one of the existing procedures > (SPECTRUM_USE_NOTIFY and "Device Validation" are possible candidates), and > 2) create a new, dedicated procedure. > >>> > >>> Thanks and regards, > >>> Cesar > >>> > >>> > >>> > >>> ________________________________ > >>> > >>> > ****************************************************************************************************************** > >>> For more information visit www.ofcom.org.uk > >>> > >>> This email (and any attachments) is confidential and intended for the > use of the addressee only. > >>> > >>> If you have received this email in error please notify the originator > of the message and delete it from your system. > >>> > >>> This email has been scanned for viruses. However, you open any > attachments at your own risk. > >>> > >>> Any views expressed in this message are those of the individual sender > and do not represent the views or opinions of Ofcom unless expressly stated > otherwise. > >>> > ****************************************************************************************************************** > >>> > _______________________________________________ > >>> 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 > -- -vince --001a11c23f3059035504da961e25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

For scalability and redundan= cy reasons, a "stateless" system is much preferred. That means no= t having answers depend on priory history of queries.
This = allows running many server instances to service requests. It also means tha= t each request can go to any serving machine.

There also may be reasons why caching might= not work:

=A0- The answer is not tota= lly dependent on only the device characteristics. In the US, for example, t= here are dynamic registrations,
=A0 =A0so the Database might have to run through most of the com= putation anyways to determine whether anything has changed.

=A0- For devices that use GPS, the location might jitte= r just a bit from time to time, so the difference might cause cache misses<= /div>

To keep the API simple, I wouldn't recommend = adding another call when the existing one already works.
----------------------
Query Volume
----------------------
As for the polling period= . I think we should look at what this actually means:

<= /div>
=A0 - At 60-seconds polling period for only 1 million devic= es.....that's almost 1.5 Billion queries per day!

Note that a large search engine like Baidu = only handles 5B queries per day.

So...= .I would be very cautious about trying to set the polling period too low. I= t would be requiring a significant amount of resources to provide
a capability that would be used rarely, perhaps 0.001% of the ti= me (once a month)?

At the F2F, there w= as a suggestion that actual management could be a staged process, e.g.,
=A0 - By default the required update period is 1 or 2 hours
=A0 - When needed, the update period for devices within a speci= fied geographic region could be lowered to 60 seconds,
=A0 = =A0 allowing investigation
=A0 - When investigation is complete (and/or after a timeout), u= pdate period is reset to default

This = seems more reasonable to me (IMHO), and the current proposed protocol with = expiry will handle this just fine, I think.

-vince


On Tue, Apr 16, 2013 at 8:28 AM, Rosen= , Brian <Brian.Rosen@neustar.biz> wrote:
Not really. =A0Use a cache. =A0If nothing ch= anged, reply so and move on.

If it's really 60 seconds, then you are maintaining the SSL connection,= so you don't need a complete reauth.
OTOH, if you are maintaining an SSL connection, then a push is pretty easy.=

Brian

On Apr 16, 2013, at 11:25 AM, Peter Stanforth <peter@spectrumbridge.com>
=A0wrote:

> Brian
> Big difference between a simple "Am I ok?" and a reauthentic= ation and channel request.
> The former could be very light weight and make DB processing a lot sim= pler
>
> On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:
>
>> We already have the notion of an expiry time on the spectrum alloc= ation. =A0If you make that short (60 seconds), then the client has to come = back to the database to get a refresh. =A0No further pull mechanism is need= ed. =A0Its not clear that doing something better helps a lot. =A0The server= has to get the location of the client and determine if any changes in spec= trum have occurred. =A0That's a full geospatial query, with some possib= ilities of maintaining caches of recently changed curves.
>>
>> A push is hard in many environments because NATs, firewalls and ot= her middle boxes make it difficult to establish a connection from outside t= o inside. =A0We could maintain a very simple ping from client to server tha= t just kept the path open, and then use that to send the push notification.=
>>
>> Maintaining pull mechanisms with circa 60 second timeouts is fine = as long as the number of clients is small. =A0A million clients on one serv= er might work without this level of interactivity, with it and we're as= much as two orders of magnitude less capacity. =A0There are always problem= s like avalanche restart due to power failures, so it's probably not re= ally this bad, but it's a pretty big problem.
>>
>> Brian
>> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.uk> wrote:<= br> >>
>>> All,
>>>
>>> At the meeting in Orlando we discussed a device update functio= n (or kill switch, or PUSH). This arises from the UK regulatory requirement= that a database should be able to contact any device within a short time. = After review of PAWS use case document with regards to this, I think our UK= requirement is neatly captured in requirement P.16 "The protocol MUST= support the capability for the database to inform master devices of change= s to spectrum availability information"
>>>
>>> This requirement is already part of the current draft of the E= TSI Harmonised Standard. =A0Its main elements are summarised below, and the= full text is attached:
>>>
>>> +++++++++++
>>> DEFINITION
>>> The master WSD update is the process by which a database infor= ms a master WSD that its operational parameters, and those of the slave WSD= s attached it, are still valid or are no longer valid
>>> REQUIREMENTS
>>> - A master WSD shall support WSD update function. =A0For this,= a master WSD shall either
>>> =A0 =A0 =A0*be able to receive an update from the Controller D= atabase WSDB within Tping seconds (push update), or
>>> =A0 =A0 =A0*send an update request to the Controller Database = WSDB every Tping seconds (pull update).
>>> - A master WSD shall support a Tping value of [60] seconds or = higher.
>>> - A master WSD shall cease transmission, and shall instruct th= e slaves attached to it to cease transmission, if it receives update from t= he WSDB that the operational parameters are no longer valid.
>>> - A master WSD shall cease transmission, and shall instruct th= e slaves attached to it to cease transmission, if it loses connection with = the WSDB
>>> ++++++++++
>>>
>>> It is worth signalling that, at least among UK stakeholders, t= here is wide support for the pull method and little support for the push me= thod. This is consistent with the view that it will be very difficult to im= plement the push functionality over the internet.
>>>
>>> As a first step, I would like to ask the PAWS WG to consider s= upport for this functionality in the specification. Secondly, it would be g= ood to have views of how a pull mechanism could be implemented in the PAWS = protocol. We have had early discussions about this off-line, and I think th= e alternatives are 1) to adapt one of the existing procedures (SPECTRUM_USE= _NOTIFY and "Device Validation" are possible candidates), and 2) = create a new, dedicated procedure.
>>>
>>> Thanks and regards,
>>> Cesar
>>>
>>>
>>>
>>> ________________________________
>>>
>>> **************************************************************= ****************************************************
>>> For more information visit www.ofcom.org.uk
>>>
>>> This email (and any attachments) is confidential and intended = for the use of the addressee only.
>>>
>>> If you have received this email in error please notify the ori= ginator of the message and delete it from your system.
>>>
>>> This email has been scanned for viruses. However, you open any= attachments at your own risk.
>>>
>>> Any views expressed in this message are those of the individua= l sender and do not represent the views or opinions of Ofcom unless express= ly stated otherwise.
>>> **************************************************************= ****************************************************
>>> <EN301598v0018_MasterWSDupdate.docx>____________________= ___________________________
>>> 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



--
= -vince
--001a11c23f3059035504da961e25-- From brian.rosen@neustar.biz Thu Apr 18 05:51:43 2013 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 1F7B021F8EBD for ; Thu, 18 Apr 2013 05:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 onrGKvG+h3vC for ; Thu, 18 Apr 2013 05:51:41 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E4C0521F8EAA for ; Thu, 18 Apr 2013 05:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1366289959; x=1681644250; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=S5h8WOvRRfmuha71qp+2W3BEOMQAu6Pgb9pg81oBqBI=; b=pgUCAsHiWJQn5B54mRKlUN/fpco/hjaLODcY2TFS1zgLvV6YZ0Fk9xjJT7MJmX QSVGWcc+qWeqTQqkZg4y0G/w== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.23432952; Thu, 18 Apr 2013 08:59:18 -0400 Received: from STNTEXHC12.cis.neustar.com (10.31.58.71) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 18 Apr 2013 08:51:34 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.77]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Thu, 18 Apr 2013 08:51:33 -0400 From: "Rosen, Brian" To: Vincent Chen Thread-Topic: [paws] Device update function - ETSI/UK regulatory requirement Thread-Index: AQHOOq1Dj70aMRaErEOAKczmgaQrm5jZOt0AgAABCwCAAgnTgIAA7t8A Date: Thu, 18 Apr 2013 12:51:32 +0000 Message-ID: <50D39A6B-A778-492F-B605-D4B29D0BEACA@neustar.biz> References: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.184.73] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: odAaBzXTDIEA5yulHBxt9g== Content-Type: multipart/alternative; boundary="_000_50D39A6BA778492FB605D4B29D0BEACAneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" , "johnny.dixon@bt.com" , Reza Karimi Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement 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, 18 Apr 2013 12:51:43 -0000 --_000_50D39A6BA778492FB605D4B29D0BEACAneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But you can't really do "stateless" and have registration. That's state. = You can't serve an unregistered device. Slowly changing state, but then ag= ain, most location is slowly changing (mobile devices on the move excepted)= . I agree that maintaining 60 second polling is very challenging, and I agree= the mechanism we discussed of having a much longer period and temporarily = lowering the period when needed is an appropriate mechanism. I will remin= d everyone that if a device is moving, a faster poll is needed due to the m= otion (every hour, or when you move more than x meters). This affects the proposed rules. Brian On Apr 17, 2013, at 6:36 PM, Vincent Chen > wrote: All, For scalability and redundancy reasons, a "stateless" system is much prefer= red. That means not having answers depend on priory history of queries. This allows running many server instances to service requests. It also mean= s that each request can go to any serving machine. There also may be reasons why caching might not work: - The answer is not totally dependent on only the device characteristics. = In the US, for example, there are dynamic registrations, so the Database might have to run through most of the computation anyway= s to determine whether anything has changed. - For devices that use GPS, the location might jitter just a bit from time= to time, so the difference might cause cache misses To keep the API simple, I wouldn't recommend adding another call when the e= xisting one already works. ---------------------- Query Volume ---------------------- As for the polling period. I think we should look at what this actually mea= ns: - At 60-seconds polling period for only 1 million devices.....that's almo= st 1.5 Billion queries per day! Note that a large search engine like Baidu only handles 5B queries per day. So....I would be very cautious about trying to set the polling period too l= ow. It would be requiring a significant amount of resources to provide a capability that would be used rarely, perhaps 0.001% of the time (once a = month)? At the F2F, there was a suggestion that actual management could be a staged= process, e.g., - By default the required update period is 1 or 2 hours - When needed, the update period for devices within a specified geographi= c region could be lowered to 60 seconds, allowing investigation - When investigation is complete (and/or after a timeout), update period = is reset to default This seems more reasonable to me (IMHO), and the current proposed protocol = with expiry will handle this just fine, I think. -vince On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian > wrote: Not really. Use a cache. If nothing changed, reply so and move on. If it's really 60 seconds, then you are maintaining the SSL connection, so = you don't need a complete reauth. OTOH, if you are maintaining an SSL connection, then a push is pretty easy. Brian On Apr 16, 2013, at 11:25 AM, Peter Stanforth > wrote: > Brian > Big difference between a simple "Am I ok?" and a reauthentication and cha= nnel request. > The former could be very light weight and make DB processing a lot simple= r > > On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" > wrote: > >> We already have the notion of an expiry time on the spectrum allocation.= If you make that short (60 seconds), then the client has to come back to = the database to get a refresh. No further pull mechanism is needed. Its n= ot clear that doing something better helps a lot. The server has to get th= e location of the client and determine if any changes in spectrum have occu= rred. That's a full geospatial query, with some possibilities of maintaini= ng caches of recently changed curves. >> >> A push is hard in many environments because NATs, firewalls and other mi= ddle boxes make it difficult to establish a connection from outside to insi= de. We could maintain a very simple ping from client to server that just k= ept the path open, and then use that to send the push notification. >> >> Maintaining pull mechanisms with circa 60 second timeouts is fine as lon= g as the number of clients is small. A million clients on one server might= work without this level of interactivity, with it and we're as much as two= orders of magnitude less capacity. There are always problems like avalanc= he restart due to power failures, so it's probably not really this bad, but= it's a pretty big problem. >> >> Brian >> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez > wrote: >> >>> All, >>> >>> At the meeting in Orlando we discussed a device update function (or kil= l switch, or PUSH). This arises from the UK regulatory requirement that a d= atabase should be able to contact any device within a short time. After rev= iew of PAWS use case document with regards to this, I think our UK requirem= ent is neatly captured in requirement P.16 "The protocol MUST support the c= apability for the database to inform master devices of changes to spectrum = availability information" >>> >>> This requirement is already part of the current draft of the ETSI Harmo= nised Standard. Its main elements are summarised below, and the full text = is attached: >>> >>> +++++++++++ >>> DEFINITION >>> The master WSD update is the process by which a database informs a mast= er WSD that its operational parameters, and those of the slave WSDs attache= d it, are still valid or are no longer valid >>> REQUIREMENTS >>> - A master WSD shall support WSD update function. For this, a master W= SD shall either >>> *be able to receive an update from the Controller Database WSDB wi= thin Tping seconds (push update), or >>> *send an update request to the Controller Database WSDB every Tpin= g seconds (pull update). >>> - A master WSD shall support a Tping value of [60] seconds or higher. >>> - A master WSD shall cease transmission, and shall instruct the slaves = attached to it to cease transmission, if it receives update from the WSDB t= hat the operational parameters are no longer valid. >>> - A master WSD shall cease transmission, and shall instruct the slaves = attached to it to cease transmission, if it loses connection with the WSDB >>> ++++++++++ >>> >>> It is worth signalling that, at least among UK stakeholders, there is w= ide support for the pull method and little support for the push method. Thi= s is consistent with the view that it will be very difficult to implement t= he push functionality over the internet. >>> >>> As a first step, I would like to ask the PAWS WG to consider support fo= r this functionality in the specification. Secondly, it would be good to ha= ve views of how a pull mechanism could be implemented in the PAWS protocol.= We have had early discussions about this off-line, and I think the alterna= tives are 1) to adapt one of the existing procedures (SPECTRUM_USE_NOTIFY a= nd "Device Validation" are possible candidates), and 2) create a new, dedic= ated procedure. >>> >>> Thanks and regards, >>> Cesar >>> >>> >>> >>> ________________________________ >>> >>> ***********************************************************************= ******************************************* >>> For more information visit www.ofcom.org.uk >>> >>> This email (and any attachments) is confidential and intended for the u= se of the addressee only. >>> >>> If you have received this email in error please notify the originator o= f the message and delete it from your system. >>> >>> This email has been scanned for viruses. However, you open any attachme= nts at your own risk. >>> >>> Any views expressed in this message are those of the individual sender = and do not represent the views or opinions of Ofcom unless expressly stated= otherwise. >>> ***********************************************************************= ******************************************* >>> ___________________________________= ____________ >>> 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 -- -vince --_000_50D39A6BA778492FB605D4B29D0BEACAneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0E498CD0CAC3DD4CBC91FB317735064E@neustar.biz> Content-Transfer-Encoding: quoted-printable But you can't really do "stateless" and have registration.  = That's state.  You can't serve an unregistered device.  Slowly ch= anging state, but then again, most location is slowly changing (mobile devi= ces on the move excepted).

I agree that maintaining 60 second polling is very challenging, and I = agree the mechanism we discussed of having a much longer period and tempora= rily lowering the period when needed is an appropriate mechanism.   I = will remind everyone that if a device is moving, a faster poll is needed due to the motion (every hour, or when = you move more than x meters).

This affects the proposed rules.

Brian

On Apr 17, 2013, at 6:36 PM, Vincent Chen <vchen@google.com>
 wrote:

All,

For scalability and redundancy reasons, a "stateless&q= uot; system is much preferred. That means not having answers depend on prio= ry history of queries.
This allows running many server instances to service reques= ts. It also means that each request can go to any serving machine.

There also may be reasons why caching might not work:

 - The answer is not totally dependent on only the dev= ice characteristics. In the US, for example, there are dynamic registration= s,
   so the Database might have to run through most= of the computation anyways to determine whether anything has changed.

 - For devices that use GPS, the location might jitter just a bit= from time to time, so the difference might cause cache misses

To keep the API simple, I wouldn't recommend adding another= call when the existing one already works.

----------------------
Query Volume
----------------------
As for the polling period. I think we should look at what t= his actually means:

  - At 60-seconds polling period for only 1 million de= vices.....that's almost 1.5 Billion queries per day!

Note that a large search engine like Baidu only handles 5B = queries per day.

So....I would be very cautious about trying to set the poll= ing period too low. It would be requiring a significant amount of resources= to provide
a capability that would be used rarely, perhaps 0.001% of t= he time (once a month)?

At the F2F, there was a suggestion that actual management c= ould be a staged process, e.g.,
  - By default the required update period is 1 or 2 ho= urs
  - When needed, the update period for devices within = a specified geographic region could be lowered to 60 seconds,
    allowing investigation
  - When investigation is complete (and/or after a tim= eout), update period is reset to default

This seems more reasonable to me (IMHO), and the current pr= oposed protocol with expiry will handle this just fine, I think.

-vince


On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
Not really.  Use a cache.  If nothing changed, reply so and move = on.

If it's really 60 seconds, then you are maintaining the SSL connection, so = you don't need a complete reauth.
OTOH, if you are maintaining an SSL connection, then a push is pretty easy.=

Brian

On Apr 16, 2013, at 11:25 AM, Peter Stanforth <peter@spectrumbridge.com>
 wrote:

> Brian
> Big difference between a simple "Am I ok?" and a reauthentic= ation and channel request.
> The former could be very light weight and make DB processing a lot sim= pler
>
> On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:
>
>> We already have the notion of an expiry time on the spectrum alloc= ation.  If you make that short (60 seconds), then the client has to co= me back to the database to get a refresh.  No further pull mechanism i= s needed.  Its not clear that doing something better helps a lot.  The server has to get the location of the client and de= termine if any changes in spectrum have occurred.  That's a full geosp= atial query, with some possibilities of maintaining caches of recently chan= ged curves.
>>
>> A push is hard in many environments because NATs, firewalls and ot= her middle boxes make it difficult to establish a connection from outside t= o inside.  We could maintain a very simple ping from client to server = that just kept the path open, and then use that to send the push notification.
>>
>> Maintaining pull mechanisms with circa 60 second timeouts is fine = as long as the number of clients is small.  A million clients on one s= erver might work without this level of interactivity, with it and we're as = much as two orders of magnitude less capacity.  There are always problems like avalanche restart due to power failur= es, so it's probably not really this bad, but it's a pretty big problem. >>
>> Brian
>> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.uk> wrote:<= br> >>
>>> All,
>>>
>>> At the meeting in Orlando we discussed a device update functio= n (or kill switch, or PUSH). This arises from the UK regulatory requirement= that a database should be able to contact any device within a short time. = After review of PAWS use case document with regards to this, I think our UK requirement is neatly captured in requirem= ent P.16 "The protocol MUST support the capability for the database to= inform master devices of changes to spectrum availability information"= ;
>>>
>>> This requirement is already part of the current draft of the E= TSI Harmonised Standard.  Its main elements are summarised below, and = the full text is attached:
>>>
>>> +++++++++++
>>> DEFINITION
>>> The master WSD update is the process by which a database infor= ms a master WSD that its operational parameters, and those of the slave WSD= s attached it, are still valid or are no longer valid
>>> REQUIREMENTS
>>> - A master WSD shall support WSD update function.  For th= is, a master WSD shall either
>>>      *be able to receive an update from the Con= troller Database WSDB within Tping seconds (push update), or
>>>      *send an update request to the Controller = Database WSDB every Tping seconds (pull update).
>>> - A master WSD shall support a Tping value of [60] seconds or = higher.
>>> - A master WSD shall cease transmission, and shall instruct th= e slaves attached to it to cease transmission, if it receives update from t= he WSDB that the operational parameters are no longer valid.
>>> - A master WSD shall cease transmission, and shall instruct th= e slaves attached to it to cease transmission, if it loses connection with = the WSDB
>>> ++++++++++
>>>
>>> It is worth signalling that, at least among UK stakeholders, t= here is wide support for the pull method and little support for the push me= thod. This is consistent with the view that it will be very difficult to im= plement the push functionality over the internet.
>>>
>>> As a first step, I would like to ask the PAWS WG to consider s= upport for this functionality in the specification. Secondly, it would be g= ood to have views of how a pull mechanism could be implemented in the PAWS = protocol. We have had early discussions about this off-line, and I think the alternatives are 1) to adapt one of the exi= sting procedures (SPECTRUM_USE_NOTIFY and "Device Validation" are= possible candidates), and 2) create a new, dedicated procedure.
>>>
>>> Thanks and regards,
>>> Cesar
>>>
>>>
>>>
>>> ________________________________
>>>
>>> **************************************************************= ****************************************************
>>> For more information visit www.ofcom.org.uk
>>>
>>> This email (and any attachments) is confidential and intended = for the use of the addressee only.
>>>
>>> If you have received this email in error please notify the ori= ginator of the message and delete it from your system.
>>>
>>> This email has been scanned for viruses. However, you open any= attachments at your own risk.
>>>
>>> Any views expressed in this message are those of the individua= l sender and do not represent the views or opinions of Ofcom unless express= ly stated otherwise.
>>> **************************************************************= ****************************************************
>>> <EN301598v0018_MasterWSDupdate.docx>____________________= ___________________________
>>> 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



--
-vince

--_000_50D39A6BA778492FB605D4B29D0BEACAneustarbiz_-- From vchen@google.com Thu Apr 18 07:12:04 2013 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 CE5FF21F8EBF for ; Thu, 18 Apr 2013 07:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, 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 R15ciDlFAYLS for ; Thu, 18 Apr 2013 07:12:03 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id E1C6221F8E67 for ; Thu, 18 Apr 2013 07:12:02 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id r5so2266531wey.25 for ; Thu, 18 Apr 2013 07:12:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Ovw6W/6wtc7xTiPYYQ09Vcdj3+fOaIiHUeb8UborkHk=; b=a2NoTAQ/icjbGuuYBOPrU0qy8c/npEv7QfR9JKA/CIvmAs9Gr15qJaZ+nwPBoI0gQB zJX7Udv82exFwUfBKadvrj2LkDk/vZoJ4OLyfueQF+CL/6ga+wO4LmgI/0eTreil/CiT hPDNTv26Nm+eBkvjUhYydJpnmIL+DvbgKWc8sPaNNXdx+26/f41pCPhtS5MZN4s7V66F kxdUAhxE0NrU6/yXfwJf3KeRRZp848Z+/8nOVngErH/IuSE/AhI2rma4eqxfPdAFewMd vmiYNByElSsWXNBUyYo6u6uN+9ri8oWxlVL3TEdUZw+rXdcpoU0qO10xM6+dYB5RQ2Si OcJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=Ovw6W/6wtc7xTiPYYQ09Vcdj3+fOaIiHUeb8UborkHk=; b=Lniksp1CIcr+FGxIKJfs1u89NF366xgeWh8XPvNOYcpl6TMFlfwQ5i+/Fr/nBT7LgJ YkVjlZ9XNAWXFK8ZQKRrWu0ThW310/ZI9oPIa+bpzm2D2d6vFqxVB0ZO5l2I/2SDkkoo UZ/yZheXhDYe3OzD39oVskZvfSJ5VwK4ZnTNRdzRQ4uQR3lcISyjgxib05f2RdCJhARZ PwqwwfW38gdyLX9zcJ2i9ofF8JkLXO2bioBDuJki0Ms6p739ARvXb1KU6J9O9XV77MHH h3nocDmw7h6Wu+nyC3OTkX7VtAKYks9GRTPLiPnWXTZKm5+VStpsKhiYUtjMvG1H5tQy FinQ== MIME-Version: 1.0 X-Received: by 10.180.38.105 with SMTP id f9mr18765723wik.15.1366294321967; Thu, 18 Apr 2013 07:12:01 -0700 (PDT) Received: by 10.194.104.200 with HTTP; Thu, 18 Apr 2013 07:12:01 -0700 (PDT) In-Reply-To: <50D39A6B-A778-492F-B605-D4B29D0BEACA@neustar.biz> References: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> <50D39A6B-A778-492F-B605-D4B29D0BEACA@neustar.biz> Date: Thu, 18 Apr 2013 07:12:01 -0700 Message-ID: From: Vincent Chen To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=e89a8f6439b4b84e3f04daa32f2d X-Gm-Message-State: ALoCoQmv7m690Yt4WZ0yjTmPVhha32Oo8XkNmmzbGJYt/DsPM36QZo7aGwLHI6NiiHoV25tjvZBV92T1ZC7ms2RpqWoGyI4+/WmDw4hlXhV1LVMqkt2utKb2xgmpQ/aNxJiiPKShpe4cqEMDGepjx3QMm+9D9Hrb39OHYJD5+V1vNTPKE9CY4IYkyQTsF0QLRymmq6Ojxmp/ Cc: "paws@ietf.org" , "johnny.dixon@bt.com" , Reza Karimi Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement 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, 18 Apr 2013 14:12:04 -0000 --e89a8f6439b4b84e3f04daa32f2d Content-Type: text/plain; charset=ISO-8859-1 Brian, On Thu, Apr 18, 2013 at 5:51 AM, Rosen, Brian wrote: > But you can't really do "stateless" and have registration. That's state. > You can't serve an unregistered device. Slowly changing state, but then > again, most location is slowly changing (mobile devices on the move > excepted). > Yes, you're right. I'll just note that there is still a difference between read (of a registration record) vs read-modify-write to update some information associated with the registration with each query. > I agree that maintaining 60 second polling is very challenging, and I > agree the mechanism we discussed of having a much longer period and > temporarily lowering the period when needed is an appropriate mechanism. > I will remind everyone that if a device is moving, a faster poll is needed > due to the motion (every hour, or when you move more than x meters). > > This affects the proposed rules. > > Brian > > On Apr 17, 2013, at 6:36 PM, Vincent Chen > wrote: > > All, > > For scalability and redundancy reasons, a "stateless" system is much > preferred. That means not having answers depend on priory history of > queries. > This allows running many server instances to service requests. It also > means that each request can go to any serving machine. > > There also may be reasons why caching might not work: > > - The answer is not totally dependent on only the device > characteristics. In the US, for example, there are dynamic registrations, > so the Database might have to run through most of the computation > anyways to determine whether anything has changed. > > - For devices that use GPS, the location might jitter just a bit from > time to time, so the difference might cause cache misses > > To keep the API simple, I wouldn't recommend adding another call when > the existing one already works. > > ---------------------- > Query Volume > ---------------------- > As for the polling period. I think we should look at what this actually > means: > > - At 60-seconds polling period for only 1 million devices.....that's > almost 1.5 Billion queries per day! > > Note that a large search engine like Baidu only handles 5B queries per > day. > > So....I would be very cautious about trying to set the polling period > too low. It would be requiring a significant amount of resources to provide > a capability that would be used rarely, perhaps 0.001% of the time (once a > month)? > > At the F2F, there was a suggestion that actual management could be a > staged process, e.g., > - By default the required update period is 1 or 2 hours > - When needed, the update period for devices within a specified > geographic region could be lowered to 60 seconds, > allowing investigation > - When investigation is complete (and/or after a timeout), update period > is reset to default > > This seems more reasonable to me (IMHO), and the current proposed > protocol with expiry will handle this just fine, I think. > > -vince > > > On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian wrote: > >> Not really. Use a cache. If nothing changed, reply so and move on. >> >> If it's really 60 seconds, then you are maintaining the SSL connection, >> so you don't need a complete reauth. >> OTOH, if you are maintaining an SSL connection, then a push is pretty >> easy. >> >> Brian >> >> On Apr 16, 2013, at 11:25 AM, Peter Stanforth >> wrote: >> >> > Brian >> > Big difference between a simple "Am I ok?" and a reauthentication and >> channel request. >> > The former could be very light weight and make DB processing a lot >> simpler >> > >> > On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" >> wrote: >> > >> >> We already have the notion of an expiry time on the spectrum >> allocation. If you make that short (60 seconds), then the client has to >> come back to the database to get a refresh. No further pull mechanism is >> needed. Its not clear that doing something better helps a lot. The server >> has to get the location of the client and determine if any changes in >> spectrum have occurred. That's a full geospatial query, with some >> possibilities of maintaining caches of recently changed curves. >> >> >> >> A push is hard in many environments because NATs, firewalls and other >> middle boxes make it difficult to establish a connection from outside to >> inside. We could maintain a very simple ping from client to server that >> just kept the path open, and then use that to send the push notification. >> >> >> >> Maintaining pull mechanisms with circa 60 second timeouts is fine as >> long as the number of clients is small. A million clients on one server >> might work without this level of interactivity, with it and we're as much >> as two orders of magnitude less capacity. There are always problems like >> avalanche restart due to power failures, so it's probably not really this >> bad, but it's a pretty big problem. >> >> >> >> Brian >> >> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez < >> Cesar.Gutierrez@ofcom.org.uk> wrote: >> >> >> >>> All, >> >>> >> >>> At the meeting in Orlando we discussed a device update function (or >> kill switch, or PUSH). This arises from the UK regulatory requirement that >> a database should be able to contact any device within a short time. After >> review of PAWS use case document with regards to this, I think our UK >> requirement is neatly captured in requirement P.16 "The protocol MUST >> support the capability for the database to inform master devices of changes >> to spectrum availability information" >> >>> >> >>> This requirement is already part of the current draft of the ETSI >> Harmonised Standard. Its main elements are summarised below, and the full >> text is attached: >> >>> >> >>> +++++++++++ >> >>> DEFINITION >> >>> The master WSD update is the process by which a database informs a >> master WSD that its operational parameters, and those of the slave WSDs >> attached it, are still valid or are no longer valid >> >>> REQUIREMENTS >> >>> - A master WSD shall support WSD update function. For this, a master >> WSD shall either >> >>> *be able to receive an update from the Controller Database WSDB >> within Tping seconds (push update), or >> >>> *send an update request to the Controller Database WSDB every >> Tping seconds (pull update). >> >>> - A master WSD shall support a Tping value of [60] seconds or higher. >> >>> - A master WSD shall cease transmission, and shall instruct the >> slaves attached to it to cease transmission, if it receives update from the >> WSDB that the operational parameters are no longer valid. >> >>> - A master WSD shall cease transmission, and shall instruct the >> slaves attached to it to cease transmission, if it loses connection with >> the WSDB >> >>> ++++++++++ >> >>> >> >>> It is worth signalling that, at least among UK stakeholders, there is >> wide support for the pull method and little support for the push method. >> This is consistent with the view that it will be very difficult to >> implement the push functionality over the internet. >> >>> >> >>> As a first step, I would like to ask the PAWS WG to consider support >> for this functionality in the specification. Secondly, it would be good to >> have views of how a pull mechanism could be implemented in the PAWS >> protocol. We have had early discussions about this off-line, and I think >> the alternatives are 1) to adapt one of the existing procedures >> (SPECTRUM_USE_NOTIFY and "Device Validation" are possible candidates), and >> 2) create a new, dedicated procedure. >> >>> >> >>> Thanks and regards, >> >>> Cesar >> >>> >> >>> >> >>> >> >>> ________________________________ >> >>> >> >>> >> ****************************************************************************************************************** >> >>> For more information visit www.ofcom.org.uk >> >>> >> >>> This email (and any attachments) is confidential and intended for the >> use of the addressee only. >> >>> >> >>> If you have received this email in error please notify the originator >> of the message and delete it from your system. >> >>> >> >>> This email has been scanned for viruses. However, you open any >> attachments at your own risk. >> >>> >> >>> Any views expressed in this message are those of the individual >> sender and do not represent the views or opinions of Ofcom unless expressly >> stated otherwise. >> >>> >> ****************************************************************************************************************** >> >>> >> _______________________________________________ >> >>> 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 >> > > > > -- > -vince > > > -- -vince --e89a8f6439b4b84e3f04daa32f2d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Brian,


On Thu, Apr 18, 2013 at 5:51 AM, Rosen, Bri= an <Brian.Rosen@neustar.biz> wrote:
But you can't really do "stateless" and have registration. = =A0That's state. =A0You can't serve an unregistered device. =A0Slow= ly changing state, but then again, most location is slowly changing (mobile= devices on the move excepted).

=A0Yes, you're right. I'll j= ust note that there is still a difference between read (of a registration r= ecord) vs read-modify-write to update some information associated with the = registration with each query.


I agree that maintaining 60 second polling is very challenging, and I = agree the mechanism we discussed of having a much longer period and tempora= rily lowering the period when needed is an appropriate mechanism. =A0 I wil= l remind everyone that if a device is moving, a faster poll is needed due to the motion (every hour, or when = you move more than x meters).

This affects the proposed rules.

Brian

On Apr 17, 2013, at 6:36 PM, Vincent Chen <vchen@google.com>
=A0wrote:

All,

For scalability and redundancy reasons, a "stateless" system= is much preferred. That means not having answers depend on priory history = of queries.
This allows running many server instances to service requests. It also= means that each request can go to any serving machine.

There also may be reasons why caching might not work:

=A0- The answer is not totally dependent on only the device characteri= stics. In the US, for example, there are dynamic registrations,
=A0 =A0so the Database might have to run through most of the computati= on anyways to determine whether anything has changed.

=A0- For devices that use GPS, the location might jitter just a bit fr= om time to time, so the difference might cause cache misses

To keep the API simple, I wouldn't recommend adding another call w= hen the existing one already works.

----------------------
Query Volume
----------------------
As for the polling period. I think we should look at what this actuall= y means:

=A0 - At 60-seconds polling period for only 1 million devices.....that= 's almost 1.5 Billion queries per day!

Note that a large search engine like Baidu only handles 5B queries per= day.

So....I would be very cautious about trying to set the polling period = too low. It would be requiring a significant amount of resources to provide=
a capability that would be used rarely, perhaps 0.001% of the time (on= ce a month)?

At the F2F, there was a suggestion that actual management could be a s= taged process, e.g.,
=A0 - By default the required update period is 1 or 2 hours
=A0 - When needed, the update period for devices within a specified ge= ographic region could be lowered to 60 seconds,
=A0 =A0 allowing investigation
=A0 - When investigation is complete (and/or after a timeout), update = period is reset to default

This seems more reasonable to me (IMHO), and the current proposed prot= ocol with expiry will handle this just fine, I think.

-vince


On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian <Brian.Rose= n@neustar.biz> wrote:
Not really. =A0Use a cache. =A0If nothing changed, reply so and move on.
If it's really 60 seconds, then you are maintaining the SSL connection,= so you don't need a complete reauth.
OTOH, if you are maintaining an SSL connection, then a push is pretty easy.=

Brian

On Apr 16, 2013, at 11:25 AM, Peter Stanforth <peter@spectrumbridge.com>
=A0wrote:

> Brian
> Big difference between a simple "Am I ok?" and a reauthentic= ation and channel request.
> The former could be very light weight and make DB processing a lot sim= pler
>
> On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:
>
>> We already have the notion of an expiry time on the spectrum alloc= ation. =A0If you make that short (60 seconds), then the client has to come = back to the database to get a refresh. =A0No further pull mechanism is need= ed. =A0Its not clear that doing something better helps a lot. =A0The server has to get the location of the client and deter= mine if any changes in spectrum have occurred. =A0That's a full geospat= ial query, with some possibilities of maintaining caches of recently change= d curves.
>>
>> A push is hard in many environments because NATs, firewalls and ot= her middle boxes make it difficult to establish a connection from outside t= o inside. =A0We could maintain a very simple ping from client to server tha= t just kept the path open, and then use that to send the push notification.
>>
>> Maintaining pull mechanisms with circa 60 second timeouts is fine = as long as the number of clients is small. =A0A million clients on one serv= er might work without this level of interactivity, with it and we're as= much as two orders of magnitude less capacity. =A0There are always problems like avalanche restart due to power failures,= so it's probably not really this bad, but it's a pretty big proble= m.
>>
>> Brian
>> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.= uk> wrote:
>>
>>> All,
>>>
>>> At the meeting in Orlando we discussed a device update functio= n (or kill switch, or PUSH). This arises from the UK regulatory requirement= that a database should be able to contact any device within a short time. = After review of PAWS use case document with regards to this, I think our UK requirement is neatly captured in requirem= ent P.16 "The protocol MUST support the capability for the database to= inform master devices of changes to spectrum availability information"= ;
>>>
>>> This requirement is already part of the current draft of the E= TSI Harmonised Standard. =A0Its main elements are summarised below, and the= full text is attached:
>>>
>>> +++++++++++
>>> DEFINITION
>>> The master WSD update is the process by which a database infor= ms a master WSD that its operational parameters, and those of the slave WSD= s attached it, are still valid or are no longer valid
>>> REQUIREMENTS
>>> - A master WSD shall support WSD update function. =A0For this,= a master WSD shall either
>>> =A0 =A0 =A0*be able to receive an update from the Controller D= atabase WSDB within Tping seconds (push update), or
>>> =A0 =A0 =A0*send an update request to the Controller Database = WSDB every Tping seconds (pull update).
>>> - A master WSD shall support a Tping value of [60] seconds or = higher.
>>> - A master WSD shall cease transmission, and shall instruct th= e slaves attached to it to cease transmission, if it receives update from t= he WSDB that the operational parameters are no longer valid.
>>> - A master WSD shall cease transmission, and shall instruct th= e slaves attached to it to cease transmission, if it loses connection with = the WSDB
>>> ++++++++++
>>>
>>> It is worth signalling that, at least among UK stakeholders, t= here is wide support for the pull method and little support for the push me= thod. This is consistent with the view that it will be very difficult to im= plement the push functionality over the internet.
>>>
>>> As a first step, I would like to ask the PAWS WG to consider s= upport for this functionality in the specification. Secondly, it would be g= ood to have views of how a pull mechanism could be implemented in the PAWS = protocol. We have had early discussions about this off-line, and I think the alternatives are 1) to adapt one of the exi= sting procedures (SPECTRUM_USE_NOTIFY and "Device Validation" are= possible candidates), and 2) create a new, dedicated procedure.
>>>
>>> Thanks and regards,
>>> Cesar
>>>
>>>
>>>
>>> ________________________________
>>>
>>> **************************************************************= ****************************************************
>>> For more information visit www.ofcom.org.uk
>>>
>>> This email (and any attachments) is confidential and intended = for the use of the addressee only.
>>>
>>> If you have received this email in error please notify the ori= ginator of the message and delete it from your system.
>>>
>>> This email has been scanned for viruses. However, you open any= attachments at your own risk.
>>>
>>> Any views expressed in this message are those of the individua= l sender and do not represent the views or opinions of Ofcom unless express= ly stated otherwise.
>>> **************************************************************= ****************************************************
>>> <EN301598v0018_MasterWSDupdate.docx>____________________= ___________________________
>>> paws mailing list
>>> paws@ietf.o= rg
>>> 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



--
-vince




--
-vince
--e89a8f6439b4b84e3f04daa32f2d-- From Cesar.Gutierrez@ofcom.org.uk Mon Apr 22 09:21:41 2013 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 4BB5621E8085 for ; Mon, 22 Apr 2013 09:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.282 X-Spam-Level: X-Spam-Status: No, score=-3.282 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=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 D06I59tof8iV for ; Mon, 22 Apr 2013 09:21:39 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.165]) by ietfa.amsl.com (Postfix) with ESMTP id 661F421F8E99 for ; Mon, 22 Apr 2013 09:21:38 -0700 (PDT) Received: from [85.158.137.99:37874] by server-5.bemta-3.messagelabs.com id B9/FE-30636-78365715; Mon, 22 Apr 2013 16:21:27 +0000 X-Env-Sender: Cesar.Gutierrez@ofcom.org.uk X-Msg-Ref: server-3.tower-217.messagelabs.com!1366647686!13551290!1 X-Originating-IP: [194.33.160.65] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14447 invoked from network); 22 Apr 2013 16:21:26 -0000 Received: from unknown (HELO WOK-INTRA-EDG02.intra.ofcom.local) (194.33.160.65) by server-3.tower-217.messagelabs.com with AES128-SHA encrypted SMTP; 22 Apr 2013 16:21:26 -0000 Received: from WOK-INTRA-EXC01.intra.ofcom.local (10.130.130.67) by WOK-INTRA-EDG02.intra.ofcom.local (10.130.239.20) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 22 Apr 2013 17:21:25 +0100 Received: from WOK-INTRA-EXC02.intra.ofcom.local ([fe80::550e:933d:224e:6a19]) by WOK-INTRA-EXC01.intra.ofcom.local ([fe80::f0b6:2506:a722:c58b%15]) with mapi id 14.01.0289.001; Mon, 22 Apr 2013 17:23:34 +0100 From: Cesar Gutierrez To: Vincent Chen , "Rosen, Brian" Thread-Topic: [paws] Device update function - ETSI/UK regulatory requirement Thread-Index: Ac46hSC6Ps1OFLeIR9uE/BxoEtWBTwAH8E0AAAJUWAAAACGHgABBOj6AAB3b2QAAAs+UgADOIZJw Date: Mon, 22 Apr 2013 16:23:33 +0000 Message-ID: <5D3E853BEE49C848BB63047C794C8655AE9703AB@WOK-INTRA-EXC02.intra.ofcom.local> References: <5D3E853BEE49C848BB63047C794C8655AE96EF20@WOK-INTRA-EXC02.intra.ofcom.local> <50D39A6B-A778-492F-B605-D4B29D0BEACA@neustar.biz> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.131.249] Content-Type: multipart/alternative; boundary="_000_5D3E853BEE49C848BB63047C794C8655AE9703ABWOKINTRAEXC02in_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Reza Karimi , "johnny.dixon@bt.com" Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement 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, 22 Apr 2013 16:21:41 -0000 --_000_5D3E853BEE49C848BB63047C794C8655AE9703ABWOKINTRAEXC02in_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince and all, A couple of comments on the update requirement in the ETSI standard: * Its purpose is to inform the device that there have been changes i= n its environment and, as a result, in the available spectrum. The device i= tself has not changed or moved, so it does not have to communicate paramete= rs to the database (except its ID). The scenario of a moving device is diff= erent and there is another requirement for it: as soon as the device moves = beyond a threshold distance, it must request new spectrum availability (for= which it must provide its new location). * I agree that a 60 secs. period for millions of devices will gener= ate an unmanageable volume of queries. I also think that the interference m= anagement process is likely to be similar to what Vincent outlined below. H= owever, I would be wary of making assumptions about the default update peri= od. My personal bet is 15 minutes, but even here in Ofcom everybody in the = team has different views. Eventually, in the UK it will be Ofcom interferen= ce enforcement team who decides on the default value and on the management = process. It is for this reason that the requirement is that devices (and da= tabases) are capable of supporting 60 secs. or higher. Regards, Cesar From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Vin= cent Chen Sent: 18 April 2013 15:12 To: Rosen, Brian Cc: paws@ietf.org; johnny.dixon@bt.com; Reza Karimi Subject: Re: [paws] Device update function - ETSI/UK regulatory requirement Brian, On Thu, Apr 18, 2013 at 5:51 AM, Rosen, Brian > wrote: But you can't really do "stateless" and have registration. That's state. = You can't serve an unregistered device. Slowly changing state, but then ag= ain, most location is slowly changing (mobile devices on the move excepted)= . Yes, you're right. I'll just note that there is still a difference between= read (of a registration record) vs read-modify-write to update some inform= ation associated with the registration with each query. I agree that maintaining 60 second polling is very challenging, and I agree= the mechanism we discussed of having a much longer period and temporarily = lowering the period when needed is an appropriate mechanism. I will remin= d everyone that if a device is moving, a faster poll is needed due to the m= otion (every hour, or when you move more than x meters). This affects the proposed rules. Brian On Apr 17, 2013, at 6:36 PM, Vincent Chen > wrote: All, For scalability and redundancy reasons, a "stateless" system is much prefer= red. That means not having answers depend on priory history of queries. This allows running many server instances to service requests. It also mean= s that each request can go to any serving machine. There also may be reasons why caching might not work: - The answer is not totally dependent on only the device characteristics. = In the US, for example, there are dynamic registrations, so the Database might have to run through most of the computation anyway= s to determine whether anything has changed. - For devices that use GPS, the location might jitter just a bit from time= to time, so the difference might cause cache misses To keep the API simple, I wouldn't recommend adding another call when the e= xisting one already works. ---------------------- Query Volume ---------------------- As for the polling period. I think we should look at what this actually mea= ns: - At 60-seconds polling period for only 1 million devices.....that's almo= st 1.5 Billion queries per day! Note that a large search engine like Baidu only handles 5B queries per day. So....I would be very cautious about trying to set the polling period too l= ow. It would be requiring a significant amount of resources to provide a capability that would be used rarely, perhaps 0.001% of the time (once a = month)? At the F2F, there was a suggestion that actual management could be a staged= process, e.g., - By default the required update period is 1 or 2 hours - When needed, the update period for devices within a specified geographi= c region could be lowered to 60 seconds, allowing investigation - When investigation is complete (and/or after a timeout), update period = is reset to default This seems more reasonable to me (IMHO), and the current proposed protocol = with expiry will handle this just fine, I think. -vince On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian > wrote: Not really. Use a cache. If nothing changed, reply so and move on. If it's really 60 seconds, then you are maintaining the SSL connection, so = you don't need a complete reauth. OTOH, if you are maintaining an SSL connection, then a push is pretty easy. Brian On Apr 16, 2013, at 11:25 AM, Peter Stanforth > wrote: > Brian > Big difference between a simple "Am I ok?" and a reauthentication and cha= nnel request. > The former could be very light weight and make DB processing a lot simple= r > > On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" > wrote: > >> We already have the notion of an expiry time on the spectrum allocation.= If you make that short (60 seconds), then the client has to come back to = the database to get a refresh. No further pull mechanism is needed. Its n= ot clear that doing something better helps a lot. The server has to get th= e location of the client and determine if any changes in spectrum have occu= rred. That's a full geospatial query, with some possibilities of maintaini= ng caches of recently changed curves. >> >> A push is hard in many environments because NATs, firewalls and other mi= ddle boxes make it difficult to establish a connection from outside to insi= de. We could maintain a very simple ping from client to server that just k= ept the path open, and then use that to send the push notification. >> >> Maintaining pull mechanisms with circa 60 second timeouts is fine as lon= g as the number of clients is small. A million clients on one server might= work without this level of interactivity, with it and we're as much as two= orders of magnitude less capacity. There are always problems like avalanc= he restart due to power failures, so it's probably not really this bad, but= it's a pretty big problem. >> >> Brian >> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez > wrote: >> >>> All, >>> >>> At the meeting in Orlando we discussed a device update function (or kil= l switch, or PUSH). This arises from the UK regulatory requirement that a d= atabase should be able to contact any device within a short time. After rev= iew of PAWS use case document with regards to this, I think our UK requirem= ent is neatly captured in requirement P.16 "The protocol MUST support the c= apability for the database to inform master devices of changes to spectrum = availability information" >>> >>> This requirement is already part of the current draft of the ETSI Harmo= nised Standard. Its main elements are summarised below, and the full text = is attached: >>> >>> +++++++++++ >>> DEFINITION >>> The master WSD update is the process by which a database informs a mast= er WSD that its operational parameters, and those of the slave WSDs attache= d it, are still valid or are no longer valid >>> REQUIREMENTS >>> - A master WSD shall support WSD update function. For this, a master W= SD shall either >>> *be able to receive an update from the Controller Database WSDB wi= thin Tping seconds (push update), or >>> *send an update request to the Controller Database WSDB every Tpin= g seconds (pull update). >>> - A master WSD shall support a Tping value of [60] seconds or higher. >>> - A master WSD shall cease transmission, and shall instruct the slaves = attached to it to cease transmission, if it receives update from the WSDB t= hat the operational parameters are no longer valid. >>> - A master WSD shall cease transmission, and shall instruct the slaves = attached to it to cease transmission, if it loses connection with the WSDB >>> ++++++++++ >>> >>> It is worth signalling that, at least among UK stakeholders, there is w= ide support for the pull method and little support for the push method. Thi= s is consistent with the view that it will be very difficult to implement t= he push functionality over the internet. >>> >>> As a first step, I would like to ask the PAWS WG to consider support fo= r this functionality in the specification. Secondly, it would be good to ha= ve views of how a pull mechanism could be implemented in the PAWS protocol.= We have had early discussions about this off-line, and I think the alterna= tives are 1) to adapt one of the existing procedures (SPECTRUM_USE_NOTIFY a= nd "Device Validation" are possible candidates), and 2) create a new, dedic= ated procedure. >>> >>> Thanks and regards, >>> Cesar >>> >>> >>> >>> ________________________________ >>> >>> ***********************************************************************= ******************************************* >>> For more information visit www.ofcom.org.uk >>> >>> This email (and any attachments) is confidential and intended for the u= se of the addressee only. >>> >>> If you have received this email in error please notify the originator o= f the message and delete it from your system. >>> >>> This email has been scanned for viruses. However, you open any attachme= nts at your own risk. >>> >>> Any views expressed in this message are those of the individual sender = and do not represent the views or opinions of Ofcom unless expressly stated= otherwise. >>> ***********************************************************************= ******************************************* >>> ___________________________________= ____________ >>> 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 -- -vince -- -vince ________________________________ ***************************************************************************= *************************************** For more information visit www.ofcom.org.uk This email (and any attachments) is confidential and intended for the use o= f the addressee only. If you have received this email in error please notify the originator of th= e message and delete it from your system. This email has been scanned for viruses. However, you open any attachments = at your own risk. Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise. ***************************************************************************= *************************************** --_000_5D3E853BEE49C848BB63047C794C8655AE9703ABWOKINTRAEXC02in_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince and all,

 

A couple of comments on= the update requirement in the ETSI standard:

&midd= ot;   = ;     Its purpose is to inform = the device that there have been changes in its environment and, as a result= , in the available spectrum. The device itself has not changed or moved, so it does not have to communicate parameters to the dat= abase (except its ID). The scenario of a moving device is different and the= re is another requirement for it: as soon as the device moves beyond a thre= shold distance, it must request new spectrum availability (for which it must provide its new location).

&midd= ot;   = ;     I agree that  a 60 s= ecs. period for millions of devices will generate an unmanageable volume of= queries. I also think that the interference management process is likely to be similar to what Vincent outlined below. However, I would b= e wary of making assumptions about the default update period. My personal b= et is 15 minutes, but even here in Ofcom everybody in the team has differen= t views. Eventually, in the UK it will be Ofcom interference enforcement team who decides on the default val= ue and on the management process. It is for this reason that the requiremen= t is that devices (and databases) are capable of supporting 60 secs. or hig= her.

 

Regards,

Cesar

 

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of Vincent Chen
Sent: 18 April 2013 15:12
To: Rosen, Brian
Cc: paws@ietf.org; johnny.dixon@bt.com; Reza Karimi
Subject: Re: [paws] Device update function - ETSI/UK regulatory requ= irement

 

Brian,

 

 

On Thu, Apr 18, 2013 at 5:51 AM, Rosen, Brian <Brian.Rosen@neus= tar.biz> wrote:

But you can't really do "stateless" and ha= ve registration.  That's state.  You can't serve an unregistered = device.  Slowly changing state, but then again, most location is slowl= y changing (mobile devices on the move excepted).

 

 Yes, you're right. I'll just note that there i= s still a difference between read (of a registration record) vs read-modify= -write to update some information associated with the registration with eac= h query.

 

 

I agree that maintaining 60 second polling is very c= hallenging, and I agree the mechanism we discussed of having a much longer = period and temporarily lowering the period when needed is an appropriate me= chanism.   I will remind everyone that if a device is moving, a faster poll is needed due to the motion (eve= ry hour, or when you move more than x meters).

 

This affects the proposed rules.

 

Brian

 

On Apr 17, 2013, at 6:36 PM, Vincent Chen <vchen@google.com>

 wrote:



All,

 

For scalability and redundancy reasons, a "stat= eless" system is much preferred. That means not having answers depend = on priory history of queries.

This allows running many server instances to service= requests. It also means that each request can go to any serving machine.

 

There also may be reasons why caching might not work= :

 

 - The answer is not totally dependent on only = the device characteristics. In the US, for example, there are dynamic regis= trations,

   so the Database might have to run throu= gh most of the computation anyways to determine whether anything has change= d.

 

 - For devices that use GPS, the location might= jitter just a bit from time to time, so the difference might cause cache m= isses

 

To keep the API simple, I wouldn't recommend adding = another call when the existing one already works.

 

----------------------

Query Volume

----------------------

As for the polling period. I think we should look at= what this actually means:

 

  - At 60-seconds polling period for only 1 mil= lion devices.....that's almost 1.5 Billion queries per day!

 

Note that a large search engine like Baidu only hand= les 5B queries per day.

 

So....I would be very cautious about trying to set t= he polling period too low. It would be requiring a significant amount of re= sources to provide

a capability that would be used rarely, perhaps 0.00= 1% of the time (once a month)?

 

At the F2F, there was a suggestion that actual manag= ement could be a staged process, e.g.,

  - By default the required update period is 1 = or 2 hours

  - When needed, the update period for devices = within a specified geographic region could be lowered to 60 seconds,

    allowing investigation

  - When investigation is complete (and/or afte= r a timeout), update period is reset to default

 

This seems more reasonable to me (IMHO), and the cur= rent proposed protocol with expiry will handle this just fine, I think.

 

-vince

 

On Tue, Apr 16, 2013 at 8:28 AM, Rosen, Brian <Brian.Rosen@neus= tar.biz> wrote:

Not really.  Use a cache.  If nothing chan= ged, reply so and move on.

If it's really 60 seconds, then you are maintaining the SSL connection, so = you don't need a complete reauth.
OTOH, if you are maintaining an SSL connection, then a push is pretty easy.=

Brian

On Apr 16, 2013, at 11:25 AM, Peter Stanforth <peter@spectrumbridge.com>

 wrote:

> Brian
> Big difference between a simple "Am I ok?" and a reauthentic= ation and channel request.
> The former could be very light weight and make DB processing a lot sim= pler
>
> On Apr 16, 2013, at 10:18 AM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:
>
>> We already have the notion of an expiry time on the spectrum alloc= ation.  If you make that short (60 seconds), then the client has to co= me back to the database to get a refresh.  No further pull mechanism i= s needed.  Its not clear that doing something better helps a lot.  The server has to get the location of the client and de= termine if any changes in spectrum have occurred.  That's a full geosp= atial query, with some possibilities of maintaining caches of recently chan= ged curves.
>>
>> A push is hard in many environments because NATs, firewalls and ot= her middle boxes make it difficult to establish a connection from outside t= o inside.  We could maintain a very simple ping from client to server = that just kept the path open, and then use that to send the push notification.
>>
>> Maintaining pull mechanisms with circa 60 second timeouts is fine = as long as the number of clients is small.  A million clients on one s= erver might work without this level of interactivity, with it and we're as = much as two orders of magnitude less capacity.  There are always problems like avalanche restart due to power failur= es, so it's probably not really this bad, but it's a pretty big problem. >>
>> Brian
>> On Apr 16, 2013, at 9:20 AM, Cesar Gutierrez <Cesar.Gutierrez@ofcom.org.= uk> wrote:
>>
>>> All,
>>>
>>> At the meeting in Orlando we discussed a device update functio= n (or kill switch, or PUSH). This arises from the UK regulatory requirement= that a database should be able to contact any device within a short time. = After review of PAWS use case document with regards to this, I think our UK requirement is neatly captured in requirem= ent P.16 "The protocol MUST support the capability for the database to= inform master devices of changes to spectrum availability information"= ;
>>>
>>> This requirement is already part of the current draft of the E= TSI Harmonised Standard.  Its main elements are summarised below, and = the full text is attached:
>>>
>>> +++++++++++
>>> DEFINITION
>>> The master WSD update is the process by which a database infor= ms a master WSD that its operational parameters, and those of the slave WSD= s attached it, are still valid or are no longer valid
>>> REQUIREMENTS
>>> - A master WSD shall support WSD update function.  For th= is, a master WSD shall either
>>>      *be able to receive an update from the Con= troller Database WSDB within Tping seconds (push update), or
>>>      *send an update request to the Controller = Database WSDB every Tping seconds (pull update).
>>> - A master WSD shall support a Tping value of [60] seconds or = higher.
>>> - A master WSD shall cease transmission, and shall instruct th= e slaves attached to it to cease transmission, if it receives update from t= he WSDB that the operational parameters are no longer valid.
>>> - A master WSD shall cease transmission, and shall instruct th= e slaves attached to it to cease transmission, if it loses connection with = the WSDB
>>> ++++++++++
>>>
>>> It is worth signalling that, at least among UK stakeholders, t= here is wide support for the pull method and little support for the push me= thod. This is consistent with the view that it will be very difficult to im= plement the push functionality over the internet.
>>>
>>> As a first step, I would like to ask the PAWS WG to consider s= upport for this functionality in the specification. Secondly, it would be g= ood to have views of how a pull mechanism could be implemented in the PAWS = protocol. We have had early discussions about this off-line, and I think the alternatives are 1) to adapt one of the exi= sting procedures (SPECTRUM_USE_NOTIFY and "Device Validation" are= possible candidates), and 2) create a new, dedicated procedure.
>>>
>>> Thanks and regards,
>>> Cesar
>>>
>>>
>>>
>>> ________________________________
>>>
>>> **************************************************************= ****************************************************
>>> For more information visit www.ofcom.org.uk
>>>
>>> This email (and any attachments) is confidential and intended = for the use of the addressee only.
>>>
>>> If you have received this email in error please notify the ori= ginator of the message and delete it from your system.
>>>
>>> This email has been scanned for viruses. However, you open any= attachments at your own risk.
>>>
>>> Any views expressed in this message are those of the individua= l sender and do not represent the views or opinions of Ofcom unless express= ly stated otherwise.
>>> **************************************************************= ****************************************************
>>> <EN301598v0018_MasterWSDupdate.docx>____________________= ___________________________
>>> paws mailing list
>>> paws@ietf.o= rg
>>> 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



 

--
-vince

 



 

--
-vince



***************************************************************************= ***************************************
For more information visit www.ofcom.org.uk

This email (and any attachments) is confidential and intended for the use o= f the addressee only.

If you have received this email in error please notify the originator of th= e message and delete it from your system.

This email has been scanned for viruses. However, you open any attachments = at your own risk.

Any views expressed in this message are those of the individual sender and = do not represent the views or opinions of Ofcom unless expressly stated oth= erwise.
***************************************************************************= ***************************************
 --_000_5D3E853BEE49C848BB63047C794C8655AE9703ABWOKINTRAEXC02in_-- From johnsonhammond1@hushmail.com Sat Apr 27 16:37:44 2013 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 C2AB621F9970 for ; Sat, 27 Apr 2013 16:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 k2Y5A77C07Ji for ; Sat, 27 Apr 2013 16:37:43 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by ietfa.amsl.com (Postfix) with ESMTP id D302A21F9957 for ; Sat, 27 Apr 2013 16:37:43 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5a.hushmail.com [65.39.178.235]) by smtp5.hushmail.com (Postfix) with SMTP id BE548580AB for ; Sat, 27 Apr 2013 17:31:02 +0000 (UTC) X-hush-relay-time: 213 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp5.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:31:02 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 6AD5FE6736; Sat, 27 Apr 2013 17:31:02 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:31:02 -0400 To: paws@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173102.6AD5FE6736@smtp.hushmail.com> Subject: [paws] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 23:37:45 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.