Subject: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard

From: Stuart Cheshire <[email-masked]>
Date: Thu, 25 Aug 2005 10:18:15 -0700

>I do not understand how defining a new, different service on a new 
>port will kill anything.

Are you saying that you *REALLY* do not understand how the IETF defining 
a new protocol, and stating publicly that it's intended to compete with 
some established protocol, gives all the appearance of an attempt to kill 
off that existing protocol? An attempt to split implementers into two 
non-interoperating camps? An attempt to cause customers and other 
implementers to put off making a decision on either protocol while they 
wait to see which camp wins?

Of course LLMNR won't actually kill off mDNS, but there's a real risk of 
it causing confusion and delay. And, in the process, the failed effort to 
kill off mDNS squanders the IETF's credibility.

Before you claim that LLMNR was not intended to compete with mDNS, this 
is from Bernard Aboba's LLMNR FAQ:

<http://www.drizzle.com/~aboba/DNSEXT/llmnrfaq.html>

> Rendezvous [Bonjour] is an individual submission that is not a work
> item of any IETF working group, and is currently not an IETF standard.
> While it is possible for an individual submission to become an
> IETF standard, this is unlikely in this case because an existing
> WG (DNSEXT) is already working on a competing protocol (LLMNR)

Before you claim that it's not causing confusion in the broader 
community, this is from the Wikipedia entry for "Zeroconf":

<http://en.wikipedia.org/wiki/Zeroconf>

> Name resolution
> There are two very similar ways of figuring out which
> networked item has a certain name. Apple Computer's Multicast
> DNS (mDNS) is in use, but is not an IETF standard. Microsoft's
> Link-local Multicast Name Resolution (LLMNR) is not yet being
> used, but is being officially standardized by the IETF.

There's a clear message being promulgated that the two protocols are 
more-or-less equivalent in functionality, the only significant difference 
being that one has the endorsement of the IETF and the other doesn't.

It would go a long way to ease my concerns if the LLMNR specification 
stated clearly in its introduction that it's NOT intended to compete with 
mDNS, because LLMNR doesn't have any of the functionality that mDNS 
provides to enable network browsing and service discovery.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer, Inc.
 * www.stuartcheshire.org

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 25 Aug 2005 10:39:33 -0700

> provides to enable network browsing and service discovery.

Stuart,

do you have a published specification of Apple's mDNS that you can point 
people at, so that people can understand what functionality mDNS has that 
LLMNR does not?

<http://www.watersprings.org/pub/id/draft-cheshire-dnsext-multicastdns-02.txt> 
claims that browsing and service discovery is described in this draft:

   [DNS-SD]   Cheshire, S. "DNS-Based Service Discovery", Internet-Draft
              (work in progress), draft-cheshire-dnsext-dns-sd-01.txt,
              June 2003.

Is it the combination of those 2 drafts that you mean when saying "mDNS", 
or is it some other document grouping?

                   Harald

---

From: Marc Manthey <[email-masked]>
Date: Thu, 25 Aug 2005 20:15:50 +0200

On Aug 25, 2005, at 7:39 PM, Harald Tveit Alvestrand wrote:
>
> <http://www.watersprings.org/pub/id/draft-cheshire-dnsext- 
> multicastdns-02.txt> claims that browsing and service discovery is  
> described in this draft:
>

hello all,

this is  more detailed i think.     http://www.dns-sd.org/

regards

marcM.

--
"Fernsehen ist Kaugummi für die Augen. "(Orson Welles)

Les Enfants Terribles
www.let.de

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 25 Aug 2005 18:29:45 -0400

Hi Stuart,

>  provides to enable network browsing and service discovery.

It is not typical for us to make statements in our standards 
regarding what proprietary mechanisms our standards are or are not 
intended to compete with, nor do we typically include statements that 
compare the features of our standards to proprietary protocols.

We do sometimes include statements about the applicability of our 
standards to specific environments, but I don't think that is quite 
what you are suggesting here.

I understand that you and some others would have preferred it if we 
had standardized the Apple protocol.  I wasn't involved at the time, 
but I understand that the WG did not choose to purse the Apple mDNS 
proposal and intentionally selected the LLMNR proposal, with the 
understanding that the standard they produced would not be compatible 
with the existing Apple mDNS technology.  I wish that I had enough 
insight into the decision-making process to know why that was 
decided, but I do not.  At this point, it seems too late to revisit 
this decision which was made several years ago.

Margaret

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 26 Aug 2005 18:27:07 +0200

On 26-aug-2005, at 0:29, Margaret Wasserman wrote:

> I wasn't involved at the time, but I understand that the WG did not  
> choose to purse the Apple mDNS proposal and intentionally selected  
> the LLMNR proposal, with the understanding that the standard they  
> produced would not be compatible with the existing Apple mDNS  
> technology.  I wish that I had enough insight into the decision- 
> making process to know why that was decided, but I do not.

Would it be too much to ask that someone who knows explain this?

> At this point, it seems too late to revisit this decision which was  
> made several years ago.

I disagree. If you can't do the right thing on time, at least do the  
right thing late. Doing the wrong thing late doesn't help anyone.

I think the fact that mDNS has been successful in the market place  
should be given a lot of consideration. At this point, something new  
has to be a A LOT better to be worth the extra implementation effort,  
and, more importantly: all the operational issues it will cause (if  
there is any uptake) for years to come.

I'm afraid we're looking at a new ip6.int / ip6.arpa debacle. This  
stuff wastes SO MUCH time and effort that it's almost criminal to  
make these changes if there is no clear technical advantage.

The posts from others lead me to believe that LLMNR is actually  
inferior to mDNS, and the fact that the draft is version 42 also  
speaks volumes.

At the very least the IESG should move this protocol off the  
standards track and let it stew in "experimental" for a while.

---

From: Marc Manthey <[email-masked]>
Date: Fri, 26 Aug 2005 21:52:53 +0200

hopefully convalesce Marshall Eubanks wrote following  important lines

> why should a protocol that no-one will use be standards track ?
> This discussion is beginning to remind me of the scientific  
> standards processes involving the Soviet
> bloc that I was involved with during the Cold War. That is not a  
> good sign...

and a very disrespectful person named  Keith Moore wrote:

> Why should we accept a few (mostly axe-grinding) peoples'  
> assertions that no-one will use it?

  Iljitsch van Beijnum wrote:
> should be given a lot of consideration. At this point, something  
> new has to be a A LOT better to be worth the extra implementation  
> effort, and, more importantly: all the operational issues it will  
> cause (if there is any uptake) for years to come.

Russ Allbery wrote:
> Presumably the DNS working group has some incredibly strong  
> arguments that
> trump running code or they wouldn't have made the choices that they  
> have.
> Let's see them, and furthermore, let's see them *in the document*  
> or at
> least in a supporting informational document, since those of us on the
> IETF mailing list are certainly not the only people who are going  
> to have
> that question.

Rob Austein wrote a lot of importand stuff and ...

>  "How about tossing a coin?"

ladys and gentleman ,

i count over 170 application that are under deployment  or  allready  
successfully  implemented
why can t we have a constructional discussion how things could be  
progressed ?

<http://www.dns-sd.org/ServiceTypes.html>

pace Marc

--  
"Pulvis et umbra sumus" -  Staub und Schatten sind wir.

Les Enfants Terribles
www.let.de