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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf