Re: [mdnsext] Discussion of BoF during Berlin IETF

With my co-chair hat on, I would like to reinforce that this topic is of great importance to the homenet WG (i.e., we are chartered to solve it whether this WG exists or not). If this WG exists, there is perhaps a better chance that the homenet solution ends up with common components, usable outside of a residential solution. That would be a good thing.

- Mark

On May 22, 2013, at 7:58 PM, Ralph Droms wrote:

> After a pretty good discussion of requirements and related considerations, traffic on the mailing list has been pretty quiet.  Looking ahead to a request for a BoF in Berlin, I've updated the draft request and charter (only a little) and included them below.
> 
> What we need now is careful review and discussion of the text below, and explicit expressions of interest in the topic and support for the specific direction laid out in the BoF request and charter.
> 
> Perhaps the most obvious change I suggest is to change the name from mdnsext to sadnssd (scalable, autonomous DNS-SD).  This change follows the direction of the earlier mailing list discussion away from extensions to mDNS to higher level consideration of scalable DNS-SD.
> 
> - Ralph
> 
> BoF scheduling information:
> 
> a. Scalable, Autonomous DNS-Based Service Discovery (sadnssd)
> 
> b. Internet Area
> 
> c. Conflicts: 6man homenet dhc apparea appsawg intarea sdnrg v6ops dnsop and dnsext
> 
> d. Expected Attendance: 200 (at least 164 attended at IETF85)
> 
> e. Special requests: None
> 
> f. Number of sessions: 1
> 
> g. Length of session: 2 hours 
> 
> 
> Draft agenda:
> --------------------
> 
> 1. Administravia (Chairs, 5 mins)   
>    Note Well and agenda bashing
> 
> 2. Goals of the BoF (Chairs, 15 mins)
>    Review of IETF 85 mdsnext BoF and progress since then
> 
> 3. Requirements (Kerry Lynn, 30 mins)
>    draft-lynn-sadnssd-requirements-01
> 
> 4. Open discussion (Chairs, 40 mins)
>    Open mic; includes draft charter and deliverables
> 
> 5. Key questions (Chairs, 30 mins)
>    Are we ready to form a WG with the agreed charter, subject to mail
>      list confirmation?  
>    Note RFC5434 section 1.
> 
> 
> Draft charter:
> -------------------
> 
> Currently, zeroconf networking protocols are generally used to
> discover services within the scope of a single link. In particular,
> the Bonjour protocols suite, comprising mDNS (RFC 6762) and DNS-SD
> (RFC 6763), are widely used for discovery and resolution of services
> and names on a single link.
> 
> The Bonjour protocol suite is commonly used in many scenarios,
> including home networks, commercial and campus enterprise networks,
> and may be of use in certain mesh networks.  However, the multicast
> Bonjour protocols are constrained to link-local scope, so can only be
> used to discover services on the same link. In a typical current home
> network, which is a single link, users should experience the desired
> discovery behavior. However, in future multi-link home networks (as
> envisaged by the homenet WG) and in routed campus or enterprise
> networks, devices and thus users can only discover services on the
> same link, which is a significant limitation. Such limitations have
> led to calls, such as those by the Educause petition, to develop an
> appropriate solution to span multiple links, or to perform discovery
> across a wide area (not necessarily on directly connected links).
> 
> In addition, the ZigBee Alliance Smart Energy Profile 2.0 commercial
> standard currently under development has specified the Bonjour
> protocols as its method of zero configuration discovery. However, its
> use of wireless mesh multi-link subnets and its use across traditional
> routed networks will require extensions to the Bonjour protocols to
> allow operation across multiple links.
> 
> As demand for service discovery across wider area routed networks
> grows, some vendors are beginning to ship their own early
> 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.
> 
> Goals
> 
> To that end, the primary goals of the sadnssd 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 four scenarios:
> 
>    a) Commercial enterprise networks
>    b) Academic/educational/university campus networks
>    c) Multi-link home networks, such as those envisaged by the
>       HOMENET WG 
>    d) Multi-link/single subnet (mesh) networks, such as those
>       described by the ZigBee Alliance Z-IP specification
> 
> 2. To develop an improved, scalable solution for wide-area service
>   discovery that can operate in multi-link networks, applicable to
>   the scenarios above.
> 
> 3. To develop a BCP for the coexistence of zeroconf (mDNS) and unicast
>   (global DNS) name services in such multi-link networks, which
>   should include consideration of both the name resolution mechanism
>   and the namespace.
> 
> It is important that the sadnssd 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 mdsnext WG, and
> thus coordination between the WGs is desirable.
> 
> Deliverables
> 
> The WG will produce three documents: an Informational RFC on the
> requirements for wide-area service discovery protocols; a Standards
> Track RFC documenting a wide-area service discovery solution that is
> applicable to those scenarios; and a BCP document describing the most
> effective method to integrate mDNS and global DNS name services.
> 
> Milestones
> 
> Sep 2013 Formation of the WG
> Oct 2013 Adopt requirements draft as WG document
> Nov 2013 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 zeroconf and unicast DNS integration BCP draft as WG
>         document 
> Sep 2014 Submit wide-area service discovery solution draft to the IESG
>         as Standards Track RFC 
> Sep 2014 Submit zeroconf and unicast DNS integration solution draft to
>         the IESG as BCP 
> 
> _______________________________________________
> mdnsext mailing list
> mdnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/mdnsext