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.
Agreed. And there are various ways to accomplish this.
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.
Agreed as well.
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.
You'd think that, wouldn't you? But the draft really only mentions this stuff
in passing.
Indeed, as I commented before, the whole tone of the document seems off kilter
to me. It really feels like a document meant to block rather than facilitate.
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.
I can argue this point either way. I haven't looked at mDNS closely enough to
have an opinion about it. OTOH, I'm pretty sure LLMNR has missed the mark
rather badly, irrespective of whether the right solution is separation by
interface or separation by naming convention.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf