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

Tom Pusateri <> Sat, 02 April 2016 20:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 589A812D593 for <>; Sat, 2 Apr 2016 13:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8ENuqU38yPhR for <>; Sat, 2 Apr 2016 13:22:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E4CA12D55A for <>; Sat, 2 Apr 2016 13:22:35 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 61BB51DD58; Sat, 2 Apr 2016 16:21:02 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A23E6058-841D-4D76-A99E-F177EE044E55"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Tom Pusateri <>
In-Reply-To: <>
Date: Sat, 2 Apr 2016 17:22:30 -0300
Message-Id: <>
References: <> <EMEW3|b98542dd0b73f37521687ff14683dda6s2GMb103tjc||> <>
To: Ralph Droms <>
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 20:22:37 -0000

I think this is answered in the details of section 4.6 Answer Aggregation and it depends on if a subscription exists or not.


> On Apr 2, 2016, at 4:38 PM, Ralph Droms <> wrote:
> 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
>> <>
>> <>
> _______________________________________________
> dnssd mailing list