MSP->IMHO the process should work the same, at every power up. A WSD which never 'roams' will experience the simple or trivial case (e.g. in the US always receive the addresses of the same WSDBs, and likely pick the same address for service every time). But when the device powers up in a roaming state, then the situation becomes more interesting. If you need to configure to have a policy that decides which of multiple competing databases you have a relationship with, configure the URI to the database.
If your default database has roaming agreements, your configured database can refer you to the right one. If your device can roam, on its own, to places where there is only one database (for example, a government run or sponsored database), then we might want a discovery mechanism, but I think LoST is it. MSP->Simplicity? It is not obvious for me how a white space business model will support the Authoritative Mapping Server, Forest Guide & Resolver entities in RFC5582. Authoritative Mapping server = Lost Server. Your DS. Forest Guide can be part of the LoST server - it's just an entity that exchanges coverage information with other FGs to build a referral database. You can restrict access to the FG to only authorized LoST servers (DS in your terms). That means that if a DS doesn't know what the right DS is, it consults the FG, which tells it. That makes the load on the FG very low. FGs have no root. It would be perfectly reasonable for a regulator to run an FG as long as only DSs in the country could access it. It would connect to similar FGs elsewhere. It's also possible for anyone who wants to to run an FG with similar restrictions - only handling requests from DSs (LoST servers) it knows. It would be very easy for example, the U.S. WSDB Admins to agree on an FG model that worked for the US and connected to other country's DSs. Brian If you want to build in some default LoST server URI into the device, as long as that server is willing to refer the query to the right LoST server for ever, for free, that works. Brian On Jul 10, 2012, at 4:00 PM, <[email protected]<mailto:[email protected]>> wrote: Inline: From: "<ext Rosen>", "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday, July 10, 2012 2:50 PM To: Scott Probasco <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] draft document for Discovery When I do the discovery, I don't know which country I am in. I can't know enough to query the right DS unless we put country boundary polygons in the device. Raj> The WSD could send information (such as GPS co-ordinates, MCC+MNC, SSID etc.) to the discovery server which can be used to determine the country that it is in. The DS itself is not country specific. It uses the information sent by the device to determine which country the device is located in and respond with the address(es) of the WSDBs therein. Of course, I forgot to add to this that if there is the U.S. model of competing DBs, then the whole discovery mechanism falls apart, and you need configuration, because if the device knows who its business relationship is with, it can know the URI. Raj> In such a case it is configured in the device. The device could still query the DS and get a list of competing databases and then some policy on the device will enable it to choose a preferred DB. -Raj Brian On Jul 10, 2012, at 3:38 PM, <[email protected]<mailto:[email protected]>> <[email protected]<mailto:[email protected]>> wrote: Hi Brian, Comments below: MSP-> Kind Regards, Scott From: "ext Rosen, Brian" <[email protected]<mailto:[email protected]>> Date: Mon, 9 Jul 2012 17:27:31 -0400 To: Scott Probasco <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [paws] draft document for Discovery This re-invents LoST without the extensive mechanisms for self organizing databases. LoST has a query that sends location in, with a Service URN (which for this use would be "I want a WSDB for this location" and you get back (a list of) URIs. That's what you propose, without the service URN because you want a special location based discovery mechanism just for WSDBs. What you don't deal with is how a WSDB DS finds out about all other WSDB DSs. That's the LoST "Forest Guide". The FG works without a root, and allows cooperating LoST servers to refer queries to the right server. MSP->If each WSD vendor arranges a service level agreement with a WSDB DS (or provides their own WSDB DS) then it is not obvious to me why a WSDB DS would need to find out about other WSDB DSs. Each WSDB DS is independent. If vendor X intends their WSD to operate in Country Y, then WSDB DS used by vendor X must include appropriate Country Y mapping information (location to WSDB or WSDB listing server) in their WSDB DS. It's not really a great idea to bake a URI into a device. Who knows what will happen over the life of a device? MSP->Including an address in the device does not imply that the address cannot be changed if needed. SW updates, device management or similar can allow for changes if needed. I take your point, these changes should be exceptions rather than regular events. The existing LoST discovery mechanism is built for widespread deployment in ISPs. We may need something that works well without that. There aren't a lot of good mechanisms that really work well - you either have a root of some sort, or, as you propose, a starting seed. The root problem is who runs the root, and the starting seed problem is the lifetime of the seed. You note that the seed gets nothing out of the exchange - it doesn't get to serve the query, it only gets to refer to someone who does. MSP->It is not clear to me what business model would support a sophisticated infrastructure as described in the LoST Architecture & Framework RFC 5582. I actually think this is not an important problem to solve really well. The most common deployment model is going to be a tower and clients. The tower can be configured, and either the clients learn from the tower, or the tower handles the database query itself. Client discovery in that case could be the LoST discovery mechanism. We have to handle the self organizing case (say a MANET) where one or more devices have some other path to the Internet to get to the WSDB. They will need real discovery and may not have a cooperating ISP. While I really don't like configuration, it may be the only viable way to do it. MSP->Configuration is pragmatic and can be easily deployed Brian On Jul 9, 2012, at 5:04 PM, <[email protected]<mailto:[email protected]>> wrote: Hello All, Please find a link below to a draft submission for the Discovery process as described in the Use Cases & Requirements document. We are looking forward to your review and comments as well as discussion at IETF#84. Abstract: A white space master device needs to query a white space database and obtain information about available spectrum/channels prior to operation. White space databases which contain information about available spectrum/channels are associated with a regulatory domain. A white space master device needs to discover the relevant white space database(s) given its current location and in which regulatory domain that it is operating. The white space database discovery is the preliminary step that a white space master device has to perform. URL: http://www.ietf.org/internet-drafts/draft-probasco-paws-discovery-00.txt Htmlized: http://tools.ietf.org/html/draft-probasco-paws-discovery-00 Kind Regards, Scott & Raj _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
