Re: [mdnsext] mDNSext features/requirements rollup

[James Andrewartha <[e-mail]>]

On 06/02/13 22:31, Andrew Sullivan wrote:
> 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.

Those are all very good points. Does the experience of Site Local
Addresses (RFC 3879) have any lessons here?

>> 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.

The primary reason this is being working on is Apple TVs. Read the
archives of EDUCAUSE that prompted the petition and forming of this
working group, it's all about streaming video from iPads to Apple TVs in
classrooms. And as has been established, Apple TV streaming doesn't work
with WA DNS-SD. If whatever new protocol extension or feature or
management tool we come up with isn't supported by Apple TVs, the whole
exercise has been pointless.

>> 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.

I'm happy to put a label on things and tell teachers to put that in, but
apparently Apple is not. I'm happy to do some administration and
management, people have been doing it with printers for years. Anyway, I
don't really care what the solution is, so long as it works for Apple
TVs. It's Apple you need to convince about the suitability of using DNS,
not me.

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. [phone]
Mob. [phone]