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 protected]> 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 protected]> >> wrote: >> >>> 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. >>>> >>>> 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 protected]> 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 >>>> >>> >>> >>> > > > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
