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

Tim Chown <tjc@ecs.soton.ac.uk> Sat, 02 April 2016 12:25 UTC

Return-Path: <tjc@ecs.soton.ac.uk>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B5512D77C for <dnssd@ietfa.amsl.com>; Sat, 2 Apr 2016 05:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.23
X-Spam-Level:
X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecs.soton.ac.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjwlXgwrFecn for <dnssd@ietfa.amsl.com>; Sat, 2 Apr 2016 05:25:22 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E35A812D573 for <dnssd@ietf.org>; Sat, 2 Apr 2016 05:25:21 -0700 (PDT)
Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32CPG25010529 for <dnssd@ietf.org>; Sat, 2 Apr 2016 13:25:16 +0100
X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk u32CPG25010529
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1459599916; bh=XXl6RKiE7ymg7jRZjVRwy5N+qTI=; h=From:Mime-Version:Subject:Date:References:To:In-Reply-To; b=uC//6P/EFR1O9R33ekabUivl5eSuoWMXPjkJ80gcZdG85fUeIkTzZGVqOnGQi7Pp4 ZE3zUBm9G2AQSIu06WlnL49OLRRswJioXe90RbxD4RvGPambnkU5ci2zPuGpdLlDya E9KP8YJbys1W58GUKczUUO/ThkMhURxokszNMxOA=
Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from <tjc@ecs.soton.ac.uk> with ESMTP (valid=N/A) id s31DPG1913606098Of ret-id none; Sat, 02 Apr 2016 13:25:16 +0100
Received: from 20010a88d51011.ipv6.customer.clara.net (20010a88d51011.ipv6.customer.clara.net [IPv6:2001:a88:d510:1101:3506:f7:9c76:f8] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id u32COr0Z022688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <dnssd@ietf.org>; Sat, 2 Apr 2016 13:25:09 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_EC6A401F-C51A-4C2C-9AAC-78B56631E550"
Message-ID: <EMEW3|643e957a1f3f46c77510cdcca47548f2s31DPG03tjc|ecs.soton.ac.uk|BB679B6D-6F79-4E40-ACA5-B37628A465D6@ecs.soton.ac.uk>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Date: Sat, 2 Apr 2016 13:25:09 +0100
References: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk> <BB679B6D-6F79-4E40-ACA5-B37628A465D6@ecs.soton.ac.uk>
To: dnssd@ietf.org
In-Reply-To: <7274B55E-8A4D-4BEE-85F9-C19EC62EEF03@ecs.soton.ac.uk>
X-Mailer: Apple Mail (2.3112)
X-ECS-MailScanner: Found to be clean, Found to be clean
X-smtpf-Report: sid=s31DPG191360609800; tid=s31DPG1913606098Of; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner-ID: u32CPG25010529
X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnssd/iEgRx1k6hwxeAh00Os4Dmz4Twog>
Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Apr 2016 12:25:24 -0000

Hi,

Ralph and I will take further comments to the list in advance of the dnssd meeting on Monday.

Comments of the form ‘this is ready to ship’ are also very useful.

Tim


> On 17 Mar 2016, at 22:36, Tim Chown <tjc@ecs.soton.ac.uk> wrote:
> 
> Dear dnssd WG participants,
> 
> We are initiating a WG Last Call today on draft-ietf-dnssd-hybrid-03, as can be found at https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03 <https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-03>.
> 
> 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 dnssd@ietf.org <mailto:dnssd@ietf.org> 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
> 
> 
> 
>