On Wed, 17 Sep 2003 15:34:25 -0700 Dave Crocker <[EMAIL PROTECTED]> wrote:
> Keith, > > KM> DNS names are not sufficient for rendezvous or referral. > > Here are the arguments about the names, themselves, that you put forward: > > KM> * Incompatible with existing transport protocols. > > If you mean that they are too long to be carried in IP packet headers, you > are of course correct. If you mean something else, please explain. > > However, your concern presupposes that the identifiers must be carried in > those protocol -- or rather, that they must be carried in them frequently. > > > KM> * Ambiguous and overloaded. Quite often, a DNS name doesn't refer to > KM> a host. > > So? What problem does that cause? Specifically, please provide a usage > example that would cause a problem. Name EXAMPLE.COM maps to hosts B and C. Hosts B ausing addresses B1 and C1, respectively. Host A looks up EXAMPLE.COM, gets addresses B1 and C1, chooses B1, and starts talking to it. The application now has some state that is only accessible to host B. For some reason the connection gets broken. Maybe host B changes its address from B1 to B2. A needs to re-establish a connection to host B - host C will not work because the application now relies on state that only B can access. EXAMPLE.COM does not name host B uniquely; it names the service provided by hosts B and C, so it is not suitble for an endpoint identifier to refer to B. What is really needed is a unique name for each host that is stably bound to the host, and which is different from the DNS name used to identify the service. > KM> There can also be many domains > KM> associated with a single host and yet be semantically different; > > How is this a problem? Service names X, Y, and Z resolve to host A. Service names W, X, and Y resolve to host B. A process on host A is talking with one on host B. They need to provide a referral to a process on host C that lets C communicate with each of them. What names do they give to C? Note that applications really have no way of knowing either the semantic bindings of DNS names (what they're supposed to mean to humans). Just because a name resolves to an address of a particular host does not mean that it's valid to use that name in a referral. For that matter, there's often no way for an application to know what names will resolve to a particular host - but even if the app did know this it would not mean that the application was justified in using a particular name in a referral. Whether it's valid to use the name in a referral depends on what the name was intended to mean. > KM> What this means among other things is that existing domain names that we > KM> use cannot be expected to be host identifiers. > > It depends upon how they are used. A wide variety of uses for DNS names is now well established; it would be very difficult to restrict this variety of use in a significant way. > KM> Even when they are > KM> sufficient to identify a host for initial connection purposes, resolving > KM> the same DNS name again may not produce a locator for the same host as > KM> before. > > You are assuming all sorts of semantics to the use of a DNS string that > might or might not be true, for any specific proposal to use domain names. The above arguments are assuming that we'd be using the same DNS names for hosts/services that we're already using. Could you create a different set of DNS names (e.g. a different class or different TLDs, or *maybe* different RRs) and insist that they be bound explicitly to hosts so that you can use them in referrals? Maybe, but it's very hard to get people to use human-readable names the way you want them to. (I've got the scars from the URN wars to prove it) > KM> * Not organized favorably. Existing DNS names are organized according to > KM> a hierarchy of administrative entities, > > This is a strength, not a weakness. If the requirement is for a > globally-registered and unique string, there is not other administrative > model for which we have global experience. Feel free to cite a > counter-example. The problem is not so much that the names are assigned in a hierarchy, but the fact that the existing hierarchy isn't a good model for how real-world hosts are used. > KM> The components of domain names are usually > KM> intended to be recognizable by humans, and humans therefore attach > KM> meaning to those names. > > This is a feature that serves to improve the mnemonic potential of the > strings. So? So it means that there are inevitably conflicts over uses of those names when a host (or its owner) has multiple roles. If you want an identifier to be bound to a host (and you need it to be, given the other problems) forcing that host to live at some point in a human-meaningful hierarchy creates conflicts because it won't always be serving in the role that goes along with the human meaning. To take a familiar example, lots of people are now encouraged (sometimes forced) to use multiple email addresses because their employer doesn't want their personal mail to be associated with the employer's domain name. Keith -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
