Keith Moore wrote:
What is this document for? No one has implemented this LLMNR protocol. No
one has any plans to implement this protocol. No company plans to ship
products using this protocol. Even Microsoft has not even hinted at plans
to use LLMNR in Longhorn/Vista.
I don't see anything in RFC 2026 criteria that hinges on whether
Microsoft intends to implement a protocol.
I have seen windows boxes use it. They left traces on our root servers
and they cried when we hit them treating ".local" like "localhost"
It was windows users who complained not Macintoshes.
Local name lookup is useful, but trying to overload DNS names to serve
two different purposes, without breaking apps and/or making DNS appear
to be inconsistent, is fairly difficult. There's an inherent conflict
between wanting local name lookup to be transparent to apps
(perhaps even by changing the semantics of existing and well-established
APIs to do local lookup in addition to DNS lookup), and having the two
lookup services produce inconsistent results (thus confusing apps that
quite reasonably expect that they should be consistent). If you try
to make the two kinds of names look different you risk breaking apps
that expect everything to look like a DNS name. And if you overload
DNS syntax then you subject DNS servers to bogus queries.
Bogus queries do sabotage our root servers. They make 90% of our traffic.
That is what "root-servers.net" say. I have seen traffic reduced on
"a.public-root.net" by some 25% when we showed them a dummy for ".local".
The primary reason IETF exists is to try to sort out those kinds of
conflict in an open, neutral setting.
For whatever reason, you chose to ship code without waiting for IETF to
finish its deliberations on how to resolve those conflicts. Maybe you
were right to do so. I wish I could say that IETF always produces
superior results, but we all know that it desn't always succeed. And
yet, by doing so you were essentially disregarding others' legitimate
concerns about the problems associated with your approach, and/or
unilaterally deciding, on behalf of not only your customers but
everyone who might be affected by deployment of your protocol, that you
are in a better position to know what is good for them than everyone
else who participated in IETF.
They are restricted to their local LANs. I have never seen them in the
wide, wild internet.
Now you are arguing that people who attempted to consider a wide range
of input, and to do a responsible job of engineering a DNS-compatible
name lookup solution should abandon the results of their efforts in
favor of your ad hoc solution, merely because you were irresponsible
enough to ship it in product before the issues were widely understood
and the conflicts resolved in an open forum.
Well, maybe you're right, and maybe mDNS is better than LLMNR. Or
maybe mDNS is only slightly worse, and not enough worse to make it
worth the confusion that standardizing LLMNR will create. But you're
not going to convince anybody of that with your current line of
argument.
IMHO, if you can't provide a thorough analysis indicating that mDNS
works better than LLMNR, that mDNS resolves those conflicts in a
superior way to LLMNR, and that your solution will do less harm to
applications and DNS consistency than LLMNR, and that mDNS conforms to
2026 criteria, you don't have much of a gripe, and you certainly don't
have justification for saying that LLMNR should be abandoned.
You ask about running code. Running code is useful. A single
impelmentation serves as a proof of concept. Multiple implementations
derived from a single spec and tested against each other serve as a
clarity check on the specification. But mere existence of running code
is not a reliable indicator of sound design. In the ARPAnet days, when
there were only a few dozen hosts, a few interoperability tests were
generally enough to give a reliable indication of full-scale behavior.
In an Internet with a billion hosts, producing an implementation is
just a baby step. These days, there's no substitute for thorough
analysis of the effect of a protocol based on a large number of use
cases. So mDNS's running code and deployment do not trump LLMNR, and a
comparison of mDNS and LLMNR implementations would not yield much
useful data unless one were grossly more inefficient than the other.
I'd say 25% of traffic on root servers is grossly inefficient and it does
violate a couple of RFCs.
As for this Last Call - I think there are two questions that should be
asked:
1. does LLMNR meet 2026 criteria? no known technical omissions,
conflicts resolved, etc.
2. is LLMNR enough better than mDNS to make it worth approving it as a
standard even though mDNS exists and has some limited deployment? If
the answer to #1 is yes, then I suspect the answer to #2 is also yes,
but an explanation is needed.
Furthermore, if there is rough consensus, supported by analysis, that
mDNS is harmful, then we ought to consider saying that. But we
shouldn't make this statement critical path for getting LLMNR out the
door.
Keith
Regards,
Peter and Karin
--
Peter and Karin Dambier
Public-Root
Graeffstrasse 14
D-64646 Heppenheim
+49-6252-671788 (Telekom)
+49-179-108-3978 (O2 Genion)
+49-6252-750308 (VoIP: sipgate.de)
+1-360-448-1275 (VoIP: freeworldialup.com)
mail: peter@xxxxxxxxxxxxxxxx
http://iason.site.voila.fr
http://www.kokoom.com/iason
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf