The basic Forest Guide idea is there is no "sanction". There is only a cooperating set of guides.
Very typically, you don't query the Forest Guide itself. You query a server who refers or iterates to the Forest Guide, which refers or iterates to the server that can help you. The idea is to not depend on government action, but to allow it if it's there. Anyone can set up a forest guide, but the servers that refer to it have to trust it. This would be an example of transitive trust. If you trust the local server, and it trusts the forest guide, then you can trust the forest guide. Brian On Jun 12, 2013, at 3:16 PM, Vincent Chen <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[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]<mailto:[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]<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/> >>>>> <http://www.google.com/> >>>>> >>>>> >>>>> Your example makes sense in this case, because >>>>> www.google.com<http://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/> <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
