➢ it would be useful to actually have some I-Ds proposing a solution for discovery I guess Subir initiated this thread to find out which solutions might be acceptable for the group.
So far we heard about two possible solutions: a) LoST (RFC5222), and b) (semi-)preconfiguration With LoST, the master device needs to first discover a LoST server (using either DNS, DHCP or it may be preconfigured), then do the query. This assumes there is a LoST server which is preconfigured with the boundaries the WSDBs can provide answer for. In roaming cases, the LoST server would need to be a local one (not just _the_ preconfigured one), as it is unlikely that a LoST server in one country would know the WSDBs in other countries. If the master device does not know what country it is in, it may find that out from the WSDB it is told to contact by the LoST server. The weak part of this solution I think is the roaming case, where the LoST server has to be discovered either by dhcp (we all know the limitations of this) or DNS. DNS also has its practical limitations, as zone admins may be reluctant to just add U-NAPTR records for a service with limited usage. If there could be assumed that the is a global LoST server able to answer queries from all over, then this could be a working solution. But can we make these assumptions? The preconfiguration could be as simple as provisioning the master devices with a URI, which would contain an up-to-date list of existing WSDBs. The device would need to find out which country it is in, then query the appropriate db. If there are multiple in that country and didn't pick the right one, it could either be redirected to the right one or could try itself the other one. The problematic part here is how to find out what country it is in. Again, if we assume non-roaming, then it is trivial, the problem here is also with the roaming case. If the device has map data available, that would help it map its location to a country/regulatory_domain. So, I think both solutions have their weak points, depending on how the assumptions we make will match with the global deployments. If we conclude that different discovery mechanisms would suit better the diversity of use cases, we may not need to pick one mechanism, but go with (eg) two. - Gabor From: [email protected] [mailto:[email protected]] On Behalf Of Patil Basavaraj (Nokia-CIC/Dallas) Sent: Thursday, April 19, 2012 12:35 PM To: [email protected]; [email protected] Cc: [email protected] Subject: Re: [paws] Database Discovery Question I agree that we are jumping off to discuss the solution space. The requirement for PAWS is that we need a database discovery mechanism. There can be multiple approaches towards this requirement. LoST is one option. But there are others as well and it would be useful to actually have some I-Ds proposing a solution for discovery than fragmented pieces of information and ideas. -Raj From: "<ext Rosen>", "[email protected]" <[email protected]> Date: Thursday, April 19, 2012 1:40 PM To: "Das, Subir" <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: [paws] Database Discovery Question We're getting solutions ahead of requirements. LoST is a solution to a requirement for discovery. However, the answer to your question is that either we use an existing LoST service and add service urns for our purpose, or all the database operators in an area cooperate to run one LoST service, or some single neutral entity runs it. Brian On Apr 19, 2012, at 2:33 PM, Das, Subir wrote: 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. SD> I would not consider both of them at the same level. I do not understand how we will satisfy the following: If it is an operator managed LoST service (likely) how would it know what answer to provide for the other database assuming there is no roaming relationship. And why should the operator provide this, if he is not managing the whitespace service. 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. 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. 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, 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. I want that to work, even if the device is certified to work in 25 countries. Preconfiguration rarely works well in global, mobile environments. You can do it, but I want a standardized discovery mechanism. 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. Also, I expect arrangements in some other countries will be simpler than the U.S. 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. I'm waving my hands a bit, but it's a very good answer for discovery of location sensitive servers. 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. 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. 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. _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
