Subject: DNSEXT WGLC Summary: LLMNR

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Tue, 21 Oct 2003 15:24:04 -0400

This last call has concluded.
There was been extensive discussion about this draft.
A number of new issues raised and closed. The most new document
version (-24) reflects all the issues raised and closed in the
working group last call.

Summary: the working group has reached consensus to advance this
document as a standards track document.

This document is of high quality and the process that lead to this state
is well documented on the document issues
tracker website: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html.

Some issues raised during the last call that where rejected.  This is
normal and expected. This even holds for objections based on
shipping code tailored to an older version of this document, as no
specification is to be considered final until after publication as an RFC.
In particular there was extensive discussion about the TTL==[1 or 255]
in this case the WG decided that it had made the right choice by
selecting 1, see
http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html#Issue 47
http://psg.com/lists/namedroppers/namedroppers.2003/msg01609.html

         Olafur 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 21 Oct 2003 13:53:51 -0700

Speaking as an individual (as is always the case at the IETF), not as a 
representative of Apple...

A brilliant move by the working group. My congratulations to those 
involved. By refusing to interoperate to punish a vendor for shipping a 
product in a timely manner, the document this working group has 
produced will now have to compete with that vendor. It's a good thing 
the IETF exists to help fragment the market.

LLMNR as defined in draft 24 is useless in my opinion. In order to 
satisfy everyone, compromises were made. So many compromises that the 
protocol is nearly useless. I see no reason why any vendor would 
implement it, it doesn't seem to solve any problems.

I am interested in a solution to the problem of ad-hoc networks. Two 
people meet and use a cross over cable. LLMNR does not address that 
scenario because there is no guidance on what name a device would have. 
While many on this working group are probably responsible for a domain 
or know someone who is, there are many people that use nothing but 
dial-up and DSL. Many of those people have NATs, where their machines 
have private addresses. Their computers don't really have a host name 
they can call their own. In the ad-hoc scenario, such a user would have 
no idea what name to use for their laptop. For this reason, LLMNR does 
not address my needs for the ad-hoc solution.

I am is also interested in solutions to common home network problems. 
The world is filled with NATs. Many people have a few machines at home 
with private addresses. Those machines don't have DNS names. When a 
friend comes over with a laptop and plugs in, that friend gets an 
address. The ability to use names in such a scenario would be a huge 
benefit. As it is, that friend will get a configured DNS server address 
just like every other device on that network. LLMNR is next to useless 
at that point. If the laptop is configured to respond to a name such as 
joe.example.com, LLMNR will never query for that name because there is 
already a DNS name joe.example.com. The only name that would work with 
LLMNR is one that gives an error when sending the query to a normal DNS 
server. Maybe "joe." gives an error today. That might change in time. 
Suddenly things stop working. The user has to come up with an easy to 
remember name that will always fail when sent to DNS to get LLMNR to 
work.

LLMNR could have been used for new devices introduced on the network. 
Headless devices like ethernet cameras have complicated manuals for 
configuring the device the first time. The manual usually requires the 
user to set their computer to an address in a specific subnet and then 
connect to the device at a specific address on that subnet. With LLMNR, 
the device could instead use DHCP or IPv4LL to acquire an address and 
advertise the name with LLMNR. Configuration would be as simple as 
launching a browser and typing in the LLMNR name of the device. What 
LLMNR name could such a device use? It's not clear.

Using Apple's mDNS protocol, I have solutions to all three scenarios. 
Using LLMNR, I don't have a solution to any of these scenarios. Why 
would I pick LLMNR over mDNS?

With so many failure cases and no clear way to help a user configure 
LLMNR, who would implement LLMNR and why?

As stated in the Introduction "The goal of LLMNR is to enable name 
resolution in scenarios in which conventional DNS name resolution is 
not possible.". I think LLMNR fails to meet this goal.

-josh

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Oct 2003 21:15:24 +0000

i have no comments for or against the quality of either the document or
the protocol for either mDNS or LLMNR.  however, i will echo one of
joshua's concerns, which is that the document that will be advanced
seems to be a compromise which will please nobody.  i very much wish
that there had been a design team, and community buy-in at the vision
level, rather than the fragmented market that will apparently now exist.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Wed, 22 Oct 2003 06:52:51 +0900 (JST)

> tracker website: http://www.drizzle.com/~aboba/DNSEXT/llmnrissues.html.

	document quality might be high, but if it does not interoperate with
	major implementation out there (i.e. Apple Rendezvous/mDNS) the
	document would be useless.

itojun

---

From: masataka ohta <[email-masked]>
Date: Wed, 22 Oct 2003 09:37:24 +0900

Josh;

> product in a timely manner, the document this working group has produced 
> will now have to compete with that vendor. It's a good thing the IETF 
> exists to help fragment the market.
> 
> LLMNR as defined in draft 24 is useless in my opinion.

I tend to agree, but, with reasons different from yours.

If LLMNR is useless, it is not because of the way it was
standardized but because its purpose is meaningless.

> In order to 

Vendors, especially biggest ones, have been having no
trouble implementing useless protocols solving no
problems.

> not address my needs for the ad-hoc solution.

Wrong.

You can give a globally unique domain name for anything which
may or may not be connected to the Internet.

For example, a vendor can, at factory, assign its products globally
unique domain names such as:

	abcd1234.pc.apple.com

or

	abcd1234.camera.apple.com

which is no more difficult than assigning MAC addresses for NIC
cards. The vendor can, like NSI, even sell premium names.

Thus, you have no trouble to use the globally unique (no worrying
about name conflict) domain name in ad-hoc networks.

Of course, if we don't have access to DNS, we may have alternative
protocol, which may or may not be LLMNR.

> resolution in scenarios in which conventional DNS name resolution is not 
> possible.". I think LLMNR fails to meet this goal.

I think it does, though I'm not sure the goal is meaningful.

						Masataka Ohta

PS

I'm not actively for or against LLMNR.

---

From: Mark Baker <[email-masked]>
Date: Tue, 21 Oct 2003 20:33:06 -0400

> 	document would be useless.

I concur.

I hope the WG appreciates what a mess it's creating.  Is the TTL issue
really *that* important?  I don't really know (I'm more an apps guy),
but the fact that the group has, at various times, held both positions,
suggests to me that it isn't.

Very disappointing ...

Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca