Re: [mdnsext] Discussion of BoF during Berlin IETF

Michael Richardson <> Wed, 05 June 2013 13:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 08A2321F9B14 for <>; Wed, 5 Jun 2013 06:43:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1QlzMZSuFGj0 for <>; Wed, 5 Jun 2013 06:43:40 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3::184]) by (Postfix) with ESMTP id 057F221F9AFE for <>; Wed, 5 Jun 2013 06:43:40 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 904992017F; Wed, 5 Jun 2013 09:56:34 -0400 (EDT)
Received: by (Postfix, from userid 179) id E686B63A8C; Wed, 5 Jun 2013 09:42:48 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id D53BE63A5E; Wed, 5 Jun 2013 09:42:48 -0400 (EDT)
From: Michael Richardson <>
To: "Albrecht, Harald" <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22)
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Wed, 05 Jun 2013 09:42:48 -0400
Message-ID: <>
Cc: "" <>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Jun 2013 13:43:41 -0000

>>>>> "Albrecht," == Albrecht, Harald <> writes:
    >> -----Urspr√ľngliche Nachricht-----
    >> Von: [] Im
    >> Auftrag von Michael Richardson
    >> Gesendet: Dienstag, 4. Juni 2013 15:46
    >> An:
    >> Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF

    >> I think that they are very different, and I think that we need to leave the
    >> door open to that commercial enterprise networks might be ruled out of
    >> bounds for mDNS.  That is, it might be that all that we wind up with is a way
    >> to signal that mDNS is *not* to be used on a particular
    >> network.   I do not believe that we have many operators of such networks
    >> at IETF meetings to represent their point of view.  (I think about the
    >> operators of the government networks near me... they have many
    >> conflicting requirements, but few clues as to how to put them together)

    Albrecht> My understanding of the ongoing discussion so far is, that
    Albrecht> the charter is not focusing solely on mDNS as the
    Albrecht> underlying technology only, but with a somewhat broader
    Albrecht> scope of service discovery; thus, also including DNS for
    Albrecht> those scenarios (use cases) where an IT infrastructure is
    Albrecht> present. At least to some extent. My impression was that
    Albrecht> the (pending?) renaming of the upcoming WG reflects this
    Albrecht> situation. Or did I misunderstand this? 

Yes, it's true that going to infrastructure DNS is useful.

But, that doesn't prevent or clearly signal, that mDNS may be
*unwelcome* on a particular network.   Enterprise folks might want to do
that. I'm not claiming that they will, or should, succeed, btw.  I'm
pointing out that we don't know what they want, because they don't tend
to participate.

    >> It's not that mDNS and global
    >> DNS *services* or even protocols have difficulties co-existing.  They do
    >> that just fine.   It is a question of them *interacting*.  The place
    >> where they interact is on the *host*.

    Albrecht> How true, that's where the devil is in the details. mDNS
    Albrecht> uses UTF-8 encoding on the wire and DNS uses (at least for
    Albrecht> host domain names) ASCII/IDNA-2008. Throw in different
    Albrecht> resolver libs and IDNA support and you are ready for an
    Albrecht> instant recipe disaster. 

It might be that some vendor find they have to greenfield things.
My preference would be to stub out the libc stub resolver, and force all
resolution to (::1), and do all the rest.  That's already the
case for some systems, but it has failed to become an architectural norm.

]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]        |   ruby on rails    [