Keith,
>> 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.
KM> Name EXAMPLE.COM maps to hosts B and C. Hosts B ausing addresses B1 and C1,
KM> respectively. Host A looks up EXAMPLE.COM, gets addresses B1 and C1, chooses
KM> B1, and starts talking to it. The application now has some state that is only
KM> accessible to host B.
KM> For some reason the connection gets broken. Maybe host B changes its
KM> address from B1 to B2. A needs to re-establish a connection to host B -
KM> host C will not work because the application now relies on state that only
KM> B can access. EXAMPLE.COM does not name host B uniquely;
I am guessing that you have not read the MAST proposal and have not been
noting the details that a number of us are seeking about actual requirements
for an endpoint identifier.. I'm suspecting you also are not familiar with the
other proposals.
So, yes, you have invented a scenario that uses domain names in a way that
will not work. Unfortunately, no one is proposing such a broken scenario.
So let me rephrase the question more simply and more rigidly:
What is it that _requires_ specifying using domain names in a way that
causes problems?
If that question is not clear enough, then try:
What is _inherent_ in domain names that prevents their use as endpoint
identifiers? Inherent, not merely "possible".
It is always possible to create a broken design. Citing such an example is
not overly helpful.
However I really should thank you. Much of these discussions have been marked
by attempts to make design choices based on very abstract issues, rather than
on looking on plausible and probable actual usage. This makes much of the
discussion fundamentally not grounded, both literally and figuratively.
We now have quite a few concrete proposals and specifications. We should make
a point of using these data points as concrete examples of the solution space.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
