On 8/31/2005 12:36 PM, Ned Freed wrote:
Section 2 states:
that's unfortunate
LLMNR clients need to make a distinction between the different kinds of
networks and then process the names accordingly.
The whole argument behind the original distinction between LLMNR and DNS
is that ad-hoc names aren't self-authoritative, the namespaces are
therefore different, and so forth. Having clients try both namespaces is
really missing the point.
Another way of fixing the overlapping namespace problem would be to require
LLMNR to be truly disjoint from the DNS: Remove all this stuff about using the
DNS as the primary service when available. However, my guess is that such a
service would not be terribly interesting, and that much of the supposed value
opf LLMNR comes from its lashup to the DNS.
I was under the impression that LLMNR value was from ad-hoc networks and
naming. Surely that's the right place to flag the distinction too.
NB: I consider ".local" to be a crutch that's needed to make a hack work,
and the right place to deal with these problems is at the interface map,
not inside the namespace. Nevermind the fact that .local is overloaded
with massive historical and experimental context already too.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf