Re: [mdnsext] mDNSext features/requirements rollup

On Mon, Jan 28, 2013 at 12:34 PM, Andrew Sullivan <ajs@anvilwalrusden.com>wrote:

> On Mon, Jan 28, 2013 at 11:51:02AM -0500, RJ Atkinson wrote:
>
> > Some of us would like to see mDNS support multiple IP subnets
> > (e.g. multiple buildings, multiple groups, multiple (V)LANs)
> > within a single administrative domain (e.g. university campus,
> > corporate campus).
> >
> >   This implies having a straight-forward way to configure
> >   networking devices (e.g. firewalls, routers) at the edge
> >   of one's administrative domain to exclude certain interfaces
> >   (e.g. exterior uplink interfaces) from all mDNS traffic
> >   of the administrative domain using mDNS.
>
> I still do not understand why this sort of thing isn't better handled
> by vastly improved tools for real DNS management.

I think one of the fundamental problems is, that by merely existing,
mDNS has created two namespaces, where the link-local (yes/no)
is the only identifying attribute for which namespace applies.

Also, creating/improving tools, in general, has certain risks, unless
improving things from implict -> explicit (mDNS vs DNS namespace) is done
first.

The risks I see (in exclusively working on tools) are:
- open/standardized tools vs proprietary
- scope creep
- scaling problems (in terms of development resources)
- work done by those who do not fully understand DNS protocols
- work done by those who do not fully understand DNS namespaces
- work done by idiots
- work supported by vendors who have history of horrible implementations
- tools in one space breaking things in another space (creating a Hobsons'
choice for users)
- users
- firmware
- longevity of deployed hardware/firmware/software

>  It seems to me that
> people are asking for a single, unifed namespace outside the
> link-local context, and we invented a mechanism for that many years
> ago.  The problem is that the support tools for that mechanism sort of
> suck.  Instead of inventing a new protocol which, by definition, is
> going to run into conflicts with the existing protocols in this space,
> why wouldn't it be better to take that energy and expend it on the
> missing tools?
>

Just to be clear, which mechanism is that to which you refer?

Brian

>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
> _______________________________________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext
>