Re: [mdnsext] Discussion of BoF during Berlin IETF

Michael Richardson <> Tue, 04 June 2013 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81FAB21F9B56 for <>; Tue, 4 Jun 2013 08:45:57 -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 4O-1fmpCf2uz for <>; Tue, 4 Jun 2013 08:45:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5B38121F8FB3 for <>; Tue, 4 Jun 2013 06:46:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2166820171 for <>; Tue, 4 Jun 2013 09:59:46 -0400 (EDT)
Received: by (Postfix, from userid 179) id 411E463A8C; Tue, 4 Jun 2013 09:45:31 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id 2F31663A5E for <>; Tue, 4 Jun 2013 09:45:31 -0400 (EDT)
From: Michael Richardson <>
To: "" <>
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: Tue, 04 Jun 2013 09:45:31 -0400
Message-ID: <>
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: Tue, 04 Jun 2013 15:45:57 -0000

{I have no travel budget to be in Berlin}

I think that the BOF proposal is very sane and very well thought out.
I question the need for a BOF at this point. I think our set of
requirements and goals is very well understood: I think that there is
enough material there to charter a WG already. 

I am pleased that the commercial enterprise networks and the
R&E campus network scenarios are broken out.  To repeat:

    a) Commercial enterprise networks ("Fortune500")
    b) Academic/educational/university campus networks (R&E)
    c) Multi-link home networks, such as those envisaged by the
       HOMENET WG 
    d) Multi-link/single subnet (mesh) networks, such as those
       described by the ZigBee Alliance Z-IP specification (LLN/LWIG)

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)

I am unconvinced that (c)HOMENET and (d)LLNs are in the same problem
space, but I also have no evidence that they aren't.  I think that there
is a scaling of complexity problem that we need to deal with here.

I am very much sure that (a)Fortune500 and (b)R&E do not share very much
in common with (c)/(d), except that the things being plugged into these
networks are from the same vendors, and that some of the devices that get
plugged in tend to travel among all these various places.

I think that 

   3. To develop a BCP for the coexistence of zeroconf (mDNS) and
   unicast (global DNS) name services in such multi-link networks, which
   should include consideration of both the name resolution mechanism
   and the namespace.

may be incomplete or even mis-guided.   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*.

We are not writing a network protocol!
We are creating a clear state machine that a host implements that takes
inputs ("replies"/"responses") from existing network protocols and acts
in deterministic and user-useful ways.

Our documents should not have time-sequence diagrams in it, assuming
that we are god and can control the other hosts.  Rather, it should have
inputs and state changes for a host, and yes, even messages to users
and/or applications about what is available.

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