Re: [mdnsext] Discussion of BoF during Berlin IETF

Kerry Lynn <kerlyn@ieee.org> Tue, 11 June 2013 19:39 UTC

Return-Path: <kerlyn2001@gmail.com>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A90821F99B3 for <mdnsext@ietfa.amsl.com>; Tue, 11 Jun 2013 12:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.729
X-Spam-Level:
X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDLfefw6A-as for <mdnsext@ietfa.amsl.com>; Tue, 11 Jun 2013 12:39:54 -0700 (PDT)
Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1528321F99AE for <mdnsext@ietf.org>; Tue, 11 Jun 2013 12:39:54 -0700 (PDT)
Received: by mail-oa0-f53.google.com with SMTP id k18so3577851oag.12 for <mdnsext@ietf.org>; Tue, 11 Jun 2013 12:39:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1BTzxl6Kwa/l5uFqOcPLYJ3sUB/VZQyb9qSsOUFXBMI=; b=n/T9Mf1v58k0nphNFq1PiHnp4sJDX7g2et4mh34XOcNZ8sNpbPDvlbbNNexbdrF0wD cXwb/HE0z+KcDxIBi50DfLeYCSvNDYvipnzBaOxYrDH0vG7d38cqVhFPgoka4umYIHpA sv+CFvSr4YBWyYyBbilB4KbT0CfO+QAV2GMAr+hhpw3Z+zh55eeszlBgPUocj/32pTxK HTy9p3X5pSCr4BzuC7KI6bbsD2JEMTgWd1JnJRS+2m+I/xpK2AuV/UWVVMAkiFvsj2kN 7p4rIYTh5DvXiumKZqUX9Me5CWZNRkwFXJH1YWtYndv0cZcKsh55HEd1a95Id0DBxaSy FNNw==
MIME-Version: 1.0
X-Received: by 10.60.164.70 with SMTP id yo6mr13451775oeb.78.1370979593578; Tue, 11 Jun 2013 12:39:53 -0700 (PDT)
Sender: kerlyn2001@gmail.com
Received: by 10.60.148.197 with HTTP; Tue, 11 Jun 2013 12:39:53 -0700 (PDT)
In-Reply-To: <13345.1370971891@sandelman.ca>
References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <E36F274013087B4EA05E08EB5037503901820D@DEFTHW99EK5MSX.ww902.siemens.net> <22635.1370439768@sandelman.ca> <51B63B07.5070802@umn.edu> <19621.1370909460@sandelman.ca> <CABOxzu3JYjpiVxP8Bv5bw-SHmOzW07KfoagWpyv2MfCYxg2wOw@mail.gmail.com> <51B71517.4080700@umn.edu> <13345.1370971891@sandelman.ca>
Date: Tue, 11 Jun 2013 15:39:53 -0400
X-Google-Sender-Auth: KkPB-cEdZMQ7okklEp4smcSzDUI
Message-ID: <CABOxzu3hkjXgr5p8MLMtgjoy=zpjFP8OwCP=_KybwegDzdKczA@mail.gmail.com>
From: Kerry Lynn <kerlyn@ieee.org>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Content-Type: multipart/alternative; boundary=047d7b3a7f84abb9fe04dee60f41
Cc: David Farmer <farmer@umn.edu>, "mdnsext@ietf.org" <mdnsext@ietf.org>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Jun 2013 19:39:55 -0000

On Tue, Jun 11, 2013 at 1:31 PM, Michael Richardson
<mcr+ietf@sandelman.ca>wrote;wrote:

>
> >>>>> "David" == David Farmer <farmer@umn.edu> 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  [
> ]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails
>    [
>
>