How would a regulator sanction the "forest guide". Or, equivalently, when a device gets a LoST Server, can it trust it to give the list sanctioned by a regulator? That's the bootstrap step that I don't quite understand.
-vince On Wed, Jun 12, 2013 at 11:34 AM, Peter McCann <[email protected]>wrote: > Ok, I just read 5582. > > Seems ok to leave the decision of which forest guide to use up to > each manufacturer. Will this be able to satisfy the Ofcom requirement > to consult their regulator-maintained list before connecting to the > database? Should we consider that consultation part of the discovery > process? > > -Pete > > > > Rosen, Brian wrote: > > 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 > >>>>> > >>>> > >>>> > >>>> > >> > >> > >> > > > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
