ietf
[Top] [All Lists]

Re: Stuart's comments

2005-09-09 14:50:20
Stuart Cheshire said:

What's happened is more complicated and more puzzling. Somehow the IETF 
process has run out of control, and taken on a life of its own, and taken 
us in a direction that makes little sense.

I agree with this, and unfortunately this is not the only instance.  In 
fact, one could argue that things would have turned out better had the IETF 
not been involved at all. 

In almost every posting on the subject there's a tacit assumption by 
almost everyone that these are two roughly equivalent competing 
protocols, and they do the same thing, but do it in slightly different 
ways. If that were true, then it would be a straightforward technical 
analysis to see which does it best, and over time a migration to the 
better one would be possible, sensible, and desirable.

The problem is that they don't do the same thing. LLMNR can't replace 
mDNS because LLMNR doesn't do what mDNS does, and LLMNR doesn't do what 
mDNS does by design, not by oversight:

Correct. 

What happened here was *not* that the DNSEXT working group disagreed with 
me on the technical details of my solution. What happened was that the 
DNSEXT working group disagreed with me on the problem statement. I said, 
"Here's a proposed way to do simple effective service discovery using 
existing DNS record types." The DNSEXT working group said, "The DNS 
protocol is not to be used for service discovery. We forbid it, and 
furthermore, to prove the point, we're going to design a protocol of our 
own that superficially looks like yours but can't be used for service 
discovery." It was a "poison the well" response. They didn't create LLMNR 
because they thought that a DNS-like multicast-based name lookup protocol 
was a good idea. They created it because they saw it as the lesser of two 
evils. It was a case of, "If we don't create this, then Stuart will 
create something worse."

At the time that DNSEXT made its decision, I was not even following the 
mDNS discussion very carefully.  Since there had been a ZEROCONF BOF and 
agreement to proceed on mDNS work, my assumption was that DNSEXT WG was 
going to proceed on standardizing one of the presented solutions (either 
Bill Manning's solution or Stuart's) and we would implement it.  However, 
after noticing that no document were advancing, we were told that the WG 
had rejected *both* proposals and that no work was planned.  So work on 
LLMNR was (reluctantly) begun -- with the understanding that the 
objectionable aspects of the other proposals could not be incorporated. 
At the time I did not appreciate that agreeing to the DNSEXT WG 
preconditions would preclude the development of an interoperable solution. 

In retrospect, the correct thing to have done at that point would have been 
to give up on the DNSEXT WG entirely in order to work with Stuart on a 
joint design, as was done with IPv4 link local (which successfully 
interoperated before the IETF became involved). 

What bothers me is the almost universal assumption that LLMNR is the 
official successor to mDNS, or at least is intended to be. Everywhere I 
read -- the LLMNR FAQ, Wikipedia, news articles, this IETF discussion -- 
I see the same assumption repeated, taken so much for granted that it 
doesn't even need to be stated. To me it's like someone on the evening 
news telling the world, "Why waste money on expensive messy oil for your 
car, when plain water works just as well? Go and drain your oil right now 
and replace it with good old clean, environmentally-friendly tap-water." 
If everyone actually did that, we'd all find out -- too late -- on the 
drive to work tomorrow what a terrible idea it was.

Funny you should mention that.  I also have a problem with the 
accuracy of the Wikipedia articles, news articles and this IETF discussion. 
And I agree with you that LLMNR is not a successor to mDNS. 


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>