Looking at the recent discussion and some private emails I've received, 
it's clear that I didn't explain some points well enough.

1. I'm not claiming this is an Apple vs. Microsoft battle. Bernard Aboba 
is not a Microsoft corporate shill, and I'm not a shill for Apple. 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.

2. People have commented that my postings were light on technical
argument and heavy on marketing. If so I apologize. But in a sense, this 
debate *is* about marketing.

My complaint is not so much that the IETF community (or at least a vocal 
and influential portion of it) didn't like what I proposed with mDNS & 
DNS-SD, or that the IETF may choose to make LLMNR a Proposed Standard. 
Those are two independent things that should really have no bearing on 
each other. My complaint is that the IETF is engaged (perhaps 
unknowingly) in a marketing campaign of its own, to present LLMNR as the 
"official" version of Apple's "inferior proprietary" solution, as if 
there were an expectation that eventually everyone would migrate over to 
the new "official" protocol.

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:

* mDNS was designed primarily to meet service discovery goals, and
delivers hostname lookup almost as a side effect that you get "for free".

* LLMNR was designed solely to do hostname lookup, and the document
explicitly prohibits any use for service discovery purposes.

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."

People who know me can tell you that I haven't done all this work with 
the intent of creating some great monopoly for Apple. I began this work 
before I joined Apple, and I'm sure I'll continue it even if I leave 
Apple. I've done all this work because I'm tired of seeing people 
struggle with computer products that are too hard to use. I'm tired of 
great potential products that can't come to market because the audience 
of people who could actually make them work is too small. That's why I 
fought so hard to get Apple's mDNS & DNS-SD code freely licensed as an 
APSL Open Source project. That's why I fought so hard to get the client 
libraries licensed under the even more liberal three-clause BSD license, 
so they're compatible with GPL client code. That's why I fought so hard 
to have Apple's code live in a publicly-accessible CVS server so that 
everything we do can be seen and shared by others, and so that others can 
contribute. That's why we work so hard to have accurate specifications 
available so others can do independent implementations from the spec, and 
when others do create independent implementations, we don't treat them as 
competitors. We thank them publicly, and encourage them, and help them, 
and make our conformance test software available to them to help them 
find any bugs or potential incompatibilities. If they believe that our 
conformance test software is making some unreasonably strict requirement, 
and we agree, then we've even changed our conformance test to permit 
legitimate variant behaviors by other implementations.

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.

So, what am I asked for, specifically?

For the IETF to stop representing LLMNR as a superior drop-in replacement 
for mDNS. That's all, really.

One idea that's been suggested is that both LLMNR and mDNS could be 
published as Informational RFCs, or both as Experimantal, and then we'll 
let the experiments run and possibly standardize one in the future.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf