Re: [mdnsext] mDNSext features/requirements rollup

[Andrew Sullivan <[e-mail]>]

On Wed, Feb 06, 2013 at 10:04:41AM +0800, James Andrewartha wrote:

> useful client UI etc? Imagine having to reconfigure your DNS search
> domains when you change location - sure this can be handled by DHCP, but
> then you have to have lots of different scopes, which is another
> management tool problem.

But you have this problem _by definition_ with mDNS.  It's always
localy scoped.  Indeed, that's what people are complaining about.

It seems to me that, in Internet terms, we really have three scopes:

    1.  my network;
    2.  my network_s_;
    3.  the Internet.

In naming, historically we've treated case (2) as a special case of
(3), and sometimes added split-horizon or something to it.  What
people are really asking for now is to treat case (2) as a special
case of (1), and figure out how to make that work.

The problem I see is that, because of historical practice, attempting
to treat (2) as a special case of (1) will mean that names designed to
be local to (1) will leak into (3).  The evidence for this is the
effectiveness of split-views at keeping "private" names off the
Internet.  This is only going to get worse as ICANN expands the root
zone (note there's an application for .mail, just for instance).
Similarly, RFC1918 addresses have often turned out to be globally
problematic because of their local scope.

I think that leaking locally-scoped names onto the public Internet is
going to be a bad thing, and that's why I'm arguing that what is
really needed is a way to bring an actual global namespace to this.
 
> As for the server side of things, apparently some devices don't support
> registration in DNS [1].

Since we're attempting to make a new protocol, no matter what we do
some already deployed stuff isn't going to work with it perfectly.  If
what people want is a perfectly backward-compatible, do-what-I-mean
protocol that gives us all the new features we want for all the
existing stuff that works according to the previous protocol
specification, then I think we're going to be disappointed.

> My use case is Apple TVs in each classroom, which I'd like to limit
> geographically, both for ease of use (finding an entry is a list of 100
> is not fun) and to prevent accidents (streaming to the wrong device).

"And no administration."  We _had_ a solution for your use case as you
describe it: put things in the DNS, put a big label on the TV that has
the name of the device, and now you don't need to navigate drop-down
lists of 100s of devices.  But it means you need to manage the DNS,
and it probably means slightly different interface design both on the
iPad and the Apple TV.  I think I get why that's not desirable; I just
want us to be clear about what the challenge really is.

Best,

A

-- 
Andrew Sullivan
[e-mail]