Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)

manning bill <> Thu, 03 October 2013 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98BD621F9AA1; Thu, 3 Oct 2013 12:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pqv-IN-fuCsB; Thu, 3 Oct 2013 12:19:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9B6C321F9C7B; Thu, 3 Oct 2013 12:07:05 -0700 (PDT)
Received: from [] ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id r93J5pq2012326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Oct 2013 12:05:51 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=windows-1252
From: manning bill <>
In-Reply-To: <EMEW3|db89e71161b3bb8f7117f7d83e2ef53ep92JhU03tjc||>
Date: Thu, 3 Oct 2013 12:05:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <EMEW3|db89e71161b3bb8f7117f7d83e2ef53ep92JhU03tjc||>
To: Tim Chown <>
X-Mailer: Apple Mail (2.1283)
X-ISI-4-43-8-MailScanner: Found to be clean
X-Mailman-Approved-At: Sun, 06 Oct 2013 19:21:27 -0700
Cc: " mdnsext" <>, Lemon Ted <>, "<> Discussion" <>, IETF-Announce <>, Ralph Droms <>
Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
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: Thu, 03 Oct 2013 19:20:08 -0000

but the "To Subscribe" pointer is busted….


On 3October2013Thursday, at 11:43, Tim Chown wrote:

> On 3 Oct 2013, at 18:07, manning bill <> wrote:
>>  ----- The following addresses had permanent fatal errors -----
>> <>
>>   (reason: 550 5.1.1 <>rg>: Recipient address rejected: User unknown in virtual alias table)
> I think the active list is still
> See:
> And the 'header' information below should now probably read something like this:
> --- snip ---
> Scalable DNS Service Discovery  (dnssd)
> ------------------------------------------------
> Current Status: Proposed WG
> Chairs:
>  Ralph Droms <>
>  Tim Chown <>
> Assigned Area Director:
>  Ted Lemon <>
> Mailing list
>  Address:
>  To Subscribe:
>  Archive:
>  Pre-WG BoF Archive: 
> --- snip ---
> Tim
>> On 3October2013Thursday, at 8:42, The IESG wrote:
>>> A new IETF working group has been proposed in the Internet Area. The IESG
>>> has not made any determination yet. The following draft charter was
>>> submitted, and is provided for informational purposes only. Please send
>>> your comments to the IESG mailing list (iesg at by 2013-10-10.
>>> Extensions for Scalable DNS Service Discovery  (dnssd)
>>> ------------------------------------------------
>>> Current Status: Proposed WG
>>> Chairs:
>>> Ralph Droms <>
>>> Tim Chown <>
>>> Assigned Area Director:
>>> Ted Lemon <>
>>> Mailing list
>>> Address:
>>> To Subscribe:
>>> Archive:
>>> Charter:
>>> Background
>>> ----------
>>> Zero configuration networking protocols are currently well suited to
>>> discover services within the scope of a single link.  In particular,
>>> the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes
>>> referred to using Apple Computer Inc.'s trademark, Bonjour) are
>>> widely used for DNS-based service discovery and host name resolution
>>> on a single link.
>>> The DNS-SD/mDNS protocol suite is used in many scenarios including
>>> home, campus, and enterprise networks.  However, the zero configuration
>>> mDNS protocol is constrained to link-local multicast scope by design,
>>> and therefore cannot be used to discover services on remote links.
>>> In a home network that consists of a single (possibly bridged) link,
>>> users experience the expected discovery behavior; available services
>>> appear because all devices share a common link.  However, in multi-link
>>> home networks (as envisaged by the homenet WG) or in routed campus or
>>> enterprise networks, devices and users can only discover services on
>>> the same link, which is a significant limitation.  This has led to
>>> calls, such as the Educause petition, to develop an appropriate service
>>> discovery solution to span multiple links or to perform discovery across
>>> a wide area, not necessarily on directly connected links.
>>> In addition, the "Smart Energy Profile 2 Application Protocol Standard",
>>> published by ZigBee Alliance and HomePlug Powerline Alliance specifies
>>> the DNS-SD/mDNS protocol suite as the basis for its method of zero
>>> configuration service discovery.  However, its use of wireless mesh
>>> multi-link subnets in conjunction with traditional routed networks will
>>> require extensions to the DNS-SD/mDNS protocols to allow operation
>>> across multiple links.
>>> The scenarios in which multi-link service discovery is required may
>>> be zero configuration environments, environments where administrative
>>> configuration is supported, or a mixture of the two.
>>> As demand for service discovery across wider area routed networks
>>> grows, some vendors are beginning to ship proprietary solutions.  It
>>> is thus both timely and important that efforts to develop improved, 
>>> scalable, autonomous service discovery solutions for routed networks 
>>> are coordinated towards producing a single, standards-based solution.
>>> The WG will consider the tradeoffs between reusing/extending existing
>>> protocols and developing entirely new ones.  It is highly desirable
>>> that any new solution is backwardly compatible with existing DNS-SD/mDNS
>>> deployments.  Any solution developed by the dnssd WG must not conflict
>>> or interfere with the operation of other zero-configuration service and
>>> naming protocols such as uPnP or LLMNR.  Integration with such protocols
>>> is out of scope for this WG.
>>> The focus of the WG is to develop a solution for extended, scalable 
>>> DNS-SD.  This work is likely to highlight problems and challenges with 
>>> naming protocols, as some level of coexistence will be required between 
>>> local zero configuration name services and those forming part of the 
>>> global DNS.  It is important that these issues are captured and 
>>> documented for further analysis; solving those problems is however not 
>>> within the scope of this WG.
>>> Working Group Description
>>> -------------------------
>>> To that end, the primary goals of the dnssd WG are as follows:
>>> 1. To document a set of requirements for scalable, autonomous
>>>  DNS-based service discovery in routed, multi-link networks in the
>>>  following five scenarios:
>>>  (A) Personal Area networks, e.g., one laptop and one printer.
>>>      This is the simplest example of a service discovery network,
>>>      and may or may not have external connectivity. 
>>>  (B) Home networks, as envisaged by the homenet WG, consisting of 
>>>      one or more exit routers, with one or more upstream providers 
>>>      or networks, and an arbitrary internal topology with 
>>>      heterogeneous media where routing is automatically configured. 
>>>      The home network would typically be a single zero configuration 
>>>      administrative domain with a relatively limited number of 
>>>      devices. 
>>>  (C) Wireless 'hotspot' networks, which may include wireless networks
>>>      made available in public places, or temporary or permanent
>>>      infrastructures targeted towards meeting or conference style
>>>      events, e.g., as provided for IETF meetings.  In such
>>>      environments other devices may be more likely to be 'hostile'
>>>      to the user.
>>>  (D) Enterprise networks, consisting of larger routed networks, 
>>>      with large numbers of devices, which may be deployments 
>>>      spanning over multiple sites with multiple upstreams, and
>>>      one more more administrative domains (depending on internal
>>>      administrative delegation).  The large majority of the 
>>>      forwarding and security devices are configured.  These may
>>>      be commercial or academic networks, with differing levels 
>>>      of administrative control over certain devices on the network,
>>>      and BYOD devices commonplace in the campus scenario.
>>>  (E) Mesh networks such as RPL/6LoWPAN, with one or more links per
>>>      routable prefix, which may or may not have external connectivity.
>>>      The topology may use technologies including 802.11 wireless, 
>>>      HomePlug AV and GP, and ZigBee IP. 
>>>  In the above scenarios, the aim is to facilitate service discovery 
>>>  across the defined site.  It is also desirable that a user or device, 
>>>  when away from such a site, is still able to discover services 
>>>  within that site, e.g. a user discovering services in their home 
>>>  network while remote from it.
>>>  It is also desirable that multiple discovery scopes are supported,
>>>  from the point of view of announcements and discovery, be the
>>>  scope 'site', 'building', or 'room'.  A user for example may only
>>>  be interested in devices in the same room.
>>> 2. To develop an improved, scalable solution for service discovery 
>>>  that can operate in multi-link networks, where devices may be
>>>  in neighboring or non-neighboring links, applicable to
>>>  the scenarios above.  The solution will consider tradeoffs between
>>>  reusing/extending existing protocols and developing entirely new
>>>  protocols. 
>>>  The solution should include documentation or definition of the
>>>  interfaces that can be implemented, separately to transport of 
>>>  the information.
>>> 3. To document challenges and problems encountered in the coexistence 
>>>  of zero configuration and global DNS name services in such 
>>>  multi-link networks, including consideration of both the name 
>>>  resolution mechanism and the namespace.
>>> It is important that the dnssd WG takes input from stakeholders in
>>> the scenarios it is considering.  For example, the homenet WG is
>>> currently evaluating its own requirements for naming and service
>>> discovery; it is up to the homenet WG as to whether it wishes to
>>> recommend adoption of the solution developed in the dnssd WG, but
>>> coordination between the WGs is desirable.
>>> Deliverables:
>>> The WG will produce three documents: an Informational RFC on the
>>> requirements for service discovery protocols operating on potentially
>>> non-neighboring multi-link networks as described above; a Standards
>>> Track RFC documenting an extended, scalable service discovery solution 
>>> that is applicable to those scenarios; and an Informational RFC 
>>> describing the problems arising when developing the extended SD solution 
>>> and how it affects the integration of local zero configuration and global
>>> DNS name services.
>>> Milestones:
>>> Sep 2013 - Formation of the WG
>>> Oct 2013 - Adopt requirements draft as WG document
>>> Jan 2014 - Submit requirements draft to the IESG as an Informational
>>> RFC
>>> Mar 2014 - Adopt wide-area service discovery solution draft as WG
>>> document 
>>> Mar 2014 - Adopt Informational document on the problems and challenges
>>> arising for zeroconf and unicast DNS name services
>>> Sep 2014 - Submit wide-area service discovery solution draft to the
>>> IESG as Standards Track RFC 
>>> Sep 2014 - Submit the zeroconf and unicast DNS "problems and
>>> challenges" draft to the IESG as Informational.