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
