From internet-drafts@ietf.org Tue Jun 4 18:51:16 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 04EF821F9A9D; Tue, 4 Jun 2013 18:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, 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 7it6f5D5vBVA; Tue, 4 Jun 2013 18:51:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9F521F9A9E; Tue, 4 Jun 2013 18:50:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130605015038.2830.69852.idtracker@ietfa.amsl.com> Date: Tue, 04 Jun 2013 18:50:38 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-05.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 01:51:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access Spectrum Database Author(s) : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-05.txt Pages : 93 Date : 2013-06-04 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vchen@google.com Tue Jun 4 19:03:49 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 9F12521F9ADB for ; Tue, 4 Jun 2013 19:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 aQo5scRBFzNk for ; Tue, 4 Jun 2013 19:03:48 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A821921F9ADA for ; Tue, 4 Jun 2013 19:03:45 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so2218466iea.4 for ; Tue, 04 Jun 2013 19:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=05JEEb2xiAT/miCycbEExm+94zTohwpf6l4+dUwgG6k=; b=hp0tQJX77IwWtiW+vpOhkrj9/3W4XXbyEEh9V4jp9Rn5C8SMFRhsKJLClyZFGBnqhX x9un53jots9H0jLEWnZfMLrCwoSuM4vPAUQBWMUh8c1uP1M6pZgjt34VskJ6+NN75Bz0 owgk/zOt+4Ta82iIeLutSahpcwC9cKG/LvFu/h9wdMeoJA5uXWlR3oT00Rk+6Y1HuR22 RhjTB4HmClDJDCqiWXq36Uv7lttwhF/omPZnSIMfo7cwIj3I4pyL45vEb/IZgxtE9Bq5 2QDNQtHcOkAKXfbnplAnpnabzaI8O92NKoAD3EhPPOpqx8rb06SAeF8h3YQR65h/SQDB gc/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=05JEEb2xiAT/miCycbEExm+94zTohwpf6l4+dUwgG6k=; b=SP2cfexXutMdv+1bJDboRf54n5bvGVTTZdESPBNwRvrE4rsVqoIEpmvrTzQNqCRn+m Xu5dRQeEJGoD0weNn3mjZ90pmcW98b9DxUQQKVQtq6Vk59lukGR8oenJ5UYllwlMOMzg srgxBIN0y8e9JrgDIyxsFGmnYZgh4OtFB18dslglRv528oMeLtYqc+aPw4b/Wkmym9Om LGvcYRi6M4nLvuI0klI7pD7kV+LvuxJYQRP5H+zalfysXwSP+Re9/OrWR+UclYwp30b9 GRjvsDio6jICHKHhREXaKOB18dI7dVLphOuYhsGnc62QevNAz90KiIHyz9N2scnRXOg6 P9iw== MIME-Version: 1.0 X-Received: by 10.50.176.202 with SMTP id ck10mr2234919igc.9.1370397824992; Tue, 04 Jun 2013 19:03:44 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Tue, 4 Jun 2013 19:03:44 -0700 (PDT) In-Reply-To: <20130605015038.2830.69852.idtracker@ietfa.amsl.com> References: <20130605015038.2830.69852.idtracker@ietfa.amsl.com> Date: Tue, 4 Jun 2013 19:03:44 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=089e0111d7588f67c904de5e9bb9 X-Gm-Message-State: ALoCoQly6eMdBfsCValj26syv03PJmywnUM8Br1JAQZPI7RhxFSh5Y8/3ElZhJBL+6YE4jWTo9dQ2vmLb6O3GzxYnqfaCmiITeVnf7Ibf874E8At/JYycjSgLM+F8p+T8EDdx3u7iSMTjA01OQwsGRk7WE+ymsn9tjr1gr8JiOyvXG0aHjjtq8+9oDOVEWdiU0fa19ti4n+P Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-05.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 02:03:49 -0000 --089e0111d7588f67c904de5e9bb9 Content-Type: text/plain; charset=ISO-8859-1 All, I've updated the draft to incorporate the comments raised on the list in response to version 04. - Clarified what should happen if device loses contact with Listing Server - Clarified that if a Database indicates a database-change via DbUpdateSpec, the Device should only replace that database's entry with the alternate databases. Other Changes from 04: o Add "masterDeviceDesc" parameter to the available-spectrum requests to allow both Master and Slave device descriptors when the Master is making the request on behalf of a Slave. o Add "requestType" parameter to the available-spectrum requests to support requesting generic operating parameters for any Slave Device. o Add DbUpdateSpec as optional parameter to all response messages and to the error response to allow a Device to detect a database change at any stage of the control flow. o For the OUTSIDE_COVERAGE error, added ability to return a list of alternate databases o Explicitly allow JSON-RPC v2.0 and v1.0 encodings o Relaxed language that state, "MUST stop operation" to "MUST cease use of spectrum under rules for database-managed spectrum". I.e., the device may have other fallback strategies allowed by regulators. Diff: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-paws-protocol-04.txt&url2=http://tools.ietf.org/id/draft-ietf-paws-protocol-05.txt --089e0111d7588f67c904de5e9bb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

I've updated the draft to inco= rporate the comments raised on the list in response to version 04.
=A0- Clarified what should happen if device loses contact with List= ing Server
=A0- Clarified that if a Database indicates a database-change vi= a DbUpdateSpec, the Device should
=A0 =A0only replace that = database's entry with the alternate databases.


<= /div>
=A0 =A0Other Changes from 04:
=A0
=A0 =A0 o =A0Add "masterDeviceDesc&= quot; parameter to the available-spectrum
=A0 =A0 =A0 =A0requests t= o allow both Master and Slave device descriptors when
=A0 = =A0 =A0 =A0the Master is making the request on behalf of a Slave.
=A0 =A0 o =A0Add "re= questType" parameter to the available-spectrum requests to
=A0 =A0 =A0 =A0support requesting generic operating paramete= rs for any Slave
=A0 =A0 =A0 =A0Device.
=A0 =A0 o =A0Add DbUpdateSpec as optional parameter = to all response messages
=A0 =A0 =A0 =A0and to the= error response to allow a Device to detect a database
=A0= =A0 =A0 =A0change at any stage of the control flow.
=A0 =A0 o =A0For the OUTS= IDE_COVERAGE error, added ability to return a list of
=A0 = =A0 =A0 =A0alternate databases=
=A0 =A0 o =A0Explicitly a= llow JSON-RPC v2.0 and v1.0 encodings =
=A0 =A0 o = =A0Relaxed language that state, "MUST stop operation" to "MU= ST cease
=A0 =A0 =A0 =A0use of spe= ctrum under rules for database-managed spectrum". =A0I.e.,
=A0 =A0 =A0 =A0the device may have other fallback strategies= allowed by
=A0 =A0 =A0 =A0regulators= .




--089e0111d7588f67c904de5e9bb9-- From vchen@google.com Tue Jun 4 19:27: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 A652E21F8D90 for ; Tue, 4 Jun 2013 19:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 TGqhx0hAlRdo for ; Tue, 4 Jun 2013 19:27:40 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA1021F9B2C for ; Tue, 4 Jun 2013 19:20:38 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id b11so2152947iee.25 for ; Tue, 04 Jun 2013 19:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FkNdlcqRHXQAHORmNlk/U6QL3CH+/1EqdY5h0x0yhkw=; b=O6lvQ6GmHO0YZuEh1ihbH3rPnlxPMO4JXU4BbhJ0HFK8cLEb+0EsOU8+pejZUjD1Zj GXCR9kboUKET5+Wl7dhGQP67zXPaSqfKMTs55wo5QljOdftJ7P3+HUgl7L38twiz3pQP Y7z1IuZcDIVaK2HUhq+kW4nbRcExcr6uk99z3KjW9Kk5VNieBKfi2sjcEe5sne7WjM0o MvztC10LZ/l5zEIBFP/cZx1Xd/pxjeWaQmHv4buSXdfIGqmLJrzp5Sn7a44jHu8Hy+dx XQlHkxWzXvpQbhbmvmWmgWuOvkEKBQlVIqkRYIIhNw8CSsNg7KjAGxrBcwCZ3TJE1u/G XHhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=FkNdlcqRHXQAHORmNlk/U6QL3CH+/1EqdY5h0x0yhkw=; b=oXSKgphtVYBoQlzIJ5NwP69S+nx4Ya0h2GaGRR6gaEtKSzvcD3c1GYuxvq+QiTswyt gLBSqrn57hifchwMQMd2bv3LZXf+N7Cdnvi5e9mHgNAAcmq7x32F5h4hxChRNOfb1mRW wsSgjBQRG9bRBL+YGGVAAVvehIPkQUwCOiVEZ3nIP0jQOOfow5VcB87TkEDpzJ8Mh3+C 2UMjPkDx2t5t+vyRBQi8bHzkrONHhjmzcpPkaW9oYsUXL5TpSHZuDjeUnUItLDSzkQju A7M/3s3TuZZ0IA/MVjvnucvbGatuv2NwNBvo+fb7XjepRRI1WDab6Cbn9IXOicfAp+ki /fUw== MIME-Version: 1.0 X-Received: by 10.50.102.67 with SMTP id fm3mr2261341igb.5.1370398836283; Tue, 04 Jun 2013 19:20:36 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Tue, 4 Jun 2013 19:20:36 -0700 (PDT) In-Reply-To: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> Date: Tue, 4 Jun 2013 19:20:36 -0700 Message-ID: From: Vincent Chen To: Weixinpeng Content-Type: multipart/alternative; boundary=047d7b10ca13d6757604de5ed7b9 X-Gm-Message-State: ALoCoQlx70gsn3tgxmKopnRjGCHYfva2GfyzZWA+4AO5c4ljB3lzYr1qdc1UYoCoA1LB9+ZwtVCJX1ej0rQVbqrkS/CtX1nJSt0sNI4Fp0fcm4WpGC5qAMw/6t/xMAgcXSbXzFUyPvPC/gDL9FgMugT1EcyE1IVFfpEDPV4xVgqld9ToTENJ7x3FPzrUXniFoHDqXF1WJJEz Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 02:27:42 -0000 X-List-Received-Date: Wed, 05 Jun 2013 02:27:42 -0000 X-List-Received-Date: Wed, 05 Jun 2013 02:27:42 -0000 --047d7b10ca13d6757604de5ed7b9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Xinpeng, All, Thanks for putting this together. It seems that discovery involves two aspects: - Deployment of LoST servers, which also impacts discovery of LoST severs - Protocol (format of messages that is communicated) The current document is placing deployment out of scope, but does suggest that preconfiguration is a strategy. That just leaves the protocol, which, may be characterized as: 1. Device sends request with its location 2. Server responds with a list of (name, uri) pairs Given that this is relatively simple, should we just build it into PAWS protocol itself? For example, the current revision (r05) of the PAWS protocol allows for the following: 1. Device asks database for available spectrum in a location outside the coverage area for the Databae 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (name, databaseUri) entries to "recommend" alternate databases This provides almost the same capability. Should we just add a ListDatabase to PAWS? -vince On Thu, May 23, 2013 at 6:57 PM, Weixinpeng wrote: > Hi Mark,**** > > Please see comments inline. Thanks!**** > > ** ** > > Best Regards,**** > > Xinpeng.**** > > ** ** > > ** ** > > *From:* Mark Jones [mailto:mark@azu.ca] > *Sent:* Thursday, May 23, 2013 10:31 PM > *To:* Weixinpeng; paws@ietf.org > > *Cc:* Peter McCann; Zhulei (A) > *Subject:* RE: [paws] draft-wei-paws-database-discovery-01**** > > ** ** > > Hi Xinpeng,**** > > ** ** > > Thank you for your responses. I have some further comments/questions > inline below (prefixed by mj>).**** > > ** ** > > *From:* Weixinpeng [mailto:weixinpeng@huawei.com ] > *Sent:* May-22-13 11:13 PM > *To:* Mark Jones; paws@ietf.org > *Cc:* Peter McCann; Zhulei (A) > *Subject:* RE: [paws] draft-wei-paws-database-discovery-01**** > > ** ** > > Hi Mark,**** > > Thanks for your feedback, and I think there are some issues that > I need to clarify.**** > > **** > > we have to be clear that the discovery mechanism is provided as > an optional method that can help master device to find the correct WSDB, > which means the master device can get WSDB by, such as, pre-configuring o= f > WSDB, provision etc. **** > > ** ** > > mj> Understood.**** > > ** ** > > The dynamic discovery mechanism provides more convenient for > master device to find WSDB, for example, when a new WSDB is setup for > providing service or when some deployed WSDB goes down and never work.***= * > > **** > > mj> In this regard, DNS resolution would appear to be equally convenient > mechanism to manage WSDB instances being commissioned or decommissioned. = I > view LoST as a kind of =93location-aware DNS=94 so I understand its > applicability to discovery of the appropriate WSDB. I still think the dra= ft > needs more information on how the Master device finds its WSDB DS so that > implementers understand if/when this optional discovery method is > applicable to their deployment.**** > > *[Wei] Yeah, because we cannot covey location information in DNS query > message, so DNS is inappropriate to find the WSDB. I think I will do more > clarification about how master device finds WSDB DS later.***** > > ** ** > > About the DHCP you mentioned below, technically speaking, there > have been some extension of DHCP for supporting the provision of LoST > server, refer to RFC5223. **** > > ** ** > > mj> I understand that the DHCP option specifying the LoST server would be > provided to the Master device when it initiated its backhaul connection > (non-WS connection) to the internet. Correct?**** > > *[Wei] Yeah.***** > > ** ** > > Besides, using DHCP method doesn=92t means IP network provider must have > some business relationship with WSDB DS provider, if the network provider > wants to provide master device with FQDN of WSDB DS it can use DHCP.**** > > ** ** > > mj> If the backhaul network operator is configuring his DHCP server to > send options to provision the WSDB DS then I assume he has some business > interest in doing so. What am I missing?**** > > *[Wei] I think there may be some relationship between network operator > and WSDB DS. But the reason why DHCP is mentioned here is because in the > LoST protocol DHCP is extended to provide LoST server=92s domain name to = the > LoST client.***** > > ** ** > > Thanks**** > > Mark**** > > ** ** > > Best Regards,**** > > Xinpeng.**** > > ** ** > > *From:* Mark Jones [mailto:mark@azu.ca ] > *Sent:* Wednesday, May 22, 2013 11:29 PM > *To:* Weixinpeng; paws@ietf.org > *Cc:* Peter McCann > *Subject:* RE: [paws] draft-wei-paws-database-discovery-01**** > > ** ** > > Hi Xinpeng,**** > > ** ** > > In section 3, you state:**** > > ** ** > > The URL or IP address of WSDB DS can be found by any method such as***= * > > DNS, DHCP, manually configuring etc, and it is out of scope of this***= * > > document.**** > > ** ** > > I=92m unclear on how the Master device obtains the URL of a trusted > discovery server unless there is some pre-configuration involved. I > understand that DNS could be used if the Master device is already > pre-configured with a preferred/home TVWS DS URL (or a preferred/home > domain that is then resolved with U-NAPTR) but I don=92t see how DHCP cou= ld > be used to bootstrap this information in the TVWS scenarios. Please could > you elaborate.**** > > ** ** > > Thanks**** > > Mark**** > > ** ** > > ** ** > > *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] > *On Behalf Of *Weixinpeng > *Sent:* May-21-13 9:11 PM > *To:* paws@ietf.org > *Cc:* Peter McCann > *Subject:* [paws] draft-wei-paws-database-discovery-01**** > > ** ** > > Hi all, **** > > I have uploaded a new version draft on database discovery. > Comments are welcomed.**** > > http://tools.ietf.org/html/draft-wei-paws-database-discovery-01.**** > > ** ** > > ** ** > > Xinpeng Wei**** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --047d7b10ca13d6757604de5ed7b9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Xinpeng, All,

Thanks for putting = this together.

It seems that discovery= involves two aspects:
=A0- Deployment of LoST servers, whi= ch also impacts discovery of LoST severs
=A0- Protocol (format of messages that is communicated)

The current document is placing deployment out= of scope, but does suggest that preconfiguration is a strategy.
That just leaves the protocol, which, may be characterized as:

=A0 1. Device sends request with its location
=A0 2. Server responds with a list of (name, uri) pairs

Given that this is relatively simple, should we just b= uild it into PAWS protocol itself?

For= example, the current revision (r05) of the PAWS protocol allows for the fo= llowing:

=A01. Device asks database for available sp= ectrum in a location outside the coverage area for the Databae
=A02. The Database returns OUTSIDE_COVERAGE error and MAY include a lis= t of (name, databaseUri) entries to "recommend" alternate databas= es

This provides almost the same capability.

Should we just add a ListDatabase to PA= WS?

-vince


On Thu, May 23, 2013 at 6:57 PM, Weixinp= eng <weixinpeng@huawei.com> wrote:

Hi Mark= ,

=A0=A0= =A0=A0=A0=A0=A0=A0 Please see comments inline. Thanks!=

= =A0

Best Re= gards,

Xinpeng= .

= =A0

= =A0

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; p= aws@ietf.org


Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

=A0

Hi Xinpeng,

=A0

Thank you for your responses. I have some further comments/questi= ons inline below (prefixed by mj>).

=A0

From: Weixinpeng [= mailto:weixinpen= g@huawei.com]
Sent: May-22-13 11:13 PM
To: Mark Jones; p= aws@ietf.org
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

=A0

Hi Mark= ,

=A0=A0= =A0=A0=A0=A0=A0=A0 Thanks for your feedback, and I think there are some iss= ues that I need to clarify.

=A0=A0= =A0=A0=A0=A0=A0=A0

=A0=A0= =A0=A0=A0=A0=A0=A0 we have to be clear that the discovery mechanism is prov= ided as an optional method that can help master device to find the correct = WSDB, which means the master device can get WSDB by, such as, pre-configuring of WSDB, provision etc.

= =A0

mj> Understood.

=A0

=A0=A0= =A0=A0=A0=A0=A0=A0 The dynamic discovery mechanism provides more convenient= for master device to find WSDB, for example, when a new WSDB is setup for = providing service or when some deployed WSDB goes down and never work.

=A0=A0= =A0=A0=A0=A0=A0=A0

mj> In this regard, DNS resolution would appear to be equally conv= enient mechanism to manage WSDB instances being commissioned or decommissio= ned. I view LoST as a kind of =93location-aware DNS=94 so I understand its applicability to discovery of the appropriate W= SDB. I still think the draft needs more information on how the Master devic= e finds its WSDB DS so that implementers understand if/when this optional d= iscovery method is applicable to their deployment.

[Wei] Yeah, because we cannot covey location information in DNS query = message, so DNS is inappropriate to find the WSDB. I think I will do more c= larification about how master device finds WSDB DS later.

=A0

=A0=A0= =A0=A0=A0=A0=A0=A0 About the DHCP you mentioned below, technically speaking= , there have been some extension of DHCP for supporting the provision of Lo= ST server, refer to RFC5223.

=A0

mj> I understand that the DHCP option specifying the LoST server w= ould be provided to the Master device when it initiated its backhaul connec= tion (non-WS connection) to the internet. Correct?

[Wei] Yeah.

=A0

Besides= , using DHCP method doesn=92t means IP network provider must have some busi= ness relationship with WSDB DS provider, if the network provider wants to p= rovide master device with FQDN of WSDB DS it can use DHCP.

= =A0

mj> If the backhaul network operator is configuring his DHCP serve= r to send options to provision the WSDB DS then I assume he has some busine= ss interest in doing so. What am I missing?

[Wei] I think there may be some relationship between network operator = and WSDB DS. But the reason why DHCP is mentioned here is because in the Lo= ST protocol DHCP is extended to provide LoST server=92s domain name to the LoST client.

=A0

Thanks

Mark

=A0

Best Re= gards,

Xinpeng= .

= =A0

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; p= aws@ietf.org
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01

=A0

Hi Xinpeng,

=A0

In section 3, you state:

=A0

= =A0=A0 The URL or IP address of WSDB DS can be found by any method such as<= u>

= =A0=A0 DNS, DHCP, manually configuring etc, and it is out of scope of this<= u>

= =A0=A0 document.

=A0

I=92m unclear on how the Master device obtains the URL of a trust= ed discovery server unless there is some pre-configuration involved. I unde= rstand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a p= referred/home domain that is then resolved with U-NAPTR) but I don=92t see = how DHCP could be used to bootstrap this information in the TVWS scenarios.= Please could you elaborate.

=A0

Thanks

Mark

=A0

=A0

From: paws-bounces@iet= f.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: paws@ietf.org=
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

=A0

Hi all,

=A0=A0=A0=A0=A0=A0=A0=A0 I have= uploaded a new version draft on database discovery. Comments are welcomed.=

http://tools.ietf.org/html/draft-wei-paws-database-discove= ry-01.

=A0

=A0

Xinpeng Wei


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




--
-vince
--047d7b10ca13d6757604de5ed7b9-- From brian.rosen@neustar.biz Wed Jun 5 05:36:59 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 1DFCA21F99CD for ; Wed, 5 Jun 2013 05:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.045 X-Spam-Level: X-Spam-Status: No, score=-6.045 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 5XnnJU73zeaZ for ; Wed, 5 Jun 2013 05:36:55 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id A475C21F99D4 for ; Wed, 5 Jun 2013 05:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370436270; x=1685777979; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=5vUewNd/wnVHbddvSWUMV+svGSRiql4D4I+KtEMf/Yg=; b=jSsVi1f0yM7JbGpyPz0Vka5kJQeIbwHj6YqMuhvyzW2NfUuqUqX7Cv0Iehw59u hAYl+NkdOow8ozsp44S5afrA== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.25810951; Wed, 05 Jun 2013 08:44:29 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Jun 2013 08:36:21 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Wed, 5 Jun 2013 08:36:19 -0400 From: "Rosen, Brian" To: Vincent Chen Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGw== Date: Wed, 5 Jun 2013 12:36:18 +0000 Message-ID: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: BJqzJzEhZmNQXA084s6aaw== Content-Type: multipart/alternative; boundary="_000_B80D7B77344240F3A7E82AFE24678105neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 12:36:59 -0000 --_000_B80D7B77344240F3A7E82AFE24678105neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The problem I see with this is that the database originally contacted (pres= umably configured directly or indirectly) is forever responsible for referr= als to the correct database. It provides no other service for the device. If I purchased a device in New York City and moved to London, the US databa= se has to refer me every time I try to register. Having a separate database whose job is to do that referral seems like a mo= re rational solution. Any device or service that wanted to participate in = that kind of "nomadic" operation could contribute to the cost of providing = the service. Cross subsidizing the U.S. database from the U.K. database fo= r the referral seems less likely to succeed. Brian On Jun 4, 2013, at 10:20 PM, Vincent Chen > wrote: Xinpeng, All, Thanks for putting this together. It seems that discovery involves two aspects: - Deployment of LoST servers, which also impacts discovery of LoST severs - Protocol (format of messages that is communicated) The current document is placing deployment out of scope, but does suggest t= hat preconfiguration is a strategy. That just leaves the protocol, which, may be characterized as: 1. Device sends request with its location 2. Server responds with a list of (name, uri) pairs Given that this is relatively simple, should we just build it into PAWS pro= tocol itself? For example, the current revision (r05) of the PAWS protocol allows for the= following: 1. Device asks database for available spectrum in a location outside the c= overage area for the Databae 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (= name, databaseUri) entries to "recommend" alternate databases This provides almost the same capability. Should we just add a ListDatabase to PAWS? -vince On Thu, May 23, 2013 at 6:57 PM, Weixinpeng > wrote: Hi Mark, Please see comments inline. Thanks! Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Thursday, May 23, 2013 10:31 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline= below (prefixed by mj>). From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: May-22-13 11:13 PM To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I= need to clarify. we have to be clear that the discovery mechanism is provided as an= optional method that can help master device to find the correct WSDB, whic= h means the master device can get WSDB by, such as, pre-configuring of WSDB= , provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for maste= r device to find WSDB, for example, when a new WSDB is setup for providing = service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient me= chanism to manage WSDB instances being commissioned or decommissioned. I vi= ew LoST as a kind of =93location-aware DNS=94 so I understand its applicabi= lity to discovery of the appropriate WSDB. I still think the draft needs mo= re information on how the Master device finds its WSDB DS so that implement= ers understand if/when this optional discovery method is applicable to thei= r deployment. [Wei] Yeah, because we cannot covey location information in DNS query messa= ge, so DNS is inappropriate to find the WSDB. I think I will do more clarif= ication about how master device finds WSDB DS later. About the DHCP you mentioned below, technically speaking, there ha= ve been some extension of DHCP for supporting the provision of LoST server,= refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be p= rovided to the Master device when it initiated its backhaul connection (non= -WS connection) to the internet. Correct? [Wei] Yeah. Besides, using DHCP method doesn=92t means IP network provider must have so= me business relationship with WSDB DS provider, if the network provider wan= ts to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send= options to provision the WSDB DS then I assume he has some business intere= st in doing so. What am I missing? [Wei] I think there may be some relationship between network operator and W= SDB DS. But the reason why DHCP is mentioned here is because in the LoST pr= otocol DHCP is extended to provide LoST server=92s domain name to the LoST = client. Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I=92m unclear on how the Master device obtains the URL of a trusted discove= ry server unless there is some pre-configuration involved. I understand tha= t DNS could be used if the Master device is already pre-configured with a p= referred/home TVWS DS URL (or a preferred/home domain that is then resolved= with U-NAPTR) but I don=92t see how DHCP could be used to bootstrap this i= nformation in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_B80D7B77344240F3A7E82AFE24678105neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <37F210748D3B8A45B05C6276A6102D8A@neustar.biz> Content-Transfer-Encoding: quoted-printable The problem I see with this is that the database originally contacted (pres= umably configured directly or indirectly) is forever responsible for referr= als to the correct database.  It provides no other service for the dev= ice.

If I purchased a device in New York City and moved to London, the US d= atabase has to refer me every time I try to register.

Having a separate database whose job is to do that referral seems like= a more rational solution.  Any device or service that wanted to parti= cipate in that kind of "nomadic" operation could contribute to th= e cost of providing the service.  Cross subsidizing the U.S. database from the U.K. database for the referral seems less likel= y to succeed.

Brian

On Jun 4, 2013, at 10:20 PM, Vincent Chen <vchen@google.com> wrote:

Xinpeng, All,

Thanks for putting this together.

It seems that discovery involves two aspects:
 - Deployment of LoST servers, which also impacts disc= overy of LoST severs
 - Protocol (format of messages that is communicated)<= /div>

The current document is placing deployment out of scope, bu= t does suggest that preconfiguration is a strategy.
That just leaves the protocol, which, may be characterized = as:

  1. Device sends request with its location
  2. Server responds with a list of (name, uri) pairs<= /div>

Given that this is relatively simple, should we just build = it into PAWS protocol itself?

For example, the current revision (r05) of the PAWS protoco= l allows for the following:

 1. Device asks database for available spectrum in a l= ocation outside the coverage area for the Databae
 2. The Database returns OUTSIDE_COVERAGE error and MA= Y include a list of (name, databaseUri) entries to "recommend" al= ternate databases

This provides almost the same capability.

Should we just add a ListDatabase to PAWS?

-vince


On Thu, May 23, 2013 at 6:57 PM, Weixinpeng <weixinpeng@h= uawei.com> wrote:

Hi Mark= ,

 &= nbsp;       Please see comments inline. Thank= s!

=  

Best Re= gards,

Xinpeng= .

=  

=  

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; p= aws@ietf.org


Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

 

Hi Xinpeng,

 

Thank you for your responses. I have some further comments/questi= ons inline below (prefixed by mj>).

 

From: Weixinpeng [= mailto:weixinpen= g@huawei.com]
Sent: May-22-13 11:13 PM
To: Mark Jones; p= aws@ietf.org
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

 

Hi Mark= ,

 &= nbsp;       Thanks for your feedback, and I t= hink there are some issues that I need to clarify.

 &= nbsp;      

 &= nbsp;       we have to be clear that the disc= overy mechanism is provided as an optional method that can help master devi= ce to find the correct WSDB, which means the master device can get WSDB by,= such as, pre-configuring of WSDB, provision etc.

=  

mj> Understood.

 

 &= nbsp;       The dynamic discovery mechanism p= rovides more convenient for master device to find WSDB, for example, when a= new WSDB is setup for providing service or when some deployed WSDB goes do= wn and never work.

 &= nbsp;      

mj> In this regard, DNS resolution would appear to be equally conv= enient mechanism to manage WSDB instances being commissioned or decommissio= ned. I view LoST as a kind of =93location-aware DNS=94 so I understand its applicability to discovery of the appropriate W= SDB. I still think the draft needs more information on how the Master devic= e finds its WSDB DS so that implementers understand if/when this optional d= iscovery method is applicable to their deployment.

[= Wei] Yeah, because we cannot covey location information in DNS query messag= e, so DNS is inappropriate to find the WSDB. I think I will do more clarifi= cation about how master device finds WSDB DS later.

 

 &= nbsp;       About the DHCP you mentioned belo= w, technically speaking, there have been some extension of DHCP for support= ing the provision of LoST server, refer to RFC5223.

 

mj> I understand that the DHCP option specifying the LoST server w= ould be provided to the Master device when it initiated its backhaul connec= tion (non-WS connection) to the internet. Correct?

[= Wei] Yeah.

 

Besides= , using DHCP method doesn=92t means IP network provider must have some busi= ness relationship with WSDB DS provider, if the network provider wants to p= rovide master device with FQDN of WSDB DS it can use DHCP.

=  

mj> If the backhaul network operator is configuring his DHCP serve= r to send options to provision the WSDB DS then I assume he has some busine= ss interest in doing so. What am I missing?

[= Wei] I think there may be some relationship between network operator and WS= DB DS. But the reason why DHCP is mentioned here is because in the LoST pro= tocol DHCP is extended to provide LoST server=92s domain name to the LoST client.

 

Thanks

Mark

 

Best Re= gards,

Xinpeng= .

=  

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; p= aws@ietf.org
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01

 

Hi Xinpeng,

 

In section 3, you state:

 

&= nbsp;  The URL or IP address of WSDB DS can be found by any method suc= h as

&= nbsp;  DNS, DHCP, manually configuring etc, and it is out of scope of = this

&= nbsp;  document.

 

I=92m unclear on how the Master device obtains the URL of a trust= ed discovery server unless there is some pre-configuration involved. I unde= rstand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a p= referred/home domain that is then resolved with U-NAPTR) but I don=92t see = how DHCP could be used to bootstrap this information in the TVWS scenarios.= Please could you elaborate.

 

Thanks

Mark

 

 

From: paws-bounces@iet= f.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: paws@ietf.org=
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

 

Hi all,

     &= nbsp;   I have uploaded a new version draft on database discovery= . Comments are welcomed.

http://tools.ietf.org/html/draft-wei-paws-database-discove= ry-01.

 

 

Xinpeng Wei


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




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

--_000_B80D7B77344240F3A7E82AFE24678105neustarbiz_-- From peter@spectrumbridge.com Wed Jun 5 06:00:50 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 ACBCB21F99CF for ; Wed, 5 Jun 2013 06:00:50 -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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37xh1t8UmSZC for ; Wed, 5 Jun 2013 06:00:46 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 0504D21F995B for ; Wed, 5 Jun 2013 06:00:45 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 5 Jun 2013 09:00:45 -0400 From: Peter Stanforth To: "Rosen, Brian" Date: Wed, 5 Jun 2013 09:00:40 -0400 Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5h7LCQ91AAatwKRJGZ1HdSxgij3A== Message-ID: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BBB5CA43FEC24EBF9E46DDB1816A1B99spectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 13:00:50 -0000 --_000_BBB5CA43FEC24EBF9E46DDB1816A1B99spectrumbridgecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnJpYW4uIFdoeSBkbyB5b3UgYXNzdW1lIGEgZGV2aWNlIHdpbGwgYWx3YXlzIGdvIGJhY2sgdG8g aXRzIG9yaWdpbmFsIERCIHJhdGhlciB0aGFuIHRoZSBvbmUgaXQgbGFzdCByZWdpc3RlcmVkIHdp dGguIFRoZSBsYXR0ZXIgc2VlbXMgbW9yZSBsaWtlbHksIGFuZCBtb3JlIGxvZ2ljYWwsIHRvIG1l DQpQZXRlciBTLg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIEp1biA1LCAyMDEzLCBhdCA4 OjM3IEFNLCAiUm9zZW4sIEJyaWFuIiA8QnJpYW4uUm9zZW5AbmV1c3Rhci5iaXo8bWFpbHRvOkJy aWFuLlJvc2VuQG5ldXN0YXIuYml6Pj4gd3JvdGU6DQoNClRoZSBwcm9ibGVtIEkgc2VlIHdpdGgg dGhpcyBpcyB0aGF0IHRoZSBkYXRhYmFzZSBvcmlnaW5hbGx5IGNvbnRhY3RlZCAocHJlc3VtYWJs eSBjb25maWd1cmVkIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkpIGlzIGZvcmV2ZXIgcmVzcG9uc2li bGUgZm9yIHJlZmVycmFscyB0byB0aGUgY29ycmVjdCBkYXRhYmFzZS4gIEl0IHByb3ZpZGVzIG5v IG90aGVyIHNlcnZpY2UgZm9yIHRoZSBkZXZpY2UuDQoNCklmIEkgcHVyY2hhc2VkIGEgZGV2aWNl IGluIE5ldyBZb3JrIENpdHkgYW5kIG1vdmVkIHRvIExvbmRvbiwgdGhlIFVTIGRhdGFiYXNlIGhh cyB0byByZWZlciBtZSBldmVyeSB0aW1lIEkgdHJ5IHRvIHJlZ2lzdGVyLg0KDQpIYXZpbmcgYSBz ZXBhcmF0ZSBkYXRhYmFzZSB3aG9zZSBqb2IgaXMgdG8gZG8gdGhhdCByZWZlcnJhbCBzZWVtcyBs aWtlIGEgbW9yZSByYXRpb25hbCBzb2x1dGlvbi4gIEFueSBkZXZpY2Ugb3Igc2VydmljZSB0aGF0 IHdhbnRlZCB0byBwYXJ0aWNpcGF0ZSBpbiB0aGF0IGtpbmQgb2YgIm5vbWFkaWMiIG9wZXJhdGlv biBjb3VsZCBjb250cmlidXRlIHRvIHRoZSBjb3N0IG9mIHByb3ZpZGluZyB0aGUgc2VydmljZS4g IENyb3NzIHN1YnNpZGl6aW5nIHRoZSBVLlMuIGRhdGFiYXNlIGZyb20gdGhlIFUuSy4gZGF0YWJh c2UgZm9yIHRoZSByZWZlcnJhbCBzZWVtcyBsZXNzIGxpa2VseSB0byBzdWNjZWVkLg0KDQpCcmlh bg0KDQpPbiBKdW4gNCwgMjAxMywgYXQgMTA6MjAgUE0sIFZpbmNlbnQgQ2hlbiA8dmNoZW5AZ29v Z2xlLmNvbTxtYWlsdG86dmNoZW5AZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQpYaW5wZW5nLCBBbGws DQoNClRoYW5rcyBmb3IgcHV0dGluZyB0aGlzIHRvZ2V0aGVyLg0KDQpJdCBzZWVtcyB0aGF0IGRp c2NvdmVyeSBpbnZvbHZlcyB0d28gYXNwZWN0czoNCiAtIERlcGxveW1lbnQgb2YgTG9TVCBzZXJ2 ZXJzLCB3aGljaCBhbHNvIGltcGFjdHMgZGlzY292ZXJ5IG9mIExvU1Qgc2V2ZXJzDQogLSBQcm90 b2NvbCAoZm9ybWF0IG9mIG1lc3NhZ2VzIHRoYXQgaXMgY29tbXVuaWNhdGVkKQ0KDQpUaGUgY3Vy cmVudCBkb2N1bWVudCBpcyBwbGFjaW5nIGRlcGxveW1lbnQgb3V0IG9mIHNjb3BlLCBidXQgZG9l cyBzdWdnZXN0IHRoYXQgcHJlY29uZmlndXJhdGlvbiBpcyBhIHN0cmF0ZWd5Lg0KVGhhdCBqdXN0 IGxlYXZlcyB0aGUgcHJvdG9jb2wsIHdoaWNoLCBtYXkgYmUgY2hhcmFjdGVyaXplZCBhczoNCg0K ICAxLiBEZXZpY2Ugc2VuZHMgcmVxdWVzdCB3aXRoIGl0cyBsb2NhdGlvbg0KICAyLiBTZXJ2ZXIg cmVzcG9uZHMgd2l0aCBhIGxpc3Qgb2YgKG5hbWUsIHVyaSkgcGFpcnMNCg0KR2l2ZW4gdGhhdCB0 aGlzIGlzIHJlbGF0aXZlbHkgc2ltcGxlLCBzaG91bGQgd2UganVzdCBidWlsZCBpdCBpbnRvIFBB V1MgcHJvdG9jb2wgaXRzZWxmPw0KDQpGb3IgZXhhbXBsZSwgdGhlIGN1cnJlbnQgcmV2aXNpb24g KHIwNSkgb2YgdGhlIFBBV1MgcHJvdG9jb2wgYWxsb3dzIGZvciB0aGUgZm9sbG93aW5nOg0KDQog MS4gRGV2aWNlIGFza3MgZGF0YWJhc2UgZm9yIGF2YWlsYWJsZSBzcGVjdHJ1bSBpbiBhIGxvY2F0 aW9uIG91dHNpZGUgdGhlIGNvdmVyYWdlIGFyZWEgZm9yIHRoZSBEYXRhYmFlDQogMi4gVGhlIERh dGFiYXNlIHJldHVybnMgT1VUU0lERV9DT1ZFUkFHRSBlcnJvciBhbmQgTUFZIGluY2x1ZGUgYSBs aXN0IG9mIChuYW1lLCBkYXRhYmFzZVVyaSkgZW50cmllcyB0byAicmVjb21tZW5kIiBhbHRlcm5h dGUgZGF0YWJhc2VzDQoNClRoaXMgcHJvdmlkZXMgYWxtb3N0IHRoZSBzYW1lIGNhcGFiaWxpdHku DQoNClNob3VsZCB3ZSBqdXN0IGFkZCBhIExpc3REYXRhYmFzZSB0byBQQVdTPw0KDQotdmluY2UN Cg0KDQpPbiBUaHUsIE1heSAyMywgMjAxMyBhdCA2OjU3IFBNLCBXZWl4aW5wZW5nIDx3ZWl4aW5w ZW5nQGh1YXdlaS5jb208bWFpbHRvOndlaXhpbnBlbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KSGkg TWFyaywNCiAgICAgICAgIFBsZWFzZSBzZWUgY29tbWVudHMgaW5saW5lLiBUaGFua3MhDQoNCkJl c3QgUmVnYXJkcywNClhpbnBlbmcuDQoNCg0KRnJvbTogTWFyayBKb25lcyBbbWFpbHRvOm1hcmtA YXp1LmNhPG1haWx0bzptYXJrQGF6dS5jYT5dDQpTZW50OiBUaHVyc2RheSwgTWF5IDIzLCAyMDEz IDEwOjMxIFBNDQpUbzogV2VpeGlucGVuZzsgcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRm Lm9yZz4NCg0KQ2M6IFBldGVyIE1jQ2FubjsgWmh1bGVpIChBKQ0KU3ViamVjdDogUkU6IFtwYXdz XSBkcmFmdC13ZWktcGF3cy1kYXRhYmFzZS1kaXNjb3ZlcnktMDENCg0KDQpIaSBYaW5wZW5nLA0K DQpUaGFuayB5b3UgZm9yIHlvdXIgcmVzcG9uc2VzLiBJIGhhdmUgc29tZSBmdXJ0aGVyIGNvbW1l bnRzL3F1ZXN0aW9ucyBpbmxpbmUgYmVsb3cgKHByZWZpeGVkIGJ5IG1qPikuDQoNCkZyb206IFdl aXhpbnBlbmcgW21haWx0bzp3ZWl4aW5wZW5nQGh1YXdlaS5jb21dDQpTZW50OiBNYXktMjItMTMg MTE6MTMgUE0NClRvOiBNYXJrIEpvbmVzOyBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYu b3JnPg0KQ2M6IFBldGVyIE1jQ2FubjsgWmh1bGVpIChBKQ0KU3ViamVjdDogUkU6IFtwYXdzXSBk cmFmdC13ZWktcGF3cy1kYXRhYmFzZS1kaXNjb3ZlcnktMDENCg0KSGkgTWFyaywNCiAgICAgICAg IFRoYW5rcyBmb3IgeW91ciBmZWVkYmFjaywgYW5kIEkgdGhpbmsgdGhlcmUgYXJlIHNvbWUgaXNz dWVzIHRoYXQgSSBuZWVkIHRvIGNsYXJpZnkuDQoNCiAgICAgICAgIHdlIGhhdmUgdG8gYmUgY2xl YXIgdGhhdCB0aGUgZGlzY292ZXJ5IG1lY2hhbmlzbSBpcyBwcm92aWRlZCBhcyBhbiBvcHRpb25h bCBtZXRob2QgdGhhdCBjYW4gaGVscCBtYXN0ZXIgZGV2aWNlIHRvIGZpbmQgdGhlIGNvcnJlY3Qg V1NEQiwgd2hpY2ggbWVhbnMgdGhlIG1hc3RlciBkZXZpY2UgY2FuIGdldCBXU0RCIGJ5LCBzdWNo IGFzLCBwcmUtY29uZmlndXJpbmcgb2YgV1NEQiwgcHJvdmlzaW9uIGV0Yy4NCg0KbWo+IFVuZGVy c3Rvb2QuDQoNCiAgICAgICAgIFRoZSBkeW5hbWljIGRpc2NvdmVyeSBtZWNoYW5pc20gcHJvdmlk ZXMgbW9yZSBjb252ZW5pZW50IGZvciBtYXN0ZXIgZGV2aWNlIHRvIGZpbmQgV1NEQiwgZm9yIGV4 YW1wbGUsIHdoZW4gYSBuZXcgV1NEQiBpcyBzZXR1cCBmb3IgcHJvdmlkaW5nIHNlcnZpY2Ugb3Ig d2hlbiBzb21lIGRlcGxveWVkIFdTREIgZ29lcyBkb3duIGFuZCBuZXZlciB3b3JrLg0KDQptaj4g SW4gdGhpcyByZWdhcmQsIEROUyByZXNvbHV0aW9uIHdvdWxkIGFwcGVhciB0byBiZSBlcXVhbGx5 IGNvbnZlbmllbnQgbWVjaGFuaXNtIHRvIG1hbmFnZSBXU0RCIGluc3RhbmNlcyBiZWluZyBjb21t aXNzaW9uZWQgb3IgZGVjb21taXNzaW9uZWQuIEkgdmlldyBMb1NUIGFzIGEga2luZCBvZiDigJxs b2NhdGlvbi1hd2FyZSBETlPigJ0gc28gSSB1bmRlcnN0YW5kIGl0cyBhcHBsaWNhYmlsaXR5IHRv IGRpc2NvdmVyeSBvZiB0aGUgYXBwcm9wcmlhdGUgV1NEQi4gSSBzdGlsbCB0aGluayB0aGUgZHJh ZnQgbmVlZHMgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cgdGhlIE1hc3RlciBkZXZpY2UgZmluZHMg aXRzIFdTREIgRFMgc28gdGhhdCBpbXBsZW1lbnRlcnMgdW5kZXJzdGFuZCBpZi93aGVuIHRoaXMg b3B0aW9uYWwgZGlzY292ZXJ5IG1ldGhvZCBpcyBhcHBsaWNhYmxlIHRvIHRoZWlyIGRlcGxveW1l bnQuDQpbV2VpXSBZZWFoLCBiZWNhdXNlIHdlIGNhbm5vdCBjb3ZleSBsb2NhdGlvbiBpbmZvcm1h dGlvbiBpbiBETlMgcXVlcnkgbWVzc2FnZSwgc28gRE5TIGlzIGluYXBwcm9wcmlhdGUgdG8gZmlu ZCB0aGUgV1NEQi4gSSB0aGluayBJIHdpbGwgZG8gbW9yZSBjbGFyaWZpY2F0aW9uIGFib3V0IGhv dyBtYXN0ZXIgZGV2aWNlIGZpbmRzIFdTREIgRFMgbGF0ZXIuDQoNCiAgICAgICAgIEFib3V0IHRo ZSBESENQIHlvdSBtZW50aW9uZWQgYmVsb3csIHRlY2huaWNhbGx5IHNwZWFraW5nLCB0aGVyZSBo YXZlIGJlZW4gc29tZSBleHRlbnNpb24gb2YgREhDUCBmb3Igc3VwcG9ydGluZyB0aGUgcHJvdmlz aW9uIG9mIExvU1Qgc2VydmVyLCByZWZlciB0byBSRkM1MjIzLg0KDQptaj4gSSB1bmRlcnN0YW5k IHRoYXQgdGhlIERIQ1Agb3B0aW9uIHNwZWNpZnlpbmcgdGhlIExvU1Qgc2VydmVyIHdvdWxkIGJl IHByb3ZpZGVkIHRvIHRoZSBNYXN0ZXIgZGV2aWNlIHdoZW4gaXQgaW5pdGlhdGVkIGl0cyBiYWNr aGF1bCBjb25uZWN0aW9uIChub24tV1MgY29ubmVjdGlvbikgdG8gdGhlIGludGVybmV0LiBDb3Jy ZWN0Pw0KW1dlaV0gWWVhaC4NCg0KQmVzaWRlcywgdXNpbmcgREhDUCBtZXRob2QgZG9lc27igJl0 IG1lYW5zIElQIG5ldHdvcmsgcHJvdmlkZXIgbXVzdCBoYXZlIHNvbWUgYnVzaW5lc3MgcmVsYXRp b25zaGlwIHdpdGggV1NEQiBEUyBwcm92aWRlciwgaWYgdGhlIG5ldHdvcmsgcHJvdmlkZXIgd2Fu dHMgdG8gcHJvdmlkZSBtYXN0ZXIgZGV2aWNlIHdpdGggRlFETiBvZiBXU0RCIERTIGl0IGNhbiB1 c2UgREhDUC4NCg0KbWo+IElmIHRoZSBiYWNraGF1bCBuZXR3b3JrIG9wZXJhdG9yIGlzIGNvbmZp Z3VyaW5nIGhpcyBESENQIHNlcnZlciB0byBzZW5kIG9wdGlvbnMgdG8gcHJvdmlzaW9uIHRoZSBX U0RCIERTIHRoZW4gSSBhc3N1bWUgaGUgaGFzIHNvbWUgYnVzaW5lc3MgaW50ZXJlc3QgaW4gZG9p bmcgc28uIFdoYXQgYW0gSSBtaXNzaW5nPw0KW1dlaV0gSSB0aGluayB0aGVyZSBtYXkgYmUgc29t ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBuZXR3b3JrIG9wZXJhdG9yIGFuZCBXU0RCIERTLiBCdXQg dGhlIHJlYXNvbiB3aHkgREhDUCBpcyBtZW50aW9uZWQgaGVyZSBpcyBiZWNhdXNlIGluIHRoZSBM b1NUIHByb3RvY29sIERIQ1AgaXMgZXh0ZW5kZWQgdG8gcHJvdmlkZSBMb1NUIHNlcnZlcuKAmXMg ZG9tYWluIG5hbWUgdG8gdGhlIExvU1QgY2xpZW50Lg0KDQpUaGFua3MNCk1hcmsNCg0KQmVzdCBS ZWdhcmRzLA0KWGlucGVuZy4NCg0KRnJvbTogTWFyayBKb25lcyBbbWFpbHRvOm1hcmtAYXp1LmNh XQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTMgMTE6MjkgUE0NClRvOiBXZWl4aW5wZW5n OyBwYXdzQGlldGYub3JnPG1haWx0bzpwYXdzQGlldGYub3JnPg0KQ2M6IFBldGVyIE1jQ2Fubg0K U3ViamVjdDogUkU6IFtwYXdzXSBkcmFmdC13ZWktcGF3cy1kYXRhYmFzZS1kaXNjb3ZlcnktMDEN Cg0KSGkgWGlucGVuZywNCg0KSW4gc2VjdGlvbiAzLCB5b3Ugc3RhdGU6DQoNCiAgIFRoZSBVUkwg b3IgSVAgYWRkcmVzcyBvZiBXU0RCIERTIGNhbiBiZSBmb3VuZCBieSBhbnkgbWV0aG9kIHN1Y2gg YXMNCiAgIEROUywgREhDUCwgbWFudWFsbHkgY29uZmlndXJpbmcgZXRjLCBhbmQgaXQgaXMgb3V0 IG9mIHNjb3BlIG9mIHRoaXMNCiAgIGRvY3VtZW50Lg0KDQpJ4oCZbSB1bmNsZWFyIG9uIGhvdyB0 aGUgTWFzdGVyIGRldmljZSBvYnRhaW5zIHRoZSBVUkwgb2YgYSB0cnVzdGVkIGRpc2NvdmVyeSBz ZXJ2ZXIgdW5sZXNzIHRoZXJlIGlzIHNvbWUgcHJlLWNvbmZpZ3VyYXRpb24gaW52b2x2ZWQuIEkg dW5kZXJzdGFuZCB0aGF0IEROUyBjb3VsZCBiZSB1c2VkIGlmIHRoZSBNYXN0ZXIgZGV2aWNlIGlz IGFscmVhZHkgcHJlLWNvbmZpZ3VyZWQgd2l0aCBhIHByZWZlcnJlZC9ob21lIFRWV1MgRFMgVVJM IChvciBhIHByZWZlcnJlZC9ob21lIGRvbWFpbiB0aGF0IGlzIHRoZW4gcmVzb2x2ZWQgd2l0aCBV LU5BUFRSKSBidXQgSSBkb27igJl0IHNlZSBob3cgREhDUCBjb3VsZCBiZSB1c2VkIHRvIGJvb3Rz dHJhcCB0aGlzIGluZm9ybWF0aW9uIGluIHRoZSBUVldTIHNjZW5hcmlvcy4gUGxlYXNlIGNvdWxk IHlvdSBlbGFib3JhdGUuDQoNClRoYW5rcw0KTWFyaw0KDQoNCkZyb206IHBhd3MtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOnBhd3MtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFdlaXhpbnBlbmcNClNlbnQ6IE1heS0yMS0xMyA5OjEx IFBNDQpUbzogcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0BpZXRmLm9yZz4NCkNjOiBQZXRlciBN Y0Nhbm4NClN1YmplY3Q6IFtwYXdzXSBkcmFmdC13ZWktcGF3cy1kYXRhYmFzZS1kaXNjb3Zlcnkt MDENCg0KSGkgYWxsLA0KICAgICAgICAgSSBoYXZlIHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gZHJh ZnQgb24gZGF0YWJhc2UgZGlzY292ZXJ5LiBDb21tZW50cyBhcmUgd2VsY29tZWQuDQpodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWktcGF3cy1kYXRhYmFzZS1kaXNjb3ZlcnktMDEu DQoNCg0KWGlucGVuZyBXZWkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnBhd3MgbWFpbGluZyBsaXN0DQpwYXdzQGlldGYub3JnPG1haWx0bzpwYXdz QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzDQoN Cg0KDQoNCi0tDQotdmluY2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpwYXdzIG1haWxpbmcgbGlzdA0KcGF3c0BpZXRmLm9yZzxtYWlsdG86cGF3c0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWls aW5nIGxpc3QNCnBhd3NAaWV0Zi5vcmc8bWFpbHRvOnBhd3NAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MNCg== --_000_BBB5CA43FEC24EBF9E46DDB1816A1B99spectrumbridgecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+QnJpYW4u IFdoeSBkbyB5b3UgYXNzdW1lIGEgZGV2aWNlIHdpbGwgYWx3YXlzIGdvIGJhY2sgdG8gaXRzIG9y aWdpbmFsIERCIHJhdGhlciB0aGFuIHRoZSBvbmUgaXQgbGFzdCByZWdpc3RlcmVkIHdpdGguIFRo ZSBsYXR0ZXIgc2VlbXMgbW9yZSBsaWtlbHksIGFuZCBtb3JlIGxvZ2ljYWwsIHRvIG1lPC9kaXY+ PGRpdj5QZXRlciBTLjwvZGl2PjxkaXY+PGJyPlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rpdj48ZGl2 Pjxicj5PbiBKdW4gNSwgMjAxMywgYXQgODozNyBBTSwgIlJvc2VuLCBCcmlhbiIgJmx0OzxhIGhy ZWY9Im1haWx0bzpCcmlhbi5Sb3NlbkBuZXVzdGFyLmJpeiI+QnJpYW4uUm9zZW5AbmV1c3Rhci5i aXo8L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxk aXY+DQoNCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PVdpbmRvd3MtMTI1MiI+DQoNCg0KVGhlIHByb2JsZW0gSSBzZWUgd2l0aCB0aGlz IGlzIHRoYXQgdGhlIGRhdGFiYXNlIG9yaWdpbmFsbHkgY29udGFjdGVkIChwcmVzdW1hYmx5IGNv bmZpZ3VyZWQgZGlyZWN0bHkgb3IgaW5kaXJlY3RseSkgaXMgZm9yZXZlciByZXNwb25zaWJsZSBm b3IgcmVmZXJyYWxzIHRvIHRoZSBjb3JyZWN0IGRhdGFiYXNlLiAmbmJzcDtJdCBwcm92aWRlcyBu byBvdGhlciBzZXJ2aWNlIGZvciB0aGUgZGV2aWNlLg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ SWYgSSBwdXJjaGFzZWQgYSBkZXZpY2UgaW4gTmV3IFlvcmsgQ2l0eSBhbmQgbW92ZWQgdG8gTG9u ZG9uLCB0aGUgVVMgZGF0YWJhc2UgaGFzIHRvIHJlZmVyIG1lIGV2ZXJ5IHRpbWUgSSB0cnkgdG8g cmVnaXN0ZXIuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5IYXZpbmcgYSBzZXBhcmF0 ZSBkYXRhYmFzZSB3aG9zZSBqb2IgaXMgdG8gZG8gdGhhdCByZWZlcnJhbCBzZWVtcyBsaWtlIGEg bW9yZSByYXRpb25hbCBzb2x1dGlvbi4gJm5ic3A7QW55IGRldmljZSBvciBzZXJ2aWNlIHRoYXQg d2FudGVkIHRvIHBhcnRpY2lwYXRlIGluIHRoYXQga2luZCBvZiAibm9tYWRpYyIgb3BlcmF0aW9u IGNvdWxkIGNvbnRyaWJ1dGUgdG8gdGhlIGNvc3Qgb2YgcHJvdmlkaW5nIHRoZSBzZXJ2aWNlLiAm bmJzcDtDcm9zcyBzdWJzaWRpemluZw0KIHRoZSBVLlMuIGRhdGFiYXNlIGZyb20gdGhlIFUuSy4g ZGF0YWJhc2UgZm9yIHRoZSByZWZlcnJhbCBzZWVtcyBsZXNzIGxpa2VseSB0byBzdWNjZWVkLjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QnJpYW48L2Rpdj4NCjxkaXY+PGJyPg0KPGRp dj4NCjxkaXY+T24gSnVuIDQsIDIwMTMsIGF0IDEwOjIwIFBNLCBWaW5jZW50IENoZW4gJmx0Ozxh IGhyZWY9Im1haWx0bzp2Y2hlbkBnb29nbGUuY29tIj52Y2hlbkBnb29nbGUuY29tPC9hPiZndDsg d3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj5YaW5wZW5nLCBBbGwsDQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iIj5UaGFua3MgZm9yIHB1dHRpbmcgdGhpcyB0b2dl dGhlci48L2Rpdj4NCjxkaXYgc3R5bGU9IiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSIiPkl0 IHNlZW1zIHRoYXQgZGlzY292ZXJ5IGludm9sdmVzIHR3byBhc3BlY3RzOjwvZGl2Pg0KPGRpdiBz dHlsZT0iIj4mbmJzcDstIERlcGxveW1lbnQgb2YgTG9TVCBzZXJ2ZXJzLCB3aGljaCBhbHNvIGlt cGFjdHMgZGlzY292ZXJ5IG9mIExvU1Qgc2V2ZXJzPC9kaXY+DQo8ZGl2IHN0eWxlPSIiPiZuYnNw Oy0gUHJvdG9jb2wgKGZvcm1hdCBvZiBtZXNzYWdlcyB0aGF0IGlzIGNvbW11bmljYXRlZCk8L2Rp dj4NCjxkaXYgc3R5bGU9IiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSIiPlRoZSBjdXJyZW50 IGRvY3VtZW50IGlzIHBsYWNpbmcgZGVwbG95bWVudCBvdXQgb2Ygc2NvcGUsIGJ1dCBkb2VzIHN1 Z2dlc3QgdGhhdCBwcmVjb25maWd1cmF0aW9uIGlzIGEgc3RyYXRlZ3kuPC9kaXY+DQo8ZGl2IHN0 eWxlPSIiPlRoYXQganVzdCBsZWF2ZXMgdGhlIHByb3RvY29sLCB3aGljaCwgbWF5IGJlIGNoYXJh Y3Rlcml6ZWQgYXM6PC9kaXY+DQo8ZGl2IHN0eWxlPSIiPjxicj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iIj4mbmJzcDsgMS4gRGV2aWNlIHNlbmRzIHJlcXVlc3Qgd2l0aCBpdHMgbG9jYXRpb248L2Rp dj4NCjxkaXYgc3R5bGU9IiI+Jm5ic3A7IDIuIFNlcnZlciByZXNwb25kcyB3aXRoIGEgbGlzdCBv ZiAobmFtZSwgdXJpKSBwYWlyczwvZGl2Pg0KPGRpdiBzdHlsZT0iIj48YnI+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9IiI+R2l2ZW4gdGhhdCB0aGlzIGlzIHJlbGF0aXZlbHkgc2ltcGxlLCBzaG91bGQg d2UganVzdCBidWlsZCBpdCBpbnRvIFBBV1MgcHJvdG9jb2wgaXRzZWxmPzwvZGl2Pg0KPGRpdiBz dHlsZT0iIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IiI+Rm9yIGV4YW1wbGUsIHRoZSBjdXJy ZW50IHJldmlzaW9uIChyMDUpIG9mIHRoZSBQQVdTIHByb3RvY29sIGFsbG93cyBmb3IgdGhlIGZv bGxvd2luZzo8L2Rpdj4NCjxkaXYgc3R5bGU9IiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSIi PiZuYnNwOzEuIERldmljZSBhc2tzIGRhdGFiYXNlIGZvciBhdmFpbGFibGUgc3BlY3RydW0gaW4g YSBsb2NhdGlvbiBvdXRzaWRlIHRoZSBjb3ZlcmFnZSBhcmVhIGZvciB0aGUgRGF0YWJhZTwvZGl2 Pg0KPGRpdiBzdHlsZT0iIj4mbmJzcDsyLiBUaGUgRGF0YWJhc2UgcmV0dXJucyBPVVRTSURFX0NP VkVSQUdFIGVycm9yIGFuZCBNQVkgaW5jbHVkZSBhIGxpc3Qgb2YgKG5hbWUsIGRhdGFiYXNlVXJp KSBlbnRyaWVzIHRvICJyZWNvbW1lbmQiIGFsdGVybmF0ZSBkYXRhYmFzZXM8L2Rpdj4NCjxkaXYg c3R5bGU9IiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSIiPlRoaXMgcHJvdmlkZXMgYWxtb3N0 IHRoZSBzYW1lIGNhcGFiaWxpdHkuPC9kaXY+DQo8ZGl2IHN0eWxlPSIiPjxicj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iIj5TaG91bGQgd2UganVzdCBhZGQgYSBMaXN0RGF0YWJhc2UgdG8gUEFXUz88 L2Rpdj4NCjxkaXYgc3R5bGU9IiI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSIiPi12aW5jZTwv ZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGJyPg0KPGRpdiBj bGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgTWF5IDIzLCAyMDEzIGF0IDY6NTcgUE0sIFdlaXhp bnBlbmcgPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzp3ZWl4aW5wZW5nQGh1 YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj53ZWl4aW5wZW5nQGh1YXdlaS5jb208L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0i bWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0 OjFleCI+DQo8ZGl2IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiMxZjQ5N2QiPkhpIE1hcmssPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMWY0OTdkIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGxlYXNlIHNlZSBjb21t ZW50cyBpbmxpbmUuIFRoYW5rcyE8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxZjQ5N2QiPjx1Pjwv dT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+QmVzdCBSZWdhcmRzLDx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFmNDk3ZCI+WGlucGVuZy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxZjQ5 N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5 bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gTWFyayBKb25lcyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptYXJrQGF6dS5jYSIg dGFyZ2V0PSJfYmxhbmsiPm1hcmtAYXp1LmNhPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVy c2RheSwgTWF5IDIzLCAyMDEzIDEwOjMxIFBNPGJyPg0KPGI+VG86PC9iPiBXZWl4aW5wZW5nOyA8 YSBocmVmPSJtYWlsdG86cGF3c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBhd3NAaWV0Zi5v cmc8L2E+PC9zcGFuPjwvcD4NCjxkaXYgY2xhc3M9ImltIj48YnI+DQo8Yj5DYzo8L2I+IFBldGVy IE1jQ2FubjsgWmh1bGVpIChBKTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3Bhd3NdIGRyYWZ0 LXdlaS1wYXdzLWRhdGFiYXNlLWRpc2NvdmVyeS0wMTx1PjwvdT48dT48L3U+PC9kaXY+DQo8ZGl2 PjxiciBjbGFzcz0id2Via2l0LWJsb2NrLXBsYWNlaG9sZGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9ImltIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0 IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PHU+PC91PiZuYnNw Ozx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPkhpIFhpbnBlbmcsPHU+ PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJz cDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMWY0OTdkIj5UaGFuayB5b3UgZm9y IHlvdXIgcmVzcG9uc2VzLiBJIGhhdmUgc29tZSBmdXJ0aGVyIGNvbW1lbnRzL3F1ZXN0aW9ucyBp bmxpbmUgYmVsb3cgKDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Y29sb3I6cmVkIj5wcmVmaXhlZCBieSBtaiZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t Q0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPikuPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXYgY2xhc3M9 ImltIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNi NWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gV2VpeGlucGVuZyBbPGEgaHJlZj0ibWFpbHRv OndlaXhpbnBlbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzp3ZWl4aW5wZW5n QGh1YXdlaS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1heS0yMi0xMyAxMToxMyBQTTxi cj4NCjxiPlRvOjwvYj4gTWFyayBKb25lczsgPGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gUGV0ZXIg TWNDYW5uOyBaaHVsZWkgKEEpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbcGF3c10gZHJhZnQt d2VpLXBhd3MtZGF0YWJhc2UtZGlzY292ZXJ5LTAxPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0i dGV4dC1hbGlnbjpsZWZ0Ij48c3BhbiBsYW5nPSJFTi1DQSI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMWY0OTdkIj5IaSBNYXJrLDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYW5rcyBm b3IgeW91ciBmZWVkYmFjaywgYW5kIEkgdGhpbmsgdGhlcmUgYXJlIHNvbWUgaXNzdWVzIHRoYXQg SSBuZWVkIHRvIGNsYXJpZnkuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMWY0OTdkIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgd2UgaGF2ZSB0byBiZSBjbGVhciB0aGF0IHRoZSBkaXNjb3ZlcnkgbWVjaGFuaXNt IGlzIHByb3ZpZGVkIGFzIGFuIG9wdGlvbmFsIG1ldGhvZCB0aGF0IGNhbiBoZWxwIG1hc3RlciBk ZXZpY2UgdG8gZmluZCB0aGUgY29ycmVjdCBXU0RCLCB3aGljaCBtZWFucyB0aGUgbWFzdGVyIGRl dmljZSBjYW4gZ2V0IFdTREIgYnksIHN1Y2gNCiBhcywgcHJlLWNvbmZpZ3VyaW5nIG9mIFdTREIs IHByb3Zpc2lvbiBldGMuIDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+PHU+PC91PiZu YnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOnJlZCI+bWomZ3Q7IFVuZGVyc3Rv b2QuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPjx1Pjwv dT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoZSBkeW5hbWljIGRpc2NvdmVyeSBtZWNoYW5pc20g cHJvdmlkZXMgbW9yZSBjb252ZW5pZW50IGZvciBtYXN0ZXIgZGV2aWNlIHRvIGZpbmQgV1NEQiwg Zm9yIGV4YW1wbGUsIHdoZW4gYSBuZXcgV1NEQiBpcyBzZXR1cCBmb3IgcHJvdmlkaW5nIHNlcnZp Y2Ugb3Igd2hlbiBzb21lIGRlcGxveWVkIFdTREIgZ29lcyBkb3duDQogYW5kIG5ldmVyIHdvcmsu PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2NvbG9yOnJlZCI+bWomZ3Q7IEluIHRoaXMgcmVnYXJkLCBETlMgcmVzb2x1dGlvbiB3b3VsZCBh cHBlYXIgdG8gYmUgZXF1YWxseSBjb252ZW5pZW50IG1lY2hhbmlzbSB0byBtYW5hZ2UgV1NEQiBp bnN0YW5jZXMgYmVpbmcgY29tbWlzc2lvbmVkIG9yIGRlY29tbWlzc2lvbmVkLiBJIHZpZXcgTG9T VCBhcyBhIGtpbmQgb2Yg4oCcbG9jYXRpb24tYXdhcmUNCiBETlPigJ0gc28gSSB1bmRlcnN0YW5k IGl0cyBhcHBsaWNhYmlsaXR5IHRvIGRpc2NvdmVyeSBvZiB0aGUgYXBwcm9wcmlhdGUgV1NEQi4g SSBzdGlsbCB0aGluayB0aGUgZHJhZnQgbmVlZHMgbW9yZSBpbmZvcm1hdGlvbiBvbiBob3cgdGhl IE1hc3RlciBkZXZpY2UgZmluZHMgaXRzIFdTREIgRFMgc28gdGhhdCBpbXBsZW1lbnRlcnMgdW5k ZXJzdGFuZCBpZi93aGVuIHRoaXMgb3B0aW9uYWwgZGlzY292ZXJ5IG1ldGhvZCBpcyBhcHBsaWNh YmxlIHRvIHRoZWlyDQogZGVwbG95bWVudC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFmNDk3ZCI+W1dlaV0gWWVhaCwgYmVjYXVzZSB3ZSBjYW5ub3QgY292ZXkgbG9jYXRp b24gaW5mb3JtYXRpb24gaW4gRE5TIHF1ZXJ5IG1lc3NhZ2UsIHNvIEROUyBpcyBpbmFwcHJvcHJp YXRlIHRvIGZpbmQgdGhlIFdTREIuIEkgdGhpbmsgSSB3aWxsIGRvIG1vcmUgY2xhcmlmaWNhdGlv biBhYm91dCBob3cgbWFzdGVyIGRldmljZSBmaW5kcyBXU0RCDQogRFMgbGF0ZXIuPC9zcGFuPjwv aT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMWY0OTdkIj48dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8ZGl2IGNsYXNzPSJpbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFmNDk3ZCI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQWJvdXQgdGhlIERIQ1AgeW91IG1lbnRpb25l ZCBiZWxvdywgdGVjaG5pY2FsbHkgc3BlYWtpbmcsIHRoZXJlIGhhdmUgYmVlbiBzb21lIGV4dGVu c2lvbiBvZiBESENQIGZvciBzdXBwb3J0aW5nIHRoZSBwcm92aXNpb24gb2YgTG9TVCBzZXJ2ZXIs IHJlZmVyIHRvIFJGQzUyMjMuDQo8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9y OnJlZCI+bWomZ3Q7IEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBESENQIG9wdGlvbiBzcGVjaWZ5aW5n IHRoZSBMb1NUIHNlcnZlciB3b3VsZCBiZSBwcm92aWRlZCB0byB0aGUgTWFzdGVyIGRldmljZSB3 aGVuIGl0IGluaXRpYXRlZCBpdHMgYmFja2hhdWwgY29ubmVjdGlvbiAobm9uLVdTIGNvbm5lY3Rp b24pIHRvIHRoZSBpbnRlcm5ldC4NCiBDb3JyZWN0Pzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMWY0OTdkIj5bV2VpXSBZZWFoLjwvc3Bhbj48L2k+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PGRpdiBjbGFzcz0iaW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFmNDk3ZCI+QmVzaWRlcywgdXNpbmcgREhDUCBtZXRob2QgZG9lc27igJl0 IG1lYW5zIElQIG5ldHdvcmsgcHJvdmlkZXIgbXVzdCBoYXZlIHNvbWUgYnVzaW5lc3MgcmVsYXRp b25zaGlwIHdpdGggV1NEQiBEUyBwcm92aWRlciwgaWYgdGhlIG5ldHdvcmsgcHJvdmlkZXIgd2Fu dHMgdG8gcHJvdmlkZSBtYXN0ZXIgZGV2aWNlIHdpdGggRlFETiBvZiBXU0RCIERTDQogaXQgY2Fu IHVzZSBESENQLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOnJlZCI+bWomZ3Q7IElmIHRoZSBiYWNraGF1 bCBuZXR3b3JrIG9wZXJhdG9yIGlzIGNvbmZpZ3VyaW5nIGhpcyBESENQIHNlcnZlciB0byBzZW5k IG9wdGlvbnMgdG8gcHJvdmlzaW9uIHRoZSBXU0RCIERTIHRoZW4gSSBhc3N1bWUgaGUgaGFzIHNv bWUgYnVzaW5lc3MgaW50ZXJlc3QgaW4gZG9pbmcgc28uIFdoYXQgYW0gSSBtaXNzaW5nPzx1Pjwv dT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMWY0OTdkIj5bV2VpXSBJIHRoaW5rIHRo ZXJlIG1heSBiZSBzb21lIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIG5ldHdvcmsgb3BlcmF0b3IgYW5k IFdTREIgRFMuIEJ1dCB0aGUgcmVhc29uIHdoeSBESENQIGlzIG1lbnRpb25lZCBoZXJlIGlzIGJl Y2F1c2UgaW4gdGhlIExvU1QgcHJvdG9jb2wgREhDUCBpcyBleHRlbmRlZCB0byBwcm92aWRlIExv U1QNCiBzZXJ2ZXLigJlzIGRvbWFpbiBuYW1lIHRvIHRoZSBMb1NUIGNsaWVudC48L3NwYW4+PC9p PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxZjQ5N2QiPjx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJoNSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6cmVk Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6cmVkIj5UaGFu a3M8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6cmVkIj5NYXJrPHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8 dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6IzFmNDk3ZCI+QmVzdCBSZWdhcmRzLDx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6IzFmNDk3ZCI+WGlucGVuZy48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxZjQ5N2QiPjx1Pjwv dT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjYjVjNGRmIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249 ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IE1hcmsgSm9uZXMgWzxhIGhyZWY9Im1haWx0bzptYXJrQGF6dS5j YSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzptYXJrQGF6dS5jYTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTMgMTE6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IFdl aXhpbnBlbmc7IDxhIGhyZWY9Im1haWx0bzpwYXdzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cGF3c0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8L2I+IFBldGVyIE1jQ2Fubjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSRTogW3Bhd3NdIGRyYWZ0LXdlaS1wYXdzLWRhdGFiYXNlLWRpc2NvdmVyeS0w MTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBhbGlnbj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0i RU4tVVMiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMWY0 OTdkIj5IaSBYaW5wZW5nLDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjoj MWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFm NDk3ZCI+SW4gc2VjdGlvbiAzLCB5b3Ugc3RhdGU6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1hbGlnbjpsZWZ0Ij48 c3BhbiBsYW5nPSJFTi1DQSIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGUgVVJMIG9yIElQIGFkZHJlc3Mg b2YgV1NEQiBEUyBjYW4gYmUgZm91bmQgYnkgYW55IG1ldGhvZCBzdWNoIGFzPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0 ZXh0LWFsaWduOmxlZnQiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEROUywg REhDUCwgbWFudWFsbHkgY29uZmlndXJpbmcgZXRjLCBhbmQgaXQgaXMgb3V0IG9mIHNjb3BlIG9m IHRoaXM8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0ibGVmdCIgc3R5bGU9InRleHQtYWxpZ246bGVmdCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsgZG9jdW1lbnQuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Nv bG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMWY0OTdkIj5J4oCZbSB1bmNsZWFyIG9uIGhvdyB0aGUgTWFzdGVyIGRldmljZSBvYnRhaW5z IHRoZSBVUkwgb2YgYSB0cnVzdGVkIGRpc2NvdmVyeSBzZXJ2ZXIgdW5sZXNzIHRoZXJlIGlzIHNv bWUgcHJlLWNvbmZpZ3VyYXRpb24gaW52b2x2ZWQuIEkgdW5kZXJzdGFuZCB0aGF0IEROUyBjb3Vs ZCBiZSB1c2VkIGlmIHRoZSBNYXN0ZXINCiBkZXZpY2UgaXMgYWxyZWFkeSBwcmUtY29uZmlndXJl ZCB3aXRoIGEgcHJlZmVycmVkL2hvbWUgVFZXUyBEUyBVUkwgKG9yIGEgcHJlZmVycmVkL2hvbWUg ZG9tYWluIHRoYXQgaXMgdGhlbiByZXNvbHZlZCB3aXRoIFUtTkFQVFIpIGJ1dCBJIGRvbuKAmXQg c2VlIGhvdyBESENQIGNvdWxkIGJlIHVzZWQgdG8gYm9vdHN0cmFwIHRoaXMgaW5mb3JtYXRpb24g aW4gdGhlIFRWV1Mgc2NlbmFyaW9zLiBQbGVhc2UgY291bGQgeW91IGVsYWJvcmF0ZS48dT48L3U+ PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1D QSIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFmNDk3ZCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0Ei IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPlRoYW5rczx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMWY0OTdkIj5NYXJrPHU+PC91Pjx1PjwvdT48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQ0EiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxZjQ5N2QiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUNBIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtjb2xvcjojMWY0OTdkIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bh bj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJsZWZ0IiBzdHlsZT0idGV4dC1h bGlnbjpsZWZ0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0K PGEgaHJlZj0ibWFpbHRvOnBhd3MtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnBh d3MtYm91bmNlc0BpZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpwYXdzLWJvdW5jZXNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+V2VpeGlucGVuZzxicj4NCjxiPlNlbnQ6PC9iPiBNYXktMjEt MTMgOToxMSBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnBhd3NAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCjxiPkNjOjwvYj4gUGV0ZXIg TWNDYW5uPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtwYXdzXSBkcmFmdC13ZWktcGF3cy1kYXRhYmFz ZS1kaXNjb3ZlcnktMDE8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImxlZnQiIHN0eWxlPSJ0ZXh0LWFsaWduOmxlZnQi PjxzcGFuIGxhbmc9IkVOLUNBIj48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgYWxsLCA8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEkgaGF2ZSB1cGxv YWRlZCBhIG5ldyB2ZXJzaW9uIGRyYWZ0IG9uIGRhdGFiYXNlIGRpc2NvdmVyeS4gQ29tbWVudHMg YXJlIHdlbGNvbWVkLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJ0ZXh0LWluZGVudDoyMS4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVm PSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC13ZWktcGF3cy1kYXRhYmFzZS1kaXNj b3ZlcnktMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC13ZWktcGF3cy1kYXRhYmFzZS1kaXNjb3ZlcnktMDE8L2E+Ljx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48dT48L3U+Jm5i c3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlhpbnBlbmcgV2VpPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KcGF3cyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86cGF3c0Bp ZXRmLm9yZyI+cGF3c0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3MiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Bhd3M8L2E+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnI+DQo8YnIgY2xlYXI9ImFsbCI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KLS0g PGJyPg0KLXZpbmNlIDwvZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpwYXdzIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpw YXdzQGlldGYub3JnIj5wYXdzQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9wYXdzPC9hPjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0K PC9kaXY+DQoNCg0KPC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxk aXY+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 L3NwYW4+PGJyPjxzcGFuPnBhd3MgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bhbj48YSBocmVm PSJtYWlsdG86cGF3c0BpZXRmLm9yZyI+cGF3c0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cyI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wYXdzPC9hPjwvc3Bhbj48YnI+PC9k aXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --_000_BBB5CA43FEC24EBF9E46DDB1816A1B99spectrumbridgecom_-- From dharasty@appcomsci.com Wed Jun 5 06:02:18 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 7A8A421F99B9 for ; Wed, 5 Jun 2013 06:02:18 -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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlmPTNLkTsCy for ; Wed, 5 Jun 2013 06:02:11 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id C847F21F99CF for ; Wed, 5 Jun 2013 06:02:10 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r55D2ACS025349 for ; Wed, 5 Jun 2013 09:02:10 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r55D29En023703 for ; Wed, 5 Jun 2013 09:02:09 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0438.000; Wed, 5 Jun 2013 09:02:09 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: clarifying use of HTTP redirect Thread-Index: Ac5h7OIS22rKPXsoSrWP4wtCPdHHkw== Date: Wed, 5 Jun 2013 13:02:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.17.249] Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CEB7F2Frrcatsexmb2atsa_" MIME-Version: 1.0 Subject: [paws] clarifying use of HTTP redirect X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 13:02:18 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEB7F2Frrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vince, all, I'd like to propose some clarifications regarding use of HTTP Redirect. Th= ese would be suitable for adding to Section 7 of the Protocol to Access Spectrum Database, Draft 5. ("draft-ietf-paws-protocol-= 05.txt"): The server SHOULD use HTTP status code "307 Temporary Redirect" to indicate= that the Device SHOULD resubmit the same request to an alternate URL. The= device MAY revert to the original URL for the very next requests, or MAY c= ontinue to use the alternate URL for a period (e.g.: the remainder of its s= ession, or a fixed period of time, or until power-cycled, or until it recei= ves another redirect). However, it SHOULD NOT modify it stored list of ava= ilable URLs. The server SHOULD use HTTP status code "301 Moved Permanently" to indicate = that the Device SHOULD resubmit this request an alternate URL and SHOULD su= bmit all future requests to the same. If the Device maintains a list of av= ailable URLs, it SHOULD replace only the current URL with the replacement i= ndicated in the Redirect. I believe this language will facilitate interoperability. - Dan Harasty Wireless Systems and Networks Dept Applied Communication Sciences Red Bank, NJ --_000_EC510C021D06A34C92F5A5A488B5290B0CEB7F2Frrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vince, all,

 

I’d like to propose some clarifications regard= ing use of HTTP Redirect.  These would be suitable for adding to Secti= on 7 of the

Protocol to Access Spectrum Database, Draft 5. = (“draft-ietf-paws-protocol-05.txt”):

 

The server SHOULD use HTT= P status code “307 Temporary Redirect” to indicate that the Dev= ice SHOULD resubmit the same request to an alternate URL.  The device = MAY revert to the original URL for the very next requests, or MAY continue to use the alternate URL for a period (e.g.: the remainder= of its session, or a fixed period of time, or until power-cycled, or until= it receives another redirect).  However, it SHOULD NOT modify it stor= ed list of available URLs.

 

The server SHOULD use HTT= P status code “301 Moved Permanently” to indicate that the Devi= ce SHOULD resubmit this request an alternate URL and SHOULD submit all futu= re requests to the same.  If the Device maintains a list of available URLs, it SHOULD replace only the current URL with the = replacement indicated in the Redirect.

 

I believe this language will facilitate interoperabi= lity.

 

- Dan Harasty

Wireless Systems and Networks Dept

Applied Communication Sciences

Red Bank, NJ

 

--_000_EC510C021D06A34C92F5A5A488B5290B0CEB7F2Frrcatsexmb2atsa_-- From brian.rosen@neustar.biz Wed Jun 5 06:34: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 04BAE21F9AED for ; Wed, 5 Jun 2013 06:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.322 X-Spam-Level: X-Spam-Status: No, score=-6.322 tagged_above=-999 required=5 tests=[AWL=0.276, 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 EjWCLnzrZLNR for ; Wed, 5 Jun 2013 06:34:00 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 853CC21F9AD9 for ; Wed, 5 Jun 2013 06:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370439413; x=1685779389; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=2lCgSLdKyjQQYjimJol9AB1VUhvcNB9UcOm43V1MXWk=; b=AImLuAOjLC3zYm2SZKhnEM7Th0wWaWi0rIUMBxl8rDekX+9oD9qOIwa8ts3rYb 9n60H/zaQNSAkubxUeRd21ug== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24657904; Wed, 05 Jun 2013 09:36:51 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Jun 2013 09:33:49 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Wed, 5 Jun 2013 09:33:48 -0400 From: "Rosen, Brian" To: Peter Stanforth Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGw== Date: Wed, 5 Jun 2013 13:33:48 +0000 Message-ID: <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: leyjpuy30LEGcTpyI1mfnw== Content-Type: multipart/alternative; boundary="_000_45C00ED946DC471989F3BA5DB6A33E0Cneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 13:34:04 -0000 --_000_45C00ED946DC471989F3BA5DB6A33E0Cneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Well, I thought that is what the protocol doc says, but actually, it's comp= letely unclear about how it works. It says, basically, that if you are permitted to operate in more than one d= omain, you should be pre-configured with URIs for a) all listing servers for each domain b) all databases for each domain that doesn't have a listing server It has no text that describes how you select one, either the first time, or= any subsequent time. It would be perfectly compatible with the doc as it = is to try servers in a list of 100 randomly until you found one that accept= ed you. Normally, protocols are pretty specific about this, so both ends know what = will happen. I would suggest that you get preconfigured with exactly one database. If t= hat needs to change, change the configuration. Discovery is the mechanism by which you find out about databases given your= location. It has to be a protocol - you send in your location (and probab= ly nothing else other than perhaps a device id), and you get back a listing= server or list of dbs in that area. Discovery has to work with a set of p= er country polygons. The discovery service needs to find out which country= you are in and give you the listing service or dbs for that country. Devices may have lists of dbs they are authorized to use. If they knew wha= t country they were in, they could try one of the ones they are configured = for. But something has to tell them that. You wouldn't configure a device= with all the dbs in a country, you would configure one (or possibly more),= the device was authorized to use. It might make sense to provide some kind of discovery sequence that has a c= ache of the last server, so you don't have to the whole sequence from the t= op every time you boot. I don't think expecting every db to know about every other country's dbs wi= ll scale very well. When there is only 2-3 countries that have such DBs, m= aybe, but if there were 50 or more, the lists would be too difficult for ev= ery other DB to track. Brian On Jun 5, 2013, at 9:00 AM, Peter Stanforth > wrote: Brian. Why do you assume a device will always go back to its original DB ra= ther than the one it last registered with. The latter seems more likely, an= d more logical, to me Peter S. Sent from my iPhone On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" > wrote: The problem I see with this is that the database originally contacted (pres= umably configured directly or indirectly) is forever responsible for referr= als to the correct database. It provides no other service for the device. If I purchased a device in New York City and moved to London, the US databa= se has to refer me every time I try to register. Having a separate database whose job is to do that referral seems like a mo= re rational solution. Any device or service that wanted to participate in = that kind of "nomadic" operation could contribute to the cost of providing = the service. Cross subsidizing the U.S. database from the U.K. database fo= r the referral seems less likely to succeed. Brian On Jun 4, 2013, at 10:20 PM, Vincent Chen > wrote: Xinpeng, All, Thanks for putting this together. It seems that discovery involves two aspects: - Deployment of LoST servers, which also impacts discovery of LoST severs - Protocol (format of messages that is communicated) The current document is placing deployment out of scope, but does suggest t= hat preconfiguration is a strategy. That just leaves the protocol, which, may be characterized as: 1. Device sends request with its location 2. Server responds with a list of (name, uri) pairs Given that this is relatively simple, should we just build it into PAWS pro= tocol itself? For example, the current revision (r05) of the PAWS protocol allows for the= following: 1. Device asks database for available spectrum in a location outside the c= overage area for the Databae 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (= name, databaseUri) entries to "recommend" alternate databases This provides almost the same capability. Should we just add a ListDatabase to PAWS? -vince On Thu, May 23, 2013 at 6:57 PM, Weixinpeng > wrote: Hi Mark, Please see comments inline. Thanks! Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Thursday, May 23, 2013 10:31 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline= below (prefixed by mj>). From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: May-22-13 11:13 PM To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I= need to clarify. we have to be clear that the discovery mechanism is provided as an= optional method that can help master device to find the correct WSDB, whic= h means the master device can get WSDB by, such as, pre-configuring of WSDB= , provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for maste= r device to find WSDB, for example, when a new WSDB is setup for providing = service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient me= chanism to manage WSDB instances being commissioned or decommissioned. I vi= ew LoST as a kind of =93location-aware DNS=94 so I understand its applicabi= lity to discovery of the appropriate WSDB. I still think the draft needs mo= re information on how the Master device finds its WSDB DS so that implement= ers understand if/when this optional discovery method is applicable to thei= r deployment. [Wei] Yeah, because we cannot covey location information in DNS query messa= ge, so DNS is inappropriate to find the WSDB. I think I will do more clarif= ication about how master device finds WSDB DS later. About the DHCP you mentioned below, technically speaking, there ha= ve been some extension of DHCP for supporting the provision of LoST server,= refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be p= rovided to the Master device when it initiated its backhaul connection (non= -WS connection) to the internet. Correct? [Wei] Yeah. Besides, using DHCP method doesn=92t means IP network provider must have so= me business relationship with WSDB DS provider, if the network provider wan= ts to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send= options to provision the WSDB DS then I assume he has some business intere= st in doing so. What am I missing? [Wei] I think there may be some relationship between network operator and W= SDB DS. But the reason why DHCP is mentioned here is because in the LoST pr= otocol DHCP is extended to provide LoST server=92s domain name to the LoST = client. Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I=92m unclear on how the Master device obtains the URL of a trusted discove= ry server unless there is some pre-configuration involved. I understand tha= t DNS could be used if the Master device is already pre-configured with a p= referred/home TVWS DS URL (or a preferred/home domain that is then resolved= with U-NAPTR) but I don=92t see how DHCP could be used to bootstrap this i= nformation in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_45C00ED946DC471989F3BA5DB6A33E0Cneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <21048F934374B64C96615984C5152919@neustar.biz> Content-Transfer-Encoding: quoted-printable Well, I thought that is what the protocol doc says, but actually, it's comp= letely unclear about how it works.

It says, basically, that if you are permitted to operate in more than = one domain, you should be pre-configured with URIs for
a) all listing servers for each domain
b) all databases for each domain that doesn't have a listing server

It has no text that describes how you select one, either the first tim= e, or any subsequent time.  It would be perfectly compatible with the = doc as it is to try servers in a list of 100 randomly until you found one t= hat accepted you.

Normally, protocols are pretty specific about this, so both ends know = what will happen.

I would suggest that you get preconfigured with exactly one database. =  If that needs to change, change the configuration.

Discovery is the mechanism by which you find out about databases given= your location.  It has to be a protocol - you send in your location (= and probably nothing else other than perhaps a device id), and you get back= a listing server or list of dbs in that area.  Discovery has to work with a set of per country polygons. &nbs= p;The discovery service needs to find out which country you are in and give= you the listing service or dbs for that country.  

Devices may have lists of dbs they are authorized to use.  If the= y knew what country they were in, they could try one of the ones they are c= onfigured for.  But something has to tell them that.  You wouldn'= t configure a device with all the dbs in a country, you would configure one (or possibly more), the device was authorized to u= se.

It might make sense to provide some kind of discovery sequence that ha= s a cache of the last server, so you don't have to the whole sequence from = the top every time you boot.  

I don't think expecting every db to know about every other country's d= bs will scale very well.  When there is only 2-3 countries that have s= uch DBs, maybe, but if there were 50 or more, the lists would be too diffic= ult for every other DB to track.

Brian


On Jun 5, 2013, at 9:00 AM, Peter Stanforth <peter@spectrumbridge.com> wrote:

Brian. Why do you assume a device will always go back to its original = DB rather than the one it last registered with. The latter seems more likel= y, and more logical, to me
Peter S.

Sent from my iPhone

On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:

The problem I see with this is that the database = originally contacted (presumably configured directly or indirectly) is fore= ver responsible for referrals to the correct database.  It provides no= other service for the device.

If I purchased a device in New York City and moved to London, the US d= atabase has to refer me every time I try to register.

Having a separate database whose job is to do that referral seems like= a more rational solution.  Any device or service that wanted to parti= cipate in that kind of "nomadic" operation could contribute to th= e cost of providing the service.  Cross subsidizing the U.S. database from the U.K. database for the referral seems less likel= y to succeed.

Brian

On Jun 4, 2013, at 10:20 PM, Vincent Chen <vchen@google.com> wrote:

Xinpeng, All,

Thanks for putting this together.

It seems that discovery involves two aspects:
 - Deployment of LoST servers, which also impacts disc= overy of LoST severs
 - Protocol (format of messages that is communicated)<= /div>

The current document is placing deployment out of scope, bu= t does suggest that preconfiguration is a strategy.
That just leaves the protocol, which, may be characterized = as:

  1. Device sends request with its location
  2. Server responds with a list of (name, uri) pairs<= /div>

Given that this is relatively simple, should we just build = it into PAWS protocol itself?

For example, the current revision (r05) of the PAWS protoco= l allows for the following:

 1. Device asks database for available spectrum in a l= ocation outside the coverage area for the Databae
 2. The Database returns OUTSIDE_COVERAGE error and MA= Y include a list of (name, databaseUri) entries to "recommend" al= ternate databases

This provides almost the same capability.

Should we just add a ListDatabase to PAWS?

-vince


On Thu, May 23, 2013 at 6:57 PM, Weixinpeng <weixinpeng@h= uawei.com> wrote:

Hi Mark= ,

 &= nbsp;       Please see comments inline. Thank= s!

=  

Best Re= gards,

Xinpeng= .

=  

=  

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; p= aws@ietf.org


Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

 

Hi Xinpeng,

 

Thank you for your responses. I have some further comments/questi= ons inline below (prefixed by mj>).

 

From: Weixinpeng [= mailto:weixinpen= g@huawei.com]
Sent: May-22-13 11:13 PM
To: Mark Jones; p= aws@ietf.org
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

 

Hi Mark= ,

 &= nbsp;       Thanks for your feedback, and I t= hink there are some issues that I need to clarify.

 &= nbsp;      

 &= nbsp;       we have to be clear that the disc= overy mechanism is provided as an optional method that can help master devi= ce to find the correct WSDB, which means the master device can get WSDB by,= such as, pre-configuring of WSDB, provision etc.

=  

mj> Understood.

 

 &= nbsp;       The dynamic discovery mechanism p= rovides more convenient for master device to find WSDB, for example, when a= new WSDB is setup for providing service or when some deployed WSDB goes do= wn and never work.

 &= nbsp;      

mj> In this regard, DNS resolution would appear to be equally conv= enient mechanism to manage WSDB instances being commissioned or decommissio= ned. I view LoST as a kind of =93location-aware DNS=94 so I understand its applicability to discovery of the appropriate W= SDB. I still think the draft needs more information on how the Master devic= e finds its WSDB DS so that implementers understand if/when this optional d= iscovery method is applicable to their deployment.

[= Wei] Yeah, because we cannot covey location information in DNS query messag= e, so DNS is inappropriate to find the WSDB. I think I will do more clarifi= cation about how master device finds WSDB DS later.

 

 &= nbsp;       About the DHCP you mentioned belo= w, technically speaking, there have been some extension of DHCP for support= ing the provision of LoST server, refer to RFC5223.

 

mj> I understand that the DHCP option specifying the LoST server w= ould be provided to the Master device when it initiated its backhaul connec= tion (non-WS connection) to the internet. Correct?

[= Wei] Yeah.

 

Besides= , using DHCP method doesn=92t means IP network provider must have some busi= ness relationship with WSDB DS provider, if the network provider wants to p= rovide master device with FQDN of WSDB DS it can use DHCP.

=  

mj> If the backhaul network operator is configuring his DHCP serve= r to send options to provision the WSDB DS then I assume he has some busine= ss interest in doing so. What am I missing?

[= Wei] I think there may be some relationship between network operator and WS= DB DS. But the reason why DHCP is mentioned here is because in the LoST pro= tocol DHCP is extended to provide LoST server=92s domain name to the LoST client.

 

Thanks

Mark

 

Best Re= gards,

Xinpeng= .

=  

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; p= aws@ietf.org
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01

 

Hi Xinpeng,

 

In section 3, you state:

 

&= nbsp;  The URL or IP address of WSDB DS can be found by any method suc= h as

&= nbsp;  DNS, DHCP, manually configuring etc, and it is out of scope of = this

&= nbsp;  document.

 

I=92m unclear on how the Master device obtains the URL of a trust= ed discovery server unless there is some pre-configuration involved. I unde= rstand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a p= referred/home domain that is then resolved with U-NAPTR) but I don=92t see = how DHCP could be used to bootstrap this information in the TVWS scenarios.= Please could you elaborate.

 

Thanks

Mark

 

 

From: paws-bounces@iet= f.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: paws@ietf.org=
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

 

Hi all,

     &= nbsp;   I have uploaded a new version draft on database discovery= . Comments are welcomed.

http://tools.ietf.org/html/draft-wei-paws-database-discove= ry-01.

 

 

Xinpeng Wei


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




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

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

--_000_45C00ED946DC471989F3BA5DB6A33E0Cneustarbiz_-- From vchen@google.com Wed Jun 5 08:42:12 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 CCCD121F9B1A for ; Wed, 5 Jun 2013 08:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 hYYz7B6o6syX for ; Wed, 5 Jun 2013 08:42:11 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2432D21F9ADC for ; Wed, 5 Jun 2013 08:42:11 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id at1so99791iec.37 for ; Wed, 05 Jun 2013 08:42:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=i03wov+/XhuVcwgZ/i0TaTmpluDEu0uBlFy5+YZ9qqo=; b=WVHFPGdoL8riqgAwrpR3bgmUcUwTp5h1zxsnvKagu5wAYYa4yKm4DjT4thuji/rhsa 3QTtOcoYD/1dE20FRsqY0wWf44lT+OxsJEWnnQDlYiMZyD2LWgCkzb1cXZApyDfpAmXN KgU8FPKXJ5xEHCjIKuNxV1vdeL+0lUDKjb441+1zKWVvYmtfJAJTNaa/VEIta9GVxg79 xo4G/FDZUV1wH2wrrJ3U//dqQ2HcZ6+dhJN2NhXqHzFIjH7ohp9Squ/1Lewufnl+3H3H QkvgzJkXhP6QmRD3qdMotHkk+UJFj3d+eO5R0Kmwbfo65Vea06F6Csdq7dZLnt9ykCaq 41gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=i03wov+/XhuVcwgZ/i0TaTmpluDEu0uBlFy5+YZ9qqo=; b=o6XwJMoBe5oKqmi5DID5gnsxUiE3Tm38fOzRzMMeLvyiuu6bpy8Jvqk8w/Drxr/HC+ RBNWidVx5E/fTnc4eTS00zoLnUw3Pps6fvCMcHUz//KOqrS7wfxj2/ZnsrrldARga0Sf zMD8agm6PsxMC0SwfoMMWCiiR40ODYhbW+5n+Oa2La+iONkQHvHQ2Id+7MkRLJ9x2HTM DX4X4cxO0ZBX/IqFMBE+9EQ0w5UWjNPT+h7luaJw4NIBTxKF2V2ncIeQl+6quL1amtb+ Fs/BoIuPTLps1RbovCyJ9rj5PQfd1JGa8Yrvaa/P9P23QcOCB129pHlMKXEHM23aF8XN xENg== MIME-Version: 1.0 X-Received: by 10.50.136.168 with SMTP id qb8mr3611399igb.5.1370446930490; Wed, 05 Jun 2013 08:42:10 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Wed, 5 Jun 2013 08:42:10 -0700 (PDT) In-Reply-To: <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> Date: Wed, 5 Jun 2013 08:42:10 -0700 Message-ID: From: Vincent Chen To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=089e0149495e7a54c004de6a0a8d X-Gm-Message-State: ALoCoQlvOuYsHLiJWl3c/5ieCGrOZ7EXAokCjvUu5o0eWQTak6iVXSKSKdgB2WX21+/9sTM0KL8Dhpe/Uwce/C1u0G0JixDd7/iiiJeweHOyeiCjJQjI3JnFA2EfCkV4uD+ZZLuvXjz34Buz96QUyFndO1SCo1R143kzvCDjFXuxx87b+Y18TIGnEdhQoWWxRHVlOKXTWFlO Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 15:42:12 -0000 --089e0149495e7a54c004de6a0a8d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Couple of thoughts: - A "preconfigured" database could serve *only* the ListDatabases method. That means it could be operated by the device manufacturer. The thought here is that device manufacturer probably has some business relationship with database operators anyways, so it would have the best idea of which database to to use There's no requirement that every DB knows every other DB, it would just be a convenience. -vince On Wed, Jun 5, 2013 at 6:33 AM, Rosen, Brian wrote= : > Well, I thought that is what the protocol doc says, but actually, it's > completely unclear about how it works. > > It says, basically, that if you are permitted to operate in more than > one domain, you should be pre-configured with URIs for > a) all listing servers for each domain > b) all databases for each domain that doesn't have a listing server > > It has no text that describes how you select one, either the first time, > or any subsequent time. It would be perfectly compatible with the doc as > it is to try servers in a list of 100 randomly until you found one that > accepted you. > > Normally, protocols are pretty specific about this, so both ends know > what will happen. > > I would suggest that you get preconfigured with exactly one database. > If that needs to change, change the configuration. > > Discovery is the mechanism by which you find out about databases given > your location. It has to be a protocol - you send in your location (and > probably nothing else other than perhaps a device id), and you get back a > listing server or list of dbs in that area. Discovery has to work with a > set of per country polygons. The discovery service needs to find out whi= ch > country you are in and give you the listing service or dbs for that > country. > > Devices may have lists of dbs they are authorized to use. If they knew > what country they were in, they could try one of the ones they are > configured for. But something has to tell them that. You wouldn't > configure a device with all the dbs in a country, you would configure one > (or possibly more), the device was authorized to use. > > It might make sense to provide some kind of discovery sequence that has > a cache of the last server, so you don't have to the whole sequence from > the top every time you boot. > > I don't think expecting every db to know about every other country's dbs > will scale very well. When there is only 2-3 countries that have such DB= s, > maybe, but if there were 50 or more, the lists would be too difficult for > every other DB to track. > > Brian > > > On Jun 5, 2013, at 9:00 AM, Peter Stanforth > wrote: > > Brian. Why do you assume a device will always go back to its original DB > rather than the one it last registered with. The latter seems more likely= , > and more logical, to me > Peter S. > > Sent from my iPhone > > On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" > wrote: > > The problem I see with this is that the database originally contacted > (presumably configured directly or indirectly) is forever responsible for > referrals to the correct database. It provides no other service for the > device. > > If I purchased a device in New York City and moved to London, the US > database has to refer me every time I try to register. > > Having a separate database whose job is to do that referral seems like a > more rational solution. Any device or service that wanted to participate > in that kind of "nomadic" operation could contribute to the cost of > providing the service. Cross subsidizing the U.S. database from the U.K. > database for the referral seems less likely to succeed. > > Brian > > On Jun 4, 2013, at 10:20 PM, Vincent Chen wrote: > > Xinpeng, All, > > Thanks for putting this together. > > It seems that discovery involves two aspects: > - Deployment of LoST servers, which also impacts discovery of LoST sever= s > - Protocol (format of messages that is communicated) > > The current document is placing deployment out of scope, but does > suggest that preconfiguration is a strategy. > That just leaves the protocol, which, may be characterized as: > > 1. Device sends request with its location > 2. Server responds with a list of (name, uri) pairs > > Given that this is relatively simple, should we just build it into PAWS > protocol itself? > > For example, the current revision (r05) of the PAWS protocol allows for > the following: > > 1. Device asks database for available spectrum in a location outside > the coverage area for the Databae > 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of > (name, databaseUri) entries to "recommend" alternate databases > > This provides almost the same capability. > > Should we just add a ListDatabase to PAWS? > > -vince > > > On Thu, May 23, 2013 at 6:57 PM, Weixinpeng wrote= : > >> Hi Mark,**** >> >> Please see comments inline. Thanks!**** >> >> ** ** >> >> Best Regards,**** >> >> Xinpeng.**** >> >> ** ** >> >> ** ** >> >> *From:* Mark Jones [mailto:mark@azu.ca] >> *Sent:* Thursday, May 23, 2013 10:31 PM >> *To:* Weixinpeng; paws@ietf.org >> >> *Cc:* Peter McCann; Zhulei (A) >> *Subject:* RE: [paws] draft-wei-paws-database-discovery-01**** >> >> ** ** >> >> Hi Xinpeng,**** >> >> ** ** >> >> Thank you for your responses. I have some further comments/questions >> inline below (prefixed by mj>).**** >> >> ** ** >> >> *From:* Weixinpeng [mailto:weixinpeng@huawei.com = ] >> >> *Sent:* May-22-13 11:13 PM >> *To:* Mark Jones; paws@ietf.org >> *Cc:* Peter McCann; Zhulei (A) >> *Subject:* RE: [paws] draft-wei-paws-database-discovery-01**** >> >> ** ** >> >> Hi Mark,**** >> >> Thanks for your feedback, and I think there are some issues tha= t >> I need to clarify.**** >> >> **** >> >> we have to be clear that the discovery mechanism is provided as >> an optional method that can help master device to find the correct WSDB, >> which means the master device can get WSDB by, such as, pre-configuring = of >> WSDB, provision etc. **** >> >> ** ** >> >> mj> Understood.**** >> >> ** ** >> >> The dynamic discovery mechanism provides more convenient for >> master device to find WSDB, for example, when a new WSDB is setup for >> providing service or when some deployed WSDB goes down and never work.**= * >> * >> >> **** >> >> mj> In this regard, DNS resolution would appear to be equally convenient >> mechanism to manage WSDB instances being commissioned or decommissioned.= I >> view LoST as a kind of =93location-aware DNS=94 so I understand its >> applicability to discovery of the appropriate WSDB. I still think the dr= aft >> needs more information on how the Master device finds its WSDB DS so tha= t >> implementers understand if/when this optional discovery method is >> applicable to their deployment.**** >> >> *[Wei] Yeah, because we cannot covey location information in DNS query >> message, so DNS is inappropriate to find the WSDB. I think I will do mor= e >> clarification about how master device finds WSDB DS later.***** >> >> ** ** >> >> About the DHCP you mentioned below, technically speaking, there >> have been some extension of DHCP for supporting the provision of LoST >> server, refer to RFC5223. **** >> >> ** ** >> >> mj> I understand that the DHCP option specifying the LoST server would b= e >> provided to the Master device when it initiated its backhaul connection >> (non-WS connection) to the internet. Correct?**** >> >> *[Wei] Yeah.***** >> >> ** ** >> >> Besides, using DHCP method doesn=92t means IP network provider must have >> some business relationship with WSDB DS provider, if the network provide= r >> wants to provide master device with FQDN of WSDB DS it can use DHCP.**** >> >> ** ** >> >> mj> If the backhaul network operator is configuring his DHCP server to >> send options to provision the WSDB DS then I assume he has some business >> interest in doing so. What am I missing?**** >> >> *[Wei] I think there may be some relationship between network operator >> and WSDB DS. But the reason why DHCP is mentioned here is because in the >> LoST protocol DHCP is extended to provide LoST server=92s domain name to= the >> LoST client.***** >> >> ** ** >> >> Thanks**** >> >> Mark**** >> >> ** ** >> >> Best Regards,**** >> >> Xinpeng.**** >> >> ** ** >> >> *From:* Mark Jones [mailto:mark@azu.ca ] >> *Sent:* Wednesday, May 22, 2013 11:29 PM >> *To:* Weixinpeng; paws@ietf.org >> *Cc:* Peter McCann >> *Subject:* RE: [paws] draft-wei-paws-database-discovery-01**** >> >> ** ** >> >> Hi Xinpeng,**** >> >> ** ** >> >> In section 3, you state:**** >> >> ** ** >> >> The URL or IP address of WSDB DS can be found by any method such as**= * >> * >> >> DNS, DHCP, manually configuring etc, and it is out of scope of this**= * >> * >> >> document.**** >> >> ** ** >> >> I=92m unclear on how the Master device obtains the URL of a trusted >> discovery server unless there is some pre-configuration involved. I >> understand that DNS could be used if the Master device is already >> pre-configured with a preferred/home TVWS DS URL (or a preferred/home >> domain that is then resolved with U-NAPTR) but I don=92t see how DHCP co= uld >> be used to bootstrap this information in the TVWS scenarios. Please coul= d >> you elaborate.**** >> >> ** ** >> >> Thanks**** >> >> Mark**** >> >> ** ** >> >> ** ** >> >> *From:* paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] >> *On Behalf Of *Weixinpeng >> *Sent:* May-21-13 9:11 PM >> *To:* paws@ietf.org >> *Cc:* Peter McCann >> *Subject:* [paws] draft-wei-paws-database-discovery-01**** >> >> ** ** >> >> Hi all, **** >> >> I have uploaded a new version draft on database discovery. >> Comments are welcomed.**** >> >> http://tools.ietf.org/html/draft-wei-paws-database-discovery-01.**** >> >> ** ** >> >> ** ** >> >> Xinpeng Wei**** >> >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >> >> > > > -- > -vince > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > > --=20 -vince --089e0149495e7a54c004de6a0a8d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Couple of thoughts:

=A0- A "= preconfigured" database could serve *only* the ListDatabases method.

=A0 =A0That means it could be operated = by the device manufacturer.
=A0 =A0The thought here is that device manufacturer probably has= some business relationship with database operators anyways, so
=A0 =A0it would have the best idea of which database to to use

There's no requirement that every DB knows every o= ther DB, it would just be a convenience.

-vince


On Wed, Jun 5, 2013 at 6:33 AM, Rosen, Brian <Brian.Rosen@neustar.b= iz> wrote:
Well, I thought that is what the protocol doc says, but actually, it's = completely unclear about how it works.

It says, basically, that if you are permitted to operate in more than = one domain, you should be pre-configured with URIs for
a) all listing servers for each domain
b) all databases for each domain that doesn't have a listing serve= r

It has no text that describes how you select one, either the first tim= e, or any subsequent time. =A0It would be perfectly compatible with the doc= as it is to try servers in a list of 100 randomly until you found one that= accepted you.

Normally, protocols are pretty specific about this, so both ends know = what will happen.

I would suggest that you get preconfigured with exactly one database. = =A0If that needs to change, change the configuration.

Discovery is the mechanism by which you find out about databases given= your location. =A0It has to be a protocol - you send in your location (and= probably nothing else other than perhaps a device id), and you get back a = listing server or list of dbs in that area. =A0Discovery has to work with a set of per country polygons. =A0The = discovery service needs to find out which country you are in and give you t= he listing service or dbs for that country. =A0

Devices may have lists of dbs they are authorized to use. =A0If they k= new what country they were in, they could try one of the ones they are conf= igured for. =A0But something has to tell them that. =A0You wouldn't con= figure a device with all the dbs in a country, you would configure one (or possibly more), the device was authorized to u= se.

It might make sense to provide some kind of discovery sequence that ha= s a cache of the last server, so you don't have to the whole sequence f= rom the top every time you boot. =A0

I don't think expecting every db to know about every other country= 's dbs will scale very well. =A0When there is only 2-3 countries that h= ave such DBs, maybe, but if there were 50 or more, the lists would be too d= ifficult for every other DB to track.

Brian


On Jun 5, 2013, at 9:00 AM, Peter Stanforth <peter@spectrumbridge.com> wr= ote:

Brian. Why do you assume a device will always go back to its original = DB rather than the one it last registered with. The latter seems more likel= y, and more logical, to me
Peter S.

Sent from my iPhone

On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" <Brian.Rosen@neustar.biz> = wrote:

The problem I see with this is that the database = originally contacted (presumably configured directly or indirectly) is fore= ver responsible for referrals to the correct database. =A0It provides no ot= her service for the device.

If I purchased a device in New York City and moved to London, the US d= atabase has to refer me every time I try to register.

Having a separate database whose job is to do that referral seems like= a more rational solution. =A0Any device or service that wanted to particip= ate in that kind of "nomadic" operation could contribute to the c= ost of providing the service. =A0Cross subsidizing the U.S. database from the U.K. database for the referral seems less likel= y to succeed.

Brian

On Jun 4, 2013, at 10:20 PM, Vincent Chen <vchen@google.com> wrote:

Xinpeng, All,

Thanks for putting this together.

It seems that discovery involves two aspects:
=A0- Deployment of LoST servers, which also impacts discovery of LoST = severs
=A0- Protocol (format of messages that is communicated)

The current document is placing deployment out of scope, but does sugg= est that preconfiguration is a strategy.
That just leaves the protocol, which, may be characterized as:

=A0 1. Device sends request with its location
=A0 2. Server responds with a list of (name, uri) pairs

Given that this is relatively simple, should we just build it into PAW= S protocol itself?

For example, the current revision (r05) of the PAWS protocol allows fo= r the following:

=A01. Device asks database for available spectrum in a location outsid= e the coverage area for the Databae
=A02. The Database returns OUTSIDE_COVERAGE error and MAY include a li= st of (name, databaseUri) entries to "recommend" alternate databa= ses

This provides almost the same capability.

Should we just add a ListDatabase to PAWS?

-vince


On Thu, May 23, 2013 at 6:57 PM, Weixinpeng <weixinpeng@h= uawei.com> wrote:

Hi Mark= ,

=A0=A0= =A0=A0=A0=A0=A0=A0 Please see comments inline. Thanks!=

= =A0

Best Re= gards,

Xinpeng= .

= =A0

= =A0

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; p= aws@ietf.org


Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

=A0

Hi Xinpeng,

=A0

Thank you for your responses. I have some further comments/questi= ons inline below (prefixed by mj>).

=A0

From: Weixinpeng [= mailto:weixinpen= g@huawei.com]
Sent: May-22-13 11:13 PM
To: Mark Jones; p= aws@ietf.org
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

=A0

Hi Mark= ,

=A0=A0= =A0=A0=A0=A0=A0=A0 Thanks for your feedback, and I think there are some iss= ues that I need to clarify.

=A0=A0= =A0=A0=A0=A0=A0=A0

=A0=A0= =A0=A0=A0=A0=A0=A0 we have to be clear that the discovery mechanism is prov= ided as an optional method that can help master device to find the correct = WSDB, which means the master device can get WSDB by, such as, pre-configuring of WSDB, provision etc.

= =A0

mj> Understood.

=A0

=A0=A0= =A0=A0=A0=A0=A0=A0 The dynamic discovery mechanism provides more convenient= for master device to find WSDB, for example, when a new WSDB is setup for = providing service or when some deployed WSDB goes down and never work.

=A0=A0= =A0=A0=A0=A0=A0=A0

mj> In this regard, DNS resolution would appear to be equally conv= enient mechanism to manage WSDB instances being commissioned or decommissio= ned. I view LoST as a kind of =93location-aware DNS=94 so I understand its applicability to discovery of the appropriate W= SDB. I still think the draft needs more information on how the Master devic= e finds its WSDB DS so that implementers understand if/when this optional d= iscovery method is applicable to their deployment.

[= Wei] Yeah, because we cannot covey location information in DNS query messag= e, so DNS is inappropriate to find the WSDB. I think I will do more clarifi= cation about how master device finds WSDB DS later.

=A0

=A0=A0= =A0=A0=A0=A0=A0=A0 About the DHCP you mentioned below, technically speaking= , there have been some extension of DHCP for supporting the provision of Lo= ST server, refer to RFC5223.

=A0

mj> I understand that the DHCP option specifying the LoST server w= ould be provided to the Master device when it initiated its backhaul connec= tion (non-WS connection) to the internet. Correct?

[= Wei] Yeah.

=A0

Besides= , using DHCP method doesn=92t means IP network provider must have some busi= ness relationship with WSDB DS provider, if the network provider wants to p= rovide master device with FQDN of WSDB DS it can use DHCP.

= =A0

mj> If the backhaul network operator is configuring his DHCP serve= r to send options to provision the WSDB DS then I assume he has some busine= ss interest in doing so. What am I missing?

[= Wei] I think there may be some relationship between network operator and WS= DB DS. But the reason why DHCP is mentioned here is because in the LoST pro= tocol DHCP is extended to provide LoST server=92s domain name to the LoST client.

=A0

Thanks

Mark

=A0

Best Re= gards,

Xinpeng= .

= =A0

From: Mark Jones [= mailto:mark@azu.ca]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; p= aws@ietf.org
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01

=A0

Hi Xinpeng,

=A0

In section 3, you state:

=A0

= =A0=A0 The URL or IP address of WSDB DS can be found by any method such as<= u>

= =A0=A0 DNS, DHCP, manually configuring etc, and it is out of scope of this<= u>

= =A0=A0 document.

=A0

I=92m unclear on how the Master device obtains the URL of a trust= ed discovery server unless there is some pre-configuration involved. I unde= rstand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a p= referred/home domain that is then resolved with U-NAPTR) but I don=92t see = how DHCP could be used to bootstrap this information in the TVWS scenarios.= Please could you elaborate.

=A0

Thanks

Mark

=A0

=A0

From: paws-bounces@iet= f.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: paws@ietf.org=
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

=A0

Hi all,

=A0=A0=A0=A0=A0=A0=A0=A0 I have= uploaded a new version draft on database discovery. Comments are welcomed.=

http://tools.ietf.org/html/draft-wei-paws-database-discove= ry-01.

=A0

=A0

Xinpeng Wei


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




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

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




--
-vince
--089e0149495e7a54c004de6a0a8d-- From dharasty@appcomsci.com Wed Jun 5 09:16: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 7CE4C21F98AC for ; Wed, 5 Jun 2013 09:16:25 -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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zV8NKDhlkhI6 for ; Wed, 5 Jun 2013 09:16:18 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0409021F9AF3 for ; Wed, 5 Jun 2013 09:16:15 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r55GGFgp028235 for ; Wed, 5 Jun 2013 12:16:15 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r55GGERk025999 for ; Wed, 5 Jun 2013 12:16:14 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0438.000; Wed, 5 Jun 2013 12:16:14 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGwLe06RQ Date: Wed, 5 Jun 2013 16:16:13 +0000 Message-ID: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> In-Reply-To: <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.130.231] Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CEB82C4rrcatsexmb2atsa_" MIME-Version: 1.0 Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 16:16:25 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEB82C4rrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian Rosen commented: I would suggest that you get preconfigured with exactly one database. If t= hat needs to change, change the configuration. I don't agree that we write the spec in such a way that enforces - or even = encourages - that a Device should be configurable with exactly one Database= URL. Here's my thinking: even if that Device manufacturer has an exclusive arran= gement with a single Database operator, the operator may run multiple Datab= ase instances on different URLs for any number of reasons (reliability, geo= graphic diversity, capacity, or segregation of the devices based some featu= re). I think it is much more robust for the device to be allowed - even encourag= ed - to be configurable with a list of Database URLs; as it allows Device t= o try a list - and presumably - experience fewer outages due to inability t= o contact any Database. Dan Harasty Wireless Systems and Networks Dept Applied Communication Sciences Red Bank, NJ From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Wednesday, June 05, 2013 9:34 AM To: Peter Stanforth Cc: paws@ietf.org; Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 Well, I thought that is what the protocol doc says, but actually, it's comp= letely unclear about how it works. It says, basically, that if you are permitted to operate in more than one d= omain, you should be pre-configured with URIs for a) all listing servers for each domain b) all databases for each domain that doesn't have a listing server It has no text that describes how you select one, either the first time, or= any subsequent time. It would be perfectly compatible with the doc as it = is to try servers in a list of 100 randomly until you found one that accept= ed you. Normally, protocols are pretty specific about this, so both ends know what = will happen. I would suggest that you get preconfigured with exactly one database. If t= hat needs to change, change the configuration. Discovery is the mechanism by which you find out about databases given your= location. It has to be a protocol - you send in your location (and probab= ly nothing else other than perhaps a device id), and you get back a listing= server or list of dbs in that area. Discovery has to work with a set of p= er country polygons. The discovery service needs to find out which country= you are in and give you the listing service or dbs for that country. Devices may have lists of dbs they are authorized to use. If they knew wha= t country they were in, they could try one of the ones they are configured = for. But something has to tell them that. You wouldn't configure a device= with all the dbs in a country, you would configure one (or possibly more),= the device was authorized to use. It might make sense to provide some kind of discovery sequence that has a c= ache of the last server, so you don't have to the whole sequence from the t= op every time you boot. I don't think expecting every db to know about every other country's dbs wi= ll scale very well. When there is only 2-3 countries that have such DBs, m= aybe, but if there were 50 or more, the lists would be too difficult for ev= ery other DB to track. Brian On Jun 5, 2013, at 9:00 AM, Peter Stanforth > wrote: Brian. Why do you assume a device will always go back to its original DB ra= ther than the one it last registered with. The latter seems more likely, an= d more logical, to me Peter S. Sent from my iPhone On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" > wrote: The problem I see with this is that the database originally contacted (pres= umably configured directly or indirectly) is forever responsible for referr= als to the correct database. It provides no other service for the device. If I purchased a device in New York City and moved to London, the US databa= se has to refer me every time I try to register. Having a separate database whose job is to do that referral seems like a mo= re rational solution. Any device or service that wanted to participate in = that kind of "nomadic" operation could contribute to the cost of providing = the service. Cross subsidizing the U.S. database from the U.K. database fo= r the referral seems less likely to succeed. Brian On Jun 4, 2013, at 10:20 PM, Vincent Chen > wrote: Xinpeng, All, Thanks for putting this together. It seems that discovery involves two aspects: - Deployment of LoST servers, which also impacts discovery of LoST severs - Protocol (format of messages that is communicated) The current document is placing deployment out of scope, but does suggest t= hat preconfiguration is a strategy. That just leaves the protocol, which, may be characterized as: 1. Device sends request with its location 2. Server responds with a list of (name, uri) pairs Given that this is relatively simple, should we just build it into PAWS pro= tocol itself? For example, the current revision (r05) of the PAWS protocol allows for the= following: 1. Device asks database for available spectrum in a location outside the c= overage area for the Databae 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (= name, databaseUri) entries to "recommend" alternate databases This provides almost the same capability. Should we just add a ListDatabase to PAWS? -vince On Thu, May 23, 2013 at 6:57 PM, Weixinpeng > wrote: Hi Mark, Please see comments inline. Thanks! Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Thursday, May 23, 2013 10:31 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline= below (prefixed by mj>). From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: May-22-13 11:13 PM To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I= need to clarify. we have to be clear that the discovery mechanism is provided as an= optional method that can help master device to find the correct WSDB, whic= h means the master device can get WSDB by, such as, pre-configuring of WSDB= , provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for maste= r device to find WSDB, for example, when a new WSDB is setup for providing = service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient me= chanism to manage WSDB instances being commissioned or decommissioned. I vi= ew LoST as a kind of "location-aware DNS" so I understand its applicability= to discovery of the appropriate WSDB. I still think the draft needs more i= nformation on how the Master device finds its WSDB DS so that implementers = understand if/when this optional discovery method is applicable to their de= ployment. [Wei] Yeah, because we cannot covey location information in DNS query messa= ge, so DNS is inappropriate to find the WSDB. I think I will do more clarif= ication about how master device finds WSDB DS later. About the DHCP you mentioned below, technically speaking, there ha= ve been some extension of DHCP for supporting the provision of LoST server,= refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be p= rovided to the Master device when it initiated its backhaul connection (non= -WS connection) to the internet. Correct? [Wei] Yeah. Besides, using DHCP method doesn't means IP network provider must have some= business relationship with WSDB DS provider, if the network provider wants= to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send= options to provision the WSDB DS then I assume he has some business intere= st in doing so. What am I missing? [Wei] I think there may be some relationship between network operator and W= SDB DS. But the reason why DHCP is mentioned here is because in the LoST pr= otocol DHCP is extended to provide LoST server's domain name to the LoST cl= ient. Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I'm unclear on how the Master device obtains the URL of a trusted discovery= server unless there is some pre-configuration involved. I understand that = DNS could be used if the Master device is already pre-configured with a pre= ferred/home TVWS DS URL (or a preferred/home domain that is then resolved w= ith U-NAPTR) but I don't see how DHCP could be used to bootstrap this infor= mation in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_EC510C021D06A34C92F5A5A488B5290B0CEB82C4rrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Brian Rosen commented:

 

I would sugg= est that you get preconfigured with exactly one database.  If that nee= ds to change, change the configuration.

 

I don’t agree that we write the s= pec in such a way that enforces – or even encourages – that a D= evice should be configurable with exactly one Database URL.

 

Here’s my thinking: even if that = Device manufacturer has an exclusive arrangement with a single Database ope= rator, the operator may run multiple Database instances on different URLs for any number of reasons (reliability, geographic diversity, capacit= y, or segregation of the devices based some feature).

 

I think it is much more robust for the = device to be allowed – even encouraged – to be configurable wit= h a list of Database URLs; as it allows Device to try a list – and pr= esumably – experience fewer outages due to inability to contact any Database.=

 

Dan Harasty

Wireless Systems and Networks Dept=

Applied Communication Sciences

Red Bank, NJ

 

 <= /p>

 <= /p>

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian
Sent: Wednesday, June 05, 2013 9:34 AM
To: Peter Stanforth
Cc: paws@ietf.org; Peter McCann
Subject: Re: [paws] draft-wei-paws-database-discovery-01<= /span>

 

Well, I thought that is what the protocol doc says, = but actually, it's completely unclear about how it works.

 

It says, basically, that if you are permitted to ope= rate in more than one domain, you should be pre-configured with URIs for

a) all listing servers for each domain

b) all databases for each domain that doesn't have a= listing server

 

It has no text that describes how you select one, ei= ther the first time, or any subsequent time.  It would be perfectly co= mpatible with the doc as it is to try servers in a list of 100 randomly unt= il you found one that accepted you.

 

Normally, protocols are pretty specific about this, = so both ends know what will happen.

 

I would suggest that you get preconfigured with exac= tly one database.  If that needs to change, change the configuration.<= o:p>

 

Discovery is the mechanism by which you find out abo= ut databases given your location.  It has to be a protocol - you send = in your location (and probably nothing else other than perhaps a device id)= , and you get back a listing server or list of dbs in that area.  Discovery has to work with a set of per co= untry polygons.  The discovery service needs to find out which country= you are in and give you the listing service or dbs for that country.  = ;

 

Devices may have lists of dbs they are authorized to= use.  If they knew what country they were in, they could try one of t= he ones they are configured for.  But something has to tell them that.=  You wouldn't configure a device with all the dbs in a country, you would configure one (or possibly more), the device w= as authorized to use.

 

It might make sense to provide some kind of discover= y sequence that has a cache of the last server, so you don't have to the wh= ole sequence from the top every time you boot.  

 

I don't think expecting every db to know about every= other country's dbs will scale very well.  When there is only 2-3 cou= ntries that have such DBs, maybe, but if there were 50 or more, the lists w= ould be too difficult for every other DB to track.

 

Brian

 

 

On Jun 5, 2013, at 9:00 AM, Peter Stanforth <peter@spectrumbridge.com> wr= ote:



Brian. Why do you assume a device will always go bac= k to its original DB rather than the one it last registered with. The latte= r seems more likely, and more logical, to me

Peter S.


Sent from my iPhone


On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:<= /p>

The problem I see with this is that the database ori= ginally contacted (presumably configured directly or indirectly) is forever= responsible for referrals to the correct database.  It provides no ot= her service for the device.

 

If I purchased a device in New York City and moved t= o London, the US database has to refer me every time I try to register.

 

Having a separate database whose job is to do that r= eferral seems like a more rational solution.  Any device or service th= at wanted to participate in that kind of "nomadic" operation coul= d contribute to the cost of providing the service.  Cross subsidizing the U.S. database from the U.K. database for the r= eferral seems less likely to succeed.

 

Brian

 

On Jun 4, 2013, at 10:20 PM, Vincent Chen <vchen@google.com> wrote:



Xinpeng, All,

 

Thanks for putting this together.

 

It seems that discovery involves two aspects:

 - Deployment of LoST servers, which also impac= ts discovery of LoST severs

 - Protocol (format of messages that is communi= cated)

 

The current document is placing deployment out of sc= ope, but does suggest that preconfiguration is a strategy.

That just leaves the protocol, which, may be charact= erized as:

 

  1. Device sends request with its location

  2. Server responds with a list of (name, uri)= pairs

 

Given that this is relatively simple, should we just= build it into PAWS protocol itself?

 

For example, the current revision (r05) of the PAWS = protocol allows for the following:

 

 1. Device asks database for available spectrum= in a location outside the coverage area for the Databae

 2. The Database returns OUTSIDE_COVERAGE error= and MAY include a list of (name, databaseUri) entries to "recommend&q= uot; alternate databases

 

This provides almost the same capability.=

 

Should we just add a ListDatabase to PAWS?

 

-vince

 

On Thu, May 23, 2013 at 6:57 PM, Weixinpeng <weixinpeng@huawei.co= m> wrote:

Hi Mark,

      =    Please see comments inline. Thanks!

 

Best Regards,

Xinpeng.

 

 

From: Mark Jones [mailto:mark@azu.ca]
Sent: Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; p= aws@ietf.org


Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01<= /p>

 

 

Hi X= inpeng,

&nbs= p;

Than= k you for your responses. I have some further comments/questions inline bel= ow (prefix= ed by mj>).

&nbs= p;

From: Weixinpeng [mailto:weixinpeng@huawei.c= om]
Sent: May-22-13 11:13 PM
To: Mark Jones; p= aws@ietf.org
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01=

 

Hi Mark,

      =    Thanks for your feedback, and I think there are some issues th= at I need to clarify.

      =   

      =    we have to be clear that the discovery mechanism is provided a= s an optional method that can help master device to find the correct WSDB, = which means the master device can get WSDB by, such as, pre-configuring of WSDB,= provision etc.

 

mj> Understood.

 <= /o:p>

      =    The dynamic discovery mechanism provides more convenient for m= aster device to find WSDB, for example, when a new WSDB is setup for provid= ing service or when some deployed WSDB goes down and never work.

      =   

mj> In this regard, = DNS resolution would appear to be equally convenient mechanism to manage WS= DB instances being commissioned or decommissioned. I view LoST as a kind of “location-aware DNS” so I understand = its applicability to discovery of the appropriate WSDB. I still think the d= raft needs more information on how the Master device finds its WSDB DS so t= hat implementers understand if/when this optional discovery method is applicable to their deployment.

[Wei] Yeah, because we cannot = covey location information in DNS query message, so DNS is inappropriate to= find the WSDB. I think I will do more clarification about how master device finds WSDB DS later.<= o:p>

 <= /o:p>

      =    About the DHCP you mentioned below, technically speaking, ther= e have been some extension of DHCP for supporting the provision of LoST ser= ver, refer to RFC5223.

 <= /o:p>

mj> I understand tha= t the DHCP option specifying the LoST server would be provided to the Maste= r device when it initiated its backhaul connection (non-WS connection) to the internet. Correct?

[Wei] Yeah.

 <= /o:p>

Besides, using DHCP method doesnR= 17;t means IP network provider must have some business relationship with WS= DB DS provider, if the network provider wants to provide master device with FQDN of WSDB DS it can use DHCP.=

 

mj> If the backhaul = network operator is configuring his DHCP server to send options to provisio= n the WSDB DS then I assume he has some business interest in doing so. What am I missing?

[Wei] I think there may be som= e relationship between network operator and WSDB DS. But the reason why DHC= P is mentioned here is because in the LoST protocol DHCP is extended to provide LoST server’s domain name = to the LoST client.

 

Thanks

Mark<= /p>

 <= /o:p>

Best Regards,

Xinpeng.

 

From: Mark Jones [mailto:mark@azu.ca]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; p= aws@ietf.org
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01=

 

Hi X= inpeng,

&nbs= p;

In s= ection 3, you state:

&nbs= p;

   The URL or IP address of WSDB DS can be foun= d by any method such as

   DNS, DHCP, manually configuring etc, and it = is out of scope of this

   document.

&nbs= p;

I= 217;m unclear on how the Master device obtains the URL of a trusted discove= ry server unless there is some pre-configuration involved. I understand that DNS could be used if the Master device is alre= ady pre-configured with a preferred/home TVWS DS URL (or a preferred/home d= omain that is then resolved with U-NAPTR) but I don’t see how DHCP co= uld be used to bootstrap this information in the TVWS scenarios. Please could you elaborate.

&nbs= p;

Than= ks

Mark=

&nbs= p;

&nbs= p;

From: paws-bounces@iet= f.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: paws@ietf.org=
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

 

Hi all,

         I have uploaded a= new version draft on database discovery. Comments are welcomed.=

http://tools.ietf.org/html/draft-wei-paws-database-disco= very-01.

 

 

Xinpeng Wei


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



 

--
-vince

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

 

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

 

--_000_EC510C021D06A34C92F5A5A488B5290B0CEB82C4rrcatsexmb2atsa_-- From dharasty@appcomsci.com Wed Jun 5 09:53:56 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 CF55C21F9C2B for ; Wed, 5 Jun 2013 09:53:54 -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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WcajxyYmoIf for ; Wed, 5 Jun 2013 09:53:50 -0700 (PDT) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5122A21F9C20 for ; Wed, 5 Jun 2013 09:53:45 -0700 (PDT) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (8.14.2/8.14.2) with ESMTP id r55Grj1X028694 for ; Wed, 5 Jun 2013 12:53:45 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.63]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id r55GrieV026335 for ; Wed, 5 Jun 2013 12:53:44 -0400 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0438.000; Wed, 5 Jun 2013 12:53:44 -0400 From: "Harasty, Daniel J" To: "paws@ietf.org" Thread-Topic: possible use of "preference values" Thread-Index: Ac5iDTybViJF76j0Rzezr1gEirFtWg== Date: Wed, 5 Jun 2013 16:53:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.130.231] Content-Type: multipart/alternative; boundary="_000_EC510C021D06A34C92F5A5A488B5290B0CEB83CFrrcatsexmb2atsa_" MIME-Version: 1.0 Subject: [paws] possible use of "preference values" X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 16:53:56 -0000 --_000_EC510C021D06A34C92F5A5A488B5290B0CEB83CFrrcatsexmb2atsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Brian Rosen commented: It might make sense to provide some kind of discovery sequence that has a c= ache of the last server, so you don't have to the whole sequence from the t= op every time you boot. I don't mind Brian's suggestion that a Device try its "most recently contac= ted database" upon the next time it tries to communicate. However, I do no= t see a need for the spec to say anything on this point. (I would object i= f the spec REQUIRED the Device to "start from the top every time the Device= boots", but if a given manufacturer decides that is best, OK with me.) I realize that the majority of the discussion around Discovery is concerned= with the following use case: 1. How does a device determine one or more valid Databases given its = location (and possibly other of its characteristics)? But that almost immediately leads the Device to consider: 2. If two or more Database URLs are available (either known to the De= vice via Discovery or its static, local configuration), is there any partic= ular sequence they should be tried in? Note also that a Database operator may be running multiple Database instanc= es on different URLs for any number of reasons (reliability, geographic div= ersity, capacity, or segregation of the devices based some feature). Thus,= there is another closely related use case: 3. If I can serve a given Device from two or more of my Database URLs= , what is the way I can "steer" traffic to one in particular, leaving the o= thers as backup/failover URLs? Use cases 2 and 3 lead me to this suggestion: as far as specifying sequenci= ng, I'd suggest we borrow a concept from MX records in DNS servers: each MX= (mail exchanger) record has a preference value, and lower values are to be= "preferred". (See http://en.wikipedia.org/wiki/MX_record and http://tools= .ietf.org/html/rfc5321.) The extension of this concept to Whitespace is that any "list of Databases"= should - conceptually - have each URL assigned a preference number as well= . (Details to be worked out as to who sets this when; I'm just proposing t= he concept of "preference value" here.) In the PAWS spec, this might be included by adding an optional "preference"= field in the "DatabaseSpec" parameter. This field is an integer, and cons= idered to be present with a value of 20 if missing. Lower values of the pr= eference value SHOULD be preferred by the Device. I would assume that - within the URLs for a given Database operator - that = the operator would have "say" in which URLs received which preference value= . In the "list of all databases" provided by the regulatory authority, it = would be at the discretion of that regulatory authority to decide what "fai= r" means in its jurisdiction (setting preference values accordingly). Anyway, I'm not trying to add unnecessary complexity to the Device, Databas= e, or spec; I'm merely proposing an "answer" to Brian's "sequencing issue" = that has precedence in other IETF specs. Dan Harasty Wireless Systems and Networks Dept Applied Communication Sciences Red Bank, NJ --_000_EC510C021D06A34C92F5A5A488B5290B0CEB83CFrrcatsexmb2atsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Brian Rosen commented:

 

It might mak= e sense to provide some kind of discovery sequence that has a cache of the = last server, so you don't have to the whole sequence from the top every time you boot.  

 

I don’t mind Brian’s sugges= tion that a Device try its “most recently contacted database” u= pon the next time it tries to communicate.  However, I do not see a ne= ed for the spec to say anything on this point.  (I would object if the spec REQU= IRED the Device to “start from the top every time the Device boots= 221;, but if a given manufacturer decides that is best, OK with me.)

 

I realize that the majority of the disc= ussion around Discovery is concerned with the following use case:

 

1.    &nb= sp;  How does a device determine one= or more valid Databases given its location (and possibly other of its char= acteristics)?

 

But that almost immediately leads the D= evice to consider:

 

2.    &nb= sp;  If two or more Database URLs ar= e available (either known to the Device via Discovery or its static, local = configuration), is there any particular sequence they should be tried in?

 

Note also that a Database operator may = be running multiple Database instances on different URLs for any n= umber of reasons (reliability, geographic diversity, capacity, or segregati= on of the devices based some feature).  Thus, there is another closely related use case:

 

3.    &nb= sp;  If I can serve a given Device f= rom two or more of my Database URLs, what is the way I can “steerR= 21; traffic to one in particular, leaving the others as backup/failover URLs?

 

Use cases 2 and 3 lead me to this sugge= stion: as far as specifying sequencing, I’d suggest we borrow a conce= pt from MX records in DNS servers: each MX (mail exchanger) record has a preference value, and lower values are to be “preferred”= .  (See http://en.wikipedia.org/wiki/MX_record and http://tools.ietf.org/html/rfc5321.)

 

The extension of this concept to Whites= pace is that any “list of Databases” should – conceptuall= y – have each URL assigned a preference number as well.  (Detail= s to be worked out as to who sets this when; I’m just proposing the concept of R= 20;preference value” here.)

 

In the PAWS spec, this might be include= d by adding an optional “preference” field in the “Databa= seSpec” parameter.  This field is an integer, and considered to = be present with a value of 20 if missing.  Lower values of the preference value = SHOULD be preferred by the Device.

 

I would assume that – within the = URLs for a given Database operator – that the operator would have = 220;say” in which URLs received which preference value.  In the = “list of all databases” provided by the regulatory authority, it would be at the = discretion of that regulatory authority to decide what “fair” m= eans in its jurisdiction (setting preference values accordingly).

 

Anyway, I’m not trying to add unn= ecessary complexity to the Device, Database, or spec; I’m merely prop= osing an “answer” to Brian’s “sequencing issue̶= 1; that has precedence in other IETF specs.

 

Dan Harasty

Wireless Systems and Networks Dept=

Applied Communication Sciences

Red Bank, NJ

 

 

--_000_EC510C021D06A34C92F5A5A488B5290B0CEB83CFrrcatsexmb2atsa_-- From brian.rosen@neustar.biz Wed Jun 5 10:35:45 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 EC90B21F8A0B for ; Wed, 5 Jun 2013 10:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, 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 QfkHm3oGXJnd for ; Wed, 5 Jun 2013 10:35:41 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 440EC21F8C40 for ; Wed, 5 Jun 2013 10:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370453655; x=1685811507; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=YQNceh36jNOwO3LuhVmFIUBX4iYzXY+bz2oLj5fAd34=; b=YESWDw95DtRbVpic0LvYHEi+lcnFVujc/csEvU+QK/j9JW+3TcZ8lawO8t/wsg hyx9EXD7XlV/B9VcnQ8odfWQ== Received: from ([10.31.13.242]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20617181; Wed, 05 Jun 2013 13:34:13 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Jun 2013 13:35:10 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Wed, 5 Jun 2013 13:35:09 -0400 From: "Rosen, Brian" To: "Harasty, Daniel J" Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGw== Date: Wed, 5 Jun 2013 17:35:09 +0000 Message-ID: <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: f9FLieqK5c6X5EsxPMdF7w== Content-Type: multipart/alternative; boundary="_000_7142558D2C344917AC9D8CC3915EC611neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 17:35:46 -0000 --_000_7142558D2C344917AC9D8CC3915EC611neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The problem with more than one is what the device does when it has more tha= n one. First of all, reliability, geographic diversity, capacity, etc are usually = done with common URLs. Witness www.google.com Segregation of devices would presumably have different URLs on different de= vices, not multiple URLs on the same device. I don't think configuration is a good solution for any device, but a simple= configuration option is the simplest, most universal way to get something = to work. Once you are past simple configuration, I personally feel that discovery is= the best mechanism. In this case, we have the issue of multiple countries/regulatory domains, s= o configuration could be one per region. The problem with that is figuring= out which region (country) you are in. If you have discovery for that, yo= u can have discovery for the databases. On the other, other hand, if there= are multiple databases per region, a given device may only have access to = one of them. It may have provisioning that tells it which one. That's a c= ombination of discovery and provisioning that avoid asking databases for he= lp that have no incentive to help, and would prefer not to see unnecessary = queries. Brian On Jun 5, 2013, at 12:16 PM, "Harasty, Daniel J" > wrote: Brian Rosen commented: I would suggest that you get preconfigured with exactly one database. If t= hat needs to change, change the configuration. I don=92t agree that we write the spec in such a way that enforces =96 or e= ven encourages =96 that a Device should be configurable with exactly one Da= tabase URL. Here=92s my thinking: even if that Device manufacturer has an exclusive arr= angement with a single Database operator, the operator may run multiple Dat= abase instances on different URLs for any number of reasons (reliability, g= eographic diversity, capacity, or segregation of the devices based some fea= ture). I think it is much more robust for the device to be allowed =96 even encour= aged =96 to be configurable with a list of Database URLs; as it allows Devi= ce to try a list =96 and presumably =96 experience fewer outages due to ina= bility to contact any Database. Dan Harasty Wireless Systems and Networks Dept Applied Communication Sciences Red Bank, NJ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Wednesday, June 05, 2013 9:34 AM To: Peter Stanforth Cc: paws@ietf.org; Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 Well, I thought that is what the protocol doc says, but actually, it's comp= letely unclear about how it works. It says, basically, that if you are permitted to operate in more than one d= omain, you should be pre-configured with URIs for a) all listing servers for each domain b) all databases for each domain that doesn't have a listing server It has no text that describes how you select one, either the first time, or= any subsequent time. It would be perfectly compatible with the doc as it = is to try servers in a list of 100 randomly until you found one that accept= ed you. Normally, protocols are pretty specific about this, so both ends know what = will happen. I would suggest that you get preconfigured with exactly one database. If t= hat needs to change, change the configuration. Discovery is the mechanism by which you find out about databases given your= location. It has to be a protocol - you send in your location (and probab= ly nothing else other than perhaps a device id), and you get back a listing= server or list of dbs in that area. Discovery has to work with a set of p= er country polygons. The discovery service needs to find out which country= you are in and give you the listing service or dbs for that country. Devices may have lists of dbs they are authorized to use. If they knew wha= t country they were in, they could try one of the ones they are configured = for. But something has to tell them that. You wouldn't configure a device= with all the dbs in a country, you would configure one (or possibly more),= the device was authorized to use. It might make sense to provide some kind of discovery sequence that has a c= ache of the last server, so you don't have to the whole sequence from the t= op every time you boot. I don't think expecting every db to know about every other country's dbs wi= ll scale very well. When there is only 2-3 countries that have such DBs, m= aybe, but if there were 50 or more, the lists would be too difficult for ev= ery other DB to track. Brian On Jun 5, 2013, at 9:00 AM, Peter Stanforth > wrote: Brian. Why do you assume a device will always go back to its original DB ra= ther than the one it last registered with. The latter seems more likely, an= d more logical, to me Peter S. Sent from my iPhone On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" > wrote: The problem I see with this is that the database originally contacted (pres= umably configured directly or indirectly) is forever responsible for referr= als to the correct database. It provides no other service for the device. If I purchased a device in New York City and moved to London, the US databa= se has to refer me every time I try to register. Having a separate database whose job is to do that referral seems like a mo= re rational solution. Any device or service that wanted to participate in = that kind of "nomadic" operation could contribute to the cost of providing = the service. Cross subsidizing the U.S. database from the U.K. database fo= r the referral seems less likely to succeed. Brian On Jun 4, 2013, at 10:20 PM, Vincent Chen > wrote: Xinpeng, All, Thanks for putting this together. It seems that discovery involves two aspects: - Deployment of LoST servers, which also impacts discovery of LoST severs - Protocol (format of messages that is communicated) The current document is placing deployment out of scope, but does suggest t= hat preconfiguration is a strategy. That just leaves the protocol, which, may be characterized as: 1. Device sends request with its location 2. Server responds with a list of (name, uri) pairs Given that this is relatively simple, should we just build it into PAWS pro= tocol itself? For example, the current revision (r05) of the PAWS protocol allows for the= following: 1. Device asks database for available spectrum in a location outside the c= overage area for the Databae 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (= name, databaseUri) entries to "recommend" alternate databases This provides almost the same capability. Should we just add a ListDatabase to PAWS? -vince On Thu, May 23, 2013 at 6:57 PM, Weixinpeng > wrote: Hi Mark, Please see comments inline. Thanks! Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Thursday, May 23, 2013 10:31 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline= below (prefixed by mj>). From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: May-22-13 11:13 PM To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I= need to clarify. we have to be clear that the discovery mechanism is provided as an= optional method that can help master device to find the correct WSDB, whic= h means the master device can get WSDB by, such as, pre-configuring of WSDB= , provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for maste= r device to find WSDB, for example, when a new WSDB is setup for providing = service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient me= chanism to manage WSDB instances being commissioned or decommissioned. I vi= ew LoST as a kind of =93location-aware DNS=94 so I understand its applicabi= lity to discovery of the appropriate WSDB. I still think the draft needs mo= re information on how the Master device finds its WSDB DS so that implement= ers understand if/when this optional discovery method is applicable to thei= r deployment. [Wei] Yeah, because we cannot covey location information in DNS query messa= ge, so DNS is inappropriate to find the WSDB. I think I will do more clarif= ication about how master device finds WSDB DS later. About the DHCP you mentioned below, technically speaking, there ha= ve been some extension of DHCP for supporting the provision of LoST server,= refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be p= rovided to the Master device when it initiated its backhaul connection (non= -WS connection) to the internet. Correct? [Wei] Yeah. Besides, using DHCP method doesn=92t means IP network provider must have so= me business relationship with WSDB DS provider, if the network provider wan= ts to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send= options to provision the WSDB DS then I assume he has some business intere= st in doing so. What am I missing? [Wei] I think there may be some relationship between network operator and W= SDB DS. But the reason why DHCP is mentioned here is because in the LoST pr= otocol DHCP is extended to provide LoST server=92s domain name to the LoST = client. Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I=92m unclear on how the Master device obtains the URL of a trusted discove= ry server unless there is some pre-configuration involved. I understand tha= t DNS could be used if the Master device is already pre-configured with a p= referred/home TVWS DS URL (or a preferred/home domain that is then resolved= with U-NAPTR) but I don=92t see how DHCP could be used to bootstrap this i= nformation in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_7142558D2C344917AC9D8CC3915EC611neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable <as individual>
The problem with more than one is what the device does when it has mor= e than one.  

First of all, reliability, geographic diversity, capacity, etc are usu= ally done with common URLs.  Witness www.google.com
Segregation of devices would presumably have different URLs on differe= nt devices, not multiple URLs on the same device.

I don't think configuration is a good solution for any device, but a s= imple configuration option is the simplest, most universal way to get somet= hing to work.
Once you are past simple configuration, I personally feel that discove= ry is the best mechanism.

In this case, we have the issue of multiple countries/regulatory domai= ns, so configuration could be one per region.  The problem with that i= s figuring out which region (country) you are in.  If you have discove= ry for that, you can have discovery for the databases.  On the other, other hand, if there are multiple databases= per region, a given device may only have access to one of them.  It m= ay have provisioning that tells it which one.  That's a combination of= discovery and provisioning that avoid asking databases for help that have no incentive to help, and would prefer not to see unnec= essary queries.

Brian 
On Jun 5, 2013, at 12:16 PM, "Harasty, Daniel J" <dharasty@appcomsci.com> wrote:
 <= /span>
Brian R= osen commented:
 <= /span>
I would= suggest that you get preconfigured with exactly one database.  If tha= t needs to change, change the configuration.
 <= /span>
I don= =92t agree that we write the spec in such a way that enforces =96 or even e= ncourages =96 that a Device should be configurable with exactly one Databas= e URL.
 <= /span>
Here=92= s my thinking: even if that Device manufacturer has an exclusive arrangemen= t with a single Database operator, the operator may run multiple Database i= nstances on different URLs for any number of reasons (reliability, geographic diversity, capacity, or segregation of= the devices based some feature).
 <= /span>
I think= it is much more robust for the device to be allowed =96 even encouraged = =96 to be configurable with a list of Database URLs; as it allows Device to= try a list =96 and presumably =96 experience fewer outages due to inability to contact any Database.<= /div>
 <= /span>
Dan Har= asty
Wireles= s Systems and Networks Dept
Applied= Communication Sciences
Red Ban= k, NJ
 <= /span>
 
 
From:=  p= aws-bounces@ietf.org = [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Bri= an
Sent: Wednesday, J= une 05, 2013 9:34 AM
To: Peter Stanfort= h
Cc: pa= ws@ietf.org; Peter McCann
Subject: Re: [paws= ] draft-wei-paws-database-discovery-01
 
Well, I thought that is what the protocol doc says, but actually, it's comp= letely unclear about how it works.
 
It says, basically, that if you are permitted to operate in more than one d= omain, you should be pre-configured with URIs for
a) all listing servers for each domain
b) all databases for each domain that doesn't have a listing server
 
It has no text that describes how you select one, either the first time, or= any subsequent time.  It would be perfectly compatible with the doc a= s it is to try servers in a list of 100 randomly until you found one that a= ccepted you.
 
Normally, protocols are pretty specific about this, so both ends know what = will happen.
 
I would suggest that you get preconfigured with exactly one database.  = ;If that needs to change, change the configuration.
 
Discovery is the mechanism by which you find out about databases given your= location.  It has to be a protocol - you send in your location (and p= robably nothing else other than perhaps a device id), and you get back a li= sting server or list of dbs in that area.  Discovery has to work with a set of per country polygons.  The = discovery service needs to find out which country you are in and give you t= he listing service or dbs for that country.  
 
Devices may have lists of dbs they are authorized to use.  If they kne= w what country they were in, they could try one of the ones they are config= ured for.  But something has to tell them that.  You wouldn't con= figure a device with all the dbs in a country, you would configure one (or possibly more), the device was authorized to u= se.
 
It might make sense to provide some kind of discovery sequence that has a c= ache of the last server, so you don't have to the whole sequence from the t= op every time you boot.  
 
I don't think expecting every db to know about every other country's dbs wi= ll scale very well.  When there is only 2-3 countries that have such D= Bs, maybe, but if there were 50 or more, the lists would be too difficult f= or every other DB to track.
 
Brian
 
 
On Jun 5, 2013, at 9:00 AM, Peter Stanforth <pete= r@spectrumbridge.com> wrote:


Brian. Why do you assume a device will always go back to its original DB ra= ther than the one it last registered with. The latter seems more likely, an= d more logical, to me
Peter S.

Sent from my iPhone


On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:

The problem I see with this is that the database originally contacted (pres= umably configured directly or indirectly) is forever responsible for referr= als to the correct database.  It provides no other service for the dev= ice.
 
If I purchased a device in New York City and moved to London, the US databa= se has to refer me every time I try to register.
 
Having a separate database whose job is to do that referral seems like a mo= re rational solution.  Any device or service that wanted to participat= e in that kind of "nomadic" operation could contribute to the cos= t of providing the service.  Cross subsidizing the U.S. database from the U.K. database for the referral seems less likel= y to succeed.
 
Brian
 
On Jun 4, 2013, at 10:20 PM, Vincent Chen <vchen@google.c= om> wrote:


Xinpeng, All,
 
Thanks for putting this together.
 
It seems that discovery involves two aspects:
 - Deployment of LoST servers, which also impacts discovery of LoST se= vers
 - Protocol (format of messages that is communicated)
 
The current document is placing deployment out of scope, but does suggest t= hat preconfiguration is a strategy.
That just leaves the protocol, which, may be characterized as:
 
  1. Device sends request with its location
  2. Server responds with a list of (name, uri) pairs
 
Given that this is relatively simple, should we just build it into PAWS pro= tocol itself?
 
For example, the current revision (r05) of the PAWS protocol allows for the= following:
 
 1. Device asks database for available spectrum in a location outside = the coverage area for the Databae
 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list= of (name, databaseUri) entries to "recommend" alternate database= s
 
This provides almost the same capability.
 
Should we just add a ListDatabase to PAWS?
 
-vince

 

On Thu, May 23, 2013 at 6:57 PM, Weixinpeng <weixinpeng@huawei.com> wrote:
Hi Mark,
     &nb= sp;   Please see comments inline. Thanks!
 
Best Regards,
Xinpeng.
 
 
From:=  Mark Jones [mailto:mark@azu.ca] 
Sent: Thursday, Ma= y 23, 2013 10:31 PM
To: Weixinpeng; 
Cc: Peter McCann; = Zhulei (A)
Subject: RE: [paws= ] draft-wei-paws-database-discovery-01
 
 
H= i Xinpeng,
&= nbsp;
T= hank you for your responses. I have some further comments/questions inline = below (= prefixed by mj>).
&= nbsp;
 
Hi Mark,
     &nb= sp;   Thanks for your feedback, and I think there are some issues= that I need to clarify.
     &nb= sp;  
     &nb= sp;   we have to be clear that the discovery mechanism is provide= d as an optional method that can help master device to find the correct WSD= B, which means the master device can get WSDB by, such as, pre-configuring of WSDB, provision etc.
 
mj> Understood.
 
     &nb= sp;   The dynamic discovery mechanism provides more convenient fo= r master device to find WSDB, for example, when a new WSDB is setup for pro= viding service or when some deployed WSDB goes down and never work.<= o:p>
     &nb= sp;  
mj> In this regard, DNS re= solution would appear to be equally convenient mechanism to manage WSDB ins= tances being commissioned or decommissioned. I view LoST as a kind of =93lo= cation-aware DNS=94 so I understand its applicability to discovery of the appropriate WSDB. I still think the draft needs more i= nformation on how the Master device finds its WSDB DS so that implementers = understand if/when this optional discovery method is applicable to their de= ployment.
[Wei] Yeah, because we cann= ot covey location information in DNS query message, so DNS is inappropriate= to find the WSDB. I think I will do more clarification about how master de= vice finds WSDB DS later.
 
     &nb= sp;   About the DHCP you mentioned below, technically speaking, t= here have been some extension of DHCP for supporting the provision of LoST = server, refer to RFC5223.
 
mj> I understand that the = DHCP option specifying the LoST server would be provided to the Master devi= ce when it initiated its backhaul connection (non-WS connection) to the int= ernet. Correct?
[Wei] Yeah.<= o:p>
 
Besides, using DHCP method doesn= =92t means IP network provider must have some business relationship with WS= DB DS provider, if the network provider wants to provide master device with= FQDN of WSDB DS it can use DHCP.
 
mj> If the backhaul networ= k operator is configuring his DHCP server to send options to provision the = WSDB DS then I assume he has some business interest in doing so. What am I = missing?
[Wei] I think there may be = some relationship between network operator and WSDB DS. But the reason why = DHCP is mentioned here is because in the LoST protocol DHCP is extended to = provide LoST server=92s domain name to the LoST client.
 
Thanks
Mark
 
Best Regards,
Xinpeng.
 
 
H= i Xinpeng,
&= nbsp;
I= n section 3, you state:
&= nbsp;
&= nbsp;
I= =92m unclear on how the Master device obtains the URL of a trusted discover= y server unless there is some pre-configuration involved. I understand that= DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a preferre= d/home domain that is then resolved with U-NAPTR) but I don=92t see how DHC= P could be used to bootstrap this information in the TVWS scenarios. Please= could you elaborate.
&= nbsp;
T= hanks
M= ark
&= nbsp;
&= nbsp;
From:=  paws-bounces@ietf.org [mailto:paws-bounce= s@ietf.org] On Behalf Of Weixinpeng=
Sent: May-21-13 9:= 11 PM
To: paws@ietf.org
Cc: Peter McCann Subject: [paws] dr= aft-wei-paws-database-discovery-01
 
Hi all,
         I have uploaded a new vers= ion draft on database discovery. Comments are welcomed.
 
 
Xinpeng Wei


_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws



 
-- 
-vince
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paw= s
 
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paw= s
 
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paw= s

--_000_7142558D2C344917AC9D8CC3915EC611neustarbiz_-- From brian.rosen@neustar.biz Wed Jun 5 10:49: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 DF24F21F9BBA for ; Wed, 5 Jun 2013 10:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.229 X-Spam-Level: X-Spam-Status: No, score=-6.229 tagged_above=-999 required=5 tests=[AWL=-0.184, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 VLk9SvB0zuHS for ; Wed, 5 Jun 2013 10:49:40 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 7906821F9A1A for ; Wed, 5 Jun 2013 10:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370455052; x=1685804951; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=srYz7gk7wJ4jkmLyah6Wln/PjKauBVXq8EdUnAkr1iI=; b=AthnkAQ5KEgv/6EXAdpWKJ0KO/9vqQCJe3I6a5L3FHhHR1WwwahxfA6UN/O8nh 07xMgs6K552sLOEv3h5VQztw== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.25827141; Wed, 05 Jun 2013 13:57:31 -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; Wed, 5 Jun 2013 13:49:23 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 5 Jun 2013 13:49:21 -0400 From: "Rosen, Brian" To: "Harasty, Daniel J" Thread-Topic: [paws] possible use of "preference values" Thread-Index: AQHOYhUCGgTzVL3mF0GA0LF1UgJT5A== Date: Wed, 5 Jun 2013 17:49:21 +0000 Message-ID: <163608FC-564A-4A6C-92C6-83B7AA96C8B7@neustar.biz> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: FDFav+ZobNp5rU90dfl9Pg== Content-Type: multipart/alternative; boundary="_000_163608FC564A4A6C92C683B7AA96C8B7neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] possible use of "preference values" X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 17:49:44 -0000 --_000_163608FC564A4A6C92C683B7AA96C8B7neustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable As a practical matter, the reason there are more than one databases in a re= gion is competition. The databases are commercial services, that have some= kind of business model that restricts who can use them. Thus the URL you = use doesn't depend on some fixed priority, but depends on commercial arrang= ements. As in my prior message, I suspect one URL per database is adequate to cover= reliability, redundancy, capacity, diversity, etc. Brian On Jun 5, 2013, at 12:53 PM, "Harasty, Daniel J" > wrote: Brian Rosen commented: It might make sense to provide some kind of discovery sequence that has a c= ache of the last server, so you don't have to the whole sequence from the t= op every time you boot. I don=92t mind Brian=92s suggestion that a Device try its =93most recently = contacted database=94 upon the next time it tries to communicate. However,= I do not see a need for the spec to say anything on this point. (I would = object if the spec REQUIRED the Device to =93start from the top every time = the Device boots=94, but if a given manufacturer decides that is best, OK w= ith me.) I realize that the majority of the discussion around Discovery is concerned= with the following use case: 1. How does a device determine one or more valid Databases given its = location (and possibly other of its characteristics)? But that almost immediately leads the Device to consider: 2. If two or more Database URLs are available (either known to the De= vice via Discovery or its static, local configuration), is there any partic= ular sequence they should be tried in? Note also that a Database operator may be running multiple Database instanc= es on different URLs for any number of reasons (reliability, geographic div= ersity, capacity, or segregation of the devices based some feature). Thus,= there is another closely related use case: 3. If I can serve a given Device from two or more of my Database URLs= , what is the way I can =93steer=94 traffic to one in particular, leaving t= he others as backup/failover URLs? Use cases 2 and 3 lead me to this suggestion: as far as specifying sequenci= ng, I=92d suggest we borrow a concept from MX records in DNS servers: each = MX (mail exchanger) record has a preference value, and lower values are to = be =93preferred=94. (Seehttp://en.wikipedia.org/wiki/MX_record and http://= tools.ietf.org/html/rfc5321.) The extension of this concept to Whitespace is that any =93list of Database= s=94 should =96 conceptually =96 have each URL assigned a preference number= as well. (Details to be worked out as to who sets this when; I=92m just p= roposing the concept of =93preference value=94 here.) In the PAWS spec, this might be included by adding an optional =93preferenc= e=94 field in the =93DatabaseSpec=94 parameter. This field is an integer, = and considered to be present with a value of 20 if missing. Lower values o= f the preference value SHOULD be preferred by the Device. I would assume that =96 within the URLs for a given Database operator =96 t= hat the operator would have =93say=94 in which URLs received which preferen= ce value. In the =93list of all databases=94 provided by the regulatory au= thority, it would be at the discretion of that regulatory authority to deci= de what =93fair=94 means in its jurisdiction (setting preference values acc= ordingly). Anyway, I=92m not trying to add unnecessary complexity to the Device, Datab= ase, or spec; I=92m merely proposing an =93answer=94 to Brian=92s =93sequen= cing issue=94 that has precedence in other IETF specs. Dan Harasty Wireless Systems and Networks Dept Applied Communication Sciences Red Bank, NJ _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_163608FC564A4A6C92C683B7AA96C8B7neustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <3647104416B5534083DAF3D8203A5D55@neustar.biz> Content-Transfer-Encoding: quoted-printable <as individual>
As a practical matter, the reason there are more than one databases in= a region is competition.  The databases are commercial services, that= have some kind of business model that restricts who can use them.  Th= us the URL you use doesn't depend on some fixed priority, but depends on commercial arrangements.  

As in my prior message, I suspect one URL per database is adequate to = cover reliability, redundancy, capacity, diversity, etc.  

Brian
On Jun 5, 2013, at 12:53 PM, "Harasty, Daniel J" <dharasty@appcomsci.com> wrote:
Brian R= osen commented:
 <= /span>
It migh= t make sense to provide some kind of discovery sequence that has a cache of= the last server, so you don't have to the whole sequence from the top ever= y time you boot.  
 <= /span>
I don= =92t mind Brian=92s suggestion that a Device try its =93most recently conta= cted database=94 upon the next time it tries to communicate.  However,= I do not see a need for the spec to say anything on this point.  (I would object if the spec REQUIRED the Device to = =93start from the top every time the Device boots=94, but if a given manufa= cturer decides that is best, OK with me.)
 <= /span>
I reali= ze that the majority of the discussion around Discovery is concerned with t= he following use case:
 <= /span>
1= .=       &= nbsp;How does a device determine one or more valid Databases given its location (an= d possibly other of its characteristics)?
 <= /span>
But tha= t almost immediately leads the Device to consider:
 <= /span>
2= .=       &= nbsp;If two or more Database URLs are available (either known to the Device via Di= scovery or its static, local configuration), is there any particular sequen= ce they should be tried in?
 <= /span>
Note al= so that a Database operator may be running multiple Database instances on different URLs for any number of reasons (reliability, geographic diver= sity, capacity, or segregation of the devices based some feature).  Th= us, there is another closely related use case:
 <= /span>
3= .=       &= nbsp;If I can serve a given Device from two or more of my Database URLs, what is t= he way I can =93steer=94 traffic to one in particular, leaving the others a= s backup/failover URLs?
 <= /span>
Use cas= es 2 and 3 lead me to this suggestion: as far as specifying sequencing, I= =92d suggest we borrow a concept from MX records in DNS servers: each MX (m= ail exchanger) record has a preference value, and lower values are to be =93preferred=94.  (Seehttp://en.wikipedia.org/wiki/MX_record and http://tools.ietf.org/html/rfc5321<= /a>.)
 <= /span>
The ext= ension of this concept to Whitespace is that any =93list of Databases=94 sh= ould =96 conceptually =96 have each URL assigned a preference number as wel= l.  (Details to be worked out as to who sets this when; I=92m just proposing the concept of =93preference value=94 here= .)
 <= /span>
In the = PAWS spec, this might be included by adding an optional =93preference=94 fi= eld in the =93DatabaseSpec=94 parameter.  This field is an integer, an= d considered to be present with a value of 20 if missing.  Lower values of the preference value SHOULD be preferred by= the Device.
 <= /span>
I would= assume that =96 within the URLs for a given Database operator =96 that the= operator would have =93say=94 in which URLs received which preference valu= e.  In the =93list of all databases=94 provided by the regulatory authority, it would be at the discretion of that regulat= ory authority to decide what =93fair=94 means in its jurisdiction (setting = preference values accordingly).
 <= /span>
Anyway,= I=92m not trying to add unnecessary complexity to the Device, Database, or= spec; I=92m merely proposing an =93answer=94 to Brian=92s =93sequencing is= sue=94 that has precedence in other IETF specs.
 <= /span>
Dan Har= asty
Wireles= s Systems and Networks Dept
Applied= Communication Sciences
Red Ban= k, NJ
 <= /span>
 <= /span>
_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/listinfo/paw= s

--_000_163608FC564A4A6C92C683B7AA96C8B7neustarbiz_-- From michael.fitch@bt.com Wed Jun 5 10:50:27 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 6017921F8E37 for ; Wed, 5 Jun 2013 10:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm7GVzoMTDnR for ; Wed, 5 Jun 2013 10:50:02 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 6823F21F8956 for ; Wed, 5 Jun 2013 10:50:00 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 5 Jun 2013 18:49:59 +0100 Received: from EVMHT35-UKDY.domain1.systemhost.net (193.113.31.60) by EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) with Microsoft SMTP Server (TLS) id 8.3.297.1; Wed, 5 Jun 2013 18:49:58 +0100 Received: from EMV35-UKDY.domain1.systemhost.net ([169.254.2.170]) by EVMHT35-UKDY.domain1.systemhost.net ([193.113.31.60]) with mapi; Wed, 5 Jun 2013 18:49:58 +0100 From: To: , Date: Wed, 5 Jun 2013 18:50:02 +0100 Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGwLi2ApQ Message-ID: <69A7E364B918F949829C3CD4FF25994E0C18C80E71@EMV35-UKDY.domain1.systemhost.net> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> In-Reply-To: <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_69A7E364B918F949829C3CD4FF25994E0C18C80E71EMV35UKDYdoma_" MIME-Version: 1.0 Cc: paws@ietf.org Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 17:50:28 -0000 --_000_69A7E364B918F949829C3CD4FF25994E0C18C80E71EMV35UKDYdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all Sorry to come in late but the foregoing discussion has sparked a worry in m= y mind. I would like WSDs to be able to select a database manager from a list, perh= aps on the basis of price and value-added services offered, such as mobilit= y support. Is there anything in the foregoing discussion that would prevent this ? Michael From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: 05 June 2013 18:35 To: Harasty, Daniel J Cc: paws@ietf.org Subject: Re: [paws] draft-wei-paws-database-discovery-01 The problem with more than one is what the device does when it has more tha= n one. First of all, reliability, geographic diversity, capacity, etc are usually = done with common URLs. Witness www.google.com Segregation of devices would presumably have different URLs on different de= vices, not multiple URLs on the same device. I don't think configuration is a good solution for any device, but a simple= configuration option is the simplest, most universal way to get something = to work. Once you are past simple configuration, I personally feel that discovery is= the best mechanism. In this case, we have the issue of multiple countries/regulatory domains, s= o configuration could be one per region. The problem with that is figuring= out which region (country) you are in. If you have discovery for that, yo= u can have discovery for the databases. On the other, other hand, if there= are multiple databases per region, a given device may only have access to = one of them. It may have provisioning that tells it which one. That's a c= ombination of discovery and provisioning that avoid asking databases for he= lp that have no incentive to help, and would prefer not to see unnecessary = queries. Brian On Jun 5, 2013, at 12:16 PM, "Harasty, Daniel J" > wrote: Brian Rosen commented: I would suggest that you get preconfigured with exactly one database. If t= hat needs to change, change the configuration. I don't agree that we write the spec in such a way that enforces - or even = encourages - that a Device should be configurable with exactly one Database= URL. Here's my thinking: even if that Device manufacturer has an exclusive arran= gement with a single Database operator, the operator may run multiple Datab= ase instances on different URLs for any number of reasons (reliability, geo= graphic diversity, capacity, or segregation of the devices based some featu= re). I think it is much more robust for the device to be allowed - even encourag= ed - to be configurable with a list of Database URLs; as it allows Device t= o try a list - and presumably - experience fewer outages due to inability t= o contact any Database. Dan Harasty Wireless Systems and Networks Dept Applied Communication Sciences Red Bank, NJ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Wednesday, June 05, 2013 9:34 AM To: Peter Stanforth Cc: paws@ietf.org; Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 Well, I thought that is what the protocol doc says, but actually, it's comp= letely unclear about how it works. It says, basically, that if you are permitted to operate in more than one d= omain, you should be pre-configured with URIs for a) all listing servers for each domain b) all databases for each domain that doesn't have a listing server It has no text that describes how you select one, either the first time, or= any subsequent time. It would be perfectly compatible with the doc as it = is to try servers in a list of 100 randomly until you found one that accept= ed you. Normally, protocols are pretty specific about this, so both ends know what = will happen. I would suggest that you get preconfigured with exactly one database. If t= hat needs to change, change the configuration. Discovery is the mechanism by which you find out about databases given your= location. It has to be a protocol - you send in your location (and probab= ly nothing else other than perhaps a device id), and you get back a listing= server or list of dbs in that area. Discovery has to work with a set of p= er country polygons. The discovery service needs to find out which country= you are in and give you the listing service or dbs for that country. Devices may have lists of dbs they are authorized to use. If they knew wha= t country they were in, they could try one of the ones they are configured = for. But something has to tell them that. You wouldn't configure a device= with all the dbs in a country, you would configure one (or possibly more),= the device was authorized to use. It might make sense to provide some kind of discovery sequence that has a c= ache of the last server, so you don't have to the whole sequence from the t= op every time you boot. I don't think expecting every db to know about every other country's dbs wi= ll scale very well. When there is only 2-3 countries that have such DBs, m= aybe, but if there were 50 or more, the lists would be too difficult for ev= ery other DB to track. Brian On Jun 5, 2013, at 9:00 AM, Peter Stanforth > wrote: Brian. Why do you assume a device will always go back to its original DB ra= ther than the one it last registered with. The latter seems more likely, an= d more logical, to me Peter S. Sent from my iPhone On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" > wrote: The problem I see with this is that the database originally contacted (pres= umably configured directly or indirectly) is forever responsible for referr= als to the correct database. It provides no other service for the device. If I purchased a device in New York City and moved to London, the US databa= se has to refer me every time I try to register. Having a separate database whose job is to do that referral seems like a mo= re rational solution. Any device or service that wanted to participate in = that kind of "nomadic" operation could contribute to the cost of providing = the service. Cross subsidizing the U.S. database from the U.K. database fo= r the referral seems less likely to succeed. Brian On Jun 4, 2013, at 10:20 PM, Vincent Chen > wrote: Xinpeng, All, Thanks for putting this together. It seems that discovery involves two aspects: - Deployment of LoST servers, which also impacts discovery of LoST severs - Protocol (format of messages that is communicated) The current document is placing deployment out of scope, but does suggest t= hat preconfiguration is a strategy. That just leaves the protocol, which, may be characterized as: 1. Device sends request with its location 2. Server responds with a list of (name, uri) pairs Given that this is relatively simple, should we just build it into PAWS pro= tocol itself? For example, the current revision (r05) of the PAWS protocol allows for the= following: 1. Device asks database for available spectrum in a location outside the c= overage area for the Databae 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (= name, databaseUri) entries to "recommend" alternate databases This provides almost the same capability. Should we just add a ListDatabase to PAWS? -vince On Thu, May 23, 2013 at 6:57 PM, Weixinpeng > wrote: Hi Mark, Please see comments inline. Thanks! Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Thursday, May 23, 2013 10:31 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline= below (prefixed by mj>). From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: May-22-13 11:13 PM To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I= need to clarify. we have to be clear that the discovery mechanism is provided as an= optional method that can help master device to find the correct WSDB, whic= h means the master device can get WSDB by, such as, pre-configuring of WSDB= , provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for maste= r device to find WSDB, for example, when a new WSDB is setup for providing = service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient me= chanism to manage WSDB instances being commissioned or decommissioned. I vi= ew LoST as a kind of "location-aware DNS" so I understand its applicability= to discovery of the appropriate WSDB. I still think the draft needs more i= nformation on how the Master device finds its WSDB DS so that implementers = understand if/when this optional discovery method is applicable to their de= ployment. [Wei] Yeah, because we cannot covey location information in DNS query messa= ge, so DNS is inappropriate to find the WSDB. I think I will do more clarif= ication about how master device finds WSDB DS later. About the DHCP you mentioned below, technically speaking, there ha= ve been some extension of DHCP for supporting the provision of LoST server,= refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be p= rovided to the Master device when it initiated its backhaul connection (non= -WS connection) to the internet. Correct? [Wei] Yeah. Besides, using DHCP method doesn't means IP network provider must have some= business relationship with WSDB DS provider, if the network provider wants= to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send= options to provision the WSDB DS then I assume he has some business intere= st in doing so. What am I missing? [Wei] I think there may be some relationship between network operator and W= SDB DS. But the reason why DHCP is mentioned here is because in the LoST pr= otocol DHCP is extended to provide LoST server's domain name to the LoST cl= ient. Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I'm unclear on how the Master device obtains the URL of a trusted discovery= server unless there is some pre-configuration involved. I understand that = DNS could be used if the Master device is already pre-configured with a pre= ferred/home TVWS DS URL (or a preferred/home domain that is then resolved w= ith U-NAPTR) but I don't see how DHCP could be used to bootstrap this infor= mation in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_69A7E364B918F949829C3CD4FF25994E0C18C80E71EMV35UKDYdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all<= o:p>

 

Sorry to come in late but the foregoing discu= ssion has sparked a worry in my mind.

 

I would= like WSDs to be able to select a database manager from a list, perhaps on = the basis of price and value-added services offered, such as mobility suppo= rt.

 

Is there anything in the foregoing discus= sion that would prevent this ?

 

Michael

 

From: paws-bounces@i= etf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian
= Sent: 05 June 2013 18:35
To: Harasty, Daniel J
Cc: paws@ietf.org
Subject: Re: [paws] draft-wei-paws-database-disc= overy-01

 <= /o:p>

<as individual>

The problem with more than one is what the device does wh= en it has more than one.  

 

First of all, reliabilit= y, geographic diversity, capacity, etc are usually done with common URLs. &= nbsp;Witness www.google.com

Segregation of devices would presumabl= y have different URLs on different devices, not multiple URLs on the same d= evice.

 

<= /div>

I don't think configuration is a good soluti= on for any device, but a simple configuration option is the simplest, most = universal way to get something to work.

Once you are past simple configuration, I personally feel that= discovery is the best mechanism.

 

In this case, we = have the issue of multiple countries/regulatory domains, so configuration c= ould be one per region.  The problem with that is figuring out which r= egion (country) you are in.  If you have discovery for that, you can h= ave discovery for the databases.  On the other, other hand, if there a= re multiple databases per region, a given device may only have access to on= e of them.  It may have provisioning that tells it which one.  Th= at's a combination of discovery and provisioning that avoid asking database= s for help that have no incentive to help, and would prefer not to see unne= cessary queries.

 <= /o:p>

Brian 

On Jun 5, 2013, at 12:16 PM, "Harast= y, Daniel J" <dharasty@ap= pcomsci.com> wrote:


 

Bria= n Rosen commented:

 

= I would suggest that you get preconfigured with exactly one database.  = ;If that needs to change, change the configuration.

 =

I don’t agree that we write the spec in such a way that enforces = – or even encourages – that a Device should be configurable wit= h exactly one Database URL.

=

 =

Here’s my th= inking: even if that Device manufacturer has an exclusive arrangement with = a single Database operator, the operator may run multiple Database instance= s on different URLs for any number of reasons (reliability, geographic dive= rsity, capacity, or segregation of the devices based some feature).<= span lang=3DEN-US>

 

I think it is much more robust for the device to be all= owed – even encouraged – to be configurable with a list of Data= base URLs; as it allows Device to try a list – and presumably –= experience fewer outages due to inability to contact any Database.<= span lang=3DEN-US>

 

Dan Harasty=

Wireless Systems and Networks Dep= t

Applied Communication Sciences

Red Bank, NJ

 

 

 

From:<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'> paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian
Sent: Wednesday, June 05, 2013 9:34 AM
To: Peter Stanforth
Cc:=  paws@ietf.org; Peter McC= ann
Subject: Re: = [paws] draft-wei-paws-database-discovery-01<= /o:p>

 

Well, I thought that is what the protocol doc says, but actually, = it's completely unclear about how it works.

 

<= /div>

It says, basic= ally, that if you are permitted to operate in more than one domain, you sho= uld be pre-configured with URIs for

<= div>

a) all listing servers for each= domain

b) all databases for each domain that doesn't have a listin= g server

 

It has no text that describes how you selec= t one, either the first time, or any subsequent time.  It would be per= fectly compatible with the doc as it is to try servers in a list of 100 ran= domly until you found one that accepted you.

 

Normall= y, protocols are pretty specific about this, so both ends know what will ha= ppen.

 

I would suggest that you get preconfigured wit= h exactly one database.  If that needs to change, change the configura= tion.

 

Discovery is the mechanism by which you find o= ut about databases given your location.  It has to be a protocol - you= send in your location (and probably nothing else other than perhaps a devi= ce id), and you get back a listing server or list of dbs in that area. &nbs= p;Discovery has to work with a set of per country polygons.  The disco= very service needs to find out which country you are in and give you the li= sting service or dbs for that country.  

 

Device= s may have lists of dbs they are authorized to use.  If they knew what= country they were in, they could try one of the ones they are configured f= or.  But something has to tell them that.  You wouldn't configure= a device with all the dbs in a country, you would configure one (or possib= ly more), the device was authorized to use.

 

It might= make sense to provide some kind of discovery sequence that has a cache of = the last server, so you don't have to the whole sequence from the top every= time you boot.  

 

I don't think expecting ever= y db to know about every other country's dbs will scale very well.  Wh= en there is only 2-3 countries that have such DBs, maybe, but if there were= 50 or more, the lists would be too difficult for every other DB to track.<= o:p>

 

Brian

 

 

=

On Jun 5, 2013= , at 9:00 AM, Peter Stanforth <peter@spectrumbridge.com> wro= te:




Brian. Why do you assume a device will always = go back to its original DB rather than the one it last registered with. The= latter seems more likely, and more logical, to me

Peter S.


Sent from my iPhone


On Jun 5, 20= 13, at 8:37 AM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:

<= div>




<= /o:p>

Xin= peng, All,

 

Thanks for putting this together.

 = ;

It seems that discovery involves two aspects:

 - Dep= loyment of LoST servers, which also impacts discovery of LoST severs

 - Protocol (format of messages that is communicated)

 =

The current document is placing deployment out of scope, but does = suggest that preconfiguration is a strategy.

That just leaves the p= rotocol, which, may be characterized as:

<= div>

 

  1. D= evice sends request with its location

  2. Server responds wit= h a list of (name, uri) pairs

 

Given that this is rel= atively simple, should we just build it into PAWS protocol itself?

=  

For example, the current revision (r05) of the PAWS protocol= allows for the following:

 

=

 1. Device asks data= base for available spectrum in a location outside the coverage area for the= Databae

 2. The Database returns OUTSIDE_COVERAGE error and M= AY include a list of (name, databaseUri) entries to "recommend" a= lternate databases

 

This provides almost the same cap= ability.

 

Should we just add a ListDatabase to PAWS?<= o:p>

 

-vince

=

&nbs= p;

O= n Thu, May 23, 2013 at 6:57 PM, Weixinpeng <weixinpeng@huaw= ei.com> wrote:

Hi Mark,

      &n= bsp;  Please see comments inline. Thanks!

 

Be= st Regards,

Xinpeng.<= span lang=3DEN-US>

 

 

From:=  Mark Jone= s [mailto:mark@azu.ca]&nb= sp;
Sent: = Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; paws@ietf.org


Cc: Peter McCann; Zhulei (A)<= br>Subject: RE: [paw= s] draft-wei-paws-database-discovery-01

 

=  

Hi Xinpeng,

 

Thank you for your respon= ses. I have some further comments/questions inline below (prefixed by mj>).

 

<= p class=3DMsoNormal>From: Weixinpeng [mailto:weixinpe= ng@huawei.com] <= br>Sent: May-22-13 1= 1:13 PM
To: Mark = Jones; paws@ietf.org
Cc: Pet= er McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

 

Hi Mark,

   =       Thanks for your feedback, and I think there = are some issues that I need to clarify.

        

       =   we have to be clear that the discovery mechanism is provided as an o= ptional method that can help master device to find the correct WSDB, which = means the master device can get WSDB by, such as, pre-configuring of WSDB, = provision etc.

 =

mj> Understood.

 =

     &nbs= p;   The dynamic discovery mechanism provides more convenient for= master device to find WSDB, for example, when a new WSDB is setup for prov= iding service or when some deployed WSDB goes down and never work.

      =   

mj= > In this regard, DNS resolution would appear to be equally convenient m= echanism to manage WSDB instances being commissioned or decommissioned. I v= iew LoST as a kind of “location-aware DNS” so I understand its = applicability to discovery of the appropriate WSDB. I still think the draft= needs more information on how the Master device finds its WSDB DS so that = implementers understand if/when this optional discovery method is applicabl= e to their deployment.

[Wei] Yeah, because we cannot covey location information in DNS quer= y message, so DNS is inappropriate to find the WSDB. I think I will do more= clarification about how master device finds WSDB DS later.<= span lang=3DEN-US>

 =

     &nbs= p;   About the DHCP you mentioned below, technically speaking, th= ere have been some extension of DHCP for supporting the provision of LoST s= erver, refer to RFC5223.

 

<= div>

mj> I understand that the DHCP option specifying the LoST server w= ould be provided to the Master device when it initiated its backhaul connec= tion (non-WS connection) to the internet. Correct?

[Wei] Yeah.

 

Besides, using DHCP method doesn’t m= eans IP network provider must have some business relationship with WSDB DS = provider, if the network provider wants to provide master device with FQDN = of WSDB DS it can use DHCP.

=

=  

mj>= If the backhaul network operator is configuring his DHCP server to send op= tions to provision the WSDB DS then I assume he has some business interest = in doing so. What am I missing?=

[Wei] I think there may be some relationship between networ= k operator and WSDB DS. But the reason why DHCP is mentioned here is becaus= e in the LoST protocol DHCP is extended to provide LoST server’s doma= in name to the LoST client.

 

Thanks

Mark

 

Best Regards,

Xinpeng.

 =

From: Mar= k Jones [mailto:mark@azu.ca] 
Sent: <= /span>Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng;&n= bsp;paws@ietf.org
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-disco= very-01

 

Hi Xinpeng,

 

<= div>

In section 3, you state:

 <= /p>

   The URL or IP address of WSDB = DS can be found by any method such as<= /span>

   DNS, DHCP, manually con= figuring etc, and it is out of scope of this=

   document.

=  

I’m unclear o= n how the Master device obtains the URL of a trusted discovery server unles= s there is some pre-configuration involved. I understand that DNS could be = used if the Master device is already pre-configured with a preferred/home T= VWS DS URL (or a preferred/home domain that is then resolved with U-NAPTR) = but I don’t see how DHCP could be used to bootstrap this information = in the TVWS scenarios. Please could you elaborate.

 

Thanks

Mark

 

 

From:<= /b> paws-bounces@ietf.org [<= span style=3D'color:purple'>mailto:paws-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: paws@ietf.org
Cc: Peter McCann
Subject: [paws] draft-= wei-paws-database-discovery-01<= /p>

 

Hi all,

         = I have uploaded a new version draft on database discovery. Comments are wel= comed.

 

 

Xinpeng Wei


_______________________________________________
paws mailin= g list
paw= s@ietf.org
https://www.ietf.org/ma= ilman/listinfo/paws



 =

-- 
-vince

_______________________= ________________________
paws mailing list
paws@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/paws

 

_____________= __________________________________
paws mailing list
paws@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/paws">https://www.ietf.org/mailman/listinfo/paws

 

_______________________________________________
paws mailing li= st
paws@ie= tf.org
https://www.ietf.org/mailman/listinfo/paws

 <= /o:p>

= --_000_69A7E364B918F949829C3CD4FF25994E0C18C80E71EMV35UKDYdoma_-- From peter@spectrumbridge.com Wed Jun 5 10:59:34 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 DC89221F9640 for ; Wed, 5 Jun 2013 10:59:04 -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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dV0ToC+LQ8bD for ; Wed, 5 Jun 2013 10:59:00 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9171921F9A24 for ; Wed, 5 Jun 2013 10:58:58 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 5 Jun 2013 13:58:57 -0400 From: Peter Stanforth To: "michael.fitch@bt.com" , "Brian.Rosen@neustar.biz" , "dharasty@appcomsci.com" Date: Wed, 5 Jun 2013 13:58:47 -0400 Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5iFllitWL0UeC7S8m+ofPkCTnBBQ== Message-ID: In-Reply-To: <69A7E364B918F949829C3CD4FF25994E0C18C80E71@EMV35-UKDY.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CDD4F3AAF336peterspectrumbridgecom_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 17:59:34 -0000 --_000_CDD4F3AAF336peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Michael, In your example who, or what is making the decision? From a purely practica= l (DB manager) perspective I want to know that the "entity" that made the c= hoice is going to pay for the value added service that is offered, and it h= as just signed up for. I have always seen the value-add as a service/business plane above PAWS rat= her than something PAWS would define. Peter S. From: "michael.fitch@bt.com" > Date: Wednesday, June 5, 2013 1:50 PM To: "Brian.Rosen@neustar.biz" >, "dharasty@appcomsci.com" > Cc: "paws@ietf.org" > Subject: Re: [paws] draft-wei-paws-database-discovery-01 Dear all Sorry to come in late but the foregoing discussion has sparked a worry in m= y mind. I would like WSDs to be able to select a database manager from a list, perh= aps on the basis of price and value-added services offered, such as mobilit= y support. Is there anything in the foregoing discussion that would prevent this ? Michael From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: 05 June 2013 18:35 To: Harasty, Daniel J Cc: paws@ietf.org Subject: Re: [paws] draft-wei-paws-database-discovery-01 The problem with more than one is what the device does when it has more tha= n one. First of all, reliability, geographic diversity, capacity, etc are usually = done with common URLs. Witness www.google.com Segregation of devices would presumably have different URLs on different de= vices, not multiple URLs on the same device. I don't think configuration is a good solution for any device, but a simple= configuration option is the simplest, most universal way to get something = to work. Once you are past simple configuration, I personally feel that discovery is= the best mechanism. In this case, we have the issue of multiple countries/regulatory domains, s= o configuration could be one per region. The problem with that is figuring= out which region (country) you are in. If you have discovery for that, yo= u can have discovery for the databases. On the other, other hand, if there= are multiple databases per region, a given device may only have access to = one of them. It may have provisioning that tells it which one. That's a c= ombination of discovery and provisioning that avoid asking databases for he= lp that have no incentive to help, and would prefer not to see unnecessary = queries. Brian On Jun 5, 2013, at 12:16 PM, "Harasty, Daniel J" > wrote: Brian Rosen commented: I would suggest that you get preconfigured with exactly one database. If t= hat needs to change, change the configuration. I don=92t agree that we write the spec in such a way that enforces =96 or e= ven encourages =96 that a Device should be configurable with exactly one Da= tabase URL. Here=92s my thinking: even if that Device manufacturer has an exclusive arr= angement with a single Database operator, the operator may run multiple Dat= abase instances on different URLs for any number of reasons (reliability, g= eographic diversity, capacity, or segregation of the devices based some fea= ture). I think it is much more robust for the device to be allowed =96 even encour= aged =96 to be configurable with a list of Database URLs; as it allows Devi= ce to try a list =96 and presumably =96 experience fewer outages due to ina= bility to contact any Database. Dan Harasty Wireless Systems and Networks Dept Applied Communication Sciences Red Bank, NJ From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Rosen, Brian Sent: Wednesday, June 05, 2013 9:34 AM To: Peter Stanforth Cc: paws@ietf.org; Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 Well, I thought that is what the protocol doc says, but actually, it's comp= letely unclear about how it works. It says, basically, that if you are permitted to operate in more than one d= omain, you should be pre-configured with URIs for a) all listing servers for each domain b) all databases for each domain that doesn't have a listing server It has no text that describes how you select one, either the first time, or= any subsequent time. It would be perfectly compatible with the doc as it = is to try servers in a list of 100 randomly until you found one that accept= ed you. Normally, protocols are pretty specific about this, so both ends know what = will happen. I would suggest that you get preconfigured with exactly one database. If t= hat needs to change, change the configuration. Discovery is the mechanism by which you find out about databases given your= location. It has to be a protocol - you send in your location (and probab= ly nothing else other than perhaps a device id), and you get back a listing= server or list of dbs in that area. Discovery has to work with a set of p= er country polygons. The discovery service needs to find out which country= you are in and give you the listing service or dbs for that country. Devices may have lists of dbs they are authorized to use. If they knew wha= t country they were in, they could try one of the ones they are configured = for. But something has to tell them that. You wouldn't configure a device= with all the dbs in a country, you would configure one (or possibly more),= the device was authorized to use. It might make sense to provide some kind of discovery sequence that has a c= ache of the last server, so you don't have to the whole sequence from the t= op every time you boot. I don't think expecting every db to know about every other country's dbs wi= ll scale very well. When there is only 2-3 countries that have such DBs, m= aybe, but if there were 50 or more, the lists would be too difficult for ev= ery other DB to track. Brian On Jun 5, 2013, at 9:00 AM, Peter Stanforth > wrote: Brian. Why do you assume a device will always go back to its original DB ra= ther than the one it last registered with. The latter seems more likely, an= d more logical, to me Peter S. Sent from my iPhone On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" > wrote: The problem I see with this is that the database originally contacted (pres= umably configured directly or indirectly) is forever responsible for referr= als to the correct database. It provides no other service for the device. If I purchased a device in New York City and moved to London, the US databa= se has to refer me every time I try to register. Having a separate database whose job is to do that referral seems like a mo= re rational solution. Any device or service that wanted to participate in = that kind of "nomadic" operation could contribute to the cost of providing = the service. Cross subsidizing the U.S. database from the U.K. database fo= r the referral seems less likely to succeed. Brian On Jun 4, 2013, at 10:20 PM, Vincent Chen > wrote: Xinpeng, All, Thanks for putting this together. It seems that discovery involves two aspects: - Deployment of LoST servers, which also impacts discovery of LoST severs - Protocol (format of messages that is communicated) The current document is placing deployment out of scope, but does suggest t= hat preconfiguration is a strategy. That just leaves the protocol, which, may be characterized as: 1. Device sends request with its location 2. Server responds with a list of (name, uri) pairs Given that this is relatively simple, should we just build it into PAWS pro= tocol itself? For example, the current revision (r05) of the PAWS protocol allows for the= following: 1. Device asks database for available spectrum in a location outside the c= overage area for the Databae 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (= name, databaseUri) entries to "recommend" alternate databases This provides almost the same capability. Should we just add a ListDatabase to PAWS? -vince On Thu, May 23, 2013 at 6:57 PM, Weixinpeng > wrote: Hi Mark, Please see comments inline. Thanks! Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Thursday, May 23, 2013 10:31 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline= below (prefixed by mj>). From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: May-22-13 11:13 PM To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I= need to clarify. we have to be clear that the discovery mechanism is provided as an= optional method that can help master device to find the correct WSDB, whic= h means the master device can get WSDB by, such as, pre-configuring of WSDB= , provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for maste= r device to find WSDB, for example, when a new WSDB is setup for providing = service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient me= chanism to manage WSDB instances being commissioned or decommissioned. I vi= ew LoST as a kind of =93location-aware DNS=94 so I understand its applicabi= lity to discovery of the appropriate WSDB. I still think the draft needs mo= re information on how the Master device finds its WSDB DS so that implement= ers understand if/when this optional discovery method is applicable to thei= r deployment. [Wei] Yeah, because we cannot covey location information in DNS query messa= ge, so DNS is inappropriate to find the WSDB. I think I will do more clarif= ication about how master device finds WSDB DS later. About the DHCP you mentioned below, technically speaking, there ha= ve been some extension of DHCP for supporting the provision of LoST server,= refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be p= rovided to the Master device when it initiated its backhaul connection (non= -WS connection) to the internet. Correct? [Wei] Yeah. Besides, using DHCP method doesn=92t means IP network provider must have so= me business relationship with WSDB DS provider, if the network provider wan= ts to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send= options to provision the WSDB DS then I assume he has some business intere= st in doing so. What am I missing? [Wei] I think there may be some relationship between network operator and W= SDB DS. But the reason why DHCP is mentioned here is because in the LoST pr= otocol DHCP is extended to provide LoST server=92s domain name to the LoST = client. Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I=92m unclear on how the Master device obtains the URL of a trusted discove= ry server unless there is some pre-configuration involved. I understand tha= t DNS could be used if the Master device is already pre-configured with a p= referred/home TVWS DS URL (or a preferred/home domain that is then resolved= with U-NAPTR) but I don=92t see how DHCP could be used to bootstrap this i= nformation in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_CDD4F3AAF336peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Michael,
In your exam= ple who, or what is making the decision? From a purely practical (DB manage= r) perspective I want to know that the "entity" that made the cho= ice is going to pay for the value added service that is offered, and it has= just signed up for.
I have always seen the value-add as a servic= e/business plane above PAWS rather than something PAWS would define.
<= div>Peter S.

From= : "michael.fitch@bt.co= m" <michael.fitch@bt.co= m>
Date: Wednesday, June= 5, 2013 1:50 PM
To: "Brian.Rosen@neustar.biz" &l= t;Brian.Rosen@neustar.biz>= ;, "dharasty@appcomsci.com" <dharasty@appcomsci.c= om>
Cc: "paws@ietf.org" <paws@ietf.org>
Subject:= Re: [paws] draft-wei-paws-database-discovery-01

=

Dear all

Sor= ry to come in late but the foregoing discussion has sparked a worry in my m= ind.

&nb= sp;

I would like W= SDs to be able to select a database manager from a list, perhaps on the bas= is of price and value-added services offered, such as mobility support.

 

Is there anything in t= he foregoing discussion that would prevent this ?

 

Michael

 

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Brian
Sent: 05 June 2013 18:35
T= o: Harasty, Daniel J
Cc: paw= s@ietf.org
Subject: Re: [paws] draft-wei-paws-database-discov= ery-01

 <= /o:p>

<as individual>

<= p class=3D"MsoNormal">The problem with more than one is what the device doe= s when it has more than one.  

 

=

First of all, reliability, geographic diversity, cap= acity, etc are usually done with common URLs.  Witness www.google.com

Segregation of devices would presumably have diff= erent URLs on different devices, not multiple URLs on the same device.=

 

I don't think configuration is a good solution for = any device, but a simple configuration option is the simplest, most univers= al way to get something to work.

Once you are past simple configuration, I personally feel that discov= ery is the best mechanism.

=  

In this case, we hav= e the issue of multiple countries/regulatory domains, so configuration coul= d be one per region.  The problem with that is figuring out which regi= on (country) you are in.  If you have discovery for that, you can have discovery for the databases.  On the other, other hand, if there are = multiple databases per region, a given device may only have access to one o= f them.  It may have provisioning that tells it which one.  That'= s a combination of discovery and provisioning that avoid asking databases for help that have no incentive to help, and would = prefer not to see unnecessary queries.

 

Brian&nb= sp;

On Jun 5, 201= 3, at 12:16 PM, "Harasty, Daniel J" <dharasty@appcomsci.com> wrote:

=



 

<= div>

Brian Rosen commented:

=  

I would suggest that yo= u get preconfigured with exactly one database.  If that needs to chang= e, change the configuration.<= /p>

 

I don= =92t agree that we write the spec in such a way that enforces =96 or even e= ncourages =96 that a Device should be configurable with exactly one Databas= e URL.

 =

Here=92s my thinking: even if= that Device manufacturer has an exclusive arrangement with a single Databa= se operator, the operator may run multiple Database instances on different URLs for any number of reasons (reliability, geographic diver= sity, capacity, or segregation of the devices based some feature).

=  

=

I think it is much more robust for the devic= e to be allowed =96 even encouraged =96 to be configurable with a list of D= atabase URLs; as it allows Device to try a list =96 and presumably =96 experience fewer outages due to inability to c= ontact any Database.

 

Dan Harasty

Wireless Systems and Networks Dept=

Applied Com= munication Sciences

=

Red Bank, NJ

 

 

 

From: paws-bounces@ietf= .org [mailto:paws-bounces@ietf.org] On Behalf Of Rosen, Bri= an
Sent: Wednes= day, June 05, 2013 9:34 AM
To: Peter Stanforth
Cc: paws@ietf.org; Peter McCann
Subject: Re: [paws] draft-wei-paws-database= -discovery-01

=

 

Well, I thou= ght that is what the protocol doc says, but actually, it's completely uncle= ar about how it works.

 

<= div>

It says, basically, that if= you are permitted to operate in more than one domain, you should be pre-co= nfigured with URIs for

a) all listing servers for each domain<= o:p>

b) all databases for each domain that doesn't have a listing se= rver

 

It has no text that describes how you s= elect one, either the first time, or any subsequent time.  It would be= perfectly compatible with the doc as it is to try servers in a list of 100= randomly until you found one that accepted you.

 

Normally, protocols are prett= y specific about this, so both ends know what will happen.

&nbs= p;

I would suggest that you get preconfigured with exactly one = database.  If that needs to change, change the configuration.

 

Discovery is the mechanism by which you find out abo= ut databases given your location.  It has to be a protocol - you send = in your location (and probably nothing else other than perhaps a device id)= , and you get back a listing server or list of dbs in that area.  Discovery has to work wi= th a set of per country polygons.  The discovery service needs to find= out which country you are in and give you the listing service or dbs for t= hat country.  

 

Devices may have lists o= f dbs they are authorized to use.  If they knew what country they were= in, they could try one of the ones they are configured for.  But some= thing has to tell them that.  You wouldn't configure a device with all the dbs in a country, you would configure one (or possib= ly more), the device was authorized to use.

 

= It might make sense to provide some kind of discovery sequence that has a c= ache of the last server, so you don't have to the whole sequence from the t= op every time you boot.  

<= p class=3D"MsoNormal"> 

I don't think= expecting every db to know about every other country's dbs will scale very= well.  When there is only 2-3 countries that have such DBs, maybe, bu= t if there were 50 or more, the lists would be too difficult for every other DB to track.

 

Brian

 

 

On Jun 5, 2013, at 9:00 AM, Peter Stanf= orth <peter@spectrumbridge.com> wrote:

=




Brian. Why do you assume a device will always go back to its ori= ginal DB rather than the one it last registered with. The latter seems more= likely, and more logical, to me

Peter S.

=


Sent from my iPhone


On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" <Brian.Rosen@neustar.b= iz> wrote:

The problem I see with this is that the database originally cont= acted (presumably configured directly or indirectly) is forever responsible= for referrals to the correct database.  It provides no other service = for the device.

 

If I purchased a device in New York Cit= y and moved to London, the US database has to refer me every time I try to = register.

 

Having a separate database whose j= ob is to do that referral seems like a more rational solution.  Any de= vice or service that wanted to participate in that kind of "nomadic&qu= ot; operation could contribute to the cost of providing the service.  Cross subsidizing the U.S. database from the U.K. datab= ase for the referral seems less likely to succeed.

 <= /o:p>

Brian

 

<= p class=3D"MsoNormal">On Jun 4, 2013, at 10:20 PM, Vin= cent Chen <vchen@google.com> wrote:




Xinpen= g, All,

 

Thanks for putting this together.

 

It seems that discovery involves two aspects:

 - Deployment of LoST servers, which also impacts discovery of L= oST severs

 - Protocol (format of messages that is communi= cated)

 

The current document is placing deplo= yment out of scope, but does suggest that preconfiguration is a strategy.

That just leaves the protocol, which, may be characterized as:

 

  1. Device sends request with its locat= ion

  2. Server responds with a list of (name, uri) pairs<= o:p>

 

Given that this is relatively simple, should= we just build it into PAWS protocol itself?

 <= /span>

For example, the current revision (r05) of the PAWS protocol allows for th= e following:

 

=

 1. Device asks database f= or available spectrum in a location outside the coverage area for the Datab= ae

 2. The Database returns OUTSIDE_COVERAGE error and MAY= include a list of (name, databaseUri) entries to "recommend" alt= ernate databases

 

<= div>

This provides almost the sa= me capability.

 

Should we just add a ListData= base to PAWS?

 

-vince

=  

On Thu, May 23, 2013 at 6:57 PM, Weixinpeng <= ;weixinpeng@huawei.com> wrote:=

Hi Mark,

=          Please see comments inline= . Thanks!

 

Best Regards,

Xinpeng.

 

 

<= div style=3D"border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4= .0pt">

From:<= span class=3D"apple-converted-space"> Mar= k Jones [mailto:mark@azu.ca] 
Sent:&nbs= p;Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; paws@ietf.org<= o:p>


Cc: Pete= r McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

=  

 

Hi Xinpeng,

 

<= div>

Thank you for your responses. I have some further comments/qu= estions inline below (prefixed by mj>).

 <= /p>

From: Weixinpeng [mailto:weixinpeng@huawei.com] 
Sent: May-22-13 11:13 PM
To: Mark Jones; paws@ietf.org
Cc: Peter McCann; Zhulei (A)
Subject= : RE: [paws] draft-we= i-paws-database-discovery-01<= /p>

 = ;

Hi Mark,

     &nb= sp;   Thanks for your feedback, and I think there are some issues= that I need to clarify.

<= /div>

        

       &nb= sp; we have to be clear that the discovery mechanism is provided as an opti= onal method that can help master device to find the correct WSDB, which mea= ns the master device can get WSDB by, such as, pre-configuring of WSDB, provision etc.

 =

mj> Understood.

 =

         The d= ynamic discovery mechanism provides more convenient for master device to fi= nd WSDB, for example, when a new WSDB is setup for providing service or whe= n some deployed WSDB goes down and never work.

 = ;       

mj> In this regard, DNS resolution wo= uld appear to be equally convenient mechanism to manage WSDB instances bein= g commissioned or decommissioned. I view LoST as a kind of =93location-awar= e DNS=94 so I understand its applicability to discovery of the appropriate W= SDB. I still think the draft needs more information on how the Master devic= e finds its WSDB DS so that implementers understand if/when this optional d= iscovery method is applicable to their deployment.

<= div>

[Wei] Yeah, because we cannot covey location information in DNS query me= ssage, so DNS is inappropriate to find the WSDB. I think I will do more cla= rification about how master device finds WSDB DS later.

<= div>

 

=

         About the DHCP you men= tioned below, technically speaking, there have been some extension of DHCP = for supporting the provision of LoST server, refer to RFC5223.

 

mj> I understand= that the DHCP option specifying the LoST server would be provided to the M= aster device when it initiated its backhaul connection (non-WS connection) = to the internet. Correct?

= [Wei] Yeah.

=

 

Besides, using DHCP method doesn=92t means IP network provider must ha= ve some business relationship with WSDB DS provider, if the network provide= r wants to provide master device with FQDN of WSDB DS it can use DHCP.

&nbs= p;

mj>= If the backhaul network operator is configuring his DHCP server to send op= tions to provision the WSDB DS then I assume he has some business interest = in doing so. What am I missing?

[Wei] I think there may be some relationship between = network operator and WSDB DS. But the reason why DHCP is mentioned here is = because in the LoST protocol DHCP is extended to provide LoST server=92s domain name to the LoST client.

 

Thanks

Mark

 

Best Regards,

Xinpeng.<= /span>

 

From: Ma= rk Jones [mailto:mark@azu.ca] 
Sent:&nbs= p;Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; paws@ietf.org
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-datab= ase-discovery-01

 =

Hi Xinpeng,

 

In section 3, you state:

<= span lang=3D"EN-CA" style=3D"font-size:11.0pt;color:#1F497D"> <= span lang=3D"EN-US">

   DNS, DHCP, manually configuring etc, and it= is out of scope of this

<= /div>

   document.

 

I=92m unclear on ho= w the Master device obtains the URL of a trusted discovery server unless th= ere is some pre-configuration involved. I understand that DNS could be used= if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a p= referred/home domain that is then resolved with U-NAPTR) but I don=92t see = how DHCP could be used to bootstrap this information in the TVWS scenarios.= Please could you elaborate.<= /p>

 

Thanks

Mark

 

 =

From: = paws-bounces@ietf.org [mailto:paws-bounces@ietf.o= rg] On Behalf Of Weixinpeng=
Sent: May-21-1= 3 9:11 PM
To: <= a href=3D"mailto:paws@ietf.org" target=3D"_blank">paws@ietf.org
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01=

 =

Hi = all,

         I have uploaded a ne= w version draft on database discovery. Comments are welcomed.

 

=  

Xinpeng Wei


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

<= p class=3D"MsoNormal">

&nb= sp;

-- 
-vince

_______________________________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/l= istinfo/paws

 

_________________________________= ______________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/l= istinfo/paws

 <= /p>

___________________= ____________________________
paws mailing list
paws@ietf.org
https://www.ietf.org/mailman/l= istinfo/paws

 

--_000_CDD4F3AAF336peterspectrumbridgecom_-- From vchen@google.com Wed Jun 5 11:15: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 B22CA21F86B2 for ; Wed, 5 Jun 2013 11:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 V0pPF2Z8lW-P for ; Wed, 5 Jun 2013 11:15:22 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id F371A21F8470 for ; Wed, 5 Jun 2013 11:15:16 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id 9so4524515iec.41 for ; Wed, 05 Jun 2013 11:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7BAbqDhiLqQLsTjB17dSDR/cI86atfAbi1k/b7fPLII=; b=QShj9p1IMXUoIg+OB/mgm8ZVokPzA1rFHNgGyQ0x5tc5I7D9GwiW+7yoxlV8VE1UR5 2ehXA/6HKihMlJTh/Jb35amFedm4DuAAXhVCu+aQFQoUqIyO+nyVW6XnVZkBDFJYexLC QFRAn2lF3fBZxOzSXpqudtILOdGKKlUnqsyZRTq642KIX63XsovG7jNics5+gQFxCV05 WmCQHpEIOmTXwCM7IIamAx8oqKNt6HF/rYYGtg/zYTxCR8BsUpm/oKclYEgdaC14zVYo A0c2hL8aL4k27CeLyFZQbbLhpLEkUb9huygu6ftrtOP4gGm9ap6AoeQA8tL5mKwnn5XE 0mgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=7BAbqDhiLqQLsTjB17dSDR/cI86atfAbi1k/b7fPLII=; b=Z/FSdfieSQrNvJogKn0/AOIUvpekbZLl+P2oTcHk7p/BfKIbBtY1vpAEedgwcGLxKs 7noK1Fh63+F4kCXjV8VI+wV4VQWgeKAQXXUaC1qk0jQSOSMoTsyd5FAm07igoKfeRIah Ztb+70w4XAOZgwcK+CtaXV0BWU8dK+d76T0sUFNPLTtesNjKUVOZ5C1RGuQHsGklsBpt XgF6K90WqrkoB03/sJrKDbH7Yk9V00lqoyjHwgycj8+I05r0xWCcq4WoCwLi64wBKMKD gSuXJlcc3qjTO2UgVXtDHEtZVMPQ5P1OoXZzqb9C6ClGGY9Zuv6nlKgu1Zt65srl3HNe rAcg== MIME-Version: 1.0 X-Received: by 10.42.31.69 with SMTP id y5mr15396473icc.44.1370456091241; Wed, 05 Jun 2013 11:14:51 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Wed, 5 Jun 2013 11:14:51 -0700 (PDT) In-Reply-To: <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> Date: Wed, 5 Jun 2013 11:14:51 -0700 Message-ID: From: Vincent Chen To: "Rosen, Brian" Content-Type: multipart/alternative; boundary=bcaec5186d667fcc5a04de6c2cea X-Gm-Message-State: ALoCoQmQycR4+0ydKJ7HIgdkujvOtQBA3agrQ4NI6951SXrjIkVQy2UXuBYj+qB+F6dR8hRFS+TQhjcVWxwVcwinpoZAvjslPUYSRMfVtR+R1dSIpLtCKP8r7pOJPkCHgfEXUQ/bYpcf2503han80s2prYzkD38FWXWrgOcwC3tL3KBwsrInsVhiebT5VbEWlBYj5takxITA Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 18:15:23 -0000 --bcaec5186d667fcc5a04de6c2cea Content-Type: text/plain; charset=ISO-8859-1 Brian, > First of all, reliability, geographic diversity, capacity, etc are > usually done with common URLs. Witness www.google.com > Your example makes sense in this case, because www.google.com is a single corporate entity and it manages its own reliability, diversity, etc. In contrast, WSDBs are offered by different entities (sometimes competing). The equivalence you are asking for would be http://www.wsdb.com and be automatically routed to different implementations. I don't think that's what we had in mind. -vince --bcaec5186d667fcc5a04de6c2cea Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Brian,


First of all, reliability, geographic diversity, capacity, etc are usu= ally done with common URLs. =A0Witness www.google.com


In contrast, WSDBs are offered by different= entities (sometimes competing). The equivalence you are asking for would
be http://www.wsdb.com a= nd be automatically routed to different implementations. I don't think = that's what we had in mind.

-vince
--bcaec5186d667fcc5a04de6c2cea-- From vchen@google.com Wed Jun 5 11:28:55 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 951D921F9BA7 for ; Wed, 5 Jun 2013 11:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 BNBXLEUsN2F4 for ; Wed, 5 Jun 2013 11:28:54 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5099A21F9BB2 for ; Wed, 5 Jun 2013 11:27:59 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x14so4390170ief.26 for ; Wed, 05 Jun 2013 11:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Vuoo74JZuA/vXrttNGa1pjkggNmC6MwIuzbMvxXTus8=; b=ohZNDFmHXtUP7gn0NubJeMDCF/sVVg5pj2qFU7FdR8ORNSWWKwwOBH7LcyO8oPZp9A 4w1jpd7ygj1euewQQ3JrqQg7HdTXfyx+KqsCCjXxEvul8NxvWlGoscLpWJ3z8PtvYkY7 AijCRgTxtuzWqHe0pv8aAB34W6brpBy5ELlKe+2xdgcrC/SlS7zy7Sa9nulCWN7BxH8a DzfQR9Bsd0pac01OXrtVk0J/B+jR7tLTN5Yq2CXR5T7Scs1Hjt/cqpXRxuKvdzEGN/3Z IteScJBMxOCCDdkLsUrijaBXTVp7Ai2V/Po+k8gFSppIXzOhokcjEvhtGdBp18iHXJnp tOGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Vuoo74JZuA/vXrttNGa1pjkggNmC6MwIuzbMvxXTus8=; b=n3LtW7ToQ6Q+5XkDz+TRamZSRVNa29egi5qslZeXyYIUy7N34CSL7sroQwZQZU5uUy S9eGLOe+T1eVdaBd6WmH4M2mhUGKVB7pAjOMGtbC/BcqM+lcVUnBo7GgPnlIcFl0sCmi X3z6AOChB6H3wgYosOtq7oMnrmFNUzk4wMXMVS3MH83jtNvxsVhhOuyzH3yu1GQjL8Zf 7+GG+Bt/stFtw9XoSwOVz8mn2Cl4zYScqbRtESl0cp9p6lbrD/2mgnNp6eIz1RuMrDxs EQ91ooJsPeL4DRch8iIRrGrXWJynvUOkyO2zQoUuA+vfpV7HfdX37d3lwXA9FCJBnrx7 AXaA== MIME-Version: 1.0 X-Received: by 10.50.136.168 with SMTP id qb8mr3970172igb.5.1370456878798; Wed, 05 Jun 2013 11:27:58 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Wed, 5 Jun 2013 11:27:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 5 Jun 2013 11:27:58 -0700 Message-ID: From: Vincent Chen To: "Harasty, Daniel J" Content-Type: multipart/alternative; boundary=089e0149495e70f00804de6c5b9d X-Gm-Message-State: ALoCoQmvW1NuEDpzM76L7BXrRZySHpOOS/SAGRuyZo08+t5xKAtrR0Y7My8gNAgEGya1ZM1jIfpkzXKNrOR6f//rJVxHf+eOzgb8wBYC/zyKryMfC3iu6ppNLpFB3RXE7x7Pz9pJggC3IUqFqJoNX0+xRp2rRRd32uc1k9BcX1k9Ze0FDhq2ROypypfU+OP1Cx/QXWQkPG+e Cc: "paws@ietf.org" Subject: Re: [paws] clarifying use of HTTP redirect X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 18:28:55 -0000 --089e0149495e70f00804de6c5b9d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you Dan! That sounds reasonable. I'll update the doc. -vince On Wed, Jun 5, 2013 at 6:02 AM, Harasty, Daniel J w= rote: > Vince, all,**** > > ** ** > > I=92d like to propose some clarifications regarding use of HTTP Redirect. > These would be suitable for adding to Section 7 of the **** > > Protocol to Access Spectrum Database, Draft 5. > (=93draft-ietf-paws-protocol-05.txt=94):**** > > ** ** > > The server SHOULD use HTTP status code =93307 Temporary Redirect=94 to > indicate that the Device SHOULD resubmit the same request to an alternate > URL. The device MAY revert to the original URL for the very next request= s, > or MAY continue to use the alternate URL for a period (e.g.: the remainde= r > of its session, or a fixed period of time, or until power-cycled, or unti= l > it receives another redirect). However, it SHOULD NOT modify it stored > list of available URLs.**** > > ** ** > > The server SHOULD use HTTP status code =93301 Moved Permanently=94 to ind= icate > that the Device SHOULD resubmit this request an alternate URL and SHOULD > submit all future requests to the same. If the Device maintains a list o= f > available URLs, it SHOULD replace only the current URL with the replaceme= nt > indicated in the Redirect.**** > > ** ** > > I believe this language will facilitate interoperability.**** > > ** ** > > - Dan Harasty**** > > Wireless Systems and Networks Dept**** > > Applied Communication Sciences**** > > Red Bank, NJ**** > > ** ** > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > > --=20 -vince --089e0149495e70f00804de6c5b9d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Thank you Dan!

That sounds reasonable. = I'll update the doc.

-vince
<= div class=3D"gmail_extra">

On Wed, Jun 5,= 2013 at 6:02 AM, Harasty, Daniel J <dharasty@appcomsci.com> wrote:

Vince, all,

=A0

I=92d like to propose some clarifications regarding = use of HTTP Redirect.=A0 These would be suitable for adding to Section 7 of= the

Protocol to Access Spectrum Database, Draft 5.=A0 (= =93draft-ietf-paws-protocol-05.txt=94):

=A0

The server SHOULD use HTT= P status code =93307 Temporary Redirect=94 to indicate that the Device SHOU= LD resubmit the same request to an alternate URL.=A0 The device MAY revert = to the original URL for the very next requests, or MAY continue to use the alternate URL for a period (e.g.: the remainder= of its session, or a fixed period of time, or until power-cycled, or until= it receives another redirect).=A0 However, it SHOULD NOT modify it stored = list of available URLs.

=A0

The server SHOULD use HTT= P status code =93301 Moved Permanently=94 to indicate that the Device SHOUL= D resubmit this request an alternate URL and SHOULD submit all future reque= sts to the same.=A0 If the Device maintains a list of available URLs, it SHOULD replace only the current URL with the = replacement indicated in the Redirect.

=A0

I believe this language will facilitate interoperabi= lity.

=A0

- Dan Harasty

Wireless Systems and Networks Dept

Applied Communication Sciences

Red Bank, NJ

=A0


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




--
-vince
--089e0149495e70f00804de6c5b9d-- From brian.rosen@neustar.biz Wed Jun 5 11:43:54 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 E826221F9B97 for ; Wed, 5 Jun 2013 11:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.183 X-Spam-Level: X-Spam-Status: No, score=-6.183 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 OWJ+M9UM1jQe for ; Wed, 5 Jun 2013 11:43:49 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 60D2C21F9B8C for ; Wed, 5 Jun 2013 11:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370458000; x=1685815420; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=gpRY21aq18lnJtgMPG3J6h1sOIIQe0iotG2PKo69O3c=; b=B4YpjEhXTTOVvIu7T1hvJrw/KXyGmJS8TnkqpMMwQbH3tKEBlLcL4BZf3UemEN 2yp0C2DjrQAKT4TdYxF/561Q== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24674231; Wed, 05 Jun 2013 14:46:39 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT01.cis.neustar.com (10.31.13.228) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Jun 2013 14:43:37 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Wed, 5 Jun 2013 14:43:31 -0400 From: "Rosen, Brian" To: Vincent Chen Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGw== Date: Wed, 5 Jun 2013 18:43:30 +0000 Message-ID: <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Pz/II0LSUhMpOrxO1R9e9g== Content-Type: multipart/alternative; boundary="_000_245B59959DEF4F78BCE6769B226D8FFDneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 05 Jun 2013 18:43:54 -0000 --_000_245B59959DEF4F78BCE6769B226D8FFDneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, but we are discussing multiple URLs for the SAME db, not multiple dbs. Multiple DBs arise because regulators want competitive options. The list m= anager can list all the approved DBs, but a given WSDB isn't likely to be a= ble to use all of them, or even most of them. I have to bring up business models in an IETF list, but it seems we may nee= d to at least understand what has been thought about with multiple competin= g dbs. The models I've heard about are: 1. The manufacturer contracts with a db, or a db per region to serve the de= vices it manufacturers. This is usually a lifetime of the device arrangeme= nt. Some provision has to be made to allow the owner to use a different DB= , and some provision has to be made to allow a new db to take over a defunc= t (for whatever reason) db URL. 2. A service provider providing a service over WS, the usual example is an = ISP, contracts for the db service for all the devices it provides its servi= ce to. This is annoying to provision unless the device comes from the SP a= s part of the service or a truck roll is needed. Some provision has to be = made to change SPs. Sometimes the SP IS the db operator. 3. A db decides it will offer its service for free. Any device can use it. 4. The end user of the device contracts with the db for service. This usua= lly requires provisioning by the device owner as part of the sign-up proces= s. 5. A notion of "roaming" or "pomading" is supported where your "home" db ha= s a relationship with a "visiting" db in another region who will supply ser= vice when the device is in the other region. And of course there is the single db per region model where all devices in = that region use a single db, with some cost sharing, regulatory fee or tax = arrangement For all of the multiple db per region cases, there ends up being one, or at= most a small number of dbs, that a given device can use within that region= . We could imagine discovery services that had some way of knowing, or the= mselves discovering and caching which of several dbs a given device could u= se. Not sure that makes a whole lot of sense. But it makes virtually no s= ense to just discover the list of possible services and then try them to se= e which one likes you. The notion of caching to avoid asking has some merit. You could cache the = db URL you successfully used last, try it, get an error if you are out of a= rea (or a referral for case 5) and then, if you do get an error, use the di= scovery mechanism to at least find out what region you are in. I don't think that we should be standardizing queries between devices and d= bs that won't serve them. A device should not routinely ask a db for serv= ice when there is no prior arrangement for service. Brian On Jun 5, 2013, at 2:14 PM, Vincent Chen > wrote: Brian, First of all, reliability, geographic diversity, capacity, etc are usually = done with common URLs. Witness www.google.com Your example makes sense in this case, because www.google.com is a single corporate entity and it manages its own reliability,= diversity, etc. In contrast, WSDBs are offered by different entities (sometimes competing).= The equivalence you are asking for would be http://www.wsdb.com and be automatically routed to= different implementations. I don't think that's what we had in mind. -vince --_000_245B59959DEF4F78BCE6769B226D8FFDneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <5C8E7475DB27574881763BAFBDABD9D4@neustar.biz> Content-Transfer-Encoding: quoted-printable <as individual>
No, but we are discussing multiple URLs for the SAME db, not multiple = dbs.

Multiple DBs arise because regulators want competitive options.  = The list manager can list all the approved DBs, but a given WSDB isn't like= ly to be able to use all of them, or even most of them.

I have to bring up business models in an IETF list, but it seems we ma= y need to at least understand what has been thought about with multiple com= peting dbs.

The models I've heard about are:
1. The manufacturer contracts with a db, or a db per region to serve t= he devices it manufacturers.  This is usually a lifetime of the device= arrangement.  Some provision has to be made to allow the owner to use= a different DB, and some provision has to be made to allow a new db to take over a defunct (for whatever reason) db = URL.

2. A service provider providing a service over WS, the usual example i= s an ISP, contracts for the db service for all the devices it provides its = service to.  This is annoying to provision unless the device comes fro= m the SP as part of the service or a truck roll is needed.  Some provision has to be made to change SPs. &= nbsp;Sometimes the SP IS the db operator.

3. A db decides it will offer its service for free.  Any device c= an use it.

4. The end user of the device contracts with the db for service.  = ;This usually requires provisioning by the device owner as part of the sign= -up process.

5. A notion of "roaming" or "pomading" is supporte= d where your "home" db has a relationship with a "visiting&q= uot; db in another region who will supply service when the device is in the= other region.

And of course there is the single db per region model where all device= s in that region use a single db, with some cost sharing, regulatory fee or= tax arrangement

For all of the multiple db per region cases, there ends up being one, = or at most a small number of dbs, that a given device can use within that r= egion.  We could imagine discovery services that had some way of knowi= ng, or themselves discovering and caching which of several dbs a given device could use.  Not sure that makes a= whole lot of sense.  But it makes virtually no sense to just discover= the list of possible services and then try them to see which one likes you= .

The notion of caching to avoid asking has some merit.  You could = cache the db URL you successfully used last, try it, get an error if you ar= e out of area (or a referral for case 5) and then, if you do get an error, = use the discovery mechanism to at least find out what region you are in. 

I don't think that we should be standardizing queries between devices = and dbs that won't serve them.   A device should not routinely ask a d= b for service when there is no prior arrangement for service.

Brian

On Jun 5, 2013, at 2:14 PM, Vincent Chen <vchen@google.com> wrote:

Brian,


First of all, reliability, geographic diversity, capacity, etc are usu= ally done with common URLs.  Witness www.google.com

Your example makes sense in this case, because www.google.com is a single corporate entity and it manages its own reli= ability, diversity, etc.

In contrast, WSDBs are offered by different entities (somet= imes competing). The equivalence you are asking for would
be http://www.wsdb.com= and be automatically routed to different implementations. I don't think th= at's what we had in mind.

-vince

--_000_245B59959DEF4F78BCE6769B226D8FFDneustarbiz_-- From weixinpeng@huawei.com Wed Jun 5 20:30:24 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 1F5F621F941F for ; Wed, 5 Jun 2013 20:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 bqYpH4RvpYWg for ; Wed, 5 Jun 2013 20:30:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2033811E80AE for ; Wed, 5 Jun 2013 20:30:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASD65563; Thu, 06 Jun 2013 03:30:15 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 6 Jun 2013 04:29:22 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 6 Jun 2013 04:30:11 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Thu, 6 Jun 2013 11:30:02 +0800 From: Weixinpeng To: Vincent Chen Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: AQHOYZNHSOkCHv+vxEOcFbw/Solbs5koAV+A Date: Thu, 6 Jun 2013 03:30:01 +0000 Message-ID: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43CA32BCEnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Jun 2013 03:30:24 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43CA32BCEnkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vince, , I am not quite clear about how OUTSIDE_COVERAGE works, if the data= base is in charge of returning a list of alternate database with OUTSIDE_CO= VERAGE error, does it means the database has to maintain some information, such as coverage area, of other databases? And h= ow it works when databases are managed by different companies? If a master moves from USA to UK, can the database that the master= originally connected return available database in UK to master? Another question is, if a Database Listing server is used, what in= terface will be deployed between master and Database Listing server, is the= re an existing one, or a new one should be devised? Finally, when HTTP redirect is provided in the protocol, can you e= xplain it to me when "DbUpdateSpec" be used and when HTTP redirect will be = used, if database wants to provide an alternate datebase? Thanks! -Xinpeng From: Vincent Chen [mailto:vchen@google.com] Sent: Wednesday, June 05, 2013 10:21 AM To: Weixinpeng Cc: Mark Jones; paws@ietf.org; Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 Xinpeng, All, Thanks for putting this together. It seems that discovery involves two aspects: - Deployment of LoST servers, which also impacts discovery of LoST severs - Protocol (format of messages that is communicated) The current document is placing deployment out of scope, but does suggest t= hat preconfiguration is a strategy. That just leaves the protocol, which, may be characterized as: 1. Device sends request with its location 2. Server responds with a list of (name, uri) pairs Given that this is relatively simple, should we just build it into PAWS pro= tocol itself? For example, the current revision (r05) of the PAWS protocol allows for the= following: 1. Device asks database for available spectrum in a location outside the c= overage area for the Databae 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (= name, databaseUri) entries to "recommend" alternate databases This provides almost the same capability. Should we just add a ListDatabase to PAWS? -vince On Thu, May 23, 2013 at 6:57 PM, Weixinpeng > wrote: Hi Mark, Please see comments inline. Thanks! Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Thursday, May 23, 2013 10:31 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline= below (prefixed by mj>). From: Weixinpeng [mailto:weixinpeng@huawei.com] Sent: May-22-13 11:13 PM To: Mark Jones; paws@ietf.org Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I= need to clarify. we have to be clear that the discovery mechanism is provided as an= optional method that can help master device to find the correct WSDB, whic= h means the master device can get WSDB by, such as, pre-configuring of WSDB= , provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for maste= r device to find WSDB, for example, when a new WSDB is setup for providing = service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient me= chanism to manage WSDB instances being commissioned or decommissioned. I vi= ew LoST as a kind of "location-aware DNS" so I understand its applicability= to discovery of the appropriate WSDB. I still think the draft needs more i= nformation on how the Master device finds its WSDB DS so that implementers = understand if/when this optional discovery method is applicable to their de= ployment. [Wei] Yeah, because we cannot covey location information in DNS query messa= ge, so DNS is inappropriate to find the WSDB. I think I will do more clarif= ication about how master device finds WSDB DS later. About the DHCP you mentioned below, technically speaking, there ha= ve been some extension of DHCP for supporting the provision of LoST server,= refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be p= rovided to the Master device when it initiated its backhaul connection (non= -WS connection) to the internet. Correct? [Wei] Yeah. Besides, using DHCP method doesn't means IP network provider must have some= business relationship with WSDB DS provider, if the network provider wants= to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send= options to provision the WSDB DS then I assume he has some business intere= st in doing so. What am I missing? [Wei] I think there may be some relationship between network operator and W= SDB DS. But the reason why DHCP is mentioned here is because in the LoST pr= otocol DHCP is extended to provide LoST server's domain name to the LoST cl= ient. Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:mark@azu.ca] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; paws@ietf.org Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I'm unclear on how the Master device obtains the URL of a trusted discovery= server unless there is some pre-configuration involved. I understand that = DNS could be used if the Master device is already pre-configured with a pre= ferred/home TVWS DS URL (or a preferred/home domain that is then resolved w= ith U-NAPTR) but I don't see how DHCP could be used to bootstrap this infor= mation in the TVWS scenarios. Please could you elaborate. Thanks Mark From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: paws@ietf.org Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comment= s are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws -- -vince --_000_C5C3BB522B1DDF478AA09545169155B43CA32BCEnkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vince, ,

 &nbs= p;       I am not quite clear about how OUTSI= DE_COVERAGE works, if the database is in charge of returning a list of alte= rnate database with OUTSIDE_COVERAGE error, does it means the database has to

maintain s= ome information, such as coverage area, of other databases? And how it work= s when databases are managed by different companies?

 &nbs= p;       If a master moves from USA to UK, ca= n the database that the master originally connected return available databa= se in UK to master?

 = ;

 &nbs= p;       Another question is, if a Database L= isting server is used, what interface will be deployed between master and D= atabase Listing server, is there an existing one, or a new one should be devised?

 &nbs= p;      

 &nbs= p;       Finally, when HTTP redirect is provi= ded in the protocol, can you explain it to me when “DbUpdateSpec̶= 1; be used and when HTTP redirect will be used, if database wants to provide an alternate datebase?

 &nbs= p;      

 &nbs= p;       Thanks!

-Xinpeng

 = ;

From: Vincent Chen [mailto:vchen@google.com]
Sent: Wednesday, June 05, 2013 10:21 AM    
To: Weixinpeng
Cc: Mark Jones; paws@ietf.org; Peter McCann
Subject: Re: [paws] draft-wei-paws-database-discovery-01<= /span>

 

Xinpeng, All,=

 

Thanks for putting this togethe= r.

 

It seems that discovery involve= s two aspects:

 - Deployment of LoST serv= ers, which also impacts discovery of LoST severs

 - Protocol (format of mes= sages that is communicated)

 

The current document is placing= deployment out of scope, but does suggest that preconfiguration is a strat= egy.

That just leaves the protocol, = which, may be characterized as:

 

  1. Device sends request = with its location

  2. Server responds with = a list of (name, uri) pairs

 

Given that this is relatively s= imple, should we just build it into PAWS protocol itself?=

 

For example, the current revisi= on (r05) of the PAWS protocol allows for the following:

 

 1. Device asks database f= or available spectrum in a location outside the coverage area for the Datab= ae

 2. The Database returns O= UTSIDE_COVERAGE error and MAY include a list of (name, databaseUri) entries= to "recommend" alternate databases

 

This provides almost the same c= apability.

 

Should we just add a ListDataba= se to PAWS?

 

-vince

=  

On Thu, May 23, 2013 at 6:57 PM= , Weixinpeng <weixinpeng@huawei.com> wrote:

Hi Mark,

   &nb= sp;     Please see comments inline. Thanks!

 

Best Regards,<= span lang=3D"EN-US">

Xinpeng.

 

 

From: Mark Jones [mailto:mark@azu.ca= ]
Sent: Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; p= aws@ietf.org


Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01<= /span>

 

Hi X= inpeng,

&nbs= p;

Than= k you for your responses. I have some further comments/questions inline bel= ow (prefix= ed by mj>).

&nbs= p;

From: Weixinpeng [mailto:weixinp= eng@huawei.com]
Sent: May-22-13 11:13 PM
To: Mark Jones; p= aws@ietf.org
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

 =

Hi Mark,

   &nb= sp;     Thanks for your feedback, and I think there are= some issues that I need to clarify.=

   &nb= sp;    

   &nb= sp;     we have to be clear that the discovery mechanis= m is provided as an optional method that can help master device to find the= correct WSDB, which means the master device can get WSDB by, such as, pre-configur= ing of WSDB, provision etc.

 

mj> U= nderstood.

&nbs= p;

   &nb= sp;     The dynamic discovery mechanism provides more c= onvenient for master device to find WSDB, for example, when a new WSDB is s= etup for providing service or when some deployed WSDB goes down and never work.=

   &nb= sp;    

mj> I= n this regard, DNS resolution would appear to be equally convenient mechani= sm to manage WSDB instances being commissioned or decommissioned. I view LoST as a kind of “location-aware DNS̶= 1; so I understand its applicability to discovery of the appropriate WSDB. = I still think the draft needs more information on how the Master device fin= ds its WSDB DS so that implementers understand if/when this optional discovery method is applicable to their deployment.<= /span>

[Wei] Yeah, bec= ause we cannot covey location information in DNS query message, so DNS is i= nappropriate to find the WSDB. I think I will do more clarification about how master device finds WSDB DS later.

&nbs= p;

   &nb= sp;     About the DHCP you mentioned below, technically= speaking, there have been some extension of DHCP for supporting the provis= ion of LoST server, refer to RFC5223.

&nbs= p;

mj> I= understand that the DHCP option specifying the LoST server would be provid= ed to the Master device when it initiated its backhaul connection (non-WS connection) to the internet. Correct?

[Wei] Yeah.

&nbs= p;

Besides, using DHCP m= ethod doesn’t means IP network provider must have some business relat= ionship with WSDB DS provider, if the network provider wants to provide master device with FQDN of WSDB DS it can use DH= CP.

 

mj> I= f the backhaul network operator is configuring his DHCP server to send opti= ons to provision the WSDB DS then I assume he has some business interest in doing so. What am I missing?

[Wei] I think t= here may be some relationship between network operator and WSDB DS. But the= reason why DHCP is mentioned here is because in the LoST protocol DHCP is extended to provide LoST server’s domai= n name to the LoST client.

 

Thanks

Mark

&nbs= p;

Best Regards,<= span lang=3D"EN-US">

Xinpeng.

 

From: Mark Jones [mailto:mark@azu.ca= ]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; p= aws@ietf.org
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01

 

Hi X= inpeng,

&nbs= p;

In s= ection 3, you state:

&nbs= p;

   The URL or IP address of WSDB DS can be foun= d by any method such as

   DNS, DHCP, manually configuring etc, and it = is out of scope of this

   document.

&nbs= p;

I= 217;m unclear on how the Master device obtains the URL of a trusted discove= ry server unless there is some pre-configuration involved. I understand that DNS could be used if the Master device is alre= ady pre-configured with a preferred/home TVWS DS URL (or a preferred/home d= omain that is then resolved with U-NAPTR) but I don’t see how DHCP co= uld be used to bootstrap this information in the TVWS scenarios. Please could you elaborate.

&nbs= p;

Than= ks

Mark=

&nbs= p;

&nbs= p;

From: paws-bounces@iet= f.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: paws@ietf.org=
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

 =

Hi all,

       &nb= sp; I have uploaded a new version draft on database discovery. Comments are= welcomed.

http://tools.ietf.org/html/draft-we= i-paws-database-discovery-01.

 

 

Xinpeng Wei

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



 

--
-vince

--_000_C5C3BB522B1DDF478AA09545169155B43CA32BCEnkgeml507mbxchi_-- From vchen@google.com Thu Jun 6 01:07: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 99FFA21F9246 for ; Thu, 6 Jun 2013 01:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 9ixQvKRs-9Px for ; Thu, 6 Jun 2013 01:07:42 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9F21C21F9263 for ; Thu, 6 Jun 2013 01:07:42 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id k13so6303851iea.32 for ; Thu, 06 Jun 2013 01:07:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G8MtETzuO4Fu5RE8p/CpwrQsNr0xaxyK+xK++6erd+w=; b=pQTAkkc5Gifnazc5EuAZiAzR6x0rQL4sdUITEDh7diggZFVkqYhOi//ma39C0MexX8 nEU7ECX+FuyAEzYn1EFqTuqbvAr0JSn5X+VJcPl/gQGHXnbGoWBg6ArCQxWzw4JKnGuO n5x/4oRSiPIarWl6pwa4YDIYQEnINONhwKuXJnXu4gbeVnP1/JLjq7byto7pcKFcyXPm Qm/EVH0r26lmedkDZ+S3CL63itezqPWcWDxYhacpJRs20qqn3FZT6epff4foEmzMzTCn w434S8oMfOkiSKnm1nm0TrlvyKbyrGehUjBCvmxlEO1+cz/uC3glZ44sTHmFHK8bcTDE Yl5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=G8MtETzuO4Fu5RE8p/CpwrQsNr0xaxyK+xK++6erd+w=; b=oCJ8q0jwIx9S2fMisMbrGfXSvAes2vIPj8bEFKhn/jUZUhJ36kowjPqYMEfyt1KPTa P1trX8g7xyklQO7wiJVwKeJZIfSGbNY8kS+vIeVq6IAv0XwhjAPOmgT6upuNLUN3LKSC 6F5MBzM3qO7X09YEomOo0vQ2VTAoTODb836uQ+mUA7P41OHVoLg+I6iLjcT5Hv6ErTRT aJUeUlWwR7uyy4WlNNG5J5bX2pQazynSKrppVjoDPYsaubQzCQZELwCk1mgkDwYTTdUJ zDbuptC1I90HG/pbQgwp5iAvABwoup+neAX9fCf1VRWBVcHx9JlVENi95/pi3bGhz7Y0 4r3g== MIME-Version: 1.0 X-Received: by 10.42.50.202 with SMTP id b10mr16683361icg.7.1370506061971; Thu, 06 Jun 2013 01:07:41 -0700 (PDT) Received: by 10.64.11.72 with HTTP; Thu, 6 Jun 2013 01:07:41 -0700 (PDT) In-Reply-To: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> Date: Thu, 6 Jun 2013 01:07:41 -0700 Message-ID: From: Vincent Chen To: Weixinpeng Content-Type: multipart/alternative; boundary=90e6ba61453afd838804de77ce3e X-Gm-Message-State: ALoCoQmAwOFe9N9FfKmuCgac9AWmOtTvGGRcGPMqF3oPxL8NSBG9aNMoQHusUD5MnplI7q8c/+JWUgbGv+3SuvSkyVe7NnycO98jUPbqwD8p6oMogzs83Z04w444Omjx4PaA77nojgYno87QfdWEBW/Tay6DEqNBiw68He9mmOaj+ohI4jH4JTMcXR7KIZBrRxx9QX7zJC1e Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 06 Jun 2013 08:07:43 -0000 --90e6ba61453afd838804de77ce3e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Xinpeng, On Wed, Jun 5, 2013 at 8:30 PM, Weixinpeng wrote: > Hi Vince, ,**** > > I am not quite clear about how OUTSIDE_COVERAGE works, if the > database is in charge of returning a list of alternate database with > OUTSIDE_COVERAGE error, does it means the database has to **** > > maintain some information, such as coverage area, of other databases? And > how it works when databases are managed by different companies? > This alternate list is optional, so it's up to the database, business arrangements, and, possibly, regulatory requirements. Because the return value here is very much like what you are proposing, I was exploring whether we should just add a ListDatabase method to the PAWS protocol such that the device just needs to understand one protocol. This would allow: - A database to serve as both listing functionality (if it wants) as well as the spectrum-availability functionality - A server can choose to implement only the ListDatabase functionality In the second case, it would be equivalent to your proposal, just that the protocol messages would be in the same JSONRPC format as the PAWS protocol, rather than the LoST XML format. (If we were to add the method, I think we should remove the listing from OUTSIDE_COVERAGE error). > **** > > If a master moves from USA to UK, can the database that the > master originally connected return available database in UK to master? > That should be allowed. > **** > > ** ** > > Another question is, if a Database Listing server is used, what > interface will be deployed between master and Database Listing server, is > there an existing one, or a new one should be devised? > It should be the same one. This simplifies the device implementation. **** > > **** > > Finally, when HTTP redirect is provided in the protocol, can you > explain it to me when =93DbUpdateSpec=94 be used and when HTTP redirect w= ill be > used, if database wants to provide an alternate datebase? > Great question. There was some thought that HTTP redirect can only return a single URL without additional "attributes", so is less flexible in case we wanted to convey more information about the change. On the other hand, DbUpdateSpec does add a bit more complexity. I think there was also some concern that HTTP redirect is at the outer layer, so does not pass through any hand-shake that might have been required by a WSDB via the INIT_REQ mechanism. So...does the simplicity of HTTP redirect outweigh the benefits? -vince **** > > **** > > Thanks!**** > > -Xinpeng**** > > > --90e6ba61453afd838804de77ce3e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Xinpeng,


On Wed, Jun 5, 2013 at 8:30 PM, Weixinpen= g <weixinpeng@huawei.com> wrote:

Hi Vince, ,

=A0=A0=A0= =A0=A0=A0=A0=A0 I am not quite clear about how OUTSIDE_COVERAGE works, if t= he database is in charge of returning a list of alternate database with OUT= SIDE_COVERAGE error, does it means the database has to

maintain s= ome information, such as coverage area, of other databases? And how it work= s when databases are managed by different companies?


This alternate list is o= ptional, so it's up to the database, business arrangements, and, possib= ly, regulatory requirements.

Because t= he return value here is very much like what you are proposing, I was explor= ing whether we should just add a ListDatabase method to the PAWS protocol s= uch that the device just needs to understand one protocol. This would allow= :

=A0- A database to serve as both listing fu= nctionality (if it wants) as well as the spectrum-availability functionalit= y
=A0- A server can choose to implement only the ListDataba= se functionality

In the second case, it would be equivalent = to your proposal, just that the protocol messages would be in the same JSON= RPC format as the PAWS protocol, rather than the LoST XML format.

(If we were to add the method, I think we s= hould remove the listing from OUTSIDE_COVERAGE error).

=
=A0

=A0=A0=A0= =A0=A0=A0=A0=A0 If a master moves from USA to UK, can the database that the= master originally connected return available database in UK to master?


That should be allowed.<= /div>
=A0

=A0=

=A0=A0=A0= =A0=A0=A0=A0=A0 Another question is, if a Database Listing server is used, = what interface will be deployed between master and Database Listing server, is there an existing one, or a new one should be devised?

=

It should be the same one. Thi= s simplifies the device implementation.

=A0=A0=A0= =A0=A0=A0=A0=A0

=A0=A0=A0= =A0=A0=A0=A0=A0 Finally, when HTTP redirect is provided in the protocol, ca= n you explain it to me when =93DbUpdateSpec=94 be used and when HTTP redire= ct will be used, if database wants to provide an alternate datebase?


Great question. There was s= ome thought that HTTP redirect can only return a single URL without additio= nal "attributes", so is less flexible in case we wanted to convey= more information about the change. On the other hand, DbUpdateSpec does ad= d a bit more complexity.

I think there was also some concern that HT= TP redirect is at the outer layer, so does not pass through any hand-shake = that might have been required by a WSDB via the INIT_REQ mechanism.

So...does the simplicity of HTTP redirect o= utweigh the benefits?

-vince

<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1f497d">

=A0=A0=A0= =A0=A0=A0=A0=A0

=A0=A0=A0= =A0=A0=A0=A0=A0 Thanks!

-Xinpeng


--90e6ba61453afd838804de77ce3e-- From weixinpeng@huawei.com Sat Jun 8 00:50:34 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 8AE8221F99EB for ; Sat, 8 Jun 2013 00:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 aEzrr4ivd-Bu for ; Sat, 8 Jun 2013 00:50:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0F03F21F99E3 for ; Sat, 8 Jun 2013 00:50:21 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR42033; Sat, 08 Jun 2013 07:50:20 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 8 Jun 2013 08:49:17 +0100 Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 8 Jun 2013 08:50:16 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.01.0323.007; Sat, 8 Jun 2013 15:50:04 +0800 From: Weixinpeng To: Vincent Chen Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: AQHOYZNHSOkCHv+vxEOcFbw/Solbs5koAV+A///PM4CAA53YgA== Date: Sat, 8 Jun 2013 07:50:04 +0000 Message-ID: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43CA32D9Cnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" , "Malyar, John P" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 08 Jun 2013 07:50:34 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43CA32D9Cnkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vince, All I think the business relationships between master device vendor, r= egulatory body and database operator is very important to decide how to dep= loy database discovery mechanism further, so maybe we should have a discuss about it and have a more clear descriptio= n of these relationships, can anyone provide some information about this? T= hanks! -Xinpeng From: Vincent Chen [mailto:vchen@google.com] Sent: Thursday, June 06, 2013 4:08 PM To: Weixinpeng Cc: Mark Jones; paws@ietf.org; Peter McCann; Zhulei (A) Subject: Re: [paws] draft-wei-paws-database-discovery-01 Xinpeng, On Wed, Jun 5, 2013 at 8:30 PM, Weixinpeng > wrote: Hi Vince, , I am not quite clear about how OUTSIDE_COVERAGE works, if the data= base is in charge of returning a list of alternate database with OUTSIDE_CO= VERAGE error, does it means the database has to maintain some information, such as coverage area, of other databases? And h= ow it works when databases are managed by different companies? This alternate list is optional, so it's up to the database, business arran= gements, and, possibly, regulatory requirements. Because the return value here is very much like what you are proposing, I w= as exploring whether we should just add a ListDatabase method to the PAWS p= rotocol such that the device just needs to understand one protocol. This wo= uld allow: - A database to serve as both listing functionality (if it wants) as well = as the spectrum-availability functionality - A server can choose to implement only the ListDatabase functionality In the second case, it would be equivalent to your proposal, just that the = protocol messages would be in the same JSONRPC format as the PAWS protocol,= rather than the LoST XML format. (If we were to add the method, I think we should remove the listing from OU= TSIDE_COVERAGE error). If a master moves from USA to UK, can the database that the master= originally connected return available database in UK to master? That should be allowed. Another question is, if a Database Listing server is used, what in= terface will be deployed between master and Database Listing server, is the= re an existing one, or a new one should be devised? It should be the same one. This simplifies the device implementation. Finally, when HTTP redirect is provided in the protocol, can you e= xplain it to me when "DbUpdateSpec" be used and when HTTP redirect will be = used, if database wants to provide an alternate datebase? Great question. There was some thought that HTTP redirect can only return a= single URL without additional "attributes", so is less flexible in case we= wanted to convey more information about the change. On the other hand, DbU= pdateSpec does add a bit more complexity. I think there was also some concern that HTTP redirect is at the outer laye= r, so does not pass through any hand-shake that might have been required by= a WSDB via the INIT_REQ mechanism. So...does the simplicity of HTTP redirect outweigh the benefits? -vince Thanks! -Xinpeng --_000_C5C3BB522B1DDF478AA09545169155B43CA32D9Cnkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vince, = All

 &nbs= p;       I think the business relationships b= etween master device vendor, regulatory body and database operator is very = important to decide how to deploy database discovery mechanism further,

so maybe w= e should have a discuss about it and have a more clear description of these= relationships, can anyone provide some information about this? Thanks!

 = ;

 = ;

-Xinpeng

 = ;

 = ;

 = ;

 = ;

From: Vincent Chen [mailto:vchen@google.com]
Sent: Thursday, June 06, 2013 4:08 PM
To: Weixinpeng
Cc: Mark Jones; paws@ietf.org; Peter McCann; Zhulei (A)
Subject: Re: [paws] draft-wei-paws-database-discovery-01<= /span>

 

Xinpeng,

 

 

On Wed, Jun 5, 2013 at 8:30 PM,= Weixinpeng <= weixinpeng@huawei.com> wrote:

Hi Vince, ,

    =      I am not quite clear about how OUTSIDE_COVERAGE wo= rks, if the database is in charge of returning a list of alternate database with OUTSIDE_COVERAGE err= or, does it means the database has to

maintain some informatio= n, such as coverage area, of other databases? And how it works when databases are managed by different companies?

 

This alternate list is optional= , so it's up to the database, business arrangements, and, possibly, regulat= ory requirements.

 

Because the return value here i= s very much like what you are proposing, I was exploring whether we should = just add a ListDatabase method to the PAWS protocol such that the device ju= st needs to understand one protocol. This would allow:

 

 - A database to serve as = both listing functionality (if it wants) as well as the spectrum-availabili= ty functionality

 - A server can choose to = implement only the ListDatabase functionality

 

In the second case, it would be= equivalent to your proposal, just that the protocol messages would be in t= he same JSONRPC format as the PAWS protocol, rather than the LoST XML forma= t.

 

(If we were to add the method, = I think we should remove the listing from OUTSIDE_COVERAGE error).

 

 

    =      If a master moves from USA to UK, can the database= that the master originally connected return available database in UK to master?

 

That should be allowed.

 

 

    =      Another question is, if a Database Listing server = is used, what interface will be deployed between master and Database Listing server, is there an existi= ng one, or a new one should be devised?

 

It should be the same one. This= simplifies the device implementation.

 

    =     

    =      Finally, when HTTP redirect is provided in the pro= tocol, can you explain it to me when “DbUpdateSpec” be used and when HTTP redirect will = be used, if database wants to provide an alternate datebase?

 

Great question. There was some = thought that HTTP redirect can only return a single URL without additional = "attributes", so is less flexible in case we wanted to convey mor= e information about the change. On the other hand, DbUpdateSpec does add a bit more complexity.

 

I think there was also some con= cern that HTTP redirect is at the outer layer, so does not pass through any= hand-shake that might have been required by a WSDB via the INIT_REQ mechan= ism.

 

So...does the simplicity of HTT= P redirect outweigh the benefits?

 

-vince

 

    =     

    =      Thanks!

-Xinpeng

 

--_000_C5C3BB522B1DDF478AA09545169155B43CA32D9Cnkgeml507mbxchi_-- From lei.zhu@huawei.com Sat Jun 8 18:37:50 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 DB9D621F8D2B for ; Sat, 8 Jun 2013 18:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.155 X-Spam-Level: X-Spam-Status: No, score=-1.155 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A774CjP1-LiN for ; Sat, 8 Jun 2013 18:37:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B9FBD21F85D1 for ; Sat, 8 Jun 2013 18:37:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATR82283; Sun, 09 Jun 2013 01:37:42 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 9 Jun 2013 02:36:43 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 9 Jun 2013 02:37:38 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Sun, 9 Jun 2013 09:37:26 +0800 From: "Zhulei (A)" To: Weixinpeng , Vincent Chen Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: AQFYo+VXBs/17kMZVWofdvD7MTZ5AJn8s3/ggABFggCAAL1CgIAAv/SAgBLiaACAAaW6gIAATZWAgAMfvQCAAauy4A== Date: Sun, 9 Jun 2013 01:37:25 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE625257BB564@NKGEML512-MBS.china.huawei.com> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.65.68] Content-Type: multipart/alternative; boundary="_000_470F27D1263A1B4EB73491ED995DE625257BB564NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" , "Malyar, John P" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 01:37:51 -0000 --_000_470F27D1263A1B4EB73491ED995DE625257BB564NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksDQoNClRoaW5rcyBvY2N1ciB0byBtZSwgYW5kIHByb3ZpZGUgdGhlIGlkZWFzIGJlZm9yZSBy ZWFsbHkgZ2V0IGl0Lg0KDQpJIHN1cHBvc2VkIHRoYXQgREIgYXMgc2VydmljZSB0byBkaXNjb3Zl ciBzaG91bGQgYmUgYW4gSW50ZXJuZXQgc2VydmljZSwgYnV0IG5vdCBzdXJlIGFueSBtb3JlIGJ5 IGxvb2tpbmcgYXQgcHJvcG9zZWQgdGV4dCAgaW4gc2VjdGlvbiA0LjEuMSBvZiBwYXdzIHByb3Rv Y29sLTA1Lg0KDQpTb21lIGRldGFpbCBpbXBsZW1lbnRhdGlvbnMgb2NjdXIgdG8gbWUgaWYgSSBj YW4gc2VyaW91c2x5IHRoaW5rIG92ZXIgdGhlIHByb3Bvc2FsOg0KDQoxLiAgICAgIElGIHJlZ3Vs YXRvcnkgc2VlbXMgdG8gbWFpbnRhaW4gYSBsb2NhdGlvbiBhbmQgREIgbGlzdCBtYXBwaW5nIGlu IGRvbWluYXRlZCBhcmVhPyBJRiByZWd1bGF0b3J5IHNlZW1zIG1haW50YWluIHRoZSBEQiBVUkwg bGlzdCBvZiBvdGhlciByZWd1bGF0b3J5IGRvbWFpbiihsFOhsSk/DQoNCkkgd291bGQgc3RpbGwg dGhpbmsgcHJvcG9zYWwgaW4gc2VjdGlvbiA0LjEuMSBvZiBwYXdzLXByb3RvY29sLTA1IGlzIGFi b3V0IGEgdmVyeSBzaG9ydCB0ZXJtIGNvbnNpZGVyYXRpb25zLCBzaG91bGQgYmUgbm90IGV4YWN0 bHkgc2FtZSBwcm9wb3NhbCBhcyB0aGF0IGluIFdlaaGvcyBEQiBkaXNjb3ZlcnkgcHJvdG9jb2wu IFNvLCB0aGUgbW90aXZhdGlvbnMgYW5kIHRoZSBzY2VuYXJpb3MgaGF2ZSBub3QgYmVlbiBjbGVh cmVkLg0KDQoNCjIuICAgICAgVGhlIGltcGxlbWVudGF0aW9ucyBvZiBzZWN0aW9uIDQuMS4xIG9m IHBhd3MtcG90b2NvbC0wNSBpcyBub3QgcmVhZHkgYWN0dWFsbHksIGFuZCBldmVuIG5vdCBkaXNj dXNzZWQgYmVmb3JlLiBJIGFtIG5vdCBhYmxlIHRvIGltYWdlIHRoZSBpbnRlcmZhY2VzIGFuZCBt ZXNzYWdlIGFzIGltcGxlbWVudGF0aW9uIGlzc3VlcywgYXMgdGhleSBhcmUgYWxsIGFib3V0IGEg cHJvdG9jb2wuDQoNCg0KMy4gICAgICBTdGlsbCBub3QgcmVhZHkgdG8gYWNjZXB0IEhUVFAgMzAy LzMwMSBtZXRob2QgdG8gcmVwbHkgbW9yZSB0aGFuIG9uZSByZWZlcnJpbmcgZGVzdGluYXRpb25z LiBJIHRoaW5rIHRoaXMgaWRlYSBpcyBub3QgYWJvdXQgY29tcGxleGl0eSwgIGp1c3Qgd3Jvbmcu DQoNCkJlc3QgcmVnYXJkcywNClpodSBMZWkNCkh1YXdlaQ0KV2lyZWxlc3MgbmV0d29yayByZXNl YXJjaCBkZXBhcnRtZW50DQpFLW1haWwgYWRkcmVzczogbGVpLnpodUBodWF3ZWkuY29tDQpQaG9u ZTogKzg2LTEwLTYwNjExOTYxDQpNb2JpbGU6ICs4Ni0xMzkxMDE1NzAyMA0KDQq3orz+yMs6IFdl aXhpbnBlbmcNCreiy83KsbzkOiAyMDEzxOo21MI4yNUgMTU6NTANCsrVvP7IyzogVmluY2VudCBD aGVuDQqzrcvNOiBNYXJrIEpvbmVzOyBwYXdzQGlldGYub3JnOyBQZXRlciBNY0Nhbm47IFpodWxl aSAoQSk7IE1hbHlhciwgSm9obiBQDQrW98ziOiBSRTogW3Bhd3NdIGRyYWZ0LXdlaS1wYXdzLWRh dGFiYXNlLWRpc2NvdmVyeS0wMQ0KDQpIaSBWaW5jZSwgQWxsDQogICAgICAgICBJIHRoaW5rIHRo ZSBidXNpbmVzcyByZWxhdGlvbnNoaXBzIGJldHdlZW4gbWFzdGVyIGRldmljZSB2ZW5kb3IsIHJl Z3VsYXRvcnkgYm9keSBhbmQgZGF0YWJhc2Ugb3BlcmF0b3IgaXMgdmVyeSBpbXBvcnRhbnQgdG8g ZGVjaWRlIGhvdyB0byBkZXBsb3kgZGF0YWJhc2UgZGlzY292ZXJ5IG1lY2hhbmlzbSBmdXJ0aGVy LA0Kc28gbWF5YmUgd2Ugc2hvdWxkIGhhdmUgYSBkaXNjdXNzIGFib3V0IGl0IGFuZCBoYXZlIGEg bW9yZSBjbGVhciBkZXNjcmlwdGlvbiBvZiB0aGVzZSByZWxhdGlvbnNoaXBzLCBjYW4gYW55b25l IHByb3ZpZGUgc29tZSBpbmZvcm1hdGlvbiBhYm91dCB0aGlzPyBUaGFua3MhDQoNCg0KLVhpbnBl bmcNCg0KDQoNCg0KRnJvbTogVmluY2VudCBDaGVuIFttYWlsdG86dmNoZW5AZ29vZ2xlLmNvbV0N ClNlbnQ6IFRodXJzZGF5LCBKdW5lIDA2LCAyMDEzIDQ6MDggUE0NClRvOiBXZWl4aW5wZW5nDQpD YzogTWFyayBKb25lczsgcGF3c0BpZXRmLm9yZzsgUGV0ZXIgTWNDYW5uOyBaaHVsZWkgKEEpDQpT dWJqZWN0OiBSZTogW3Bhd3NdIGRyYWZ0LXdlaS1wYXdzLWRhdGFiYXNlLWRpc2NvdmVyeS0wMQ0K DQpYaW5wZW5nLA0KDQoNCk9uIFdlZCwgSnVuIDUsIDIwMTMgYXQgODozMCBQTSwgV2VpeGlucGVu ZyA8d2VpeGlucGVuZ0BodWF3ZWkuY29tPG1haWx0bzp3ZWl4aW5wZW5nQGh1YXdlaS5jb20+PiB3 cm90ZToNCkhpIFZpbmNlLCAsDQogICAgICAgICBJIGFtIG5vdCBxdWl0ZSBjbGVhciBhYm91dCBo b3cgT1VUU0lERV9DT1ZFUkFHRSB3b3JrcywgaWYgdGhlIGRhdGFiYXNlIGlzIGluIGNoYXJnZSBv ZiByZXR1cm5pbmcgYSBsaXN0IG9mIGFsdGVybmF0ZSBkYXRhYmFzZSB3aXRoIE9VVFNJREVfQ09W RVJBR0UgZXJyb3IsIGRvZXMgaXQgbWVhbnMgdGhlIGRhdGFiYXNlIGhhcyB0bw0KbWFpbnRhaW4g c29tZSBpbmZvcm1hdGlvbiwgc3VjaCBhcyBjb3ZlcmFnZSBhcmVhLCBvZiBvdGhlciBkYXRhYmFz ZXM/IEFuZCBob3cgaXQgd29ya3Mgd2hlbiBkYXRhYmFzZXMgYXJlIG1hbmFnZWQgYnkgZGlmZmVy ZW50IGNvbXBhbmllcz8NCg0KVGhpcyBhbHRlcm5hdGUgbGlzdCBpcyBvcHRpb25hbCwgc28gaXQn cyB1cCB0byB0aGUgZGF0YWJhc2UsIGJ1c2luZXNzIGFycmFuZ2VtZW50cywgYW5kLCBwb3NzaWJs eSwgcmVndWxhdG9yeSByZXF1aXJlbWVudHMuDQoNCkJlY2F1c2UgdGhlIHJldHVybiB2YWx1ZSBo ZXJlIGlzIHZlcnkgbXVjaCBsaWtlIHdoYXQgeW91IGFyZSBwcm9wb3NpbmcsIEkgd2FzIGV4cGxv cmluZyB3aGV0aGVyIHdlIHNob3VsZCBqdXN0IGFkZCBhIExpc3REYXRhYmFzZSBtZXRob2QgdG8g dGhlIFBBV1MgcHJvdG9jb2wgc3VjaCB0aGF0IHRoZSBkZXZpY2UganVzdCBuZWVkcyB0byB1bmRl cnN0YW5kIG9uZSBwcm90b2NvbC4gVGhpcyB3b3VsZCBhbGxvdzoNCg0KIC0gQSBkYXRhYmFzZSB0 byBzZXJ2ZSBhcyBib3RoIGxpc3RpbmcgZnVuY3Rpb25hbGl0eSAoaWYgaXQgd2FudHMpIGFzIHdl bGwgYXMgdGhlIHNwZWN0cnVtLWF2YWlsYWJpbGl0eSBmdW5jdGlvbmFsaXR5DQogLSBBIHNlcnZl ciBjYW4gY2hvb3NlIHRvIGltcGxlbWVudCBvbmx5IHRoZSBMaXN0RGF0YWJhc2UgZnVuY3Rpb25h bGl0eQ0KDQpJbiB0aGUgc2Vjb25kIGNhc2UsIGl0IHdvdWxkIGJlIGVxdWl2YWxlbnQgdG8geW91 ciBwcm9wb3NhbCwganVzdCB0aGF0IHRoZSBwcm90b2NvbCBtZXNzYWdlcyB3b3VsZCBiZSBpbiB0 aGUgc2FtZSBKU09OUlBDIGZvcm1hdCBhcyB0aGUgUEFXUyBwcm90b2NvbCwgcmF0aGVyIHRoYW4g dGhlIExvU1QgWE1MIGZvcm1hdC4NCg0KKElmIHdlIHdlcmUgdG8gYWRkIHRoZSBtZXRob2QsIEkg dGhpbmsgd2Ugc2hvdWxkIHJlbW92ZSB0aGUgbGlzdGluZyBmcm9tIE9VVFNJREVfQ09WRVJBR0Ug ZXJyb3IpLg0KDQoNCiAgICAgICAgIElmIGEgbWFzdGVyIG1vdmVzIGZyb20gVVNBIHRvIFVLLCBj YW4gdGhlIGRhdGFiYXNlIHRoYXQgdGhlIG1hc3RlciBvcmlnaW5hbGx5IGNvbm5lY3RlZCByZXR1 cm4gYXZhaWxhYmxlIGRhdGFiYXNlIGluIFVLIHRvIG1hc3Rlcj8NCg0KVGhhdCBzaG91bGQgYmUg YWxsb3dlZC4NCg0KDQogICAgICAgICBBbm90aGVyIHF1ZXN0aW9uIGlzLCBpZiBhIERhdGFiYXNl IExpc3Rpbmcgc2VydmVyIGlzIHVzZWQsIHdoYXQgaW50ZXJmYWNlIHdpbGwgYmUgZGVwbG95ZWQg YmV0d2VlbiBtYXN0ZXIgYW5kIERhdGFiYXNlIExpc3Rpbmcgc2VydmVyLCBpcyB0aGVyZSBhbiBl eGlzdGluZyBvbmUsIG9yIGEgbmV3IG9uZSBzaG91bGQgYmUgZGV2aXNlZD8NCg0KSXQgc2hvdWxk IGJlIHRoZSBzYW1lIG9uZS4gVGhpcyBzaW1wbGlmaWVzIHRoZSBkZXZpY2UgaW1wbGVtZW50YXRp b24uDQoNCg0KICAgICAgICAgRmluYWxseSwgd2hlbiBIVFRQIHJlZGlyZWN0IGlzIHByb3ZpZGVk IGluIHRoZSBwcm90b2NvbCwgY2FuIHlvdSBleHBsYWluIGl0IHRvIG1lIHdoZW4gobBEYlVwZGF0 ZVNwZWOhsSBiZSB1c2VkIGFuZCB3aGVuIEhUVFAgcmVkaXJlY3Qgd2lsbCBiZSB1c2VkLCBpZiBk YXRhYmFzZSB3YW50cyB0byBwcm92aWRlIGFuIGFsdGVybmF0ZSBkYXRlYmFzZT8NCg0KR3JlYXQg cXVlc3Rpb24uIFRoZXJlIHdhcyBzb21lIHRob3VnaHQgdGhhdCBIVFRQIHJlZGlyZWN0IGNhbiBv bmx5IHJldHVybiBhIHNpbmdsZSBVUkwgd2l0aG91dCBhZGRpdGlvbmFsICJhdHRyaWJ1dGVzIiwg c28gaXMgbGVzcyBmbGV4aWJsZSBpbiBjYXNlIHdlIHdhbnRlZCB0byBjb252ZXkgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCB0aGUgY2hhbmdlLiBPbiB0aGUgb3RoZXIgaGFuZCwgRGJVcGRhdGVTcGVj IGRvZXMgYWRkIGEgYml0IG1vcmUgY29tcGxleGl0eS4NCg0KSSB0aGluayB0aGVyZSB3YXMgYWxz byBzb21lIGNvbmNlcm4gdGhhdCBIVFRQIHJlZGlyZWN0IGlzIGF0IHRoZSBvdXRlciBsYXllciwg c28gZG9lcyBub3QgcGFzcyB0aHJvdWdoIGFueSBoYW5kLXNoYWtlIHRoYXQgbWlnaHQgaGF2ZSBi ZWVuIHJlcXVpcmVkIGJ5IGEgV1NEQiB2aWEgdGhlIElOSVRfUkVRIG1lY2hhbmlzbS4NCg0KU28u Li5kb2VzIHRoZSBzaW1wbGljaXR5IG9mIEhUVFAgcmVkaXJlY3Qgb3V0d2VpZ2ggdGhlIGJlbmVm aXRzPw0KDQotdmluY2UNCg0KDQogICAgICAgICBUaGFua3MhDQotWGlucGVuZw0KDQo= --_000_470F27D1263A1B4EB73491ED995DE625257BB564NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Thinks occ= ur to me, and provide the ideas before really get it.

 = ;

I supposed= that DB as service to discover should be an Internet service, but not sure= any more by looking at proposed text  in section 4.1.1 of paws protocol-05.

 = ;

Some detai= l implementations occur to me if I can seriously think over the proposal:

1.      IF= regulatory seems to maintain a location and DB list mapping in dominated a= rea? IF regulatory seems maintain the DB URL list of other regulatory domain(=A1=B0S=A1=B1)?

= I would still think proposal in s= ection 4.1.1 of paws-protocol-05 is about a very short term considerations, should be not exactly same proposal as that in Wei=A1=AFs = DB discovery protocol. So, the motivations and the scenarios have not been = cleared.

 = ;

2.      Th= e implementations of section 4.1.1 of paws-potocol-05 is not ready actually= , and even not discussed before. I am not able to image the interfaces and message as implementation issues, as they are all about= a protocol.

 = ;

3.      St= ill not ready to accept HTTP 302/301 method to reply more than one referrin= g destinations. I think this idea is not about complexity,  just wrong.

 = ;

Best regar= ds,

Zhu Lei

Huawei

Wireless network research d= epartment

E-mail address: lei.zhu@hua= wei.com

Phone: +86-10-60611961<= o:p>

Mobile: +86-13910157020=

 = ;

=B7=A2=BC=FE=C8=CB: Weixinp= eng
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA6=D4=C28=C8=D5 15:50
=CA=D5=BC=FE=C8=CB: Vincent Chen
=B3=AD=CB=CD: Mark Jones; paws@ietf.org; Peter McCann; Zhulei (A); Malyar, John P
=D6=F7=CC=E2: RE: [paws] draft-wei-paws-database-discovery-01<= /p>

 

Hi Vince, = All

 &nbs= p;       I think the business relationships b= etween master device vendor, regulatory body and database operator is very = important to decide how to deploy database discovery mechanism further,

so maybe w= e should have a discuss about it and have a more clear description of these= relationships, can anyone provide some information about this? Thanks!

 = ;

 = ;

-Xinpeng

 = ;

 = ;

 = ;

 = ;

From: Vincent Chen [mailto:vchen@google.com]
Sent: Thursday, June 06, 2013 4:08 PM
To: Weixinpeng
Cc: Mark Jones; paws@ietf.org; Peter McCann; Zhulei (A)
Subject: Re: [paws] draft-wei-paws-database-discovery-01<= /span>

 

Xinpeng,

 

 

On Wed, Jun 5, 2013 at 8:30 PM,= Weixinpeng <= weixinpeng@huawei.com> wrote:

Hi Vince, ,

    =      I am not quite clear about how OUTSIDE_COVERAGE wo= rks, if the database is in charge of returning a list of alternate database with OUTSIDE_COVERAGE err= or, does it means the database has to

maintain some informatio= n, such as coverage area, of other databases? And how it works when databases are managed by different companies?

 

This alternate list is optional= , so it's up to the database, business arrangements, and, possibly, regulat= ory requirements.

 

Because the return value here i= s very much like what you are proposing, I was exploring whether we should = just add a ListDatabase method to the PAWS protocol such that the device ju= st needs to understand one protocol. This would allow:

 

 - A database to serve as = both listing functionality (if it wants) as well as the spectrum-availabili= ty functionality

 - A server can choose to = implement only the ListDatabase functionality

 

In the second case, it would be= equivalent to your proposal, just that the protocol messages would be in t= he same JSONRPC format as the PAWS protocol, rather than the LoST XML forma= t.

 

(If we were to add the method, = I think we should remove the listing from OUTSIDE_COVERAGE error).

 

 

    =      If a master moves from USA to UK, can the database= that the master originally connected return available database in UK to master?

 

That should be allowed.

 

 

    =      Another question is, if a Database Listing server = is used, what interface will be deployed between master and Database Listing server, is there an existi= ng one, or a new one should be devised?

 

It should be the same one. This= simplifies the device implementation.

 

    =     

    =      Finally, when HTTP redirect is provided in the pro= tocol, can you explain it to me when =A1=B0DbUpdateSpec=A1=B1 be used and when HTTP redirect will be= used, if database wants to provide an alternate datebase?

 

Great question. There was some = thought that HTTP redirect can only return a single URL without additional = "attributes", so is less flexible in case we wanted to convey mor= e information about the change. On the other hand, DbUpdateSpec does add a bit more complexity.

 

I think there was also some con= cern that HTTP redirect is at the outer layer, so does not pass through any= hand-shake that might have been required by a WSDB via the INIT_REQ mechan= ism.

 

So...does the simplicity of HTT= P redirect outweigh the benefits?

 

-vince

 

    =     

    =      Thanks!

-Xinpeng

 

--_000_470F27D1263A1B4EB73491ED995DE625257BB564NKGEML512MBSchi_-- From vchen@google.com Tue Jun 11 09:40: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 201F021F93E0 for ; Tue, 11 Jun 2013 09:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.357 X-Spam-Level: X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9Mu4oLdan-P for ; Tue, 11 Jun 2013 09:40:20 -0700 (PDT) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5C81321F93DA for ; Tue, 11 Jun 2013 09:40:20 -0700 (PDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so2746559iec.22 for ; Tue, 11 Jun 2013 09:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BGGiqNtrI5QsncJ113Vra8skR/p+dzp9iZAlAlrCtkg=; b=US/jSecv/W1n7MwoW4vBHL6+aS9/TgUo/unys78fcBU4frz6aLAu75Cm6pNLsQKMH0 ccFK4tcq6RFYRxamm++kbGNpjhmZiEjSQHzmTID2/bsO349bBp1EaTzd+d6VZm41zUmE 8j3vaLNcjmbPenpCvR8Zc9PCwRmZgBceVt5V5eKdGl5Yd2aesbGyotxBP2Fgltz8HJHU CDAhO8sBEwoFbMqmkhKon6dy569oTDFbwgaBDHis1M7YJv7upErtIAAUbO2pWdLEMph/ 3Tr9YmTGcQmKNgS0onbemv2qfCfkWNYpUfgmWYvulcmcqWcSDNrYkVe+5U0eIbSt8GLz Xj4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BGGiqNtrI5QsncJ113Vra8skR/p+dzp9iZAlAlrCtkg=; b=XcQIbRI4E6T8shHE4GtJYutjGLZzcKGVD9V7C56ZKbfu+vmGs5cMC3U9kHa8kVpQC3 XR4gfUOQAB7H6IBEMKN/T/X2Sa2ETff2hcN//dxQl3niR2BE1tu3TG+OWJnZ6HXW1DZh Qog4Sji3qvbcIjKCGEkP7SooluYyP5tmGg/3z22zY0C2Ui2OcE2sCxqL+iH3qzpWId8b HkheUq+ZcnyZ2c6NUl4ZIouZJyQ7IMjuRXCSdBXtQOdW0rjAK/xAvq6/cc600tJs/2aj oCk29LQrKFv8HK4IEWSTvvswyI5ms11JKihq1d88e91H9Debb2uV0c7PoJam/A3IgTLT 9vgQ== MIME-Version: 1.0 X-Received: by 10.50.97.74 with SMTP id dy10mr1377609igb.3.1370968819663; Tue, 11 Jun 2013 09:40:19 -0700 (PDT) Received: by 10.64.42.37 with HTTP; Tue, 11 Jun 2013 09:40:19 -0700 (PDT) In-Reply-To: <470F27D1263A1B4EB73491ED995DE625257BB564@NKGEML512-MBS.china.huawei.com> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <470F27D1263A1B4EB73491ED995DE625257BB564@NKGEML512-MBS.china.huawei.com> Date: Tue, 11 Jun 2013 09:40:19 -0700 Message-ID: From: Vincent Chen To: "Zhulei (A)" Content-Type: multipart/alternative; boundary=047d7b10d01d7eecd204dee38de9 X-Gm-Message-State: ALoCoQkk+1ps6Ek4XMrh42iR00XQMqHH0PdS3eb13rcqnFtmLsWs9eyCZfUA5XRQcKEYkt2HDl7N6ozxU/T0AVlPJwJww89M6cFygVbw/zCOn8dRPVtDKooL+PHIo+XZx+s3zNI3KXiICqnrIgTx74VEviQ5g4mqPQ7mHi/C9DOBvPIxcXQ86CLWd/K6mlSgYPYyrejPOdRv Cc: "paws@ietf.org" , "Malyar, John P" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 11 Jun 2013 16:40:21 -0000 --047d7b10d01d7eecd204dee38de9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Zhu Lei, On Sat, Jun 8, 2013 at 6:37 PM, Zhulei (A) wrote: > Hi,**** > > ** ** > > Thinks occur to me, and provide the ideas before really get it.**** > > ** ** > > I supposed that DB as service to discover should be an Internet service, > but not sure any more by looking at proposed text in section 4.1.1 of pa= ws > protocol-05. **** > > ** ** > > Some detail implementations occur to me if I can seriously think over the > proposal:**** > > **1. **IF regulatory seems to maintain a location and DB list > mapping in dominated area? IF regulatory seems maintain the DB URL list o= f > other regulatory domain(=93S=94)? **** > > I would still think proposal in section 4.1.1 of paws-protocol-05 is abou= t > a very short term considerations, should be not exactly same proposal as > that in Wei=92s DB discovery protocol. So, the motivations and the scenar= ios > have not been cleared.**** > > ** > - The Listing Server, as described in 4.1.1, may not be universal: - It will not be in every regulatory domain - There is no requirement that a Listing Server for one regulator does about other regulatory domains - A Device MAY treat the list as validation that the DB it uses is on the list, rather than for discovery Thus, I agree that it does not serve the same purpose as a DB Discovery protocol. > ** > > **2. **The implementations of section 4.1.1 of paws-potocol-05 is > not ready actually, and even not discussed before. I am not able to image > the interfaces and message as implementation issues, as they are all abou= t > a protocol. > - Section 4.1.1 was proposed in version 04 to address the Ofcom/ETSI requirements that was discussed on the list after the F2F. You are correct that the message between a Device and Listing Server is listed as out of scope. Are you suggesting that it should be in scope? > **3. **Still not ready to accept HTTP 302/301 method to reply more > than one referring destinations. I think this idea is not about complexit= y, > just wrong. > Agreed. The question is really between the two choices: a) Use HTTP 302/301 to redirect to a single destination, or b) Use DbUpdateSpec message to list more than one alternatives b) is more flexible, but potentially more complex. ------------------------ Bottom line: Is there a compelling use case where a Discovery Service is NOT preconfigured that: - Is "trustworthy" to all regulators, databases, and devices? - Is easily deployable? If not, do we need LoST? or just a protocol to encode the request and response? -vince --047d7b10d01d7eecd204dee38de9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Zhu Lei,


On Sat, Jun 8, 2013 at 6:37 PM, Zhulei (A= ) <lei.zhu@huawei.com> wrote:

Hi,

=A0

Thinks occur to me, and provide the ideas befor= e really get it.

=A0

I supposed that DB as service to discover shoul= d be an Internet service, but not sure any more by looking at proposed text= =A0in section 4.1.1 of paws protocol-05.

=A0

Some detail implementations occur to me if I ca= n seriously think over the proposal:

1.=A0=A0=A0=A0=A0 IF regulatory seems to= maintain a location and DB list mapping in dominated area? IF regulatory s= eems maintain the DB URL list of other regulatory domain(=93S=94)?

I wo= uld still think proposal in section 4.1.1 of paws-protocol-05 is about a ve= ry short term considerations, should be not exactly same proposal as that in Wei=92s DB = discovery protocol. So, the motivations and the scenarios have not been cle= ared.

=A0

<= div>- The Listing Server, as described in 4.1.1, may not be universal:
=A0 - It will not be in every regulatory domain
=A0 - There = is no requirement that a Listing Server for one regulator does about other = regulatory domains
=A0 - A Device MAY treat the list as validatio= n that the DB it uses is on the list, rather than for discovery

Thus, I agree that it does not serve the same purpose a= s a DB Discovery protocol.
=A0

2.=A0=A0=A0=A0=A0 The implementations of= section 4.1.1 of paws-potocol-05 is not ready actually, and even not discu= ssed before. I am not able to image the interfaces and message as implementation issues, as they are all about= a protocol.

- Section 4.1.1 was pr= oposed in version 04 to address the Ofcom/ETSI requirements that was discus= sed
=A0 on the list after the F2F.

=A0 You are co= rrect that the message between a Device and Listing Server is listed as out= of scope.
=A0 Are you suggesting that it should be in scope?
=A0

3.=A0=A0=A0=A0=A0 Still not ready to acc= ept HTTP 302/301 method to reply more than one referring destinations. I th= ink this idea is not about complexity, =A0just wrong.

Agreed. The question is r= eally between the two choices:

=A0 a) Use HTTP 302= /301 to redirect to a single destination, or
=A0 b) Use DbUpdateSpec message to list more than one alternatives=A0<= /div>

b) is more flexible, but potentially more complex.=

------------------------
Bo= ttom line:

Is there a compelling use case where a Disc= overy Service is NOT preconfigured that:
=A0- Is "trus= tworthy" to all regulators, databases, and devices?
=A0- Is easily deployable?

If not, do = we need LoST? or just a protocol to encode the request and response?
<= div style>
-vince
--047d7b10d01d7eecd204dee38de9-- From Peter.McCann@huawei.com Wed Jun 12 10:40:57 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 C79B721F99AE for ; Wed, 12 Jun 2013 10:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw2ZYSrrO6bF for ; Wed, 12 Jun 2013 10:40:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 43A6611E80F3 for ; Wed, 12 Jun 2013 10:40:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASI93797; Wed, 12 Jun 2013 17:40:49 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 12 Jun 2013 18:40:35 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 12 Jun 2013 18:40:47 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 12 Jun 2013 10:40:41 -0700 From: Peter McCann To: "Rosen, Brian" , Vincent Chen Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGwRClWJA Date: Wed, 12 Jun 2013 17:40:41 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F49F64@dfweml512-mbx.china.huawei.com> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> In-Reply-To: <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jun 2013 17:40:57 -0000 Maybe the ITU-R should run a "root" discovery service, pointing at national servers and mapping geographic coordinates to nation states. Each national server can list all the databases approved for use within=20 that nation. The WSD can then pick one based on its business relationships= . -Pete Rosen, Brian wrote: > No, but we are discussing multiple URLs for the SAME=20 > db, not multiple dbs. >=20 > Multiple DBs arise because regulators want competitive options. The=20 > list manager can list all the approved DBs, but a given WSDB isn't=20 > likely to be able to use all of them, or even most of them. >=20 > I have to bring up business models in an IETF list, but it seems we=20 > may need to at least understand what has been thought about with=20 > multiple competing dbs. >=20 > The models I've heard about are: > 1. The manufacturer contracts with a db, or a db per region to serve=20 > the devices it manufacturers. This is usually a lifetime of the=20 > device arrangement. Some provision has to be made to allow the owner=20 > to use a different DB, and some provision has to be made to allow a=20 > new db to take over a defunct (for whatever reason) db URL. >=20 > 2. A service provider providing a service over WS, the usual example=20 > is an ISP, contracts for the db service for all the devices it=20 > provides its service to. This is annoying to provision unless the=20 > device comes from the SP as part of the service or a truck roll is=20 > needed. Some provision has to be made to change SPs. Sometimes the=20 > SP IS the db operator. >=20 > 3. A db decides it will offer its service for free. Any device can=20 > use it. >=20 > 4. The end user of the device contracts with the db for service. This=20 > usually requires provisioning by the device owner as part of the sign-=20 > up process. >=20 > 5. A notion of "roaming" or "pomading" is supported where your "home" > db has a relationship with a "visiting" db in another region who will=20 > supply service when the device is in the other region. >=20 > And of course there is the single db per region model where all=20 > devices in that region use a single db, with some cost sharing,=20 > regulatory fee or tax arrangement >=20 > For all of the multiple db per region cases, there ends up being one,=20 > or at most a small number of dbs, that a given device can use within=20 > that region. We could imagine discovery services that had some way of=20 > knowing, or themselves discovering and caching which of several dbs a=20 > given device could use. Not sure that makes a whole lot of sense. > But it makes virtually no sense to just discover the list of possible=20 > services and then try them to see which one likes you. >=20 > The notion of caching to avoid asking has some merit. You could cache=20 > the db URL you successfully used last, try it, get an error if you are=20 > out of area (or a referral for case 5) and then, if you do get an=20 > error, use the discovery mechanism to at least find out what region=20 > you are in. >=20 > I don't think that we should be standardizing queries between devices > and dbs that won't serve them. A device should not routinely ask a db > for service when there is no prior arrangement for service. >=20 > Brian >=20 > On Jun 5, 2013, at 2:14 PM, Vincent Chen wrote: >=20 >=20 > Brian, >=20 >=20 >=20 > First of all, reliability, geographic diversity, capacity, etc are=20 > usually done with common URLs. Witness www.google.com=20 > >=20 >=20 > Your example makes sense in this case, because www.google.com=20 > is a single corporate entity and it manages=20 > its own reliability, diversity, etc. >=20 > In contrast, WSDBs are offered by different entities (sometimes=20 > competing). The equivalence you are asking for would > be http://www.wsdb.com and be automatically=20 > routed to different implementations. I don't think that's what we had=20 > in mind. >=20 > -vince > From brian.rosen@neustar.biz Wed Jun 12 10:48: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 F2BAF11E8105 for ; Wed, 12 Jun 2013 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQgYMaNceWG4 for ; Wed, 12 Jun 2013 10:48:22 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id C4EE611E8104 for ; Wed, 12 Jun 2013 10:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371059786; x=1686416883; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=/WRosdm4zu 6kCmLDTFFmfpc8nLjhLrNmhCZVV+61Jr0=; b=S63povY0mB+hQCmYqdFD837QDT JH6BWAi0hDGtdFlij1zrr2F/ebhXkqGZuDGdKjk3FnaKIGT6EH5lFaDsevuw== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.26180051; Wed, 12 Jun 2013 13:56:25 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 12 Jun 2013 13:48:13 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Wed, 12 Jun 2013 13:48:10 -0400 From: "Rosen, Brian" To: Peter McCann Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGw== Date: Wed, 12 Jun 2013 17:48:10 +0000 Message-ID: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F64@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F49F64@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 90PwKWgs5W7tiZjphlCwbQ== Content-Type: text/plain; charset="us-ascii" Content-ID: <3AAE6732884B70428D604C584E6F1CC4@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jun 2013 17:48:26 -0000 We have history with ideas like that. Try to follow the history of ENUM. = It failed, miserably. =20 Brian On Jun 12, 2013, at 1:40 PM, Peter McCann wrote: > Maybe the ITU-R should run a "root" discovery service, pointing at > national servers and mapping geographic coordinates to nation states. > Each national server can list all the databases approved for use within=20 > that nation. The WSD can then pick one based on its business relationshi= ps. >=20 > -Pete >=20 >=20 > Rosen, Brian wrote: >> No, but we are discussing multiple URLs for the SAME=20 >> db, not multiple dbs. >>=20 >> Multiple DBs arise because regulators want competitive options. The=20 >> list manager can list all the approved DBs, but a given WSDB isn't=20 >> likely to be able to use all of them, or even most of them. >>=20 >> I have to bring up business models in an IETF list, but it seems we=20 >> may need to at least understand what has been thought about with=20 >> multiple competing dbs. >>=20 >> The models I've heard about are: >> 1. The manufacturer contracts with a db, or a db per region to serve=20 >> the devices it manufacturers. This is usually a lifetime of the=20 >> device arrangement. Some provision has to be made to allow the owner=20 >> to use a different DB, and some provision has to be made to allow a=20 >> new db to take over a defunct (for whatever reason) db URL. >>=20 >> 2. A service provider providing a service over WS, the usual example=20 >> is an ISP, contracts for the db service for all the devices it=20 >> provides its service to. This is annoying to provision unless the=20 >> device comes from the SP as part of the service or a truck roll is=20 >> needed. Some provision has to be made to change SPs. Sometimes the=20 >> SP IS the db operator. >>=20 >> 3. A db decides it will offer its service for free. Any device can=20 >> use it. >>=20 >> 4. The end user of the device contracts with the db for service. This=20 >> usually requires provisioning by the device owner as part of the sign-=20 >> up process. >>=20 >> 5. A notion of "roaming" or "pomading" is supported where your "home" >> db has a relationship with a "visiting" db in another region who will=20 >> supply service when the device is in the other region. >>=20 >> And of course there is the single db per region model where all=20 >> devices in that region use a single db, with some cost sharing,=20 >> regulatory fee or tax arrangement >>=20 >> For all of the multiple db per region cases, there ends up being one,=20 >> or at most a small number of dbs, that a given device can use within=20 >> that region. We could imagine discovery services that had some way of=20 >> knowing, or themselves discovering and caching which of several dbs a=20 >> given device could use. Not sure that makes a whole lot of sense. >> But it makes virtually no sense to just discover the list of possible=20 >> services and then try them to see which one likes you. >>=20 >> The notion of caching to avoid asking has some merit. You could cache=20 >> the db URL you successfully used last, try it, get an error if you are=20 >> out of area (or a referral for case 5) and then, if you do get an=20 >> error, use the discovery mechanism to at least find out what region=20 >> you are in. >>=20 >> I don't think that we should be standardizing queries between devices >> and dbs that won't serve them. A device should not routinely ask a db >> for service when there is no prior arrangement for service. >>=20 >> Brian >>=20 >> On Jun 5, 2013, at 2:14 PM, Vincent Chen wrote: >>=20 >>=20 >> Brian, >>=20 >>=20 >>=20 >> First of all, reliability, geographic diversity, capacity, etc are=20 >> usually done with common URLs. Witness www.google.com=20 >> >>=20 >>=20 >> Your example makes sense in this case, because www.google.com=20 >> is a single corporate entity and it manages=20 >> its own reliability, diversity, etc. >>=20 >> In contrast, WSDBs are offered by different entities (sometimes=20 >> competing). The equivalence you are asking for would >> be http://www.wsdb.com and be automatically=20 >> routed to different implementations. I don't think that's what we had=20 >> in mind. >>=20 >> -vince >>=20 >=20 >=20 >=20 From Peter.McCann@huawei.com Wed Jun 12 10:51:29 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 B2F9011E8105 for ; Wed, 12 Jun 2013 10:51:29 -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 YYunpiUIOzCo for ; Wed, 12 Jun 2013 10:51:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 779CF11E810A for ; Wed, 12 Jun 2013 10:51:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATU96698; Wed, 12 Jun 2013 17:51:08 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 12 Jun 2013 18:50:56 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 12 Jun 2013 18:51:08 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Wed, 12 Jun 2013 10:51:02 -0700 From: Peter McCann To: "Rosen, Brian" Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGwRClWJAAA8LBAAADqW+4A== Date: Wed, 12 Jun 2013 17:51:02 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F49F80@dfweml512-mbx.china.huawei.com> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F64@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jun 2013 17:51:29 -0000 Understood. But, I can't think of anyone else in a better position to resolve=20 territorial disputes. Even if they don't run the service themselves, it seems like they're the best ones to publish the national polygons and the list of pointers to national authorities. -Pete Rosen, Brian wrote: > We have history with ideas like that. Try to follow the history of > ENUM. It failed, miserably. >=20 > Brian >=20 > On Jun 12, 2013, at 1:40 PM, Peter McCann > wrote: >=20 >> Maybe the ITU-R should run a "root" discovery service, pointing at >> national servers and mapping geographic coordinates to nation states. >> Each national server can list all the databases approved for use within >> that nation. The WSD can then pick one based on its business >> relationships. >>=20 >> -Pete >>=20 >>=20 >> Rosen, Brian wrote: >>> No, but we are discussing multiple URLs for the >>> SAME db, not multiple dbs. >>>=20 >>> Multiple DBs arise because regulators want competitive options. >>> The list manager can list all the approved DBs, but a given WSDB >>> isn't likely to be able to use all of them, or even most of them. >>>=20 >>> I have to bring up business models in an IETF list, but it seems we >>> may need to at least understand what has been thought about with >>> multiple competing dbs. >>>=20 >>> The models I've heard about are: 1. The manufacturer contracts with a >>> db, or a db per region to serve the devices it manufacturers. This is >>> usually a lifetime of the device arrangement. Some provision has to >>> be made to allow the owner to use a different DB, and some provision >>> has to be made to allow a new db to take over a defunct (for whatever >>> reason) db URL. >>>=20 >>> 2. A service provider providing a service over WS, the usual >>> example is an ISP, contracts for the db service for all the devices >>> it provides its service to. This is annoying to provision unless >>> the device comes from the SP as part of the service or a truck roll >>> is needed. Some provision has to be made to change SPs. Sometimes >>> the SP IS the db operator. >>>=20 >>> 3. A db decides it will offer its service for free. Any device can >>> use it. >>>=20 >>> 4. The end user of the device contracts with the db for service. This >>> usually requires provisioning by the device owner as part of the sign- >>> up process. >>>=20 >>> 5. A notion of "roaming" or "pomading" is supported where your "home" >>> db has a relationship with a "visiting" db in another region who will >>> supply service when the device is in the other region. >>>=20 >>> And of course there is the single db per region model where all >>> devices in that region use a single db, with some cost sharing, >>> regulatory fee or tax arrangement >>>=20 >>> For all of the multiple db per region cases, there ends up being one, >>> or at most a small number of dbs, that a given device can use within >>> that region. We could imagine discovery services that had some way of >>> knowing, or themselves discovering and caching which of several dbs a >>> given device could use. Not sure that makes a whole lot of sense. But >>> it makes virtually no sense to just discover the list of possible >>> services and then try them to see which one likes you. >>>=20 >>> The notion of caching to avoid asking has some merit. You could >>> cache the db URL you successfully used last, try it, get an error >>> if you are out of area (or a referral for case 5) and then, if you >>> do get an error, use the discovery mechanism to at least find out >>> what region you are in. >>>=20 >>> I don't think that we should be standardizing queries between devices >>> and dbs that won't serve them. A device should not routinely ask a >>> db for service when there is no prior arrangement for service. >>>=20 >>> Brian >>>=20 >>> On Jun 5, 2013, at 2:14 PM, Vincent Chen wrote: >>>=20 >>>=20 >>> Brian, >>>=20 >>>=20 >>>=20 >>> First of all, reliability, geographic diversity, capacity, etc are >>> usually done with common URLs. Witness www.google.com >>> >>>=20 >>>=20 >>> Your example makes sense in this case, because www.google.com >>> is a single corporate entity and it manages >>> its own reliability, diversity, etc. >>>=20 >>> In contrast, WSDBs are offered by different entities (sometimes >>> competing). The equivalence you are asking for would be >>> http://www.wsdb.com and be automatically >>> routed to different implementations. I don't think that's what we had >>> in mind. >>>=20 >>> -vince >>>=20 >>=20 >>=20 >> From brian.rosen@neustar.biz Wed Jun 12 11:00:48 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 0E2C111E80BA for ; Wed, 12 Jun 2013 11:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.119, 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 tDQektBg93YE for ; Wed, 12 Jun 2013 11:00:38 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC3C21F99E2 for ; Wed, 12 Jun 2013 11:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371059963; x=1685861982; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type:Content-ID:Content-Transfer-Encoding; bh=Th5vBaaR8H swKi33wFwB9c2cNFTmoraEyZJ1Pa79t80=; b=V9lByRboEMN/vaZ8BDKOQ8vZGI h1OTW3W3Qf6SPrPhJbNGbmZBiF74d8To+thKZGZUN18EHK3dxdY+eE9PdoIw== Received: from ([10.31.58.70]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.20884089; Wed, 12 Jun 2013 13:59:22 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 14:00:10 -0400 From: "Rosen, Brian" To: Peter McCann Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGw== Date: Wed, 12 Jun 2013 18:00:10 +0000 Message-ID: References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F64@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F80@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F49F80@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: gB3VjiYTL+SmVHhkLo2Alw== Content-Type: text/plain; charset="us-ascii" Content-ID: <6859B8EF53945E4E94A2543BB26E332B@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jun 2013 18:00:48 -0000 The LoST forest guide idea does that without anywhere near as much infrastr= ucture. Basically, it relies on cooperating national servers to provide appropriate= referral services. In fact the LoST forest guide does EXACTLY what we want - given a location = and a URN indicating what service you want, it provides a referral to the r= ight server in the right area for that service, based on a set of polygons. Brian On Jun 12, 2013, at 1:51 PM, Peter McCann wrote: > Understood. >=20 > But, I can't think of anyone else in a better position to resolve=20 > territorial disputes. Even if they don't run the service themselves, > it seems like they're the best ones to publish the national polygons > and the list of pointers to national authorities. >=20 > -Pete >=20 >=20 > Rosen, Brian wrote: >> We have history with ideas like that. Try to follow the history of >> ENUM. It failed, miserably. >>=20 >> Brian >>=20 >> On Jun 12, 2013, at 1:40 PM, Peter McCann >> wrote: >>=20 >>> Maybe the ITU-R should run a "root" discovery service, pointing at >>> national servers and mapping geographic coordinates to nation states. >>> Each national server can list all the databases approved for use within >>> that nation. The WSD can then pick one based on its business >>> relationships. >>>=20 >>> -Pete >>>=20 >>>=20 >>> Rosen, Brian wrote: >>>> No, but we are discussing multiple URLs for the >>>> SAME db, not multiple dbs. >>>>=20 >>>> Multiple DBs arise because regulators want competitive options. >>>> The list manager can list all the approved DBs, but a given WSDB >>>> isn't likely to be able to use all of them, or even most of them. >>>>=20 >>>> I have to bring up business models in an IETF list, but it seems we >>>> may need to at least understand what has been thought about with >>>> multiple competing dbs. >>>>=20 >>>> The models I've heard about are: 1. The manufacturer contracts with a >>>> db, or a db per region to serve the devices it manufacturers. This is >>>> usually a lifetime of the device arrangement. Some provision has to >>>> be made to allow the owner to use a different DB, and some provision >>>> has to be made to allow a new db to take over a defunct (for whatever >>>> reason) db URL. >>>>=20 >>>> 2. A service provider providing a service over WS, the usual >>>> example is an ISP, contracts for the db service for all the devices >>>> it provides its service to. This is annoying to provision unless >>>> the device comes from the SP as part of the service or a truck roll >>>> is needed. Some provision has to be made to change SPs. Sometimes >>>> the SP IS the db operator. >>>>=20 >>>> 3. A db decides it will offer its service for free. Any device can >>>> use it. >>>>=20 >>>> 4. The end user of the device contracts with the db for service. This >>>> usually requires provisioning by the device owner as part of the sign- >>>> up process. >>>>=20 >>>> 5. A notion of "roaming" or "pomading" is supported where your "home" >>>> db has a relationship with a "visiting" db in another region who will >>>> supply service when the device is in the other region. >>>>=20 >>>> And of course there is the single db per region model where all >>>> devices in that region use a single db, with some cost sharing, >>>> regulatory fee or tax arrangement >>>>=20 >>>> For all of the multiple db per region cases, there ends up being one, >>>> or at most a small number of dbs, that a given device can use within >>>> that region. We could imagine discovery services that had some way of >>>> knowing, or themselves discovering and caching which of several dbs a >>>> given device could use. Not sure that makes a whole lot of sense. But >>>> it makes virtually no sense to just discover the list of possible >>>> services and then try them to see which one likes you. >>>>=20 >>>> The notion of caching to avoid asking has some merit. You could >>>> cache the db URL you successfully used last, try it, get an error >>>> if you are out of area (or a referral for case 5) and then, if you >>>> do get an error, use the discovery mechanism to at least find out >>>> what region you are in. >>>>=20 >>>> I don't think that we should be standardizing queries between devices >>>> and dbs that won't serve them. A device should not routinely ask a >>>> db for service when there is no prior arrangement for service. >>>>=20 >>>> Brian >>>>=20 >>>> On Jun 5, 2013, at 2:14 PM, Vincent Chen wrote: >>>>=20 >>>>=20 >>>> Brian, >>>>=20 >>>>=20 >>>>=20 >>>> First of all, reliability, geographic diversity, capacity, etc are >>>> usually done with common URLs. Witness www.google.com >>>> >>>>=20 >>>>=20 >>>> Your example makes sense in this case, because www.google.com >>>> is a single corporate entity and it manages >>>> its own reliability, diversity, etc. >>>>=20 >>>> In contrast, WSDBs are offered by different entities (sometimes >>>> competing). The equivalence you are asking for would be >>>> http://www.wsdb.com and be automatically >>>> routed to different implementations. I don't think that's what we had >>>> in mind. >>>>=20 >>>> -vince >>>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 >=20 From Peter.McCann@huawei.com Wed Jun 12 11:34:18 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 8FFDD21F961F for ; Wed, 12 Jun 2013 11:34:18 -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 tE6bxrx2ho0k for ; Wed, 12 Jun 2013 11:34:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 92FAD11E80CC for ; Wed, 12 Jun 2013 11:34:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATU98545; Wed, 12 Jun 2013 18:34:11 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 12 Jun 2013 19:34:03 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 13 Jun 2013 02:34:09 +0800 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Wed, 12 Jun 2013 11:34:04 -0700 From: Peter McCann To: "Rosen, Brian" Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGwRClWJAAA8LBAAADqW+4P//jiwAgABw1WA= Date: Wed, 12 Jun 2013 18:34:04 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F49FAD@dfweml512-mbx.china.huawei.com> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F64@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F80@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jun 2013 18:34:18 -0000 Ok, I just read 5582. Seems ok to leave the decision of which forest guide to use up to each manufacturer. Will this be able to satisfy the Ofcom requirement=20 to consult their regulator-maintained list before connecting to the database? Should we consider that consultation part of the discovery process? -Pete Rosen, Brian wrote: > The LoST forest guide idea does that without anywhere near as much > infrastructure. >=20 > Basically, it relies on cooperating national servers to provide > appropriate referral services. >=20 > In fact the LoST forest guide does EXACTLY what we want - given a > location and a URN indicating what service you want, it provides a > referral to the right server in the right area for that service, based > on a set of polygons. >=20 > Brian On Jun 12, 2013, at 1:51 PM, Peter McCann > wrote: >=20 >> Understood. >>=20 >> But, I can't think of anyone else in a better position to resolve >> territorial disputes. Even if they don't run the service >> themselves, it seems like they're the best ones to publish the >> national polygons and the list of pointers to national authorities. >>=20 >> -Pete >>=20 >>=20 >> Rosen, Brian wrote: >>> We have history with ideas like that. Try to follow the history of >>> ENUM. It failed, miserably. >>>=20 >>> Brian >>>=20 >>> On Jun 12, 2013, at 1:40 PM, Peter McCann >>> wrote: >>>=20 >>>> Maybe the ITU-R should run a "root" discovery service, pointing at >>>> national servers and mapping geographic coordinates to nation states. >>>> Each national server can list all the databases approved for use >>>> within that nation. The WSD can then pick one based on its business >>>> relationships. >>>>=20 >>>> -Pete >>>>=20 >>>>=20 >>>> Rosen, Brian wrote: >>>>> No, but we are discussing multiple URLs for the >>>>> SAME db, not multiple dbs. >>>>>=20 >>>>> Multiple DBs arise because regulators want competitive options. >>>>> The list manager can list all the approved DBs, but a given WSDB >>>>> isn't likely to be able to use all of them, or even most of them. >>>>>=20 >>>>> I have to bring up business models in an IETF list, but it seems we >>>>> may need to at least understand what has been thought about with >>>>> multiple competing dbs. >>>>>=20 >>>>> The models I've heard about are: 1. The manufacturer contracts with >>>>> a db, or a db per region to serve the devices it manufacturers. This >>>>> is usually a lifetime of the device arrangement. Some provision has >>>>> to be made to allow the owner to use a different DB, and some >>>>> provision has to be made to allow a new db to take over a defunct >>>>> (for whatever reason) db URL. >>>>>=20 >>>>> 2. A service provider providing a service over WS, the usual example >>>>> is an ISP, contracts for the db service for all the devices it >>>>> provides its service to. This is annoying to provision unless the >>>>> device comes from the SP as part of the service or a truck roll is >>>>> needed. Some provision has to be made to change SPs. Sometimes the >>>>> SP IS the db operator. >>>>>=20 >>>>> 3. A db decides it will offer its service for free. Any device can >>>>> use it. >>>>>=20 >>>>> 4. The end user of the device contracts with the db for service. >>>>> This usually requires provisioning by the device owner as part of >>>>> the sign- up process. >>>>>=20 >>>>> 5. A notion of "roaming" or "pomading" is supported where your >>>>> "home" db has a relationship with a "visiting" db in another region >>>>> who will supply service when the device is in the other region. >>>>>=20 >>>>> And of course there is the single db per region model where all >>>>> devices in that region use a single db, with some cost sharing, >>>>> regulatory fee or tax arrangement >>>>>=20 >>>>> For all of the multiple db per region cases, there ends up being >>>>> one, or at most a small number of dbs, that a given device can use >>>>> within that region. We could imagine discovery services that had >>>>> some way of knowing, or themselves discovering and caching which of >>>>> several dbs a given device could use. Not sure that makes a whole >>>>> lot of sense. But it makes virtually no sense to just discover the >>>>> list of possible services and then try them to see which one likes >>>>> you. >>>>>=20 >>>>> The notion of caching to avoid asking has some merit. You could >>>>> cache the db URL you successfully used last, try it, get an error >>>>> if you are out of area (or a referral for case 5) and then, if >>>>> you do get an error, use the discovery mechanism to at least find >>>>> out what region you are in. >>>>>=20 >>>>> I don't think that we should be standardizing queries between >>>>> devices and dbs that won't serve them. A device should not >>>>> routinely ask a db for service when there is no prior arrangement >>>>> for service. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Jun 5, 2013, at 2:14 PM, Vincent Chen wrote: >>>>>=20 >>>>>=20 >>>>> Brian, >>>>>=20 >>>>>=20 >>>>>=20 >>>>> First of all, reliability, geographic diversity, capacity, etc are >>>>> usually done with common URLs. Witness www.google.com >>>>> >>>>>=20 >>>>>=20 >>>>> Your example makes sense in this case, because www.google.com >>>>> is a single corporate entity and it >>>>> manages its own reliability, diversity, etc. >>>>>=20 >>>>> In contrast, WSDBs are offered by different entities (sometimes >>>>> competing). The equivalence you are asking for would be >>>>> http://www.wsdb.com and be automatically >>>>> routed to different implementations. I don't think that's what we >>>>> had in mind. >>>>>=20 >>>>> -vince >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >> From vchen@google.com Wed Jun 12 12:16:45 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 8CDA121F9950 for ; Wed, 12 Jun 2013 12:16:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 30pLphN-pxdT for ; Wed, 12 Jun 2013 12:16:44 -0700 (PDT) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id BD82D21F9952 for ; Wed, 12 Jun 2013 12:16:42 -0700 (PDT) Received: by mail-ie0-f169.google.com with SMTP id 10so10483127ied.14 for ; Wed, 12 Jun 2013 12:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qpb6TNGtEEIZYXPsitFK1OMgshtmmaP04NcLNFAFXkU=; b=KzHj5J7WEG6z+auZzc4Bqrfmi57SGJvS53qRz79fM7OmLWaqJ4gyaVYJB9yc3MKWtg Jp7c5Lpr1ilHeXX18l9VajhtbrW4W2ydsVlq3aeTt2s9W2mbCGXx82Qx4nHYdR+3926P 6KRQx0du+LUeHM/2b4ndGSHTP1YbPmV950sxl/o//wuXEdmjBHUl83SmOxX+IuKZ08sv DyfMFlnQT5KxH3etWIXTAcgJskLVH+QG/JbYY7naSJSzFl/iNyjns6XLmZtNC+Rwt0yZ L9VjkZuWFJ7W36E6brxNXNTcYyLGV15u7dSWDFVbBg3xL0poxmvU5nszaA2jwCCQA2NI 6WGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Qpb6TNGtEEIZYXPsitFK1OMgshtmmaP04NcLNFAFXkU=; b=JU662CNZYXXCg0kkRdjVIUGpzMZJv/XmBF3efu28A5efOGcRDBCWr+fc1EznWM1HoB ZwGb96Nvaz3tShY2Ttj6gDoU58BsJFKTqOQwal9QSlLePHbtImPhkYjCrSYv3Po2hrZD d7bn08FLmfJwQ1e9iKvLLHO9ameWU3lRszrL7iTMSr2jVin8XgzkymiUR0gkJocczyYk ix7bNTKSEdmFSCGN2IGEcw2XPgi5O77TTqo6jdjRE+u3368IBRWdDrxtkGfQF4Pml5EI usFzeNs4CdhRZLKJj+oKMQSTWFzKl6h0YvuRMQ4LHU+e8AeEmqA5hiH7KrY3ff62z3qt 5YzQ== MIME-Version: 1.0 X-Received: by 10.50.118.37 with SMTP id kj5mr4132868igb.70.1371064602195; Wed, 12 Jun 2013 12:16:42 -0700 (PDT) Received: by 10.64.42.37 with HTTP; Wed, 12 Jun 2013 12:16:41 -0700 (PDT) In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F49FAD@dfweml512-mbx.china.huawei.com> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F64@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F80@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F49FAD@dfweml512-mbx.china.huawei.com> Date: Wed, 12 Jun 2013 12:16:41 -0700 Message-ID: From: Vincent Chen To: Peter McCann Content-Type: multipart/alternative; boundary=089e0115ec7494126d04def9dab6 X-Gm-Message-State: ALoCoQkCWHGBS97Brg9ET+pduT6OPNcxxT0gV3VV0gEMS7caLIDScb8/6YZa6Vl4Slc0lXrqn4WnRu41Lvv+VEsJmTgq8y2rK4Z7jiASoloO8Dk4E0Z0kLTXR9HL0gD0ao7D2HlJfbw0Sz9abqBa7jStDG13yyISQSensS+xBSJ2CGmMQguySISLV2YEVKahtBZPwXFpE7RV Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jun 2013 19:16:45 -0000 --089e0115ec7494126d04def9dab6 Content-Type: text/plain; charset=ISO-8859-1 How would a regulator sanction the "forest guide". Or, equivalently, when a device gets a LoST Server, can it trust it to give the list sanctioned by a regulator? That's the bootstrap step that I don't quite understand. -vince On Wed, Jun 12, 2013 at 11:34 AM, Peter McCann wrote: > Ok, I just read 5582. > > Seems ok to leave the decision of which forest guide to use up to > each manufacturer. Will this be able to satisfy the Ofcom requirement > to consult their regulator-maintained list before connecting to the > database? Should we consider that consultation part of the discovery > process? > > -Pete > > > > Rosen, Brian wrote: > > The LoST forest guide idea does that without anywhere near as much > > infrastructure. > > > > Basically, it relies on cooperating national servers to provide > > appropriate referral services. > > > > In fact the LoST forest guide does EXACTLY what we want - given a > > location and a URN indicating what service you want, it provides a > > referral to the right server in the right area for that service, based > > on a set of polygons. > > > > Brian On Jun 12, 2013, at 1:51 PM, Peter McCann > > wrote: > > > >> Understood. > >> > >> But, I can't think of anyone else in a better position to resolve > >> territorial disputes. Even if they don't run the service > >> themselves, it seems like they're the best ones to publish the > >> national polygons and the list of pointers to national authorities. > >> > >> -Pete > >> > >> > >> Rosen, Brian wrote: > >>> We have history with ideas like that. Try to follow the history of > >>> ENUM. It failed, miserably. > >>> > >>> Brian > >>> > >>> On Jun 12, 2013, at 1:40 PM, Peter McCann > >>> wrote: > >>> > >>>> Maybe the ITU-R should run a "root" discovery service, pointing at > >>>> national servers and mapping geographic coordinates to nation states. > >>>> Each national server can list all the databases approved for use > >>>> within that nation. The WSD can then pick one based on its business > >>>> relationships. > >>>> > >>>> -Pete > >>>> > >>>> > >>>> Rosen, Brian wrote: > >>>>> No, but we are discussing multiple URLs for the > >>>>> SAME db, not multiple dbs. > >>>>> > >>>>> Multiple DBs arise because regulators want competitive options. > >>>>> The list manager can list all the approved DBs, but a given WSDB > >>>>> isn't likely to be able to use all of them, or even most of them. > >>>>> > >>>>> I have to bring up business models in an IETF list, but it seems we > >>>>> may need to at least understand what has been thought about with > >>>>> multiple competing dbs. > >>>>> > >>>>> The models I've heard about are: 1. The manufacturer contracts with > >>>>> a db, or a db per region to serve the devices it manufacturers. This > >>>>> is usually a lifetime of the device arrangement. Some provision has > >>>>> to be made to allow the owner to use a different DB, and some > >>>>> provision has to be made to allow a new db to take over a defunct > >>>>> (for whatever reason) db URL. > >>>>> > >>>>> 2. A service provider providing a service over WS, the usual example > >>>>> is an ISP, contracts for the db service for all the devices it > >>>>> provides its service to. This is annoying to provision unless the > >>>>> device comes from the SP as part of the service or a truck roll is > >>>>> needed. Some provision has to be made to change SPs. Sometimes the > >>>>> SP IS the db operator. > >>>>> > >>>>> 3. A db decides it will offer its service for free. Any device can > >>>>> use it. > >>>>> > >>>>> 4. The end user of the device contracts with the db for service. > >>>>> This usually requires provisioning by the device owner as part of > >>>>> the sign- up process. > >>>>> > >>>>> 5. A notion of "roaming" or "pomading" is supported where your > >>>>> "home" db has a relationship with a "visiting" db in another region > >>>>> who will supply service when the device is in the other region. > >>>>> > >>>>> And of course there is the single db per region model where all > >>>>> devices in that region use a single db, with some cost sharing, > >>>>> regulatory fee or tax arrangement > >>>>> > >>>>> For all of the multiple db per region cases, there ends up being > >>>>> one, or at most a small number of dbs, that a given device can use > >>>>> within that region. We could imagine discovery services that had > >>>>> some way of knowing, or themselves discovering and caching which of > >>>>> several dbs a given device could use. Not sure that makes a whole > >>>>> lot of sense. But it makes virtually no sense to just discover the > >>>>> list of possible services and then try them to see which one likes > >>>>> you. > >>>>> > >>>>> The notion of caching to avoid asking has some merit. You could > >>>>> cache the db URL you successfully used last, try it, get an error > >>>>> if you are out of area (or a referral for case 5) and then, if > >>>>> you do get an error, use the discovery mechanism to at least find > >>>>> out what region you are in. > >>>>> > >>>>> I don't think that we should be standardizing queries between > >>>>> devices and dbs that won't serve them. A device should not > >>>>> routinely ask a db for service when there is no prior arrangement > >>>>> for service. > >>>>> > >>>>> Brian > >>>>> > >>>>> On Jun 5, 2013, at 2:14 PM, Vincent Chen wrote: > >>>>> > >>>>> > >>>>> Brian, > >>>>> > >>>>> > >>>>> > >>>>> First of all, reliability, geographic diversity, capacity, > etc are > >>>>> usually done with common URLs. Witness www.google.com > >>>>> > >>>>> > >>>>> > >>>>> Your example makes sense in this case, because www.google.com > >>>>> is a single corporate entity and it > >>>>> manages its own reliability, diversity, etc. > >>>>> > >>>>> In contrast, WSDBs are offered by different entities (sometimes > >>>>> competing). The equivalence you are asking for would be > >>>>> http://www.wsdb.com and be automatically > >>>>> routed to different implementations. I don't think that's what we > >>>>> had in mind. > >>>>> > >>>>> -vince > >>>>> > >>>> > >>>> > >>>> > >> > >> > >> > > > > -- -vince --089e0115ec7494126d04def9dab6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How would a regulator sanction the "forest guide"= ;.

Or, equivalently, when a device gets a LoST Server, c= an it trust it to give the list sanctioned by a regulator?
That's the bootstrap step that I don't quite understand.

-vince

On Wed, Jun 12, 2013 at 11:34 AM, Peter McC= ann <Peter.McCann@huawei.com> wrote:
Ok, I just read 5582.

Seems ok to leave the decision of which forest guide to use up to
each manufacturer. =A0Will this be able to satisfy the Ofcom requirement to consult their regulator-maintained list before connecting to the
database? =A0Should we consider that consultation part of the discovery
process?

-Pete



Rosen, Brian wrote:
> The LoST forest guide idea does that without anywhere near as much
> infrastructure.
>
> Basically, it relies on cooperating national servers to provide
> appropriate referral services.
>
> In fact the LoST forest guide does EXACTLY what we want - given a
> location and a URN indicating what service you want, it provides a
> referral to the right server in the right area for that service, based=
> on a set of polygons.
>
> Brian On Jun 12, 2013, at 1:51 PM, Peter McCann
> <Peter.McCann@huawei.com= > wrote:
>
>> Understood.
>>
>> But, I can't think of anyone else in a better position to reso= lve
>> territorial disputes. =A0Even if they don't run the service >> themselves, it seems like they're the best ones to publish the=
>> national polygons and the list of pointers to national authorities= .
>>
>> -Pete
>>
>>
>> Rosen, Brian wrote:
>>> We have history with ideas like that. =A0Try to follow the his= tory of
>>> ENUM. =A0It failed, miserably.
>>>
>>> Brian
>>>
>>> On Jun 12, 2013, at 1:40 PM, Peter McCann <Peter.McCann@huawei.com>
>>> wrote:
>>>
>>>> Maybe the ITU-R should run a "root" discovery se= rvice, pointing at
>>>> national servers and mapping geographic coordinates to nat= ion states.
>>>> Each national server can list all the databases approved f= or use
>>>> within that nation. =A0The WSD can then pick one based on = its business
>>>> relationships.
>>>>
>>>> -Pete
>>>>
>>>>
>>>> Rosen, Brian wrote:
>>>>> <as individual> No, but we are discussing multip= le URLs for the
>>>>> SAME db, not multiple dbs.
>>>>>
>>>>> Multiple DBs arise because regulators want competitive= options.
>>>>> The list manager can list all the approved DBs, but a = given WSDB
>>>>> isn't likely to be able to use all of them, or eve= n most of them.
>>>>>
>>>>> I have to bring up business models in an IETF list, bu= t it seems we
>>>>> may need to at least understand what has been thought = about with
>>>>> multiple competing dbs.
>>>>>
>>>>> The models I've heard about are: 1. The manufactur= er contracts with
>>>>> a db, or a db per region to serve the devices it manuf= acturers. This
>>>>> is usually a lifetime of the device arrangement. =A0So= me provision has
>>>>> to be made to allow the owner to use a different DB, a= nd some
>>>>> provision has to be made to allow a new db to take ove= r a defunct
>>>>> (for whatever reason) db URL.
>>>>>
>>>>> 2. A service provider providing a service over WS, the= usual example
>>>>> is an ISP, contracts for the db service for all the de= vices it
>>>>> provides its service to. =A0This is annoying to provis= ion unless the
>>>>> device comes from the SP as part of the service or a t= ruck roll is
>>>>> needed. =A0Some provision has to be made to change SPs= . Sometimes the
>>>>> SP IS the db operator.
>>>>>
>>>>> 3. A db decides it will offer its service for free. = =A0Any device can
>>>>> use it.
>>>>>
>>>>> 4. The end user of the device contracts with the db fo= r service.
>>>>> This usually requires provisioning by the device owner= as part of
>>>>> the sign- up process.
>>>>>
>>>>> 5. A notion of "roaming" or "pomading&q= uot; is supported where your
>>>>> "home" db has a relationship with a "vi= siting" db in another region
>>>>> who will supply service when the device is in the othe= r region.
>>>>>
>>>>> And of course there is the single db per region model = where all
>>>>> devices in that region use a single db, with some cost= sharing,
>>>>> regulatory fee or tax arrangement
>>>>>
>>>>> For all of the multiple db per region cases, there end= s up being
>>>>> one, or at most a small number of dbs, that a given de= vice can use
>>>>> within that region. =A0We could imagine discovery serv= ices that had
>>>>> some way of knowing, or themselves discovering and cac= hing which of
>>>>> several dbs a given device could use. =A0Not sure that= makes a whole
>>>>> lot of sense. But it makes virtually no sense to just = discover the
>>>>> list of possible services and then try them to see whi= ch one likes
>>>>> you.
>>>>>
>>>>> The notion of caching to avoid asking has some merit. = =A0You could
>>>>> cache the db URL you successfully used last, try it, g= et an error
>>>>> if you are out of area (or a referral for case 5) and = then, if
>>>>> you do get an error, use the discovery mechanism to at= least find
>>>>> out what region you are in.
>>>>>
>>>>> I don't think that we should be standardizing quer= ies between
>>>>> devices and dbs that won't serve them. =A0 A devic= e should not
>>>>> routinely ask a db for service when there is no prior = arrangement
>>>>> for service.
>>>>>
>>>>> Brian
>>>>>
>>>>> On Jun 5, 2013, at 2:14 PM, Vincent Chen <vchen@google.com> wrote:
>>>>>
>>>>>
>>>>> =A0 Brian,
>>>>>
>>>>>
>>>>>
>>>>> =A0 =A0 =A0 =A0 =A0 First of all, reliability, geograp= hic diversity, capacity, etc are
>>>>> usually done with common URLs. =A0Witness www.google.com
>>>>> <http://www.google.com/>
>>>>>
>>>>>
>>>>> =A0 Your example makes sense in this case, because www.google.com
>>>>> <http://www.google.com/> =A0is a single corporate entity and it >>>>> manages its own reliability, diversity, etc.
>>>>>
>>>>> =A0 In contrast, WSDBs are offered by different entiti= es (sometimes
>>>>> competing). The equivalence you are asking for would = =A0 =A0 =A0be
>>>>> http= ://www.wsdb.com <= http://www.wsdb.com/> =A0and be automatically
>>>>> routed to different implementations. I don't think= that's what we
>>>>> had in mind.
>>>>>
>>>>> =A0 -vince
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>






--
= -vince
--089e0115ec7494126d04def9dab6-- From brian.rosen@neustar.biz Wed Jun 12 12:22: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 DA19721E8051 for ; Wed, 12 Jun 2013 12:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Am21ryuioC9H for ; Wed, 12 Jun 2013 12:22:39 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1986C21F99C2 for ; Wed, 12 Jun 2013 12:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371065135; x=1686416367; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=LOIWqN6X5Guo9EtzY1V2DNR9TS3SKm9xPnH4o/XPQow=; b=OFVsYfKnJ9DRkMoMNJ5asoAWGvUdvDFqY1r1IzjZqfTj6XiKMk8UO1Dy0WupQP pXPuFbi/MqIqxYpVIOtYMguw== Received: from ([10.31.58.69]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25016082; Wed, 12 Jun 2013 15:25:34 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Wed, 12 Jun 2013 15:22:28 -0400 From: "Rosen, Brian" To: Vincent Chen Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGw== Date: Wed, 12 Jun 2013 19:22:27 +0000 Message-ID: <49E92720-872B-4761-BF70-A5E44B84A353@neustar.biz> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F64@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F80@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F49FAD@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: a5s7unTXPpGFgDfA4ZsStg== Content-Type: multipart/alternative; boundary="_000_49E92720872B4761BF70A5E44B84A353neustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jun 2013 19:22:44 -0000 --_000_49E92720872B4761BF70A5E44B84A353neustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The basic Forest Guide idea is there is no "sanction". There is only a coo= perating set of guides. Very typically, you don't query the Forest Guide itself. You query a serve= r who refers or iterates to the Forest Guide, which refers or iterates to t= he server that can help you. The idea is to not depend on government action, but to allow it if it's the= re. Anyone can set up a forest guide, but the servers that refer to it hav= e to trust it. This would be an example of transitive trust. If you trust the local serve= r, and it trusts the forest guide, then you can trust the forest guide. Brian On Jun 12, 2013, at 3:16 PM, Vincent Chen > wrote: How would a regulator sanction the "forest guide". Or, equivalently, when a device gets a LoST Server, can it trust it to give= the list sanctioned by a regulator? That's the bootstrap step that I don't quite understand. -vince On Wed, Jun 12, 2013 at 11:34 AM, Peter McCann > wrote: Ok, I just read 5582. Seems ok to leave the decision of which forest guide to use up to each manufacturer. Will this be able to satisfy the Ofcom requirement to consult their regulator-maintained list before connecting to the database? Should we consider that consultation part of the discovery process? -Pete Rosen, Brian wrote: > The LoST forest guide idea does that without anywhere near as much > infrastructure. > > Basically, it relies on cooperating national servers to provide > appropriate referral services. > > In fact the LoST forest guide does EXACTLY what we want - given a > location and a URN indicating what service you want, it provides a > referral to the right server in the right area for that service, based > on a set of polygons. > > Brian On Jun 12, 2013, at 1:51 PM, Peter McCann > > wrote: > >> Understood. >> >> But, I can't think of anyone else in a better position to resolve >> territorial disputes. Even if they don't run the service >> themselves, it seems like they're the best ones to publish the >> national polygons and the list of pointers to national authorities. >> >> -Pete >> >> >> Rosen, Brian wrote: >>> We have history with ideas like that. Try to follow the history of >>> ENUM. It failed, miserably. >>> >>> Brian >>> >>> On Jun 12, 2013, at 1:40 PM, Peter McCann > >>> wrote: >>> >>>> Maybe the ITU-R should run a "root" discovery service, pointing at >>>> national servers and mapping geographic coordinates to nation states. >>>> Each national server can list all the databases approved for use >>>> within that nation. The WSD can then pick one based on its business >>>> relationships. >>>> >>>> -Pete >>>> >>>> >>>> Rosen, Brian wrote: >>>>> No, but we are discussing multiple URLs for the >>>>> SAME db, not multiple dbs. >>>>> >>>>> Multiple DBs arise because regulators want competitive options. >>>>> The list manager can list all the approved DBs, but a given WSDB >>>>> isn't likely to be able to use all of them, or even most of them. >>>>> >>>>> I have to bring up business models in an IETF list, but it seems we >>>>> may need to at least understand what has been thought about with >>>>> multiple competing dbs. >>>>> >>>>> The models I've heard about are: 1. The manufacturer contracts with >>>>> a db, or a db per region to serve the devices it manufacturers. This >>>>> is usually a lifetime of the device arrangement. Some provision has >>>>> to be made to allow the owner to use a different DB, and some >>>>> provision has to be made to allow a new db to take over a defunct >>>>> (for whatever reason) db URL. >>>>> >>>>> 2. A service provider providing a service over WS, the usual example >>>>> is an ISP, contracts for the db service for all the devices it >>>>> provides its service to. This is annoying to provision unless the >>>>> device comes from the SP as part of the service or a truck roll is >>>>> needed. Some provision has to be made to change SPs. Sometimes the >>>>> SP IS the db operator. >>>>> >>>>> 3. A db decides it will offer its service for free. Any device can >>>>> use it. >>>>> >>>>> 4. The end user of the device contracts with the db for service. >>>>> This usually requires provisioning by the device owner as part of >>>>> the sign- up process. >>>>> >>>>> 5. A notion of "roaming" or "pomading" is supported where your >>>>> "home" db has a relationship with a "visiting" db in another region >>>>> who will supply service when the device is in the other region. >>>>> >>>>> And of course there is the single db per region model where all >>>>> devices in that region use a single db, with some cost sharing, >>>>> regulatory fee or tax arrangement >>>>> >>>>> For all of the multiple db per region cases, there ends up being >>>>> one, or at most a small number of dbs, that a given device can use >>>>> within that region. We could imagine discovery services that had >>>>> some way of knowing, or themselves discovering and caching which of >>>>> several dbs a given device could use. Not sure that makes a whole >>>>> lot of sense. But it makes virtually no sense to just discover the >>>>> list of possible services and then try them to see which one likes >>>>> you. >>>>> >>>>> The notion of caching to avoid asking has some merit. You could >>>>> cache the db URL you successfully used last, try it, get an error >>>>> if you are out of area (or a referral for case 5) and then, if >>>>> you do get an error, use the discovery mechanism to at least find >>>>> out what region you are in. >>>>> >>>>> I don't think that we should be standardizing queries between >>>>> devices and dbs that won't serve them. A device should not >>>>> routinely ask a db for service when there is no prior arrangement >>>>> for service. >>>>> >>>>> Brian >>>>> >>>>> On Jun 5, 2013, at 2:14 PM, Vincent Chen > wrote: >>>>> >>>>> >>>>> Brian, >>>>> >>>>> >>>>> >>>>> First of all, reliability, geographic diversity, capacity, = etc are >>>>> usually done with common URLs. Witness www.google.com >>>>> >>>>> >>>>> >>>>> Your example makes sense in this case, because www.google.com >>>>> is a single corporate entity and it >>>>> manages its own reliability, diversity, etc. >>>>> >>>>> In contrast, WSDBs are offered by different entities (sometimes >>>>> competing). The equivalence you are asking for would be >>>>> http://www.wsdb.com and= be automatically >>>>> routed to different implementations. I don't think that's what we >>>>> had in mind. >>>>> >>>>> -vince >>>>> >>>> >>>> >>>> >> >> >> -- -vince --_000_49E92720872B4761BF70A5E44B84A353neustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <51AF8A70C5272C4A9D08CDA3004FB21B@neustar.biz> Content-Transfer-Encoding: quoted-printable
The basic Forest Guide idea is there is no "sanction".  = ;There is only a cooperating set of guides. 

Very typically, you don't query the Forest Guide itself.  You que= ry a server who refers or iterates to the Forest Guide, which refers or ite= rates to the server that can help you.

The idea is to not depend on government action, but to allow it if it'= s there.  Anyone can set up a forest guide, but the servers that refer= to it have to trust it. 
This would be an example of transitive trust.  If you trust the l= ocal server, and it trusts the forest guide, then you can trust the forest = guide.

Brian

On Jun 12, 2013, at 3:16 PM, Vincent Chen <vchen@google.com>
 wrote:

How would a regulator sanction the "forest guide"= ;.

Or, equivalently, when a device gets a LoST Server, can it = trust it to give the list sanctioned by a regulator?
That's the bootstrap step that I don't quite understand.

-vince


On Wed, Jun 12, 2013 at 11:34 AM, Peter McCann <= span dir=3D"ltr"> <Peter.McCa= nn@huawei.com> wrote:
Ok, I just read 5582.

Seems ok to leave the decision of which forest guide to use up to
each manufacturer.  Will this be able to satisfy the Ofcom requirement=
to consult their regulator-maintained list before connecting to the
database?  Should we consider that consultation part of the discovery<= br> process?

-Pete



Rosen, Brian wrote:
> The LoST forest guide idea does that without anywhere near as much
> infrastructure.
>
> Basically, it relies on cooperating national servers to provide
> appropriate referral services.
>
> In fact the LoST forest guide does EXACTLY what we want - given a
> location and a URN indicating what service you want, it provides a
> referral to the right server in the right area for that service, based=
> on a set of polygons.
>
> Brian On Jun 12, 2013, at 1:51 PM, Peter McCann
> <Peter.McCann@huawei.com= > wrote:
>
>> Understood.
>>
>> But, I can't think of anyone else in a better position to resolve<= br> >> territorial disputes.  Even if they don't run the service
>> themselves, it seems like they're the best ones to publish the
>> national polygons and the list of pointers to national authorities= .
>>
>> -Pete
>>
>>
>> Rosen, Brian wrote:
>>> We have history with ideas like that.  Try to follow the = history of
>>> ENUM.  It failed, miserably.
>>>
>>> Brian
>>>
>>> On Jun 12, 2013, at 1:40 PM, Peter McCann <Peter.McCann@huawei.com>
>>> wrote:
>>>
>>>> Maybe the ITU-R should run a "root" discovery se= rvice, pointing at
>>>> national servers and mapping geographic coordinates to nat= ion states.
>>>> Each national server can list all the databases approved f= or use
>>>> within that nation.  The WSD can then pick one based = on its business
>>>> relationships.
>>>>
>>>> -Pete
>>>>
>>>>
>>>> Rosen, Brian wrote:
>>>>> <as individual> No, but we are discussing multip= le URLs for the
>>>>> SAME db, not multiple dbs.
>>>>>
>>>>> Multiple DBs arise because regulators want competitive= options.
>>>>> The list manager can list all the approved DBs, but a = given WSDB
>>>>> isn't likely to be able to use all of them, or even mo= st of them.
>>>>>
>>>>> I have to bring up business models in an IETF list, bu= t it seems we
>>>>> may need to at least understand what has been thought = about with
>>>>> multiple competing dbs.
>>>>>
>>>>> The models I've heard about are: 1. The manufacturer c= ontracts with
>>>>> a db, or a db per region to serve the devices it manuf= acturers. This
>>>>> is usually a lifetime of the device arrangement.  = ;Some provision has
>>>>> to be made to allow the owner to use a different DB, a= nd some
>>>>> provision has to be made to allow a new db to take ove= r a defunct
>>>>> (for whatever reason) db URL.
>>>>>
>>>>> 2. A service provider providing a service over WS, the= usual example
>>>>> is an ISP, contracts for the db service for all the de= vices it
>>>>> provides its service to.  This is annoying to pro= vision unless the
>>>>> device comes from the SP as part of the service or a t= ruck roll is
>>>>> needed.  Some provision has to be made to change = SPs. Sometimes the
>>>>> SP IS the db operator.
>>>>>
>>>>> 3. A db decides it will offer its service for free. &n= bsp;Any device can
>>>>> use it.
>>>>>
>>>>> 4. The end user of the device contracts with the db fo= r service.
>>>>> This usually requires provisioning by the device owner= as part of
>>>>> the sign- up process.
>>>>>
>>>>> 5. A notion of "roaming" or "pomading&q= uot; is supported where your
>>>>> "home" db has a relationship with a "vi= siting" db in another region
>>>>> who will supply service when the device is in the othe= r region.
>>>>>
>>>>> And of course there is the single db per region model = where all
>>>>> devices in that region use a single db, with some cost= sharing,
>>>>> regulatory fee or tax arrangement
>>>>>
>>>>> For all of the multiple db per region cases, there end= s up being
>>>>> one, or at most a small number of dbs, that a given de= vice can use
>>>>> within that region.  We could imagine discovery s= ervices that had
>>>>> some way of knowing, or themselves discovering and cac= hing which of
>>>>> several dbs a given device could use.  Not sure t= hat makes a whole
>>>>> lot of sense. But it makes virtually no sense to just = discover the
>>>>> list of possible services and then try them to see whi= ch one likes
>>>>> you.
>>>>>
>>>>> The notion of caching to avoid asking has some merit. =  You could
>>>>> cache the db URL you successfully used last, try it, g= et an error
>>>>> if you are out of area (or a referral for case 5) and = then, if
>>>>> you do get an error, use the discovery mechanism to at= least find
>>>>> out what region you are in.
>>>>>
>>>>> I don't think that we should be standardizing queries = between
>>>>> devices and dbs that won't serve them.   A device= should not
>>>>> routinely ask a db for service when there is no prior = arrangement
>>>>> for service.
>>>>>
>>>>> Brian
>>>>>
>>>>> On Jun 5, 2013, at 2:14 PM, Vincent Chen <vchen@google.com> wrote:
>>>>>
>>>>>
>>>>>   Brian,
>>>>>
>>>>>
>>>>>
>>>>>           First of all, relia= bility, geographic diversity, capacity, etc are
>>>>> usually done with common URLs.  Witness www.google.com
>>>>> <http://www.google.com/>
>>>>>
>>>>>
>>>>>   Your example makes sense in this case, because = www.google.com
>>>>> <http://www.google.com/>  is a single corporate entity and it=
>>>>> manages its own reliability, diversity, etc.
>>>>>
>>>>>   In contrast, WSDBs are offered by different ent= ities (sometimes
>>>>> competing). The equivalence you are asking for would &= nbsp;    be
>>>>> htt= p://www.wsdb.com <http://www.wsdb.com/>  and be automatically
>>>>> routed to different implementations. I don't think tha= t's what we
>>>>> had in mind.
>>>>>
>>>>>   -vince
>>>>>
>>>>
>>>>
>>>>
>>
>>
>>






--
-vince

--_000_49E92720872B4761BF70A5E44B84A353neustarbiz_-- From Peter.McCann@huawei.com Wed Jun 12 12:23:46 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 AE7E421E8051 for ; Wed, 12 Jun 2013 12:23:45 -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 cPalPY4VRlFa for ; Wed, 12 Jun 2013 12:23:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 457C921F99C2 for ; Wed, 12 Jun 2013 12:23:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASI98160; Wed, 12 Jun 2013 19:23:22 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 12 Jun 2013 20:22:48 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 12 Jun 2013 20:23:01 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Wed, 12 Jun 2013 12:22:55 -0700 From: Peter McCann To: Vincent Chen Thread-Topic: [paws] draft-wei-paws-database-discovery-01 Thread-Index: Ac5WiSt8Wa4oIijeTd2cWiURl5rVGwRClWJAAA8LBAAADqW+4P//jiwAgABw1WD//6SMgIAAdLOg Date: Wed, 12 Jun 2013 19:22:54 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F4AF33@dfweml512-mbx.china.huawei.com> References: <004f01ce5701$16c11720$44434560$@azu.ca> <000c01ce57c2$16a4bcd0$43ee3670$@azu.ca> <45C00ED9-46DC-4719-89F3-BA5DB6A33E0C@neustar.biz> <7142558D-2C34-4917-AC9D-8CC3915EC611@neustar.biz> <245B5995-9DEF-4F78-BCE6-769B226D8FFD@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F64@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F49F80@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F49FAD@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.224] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" Subject: Re: [paws] draft-wei-paws-database-discovery-01 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 12 Jun 2013 19:23:46 -0000 That's the question I'm struggling with too. It's easy just to assume that authority on spectrum issues descends from and is delegated from ITU-R, which is what led to my initial suggestion. But, as Brian points out, there are operational issues with the centralized approach. Perhaps we can only rely on the individual national certification processes that will test each device for non-interference and correct operation to guarantee that the device will only connect to an "authorized" database. But, it seems like a natural question to ask how a device can check for itself whether a database is authorized by the regulator under which it finds itself. This would be necessary, for example, if a database original= ly configured into the device was de-certified by the regulator, and seems to be the motivation for Ofcom to publish its approved list and require that all devices consult it before operation. -Pete Vincent Chen wrote: > How would a regulator sanction the "forest guide". >=20 > Or, equivalently, when a device gets a LoST Server, can it trust it to > give the list sanctioned by a regulator? > That's the bootstrap step that I don't quite understand. >=20 > -vince >=20 >=20 > On Wed, Jun 12, 2013 at 11:34 AM, Peter McCann > wrote: >=20 >=20 > Ok, I just read 5582. >=20 > Seems ok to leave the decision of which forest guide to use up to each > manufacturer. Will this be able to satisfy the Ofcom requirement to > consult their regulator-maintained list before connecting to the > database? Should we consider that consultation part of the discovery > process? >=20 > -Pete >=20 >=20 >=20 >=20 > Rosen, Brian wrote: > The LoST forest guide idea does that without > anywhere near as much > infrastructure. > > Basically, it relies on > cooperating national servers to provide > appropriate referral > services. > > In fact the LoST forest guide does EXACTLY what we want > - given a > location and a URN indicating what service you want, it > provides a > referral to the right server in the right area for that > service, based > on a set of polygons. > > Brian On Jun 12, 2013, at > 1:51 PM, Peter McCann > wrote: > >> > Understood. >> >> But, I can't think of anyone else in a better > position to resolve >> territorial disputes. Even if they don't run > the service >> themselves, it seems like they're the best ones to > publish the >> national polygons and the list of pointers to national > authorities. >> >> -Pete >> >> >> Rosen, Brian wrote: >>> We have > history with ideas like that. Try to follow the history of >>> ENUM.=20 > It failed, miserably. >>> >>> Brian >>> >>> On Jun 12, 2013, at 1:40 > PM, Peter McCann >>> wrote: >>> >>>> Maybe > the ITU-R should run a "root" discovery service, pointing at >>>> > national servers and mapping geographic coordinates to nation states. > >>>> Each national server can list all the databases approved for use > >>>> within that nation. The WSD can then pick one based on its > business >>>> relationships. >>>> >>>> -Pete >>>> >>>> >>>> Rosen, > Brian wrote: >>>>> No, but we are discussing multiple > URLs for the >>>>> SAME db, not multiple dbs. >>>>> >>>>> Multiple > DBs arise because regulators want competitive options. >>>>> The list > manager can list all the approved DBs, but a given WSDB >>>>> isn't > likely to be able to use all of them, or even most of them. >>>>> > >>>>> I have to bring up business models in an IETF list, but it seems > we >>>>> may need to at least understand what has been thought about > with >>>>> multiple competing dbs. >>>>> >>>>> The models I've heard > about are: 1. The manufacturer contracts with >>>>> a db, or a db per > region to serve the devices it manufacturers. This >>>>> is usually a > lifetime of the device arrangement. Some provision has >>>>> to be > made to allow the owner to use a different DB, and some >>>>> provision > has to be made to allow a new db to take over a defunct >>>>> (for > whatever reason) db URL. >>>>> >>>>> 2. A service provider providing a > service over WS, the usual example >>>>> is an ISP, contracts for the > db service for all the devices it >>>>> provides its service to. This > is annoying to provision unless the >>>>> device comes from the SP as > part of the service or a truck roll is >>>>> needed. Some provision > has to be made to change SPs. Sometimes the >>>>> SP IS the db > operator. >>>>> >>>>> 3. A db decides it will offer its service for > free. Any device can >>>>> use it. >>>>> >>>>> 4. The end user of > the device contracts with the db for service. >>>>> This usually > requires provisioning by the device owner as part of >>>>> the sign- up > process. >>>>> >>>>> 5. A notion of "roaming" or "pomading" is > supported where your >>>>> "home" db has a relationship with a > "visiting" db in another region >>>>> who will supply service when the > device is in the other region. >>>>> >>>>> And of course there is the > single db per region model where all >>>>> devices in that region use a > single db, with some cost sharing, >>>>> regulatory fee or tax > arrangement >>>>> >>>>> For all of the multiple db per region cases, > there ends up being >>>>> one, or at most a small number of dbs, that a > given device can use >>>>> within that region. We could imagine > discovery services that had >>>>> some way of knowing, or themselves > discovering and caching which of >>>>> several dbs a given device could > use. Not sure that makes a whole >>>>> lot of sense. But it makes > virtually no sense to just discover the >>>>> list of possible services > and then try them to see which one likes >>>>> you. >>>>> >>>>> The > notion of caching to avoid asking has some merit. You could >>>>> > cache the db URL you successfully used last, try it, get an error >>>>> > if you are out of area (or a referral for case 5) and then, if >>>>> > you do get an error, use the discovery mechanism to at least find >>>>> > out what region you are in. >>>>> >>>>> I don't think that we should > be standardizing queries between >>>>> devices and dbs that won't serve > them. A device should not >>>>> routinely ask a db for service when > there is no prior arrangement >>>>> for service. >>>>> >>>>> Brian > >>>>> >>>>> On Jun 5, 2013, at 2:14 PM, Vincent Chen > wrote: >>>>> >>>>> >>>>> Brian, >>>>> >>>>> > >>>>> >>>>> First of all, reliability, geographic diversity, > capacity, etc are >>>>> usually done with common URLs. Witness > www.google.com >>>>> >>>>> >>>>> >>>>> =20 > Your example makes sense in this case, because www.google.com >>>>> > is a single corporate entity and it >>>>> > manages its own reliability, diversity, etc. >>>>> >>>>> In > contrast, WSDBs are offered by different entities (sometimes >>>>> > competing). The equivalence you are asking for would be >>>>> > http://www.wsdb.com and be automatically >>>>> > routed to different implementations. I don't think that's what we >>>>> > had in mind. >>>>> >>>>> -vince >>>>> >>>> >>>> >>>> >> >> >> >=20 >=20 >=20 >=20 >=20 >=20 >=20 > From weixinpeng@huawei.com Thu Jun 13 23:30:56 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 1BAC921F9BC7 for ; Thu, 13 Jun 2013 23:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 QGL48zzzL0bn for ; Thu, 13 Jun 2013 23:30:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CA56621F9BC4 for ; Thu, 13 Jun 2013 23:30:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASL19198; Fri, 14 Jun 2013 06:30:47 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 14 Jun 2013 07:30:36 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 14 Jun 2013 07:30:45 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Fri, 14 Jun 2013 14:30:37 +0800 From: Weixinpeng To: "paws@ietf.org" Thread-Topic: considerations about a seperated discovery mechanism and an integrated one. Thread-Index: Ac5oyK3lwpuVgA+2SAyR4ak+Ff70lw== Content-Class: Date: Fri, 14 Jun 2013 06:30:36 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43CA33181nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Malyar, John P" , Peter McCann Subject: [paws] considerations about a seperated discovery mechanism and an integrated one. X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 06:30:56 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43CA33181nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Here are some of my considerations of database discovery mechanism= on differences between the independent LoST based mechanism and the mechan= ism integrated in PAWS protocol. (1) In the LoST protocol, an architecture for a global, scalable, = resilient, and administratively distributed system for mapping geographic l= ocation information to URLs has been provided [refer to RFC5582], and this architecture can be used for LoST based database discovery mechani= sm, so it can be sure the discovery mechanism can be used globally. But for= this mechanism how the "Forest Guide" should be deployed is an important issue to be satisfied. (2) For the scheme that integrates discovery mechanism totally in P= AWS protocol document, there are also some considerations. Firstly, I think= it is better of this "Standards Track " document only focus on the PAWS pr= otocol and let the discovery mechanism not standardized, and this can give more fr= eedom on how to provide discovery procedure in different regulatory domain;= secondly, the mechanism described in paws protocol seems not scalable very= well, may be some more description needs to be provided. -Xinpeng --_000_C5C3BB522B1DDF478AA09545169155B43CA33181nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

     &= nbsp;   Here are some of my considerations of database discovery = mechanism on differences between the independent LoST based mechanism and t= he mechanism integrated in PAWS protocol.

     &= nbsp;   (1) In the LoST protocol, an architecture for a global, s= calable, resilient, and administratively distributed system for mapping geo= graphic location information to URLs has been provided [refer to RFC5582],<= o:p>

and this architecture can be us= ed for LoST based database discovery mechanism, so it can be sure the disco= very mechanism can be used globally. But for this mechanism how the “= Forest Guide” should be deployed

is an important issue to be sat= isfied.

     &= nbsp;  (2) For the scheme that integrates discovery mechanism totally = in PAWS protocol document, there are also some considerations. Firstly, I t= hink it is better of this “Standards Track “ document only focu= s on the PAWS protocol

and let the discovery mechanism= not standardized, and this can give more freedom on how to provide discove= ry procedure in different regulatory domain; secondly, the mechanism descri= bed in paws protocol seems not scalable very well, may be some more description needs to be provided. <= /span>

 

 

-Xinpeng

--_000_C5C3BB522B1DDF478AA09545169155B43CA33181nkgeml507mbxchi_-- From vchen@google.com Fri Jun 14 00:09:10 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 528B721F9C4D for ; Fri, 14 Jun 2013 00:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 iaZcqISX8Ii6 for ; Fri, 14 Jun 2013 00:09:09 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2BADA21F9C4B for ; Fri, 14 Jun 2013 00:09:08 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so165118wev.14 for ; Fri, 14 Jun 2013 00:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CEPwLOj31VpC6X0Aq0YQoMgF/eixBQFRVDdUjC2DzRE=; b=EMY6Y7edFTV3qfCNaGIoBBthT4AOMtXxyB7xy7TFos8NZZ+db7OOax96h7vFolRu2o 0noeq0VsgIe6paGl8V1nXQTk1gvkVWIl4RPLzHv3OGcWkX0QFA2aMZyMHWPtUst1bxl1 Imead3/oYGcya5p53k/ZQ0STYA8KjIgoYE4T/3uF3q0q/Gaf2CAvin4rnnODJ0s6YarT 9NDoGxS/HpThQO06h2fXZiqfwQ1qRha6+i8ozpoGdLeveb0Cl2+XL2maesFgXQZaLf81 2VIUJwxK8/x2E/hsqOdrYAigs5coq0GFQ2m3jsCaTi738nC5hIketzbCDpQ1I+s2xKnB 0L7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=CEPwLOj31VpC6X0Aq0YQoMgF/eixBQFRVDdUjC2DzRE=; b=Kf6M9UUONQJiDb45r3WYRv/PeOrf6IEfLn3a0wabiAXPXLktWKhO6WqQKLa0IKvcia +NQQ7vzDoTQXd+JZhGAskKjZn1MUcWanNcdPxEg7Vcq63XO03Oznxg/TZsjJWp1PMjiN vW9dj31nmvxgwsDASaqMeXQ4K/2LMnR0iLPnm1wSVjoZnyknhl+lqXqyURk0Iy9deEtW OC0ebc2qF/XCwDfqNbOuVvobUhEpcZGppSOclX89jV7zYyDxkrZVFPLfqOZlPCfkNj3D lMedb1iDlObotqFcOGqndHeq7TmZe2OGSiQuqkFRxbwO2XBoXSaEVc1GEqOqKEiGrNfZ 3Lvg== MIME-Version: 1.0 X-Received: by 10.194.84.74 with SMTP id w10mr558645wjy.52.1371193748151; Fri, 14 Jun 2013 00:09:08 -0700 (PDT) Received: by 10.194.33.194 with HTTP; Fri, 14 Jun 2013 00:09:08 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Jun 2013 00:09:08 -0700 Message-ID: From: Vincent Chen To: Weixinpeng Content-Type: multipart/alternative; boundary=047d7bf0ca0246f36b04df17ecf0 X-Gm-Message-State: ALoCoQmUS3ssoAV5nYbW1rFhb70NbmeVJHj4p3oQJt+n8r0EB7HcW3IHP1PVfje4IG7FiyH/qsYvrK8r7Wtqg8ODmbuSK73MG7DcXGbFrgEjU06Gz8G93jxjTh1IMLnBvIPeGtG9vY6Vasmi9JY8C579+GARq5XArw8RhViGOYxdpjUd5Kr55FDly5eMKPOjWy5kL1hsGEjC Cc: "paws@ietf.org" , "Malyar, John P" , Peter McCann Subject: Re: [paws] considerations about a seperated discovery mechanism and an integrated one. X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 07:09:10 -0000 --047d7bf0ca0246f36b04df17ecf0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Xinpeng, Thanks. Let's then focus on getting the PAWS protocol to a sufficient state, not for discovery, but to support preconfiguration that is robust to change. Preconfiguration needs to support both Database URLs and Listing Server URLs (as required by Ofcom/ETSI). Let's focus on Section 4.1 1. A Device MAY have one or more Database URLs preconfigured 2. A Device MAY have one or more List Servers preconfigured (those approved by regulators) 3. To support changes, PAWS response messages MAY contain databaseChange parameter that includes alternate Database URLs and Devices SHOULD replace its entry for the responding Database with the alternates 4. Error handling is described on how the Device should try its list of Database URLs in case it fails to contact a Database 5. When a regulator requires a Listing Server, a Device must make sure that the DB it gets answers from is on that list. There is NO statement about a Device implementing additional logic to select amongst its list of preconfigured URLs, since that's completely Device-side behavior (e.g., caching, having prioritized preferred lists, etc.). Are there any objects to any of these steps? ----------------- Separately, in Section 5.15, when a Device is outside the coverage area of a Database, the Database MUST return an OUTSIDE_COVERAGE error and MAY include a list of alternate Databases. This is not intended to be full discovery, but could provide some flexibility before discovery is completely defined. Is this the step you have concerns with? or are you referring to another section? Thanks. -vince On Thu, Jun 13, 2013 at 11:30 PM, Weixinpeng wrote: > Hi all,**** > > Here are some of my considerations of database discovery > mechanism on differences between the independent LoST based mechanism and > the mechanism integrated in PAWS protocol.**** > > (1) In the LoST protocol, an architecture for a global, scalable= , > resilient, and administratively distributed system for mapping geographic > location information to URLs has been provided [refer to RFC5582],**** > > and this architecture can be used for LoST based database discovery > mechanism, so it can be sure the discovery mechanism can be used globally= . > But for this mechanism how the =93Forest Guide=94 should be deployed**** > > is an important issue to be satisfied.**** > > (2) For the scheme that integrates discovery mechanism totally in > PAWS protocol document, there are also some considerations. Firstly, I > think it is better of this =93Standards Track =93 document only focus on = the > PAWS protocol**** > > and let the discovery mechanism not standardized, and this can give more > freedom on how to provide discovery procedure in different regulatory > domain; secondly, the mechanism described in paws protocol seems not > scalable very well, may be some more description needs to be provided. **= * > * > > ** ** > > ** ** > > -Xinpeng**** > --=20 -vince --047d7bf0ca0246f36b04df17ecf0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Xinpeng,

Thanks. Let's then f= ocus on getting the PAWS protocol to a sufficient state, not for discovery,= but to support preconfiguration that is robust to change.
Preconfiguration needs to support both Database URLs and Listing Server URL= s (as required by Ofcom/ETSI).

Let'= ;s focus on Section 4.1
=A01. A Device MAY have one or more= Database URLs preconfigured
=A02. A Device MAY have one or more List Servers preconfigured (= those approved by regulators)
=A03. To support changes, PAW= S response messages MAY contain databaseChange parameter that includes
=A0 =A0 alternate Database URLs and Devices SHOULD replace its e= ntry for the responding Database with the alternates
=A04. = Error handling is described on how the Device should try its list of Databa= se URLs in case it fails to contact a Database
=A05. When a regulator requires a Listing Server, a Device must = make sure that the DB it gets answers from is on that list.

There is NO statement about a Device implementing add= itional logic to select amongst its list of preconfigured URLs, since
that's completely Device-side behavior (e.g., caching, havin= g prioritized preferred lists, etc.).

= Are there any objects to any of these steps?

-----------------
Separately, in Section 5.15, w= hen a Device is outside the coverage area of a Database, the Database MUST = return an OUTSIDE_COVERAGE
error and MAY include a list of = alternate Databases.

This is not intended to be full discovery, = but could provide some flexibility before discovery is completely defined.<= /div>

Is this the step you have concerns wit= h? or are you referring to another section?

Thanks.

-vince


On Thu, Jun 13, 2013 at 11:30 PM, Weixinpeng <<= a href=3D"mailto:weixinpeng@huawei.com" target=3D"_blank">weixinpeng@huawei= .com> wrote:

Hi all,

=A0=A0=A0=A0=A0=A0=A0=A0 Here a= re some of my considerations of database discovery mechanism on differences= between the independent LoST based mechanism and the mechanism integrated = in PAWS protocol.

=A0=A0=A0=A0=A0=A0=A0=A0 (1) In= the LoST protocol, an architecture for a global, scalable, resilient, and = administratively distributed system for mapping geographic location informa= tion to URLs has been provided [refer to RFC5582],

and this architecture can be us= ed for LoST based database discovery mechanism, so it can be sure the disco= very mechanism can be used globally. But for this mechanism how the =93Fore= st Guide=94 should be deployed

is an important issue to be sat= isfied.

=A0=A0=A0=A0=A0=A0=A0 (2) For t= he scheme that integrates discovery mechanism totally in PAWS protocol docu= ment, there are also some considerations. Firstly, I think it is better of = this =93Standards Track =93 document only focus on the PAWS protocol

and let the discovery mechanism= not standardized, and this can give more freedom on how to provide discove= ry procedure in different regulatory domain; secondly, the mechanism descri= bed in paws protocol seems not scalable very well, may be some more description needs to be provided.

=A0

=A0

-Xinpeng




--
-vince
--047d7bf0ca0246f36b04df17ecf0-- From weixinpeng@huawei.com Sun Jun 16 19:14: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 8E4FD21F9D9E for ; Sun, 16 Jun 2013 19:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 0wMKV1k9YEgy for ; Sun, 16 Jun 2013 19:13:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 44D2521F9BCE for ; Sun, 16 Jun 2013 19:13:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATY99181; Mon, 17 Jun 2013 02:13:53 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 17 Jun 2013 03:13:26 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 17 Jun 2013 03:13:50 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.117]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Mon, 17 Jun 2013 10:13:41 +0800 From: Weixinpeng To: Vincent Chen Thread-Topic: considerations about a seperated discovery mechanism and an integrated one. Thread-Index: Ac5oyK3lwpuVgA+2SAyR4ak+Ff70l///hKcA//scelA= Date: Mon, 17 Jun 2013 02:13:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.77.68] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B43CA3336Fnkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" , "Malyar, John P" , Peter McCann Subject: Re: [paws] considerations about a seperated discovery mechanism and an integrated one. X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Jun 2013 02:14:04 -0000 --_000_C5C3BB522B1DDF478AA09545169155B43CA3336Fnkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vince, The following statement seems ok to me. And I think a separate dis= covery document is needed. There is a question, when the Database returns an OUTSIDE_COVERAGE= error and includes a list of alternate Databases, how does database know t= he alternate databases? Thanks. -Xinpeng From: Vincent Chen [mailto:vchen@google.com] Sent: Friday, June 14, 2013 3:09 PM To: Weixinpeng Cc: paws@ietf.org; Peter McCann; Zhulei (A); Malyar, John P Subject: Re: considerations about a seperated discovery mechanism and an in= tegrated one. Xinpeng, Thanks. Let's then focus on getting the PAWS protocol to a sufficient state= , not for discovery, but to support preconfiguration that is robust to chan= ge. Preconfiguration needs to support both Database URLs and Listing Server URL= s (as required by Ofcom/ETSI). Let's focus on Section 4.1 1. A Device MAY have one or more Database URLs preconfigured 2. A Device MAY have one or more List Servers preconfigured (those approve= d by regulators) 3. To support changes, PAWS response messages MAY contain databaseChange p= arameter that includes alternate Database URLs and Devices SHOULD replace its entry for the re= sponding Database with the alternates 4. Error handling is described on how the Device should try its list of Da= tabase URLs in case it fails to contact a Database 5. When a regulator requires a Listing Server, a Device must make sure tha= t the DB it gets answers from is on that list. There is NO statement about a Device implementing additional logic to selec= t amongst its list of preconfigured URLs, since that's completely Device-side behavior (e.g., caching, having prioritized p= referred lists, etc.). Are there any objects to any of these steps? ----------------- Separately, in Section 5.15, when a Device is outside the coverage area of = a Database, the Database MUST return an OUTSIDE_COVERAGE error and MAY include a list of alternate Databases. This is not intended to be full discovery, but could provide some flexibili= ty before discovery is completely defined. Is this the step you have concerns with? or are you referring to another se= ction? Thanks. -vince On Thu, Jun 13, 2013 at 11:30 PM, Weixinpeng > wrote: Hi all, Here are some of my considerations of database discovery mechanism= on differences between the independent LoST based mechanism and the mechan= ism integrated in PAWS protocol. (1) In the LoST protocol, an architecture for a global, scalable, = resilient, and administratively distributed system for mapping geographic l= ocation information to URLs has been provided [refer to RFC5582], and this architecture can be used for LoST based database discovery mechani= sm, so it can be sure the discovery mechanism can be used globally. But for= this mechanism how the "Forest Guide" should be deployed is an important issue to be satisfied. (2) For the scheme that integrates discovery mechanism totally in P= AWS protocol document, there are also some considerations. Firstly, I think= it is better of this "Standards Track " document only focus on the PAWS pr= otocol and let the discovery mechanism not standardized, and this can give more fr= eedom on how to provide discovery procedure in different regulatory domain;= secondly, the mechanism described in paws protocol seems not scalable very= well, may be some more description needs to be provided. -Xinpeng -- -vince --_000_C5C3BB522B1DDF478AA09545169155B43CA3336Fnkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Vince,

 &nbs= p;       The following statement seems ok to = me. And I think a separate discovery document is needed.<= /p>

 &nbs= p;       There is a question, when the Databa= se returns an OUTSIDE_COVERAGE error and includes a list of alternate Datab= ases, how does database know the alternate databases?

 &nbs= p;       Thanks.

 = ;

-Xinpeng

 = ;

From: Vincent Chen [mailto:vchen@google.com]
Sent: Friday, June 14, 2013 3:09 PM
To: Weixinpeng
Cc: paws@ietf.org; Peter McCann; Zhulei (A); Malyar, John P
Subject: Re: considerations about a seperated discovery mechanism an= d an integrated one.

 

Xinpeng,

 

Thanks. Let's then focus on get= ting the PAWS protocol to a sufficient state, not for discovery, but to sup= port preconfiguration that is robust to change.

Preconfiguration needs to suppo= rt both Database URLs and Listing Server URLs (as required by Ofcom/ETSI).<= o:p>

 

Let's focus on Section 4.1=

 1. A Device MAY have one = or more Database URLs preconfigured

 2. A Device MAY have one = or more List Servers preconfigured (those approved by regulators)

 3. To support changes, PA= WS response messages MAY contain databaseChange parameter that includes

    alternate Databas= e URLs and Devices SHOULD replace its entry for the responding Database wit= h the alternates

 4. Error handling is desc= ribed on how the Device should try its list of Database URLs in case it fai= ls to contact a Database

 5. When a regulator requi= res a Listing Server, a Device must make sure that the DB it gets answers f= rom is on that list.

 

There is NO statement about a D= evice implementing additional logic to select amongst its list of preconfig= ured URLs, since

that's completely Device-side b= ehavior (e.g., caching, having prioritized preferred lists, etc.).

 

Are there any objects to any of= these steps?

 

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

Separately, in Section 5.15, wh= en a Device is outside the coverage area of a Database, the Database MUST r= eturn an OUTSIDE_COVERAGE

error and MAY include a list of= alternate Databases.

 

This is not intended to be full= discovery, but could provide some flexibility before discovery is complete= ly defined.

 

Is this the step you have conce= rns with? or are you referring to another section?

 

Thanks.

 

-vince

=  

On Thu, Jun 13, 2013 at 11:30 P= M, Weixinpeng <weixinpeng@huawei.com> wrote:

Hi all,

       &nb= sp; Here are some of my considerations of database discovery mechanism on d= ifferences between the independent LoST based mechanism and the mechanism i= ntegrated in PAWS protocol.

       &nb= sp; (1) In the LoST protocol, an architecture for a global, scalable, resil= ient, and administratively distributed system for mapping geographic locati= on information to URLs has been provided [refer to RFC5582],

and this architecture can be used for LoST ba= sed database discovery mechanism, so it can be sure the discovery mechanism= can be used globally. But for this mechanism how the “Forest Guide” should be deployed

is an important issue to be satisfied.

        (2= ) For the scheme that integrates discovery mechanism totally in PAWS protoc= ol document, there are also some considerations. Firstly, I think it is bet= ter of this “Standards Track “ document only focus on the PAWS pro= tocol

and let the discovery mechanism not standardi= zed, and this can give more freedom on how to provide discovery procedure i= n different regulatory domain; secondly, the mechanism described in paws protocol seems not scalable very well, may= be some more description needs to be provided.

 

 

-Xinpeng



 

--
-vince

--_000_C5C3BB522B1DDF478AA09545169155B43CA3336Fnkgeml507mbxchi_-- From vchen@google.com Sun Jun 16 22:18:10 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 667E321F9A42 for ; Sun, 16 Jun 2013 22:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 U8eKXjRUGpd4 for ; Sun, 16 Jun 2013 22:18:09 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 328A421F9A41 for ; Sun, 16 Jun 2013 22:18:02 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so2030594wgh.9 for ; Sun, 16 Jun 2013 22:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OSpYWZYRGbyCJkcE3NIZMbHtxwjEOiOIdM+gQLBZSZo=; b=IGd75EtjDzLE/2lnY4/jsE3kcb0wj87YS09ttb7PiAell+Lf8r7OndcIIGcyKFjMQE h/ZuwjsQogmQ39hOq53LSyZpJJQJwM9RsB/Lp+kDAJ0KcFeNdlq7jayjs4GWGSp+1KME 1HOpLmMofRkfYje6ykJnHLb1NnXIUSLavURH2p2X4QrAgbuXOqtp2nEtdnaF1yPB/tx5 bu9M26FnCzFi7tk9gwrdHImWXPwlDeoMNV0k0ntIg7tfbiC6VtaNol+EROqHqZ8wMm4Y QM3Cwq+FbXRctGEC4aksjZg/Y5y7YxKfFNyx+Ei+XTtEIIhZ5OI+YKX5cU94JhoqzvDH 9kUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=OSpYWZYRGbyCJkcE3NIZMbHtxwjEOiOIdM+gQLBZSZo=; b=RrfKFYBWo187f/J+DL1NOEqC+tKt2Uidlv0bXZoFLH7Xrme0fNz5TNA4By5ytm2kuu fSfUHB1xAPx/6AG6YupvxGyjB7meM7zyhsleVjiylAERsGEoNuX5jI3TxB8D5tcocakC KEocm6TAq0YC2FaCIJfzJRugJF+CBkmDqlGF0l4p8VWmdr0zezHwuENLb1bHYFeXd3sg /P+YQEwgaBWRKQ82CjeiQ9RdqyrxMwqzo1J/+S6GfJ4Dhn9DzqwIL8D00cd1IyHQbytl n6dbaYXji5hhyZohbdILDrELl1/PY/yYSDAVtoQLYsowMSAGqWl6CxQhVncLtwd5nBIq SQ0Q== MIME-Version: 1.0 X-Received: by 10.180.183.40 with SMTP id ej8mr3925253wic.37.1371446282026; Sun, 16 Jun 2013 22:18:02 -0700 (PDT) Received: by 10.194.33.194 with HTTP; Sun, 16 Jun 2013 22:18:01 -0700 (PDT) In-Reply-To: References: Date: Sun, 16 Jun 2013 22:18:01 -0700 Message-ID: From: Vincent Chen To: Weixinpeng Content-Type: multipart/alternative; boundary=001a11c2297a7824d504df52b894 X-Gm-Message-State: ALoCoQmLXOZIs3ylc5siz/yjrdNGJRMldks8wbLEeuZPnF3I1CYU070WhlZGyZOr/7z87zm3ckEpR4YGA2d5baIuvujx4folEfmmFQz4n6qKvbA87o4HxA1xs/jPxyD7ZFdcHKN/luk2dQ4ZxrsQZYxlM4OUkqimKI41c3/ywDuE8lRlMy9g8iwv+pY+5JqeliqSU/6MD6kQ Cc: "paws@ietf.org" , "Malyar, John P" , Peter McCann Subject: Re: [paws] considerations about a seperated discovery mechanism and an integrated one. X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Jun 2013 05:18:10 -0000 --001a11c2297a7824d504df52b894 Content-Type: text/plain; charset=ISO-8859-1 Hi Xinpeng, On Sun, Jun 16, 2013 at 7:13 PM, Weixinpeng wrote: > Hi Vince, **** > > The following statement seems ok to me. And I think a separate > discovery document is needed.**** > > There is a question, when the Database returns an > OUTSIDE_COVERAGE error and includes a list of alternate Databases, how does > database know the alternate databases? > Good question. Presumably, it would depend on business relationships between the databases and trust that the returned database(s) are certified by the application regulator. In a domain that requires the use of a Listing Server, the device must still check the alternate database(s) with the Listing Server. A flow might be: 1. Device is in regulatory domain X (but does not know it), but contacts a Database A in Y 2. Database Y returns OUTSIDE_COVERAGE error, suggesting the use of Database B 3. Device contacts Database B, returning available spectrum and a ruleset that indicates the device is in domain X 4. Device uses its (preconfigured) Listing Server for X to determine whether Database B is valid 5. If so, Device can use the available spectrum returned by B (The device may do any sort of caching it desires to try to start with the "right" database for the next query). -vince --001a11c2297a7824d504df52b894 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Xinpeng,


On Sun, Jun 16, 2013 at 7:13 PM, Weixinpeng <weixin= peng@huawei.com> wrote:

Hi Vince,

=A0=A0=A0= =A0=A0=A0=A0=A0 The following statement seems ok to me. And I think a separ= ate discovery document is needed.

=A0=A0=A0= =A0=A0=A0=A0=A0 There is a question, when the Database returns an OUTSIDE_C= OVERAGE error and includes a list of alternate Databases, how does database know the alternate databases?


=
Good question. Presumably, it would depend on business rel= ationships between the databases and trust that the returned database(s)
are certified by the application regulator.

=
In a domain that requires the use of a Listing Server, the= device must still check the alternate database(s) with the Listing Server.=

A flow might be:

=
=A01. Device is in regulatory domain X (but does not know it), b= ut contacts a Database A in Y
=A02. Database Y returns OUTS= IDE_COVERAGE error, suggesting the use of Database B
=A03. Device contacts Database B, returning available spectrum a= nd a ruleset that indicates the device is in domain X
=A04.= Device uses its (preconfigured) Listing Server for X to determine whether = Database B is valid
=A05. If so, Device can use the available spectrum returned by B=

(The device may do any sort of cachin= g it desires to try to start with the "right" database for the ne= xt query).

-vince
--001a11c2297a7824d504df52b894-- From Peter.McCann@huawei.com Mon Jun 17 06:25: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 0DD2F21F8ADC for ; Mon, 17 Jun 2013 06:25:39 -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 Y9pH0U2RRnsN for ; Mon, 17 Jun 2013 06:25:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA20621F88EA for ; Mon, 17 Jun 2013 06:25:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATZ54391; Mon, 17 Jun 2013 13:25:31 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 17 Jun 2013 14:25:08 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 17 Jun 2013 14:25:26 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Mon, 17 Jun 2013 06:25:19 -0700 From: Peter McCann To: Vincent Chen , Weixinpeng Thread-Topic: considerations about a seperated discovery mechanism and an integrated one. Thread-Index: Ac5oyK3lwpuVgA+2SAyR4ak+Ff70l///hKcA//scelCACnbugP//7VIA Date: Mon, 17 Jun 2013 13:25:18 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F4B3F5@dfweml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "paws@ietf.org" , "Malyar, John P" Subject: Re: [paws] considerations about a seperated discovery mechanism and an integrated one. X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Jun 2013 13:25:39 -0000 Vincent, Do you imagine that the protocol used to check with the listing service is also PAWS? -Pete Vincent Chen wrote: > Hi Xinpeng, >=20 >=20 >=20 > On Sun, Jun 16, 2013 at 7:13 PM, Weixinpeng > wrote: >=20 >=20 > Hi Vince, >=20 > The following statement seems ok to me. And I think a > separate discovery document is needed. >=20 > There is a question, when the Database returns an > OUTSIDE_COVERAGE error and includes a list of alternate Databases, how > does database know the alternate databases? >=20 >=20 > Good question. Presumably, it would depend on business relationships > between the databases and trust that the returned database(s) are > certified by the application regulator. >=20 > In a domain that requires the use of a Listing Server, the device must > still check the alternate database(s) with the Listing Server. >=20 > A flow might be: >=20 > 1. Device is in regulatory domain X (but does not know it), but > contacts a Database A in Y 2. Database Y returns OUTSIDE_COVERAGE > error, suggesting the use of Database B 3. Device contacts Database > B, returning available spectrum and a ruleset that indicates the > device is in domain X 4. Device uses its (preconfigured) Listing > Server for X to determine whether Database B is valid 5. If so, > Device can use the available spectrum returned by B >=20 > (The device may do any sort of caching it desires to try to start with > the "right" database for the next query). >=20 > -vince From vchen@google.com Mon Jun 17 07:59:34 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 6B01D21F9CD1 for ; Mon, 17 Jun 2013 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.853 X-Spam-Level: X-Spam-Status: No, score=-1.853 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 QEBQQnHj7lZ1 for ; Mon, 17 Jun 2013 07:59:34 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8496521F9CC9 for ; Mon, 17 Jun 2013 07:59:33 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u53so2443420wes.37 for ; Mon, 17 Jun 2013 07:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y8ZCgOwKdl460oVTg5bLk2+zH/DB22nXqZpJgfbTORk=; b=nqh4UK2WiwqHL5PfCyxFEMdbwZAomNECxH3youcIpCs4Iu5K20cs0J84OC9ToABra5 gM6eITLTary30pqYyhD9gkjowBjQJ4j/1ni5fHfk0ENzPhSU0ZQXQ7jqOdTZexcPL+oF +cWMe+FHXY9QkChVTlrsPpHCdpRbV/dgWRLFjaEe+lwEruJZWEYdDyG4pJG7w0sFHP01 T6TcrqkqVUQfwU/+kVovEat+eEJ0ilJ6W9tcc86+odLQNEKQEVT9pIuj1X0quFMQ0I/S qzQTs9abI/u8tipxWJn/XC0Zuwa+D4PJMRQB0iFvxkOgkPH4u5JWK6S/mifG1c9lkFAS soqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Y8ZCgOwKdl460oVTg5bLk2+zH/DB22nXqZpJgfbTORk=; b=YlVTE/ipEn/Mtl70tTwnevqIww3xHGP1MgXtBqRNQFaKjpukQtAZDzetKlOdum8DLN /VTMPuC0rM7MLSwIuVee24GuaE+fyp0R8e4glmvalEOkM4ZRBQPhTTjfEoeMwK8hV1+o 4b3CkGxOlF3VzurhuLytyAnQkchK8dEr2QDW3zD477OnnOSFgw/8mbCKQs4pCyP7qcwu CIMs8/1AqdGFsd2qQeWbt8duLabQBuYzO6EhTEMlzB7wOmiAwPAUgCkFga1xVlbI4GI0 0pqVFj3h846J5etRO1CbLHg39iW4HToeJEuH6TAVzvv+ppIGURKCPDBsU6cmznSzcyyj javQ== MIME-Version: 1.0 X-Received: by 10.194.6.99 with SMTP id z3mr8189020wjz.57.1371481172602; Mon, 17 Jun 2013 07:59:32 -0700 (PDT) Received: by 10.194.33.194 with HTTP; Mon, 17 Jun 2013 07:59:32 -0700 (PDT) In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F4B3F5@dfweml512-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716F4B3F5@dfweml512-mbx.china.huawei.com> Date: Mon, 17 Jun 2013 07:59:32 -0700 Message-ID: From: Vincent Chen To: Peter McCann Content-Type: multipart/alternative; boundary=047d7b414f281c10e204df5ad8b0 X-Gm-Message-State: ALoCoQmC4BYx+zEIrrq0pdb5PcjSjIl54NkhaVbBP+WSTdyF7SNbh91xxtdO53axTT7B3/Il6+xsG4LaHNLbcfKXE3g29/PGznutp16IB335ECy0QMdOnPPmogMXxD83buiFRx/q7KvE7FvfqKN0PUq5n9pHqgC7Os1pRFCBEM4GVwFxi6TwBr5VDq9b1kMJnnfC5qFLQIFx Cc: "paws@ietf.org" , "Malyar, John P" Subject: Re: [paws] considerations about a seperated discovery mechanism and an integrated one. X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 17 Jun 2013 14:59:34 -0000 --047d7b414f281c10e204df5ad8b0 Content-Type: text/plain; charset=ISO-8859-1 Pete, On Mon, Jun 17, 2013 at 6:25 AM, Peter McCann wrote: > Vincent, > > Do you imagine that the protocol used to check with the listing service > is also PAWS? > I'm not yet convinced it should be PAWS, but just wanted to float the idea, since the the messages are so similar, namely: - Location-aware service - Ability to express a list of (name, url) pairs in the response - Preconfiguration of some "root" server I just don't see how a deployment would work without preconfiguration of some sort. I think it might be confusing to define a protocol that we don't know how to make real. Even if we were to add it to PAWS, though, it would be a separate set of functionalities, such that - A Database MAY implement only the LIsting service - A Database MAY implement only the Spectrum service - A Database MAY implement both A Database implementing the Listing service may consult other Listing services to minimize retry logic on Devices. -vince > > -Pete > > > --047d7b414f281c10e204df5ad8b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Pete,


On Mon, Jun 17, 2013 at 6:25 AM, Peter McCann <P= eter.McCann@huawei.com> wrote:
Vincent,

Do you imagine that the protocol used to check with the listing service
is also PAWS?

I'm not yet con= vinced it should be PAWS, but just wanted to float the idea, since the
the messages are so similar, namely:

=A0- Location-aware service
=A0- Ability to expr= ess a list of (name, url) pairs in the response
=A0- Precon= figuration of some "root" server

I just don't see how a deployment would work without preconfiguration o= f some sort.
I think it might be confusing to define a prot= ocol that we don't know how to make real.

Even if we were to add it to PAWS, though, it would be a separat= e set of functionalities, such that
=A0- A Database MAY imp= lement only the LIsting service
=A0- A Database MAY impleme= nt only the Spectrum service
=A0- A Database MAY implement both

A Database implementing the Listing service may consult other Listi= ng services to minimize retry logic on Devices.
=A0
-vince
=A0

-Pete


--047d7b414f281c10e204df5ad8b0-- From internet-drafts@ietf.org Wed Jun 19 09:45:31 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 5138621F9D17; Wed, 19 Jun 2013 09:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, 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 RugsV--Ap-Zp; Wed, 19 Jun 2013 09:45:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E2421F9CFB; Wed, 19 Jun 2013 09:44:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130619164457.26617.82389.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 09:44:57 -0700 Cc: paws@ietf.org Subject: [paws] I-D Action: draft-ietf-paws-protocol-06.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:45:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Protocol to Access WS database Working Gr= oup of the IETF. Title : Protocol to Access Spectrum Database Author(s) : Vincent Chen Subir Das Lei Zhu John Malyar Peter J. McCann Filename : draft-ietf-paws-protocol-06.txt Pages : 95 Date : 2013-06-19 Abstract: Portions of the radio spectrum that are allocated to licensees are available for non-interfering use. This available spectrum is called "White Space." Allowing secondary users access to available spectrum "unlocks" existing spectrum to maximize its utilization and to provide opportunities for innovation, resulting in greater overall spectrum utilization. One approach to manage spectrum sharing uses databases to report spectrum availability to devices. To achieve interoperability among multiple devices and databases, a standardized protocol must be defined and implemented. This document defines such a protocol, the "Protocol to Access White Space database" (PAWS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-paws-protocol There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-paws-protocol-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protocol-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vchen@google.com Wed Jun 19 09:53:03 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 9376821F9D48 for ; Wed, 19 Jun 2013 09:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.874 X-Spam-Level: X-Spam-Status: No, score=-1.874 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 uMAJMrmtrnam for ; Wed, 19 Jun 2013 09:53:01 -0700 (PDT) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 2555D21F99E9 for ; Wed, 19 Jun 2013 09:53:00 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id z11so197324wgg.1 for ; Wed, 19 Jun 2013 09:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CMWZm7dObcpZ7ZhuXQrG4osXYOJVEOnJGd4Ma8tcBvI=; b=AxTZkG177V6DId48SW70DQm/5+ufoj2VrqHMfrKti1XupPIVeOjrf0utxi/uko6Efu K3tpeDnSXfAT0MUHVSAs4F95fJXq6OxKjYZUUIgZ7wZ4ZGuj2r4BSkOYrz1V8iorDncl K8bRDb2++m4Q5U8CHj/3uSkEEUCXgJGxYjq8C3uieyC8OR7V6QSOwy2yXXSGjntJBuyM CQ43oh7TD6eoO3ztiLTDKBgeFQ9jYRJDEeNR2ZuyvOktBdQ9pdfAemcKm+x4sRWmvZq0 G7Vnk8KHjYExAgcyTMH5T4xz1zEyMYr/H6U1ldObXpgpDn/TkXoqvkfeEniVuq6qYWHE 2miw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=CMWZm7dObcpZ7ZhuXQrG4osXYOJVEOnJGd4Ma8tcBvI=; b=aSEpKug/sYvHPOOKge4+5edkO5WsMb+UE/sMDoeS/F5fhMkec4kXmWpGJMknFYZVID g/z97EfCG4/D/VLnqMfvE0SPxlp9Jc9mEkrf4eZa1kbgDY9tw88DPNOGl4gBdUwD9N5J 6jxceGSV2GnyfcTwRr9yoCpe9XIBCYzTuTyw5JXlz9cCP6djtYSZz4UPW444XXG6NY6U qsxdgeoOm6riTFRCp5Gb7ewLEyTHc2/v05i751JM+qRrOln9xfztrcg2m4hi7AUQmFUd BFdsDL5lqfw5TQIViexpRG/c2f+WmH/TC0DuvuhH3QymnvPHHONezaepofseJrvL8lAz 9kow== MIME-Version: 1.0 X-Received: by 10.180.38.37 with SMTP id d5mr11691433wik.37.1371660780113; Wed, 19 Jun 2013 09:53:00 -0700 (PDT) Received: by 10.194.33.194 with HTTP; Wed, 19 Jun 2013 09:53:00 -0700 (PDT) In-Reply-To: <20130619164457.26617.82389.idtracker@ietfa.amsl.com> References: <20130619164457.26617.82389.idtracker@ietfa.amsl.com> Date: Wed, 19 Jun 2013 09:53:00 -0700 Message-ID: From: Vincent Chen To: "paws@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f646c8b8d342204df84a976 X-Gm-Message-State: ALoCoQmu7K15wLnGPXFn0Z5HQLtBf5OhwSPrrrzBSJbpDnx5JxIPyLLOppb3xeAi3/78/OyceRTaNNX080kbsTeu5ExnoKDsAbYJWyy4YF0nT1q/FjXNseiuD3TLOGsOghr3fkbF/Jjj6kAvLSw7cs2mDNNYpdVQw8fOiFUqM2M/dX16auEBd0gNlgTheeKG9CtZ/guj4h+a Subject: Re: [paws] I-D Action: draft-ietf-paws-protocol-06.txt X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:53:03 -0000 --e89a8f646c8b8d342204df84a976 Content-Type: text/plain; charset=ISO-8859-1 All, I've uploaded a new version of the PAWS protocol draft. I believe I've address all open items. Summary of changes: - Removed requirement for JSON-RPC 1.0. It just references 2.0 - Fixed typos and added clarifications, including updating some of the diagrams Diff: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-paws-protocol-05.txt&url2=http://tools.ietf.org/id/draft-ietf-paws-protocol-06.txt Thanks. -vince On Wed, Jun 19, 2013 at 9:44 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Protocol to Access WS database Working > Group of the IETF. > > Title : Protocol to Access Spectrum Database > Author(s) : Vincent Chen > Subir Das > Lei Zhu > John Malyar > Peter J. McCann > Filename : draft-ietf-paws-protocol-06.txt > Pages : 95 > Date : 2013-06-19 > > Abstract: > Portions of the radio spectrum that are allocated to licensees are > available for non-interfering use. This available spectrum is called > "White Space." Allowing secondary users access to available spectrum > "unlocks" existing spectrum to maximize its utilization and to > provide opportunities for innovation, resulting in greater overall > spectrum utilization. > > One approach to manage spectrum sharing uses databases to report > spectrum availability to devices. To achieve interoperability among > multiple devices and databases, a standardized protocol must be > defined and implemented. This document defines such a protocol, the > "Protocol to Access White Space database" (PAWS). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-paws-protocol > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-paws-protocol-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-paws-protocol-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws > -- -vince --e89a8f646c8b8d342204df84a976 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

I've uploaded a new version of= the PAWS protocol draft.
I believe I've address all open ite= ms.

Summary of changes:
=A0- Removed req= uirement for JSON-RPC 1.0. It just references 2.0

Thanks.

-vince


On Wed, Jun 19, 2013 at 9:44 AM, <internet-drafts@iet= f.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the Protocol to Access WS database Working = Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Protocol to Access Spectrum Dat= abase
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Vincent Chen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subir Das
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Lei Zhu
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 John Malyar
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Peter J. McCann
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-paws-protocol-06.txt =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 95
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-06-19

Abstract:
=A0 =A0Portions of the radio spectrum that are allocated to licensees are =A0 =A0available for non-interfering use. =A0This available spectrum is cal= led
=A0 =A0"White Space." =A0Allowing secondary users access to avail= able spectrum
=A0 =A0"unlocks" existing spectrum to maximize its utilization an= d to
=A0 =A0provide opportunities for innovation, resulting in greater overall =A0 =A0spectrum utilization.

=A0 =A0One approach to manage spectrum sharing uses databases to report
=A0 =A0spectrum availability to devices. =A0To achieve interoperability amo= ng
=A0 =A0multiple devices and databases, a standardized protocol must be
=A0 =A0defined and implemented. =A0This document defines such a protocol, t= he
=A0 =A0"Protocol to Access White Space database" (PAWS).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-paws-protocol<= br>
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-paws-protocol-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-paws-protoc= ol-06


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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



--
-vince
--e89a8f646c8b8d342204df84a976-- From Gabor.Bajko@nokia.com Wed Jun 19 10:17:52 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 97B7921F9DEC for ; Wed, 19 Jun 2013 10:17:52 -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 LpeVOnyupO1T for ; Wed, 19 Jun 2013 10:17:47 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 39C6B21F9DC5 for ; Wed, 19 Jun 2013 10:17:46 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (vaebh102.europe.nokia.com [10.160.244.23]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id r5JHHdks013606 for ; Wed, 19 Jun 2013 20:17:39 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.24]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Jun 2013 20:17:38 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.101]) by 008-AM1MMR1-008.mgdnok.nokia.com ([65.54.30.24]) with mapi id 14.02.0328.011; Wed, 19 Jun 2013 17:19:17 +0000 From: To: Thread-Topic: WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 Thread-Index: Ac5tED3uJb/xv+13Q/isaSe3CRkDqg== Date: Wed, 19 Jun 2013 17:17:37 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.143.158.145] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Jun 2013 17:17:39.0210 (UTC) FILETIME=[E65D46A0:01CE6D10] X-Nokia-AV: Clean Subject: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 Jun 2013 17:17:52 -0000 All, The Editor of the document posted a new version and indicated that all open= issues raised on the list were resolved, and that there are no more open i= ssues he is aware of. Therefore, I'd like to issue a wg last call on the document. We need review= s and feedback in order to be able to progress the document. Please read through the draft and send any comments you may have to the lis= t in the next 2-3 weeks. If you review the draft and have no comments, send a note to the list that = the draft is good as it is, we need these notes as much as we need the actu= al comments. Thanks, Gabor From stpeter@stpeter.im Mon Jun 24 16:27: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 2857211E818C for ; Mon, 24 Jun 2013 16:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSjYUKF9WKAe for ; Mon, 24 Jun 2013 16:27:19 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E9F0A11E8167 for ; Mon, 24 Jun 2013 16:27:18 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 716EA412C3; Mon, 24 Jun 2013 17:27:33 -0600 (MDT) Message-ID: <51C8D5D3.2080302@stpeter.im> Date: Mon, 24 Jun 2013 17:27:15 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: paws@ietf.org X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [paws] JSON vCard in draft-ietf-paws-protocol X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Protocol to Access White Space database \(PAWS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 23:27:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Someone who is implementing draft-ietf-paws-protocol pinged me offlist with some questions about draft-bhat-vcarddav-json. After wondering why he was doing that, I noticed that the PAWS protocol still references that early work on a JSON representation of vCard, instead of the output of the JCARDCAL WG: http://datatracker.ietf.org/doc/draft-ietf-jcardcal-jcard/ Please make sure to update the PAWS spec so that it uses the official representation of vCard, and please note that Raghu and I (as authors of draft-bhat-vcarddav-json) formally retracted our work in favor of the document being produced in the JCARDCAL WG. Also, if you have feedback on draft-ietf-jcardcal-jcard, please send it along as soon as possible, because it has already been submitted to the IESG for publication. Thanks! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRyNXTAAoJEOoGpJErxa2pxLEP/i/JzpQ6bliZPVCSdWmuXHiw eVfp2bSLlOlmQnY/T3Hzv9002xUS8lO/jhdlv+bGR23hOt1hlwR/R5GKkedLadwv pKEpSKtjnCnB2PmfVzBxoWt3VkWWs5U27Mp8ajWhWrOa5T2ifck0xi+3Np69OyZ8 b7TZ/tEprJa/9EWc+HP3MWJc68rwHJd9Usm8pE9dkXaiqxc3ci9p3poMFvcwyn3I 2Km7+Pjc77ZTTe40SNnn/GkWGXMd46QRBkNnaBuALiPYh/aR6hQMWR/8ymyrUMXU oeWrN9PnLk9GY7mvkEZgsex/EdpArqqwGmvLVD2/Xb27WDoUeNvyK+WjJjRN5kWK baXatAncSTygGqlsmvxr2e462OpQ2MESoZxYzPGWiKJkHlRpFh+bEy/c1hBB4qWO EvYYj/d8GBDGG+7LN5oSu8woGduYEwleh6P70U7r4CkuM3vNhpHU5lixW6t+Bu39 sDQOsa1XGjBMX6SXvSW01w+7yt096e+cj3OF0QlPF5jzDf9LZQcJkf5UWzuzbb50 DA1PlD0WyNN/tgCYxSHVq7ADmTNrRfjNKahYN+TQrwrhU7E9xp4tdRKFhKrVDQGw arUqMGb6kxHrbkLJeEratxdOC0mRIr+1KY2UBOB7wTvksYOYboYPNsbf74SrPdyd +PLOZPmaitoxE9rFZ+Ml =Lywj -----END PGP SIGNATURE----- From sjyou@etri.re.kr Sun Jun 30 22:30: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 062D921F9D41 for ; Sun, 30 Jun 2013 22:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.346 X-Spam-Level: X-Spam-Status: No, score=-97.346 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, 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 j08UMZTyK+IW for ; Sun, 30 Jun 2013 22:30:15 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 9B79921F9D08 for ; Sun, 30 Jun 2013 22:30:14 -0700 (PDT) Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 1 Jul 2013 14:30:13 +0900 Received: from SMTP1.etri.info ([169.254.1.31]) by SMTP2.etri.info ([169.254.2.3]) with mapi id 14.01.0355.002; Mon, 1 Jul 2013 14:30:11 +0900 From: =?ks_c_5601-1987?B?wK+8usH4?= To: "paws@ietf.org" Thread-Topic: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 Thread-Index: Ac5tED3uJb/xv+13Q/isaSe3CRkDqgI4NXhQ Date: Mon, 1 Jul 2013 05:30:10 +0000 Message-ID: References: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E476022A10DC@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.254.65.147] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [paws] WGLC on http://tools.ietf.org/html/draft-ietf-paws-protocol-06 X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 Jul 2013 05:30:20 -0000 SGkgQWxsLA0KDQpJIGhhdmUgZm91bmQgdHdvIHR5cG9zLiANCg0KQXQgZXhhbXBsZSAiZ2V0U3Bl Y3RydW0iIEpTT04tUlBDIGluIDYuNC4xLiA6DQoJImlkIjogInh4eHh4eCIsICAgICAtLT4gQ29t bWEgc2hvdWxkIGJlIGRlbGV0ZWQuDQpBdCBleGFtcGxlICJnZXRTcGVjdHJ1bUJhdGNoIiBKU09O LVJQQyBpbiA2LjUuMS4gOg0KCSJpZCI6ICJ4eHh4eHgiLCAgICAgLS0+IENvbW1hIHNob3VsZCBi ZSBkZWxldGVkLg0KDQoNCkkgaGF2ZSBhIGNvbW1lbnQgYWJvdXQgZXhhbXBsZSAiZ2V0U3BlY3Ry dW0iIEpTT04tUlBDIHJlc3BvbnNlIGluIDYuNC4yIGFuZCA2LjUuMi4NClRoZXJlIGFyZSB0d28g c3BlY3RydW0gaW5mb3JtYXRpb24gcGFyYW1ldGVycyAgZm9yIHRoZSBzYW1lIGZyZXF1ZW5jeSBy YW5nZS4NCk9uZSBpcyBmb3IgYmFuZHdpZHRoIDZlNiwgYW5kIHRoZSBvdGhlciBpcyBmb3IgYmFu ZHdpZHRoIDFlNS4gDQpCdXQgc3BlY3RyYWwgZGVuc2l0eSBvZiA2ZTYgaXMgZGlmZmVyZW50IGZy b20gdGhhdCBvZiAxZTUgaW4gdGhlIHNhbWUgZnJlcXVlbmN5IHJhbmdlLg0KSXQgd2lsbCBiZSBt b3JlIG5pY2UgaWYgdGhlIHNwZWN0cmFsIGRlbnNpdHkgb2YgdGhlIHNhbWUgZnJlcXVlbmN5IHJh bmdlIGlzIHNhbWUuIA0KT3IgaXQgd2lsbCBiZSBhbHNvIG5pY2UgaWYgZnJlcXVlbmN5IHJhbmdl cyBhcmUgbW9kaWZpZWQgdG8gYmUgZGlmZmVyZW50IGZyb20gZWFjaCBvdGhlci4NCg0KVGhhbmsg eW91Lg0KDQpCUiwNClN1bmdqaW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogcGF3cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86cGF3cy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgR2Fib3IuQmFqa29Abm9raWEuY29tDQpTZW50OiBUaHVyc2RheSwgSnVuZSAy MCwgMjAxMyAyOjE4IEFNDQpUbzogcGF3c0BpZXRmLm9yZw0KU3ViamVjdDogW3Bhd3NdIFdHTEMg b24gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1wYXdzLXByb3RvY29sLTA2 DQoNCg0KQWxsLA0KDQpUaGUgRWRpdG9yIG9mIHRoZSBkb2N1bWVudCBwb3N0ZWQgYSBuZXcgdmVy c2lvbiBhbmQgaW5kaWNhdGVkIHRoYXQgYWxsIG9wZW4gaXNzdWVzIHJhaXNlZCBvbiB0aGUgbGlz dCB3ZXJlIHJlc29sdmVkLCBhbmQgdGhhdCB0aGVyZSBhcmUgbm8gbW9yZSBvcGVuIGlzc3VlcyBo ZSBpcyBhd2FyZSBvZi4NClRoZXJlZm9yZSwgSSdkIGxpa2UgdG8gaXNzdWUgYSB3ZyBsYXN0IGNh bGwgb24gdGhlIGRvY3VtZW50LiBXZSBuZWVkIHJldmlld3MgYW5kIGZlZWRiYWNrIGluIG9yZGVy IHRvIGJlIGFibGUgdG8gcHJvZ3Jlc3MgdGhlIGRvY3VtZW50Lg0KDQpQbGVhc2UgcmVhZCB0aHJv dWdoIHRoZSBkcmFmdCBhbmQgc2VuZCBhbnkgY29tbWVudHMgeW91IG1heSBoYXZlIHRvIHRoZSBs aXN0IGluIHRoZSBuZXh0IDItMyB3ZWVrcy4NCklmIHlvdSByZXZpZXcgdGhlIGRyYWZ0IGFuZCBo YXZlIG5vIGNvbW1lbnRzLCBzZW5kIGEgbm90ZSB0byB0aGUgbGlzdCB0aGF0IHRoZSBkcmFmdCBp cyBnb29kIGFzIGl0IGlzLCB3ZSBuZWVkIHRoZXNlIG5vdGVzIGFzIG11Y2ggYXMgd2UgbmVlZCB0 aGUgYWN0dWFsIGNvbW1lbnRzLg0KDQpUaGFua3MsIEdhYm9yDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KcGF3cyBtYWlsaW5nIGxpc3QNCnBhd3NAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGF3cw0K