Margaret Wasserman writes ("Re: Last Call: 'Linklocal Multicast Name Resolution
(LLMNR)' to Proposed Standard"):
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.
Just to be clear, I am intending my contributions to this argument as
descriptions of what I see as blocking technical issues with LLMNR.
It seems to me from my reading of the specifications that:
* LLMNR is a ghastly protocol which should not be on the IETF
Standards Track.
* mDNS is a superior protocol to LLMNR in nearly all relevant
respects.
* The IETF should abandon LLMNR and put mDNS on the Standards Track.
I'd like to reiterate that I entered this discussion with a strong
presupposition towards IETF processes as opposed to third-party
activities. As I have read the specifications, and the arguments of
those we see reported here, I have become steadily more convinced that
Stuart is right about the politics and that LLMNR critics - such as I
now am - are right about the technical issues.
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?
It seems to me that these kinds of confusion are almost what the LLMNR
proponents are _aiming_ for !
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 LLMNR specification is _terrible_.
The issue with namespace ownership, that I've been hammering on about,
should in my opinion *of itself* be sufficient to block progress of
LLMNR on the Standards Track.
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.
If we believe Stuart Cheshire's description of events, it is not the
case that the IETF has chosen LLMNR over mDNS. Rather a subset of the
IETF (mainly associated with the DNSEXT WG) were so upset with mDNS as
a concept that they have sabotaged it.
Furthermore, the point of this exercise is not to measure how much
hard work the LLMNR authors have put into their draft. The fact that
it has been through 40 document iterations should be a cause for
worry, not a cause for applause !
The point of this exercise is for the IETF, as a whole, to standardise
on the best protocols.
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, [...]
If this situation is considered exceptional then I can only think that
the mechanisms for detecting it are broken !
Surely it is obvious that it will often be the case that an IETF Last
Call will bring the attention of many more people to a situation - and
most of those people will not share a community background with the WG
members. It is not surprising that in some subset of those cases, it
turns out that the WG have gone off in some undesirable direction
(either out of technical error or political machination).
The WG is a part of the whole IETF and should be subject to its
opinions.
Ian.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf