Keith Moore writes ("Re: Last Call: 'Linklocal Multicast Name Resolution (LLMNR)' to Proposed Standard"):
> The whole idea that local names should look like DNS names and be
> queried through the same APIs and user interfaces seems, well, wrong (or
> dubious at best), and needs serious study for the implications of
> applications using those APIs and the impact of such names on DNS, no?
No. Or at least, the point of having something like a link-local name
resolution protocol is that you can use the same interfaces to look up
the local names when using the link-local protocol, as you do when
looking up real DNS names when using the real DNS protocol. That way
all the existing applications work and don't need to be changed.
Otherwise you would be suggesting building an entirely new protocol
and application stack, with changes to every application to support
the link-local scheme, which is obviously out of the question.
So what you're saying is that you're opposed to whole concept of
link-local name resolution. And that therefore you favour LLMNR
because it doesn't (in your view) provide it ! Of course you are
wrong on this last point - LLMNR will be deployed behind the same APIs
currently used to do real DNS lookups.
I think that what you've done with your posting, really, is
demonstrate Stuart Cheshire's claim that LLMNR is for blocking effort !
> IMO, local names and a lookup service for local names would be extremely
> useful, but neither the names nor the query interface should look much
> like DNS - the names should look different because otherwise there's too
> much potential for confusion with DNS names, and the query service
> should look different because local name lookup service probably can't
> make the same kinds of consistency or stability assurances that DNS does.
To say that, is to say that work on LLMNR should never have been
started. There is no demand for a local name resolution protocol
which doesn't present a DNS API to applications.
You may well say that the whole concept of local name resolution, if
it must be presented to applications behind a DNS API, is a bad idea
and I have some sympathy with that view - but that's no argument for
LLMNR against mDNS !
Stuart seems to be claiming that the people who first told him to take
is mDNS away from the IETF, and LLMNR's authors, have that view - and
that LLMNR is the result of those people producing a protocol which is
intended to look enough like mDNS to fool people but is deliberately
_not_ intended to do any of the things that mDNS is good for !
Ian.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf