--On Monday, 27 November, 2006 12:44 +0100 Patrick Vande Walle
<patrick(_at_)vande-walle(_dot_)eu> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf