We're not dealing with business models in the = IETF. We are dealing in protocols and possibilities. Roaming re= lationships may exist, or they may not. Both have to work in the sens= e that I could build a device that worked in a variety of environments.

I don't wish to imply anything about a server's willi= ngness to provide service. I only want a way for a client to discover= a server that provides service where it is at the time it needs service.

As with my answer to Peter, I may have to provide a list of possib= le servers.

So there are a couple of inputs to discovery:

a) Location. This has to allow location as arbitrary lat/lon; yo= u may not know what country you are in. This is the device, not the h= uman. The human may know, the device may not. Some databases ma= y cover the entire country, others may cover a region. Sometimes location is known by a street address, and you can know wh= at country you are in.

b) Type of device. In every country, there are different classif= ications of devices that may depend on band, power, portability, antenna ch= aracteristics=85 So far, what we see is enumerated types per country,= but I could imagine more complex things. If the device doesn't know what country it is in, it may need to do discovery= in a couple of steps, the first of which identifies the country, and then = what type of device.

How does the Mobile client know the location? Do we assume GPS= ? What if it is inside the building?
We make no assumptions. It has location, either in lat/lon or= street address form. We don't care how it gets it. One way it = might is DHCP or HELD. This is the same problem we have with emergenc= y calls and those are two IETF solutions for that problem.

=

Discovery then is type and location in, device URI (not IP address I t= hink) out.

LoST (RFC5222) is ideal for this. You pass location and a "servi= ce urn" in, and you get a URI out. The service urn would contain the = type. It has a "forest guide" scheme that links LoST servers together= kind of like DNS without a root.

Brian

On Apr 17, 2012, at 5:26 PM, Das, Subir wrote:

During PAWS session in Paris IETF, there were a lot of questions/discussion= s on 'Discovery' of Database. It was not clear to me except if we are talki= ng about "Database Server Discovery", in particular, the domain name or the= IP address of the 'Server" that is hosting the database. OTH, I felt that some folks may have different vi= ews and they would possibly like to see more features than just discovering= the domain name or IP address of the "Database Server".

In some offline discussions, I was told that it may be similar to what LOST= (RFC 5222) has defined. I read the LOST protocol and associated architectu= re and my current understanding is that the LOST use case is different than= what we are trying to achieve via PAWS. Here is my understanding of the operating model of PAWS interface (w= hen defined):

-"Fixed/Mode II WSD" (per figure 1,<draft-das-paws-protocol-01>) can = only query the database

-The manufacturer of the "Fixed/Mode II WSD" may be different than owner/op= erator of this device

-"Fixed/Mode II WSD" is certified by the regulatory body of the region that= they serve

- Either the "Fixed/Mode II WSD" device operator or the device vendor has a= n a-priori relationship with one or more covering database administrators. = This relationship

is utilized to either configure or enable the discovery of the proper= database to contact in the current location

I would like to know the group's view of the above model. To me, finding th= e emergency services or restaurant information near my location is differen= t than getting to know a server that can provide me with channel/frequency/= power and other information in the location where "Fixed/Mode II WSD" is situated. In addition, emergency ser= vices do not require a subscription and the service is mandated by the Gove= rnment/regulatory bodies. Some may argue that 'White Space' service may be = free as well, but to my understanding it is not quite the similar model as emergency services.

I hope with this thread we can clarify/understand the discovery issue.=

Regards,

_Subir

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

= --_000_EACD1A86D6254866A02EBA2298FACB80neustarbiz_-- From Peter.McCann@huawei.com Wed Apr 18 07:39:40 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B2D21F85F0 for ; Wed, 18 Apr 2012 07:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISbKjkckDvcP for ; Wed, 18 Apr 2012 07:39:39 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id ABE7B21F85C7 for ; Wed, 18 Apr 2012 07:39:39 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA14489; Wed, 18 Apr 2012 10:39:39 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 07:37:36 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 07:37:33 -0700 From: Peter McCann To: "Rosen, Brian" , "Das, Subir" Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dZpeo3fIMQZpGRAyIo3z+FwWN1AACNazQ Date: Wed, 18 Apr 2012 14:37:33 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

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.157] 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] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 14:39:40 -0000 I agree with Brian that LoST could be a good model for discovering the appropriate database for the region you're in. A nation may decide to subdivide their territory into provinces or states, each of which maintains its own database. I think it would be a mistake to assume that there is a single,=20 pre-defined relationship for one device with just one database. In particular, I think there is a thorny issue that will arise with management of secure credentials on whitespace devices, illustrated by the first use case in Section 4.2.1 of draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use case says: 9. Once the master/AP has met all regulatory domain requirements (e.g. validating the Device ID with the trusted database, etc) the master provides the list of channels locally available to the slave/user device. My question is, what if the master device has a relationship with one database, but the slave device has a relationship with another? How is the master's database supposed to validate the credentials of the slave device, if we don't have some sort of common trust anchor? Or will this "validation" be simply an insecure check of an ID against a whitelist/blacklist? Who will allocate Device IDs? Will they be specific to a particular database operator, or do we need some common top-level allocation format? -Pete From brian.rosen@neustar.biz Wed Apr 18 07:42:21 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA6121F8484 for ; Wed, 18 Apr 2012 07:42:21 -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.277, 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 4xlaAnXd5V1r for ; Wed, 18 Apr 2012 07:42:17 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E7E7321F847D for ; Wed, 18 Apr 2012 07:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1334760160; x=1650110062; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=MDImQSUy1hKil/0WtDs+M NK7T+RgNCmTP5qYZJ6EFQ4=; b=ggcgY9kvms0P3gjy8WbE3am3AfBylg5WL+Est FMviEXl6ArtMdLuMOb4/NdRpqcgrsEW5zL8v8hXldeOwqZjUA== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.7498296; Wed, 18 Apr 2012 10:42:39 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 18 Apr 2012 10:42:01 -0400 From: "Rosen, Brian" To: Peter McCann Date: Wed, 18 Apr 2012 10:42:00 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dcWnUFjG5nJQJQtKVdi15xx2tig== Message-ID: References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: bR7yHh0yGI+ecSHClBJL9A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 14:42:21 -0000 Doesn't the slave get it's database access through the master? If that's true, the problem you are worried about doesn't exist. Brian On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: > I agree with Brian that LoST could be a good model for discovering > the appropriate database for the region you're in. A nation may > decide to subdivide their territory into provinces or states, each > of which maintains its own database. >=20 > I think it would be a mistake to assume that there is a single,=20 > pre-defined relationship for one device with just one database. > In particular, I think there is a thorny issue that will arise > with management of secure credentials on whitespace devices, > illustrated by the first use case in Section 4.2.1 of > draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of > that use case says: >=20 > 9. Once the master/AP has met all regulatory domain requirements > (e.g. validating the Device ID with the trusted database, etc) > the master provides the list of channels locally available to > the slave/user device. >=20 > My question is, what if the master device has a relationship with > one database, but the slave device has a relationship with another? > How is the master's database supposed to validate the credentials > of the slave device, if we don't have some sort of common trust > anchor? Or will this "validation" be simply an insecure check of > an ID against a whitelist/blacklist? Who will allocate Device IDs? > Will they be specific to a particular database operator, or do we > need some common top-level allocation format? >=20 > -Pete >=20 From Peter.McCann@huawei.com Wed Apr 18 07:54:35 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E61121F85D9 for ; Wed, 18 Apr 2012 07:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIoXcpMCXSu3 for ; Wed, 18 Apr 2012 07:54:35 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id E053E21F85D3 for ; Wed, 18 Apr 2012 07:54:34 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA15435; Wed, 18 Apr 2012 10:54:34 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 07:51:36 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 07:51:37 -0700 From: Peter McCann To: "Rosen, Brian" Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dZpeo3fIMQZpGRAyIo3z+FwWN1AACNazQAA8p2QAADmiScA== Date: Wed, 18 Apr 2012 14:51:37 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716456701@dfweml503-mbx> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> 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.157] 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] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 14:54:35 -0000 I think it would be a mistake to assume that the slave & master devices both have pre-existing relationships with the same database. In a commercial service, the slave devices would all come from different manufacturers and would certainly have different owners. Wouldn't we want them to interoperate with any master device, assuming they are RF-compatible? -Pete Rosen, Brian wrote: > Doesn't the slave get it's database access through the master? > If that's true, the problem you are worried about doesn't exist. >=20 > Brian >=20 > On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >=20 >> I agree with Brian that LoST could be a good model for discovering the >> appropriate database for the region you're in. A nation may decide to >> subdivide their territory into provinces or states, each of which >> maintains its own database. >>=20 >> I think it would be a mistake to assume that there is a single, >> pre-defined relationship for one device with just one database. In >> particular, I think there is a thorny issue that will arise with >> management of secure credentials on whitespace devices, illustrated by >> the first use case in Section 4.2.1 of >> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use >> case says: >>=20 >> 9. Once the master/AP has met all regulatory domain requirements >> (e.g. validating the Device ID with the trusted database, etc) >> the master provides the list of channels locally available to >> the slave/user device. >> My question is, what if the master device has a relationship with one >> database, but the slave device has a relationship with another? How is >> the master's database supposed to validate the credentials of the slave >> device, if we don't have some sort of common trust anchor? Or will this >> "validation" be simply an insecure check of an ID against a >> whitelist/blacklist? Who will allocate Device IDs? Will they be >> specific to a particular database operator, or do we need some common >> top-level allocation format? >>=20 >> -Pete >> From brian.rosen@neustar.biz Wed Apr 18 08:05:08 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A2321F8533 for ; Wed, 18 Apr 2012 08:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 zopigndbmqDE for ; Wed, 18 Apr 2012 08:05:04 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id E901721F85B5 for ; Wed, 18 Apr 2012 08:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1334761702; x=1650116182; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=EsM1hdk4SUejIQUVX4VPe XEC7rPDXjDjbTcVHFUx/6Q=; b=RiJstenCIGMNd1K1iESs6jSyu7ZhfZgQD9znI gZn88yeWsF12oYzad1n1psYTzwFGzIq77kAUrT/eJ9G+mgfxA== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.7938944; Wed, 18 Apr 2012 11:08:21 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 18 Apr 2012 11:04:51 -0400 From: "Rosen, Brian" Date: Wed, 18 Apr 2012 11:04:50 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0ddJpDQ2LCVJVwRqyYmgaczltjcA== Message-ID: <2AF1819D-90BE-4614-963F-019AAF92B4B5@neustar.biz> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> <5963DDF1F751474D8DEEFDCDBEE43AE716456701@dfweml503-mbx> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716456701@dfweml503-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: oIIJ0vSGRqPmDE0A2oyp8A== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Peter McCann Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 15:05:08 -0000 Perhaps I am confused, but I think in a master/slave environment, the slave= does not query the database, the master does. The slave gets its allowed = spectrum data from the master. There is always the question of whether the= master queries on its own behalf and the slaves just get assignments withi= n that database response, or whether the master queries on behalf of the sl= aves. Might have to support both models. In many cases, I think it's the = latter: the master queries using the slaves location and parameters. The most common master/slave setup is tower and clients, right? The tower = has an Internet connection and can query the database. The clients of the = tower are the slaves. Does the database query use the location and type da= ta of the slave or the master? =20 Brian On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: > I think it would be a mistake to assume that the slave & master > devices both have pre-existing relationships with the same database. > In a commercial service, the slave devices would all come from > different manufacturers and would certainly have different owners. > Wouldn't we want them to interoperate with any master device, assuming > they are RF-compatible? >=20 > -Pete >=20 > Rosen, Brian wrote: >> Doesn't the slave get it's database access through the master? >> If that's true, the problem you are worried about doesn't exist. >>=20 >> Brian >>=20 >> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>=20 >>> I agree with Brian that LoST could be a good model for discovering the >>> appropriate database for the region you're in. A nation may decide to >>> subdivide their territory into provinces or states, each of which >>> maintains its own database. >>>=20 >>> I think it would be a mistake to assume that there is a single, >>> pre-defined relationship for one device with just one database. In >>> particular, I think there is a thorny issue that will arise with >>> management of secure credentials on whitespace devices, illustrated by >>> the first use case in Section 4.2.1 of >>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use >>> case says: >>>=20 >>> 9. Once the master/AP has met all regulatory domain requirements >>> (e.g. validating the Device ID with the trusted database, etc) >>> the master provides the list of channels locally available to >>> the slave/user device. >>> My question is, what if the master device has a relationship with one >>> database, but the slave device has a relationship with another? How is >>> the master's database supposed to validate the credentials of the slave >>> device, if we don't have some sort of common trust anchor? Or will this >>> "validation" be simply an insecure check of an ID against a >>> whitelist/blacklist? Who will allocate Device IDs? Will they be >>> specific to a particular database operator, or do we need some common >>> top-level allocation format? >>>=20 >>> -Pete >>>=20 >=20 >=20 >=20 From d.joslyn@spectrumbridge.com Wed Apr 18 08:08:52 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAB221F85E5 for ; Wed, 18 Apr 2012 08:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1kdDS+ZI94t for ; Wed, 18 Apr 2012 08:08:48 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8763521F85D3 for ; Wed, 18 Apr 2012 08:08:48 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 18 Apr 2012 11:10:23 -0400 From: Don Joslyn To: "Rosen, Brian" , Peter McCann Date: Wed, 18 Apr 2012 11:10:21 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dcWnUFjG5nJQJQtKVdi15xx2tigAAxbYA Message-ID: <8375F6DAEFB09F48815203F1FE23B797113CB4F352@shelby> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 15:08:53 -0000 See response below... -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Wednesday, April 18, 2012 10:42 AM To: Peter McCann Cc: paws@ietf.org Subject: Re: [paws] Database Discovery Question Doesn't the slave get it's database access through the master? If that's true, the problem you are worried about doesn't exist. [Don - In the US, if the slave device is a personal/portable Mode I device,= the master device provides a channel list to the slave device, but the mas= ter device must validate the slave device (FCCID) first via the Whitespace = database.] Brian On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: > I agree with Brian that LoST could be a good model for discovering the=20 > appropriate database for the region you're in. A nation may decide to=20 > subdivide their territory into provinces or states, each of which=20 > maintains its own database. >=20 > I think it would be a mistake to assume that there is a single,=20 > pre-defined relationship for one device with just one database. > In particular, I think there is a thorny issue that will arise with=20 > management of secure credentials on whitespace devices, illustrated by=20 > the first use case in Section 4.2.1 of=20 > draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use=20 > case says: >=20 > 9. Once the master/AP has met all regulatory domain requirements > (e.g. validating the Device ID with the trusted database, etc) > the master provides the list of channels locally available to > the slave/user device. >=20 > My question is, what if the master device has a relationship with one=20 > database, but the slave device has a relationship with another? > How is the master's database supposed to validate the credentials of=20 > the slave device, if we don't have some sort of common trust anchor? =20 > Or will this "validation" be simply an insecure check of an ID against=20 > a whitelist/blacklist? Who will allocate Device IDs? > Will they be specific to a particular database operator, or do we need=20 > some common top-level allocation format? >=20 > -Pete >=20 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Wed Apr 18 08:13:55 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 252D221F85EF for ; Wed, 18 Apr 2012 08:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uu0ej7mh70vC for ; Wed, 18 Apr 2012 08:13:50 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id DF53521F859B for ; Wed, 18 Apr 2012 08:13:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1334762071; x=1650120865; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=2dHwj3nHov7xWLSXYKxu5 f+nsUux5JIDCrMYBJPhiIg=; b=QSqVS1kFr7O2YB5D2UBg3EzJlO7M5uPX3qtfV JFm9GAG6V9QmqTA5mRwDVQHAdgXdnYoajoxCfRzUS0/EB9Dag== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.6790688; Wed, 18 Apr 2012 11:14:30 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 18 Apr 2012 11:13:34 -0400 From: "Rosen, Brian" To: Don Joslyn Date: Wed, 18 Apr 2012 11:13:33 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dddIbILcOVtSKT1qsw7xMGdWMNg== Message-ID: <771245AD-8D5D-4548-8361-6142B0023CF1@neustar.biz> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> <8375F6DAEFB09F48815203F1FE23B797113CB4F352@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797113CB4F352@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: rXnvF8s9BbdttJt7hfq8mQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 15:13:55 -0000 Yes, an example of what I was talking about. The credentials to access the= database in this case are the master's. Brian On Apr 18, 2012, at 11:10 AM, Don Joslyn wrote: > See response below... >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of R= osen, Brian > Sent: Wednesday, April 18, 2012 10:42 AM > To: Peter McCann > Cc: paws@ietf.org > Subject: Re: [paws] Database Discovery Question >=20 > Doesn't the slave get it's database access through the master? > If that's true, the problem you are worried about doesn't exist. >=20 > [Don - In the US, if the slave device is a personal/portable Mode I devic= e, the master device provides a channel list to the slave device, but the m= aster device must validate the slave device (FCCID) first via the Whitespac= e database.] >=20 > Brian >=20 > On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >=20 >> I agree with Brian that LoST could be a good model for discovering the=20 >> appropriate database for the region you're in. A nation may decide to=20 >> subdivide their territory into provinces or states, each of which=20 >> maintains its own database. >>=20 >> I think it would be a mistake to assume that there is a single,=20 >> pre-defined relationship for one device with just one database. >> In particular, I think there is a thorny issue that will arise with=20 >> management of secure credentials on whitespace devices, illustrated by=20 >> the first use case in Section 4.2.1 of=20 >> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use=20 >> case says: >>=20 >> 9. Once the master/AP has met all regulatory domain requirements >> (e.g. validating the Device ID with the trusted database, etc) >> the master provides the list of channels locally available to >> the slave/user device. >>=20 >> My question is, what if the master device has a relationship with one=20 >> database, but the slave device has a relationship with another? >> How is the master's database supposed to validate the credentials of=20 >> the slave device, if we don't have some sort of common trust anchor? =20 >> Or will this "validation" be simply an insecure check of an ID against=20 >> a whitelist/blacklist? Who will allocate Device IDs? >> Will they be specific to a particular database operator, or do we need=20 >> some common top-level allocation format? >>=20 >> -Pete >>=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Wed Apr 18 08:19:14 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786E121F859F for ; Wed, 18 Apr 2012 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cv7ICCDNsmrE for ; Wed, 18 Apr 2012 08:19:13 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id AE88321F8533 for ; Wed, 18 Apr 2012 08:19:13 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA17096; Wed, 18 Apr 2012 11:19:13 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 08:16:56 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 08:16:51 -0700 From: Peter McCann To: "Rosen, Brian" Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dZpeo3fIMQZpGRAyIo3z+FwWN1AACNazQAA8p2QAADmiScP//kxwAgABy+6A= Date: Wed, 18 Apr 2012 15:16:50 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE71645674D@dfweml503-mbx> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> <5963DDF1F751474D8DEEFDCDBEE43AE716456701@dfweml503-mbx> <2AF1819D-90BE-4614-963F-019AAF92B4B5@neustar.biz> In-Reply-To: <2AF1819D-90BE-4614-963F-019AAF92B4B5@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.157] 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] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 15:19:14 -0000 Right, the master queries the database on behalf of the slave, sending the slave's Device ID and location. (See Don's message about validating the FCC ID). My question is, what is the security model for validating the slave's ID? Is there a secure credential associated with the ID, or is it an insecure check of a number against a whitelist? If the former, we will need a credential management system that is able to cross between different databases. If the latter, I wonder if it opens up security=20 problems. -Pete Rosen, Brian wrote: > Perhaps I am confused, but I think in a master/slave environment, the > slave does not query the database, the master does. The slave gets > its allowed spectrum data from the master. There is always the > question of whether the master queries on its own behalf and the > slaves just get assignments within that database response, or whether > the master queries on behalf of the slaves. Might have to support both m= odels. > In many cases, I think it's the latter: the master queries using the > slaves location and parameters. >=20 > The most common master/slave setup is tower and clients, right? The > tower has an Internet connection and can query the database. The > clients of the tower are the slaves. Does the database query use the > location and type data of the slave or the master? >=20 > Brian >=20 > On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: >=20 >> I think it would be a mistake to assume that the slave & master devices >> both have pre-existing relationships with the same database. In a >> commercial service, the slave devices would all come from different >> manufacturers and would certainly have different owners. Wouldn't we >> want them to interoperate with any master device, assuming they are >> RF-compatible? >>=20 >> -Pete >>=20 >> Rosen, Brian wrote: >>> Doesn't the slave get it's database access through the master? >>> If that's true, the problem you are worried about doesn't exist. >>>=20 >>> Brian >>>=20 >>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>>=20 >>>> I agree with Brian that LoST could be a good model for discovering >>>> the appropriate database for the region you're in. A nation may >>>> decide to subdivide their territory into provinces or states, each >>>> of which maintains its own database. >>>>=20 >>>> I think it would be a mistake to assume that there is a single, >>>> pre-defined relationship for one device with just one database. In >>>> particular, I think there is a thorny issue that will arise with >>>> management of secure credentials on whitespace devices, >>>> illustrated by the first use case in Section 4.2.1 of >>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that >>>> use case says: >>>>=20 >>>> 9. Once the master/AP has met all regulatory domain requirements >>>> (e.g. validating the Device ID with the trusted database, etc) >>>> the master provides the list of channels locally available to >>>> the slave/user device. >>>> My question is, what if the master device has a relationship with one >>>> database, but the slave device has a relationship with another? How >>>> is the master's database supposed to validate the credentials of the >>>> slave device, if we don't have some sort of common trust anchor? Or >>>> will this "validation" be simply an insecure check of an ID against a >>>> whitelist/blacklist? Who will allocate Device IDs? Will they be >>>> specific to a particular database operator, or do we need some common >>>> top-level allocation format? >>>>=20 >>>> -Pete >>>>=20 >>=20 >>=20 >> From sdas@appcomsci.com Wed Apr 18 08:24:47 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75ECF21F8603 for ; Wed, 18 Apr 2012 08:24:47 -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 tcZlt4A+QtBm for ; Wed, 18 Apr 2012 08:24:43 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id 41EB721F85B8 for ; Wed, 18 Apr 2012 08:24:42 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q3IFOgTd028486; Wed, 18 Apr 2012 11:24:42 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.research.telcordia.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q3IFOfa5004123; Wed, 18 Apr 2012 11:24:41 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 11:25:02 -0400 From: "Das, Subir" To: "'Rosen, Brian'" Thread-Topic: [paws] Database Discovery Question Thread-Index: AQHNHOLPA1P5CnAISk2CQekvF3iXjpaf2ms6gAD8DID//90hwA== Date: Wed, 18 Apr 2012 15:25:01 +0000 Message-ID: References: , <656D317F-8D11-4CA7-8B90-146A41372D20@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.109.16.87] Content-Type: multipart/alternative; boundary="_000_AAC987F0CC2C7845A9FBD8A36D52E12D8B0C8Arrcatsexmb1_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 15:24:47 -0000 --_000_AAC987F0CC2C7845A9FBD8A36D52E12D8B0C8Arrcatsexmb1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks and agree that we do not need to make assumptions here. In the LoST model who manages this service. I can understand for emergency= service example. From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Wednesday, April 18, 2012 9:25 AM To: Das, Subir Cc: paws@ietf.org Subject: Re: [paws] Database Discovery Question Inline On Apr 17, 2012, at 10:22 PM, Das, Subir wrote: On Apr 17, 2012, at 5:41 PM, "Rosen, Brian" > wrote: We recognize that there will be many databases, and the discovery problem i= s to find the right "one" where one is in quotes because there could be mor= e than one suitable database. Agree. When you say the right "one", how does the device know that in = the first place? Lots of possibilities, see my response to Peter. Some systems may not need discovery - some clients can be hardwired to a se= rver. Mobile clients probably can't do that if they can roam international= ly. When you say mobile client, are you considering "Fixed/Mode II WSD" or = "Slave/Mode I WSD" or both? A device may be built to work in several countries, each of which has it's = own type mechanism, or there will (hopefully) evolve a few common types. I= mean a device that can move and potentially operate in different places. = That includes "nomadic" devices; devices that are nominally fixed, but may = be tossed in a suitcase, taken on a trip, and set up wherever the owner goe= s. If it's legal to operate where it is, I want it to work. In case of "Fixed/Mode II WSD", what is the model? Can it roam without a= roaming relationship? Sure, why not? We're not dealing with business models in the IETF. We are dealing in prot= ocols and possibilities. Roaming relationships may exist, or they may not.= Both have to work in the sense that I could build a device that worked in= a variety of environments. I don't wish to imply anything about a server's willingness to provide serv= ice. I only want a way for a client to discover a server that provides ser= vice where it is at the time it needs service. As with my answer to Peter, I may have to provide a list of possible server= s. So there are a couple of inputs to discovery: a) Location. This has to allow location as arbitrary lat/lon; you may not = know what country you are in. This is the device, not the human. The huma= n may know, the device may not. Some databases may cover the entire countr= y, others may cover a region. Sometimes location is known by a street addr= ess, and you can know what country you are in. b) Type of device. In every country, there are different classifications o= f devices that may depend on band, power, portability, antenna characterist= ics... So far, what we see is enumerated types per country, but I could im= agine more complex things. If the device doesn't know what country it is i= n, it may need to do discovery in a couple of steps, the first of which ide= ntifies the country, and then what type of device. How does the Mobile client know the location? Do we assume GPS? What if = it is inside the building? We make no assumptions. It has location, either in lat/lon or street addre= ss form. We don't care how it gets it. One way it might is DHCP or HELD. = This is the same problem we have with emergency calls and those are two IE= TF solutions for that problem. Discovery then is type and location in, device URI (not IP address I think)= out. LoST (RFC5222) is ideal for this. You pass location and a "service urn" in= , and you get a URI out. The service urn would contain the type. It has a= "forest guide" scheme that links LoST servers together kind of like DNS wi= thout a root. Brian On Apr 17, 2012, at 5:26 PM, Das, Subir wrote: During PAWS session in Paris IETF, there were a lot of questions/discussion= s on 'Discovery' of Database. It was not clear to me except if we are talki= ng about "Database Server Discovery", in particular, the domain name or the= IP address of the 'Server" that is hosting the database. OTH, I felt that = some folks may have different views and they would possibly like to see mor= e features than just discovering the domain name or IP address of the "Data= base Server". In some offline discussions, I was told that it may be similar to what LOST= (RFC 5222) has defined. I read the LOST protocol and associated architectu= re and my current understanding is that the LOST use case is different than= what we are trying to achieve via PAWS. Here is my understanding of the op= erating model of PAWS interface (when defined): -"Fixed/Mode II WSD" (per figure 1,) can only q= uery the database -The manufacturer of the "Fixed/Mode II WSD" may be different than owner/op= erator of this device -"Fixed/Mode II WSD" is certified by the regulatory body of the region that= they serve - Either the "Fixed/Mode II WSD" device operator or the device vendor has a= n a-priori relationship with one or more covering database administrators. = This relationship is utilized to either configure or enable the discovery of the proper data= base to contact in the current location I would like to know the group's view of the above model. To me, finding th= e emergency services or restaurant information near my location is differen= t than getting to know a server that can provide me with channel/frequency/= power and other information in the location where "Fixed/Mode II WSD" is si= tuated. In addition, emergency services do not require a subscription and t= he service is mandated by the Government/regulatory bodies. Some may argue = that 'White Space' service may be free as well, but to my understanding it = is not quite the similar model as emergency services. I hope with this thread we can clarify/understand the discovery issue. Regards, _Subir _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws --_000_AAC987F0CC2C7845A9FBD8A36D52E12D8B0C8Arrcatsexmb1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks and agree that we = do not need to make assumptions here.

<= /p>

In the LoST model who man= ages this service. I can understand for emergency service example.

<= /p>

From: Rosen, B= rian [mailto:Brian.Rosen@neustar.biz]
Sent: Wednesday, April 18, 2012 9:25 AM
To: Das, Subir
Cc: paws@ietf.org
Subject: Re: [paws] Database Discovery Question

Inline

On Apr 17, 2012, at 10:22 PM, Das, Subir wrote:=

On Apr 17, 2012, at 5:41 PM, "Rosen, Brian" <Brian.Rosen@neustar.biz> wrote:=

We recognize that there will be many databases, and = the discovery problem is to find the right "one" where one is in = quotes because there could be more than one suitable database.

Agree. When you say the right "on= e", how does the device know that in the first place?

Lots of possibilities, see my response to Peter.

Some systems may not need discovery - some clients c= an be hardwired to a server. Mobile clients probably can't do that if= they can roam internationally.

When you say mobile client, are y= ou considering "Fixed/Mode II WSD" or "Slave/Mode I WSD"= ; or both?

A device may be built to work in several countries, = each of which has it's own type mechanism, or there will (hopefully) evolve= a few common types. I mean a device that can move and potentially op= erate in different places. That includes "nomadic" devices; devices that are nominally fixed, but may be = tossed in a suitcase, taken on a trip, and set up wherever the owner goes. = If it's legal to operate where it is, I want it to work.

In case of "Fixed/Mode II WSD"= ;, what is the model? Can it roam without a roaming relationship?

Sure, why not?

We're not dealing with business models in the IETF. = We are dealing in protocols and possibilities. Roaming relation= ships may exist, or they may not. Both have to work in the sense that= I could build a device that worked in a variety of environments.

I don't wish to imply anything about a server's will= ingness to provide service. I only want a way for a client to discove= r a server that provides service where it is at the time it needs service.<= o:p>

As with my answer to Peter, I may have to provide a = list of possible servers.

So there are a couple of inputs to discovery:

a) Location. This has to allow location as arb= itrary lat/lon; you may not know what country you are in. This is the= device, not the human. The human may know, the device may not. = ;Some databases may cover the entire country, others may cover a region. Sometimes location is known by a street address, and= you can know what country you are in.

b) Type of device. In every country, there are= different classifications of devices that may depend on band, power, porta= bility, antenna characteristics… So far, what we see is enumera= ted types per country, but I could imagine more complex things. If the device doesn't know what country it is in, it may nee= d to do discovery in a couple of steps, the first of which identifies the c= ountry, and then what type of device.

How does the Mobile client know the loc= ation? Do we assume GPS? What if it is inside the building?

We make no assumptions. It has location, eithe= r in lat/lon or street address form. We don't care how it gets it. &n= bsp;One way it might is DHCP or HELD. This is the same problem we hav= e with emergency calls and those are two IETF solutions for that problem.

Discovery then is type and location in, device URI (= not IP address I think) out.

LoST (RFC5222) is ideal for this. You pass loc= ation and a "service urn" in, and you get a URI out. The se= rvice urn would contain the type. It has a "forest guide" s= cheme that links LoST servers together kind of like DNS without a root.

Brian

On Apr 17, 2012, at 5:26 PM, Das, Subir wrote:<= /o:p>

During PAWS session in Paris IETF, there were a lot of questions/discussi= ons on 'Discovery' of Database. It was not clear to me except if we are tal= king about "Database Server Discovery", in particular, the domain name or the IP address of the 'Server" that= is hosting the database. OTH, I felt that some folks may have different vi= ews and they would possibly like to see more features than just discovering= the domain name or IP address of the "Database Server".

In some offline discussions, I was told that it may be similar to what LO= ST (RFC 5222) has defined. I read the LOST protocol and associated architec= ture and my current understanding is that the LOST use case is different than what we are trying to achieve via= PAWS. Here is my understanding of the operating model of PAWS interface (w= hen defined):

-"Fixed/Mode II WSD" (per figure 1,<draft-das-paws-protocol-= 01>) can only query the database

-The manufacturer of the "Fixed/Mode II WSD" may be different t= han owner/operator of this device

-"Fixed/Mode II WSD" is certified by the regulatory body of the= region that they serve

- Either the "Fixed/Mode II WSD" device operator or the device = vendor has an a-priori relationship with one or more covering database admi= nistrators. This relationship

is utilized to either configure or enable the discovery of the prop= er database to contact in the current location

I would like to know the group's view of the above model. To me, finding = the emergency services or restaurant information near my location is differ= ent than getting to know a server that can provide me with channel/frequency/power and other information in the l= ocation where "Fixed/Mode II WSD" is situated. In addition, emerg= ency services do not require a subscription and the service is mandated by = the Government/regulatory bodies. Some may argue that 'White Space' service may be free as well, but to my understand= ing it is not quite the similar model as emergency services.

I hope with this thread we can clarify/understand the discovery issue.

Regards,

_Subir

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

--_000_AAC987F0CC2C7845A9FBD8A36D52E12D8B0C8Arrcatsexmb1_-- From d.joslyn@spectrumbridge.com Wed Apr 18 08:27:09 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A18721F8459 for ; Wed, 18 Apr 2012 08:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWypavQ-v-TT for ; Wed, 18 Apr 2012 08:27:05 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5736621F847F for ; Wed, 18 Apr 2012 08:27:05 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 18 Apr 2012 11:28:41 -0400 From: Don Joslyn To: "Rosen, Brian" Date: Wed, 18 Apr 2012 11:28:39 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dddIbILcOVtSKT1qsw7xMGdWMNgAAOXfQ Message-ID: <8375F6DAEFB09F48815203F1FE23B797113CB4F35B@shelby> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> <8375F6DAEFB09F48815203F1FE23B797113CB4F352@shelby> <771245AD-8D5D-4548-8361-6142B0023CF1@neustar.biz> In-Reply-To: <771245AD-8D5D-4548-8361-6142B0023CF1@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 15:27:09 -0000 There are also examples where fixed devices are slaves to a master device, = and because they are fixed TVBDs, they must go directly to the database for= channel lists. In this case, the slaves need authentication to access the = database. In the previous case I mentioned, where a Personal/Portable Mode I gets its= channel list from the master, the master must first verify the FCCID of th= e Mode I device that is requesting a channel list. Since the Mode I device = does not directly access the database, it does not require authentication t= o directly access the database. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Wednesday, April 18, 2012 11:14 AM To: Don Joslyn Cc: Peter McCann; paws@ietf.org Subject: Re: [paws] Database Discovery Question Yes, an example of what I was talking about. The credentials to access the= database in this case are the master's. Brian On Apr 18, 2012, at 11:10 AM, Don Joslyn wrote: > See response below... >=20 > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 > Of Rosen, Brian > Sent: Wednesday, April 18, 2012 10:42 AM > To: Peter McCann > Cc: paws@ietf.org > Subject: Re: [paws] Database Discovery Question >=20 > Doesn't the slave get it's database access through the master? > If that's true, the problem you are worried about doesn't exist. >=20 > [Don - In the US, if the slave device is a personal/portable Mode I=20 > device, the master device provides a channel list to the slave device,=20 > but the master device must validate the slave device (FCCID) first via=20 > the Whitespace database.] >=20 > Brian >=20 > On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >=20 >> I agree with Brian that LoST could be a good model for discovering=20 >> the appropriate database for the region you're in. A nation may=20 >> decide to subdivide their territory into provinces or states, each of=20 >> which maintains its own database. >>=20 >> I think it would be a mistake to assume that there is a single,=20 >> pre-defined relationship for one device with just one database. >> In particular, I think there is a thorny issue that will arise with=20 >> management of secure credentials on whitespace devices, illustrated=20 >> by the first use case in Section 4.2.1 of=20 >> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use=20 >> case says: >>=20 >> 9. Once the master/AP has met all regulatory domain requirements >> (e.g. validating the Device ID with the trusted database, etc) >> the master provides the list of channels locally available to >> the slave/user device. >>=20 >> My question is, what if the master device has a relationship with one=20 >> database, but the slave device has a relationship with another? >> How is the master's database supposed to validate the credentials of=20 >> the slave device, if we don't have some sort of common trust anchor? >> Or will this "validation" be simply an insecure check of an ID=20 >> against a whitelist/blacklist? Who will allocate Device IDs? >> Will they be specific to a particular database operator, or do we=20 >> need some common top-level allocation format? >>=20 >> -Pete >>=20 >=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From brian.rosen@neustar.biz Wed Apr 18 08:27:48 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377CE21F8589 for ; Wed, 18 Apr 2012 08:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 F1EKTzmxQOJy for ; Wed, 18 Apr 2012 08:27:44 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id DB1E821F8541 for ; Wed, 18 Apr 2012 08:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1334762907; x=1650120865; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=x7+F5St+78M/lCV450Vgf V3R2MXAK7ZW5fPlXBoSCpo=; b=CPJzp7bpD3K84YG/t5lgNnG4QPiQR19EpaUow uSfesdFZvt3mjqClqY8UjGUI02wwV7nMbWpLZKqbeFclDMvlA== Received: from ([10.31.13.228]) by chihiron2.nc.neustar.com with ESMTP with TLS id J041123125.6791422; Wed, 18 Apr 2012 11:28:26 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Wed, 18 Apr 2012 11:27:31 -0400 From: "Rosen, Brian" To: Peter McCann Date: Wed, 18 Apr 2012 11:27:29 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dd8S0kCd0NZ+iShGIyw33WObrJQ== Message-ID: <82C1A88A-9FF1-47BB-B8B9-4D5173962379@neustar.biz> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> <5963DDF1F751474D8DEEFDCDBEE43AE716456701@dfweml503-mbx> <2AF1819D-90BE-4614-963F-019AAF92B4B5@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE71645674D@dfweml503-mbx> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE71645674D@dfweml503-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: s1pQeNDco8DLX8Olm6jFyQ== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 15:27:48 -0000 The credentialling system used between the database server and its client (= the master) are those of its client. The database trusts its client. The client (the master) may need its customer, the slave, to present creden= tials for service. This means we assume transitive trust on the ID information from the client= . The master validates the slave, the database validates the master. I wo= uld not advocate trying to make anything more complex. Brian On Apr 18, 2012, at 11:16 AM, Peter McCann wrote: > Right, the master queries the database on behalf of the slave, sending > the slave's Device ID and location. (See Don's message about validating > the FCC ID). My question is, what is the security model for validating > the slave's ID? Is there a secure credential associated with the ID, > or is it an insecure check of a number against a whitelist? If the forme= r, > we will need a credential management system that is able to cross between > different databases. If the latter, I wonder if it opens up security=20 > problems. >=20 > -Pete >=20 > Rosen, Brian wrote: >> Perhaps I am confused, but I think in a master/slave environment, the >> slave does not query the database, the master does. The slave gets >> its allowed spectrum data from the master. There is always the >> question of whether the master queries on its own behalf and the >> slaves just get assignments within that database response, or whether >> the master queries on behalf of the slaves. Might have to support both = models. >> In many cases, I think it's the latter: the master queries using the >> slaves location and parameters. >>=20 >> The most common master/slave setup is tower and clients, right? The >> tower has an Internet connection and can query the database. The >> clients of the tower are the slaves. Does the database query use the >> location and type data of the slave or the master? >>=20 >> Brian >>=20 >> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: >>=20 >>> I think it would be a mistake to assume that the slave & master devices >>> both have pre-existing relationships with the same database. In a >>> commercial service, the slave devices would all come from different >>> manufacturers and would certainly have different owners. Wouldn't we >>> want them to interoperate with any master device, assuming they are >>> RF-compatible? >>>=20 >>> -Pete >>>=20 >>> Rosen, Brian wrote: >>>> Doesn't the slave get it's database access through the master? >>>> If that's true, the problem you are worried about doesn't exist. >>>>=20 >>>> Brian >>>>=20 >>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>>>=20 >>>>> I agree with Brian that LoST could be a good model for discovering >>>>> the appropriate database for the region you're in. A nation may >>>>> decide to subdivide their territory into provinces or states, each >>>>> of which maintains its own database. >>>>>=20 >>>>> I think it would be a mistake to assume that there is a single, >>>>> pre-defined relationship for one device with just one database. In >>>>> particular, I think there is a thorny issue that will arise with >>>>> management of secure credentials on whitespace devices, >>>>> illustrated by the first use case in Section 4.2.1 of >>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that >>>>> use case says: >>>>>=20 >>>>> 9. Once the master/AP has met all regulatory domain requirements >>>>> (e.g. validating the Device ID with the trusted database, etc) >>>>> the master provides the list of channels locally available to >>>>> the slave/user device. >>>>> My question is, what if the master device has a relationship with one >>>>> database, but the slave device has a relationship with another? How >>>>> is the master's database supposed to validate the credentials of the >>>>> slave device, if we don't have some sort of common trust anchor? Or >>>>> will this "validation" be simply an insecure check of an ID against a >>>>> whitelist/blacklist? Who will allocate Device IDs? Will they be >>>>> specific to a particular database operator, or do we need some common >>>>> top-level allocation format? >>>>>=20 >>>>> -Pete >>>>>=20 >>>=20 >>>=20 >>>=20 >=20 >=20 >=20 From brian.rosen@neustar.biz Wed Apr 18 08:36:56 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2F921F85D9 for ; Wed, 18 Apr 2012 08:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=-0.138, 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 NtRppqRv9rTa for ; Wed, 18 Apr 2012 08:36:52 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id B6A4421F85B9 for ; Wed, 18 Apr 2012 08:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1334763603; x=1650116182; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=1WNIPydvAQJ+9q5iZbeZC MJ3m5xint2p4NlWLCyGbCY=; b=S5TjczluMqO8Y1RTnsf2dbHKpybJvNZhWsH5g V/nR8JICLbSyGIdIKBIAJkdTFGgaAzjlF2DUu0arch1FmzMNQ== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.7940985; Wed, 18 Apr 2012 11:40:02 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Wed, 18 Apr 2012 11:36:32 -0400 From: "Rosen, Brian" Date: Wed, 18 Apr 2012 11:36:31 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0deQd+29wYC60dR1+oo1TU+jWv9A== Message-ID: <58226550-F083-4C8E-AC29-21B0DBDB3DB1@neustar.biz> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> <8375F6DAEFB09F48815203F1FE23B797113CB4F352@shelby> <771245AD-8D5D-4548-8361-6142B0023CF1@neustar.biz> <8375F6DAEFB09F48815203F1FE23B797113CB4F35B@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797113CB4F35B@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: +J/otJ4rGEpjFCMYYLITYA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 To: Don Joslyn Cc: "paws@ietf.org" , Peter McCann Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 15:36:57 -0000 I'm never in favor of limiting options. If a slave has independent access = to the database, it can use its credentials and query. There isn't even an= assumption that the database the master uses has to be the same as the one= the slave uses. The master to slave protocol is out of scope, which is good, we don't have = to worry about issues where the slave gets a different answer than the mast= er, and thus some sort of negotiation has to happen. That could happen. T= he master could be far enough away from a protected entity that it wouldn't= be prohibited from using the channel the protected entity occupied, but th= e slave may be close enough that it could be blocked, even with different p= ower/antenna rules. Doesn't matter. If the slave directly accesses the database, it uses its own credentials to= do that. The master uses its own credentials for its access, and the data= bases could be the same or different. Brian On Apr 18, 2012, at 11:28 AM, Don Joslyn wrote: > There are also examples where fixed devices are slaves to a master device= , and because they are fixed TVBDs, they must go directly to the database f= or channel lists. In this case, the slaves need authentication to access th= e database. >=20 > In the previous case I mentioned, where a Personal/Portable Mode I gets i= ts channel list from the master, the master must first verify the FCCID of = the Mode I device that is requesting a channel list. Since the Mode I devic= e does not directly access the database, it does not require authentication= to directly access the database. >=20 > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 > Sent: Wednesday, April 18, 2012 11:14 AM > To: Don Joslyn > Cc: Peter McCann; paws@ietf.org > Subject: Re: [paws] Database Discovery Question >=20 > Yes, an example of what I was talking about. The credentials to access t= he database in this case are the master's. >=20 > Brian >=20 > On Apr 18, 2012, at 11:10 AM, Don Joslyn wrote: >=20 >> See response below... >>=20 >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf=20 >> Of Rosen, Brian >> Sent: Wednesday, April 18, 2012 10:42 AM >> To: Peter McCann >> Cc: paws@ietf.org >> Subject: Re: [paws] Database Discovery Question >>=20 >> Doesn't the slave get it's database access through the master? >> If that's true, the problem you are worried about doesn't exist. >>=20 >> [Don - In the US, if the slave device is a personal/portable Mode I=20 >> device, the master device provides a channel list to the slave device,=20 >> but the master device must validate the slave device (FCCID) first via=20 >> the Whitespace database.] >>=20 >> Brian >>=20 >> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>=20 >>> I agree with Brian that LoST could be a good model for discovering=20 >>> the appropriate database for the region you're in. A nation may=20 >>> decide to subdivide their territory into provinces or states, each of=20 >>> which maintains its own database. >>>=20 >>> I think it would be a mistake to assume that there is a single,=20 >>> pre-defined relationship for one device with just one database. >>> In particular, I think there is a thorny issue that will arise with=20 >>> management of secure credentials on whitespace devices, illustrated=20 >>> by the first use case in Section 4.2.1 of=20 >>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use=20 >>> case says: >>>=20 >>> 9. Once the master/AP has met all regulatory domain requirements >>> (e.g. validating the Device ID with the trusted database, etc) >>> the master provides the list of channels locally available to >>> the slave/user device. >>>=20 >>> My question is, what if the master device has a relationship with one=20 >>> database, but the slave device has a relationship with another? >>> How is the master's database supposed to validate the credentials of=20 >>> the slave device, if we don't have some sort of common trust anchor? >>> Or will this "validation" be simply an insecure check of an ID=20 >>> against a whitelist/blacklist? Who will allocate Device IDs? >>> Will they be specific to a particular database operator, or do we=20 >>> need some common top-level allocation format? >>>=20 >>> -Pete >>>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws >=20 From nbravin@earthlink.net Wed Apr 18 08:51:40 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FCF21F85C0 for ; Wed, 18 Apr 2012 08:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.091 X-Spam-Level: X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_50=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 Y3u4DYhFvwJp for ; Wed, 18 Apr 2012 08:51:39 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 89EE721F85B9 for ; Wed, 18 Apr 2012 08:51:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ZssfDOQgUcvo930jzvTOiKKMbTTG4MHc25d3OFTyKulCgRuvoCJq3XsbuYe0yVAP; h=Received:From:Content-Type:Content-Transfer-Encoding:Subject:Date:Message-Id:To:Mime-Version:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.2]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1SKXAQ-00011x-Vl for paws@ietf.org; Wed, 18 Apr 2012 11:51:39 -0400 From: Nancy Bravin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Apr 2012 08:51:37 -0700 Message-Id: <89B5D6CE-07F6-487E-9DA9-A6DF49E4B7ED@earthlink.net> To: paws@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86cd3fda77868210b5ad9c1a592a791535350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Subject: [paws] Here is what I think I am hearing X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 15:51:41 -0000 1. It is fine to have the ability to send messages and negotiate, but it = should not be a requirement. 2. Some of the issues being discussed are best managed and implemented = by the regulators, and owners of spectrum and that can vary greatly from = country to country. I am sure smarter people than I can put this into a sensible path if = what I think I am hearing is correct. SIncerely, Nancy From d.joslyn@spectrumbridge.com Wed Apr 18 09:03:14 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DADA21F85D5 for ; Wed, 18 Apr 2012 09:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lySb5QafzqxX for ; Wed, 18 Apr 2012 09:03:10 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 532FA21F85D9 for ; Wed, 18 Apr 2012 09:03:10 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 18 Apr 2012 12:04:46 -0400 From: Don Joslyn To: "Rosen, Brian" , Peter McCann Date: Wed, 18 Apr 2012 12:04:43 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0ddJpDQ2LCVJVwRqyYmgaczltjcAABHymg Message-ID: <8375F6DAEFB09F48815203F1FE23B797113CB4F362@shelby> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> <5963DDF1F751474D8DEEFDCDBEE43AE716456701@dfweml503-mbx> <2AF1819D-90BE-4614-963F-019AAF92B4B5@neustar.biz> In-Reply-To: <2AF1819D-90BE-4614-963F-019AAF92B4B5@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 16:03:14 -0000 Based on the PAWS definition of master versus slave, you are correct, the s= lave does not query the database. I think the confusion is that if you have a master device on a tower suppor= ting several fixed devices, the FCC considers them all as fixed TVBDs, whic= h means they are all master devices according to the PAWS definition. In th= e US, based on FCC rules, the only device type that qualifies as a PAWS sla= ve device is the Mode I personal/portable. -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Wednesday, April 18, 2012 11:05 AM To: Peter McCann Cc: paws@ietf.org Subject: Re: [paws] Database Discovery Question Perhaps I am confused, but I think in a master/slave environment, the slave= does not query the database, the master does. The slave gets its allowed = spectrum data from the master. There is always the question of whether the= master queries on its own behalf and the slaves just get assignments withi= n that database response, or whether the master queries on behalf of the sl= aves. Might have to support both models. In many cases, I think it's the = latter: the master queries using the slaves location and parameters. The most common master/slave setup is tower and clients, right? The tower = has an Internet connection and can query the database. The clients of the = tower are the slaves. Does the database query use the location and type da= ta of the slave or the master? =20 Brian On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: > I think it would be a mistake to assume that the slave & master=20 > devices both have pre-existing relationships with the same database. > In a commercial service, the slave devices would all come from=20 > different manufacturers and would certainly have different owners. > Wouldn't we want them to interoperate with any master device, assuming=20 > they are RF-compatible? >=20 > -Pete >=20 > Rosen, Brian wrote: >> Doesn't the slave get it's database access through the master? >> If that's true, the problem you are worried about doesn't exist. >>=20 >> Brian >>=20 >> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>=20 >>> I agree with Brian that LoST could be a good model for discovering=20 >>> the appropriate database for the region you're in. A nation may=20 >>> decide to subdivide their territory into provinces or states, each=20 >>> of which maintains its own database. >>>=20 >>> I think it would be a mistake to assume that there is a single,=20 >>> pre-defined relationship for one device with just one database. In=20 >>> particular, I think there is a thorny issue that will arise with=20 >>> management of secure credentials on whitespace devices, illustrated=20 >>> by the first use case in Section 4.2.1 of=20 >>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use=20 >>> case says: >>>=20 >>> 9. Once the master/AP has met all regulatory domain requirements >>> (e.g. validating the Device ID with the trusted database, etc) >>> the master provides the list of channels locally available to >>> the slave/user device. >>> My question is, what if the master device has a relationship with=20 >>> one database, but the slave device has a relationship with another?=20 >>> How is the master's database supposed to validate the credentials of=20 >>> the slave device, if we don't have some sort of common trust anchor?=20 >>> Or will this "validation" be simply an insecure check of an ID=20 >>> against a whitelist/blacklist? Who will allocate Device IDs? Will=20 >>> they be specific to a particular database operator, or do we need=20 >>> some common top-level allocation format? >>>=20 >>> -Pete >>>=20 >=20 >=20 >=20 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Wed Apr 18 09:05:09 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF0021F85DB for ; Wed, 18 Apr 2012 09:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5ogxX+ntKtF for ; Wed, 18 Apr 2012 09:05:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 316DF21F85D7 for ; Wed, 18 Apr 2012 09:05:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFA20409; Wed, 18 Apr 2012 12:05:08 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 09:02:26 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 09:02:20 -0700 From: Peter McCann To: "Rosen, Brian" Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dZpeo3fIMQZpGRAyIo3z+FwWN1AACNazQAA8p2QAADmiScP//kxwAgABy+6D//5NZgIAAcUcQ Date: Wed, 18 Apr 2012 16:02:20 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE7164567A4@dfweml503-mbx> References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> <5963DDF1F751474D8DEEFDCDBEE43AE716456701@dfweml503-mbx> <2AF1819D-90BE-4614-963F-019AAF92B4B5@neustar.biz> <5963DDF1F751474D8DEEFDCDBEE43AE71645674D@dfweml503-mbx> <82C1A88A-9FF1-47BB-B8B9-4D5173962379@neustar.biz> In-Reply-To: <82C1A88A-9FF1-47BB-B8B9-4D5173962379@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.157] 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] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 16:05:09 -0000 Hi, Brian, The problem is, the master device cannot be authoritative on whether the slave device is approved for use by the regulator. It must rely on the WSDB it uses (has a relationship with) to tell it. At the least, we need a format for device identifiers that can be understood by multiple independently operated databases. Maybe the WSDB trusts the master device to collect this information securely from the slave devices using slave-to-master credentials. Normally, the allocation authority for the identifier space would be a trust anchor for the identifier-to-device binding. I agree that the master-to-slave interface is out of scope, but there should be some mechanism in the marketplace for the master device operator to securely bind the identifier presented by the slave to the communication=20 channel with the slave device, in the sense that the master device is able to know in a secure way that the device it is talking to actually does own the regulator-assigned device identifier. It seems natural for the master device to rely on its relationship with a database to help with this binding. -Pete Rosen, Brian wrote: > this thread> The credentialling system used between the database > server and its client (the master) are those of its client. The > database trusts its client. >=20 > The client (the master) may need its customer, the slave, to present > credentials for service. >=20 > This means we assume transitive trust on the ID information from the > client. The master validates the slave, the database validates the > master. I would not advocate trying to make anything more complex. >=20 > Brian >=20 > On Apr 18, 2012, at 11:16 AM, Peter McCann wrote: >=20 >> Right, the master queries the database on behalf of the slave, sending >> the slave's Device ID and location. (See Don's message about >> validating the FCC ID). My question is, what is the security model for >> validating the slave's ID? Is there a secure credential associated >> with the ID, or is it an insecure check of a number against a >> whitelist? If the former, we will need a credential management system >> that is able to cross between different databases. If the latter, I >> wonder if it opens up security problems. >>=20 >> -Pete >>=20 >> Rosen, Brian wrote: >>> Perhaps I am confused, but I think in a master/slave environment, the >>> slave does not query the database, the master does. The slave gets >>> its allowed spectrum data from the master. There is always the >>> question of whether the master queries on its own behalf and the >>> slaves just get assignments within that database response, or whether >>> the master queries on behalf of the slaves. Might have to support >>> both models. In many cases, I think it's the latter: the master >>> queries using the slaves location and parameters. >>>=20 >>> The most common master/slave setup is tower and clients, right? The >>> tower has an Internet connection and can query the database. The >>> clients of the tower are the slaves. Does the database query use the >>> location and type data of the slave or the master? >>>=20 >>> Brian >>>=20 >>> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: >>>=20 >>>> I think it would be a mistake to assume that the slave & master >>>> devices both have pre-existing relationships with the same database. >>>> In a commercial service, the slave devices would all come from >>>> different manufacturers and would certainly have different owners. >>>> Wouldn't we want them to interoperate with any master device, >>>> assuming they are RF-compatible? >>>>=20 >>>> -Pete >>>>=20 >>>> Rosen, Brian wrote: >>>>> Doesn't the slave get it's database access through the master? >>>>> If that's true, the problem you are worried about doesn't exist. >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>>>>=20 >>>>>> I agree with Brian that LoST could be a good model for discovering >>>>>> the appropriate database for the region you're in. A nation may >>>>>> decide to subdivide their territory into provinces or states, each >>>>>> of which maintains its own database. >>>>>>=20 >>>>>> I think it would be a mistake to assume that there is a single, >>>>>> pre-defined relationship for one device with just one database. In >>>>>> particular, I think there is a thorny issue that will arise with >>>>>> management of secure credentials on whitespace devices, illustrated >>>>>> by the first use case in Section 4.2.1 of >>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use >>>>>> case says: >>>>>>=20 >>>>>> 9. Once the master/AP has met all regulatory domain > requirements >>>>>> (e.g. validating the Device ID with the trusted database, etc) >>>>>> the master provides the list of channels locally available to >>>>>> the slave/user device. >>>>>> My question is, what if the master device has a relationship with >>>>>> one database, but the slave device has a relationship with another? >>>>>> How is the master's database supposed to validate the credentials >>>>>> of the slave device, if we don't have some sort of common trust >>>>>> anchor? Or will this "validation" be simply an insecure check of an >>>>>> ID against a whitelist/blacklist? Who will allocate Device IDs? >>>>>> Will they be specific to a particular database operator, or do we >>>>>> need some common top-level allocation format? >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >> From sdas@appcomsci.com Wed Apr 18 09:15:37 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C958111E8081 for ; Wed, 18 Apr 2012 09:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5hYp1w0EZQ+O for ; Wed, 18 Apr 2012 09:15:34 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [205.132.0.196]) by ietfa.amsl.com (Postfix) with ESMTP id CCBA621F8552 for ; Wed, 18 Apr 2012 09:15:33 -0700 (PDT) Received: from bambi.research.telcordia.com (bambi.research.telcordia.com [192.4.5.54]) by thumper.research.telcordia.com (8.14.2/8.14.2) with ESMTP id q3IGFTQa001540; Wed, 18 Apr 2012 12:15:29 -0400 (EDT) Received: from rrc-ats-exhb1.ats.atsinnovate.com (exch.research.telcordia.com [192.4.5.63]) by bambi.research.telcordia.com (8.14.4/8.13.4) with ESMTP id q3IGFSTn005057; Wed, 18 Apr 2012 12:15:28 -0400 X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.97.3 at bambi Received: from rrc-ats-exmb1.ats.atsinnovate.com ([192.4.5.65]) by rrc-ats-exhb1.ats.atsinnovate.com ([2002:c004:53f::c004:53f]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 12:15:49 -0400 From: "Das, Subir" To: "'Don Joslyn'" , "Rosen, Brian" , Peter McCann Thread-Topic: [paws] Database Discovery Question Thread-Index: AQHNHOLPA1P5CnAISk2CQekvF3iXjpaf2ms6gAD8DICAABRlgIAAAT8AgAACsICAAAOxAIAAELuA//+/eAA= Date: Wed, 18 Apr 2012 16:15:48 +0000 Message-ID: References: , <656D317F-8D11-4CA7-8B90-146A41372D20@neustar.biz>

<5963DDF1F751474D8DEEFDCDBEE43AE7164566EA@dfweml503-mbx> <5963DDF1F751474D8DEEFDCDBEE43AE716456701@dfweml503-mbx> <2AF1819D-90BE-4614-963F-019AAF92B4B5@neustar.biz> <8375F6DAEFB09F48815203F1FE23B797113CB4F362@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797113CB4F362@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.16.87] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 16:15:37 -0000 Agree. -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don= Joslyn Sent: Wednesday, April 18, 2012 12:05 PM To: Rosen, Brian; Peter McCann Cc: paws@ietf.org Subject: Re: [paws] Database Discovery Question Based on the PAWS definition of master versus slave, you are correct, the s= lave does not query the database. I think the confusion is that if you have a master device on a tower suppor= ting several fixed devices, the FCC considers them all as fixed TVBDs, whic= h means they are all master devices according to the PAWS definition. In th= e US, based on FCC rules, the only device type that qualifies as a PAWS sla= ve device is the Mode I personal/portable. -----Original Message----- From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Ros= en, Brian Sent: Wednesday, April 18, 2012 11:05 AM To: Peter McCann Cc: paws@ietf.org Subject: Re: [paws] Database Discovery Question Perhaps I am confused, but I think in a master/slave environment, the slave= does not query the database, the master does. The slave gets its allowed = spectrum data from the master. There is always the question of whether the= master queries on its own behalf and the slaves just get assignments withi= n that database response, or whether the master queries on behalf of the sl= aves. Might have to support both models. In many cases, I think it's the = latter: the master queries using the slaves location and parameters. The most common master/slave setup is tower and clients, right? The tower = has an Internet connection and can query the database. The clients of the = tower are the slaves. Does the database query use the location and type da= ta of the slave or the master? =20 Brian On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: > I think it would be a mistake to assume that the slave & master=20 > devices both have pre-existing relationships with the same database. > In a commercial service, the slave devices would all come from=20 > different manufacturers and would certainly have different owners. > Wouldn't we want them to interoperate with any master device, assuming=20 > they are RF-compatible? >=20 > -Pete >=20 > Rosen, Brian wrote: >> Doesn't the slave get it's database access through the master? >> If that's true, the problem you are worried about doesn't exist. >>=20 >> Brian >>=20 >> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>=20 >>> I agree with Brian that LoST could be a good model for discovering=20 >>> the appropriate database for the region you're in. A nation may=20 >>> decide to subdivide their territory into provinces or states, each=20 >>> of which maintains its own database. >>>=20 >>> I think it would be a mistake to assume that there is a single,=20 >>> pre-defined relationship for one device with just one database. In=20 >>> particular, I think there is a thorny issue that will arise with=20 >>> management of secure credentials on whitespace devices, illustrated=20 >>> by the first use case in Section 4.2.1 of=20 >>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use=20 >>> case says: >>>=20 >>> 9. Once the master/AP has met all regulatory domain requirements >>> (e.g. validating the Device ID with the trusted database, etc) >>> the master provides the list of channels locally available to >>> the slave/user device. >>> My question is, what if the master device has a relationship with=20 >>> one database, but the slave device has a relationship with another? >>> How is the master's database supposed to validate the credentials of=20 >>> the slave device, if we don't have some sort of common trust anchor? >>> Or will this "validation" be simply an insecure check of an ID=20 >>> against a whitelist/blacklist? Who will allocate Device IDs? Will=20 >>> they be specific to a particular database operator, or do we need=20 >>> some common top-level allocation format? >>>=20 >>> -Pete >>>=20 >=20 >=20 >=20 _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list paws@ietf.org https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Wed Apr 18 10:25:58 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B10F11E8087 for ; Wed, 18 Apr 2012 10:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkfsxyASasXw for ; Wed, 18 Apr 2012 10:25:54 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id DC8B011E8083 for ; Wed, 18 Apr 2012 10:25:53 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Wed, 18 Apr 2012 13:27:29 -0400 From: Peter Stanforth To: Peter McCann , "Rosen, Brian" Date: Wed, 18 Apr 2012 13:25:45 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0diId+kCSAOb08T7yHPRyIunv6nQ== Message-ID: In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE7164567A4@dfweml503-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 17:25:58 -0000 Under current US rules a "Slave" or low power Personal/Portable client attempts to associate with a "master" which is a Fixed or Personal/Portable Mode 2 device. As a precursor to this association attempt the master has obtained a permitted channel list from a WSDB. The FCC rule requires the Master to identify the slave by FCC-ID and query the WSDB to determine if it is allowed to provide access/service to this device (FCC-ID). The rules don't preclude the master from remembering this information so it does not have to ask again if it has cached the response from the WSDB. So from a protocol perspective, which is what I believe PAWS is about, there needs to be a mechanism to support this kind of capability. How the master gets the information from the slave or how it maintains or verifies it is not, I believe, within the PAWS scope. Under the same US rules a "slave" that is a High Power Fixed device (Typically found in a wide area point to point or point to multipoint solution) the slave has to both register with the WSDB and request a channel list. The rule explicitly allows the slave, in this case, to use the channel that the master is operating on to query the WSDB. If the returned channel list does not include the channel the master is currently operating on then the slave cannot use it and the master/slave have to figure out some alternative (no rule to define what or how that happens). As a US WSDB operator. We never see a low power personal portable slave, other than the query from it's master). We treat a high power fixed slave in exactly the same way as a high power fixed master. On WedApr/18/12 Wed Apr 18, 12:02 PM, "Peter McCann" wrote: >Hi, Brian, > >The problem is, the master device cannot be authoritative on whether >the slave device is approved for use by the regulator. It must rely >on the WSDB it uses (has a relationship with) to tell it. > >At the least, we need a format for device identifiers that can be >understood by multiple independently operated databases. Maybe the >WSDB trusts the master device to collect this information securely >from the slave devices using slave-to-master credentials. Normally, >the allocation authority for the identifier space would be a trust >anchor for the identifier-to-device binding. I agree that the >master-to-slave interface is out of scope, but there should be some >mechanism in the marketplace for the master device operator to >securely bind the identifier presented by the slave to the communication >channel with the slave device, in the sense that the master device >is able to know in a secure way that the device it is talking to actually >does own the regulator-assigned device identifier. It seems natural >for the master device to rely on its relationship with a database to >help with this binding. > >-Pete > >Rosen, Brian wrote: >> > this thread> The credentialling system used between the database >> server and its client (the master) are those of its client. The >> database trusts its client. >>=20 >> The client (the master) may need its customer, the slave, to present >> credentials for service. >>=20 >> This means we assume transitive trust on the ID information from the >> client. The master validates the slave, the database validates the >> master. I would not advocate trying to make anything more complex. >>=20 >> Brian >>=20 >> On Apr 18, 2012, at 11:16 AM, Peter McCann wrote: >>=20 >>> Right, the master queries the database on behalf of the slave, sending >>> the slave's Device ID and location. (See Don's message about >>> validating the FCC ID). My question is, what is the security model for >>> validating the slave's ID? Is there a secure credential associated >>> with the ID, or is it an insecure check of a number against a >>> whitelist? If the former, we will need a credential management system >>> that is able to cross between different databases. If the latter, I >>> wonder if it opens up security problems. >>>=20 >>> -Pete >>>=20 >>> Rosen, Brian wrote: >>>> Perhaps I am confused, but I think in a master/slave environment, the >>>> slave does not query the database, the master does. The slave gets >>>> its allowed spectrum data from the master. There is always the >>>> question of whether the master queries on its own behalf and the >>>> slaves just get assignments within that database response, or whether >>>> the master queries on behalf of the slaves. Might have to support >>>> both models. In many cases, I think it's the latter: the master >>>> queries using the slaves location and parameters. >>>>=20 >>>> The most common master/slave setup is tower and clients, right? The >>>> tower has an Internet connection and can query the database. The >>>> clients of the tower are the slaves. Does the database query use the >>>> location and type data of the slave or the master? >>>>=20 >>>> Brian >>>>=20 >>>> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: >>>>=20 >>>>> I think it would be a mistake to assume that the slave & master >>>>> devices both have pre-existing relationships with the same database. >>>>> In a commercial service, the slave devices would all come from >>>>> different manufacturers and would certainly have different owners. >>>>> Wouldn't we want them to interoperate with any master device, >>>>> assuming they are RF-compatible? >>>>>=20 >>>>> -Pete >>>>>=20 >>>>> Rosen, Brian wrote: >>>>>> Doesn't the slave get it's database access through the master? >>>>>> If that's true, the problem you are worried about doesn't exist. >>>>>>=20 >>>>>> Brian >>>>>>=20 >>>>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>>>>>=20 >>>>>>> I agree with Brian that LoST could be a good model for discovering >>>>>>> the appropriate database for the region you're in. A nation may >>>>>>> decide to subdivide their territory into provinces or states, each >>>>>>> of which maintains its own database. >>>>>>>=20 >>>>>>> I think it would be a mistake to assume that there is a single, >>>>>>> pre-defined relationship for one device with just one database. In >>>>>>> particular, I think there is a thorny issue that will arise with >>>>>>> management of secure credentials on whitespace devices, illustrated >>>>>>> by the first use case in Section 4.2.1 of >>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that use >>>>>>> case says: >>>>>>>=20 >>>>>>> 9. Once the master/AP has met all regulatory domain >> requirements >>>>>>> (e.g. validating the Device ID with the trusted database, etc) >>>>>>> the master provides the list of channels locally available to >>>>>>> the slave/user device. >>>>>>> My question is, what if the master device has a relationship with >>>>>>> one database, but the slave device has a relationship with another? >>>>>>> How is the master's database supposed to validate the credentials >>>>>>> of the slave device, if we don't have some sort of common trust >>>>>>> anchor? Or will this "validation" be simply an insecure check of an >>>>>>> ID against a whitelist/blacklist? Who will allocate Device IDs? >>>>>>> Will they be specific to a particular database operator, or do we >>>>>>> need some common top-level allocation format? >>>>>>>=20 >>>>>>> -Pete >>>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>=20 >>>=20 >>> > > > >_______________________________________________ >paws mailing list >paws@ietf.org >https://www.ietf.org/mailman/listinfo/paws From Peter.McCann@huawei.com Wed Apr 18 11:26:54 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1884E11E808E for ; Wed, 18 Apr 2012 11:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTl59viRFtKs for ; Wed, 18 Apr 2012 11:26:49 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id C1C4E21F84BD for ; Wed, 18 Apr 2012 11:26:49 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFI30705; Wed, 18 Apr 2012 14:26:49 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 18 Apr 2012 11:24:07 -0700 Received: from DFWEML503-MBX.china.huawei.com ([10.124.31.29]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0323.003; Wed, 18 Apr 2012 11:23:07 -0700 From: Peter McCann To: Peter Stanforth , "Rosen, Brian" Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0dZpeo3fIMQZpGRAyIo3z+FwWN1AACNazQAA8p2QAADmiScP//kxwAgABy+6D//5NZgIAAcUcQ//+vxICAAGbWAA== Date: Wed, 18 Apr 2012 18:24:04 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE71645683C@dfweml503-mbx> References: <5963DDF1F751474D8DEEFDCDBEE43AE7164567A4@dfweml503-mbx> 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.157] 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] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Apr 2012 18:26:54 -0000 Hi, Peter, In part, you write: ... > The FCC rule requires the Master to identify the slave by FCC-ID and > query the WSDB to determine if it is allowed to provide access/service > to this device (FCC-ID). ... > How the master gets the information > from the slave or how it maintains or verifies it is not, I believe, > within the PAWS scope. You seem to agree, though, that we must have some representation of the slave's FCC ID on the PAWS interface, and that the database must be able to give an answer (yes/no) about a particular FCC ID. Correct? This seems to imply some sort of relationship between the slave device and the database. If we want a slave device (with a different vendor/ owner/database from the master device) to interoperate with any master device, it would seem that any database would need to be capable of responding yes/no with respect to any particular slave FCC ID. Will there be a global whitelist of all un-revoked FCC IDs? Or am I=20 mistaken, and is FCC ID more akin to a model number than a serial number? -Pete Peter Stanforth wrote: > Under current US rules a "Slave" or low power Personal/Portable client > attempts to associate with a "master" which is a Fixed or > Personal/Portable Mode 2 device. As a precursor to this association > attempt the master has obtained a permitted channel list from a WSDB. > The FCC rule requires the Master to identify the slave by FCC-ID and > query the WSDB to determine if it is allowed to provide access/service > to this device (FCC-ID). The rules don't preclude the master from > remembering this information so it does not have to ask again if it has > cached the response from the WSDB. So from a protocol perspective, which > is what I believe PAWS is about, there needs to be a mechanism to > support this kind of capability. How the master gets the information > from the slave or how it maintains or verifies it is not, I believe, > within the PAWS scope. Under the same US rules a "slave" that is a High > Power Fixed device (Typically found in a wide area point to point or > point to multipoint solution) the slave has to both register with the > WSDB and request a channel list. The rule explicitly allows the slave, > in this case, to use the channel that the master is operating on to > query the WSDB. If the returned channel list does not include the > channel the master is currently operating on then the slave cannot use > it and the master/slave have to figure out some alternative (no rule to > define what or how that happens). As a US WSDB operator. We never see a > low power personal portable slave, other than the query from it's > master). We treat a high power fixed slave in exactly the same way as a > high power fixed master. >=20 > On WedApr/18/12 Wed Apr 18, 12:02 PM, "Peter McCann" > wrote: >=20 >> Hi, Brian, >>=20 >> The problem is, the master device cannot be authoritative on whether >> the slave device is approved for use by the regulator. It must rely >> on the WSDB it uses (has a relationship with) to tell it. >>=20 >> At the least, we need a format for device identifiers that can be >> understood by multiple independently operated databases. Maybe the >> WSDB trusts the master device to collect this information securely from >> the slave devices using slave-to-master credentials. Normally, the >> allocation authority for the identifier space would be a trust anchor >> for the identifier-to-device binding. I agree that the master-to-slave >> interface is out of scope, but there should be some mechanism in the >> marketplace for the master device operator to securely bind the >> identifier presented by the slave to the communication channel with the >> slave device, in the sense that the master device is able to know in a >> secure way that the device it is talking to actually does own the >> regulator-assigned device identifier. It seems natural for the master >> device to rely on its relationship with a database to help with this >> binding. >>=20 >> -Pete >>=20 >> Rosen, Brian wrote: >>> >> this thread> The credentialling system used between the database >>> server and its client (the master) are those of its client. The >>> database trusts its client. >>>=20 >>> The client (the master) may need its customer, the slave, to present >>> credentials for service. >>>=20 >>> This means we assume transitive trust on the ID information from the >>> client. The master validates the slave, the database validates the >>> master. I would not advocate trying to make anything more complex. >>>=20 >>> Brian >>>=20 >>> On Apr 18, 2012, at 11:16 AM, Peter McCann wrote: >>>=20 >>>> Right, the master queries the database on behalf of the slave, >>>> sending the slave's Device ID and location. (See Don's message about >>>> validating the FCC ID). My question is, what is the security model >>>> for validating the slave's ID? Is there a secure credential >>>> associated with the ID, or is it an insecure check of a number >>>> against a whitelist? If the former, we will need a credential >>>> management system that is able to cross between different databases.=20 >>>> If the latter, I wonder if it opens up security problems. >>>>=20 >>>> -Pete >>>>=20 >>>> Rosen, Brian wrote: >>>>> Perhaps I am confused, but I think in a master/slave environment, >>>>> the slave does not query the database, the master does. The slave >>>>> gets its allowed spectrum data from the master. There is always the >>>>> question of whether the master queries on its own behalf and the >>>>> slaves just get assignments within that database response, or >>>>> whether the master queries on behalf of the slaves. Might have to >>>>> support both models. In many cases, I think it's the latter: the >>>>> master queries using the slaves location and parameters. >>>>>=20 >>>>> The most common master/slave setup is tower and clients, right? The >>>>> tower has an Internet connection and can query the database. The >>>>> clients of the tower are the slaves. Does the database query use >>>>> the location and type data of the slave or the master? >>>>>=20 >>>>> Brian >>>>>=20 >>>>> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: >>>>>=20 >>>>>> I think it would be a mistake to assume that the slave & master >>>>>> devices both have pre-existing relationships with the same >>>>>> database. In a commercial service, the slave devices would all come >>>>>> from different manufacturers and would certainly have different >>>>>> owners. Wouldn't we want them to interoperate with any master >>>>>> device, assuming they are RF-compatible? >>>>>>=20 >>>>>> -Pete >>>>>>=20 >>>>>> Rosen, Brian wrote: >>>>>>> Doesn't the slave get it's database access through the master? >>>>>>> If that's true, the problem you are worried about doesn't exist. >>>>>>>=20 >>>>>>> Brian >>>>>>>=20 >>>>>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>>>>>>=20 >>>>>>>> I agree with Brian that LoST could be a good model for >>>>>>>> discovering the appropriate database for the region you're in. A >>>>>>>> nation may decide to subdivide their territory into provinces or >>>>>>>> states, each of which maintains its own database. >>>>>>>>=20 >>>>>>>> I think it would be a mistake to assume that there is a single, >>>>>>>> pre-defined relationship for one device with just one database. >>>>>>>> In particular, I think there is a thorny issue that will arise >>>>>>>> with management of secure credentials on whitespace devices, >>>>>>>> illustrated by the first use case in Section 4.2.1 of >>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that >>>>>>>> use case says: >>>>>>>>=20 >>>>>>>> 9. Once the master/AP has met all regulatory domain >>> requirements >>>>>>>> (e.g. validating the Device ID with the trusted database, >>>>>>>> etc) the master provides the list of channels locally >>>>>>>> available to the slave/user device. >>>>>>>> My question is, what if the master device has a relationship with >>>>>>>> one database, but the slave device has a relationship with >>>>>>>> another? How is the master's database supposed to validate the >>>>>>>> credentials of the slave device, if we don't have some sort of >>>>>>>> common trust anchor? Or will this "validation" be simply an >>>>>>>> insecure check of an ID against a whitelist/blacklist? Who will >>>>>>>> allocate Device IDs? Will they be specific to a particular >>>>>>>> database operator, or do we need some common top-level allocation >>>>>>>> format? >>>>>>>>=20 >>>>>>>> -Pete >>>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> paws mailing list >> paws@ietf.org >> https://www.ietf.org/mailman/listinfo/paws From d.joslyn@spectrumbridge.com Thu Apr 19 10:29:27 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F1921F86C4 for ; Thu, 19 Apr 2012 10:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXjs5sLFhmeS for ; Thu, 19 Apr 2012 10:29:26 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 55FEF21F86B6 for ; Thu, 19 Apr 2012 10:29:23 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Thu, 19 Apr 2012 13:31:00 -0400 From: Don Joslyn To: "Das, Subir" , "paws@ietf.org" Date: Thu, 19 Apr 2012 13:30:58 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0c4K8PQNA9Co7UTfGQzW7Gue+uSwBcXadg Message-ID: <8375F6DAEFB09F48815203F1FE23B797113CB4F3CF@shelby> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8375F6DAEFB09F48815203F1FE23B797113CB4F3CFshelby_" MIME-Version: 1.0 Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 Apr 2012 17:29:27 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797113CB4F3CFshelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't think PAWS should define discovery, I think the protocol should sim= ply start after a device has "found" the correct database to use. I feel this way for many reasons: 1) In the US, a radio is certified to work with one or more specific databa= ses. So the device will be pre-configured to contact specific databases, no= need to implement a discovery service. If the device is programmed to work= with more than one database provider, the device owner will configure whic= h one to use based on the relationship that they have established with the = database provider (for example, which one they are paying to use). 2) Discovery services like LoST are based on location, but the device's rel= ationship with a database service is not known or considered. While it may = seem simple to configure LoST or similar service to point to a database ser= vice based on location, how do you point to the one that the customer has a= relationship with, for example, paid to use? I do realize that this may no= t be an issue in every country. 3) If PAWS defines a globally applicable discovery process and either picks= an existing protocol (like LoST) or designs one, most likely it would incl= ude a centrally based discovery service. What entity will be responsible fo= r hosting and configuring the central discovery service? How will PAWS defi= ne this as a global solution, and deal with the politics between countries? 4) Some radio manufacturers do not have very much ROM to include even more = code on their device. I'm concerned that discovery will consume even more s= pace on the radio, space that they may not even have. 5) I believe that defining discovery will take more time than defining the = protocol between the WSDB and WSD. I think that database discovery should be left to each country to define ba= sed on their own requirements and Whitespace ecosystem. Regards, Don From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Das= , Subir Sent: Tuesday, April 17, 2012 5:26 PM To: paws@ietf.org Subject: [paws] Database Discovery Question During PAWS session in Paris IETF, there were a lot of questions/discussion= s on 'Discovery' of Database. It was not clear to me except if we are talki= ng about "Database Server Discovery", in particular, the domain name or the= IP address of the 'Server" that is hosting the database. OTH, I felt that = some folks may have different views and they would possibly like to see mor= e features than just discovering the domain name or IP address of the "Data= base Server". In some offline discussions, I was told that it may be similar to what LOST= (RFC 5222) has defined. I read the LOST protocol and associated architectu= re and my current understanding is that the LOST use case is different than= what we are trying to achieve via PAWS. Here is my understanding of the op= erating model of PAWS interface (when defined): -"Fixed/Mode II WSD" (per figure 1,) can only q= uery the database -The manufacturer of the "Fixed/Mode II WSD" may be different than owner/op= erator of this device -"Fixed/Mode II WSD" is certified by the regulatory body of the region that= they serve - Either the "Fixed/Mode II WSD" device operator or the device vendor has a= n a-priori relationship with one or more covering database administrators. = This relationship is utilized to either configure or enable the discovery of the proper data= base to contact in the current location I would like to know the group's view of the above model. To me, finding th= e emergency services or restaurant information near my location is differen= t than getting to know a server that can provide me with channel/frequency/= power and other information in the location where "Fixed/Mode II WSD" is si= tuated. In addition, emergency services do not require a subscription and t= he service is mandated by the Government/regulatory bodies. Some may argue = that 'White Space' service may be free as well, but to my understanding it = is not quite the similar model as emergency services. I hope with this thread we can clarify/understand the discovery issue. Regards, _Subir --_000_8375F6DAEFB09F48815203F1FE23B797113CB4F3CFshelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don't think= PAWS should define discovery, I think the protocol should simply start aft= er a device has "found" the correct database to use.

I fe= el this way for many reasons:

1) In t= he US, a radio is certified to work with one or more specific databases. So= the device will be pre-configured to contact specific databases, no need t= o implement a discovery service. If the device is programmed to work with m= ore than one database provider, the device owner will configure which one t= o use based on the relationship that they have established with the databas= e provider (for example, which one they are paying to use).

<= p class=3DMsoPlainText>2) Discovery services like LoST are based on locatio= n, but the device's relationship with a database service is not known or co= nsidered. While it may seem simple to configure LoST or similar service to = point to a database service based on location, how do you point to the one = that the customer has a relationship with, for example, paid to use? I do r= ealize that this may not be an issue in every country.

3) If PAWS defines a globally applicable discovery proces= s and either picks an existing protocol (like LoST) or designs one, most li= kely it would include a centrally based discovery service. What entity will= be responsible for hosting and configuring the central discovery service? = How will PAWS define this as a global solution, and deal with the politics = between countries?

4) Some radio manu= facturers do not have very much ROM to include even more code on their devi= ce. I'm concerned that discovery will consume even more space on the radio,= space that they may not even have.

5= ) I believe that defining discovery will take more time than defining the p= rotocol between the WSDB and WSD.

I think that database discovery s= hould be left to each country to define based on their own requirements and= Whitespace ecosystem.

Regards,

Don

From:= paws-bo= unces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Das, Subi= r
Sent: Tuesday, April 17, 2012 5:26 PM
To: paws@ietf.o= rg
Subject: [paws] Database Discovery Question<= /p>

During PAWS session in Paris IETF, there were a lot of questions/disc= ussions on 'Discovery' of Database. It was not clear to me except if we are= talking about "Database Server Discovery", in particular, the do= main name or the IP address of the 'Server" that is hosting the databa= se. OTH, I felt that some folks may have different views and they would pos= sibly like to see more features than just discovering the domain name or IP= address of the "Database Server".

In some offline discus= sions, I was told that it may be similar to what LOST (RFC 5222) has define= d. I read the LOST protocol and associated architecture and my current unde= rstanding is that the LOST use case is different than what we are trying to= achieve via PAWS. Here is my understanding of the operating model of PAWS = interface (when defined):

-"Fixed/Mode II WSD" (per figur= e 1,<draft-das-paws-protocol-01>) can only query the database

-The manufacturer of the "Fixed/Mode II WSD" may be different th= an owner/operator of this device

-"Fixed/Mode II WSD" is = certified by the regulatory body of the region that they serve

- Ei= ther the "Fixed/Mode II WSD" device operator or the device vendor= has an a-priori relationship with one or more covering database administra= tors. This relationship

is util= ized to either configure or enable the discovery of the proper database to = contact in the current location

I would like to know the group's view of the above model. To me, = finding the emergency services or restaurant information near my location i= s different than getting to know a server that can provide me with channel/= frequency/power and other information in the location where "Fixed/Mod= e II WSD" is situated. In addition, emergency services do not require = a subscription and the service is mandated by the Government/regulatory bod= ies. Some may argue that 'White Space' service may be free as well, but to = my understanding it is not quite the similar model as emergency services.

I hope with this thread= we can clarify/understand the discovery issue.

Regards,

_= Subir

= --_000_8375F6DAEFB09F48815203F1FE23B797113CB4F3CFshelby_-- From brian.rosen@neustar.biz Thu Apr 19 11:00:46 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973EA21F85BB for ; Thu, 19 Apr 2012 11:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.961 X-Spam-Level: X-Spam-Status: No, score=-4.961 tagged_above=-999 required=5 tests=[AWL=-1.330, BAYES_40=-0.185, 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 n3LGZhQAOsrc for ; Thu, 19 Apr 2012 11:00:45 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 224F021F85AC for ; Thu, 19 Apr 2012 11:00:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1334858553; x=1650212784; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=u6Ubf6ZAMwmjUR7OwXiEAvsbmDB1ZTbWGY1JKfhy5J4=; b=lBqPsiFtUDKqp0x1Sm+0Py/Qxtoc1hpzf2mOJbPoEG5NtAJsnSfQsVttIATNPn HqTwP9PEcfDL7unrW2+PZ59A== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.7501403; Thu, 19 Apr 2012 14:02:31 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Thu, 19 Apr 2012 14:00:32 -0400 From: "Rosen, Brian" To: Don Joslyn Date: Thu, 19 Apr 2012 14:00:31 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0eVlAHnfNO/fmIT5C7+jeZABegjQ== Message-ID: <77CCA903-E18E-4FDB-BCE5-C2B2AD8ACA7A@neustar.biz> References: <8375F6DAEFB09F48815203F1FE23B797113CB4F3CF@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797113CB4F3CF@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: VYrBwx4ys5Ppj5yHRY/T7A== Content-Type: multipart/alternative; boundary="_000_77CCA903E18E4FDBBCE5C2B2AD8ACA7Aneustarbiz_" MIME-Version: 1.0 Cc: "paws@ietf.org" Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 19 Apr 2012 18:00:46 -0000 --_000_77CCA903E18E4FDBBCE5C2B2AD8ACA7Aneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I disagree. While local regulation could limit capability for discovery, in general, I = would like to be able to build devices that find databases based on locatio= n and type of device. It may be, as in say GSM cell phones, that discovery presents a list of pos= sibilities, and specific choices get based on things like roaming relations= hips, but to make that work requires standardization. See inline for comments On Apr 19, 2012, at 1:30 PM, Don Joslyn wrote: I don't think PAWS should define discovery, I think the protocol should sim= ply start after a device has "found" the correct database to use. I feel this way for many reasons: 1) In the US, a radio is certified to work with one or more specific databa= ses. So the device will be pre-configured to contact specific databases, no= need to implement a discovery service. If the device is programmed to work= with more than one database provider, the device owner will configure whic= h one to use based on the relationship that they have established with the = database provider (for example, which one they are paying to use). Discovery would provide the list of (10) databases. Which one you use coul= d be based on existing subscriptions, but could also be based on roaming ag= reements. Preconfiguration won't work: I build a device that is certified = to work in the U.S. and the U.K. It's sold to a U.K. customer, who visits = the U.S. The customer's U.K. provider has a roaming arrangement with one o= r more U.S. database operators. I want that to work, even if the device is= certified to work in 25 countries. Preconfiguration rarely works well in = global, mobile environments. You can do it, but I want a standardized disc= overy mechanism. 2) Discovery services like LoST are based on location, but the device's rel= ationship with a database service is not known or considered. While it may = seem simple to configure LoST or similar service to point to a database ser= vice based on location, how do you point to the one that the customer has a= relationship with, for example, paid to use? I do realize that this may no= t be an issue in every country. See roaming above. You may have configuration for your home database, but = not a roaming database. Also, I expect arrangements in some other countrie= s will be simpler than the U.S. 3) If PAWS defines a globally applicable discovery process and either picks= an existing protocol (like LoST) or designs one, most likely it would incl= ude a centrally based discovery service. What entity will be responsible fo= r hosting and configuring the central discovery service? How will PAWS defi= ne this as a global solution, and deal with the politics between countries? LoST is designed to not require a central anything. It's distributed. It = cleverly avoids the political mess. The designers were mindful of these is= sues. I'm waving my hands a bit, but it's a very good answer for discovery of loc= ation sensitive servers. 4) Some radio manufacturers do not have very much ROM to include even more = code on their device. I'm concerned that discovery will consume even more s= pace on the radio, space that they may not even have. Not an argument that gets you any traction in the IETF. ROM is cheap. Have= more. All it takes is one service call to wipe out savings in ROM. 5) I believe that defining discovery will take more time than defining the = protocol between the WSDB and WSD. Nah. We do this for lots of protocols. If we decide to use LoST, it will = be very easy. I think that database discovery should be left to each country to define ba= sed on their own requirements and Whitespace ecosystem. By that argument, we should close up shop and let each country define their= own database query protocol. --_000_77CCA903E18E4FDBBCE5C2B2AD8ACA7Aneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don't think PAWS should define discovery, I think the protocol should= simply start after a device has "found" the correct database to use.<= /o:p>

I feel this way for many reasons:
1) In the US, a radio is certi= fied to work with one or more specific databases. So the device will be pre= -configured to contact specific databases, no need to implement a discovery= service. If the device is programmed to work with more than one database p= rovider, the device owner will configure which one to use based on the rela= tionship that they have established with the database provider (for example= , which one they are paying to use).

D= iscovery would provide the list of (10) databases. Which one you use = could be based on existing subscriptions, but could also be based on roamin= g agreements. Preconfiguration won't work: I build a device that is c= ertified to work in the U.S. and the U.K. It's sold to a U.K. custome= r, who visits the U.S. The customer's U.K. provider has a roaming arr= angement with one or more U.S. database operators. I want that to wor= k, even if the device is certified to work in 25 countries. Preconfig= uration rarely works well in global, mobile environments. You can do = it, but I want a standardized discovery mechanism.

<= /div>
2) Disco= very services like LoST are based on location, but the device's relationshi= p with a database service is not known or considered. While it may seem sim= ple to configure LoST or similar service to point to a database service bas= ed on location, how do you point to the one that the customer has a relatio= nship with, for example, paid to use? I do realize that this may not be an = issue in every country.

See roaming ab= ove. You may have configuration for your home database, but not a roa= ming database. Also, I expect arrangements in some other countries wi= ll be simpler than the U.S.

Brian,

Please see my reply inline b= elow.

Don

From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
= Sent: Thursday, April 19, 2012 2:01 PM
To: Don Joslyn
<= b>Cc: Das, Subir; paws@ietf.org
Subject: Re: [paws] Database = Discovery Question

I disagree.

While local = regulation could limit capability for discovery, in general, I would like t= o be able to build devices that find databases based on location and type o= f device.

[Don – If a device is presented a li= st of available databases (simply based on location and device type), what = selection criteria is PAWS defining to help the radio make a choice between= the available databases? Shall we factor in cost, feature level, SLA, or o= ther parameters that might help the radio make a choice between them? If so= , is it not true that the user will need to configure parameters to help th= e radio make the choice that fits the users choice? Are we ignoring the bus= iness relationship within the ecosystem that may be used to match a custome= r with a database? How is the radio to know about the relationship ahead of= time without the user performing some configuration? I think you’re = over simplifying the use case, by suggesting that device location is the on= ly criteria that a device needs to use to find a database. In an ecosystem = that includes a business model where database use may have an associated co= st for access, I’m pretty sure the user will decide which database to= use before the radio is fired up.]

It may = be, as in say GSM cell phones, that discovery presents a list of possibilit= ies, and specific choices get based on things like roaming relationships, b= ut to make that work requires standardization.

[Don= – I would think that GSM cell phones are slave devices and thus do n= ot need to access a whitespace database, and I think slave roaming is outsi= de the scope of PAWS protocol.]

See inline f= or comments

On Apr 19, 2012, a= t 1:30 PM, Don Joslyn wrote:

<= br>

I don't think PAWS should define discovery, I t= hink the protocol should simply start after a device has "found" = the correct database to use.

I feel this way for many reasons:

1) In the US, a radio is certified to work with one or more= specific databases. So the device will be pre-configured to contact specif= ic databases, no need to implement a discovery service. If the device is pr= ogrammed to work with more than one database provider, the device owner wil= l configure which one to use based on the relationship that they have estab= lished with the database provider (for example, which one they are paying t= o use).

Discovery wou= ld provide the list of (10) databases. Which one you use could be bas= ed on existing subscriptions,

[Don – If based on existing subscri= ptions, I’m still configuring the radio to pick a specific one, so wh= at benefit did I really get from discovery (other than added complexity)?]<= o:p>

but could also be based on roami= ng agreements. Preconfiguration won't work: I build a device that is = certified to work in the U.S. and the U.K. It's sold to a U.K. custom= er, who visits the U.S. The customer's U.K. provider has a roaming ar= rangement with one or more U.S. database operators.

[Don – Inter= esting… how do we define these roaming arrangements within the discov= ery domain in such a way that discovery provides the right answer to the ra= dio? Are you adding roaming arrangements to the selection criteria for the = discovery service to use or for the radio to use to make a selection?]=

I want that to work, even if th= e device is certified to work in 25 countries.

[Don – Will PAWS = also be defining all of the possible selection criteria and supporting algo= rithms (for 25 countries) that either the discovery service or radio must u= nderstand and use to make a database choice, a choice that ultimately must = match the user’s requirements?]

Preconfiguration rarely works well in global, mobile environments. &nb= sp;You can do it, but I want a standardized discovery mechanism.=

[Don – For a global mobile environmen= t of slave devices? The slaves will not access a whitespace database, they = will determine a whitespace channel to use from the master. Master to slave= association parameters, such as roaming, are outside the scope of a protoc= ol to exchange whitespace channel lists.]

<= p class=3DMsoNormal>

2) Discovery services like LoST are based on= location, but the device's relationship with a database service is not kno= wn or considered. While it may seem simple to configure LoST or similar ser= vice to point to a database service based on location, how do you point to = the one that the customer has a relationship with, for example, paid to use= ? I do realize that this may not be an issue in every country.

See roaming above. You may = have configuration for your home database, but not a roaming database.

[Don – See my comments on roaming above and b= elow. Are we now defining a roaming database?]

Also, I expect arrangements in some other countries will be s= impler than the U.S.

[Don –Simpler than having the device owner conf= igure a database provider address while they are setting other configuratio= n parameters on the device? Somebody is going to have to configure the disc= overy service. I’m still wondering who that will be and if it’s= really going to be simpler in the end.]

3) If PAWS defines a gl= obally applicable discovery process and either picks an existing protocol (= like LoST) or designs one, most likely it would include a centrally based d= iscovery service. What entity will be responsible for hosting and configuri= ng the central discovery service? How will PAWS define this as a global sol= ution, and deal with the politics between countries?

<= /div>

LoST is designed to not require a central a= nything. It's distributed. It cleverly avoids the political mes= s. The designers were mindful of these issues.

[Don – You avoided my question regarding hosting = and configuration.]

I'm waving my hands a bi= t, but it's a very good answer for discovery of location sensitive servers.=

[Don – If device location = were the only consideration for database selection, we would not be having = this conversation.]

4) Some radio manufacturers do not have very much R= OM to include even more code on their device. I'm concerned that discovery = will consume even more space on the radio, space that they may not even hav= e.

Not a= n argument that gets you any traction in the IETF. ROM is cheap. Have= more. All it takes is one service call to wipe out savings in ROM.

[Don – You’re simply a= voiding the issue, ok.]

5) I believe that defining discovery wil= l take more time than defining the protocol between the WSDB and WSD.<= /o:p>

Nah. We do this for = lots of protocols. If we decide to use LoST, it will be very easy. &n= bsp;

[Don – Time will tell if I’m right or wrong. I do hope we= can find an easy solution, but based on the selection criteria that weR= 17;ve already discussed, I’m still concerned that it may not be the c= ase.]

I think that database discovery should be left to each country to = define based on their own requirements and Whitespace ecosystem.=

By that argument, we should clo= se up shop and let each country define their own database query protocol.

[Don – I’m not falling= for the all-or-nothing argument.]

<= /o:p>

= --_000_8375F6DAEFB09F48815203F1FE23B797113CB4F421shelby_-- From d.joslyn@spectrumbridge.com Fri Apr 20 12:19:06 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9484411E8079 for ; Fri, 20 Apr 2012 12:19:06 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0+eqvmv0383 for ; Fri, 20 Apr 2012 12:19:02 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id D6C5321F847B for ; Fri, 20 Apr 2012 12:19:01 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Fri, 20 Apr 2012 15:20:41 -0400 From: Don Joslyn To: Paul Lambert , "Das, Subir" , "paws@ietf.org" Date: Fri, 20 Apr 2012 15:20:40 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0c4K8PQNA9Co7UTfGQzW7Gue+uSwBcXadgAAInqCAAMn5KAA== Message-ID: <8375F6DAEFB09F48815203F1FE23B797113CB4F440@shelby> References: <8375F6DAEFB09F48815203F1FE23B797113CB4F3CF@shelby> <7BAC95F5A7E67643AAFB2C31BEE662D015E397BF4B@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D015E397BF4B@SC-VEXCH2.marvell.com> 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_8375F6DAEFB09F48815203F1FE23B797113CB4F440shelby_" MIME-Version: 1.0 Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Apr 2012 19:19:06 -0000 --_000_8375F6DAEFB09F48815203F1FE23B797113CB4F440shelby_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See reply below. Don From: Paul Lambert [mailto:paul@marvell.com] Sent: Thursday, April 19, 2012 2:36 PM To: Don Joslyn; Das, Subir; paws@ietf.org Subject: RE: [paws] Database Discovery Question Paul A. Lambert | Marvell | +1-650-787-9141 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Joslyn Sent: Thursday, April 19, 2012 10:31 AM To: Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question I don't think PAWS should define discovery, I think the protocol should sim= ply start after a device has "found" the correct database to use. I feel this way for many reasons: 1) In the US, a radio is certified to work with one or more specific databa= ses. So the device will be pre-configured to contact specific databases, no= need to implement a discovery service. If the device is programmed to work= with more than one database provider, the device owner will configure whic= h one to use based on the relationship that they have established with the = database provider (for example, which one they are paying to use). When new databases come online, users would likely appreciate an option to = connect to a system additional services or perhaps lower prices for the ser= vice. [Don - Yes, this may be desired, but can the device immediately take advant= age of these new database records and decide on its own to use a new one th= at has a lower cost? I would think that the device owner still needs to dec= ide to use the lower cost service (may even have to consider why it costs l= ess), pay for the service, and then configure the device to use it. I'm not= sure how this can automatically happen between the discovery service and W= SD. Will cost considerations be part of the discovery solution? Is it cost = per month, year, lifetime, message count, etc? You mentioned cost, but ther= e can be many other parameters that can influence the selection outcome (SL= A, features, etc.), where will we stop?] If we go strictly on the preconfiguration model ... we don't even need PAWS= . The relationship you describe would have defined all the interfaces. If= we are in the business of having open interfaces, we need to provide a mea= ns to discocovery and select DBs. [Don - I don't agree with the all-or-nothing argument, using discovery is o= ptional (per PAWS requirements). Establishing a standard protocol between W= SDB and WSD is still valuable because, for example, will can still lower th= e cost to device manufacturers because they will only need to implement cod= e for a single standard defined interface.] Paul 2) Discovery services like LoST are based on location, but the device's rel= ationship with a database service is not known or considered. While it may = seem simple to configure LoST or similar service to point to a database ser= vice based on location, how do you point to the one that the customer has a= relationship with, for example, paid to use? I do realize that this may no= t be an issue in every country. 3) If PAWS defines a globally applicable discovery process and either picks= an existing protocol (like LoST) or designs one, most likely it would incl= ude a centrally based discovery service. What entity will be responsible fo= r hosting and configuring the central discovery service? How will PAWS defi= ne this as a global solution, and deal with the politics between countries? 4) Some radio manufacturers do not have very much ROM to include even more = code on their device. I'm concerned that discovery will consume even more s= pace on the radio, space that they may not even have. 5) I believe that defining discovery will take more time than defining the = protocol between the WSDB and WSD. I think that database discovery should be left to each country to define ba= sed on their own requirements and Whitespace ecosystem. Regards, Don From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Das, Subir Sent: Tuesday, April 17, 2012 5:26 PM To: paws@ietf.org Subject: [paws] Database Discovery Question During PAWS session in Paris IETF, there were a lot of questions/discussion= s on 'Discovery' of Database. It was not clear to me except if we are talki= ng about "Database Server Discovery", in particular, the domain name or the= IP address of the 'Server" that is hosting the database. OTH, I felt that = some folks may have different views and they would possibly like to see mor= e features than just discovering the domain name or IP address of the "Data= base Server". In some offline discussions, I was told that it may be similar to what LOST= (RFC 5222) has defined. I read the LOST protocol and associated architectu= re and my current understanding is that the LOST use case is different than= what we are trying to achieve via PAWS. Here is my understanding of the op= erating model of PAWS interface (when defined): -"Fixed/Mode II WSD" (per figure 1,) can only q= uery the database -The manufacturer of the "Fixed/Mode II WSD" may be different than owner/op= erator of this device -"Fixed/Mode II WSD" is certified by the regulatory body of the region that= they serve - Either the "Fixed/Mode II WSD" device operator or the device vendor has a= n a-priori relationship with one or more covering database administrators. = This relationship is utilized to either configure or enable the discovery of the proper data= base to contact in the current location I would like to know the group's view of the above model. To me, finding th= e emergency services or restaurant information near my location is differen= t than getting to know a server that can provide me with channel/frequency/= power and other information in the location where "Fixed/Mode II WSD" is si= tuated. In addition, emergency services do not require a subscription and t= he service is mandated by the Government/regulatory bodies. Some may argue = that 'White Space' service may be free as well, but to my understanding it = is not quite the similar model as emergency services. I hope with this thread we can clarify/understand the discovery issue. Regards, _Subir --_000_8375F6DAEFB09F48815203F1FE23B797113CB4F440shelby_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

See reply below.

Don

<= span style=3D'color:#1F497D'>

From: Paul Lambert [mailto:paul@marvell.com]
Sent: Thursday, April 19, 2012 2:36 PM
To: Don Joslyn; Das, Subir; pa= ws@ietf.org
Subject: RE: [paws] Database Discovery Question<= /o:p>

<= p class=3DMsoNormal> <= /p>

Paul A. Lamb= ert | Marvell | +1-650-787-9141

From: paws-bounces@ietf.org [mailt= o:paws-bounces@ietf.org] On Behalf Of Don Joslyn
Sent:= Thursday, April 19, 2012 10:31 AM
To: Das, Subir; paws@ietf.org
Subject: Re: [paws] Database= Discovery Question
<= o:p>
I don't think PAWS should defin= e discovery, I think the protocol should simply start after a device has &q= uot;found" the correct database to use.

I feel this way for ma= ny reasons:
1) In the US, a radio is = certified to work with one or more specific databases. So the device will b= e pre-configured to contact specific databases, no need to implement a disc= overy service. If the device is programmed to work with more than one datab= ase provider, the device owner will configure which one to use based on the= relationship that they have established with the database provider (for ex= ample, which one they are paying to use).

When= new databases come online, users would likely appreciate an option to conn= ect to a system additional services or perhaps lower prices for the service= .

[Don – Yes, this may be desired= , but can the device immediately take advantage of these new database recor= ds and decide on its own to use a new one that has a lower cost? I would th= ink that the device owner still needs to decide to use the lower cost servi= ce (may even have to consider why it costs less), pay for the service, and = then configure the device to use it. I’m not sure how this can automa= tically happen between the discovery service and WSD. Will cost considerati= ons be part of the discovery solution? Is it cost per month, year, lifetime= , message count, etc? You mentioned cost, but there can be many other param= eters that can influence the selection outcome (SLA, features, etc.), where= will we stop?]
&n= bsp;
If we go strictly on th= e preconfiguration model … we don’t even need PAWS. The r= elationship you describe would have defined all the interfaces. If we= are in the business of having open interfaces, we need to provide a means = to discocovery and select DBs.
[Don – I don’t agree with the all-or-not= hing argument, using discovery is optional (per PAWS requirements). Establi= shing a standard protocol between WSDB and WSD is still valuable because, f= or example, will can still lower the cost to device manufacturers because t= hey will only need to implement code for a single standard defined interfac= e.]

Paul

= 2) Discovery services like LoST are based on location, but the device's rel= ationship with a database service is not known or considered. While it may = seem simple to configure LoST or similar service to point to a database ser= vice based on location, how do you point to the one that the customer has a= relationship with, for example, paid to use? I do realize that this may no= t be an issue in every country.
3) If= PAWS defines a globally applicable discovery process and either picks an e= xisting protocol (like LoST) or designs one, most likely it would include a= centrally based discovery service. What entity will be responsible for hos= ting and configuring the central discovery service? How will PAWS define th= is as a global solution, and deal with the politics between countries?=
4) Some radio manufacturers do not have v= ery much ROM to include even more code on their device. I'm concerned that = discovery will consume even more space on the radio, space that they may no= t even have.
5) I believe that defini= ng discovery will take more time than defining the protocol between the WSD= B and WSD.

I think that database discovery should be left to each c= ountry to define based on their own requirements and Whitespace ecosystem.<= o:p>

Regards,
Don

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Das, Subir
= Sent: Tuesday, April 17, 2012 5:26 PM
To: paws@ietf.org
Subject: [paws] Database Discover= y Question
= ;
During PAWS session in Paris IETF, there= were a lot of questions/discussions on 'Discovery' of Database. It was not= clear to me except if we are talking about "Database Server Discovery= ", in particular, the domain name or the IP address of the 'Server&quo= t; that is hosting the database. OTH, I felt that some folks may have diffe= rent views and they would possibly like to see more features than just disc= overing the domain name or IP address of the "Database Server".

In some offline discussions, I was told that it may be similar to wh= at LOST (RFC 5222) has defined. I read the LOST protocol and associated arc= hitecture and my current understanding is that the LOST use case is differe= nt than what we are trying to achieve via PAWS. Here is my understanding of= the operating model of PAWS interface (when defined):

-"Fixed= /Mode II WSD" (per figure 1,<draft-das-paws-protocol-01>) can on= ly query the database

-The manufacturer of the "Fixed/Mode II = WSD" may be different than owner/operator of this device

-&quo= t;Fixed/Mode II WSD" is certified by the regulatory body of the region= that they serve

- Either the "Fixed/Mode II WSD" device = operator or the device vendor has an a-priori relationship with one or more= covering database administrators. This relationship
is utilized to either configure or enable the discove= ry of the proper database to contact in the current location
=

&= nbsp;
I would like to know the group's vie= w of the above model. To me, finding the emergency services or restaurant i= nformation near my location is different than getting to know a server that= can provide me with channel/frequency/power and other information in the l= ocation where "Fixed/Mode II WSD" is situated. In addition, emerg= ency services do not require a subscription and the service is mandated by = the Government/regulatory bodies. Some may argue that 'White Space' service= may be free as well, but to my understanding it is not quite the similar m= odel as emergency services.
&nbs= p;

I hope with this thread we can clarify/understand the discovery issue= .

Regards,
=
_Subir

= --_000_8375F6DAEFB09F48815203F1FE23B797113CB4F440shelby_-- From Gabor.Bajko@nokia.com Fri Apr 20 13:44:38 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B3EB21F85A4 for ; Fri, 20 Apr 2012 13:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0LA54aAnaCI for ; Fri, 20 Apr 2012 13:44:32 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 90D1821F85A0 for ; Fri, 20 Apr 2012 13:44:31 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3KKiIxV015014; Fri, 20 Apr 2012 23:44:19 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.20]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 20 Apr 2012 23:44:17 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.85]) by 008-AM1MMR1-011.mgdnok.nokia.com ([65.54.30.20]) with mapi id 14.02.0283.004; Fri, 20 Apr 2012 22:44:17 +0200 From: To: Thread-Topic: [paws] identity verification (was: Database Discovery Question) Thread-Index: Ac0eZQTbSgaeGcPfQOKDbU23fUOLZgADjImAAADsQkAAHXx2AAASI/0w Date: Fri, 20 Apr 2012 20:44:16 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E7E79B@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E77FC9@008-AM1MPN1-001.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716456BC0@dfweml503-mbx> <1ECAFF543A2FED4EA2BEB6CACE08E47601E78109@008-AM1MPN1-001.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.124.61] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E7E79B008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2012 20:44:17.0804 (UTC) FILETIME=[5AF0D4C0:01CD1F36] X-Nokia-AV: Clean Cc: paws@ietf.org, Peter.McCann@huawei.com Subject: Re: [paws] identity verification (was: Database Discovery Question) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Apr 2012 20:44:39 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E7E79B008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, and I don't think anyone said otherwise. The point we were debating is how to make sure the slave (mode 1) devices d= id not spoof their identity. Since regulators do not require the slave devi= ces to have a crypto binding between the identifier and the hardware, the m= aster who authenticates the slave using some other existing credentials, ha= s no choice but to trust the slave will not spoof its identity. - Gabor From: wtr486@motorola.com [mailto:wtr486@motorola.com] On Behalf Of ext Dav= e Halasz Sent: Friday, April 20, 2012 6:58 AM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: Peter.McCann@huawei.com; Brian.Rosen@neustar.biz; paws@ietf.org Subject: Re: [paws] identity verification (was: Database Discovery Question= ) My reading of paragraph 98 of FCC-10-174A1 indicates that regulators do req= uire verification of the FCC-ID of Mode 1 devices by the database(s). http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-10-174A1.pdf Dave H. > Afaik, regulators do not require for client certs binding the > identifier to the hardware. Therefore, the verification of whether the > identifier is the correct one or not seems to be outside the scope of > paws. The master should rely on the lower layers and the DB for this > verification. This statement really confuses me. To me, a binding of an identifier to ha= rdware means that there is some tamper and copy-proof storage for a private= key epoxied into the wireless hardware. This private key would be used to= authenticate & distribute keying material for a secure channel between the= slave and the master. That part is indeed out of scope of PAWS, but the m= aster-to-database messages to validate the slave's credentials are not. I think the confusion might come that you assume the private key in th= e slave (if existed at all) would also be used to authenticate the slave to= the master. In my understanding that would not necessarily be the case. Ev= en if there was a private key in the slave, the slave would acquire another= set of (eg username/password) credentials, independent of the private key,= to connect to the master device. On Thu, Apr 19, 2012 at 6:14 PM, > wrote: Hi Pete, My responses inline: -----Original Message----- From: ext Peter McCann [mailto:Peter.McCann@huawei.com] Sent: Thursday, April 19, 2012 2:42 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Brian.Rosen@neustar.biz Cc: paws@ietf.org Subject: RE: identity verification (was: Database Discovery Question) Hi, Gabor, Gabor.Bajko@nokia.com wrote: > Hi Pete, > > Some comments inline: > > > -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-b= ounces@ietf.org] On Behalf >> Of ext Peter McCann >> Sent: Wednesday, April 18, 2012 9:02 AM >> To: Rosen, Brian >> Cc: paws@ietf.org >> Subject: Re: [paws] Database Discovery Question >> >> Hi, Brian, >> >> The problem is, the master device cannot be authoritative on whether >> the slave device is approved for use by the regulator. It must rely >> on the WSDB it uses (has a relationship with) to tell it. >> >> At the least, we need a format for device identifiers that can be >> understood by multiple independently operated databases. >> > yes, this should be part of the data model. Agreed. >> Maybe the WSDB trusts the master device to collect this information >> securely from the slave devices using slave-to-master credentials. >> > yes, this is what at least the 802.11af draft amendment is > currently defining for the 802.11 air interface. The slave sends its > identifier to the master, then waits for the enablement signal. The > enablement signal comes after the master was able to successfully > validate the identifier of the slave with the DB. Is there any security or spoofing protection defined in 802.11af? It inherits whatever is in the 802.11 base spec, ie .1x >> Normally, the allocation authority for the identifier space would be >> a trust anchor for the identifier-to-device binding. I agree that >> the master-to-slave interface is out of scope, but there should be >> some mechanism in the marketplace for the master device operator to >> securely bind the identifier presented by the slave to the >> communication channel with the slave device, in the sense that the >> master device is able to know in a secure way that the device it is >> talking to actually does own the regulator-assigned device >> identifier. It seems natural for the master device to rely on its >> relationship with a database to help with this binding. >> > I see two things here: binding between the communication channel > and identity; and binding between the identity and the hardware to > which it was assigned. The binding between the communication channel > and the identity as presented by slave is there inherently in the > radio. I don't understand this last statement. Do you mean a cryptographically se= cure binding? What if I spoof my MAC address? Assuming an RSN network, after the .1x procedure, there is a key deriv= ed to encrypt the STA to AP communication. 802.11af does not assume that the credentials the slave has to get authenti= cated with the master can in any way be used to prove the ownership of the = identity. There's a set of credentials for slave-master authentication, and= there might be (currently there is no requirement for it) another mechanis= m for the slave to prove to the db that it owns the identity it sent to the= master. > The task to verify that the identity indeed belongs to the slave > should not be the burden of the master device, rather the DB (if seen > necessary). In order for the DB to verify that the presented > identifier indeed belongs to that device, a client cert or sg similar > would be needed. That seems reasonable to me. The slave device has a client cert and someho= w demonstrates knowledge of the private key that goes with the cert to the = database. After this, the database can send "I approve" to the master device. Assuming that both communication channels (slave to = master and master to database) have been authenticated and secured, the mas= ter can then tell the slave to go ahead. However, we now require the database be able to validate the credentials of= any slave device that may be manufactured/owned by someone other than the = manufacturer/owner of the master device. It would seem we need a nationall= y-scoped trust anchor to achieve this. I think this is the part which is outside the scope of our charter, wh= ich says: " 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. ". Th= ere is no mention about the db making sure the slave devices did not spoof = their identity. Especially as regulators do not require slave devices to ha= ve a mechanism to be able to prove ownership of the identity. If I remember= correctly, this was considered in FCC, but then the requirement was droppe= d. > Afaik, regulators do not require for client certs binding the > identifier to the hardware. Therefore, the verification of whether the > identifier is the correct one or not seems to be outside the scope of > paws. The master should rely on the lower layers and the DB for this > verification. This statement really confuses me. To me, a binding of an identifier to ha= rdware means that there is some tamper and copy-proof storage for a private= key epoxied into the wireless hardware. This private key would be used to= authenticate & distribute keying material for a secure channel between the= slave and the master. That part is indeed out of scope of PAWS, but the m= aster-to-database messages to validate the slave's credentials are not. I think the confusion might come that you assume the private key in th= e slave (if existed at all) would also be used to authenticate the slave to= the master. In my understanding that would not necessarily be the case. Ev= en if there was a private key in the slave, the slave would acquire another= set of (eg username/password) credentials, independent of the private key,= to connect to the master device. - Gabor -Pete > > - Gabor > > > > -Pete > > Rosen, Brian wrote: >> > this thread> The credentialling system used between the database >> server and its client (the master) are those of its client. The >> database trusts its client. >> >> The client (the master) may need its customer, the slave, to present >> credentials for service. >> >> This means we assume transitive trust on the ID information from the >> client. The master validates the slave, the database validates the >> master. I would not advocate trying to make anything more complex. >> >> Brian >> >> On Apr 18, 2012, at 11:16 AM, Peter McCann wrote: >> >>> Right, the master queries the database on behalf of the slave, >>> sending the slave's Device ID and location. (See Don's message >>> about validating the FCC ID). My question is, what is the security >>> model for validating the slave's ID? Is there a secure credential >>> associated with the ID, or is it an insecure check of a number >>> against a whitelist? If the former, we will need a credential >>> management system that is able to cross between different databases. >>> If the latter, I wonder if it opens up security problems. >>> >>> -Pete >>> >>> Rosen, Brian wrote: >>>> Perhaps I am confused, but I think in a master/slave environment, >>>> the slave does not query the database, the master does. The slave >>>> gets its allowed spectrum data from the master. There is always >>>> the question of whether the master queries on its own behalf and >>>> the slaves just get assignments within that database response, or >>>> whether the master queries on behalf of the slaves. Might have to >>>> support both models. In many cases, I think it's the latter: the >>>> master queries using the slaves location and parameters. >>>> >>>> The most common master/slave setup is tower and clients, right? >>>> The tower has an Internet connection and can query the database. >>>> The clients of the tower are the slaves. Does the database query >>>> use the location and type data of the slave or the master? >>>> >>>> Brian >>>> >>>> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: >>>> >>>>> I think it would be a mistake to assume that the slave & master >>>>> devices both have pre-existing relationships with the same database. >>>>> In a commercial service, the slave devices would all come from >>>>> different manufacturers and would certainly have different owners. >>>>> Wouldn't we want them to interoperate with any master device, >>>>> assuming they are RF-compatible? >>>>> >>>>> -Pete >>>>> >>>>> Rosen, Brian wrote: >>>>>> Doesn't the slave get it's database access through the master? >>>>>> If that's true, the problem you are worried about doesn't exist. >>>>>> >>>>>> Brian >>>>>> >>>>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>>>>> >>>>>>> I agree with Brian that LoST could be a good model for >>>>>>> discovering the appropriate database for the region you're in. A >>>>>>> nation may decide to subdivide their territory into provinces or >>>>>>> states, each of which maintains its own database. >>>>>>> >>>>>>> I think it would be a mistake to assume that there is a single, >>>>>>> pre-defined relationship for one device with just one database. >>>>>>> In particular, I think there is a thorny issue that will arise >>>>>>> with management of secure credentials on whitespace devices, >>>>>>> illustrated by the first use case in Section 4.2.1 of >>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that >>>>>>> use case says: >>>>>>> >>>>>>> 9. Once the master/AP has met all regulatory domain >> requirements >>>>>>> (e.g. validating the Device ID with the trusted database, >>>>>>> etc) the master provides the list of channels locally >>>>>>> available to the slave/user device. >>>>>>> My question is, what if the master device has a relationship >>>>>>> with one database, but the slave device has a relationship with >>>>>>> another? How is the master's database supposed to validate the >>>>>>> credentials of the slave device, if we don't have some sort of >>>>>>> common trust anchor? Or will this "validation" be simply an >>>>>>> insecure check of an ID against a whitelist/blacklist? Who will >>>>>>> allocate Device IDs? Will they be specific to a particular >>>>>>> database operator, or do we need some common top-level >>>>>>> allocation format? >>>>>>> >>>>>>> -Pete >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > > _______________________________________________ > 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_1ECAFF543A2FED4EA2BEB6CACE08E47601E7E79B008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure, and I don’t t= hink anyone said otherwise.

The point we were debatin= g is how to make sure the slave (mode 1) devices did not spoof their identi= ty. Since regulators do not require the slave devices to have a crypto binding between the identifier and the hardware, the master = who authenticates the slave using some other existing credentials, has no c= hoice but to trust the slave will not spoof its identity.=

<= /p>
- =          Gabor<= /span>

<= /p>
<= /p>
From: wtr486@m= otorola.com [mailto:wtr486@motorola.com] On Behalf Of ext Dave Halasz
Sent: Friday, April 20, 2012 6:58 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: Peter.McCann@huawei.com; Brian.Rosen@neustar.biz; paws@ietf.org<= br> Subject: Re: [paws] identity verification (was: Database Discovery Q= uestion)

My reading of paragra= ph 98 of FCC-10-174A1 indicates that regulators do require verification of = the FCC-ID of Mode 1 devices by the database(s).
http://hraunfoss.fcc.gov/edocs_public/attachmatch/F= CC-10-174A1.pdf

Dave H.

> Afaik, regulators do not require for client certs binding the
> identifier to the hardware. Therefore, the verification of whether the=
> identifier is the correct one or not seems to be outside the scope of<= br> > paws. The master should rely on the lower layers and the DB for this > verification.

This statement really confuses me. To me, a binding of an identifier = to hardware means that there is some tamper and copy-proof storage for a pr= ivate key epoxied into the wireless hardware. This private key would = be used to authenticate & distribute keying material for a secure channel between the slave and the master. That= part is indeed out of scope of PAWS, but the master-to-database messages t= o validate the slave's credentials are not.

<GB> I think the confusion might come that you assume the private key= in the slave (if existed at all) would also be used to authenticate the sl= ave to the master. In my understanding that would not necessarily be the ca= se. Even if there was a private key in the slave, the slave would acquire another set of (eg username/password) c= redentials, independent of the private key, to connect to the master = device.

On Thu, Apr 19, 2012 at 6:14 PM, <Gabor.Bajko@nokia.com> wrote:
Hi Pete,
My responses inline:

-----Original Message-----
From: ext Peter McCann [mailto:P= eter.McCann@huawei.com]
Sent: Thursday, April 19, 2012 2:42 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); Brian.Rosen@neustar.biz
Cc: paws@ietf.org
Subject: RE: identity verification (was: Database Discovery Question)

Hi, Gabor,

Gabor.Bajko@nokia.com wrote: > Hi Pete,
>
> Some comments inline:
>
>
> -----Original Message-----
>> From: paws-bounces@ietf.o= rg [mailto:paws-bounces@ietf.o= rg] On Behalf
>> Of ext Peter McCann
>> Sent: Wednesday, April 18, 2012 9:02 AM
>> To: Rosen, Brian
>> Cc: paws@ietf.org
>> Subject: Re: [paws] Database Discovery Question
>>
>> Hi, Brian,
>>
>> The problem is, the master device cannot be authoritative on wheth= er
>> the slave device is approved for use by the regulator. It mu= st rely
>> on the WSDB it uses (has a relationship with) to tell it.
>>
>> At the least, we need a format for device identifiers that can be<= br> >> understood by multiple independently operated databases.
>>
> <GB> yes, this should be part of the data model.

Agreed.

>> Maybe the WSDB trusts the master device to collect this informatio= n
>> securely from the slave devices using slave-to-master credentials.=
>>
> <GB> yes, this is what at least the 802.11af draft amendment is<= br> > currently defining for the 802.11 air interface. The slave sends its > identifier to the master, then waits for the enablement signal. The > enablement signal comes after the master was able to successfully
> validate the identifier of the slave with the DB.

Is there any security or spoofing protection defined in 802.11af?

<GB> It inherits whatever is in the 802.11 bas= e spec, ie .1x

>> Normally, the allocation authority for the identifier space would = be
>> a trust anchor for the identifier-to-device binding. I agree= that
>> the master-to-slave interface is out of scope, but there should be=
>> some mechanism in the marketplace for the master device operator t= o
>> securely bind the identifier presented by the slave to the
>> communication channel with the slave device, in the sense that the=
>> master device is able to know in a secure way that the device it i= s
>> talking to actually does own the regulator-assigned device
>> identifier. It seems natural for the master device to rely on its<= br> >> relationship with a database to help with this binding.
>>
> <GB> I see two things here: binding between the communication ch= annel
> and identity; and binding between the identity and the hardware to
> which it was assigned. The binding between the communication channel > and the identity as presented by slave is there inherently in the
> radio.

I don't understand this last statement. Do you mean a cryptographical= ly secure binding? What if I spoof my MAC address?

<GB> Assuming an RSN network, after the .1x pr= ocedure, there is a key derived to encrypt the STA to AP communication.
802.11af does not assume that the credentials the slave has to get authenti= cated with the master can in any way be used to prove the ownership of the = identity. There's a set of credentials for slave-master authentication, and= there might be (currently there is no requirement for it) another mechanism for the slave to prove to the = db that it owns the identity it sent to the master.

> The task to verify that the identity indeed belongs to the slave
> should not be the burden of the master device, rather the DB (if seen<= br> > necessary). In order for the DB to verify that the presented
> identifier indeed belongs to that device, a client cert or sg similar<= br> > would be needed.

That seems reasonable to me. The slave device has a client cert and s= omehow demonstrates knowledge of the private key that goes with the cert to= the database. After this, the database can send "I approve"= ;
to the master device. Assuming that both communication channels (slav= e to master and master to database) have been authenticated and secured, th= e master can then tell the slave to go ahead.

However, we now require the database be able to validate the credentials of= any slave device that may be manufactured/owned by someone other than the = manufacturer/owner of the master device. It would seem we need a nati= onally-scoped trust anchor to achieve this.

<GB> I think this is the part which is outside= the scope of our charter, which says: " 4. Ensure that the discovery = mechanism, database access method,
and query/response formats have appropriate security levels in place. "= ;. There is no mention about the db making sure the slave devices did not s= poof their identity. Especially as regulators do not require slave devices = to have a mechanism to be able to prove ownership of the identity. If I remember correctly, this was considered in= FCC, but then the requirement was dropped.

> Afaik, regulators do not require for client certs binding the
> identifier to the hardware. Therefore, the verification of whether the=
> identifier is the correct one or not seems to be outside the scope of<= br> > paws. The master should rely on the lower layers and the DB for this > verification.

This statement really confuses me. To me, a binding of an identifier = to hardware means that there is some tamper and copy-proof storage for a pr= ivate key epoxied into the wireless hardware. This private key would = be used to authenticate & distribute keying material for a secure channel between the slave and the master. That= part is indeed out of scope of PAWS, but the master-to-database messages t= o validate the slave's credentials are not.

<GB> I think the confusion might come that you= assume the private key in the slave (if existed at all) would also be used= to authenticate the slave to the master. In my understanding that would no= t necessarily be the case. Even if there was a private key in the slave, the slave would acquire another set of (eg= username/password) credentials, independent of the private key, to c= onnect to the master device.

- Gabor

-Pete

>
> - Gabor
>
>
>
> -Pete
>
> Rosen, Brian wrote:
>> <As individual, and I should have said that on all of my messag= es on
>> this thread> The credentialling system used between the databas= e
>> server and its client (the master) are those of its client. = The
>> database trusts its client.
>>
>> The client (the master) may need its customer, the slave, to prese= nt
>> credentials for service.
>>
>> This means we assume transitive trust on the ID information from t= he
>> client. The master validates the slave, the database validat= es the
>> master. I would not advocate trying to make anything more co= mplex.
>>
>> Brian
>>
>> On Apr 18, 2012, at 11:16 AM, Peter McCann wrote:
>>
>>> Right, the master queries the database on behalf of the slave,=
>>> sending the slave's Device ID and location. (See Don's m= essage
>>> about validating the FCC ID). My question is, what is th= e security
>>> model for validating the slave's ID? Is there a secure c= redential
>>> associated with the ID, or is it an insecure check of a number=
>>> against a whitelist? If the former, we will need a crede= ntial
>>> management system that is able to cross between different data= bases.
>>> If the latter, I wonder if it opens up security problems.
>>>
>>> -Pete
>>>
>>> Rosen, Brian wrote:
>>>> Perhaps I am confused, but I think in a master/slave envir= onment,
>>>> the slave does not query the database, the master does. &n= bsp;The slave
>>>> gets its allowed spectrum data from the master. Ther= e is always
>>>> the question of whether the master queries on its own beha= lf and
>>>> the slaves just get assignments within that database respo= nse, or
>>>> whether the master queries on behalf of the slaves. = Might have to
>>>> support both models. In many cases, I think it's the latte= r: the
>>>> master queries using the slaves location and parameters. >>>>
>>>> The most common master/slave setup is tower and clients, r= ight?
>>>> The tower has an Internet connection and can query the dat= abase.
>>>> The clients of the tower are the slaves. Does the da= tabase query
>>>> use the location and type data of the slave or the master?=
>>>>
>>>> Brian
>>>>
>>>> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote:
>>>>
>>>>> I think it would be a mistake to assume that the slave= & master
>>>>> devices both have pre-existing relationships with the = same database.
>>>>> In a commercial service, the slave devices would all c= ome from
>>>>> different manufacturers and would certainly have diffe= rent owners.
>>>>> Wouldn't we want them to interoperate with any master = device,
>>>>> assuming they are RF-compatible?
>>>>>
>>>>> -Pete
>>>>>
>>>>> Rosen, Brian wrote:
>>>>>> Doesn't the slave get it's database access through= the master?
>>>>>> If that's true, the problem you are worried about = doesn't exist.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote:<= br> >>>>>>
>>>>>>> I agree with Brian that LoST could be a good m= odel for
>>>>>>> discovering the appropriate database for the r= egion you're in. A
>>>>>>> nation may decide to subdivide their territory= into provinces or
>>>>>>> states, each of which maintains its own databa= se.
>>>>>>>
>>>>>>> I think it would be a mistake to assume that t= here is a single,
>>>>>>> pre-defined relationship for one device with j= ust one database.
>>>>>>> In particular, I think there is a thorny issue= that will arise
>>>>>>> with management of secure credentials on white= space devices,
>>>>>>> illustrated by the first use case in Section 4= .2.1 of
>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03= . Step 9 of that
>>>>>>> use case says:
>>>>>>>
>>>>>>> 9. Once the master/AP has met all regul= atory domain
>> requirements
>>>>>>> (e.g. validating the Devic= e ID with the trusted database,
>>>>>>> etc) the master provides t= he list of channels locally
>>>>>>> available to the slave/use= r device.
>>>>>>> My question is, what if the master device has = a relationship
>>>>>>> with one database, but the slave device has a = relationship with
>>>>>>> another? How is the master's database supposed= to validate the
>>>>>>> credentials of the slave device, if we don't h= ave some sort of
>>>>>>> common trust anchor? Or will this "valida= tion" be simply an
>>>>>>> insecure check of an ID against a whitelist/bl= acklist? Who will
>>>>>>> allocate Device IDs? Will they be specific to = a particular
>>>>>>> database operator, or do we need some common t= op-level
>>>>>>> allocation format?
>>>>>>>
>>>>>>> -Pete
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
> _______________________________________________
> paws mailing list
> paws@ietf.org
> https://www.ietf.org/mailman/listinfo/paws

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

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E7E79B008AM1MPN1006mg_-- From Gabor.Bajko@nokia.com Fri Apr 20 14:06:28 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984AD21F84E4 for ; Fri, 20 Apr 2012 14:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 O5zl9ZaXXRZl for ; Fri, 20 Apr 2012 14:06:24 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7F97C21E8032 for ; Fri, 20 Apr 2012 14:06:15 -0700 (PDT) Received: from vaebh101.NOE.Nokia.com (in-mx.nokia.com [10.160.244.22]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3KL65DC025278; Sat, 21 Apr 2012 00:06:06 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Apr 2012 00:06:05 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.85]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Fri, 20 Apr 2012 23:06:04 +0200 From: To: , , , Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0c4K8PQNA9Co7UTfGQzW7Gue+uSwBcXadgAAInqCAAMn5KAAAEuj9A Date: Fri, 20 Apr 2012 21:06:04 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E817E3@008-AM1MPN1-006.mgdnok.nokia.com> References: <8375F6DAEFB09F48815203F1FE23B797113CB4F3CF@shelby> <7BAC95F5A7E67643AAFB2C31BEE662D015E397BF4B@SC-VEXCH2.marvell.com> <8375F6DAEFB09F48815203F1FE23B797113CB4F440@shelby> In-Reply-To: <8375F6DAEFB09F48815203F1FE23B797113CB4F440@shelby> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.124.61] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E817E3008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2012 21:06:05.0484 (UTC) FILETIME=[6660F6C0:01CD1F39] X-Nokia-AV: Clean Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Apr 2012 21:06:28 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E817E3008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Don, As chair, I'll have to ask you to stop arguing against a database discovery= protocol. That is clearly within the scope for the wg, as the charter says= : "Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database." a= nd it doesn't mention the optionality. ietf is contribution driven, if you are not interested in the discovery, th= en you do not need to contribute to it. But do not try to persuade the wg t= o not work on a piece which is in charter and folks are willing to do; tha= t is not how ietf works. - Gabor From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext= Don Joslyn Sent: Friday, April 20, 2012 12:21 PM To: Paul Lambert; Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question See reply below. Don From: Paul Lambert [mailto:paul@marvell.com] Sent: Thursday, April 19, 2012 2:36 PM To: Don Joslyn; Das, Subir; paws@ietf.org Subject: RE: [paws] Database Discovery Question Paul A. Lambert | Marvell | +1-650-787-9141 From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Don Joslyn Sent: Thursday, April 19, 2012 10:31 AM To: Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question I don't think PAWS should define discovery, I think the protocol should sim= ply start after a device has "found" the correct database to use. I feel this way for many reasons: 1) In the US, a radio is certified to work with one or more specific databa= ses. So the device will be pre-configured to contact specific databases, no= need to implement a discovery service. If the device is programmed to work= with more than one database provider, the device owner will configure whic= h one to use based on the relationship that they have established with the = database provider (for example, which one they are paying to use). When new databases come online, users would likely appreciate an option to = connect to a system additional services or perhaps lower prices for the ser= vice. [Don - Yes, this may be desired, but can the device immediately take advant= age of these new database records and decide on its own to use a new one th= at has a lower cost? I would think that the device owner still needs to dec= ide to use the lower cost service (may even have to consider why it costs l= ess), pay for the service, and then configure the device to use it. I'm not= sure how this can automatically happen between the discovery service and W= SD. Will cost considerations be part of the discovery solution? Is it cost = per month, year, lifetime, message count, etc? You mentioned cost, but ther= e can be many other parameters that can influence the selection outcome (SL= A, features, etc.), where will we stop?] If we go strictly on the preconfiguration model ... we don't even need PAWS= . The relationship you describe would have defined all the interfaces. If= we are in the business of having open interfaces, we need to provide a mea= ns to discocovery and select DBs. [Don - I don't agree with the all-or-nothing argument, using discovery is o= ptional (per PAWS requirements). Establishing a standard protocol between W= SDB and WSD is still valuable because, for example, will can still lower th= e cost to device manufacturers because they will only need to implement cod= e for a single standard defined interface.] Paul 2) Discovery services like LoST are based on location, but the device's rel= ationship with a database service is not known or considered. While it may = seem simple to configure LoST or similar service to point to a database ser= vice based on location, how do you point to the one that the customer has a= relationship with, for example, paid to use? I do realize that this may no= t be an issue in every country. 3) If PAWS defines a globally applicable discovery process and either picks= an existing protocol (like LoST) or designs one, most likely it would incl= ude a centrally based discovery service. What entity will be responsible fo= r hosting and configuring the central discovery service? How will PAWS defi= ne this as a global solution, and deal with the politics between countries? 4) Some radio manufacturers do not have very much ROM to include even more = code on their device. I'm concerned that discovery will consume even more s= pace on the radio, space that they may not even have. 5) I believe that defining discovery will take more time than defining the = protocol between the WSDB and WSD. I think that database discovery should be left to each country to define ba= sed on their own requirements and Whitespace ecosystem. Regards, Don From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of Das, Subir Sent: Tuesday, April 17, 2012 5:26 PM To: paws@ietf.org Subject: [paws] Database Discovery Question During PAWS session in Paris IETF, there were a lot of questions/discussion= s on 'Discovery' of Database. It was not clear to me except if we are talki= ng about "Database Server Discovery", in particular, the domain name or the= IP address of the 'Server" that is hosting the database. OTH, I felt that = some folks may have different views and they would possibly like to see mor= e features than just discovering the domain name or IP address of the "Data= base Server". In some offline discussions, I was told that it may be similar to what LOST= (RFC 5222) has defined. I read the LOST protocol and associated architectu= re and my current understanding is that the LOST use case is different than= what we are trying to achieve via PAWS. Here is my understanding of the op= erating model of PAWS interface (when defined): -"Fixed/Mode II WSD" (per figure 1,) can only q= uery the database -The manufacturer of the "Fixed/Mode II WSD" may be different than owner/op= erator of this device -"Fixed/Mode II WSD" is certified by the regulatory body of the region that= they serve - Either the "Fixed/Mode II WSD" device operator or the device vendor has a= n a-priori relationship with one or more covering database administrators. = This relationship is utilized to either configure or enable the discovery of the proper data= base to contact in the current location I would like to know the group's view of the above model. To me, finding th= e emergency services or restaurant information near my location is differen= t than getting to know a server that can provide me with channel/frequency/= power and other information in the location where "Fixed/Mode II WSD" is si= tuated. In addition, emergency services do not require a subscription and t= he service is mandated by the Government/regulatory bodies. Some may argue = that 'White Space' service may be free as well, but to my understanding it = is not quite the similar model as emergency services. I hope with this thread we can clarify/understand the discovery issue. Regards, _Subir --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E817E3008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Don,=

As chair, I’ll h= ave to ask you to stop arguing against a database discovery protocol. That = is clearly within the scope for the wg, as the charter says:

“Objectives=

The overall goals of t= his working group are to:

1.&n= bsp;      Standardize a = mechanism for discovering a white space database.” and it doesn’= ;t mention the optionality.

ietf is contribution d= riven, if you are not interested in the discovery, then you do not need to = contribute to it. But do not try to persuade the wg to not work on a piece = which is in charter and folks are willing to do; that is not how ietf works.

-&nb= sp;         Gabor

From: paws-bou= nces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Don Joslyn
Sent: Friday, April 20, 2012 12:21 PM
To: Paul Lambert; Das, Subir; paws@ietf.org
Subject: Re: [paws] Database Discovery Question

See reply below.<= /o:p>

Don<= /p>

From: Paul Lam= bert [mailto:paul@marvell.com] =
Sent: Thursday, April 19, 2012 2:36 PM
To: Don Joslyn; Das, Subir; paws@ie= tf.org
Subject: RE: [paws] Database Discovery Question

Paul A. Lambert | Marv= ell | +1-650-787-9141

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Don Joslyn
Sent: Thursday, April 19, 2012 10:31 AM
To: Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question

I don't think PAWS should define discovery, I thi= nk the protocol should simply start after a device has "found" th= e correct database to use.

I feel this way for many reasons:

1) In the US, a radio is certified to work with o= ne or more specific databases. So the device will be pre-configured to cont= act specific databases, no need to implement a discovery service. If the de= vice is programmed to work with more than one database provider, the device owner will configure which one to u= se based on the relationship that they have established with the database p= rovider (for example, which one they are paying to use).

When new databases com= e online, users would likely appreciate an option to connect to a system ad= ditional services or perhaps lower prices for the service.

[Don – Yes, this= may be desired, but can the device immediately take advantage of these new= database records and decide on its own to use a new one that has a lower cost? I would think that the device owner still needs to decid= e to use the lower cost service (may even have to consider why it costs les= s), pay for the service, and then configure the device to use it. I’m= not sure how this can automatically happen between the discovery service and WSD. Will cost considerations be part of= the discovery solution? Is it cost per month, year, lifetime, message coun= t, etc? You mentioned cost, but there can be many other parameters that can= influence the selection outcome (SLA, features, etc.), where will we stop?]

If we go strictly on t= he preconfiguration model … we don’t even need PAWS. The = relationship you describe would have defined all the interfaces. If w= e are in the business of having open interfaces, we need to provide a means to d= iscocovery and select DBs.

[Don – I donR= 17;t agree with the all-or-nothing argument, using discovery is optional (p= er PAWS requirements). Establishing a standard protocol between WSDB and WSD is still valuable because, for example, will can still lower the c= ost to device manufacturers because they will only need to implement code f= or a single standard defined interface.]

Paul=

2) Discovery services like LoST are based on loca= tion, but the device's relationship with a database service is not known or= considered. While it may seem simple to configure LoST or similar service = to point to a database service based on location, how do you point to the one that the customer has a relations= hip with, for example, paid to use? I do realize that this may not be an is= sue in every country.

3) If PAWS defines a globally applicable discover= y process and either picks an existing protocol (like LoST) or designs one,= most likely it would include a centrally based discovery service. What ent= ity will be responsible for hosting and configuring the central discovery service? How will PAWS define this a= s a global solution, and deal with the politics between countries?

4) Some radio manufacturers do not have very much= ROM to include even more code on their device. I'm concerned that discover= y will consume even more space on the radio, space that they may not even h= ave.

5) I believe that defining discovery will take mo= re time than defining the protocol between the WSDB and WSD.

I think that database discovery should be left to= each country to define based on their own requirements and Whitespace ecos= ystem.

Regards,

Don

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Das, Subir
Sent: Tuesday, April 17, 2012 5:26 PM
To: paws@ietf.org
Subject: [paws] Database Discovery Question

During PAWS session in Paris IETF, there were a l= ot of questions/discussions on 'Discovery' of Database. It was not clear to= me except if we are talking about "Database Server Discovery", i= n particular, the domain name or the IP address of the 'Server" that is hosting the database. OTH, I felt that some f= olks may have different views and they would possibly like to see more feat= ures than just discovering the domain name or IP address of the "Datab= ase Server".

In some offline discussions, I was told that it m= ay be similar to what LOST (RFC 5222) has defined. I read the LOST protocol= and associated architecture and my current understanding is that the LOST = use case is different than what we are trying to achieve via PAWS. Here is my understanding of the operating = model of PAWS interface (when defined):

-"Fixed/Mode II WSD" (per figure 1,<= draft-das-paws-protocol-01>) can only query the database

-The manufacturer of the "Fixed/Mode II WSD&= quot; may be different than owner/operator of this device

-"Fixed/Mode II WSD" is certified by th= e regulatory body of the region that they serve

- Either the "Fixed/Mode II WSD" device= operator or the device vendor has an a-priori relationship with one or mor= e covering database administrators. This relationship

is utilized to either configure or enable t= he discovery of the proper database to contact in the current location=

I would like to know the group's view of the abov= e model. To me, finding the emergency services or restaurant information ne= ar my location is different than getting to know a server that can provide = me with channel/frequency/power and other information in the location where "Fixed/Mode II WSD" is s= ituated. In addition, emergency services do not require a subscription and = the service is mandated by the Government/regulatory bodies. Some may argue= that 'White Space' service may be free as well, but to my understanding it is not quite the similar model as emergen= cy services.

I hope with this thread we can clarify/understand= the discovery issue.

Regards,

_Subir

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E817E3008AM1MPN1006mg_-- From presnick@qualcomm.com Fri Apr 20 15:02:33 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5ABB21E8039 for ; Fri, 20 Apr 2012 15:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.571 X-Spam-Level: X-Spam-Status: No, score=-106.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jxT-8mmyJcLH for ; Fri, 20 Apr 2012 15:02:32 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by ietfa.amsl.com (Postfix) with ESMTP id 525EF21E8012 for ; Fri, 20 Apr 2012 15:02:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=presnick@qualcomm.com; q=dns/txt; s=qcdkim; t=1334959352; x=1366495352; h=message-id:date:from:user-agent:mime-version:to:cc: subject:references:in-reply-to:content-type: content-transfer-encoding:x-originating-ip; bh=2o31bX0CdqQH31uD7DDJFCA7+SGLlcshwWgpNkeZrN4=; b=R9pKjYqsRKEbSOLqgoA2SXdJCj1NLFJECZurr+0utpP7mZIWnG1EFgUq kBZR9pwEuuoll9Y0hJLXs3QZ2osKJxpo8zMxf1r6Prt9Mq3v1sxQ2eXDP MM7nMBc9gDL/KXfRWsMrE1zMI/wDOaGdWQVcd6NskREzoi5HPml2rxJSN A=; X-IronPort-AV: E=McAfee;i="5400,1158,6687"; a="183670746" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine01.qualcomm.com with ESMTP; 20 Apr 2012 15:02:31 -0700 X-IronPort-AV: E=Sophos;i="4.75,453,1330934400"; d="scan'208";a="223346212" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 20 Apr 2012 15:02:31 -0700 Received: from resnick2.qualcomm.com (172.30.48.1) by qcmail1.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.2.283.3; Fri, 20 Apr 2012 15:02:30 -0700 Message-ID: <4F91DCF4.1020500@qualcomm.com> Date: Fri, 20 Apr 2012 17:02:28 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Gerald Chouinard References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E694A9@008-AM1MPN1-001.mgdnok.nokia.com><4F84D8FF.9010509@stpeter.im><1ECAFF543A2FED4EA2BEB6CACE08E47601E731B0@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601E75E57@008-AM1MPN1-001.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F714140945F4C87@EMV62-UKRD.domain1.systemhost.net> <4F8D7361.40803@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.48.1] Cc: paws@ietf.org Subject: Re: [paws] charter update X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Apr 2012 22:02:33 -0000 Hi Gerald, On 4/19/12 10:01 PM, Gerald Chouinard wrote: > The "anticipated usage" describes the response that the WSD will make in a > transitional state when it initiates its operation after having queried the > database. > Actually, no. The "anticipated usage" (or, again, perhaps "intended usage") describes the response that the radio device will make *whenever* it queries the database. Whether it does this as a transitional state when it initiates its operation or at a later time in order to refresh is completely an implementation detail. As far as the protocol is concerned, the response is about which of frequencies it intends to use given what the WSD has reported. > However, since the regulatory bodies in different countries will require > that the WSD queries the database on a regular basis (e.g., within 24 hours > in the USA), the question is whether the WSD will need to send its spectrum > occupation after every query, even if it has not changed (i.e., the behavior > in a steady-state). No, this is absolutely irrelevant. This is outside of the protocol operation and is strictly about the semantics of the use of the protocol. It does not effect what the protocol will require. > If this is not needed, then the term "anticipated usage" > would be appropriate since the WSD would only respond when it changes its > spectrum occupation (however, see paragraph below). If a confirmation is > needed every time, then in most of the cases, the WSD would report its > current spectrum usage and only when it happens to change its usage would it > nee to report its "anticipated usage". if it has not already re-tuned to the > new allowed channel before it sends its report to the database. > The server cannot tell the difference between "I have queried to refresh; I've been using this WS and intend to continue to do so" versus "I had stopped using this WS some time ago and I am making a new request for WS; here's what I intend to use now" versus "I am requesting WS for the first time; here is what I intend to use". It is protocol-irrelevant which case is being used. > My guess is that since it will need to free the channel that it was > operating on and that is no longer available as soon as possible to avoid > interference, it will likely re-tune right away and not wait for the report > to be sent to the database over the internet before re-tuning (my guess is > this would be done over TCP with proper transmission confirmation rather > than UDP). In such case, it would then report on its "actual usage" rather > than the "anticipated usage". > > As you can see, this depends on what is being assumed as the process taking > place at the WSD when it queries the database. Once this is clearly > understood, it will be to the group to decide. > I simply disagree with your assessment. If the group thinks that you will (potentially) need to work on a separate protocol piece for notifications of current usage, I think you should add that to the proposed charter changes. But I don't see a need for that protocol requirement. It seems to me that all of the functionality can be satisfied with a response after receiving the list of WS indicating intended usage. pr > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pete > Resnick > Sent: Tuesday, 17 April, 2012 09:43 > To: andy.sago@bt.com > Cc: paws@ietf.org > Subject: Re: [paws] charter update > > Folks, > > 1. As was said by others, "anticipated" is correct. The change in the > charter was not to include a constant dynamic update to the database of > what the device is currently using, but a one-time immediate report of > what the device intends to use. If you prefer "intended" to > "anticipated", that is also fine, but we have *not* discussed the > possibility of writing the protocol to have an update mechanism to > inform the database of the current actual usage. If that's needed, we > should further discuss. > > 2. I should repeat the admonition I made at the meeting in Paris: We are > *not* writing regulatory requirements into the protocol. We are writing > the protocol to have enough flexibility to satisfy regulatory > requirements. I am quite sure if we asked Ofcom whether they wanted > "anticipated usage" or "actual usage" in the protocol, they'd say > "actual usage", but that is entirely the wrong question to be asking and > we'd be getting a bogus answer. If the regulatory requirement we are > trying to make sure we are able to cover is "a single report by the > device of which spectrum it will be using", then "anticipated" is our > design requirement. Regulators (like end users in general) are not > protocol designers and the language they use for requirements should not > be used in our charter or protocol documents. We need to interpret what > their high-level requirements mean for our protocol and use language > within our documents (including our charter) that makes sense for a > protocol. > > So, my question to the list: > > Does anybody think we need to have the device constantly report back to > the database about its current usage? > > If I don't hear from anybody, I'm going to assume that this is *not* > needed and that the correct charter update to submit to the IESG should > have "anticipated" or "intended". > > pr > > On 4/16/12 5:13 AM, andy.sago@bt.com wrote: > >> Gabor >> >> Like Gerald, I am uneasy with the use of the word "anticipated". We can >> > ask Ofcom, but I am sure they will just point us to their regulatory > requirements which use phrasing like "a master WSD must communicate to the > WSDB the following information: .... The lower and upper frequency > boundaries of the in-block emissions.... The maximum in-block EIRP spectral > densities (in dBm/(0.2 MHz)) that the master WSD, and its associated slaves, > actually radiate ....". So their regulatory requirements are for actual > usage, not anticipated. It may be foolish for the group to agree charter > text that says something different. Can we just delete the word > "anticipated" in the new bullet 5? The word order could be changed to" > Report spectrum usage to the white space database at a suitable > granularity". > >> Andy >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> > Gerald Chouinard > >> Sent: 15 April 2012 18:40 >> To: Gabor.Bajko@nokia.com >> Cc: presnick@qualcomm.com; paws@ietf.org >> Subject: Re: [paws] charter update >> >> Gabor, >> >> I am wandering is the word "anticipated" will be good enough for OFCOM. >> > You may want to verify with them. To establish a status of the spectrum > usage in an area, the regulator will likely need the actual usage of this > spectrum and not only its "anticipated" usage. > >> My two cents ... >> >> Gerald >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> > Gabor.Bajko@nokia.com > >> Sent: Friday, 13 April, 2012 16:31 >> To: stpeter@stpeter.im; presnick@qualcomm.com >> Cc: paws@ietf.org >> Subject: Re: [paws] charter update >> >> Pete, Peter, >> >> There doesn't seem to be any objection to this charter update text on the >> > list from the WG members. Could you guys take this charter proposal text to > the iesg's telechat? > >> Thanks, Gabor >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> > Bajko Gabor (Nokia-CIC/SiliconValley) > >> Sent: Wednesday, April 11, 2012 1:02 PM >> To: stpeter@stpeter.im >> Cc: paws@ietf.org >> Subject: Re: [paws] charter update >> >> Here's the charter update proposal text: >> http://www.ietf.org/proceedings/83/slides/slides-83-paws-4.txt >> >> According to diff, the are 6 lines changed, including the update to the >> > milestones. The main change is adding bullet point 5: " Report to the white > space database anticipated spectrum usage at a suitable granularity." > >> - Gabor >> >> >> -----Original Message----- >> From: ext Peter Saint-Andre [mailto:stpeter@stpeter.im] >> Sent: Tuesday, April 10, 2012 6:06 PM >> To: Bajko Gabor (Nokia-CIC/SiliconValley) >> Cc: paws@ietf.org >> Subject: Re: [paws] charter update >> >> On 4/9/12 3:40 PM, Gabor.Bajko@nokia.com wrote: >> >> >>> Folks, >>> >>> There was long discussion on the list before the Paris F2F about the >>> newly surfaced Ofcom requirements, which require the master devices to >>> report back to the wsdb the spectrum chosen for operation. Since this >>> aspect is not captured in the current charter, during the F2F we >>> discussed how to capture those requirements and there was no objection >>> to a slight charter update. >>> >>> The tentative charter update text I showed in slide 7 of >>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx had >>> one objection to the text added as a 5^th bullet point: "5. Report >>> back to the white space database use information, including the chosen >>> channels for operation and other relevant information", noting that >>> the result may be a chatty behavior in case of frequency hopping (see >>> the >>> >>> >> minutes). >> >> >>> The new proposal would be to replace the text in bullet 5 with "Report >>> to the white space database anticipated spectrum usage at a suitable >>> granularity." This text seem to be fine with Joel, who raised the >>> >>> >> objection. >> >> >>> I hope there is consensus in the wg for this new wording for the >>> charter update text. If there is no objection on the list to this >>> newly proposed text in the next few days, I would ask our AD to take >>> the proposed charter update text in slide 7 of >>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx, with >>> the new text for bullet 5, to the iesg. >>> >>> >> Hi Gabor, >> >> Would you be so kind as to send the actual text to the list? That will >> > make it easier for people to track the changes, search on this thread, etc. > >> Thanks! >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From Gabor.Bajko@nokia.com Fri Apr 20 15:35:15 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D36721E8039 for ; Fri, 20 Apr 2012 15:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 auVYl+6w7Tcr for ; Fri, 20 Apr 2012 15:35:07 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8EA11E8086 for ; Fri, 20 Apr 2012 15:35:07 -0700 (PDT) Received: from vaebh104.NOE.Nokia.com (in-mx.nokia.com [10.160.244.30]) by mgw-da02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3KMYl73023960; Sat, 21 Apr 2012 01:34:48 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.59]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Apr 2012 01:34:46 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.85]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi id 14.02.0283.004; Sat, 21 Apr 2012 00:34:46 +0200 From: To: Thread-Topic: [paws] identity verification (was: Database Discovery Question) Thread-Index: Ac0eZQTbSgaeGcPfQOKDbU23fUOLZgADjImAAADsQkAAHXx2AAASI/0w///rEQD//9Mj8A== Date: Fri, 20 Apr 2012 22:34:45 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E81892@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E77FC9@008-AM1MPN1-001.mgdnok.nokia.com> <5963DDF1F751474D8DEEFDCDBEE43AE716456BC0@dfweml503-mbx> <1ECAFF543A2FED4EA2BEB6CACE08E47601E78109@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601E7E79B@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.124.61] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E81892008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 20 Apr 2012 22:34:46.0769 (UTC) FILETIME=[CA1C9E10:01CD1F45] X-Nokia-AV: Clean Cc: paws@ietf.org, Peter.McCann@huawei.com Subject: Re: [paws] identity verification (was: Database Discovery Question) X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Apr 2012 22:35:15 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E81892008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave, I don't read it that way. What that paragraph tells me is that the= FFC ID is sent to the db which checks it against a white list to determine= if a device with the presented FCCID was certified for white spaces operat= ion. But maybe some other folks more intimately familiar with FCC intentions cou= ld clarify. - Gabor From: wtr486@motorola.com [mailto:wtr486@motorola.com] On Behalf Of ext Dav= e Halasz Sent: Friday, April 20, 2012 2:23 PM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: Peter.McCann@huawei.com; Brian.Rosen@neustar.biz; paws@ietf.org Subject: Re: [paws] identity verification (was: Database Discovery Question= ) Hi Gabor, I'm confused by your second sentence. My read of paragraph 98 indicates the= regulators do require a crypto binding. Of course, my interpretation can b= e wrong. Pasting in the section that has me concerned. "To achieve the necessary protection of databases and connections between devices and databases regarding channel availability, we are requiring that= TV bands devices and database systems employ security measures as follows. First, we are requir= ing that, for purposes of obtaining a list of available channels and related matters, fixed and Mo= de II TVBDs only be capable of contacting databases operated by administrators designated by th= e Commission. This will prevent TV bands devices from obtaining channel lists from unauthorize= d databases which may be invalid or inaccurate - we are particularly concerned about potenti= al cases where a database would indicate as available channels that are used by authorized s= ervices. We also are specifying that TV bands databases must not provide lists of available chan= nels to uncertified TV bands devices for purposes of operation (it is acceptable for a TV bands da= tabase to distribute lists of available channels by means other than contact with TVBDs) in orde= r to avoid facilitating the operation of unapproved and non-compliant devices. To facilitate these= restrictions, we are requiring that database(s) verify that the FCC identification number (FCC I= D) supplied by a fixed or personal/portable TV bands device is for a certified device. To i= mplement this provision, we are also requiring that database administrators obtain a list= of certified TVBDs from our Equipment Authorization System." In particular, the following sentence, "To facilitate these restrictions, we are requiring that database(s) verify that the FCC identification number (FCC I= D) supplied by a fixed or personal/portable TV bands device is for a certified device." To me, it sounds like they do want a binding of the FCC ID to the hardware. Dave H. On Fri, Apr 20, 2012 at 4:44 PM, > wrote: Sure, and I don't think anyone said otherwise. The point we were debating is how to make sure the slave (mode 1) devices d= id not spoof their identity. Since regulators do not require the slave devi= ces to have a crypto binding between the identifier and the hardware, the m= aster who authenticates the slave using some other existing credentials, ha= s no choice but to trust the slave will not spoof its identity. - Gabor From: wtr486@motorola.com [mailto:wtr486@motoro= la.com] On Behalf Of ext Dave Halasz Sent: Friday, April 20, 2012 6:58 AM To: Bajko Gabor (Nokia-CIC/SiliconValley) Cc: Peter.McCann@huawei.com; Brian.Rosen@ne= ustar.biz; paws@ietf.org Subject: Re: [paws] identity verification (was: Database Discovery Question= ) My reading of paragraph 98 of FCC-10-174A1 indicates that regulators do req= uire verification of the FCC-ID of Mode 1 devices by the database(s). http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-10-174A1.pdf Dave H. > Afaik, regulators do not require for client certs binding the > identifier to the hardware. Therefore, the verification of whether the > identifier is the correct one or not seems to be outside the scope of > paws. The master should rely on the lower layers and the DB for this > verification. This statement really confuses me. To me, a binding of an identifier to ha= rdware means that there is some tamper and copy-proof storage for a private= key epoxied into the wireless hardware. This private key would be used to= authenticate & distribute keying material for a secure channel between the= slave and the master. That part is indeed out of scope of PAWS, but the m= aster-to-database messages to validate the slave's credentials are not. I think the confusion might come that you assume the private key in th= e slave (if existed at all) would also be used to authenticate the slave to= the master. In my understanding that would not necessarily be the case. Ev= en if there was a private key in the slave, the slave would acquire another= set of (eg username/password) credentials, independent of the private key,= to connect to the master device. On Thu, Apr 19, 2012 at 6:14 PM, > wrote: Hi Pete, My responses inline: -----Original Message----- From: ext Peter McCann [mailto:Peter.McCann@huawei.com] Sent: Thursday, April 19, 2012 2:42 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); Brian.Rosen@neustar.biz Cc: paws@ietf.org Subject: RE: identity verification (was: Database Discovery Question) Hi, Gabor, Gabor.Bajko@nokia.com wrote: > Hi Pete, > > Some comments inline: > > > -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-b= ounces@ietf.org] On Behalf >> Of ext Peter McCann >> Sent: Wednesday, April 18, 2012 9:02 AM >> To: Rosen, Brian >> Cc: paws@ietf.org >> Subject: Re: [paws] Database Discovery Question >> >> Hi, Brian, >> >> The problem is, the master device cannot be authoritative on whether >> the slave device is approved for use by the regulator. It must rely >> on the WSDB it uses (has a relationship with) to tell it. >> >> At the least, we need a format for device identifiers that can be >> understood by multiple independently operated databases. >> > yes, this should be part of the data model. Agreed. >> Maybe the WSDB trusts the master device to collect this information >> securely from the slave devices using slave-to-master credentials. >> > yes, this is what at least the 802.11af draft amendment is > currently defining for the 802.11 air interface. The slave sends its > identifier to the master, then waits for the enablement signal. The > enablement signal comes after the master was able to successfully > validate the identifier of the slave with the DB. Is there any security or spoofing protection defined in 802.11af? It inherits whatever is in the 802.11 base spec, ie .1x >> Normally, the allocation authority for the identifier space would be >> a trust anchor for the identifier-to-device binding. I agree that >> the master-to-slave interface is out of scope, but there should be >> some mechanism in the marketplace for the master device operator to >> securely bind the identifier presented by the slave to the >> communication channel with the slave device, in the sense that the >> master device is able to know in a secure way that the device it is >> talking to actually does own the regulator-assigned device >> identifier. It seems natural for the master device to rely on its >> relationship with a database to help with this binding. >> > I see two things here: binding between the communication channel > and identity; and binding between the identity and the hardware to > which it was assigned. The binding between the communication channel > and the identity as presented by slave is there inherently in the > radio. I don't understand this last statement. Do you mean a cryptographically se= cure binding? What if I spoof my MAC address? Assuming an RSN network, after the .1x procedure, there is a key deriv= ed to encrypt the STA to AP communication. 802.11af does not assume that the credentials the slave has to get authenti= cated with the master can in any way be used to prove the ownership of the = identity. There's a set of credentials for slave-master authentication, and= there might be (currently there is no requirement for it) another mechanis= m for the slave to prove to the db that it owns the identity it sent to the= master. > The task to verify that the identity indeed belongs to the slave > should not be the burden of the master device, rather the DB (if seen > necessary). In order for the DB to verify that the presented > identifier indeed belongs to that device, a client cert or sg similar > would be needed. That seems reasonable to me. The slave device has a client cert and someho= w demonstrates knowledge of the private key that goes with the cert to the = database. After this, the database can send "I approve" to the master device. Assuming that both communication channels (slave to = master and master to database) have been authenticated and secured, the mas= ter can then tell the slave to go ahead. However, we now require the database be able to validate the credentials of= any slave device that may be manufactured/owned by someone other than the = manufacturer/owner of the master device. It would seem we need a nationall= y-scoped trust anchor to achieve this. I think this is the part which is outside the scope of our charter, wh= ich says: " 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. ". Th= ere is no mention about the db making sure the slave devices did not spoof = their identity. Especially as regulators do not require slave devices to ha= ve a mechanism to be able to prove ownership of the identity. If I remember= correctly, this was considered in FCC, but then the requirement was droppe= d. > Afaik, regulators do not require for client certs binding the > identifier to the hardware. Therefore, the verification of whether the > identifier is the correct one or not seems to be outside the scope of > paws. The master should rely on the lower layers and the DB for this > verification. This statement really confuses me. To me, a binding of an identifier to ha= rdware means that there is some tamper and copy-proof storage for a private= key epoxied into the wireless hardware. This private key would be used to= authenticate & distribute keying material for a secure channel between the= slave and the master. That part is indeed out of scope of PAWS, but the m= aster-to-database messages to validate the slave's credentials are not. I think the confusion might come that you assume the private key in th= e slave (if existed at all) would also be used to authenticate the slave to= the master. In my understanding that would not necessarily be the case. Ev= en if there was a private key in the slave, the slave would acquire another= set of (eg username/password) credentials, independent of the private key,= to connect to the master device. - Gabor -Pete > > - Gabor > > > > -Pete > > Rosen, Brian wrote: >> > this thread> The credentialling system used between the database >> server and its client (the master) are those of its client. The >> database trusts its client. >> >> The client (the master) may need its customer, the slave, to present >> credentials for service. >> >> This means we assume transitive trust on the ID information from the >> client. The master validates the slave, the database validates the >> master. I would not advocate trying to make anything more complex. >> >> Brian >> >> On Apr 18, 2012, at 11:16 AM, Peter McCann wrote: >> >>> Right, the master queries the database on behalf of the slave, >>> sending the slave's Device ID and location. (See Don's message >>> about validating the FCC ID). My question is, what is the security >>> model for validating the slave's ID? Is there a secure credential >>> associated with the ID, or is it an insecure check of a number >>> against a whitelist? If the former, we will need a credential >>> management system that is able to cross between different databases. >>> If the latter, I wonder if it opens up security problems. >>> >>> -Pete >>> >>> Rosen, Brian wrote: >>>> Perhaps I am confused, but I think in a master/slave environment, >>>> the slave does not query the database, the master does. The slave >>>> gets its allowed spectrum data from the master. There is always >>>> the question of whether the master queries on its own behalf and >>>> the slaves just get assignments within that database response, or >>>> whether the master queries on behalf of the slaves. Might have to >>>> support both models. In many cases, I think it's the latter: the >>>> master queries using the slaves location and parameters. >>>> >>>> The most common master/slave setup is tower and clients, right? >>>> The tower has an Internet connection and can query the database. >>>> The clients of the tower are the slaves. Does the database query >>>> use the location and type data of the slave or the master? >>>> >>>> Brian >>>> >>>> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote: >>>> >>>>> I think it would be a mistake to assume that the slave & master >>>>> devices both have pre-existing relationships with the same database. >>>>> In a commercial service, the slave devices would all come from >>>>> different manufacturers and would certainly have different owners. >>>>> Wouldn't we want them to interoperate with any master device, >>>>> assuming they are RF-compatible? >>>>> >>>>> -Pete >>>>> >>>>> Rosen, Brian wrote: >>>>>> Doesn't the slave get it's database access through the master? >>>>>> If that's true, the problem you are worried about doesn't exist. >>>>>> >>>>>> Brian >>>>>> >>>>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote: >>>>>> >>>>>>> I agree with Brian that LoST could be a good model for >>>>>>> discovering the appropriate database for the region you're in. A >>>>>>> nation may decide to subdivide their territory into provinces or >>>>>>> states, each of which maintains its own database. >>>>>>> >>>>>>> I think it would be a mistake to assume that there is a single, >>>>>>> pre-defined relationship for one device with just one database. >>>>>>> In particular, I think there is a thorny issue that will arise >>>>>>> with management of secure credentials on whitespace devices, >>>>>>> illustrated by the first use case in Section 4.2.1 of >>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03. Step 9 of that >>>>>>> use case says: >>>>>>> >>>>>>> 9. Once the master/AP has met all regulatory domain >> requirements >>>>>>> (e.g. validating the Device ID with the trusted database, >>>>>>> etc) the master provides the list of channels locally >>>>>>> available to the slave/user device. >>>>>>> My question is, what if the master device has a relationship >>>>>>> with one database, but the slave device has a relationship with >>>>>>> another? How is the master's database supposed to validate the >>>>>>> credentials of the slave device, if we don't have some sort of >>>>>>> common trust anchor? Or will this "validation" be simply an >>>>>>> insecure check of an ID against a whitelist/blacklist? Who will >>>>>>> allocate Device IDs? Will they be specific to a particular >>>>>>> database operator, or do we need some common top-level >>>>>>> allocation format? >>>>>>> >>>>>>> -Pete >>>>>>> >>>>> >>>>> >>>>> >>> >>> >>> > > > > _______________________________________________ > 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_1ECAFF543A2FED4EA2BEB6CACE08E47601E81892008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave, I don’t re= ad it that way. What that paragraph tells me is that the FFC ID is sent to = the db which checks it against a white list to determine if a device with the presented FCCID was certified for white spaces operation.<= o:p>

But maybe some other folk= s more intimately familiar with FCC intentions could clarify.

- =          Gabor<= /span>

<= /p>
<= /p>
From: wtr486@m= otorola.com [mailto:wtr486@motorola.com] On Behalf Of ext Dave Halasz
Sent: Friday, April 20, 2012 2:23 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: Peter.McCann@huawei.com; Brian.Rosen@neustar.biz; paws@ietf.org<= br> Subject: Re: [paws] identity verification (was: Database Discovery Q= uestion)

Hi Gabor,

I'm confused by your second sentence. My read of paragraph 98 indicates the= regulators do require a crypto binding. Of course, my interpretation can b= e wrong. Pasting in the section that has me concerned.

"To achieve the necessary protection of databas= es and connections between
devices and databases regarding channel availability, we are requiring that= TV bands devices and
database systems employ security measures as follows. First, we are r= equiring that, for purposes
of obtaining a list of available channels and related matters, fixed and Mo= de II TVBDs only be
capable of contacting databases operated by administrators designated by th= e Commission. This
will prevent TV bands devices from obtaining channel lists from unauthorize= d databases which
may be invalid or inaccurate – we are particularly concerned ab= out potential cases where a
database would indicate as available channels that are used by authorized s= ervices. We also are
specifying that TV bands databases must not provide lists of available chan= nels to uncertified TV
bands devices for purposes of operation (it is acceptable for a TV bands da= tabase to distribute
lists of available channels by means other than contact with TVBDs) in orde= r to avoid facilitating
the operation of unapproved and non-compliant devices. To facilitate = these restrictions, we are
requiring that database(s) verify that the FCC identification number (FCC I= D) supplied by a
fixed or personal/portable TV bands device is for a certified device. = To implement this
provision, we are also requiring that database administrators obtain a list= of certified TVBDs
from our Equipment Authorization System."

In particular, the following sentence,

"To facilitate these restrictions, we are
requiring that database(s) verify that the FCC identification number (FCC I= D) supplied by a
fixed or personal/portable TV bands device is for a certified device."=

To me, it sounds like they do want a binding of the FCC ID to the hardware.=

Dave H.

On Fri, Apr 20, 2012 at 4:44 PM, <Gabor.Bajko@nokia.com> wrote:

Sure, and I don’t think anyone sa= id otherwise.

The point we were debating is how to ma= ke sure the slave (mode 1) devices did not spoof their identity. Since regulators do not require the slave devices to have a crypto binding= between the identifier and the hardware, the master who authenticates the = slave using some other existing credentials, has no choice but to trust the= slave will not spoof its identity.

-          Gabor

From: wtr486@motorola.co= m [mailto:wtr4= 86@motorola.com] On Behalf Of ext Dave Halasz
Sent: Friday, April 20, 2012 6:58 AM
To: Bajko Gabor (Nokia-CIC/SiliconValley)
Cc: Pet= er.McCann@huawei.com; Brian.Rosen@ne= ustar.biz; paws@ietf.org
Subject: Re: [paws] identity verification (was: Database Discovery Q= uestion)

My reading of paragraph 98 of FCC-10-174A1 indicates that regulators do = require verification of the FCC-ID of Mode 1 devices by the database(s). http://hraunfoss.fcc.gov/edocs_public/attachmatch/F= CC-10-174A1.pdf

Dave H.

> Afaik, regulators do not require for client certs binding the
> identifier to the hardware. Therefore, the verification of whether the=
> identifier is the correct one or not seems to be outside the scope of<= br> > paws. The master should rely on the lower layers and the DB for this > verification.

This statement really confuses me. To me, a binding of an identifier = to hardware means that there is some tamper and copy-proof storage for a pr= ivate key epoxied into the wireless hardware. This private key would = be used to authenticate & distribute keying material for a secure channel between the slave and the master. That= part is indeed out of scope of PAWS, but the master-to-database messages t= o validate the slave's credentials are not.

<GB> I think the confusion might come that you assume the private key= in the slave (if existed at all) would also be used to authenticate the sl= ave to the master. In my understanding that would not necessarily be the ca= se. Even if there was a private key in the slave, the slave would acquire another set of (eg username/password) c= redentials, independent of the private key, to connect to the master = device.

On Thu, Apr 19, 2012 at 6:14 PM, <Gabor.Bajko@nokia.com> wrote:

Hi Pete,
My responses inline:

-----Original Message-----
From: ext Peter McCann [mailto:Peter.McCann@huawei.com]
Sent: Thursday, April 19, 2012 2:42 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); Brian.Rosen@neustar.biz
Cc: paws@ietf.org Subject: RE: identity verification (was: Database Discovery Question)

Hi, Gabor,

Gabor.Bajko@noki= a.com wrote:
> Hi Pete,
>
> Some comments inline:
>
>
> -----Original Message-----
>> From: p= aws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf
>> Of ext Peter McCann
>> Sent: Wednesday, April 18, 2012 9:02 AM
>> To: Rosen, Brian
>> Cc: paws@ietf.o= rg
>> Subject: Re: [paws] Database Discovery Question
>>
>> Hi, Brian,
>>
>> The problem is, the master device cannot be authoritative on wheth= er
>> the slave device is approved for use by the regulator. It mu= st rely
>> on the WSDB it uses (has a relationship with) to tell it.
>>
>> At the least, we need a format for device identifiers that can be<= br> >> understood by multiple independently operated databases.
>>
> <GB> yes, this should be part of the data model.

Agreed.

>> Maybe the WSDB trusts the master device to collect this informatio= n
>> securely from the slave devices using slave-to-master credentials.=
>>
> <GB> yes, this is what at least the 802.11af draft amendment is<= br> > currently defining for the 802.11 air interface. The slave sends its > identifier to the master, then waits for the enablement signal. The > enablement signal comes after the master was able to successfully
> validate the identifier of the slave with the DB.

Is there any security or spoofing protection defined in 802.11af?

<GB> It inherits whatever is in the 802.11 base spec, ie .1x=

>> Normally, the allocation authority for the identifier space would = be
>> a trust anchor for the identifier-to-device binding. I agree= that
>> the master-to-slave interface is out of scope, but there should be=
>> some mechanism in the marketplace for the master device operator t= o
>> securely bind the identifier presented by the slave to the
>> communication channel with the slave device, in the sense that the=
>> master device is able to know in a secure way that the device it i= s
>> talking to actually does own the regulator-assigned device
>> identifier. It seems natural for the master device to rely on its<= br> >> relationship with a database to help with this binding.
>>
> <GB> I see two things here: binding between the communication ch= annel
> and identity; and binding between the identity and the hardware to
> which it was assigned. The binding between the communication channel > and the identity as presented by slave is there inherently in the
> radio.

I don't understand this last statement. Do you mean a cryptographical= ly secure binding? What if I spoof my MAC address?

<GB> Assuming an RSN network, after the .1x procedure, there= is a key derived to encrypt the STA to AP communication.
802.11af does not assume that the credentials the slave has to get authenti= cated with the master can in any way be used to prove the ownership of the = identity. There's a set of credentials for slave-master authentication, and= there might be (currently there is no requirement for it) another mechanism for the slave to prove to the = db that it owns the identity it sent to the master.

> The task to verify that the identity indeed belongs to the slave
> should not be the burden of the master device, rather the DB (if seen<= br> > necessary). In order for the DB to verify that the presented
> identifier indeed belongs to that device, a client cert or sg similar<= br> > would be needed.

That seems reasonable to me. The slave device has a client cert and s= omehow demonstrates knowledge of the private key that goes with the cert to= the database. After this, the database can send "I approve"= ;
to the master device. Assuming that both communication channels (slav= e to master and master to database) have been authenticated and secured, th= e master can then tell the slave to go ahead.

However, we now require the database be able to validate the credentials of= any slave device that may be manufactured/owned by someone other than the = manufacturer/owner of the master device. It would seem we need a nati= onally-scoped trust anchor to achieve this.

<GB> I think this is the part which is outside the scope of = our charter, which says: " 4. Ensure that the discovery mechanism, dat= abase access method,
and query/response formats have appropriate security levels in place. "= ;. There is no mention about the db making sure the slave devices did not s= poof their identity. Especially as regulators do not require slave devices = to have a mechanism to be able to prove ownership of the identity. If I remember correctly, this was considered in= FCC, but then the requirement was dropped.

> Afaik, regulators do not require for client certs binding the
> identifier to the hardware. Therefore, the verification of whether the=
> identifier is the correct one or not seems to be outside the scope of<= br> > paws. The master should rely on the lower layers and the DB for this > verification.

This statement really confuses me. To me, a binding of an identifier = to hardware means that there is some tamper and copy-proof storage for a pr= ivate key epoxied into the wireless hardware. This private key would = be used to authenticate & distribute keying material for a secure channel between the slave and the master. That= part is indeed out of scope of PAWS, but the master-to-database messages t= o validate the slave's credentials are not.

<GB> I think the confusion might come that you assume the pr= ivate key in the slave (if existed at all) would also be used to authentica= te the slave to the master. In my understanding that would not necessarily be the case. Even if there was a private key in= the slave, the slave would acquire another set of (eg username/password) c= redentials, independent of the private key, to connect to the master = device.

- Gabor

-Pete

>
> - Gabor
>
>
>
> -Pete
>
> Rosen, Brian wrote:
>> <As individual, and I should have said that on all of my messag= es on
>> this thread> The credentialling system used between the databas= e
>> server and its client (the master) are those of its client. = The
>> database trusts its client.
>>
>> The client (the master) may need its customer, the slave, to prese= nt
>> credentials for service.
>>
>> This means we assume transitive trust on the ID information from t= he
>> client. The master validates the slave, the database validat= es the
>> master. I would not advocate trying to make anything more co= mplex.
>>
>> Brian
>>
>> On Apr 18, 2012, at 11:16 AM, Peter McCann wrote:
>>
>>> Right, the master queries the database on behalf of the slave,=
>>> sending the slave's Device ID and location. (See Don's m= essage
>>> about validating the FCC ID). My question is, what is th= e security
>>> model for validating the slave's ID? Is there a secure c= redential
>>> associated with the ID, or is it an insecure check of a number=
>>> against a whitelist? If the former, we will need a crede= ntial
>>> management system that is able to cross between different data= bases.
>>> If the latter, I wonder if it opens up security problems.
>>>
>>> -Pete
>>>
>>> Rosen, Brian wrote:
>>>> Perhaps I am confused, but I think in a master/slave envir= onment,
>>>> the slave does not query the database, the master does. &n= bsp;The slave
>>>> gets its allowed spectrum data from the master. Ther= e is always
>>>> the question of whether the master queries on its own beha= lf and
>>>> the slaves just get assignments within that database respo= nse, or
>>>> whether the master queries on behalf of the slaves. = Might have to
>>>> support both models. In many cases, I think it's the latte= r: the
>>>> master queries using the slaves location and parameters. >>>>
>>>> The most common master/slave setup is tower and clients, r= ight?
>>>> The tower has an Internet connection and can query the dat= abase.
>>>> The clients of the tower are the slaves. Does the da= tabase query
>>>> use the location and type data of the slave or the master?=
>>>>
>>>> Brian
>>>>
>>>> On Apr 18, 2012, at 10:51 AM, Peter McCann wrote:
>>>>
>>>>> I think it would be a mistake to assume that the slave= & master
>>>>> devices both have pre-existing relationships with the = same database.
>>>>> In a commercial service, the slave devices would all c= ome from
>>>>> different manufacturers and would certainly have diffe= rent owners.
>>>>> Wouldn't we want them to interoperate with any master = device,
>>>>> assuming they are RF-compatible?
>>>>>
>>>>> -Pete
>>>>>
>>>>> Rosen, Brian wrote:
>>>>>> Doesn't the slave get it's database access through= the master?
>>>>>> If that's true, the problem you are worried about = doesn't exist.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> On Apr 18, 2012, at 10:37 AM, Peter McCann wrote:<= br> >>>>>>
>>>>>>> I agree with Brian that LoST could be a good m= odel for
>>>>>>> discovering the appropriate database for the r= egion you're in. A
>>>>>>> nation may decide to subdivide their territory= into provinces or
>>>>>>> states, each of which maintains its own databa= se.
>>>>>>>
>>>>>>> I think it would be a mistake to assume that t= here is a single,
>>>>>>> pre-defined relationship for one device with j= ust one database.
>>>>>>> In particular, I think there is a thorny issue= that will arise
>>>>>>> with management of secure credentials on white= space devices,
>>>>>>> illustrated by the first use case in Section 4= .2.1 of
>>>>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03= . Step 9 of that
>>>>>>> use case says:
>>>>>>>
>>>>>>> 9. Once the master/AP has met all regul= atory domain
>> requirements
>>>>>>> (e.g. validating the Devic= e ID with the trusted database,
>>>>>>> etc) the master provides t= he list of channels locally
>>>>>>> available to the slave/use= r device.
>>>>>>> My question is, what if the master device has = a relationship
>>>>>>> with one database, but the slave device has a = relationship with
>>>>>>> another? How is the master's database supposed= to validate the
>>>>>>> credentials of the slave device, if we don't h= ave some sort of
>>>>>>> common trust anchor? Or will this "valida= tion" be simply an
>>>>>>> insecure check of an ID against a whitelist/bl= acklist? Who will
>>>>>>> allocate Device IDs? Will they be specific to = a particular
>>>>>>> database operator, or do we need some common t= op-level
>>>>>>> allocation format?
>>>>>>>
>>>>>>> -Pete
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
> _______________________________________________
> paws mailing list
> paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws

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

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E81892008AM1MPN1006mg_-- From gerald.chouinard@sympatico.ca Sat Apr 21 13:21:08 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C6721F84FA for ; Sat, 21 Apr 2012 13:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLu+6EEqvMgn for ; Sat, 21 Apr 2012 13:21:04 -0700 (PDT) Received: from blu0-omc1-s31.blu0.hotmail.com (blu0-omc1-s31.blu0.hotmail.com [65.55.116.42]) by ietfa.amsl.com (Postfix) with ESMTP id BF26221F84EB for ; Sat, 21 Apr 2012 13:21:03 -0700 (PDT) Received: from BLU0-SMTP29 ([65.55.116.7]) by blu0-omc1-s31.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Apr 2012 13:21:02 -0700 X-Originating-IP: [184.144.140.101] X-Originating-Email: [gerald.chouinard@sympatico.ca] Message-ID: Received: from Gerald2 ([184.144.140.101]) by BLU0-SMTP29.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Apr 2012 13:21:01 -0700 From: Gerald Chouinard To: "'Pete Resnick'" References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E694A9@008-AM1MPN1-001.mgdnok.nokia.com><4F84D8FF.9010509@stpeter.im><1ECAFF543A2FED4EA2BEB6CACE08E47601E731B0@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601E75E57@008-AM1MPN1-001.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F714140945F4C87@EMV62-UKRD.domain1.systemhost.net> <4F8D7361.40803@qualcomm.com> <4F91DCF4.1020500@qualcomm.com> Date: Sat, 21 Apr 2012 16:21:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0fQVhl1DyTZPBSRDmnll7GjCOxZAAuZatw In-Reply-To: <4F91DCF4.1020500@qualcomm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-OriginalArrivalTime: 21 Apr 2012 20:21:02.0151 (UTC) FILETIME=[457AD570:01CD1FFC] Cc: paws@ietf.org Subject: Re: [paws] charter update X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Apr 2012 20:21:08 -0000 Hi Pete, I believe you are reading too much into my explanation. I was merely trying to identify whether the response back to the database will include the actual channel being used at the time of the response or the channel that is anticipated to be used later. This is only a question of relative timing. Furthermore, the regulators will likely prefer getting information on the channels that are actually being used rather than the channels that are anticipated to be used, in other words, those that are used rather than those that may eventually be used. In practice, if one can equate the "anticipated usage" to the "actual usage", then there is no problem. Gerald -----Original Message----- From: Pete Resnick [mailto:presnick@qualcomm.com] Sent: Friday, 20 April, 2012 18:02 To: Gerald Chouinard Cc: paws@ietf.org Subject: Re: [paws] charter update Hi Gerald, On 4/19/12 10:01 PM, Gerald Chouinard wrote: > The "anticipated usage" describes the response that the WSD will make in a > transitional state when it initiates its operation after having queried the > database. > Actually, no. The "anticipated usage" (or, again, perhaps "intended usage") describes the response that the radio device will make *whenever* it queries the database. Whether it does this as a transitional state when it initiates its operation or at a later time in order to refresh is completely an implementation detail. As far as the protocol is concerned, the response is about which of frequencies it intends to use given what the WSD has reported. > However, since the regulatory bodies in different countries will require > that the WSD queries the database on a regular basis (e.g., within 24 hours > in the USA), the question is whether the WSD will need to send its spectrum > occupation after every query, even if it has not changed (i.e., the behavior > in a steady-state). No, this is absolutely irrelevant. This is outside of the protocol operation and is strictly about the semantics of the use of the protocol. It does not effect what the protocol will require. > If this is not needed, then the term "anticipated usage" > would be appropriate since the WSD would only respond when it changes its > spectrum occupation (however, see paragraph below). If a confirmation is > needed every time, then in most of the cases, the WSD would report its > current spectrum usage and only when it happens to change its usage would it > nee to report its "anticipated usage". if it has not already re-tuned to the > new allowed channel before it sends its report to the database. > The server cannot tell the difference between "I have queried to refresh; I've been using this WS and intend to continue to do so" versus "I had stopped using this WS some time ago and I am making a new request for WS; here's what I intend to use now" versus "I am requesting WS for the first time; here is what I intend to use". It is protocol-irrelevant which case is being used. > My guess is that since it will need to free the channel that it was > operating on and that is no longer available as soon as possible to avoid > interference, it will likely re-tune right away and not wait for the report > to be sent to the database over the internet before re-tuning (my guess is > this would be done over TCP with proper transmission confirmation rather > than UDP). In such case, it would then report on its "actual usage" rather > than the "anticipated usage". > > As you can see, this depends on what is being assumed as the process taking > place at the WSD when it queries the database. Once this is clearly > understood, it will be to the group to decide. > I simply disagree with your assessment. If the group thinks that you will (potentially) need to work on a separate protocol piece for notifications of current usage, I think you should add that to the proposed charter changes. But I don't see a need for that protocol requirement. It seems to me that all of the functionality can be satisfied with a response after receiving the list of WS indicating intended usage. pr > -----Original Message----- > From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of Pete > Resnick > Sent: Tuesday, 17 April, 2012 09:43 > To: andy.sago@bt.com > Cc: paws@ietf.org > Subject: Re: [paws] charter update > > Folks, > > 1. As was said by others, "anticipated" is correct. The change in the > charter was not to include a constant dynamic update to the database of > what the device is currently using, but a one-time immediate report of > what the device intends to use. If you prefer "intended" to > "anticipated", that is also fine, but we have *not* discussed the > possibility of writing the protocol to have an update mechanism to > inform the database of the current actual usage. If that's needed, we > should further discuss. > > 2. I should repeat the admonition I made at the meeting in Paris: We are > *not* writing regulatory requirements into the protocol. We are writing > the protocol to have enough flexibility to satisfy regulatory > requirements. I am quite sure if we asked Ofcom whether they wanted > "anticipated usage" or "actual usage" in the protocol, they'd say > "actual usage", but that is entirely the wrong question to be asking and > we'd be getting a bogus answer. If the regulatory requirement we are > trying to make sure we are able to cover is "a single report by the > device of which spectrum it will be using", then "anticipated" is our > design requirement. Regulators (like end users in general) are not > protocol designers and the language they use for requirements should not > be used in our charter or protocol documents. We need to interpret what > their high-level requirements mean for our protocol and use language > within our documents (including our charter) that makes sense for a > protocol. > > So, my question to the list: > > Does anybody think we need to have the device constantly report back to > the database about its current usage? > > If I don't hear from anybody, I'm going to assume that this is *not* > needed and that the correct charter update to submit to the IESG should > have "anticipated" or "intended". > > pr > > On 4/16/12 5:13 AM, andy.sago@bt.com wrote: > >> Gabor >> >> Like Gerald, I am uneasy with the use of the word "anticipated". We can >> > ask Ofcom, but I am sure they will just point us to their regulatory > requirements which use phrasing like "a master WSD must communicate to the > WSDB the following information: .... The lower and upper frequency > boundaries of the in-block emissions.... The maximum in-block EIRP spectral > densities (in dBm/(0.2 MHz)) that the master WSD, and its associated slaves, > actually radiate ....". So their regulatory requirements are for actual > usage, not anticipated. It may be foolish for the group to agree charter > text that says something different. Can we just delete the word > "anticipated" in the new bullet 5? The word order could be changed to" > Report spectrum usage to the white space database at a suitable > granularity". > >> Andy >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> > Gerald Chouinard > >> Sent: 15 April 2012 18:40 >> To: Gabor.Bajko@nokia.com >> Cc: presnick@qualcomm.com; paws@ietf.org >> Subject: Re: [paws] charter update >> >> Gabor, >> >> I am wandering is the word "anticipated" will be good enough for OFCOM. >> > You may want to verify with them. To establish a status of the spectrum > usage in an area, the regulator will likely need the actual usage of this > spectrum and not only its "anticipated" usage. > >> My two cents ... >> >> Gerald >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> > Gabor.Bajko@nokia.com > >> Sent: Friday, 13 April, 2012 16:31 >> To: stpeter@stpeter.im; presnick@qualcomm.com >> Cc: paws@ietf.org >> Subject: Re: [paws] charter update >> >> Pete, Peter, >> >> There doesn't seem to be any objection to this charter update text on the >> > list from the WG members. Could you guys take this charter proposal text to > the iesg's telechat? > >> Thanks, Gabor >> >> >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >> > Bajko Gabor (Nokia-CIC/SiliconValley) > >> Sent: Wednesday, April 11, 2012 1:02 PM >> To: stpeter@stpeter.im >> Cc: paws@ietf.org >> Subject: Re: [paws] charter update >> >> Here's the charter update proposal text: >> http://www.ietf.org/proceedings/83/slides/slides-83-paws-4.txt >> >> According to diff, the are 6 lines changed, including the update to the >> > milestones. The main change is adding bullet point 5: " Report to the white > space database anticipated spectrum usage at a suitable granularity." > >> - Gabor >> >> >> -----Original Message----- >> From: ext Peter Saint-Andre [mailto:stpeter@stpeter.im] >> Sent: Tuesday, April 10, 2012 6:06 PM >> To: Bajko Gabor (Nokia-CIC/SiliconValley) >> Cc: paws@ietf.org >> Subject: Re: [paws] charter update >> >> On 4/9/12 3:40 PM, Gabor.Bajko@nokia.com wrote: >> >> >>> Folks, >>> >>> There was long discussion on the list before the Paris F2F about the >>> newly surfaced Ofcom requirements, which require the master devices to >>> report back to the wsdb the spectrum chosen for operation. Since this >>> aspect is not captured in the current charter, during the F2F we >>> discussed how to capture those requirements and there was no objection >>> to a slight charter update. >>> >>> The tentative charter update text I showed in slide 7 of >>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx had >>> one objection to the text added as a 5^th bullet point: "5. Report >>> back to the white space database use information, including the chosen >>> channels for operation and other relevant information", noting that >>> the result may be a chatty behavior in case of frequency hopping (see >>> the >>> >>> >> minutes). >> >> >>> The new proposal would be to replace the text in bullet 5 with "Report >>> to the white space database anticipated spectrum usage at a suitable >>> granularity." This text seem to be fine with Joel, who raised the >>> >>> >> objection. >> >> >>> I hope there is consensus in the wg for this new wording for the >>> charter update text. If there is no objection on the list to this >>> newly proposed text in the next few days, I would ask our AD to take >>> the proposed charter update text in slide 7 of >>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx, with >>> the new text for bullet 5, to the iesg. >>> >>> >> Hi Gabor, >> >> Would you be so kind as to send the actual text to the list? That will >> > make it easier for people to track the changes, search on this thread, etc. > >> Thanks! >> >> Peter >> >> -- >> Peter Saint-Andre >> https://stpeter.im/ >> >> -- Pete Resnick Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 From jmh@joelhalpern.com Sat Apr 21 15:16:54 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA6E21F85B4 for ; Sat, 21 Apr 2012 15:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRmXsdszV+PH for ; Sat, 21 Apr 2012 15:16:50 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7B90321F85AD for ; Sat, 21 Apr 2012 15:16:50 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 6095C558482 for ; Sat, 21 Apr 2012 15:16:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 4439D8280A; Sat, 21 Apr 2012 15:16:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.100] (pool-71-161-51-182.clppva.btas.verizon.net [71.161.51.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D9C12812C6; Sat, 21 Apr 2012 15:16:48 -0700 (PDT) Message-ID: <4F9331D3.4010906@joelhalpern.com> Date: Sat, 21 Apr 2012 18:16:51 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Gerald Chouinard References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E694A9@008-AM1MPN1-001.mgdnok.nokia.com><4F84D8FF.9010509@stpeter.im><1ECAFF543A2FED4EA2BEB6CACE08E47601E731B0@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601E75E57@008-AM1MPN1-001.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F714140945F4C87@EMV62-UKRD.domain1.systemhost.net> <4F8D7361.40803@qualcomm.com> <4F91DCF4.1020500@qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Pete Resnick' , paws@ietf.org Subject: Re: [paws] charter update X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Apr 2012 22:16:54 -0000 I have to diasagree. Given that the response to a new request for available channels can potentially be different from the old one, and that the base station can make a new plan based on the response (including lifetimes) it receives, the answer that goes with a registration is the expected future usage. If an operator wants historic actual usage reports, taht is a new requirement. Yours, Joel On 4/21/2012 4:21 PM, Gerald Chouinard wrote: > Hi Pete, > > I believe you are reading too much into my explanation. I was merely trying > to identify whether the response back to the database will include the > actual channel being used at the time of the response or the channel that is > anticipated to be used later. This is only a question of relative timing. > > Furthermore, the regulators will likely prefer getting information on the > channels that are actually being used rather than the channels that are > anticipated to be used, in other words, those that are used rather than > those that may eventually be used. In practice, if one can equate the > "anticipated usage" to the "actual usage", then there is no problem. > > Gerald > > > -----Original Message----- > From: Pete Resnick [mailto:presnick@qualcomm.com] > Sent: Friday, 20 April, 2012 18:02 > To: Gerald Chouinard > Cc: paws@ietf.org > Subject: Re: [paws] charter update > > Hi Gerald, > > On 4/19/12 10:01 PM, Gerald Chouinard wrote: > >> The "anticipated usage" describes the response that the WSD will make in a >> transitional state when it initiates its operation after having queried > the >> database. >> > > Actually, no. The "anticipated usage" (or, again, perhaps "intended > usage") describes the response that the radio device will make > *whenever* it queries the database. Whether it does this as a > transitional state when it initiates its operation or at a later time in > order to refresh is completely an implementation detail. As far as the > protocol is concerned, the response is about which of frequencies it > intends to use given what the WSD has reported. > >> However, since the regulatory bodies in different countries will require >> that the WSD queries the database on a regular basis (e.g., within 24 > hours >> in the USA), the question is whether the WSD will need to send its > spectrum >> occupation after every query, even if it has not changed (i.e., the > behavior >> in a steady-state). > > No, this is absolutely irrelevant. This is outside of the protocol > operation and is strictly about the semantics of the use of the > protocol. It does not effect what the protocol will require. > >> If this is not needed, then the term "anticipated usage" >> would be appropriate since the WSD would only respond when it changes its >> spectrum occupation (however, see paragraph below). If a confirmation is >> needed every time, then in most of the cases, the WSD would report its >> current spectrum usage and only when it happens to change its usage would > it >> nee to report its "anticipated usage". if it has not already re-tuned to > the >> new allowed channel before it sends its report to the database. >> > > The server cannot tell the difference between "I have queried to > refresh; I've been using this WS and intend to continue to do so" versus > "I had stopped using this WS some time ago and I am making a new request > for WS; here's what I intend to use now" versus "I am requesting WS for > the first time; here is what I intend to use". It is protocol-irrelevant > which case is being used. > >> My guess is that since it will need to free the channel that it was >> operating on and that is no longer available as soon as possible to avoid >> interference, it will likely re-tune right away and not wait for the > report >> to be sent to the database over the internet before re-tuning (my guess is >> this would be done over TCP with proper transmission confirmation rather >> than UDP). In such case, it would then report on its "actual usage" rather >> than the "anticipated usage". >> >> As you can see, this depends on what is being assumed as the process > taking >> place at the WSD when it queries the database. Once this is clearly >> understood, it will be to the group to decide. >> > > I simply disagree with your assessment. > > If the group thinks that you will (potentially) need to work on a > separate protocol piece for notifications of current usage, I think you > should add that to the proposed charter changes. But I don't see a need > for that protocol requirement. It seems to me that all of the > functionality can be satisfied with a response after receiving the list > of WS indicating intended usage. > > pr > >> -----Original Message----- >> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of > Pete >> Resnick >> Sent: Tuesday, 17 April, 2012 09:43 >> To: andy.sago@bt.com >> Cc: paws@ietf.org >> Subject: Re: [paws] charter update >> >> Folks, >> >> 1. As was said by others, "anticipated" is correct. The change in the >> charter was not to include a constant dynamic update to the database of >> what the device is currently using, but a one-time immediate report of >> what the device intends to use. If you prefer "intended" to >> "anticipated", that is also fine, but we have *not* discussed the >> possibility of writing the protocol to have an update mechanism to >> inform the database of the current actual usage. If that's needed, we >> should further discuss. >> >> 2. I should repeat the admonition I made at the meeting in Paris: We are >> *not* writing regulatory requirements into the protocol. We are writing >> the protocol to have enough flexibility to satisfy regulatory >> requirements. I am quite sure if we asked Ofcom whether they wanted >> "anticipated usage" or "actual usage" in the protocol, they'd say >> "actual usage", but that is entirely the wrong question to be asking and >> we'd be getting a bogus answer. If the regulatory requirement we are >> trying to make sure we are able to cover is "a single report by the >> device of which spectrum it will be using", then "anticipated" is our >> design requirement. Regulators (like end users in general) are not >> protocol designers and the language they use for requirements should not >> be used in our charter or protocol documents. We need to interpret what >> their high-level requirements mean for our protocol and use language >> within our documents (including our charter) that makes sense for a >> protocol. >> >> So, my question to the list: >> >> Does anybody think we need to have the device constantly report back to >> the database about its current usage? >> >> If I don't hear from anybody, I'm going to assume that this is *not* >> needed and that the correct charter update to submit to the IESG should >> have "anticipated" or "intended". >> >> pr >> >> On 4/16/12 5:13 AM, andy.sago@bt.com wrote: >> >>> Gabor >>> >>> Like Gerald, I am uneasy with the use of the word "anticipated". We can >>> >> ask Ofcom, but I am sure they will just point us to their regulatory >> requirements which use phrasing like "a master WSD must communicate to the >> WSDB the following information: .... The lower and upper frequency >> boundaries of the in-block emissions.... The maximum in-block EIRP > spectral >> densities (in dBm/(0.2 MHz)) that the master WSD, and its associated > slaves, >> actually radiate ....". So their regulatory requirements are for actual >> usage, not anticipated. It may be foolish for the group to agree charter >> text that says something different. Can we just delete the word >> "anticipated" in the new bullet 5? The word order could be changed to" >> Report spectrum usage to the white space database at a suitable >> granularity". >> >>> Andy >>> >>> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>> >> Gerald Chouinard >> >>> Sent: 15 April 2012 18:40 >>> To: Gabor.Bajko@nokia.com >>> Cc: presnick@qualcomm.com; paws@ietf.org >>> Subject: Re: [paws] charter update >>> >>> Gabor, >>> >>> I am wandering is the word "anticipated" will be good enough for OFCOM. >>> >> You may want to verify with them. To establish a status of the spectrum >> usage in an area, the regulator will likely need the actual usage of this >> spectrum and not only its "anticipated" usage. >> >>> My two cents ... >>> >>> Gerald >>> >>> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>> >> Gabor.Bajko@nokia.com >> >>> Sent: Friday, 13 April, 2012 16:31 >>> To: stpeter@stpeter.im; presnick@qualcomm.com >>> Cc: paws@ietf.org >>> Subject: Re: [paws] charter update >>> >>> Pete, Peter, >>> >>> There doesn't seem to be any objection to this charter update text on the >>> >> list from the WG members. Could you guys take this charter proposal text > to >> the iesg's telechat? >> >>> Thanks, Gabor >>> >>> >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of >>> >> Bajko Gabor (Nokia-CIC/SiliconValley) >> >>> Sent: Wednesday, April 11, 2012 1:02 PM >>> To: stpeter@stpeter.im >>> Cc: paws@ietf.org >>> Subject: Re: [paws] charter update >>> >>> Here's the charter update proposal text: >>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-4.txt >>> >>> According to diff, the are 6 lines changed, including the update to the >>> >> milestones. The main change is adding bullet point 5: " Report to the > white >> space database anticipated spectrum usage at a suitable granularity." >> >>> - Gabor >>> >>> >>> -----Original Message----- >>> From: ext Peter Saint-Andre [mailto:stpeter@stpeter.im] >>> Sent: Tuesday, April 10, 2012 6:06 PM >>> To: Bajko Gabor (Nokia-CIC/SiliconValley) >>> Cc: paws@ietf.org >>> Subject: Re: [paws] charter update >>> >>> On 4/9/12 3:40 PM, Gabor.Bajko@nokia.com wrote: >>> >>> >>>> Folks, >>>> >>>> There was long discussion on the list before the Paris F2F about the >>>> newly surfaced Ofcom requirements, which require the master devices to >>>> report back to the wsdb the spectrum chosen for operation. Since this >>>> aspect is not captured in the current charter, during the F2F we >>>> discussed how to capture those requirements and there was no objection >>>> to a slight charter update. >>>> >>>> The tentative charter update text I showed in slide 7 of >>>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx had >>>> one objection to the text added as a 5^th bullet point: "5. Report >>>> back to the white space database use information, including the chosen >>>> channels for operation and other relevant information", noting that >>>> the result may be a chatty behavior in case of frequency hopping (see >>>> the >>>> >>>> >>> minutes). >>> >>> >>>> The new proposal would be to replace the text in bullet 5 with "Report >>>> to the white space database anticipated spectrum usage at a suitable >>>> granularity." This text seem to be fine with Joel, who raised the >>>> >>>> >>> objection. >>> >>> >>>> I hope there is consensus in the wg for this new wording for the >>>> charter update text. If there is no objection on the list to this >>>> newly proposed text in the next few days, I would ask our AD to take >>>> the proposed charter update text in slide 7 of >>>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx, with >>>> the new text for bullet 5, to the iesg. >>>> >>>> >>> Hi Gabor, >>> >>> Would you be so kind as to send the actual text to the list? That will >>> >> make it easier for people to track the changes, search on this thread, > etc. >> >>> Thanks! >>> >>> Peter >>> >>> -- >>> Peter Saint-Andre >>> https://stpeter.im/ >>> >>> > From nbravin@earthlink.net Sat Apr 21 16:20:58 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2831621F8570 for ; Sat, 21 Apr 2012 16:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=1.254, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXt9mPdS--+g for ; Sat, 21 Apr 2012 16:20:53 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 697D121F852C for ; Sat, 21 Apr 2012 16:20:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=oNgYycp6kSgHunaQEA7tdgIhVA1Fssfg4BYjHJjwM/kJCOY+aa3mvaxwR8T6nMCZ; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [71.46.198.120] (helo=[10.0.1.2]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1SLjbE-00079i-3C; Sat, 21 Apr 2012 19:20:16 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Nancy Bravin In-Reply-To: <4F9331D3.4010906@joelhalpern.com> Date: Sat, 21 Apr 2012 16:20:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5DF63B02-F841-4BF8-9A62-B31A362675E9@earthlink.net> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E694A9@008-AM1MPN1-001.mgdnok.nokia.com><4F84D8FF.9010509@stpeter.im><1ECAFF543A2FED4EA2BEB6CACE08E47601E731B0@008-AM1MPN1-001.mgdnok.nokia.com> <1ECAFF543A2FED4EA2BEB6CACE08E47601E75E57@008-AM1MPN1-001.mgdnok.nokia.com> <619CDADDCCD2B44380834BE8BF6F714140945F4C87@EMV62-UKRD.domain1.systemhost.net> <4F8D7361.40803@qualcomm.com> <4F91DCF4.1020500@qualcomm.com> <4F9331D3.4010906@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1084) X-ELNK-Trace: 9a7a58baebc0701cd780f4a490ca6956d5d4673fe7faad86638e3bf12f9a5564c9b1cbf8d19a1e71350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 71.46.198.120 Cc: Pete Resnick , paws@ietf.org Subject: Re: [paws] charter update X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 21 Apr 2012 23:20:58 -0000 An interesting thought if an operator could use historic actual data = usage reports, which could help if the information was used to find = people if there was a need immediately, or=20 in disasters via last known location? Maybe this could be a function of = a carrier under regs of that country ? It could be part of information that a DB, or GPS or Broadband system = could, if down, make some redundancy if others would be able to do this = instead of or in addition to each other. I know this comes under the part about if there is no communication from = either side DB/WSD because of cyber/disaster(natural or not) = section..was just a thought . We left it as being left to local authorities and regulators to relax = the rules so communication could take place. =20 In the discussion yesterday about roaming=85just a thought for those = related to the cellular industry, carriers, manufacturers of components, = etc.=20 ANd maybe this is a ridiculous thought, could a whitespace device, if = one might be in the form of a GPS cellular device, have the ability to = have the equivalent of a sim card =85when going from the US to the UK, ID for = FCC or UK programmed, so if one had a DB in each country=85it could be = applicable to both sets of regulations?=20 OUt of scope, present later under? Don't think it would work, = interrupting the flow of thought, but thanks anyway, we can ask members = to comment? Sincerely, Nancy On Apr 21, 2012, at 3:16 PM, Joel M. Halpern wrote: > I have to diasagree. Given that the response to a new request for = available channels can potentially be different from the old one, and = that the base station can make a new plan based on the response = (including lifetimes) it receives, the answer that goes with a = registration is the expected future usage. >=20 > If an operator wants historic actual usage reports, taht is a new = requirement. >=20 > Yours, > Joel >=20 > On 4/21/2012 4:21 PM, Gerald Chouinard wrote: >> Hi Pete, >>=20 >> I believe you are reading too much into my explanation. I was merely = trying >> to identify whether the response back to the database will include = the >> actual channel being used at the time of the response or the channel = that is >> anticipated to be used later. This is only a question of relative = timing. >>=20 >> Furthermore, the regulators will likely prefer getting information on = the >> channels that are actually being used rather than the channels that = are >> anticipated to be used, in other words, those that are used rather = than >> those that may eventually be used. In practice, if one can equate the >> "anticipated usage" to the "actual usage", then there is no problem. >>=20 >> Gerald >>=20 >>=20 >> -----Original Message----- >> From: Pete Resnick [mailto:presnick@qualcomm.com] >> Sent: Friday, 20 April, 2012 18:02 >> To: Gerald Chouinard >> Cc: paws@ietf.org >> Subject: Re: [paws] charter update >>=20 >> Hi Gerald, >>=20 >> On 4/19/12 10:01 PM, Gerald Chouinard wrote: >>=20 >>> The "anticipated usage" describes the response that the WSD will = make in a >>> transitional state when it initiates its operation after having = queried >> the >>> database. >>>=20 >>=20 >> Actually, no. The "anticipated usage" (or, again, perhaps "intended >> usage") describes the response that the radio device will make >> *whenever* it queries the database. Whether it does this as a >> transitional state when it initiates its operation or at a later time = in >> order to refresh is completely an implementation detail. As far as = the >> protocol is concerned, the response is about which of frequencies it >> intends to use given what the WSD has reported. >>=20 >>> However, since the regulatory bodies in different countries will = require >>> that the WSD queries the database on a regular basis (e.g., within = 24 >> hours >>> in the USA), the question is whether the WSD will need to send its >> spectrum >>> occupation after every query, even if it has not changed (i.e., the >> behavior >>> in a steady-state). >>=20 >> No, this is absolutely irrelevant. This is outside of the protocol >> operation and is strictly about the semantics of the use of the >> protocol. It does not effect what the protocol will require. >>=20 >>> If this is not needed, then the term "anticipated usage" >>> would be appropriate since the WSD would only respond when it = changes its >>> spectrum occupation (however, see paragraph below). If a = confirmation is >>> needed every time, then in most of the cases, the WSD would report = its >>> current spectrum usage and only when it happens to change its usage = would >> it >>> nee to report its "anticipated usage". if it has not already = re-tuned to >> the >>> new allowed channel before it sends its report to the database. >>>=20 >>=20 >> The server cannot tell the difference between "I have queried to >> refresh; I've been using this WS and intend to continue to do so" = versus >> "I had stopped using this WS some time ago and I am making a new = request >> for WS; here's what I intend to use now" versus "I am requesting WS = for >> the first time; here is what I intend to use". It is = protocol-irrelevant >> which case is being used. >>=20 >>> My guess is that since it will need to free the channel that it was >>> operating on and that is no longer available as soon as possible to = avoid >>> interference, it will likely re-tune right away and not wait for the >> report >>> to be sent to the database over the internet before re-tuning (my = guess is >>> this would be done over TCP with proper transmission confirmation = rather >>> than UDP). In such case, it would then report on its "actual usage" = rather >>> than the "anticipated usage". >>>=20 >>> As you can see, this depends on what is being assumed as the process >> taking >>> place at the WSD when it queries the database. Once this is clearly >>> understood, it will be to the group to decide. >>>=20 >>=20 >> I simply disagree with your assessment. >>=20 >> If the group thinks that you will (potentially) need to work on a >> separate protocol piece for notifications of current usage, I think = you >> should add that to the proposed charter changes. But I don't see a = need >> for that protocol requirement. It seems to me that all of the >> functionality can be satisfied with a response after receiving the = list >> of WS indicating intended usage. >>=20 >> pr >>=20 >>> -----Original Message----- >>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf = Of >> Pete >>> Resnick >>> Sent: Tuesday, 17 April, 2012 09:43 >>> To: andy.sago@bt.com >>> Cc: paws@ietf.org >>> Subject: Re: [paws] charter update >>>=20 >>> Folks, >>>=20 >>> 1. As was said by others, "anticipated" is correct. The change in = the >>> charter was not to include a constant dynamic update to the database = of >>> what the device is currently using, but a one-time immediate report = of >>> what the device intends to use. If you prefer "intended" to >>> "anticipated", that is also fine, but we have *not* discussed the >>> possibility of writing the protocol to have an update mechanism to >>> inform the database of the current actual usage. If that's needed, = we >>> should further discuss. >>>=20 >>> 2. I should repeat the admonition I made at the meeting in Paris: We = are >>> *not* writing regulatory requirements into the protocol. We are = writing >>> the protocol to have enough flexibility to satisfy regulatory >>> requirements. I am quite sure if we asked Ofcom whether they wanted >>> "anticipated usage" or "actual usage" in the protocol, they'd say >>> "actual usage", but that is entirely the wrong question to be asking = and >>> we'd be getting a bogus answer. If the regulatory requirement we are >>> trying to make sure we are able to cover is "a single report by the >>> device of which spectrum it will be using", then "anticipated" is = our >>> design requirement. Regulators (like end users in general) are not >>> protocol designers and the language they use for requirements should = not >>> be used in our charter or protocol documents. We need to interpret = what >>> their high-level requirements mean for our protocol and use language >>> within our documents (including our charter) that makes sense for a >>> protocol. >>>=20 >>> So, my question to the list: >>>=20 >>> Does anybody think we need to have the device constantly report back = to >>> the database about its current usage? >>>=20 >>> If I don't hear from anybody, I'm going to assume that this is *not* >>> needed and that the correct charter update to submit to the IESG = should >>> have "anticipated" or "intended". >>>=20 >>> pr >>>=20 >>> On 4/16/12 5:13 AM, andy.sago@bt.com wrote: >>>=20 >>>> Gabor >>>>=20 >>>> Like Gerald, I am uneasy with the use of the word "anticipated". = We can >>>>=20 >>> ask Ofcom, but I am sure they will just point us to their regulatory >>> requirements which use phrasing like "a master WSD must communicate = to the >>> WSDB the following information: .... The lower and upper frequency >>> boundaries of the in-block emissions.... The maximum in-block EIRP >> spectral >>> densities (in dBm/(0.2 MHz)) that the master WSD, and its associated >> slaves, >>> actually radiate ....". So their regulatory requirements are for = actual >>> usage, not anticipated. It may be foolish for the group to agree = charter >>> text that says something different. Can we just delete the word >>> "anticipated" in the new bullet 5? The word order could be changed = to" >>> Report spectrum usage to the white space database at a suitable >>> granularity". >>>=20 >>>> Andy >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of >>>>=20 >>> Gerald Chouinard >>>=20 >>>> Sent: 15 April 2012 18:40 >>>> To: Gabor.Bajko@nokia.com >>>> Cc: presnick@qualcomm.com; paws@ietf.org >>>> Subject: Re: [paws] charter update >>>>=20 >>>> Gabor, >>>>=20 >>>> I am wandering is the word "anticipated" will be good enough for = OFCOM. >>>>=20 >>> You may want to verify with them. To establish a status of the = spectrum >>> usage in an area, the regulator will likely need the actual usage of = this >>> spectrum and not only its "anticipated" usage. >>>=20 >>>> My two cents ... >>>>=20 >>>> Gerald >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of >>>>=20 >>> Gabor.Bajko@nokia.com >>>=20 >>>> Sent: Friday, 13 April, 2012 16:31 >>>> To: stpeter@stpeter.im; presnick@qualcomm.com >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] charter update >>>>=20 >>>> Pete, Peter, >>>>=20 >>>> There doesn't seem to be any objection to this charter update text = on the >>>>=20 >>> list from the WG members. Could you guys take this charter proposal = text >> to >>> the iesg's telechat? >>>=20 >>>> Thanks, Gabor >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On = Behalf Of >>>>=20 >>> Bajko Gabor (Nokia-CIC/SiliconValley) >>>=20 >>>> Sent: Wednesday, April 11, 2012 1:02 PM >>>> To: stpeter@stpeter.im >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] charter update >>>>=20 >>>> Here's the charter update proposal text: >>>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-4.txt >>>>=20 >>>> According to diff, the are 6 lines changed, including the update to = the >>>>=20 >>> milestones. The main change is adding bullet point 5: " Report to = the >> white >>> space database anticipated spectrum usage at a suitable = granularity." >>>=20 >>>> - Gabor >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: ext Peter Saint-Andre [mailto:stpeter@stpeter.im] >>>> Sent: Tuesday, April 10, 2012 6:06 PM >>>> To: Bajko Gabor (Nokia-CIC/SiliconValley) >>>> Cc: paws@ietf.org >>>> Subject: Re: [paws] charter update >>>>=20 >>>> On 4/9/12 3:40 PM, Gabor.Bajko@nokia.com wrote: >>>>=20 >>>>=20 >>>>> Folks, >>>>>=20 >>>>> There was long discussion on the list before the Paris F2F about = the >>>>> newly surfaced Ofcom requirements, which require the master = devices to >>>>> report back to the wsdb the spectrum chosen for operation. Since = this >>>>> aspect is not captured in the current charter, during the F2F we >>>>> discussed how to capture those requirements and there was no = objection >>>>> to a slight charter update. >>>>>=20 >>>>> The tentative charter update text I showed in slide 7 of >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx = had >>>>> one objection to the text added as a 5^th bullet point: "5. Report >>>>> back to the white space database use information, including the = chosen >>>>> channels for operation and other relevant information", noting = that >>>>> the result may be a chatty behavior in case of frequency hopping = (see >>>>> the >>>>>=20 >>>>>=20 >>>> minutes). >>>>=20 >>>>=20 >>>>> The new proposal would be to replace the text in bullet 5 with = "Report >>>>> to the white space database anticipated spectrum usage at a = suitable >>>>> granularity." This text seem to be fine with Joel, who raised the >>>>>=20 >>>>>=20 >>>> objection. >>>>=20 >>>>=20 >>>>> I hope there is consensus in the wg for this new wording for the >>>>> charter update text. If there is no objection on the list to this >>>>> newly proposed text in the next few days, I would ask our AD to = take >>>>> the proposed charter update text in slide 7 of >>>>> http://www.ietf.org/proceedings/83/slides/slides-83-paws-0.pptx, = with >>>>> the new text for bullet 5, to the iesg. >>>>>=20 >>>>>=20 >>>> Hi Gabor, >>>>=20 >>>> Would you be so kind as to send the actual text to the list? That = will >>>>=20 >>> make it easier for people to track the changes, search on this = thread, >> etc. >>>=20 >>>> Thanks! >>>>=20 >>>> Peter >>>>=20 >>>> -- >>>> Peter Saint-Andre >>>> https://stpeter.im/ >>>>=20 >>>>=20 >>=20 > _______________________________________________ > paws mailing list > paws@ietf.org > https://www.ietf.org/mailman/listinfo/paws From peter@spectrumbridge.com Sun Apr 22 18:18:18 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2556821F8541 for ; Sun, 22 Apr 2012 18:18: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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AODwKSqVq6pg for ; Sun, 22 Apr 2012 18:18:16 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id 1E54F21F8496 for ; Sun, 22 Apr 2012 18:18:16 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Sun, 22 Apr 2012 21:20:01 -0400 From: Peter Stanforth To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Date: Sun, 22 Apr 2012 21:18:09 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0g7zO8RiweBBjVRiW+koqujw5WxA== Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601E817E3@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBBA216A23F9Bpeterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Apr 2012 01:18:18 -0000 --_000_CBBA216A23F9Bpeterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If you are going to quote the charter get it right (See below). At best ta= sk1 and objective 1 are ambiguous, at worst the objective won't address the= task. But more to the point, it baffles me that PAWS is perfectly willing = to update it's charter on a suggested rule (Ofcom consultation proposing a = channel use report) yet not even discuss a violation of the only implemente= d rules out there (FCC radio certification process does not allow for a dat= abase discovery process). Let me be very clear, Spectrum Bridge supports, and desires to have, channe= l use feedback and database discovery mechanisms. I believe our experience = in deploying white space networks, various white space databases and multip= le radio/database protocols gives us the credibility to say these two topic= s raise the complexity of the PAWS task by an order of magnitude. All Don w= as asking, on our behalf, was that PAWS take a bite out of the apple we can= swallow quickly and not a bite that is so big it chokes us to death. I don= 't think that is unreasonable. =85..complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined communication method. 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 4. Receive in return a list of available white space spectrum with their ch= aracteristics, using a well-defined format for returning information. 5. Report to the white space database spectrum usage at a suitable granular= ity. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for communicating with a white space database. 3. Standardize the data formats to be carried over the defined database communication method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. From: "Gabor.Bajko@nokia.com" > To: Don Joslyn >, "paul@marvell.com" >, "sdas@appcomsci.com" >, "paws@ietf.org" > Subject: Re: [paws] Database Discovery Question Don, As chair, I=92ll have to ask you to stop arguing against a database discove= ry protocol. That is clearly within the scope for the wg, as the charter sa= ys: =93Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database.=94= and it doesn=92t mention the optionality. ietf is contribution driven, if you are not interested in the discovery, th= en you do not need to contribute to it. But do not try to persuade the wg t= o not work on a piece which is in charter and folks are willing to do; tha= t is not how ietf works. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Don Joslyn Sent: Friday, April 20, 2012 12:21 PM To: Paul Lambert; Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question See reply below. Don From: Paul Lambert [mailto:paul@marvell.com] Sent: Thursday, April 19, 2012 2:36 PM To: Don Joslyn; Das, Subir; paws@ietf.org Subject: RE: [paws] Database Discovery Question Paul A. Lambert | Marvell | +1-650-787-9141 From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Don Joslyn Sent: Thursday, April 19, 2012 10:31 AM To: Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question I don't think PAWS should define discovery, I think the protocol should sim= ply start after a device has "found" the correct database to use. I feel this way for many reasons: 1) In the US, a radio is certified to work with one or more specific databa= ses. So the device will be pre-configured to contact specific databases, no= need to implement a discovery service. If the device is programmed to work= with more than one database provider, the device owner will configure whic= h one to use based on the relationship that they have established with the = database provider (for example, which one they are paying to use). When new databases come online, users would likely appreciate an option to = connect to a system additional services or perhaps lower prices for the ser= vice. [Don =96 Yes, this may be desired, but can the device immediately take adva= ntage of these new database records and decide on its own to use a new one = that has a lower cost? I would think that the device owner still needs to d= ecide to use the lower cost service (may even have to consider why it costs= less), pay for the service, and then configure the device to use it. I=92m= not sure how this can automatically happen between the discovery service a= nd WSD. Will cost considerations be part of the discovery solution? Is it c= ost per month, year, lifetime, message count, etc? You mentioned cost, but = there can be many other parameters that can influence the selection outcome= (SLA, features, etc.), where will we stop?] If we go strictly on the preconfiguration model =85 we don=92t even need PA= WS. The relationship you describe would have defined all the interfaces. = If we are in the business of having open interfaces, we need to provide a m= eans to discocovery and select DBs. [Don =96 I don=92t agree with the all-or-nothing argument, using discovery = is optional (per PAWS requirements). Establishing a standard protocol betwe= en WSDB and WSD is still valuable because, for example, will can still lowe= r the cost to device manufacturers because they will only need to implement= code for a single standard defined interface.] Paul 2) Discovery services like LoST are based on location, but the device's rel= ationship with a database service is not known or considered. While it may = seem simple to configure LoST or similar service to point to a database ser= vice based on location, how do you point to the one that the customer has a= relationship with, for example, paid to use? I do realize that this may no= t be an issue in every country. 3) If PAWS defines a globally applicable discovery process and either picks= an existing protocol (like LoST) or designs one, most likely it would incl= ude a centrally based discovery service. What entity will be responsible fo= r hosting and configuring the central discovery service? How will PAWS defi= ne this as a global solution, and deal with the politics between countries? 4) Some radio manufacturers do not have very much ROM to include even more = code on their device. I'm concerned that discovery will consume even more s= pace on the radio, space that they may not even have. 5) I believe that defining discovery will take more time than defining the = protocol between the WSDB and WSD. I think that database discovery should be left to each country to define ba= sed on their own requirements and Whitespace ecosystem. Regards, Don From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org]On Behalf Of Das, Subir Sent: Tuesday, April 17, 2012 5:26 PM To: paws@ietf.org Subject: [paws] Database Discovery Question During PAWS session in Paris IETF, there were a lot of questions/discussion= s on 'Discovery' of Database. It was not clear to me except if we are talki= ng about "Database Server Discovery", in particular, the domain name or the= IP address of the 'Server" that is hosting the database. OTH, I felt that = some folks may have different views and they would possibly like to see mor= e features than just discovering the domain name or IP address of the "Data= base Server". In some offline discussions, I was told that it may be similar to what LOST= (RFC 5222) has defined. I read the LOST protocol and associated architectu= re and my current understanding is that the LOST use case is different than= what we are trying to achieve via PAWS. Here is my understanding of the op= erating model of PAWS interface (when defined): -"Fixed/Mode II WSD" (per figure 1,) can only q= uery the database -The manufacturer of the "Fixed/Mode II WSD" may be different than owner/op= erator of this device -"Fixed/Mode II WSD" is certified by the regulatory body of the region that= they serve - Either the "Fixed/Mode II WSD" device operator or the device vendor has a= n a-priori relationship with one or more covering database administrators. = This relationship is utilized to either configure or enable the discovery of the proper data= base to contact in the current location I would like to know the group's view of the above model. To me, finding th= e emergency services or restaurant information near my location is differen= t than getting to know a server that can provide me with channel/frequency/= power and other information in the location where "Fixed/Mode II WSD" is si= tuated. In addition, emergency services do not require a subscription and t= he service is mandated by the Government/regulatory bodies. Some may argue = that 'White Space' service may be free as well, but to my understanding it = is not quite the similar model as emergency services. I hope with this thread we can clarify/understand the discovery issue. Regards, _Subir --_000_CBBA216A23F9Bpeterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If you are going to = quote the charter get it right (See below). At best task1 and objecti= ve 1 are ambiguous, at worst the objective won't address the task. But more= to the point, it baffles me that PAWS is perfectly willing to update it's = charter on a suggested rule (Ofcom consultation proposing a channel use rep= ort) yet not even discuss a violation of the only implemented rules out the= re (FCC radio certification process does not allow for a database discovery= process).
Let me be very clear, = Spectrum Bridge supports, and desires to have, channel use feedback and dat= abase discovery mechanisms. I believe our experience in deploying white spa= ce networks, various white space databases and multiple radio/database prot= ocols gives us the credibility to say these two topics raise the complexity= of the PAWS task by an order of magnitude. All Don was asking, on our beha= lf, was that PAWS take a bite out of the apple we can swallow quickly and n= ot a bite that is so big it chokes us to death. I don't think that is unrea= sonable.
= =85..complete the following tasks: 1. Determine the = relevant white space database to query. 2. Connect to the database using a well-defined communication method. 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 4. Receive in return a list of available white space spectrum with their ch= aracteristics, using a well-defined format for returning information. 5. Report to the white space database spectrum usage at a suitable granular= ity. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a = mechanism for discovering a white space database. 2. Standardize a method for communicating with a white space database. 3. Standardize the data formats to be carried over the defined database communication method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place.

From: "= Gabor.Bajko@nokia.com" &l= t;Gabor.Bajko@nokia.com>To: Don Joslyn <d.joslyn@spectrumbridge.com>, "= ;paul@marvell.com" <paul@marvell.com>, "sdas@appcomsci.com" <sdas@appcomsci.com>, "paws@ietf.org" <pa= ws@ietf.org>
Subject: Re= : [paws] Database Discovery Question

Don,

<= span style=3D"color:#1F497D">As chair, I=92ll have to ask you to stop argui= ng against a database discovery protocol. That is clearly within the scope = for the wg, as the charter says:
=93Objectives
The overall goals of this work= ing group are to:
1.     &= nbsp; Standardiz= e a mechanism for discovering a white space database.=94 and it doesn=92t m= ention the optionality.
ietf is contribution driven, if you are not interest= ed in the discovery, then you do not need to contribute to it. But do not t= ry to persuade the wg to not work on a piece which is in charter and folks = are willing to do; that is not how ietf works.

- = ;         Gabor=
=
From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Don Joslyn
Sent: Friday, April 20, 2012 1= 2:21 PM
To: Paul Lambert; Das, Subir; paws@ietf.org
Subject: Re: [paws] Database Discovery Qu= estion
<= /o:p>
See reply bel= ow.
Don

<= span style=3D"font-size: 10pt; font-family: Tahoma, sans-serif; ">From: = Paul Lambert [mailto:paul@marvell.com] =
Sent: Thursday, April 19, 2012 2:36 PM
To: Don Joslyn;= Das, Subir; paws@ietf.org
Subje= ct: RE: [paws] Database Discovery Question
<= /div>

Paul A. Lambert | Marvel= l | +1-650-787-9141
<= span style=3D"color:#1F497D">
From:paws-= bounces@ietf.org [mailto:paws-= bounces@ietf.org] On Behalf Of Don Joslyn
Sent: Thursday, April 19, 2012 10:= 31 AM
To: Das, Subir; paws@ietf.= org
Subject: Re: [paws] Database Discovery Question

I don't think PAWS should define discovery, I think the = protocol should simply start after a device has "found" the corre= ct database to use.

I feel this way for many reasons:
1) In the US, a radio is certified to work w= ith one or more specific databases. So the device will be pre-configured to= contact specific databases, no need to implement a discovery service. If t= he device is programmed to work with more than one database provider, the device owner will configure which one to u= se based on the relationship that they have established with the database p= rovider (for example, which one they are paying to use).

When new databases come online, users = would likely appreciate an option to connect to a system additional service= s or perhaps lower prices for the service.

[Don =96 Yes, this may be desired, but can th= e device immediately take advantage of these new database records and decid= e on its own to use a new one that has a lower cost? I would think that the device owner still needs to decid= e to use the lower cost service (may even have to consider why it costs les= s), pay for the service, and then configure the device to use it. I=92m not= sure how this can automatically happen between the discovery service and WSD. Will cost considerations be part of= the discovery solution? Is it cost per month, year, lifetime, message coun= t, etc? You mentioned cost, but there can be many other parameters that can= influence the selection outcome (SLA, features, etc.), where will we stop?]

If we go strictly on the preconfiguration = model =85 we don=92t even need PAWS. The relationship you describe wo= uld have defined all the interfaces. If we are in the business of having open interfaces, we need to provide a means to d= iscocovery and select DBs.
<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibr= i, sans-serif; ">[Don =96 I don=92t agree with the all-or-nothing argument,= using discovery is optional (per PAWS requirements). Establishing a standa= rd protocol between WSDB and WSD is still valuable because, for example, will can still lower the c= ost to device manufacturers because they will only need to implement code f= or a single standard defined interface.]

Paul

2) Discovery services like LoST are based on location, but the device's r= elationship with a database service is not known or considered. While it ma= y seem simple to configure LoST or similar service to point to a database s= ervice based on location, how do you point to the one that the customer has a relations= hip with, for example, paid to use? I do realize that this may not be an is= sue in every country.
3) If PAWS de= fines a globally applicable discovery process and either picks an existing = protocol (like LoST) or designs one, most likely it would include a central= ly based discovery service. What entity will be responsible for hosting and configuring the central discovery service? How will PAWS define this a= s a global solution, and deal with the politics between countries?
4) Some radio manufacturers do not have ver= y much ROM to include even more code on their device. I'm concerned that di= scovery will consume even more space on the radio, space that they may not = even have.
5) I believe that defini= ng discovery will take more time than defining the protocol between the WSD= B and WSD.

I think that database discovery should be left to ea= ch country to define based on their own requirements and Whitespace ecosyst= em.

Regards,
Don=
<= /o:p>
&= nbsp;
From:paws-bounces@ietf.org [mailto:paws-bounces@ietf.org]On Behalf Of Das, Subir
Sent: Tuesday, April 17, 2012 5:26 PM
To: <= a href=3D"mailto:paws@ietf.org">paws@ietf.org
Subject: [paws]= Database Discovery Question

During PAWS sessio= n in Paris IETF, there were a lot of questions/discussions on 'Discovery' o= f Database. It was not clear to me except if we are talking about "Dat= abase Server Discovery", in particular, the domain name or the IP addr= ess of the 'Server" that is hosting the database. OTH, I felt that som= e folks may have different views and they would possibly like to see more f= eatures than just discovering the domain name or IP address of the "Da= tabase Server".

In some offline discussions, I was told th= at it may be similar to what LOST (RFC 5222) has defined. I read the LOST p= rotocol and associated architecture and my current understanding is that th= e LOST use case is different than what we are trying to achieve via PAWS. Here is my understanding of the operating = model of PAWS interface (when defined):

-"Fixed/Mode II WS= D" (per figure 1,<draft-das-paws-protocol-01>) can only query th= e database

-The manufacturer of the "Fixed/Mode II WSD&quo= t; may be different than owner/operator of this device

-"F= ixed/Mode II WSD" is certified by the regulatory body of the region th= at they serve

=
- Either the "Fixed/Mode II WSD" device= operator or the device vendor has an a-priori relationship with one or mor= e covering database administrators. This relationship
is utilized to either configure or enable the disc= overy of the proper database to contact in the current location<= /p>

I would like to know the gr= oup's view of the above model. To me, finding the emergency services or res= taurant information near my location is different than getting to know a se= rver that can provide me with channel/frequency/power and other information in the location where "Fixed/Mode II WSD" is s= ituated. In addition, emergency services do not require a subscription and = the service is mandated by the Government/regulatory bodies. Some may argue= that 'White Space' service may be free as well, but to my understanding it is not quite the similar model as emergen= cy services.

<= p class=3D"MsoPlainText">
I h= ope with this thread we can clarify/understand the discovery issue.

Regards,

_Subir

--_000_CBBA216A23F9Bpeterspectrumbridgecom_-- From Gabor.Bajko@nokia.com Mon Apr 23 13:36:32 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 043EA21F8601 for ; Mon, 23 Apr 2012 13:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Bmb4wnzyf8eg for ; Mon, 23 Apr 2012 13:36:25 -0700 (PDT) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 64E0621F85D9 for ; Mon, 23 Apr 2012 13:36:24 -0700 (PDT) Received: from vaebh102.NOE.Nokia.com (in-mx.nokia.com [10.160.244.23]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q3NKaGHm031769; Mon, 23 Apr 2012 23:36:17 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.60]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 23:36:16 +0300 Received: from 008-AM1MPN1-006.mgdnok.nokia.com ([169.254.6.85]) by 008-AM1MMR1-005.mgdnok.nokia.com ([65.54.30.60]) with mapi id 14.02.0283.004; Mon, 23 Apr 2012 22:36:15 +0200 From: To: , Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0c4K8PQNA9Co7UTfGQzW7Gue+uSwBcXadgAAInqCAAMn5KAAAEuj9AAGmh44AAItPXwA== Date: Mon, 23 Apr 2012 20:36:14 +0000 Message-ID: <1ECAFF543A2FED4EA2BEB6CACE08E47601E900D6@008-AM1MPN1-006.mgdnok.nokia.com> References: <1ECAFF543A2FED4EA2BEB6CACE08E47601E817E3@008-AM1MPN1-006.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [69.181.124.61] Content-Type: multipart/alternative; boundary="_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E900D6008AM1MPN1006mg_" MIME-Version: 1.0 X-OriginalArrivalTime: 23 Apr 2012 20:36:16.0587 (UTC) FILETIME=[BB5A31B0:01CD2190] X-Nokia-AV: Clean Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 23 Apr 2012 20:36:32 -0000 --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E900D6008AM1MPN1006mg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are you now saying that the charter text is wrong because regulators will r= equire that there should always be a prior relationship between a master de= vice and the database it can query for channel availability? Even if that's= the case with FCC, the question is if this view is shared by other regulat= ors or not. In FCC case, the device will simply not need to make use of discovery, as i= t knows the db. When we wrote the paws charter, we targeted a global scope,= not FCC specific one. Having the discovery in the charter does not mean that we have to have disc= overy defined as part of the document dealing with the protocol, it could b= e a separate document, if the wg wishes so. It certainly does not mean that= we are *not* done with the ws protocol itself until the discovery part is = not finalized; we can certainly cut the apple in smaller pieces if needed. And I think this discussion should be preceded by individual submissions wh= ich the wg can adopt as wg document(s). - Gabor From: ext Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Sunday, April 22, 2012 6:18 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); paws@ietf.org Subject: Re: [paws] Database Discovery Question If you are going to quote the charter get it right (See below). At best ta= sk1 and objective 1 are ambiguous, at worst the objective won't address the= task. But more to the point, it baffles me that PAWS is perfectly willing = to update it's charter on a suggested rule (Ofcom consultation proposing a = channel use report) yet not even discuss a violation of the only implemente= d rules out there (FCC radio certification process does not allow for a dat= abase discovery process). Let me be very clear, Spectrum Bridge supports, and desires to have, channe= l use feedback and database discovery mechanisms. I believe our experience = in deploying white space networks, various white space databases and multip= le radio/database protocols gives us the credibility to say these two topic= s raise the complexity of the PAWS task by an order of magnitude. All Don w= as asking, on our behalf, was that PAWS take a bite out of the apple we can= swallow quickly and not a bite that is so big it chokes us to death. I don= 't think that is unreasonable. .....complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined communication method. 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 4. Receive in return a list of available white space spectrum with their ch= aracteristics, using a well-defined format for returning information. 5. Report to the white space database spectrum usage at a suitable granular= ity. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for communicating with a white space database. 3. Standardize the data formats to be carried over the defined database communication method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. From: "Gabor.Bajko@nokia.com" > To: Don Joslyn >, "paul@marvell.com" >, "sdas@appcomsci.com" >, "paws@ietf.org" > Subject: Re: [paws] Database Discovery Question Don, As chair, I'll have to ask you to stop arguing against a database discovery= protocol. That is clearly within the scope for the wg, as the charter says= : "Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database." a= nd it doesn't mention the optionality. ietf is contribution driven, if you are not interested in the discovery, th= en you do not need to contribute to it. But do not try to persuade the wg t= o not work on a piece which is in charter and folks are willing to do; tha= t is not how ietf works. - Gabor From: paws-bounces@ietf.org [mailto:paws-boun= ces@ietf.org] On Behalf Of ext Don Joslyn Sent: Friday, April 20, 2012 12:21 PM To: Paul Lambert; Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question See reply below. Don From: Paul Lambert [mailto:paul@marvell.com] Sent: Thursday, April 19, 2012 2:36 PM To: Don Joslyn; Das, Subir; paws@ietf.org Subject: RE: [paws] Database Discovery Question Paul A. Lambert | Marvell | +1-650-787-9141 From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Don Joslyn Sent: Thursday, April 19, 2012 10:31 AM To: Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question I don't think PAWS should define discovery, I think the protocol should sim= ply start after a device has "found" the correct database to use. I feel this way for many reasons: 1) In the US, a radio is certified to work with one or more specific databa= ses. So the device will be pre-configured to contact specific databases, no= need to implement a discovery service. If the device is programmed to work= with more than one database provider, the device owner will configure whic= h one to use based on the relationship that they have established with the = database provider (for example, which one they are paying to use). When new databases come online, users would likely appreciate an option to = connect to a system additional services or perhaps lower prices for the ser= vice. [Don - Yes, this may be desired, but can the device immediately take advant= age of these new database records and decide on its own to use a new one th= at has a lower cost? I would think that the device owner still needs to dec= ide to use the lower cost service (may even have to consider why it costs l= ess), pay for the service, and then configure the device to use it. I'm not= sure how this can automatically happen between the discovery service and W= SD. Will cost considerations be part of the discovery solution? Is it cost = per month, year, lifetime, message count, etc? You mentioned cost, but ther= e can be many other parameters that can influence the selection outcome (SL= A, features, etc.), where will we stop?] If we go strictly on the preconfiguration model ... we don't even need PAWS= . The relationship you describe would have defined all the interfaces. If= we are in the business of having open interfaces, we need to provide a mea= ns to discocovery and select DBs. [Don - I don't agree with the all-or-nothing argument, using discovery is o= ptional (per PAWS requirements). Establishing a standard protocol between W= SDB and WSD is still valuable because, for example, will can still lower th= e cost to device manufacturers because they will only need to implement cod= e for a single standard defined interface.] Paul 2) Discovery services like LoST are based on location, but the device's rel= ationship with a database service is not known or considered. While it may = seem simple to configure LoST or similar service to point to a database ser= vice based on location, how do you point to the one that the customer has a= relationship with, for example, paid to use? I do realize that this may no= t be an issue in every country. 3) If PAWS defines a globally applicable discovery process and either picks= an existing protocol (like LoST) or designs one, most likely it would incl= ude a centrally based discovery service. What entity will be responsible fo= r hosting and configuring the central discovery service? How will PAWS defi= ne this as a global solution, and deal with the politics between countries? 4) Some radio manufacturers do not have very much ROM to include even more = code on their device. I'm concerned that discovery will consume even more s= pace on the radio, space that they may not even have. 5) I believe that defining discovery will take more time than defining the = protocol between the WSDB and WSD. I think that database discovery should be left to each country to define ba= sed on their own requirements and Whitespace ecosystem. Regards, Don From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org]On Behalf Of Das, Subir Sent: Tuesday, April 17, 2012 5:26 PM To: paws@ietf.org Subject: [paws] Database Discovery Question During PAWS session in Paris IETF, there were a lot of questions/discussion= s on 'Discovery' of Database. It was not clear to me except if we are talki= ng about "Database Server Discovery", in particular, the domain name or the= IP address of the 'Server" that is hosting the database. OTH, I felt that = some folks may have different views and they would possibly like to see mor= e features than just discovering the domain name or IP address of the "Data= base Server". In some offline discussions, I was told that it may be similar to what LOST= (RFC 5222) has defined. I read the LOST protocol and associated architectu= re and my current understanding is that the LOST use case is different than= what we are trying to achieve via PAWS. Here is my understanding of the op= erating model of PAWS interface (when defined): -"Fixed/Mode II WSD" (per figure 1,) can only q= uery the database -The manufacturer of the "Fixed/Mode II WSD" may be different than owner/op= erator of this device -"Fixed/Mode II WSD" is certified by the regulatory body of the region that= they serve - Either the "Fixed/Mode II WSD" device operator or the device vendor has a= n a-priori relationship with one or more covering database administrators. = This relationship is utilized to either configure or enable the discovery of the proper data= base to contact in the current location I would like to know the group's view of the above model. To me, finding th= e emergency services or restaurant information near my location is differen= t than getting to know a server that can provide me with channel/frequency/= power and other information in the location where "Fixed/Mode II WSD" is si= tuated. In addition, emergency services do not require a subscription and t= he service is mandated by the Government/regulatory bodies. Some may argue = that 'White Space' service may be free as well, but to my understanding it = is not quite the similar model as emergency services. I hope with this thread we can clarify/understand the discovery issue. Regards, _Subir --_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E900D6008AM1MPN1006mg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Are you now saying tha= t the charter text is wrong because regulators will require that there shou= ld always be a prior relationship between a master device and the database = it can query for channel availability? Even if that’s the case with FCC, the question is if this view is sh= ared by other regulators or not.

In FCC case, the devic= e will simply not need to make use of discovery, as it knows the db. When w= e wrote the paws charter, we targeted a global scope, not FCC specific one.=

Having the discovery i= n the charter does not mean that we have to have discovery defined as part = of the document dealing with the protocol, it could be a separate document,= if the wg wishes so. It certainly does not mean that we are *not* done with the ws protocol itself until t= he discovery part is not finalized; we can certainly cut the apple in small= er pieces if needed.

And I think this discu= ssion should be preceded by individual submissions which the wg can adopt a= s wg document(s).

-&nb= sp;         Gabor

From: ext Pete= r Stanforth [mailto:peter@spectrumbridge.com]
Sent: Sunday, April 22, 2012 6:18 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); paws@ietf.org
Subject: Re: [paws] Database Discovery Question

If yo= u are going to quote the charter get it right (See below). At best ta= sk1 and objective 1 are ambiguous, at worst the objective won't address the= task. But more to the point, it baffles me that PAWS is perfectly willing to update it's charter on a suggested ru= le (Ofcom consultation proposing a channel use report) yet not even discuss= a violation of the only implemented rules out there (FCC radio certificati= on process does not allow for a database discovery process).

Let m= e be very clear, Spectrum Bridge supports, and desires to have, channel use= feedback and database discovery mechanisms. I believe our experience in de= ploying white space networks, various white space databases and multiple radio/database protocols gives us the c= redibility to say these two topics raise the complexity of the PAWS task by= an order of magnitude. All Don was asking, on our behalf, was that PAWS ta= ke a bite out of the apple we can swallow quickly and not a bite that is so big it chokes us to death. I don= 't think that is unreasonable.

…..complete the following tasks:

1. Determine the relevant white space databa= se to query.

2. Connect to the database using a well-= defined communication method.

3. Provide its geolocation and perhaps o= ther data to the database

using a well-defined format for querying= the database.

4. Receive in return a list of available= white space spectrum with their characteristics, using a well-defined form= at for returning information.

5. Report to the white space database sp= ectrum usage at a suitable granularity.

Once the device learns of the available = white space (e.g., in a TV

white space implementation, the list of = available channels at that

location), it can then select one of the= bands from the list and

begin to transmit and receive on the sel= ected band. If the device's

parameters have changed (e.g., if some a= mount of time has passed or if

the device has changed location beyond a= specified threshold), it might

need to query the database again to dete= rmine what white space is still

available.

Objectives

The overall goals of this working group = are to:

1. Standardize a mechanism for discovering a= white space database.

2. Standardize a method for communicatin= g with a white space database.

3. Standardize the data formats to be ca= rried over the defined

database communication method.

4. Ensure that the discovery mechanism, = database access method,

and query/response formats have appropri= ate security levels in place.

=

From: "Gabo= r.Bajko@nokia.com" <Ga= bor.Bajko@nokia.com>
To: Don Joslyn <d.= joslyn@spectrumbridge.com>, "paul@marvell.com" <paul@m= arvell.com>, "sdas@appcom= sci.com" <sdas@appcomsci.com>, &quo= t;paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Database Discovery Question

=

Don,

As chair, I’ll h= ave to ask you to stop arguing against a database discovery protocol. That = is clearly within the scope for the wg, as the charter says:

“Objectives

The overall goals of t= his working group are to:

1.&n= bsp;      Standardize a = mechanism for discovering a white space database.” and it doesn’= ;t mention the optionality.=

ietf is contribution d= riven, if you are not interested in the discovery, then you do not need to = contribute to it. But do not try to persuade the wg to not work on a piece = which is in charter and folks are willing to do; that is not how ietf works.

-&nb= sp;         Gabor

From: paws-bounces@ietf.org [mailto:paws-bounces@ietf.org] On Behalf Of ext Don Joslyn
Sent: Friday, April 20, 2012 12:21 PM
To: Paul Lambert; Das, Subir; paws@= ietf.org
Subject: Re: [paws] Database Discovery Question

See reply below.

Don

From: Paul Lambert [mailto:paul@marvell.com] =
Sent: Thursday, April 19, 2012 2:36 PM
To: Don Joslyn; Das, Subir; paws@ie= tf.org
Subject: RE: [paws] Database Discovery Question

Paul A. Lambert | Marv= ell | +1-650-787-9141

From:paws-bounces@ie= tf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of Don Joslyn
Sent: Thursday, April 19, 2012 10:31 AM
To: Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question

I don't think PAWS = should define discovery, I think the protocol should simply start after a d= evice has "found" the correct database to use.<= /p>

I feel this way for= many reasons:

1) In the US, a rad= io is certified to work with one or more specific databases. So the device = will be pre-configured to contact specific databases, no need to implement = a discovery service. If the device is programmed to work with more than one database provider, the device owner = will configure which one to use based on the relationship that they have es= tablished with the database provider (for example, which one they are payin= g to use).

When new databases com= e online, users would likely appreciate an option to connect to a system ad= ditional services or perhaps lower prices for the service.

[Don – Yes, this= may be desired, but can the device immediately take advantage of these new= database records and decide on its own to use a new one that has a lower cost? I would think that the device owner still needs to decid= e to use the lower cost service (may even have to consider why it costs les= s), pay for the service, and then configure the device to use it. I’m= not sure how this can automatically happen between the discovery service and WSD. Will cost considerations be part of= the discovery solution? Is it cost per month, year, lifetime, message coun= t, etc? You mentioned cost, but there can be many other parameters that can= influence the selection outcome (SLA, features, etc.), where will we stop?]

If we go strictly on t= he preconfiguration model … we don’t even need PAWS. The = relationship you describe would have defined all the interfaces. If w= e are in the business of having open interfaces, we need to provide a means to d= iscocovery and select DBs.<= /span>

[Don – I donR= 17;t agree with the all-or-nothing argument, using discovery is optional (p= er PAWS requirements). Establishing a standard protocol between WSDB and WSD is still valuable because, for example, will can still lower the c= ost to device manufacturers because they will only need to implement code f= or a single standard defined interface.]

Paul

2) Discovery servic= es like LoST are based on location, but the device's relationship with a da= tabase service is not known or considered. While it may seem simple to conf= igure LoST or similar service to point to a database service based on location, how do you point to the one that = the customer has a relationship with, for example, paid to use? I do realiz= e that this may not be an issue in every country.

3) If PAWS defines = a globally applicable discovery process and either picks an existing protoc= ol (like LoST) or designs one, most likely it would include a centrally bas= ed discovery service. What entity will be responsible for hosting and configuring the central discovery service? = How will PAWS define this as a global solution, and deal with the politics = between countries?

4) Some radio manuf= acturers do not have very much ROM to include even more code on their devic= e. I'm concerned that discovery will consume even more space on the radio, = space that they may not even have.

5) I believe that d= efining discovery will take more time than defining the protocol between th= e WSDB and WSD.

I think that databa= se discovery should be left to each country to define based on their own re= quirements and Whitespace ecosystem.

Regards,=

Don

From:paws-bounces@ie= tf.org [mailto:paws-bounces@ietf.org= ]On Behalf Of Das, Subir
Sent: Tuesday, April 17, 2012 5:26 PM
To: paws@ietf.org
Subject: [paws] Database Discovery Question

During PAWS session= in Paris IETF, there were a lot of questions/discussions on 'Discovery' of= Database. It was not clear to me except if we are talking about "Data= base Server Discovery", in particular, the domain name or the IP address of the 'Server" that is hosting the dat= abase. OTH, I felt that some folks may have different views and they would = possibly like to see more features than just discovering the domain name or= IP address of the "Database Server".

In some offline dis= cussions, I was told that it may be similar to what LOST (RFC 5222) has def= ined. I read the LOST protocol and associated architecture and my current u= nderstanding is that the LOST use case is different than what we are trying to achieve via PAWS. Here is my under= standing of the operating model of PAWS interface (when defined):

-"Fixed/Mode I= I WSD" (per figure 1,<draft-das-paws-protocol-01>) can only quer= y the database

-The manufacturer o= f the "Fixed/Mode II WSD" may be different than owner/operator of= this device

-"Fixed/Mode I= I WSD" is certified by the regulatory body of the region that they ser= ve

- Either the "= Fixed/Mode II WSD" device operator or the device vendor has an a-prior= i relationship with one or more covering database administrators. This rela= tionship

is utilized t= o either configure or enable the discovery of the proper database to contac= t in the current location

I would like to kno= w the group's view of the above model. To me, finding the emergency service= s or restaurant information near my location is different than getting to k= now a server that can provide me with channel/frequency/power and other information in the location where "= Fixed/Mode II WSD" is situated. In addition, emergency services do not= require a subscription and the service is mandated by the Government/regul= atory bodies. Some may argue that 'White Space' service may be free as well, but to my understanding it is not quite the s= imilar model as emergency services.

I hope with this th= read we can clarify/understand the discovery issue.

Regards,=

_Subir

--_000_1ECAFF543A2FED4EA2BEB6CACE08E47601E900D6008AM1MPN1006mg_-- From peter@spectrumbridge.com Mon Apr 23 17:20:24 2012 Return-Path: X-Original-To: paws@ietfa.amsl.com Delivered-To: paws@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AECA21F8678 for ; Mon, 23 Apr 2012 17:20:24 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkh0hWhHMX19 for ; Mon, 23 Apr 2012 17:20:22 -0700 (PDT) Received: from mail.spectrumbridge.com (mail.spectrumbridge.com [64.132.248.82]) by ietfa.amsl.com (Postfix) with ESMTP id CB60C21F8674 for ; Mon, 23 Apr 2012 17:20:21 -0700 (PDT) Received: from shelby.sbi.com ([127.0.0.1]) by shelby ([127.0.0.1]) with mapi; Mon, 23 Apr 2012 20:22:09 -0400 From: Peter Stanforth To: "Gabor.Bajko@nokia.com" , "paws@ietf.org" Date: Mon, 23 Apr 2012 20:20:11 -0400 Thread-Topic: [paws] Database Discovery Question Thread-Index: Ac0hsEiLIR++lzFuSXGNT/wLoTjclw== Message-ID: In-Reply-To: <1ECAFF543A2FED4EA2BEB6CACE08E47601E900D6@008-AM1MPN1-006.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.120402 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CBBB61C924052peterspectrumbridgecom_" MIME-Version: 1.0 Subject: Re: [paws] Database Discovery Question X-BeenThere: paws@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 Apr 2012 00:20:24 -0000 --_000_CBBB61C924052peterspectrumbridgecom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable What I am saying is that a DB will be managing access to spectrum, which c= ome under regulatory control. In the case of the FCC they had the option to= tie DB and radio together and they did it. Other regulators may not have t= hat luxury and, like Ofcom, choose to have a managed discovery mechanism. T= he simple fact is that, using SBI as an example, we were certified on our a= bility to protect incumbents. We are required to provide that protection fo= r free. So any business case or justification for providing a DB service is= based solely on the value we provide to the users of TVWS. It is not impor= tant if this is the radio vendor, network operator or any one else at this = time. What is important is that it creates a potential conflict. Who is to = say that I won't slip someone a little "extra" white space for the right re= turn? That is why I believe the regulator is going to retain control of th= e permitted DB administrators, and incumbents will demand it. What ever we= discuss in the way of a determining the relevant database/discovery proces= s has to be within that context. Splitting the protocol and discovery proc= ess into separate documents seems like it would help retain focus and allow= us to work on things in parallel. You could also use this construct to all= ow a protocol that is independent of the discovery process(es) which should= resolve a lot of these issues. As I have said before, we are trying to map= PAWS into our US and UK implementations so this is not a case of favoring = one over the other, we just need to know that the end result works for both= . Peter S. From: "Gabor.Bajko@nokia.com" > To: Peter Stanforth >, "paws@ietf.org" > Subject: RE: [paws] Database Discovery Question Are you now saying that the charter text is wrong because regulators will r= equire that there should always be a prior relationship between a master de= vice and the database it can query for channel availability? Even if that= =92s the case with FCC, the question is if this view is shared by other reg= ulators or not. In FCC case, the device will simply not need to make use of discovery, as i= t knows the db. When we wrote the paws charter, we targeted a global scope,= not FCC specific one. Having the discovery in the charter does not mean that we have to have disc= overy defined as part of the document dealing with the protocol, it could b= e a separate document, if the wg wishes so. It certainly does not mean that= we are *not* done with the ws protocol itself until the discovery part is = not finalized; we can certainly cut the apple in smaller pieces if needed. And I think this discussion should be preceded by individual submissions wh= ich the wg can adopt as wg document(s). - Gabor From: ext Peter Stanforth [mailto:peter@spectrumbridge.com] Sent: Sunday, April 22, 2012 6:18 PM To: Bajko Gabor (Nokia-CIC/SiliconValley); paws@ietf.org Subject: Re: [paws] Database Discovery Question If you are going to quote the charter get it right (See below). At best ta= sk1 and objective 1 are ambiguous, at worst the objective won't address the= task. But more to the point, it baffles me that PAWS is perfectly willing = to update it's charter on a suggested rule (Ofcom consultation proposing a = channel use report) yet not even discuss a violation of the only implemente= d rules out there (FCC radio certification process does not allow for a dat= abase discovery process). Let me be very clear, Spectrum Bridge supports, and desires to have, channe= l use feedback and database discovery mechanisms. I believe our experience = in deploying white space networks, various white space databases and multip= le radio/database protocols gives us the credibility to say these two topic= s raise the complexity of the PAWS task by an order of magnitude. All Don w= as asking, on our behalf, was that PAWS take a bite out of the apple we can= swallow quickly and not a bite that is so big it chokes us to death. I don= 't think that is unreasonable. =85..complete the following tasks: 1. Determine the relevant white space database to query. 2. Connect to the database using a well-defined communication method. 3. Provide its geolocation and perhaps other data to the database using a well-defined format for querying the database. 4. Receive in return a list of available white space spectrum with their ch= aracteristics, using a well-defined format for returning information. 5. Report to the white space database spectrum usage at a suitable granular= ity. Once the device learns of the available white space (e.g., in a TV white space implementation, the list of available channels at that location), it can then select one of the bands from the list and begin to transmit and receive on the selected band. If the device's parameters have changed (e.g., if some amount of time has passed or if the device has changed location beyond a specified threshold), it might need to query the database again to determine what white space is still available. Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database. 2. Standardize a method for communicating with a white space database. 3. Standardize the data formats to be carried over the defined database communication method. 4. Ensure that the discovery mechanism, database access method, and query/response formats have appropriate security levels in place. From: "Gabor.Bajko@nokia.com" > To: Don Joslyn >, "paul@marvell.com" >, "sdas@appcomsci.com" >, "paws@ietf.org" > Subject: Re: [paws] Database Discovery Question Don, As chair, I=92ll have to ask you to stop arguing against a database discove= ry protocol. That is clearly within the scope for the wg, as the charter sa= ys: =93Objectives The overall goals of this working group are to: 1. Standardize a mechanism for discovering a white space database.=94= and it doesn=92t mention the optionality. ietf is contribution driven, if you are not interested in the discovery, th= en you do not need to contribute to it. But do not try to persuade the wg t= o not work on a piece which is in charter and folks are willing to do; tha= t is not how ietf works. - Gabor From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of ext Don Joslyn Sent: Friday, April 20, 2012 12:21 PM To: Paul Lambert; Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question See reply below. Don From: Paul Lambert [mailto:paul@marvell.com] Sent: Thursday, April 19, 2012 2:36 PM To: Don Joslyn; Das, Subir; paws@ietf.org Subject: RE: [paws] Database Discovery Question Paul A. Lambert | Marvell | +1-650-787-9141 From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org] On Behalf Of Don Joslyn Sent: Thursday, April 19, 2012 10:31 AM To: Das, Subir; paws@ietf.org Subject: Re: [paws] Database Discovery Question I don't think PAWS should define discovery, I think the protocol should sim= ply start after a device has "found" the correct database to use. I feel this way for many reasons: 1) In the US, a radio is certified to work with one or more specific databa= ses. So the device will be pre-configured to contact specific databases, no= need to implement a discovery service. If the device is programmed to work= with more than one database provider, the device owner will configure whic= h one to use based on the relationship that they have established with the = database provider (for example, which one they are paying to use). When new databases come online, users would likely appreciate an option to = connect to a system additional services or perhaps lower prices for the ser= vice. [Don =96 Yes, this may be desired, but can the device immediately take adva= ntage of these new database records and decide on its own to use a new one = that has a lower cost? I would think that the device owner still needs to d= ecide to use the lower cost service (may even have to consider why it costs= less), pay for the service, and then configure the device to use it. I=92m= not sure how this can automatically happen between the discovery service a= nd WSD. Will cost considerations be part of the discovery solution? Is it c= ost per month, year, lifetime, message count, etc? You mentioned cost, but = there can be many other parameters that can influence the selection outcome= (SLA, features, etc.), where will we stop?] If we go strictly on the preconfiguration model =85 we don=92t even need PA= WS. The relationship you describe would have defined all the interfaces. = If we are in the business of having open interfaces, we need to provide a m= eans to discocovery and select DBs. [Don =96 I don=92t agree with the all-or-nothing argument, using discovery = is optional (per PAWS requirements). Establishing a standard protocol betwe= en WSDB and WSD is still valuable because, for example, will can still lowe= r the cost to device manufacturers because they will only need to implement= code for a single standard defined interface.] Paul 2) Discovery services like LoST are based on location, but the device's rel= ationship with a database service is not known or considered. While it may = seem simple to configure LoST or similar service to point to a database ser= vice based on location, how do you point to the one that the customer has a= relationship with, for example, paid to use? I do realize that this may no= t be an issue in every country. 3) If PAWS defines a globally applicable discovery process and either picks= an existing protocol (like LoST) or designs one, most likely it would incl= ude a centrally based discovery service. What entity will be responsible fo= r hosting and configuring the central discovery service? How will PAWS defi= ne this as a global solution, and deal with the politics between countries? 4) Some radio manufacturers do not have very much ROM to include even more = code on their device. I'm concerned that discovery will consume even more s= pace on the radio, space that they may not even have. 5) I believe that defining discovery will take more time than defining the = protocol between the WSDB and WSD. I think that database discovery should be left to each country to define ba= sed on their own requirements and Whitespace ecosystem. Regards, Don From:paws-bounces@ietf.org [mailto:paws-bounc= es@ietf.org]On Behalf Of Das, Subir Sent: Tuesday, April 17, 2012 5:26 PM To: paws@ietf.org Subject: [paws] Database Discovery Question During PAWS session in Paris IETF, there were a lot of questions/discussion= s on 'Discovery' of Database. It was not clear to me except if we are talki= ng about "Database Server Discovery", in particular, the domain name or the= IP address of the 'Server" that is hosting the database. OTH, I felt that = some folks may have different views and they would possibly like to see mor= e features than just discovering the domain name or IP address of the "Data= base Server". In some offline discussions, I was told that it may be similar to what LOST= (RFC 5222) has defined. I read the LOST protocol and associated architectu= re and my current understanding is that the LOST use case is different than= what we are trying to achieve via PAWS. Here is my understanding of the op= erating model of PAWS interface (when defined): -"Fixed/Mode II WSD" (per figure 1,) can only q= uery the database -The manufacturer of the "Fixed/Mode II WSD" may be different than owner/op= erator of this device -"Fixed/Mode II WSD" is certified by the regulatory body of the region that= they serve - Either the "Fixed/Mode II WSD" device operator or the device vendor has a= n a-priori relationship with one or more covering database administrators. = This relationship is utilized to either configure or enable the discovery of the proper data= base to contact in the current location I would like to know the group's view of the above model. To me, finding th= e emergency services or restaurant information near my location is differen= t than getting to know a server that can provide me with channel/frequency/= power and other information in the location where "Fixed/Mode II WSD" is si= tuated. In addition, emergency services do not require a subscription and t= he service is mandated by the Government/regulatory bodies. Some may argue = that 'White Space' service may be free as well, but to my understanding it = is not quite the similar model as emergency services. I hope with this thread we can clarify/understand the discovery issue. Regards, _Subir --_000_CBBB61C924052peterspectrumbridgecom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
What I am saying is that a DB w= ill be managing access to spectrum, which come under regulatory contr= ol. In the case of the FCC they had the option to tie DB and radio together= and they did it. Other regulators may not have that luxury and, like Ofcom= , choose to have a managed discovery mechanism. The simple fact is that, us= ing SBI as an example, we were certified on our ability to protect incumben= ts. We are required to provide that protection for free. So any business ca= se or justification for providing a DB service is based solely on the value= we provide to the users of TVWS. It is not important if this is the radio = vendor, network operator or any one else at this time. What is important is= that it creates a potential conflict. Who is to say that I won't slip some= one a little "extra" white space for the right return? That is wh= y I believe the regulator is going to retain control of the permitted= DB administrators, and incumbents will demand it. What ever we discu= ss in the way of a determining the relevant database/discovery process has = to be within that context. Splitting the protocol and discovery proce= ss into separate documents seems like it would help retain focus and allow = us to work on things in parallel. You could also use this construct to allo= w a protocol that is independent of the discovery process(es) which should = resolve a lot of these issues. As I have said before, we are trying to map = PAWS into our US and UK implementations so this is not a case of favoring o= ne over the other, we just need to know that the end result works for both.=

Peter S.

From: "Gabor.Bajko@nokia.com" <Gabor.Bajko@nokia.com>
To:= Peter Stanforth <pe= ter@spectrumbridge.com>, "paws= @ietf.org" <paws@ietf.org&= gt;
Subject: RE: [paws] Databas= e Discovery Question

Are you now saying that the charter text is wrong becaus= e regulators will require that there should always be a prior relationship = between a master device and the database it can query for channel availabil= ity? Even if that=92s the case with FCC, the question is if this view is shared= by other regulators or not.
= In FCC case, the device will simply not need to make use of discovery, as i= t knows the db. When we wrote the paws charter, we targeted a global scope,= not FCC specific one.
Having the discovery in the charter does not mean tha= t we have to have discovery defined as part of the document dealing with th= e protocol, it could be a separate document, if the wg wishes so. It certai= nly does not mean that we are *not* done with the ws protocol itself until t= he discovery part is not finalized; we can certainly cut the apple in small= er pieces if needed.
And I think this discussion should be preceded by indiv= idual submissions which the wg can adopt as wg document(s).
-        &nbs= p; Gabor=
=

From: ext P= eter Stanforth [mailto:peter@sp= ectrumbridge.com]
Sent: Sunday, April 22, 2012 6:18 PM
To: Bajko Gabor (= Nokia-CIC/SiliconValley); paws@ietf.org
Subject: Re: [paws] Database Discovery Question

If you are go= ing to quote the charter get it right (See below). At best task1 and = objective 1 are ambiguous, at worst the objective won't address the task. B= ut more to the point, it baffles me that PAWS is perfectly willing to update it's charter on a suggested ru= le (Ofcom consultation proposing a channel use report) yet not even discuss= a violation of the only implemented rules out there (FCC radio certificati= on process does not allow for a database discovery process).
Let me be very cle= ar, Spectrum Bridge supports, and desires to have, channel use feedback and= database discovery mechanisms. I believe our experience in deploying white= space networks, various white space databases and multiple radio/database protocols gives us the c= redibility to say these two topics raise the complexity of the PAWS task by= an order of magnitude. All Don was asking, on our behalf, was that PAWS ta= ke a bite out of the apple we can swallow quickly and not a bite that is so big it chokes us to death. I don= 't think that is unreasonable.
=85..complete the following tasks:=

1. Determine the relevant white space database t= o query.
<= span style=3D"color:#040100">
2. Connect to the database using a well-defined communic= ation method.

3. Provide it= s geolocation and perhaps other data to the database
using a well-defined format for queryin= g the database.
<= o:p>
4. Receive = in return a list of available white space spectrum with their characteristi= cs, using a well-defined format for returning information.

5. Report to the white space database spect= rum usage at a suitable granularity.

Once the device learns of the available white space (e.g., in a T= V
white space imp= lementation, the list of available channels at that
=
location), it can then select one of the= bands from the list and
begin to transmit and receive on the selected band. If the device's=
parameters have = changed (e.g., if some amount of time has passed or if
the device has changed location beyon= d a specified threshold), it might
need to query the database again to determine what white= space is still
a= vailable.
&n= bsp;
Objectives

The overall goals of this working= group are to:

1. Standardize a= mechanism for discovering a white space database.

2. Standardize= a method for communicating with a white space database.<= /pre>

= 3. Standardize the data formats to be carried= over the defined
database communication method.

4. Ensure that the discovery mechanism, database access method,
and query/response form= ats have appropriate security levels in place.

From: "<= a href=3D"mailto:Gabor.Bajko@nokia.com">Gabor.Bajko@nokia.com" <= ;Gabor.Bajko@nokia.com>
= To: Don Joslyn <d.= joslyn@spectrumbridge.com>, "paul@marvell.com" <paul@m= arvell.com>, "sdas@appcom= sci.com" <sdas@appcomsci.com>, &quo= t;paws@ietf.org" <paws@ietf.org>
Subject: Re: [paws] Da= tabase Discovery Question

<= p class=3D"MsoNormal">Don,

As chair, I= =92ll have to ask you to stop arguing against a database discovery protocol= . That is clearly within the scope for the wg, as the charter says:<= span style=3D"color:#040100">
<= span style=3D"color:#1F497D">=93Objectives
The overall goals of this working group are to:
1.       Standardiz= e a mechanism for discovering a white space database.=94 and it doesn=92t m= ention the optionality.
ietf is contrib= ution driven, if you are not interested in the discovery, then you do not n= eed to contribute to it. But do not try to persuade the wg to not work on a= piece which is in charter and folks are willing to do; that is not how ietf works.

- =          Gabor
=
paw= s-bounces@ietf.org [mailto:paw= s-bounces@ietf.org] On Behalf Of ext Don Joslyn
Sent: Friday, April 20, 2012 1= 2:21 PM
To: Paul Lambert; Das, Subir; paws@ietf.org
Subject: Re: [paws] Database Discovery Qu= estion

See reply belo= w.
Don

<= div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0= in 0in">
From:[mailto:paul@marvell.com] =
Sent: Thursday, April 19, 2012 2:36 PM
To: Don Joslyn;= Das, Subir; paws@ietf.org
Subje= ct: RE: [paws] Database Discovery Question

<= /o:p>
=

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

paw= s-bounces@ietf.org [mailto:paws-bounces@ietf.org= ] On Behalf Of Don Joslyn
Sent: Thursday, April 19, 2012 10:31 AM
To:<= /b> Das, Subir; paws@ietf.org
Su= bject: Re: [paws] Database Discovery Question

I don't think PAWS should define discovery,= I think the protocol should simply start after a device has "found&qu= ot; the correct database to use.

I feel this way for many reason= s:
1) In the US, a radio is certified to work with one or more specific d= atabases. So the device will be pre-configured to contact specific database= s, no need to implement a discovery service. If the device is programmed to work with more than one database provider, the device owner = will configure which one to use based on the relationship that they have es= tablished with the database provider (for example, which one they are payin= g to use).

When new databases come online, users w= ould likely appreciate an option to connect to a system additional services= or perhaps lower prices for the service.
=
[Don =96 Yes, this may be desired, but can the = device immediately take advantage of these new database records and decide = on its own to use a new one that has a lower cost? I would think that the device owner still needs to decid= e to use the lower cost service (may even have to consider why it costs les= s), pay for the service, and then configure the device to use it. I=92m not= sure how this can automatically happen between the discovery service and WSD. Will cost considerations be part of= the discovery solution? Is it cost per month, year, lifetime, message coun= t, etc? You mentioned cost, but there can be many other parameters that can= influence the selection outcome (SLA, features, etc.), where will we stop?]
&nb= sp;
If we go strictly on the preconfiguration mo= del =85 we don=92t even need PAWS. The relationship you describe woul= d have defined all the interfaces. If we are in the business of having open interfaces, we need to provide a means to d= iscocovery and select DBs.<= /span>
[Don =96 I don=92t ag= ree with the all-or-nothing argument, using discovery is optional (per PAWS= requirements). Establishing a standard protocol between WSDB and WSD is still valuable because, for example, will can still lower the c= ost to device manufacturers because they will only need to implement code f= or a single standard defined interface.]
<= /span>
Paul

= 2) Discovery services like LoST are based on = location, but the device's relationship with a database service is not know= n or considered. While it may seem simple to configure LoST or similar serv= ice to point to a database service based on location, how do you point to the one that = the customer has a relationship with, for example, paid to use? I do realiz= e that this may not be an issue in every country.
3) If PAWS defines a gl= obally applicable discovery process and either picks an existing protocol (= like LoST) or designs one, most likely it would include a centrally based d= iscovery service. What entity will be responsible for hosting and configuring the central discovery service? = How will PAWS define this as a global solution, and deal with the politics = between countries?
4) Some radio manufacturers do not have very much ROM = to include even more code on their device. I'm concerned that discovery wil= l consume even more space on the radio, space that they may not even have.<= o:p>
5) I believe that defining discovery will take more time than defining th= e protocol between the WSDB and WSD.

I think that database disco= very should be left to each country to define based on their own requiremen= ts and Whitespace ecosystem.

Regards,
Don

From:paws-bounces@ie= tf.org [mailto:paws-bounces@ietf.org= ]On Behalf Of Das, Subir
Sent: Tuesday, April 17, 2012 5:26 PM
To: paws@ietf.org
Subject: [pa= ws] Database Discovery Question

During PAWS session in Paris IETF, there were a lot of questi= ons/discussions on 'Discovery' of Database. It was not clear to me except i= f we are talking about "Database Server Discovery", in particular= , the domain name or the IP address of the 'Server" that is hosting the dat= abase. OTH, I felt that some folks may have different views and they would = possibly like to see more features than just discovering the domain name or= IP address of the "Database Server".
<= /p>
In some offline = discussions, I was told that it may be similar to what LOST (RFC 5222) has = defined. I read the LOST protocol and associated architecture and my curren= t understanding is that the LOST use case is different than what we are trying to achieve via PAWS. Here is my under= standing of the operating model of PAWS interface (when defined):
<= o:p>
-"Fixed/Mode II WSD" (per figure 1,<draft-das-paws-protocol-= 01>) can only query the database

-The manufacturer of the &q= uot;Fixed/Mode II WSD" may be different than owner/operator of this de= vice

-"Fixed/Mode II WSD" is certified by the regulato= ry body of the region that they serve

- Either the "Fixed/M= ode II WSD" device operator or the device vendor has an a-priori relat= ionship with one or more covering database administrators. This relationshi= p
is utilized to either configure or enable the discovery of the pr= oper database to contact in the current location
=

I woul= d like to know the group's view of the above model. To me, finding the emer= gency services or restaurant information near my location is different than= getting to know a server that can provide me with channel/frequency/power and other information in the location where "= Fixed/Mode II WSD" is situated. In addition, emergency services do not= require a subscription and the service is mandated by the Government/regul= atory bodies. Some may argue that 'White Space' service may be free as well, but to my understanding it is not quite the s= imilar model as emergency services.

I hope with this t= hread we can clarify/understand the discovery issue.

Regards,

_Subir

=
--_000_CBBB61C924052peterspectrumbridgecom_--