--On Monday, 27 November, 2006 12:44 +0100 Patrick Vande Walle <patrick@xxxxxxxxxxxxxx> wrote: > Olaf M. Kolkman wrote, On 27/11/2006 11:27: > >> Hmmm, "Reliable answers" and "multiple registries for the >> same TLD" in the same sentence? >> >> Multiple registries imply multiple namespaces. That implies >> that there is no coherency, which I interpret as not being >> reliable. > > From > http://www.cs.cornell.edu/people/egs/beehive/codons-sigcomm04/ > node15.html > > "CoDoNS enables multiple namespace operators to manage the > same part of the name hierarchy [...] Ideally, competing > operators would preserve a single consistent namespace by > issuing names out of a common, shared pool. In the presence of > conflicting or inconsistent records, clients simply pick the > records signed by an operator they trust, similar to the way > they pick between separate sets of root servers today. > Essentially, nameowners have the ability to choose the > namespace operator that will endorse their records based on > price, service and functionality." Patrick, to complement Brian's comment and avoid getting hung up on precise definitions of "namespace"... There are many situations in which one can be quite relaxed about collections of names. In appropriate situations, one can tolerate duplicate names (with or without a disambiguation procedure) and one can tolerate having users (clients) select among endorsers or even (effectively) provide their own endorsements and make choices on a name-by-name basis. We may be headed down exactly that path with ENUM and ENUM variants: whether that will be good for ENUM or VoIP will probably be resolved in the marketplace, but it is as harmless to the network as the naming rules I use for the namespace of email addresses within jck.com (or, presumably, the rules you use for the email namespace within vande-walle.eu). It is also worth remembering that countries can tolerate multiple currencies (although most don't, and actually react quite hostilely to independent currency developers) and that duplication in names of people is very common ("will 'Joe Smith' please stand up?"). On the other hand, if one is going to have a network in which all resources are publicly available and unambiguous without prior negotiations between each client and server and in which one doesn't want to allow the time and resources for a post-query disambiguation process (which is exactly what we do to identify the desired "Joe Smith" from that pool) then identifiers must be unique. Not overlapping name spaces, or fragments of a name space that the client gets to pull together based on its own choice algorithms, or a fraction of the aggregate name space chosen on the basis of "least bad" or "most complete" service by a name-vendor, but _unique_ and comprehensive. In particular, if I use my view of the DNS to create an object identifier (e.g., a URI) and pass it to you, it much be resolvable in your environment to point to the same object that I intended or we are both in trouble. Now, in principle, I could pass you both the identifier and my entire context of selected namespace vendors and you could push down your vendor context but consider putting that identifier along with several others generated by other people in their contexts... well, one would like this to work reliably and in finite time. It is a different issue, although tied to precisely this set of difficulties, but this is one of the reasons why many of us continue to say "don't put 'that' into the DNS, let's look at 'above DNS' solutions" to address a variety of naming, locational, and navigational functions. If one really wants competition (or parallelism) over the right to designate the definition of individual names, then one can imagine all sorts of interesting systems, many of them matched to specific applications. For them, query-time disambiguation, negotiation about attributes and their use in selection, competitive suppliers (look at the so-called "keyword" market), and a host of other options may all make sense. But _they_ need a reliable, consistent, DNS with unique and unambiguous naming to work successfully. And, conversely, weakening those properties of the DNS could prevent those services from developing properly and being interoperable at the identifier level. The "CoDoNS" idea might actually be very useful for some of those "above DNS" functions. But considering it as an alternative to the DNS seems to either exhibit a profound misunderstanding of what the DNS is about or, perhaps, a desire to use terminology that excites funding agencies or journal editors. john _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf