Re: [paws] draft document for Discovery

["Joel M. Halpern" <[e-mail]>]

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