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

  ----- The following addresses had permanent fatal errors -----
<dnssdext-request(_at_)ietf(_dot_)org>
   (reason: 550 5.1.1 <dnssdext-request(_at_)ietf(_dot_)org>: Recipient address 
rejected: User unknown in virtual alias table)



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 ietf.org) by 2013-10-10.
>
> Extensions for Scalable DNS Service Discovery  (dnssd)
> ------------------------------------------------
> Current Status: Proposed WG
>
> Chairs:
>  Ralph Droms <rdroms(_dot_)ietf(_at_)gmail(_dot_)com>
>  Tim Chown <tjc(_at_)ecs(_dot_)soton(_dot_)ac(_dot_)uk>
>
> Assigned Area Director:
>  Ted Lemon <ted(_dot_)lemon(_at_)nominum(_dot_)com>
>
> Mailing list
>  Address: dnssdext(_at_)ietf(_dot_)org
>  To Subscribe: dnssdext-request(_at_)ietf(_dot_)org
>  Archive: http://www.ietf.org/mail-archive/web/dnssdext
>
> 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.