[mdnsext] Discussion of BoF during Berlin IETF

Ralph Droms <rdroms.ietf@gmail.com> Wed, 22 May 2013 17:58 UTC

Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0993A21F96E9 for <mdnsext@ietfa.amsl.com>; Wed, 22 May 2013 10:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.399
X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HSBpq5mCOjsR for <mdnsext@ietfa.amsl.com>; Wed, 22 May 2013 10:58:43 -0700 (PDT)
Received: from mail-gg0-x236.google.com (mail-gg0-x236.google.com [IPv6:2607:f8b0:4002:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB9721F96DD for <mdnsext@ietf.org>; Wed, 22 May 2013 10:58:43 -0700 (PDT)
Received: by mail-gg0-f182.google.com with SMTP id q2so794371ggc.27 for <mdnsext@ietf.org>; Wed, 22 May 2013 10:58:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=U8l3BQ8tjlZJKKogWIhYsGqDbh879WORmwjxOgaRBv4=; b=swQ3nrcPJiRR+u1edIqEhtc0n13aN53/f12ODF9Kk2HBFMPHniuRq9jDszaViJ//FY 8qO99/WrO3UlY6Og6X2+Aqn/vRfe4O7hw5iR+dk9x9xBjl5CqO7a50LyPQNhs29co3CA pXDRSXFuDLd+sfoQuyXTiOhbuO1iyHy383zz7243pv5+8NRU3F8RLac5iB9rUvmqRyFV Tc9nMqWSqDPV81NtBBlRO7BSS6f7Ohg9XeqWHvI0XAnqMIH8tgEJv10+grqxaqjGsQzQ wrdMiuSNxPXBLsU44dZmO/jxYFBjs1iDsOv8kgCqHCMzMZ1J7+neUDR4OhUtoEO5c0Vh lCkw==
X-Received: by with SMTP id p8mr6347893yhj.74.1369245522683; Wed, 22 May 2013 10:58:42 -0700 (PDT)
Received: from [] (198-135-0-233.cisco.com. []) by mx.google.com with ESMTPSA id u69sm12363061yhf.23.2013. for <mdnsext@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 May 2013 10:58:41 -0700 (PDT)
From: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com>
Date: Wed, 22 May 2013 20:58:38 +0300
To: "mdnsext@ietf.org" <mdnsext@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
X-Mailer: Apple Mail (2.1503)
Subject: [mdnsext] Discussion of BoF during Berlin IETF
X-BeenThere: mdnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <mdnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mdnsext>
List-Post: <mailto:mdnsext@ietf.org>
List-Help: <mailto:mdnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mdnsext>, <mailto:mdnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2013 17:58:44 -0000

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)

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.


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.


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.


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
Mar 2014 Adopt zeroconf and unicast DNS integration BCP draft as WG
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