<as individual> As a practical matter, the reason there are more than one databases in a region is competition. The databases are commercial services, that have some kind of business model that restricts who can use them. Thus the URL you use doesn't depend on some fixed priority, but depends on commercial arrangements.
As in my prior message, I suspect one URL per database is adequate to cover reliability, redundancy, capacity, diversity, etc. Brian On Jun 5, 2013, at 12:53 PM, "Harasty, Daniel J" <[email protected]<mailto:[email protected]>> wrote: Brian Rosen commented: 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 mind Brian’s suggestion that a Device try its “most recently contacted database” upon the next time it tries to communicate. However, I do not see a need for the spec to say anything on this point. (I would object if the spec REQUIRED the Device to “start from the top every time the Device boots”, but if a given manufacturer decides that is best, OK with me.) I realize that the majority of the discussion around Discovery is concerned with the following use case: 1. How does a device determine one or more valid Databases given its location (and possibly other of its characteristics)? But that almost immediately leads the Device to consider: 2. If two or more Database URLs are available (either known to the Device via Discovery or its static, local configuration), is there any particular sequence they should be tried in? Note also that a Database operator may be running multiple Database instances on different URLs for any number of reasons (reliability, geographic diversity, capacity, or segregation of the devices based some feature). Thus, there is another closely related use case: 3. If I can serve a given Device from two or more of my Database URLs, what is the way I can “steer” traffic to one in particular, leaving the others as backup/failover URLs? Use cases 2 and 3 lead me to this suggestion: as far as specifying sequencing, I’d suggest we borrow a concept from MX records in DNS servers: each MX (mail exchanger) record has a preference value, and lower values are to be “preferred”. (Seehttp://en.wikipedia.org/wiki/MX_record and http://tools.ietf.org/html/rfc5321.) The extension of this concept to Whitespace is that any “list of Databases” should – conceptually – have each URL assigned a preference number as well. (Details to be worked out as to who sets this when; I’m just proposing the concept of “preference value” here.) In the PAWS spec, this might be included by adding an optional “preference” field in the “DatabaseSpec” parameter. This field is an integer, and considered to be present with a value of 20 if missing. Lower values of the preference value SHOULD be preferred by the Device. I would assume that – within the URLs for a given Database operator – that the operator would have “say” in which URLs received which preference value. In the “list of all databases” provided by the regulatory authority, it would be at the discretion of that regulatory authority to decide what “fair” means in its jurisdiction (setting preference values accordingly). Anyway, I’m not trying to add unnecessary complexity to the Device, Database, or spec; I’m merely proposing an “answer” to Brian’s “sequencing issue” that has precedence in other IETF specs. Dan Harasty Wireless Systems and Networks Dept Applied Communication Sciences Red Bank, NJ _______________________________________________ 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
