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

[Brian E Carpenter <brc at zurich.ibm.com>]

Ian Jackson wrote:
> Brian E Carpenter writes ("Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)'  to	Proposed Standard"):
>
> > Russ Allbery wrote:
> > ...
> >
> > > I think your criteria doesn't survive logical scrutiny.  If other people
> > > have access to the standard, can implement the standard, and can build on
> > > the standard to create a newer revision of it, I can't imagine what
> > > definition of "proprietary" you're using that would apply.
> >
> > But mDNS is not on the standards track and LLMNR is proposed to be
> > on the standards track. That, I think, is why Stuart has raised the issue.
>
>
> I'm finding this discussion quite disturbing.  It seems that the
> proposal is that the IETF should bless LLMNR because LLMNR is on the
> Blessing Track.

It's been duly submitted by a WG and Last Called, so we *must*
consider it for the standards track. I can't tell you what the result
of that consideration will be; my crystal ball is down.

> Surely the reasons for the IETF to bless LLMNR as opposed to mDNS
> should be based on technical details

Yes, except that we don't "bless", we approve publication (or not).

> and deployment experience ? 

Strictly speaking, no - not for Proposed Standard status. But
implementation and deployment experience is always valuable input.

> In
> which case it seems clear that mDNS is far superior.  It's more widely
> deployed, more widely implemented, and not COMPLETELY INSANE !
>
> Sorry to be pejorative, but as a DNS implementor[1] I'm amazed to find
> senior IETF/IESG people seriously contemplating the kind of namespace
> confusion which is fundamental in the LLMNR protocol design.

Can you spell that out please? Since it uses a different port number,
where does the confusion occur?

    Brian

> The mDNS approach at least isolates the damage (if you consider it
> damage) to a specific subregion of the DNS, which you can choose to
> have on your search path or in your configuration - or not.
>
> It's a shame they chose `.local' (which was previously thought to be
> reserved for local system administrators) but that's too late to
> change now.  This mistake has happened in part because the relevant
> IETF WG failed to properly engage with the mDNS authors !
>
> I'm in general not a big fan of zeroconf, multicast, or anything else
> you might think of as weirdo DNS extensions.  I'm something of a
> luddite.  But if we're going to have an IETF-standardised protocol to
> address this problem area, surely we should choose the protocol that's
> (a) widely deployed, (b) technically superior and (c) less weird ?
>
> I haven't read the drafts in detail, but I have read the LLMNR FAQ,
> expecting to find a biased account of the differences which would lead
> me to want to read the other side of the story.  But in nearly all of
> the cases, I found myself disagreeing with the LLMNR way of doing
> things, despite the best efforts of the text I was reading !
>
>
> > As long as they are Internet-Drafts they all have the same status, work
> > in progress, except that LLMNR has gained WG consensus.
>
>
> > From what I can see it might be more accurate to say that the DNSEXT
> WG has been captured by people who have a bee in their bonnet about
> killing mDNS, or who are at the very least badly misguided.
>
> Ian.
> (not usually a fan of people making wild-sounding statements about
>  IETF WG conspiracies, either!)
>
> [1] GNU adns, http://www.chiark.greenend.org.uk/~ian/adns/
>
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf