Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
manning bill <bmanning@isi.edu> Thu, 03 October 2013 19:20 UTC
Return-Path: <bmanning@isi.edu>
X-Original-To: mdnsext@ietfa.amsl.com
Delivered-To: mdnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98BD621F9AA1; Thu, 3 Oct 2013 12:20:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.599
X-Spam-Level:
X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pqv-IN-fuCsB; Thu, 3 Oct 2013 12:19:56 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C321F9C7B; Thu, 3 Oct 2013 12:07:05 -0700 (PDT)
Received: from [128.9.184.131] ([128.9.184.131]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id r93J5pq2012326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 3 Oct 2013 12:05:51 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="windows-1252"
From: manning bill <bmanning@isi.edu>
In-Reply-To: <EMEW3|db89e71161b3bb8f7117f7d83e2ef53ep92JhU03tjc|ecs.soton.ac.uk|9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk>
Date: Thu, 03 Oct 2013 12:05:51 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <D6ABF372-BAA8-4CCC-AFE7-41D480C2D28F@isi.edu>
References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> <EMEW3|db89e71161b3bb8f7117f7d83e2ef53ep92JhU03tjc|ecs.soton.ac.uk|9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk>
To: Tim Chown <tjc@ecs.soton.ac.uk>
X-Mailer: Apple Mail (2.1283)
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: bmanning@isi.edu
X-Mailman-Approved-At: Sun, 06 Oct 2013 19:21:27 -0700
Cc: "mdnsext@ietf.org mdnsext" <mdnsext@ietf.org>, Lemon Ted <Ted.Lemon@nominum.com>, "<ietf@ietf.org> Discussion" <ietf@ietf.org>, IETF-Announce <ietf-announce@ietf.org>, Ralph Droms <rdroms.ietf@gmail.com>
Subject: Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
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: Thu, 03 Oct 2013 19:20:08 -0000
but the "To Subscribe" pointer is busted…. /bill On 3October2013Thursday, at 11:43, Tim Chown wrote: > On 3 Oct 2013, at 18:07, manning bill <bmanning@isi.edu> wrote: > >> ----- The following addresses had permanent fatal errors ----- >> <dnssdext-request@ietf.org> >> (reason: 550 5.1.1 <dnssdext-request@ietf.org>: Recipient address rejected: User unknown in virtual alias table) > > I think the active list is still mdnsext@ietf.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.ietf@gmail.com> > Tim Chown <tjc@ecs.soton.ac.uk> > > Assigned Area Director: > Ted Lemon <ted.lemon@nominum.com> > > Mailing list > Address: dnssd@ietf.org > To Subscribe: dnssd-request@ietf.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.ietf@gmail.com> >>> Tim Chown <tjc@ecs.soton.ac.uk> >>> >>> Assigned Area Director: >>> Ted Lemon <ted.lemon@nominum.com> >>> >>> Mailing list >>> Address: dnssdext@ietf.org >>> To Subscribe: dnssdext-request@ietf.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. >>> >>> >> >
- Re: [mdnsext] WG Review: Extensions for Scalable … Tim Chown
- Re: [mdnsext] WG Review: Extensions for Scalable … Ted Lemon
- Re: [mdnsext] WG Review: Extensions for Scalable … Ted Lemon
- Re: [mdnsext] WG Review: Extensions for Scalable … Jaap Akkerhuis
- Re: [mdnsext] WG Review: Extensions for Scalable … Ralph Droms
- Re: [mdnsext] WG Review: Extensions for Scalable … manning bill
- Re: [mdnsext] WG Review: Extensions for Scalable … macbroadcast