Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03

Ralph Droms <> Sat, 02 April 2016 19:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4026412D17B for <>; Sat, 2 Apr 2016 12:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ktM9H4wzO9er for <>; Sat, 2 Apr 2016 12:38:17 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFBFE12D0DC for <>; Sat, 2 Apr 2016 12:38:17 -0700 (PDT)
Received: by with SMTP id c20so6078225pfc.1 for <>; Sat, 02 Apr 2016 12:38:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:message-id:references:to; bh=ZaDmEQCWrXV8y4Q5VchQaXQ/3aUK6lRbAgazy9wRzoo=; b=e/AEkpim5/zgZ8VdS94igFUn3kZz4kK9bcYApEQbzFD3fwO8r1p4pLVo2JWBopiQiu 2xN/8hCscL33ytRpoKkzatS4gWwT+Fu2QhgkeXsgIpQ4wQ7qr4VNg5SrjM8OCV5uA8+M 365hdWC321hidqh9w8VybihHOND+Lm7vz9b03a086VQKJHobLOySXIiQy/xmeEu5j4NL ncSJQ2Hg9RoYnCkEo2q7QKwWLYLXtwhTAM1pgq8sWx5Fc5MExMDjvmW6tGp3TRRZyBXR axi7YjtQAPSZs284NZ+3J4E5hF3XojzgLj82gautmBng4yaiYVrt8PpTYhTaLW7y5Ts0 jp3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :message-id:references:to; bh=ZaDmEQCWrXV8y4Q5VchQaXQ/3aUK6lRbAgazy9wRzoo=; b=JC+GMCyIFJ/1yhrc6SXoabjkf9iK3vst4LlrWKem51PsIOIdJ3kVt5wx+BrEgqvL89 f4bYORYdGApHEcnczJx0B8N1miiUUr4BzJy6QpR6sRMqRmRgken68h0Ky7L2YClZrIRC +qvpY3QfwkbsuTFvRnM/mMU4CosIpavFMIGa0Ob4X5yArjUdXctKPooX8SFAfFcZf2yH tWmQhGW4awN4inVlNq9oTND9YP2CR4xkSsBYa2ZQnUkVILdcMP+JtHr6Jz5TNAtA8sBW /Jau2cbLFDxmPvzZfogzJigBt/Q6TcaZlkT3zcF98qd9hdDhNwaODaZqkDAGrWY48/mb P+tQ==
X-Gm-Message-State: AD7BkJIAbJx5zAe8mmWJpwOFfEiODhHBywUxWeQIiLBOeeyOQcGC327r6o4E5dUu39+lxQ==
X-Received: by with SMTP id z71mr8280862pfi.30.1459625897409; Sat, 02 Apr 2016 12:38:17 -0700 (PDT)
Received: from ([]) by with ESMTPSA id to9sm30800635pab.27.2016. for <> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 02 Apr 2016 12:38:16 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_C8523650-0FCF-42C3-B34B-53FCFEF24643"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Pgp-Agent: GPGMail 2.6b2
From: Ralph Droms <>
In-Reply-To: <EMEW3|b98542dd0b73f37521687ff14683dda6s2GMb103tjc||>
Date: Sat, 2 Apr 2016 16:38:11 -0300
Message-Id: <>
References: <> <EMEW3|b98542dd0b73f37521687ff14683dda6s2GMb103tjc||>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03
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: Sat, 02 Apr 2016 19:38:20 -0000

I have a technical issue with draft-ietf-dnssd-hybrid-03 that, in my opinion, requires come clarification.

Section 4.3 describes how a Hybrid Proxy processes a received Unicast DNS query.  I understand, in principle, that the Hybrid Proxy consults its local mDNS cache to construct a response to the Unicast DNS Query.  The last paragraph begins with:

   Naturally, the existing Multicast DNS caching mechanism is used to
   avoid issuing unnecessary Multicast DNS queries on the wire.

I've re-read section 5.2 of RFC 6762, "Multicast DNS".  Based on section 5.2 of RFC 6762 and section 4.3 of draft-ietf-dnssd-hybrid-03, I would not be able to justify the specific ways in which the Hybrid Proxy cache is used and any requirements for the Hybrid Proxy to issue an mDNS query to refresh its cache.  That is, I can't determine if the Hybrid Proxy always issues an mDNS query based on a received Unicast DNS query to initially populate its cache, or if the Hybrid Proxy can construct its response based solely on its cache in some circumstances, or there is some other behavior.

- Ralph

> On Mar 17, 2016, at 7:36 PM 3/17/16, Tim Chown < <>> wrote:
> Dear dnssd WG participants,
> We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as can be found at <>.
> The call runs for two weeks, and will thus close on Thursday 31st March.
> Please send any comments (including indications of support for progression of the document as is) to the <> list. This draft will not be advanced for publication unless there is sufficient response and support from the WG.  And, of course, any substantive comments on the draft are strongly encouraged as well. We are aware of a small number of minor outstanding comments from the list, but will consider these as part of the WGLC process.
> We will discuss the comments arising from the WGLC in the WG meeting in BA on Monday 4th April.
> Abstract
>    Performing DNS-Based Service Discovery using purely link-local
>    Multicast DNS enables discovery of services that are on the local
>    link, but not (without some kind of proxy or similar special support)
>    discovery of services that are outside the local link.  Using a very
>    large local link with thousands of hosts facilitates service
>    discovery, but at the cost of large amounts of multicast traffic.
>    Performing DNS-Based Service Discovery using purely Unicast DNS is
>    more efficient and doesn't require excessively large multicast
>    domains, but requires that the relevant data be available in the
>    Unicast DNS namespace.  This can be achieved by manual DNS
>    configuration (as has been done for many years at IETF meetings to
>    advertise the IETF Terminal Room printer) but this is labor
>    intensive, error prone, and requires a reasonable degree of DNS
>    expertise.  The Unicast DNS namespace can be populated with the
>    required data automatically by the devices themselves, but that
>    requires configuration of DNS Update keys on the devices offering the
>    services, which has proven onerous and impractical for simple devices
>    like printers and network cameras.
>    Hence, to facilitate efficient and reliable DNS-Based Service
>    Discovery, a compromise is needed that combines the ease-of-use of
>    Multicast DNS with the efficiency and scalability of Unicast DNS.
> Thanks,
> Ralph and Tim
> dnssd WG co-chairs
> _______________________________________________
> dnssd mailing list
> <>