Re: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02

Andrew Sullivan <> Sun, 03 April 2016 01:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8017F12D12F for <>; Sat, 2 Apr 2016 18:02:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I_l724Rt0ufy for <>; Sat, 2 Apr 2016 18:02:53 -0700 (PDT)
Received: from ( [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by (Postfix) with ESMTP id 7AB6712D11A for <>; Sat, 2 Apr 2016 18:02:53 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1013D10B0A for <>; Sun, 3 Apr 2016 01:02:53 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kit4_QqscsJm for <>; Sun, 3 Apr 2016 01:02:52 +0000 (UTC)
Received: from (unknown [IPv6:2001:67c:370:136:7808:fd57:2be5:760f]) by (Postfix) with ESMTPSA id D374D10AE8 for <>; Sun, 3 Apr 2016 01:02:51 +0000 (UTC)
Date: Sat, 2 Apr 2016 21:02:46 -0400
From: Andrew Sullivan <>
Message-ID: <>
References: <> <> <EMEW3|7e690cd33b6c76dcc010b72a8c2a5c1cs31DP503tjc||> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02
X-Mailman-Version: 2.1.17
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: Sun, 03 Apr 2016 01:02:55 -0000


First, thanks very much for the review.

[ObIHopeObvious: I elided things I just think are good.  Thanks for them.]

On Sat, Apr 02, 2016 at 11:44:51PM +0000, Dave Thaler wrote:

> > If DNS-SD is
> > to be used in an environment where multiple resolution systems (such
> > as mDNS and DNS) are to be queried for services, then some parts of
> > the domain names to be queried will need to be compatible with the
> > rules and conventions for all  the relevant technologies.
> I don’t follow.   The point of RFC 6055 is that the encoding should be
> handled by the name resolution provider (mapping to DNS or to mDNS
> or hosts file or whatever else) not by the application.   So which layer
> is this talking about?

I think I don't follow.  The point is that, when someone is offering
services across multiple resolution contexts, there are multiple
resolition systems.  There's actually no way for the name resolution
provider to provide the solution here, because it's impossible to know
in advance which kind of provision is likely to happen.  

Hmm.  I suppose the point is made clearer if the draft says something
like, "If you are sure that nothing will go past some context -- where
that context is either the LAN, or the site-network however defined --
then local conventions prevail.  Otherwise, parts of the domain names
to be queried … &c."  Is that clearer?

> Section 4.1:
> > The first way would be to treat this portion as likely to be
> >   intercepted by system-wide IDNA-aware resolvers ,
> What do you mean by "system-wide IDNA-aware resolver" here?
> One unaware of which protocol will be used to resolve and in which naming context?
> Clarify.

> >   Instead, DNS-SD implementations can intercept the <Instance> portion
> >   of a Service Instance Name and ensure that those labels are never
> >   handed to IDNA-aware resolvers that might attempt to convert these
> >   labels into A-labels .  
> Either I’m confused (which is certainly possible, but would then imply the document
> could be better worded for dummies), or neither approach in this document is
> consistent with RFC 6055 recommendations.

Stuart has asserted strogly -- and I confess I have some sympathy for
his claim -- that all the use cases involve pick-lists.  If that's
true, then the "first way" is never going to happen, and the "second
way" is the only real option.  And you're right that neither is
actually consistent with 6055.

> should all do the correct transformation.   But RFC 6055 just recommends that it be done by 
> some layer that knows both the protocol & the naming context, which could be the protocol layer
> or could be the naming API layer, but to me having to change the naming API layer to be protocol-aware
> seems architecturally bad.   So I think the confusing is perhaps around the term 
> “DNS-SD implementations” which could use some elaboration, or at least rewording for consistency
> with RFC 6055.

I wish I knew what the WG wanted here.  I'm way more than amenable to text.


Andrew Sullivan