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 protected] 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 protected] [mailto:[email protected]] *On Behalf
Of *[email protected]
*Sent:* 10 July 2012 22:44
*To:* [email protected]
*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 protected]
<mailto:[email protected]>>
*Date: *Tue, 10 Jul 2012 17:17:46 -0400
*To: *"ext com>" <[email protected]
<mailto:[email protected]>>
*Cc: *Scott Probasco <[email protected]
<mailto:[email protected]>>, "[email protected]
<mailto:[email protected]>" <[email protected] <mailto:[email protected]>>
*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 protected]
<mailto:[email protected]>> 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 protected]
<mailto:[email protected]>> <[email protected]
<mailto:[email protected]>> wrote:
Hi Brian,
Comments below: MSP->
Kind Regards,
Scott
*From: *"ext Rosen, Brian" <[email protected]
<mailto:[email protected]>>
*Date: *Mon, 9 Jul 2012 17:27:31 -0400
*To: *Scott Probasco <[email protected]
<mailto:[email protected]>>
*Cc: *"[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
*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 protected]
<mailto:[email protected]>> 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 protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
