Dear all Sorry to come in late but the foregoing discussion has sparked a worry in my mind.
I would like WSDs to be able to select a database manager from a list, perhaps on the basis of price and value-added services offered, such as mobility support. Is there anything in the foregoing discussion that would prevent this ? Michael From: [email protected] [mailto:[email protected]] On Behalf Of Rosen, Brian Sent: 05 June 2013 18:35 To: Harasty, Daniel J Cc: [email protected] Subject: Re: [paws] draft-wei-paws-database-discovery-01 <as individual> The problem with more than one is what the device does when it has more than one. First of all, reliability, geographic diversity, capacity, etc are usually done with common URLs. Witness www.google.com<http://www.google.com> Segregation of devices would presumably have different URLs on different devices, not multiple URLs on the same device. I don't think configuration is a good solution for any device, but a simple configuration option is the simplest, most universal way to get something to work. Once you are past simple configuration, I personally feel that discovery is the best mechanism. In this case, we have the issue of multiple countries/regulatory domains, so configuration could be one per region. The problem with that is figuring out which region (country) you are in. If you have discovery for that, you can have discovery for the databases. On the other, other hand, if there are multiple databases per region, a given device may only have access to one of them. It may have provisioning that tells it which one. That's a combination of discovery and provisioning that avoid asking databases for help that have no incentive to help, and would prefer not to see unnecessary queries. Brian On Jun 5, 2013, at 12:16 PM, "Harasty, Daniel J" <[email protected]<mailto:[email protected]>> wrote: Brian Rosen commented: I would suggest that you get preconfigured with exactly one database. If that needs to change, change the configuration. I don't agree that we write the spec in such a way that enforces - or even encourages - that a Device should be configurable with exactly one Database URL. Here's my thinking: even if that Device manufacturer has an exclusive arrangement with a single Database operator, the operator may run multiple Database instances on different URLs for any number of reasons (reliability, geographic diversity, capacity, or segregation of the devices based some feature). I think it is much more robust for the device to be allowed - even encouraged - to be configurable with a list of Database URLs; as it allows Device to try a list - and presumably - experience fewer outages due to inability to contact any Database. Dan Harasty Wireless Systems and Networks Dept Applied Communication Sciences Red Bank, NJ From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Rosen, Brian Sent: Wednesday, June 05, 2013 9:34 AM To: Peter Stanforth Cc: [email protected]<mailto:[email protected]>; Peter McCann Subject: Re: [paws] draft-wei-paws-database-discovery-01 Well, I thought that is what the protocol doc says, but actually, it's completely unclear about how it works. It says, basically, that if you are permitted to operate in more than one domain, you should be pre-configured with URIs for a) all listing servers for each domain b) all databases for each domain that doesn't have a listing server It has no text that describes how you select one, either the first time, or any subsequent time. It would be perfectly compatible with the doc as it is to try servers in a list of 100 randomly until you found one that accepted you. Normally, protocols are pretty specific about this, so both ends know what will happen. I would suggest that you get preconfigured with exactly one database. If that needs to change, change the configuration. Discovery is the mechanism by which you find out about databases given your location. It has to be a protocol - you send in your location (and probably nothing else other than perhaps a device id), and you get back a listing server or list of dbs in that area. Discovery has to work with a set of per country polygons. The discovery service needs to find out which country you are in and give you the listing service or dbs for that country. Devices may have lists of dbs they are authorized to use. If they knew what country they were in, they could try one of the ones they are configured for. But something has to tell them that. You wouldn't configure a device with all the dbs in a country, you would configure one (or possibly more), the device was authorized to use. It might make sense to provide some kind of discovery sequence that has a cache of the last server, so you don't have to the whole sequence from the top every time you boot. I don't think expecting every db to know about every other country's dbs will scale very well. When there is only 2-3 countries that have such DBs, maybe, but if there were 50 or more, the lists would be too difficult for every other DB to track. Brian On Jun 5, 2013, at 9:00 AM, Peter Stanforth <[email protected]<mailto:[email protected]>> wrote: Brian. Why do you assume a device will always go back to its original DB rather than the one it last registered with. The latter seems more likely, and more logical, to me Peter S. Sent from my iPhone On Jun 5, 2013, at 8:37 AM, "Rosen, Brian" <[email protected]<mailto:[email protected]>> wrote: The problem I see with this is that the database originally contacted (presumably configured directly or indirectly) is forever responsible for referrals to the correct database. It provides no other service for the device. If I purchased a device in New York City and moved to London, the US database has to refer me every time I try to register. Having a separate database whose job is to do that referral seems like a more rational solution. Any device or service that wanted to participate in that kind of "nomadic" operation could contribute to the cost of providing the service. Cross subsidizing the U.S. database from the U.K. database for the referral seems less likely to succeed. Brian On Jun 4, 2013, at 10:20 PM, Vincent Chen <[email protected]<mailto:[email protected]>> wrote: Xinpeng, All, Thanks for putting this together. It seems that discovery involves two aspects: - Deployment of LoST servers, which also impacts discovery of LoST severs - Protocol (format of messages that is communicated) The current document is placing deployment out of scope, but does suggest that preconfiguration is a strategy. That just leaves the protocol, which, may be characterized as: 1. Device sends request with its location 2. Server responds with a list of (name, uri) pairs Given that this is relatively simple, should we just build it into PAWS protocol itself? For example, the current revision (r05) of the PAWS protocol allows for the following: 1. Device asks database for available spectrum in a location outside the coverage area for the Databae 2. The Database returns OUTSIDE_COVERAGE error and MAY include a list of (name, databaseUri) entries to "recommend" alternate databases This provides almost the same capability. Should we just add a ListDatabase to PAWS? -vince On Thu, May 23, 2013 at 6:57 PM, Weixinpeng <[email protected]<mailto:[email protected]>> wrote: Hi Mark, Please see comments inline. Thanks! Best Regards, Xinpeng. From: Mark Jones [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, May 23, 2013 10:31 PM To: Weixinpeng; [email protected]<mailto:[email protected]> Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, Thank you for your responses. I have some further comments/questions inline below (prefixed by mj>). From: Weixinpeng [mailto:[email protected]] Sent: May-22-13 11:13 PM To: Mark Jones; [email protected]<mailto:[email protected]> Cc: Peter McCann; Zhulei (A) Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Mark, Thanks for your feedback, and I think there are some issues that I need to clarify. we have to be clear that the discovery mechanism is provided as an optional method that can help master device to find the correct WSDB, which means the master device can get WSDB by, such as, pre-configuring of WSDB, provision etc. mj> Understood. The dynamic discovery mechanism provides more convenient for master device to find WSDB, for example, when a new WSDB is setup for providing service or when some deployed WSDB goes down and never work. mj> In this regard, DNS resolution would appear to be equally convenient mechanism to manage WSDB instances being commissioned or decommissioned. I view LoST as a kind of "location-aware DNS" so I understand its applicability to discovery of the appropriate WSDB. I still think the draft needs more information on how the Master device finds its WSDB DS so that implementers understand if/when this optional discovery method is applicable to their deployment. [Wei] Yeah, because we cannot covey location information in DNS query message, so DNS is inappropriate to find the WSDB. I think I will do more clarification about how master device finds WSDB DS later. About the DHCP you mentioned below, technically speaking, there have been some extension of DHCP for supporting the provision of LoST server, refer to RFC5223. mj> I understand that the DHCP option specifying the LoST server would be provided to the Master device when it initiated its backhaul connection (non-WS connection) to the internet. Correct? [Wei] Yeah. Besides, using DHCP method doesn't means IP network provider must have some business relationship with WSDB DS provider, if the network provider wants to provide master device with FQDN of WSDB DS it can use DHCP. mj> If the backhaul network operator is configuring his DHCP server to send options to provision the WSDB DS then I assume he has some business interest in doing so. What am I missing? [Wei] I think there may be some relationship between network operator and WSDB DS. But the reason why DHCP is mentioned here is because in the LoST protocol DHCP is extended to provide LoST server's domain name to the LoST client. Thanks Mark Best Regards, Xinpeng. From: Mark Jones [mailto:[email protected]] Sent: Wednesday, May 22, 2013 11:29 PM To: Weixinpeng; [email protected]<mailto:[email protected]> Cc: Peter McCann Subject: RE: [paws] draft-wei-paws-database-discovery-01 Hi Xinpeng, In section 3, you state: The URL or IP address of WSDB DS can be found by any method such as DNS, DHCP, manually configuring etc, and it is out of scope of this document. I'm unclear on how the Master device obtains the URL of a trusted discovery server unless there is some pre-configuration involved. I understand that DNS could be used if the Master device is already pre-configured with a preferred/home TVWS DS URL (or a preferred/home domain that is then resolved with U-NAPTR) but I don't see how DHCP could be used to bootstrap this information in the TVWS scenarios. Please could you elaborate. Thanks Mark From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Weixinpeng Sent: May-21-13 9:11 PM To: [email protected]<mailto:[email protected]> Cc: Peter McCann Subject: [paws] draft-wei-paws-database-discovery-01 Hi all, I have uploaded a new version draft on database discovery. Comments are welcomed. http://tools.ietf.org/html/draft-wei-paws-database-discovery-01. Xinpeng Wei _______________________________________________ paws mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince _______________________________________________ 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
