Hello, Comments inline below:
----- Original Message ----- From: "Keith Moore" <[EMAIL PROTECTED]> To: "Dave Crocker" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, September 17, 2003 7:21 PM Subject: Re: A strawman analysis on locator identifiers vs. non-locator identifiers (was Re: A roadmap for end-point identifiers?) > 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. How about B saying in the earliest possible stage of conversation with A: `Okay, I don't know what name you looked up in DNS to reach me, but in the future please use this domain name (that uniquely identifies me) to reach me again later'? This could, but need not, happen in the application layer; some other layer that handles the id-loc mapping could do this. My assumption is that each host has knowledge about what domain name is its unique identifier. Host/site administrators can configure one into each host using various ways such as (heaven forbid) manual configuration, or DHCP e.g. by looking up the client's link-layer address in a link-layer-address-to-identifier table and, if not found in the table, defaulting to the link-layer address combined with the network identifier to form one like `EUI64-003048FFFE234C67.MARKETINGNET1.EXAMPLE.COM'. Then it really comes down to the application figuring out what the identifier for the host it is running on. gethostname(3) comes to mind first; if the common practice dictates that it's already being used for something else (e.g. a service identifier), we could invent and propose something else like confstr(_CS_HOSTID) in 4.4BSD. > > > 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. Please see the above. > > > 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) How about making the name used as an identifier (at least to those ones that configure it to DNS zones) suggest `No, this isn't a typical domain name you could do anything you wish; don't overload this for anything else'? One example could be a SRV RR with _HOSTID._IP as the _Service._Proto part. IMO, actually a SRV-like syntax is ugly to human eyes (because it starts with an underscore =p) so DNS administrators are less tempted to overload that name for other purposes. > > > 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. Could you (give a pointer to some documents that) elaborate on the subject? Regards, Eugene -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
