Subject: Re: Stuart's comments

From: Bernard Aboba <[email-masked]>
Date: Fri, 9 Sep 2005 14:48:33 -0700 (PDT)

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Sep 2005 08:56:54 -0700

Folks,

> I agree with this, and unfortunately this is not the only instance.  
...
> interoperated before the IETF became involved). 

Successful IETF work begins by developing support to do the development work and 
support to use the output of that work. The work is then done for development 
and deployment.

The procedural simplicity and practical utility of this model tend to be vastly 
under-appreciated.

It requires essentially no bureaucracy -- other than to assess the support -- 
while still imposing a very substantial (but appropriate) barrier to approval. 
In its stead we have developed a mythology about "controlling" and "choosing" 
single solutions before the work is done, as if we -- the IETF community or the 
IESG -- have the prescience to make the choice.

I believe you folks are describing a really good example of why the more 
authority-based and pre-emptive pruning process -- before work is attempted -- 
is such a fundamental problem. It is based on theoretical analyses and 
hypothetical criteria, rather than... running code (and running community support.)

Successful "competition" relies mostly on this "productivity" filter/test.  It 
is very, very rare that competing proposals both develop the necessary support 
and do the necessary work.  Further, the competition has the obvious benefit of 
adding a timeliness factor.  Efforts that do not make progress in a timely 
fashion are overtaken by those that do.

We used to trust the market to choose among competing proposals, so that the 
IETF process was primarily concerned with assuring a process of rational, open 
development. Instead, now, we purport to worry about the market getting confused 
by alternatives and about the market's inability to distinguish "bad" solutions.

The result tends to be that the IETF now serves to deprive the market of *any* 
(timely) solution and/or to provide overly complex, inappropriate ones.

As for the possible claim that the pruning is needed so that we don't waste IETF 
resources, folks really do need to take another look at how the IETF functions, 
since we do virtually nothing else to attend to efficiencies.  If we were 
seriously worried about efficiencies, we would require working groups to sustain 
substantial community involvement, rather than devolving into having all 
meaningful activity done by only a small number of individuals.  We also would 
worry far, far more about timeliness.

Certainly the random-walk of a popularity-based (ie, community support) 
filtering process can produce conflicting mechanisms that deploy simultaneously, 
where the conflict is either from competition or from unexpected interactions.

However it is simply not reasonable to let our fear of that eventuality take 
precedence to the extent that it defeats the basic utility of the IETF.

-- 
 
   d/

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net