Re: [mdnsext] Discussion of BoF during Berlin IETF

[Kerry Lynn <[e-mail]>]

On Tue, Jun 11, 2013 at 1:31 PM, Michael Richardson
<[e-mail]>wrote:

>
> >>>>> "David" == David Farmer <[e-mail]> writes:
>     David> If you are saying the only solution a network operator has to
> controlling
>     David> current mDNS traffic is black-holing it; Then we have to make
> what ever the
>     David> new solution is work in the presence of black-holing of
>     David> current mDNS traffic,
>     David> including both registration and query of services.  One of
>     David> the use case
>
> What David said +5.
>
> Kerry, many **enterprises** do *not* have any mDNS traffic, because they
> won't let any non-IT person plug ANYTHING in.
>
> How does an IT person disable intrinsic mDNS probing/announcing/responding
behavior in a commercial printer?  I guess those same enterprises also ban
OS X
entirely?

It seems to me that to carry this conversation forward we need to a) define
sdnssd requirements for Enterprise, which I think we've already hinted we're
not well qualified to do, and b) rank those requirements against those of
homenet and higher ed, which we arguably know much better.

I just may have gotten off on the wrong foot with this discussion,
misunderstanding
the original point.  If it was that enterprise customers do not like
excessive link-
local multicast, then I agree that one major objective of this work is to
decrease
reliance on it by e.g. introducing name caches and client libraries that
unicast
queries to them when possible.  We can't eliminate all link-local
multicasting in
general, or a number of things stop working.


> Those enterprises/IT-divisions are either gonna change (and we can help
> them),
> or they will go the way of the mainframe operators.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails
>    [
>
>