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

On 3 Oct 2013, at 18:07, manning bill <bmanning(_at_)isi(_dot_)edu> wrote:

>  ----- 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)
I think the active list is still mdnsext(_at_)ietf(_dot_)org?
See: http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html

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 <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: dnssd(_at_)ietf(_dot_)org
 To Subscribe: dnssd-request(_at_)ietf(_dot_)org
 Archive: http://www.ietf.org/mail-archive/web/dnssd
 Pre-WG BoF Archive: http://www.ietf.org/mail-archive/web/mdnsext 


--- 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 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.