Re: [dnssd] draft-sullivan-dnssd-mdns-dns-interop-00

[Andrew Sullivan <[e-mail]>]

Hi Doug,

On Wed, Jan 29, 2014 at 06:44:39PM -0800, Douglas Otis wrote:
> Please forgive my awkward summary of what I understood you to be proposing. 

If there's anyone to apologise, it's obviously me, since I've made
such a hash of making my meaning clear.

> On Jan 28, 2014, at 10:27 PM, Andrew Sullivan <[e-mail]> wrote:
> 
> The goal is to facilitate access to mDNS gateways or proxies for
> access to services likely publishing non-global addresses in mDNS
> which do not permit direct Internet access and are not on a common
> network bridge.  Profoundly not the same as transparently resolving
> global services which you seem to suggest.

I don't think that's right.  Here's what the charter says:

  The focus of the WG is to develop a solution for extended, scalable
  DNS-SD.  This work is likely to highlight problems and challenges with
  naming protocols, as some level of coexistence will be required between
  local zero configuration name services and those forming part of the
  global DNS.

That seems to me to suggest that we have to cope with service
discovery in a global context.  These are, clearly, not necessarily
global services, but I wasn't trying to suggest that.

> Read section 1.1 of RFC5895.  There are few protocol checks on
> U-Labels. 

So what?  We're developing protocol here, and _we_ need to be clear.
There is a perfectly good definition of U-label in RFC 5890, section
2.3.2.1.  Importantly, that section specifically says that a thing
that might be a U-label but that hasn't been determined yet.  We
sometimes call these "putative U-labels" or something of that sort.
It's really important in this conversation to be clear about this
distinction, however, or we'll never get clear on what we're talking
about.

> depending on geographic or cultural factors.  As such, it does not
> offer fixed translations between user input in UTF-8 form and
> A-labels.  

Of course not.  Not all user input is in fact a U-label.  For
instance, depending on your operating system, your user input may not
be UTF-8 in NFC.  And that barely gets us started.  That's why we have
the definition of U-label we have.

Yes, this imposes all kinds of stuff on clients, and no, it is not
reasonable to expect that everyone will do this correctly.  That's why
IDNA suggests so strongly that different layers each need to do their
own validation.
 
> The suggestion was to recommend an implied ".local." be positioned
> first in a domain search list when fewer than 3 labels are entered
> when applications make use of search domain lists.  This would mean
> for users not entering FQDNs they might experience a 3 second delay
> with the benefit of better protecting the Internet and the user
> alike.

Why do you think that the right level is fewer than 3 labels?  It
seems to me that you're depending in that case on a view about what's
"probably actually DNS" and "probably not" that is at least dodgy in
the current ICANN policies.
 
> room.  Have been unable to find evidence DNS-SD had been implemented
> by the IETF within DNS, although the charter did mention its use.

Stuart Cheshire has used this repeatedly as an example for DNS-SD, so
I encourage you to look through minutes of past meetings.  He also has
said repeatedly that Apple uses it this way.  

> It seems highly doubtful most organizations will want selectively configured local services exposed to the Internet, unlike the IETF.

Who says they're exposed to the Internet?  First, publishing something
in the DNS hardly means that the service is available.  Second, split
horizons are, despite the IETF's lalalala-i-can't-hear-you act, a reality.

Regards,

A

-- 
Andrew Sullivan
[e-mail]