Subject: Re: [paws] draft document for Discovery

From: <[email-masked]>
Date: Tue, 10 Jul 2012 19:38:13 +0000

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" <[email-masked]<mailto:[email-masked]>>
Date: Mon, 9 Jul 2012 17:27:31 -0400
To: Scott Probasco <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] draft document for Discovery

This re-invents LoST without the extensive mechanisms for self organizing databases.
LoST has a query that sends location in, with a Service URN (which for this use would be "I want a WSDB for this location" and you get back (a list of) URIs.

That's what you propose, without the service URN because you want a special location based discovery mechanism just for WSDBs.

What you don't deal with is how a WSDB DS finds out about all other WSDB DSs.  That's the LoST "Forest Guide".  The FG works without a root, and allows cooperating LoST servers to  refer queries to the right server.
MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (or provides their own WSDB DS) then it is not obvious to me why a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is independent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include appropriate Country Y mapping information (location to WSDB or WSDB listing server) in their WSDB DS.

It's not really a great idea to bake a URI into a device.  Who knows what will happen over the life of a device?
MSP->Including an address in the device does not imply that the address cannot be changed if needed. SW updates, device management or similar can allow for changes if needed. I take your point, these changes should be exceptions rather than regular events.

The existing LoST discovery mechanism is built for widespread deployment in ISPs.   We may need something that works well without that.  There aren't a lot of good mechanisms that really work well - you either have a root of some sort, or, as you propose, a starting seed.  The root problem is who runs the root, and the starting seed problem is the lifetime of the seed.  You note that the seed gets nothing out of the exchange - it doesn't get to serve the query, it only gets to refer to someone who does.
MSP->It is not clear to me what business model would support a sophisticated infrastructure as described in the LoST Architecture & Framework RFC 5582.

I actually think this is not an important problem to solve really well.  The most common deployment model is going to be a tower and clients.  The tower can be configured, and either the clients learn from the tower, or the tower handles the database query itself.  Client discovery in that case could be the LoST discovery mechanism.

We have to handle the self organizing case (say a MANET) where one or more devices have some other path to the Internet to get to the WSDB.  They will need real discovery and may not have a cooperating ISP.  While I really don't like configuration, it may be the only viable way to do it.
MSP->Configuration is pragmatic and can be easily deployed

Brian

On Jul 9, 2012, at 5:04 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Hello All,

Please find a link below to a draft submission for the Discovery process as described in the Use Cases & Requirements document. We are looking forward to your review and comments as well as discussion at IETF#84.

Abstract:
   A white space master device needs to query a white space database and
   obtain information about available spectrum/channels prior to
   operation.  White space databases which contain information about
   available spectrum/channels are associated with a regulatory domain.
   A white space master device needs to discover the relevant white
   space database(s) given its current location and in which regulatory
   domain that it is operating.  The white space database discovery is
   the preliminary step that a white space master device has to perform.

URL:             http://www.ietf.org/internet-drafts/draft-probasco-paws-discovery-00.txt
Htmlized:        http://tools.ietf.org/html/draft-probasco-paws-discovery-00

Kind Regards,
Scott & Raj

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

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Jul 2012 15:50:08 -0400

When I do the discovery, I don't know which country I am in.  I can't know enough to query the right DS unless we put country boundary polygons in the device.

Of course, I forgot to add to this that if there is the U.S. model of competing DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is with, it can know the URI.

Brian

On Jul 10, 2012, at 3:38 PM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 19:57:47 +0000

Hi Brian,

The intention is that each DS has global scope. The WSD does not have to know what country it is in.

In the US the I don't believe the discovery model falls apart. Discovery will return all suitable WSDB addresses allowing the WSD to make its own selection. Also I don't know why a WSD would be restricted to a business relationship with a single WSDB. One small example, perhaps my device has relationship with two different WSDB, each DB provides a different 'additional service' which might be the ultimate deciding factor why my WSD selects one WSDB over the other (at a given location, time, or user-selected service request). But in in case discovery would work the same.

Kind Regards,
Scott

Date: Tue, 10 Jul 2012 15:50:08 -0400

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 20:00:46 +0000

Inline:

From: "<ext Rosen>", "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, July 10, 2012 2:50 PM
To: Scott Probasco <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] draft document for Discovery

Raj> The WSD could send information (such as GPS co-ordinates, MCC+MNC, SSID etc.) to the discovery server which can be used to determine the country that it is in. The DS itself is not country specific. It uses the information sent by the device to determine which country the device is located in and respond with the address(es) of the WSDBs therein.

Of course, I forgot to add to this that if there is the U.S. model of competing DBs, then the whole discovery mechanism falls apart, and you need
configuration, because if the device knows who its business relationship is with, it can know the URI.

Raj> In such a case it is configured in the device. The device could still query the DS and get a list of competing databases and then some policy on the device will enable it to choose a preferred DB.

-Raj

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Jul 2012 16:12:19 -0400

Scott said in his email that DS was per country:
 If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include appropriate Country Y mapping information (location to WSDB or WSDB listing server) in their WSDB DS.

If every DS will, for free, refer to the right DS for every other country, great.  Otherwise, we have a problem.    Forest Guides in LoST work kind of like this.  If you find any LoST server, the FGs can refer a query to the right LoST server based on location.

If you configure a policy in a device, you can configure a URI.  There is no need for discovery mechanisms in such cases.  Discovery mechanisms generally work without configuration, and they (should) work everywhere.

I'm not opposed to a discovery mechanism.  I do rather like the LoST mechanism, because it is documented, it works, and it solves this set of problems, provided the servers do in fact allow you to refer to other servers for free.

Configuration and LoST works.  Why invent something else?

If you want to build in some default LoST server URI into the device, as long as that server is willing to refer the query to the right LoST server for ever, for free, that works.

Brian

On Jul 10, 2012, at 4:00 PM, <[email-masked]<mailto:[email-masked]>> wrote:

Inline:

-Raj

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 20:46:22 +0000

Hi,

Comments below: MSP->

Kind Regards,
Scott

From: "ext Rosen, Brian" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 10 Jul 2012 16:12:19 -0400
To: Raj Patil <[email-masked]<mailto:[email-masked]>>
Cc: Scott Probasco <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] draft document for Discovery

Scott said in his email that DS was per country:
 If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include appropriate Country Y mapping information (location to WSDB or WSDB listing server) in their WSDB DS.
MSP->This was not meant to imply that there is a WSDB DS for each country. There is a global DS URI that the device is configured with. The DS is aware of all the databases offering service in various regulatory domains. The DS responds with the list of databases to the device based on its current location.

If you configure a policy in a device, you can configure a URI.  There is no need for discovery mechanisms in such cases.  Discovery mechanisms generally work without configuration, and they (should) work everywhere.
MSP->IMHO the process should work the same, at every power up. A WSD which never 'roams' will experience the simple or trivial case (e.g. in the US always receive the addresses of the same WSDBs, and likely pick the same address for service every time). But when the device powers up in a roaming state, then the situation becomes more interesting.

Configuration and LoST works.  Why invent something else?
MSP->Simplicity? It is not obvious for me how a white space business model will support the Authoritative Mapping Server, Forest Guide & Resolver entities in RFC5582.

Brian

Inline:

-Raj

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Jul 2012 17:02:34 -0400

MSP->IMHO the process should work the same, at every power up. A WSD which never 'roams' will experience the simple or trivial case (e.g. in the US always receive the addresses of the same WSDBs, and likely pick the same address for service every time). But when the device powers up in a roaming state, then the situation becomes more interesting.
If you need to configure to have a policy that decides which of multiple competing databases you have a relationship with, configure the URI to the database.

If your default database has roaming agreements, your configured database can refer you to the right one.

If your device can roam, on its own, to places where there is only one database (for example, a government run or sponsored database), then we might want a discovery mechanism, but I think LoST is it.

MSP->Simplicity? It is not obvious for me how a white space business model will support the Authoritative Mapping Server, Forest Guide & Resolver entities in RFC5582.
Authoritative Mapping server = Lost Server.  Your DS.
Forest Guide can be part of the LoST server - it's just an entity that exchanges coverage information with other FGs to build a referral database.

You can restrict access to the FG to only authorized LoST servers (DS in your terms).  That means that if a DS doesn't know what the right DS is, it consults the FG, which tells it.  That makes the load on the FG very low.  FGs have no root.  It would be perfectly reasonable for a regulator to run an FG as long as only DSs in the country could access it.  It would connect to similar FGs elsewhere.

It's also possible for anyone who wants to to run an FG with similar restrictions - only handling requests from DSs (LoST servers) it knows.

It would be very easy for example, the U.S. WSDB Admins to agree on an FG model that worked for the US and connected to other country's DSs.

Brian

Brian

Inline:

-Raj

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: Peter Stanforth <[email-masked]>
Date: Tue, 10 Jul 2012 17:09:37 -0400

on this topic a completely different approach would be for the device to call home, to the manufacturer, with the ability for the manufacturer to point it to the appropriate DB for that location. This works well, and simply if we assume the device has the relationship with the DB. If it is a user (Say network operator) then I would expect them to configure their devices to go where they desire them to go.

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <[email-masked]<mailto:[email-masked]>> wrote:

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 10 Jul 2012 17:17:46 -0400

That would work.

This would happen every time the device booted.  That could be a fair amount of traffic for a high volume manufacturer.   They have to support this forever.

It's simple.

I wonder if the device mfg would agree to that?

Brian

On Jul 10, 2012, at 5:09 PM, Peter Stanforth wrote:

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 21:36:15 +0000

Hi Brian,

The concept of 'policy' is perhaps difficult to handle. We don't have a definition, and it could ultimately be simply a user's choice. It is difficult to assume URIs could be configured with such flexibility.

Roaming agreements among WSDBs is interesting, I like the concept. But the protocols must function even if there happen to not be roaming agreements in place.

If LoST turns out to be the best solution, I am okay with it. I believe we need to look at proposals and understand what is needed, possible and also pragmatic.

Best Regards,
Scott

Date: Tue, 10 Jul 2012 17:02:34 -0400

Brian

Brian

Inline:

-Raj

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 21:37:06 +0000

Hi Peter,

In the simplest form, this is the essence of our discovery proposal. The device calls home to learn which DB to use.

Best Regards,
Scott

From: "ext com>" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 10 Jul 2012 17:09:37 -0400
To: "Rosen, Brian" <[email-masked]<mailto:[email-masked]>>
Cc: Scott Probasco <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] draft document for Discovery

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: <[email-masked]>
Date: Tue, 10 Jul 2012 21:43:40 +0000

Hi All,

It is simple. Vendors could support it forever. And if for example the roaming agreement becomes a preferred solution, the vendor could program one or more addresses into the device (SW update, device management, etc). In the use case & requirements document the assumption has been that a simple case of discovery is hard-coded addresses in the device.

Best Regards,
Scott

From: "ext Rosen, Brian" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 10 Jul 2012 17:17:46 -0400
To: "ext com>" <[email-masked]<mailto:[email-masked]>>
Cc: Scott Probasco <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] draft document for Discovery

That would work.

It's simple.

Brian

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: <[email-masked]>
Date: Wed, 11 Jul 2012 22:21:47 +0100

All

Just to highlight that Ofcom requires that the list of available databases (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving database operators can be removed from the list and devices stop using their channel allocations). Ofcom doesn't permit a master device to have a pre-arrangement with a database (such as a pre-programmed URI), or at least, the validity of any pre-programmed URI has to be checked every 24 hours with Ofcom's listing. The discovery problem is similar to US, but two step through an intermediate listing.

Regards

Andy

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 10 July 2012 22:44
To: [email-masked]
Subject: Re: [paws] draft document for Discovery

Hi All,

Best Regards,
Scott

That would work.

It's simple.

Brian

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 11 Jul 2012 17:48:11 -0400

It is pretty clear, and reasonable, that different domains are going to 
have different discovery rules.  (I wish that regulators operating by 
defining their goals.  There are other ways to achieve what ofcom wants. 
  But that is a different rant.)

The simplest answer from a protocol perspective seems to be to allow a 
provisioned starting point, and a recursion mechanism.  Then it doesn't 
matter how many hops different domains require.

Is it acceptable, in ofcom-like environments, for the device to call its 
vendor, in order to determine who to call next?  (It is easy enough to 
design the referral to allow multiple stages of referral, as long as the 
regulations don't require that the master device must check with the 
regulator before checking with anyone else.)

Yours,
Joel

On 7/11/2012 5:21 PM, [email-masked] wrote:
> All
>
> Just to highlight that Ofcom requires that the list of available
> databases (maintained by Ofcom) is consulted once every 24 hours (so
> that misbehaving database operators can be removed from the list and
> devices stop using their channel allocations). Ofcom doesn’t permit a
> master device to have a pre-arrangement with a database (such as a
> pre-programmed URI), or at least, the validity of any pre-programmed URI
> has to be checked every 24 hours with Ofcom’s listing. The discovery
> problem is similar to US, but two step through an intermediate listing.
>
> Regards
>
> Andy
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf
> Of [email-masked]
> *Sent:* 10 July 2012 22:44
> *To:* [email-masked]
> *Subject:* Re: [paws] draft document for Discovery
>
> Hi All,
>
> It is simple. Vendors could support it forever. And if for example the
> roaming agreement becomes a preferred solution, the vendor could program
> one or more addresses into the device (SW update, device management,
> etc). In the use case & requirements document the assumption has been
> that a simple case of discovery is hard-coded addresses in the device.
>
> Best Regards,
>
> Scott
>
> *From: *"ext Rosen, Brian" <[email-masked]
> <mailto:[email-masked]>>
> *Date: *Tue, 10 Jul 2012 17:17:46 -0400
> *To: *"ext com>" <[email-masked]
> <mailto:[email-masked]>>
> *Cc: *Scott Probasco <[email-masked]
> <mailto:[email-masked]>>, "[email-masked]
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [paws] draft document for Discovery
>
> That would work.
>
> This would happen every time the device booted.  That could be a fair
> amount of traffic for a high volume manufacturer.   They have to support
> this forever.
>
> It's simple.
>
> on this topic a completely different approach would be for the device to
> call home, to the manufacturer, with the ability for the manufacturer to
> point it to the appropriate DB for that location. This works well, and
> simply if we assume the device has the relationship with the DB. If it
> is a user (Say network operator) then I would expect them to configure
> their devices to go where they desire them to go.
>
>     When I do the discovery, I don't know which country I am in.  I
>     can't know enough to query the right DS unless we put country
>     boundary polygons in the device.
>
>     Of course, I forgot to add to this that if there is the U.S. model
>     of competing DBs, then the whole discovery mechanism falls apart,
>     and you need configuration, because if the device knows who its
>     business relationship is with, it can know the URI.
>
>     Brian
>
>     On Jul 10, 2012, at 3:38 PM, <[email-masked]
>     <mailto:[email-masked]>> <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>     Hi Brian,
>
>     Comments below: MSP->
>
>     Kind Regards,
>
>     Scott
>
>     *From: *"ext Rosen, Brian" <[email-masked]
>     <mailto:[email-masked]>>
>     *Date: *Mon, 9 Jul 2012 17:27:31 -0400
>     *To: *Scott Probasco <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc: *"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject: *Re: [paws] draft document for Discovery
>
>     LoST has a query that sends location in, with a Service URN (which
>     for this use would be "I want a WSDB for this location" and you get
>     back (a list of) URIs.
>
>     That's what you propose, without the service URN because you want a
>     special location based discovery mechanism just for WSDBs.
>
>     What you don't deal with is how a WSDB DS finds out about all other
>     WSDB DSs.  That's the LoST "Forest Guide".  The FG works without a
>     root, and allows cooperating LoST servers to  refer queries to the
>     right server.
>
>     MSP->If each WSD vendor arranges a service level agreement with a
>     WSDB DS (or provides their own WSDB DS) then it is not obvious to me
>     why a WSDB DS would need to find out about other WSDB DSs. Each WSDB
>     DS is independent. If vendor X intends their WSD to operate in
>     Country Y, then WSDB DS used by vendor X must include appropriate
>     Country Y mapping information (location to WSDB or WSDB listing
>     server) in their WSDB DS.
>
>     It's not really a great idea to bake a URI into a device.  Who knows
>     what will happen over the life of a device?
>
>     MSP->Including an address in the device does not imply that the
>     address cannot be changed if needed. SW updates, device management
>     or similar can allow for changes if needed. I take your point, these
>     changes should be exceptions rather than regular events.
>
>     The existing LoST discovery mechanism is built for widespread
>     deployment in ISPs.   We may need something that works well without
>     that.  There aren't a lot of good mechanisms that really work well -
>     you either have a root of some sort, or, as you propose, a starting
>     seed.  The root problem is who runs the root, and the starting seed
>     problem is the lifetime of the seed.  You note that the seed gets
>     nothing out of the exchange - it doesn't get to serve the query, it
>     only gets to refer to someone who does.
>
>     MSP->It is not clear to me what business model would support a
>     sophisticated infrastructure as described in the LoST Architecture &
>     Framework RFC 5582.
>
>     I actually think this is not an important problem to solve really
>     well.  The most common deployment model is going to be a tower and
>     clients.  The tower can be configured, and either the clients learn
>     from the tower, or the tower handles the database query itself.
>       Client discovery in that case could be the LoST discovery mechanism.
>
>     We have to handle the self organizing case (say a MANET) where one
>     or more devices have some other path to the Internet to get to the
>     WSDB.  They will need real discovery and may not have a cooperating
>     ISP.  While I really don't like configuration, it may be the only
>     viable way to do it.
>
>     On Jul 9, 2012, at 5:04 PM, <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>
>
>     Hello All,
>
>     Please find a link below to a draft submission for the Discovery
>     process as described in the Use Cases & Requirements document. We
>     are looking forward to your review and comments as well as
>     discussion at IETF#84.
>
>     Abstract:
>
>     URL:
>     http://www.ietf.org/internet-drafts/draft-probasco-paws-discovery-00.txt
>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> [email-masked]

---

From: <[email-masked]>
Date: Thu, 12 Jul 2012 07:29:19 +0100

Joel

>From a regulatory perspective, yes the device can call its vendor or call a friend (another WSD say) first, as long as nothing happens over the TVWS channel until the regulator's listing has been checked.

Regards

Andy

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: 11 July 2012 22:48
To: Sago,AJ,Andy,COD R
Cc: [email-masked]; [email-masked]
Subject: Re: [paws] draft document for Discovery

It is pretty clear, and reasonable, that different domains are going to have different discovery rules.  (I wish that regulators operating by defining their goals.  There are other ways to achieve what ofcom wants. 
  But that is a different rant.)

The simplest answer from a protocol perspective seems to be to allow a provisioned starting point, and a recursion mechanism.  Then it doesn't matter how many hops different domains require.

Is it acceptable, in ofcom-like environments, for the device to call its vendor, in order to determine who to call next?  (It is easy enough to design the referral to allow multiple stages of referral, as long as the regulations don't require that the master device must check with the regulator before checking with anyone else.)

Yours,
Joel

On 7/11/2012 5:21 PM, [email-masked] wrote:
> devices stop using their channel allocations). Ofcom doesn't permit a 
> pre-programmed URI), or at least, the validity of any pre-programmed 
> URI has to be checked every 24 hours with Ofcom's listing. The 
> discovery problem is similar to US, but two step through an intermediate listing.
>
> Regards
>
> Andy
>
> roaming agreement becomes a preferred solution, the vendor could 
> program one or more addresses into the device (SW update, device 
> management, etc). In the use case & requirements document the 
> assumption has been that a simple case of discovery is hard-coded addresses in the device.
>
> Best Regards,
>
> Scott
>
> on this topic a completely different approach would be for the device 
> to call home, to the manufacturer, with the ability for the 
> manufacturer to point it to the appropriate DB for that location. This 
> works well, and simply if we assume the device has the relationship 
> with the DB. If it is a user (Say network operator) then I would 
> expect them to configure their devices to go where they desire them to go.
>
>     Htmlized: 
> http://tools.ietf.org/html/draft-probasco-paws-discovery-00
>
>     Kind Regards,
>
>     Scott & Raj
>

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 12 Jul 2012 12:24:15 -0700

Thanks Andy,

So in this case the is it expected the device knows the URI for
Ofcom's list and should start there?

-Ben

All

Just to highlight that Ofcom requires that the
list of available databases (maintained by Ofcom) is
consulted once every 24 hours (so that misbehaving database
operators can be removed from the list and devices stop
using their channel allocations). Ofcom doesn’t permit a
master device to have a pre-arrangement with a database
(such as a pre-programmed URI), or at least, the validity of
any pre-programmed URI has to be checked every 24 hours with
Ofcom’s listing. The discovery problem is similar to US, but
two step through an intermediate listing.

Regards

Andy

From:
[email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]

Sent: 10 July 2012 22:44

To: [email-masked]

Hi All,

It is simple. Vendors could support it
forever. And if for example the roaming agreement becomes
a preferred solution, the vendor could program one or more
addresses into the device (SW update, device management,
etc). In the use case & requirements document the
assumption has been that a simple case of discovery is
hard-coded addresses in the device.

Best Regards,

Scott

From: "ext
Rosen, Brian" <[email-masked]>

To: "ext com>" <[email-masked]>

Cc: Scott Probasco <[email-masked]>,
"[email-masked]"
<[email-masked]>

That would work.

This would happen every time the device
booted.  That could be a fair amount of traffic for a
high volume manufacturer.   They have to support this
forever.

It's simple.

I wonder if the device mfg would agree to
that?

Brian

On Jul 10, 2012, at 5:09 PM, Peter
Stanforth wrote:

on this topic a completely
different approach would be for the device to
call home, to the manufacturer, with the ability
for the manufacturer to point it to the
appropriate DB for that location. This works
well, and simply if we assume the device has the
relationship with the DB. If it is a user (Say
network operator) then I would expect them to
configure their devices to go where they desire
them to go.

On Jul 10, 2012, at 3:50 PM, "Rosen, Brian" <[email-masked]>
wrote:

When I do the discovery, I
don't know which country I am in.  I can't
know enough to query the right DS unless we
put country boundary polygons in the device.

Of course, I forgot to add to
this that if there is the U.S. model of
competing DBs, then the whole discovery
mechanism falls apart, and you need
configuration, because if the device knows
who its business relationship is with, it
can know the URI.

Brian

On Jul 10, 2012, at
3:38 PM, <[email-masked]>
<[email-masked]>
wrote:

Hi Brian,

Comments below:
MSP->

Kind Regards,

Scott

From: "ext Rosen,
Brian" <[email-masked]>

Date: Mon, 9 Jul 2012
17:27:31 -0400

To: Scott Probasco <[email-masked]>

Cc: "[email-masked]"
<[email-masked]>

Subject: Re: [paws]
draft document for Discovery

This re-invents
LoST without the extensive
mechanisms for self organizing
databases.

LoST has a
query that sends location
in, with a Service URN
(which for this use would be
"I want a WSDB for this
location" and you get back
(a list of) URIs.

That's what
you propose, without the
service URN because you want
a special location based
discovery mechanism just for
WSDBs.

What you
don't deal with is how a
WSDB DS finds out about all
other WSDB DSs.  That's the
LoST "Forest Guide".  The FG
works without a root, and
allows cooperating LoST
servers to  refer queries to
the right server.

MSP->If each
WSD vendor arranges a service
level agreement with a WSDB DS
(or provides their own WSDB DS)
then it is not obvious to me why
a WSDB DS would need to find out
about other WSDB DSs. Each WSDB
DS is independent. If vendor X
intends their WSD to operate in
Country Y, then WSDB DS used by
vendor X must include
appropriate Country Y mapping
information (location to WSDB or
WSDB listing server) in their
WSDB DS.

It's not
really a great idea to bake
a URI into a device.  Who
knows what will happen over
the life of a device?

MSP->Including
an address in the device does
not imply that the address
cannot be changed if needed. SW
updates, device management or
similar can allow for changes if
needed. I take your point, these
changes should be exceptions
rather than regular events.

The existing
LoST discovery mechanism is
built for widespread
deployment in ISPs.   We may
need something that works
well without that.  There
aren't a lot of good
mechanisms that really work
well - you either have a
root of some sort, or, as
you propose, a starting
seed.  The root problem is
who runs the root, and the
starting seed problem is the
lifetime of the seed.  You
note that the seed gets
nothing out of the exchange
- it doesn't get to serve
the query, it only gets to
refer to someone who does.

MSP->It is not
clear to me what business model
would support a sophisticated
infrastructure as described in
the LoST Architecture &
Framework RFC 5582.

I actually
think this is not an
important problem to solve
really well.  The most
common deployment model is
going to be a tower and
clients.  The tower can be
configured, and either the
clients learn from the
tower, or the tower handles
the database query itself.
Client discovery in that
case could be the LoST
discovery mechanism.

We have to
handle the self organizing
case (say a MANET) where one
or more devices have some
other path to the Internet
to get to the WSDB.  They
will need real discovery and
may not have a cooperating
ISP.  While I really don't
like configuration, it may
be the only viable way to do
it.

MSP->Configuration
is pragmatic and can be easily
deployed

Brian

On Jul 9,
2012, at 5:04 PM, <[email-masked]>
wrote:

Hello
All,

Please
find a link below to a
draft submission for
the Discovery process
as described in the
Use Cases &
Requirements document.
We are looking forward
to your review and
comments as well as
discussion at IETF#84.

Abstract:

A
white space master
device needs to
query a white space
database and

obtain information
about available
spectrum/channels
prior to

operation.  White
space databases
which contain
information about

available
spectrum/channels
are associated with
a regulatory domain.

A
white space master
device needs to
discover the
relevant white

space database(s)
given its current
location and in
which regulatory

domain that it is
operating.  The
white space database
discovery is

the preliminary step
that a white space
master device has to
perform.

Kind
Regards,

Scott
& Raj

paws mailing list

[email-masked]

paws mailing list

[email-masked]

paws mailing list

[email-masked]

---

From: <[email-masked]>
Date: Thu, 12 Jul 2012 19:27:21 +0000

Hi Ben,

If the WSD will never have the possibility to be turned on outside the UK, this could work. But about the case where the device is carried to another regulatory domain somewhere in the world? Discovery is needed for this case; to find an authorized database no matter where the device is when turned on (assuming white space is authorized in the country where the device is turned on).

Kind Regards,
Scott

From: "ext Benjamin A. Rolfe" <[email-masked]<mailto:[email-masked]>>
Date: Thu, 12 Jul 2012 12:24:15 -0700
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [paws] draft document for Discovery

Thanks Andy,
So in this case the is it expected the device knows the URI for Ofcom's list and should start there?
-Ben

All

Just to highlight that Ofcom requires that the list of available databases (maintained by Ofcom) is consulted once every 24 hours (so that misbehaving database operators can be removed from the list and devices stop using their channel allocations). Ofcom doesn’t permit a master device to have a pre-arrangement with a database (such as a pre-programmed URI), or at least, the validity of any pre-programmed URI has to be checked every 24 hours with Ofcom’s listing. The discovery problem is similar to US, but two step through an intermediate listing.

Regards

Andy

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 10 July 2012 22:44
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [paws] draft document for Discovery

Hi All,

Best Regards,
Scott

That would work.

It's simple.

Brian

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

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

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

---

From: "Benjamin A. Rolfe" <[email-masked]>
Date: Thu, 12 Jul 2012 12:56:25 -0700

Thanks Scott,

Yes, there is an presumption that the WSD knows where it is located
on earth.  It has to know this to make a database request of
course.  What we're looking for then is a global means to determine
what the initial contact needs to be depending on location.  It
seems like the steps necessary to find a database may be different
region by region. That should make it fun!

-Ben

Hi Ben,

If the WSD will never have the possibility to be turned on
outside the UK, this could work. But about the case where the
device is carried to another regulatory domain somewhere in the
world? Discovery is needed for this case; to find an authorized
database no matter where the device is when turned on (assuming
white space is authorized in the country where the device is
turned on).

Kind Regards,

Scott

From: "ext Benjamin
A. Rolfe" <[email-masked]>

Date: Thu, 12 Jul
2012 12:24:15 -0700

To: "[email-masked]"
<[email-masked]>

Subject: Re: [paws]

Thanks Andy,

So in this case the is it expected the device knows the URI
for Ofcom's list and should start there?

-Ben

All

Just to
highlight that Ofcom requires that the list of
available databases (maintained by Ofcom) is
consulted once every 24 hours (so that misbehaving
database operators can be removed from the list and
devices stop using their channel allocations). Ofcom
doesn’t permit a master device to have a
pre-arrangement with a database (such as a
pre-programmed URI), or at least, the validity of
any pre-programmed URI has to be checked every 24
hours with Ofcom’s listing. The discovery problem is
similar to US, but two step through an intermediate
listing.

Regards

Andy

From:
[email-masked]
[mailto:[email-masked]]
On Behalf Of [email-masked]

Sent: 10 July 2012 22:44

To: [email-masked]

Subject: Re: [paws] draft document for
Discovery

Hi
All,

It
is simple. Vendors could support it forever. And
if for example the roaming agreement becomes a
preferred solution, the vendor could program one
or more addresses into the device (SW update,
device management, etc). In the use case &
requirements document the assumption has been that
a simple case of discovery is hard-coded addresses
in the device.

Best
Regards,

Scott

From:
"ext

Subject: Re: [paws] draft document for
Discovery

That
would work.

This would happen every
time the device booted.  That could be a fair
amount of traffic for a high volume
manufacturer.   They have to support this
forever.

It's simple.

I wonder if the device
mfg would agree to that?

Brian

On Jul 10, 2012, at
5:09 PM, Peter Stanforth wrote:

on this topic a
completely different approach would be
for the device to call home, to the
manufacturer, with the ability for the
manufacturer to point it to the
appropriate DB for that location. This
works well, and simply if we assume the
device has the relationship with the DB.
If it is a user (Say network operator)
then I would expect them to configure
their devices to go where they desire
them to go.

On Jul 10, 2012, at 3:50 PM, "Rosen,
Brian" <[email-masked]>
wrote:

When I do the
discovery, I don't know which
country I am in.  I can't know
enough to query the right DS unless
we put country boundary polygons in
the device.

Of course, I
forgot to add to this that if there
is the U.S. model of competing DBs,
then the whole discovery mechanism
falls apart, and you need
configuration, because if the device
knows who its business relationship
is with, it can know the URI.

Brian

On Jul
10, 2012, at 3:38 PM, <[email-masked]>
<[email-masked]>
wrote:

Hi
Brian,

Comments
below: MSP->

Kind
Regards,

Scott

From:
"ext

Date: Mon, 9 Jul
2012 17:27:31 -0400

To: Scott
Probasco <[email-masked]>

Cc: "[email-masked]" <[email-masked]>

Subject: Re:
[paws] draft document
for Discovery

This
re-invents LoST
without the extensive
mechanisms for self
organizing databases.

LoST
has a query that
sends location in,
with a Service URN
(which for this use
would be "I want a
WSDB for this
location" and you
get back (a list of)
URIs.

That's
what you propose,
without the service
URN because you want
a special location
based discovery
mechanism just for
WSDBs.

What
you don't deal with
is how a WSDB DS
finds out about all
other WSDB DSs.
That's the LoST
"Forest Guide".  The
FG works without a
root, and allows
cooperating LoST
servers to  refer
queries to the right
server.

MSP->If
each WSD vendor arranges
a service level
agreement with a WSDB DS
(or provides their own
WSDB DS) then it is not
obvious to me why a WSDB
DS would need to find
out about other WSDB
DSs. Each WSDB DS is
independent. If vendor X
intends their WSD to
operate in Country Y,
then WSDB DS used by
vendor X must include
appropriate Country Y
mapping information
(location to WSDB or
WSDB listing server) in
their WSDB DS.

It's
not really a great
idea to bake a URI
into a device.  Who
knows what will
happen over the life
of a device?

MSP->Including
an address in the device
does not imply that the
address cannot be
changed if needed. SW
updates, device
management or similar
can allow for changes if
needed. I take your
point, these changes
should be exceptions
rather than regular
events.

The
existing LoST
discovery mechanism
is built for
widespread
deployment in ISPs.
We may need
something that works
well without that.
There aren't a lot
of good mechanisms
that really work
well - you either
have a root of some
sort, or, as you
propose, a starting
seed.  The root
problem is who runs
the root, and the
starting seed
problem is the
lifetime of the
seed.  You note that
the seed gets
nothing out of the
exchange - it
doesn't get to serve
the query, it only
gets to refer to
someone who does.

MSP->It
is not clear to me what
business model would
support a sophisticated
infrastructure as
described in the LoST
Architecture &
Framework RFC 5582.

I
actually think this
is not an important
problem to solve
really well.  The
most common
deployment model is
going to be a tower
and clients.  The
tower can be
configured, and
either the clients
learn from the
tower, or the tower
handles the database
query itself.
Client discovery in
that case could be
the LoST discovery
mechanism.

We
have to handle the
self organizing case
(say a MANET) where
one or more devices
have some other path
to the Internet to
get to the WSDB.
They will need real
discovery and may
not have a
cooperating ISP.
While I really
don't like
configuration, it
may be the only
viable way to do it.

MSP->Configuration
is pragmatic and can be
easily deployed

Brian

On
Jul 9, 2012, at
5:04 PM, <[email-masked]>
wrote:

Hello
All,

Please
find a link
below to a
draft
submission for
the Discovery
process as
described in
the Use Cases
&
Requirements
document. We
are looking
forward to
your review
and comments
as well as
discussion at
IETF#84.

Abstract:

A white space
master device
needs to query
a white space
database and

obtain
information
about
available
spectrum/channels
prior to

operation.  White
space
databases
which contain
information
about

available
spectrum/channels
are associated
with a
regulatory
domain.

A white space
master device
needs to
discover the
relevant white

space
database(s)
given its
current
location and
in which
regulatory

domain that it
is
operating.  The
white space
database
discovery is

the
preliminary
step that a
white space
master device
has to
perform.

Kind
Regards,

Scott
& Raj

paws mailing list

[email-masked]

paws mailing list

[email-masked]

paws mailing list

[email-masked]

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

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

---

From: Siew Yoon Tan <[email-masked]>
Date: Thu, 12 Jul 2012 20:02:38 +0000

Hi All,

Just to clarify that Ofcom will include the URI for the list of approved database as part of our regulations, so that this could be 'discovered' by WSDs. We are agnostic on how this discovery mechanism would be implemented in the WSD; either pre-programmed or through DNS server.

However, it's a prerequisite that the validity of the database that WSD wish to connect to would have to be checked by WSD every 24 hours  through connection to Ofcom listing to confirm that it's still approved.

Hope this helps the discussion.

Best regards,

Siew Yoon

:: Siew Yoon Tan
   Technical Regulation Specialist
   Spectrum Policy Group
   Direct : +44 (0) 20 7981 3066
   Mobile : +44 (0) 78 1132 6573
   [email-masked]<mailto:[email-masked]>

:: Ofcom
   Riverside House
   2a Southwark Bridge Road
   London SE1 9HA
   020 7981 3000
   www.ofcom.org.uk<http://www.ofcom.org.uk/>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Benjamin A. Rolfe
Sent: 12 July 2012 20:24
To: [email-masked]
Subject: Re: [paws] draft document for Discovery

Thanks Andy,

All

Regards

Andy

Hi All,

Best Regards,
Scott

That would work.

It's simple.

Brian

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj

paws mailing list

________________________________

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

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

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

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

Any views expressed in this message are those of the individual sender and do not represent the views or opinions of Ofcom unless expressly stated otherwise.
******************************************************************************************************************

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 12 Jul 2012 16:02:58 -0400

A device needs to know its own location.

However, as Scott points out, without a list of polygons representing the boundaries of every country, and suitable code, a device doesn't know what country it is in.

So, we need a mechanism that given an arbitrary lat/lon, leads you to the right database.

That in turn means there is some kind of server you go to first, and it leads you to country specific information.  You can't start at the OFCOM server because first you have to determine you are in the U.K.

So this is some form of query with location in the query, and at list one, or possibly a list of URIs to go to.  There may be a couple of steps - the URI you get may lead you to a list of URIs.  Each one is the same - you query with location, you get one or more URIs.   The original discovery server may lead you to the Ofcom server which leads you to one or more actual databases.

At some point, you need some way to choose between more than one URI when you get that.  This was called "policy" before.

Brian

On Jul 12, 2012, at 3:56 PM, Benjamin A. Rolfe wrote:

Thanks Scott,
Yes, there is an presumption that the WSD knows where it is located on earth.  It has to know this to make a database request of course.  What we're looking for then is a global means to determine what the initial contact needs to be depending on location.  It seems like the steps necessary to find a database may be different region by region. That should make it fun!

-Ben

Hi Ben,

Kind Regards,
Scott

Thanks Andy,

All

Regards

Andy

Hi All,

Best Regards,
Scott

That would work.

It's simple.

Brian

Brian

Hi Brian,

Comments below: MSP->

Kind Regards,
Scott

Brian

Hello All,

Abstract:

Kind Regards,
Scott & Raj