Response to LLMNR Last Call Comments

[Bernard Aboba <[e-mail]>]

Edward Lewis said:

"Security concerns I understand and would become a work item"

Since security issues came up in the LLMNR Last Call discussions, it would 
be useful for DNSEXT WG to discuss that issue, although I'm not clear that 
a separate work item would be required.  For example, it would be useful 
to understand what if any barriers exist to the use of TSIG, SIG(0) and 
DNSSEC in the mDNS and LLMNR specifications, and how they could be 
overcome. 

It would also be useful for the DNSEXT WG to discuss the other issues that 
were raised, such as defining the behavior of DNS resolvers with respect 
to the .local domain. 

Paul Vixie stated:

>while i agree with this in general, i have three specific concerns.
>
>1. the right way to do multicast DNS is draft-manning-opcode-discover-01,

So why not publish that document as well?

>   and while apple and microsoft both call their approaches "multicast 
>   dns" they are really "overloading dns to carry service discovery in 
>   multicast".

LLMNR is not a service discovery protocol.  It is usable solely for name 
resolution.  While the discussion of mDNS in the two ZEROCONF BOFs 
centered on service discovery, discussion in the ZEROCONF WG did not converge
and work on service discovery was not chartered in ZEROCONF or DNSEXT.  

Since people's memory of events that occurred more than 6 years ago may be 
a bit foggy, I've gone back through the proceedings, which document what 
happened in the ZEROCONF BOFs, as well as early discussions in the DNSEXT 
WG.  That information is available here:
http://www.drizzle.com/~aboba/DNSEXT/history.txt

>2. any attempt to merge mdns and llmnr MUST be backward compatible with 
>mdns, since apple has created an important new economy of mdns 
>services/devices and ietf should only ignore this economy if mdns is the 
>provably wrong  approach, rather than merely suboptimal in some way (that 
>i'm unaware of).

mDNS is designed to serve as a service discovery substrate for DNS-SD.  If 
the DNSEXT WG and IESG want to reverse their prior edicts against DNS-SD 
and use of DNS for service discovery, as well as the refusal to allow 
Bill's document to move forward, that is fine with me. 

However, that is really an orthogonal issue as far as LLMNR is concerned. 
At this point, LLMNR has also shipped in multiple implementations, and 
given the past history of IETF activity, I doubt there is anyone interested 
in working on a "merger" effort. 

The only reasonable thing to do is to address the LC comments, publish 
(as Experimental or Informational, probably) and move on.

>3. if this is really about PnP, i sure wish that everybody would just say 
>so  and re-frame the debate in PnP terms and stop treating it as a dns 
>issue  that's somehow relevant to the skills of the core namedroppers 
>community.

While mDNS relates to PnP service discovery, LLMNR does not.  So no, 
the LLMNR discussion isn't about PnP or service discovery.  It's largely 
about security issues, and resolver behavior. 

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