Brian, Please see my reply inline below. Don From: Rosen, Brian [mailto:[email protected]] Sent: Thursday, April 19, 2012 2:01 PM To: Don Joslyn Cc: Das, Subir; [email protected] Subject: Re: [paws] Database Discovery Question
<as individual> I disagree. While local regulation could limit capability for discovery, in general, I would like to be able to build devices that find databases based on location and type of device. [Don - If a device is presented a list of available databases (simply based on location and device type), what selection criteria is PAWS defining to help the radio make a choice between the available databases? Shall we factor in cost, feature level, SLA, or other parameters that might help the radio make a choice between them? If so, is it not true that the user will need to configure parameters to help the radio make the choice that fits the users choice? Are we ignoring the business relationship within the ecosystem that may be used to match a customer with a database? How is the radio to know about the relationship ahead of time without the user performing some configuration? I think you're over simplifying the use case, by suggesting that device location is the only criteria that a device needs to use to find a database. In an ecosystem that includes a business model where database use may have an associated cost for access, I'm pretty sure the user will decide which database to use before the radio is fired up.] It may be, as in say GSM cell phones, that discovery presents a list of possibilities, and specific choices get based on things like roaming relationships, but to make that work requires standardization. [Don - I would think that GSM cell phones are slave devices and thus do not need to access a whitespace database, and I think slave roaming is outside the scope of PAWS protocol.] See inline for comments On Apr 19, 2012, at 1:30 PM, Don Joslyn wrote: I don't think PAWS should define discovery, I think the protocol should simply start after a device has "found" the correct database to use. I feel this way for many reasons: 1) In the US, a radio is certified to work with one or more specific databases. So the device will be pre-configured to contact specific databases, no need to implement a discovery service. If the device is programmed to work with more than one database provider, the device owner will configure which one to use based on the relationship that they have established with the database provider (for example, which one they are paying to use). Discovery would provide the list of (10) databases. Which one you use could be based on existing subscriptions, [Don - If based on existing subscriptions, I'm still configuring the radio to pick a specific one, so what benefit did I really get from discovery (other than added complexity)?] but could also be based on roaming agreements. Preconfiguration won't work: I build a device that is certified to work in the U.S. and the U.K. It's sold to a U.K. customer, who visits the U.S. The customer's U.K. provider has a roaming arrangement with one or more U.S. database operators. [Don - Interesting... how do we define these roaming arrangements within the discovery domain in such a way that discovery provides the right answer to the radio? Are you adding roaming arrangements to the selection criteria for the discovery service to use or for the radio to use to make a selection?] I want that to work, even if the device is certified to work in 25 countries. [Don - Will PAWS also be defining all of the possible selection criteria and supporting algorithms (for 25 countries) that either the discovery service or radio must understand and use to make a database choice, a choice that ultimately must match the user's requirements?] Preconfiguration rarely works well in global, mobile environments. You can do it, but I want a standardized discovery mechanism. [Don - For a global mobile environment of slave devices? The slaves will not access a whitespace database, they will determine a whitespace channel to use from the master. Master to slave association parameters, such as roaming, are outside the scope of a protocol to exchange whitespace channel lists.] 2) Discovery services like LoST are based on location, but the device's relationship with a database service is not known or considered. While it may seem simple to configure LoST or similar service to point to a database service based on location, how do you point to the one that the customer has a relationship with, for example, paid to use? I do realize that this may not be an issue in every country. See roaming above. You may have configuration for your home database, but not a roaming database. [Don - See my comments on roaming above and below. Are we now defining a roaming database?] Also, I expect arrangements in some other countries will be simpler than the U.S. [Don -Simpler than having the device owner configure a database provider address while they are setting other configuration parameters on the device? Somebody is going to have to configure the discovery service. I'm still wondering who that will be and if it's really going to be simpler in the end.] 3) If PAWS defines a globally applicable discovery process and either picks an existing protocol (like LoST) or designs one, most likely it would include a centrally based discovery service. What entity will be responsible for hosting and configuring the central discovery service? How will PAWS define this as a global solution, and deal with the politics between countries? LoST is designed to not require a central anything. It's distributed. It cleverly avoids the political mess. The designers were mindful of these issues. [Don - You avoided my question regarding hosting and configuration.] I'm waving my hands a bit, but it's a very good answer for discovery of location sensitive servers. [Don - If device location were the only consideration for database selection, we would not be having this conversation.] 4) Some radio manufacturers do not have very much ROM to include even more code on their device. I'm concerned that discovery will consume even more space on the radio, space that they may not even have. Not an argument that gets you any traction in the IETF. ROM is cheap. Have more. All it takes is one service call to wipe out savings in ROM. [Don - You're simply avoiding the issue, ok.] 5) I believe that defining discovery will take more time than defining the protocol between the WSDB and WSD. Nah. We do this for lots of protocols. If we decide to use LoST, it will be very easy. [Don - Time will tell if I'm right or wrong. I do hope we can find an easy solution, but based on the selection criteria that we've already discussed, I'm still concerned that it may not be the case.] I think that database discovery should be left to each country to define based on their own requirements and Whitespace ecosystem. By that argument, we should close up shop and let each country define their own database query protocol. [Don - I'm not falling for the all-or-nothing argument.]
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
