Subject: [paws] Database Discovery Question

From: "Das, Subir" <[email-masked]>
Date: Tue, 17 Apr 2012 21:26:21 +0000

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" that is hosting the database. 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 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 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" may be different than 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 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 the emergency 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/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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Apr 2012 17:40:41 -0400

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.

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

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 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, portability, antenna characteristics…  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.

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 without a root.

Brian

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

Regards,

_Subir

_______________________________________________
paws mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/paws

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 17 Apr 2012 17:48:22 -0400

typo below
"Discovery then is type and location in, database URI (not IP address I think) out."
On Apr 17, 2012, at 5:40 PM, Rosen, Brian wrote:

Brian

Regards,

_Subir

---

From: "Das, Subir" <[email-masked]>
Date: Wed, 18 Apr 2012 02:22:26 +0000

On Apr 17, 2012, at 5:41 PM, "Rosen, Brian" <[email-masked]<mailto:[email-masked]>> wrote:

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

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

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

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

Brian

Regards,

_Subir

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 18 Apr 2012 08:20:25 -0400

Brian,
The concept of "finding the right one" assumes that the DB will support the device. I am not sure I would do this, as a database operator, but now that brings up the possibility that I would refuse to support the device, which then it has to find another database to talk to. I am assuming that your comment below about "more than one suitable database" is intended to cover scenarios like this.
Peter S.

From: <Rosen>, Brian <[email-masked]<mailto:[email-masked]>>
To: "Das, Subir" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Database Discovery Question

typo below

Brian

Regards,

_Subir

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Apr 2012 09:15:56 -0400

Yes, indeed.  Although the U.S. model of competing databases may be replicated, some nations may operate the database as a single national resource, or they may have different databases in different regions, or lots of other arrangements.  We can't assume.  What we can do is provide a list of potential servers given location and type.

Brian

On Apr 18, 2012, at 8:20 AM, Peter Stanforth wrote:

 Brian,

typo below

Brian

Regards,

_Subir

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Apr 2012 09:24:33 -0400

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

    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.

   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 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 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 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 possible servers.

   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 emergency calls and those are two IETF solutions for that problem.

Brian

Regards,

_Subir

---

From: Peter McCann <[email-masked]>
Date: Wed, 18 Apr 2012 14:37:33 +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, 
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: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Apr 2012 10:42:00 -0400

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

---

From: Peter McCann <[email-masked]>
Date: Wed, 18 Apr 2012 14:51:37 +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:
>> 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.
>> 
>> 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:
>> 
>> 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: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Apr 2012 11:04:50 -0400

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

---

From: Don Joslyn <[email-masked]>
Date: Wed, 18 Apr 2012 11:10:21 -0400

See response below...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, April 18, 2012 10:42 AM
To: Peter McCann
Cc: [email-masked]
Subject: Re: [paws] Database Discovery Question

[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 master device must validate the slave device (FCCID) first via the Whitespace database.]

Brian

On Apr 18, 2012, at 10:37 AM, Peter McCann wrote:

> In particular, I think there is a thorny issue that will arise with 
> 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
> 

[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Apr 2012 11:13:33 -0400

Yes, an example of what I was talking about.  The credentials to access the database in this case are the master's.

Brian

---

From: Peter McCann <[email-masked]>
Date: Wed, 18 Apr 2012 15:16:50 +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 
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
> 
>> 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:
>>>> management of secure credentials on whitespace devices,
>>>> draft-ietf-paws-problem-stmt-usecases-rqmts-03.  Step 9 of that
>>>> use case says:
>>>> 
>>>> 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

---

From: "Das, Subir" <[email-masked]>
Date: Wed, 18 Apr 2012 15:25:01 +0000

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:[email-masked]]
Sent: Wednesday, April 18, 2012 9:25 AM
To: Das, Subir
Cc: [email-masked]
Subject: Re: [paws] Database Discovery Question

Inline

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 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, portability, antenna characteristics...  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.

Brian

Regards,

_Subir

---

From: Don Joslyn <[email-masked]>
Date: Wed, 18 Apr 2012 11:28:39 -0400

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 the 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 to directly access the database.

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] 
Sent: Wednesday, April 18, 2012 11:14 AM
To: Don Joslyn
Cc: Peter McCann; [email-masked]
Subject: Re: [paws] Database Discovery Question

Brian

On Apr 18, 2012, at 11:10 AM, Don Joslyn wrote:

> [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 master device must validate the slave device (FCCID) first via 
> the Whitespace database.]
> 
> Brian
> 
>> decide to subdivide their territory into provinces or states, each of 
>> which maintains its own database.
>> 
>> management of secure credentials on whitespace devices, illustrated 
>> by the first use case in Section 4.2.1 of 
>> Or will this "validation" be simply an insecure check of an ID 
>> against a whitelist/blacklist?  Who will allocate Device IDs?

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Apr 2012 11:27:29 -0400

<As individual, and I should have said that on all of my messages on 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

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 18 Apr 2012 11:36:31 -0400

<as individual>
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 master, and thus some sort of negotiation has to happen.  That could happen.  The 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 the slave may be close enough that it could be blocked, even with different power/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 databases could be the same or different.

Brian

---

From: Don Joslyn <[email-masked]>
Date: Wed, 18 Apr 2012 12:04:43 -0400

Based on the PAWS definition of master versus slave, you are correct, the slave does not query the database.

I think the confusion is that if you have a master device on a tower supporting several fixed devices, the FCC considers them all as fixed TVBDs, which means they are all master devices according to the PAWS definition. In the US, based on FCC rules, the only device type that qualifies as a PAWS slave device is the Mode I personal/portable.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, April 18, 2012 11:05 AM
To: Peter McCann
Cc: [email-masked]
Subject: Re: [paws] Database Discovery Question

Brian

On Apr 18, 2012, at 10:51 AM, Peter McCann wrote:

>>> against a whitelist/blacklist?  Who will allocate Device IDs? Will 
>>> they be specific to a particular database operator, or do we need

---

From: Peter McCann <[email-masked]>
Date: Wed, 18 Apr 2012 16:02:20 +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 
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:
> <As individual, and I should have said that on all of my messages on
> 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.
> 
> 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
> 
>> 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:
>>> 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.
>>> 
>>>> Wouldn't we want them to interoperate with any master device,
>>>> assuming they are RF-compatible?
>>>> 
>>>> -Pete
>>>> 
>>>> Rosen, Brian wrote:
>>>>>> anchor? Or will this "validation" be simply an insecure check of an
>>>>>> ID against a whitelist/blacklist?  Who will allocate Device IDs?

---

From: "Das, Subir" <[email-masked]>
Date: Wed, 18 Apr 2012 16:15:48 +0000

Agree.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, April 18, 2012 11:05 AM
To: Peter McCann
Cc: [email-masked]
Subject: Re: [paws] Database Discovery Question

Brian

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 18 Apr 2012 13:25:45 -0400

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.

---

From: Peter McCann <[email-masked]>
Date: Wed, 18 Apr 2012 18:24:04 +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 
mistaken, and is FCC ID more akin to a model number than a serial number?

-Pete

Peter Stanforth wrote:
> 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.
> 
>> 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:
>>>> 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
>>>>> 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.
>>>>> 
>>>>> clients of the tower are the slaves.  Does the database query use
>>>>> the location and type data of the slave or the master?
>>>>> 
>>>>> Brian
>>>>> 
>>>>>> 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:
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>>      (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.
>>>>>>>> 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: Don Joslyn <[email-masked]>
Date: Thu, 19 Apr 2012 13:30:58 -0400

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.

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 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 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 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 relationship with, for example, paid to use? I do realize that this may not 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 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 manufacturers do not have very 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 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 based on their own requirements and Whitespace ecosystem.

Regards,

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of Das, Subir
Sent: Tuesday, April 17, 2012 5:26 PM
To: [email-masked]
Subject: [paws] Database Discovery Question

Regards,

_Subir

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Apr 2012 14:00:31 -0400

<as individual>
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 location and type of device.

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

See inline for comments
On Apr 19, 2012, at 1:30 PM, Don Joslyn wrote:

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 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 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 could be based on existing subscriptions, but could also be based on roaming 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. customer, who visits the U.S.  The customer's U.K. provider has a roaming arrangement with one or 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 discovery mechanism.

2) Discovery services like LoST are based on location, 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 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.  Also, I expect arrangements in some other countries 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 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?
LoST is designed to not require a central anything.  It's distributed.  It cleverly avoids the political mess.  The designers were mindful of these issues.

I'm waving my hands a bit, but it's a very good answer for discovery of location 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 space 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 based 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.

---

From: "Das, Subir" <[email-masked]>
Date: Thu, 19 Apr 2012 18:33:20 +0000

SD> I would not consider both of them at the same level.

I do not understand how we will satisfy the following:

If it is an operator managed LoST service (likely) how would it know what answer to provide for the other database assuming there is no roaming relationship.  And why should the operator provide this, if he is not managing the whitespace service.

From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, April 19, 2012 2:01 PM
To: Don Joslyn
Cc: Das, Subir; [email-masked]
Subject: Re: [paws] Database Discovery Question

<as individual>
I disagree.

See inline for comments

---

From: Paul Lambert <[email-masked]>
Date: Thu, 19 Apr 2012 11:35:46 -0700

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

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

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

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 means to discocovery and select DBs.

Paul

Regards,

Don

Regards,

_Subir

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Apr 2012 14:40:58 -0400

We're getting solutions ahead of requirements.

LoST is a solution to a requirement for discovery.

However, the answer to your question is that either we use an existing LoST service and add service urns for our purpose, or all the database operators in an area cooperate to run one LoST service, or some single neutral entity runs it.

Brian

On Apr 19, 2012, at 2:33 PM, Das, Subir wrote:

From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, April 19, 2012 2:01 PM
To: Don Joslyn
Cc: Das, Subir; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Database Discovery Question

<as individual>
I disagree.

See inline for comments

---

From: "Das, Subir" <[email-masked]>
Date: Thu, 19 Apr 2012 19:31:44 +0000

From: Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, April 19, 2012 2:41 PM
To: Das, Subir
Cc: Don Joslyn; [email-masked]
Subject: Re: [paws] Database Discovery Question

SD> Not my intention though.

SD>  As I mentioned in my earlier mail, my understanding is:  that requirement and deployment model are not entirely identical  to PAWS. Am I wrong?   I am not against  having a solution for discovery and I am also not saying that we need to rely only upon pre-configuration.  My goal was to clarify the operating model and requirements since there were a lot of confusions in my mind during Paris meeting.   I think we are getting there but it would be good to hear from more people and in particular from folks that are going to deploy and use it.   Your input is definitely valuable since you understand LoST more than many of us.

SD>  If there is no roaming relationship, will that adding a service urn help?  Second part  may be  difficult  unless some regulators mandate it.

Brian

<as individual>
I disagree.

See inline for comments

---

From: <[email-masked]>
Date: Thu, 19 Apr 2012 19:35:26 +0000

I agree that we are jumping off to discuss the solution space.
The requirement for PAWS is that we need a database discovery mechanism.
There can be multiple approaches towards this requirement. LoST is one option. But there are others as well and it would be useful to actually have some I-Ds proposing a solution for discovery than fragmented pieces of information and ideas.

-Raj

From: "<ext Rosen>", "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, April 19, 2012 1:40 PM
To: "Das, Subir" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] Database Discovery Question

Brian

<as individual>
I disagree.

See inline for comments

---

From: Don Joslyn <[email-masked]>
Date: Fri, 20 Apr 2012 12:08:11 -0400

Brian,
Please see my reply inline below.
Don

<as individual>
I disagree.

[Don - If a device is presented a list 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 other 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 the radio make the choice that fits the users choice? Are we ignoring the business relationship within the ecosystem that may be used to match a customer 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 only 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 cost for access, I'm pretty sure the user will decide which database to use before the radio is fired up.]

[Don - I would think that GSM cell phones are slave devices and thus do not need to access a whitespace database, and I think slave roaming is outside the scope of PAWS protocol.]

See inline for comments

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 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 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 could be based on existing subscriptions,
[Don - If based on existing subscriptions, I'm still configuring the radio to pick a specific one, so what benefit did I really get from discovery (other than added complexity)?]
but could also be based on roaming 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. customer, who visits the U.S.  The customer's U.K. provider has a roaming arrangement with one or more U.S. database operators.
[Don - Interesting... how do we define these roaming arrangements within the discovery domain in such a way that discovery provides the right answer to the radio? 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 the device is certified to work in 25 countries.
[Don - Will PAWS also be defining all of the possible selection criteria and supporting algorithms (for 25 countries) that either the discovery service or radio must understand 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.  You can do it, but I want a standardized discovery mechanism.
[Don - For a global mobile environment 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 protocol to exchange whitespace channel lists.]

2) Discovery services like LoST are based on location, 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 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 below. Are we now defining a roaming database?]
Also, I expect arrangements in some other countries will be simpler than the U.S.
[Don -Simpler than having the device owner configure a database provider address while they are setting other configuration parameters on the device? Somebody is going to have to configure the discovery 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 globally applicable discovery process and either picks an existing protocol (like LoST) or designs one, most likely 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?
LoST is designed to not require a central anything.  It's distributed.  It cleverly avoids the political mess.  The designers were mindful of these issues.
[Don - You avoided my question regarding hosting and configuration.]

I'm waving my hands a bit, 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 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 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.
[Don - You're simply avoiding the issue, ok.]

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.
[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 we've already discussed, I'm still concerned that it may not be the case.]

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 close up shop and let each country define their own database query protocol.
[Don - I'm not falling for the all-or-nothing argument.]

---

From: Don Joslyn <[email-masked]>
Date: Fri, 20 Apr 2012 15:20:40 -0400

See reply below.
Don

From: Paul Lambert [mailto:[email-masked]]
Sent: Thursday, April 19, 2012 2:36 PM
To: Don Joslyn; Das, Subir; [email-masked]
Subject: RE: [paws] Database Discovery Question

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Don Joslyn
Sent: Thursday, April 19, 2012 10:31 AM
To: Das, Subir; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Database Discovery Question

[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 decide 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'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 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?]

[Don - I don't agree 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 cost to device manufacturers because they will only need to implement code for a single standard defined interface.]

Paul

Regards,

Don

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Das, Subir
Sent: Tuesday, April 17, 2012 5:26 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] Database Discovery Question

Regards,

_Subir

---

From: <[email-masked]>
Date: Fri, 20 Apr 2012 21:06:04 +0000

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." and it doesn't mention the optionality.
ietf is contribution driven, 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.

-          Gabor

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

See reply below.
Don

From: Paul Lambert [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Thursday, April 19, 2012 2:36 PM
To: Don Joslyn; Das, Subir; [email-masked]<mailto:[email-masked]>
Subject: RE: [paws] Database Discovery Question

Paul

Regards,

Don

Regards,

_Subir

---

From: Peter Stanforth <[email-masked]>
Date: Sun, 22 Apr 2012 21:18:09 -0400

If you are going 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. 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 implemented rules out there (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 database discovery mechanisms. I believe our experience in deploying white space networks, various white space databases and multiple radio/database protocols 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 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 characteristics, using a well-defined format for returning information.

5. Report to the white space database spectrum 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 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

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: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
To: Don Joslyn <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.” and it doesn’t mention the optionality.
ietf is contribution driven, 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.

-          Gabor

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Don Joslyn
Sent: Friday, April 20, 2012 12:21 PM
To: Paul Lambert; Das, Subir; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Database Discovery Question

See reply below.
Don

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Don Joslyn
Sent: Thursday, April 19, 2012 10:31 AM
To: Das, Subir; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Database Discovery Question

[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 decide 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’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 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 … 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 means to discocovery and select DBs.

[Don – I don’t agree 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 cost to device manufacturers because they will only need to implement code for a single standard defined interface.]

Paul

Regards,

Don

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]On Behalf Of Das, Subir
Sent: Tuesday, April 17, 2012 5:26 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [paws] Database Discovery Question

Regards,

_Subir

---

From: <[email-masked]>
Date: Mon, 23 Apr 2012 20:36:14 +0000

Are you now saying that the charter text is wrong because regulators will require that there should 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 shared by other regulators or not.
In FCC case, the device will simply not need to make use of discovery, as it 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 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 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 which the wg can adopt as wg document(s).

-          Gabor

From: ext Peter Stanforth [mailto:[email-masked]]
Sent: Sunday, April 22, 2012 6:18 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]
Subject: Re: [paws] Database Discovery Question

.....complete the following tasks:

available.

Objectives

Don,

-          Gabor

See reply below.
Don

Paul

Regards,

Don

Regards,

_Subir

---

From: Peter Stanforth <[email-masked]>
Date: Mon, 23 Apr 2012 20:20:11 -0400

What I am saying is that a DB will be managing  access to spectrum, which come 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 that luxury and, like Ofcom, choose to have a managed discovery mechanism. The simple fact is that, using SBI as an example, we were certified on our ability to protect incumbents. We are required to provide that protection for 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 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 someone a little "extra" white space for the right return? That is why I believe the regulator is going to  retain control of the permitted DB administrators, and incumbents will demand it.  What ever we discuss in the way of a determining the relevant database/discovery process has to be within that context.  Splitting the protocol and discovery process 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 allow 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: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
To: Peter Stanforth <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [paws] Database Discovery Question

Are you now saying that the charter text is wrong because regulators will require that there should 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 shared by other regulators or not.
In FCC case, the device will simply not need to make use of discovery, as it 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 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 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 which the wg can adopt as wg document(s).

-          Gabor

From: ext Peter Stanforth [mailto:[email-masked]]
Sent: Sunday, April 22, 2012 6:18 PM
To: Bajko Gabor (Nokia-CIC/SiliconValley); [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Database Discovery Question

available.

Objectives

Don,

-          Gabor

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Don Joslyn
Sent: Friday, April 20, 2012 12:21 PM
To: Paul Lambert; Das, Subir; [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] Database Discovery Question

See reply below.
Don

Paul

Regards,

Don

Regards,

_Subir