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

Hi Stuart,

Somehow our discussion has gone awry, and I'm not quite sure why, 
because I am not sure that we fundamentally disagree with each other. 
At least, I think that we both see some of the same potential 
problems, even if we disagree about what steps would be appropriate 
to resolve them.
[Please note:  In this note, I will use the term "LLMNR" to refer to 
the DNSEXT WG draft named draft-ietf-dnsext-mdns-XX.txt, and I will 
use the term "mDNS" to refer to the de facto standard Apple mDNS 
protocol.]
Other than a few minor issues that are being dealt with in a -43 
update, I don't think that anyone has raised a blocking technical 
issue with the LLMNR specification during this IETF LC.  If you (or 
anyone else) has intended to raise a blocking technical issue, either 
with LLMNR itself or with its ability to coexist with mDNS, please 
make that clearer to me.
I do, of course, see overlapping purpose/applicability for the mDNS 
and LLMNR mechanisms, and that is a significant source of concern.
In general, I don't personally think that the Internet would be 
best-served by having two different widely-deployed mechanisms for 
link local name resolution.  I can infer that the DNSEXT WG agrees 
(or agreed at one time), since they decided that a selection process 
was necessary rather than just publishing both (or all three) 
mechanisms.  So, I'm not quite sure what to do given that mDNS _is_ 
widely deployed, and that we are considering the standardization of 
LLMNR in an Internet where mDNS must considered as part of the 
existing landscape.
I am somewhat concerned, for example, that someone could implement 
LLMNR thinking that it is the same thing as mDNS and only later find 
that the two do not interoperate.  Or that some vendors will ship 
LLMNR while others ship mDNS, so that products from different vendors 
will not interoperate.  Do others have any thoughts on whether the 
publication of LLMNR is likely to cause confusion along these lines?
On the other hand, the DNSEXT WG has worked for several years to 
produce the LLMNR specification, and I don't see anything 
fundamentally wrong with the mechanism that we have produced (people 
should respond to the IETF LC if they see blocking technical issues). 
The authors of that specification gave change control to the IETF 
community, and they have gone through 40+ document iterations, 
working towards a document that would achieve DNSEXT consensus.  That 
process was not followed for mDNS (because it was not the chosen 
solution), and we currently only have one document (LLMNR) that has 
reached IETF WG consensus and has been submitted for standards 
publication.
It is possible, in an IETF LC, that we could learn that we do not 
have IETF consensus to publish something that was produced by an IETF 
WG.  That would be an exceptional and unpleasant situation, but I am 
open to that possibility.  In this particular case, though, I see 
that a few concerns have been raised that were already raised during 
the WG process, and I do not see an IETF consensus against publishing 
the LLMNR document that would override the DNSEXT WG consensus to 
publish it.  If folks disagree with this determination, they should 
speak up, because I am currently of the opinion that we do have 
DNSEXT WG and IETF consensus to publish LLMNR on the IETF standards 
track.
Some folks have already implemented LLMNR, and at least one company 
has shipped it in a commercial product.
So, I think that, no matter what happens, we are stuck in a world 
where there will be at least two link-local name resolution 
mechanisms.  Having come to that conclusion, I don't believe that 
there is any perfect answer here.  I think that our focus needs to be 
on minimizing the potential damage or confusion that will be caused 
by having two mechanisms.
Stuart, have you considered publishing mDNS on the individual 
submission track (as an Informational RFC)? I think that the 
existence of that document might help to avoid confusion about 
whether the LLMNR document describes mDNS.
The LLMNR document already includes an informative reference to 
draft-cheshire-dnsext-multicastdns-05.txt, but it does so rather 
obscurely (citing a need to use a TTL of 255 for "compatibility with 
Apple Bonjour").  It might be better to include a pointer to this 
document earlier in the LLMNR spec and indicate that Apple Bonjour 
includes another mechanisms for link-local name resolution.  Also, I 
am surprised by the reference to compatibility with Apple Bonjour 
(which I didn't notice in my AD review), because I was not under the 
impression that these protocols are compatible (as in interoperable). 
LLMNR authors, could you perhaps elaborate on what was meant by this 
statement?
Would the LLMNR authors and or the DNSEXT WG object to the idea of 
including an informative reference to mDNS (presumably as "Apple 
Bonjour") earlier in the document, stating that it is another 
link-local name resolution protocol and making it clear to what 
extent LLMNR is (or is not) compatible with mDNS?
Thoughts?
Margaret



_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf