Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
Keith Moore <moore@cs.utk.edu> Thu, 25 August 2005 21:22 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PB8-0002j5-6O; Thu, 25 Aug 2005 17:22:30 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PB6-0002is-U4; Thu, 25 Aug 2005 17:22:28 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20648; Thu, 25 Aug 2005 17:22:26 -0400 (EDT)
Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8PBg-0002kV-LA; Thu, 25 Aug 2005 17:23:06 -0400
Received: from localhost (ka [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id DE1712351C; Thu, 25 Aug 2005 17:22:21 -0400 (EDT)
Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17167-02; Thu, 25 Aug 2005 17:22:19 -0400 (EDT)
Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by ka.cs.utk.edu (Postfix) with ESMTP id 23AB62351B; Thu, 25 Aug 2005 17:22:19 -0400 (EDT)
Date: Thu, 25 Aug 2005 17:22:17 -0400
From: Keith Moore <moore@cs.utk.edu>
To: Stuart Cheshire <cheshire@apple.com>
Message-Id: <20050825172217.432f7af9.moore@cs.utk.edu>
In-Reply-To: <200508250537.j7P5bgdU015864@relay3.apple.com>
References: <200508250537.j7P5bgdU015864@relay3.apple.com>
X-Mailer: Sylpheed version 2.0.0rc (GTK+ 2.6.7; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Content-Transfer-Encoding: 7bit
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
> 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. 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. 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. 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. 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 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Harald Tveit Alvestrand
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marc Manthey
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Keith Moore
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stephane Bortzmeyer
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marc Manthey
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stephane Bortzmeyer
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Bill Manning
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marshall Eubanks
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Keith Moore
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Iljitsch van Beijnum
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Bill Manning
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Rob Austein
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marc Manthey
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Steven M. Bellovin
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Pete Resnick
- Re: Last Call: 'Linklocal Multicast Name Resoluti… bmanning
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Christian Huitema
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Margaret Wasserman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Iljitsch van Beijnum
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ned Freed
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Russ Allbery
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Iljitsch van Beijnum
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Jeffrey Hutzelman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Spencer Dawkins
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Henrik Levkowetz
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Bill Manning
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Marc Manthey
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Steven M. Bellovin
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Jeroen Massar
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Brian E Carpenter
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Single DNS root (Re: Last Call: 'Linklocal Multic… Harald Tveit Alvestrand
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Christian Huitema
- Alternative roots (was: Re: Last Call: 'Linklocal… Paul Hoffman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Paul Hoffman
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Christian de Larrinaga
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Eric A. Hall
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ned Freed
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ned Freed
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Eric A. Hall
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ned Freed
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Tony Finch
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Christian Huitema
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Dave Singer
- Re: Single DNS root JFC (Jefsey) Morfin
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Keith Moore
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Jeroen Massar
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Frank Ellermann
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Jeroen Massar
- Name ownership and LLMNR (Re: Last Call: 'Linkloc… Harald Tveit Alvestrand
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Peter Dambier
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Keith Moore
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Henning Schulzrinne
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Iljitsch van Beijnum
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Tony Finch
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Alan Barrett
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Iljitsch van Beijnum
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Tony Finch
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Paul Vixie
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Stephane Bortzmeyer
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Paul Vixie
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Ian Jackson
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Harald Tveit Alvestrand
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Jeroen Massar
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Iljitsch van Beijnum
- Re: Single DNS root John C Klensin
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Daniel Senie
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Jeffrey Hutzelman
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Harald Tveit Alvestrand
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Iljitsch van Beijnum
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Bill Manning
- Re: Single DNS root JFC (Jefsey) Morfin
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Tony Finch
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Steven M. Bellovin
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Tony Finch
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Masataka Ohta
- Re: Last Call: 'Linklocal Multicast Name Resoluti… JFC (Jefsey) Morfin
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… Harald Tveit Alvestrand
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Daniel Karrenberg
- Re: Name ownership and LLMNR (Re: Last Call: 'Lin… JFC (Jefsey) Morfin
- Re: Last Call: 'Linklocal Multicast Name Resoluti… Andrew Sullivan
- RE: Last Call: 'Linklocal Multicast Name Resoluti… Stuart Cheshire