Inline On Apr 17, 2012, at 10:22 PM, Das, Subir wrote:
On Apr 17, 2012, at 5:41 PM, "Rosen, Brian" <[email protected]<mailto:[email protected]>> wrote: We recognize that there will be many databases, and the discovery problem is to find the right "one" where one is in quotes because there could be more than one suitable database. Agree. When you say the right "one", how does the device know that in the first place? Lots of possibilities, see my response to Peter. Some systems may not need discovery - some clients can be hardwired to a server. Mobile clients probably can't do that if they can roam internationally. When you say mobile client, are you considering "Fixed/Mode II WSD" or "Slave/Mode I WSD" or both? A device may be built to work in several countries, each of which has it's own type mechanism, or there will (hopefully) evolve a few common types. I mean a device that can move and potentially operate in different places. That includes "nomadic" devices; devices that are nominally fixed, but may be tossed in a suitcase, taken on a trip, and set up wherever the owner goes. If it's legal to operate where it is, I want it to work. In case of "Fixed/Mode II WSD", what is the model? Can it roam without a roaming relationship? Sure, why not? We're not dealing with business models in the IETF. We are dealing in protocols and possibilities. Roaming relationships may exist, or they may not. Both have to work in the sense that I could build a device that worked in a variety of environments. I don't wish to imply anything about a server's willingness to provide service. I only want a way for a client to discover a server that provides service where it is at the time it needs service. As with my answer to Peter, I may have to provide a list of possible servers. So there are a couple of inputs to discovery: a) Location. This has to allow location as arbitrary lat/lon; you may not know what country you are in. This is the device, not the human. The human may know, the device may not. Some databases may cover the entire country, others may cover a region. Sometimes location is known by a street address, and you can know what country you are in. b) Type of device. In every country, there are different classifications of devices that may depend on band, power, portability, antenna characteristics… So far, what we see is enumerated types per country, but I could imagine more complex things. If the device doesn't know what country it is in, it may need to do discovery in a couple of steps, the first of which identifies the country, and then what type of device. How does the Mobile client know the location? Do we assume GPS? What if it is inside the building? We make no assumptions. It has location, either in lat/lon or street address form. We don't care how it gets it. One way it might is DHCP or HELD. This is the same problem we have with emergency calls and those are two IETF solutions for that problem. Discovery then is type and location in, device URI (not IP address I think) out. LoST (RFC5222) is ideal for this. You pass location and a "service urn" in, and you get a URI out. The service urn would contain the type. It has a "forest guide" scheme that links LoST servers together kind of like DNS without a root. Brian On Apr 17, 2012, at 5:26 PM, Das, Subir wrote: During PAWS session in Paris IETF, there were a lot of questions/discussions on 'Discovery' of Database. It was not clear to me except if we are talking about "Database Server Discovery", in particular, the domain name or the IP address of the 'Server" that is hosting the database. OTH, I felt that some folks may have different views and they would possibly like to see more features than just discovering the domain name or IP address of the "Database Server". In some offline discussions, I was told that it may be similar to what LOST (RFC 5222) has defined. I read the LOST protocol and associated architecture and my current understanding is that the LOST use case is different than what we are trying to achieve via PAWS. Here is my understanding of the operating model of PAWS interface (when defined): -"Fixed/Mode II WSD" (per figure 1,<draft-das-paws-protocol-01>) can only query the database -The manufacturer of the "Fixed/Mode II WSD" may be different than owner/operator of this device -"Fixed/Mode II WSD" is certified by the regulatory body of the region that they serve - Either the "Fixed/Mode II WSD" device operator or the device vendor has an a-priori relationship with one or more covering database administrators. This relationship is utilized to either configure or enable the discovery of the proper database to contact in the current location I would like to know the group's view of the above model. To me, finding the emergency services or restaurant information near my location is different than getting to know a server that can provide me with channel/frequency/power and other information in the location where "Fixed/Mode II WSD" is situated. In addition, emergency services do not require a subscription and the service is mandated by the Government/regulatory bodies. Some may argue that 'White Space' service may be free as well, but to my understanding it is not quite the similar model as emergency services. I hope with this thread we can clarify/understand the discovery issue. Regards, _Subir _______________________________________________ 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
