Subject: [mdnsext] Discussion of BoF during Berlin IETF

From: Ralph Droms <[email-masked]>
Date: Wed, 22 May 2013 20:58:38 +0300

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

---

From: Ralph Droms <[email-masked]>
Date: Thu, 30 May 2013 23:24:22 -0400

REMINDER!!!!

I'm looking for review and discussion of the BoF proposal and draft charter here: http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html

The mailing list has been quiet (0 responses so far).  Is there still interest in taking on this work?

- Ralph

---

From: peter van der Stok <[email-masked]>
Date: Fri, 31 May 2013 08:24:28 +0200

Ralph,

I am certainly interested in this work and agree with the charter, 
which has improved with respect to the former version.
 From the point of view of building control, it is essential to do 
disovery on a multilink stand-alone network, and not needing to change 
the applications when the network is connected to a backbone with access 
to DNS. From the outside the resources on the now connected network 
should be visible with the same names, possibly suffixed with additional 
domain name information.

In the past I have commented on the requirements and I am looking 
forward to a new version.

Peter van der Stok.

Ralph Droms schreef op 2013-05-31 05:24:
> REMINDER!!!!
> 
> I'm looking for review and discussion of the BoF proposal and draft
> charter here:
> http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html
> 
> _______________________________________________
> mdnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mdnsext

---

From: Daniel Park <[email-masked]>
Date: Fri, 31 May 2013 18:18:45 +0900

Just curious why mDNS was originally developed for a single link? Any
special reasons from the beginning?

Soohong Daniel Park