<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]<mailto:[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
