Subject: Re: [paws] draft-wei-paws-database-discovery-01

From: Vincent Chen <[email-masked]>
Date: Tue, 4 Jun 2013 19:20:36 -0700

Xinpeng, All,

Thanks for putting this together.

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

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

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

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

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

 1. Device asks database for available spectrum in a location outside the
coverage area for the Databae
 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of
(name, databaseUri) entries to "recommend" alternate databases

This provides almost the same capability.

Should we just add a ListDatabase to PAWS?

-vince

On Thu, May 23, 2013 at 6:57 PM, Weixinpeng <[email-masked]> wrote:

>  Hi Mark,****
>
>          Please see comments inline. Thanks!****
>
> ** **
>
> Best Regards,****
>
> Xinpeng.****
>
> ** **
>
> ** **
>
> *From:* Mark Jones [mailto:[email-masked]]
> *Sent:* Thursday, May 23, 2013 10:31 PM
> *To:* Weixinpeng; [email-masked]
>
> *Cc:* Peter McCann; Zhulei (A)
> *Subject:* RE: [paws] draft-wei-paws-database-discovery-01****
>
>  ** **
>
> Hi Xinpeng,****
>
> ** **
>
> Thank you for your responses. I have some further comments/questions
> inline below (prefixed by mj>).****
>
> ** **
>
> *From:* Weixinpeng [mailto:[email-masked] <[email-masked]>]
> *Sent:* May-22-13 11:13 PM
> *To:* Mark Jones; [email-masked]
> *Cc:* Peter McCann; Zhulei (A)
> *Subject:* RE: [paws] draft-wei-paws-database-discovery-01****
>
> ** **
>
> Hi Mark,****
>
>          Thanks for your feedback, and I think there are some issues that
> I need to clarify.****
>
>          ****
>
>          we have to be clear that the discovery mechanism is provided as
> an optional method that can help master device to find the correct WSDB,
> which means the master device can get WSDB by, such as, pre-configuring of
> WSDB, provision etc. ****
>
> ** **
>
> mj> Understood.****
>
> ** **
>
>          The dynamic discovery mechanism provides more convenient for
> master device to find WSDB, for example, when a new WSDB is setup for
> providing service or when some deployed WSDB goes down and never work.****
>
>          ****
>
> mj> In this regard, DNS resolution would appear to be equally convenient
> mechanism to manage WSDB instances being commissioned or decommissioned. I
> view LoST as a kind of “location-aware DNS” so I understand its
> applicability to discovery of the appropriate WSDB. I still think the draft
> needs more information on how the Master device finds its WSDB DS so that
> implementers understand if/when this optional discovery method is
> applicable to their deployment.****
>
> *[Wei] Yeah, because we cannot covey location information in DNS query
> message, so DNS is inappropriate to find the WSDB. I think I will do more
> clarification about how master device finds WSDB DS later.*****
>
> ** **
>
>          About the DHCP you mentioned below, technically speaking, there
> have been some extension of DHCP for supporting the provision of LoST
> server, refer to RFC5223. ****
>
> ** **
>
> mj> I understand that the DHCP option specifying the LoST server would be
> provided to the Master device when it initiated its backhaul connection
> (non-WS connection) to the internet. Correct?****
>
> *[Wei] Yeah.*****
>
> ** **
>
> Besides, using DHCP method doesn’t means IP network provider must have
> some business relationship with WSDB DS provider, if the network provider
> wants to provide master device with FQDN of WSDB DS it can use DHCP.****
>
> ** **
>
> mj> If the backhaul network operator is configuring his DHCP server to
> send options to provision the WSDB DS then I assume he has some business
> interest in doing so. What am I missing?****
>
> *[Wei] I think there may be some relationship between network operator
> and WSDB DS. But the reason why DHCP is mentioned here is because in the
> LoST protocol DHCP is extended to provide LoST server’s domain name to the
> LoST client.*****
>
> ** **
>
> Thanks****
>
> Mark****
>
> ** **
>
> Best Regards,****
>
> Xinpeng.****
>
> ** **
>
> *From:* Mark Jones [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, May 22, 2013 11:29 PM
> *To:* Weixinpeng; [email-masked]
> *Cc:* Peter McCann
> *Subject:* RE: [paws] draft-wei-paws-database-discovery-01****
>
> ** **
>
> Hi Xinpeng,****
>
> ** **
>
> In section 3, you state:****
>
> ** **
>
>    The URL or IP address of WSDB DS can be found by any method such as****
>
>    DNS, DHCP, manually configuring etc, and it is out of scope of this****
>
>    document.****
>
> ** **
>
> I’m unclear on how the Master device obtains the URL of a trusted
> discovery server unless there is some pre-configuration involved. I
> understand that DNS could be used if the Master device is already
> pre-configured with a preferred/home TVWS DS URL (or a preferred/home
> domain that is then resolved with U-NAPTR) but I don’t see how DHCP could
> be used to bootstrap this information in the TVWS scenarios. Please could
> you elaborate.****
>
> ** **
>
> Thanks****
>
> Mark****
>
> ** **
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Weixinpeng
> *Sent:* May-21-13 9:11 PM
> *To:* [email-masked]
> *Cc:* Peter McCann
> *Subject:* [paws] draft-wei-paws-database-discovery-01****
>
> ** **
>
> Hi all, ****
>
>          I have uploaded a new version draft on database discovery.
> Comments are welcomed.****
>
> http://tools.ietf.org/html/draft-wei-paws-database-discovery-01.****
>
> ** **
>
> ** **
>
> Xinpeng Wei****
>
> _______________________________________________
> paws mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/paws
>
>

-- 
-vince

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 5 Jun 2013 12:36:18 +0000

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

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

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

Brian

On Jun 4, 2013, at 10:20 PM, Vincent Chen <[email-masked]<mailto:[email-masked]>> wrote:

Xinpeng, All,

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

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

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

 1. Device asks database for available spectrum in a location outside the coverage area for the Databae
 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (name, databaseUri) entries to "recommend" alternate databases

-vince

On Thu, May 23, 2013 at 6:57 PM, Weixinpeng <[email-masked]<mailto:[email-masked]>> wrote:
Hi Mark,
         Please see comments inline. Thanks!

Best Regards,
Xinpeng.

From: Mark Jones [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, May 23, 2013 10:31 PM
To: Weixinpeng; [email-masked]<mailto:[email-masked]>

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

Hi Xinpeng,

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

From: Weixinpeng [mailto:[email-masked]]
Sent: May-22-13 11:13 PM
To: Mark Jones; [email-masked]<mailto:[email-masked]>
Cc: Peter McCann; Zhulei (A)
Subject: RE: [paws] draft-wei-paws-database-discovery-01

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

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

mj> Understood.

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

mj> In this regard, DNS resolution would appear to be equally convenient mechanism to manage WSDB instances being commissioned or decommissioned. I view LoST as a kind of “location-aware DNS” so I understand its applicability to discovery of the appropriate WSDB. I still think the draft needs more information on how the Master device finds its WSDB DS so that implementers understand if/when this optional discovery method is applicable to their deployment.
[Wei] Yeah, because we cannot covey location information in DNS query message, so DNS is inappropriate to find the WSDB. I think I will do more clarification about how master device finds WSDB DS later.

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

mj> I understand that the DHCP option specifying the LoST server would be provided to the Master device when it initiated its backhaul connection (non-WS connection) to the internet. Correct?
[Wei] Yeah.

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

mj> If the backhaul network operator is configuring his DHCP server to send options to provision the WSDB DS then I assume he has some business interest in doing so. What am I missing?
[Wei] I think there may be some relationship between network operator and WSDB DS. But the reason why DHCP is mentioned here is because in the LoST protocol DHCP is extended to provide LoST server’s domain name to the LoST client.

Thanks
Mark

Best Regards,
Xinpeng.

From: Mark Jones [mailto:[email-masked]]
Sent: Wednesday, May 22, 2013 11:29 PM
To: Weixinpeng; [email-masked]<mailto:[email-masked]>
Cc: Peter McCann
Subject: RE: [paws] draft-wei-paws-database-discovery-01

Hi Xinpeng,

In section 3, you state:

   The URL or IP address of WSDB DS can be found by any method such as
   DNS, DHCP, manually configuring etc, and it is out of scope of this
   document.

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

Thanks
Mark

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Weixinpeng
Sent: May-21-13 9:11 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Peter McCann
Subject: [paws] draft-wei-paws-database-discovery-01

Hi all,
         I have uploaded a new version draft on database discovery. Comments are welcomed.
http://tools.ietf.org/html/draft-wei-paws-database-discovery-01.

Xinpeng Wei

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

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

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 5 Jun 2013 09:00:40 -0400

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

Sent from my iPhone

On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Xinpeng, All,

-vince

Best Regards,
Xinpeng.

Hi Xinpeng,

Hi Mark,

mj> Understood.

Thanks
Mark

Best Regards,
Xinpeng.

Hi Xinpeng,

In section 3, you state:

Thanks
Mark

Hi all,

Xinpeng Wei

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 5 Jun 2013 13:33:48 +0000

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

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

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

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

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

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

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

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

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

Brian

On Jun 5, 2013, at 9:00 AM, Peter Stanforth <[email-masked]<mailto:[email-masked]>> wrote:

Sent from my iPhone

Brian

Xinpeng, All,

-vince

Best Regards,
Xinpeng.

Hi Xinpeng,

Hi Mark,

mj> Understood.

Thanks
Mark

Best Regards,
Xinpeng.

Hi Xinpeng,

In section 3, you state:

Thanks
Mark

Hi all,

Xinpeng Wei

---

From: Vincent Chen <[email-masked]>
Date: Wed, 5 Jun 2013 08:42:10 -0700

Couple of thoughts:

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

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

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

-vince

On Wed, Jun 5, 2013 at 6:33 AM, Rosen, Brian <[email-masked]>wrote:

>  It says, basically, that if you are permitted to operate in more than
> one domain, you should be pre-configured with URIs for
>  It has no text that describes how you select one, either the first time,
> or any subsequent time.  It would be perfectly compatible with the doc as
> it is to try servers in a list of 100 randomly until you found one that
> accepted you.
>
>  I would suggest that you get preconfigured with exactly one database.
>  If that needs to change, change the configuration.
>
>  Discovery is the mechanism by which you find out about databases given
> your location.  It has to be a protocol - you send in your location (and
> probably nothing else other than perhaps a device id), and you get back a
> listing server or list of dbs in that area.  Discovery has to work with a
> set of per country polygons.  The discovery service needs to find out which
> country you are in and give you the listing service or dbs for that
> country.
>
>  Devices may have lists of dbs they are authorized to use.  If they knew
> what country they were in, they could try one of the ones they are
> configured for.  But something has to tell them that.  You wouldn't
> configure a device with all the dbs in a country, you would configure one
> (or possibly more), the device was authorized to use.
>
>  It might make sense to provide some kind of discovery sequence that has
> a cache of the last server, so you don't have to the whole sequence from
> the top every time you boot.
>
>  I don't think expecting every db to know about every other country's dbs
> will scale very well.  When there is only 2-3 countries that have such DBs,
> maybe, but if there were 50 or more, the lists would be too difficult for
> every other DB to track.
>
>  Brian
>
>
>  On Jun 5, 2013, at 9:00 AM, Peter Stanforth <[email-masked]>
> wrote:
>
>  Brian. Why do you assume a device will always go back to its original DB
> rather than the one it last registered with. The latter seems more likely,
> and more logical, to me
> Peter S.
>
> Sent from my iPhone
>
> On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" <[email-masked]>
> wrote:
>
>  The problem I see with this is that the database originally contacted
> (presumably configured directly or indirectly) is forever responsible for
> referrals to the correct database.  It provides no other service for the
> device.
>
>  If I purchased a device in New York City and moved to London, the US
> database has to refer me every time I try to register.
>
>  Having a separate database whose job is to do that referral seems like a
> more rational solution.  Any device or service that wanted to participate
> in that kind of "nomadic" operation could contribute to the cost of
> providing the service.  Cross subsidizing the U.S. database from the U.K.
> database for the referral seems less likely to succeed.
>
>  Brian
>
>  On Jun 4, 2013, at 10:20 PM, Vincent Chen <[email-masked]> wrote:
>
>  Xinpeng, All,
>
>  The current document is placing deployment out of scope, but does
> suggest that preconfiguration is a strategy.

-- 
-vince

---

From: "Harasty, Daniel J" <[email-masked]>
Date: Wed, 5 Jun 2013 16:16:13 +0000

Brian Rosen commented:

I don't agree that we write the spec in such a way that enforces - or even encourages - that a Device should be configurable with exactly one Database URL.

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

I think it is much more robust for the device to be allowed - even encouraged - to be configurable with a list of Database URLs; as it allows Device to try a list - and presumably - experience fewer outages due to inability to contact any Database.

Dan Harasty
Wireless Systems and Networks Dept
Applied Communication Sciences
Red Bank, NJ

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: Wednesday, June 05, 2013 9:34 AM
To: Peter Stanforth
Cc: [email-masked]; Peter McCann
Subject: Re: [paws] draft-wei-paws-database-discovery-01

Brian

Sent from my iPhone

Brian

Xinpeng, All,

-vince

Best Regards,
Xinpeng.

Hi Xinpeng,

Hi Mark,

mj> Understood.

mj> In this regard, DNS resolution would appear to be equally convenient mechanism to manage WSDB instances being commissioned or decommissioned. I view LoST as a kind of "location-aware DNS" so I understand its applicability to discovery of the appropriate WSDB. I still think the draft needs more information on how the Master device finds its WSDB DS so that implementers understand if/when this optional discovery method is applicable to their deployment.
[Wei] Yeah, because we cannot covey location information in DNS query message, so DNS is inappropriate to find the WSDB. I think I will do more clarification about how master device finds WSDB DS later.

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

mj> If the backhaul network operator is configuring his DHCP server to send options to provision the WSDB DS then I assume he has some business interest in doing so. What am I missing?
[Wei] I think there may be some relationship between network operator and WSDB DS. But the reason why DHCP is mentioned here is because in the LoST protocol DHCP is extended to provide LoST server's domain name to the LoST client.

Thanks
Mark

Best Regards,
Xinpeng.

Hi Xinpeng,

In section 3, you state:

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

Thanks
Mark

Hi all,

Xinpeng Wei

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 5 Jun 2013 17:35:09 +0000

<as individual>
The problem with more than one is what the device does when it has more than one.

First of all, reliability, geographic diversity, capacity, etc are usually done with common URLs.  Witness www.google.com<http://www.google.com>
Segregation of devices would presumably have different URLs on different devices, not multiple URLs on the same device.

I don't think configuration is a good solution for any device, but a simple configuration option is the simplest, most universal way to get something to work.
Once you are past simple configuration, I personally feel that discovery is the best mechanism.

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

Brian
On Jun 5, 2013, at 12:16 PM, "Harasty, Daniel J" <[email-masked]<mailto:[email-masked]>> wrote:

Brian Rosen commented:

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

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

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

Dan Harasty

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Rosen, Brian
Sent: Wednesday, June 05, 2013 9:34 AM
To: Peter Stanforth
Cc: [email-masked]<mailto:[email-masked]>; Peter McCann
Subject: Re: [paws] draft-wei-paws-database-discovery-01

Brian

Sent from my iPhone

Brian

Xinpeng, All,

-vince

Best Regards,
Xinpeng.

Hi Xinpeng,

Hi Mark,

mj> Understood.

Thanks
Mark

Best Regards,
Xinpeng.

Hi Xinpeng,

In section 3, you state:

Thanks
Mark

Hi all,

Xinpeng Wei

---

From: <[email-masked]>
Date: Wed, 5 Jun 2013 18:50:02 +0100

Dear all

Sorry to come in late but the foregoing discussion has sparked a worry in my mind.

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

Is there anything in the foregoing discussion that would prevent this ?

Michael

Sent: 05 June 2013 18:35
To: Harasty, Daniel J
Cc: [email-masked]

<as individual>

Brian

Brian Rosen commented:

Dan Harasty

Brian

Sent from my iPhone

Brian

Xinpeng, All,

-vince

Best Regards,
Xinpeng.

Hi Xinpeng,

Hi Mark,

mj> Understood.

Thanks
Mark

Best Regards,
Xinpeng.

Hi Xinpeng,

In section 3, you state:

Thanks
Mark

Hi all,

Xinpeng Wei

---

From: Peter Stanforth <[email-masked]>
Date: Wed, 5 Jun 2013 13:58:47 -0400

Michael,
In your example who, or what is making the decision? From a purely practical (DB manager) perspective I want to know that the "entity" that made the choice is going to pay for the value added service that is offered, and it has just signed up for.
I have always seen the value-add as a service/business plane above PAWS rather than something PAWS would define.
Peter S.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 5, 2013 1:50 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] draft-wei-paws-database-discovery-01

Dear all

Michael

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Rosen, Brian
Sent: 05 June 2013 18:35
To: Harasty, Daniel J
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] draft-wei-paws-database-discovery-01

<as individual>

Brian

Brian Rosen commented:

Dan Harasty

Brian

Sent from my iPhone

Brian

Xinpeng, All,

-vince

Best Regards,
Xinpeng.

Hi Xinpeng,

Hi Mark,

mj> Understood.

Thanks
Mark

Best Regards,
Xinpeng.

Hi Xinpeng,

In section 3, you state:

Thanks
Mark

Hi all,

Xinpeng Wei

---

From: Vincent Chen <[email-masked]>
Date: Wed, 5 Jun 2013 11:14:51 -0700

Brian,

>  First of all, reliability, geographic diversity, capacity, etc are
> usually done with common URLs.  Witness www.google.com
>

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

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

-vince

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 5 Jun 2013 18:43:30 +0000

<as individual>
No, but we are discussing multiple URLs for the SAME db, not multiple dbs.

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

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

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

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

3. A db decides it will offer its service for free.  Any device can use it.

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

5. A notion of "roaming" or "pomading" is supported where your "home" db has a relationship with a "visiting" db in another region who will supply service when the device is in the other region.

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

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

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

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

Brian

On Jun 5, 2013, at 2:14 PM, Vincent Chen <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

First of all, reliability, geographic diversity, capacity, etc are usually done with common URLs.  Witness www.google.com<http://www.google.com/>

Your example makes sense in this case, because www.google.com<http://www.google.com/> is a single corporate entity and it manages its own reliability, diversity, etc.

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

-vince

---

From: Weixinpeng <[email-masked]>
Date: Thu, 6 Jun 2013 03:30:01 +0000

Hi Vince, ,
         I am not quite clear about how OUTSIDE_COVERAGE works, if the database is in charge of returning a list of alternate database with OUTSIDE_COVERAGE error, does it means the database has to
maintain some information, such as coverage area, of other databases? And how it works when databases are managed by different companies?
         If a master moves from USA to UK, can the database that the master originally connected return available database in UK to master?

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

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

         Thanks!
-Xinpeng

From: Vincent Chen [mailto:[email-masked]]
Sent: Wednesday, June 05, 2013 10:21 AM
To: Weixinpeng
Cc: Mark Jones; [email-masked]; Peter McCann
Subject: Re: [paws] draft-wei-paws-database-discovery-01

Xinpeng, All,

-vince

Best Regards,
Xinpeng.

Hi Xinpeng,

Hi Mark,

mj> Understood.

Thanks
Mark

Best Regards,
Xinpeng.

Hi Xinpeng,

In section 3, you state:

Thanks
Mark

Hi all,

Xinpeng Wei

--
-vince

---

From: Vincent Chen <[email-masked]>
Date: Thu, 6 Jun 2013 01:07:41 -0700

Xinpeng,

On Wed, Jun 5, 2013 at 8:30 PM, Weixinpeng <[email-masked]> wrote:

>  Hi Vince, ,****
>
>          I am not quite clear about how OUTSIDE_COVERAGE works, if the
> database is in charge of returning a list of alternate database with
> OUTSIDE_COVERAGE error, does it means the database has to ****
>
> maintain some information, such as coverage area, of other databases? And
> how it works when databases are managed by different companies?
>

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

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

 - A database to serve as both listing functionality (if it wants) as well
as the spectrum-availability functionality
 - A server can choose to implement only the ListDatabase functionality

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

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

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

That should be allowed.

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

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

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

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

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

So...does the simplicity of HTTP redirect outweigh the benefits?

-vince

****
>          Thanks!****
> -Xinpeng****

---

From: Weixinpeng <[email-masked]>
Date: Sat, 8 Jun 2013 07:50:04 +0000

Hi Vince, All
         I think the business relationships between master device vendor, regulatory body and database operator is very important to decide how to deploy database discovery mechanism further,
so maybe we should have a discuss about it and have a more clear description of these relationships, can anyone provide some information about this? Thanks!

-Xinpeng

From: Vincent Chen [mailto:[email-masked]]
Sent: Thursday, June 06, 2013 4:08 PM
To: Weixinpeng
Cc: Mark Jones; [email-masked]; Peter McCann; Zhulei (A)
Subject: Re: [paws] draft-wei-paws-database-discovery-01

Xinpeng,

On Wed, Jun 5, 2013 at 8:30 PM, Weixinpeng <[email-masked]<mailto:[email-masked]>> wrote:
Hi Vince, ,
         I am not quite clear about how OUTSIDE_COVERAGE works, if the database is in charge of returning a list of alternate database with OUTSIDE_COVERAGE error, does it means the database has to
maintain some information, such as coverage area, of other databases? And how it works when databases are managed by different companies?

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

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

 - A database to serve as both listing functionality (if it wants) as well as the spectrum-availability functionality
 - A server can choose to implement only the ListDatabase functionality

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

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

That should be allowed.

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

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

-vince

         Thanks!
-Xinpeng

---

From: "Zhulei (A)" <[email-masked]>
Date: Sun, 9 Jun 2013 01:37:25 +0000

Hi,

Thinks occur to me, and provide the ideas before really get it.

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

Some detail implementations occur to me if I can seriously think over the proposal:

1.      IF regulatory seems to maintain a location and DB list mapping in dominated area? IF regulatory seems maintain the DB URL list of other regulatory domain(“S”)?

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

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

3.      Still not ready to accept HTTP 302/301 method to reply more than one referring destinations. I think this idea is not about complexity,  just wrong.

Best regards,
Zhu Lei
Huawei
Wireless network research department
E-mail address: [email-masked]
Phone: +86-10-60611961
Mobile: +86-13910157020

发件人: Weixinpeng
发送时间: 2013年6月8日 15:50
收件人: Vincent Chen
抄送: Mark Jones; [email-masked]; Peter McCann; Zhulei (A); Malyar, John P
主题: RE: [paws] draft-wei-paws-database-discovery-01

Hi Vince, All

-Xinpeng

Xinpeng,

That should be allowed.

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

-vince

         Thanks!
-Xinpeng

---

From: Vincent Chen <[email-masked]>
Date: Tue, 11 Jun 2013 09:40:19 -0700

Zhu Lei,

On Sat, Jun 8, 2013 at 6:37 PM, Zhulei (A) <[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> Thinks occur to me, and provide the ideas before really get it.****
>
> ** **
>
> I supposed that DB as service to discover should be an Internet service,
> but not sure any more by looking at proposed text  in section 4.1.1 of paws
> protocol-05. ****
>
> ** **
>
> Some detail implementations occur to me if I can seriously think over the
> proposal:****
>
> **1.      **IF regulatory seems to maintain a location and DB list
> mapping in dominated area? IF regulatory seems maintain the DB URL list of
> other regulatory domain(“S”)? ****
>
> I would still think proposal in section 4.1.1 of paws-protocol-05 is about
> a very short term considerations, should be not exactly same proposal as
> that in Wei’s DB discovery protocol. So, the motivations and the scenarios
> have not been cleared.****
>
> **
>
- The Listing Server, as described in 4.1.1, may not be universal:
  - It will not be in every regulatory domain
  - There is no requirement that a Listing Server for one regulator does
about other regulatory domains
  - A Device MAY treat the list as validation that the DB it uses is on the
list, rather than for discovery

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

> **
>
> **2.      **The implementations of section 4.1.1 of paws-potocol-05 is
> not ready actually, and even not discussed before. I am not able to image
> the interfaces and message as implementation issues, as they are all about
> a protocol.
>
- Section 4.1.1 was proposed in version 04 to address the Ofcom/ETSI
requirements that was discussed
  on the list after the F2F.

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

>  **3.      **Still not ready to accept HTTP 302/301 method to reply more
> than one referring destinations. I think this idea is not about complexity,
>  just wrong.
>
Agreed. The question is really between the two choices:

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

b) is more flexible, but potentially more complex.

------------------------
Bottom line:

Is there a compelling use case where a Discovery Service is NOT
preconfigured that:
 - Is "trustworthy" to all regulators, databases, and devices?
 - Is easily deployable?

If not, do we need LoST? or just a protocol to encode the request and
response?

-vince

---

From: Peter McCann <[email-masked]>
Date: Wed, 12 Jun 2013 17:40:41 +0000

Maybe the ITU-R should run a "root" discovery service, pointing at
national servers and mapping geographic coordinates to nation states.
Each national server can list all the databases approved for use within 
that nation.  The WSD can then pick one based on its business relationships.

-Pete

Rosen, Brian wrote:
> <as individual> No, but we are discussing multiple URLs for the SAME 
> db, not multiple dbs.
> 
> Multiple DBs arise because regulators want competitive options.  The 
> list manager can list all the approved DBs, but a given WSDB isn't 
> likely to be able to use all of them, or even most of them.
> 
> I have to bring up business models in an IETF list, but it seems we 
> may need to at least understand what has been thought about with 
> multiple competing dbs.
> 
> 1. The manufacturer contracts with a db, or a db per region to serve 
> the devices it manufacturers.  This is usually a lifetime of the 
> device arrangement.  Some provision has to be made to allow the owner 
> to use a different DB, and some provision has to be made to allow a 
> new db to take over a defunct (for whatever reason) db URL.
> 
> 2. A service provider providing a service over WS, the usual example 
> is an ISP, contracts for the db service for all the devices it 
> provides its service to.  This is annoying to provision unless the 
> device comes from the SP as part of the service or a truck roll is 
> needed.  Some provision has to be made to change SPs.  Sometimes the 
> SP IS the db operator.
> 
> 4. The end user of the device contracts with the db for service.  This 
> usually requires provisioning by the device owner as part of the sign- 
> up process.
> 
> 5. A notion of "roaming" or "pomading" is supported where your "home"
> db has a relationship with a "visiting" db in another region who will 
> supply service when the device is in the other region.
> 
> And of course there is the single db per region model where all 
> devices in that region use a single db, with some cost sharing, 
> regulatory fee or tax arrangement
> 
> For all of the multiple db per region cases, there ends up being one, 
> or at most a small number of dbs, that a given device can use within 
> that region.  We could imagine discovery services that had some way of 
> knowing, or themselves discovering and caching which of several dbs a 
> given device could use.  Not sure that makes a whole lot of sense.
> But it makes virtually no sense to just discover the list of possible 
> services and then try them to see which one likes you.
> 
> The notion of caching to avoid asking has some merit.  You could cache 
> the db URL you successfully used last, try it, get an error if you are 
> out of area (or a referral for case 5) and then, if you do get an 
> error, use the discovery mechanism to at least find out what region 
> you are in.
> 
> I don't think that we should be standardizing queries between devices
> and dbs that won't serve them.   A device should not routinely ask a db
> for service when there is no prior arrangement for service.
> 
> Brian
> 
> On Jun 5, 2013, at 2:14 PM, Vincent Chen <[email-masked]> wrote:
> 
> 
> 	Brian,
> 
> 
> 
> <http://www.google.com/>
> 	Your example makes sense in this case, because www.google.com 
> <http://www.google.com/>  is a single corporate entity and it manages 
> its own reliability, diversity, etc.
> 
> 	In contrast, WSDBs are offered by different entities (sometimes 
> competing). The equivalence you are asking for would
> 	be http://www.wsdb.com <http://www.wsdb.com/>  and be automatically 
> routed to different implementations. I don't think that's what we had 
> in mind.
> 
> 	-vince
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 12 Jun 2013 17:48:10 +0000

We have history with ideas like that.  Try to follow the history of ENUM.  It failed, miserably.  

Brian

---

From: Peter McCann <[email-masked]>
Date: Wed, 12 Jun 2013 17:51:02 +0000

Understood.

But, I can't think of anyone else in a better position to resolve 
territorial disputes.  Even if they don't run the service themselves,
it seems like they're the best ones to publish the national polygons
and the list of pointers to national authorities.

-Pete

Rosen, Brian wrote:
>>> <as individual> No, but we are discussing multiple URLs for the
>>> SAME db, not multiple dbs.
>>> 
>>> Multiple DBs arise because regulators want competitive options.
>>> The list manager can list all the approved DBs, but a given WSDB
>>> isn't likely to be able to use all of them, or even most of them.
>>> 
>>> The models I've heard about are: 1. The manufacturer contracts with a
>>> db, or a db per region to serve the devices it manufacturers.  This is
>>> usually a lifetime of the device arrangement.  Some provision has to
>>> be made to allow the owner to use a different DB, and some provision
>>> has to be made to allow a new db to take over a defunct (for whatever
>>> reason) db URL.
>>> 
>>> 2. A service provider providing a service over WS, the usual
>>> example is an ISP, contracts for the db service for all the devices
>>> it provides its service to.  This is annoying to provision unless
>>> the device comes from the SP as part of the service or a truck roll
>>> is needed.  Some provision has to be made to change SPs.  Sometimes
>>> the SP IS the db operator.
>>> 
>>> given device could use.  Not sure that makes a whole lot of sense. But
>>> it makes virtually no sense to just discover the list of possible
>>> The notion of caching to avoid asking has some merit.  You could
>>> cache the db URL you successfully used last, try it, get an error
>>> if you are out of area (or a referral for case 5) and then, if you
>>> do get an error, use the discovery mechanism to at least find out
>>> what region you are in.
>>> 
>>> and dbs that won't serve them.   A device should not routinely ask a
>>> db for service when there is no prior arrangement for service.
>>> 
>>> Brian
>>> 
>>> competing). The equivalence you are asking for would 	be
>>> http://www.wsdb.com <http://www.wsdb.com/>  and be automatically

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 12 Jun 2013 18:00:10 +0000

The LoST forest guide idea does that without anywhere near as much infrastructure.

Basically, it relies on cooperating national servers to provide appropriate referral services.

In fact the LoST forest guide does EXACTLY what we want - given a location and a URN indicating what service you want, it provides a referral to the right server in the right area for that service, based on a set of polygons.

Brian

---

From: Peter McCann <[email-masked]>
Date: Wed, 12 Jun 2013 18:34:04 +0000

Ok, I just read 5582.

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

-Pete

Rosen, Brian wrote:
> In fact the LoST forest guide does EXACTLY what we want - given a
> location and a URN indicating what service you want, it provides a
> referral to the right server in the right area for that service, based
> on a set of polygons.
> 
> Brian On Jun 12, 2013, at 1:51 PM, Peter McCann
> <[email-masked]> wrote:
> 
>> Understood.
>> 
>> territorial disputes.  Even if they don't run the service
>> themselves, it seems like they're the best ones to publish the
>> national polygons and the list of pointers to national authorities.
>> 
>> -Pete
>> 
>> 
>> Rosen, Brian wrote:
>>>> Each national server can list all the databases approved for use
>>>> within that nation.  The WSD can then pick one based on its business
>>>> relationships.
>>>> 
>>>> -Pete
>>>> 
>>>> 
>>>> Rosen, Brian wrote:
>>>>> The models I've heard about are: 1. The manufacturer contracts with
>>>>> a db, or a db per region to serve the devices it manufacturers. This
>>>>> is usually a lifetime of the device arrangement.  Some provision has
>>>>> to be made to allow the owner to use a different DB, and some
>>>>> provision has to be made to allow a new db to take over a defunct
>>>>> (for whatever reason) db URL.
>>>>> 
>>>>> 4. The end user of the device contracts with the db for service.
>>>>> This usually requires provisioning by the device owner as part of
>>>>> the sign- up process.
>>>>> 
>>>>> 5. A notion of "roaming" or "pomading" is supported where your
>>>>> "home" db has a relationship with a "visiting" db in another region
>>>>> who will supply service when the device is in the other region.
>>>>> 
>>>>> For all of the multiple db per region cases, there ends up being
>>>>> one, or at most a small number of dbs, that a given device can use
>>>>> within that region.  We could imagine discovery services that had
>>>>> some way of knowing, or themselves discovering and caching which of
>>>>> several dbs a given device could use.  Not sure that makes a whole
>>>>> lot of sense. But it makes virtually no sense to just discover the
>>>>> list of possible services and then try them to see which one likes
>>>>> you.
>>>>> 
>>>>> if you are out of area (or a referral for case 5) and then, if
>>>>> you do get an error, use the discovery mechanism to at least find
>>>>> out what region you are in.
>>>>> 
>>>>> I don't think that we should be standardizing queries between
>>>>> devices and dbs that won't serve them.   A device should not
>>>>> routinely ask a db for service when there is no prior arrangement
>>>>> for service.
>>>>> 
>>>>> Brian
>>>>> 
>>>>> <http://www.google.com/>  is a single corporate entity and it
>>>>> manages its own reliability, diversity, etc.
>>>>> 
>>>>> routed to different implementations. I don't think that's what we
>>>>> had in mind.
>>>>> 
>>>>> 	-vince
>>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> 
>>

---

From: Vincent Chen <[email-masked]>
Date: Wed, 12 Jun 2013 12:16:41 -0700

How would a regulator sanction the "forest guide".

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

-vince

-- 
-vince

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 12 Jun 2013 19:22:27 +0000

The basic Forest Guide idea is there is no "sanction".  There is only a cooperating set of guides.

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

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

Brian

On Jun 12, 2013, at 3:16 PM, Vincent Chen <[email-masked]<mailto:[email-masked]>>
 wrote:

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

-vince

On Wed, Jun 12, 2013 at 11:34 AM, Peter McCann <[email-masked]<mailto:[email-masked]>> wrote:
Ok, I just read 5582.

-Pete

Rosen, Brian wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Understood.
>>
>>> On Jun 12, 2013, at 1:40 PM, Peter McCann <[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>>
>>>>> usually done with common URLs.  Witness www.google.com<http://www.google.com/>
>>>>> <http://www.google.com/>
>>>>>
>>>>>
>>>>>   Your example makes sense in this case, because www.google.com<http://www.google.com/>
>>>>> http://www.wsdb.com<http://www.wsdb.com/> <http://www.wsdb.com/>  and be automatically

--
-vince

---

From: Peter McCann <[email-masked]>
Date: Wed, 12 Jun 2013 19:22:54 +0000

That's the question I'm struggling with too.  It's easy just to assume
that authority on spectrum issues descends from and is delegated from
ITU-R, which is what led to my initial suggestion.  But, as Brian points
out, there are operational issues with the centralized approach.

Perhaps we can only rely on the individual national certification processes
that will test each device for non-interference and correct operation to
guarantee that the device will only connect to an "authorized" database.
But, it seems like a natural question to ask how a device can check for
itself whether a database is authorized by the regulator under which it
finds itself.  This would be necessary, for example, if a database originally
configured into the device was de-certified by the regulator, and seems to
be the motivation for Ofcom to publish its approved list and require that
all devices consult it before operation.

-Pete

Vincent Chen wrote:
> On Wed, Jun 12, 2013 at 11:34 AM, Peter McCann
> 	Seems ok to leave the decision of which forest guide to use up to 	each
> manufacturer.  Will this be able to satisfy the Ofcom requirement 	to
> consult their regulator-maintained list before connecting to the
> 	Rosen, Brian wrote: 	> The LoST forest guide idea does that without
> anywhere near as much 	> infrastructure. 	> 	> Basically, it relies on
> cooperating national servers to provide 	> appropriate referral
> services. 	> 	> In fact the LoST forest guide does EXACTLY what we want
> - given a 	> location and a URN indicating what service you want, it
> provides a 	> referral to the right server in the right area for that
> service, based 	> on a set of polygons. 	> 	> Brian On Jun 12, 2013, at
> 1:51 PM, Peter McCann 	> <[email-masked]> wrote: 	> 	>>
> Understood. 	>> 	>> But, I can't think of anyone else in a better
> position to resolve 	>> territorial disputes.  Even if they don't run
> the service 	>> themselves, it seems like they're the best ones to
> publish the 	>> national polygons and the list of pointers to national
> authorities. 	>> 	>> -Pete 	>> 	>> 	>> Rosen, Brian wrote: 	>>> We have
> history with ideas like that.  Try to follow the history of 	>>> ENUM. 
> It failed, miserably. 	>>> 	>>> Brian 	>>> 	>>> On Jun 12, 2013, at 1:40
> PM, Peter McCann <[email-masked]> 	>>> wrote: 	>>> 	>>>> Maybe
> the ITU-R should run a "root" discovery service, pointing at 	>>>>
> 	>>>> within that nation.  The WSD can then pick one based on its
> business 	>>>> relationships. 	>>>> 	>>>> -Pete 	>>>> 	>>>> 	>>>> Rosen,
> Brian wrote: 	>>>>> <as individual> No, but we are discussing multiple
> URLs for the 	>>>>> SAME db, not multiple dbs. 	>>>>> 	>>>>> Multiple
> DBs arise because regulators want competitive options. 	>>>>> The list
> manager can list all the approved DBs, but a given WSDB 	>>>>> isn't
> likely to be able to use all of them, or even most of them. 	>>>>>
> 	>>>>> I have to bring up business models in an IETF list, but it seems
> we 	>>>>> may need to at least understand what has been thought about
> with 	>>>>> multiple competing dbs. 	>>>>> 	>>>>> The models I've heard
> about are: 1. The manufacturer contracts with 	>>>>> a db, or a db per
> region to serve the devices it manufacturers. This 	>>>>> is usually a
> lifetime of the device arrangement.  Some provision has 	>>>>> to be
> made to allow the owner to use a different DB, and some 	>>>>> provision
> has to be made to allow a new db to take over a defunct 	>>>>> (for
> whatever reason) db URL. 	>>>>> 	>>>>> 2. A service provider providing a
> service over WS, the usual example 	>>>>> is an ISP, contracts for the
> db service for all the devices it 	>>>>> provides its service to.  This
> is annoying to provision unless the 	>>>>> device comes from the SP as
> part of the service or a truck roll is 	>>>>> needed.  Some provision
> has to be made to change SPs. Sometimes the 	>>>>> SP IS the db
> operator. 	>>>>> 	>>>>> 3. A db decides it will offer its service for
> free.  Any device can 	>>>>> use it. 	>>>>> 	>>>>> 4. The end user of
> the device contracts with the db for service. 	>>>>> This usually
> requires provisioning by the device owner as part of 	>>>>> the sign- up
> process. 	>>>>> 	>>>>> 5. A notion of "roaming" or "pomading" is
> supported where your 	>>>>> "home" db has a relationship with a
> "visiting" db in another region 	>>>>> who will supply service when the
> device is in the other region. 	>>>>> 	>>>>> And of course there is the
> single db per region model where all 	>>>>> devices in that region use a
> single db, with some cost sharing, 	>>>>> regulatory fee or tax
> arrangement 	>>>>> 	>>>>> For all of the multiple db per region cases,
> there ends up being 	>>>>> one, or at most a small number of dbs, that a
> given device can use 	>>>>> within that region.  We could imagine
> discovery services that had 	>>>>> some way of knowing, or themselves
> discovering and caching which of 	>>>>> several dbs a given device could
> use.  Not sure that makes a whole 	>>>>> lot of sense. But it makes
> virtually no sense to just discover the 	>>>>> list of possible services
> and then try them to see which one likes 	>>>>> you. 	>>>>> 	>>>>> The
> notion of caching to avoid asking has some merit.  You could 	>>>>>
> cache the db URL you successfully used last, try it, get an error 	>>>>>
> if you are out of area (or a referral for case 5) and then, if 	>>>>>
> you do get an error, use the discovery mechanism to at least find 	>>>>>
> out what region you are in. 	>>>>> 	>>>>> I don't think that we should
> be standardizing queries between 	>>>>> devices and dbs that won't serve
> them.   A device should not 	>>>>> routinely ask a db for service when
> there is no prior arrangement 	>>>>> for service. 	>>>>> 	>>>>> Brian
> 	>>>>> 	>>>>> On Jun 5, 2013, at 2:14 PM, Vincent Chen
> <[email-masked]> wrote: 	>>>>> 	>>>>> 	>>>>>   Brian, 	>>>>> 	>>>>>
> 	>>>>> 	>>>>>           First of all, reliability, geographic diversity,
> capacity, etc are 	>>>>> usually done with common URLs.  Witness
> www.google.com 	>>>>> <http://www.google.com/> 	>>>>> 	>>>>> 	>>>>>  
> Your example makes sense in this case, because www.google.com 	>>>>>
> <http://www.google.com/>  is a single corporate entity and it 	>>>>>
> manages its own reliability, diversity, etc. 	>>>>> 	>>>>>   In
> contrast, WSDBs are offered by different entities (sometimes 	>>>>>
> competing). The equivalence you are asking for would be 	>>>>>
> http://www.wsdb.com <http://www.wsdb.com/>  and be automatically 	>>>>>
> routed to different implementations. I don't think that's what we 	>>>>>
> had in mind. 	>>>>> 	>>>>>   -vince 	>>>>> 	>>>> 	>>>> 	>>>> 	>> 	>> 	>>
> 
> 
> 
> 
> 
> 
> 
>