From tjc@ecs.soton.ac.uk Thu Oct 3 11:52:06 2013 Return-Path: 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 11AD021F8D62; Thu, 3 Oct 2013 11:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 qYpzdwZq6bDc; Thu, 3 Oct 2013 11:51:51 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id F2C3021F8984; Thu, 3 Oct 2013 11:43:36 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r93IhUjm025455; Thu, 3 Oct 2013 19:43:30 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r93IhUjm025455 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1380825810; bh=SXHCY0EZOq8r7Nj75r+vIh08TRE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=NSs5dihBz9bfSTNDxdWxzh6rfqfmSGHaa6AlFhqio/w74KdGwTkYb7rf+jZLXSebq Mpteu7h18+wbsZ3SWet31Vhneol8gCfNFL1qOInKxu71QSaNC+d654ffrZxKH/Nz8Q duelj2QUfvzDTYK2Wd6qUxJHHkwYjwOVDanvYrjY= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p92JhU0544563631dS ret-id none; Thu, 03 Oct 2013 19:43:30 +0100 Received: from [192.168.1.108] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r93IhO3B031347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 3 Oct 2013 19:43:25 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Tim Chown In-Reply-To: <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> Date: Thu, 3 Oct 2013 19:43:24 +0100 Message-ID: References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> To: manning bill X-Mailer: Apple Mail (2.1510) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p92JhU054456363100; tid=p92JhU0544563631dS; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r93IhUjm025455 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "mdnsext@ietf.org mdnsext" , Lemon Ted , " Discussion" , IETF-Announce , Ralph Droms 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 18:52:06 -0000 --Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Oct 2013, at 18:07, manning bill wrote: > ----- The following addresses had permanent fatal errors ----- > > (reason: 550 5.1.1 : 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 Tim Chown Assigned Area Director: Ted Lemon 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=20 --- snip --- Tim >=20 >=20 >=20 > On 3October2013Thursday, at 8:42, The IESG wrote: >=20 >> 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. >>=20 >> Extensions for Scalable DNS Service Discovery (dnssd) >> ------------------------------------------------ >> Current Status: Proposed WG >>=20 >> Chairs: >> Ralph Droms >> Tim Chown >>=20 >> Assigned Area Director: >> Ted Lemon >>=20 >> Mailing list >> Address: dnssdext@ietf.org >> To Subscribe: dnssdext-request@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/dnssdext >>=20 >> Charter: >>=20 >> Background >> ---------- >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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,=20= >> scalable, autonomous service discovery solutions for routed networks=20= >> are coordinated towards producing a single, standards-based solution. >>=20 >> 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. >>=20 >> The focus of the WG is to develop a solution for extended, scalable=20= >> DNS-SD. This work is likely to highlight problems and challenges = with=20 >> naming protocols, as some level of coexistence will be required = between=20 >> local zero configuration name services and those forming part of the=20= >> global DNS. It is important that these issues are captured and=20 >> documented for further analysis; solving those problems is however = not=20 >> within the scope of this WG. >>=20 >> Working Group Description >> ------------------------- >>=20 >> To that end, the primary goals of the dnssd WG are as follows: >>=20 >> 1. To document a set of requirements for scalable, autonomous >> DNS-based service discovery in routed, multi-link networks in the >> following five scenarios: >>=20 >> (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.=20 >>=20 >> (B) Home networks, as envisaged by the homenet WG, consisting of=20 >> one or more exit routers, with one or more upstream providers=20 >> or networks, and an arbitrary internal topology with=20 >> heterogeneous media where routing is automatically configured.=20= >> The home network would typically be a single zero configuration=20= >> administrative domain with a relatively limited number of=20 >> devices.=20 >>=20 >> (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. >>=20 >> (D) Enterprise networks, consisting of larger routed networks,=20 >> with large numbers of devices, which may be deployments=20 >> spanning over multiple sites with multiple upstreams, and >> one more more administrative domains (depending on internal >> administrative delegation). The large majority of the=20 >> forwarding and security devices are configured. These may >> be commercial or academic networks, with differing levels=20 >> of administrative control over certain devices on the network, >> and BYOD devices commonplace in the campus scenario. >>=20 >> (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,=20 >> HomePlug AV and GP, and ZigBee IP.=20 >>=20 >> In the above scenarios, the aim is to facilitate service discovery=20= >> across the defined site. It is also desirable that a user or = device,=20 >> when away from such a site, is still able to discover services=20 >> within that site, e.g. a user discovering services in their home=20 >> network while remote from it. >>=20 >> 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. >>=20 >> 2. To develop an improved, scalable solution for service discovery=20 >> 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.=20 >>=20 >> The solution should include documentation or definition of the >> interfaces that can be implemented, separately to transport of=20 >> the information. >>=20 >> 3. To document challenges and problems encountered in the coexistence=20= >> of zero configuration and global DNS name services in such=20 >> multi-link networks, including consideration of both the name=20 >> resolution mechanism and the namespace. >>=20 >> 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. >>=20 >> Deliverables: >>=20 >> 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=20 >> that is applicable to those scenarios; and an Informational RFC=20 >> describing the problems arising when developing the extended SD = solution=20 >> and how it affects the integration of local zero configuration and = global >>=20 >> DNS name services. >>=20 >> 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=20 >> 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=20 >> Sep 2014 - Submit the zeroconf and unicast DNS "problems and >> challenges" draft to the IESG as Informational. >>=20 >>=20 >=20 --Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii 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)
------------------------------------------------
Curre= nt Status: Proposed WG

Chairs:
 Ralph Droms <rdroms.ietf@gmail.com>
&nb= sp;Tim Chown <tjc@ecs.soton.ac.uk>

Ass= igned Area Director:
 Ted Lemon <ted.lemon@nominum.com>
Mailing list
 Address: dnssd@ietf.org
 To = Subscribe: dnssd-request@ietf.org
&n= bsp;Archive: http://www.ietf.org/ma= il-archive/web/dnssd
 Pre-WG BoF Archive: http://www.ietf.org/mail-ar= chive/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)
------------------------------------------------
Curre= nt Status: Proposed WG

Chairs:
Ralph Droms <rdroms.ietf@gmail.com>
= Tim Chown <tjc@ecs.soton.ac.uk>

Ass= igned 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.




<= /html>= --Apple-Mail=_2193BD6E-6B92-4549-A4F3-42F75A2BC089-- From Ted.Lemon@nominum.com Thu Oct 3 12:34:37 2013 Return-Path: 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 E857521E805D; Thu, 3 Oct 2013 12:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.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 3isgxgE7Ee56; Thu, 3 Oct 2013 12:34:23 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 436CB21E80B0; Thu, 3 Oct 2013 12:17:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUk3Cq2iPwqHbr6JLwMpvairt29Ciwt9S@postini.com; Thu, 03 Oct 2013 12:17:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id CB92F1B82EC; Thu, 3 Oct 2013 12:16:58 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 356C5190075; Thu, 3 Oct 2013 12:16:58 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 12:16:58 -0700 From: Ted Lemon To: Tim Chown Thread-Topic: WG Review: Extensions for Scalable DNS Service Discovery (dnssd) Thread-Index: AQHOwF5B0GotrtN9IE6CWx+CuArZj5njxX0AgAAJXwA= Date: Thu, 3 Oct 2013 19:16:57 +0000 Message-ID: <869EE259-1A87-447B-A3A8-2B8254FCB6CA@nominum.com> References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6059774F1402C9438CC2BDB1951A7395@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org mdnsext" , Ralph Droms , " Discussion" , IETF-Announce , manning bill 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:34:37 -0000 Discussion of IETF consensus activities is supposed to occur on the IETF ma= iling list, not on the working group mailing list, which doesn't yet exist.= We'll set up the new mailing list when the working group is approved. S= orry for the confusion. From Ted.Lemon@nominum.com Thu Oct 3 12:38:50 2013 Return-Path: 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 C85B221E80CD; Thu, 3 Oct 2013 12:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 djiYzGBJswee; Thu, 3 Oct 2013 12:38:38 -0700 (PDT) Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id 4842221F9AD5; Thu, 3 Oct 2013 12:20:11 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUk3Da4V5OJa4j02DazmNSXOsrMlsSVJD@postini.com; Thu, 03 Oct 2013 12:20:11 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E1B1F1B82F0; Thu, 3 Oct 2013 12:20:10 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id D53C2190075; Thu, 3 Oct 2013 12:20:10 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.03.0158.001; Thu, 3 Oct 2013 12:20:10 -0700 From: Ted Lemon To: manning bill Thread-Topic: WG Review: Extensions for Scalable DNS Service Discovery (dnssd) Thread-Index: AQHOwF5B0GotrtN9IE6CWx+CuArZj5njxX0AgAAGRoCAAAQAAA== Date: Thu, 3 Oct 2013 19:20:10 +0000 Message-ID: References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <42B3C02C1C0FEF49A973B7E2E4D67F36@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org mdnsext" , Tim Chown , " Discussion" , IETF-Announce , Ralph Droms 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:38:50 -0000 On Oct 3, 2013, at 3:05 PM, manning bill wrote: > but the "To Subscribe" pointer is busted=85. Correct. I should have gotten the information right before sending out th= e announcement, but I blew it=97sorry about that. From jaap@NLnetLabs.nl Thu Oct 3 13:05:19 2013 Return-Path: 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 A3D6321E8114; Thu, 3 Oct 2013 13:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 afGPs0l2xEpL; Thu, 3 Oct 2013 13:05:09 -0700 (PDT) Received: from bela.nlnetlabs.nl (bela.nlnetlabs.nl [IPv6:2001:7b8:206:1:222:4dff:fe55:4ccb]) by ietfa.amsl.com (Postfix) with ESMTP id 89AAA21F8319; Thu, 3 Oct 2013 12:47:12 -0700 (PDT) Received: from bela.nlnetlabs.nl (localhost [IPv6:::1]) by bela.nlnetlabs.nl (8.14.7/8.14.7) with ESMTP id r93JkaUQ026289; Thu, 3 Oct 2013 21:46:37 +0200 (CEST) (envelope-from jaap@NLnetLabs.nl) Authentication-Results: bela.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl Message-Id: <201310031946.r93JkaUQ026289@bela.nlnetlabs.nl> To: manning bill From: Jaap Akkerhuis In-reply-to: References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> Comments: In-reply-to manning bill message dated "Thu, 03 Oct 2013 12:05:51 -0700." Date: Thu, 03 Oct 2013 21:46:36 +0200 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (bela.nlnetlabs.nl [IPv6:::1]); Thu, 03 Oct 2013 21:46:38 +0200 (CEST) Cc: "mdnsext@ietf.org mdnsext" , Tim Chown , " Discussion" , IETF-Announce 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 20:05:21 -0000 but the "To Subscribe" pointer is busted. According to the list is supposed to be . jaap From rdroms.ietf@gmail.com Thu Oct 3 15:10:01 2013 Return-Path: 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 5A0B521F9248; Thu, 3 Oct 2013 15:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 LE06FLcJGRZc; Thu, 3 Oct 2013 15:09:54 -0700 (PDT) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0821F918C; Thu, 3 Oct 2013 15:09:49 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id q4so2122173qcx.26 for ; Thu, 03 Oct 2013 15:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=gS5pasxw9YsxQK97WN1Gdc8ktOO2njrhWnM/b+GXclU=; b=s0vd7n8K20TREX5RYqMiLzvg20np0kLEW5lJmCItGspRcieEtDXuTacIhE/gIFn7gq bJfWoFvW4r79w3AgfJGZEGQUqQPMk8vUgGL9zsvvubdbuQa7GApByDRYvhnjvxgv1wEl Mr94SRVxyPqmK/4JjvP4A1eKnffYD39xDhdAqidbhoMBFz8XvyHsTeV7XW4JTCS0kyok DqobyjfCR7B6D6BdvPFLqEvoE5flS98KH4spPdIy6BYdjKtqOTX7HJVOiBk4GxRZIeJ3 bpcgh6hwrM9K4+0pvh8tkG4f8xd3115au3f51ztzDGgmF0xdwnj0VwJbg6ba4oOk+NdO 01rQ== X-Received: by 10.224.22.202 with SMTP id o10mr4609550qab.117.1380838188204; Thu, 03 Oct 2013 15:09:48 -0700 (PDT) Received: from [192.168.1.116] (c-24-62-108-202.hsd1.ma.comcast.net. [24.62.108.202]) by mx.google.com with ESMTPSA id 4sm18910336qak.11.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Oct 2013 15:09:47 -0700 (PDT) References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> <201310031946.r93JkaUQ026289@bela.nlnetlabs.nl> Mime-Version: 1.0 (1.0) In-Reply-To: <201310031946.r93JkaUQ026289@bela.nlnetlabs.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <000F1B1E-93E6-432D-BC33-46D5E70B41E4@gmail.com> X-Mailer: iPhone Mail (10B350) From: Ralph Droms Date: Thu, 3 Oct 2013 18:09:45 -0400 To: Jaap Akkerhuis Cc: "mdnsext@ietf.org mdnsext" , Tim Chown , " Discussion" , IETF-Announce , manning bill 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 22:10:01 -0000 On Oct 3, 2013, at 3:46 PM, Jaap Akkerhuis wrote: >=20 > but the "To Subscribe" pointer is busted. >=20 > According to the list is supposed > to be . mdnsext@ietf.org was used for the two BoFs. The WG will be dnssd, and the m= ailing list will be dnssd@ietf.org (which, I air, is not what is shown in th= e charter header). - Ralph >=20 > jaap > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext From bmanning@isi.edu Thu Oct 3 12:20:08 2013 Return-Path: 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 In-Reply-To: Date: Thu, 3 Oct 2013 12:05:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> To: Tim Chown 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" , Lemon Ted , " Discussion" , IETF-Announce , Ralph Droms 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2013 19:20:08 -0000 but the "To Subscribe" pointer is busted=85. /bill On 3October2013Thursday, at 11:43, Tim Chown wrote: > On 3 Oct 2013, at 18:07, manning bill wrote: >=20 >> ----- The following addresses had permanent fatal errors ----- >> >> (reason: 550 5.1.1 : Recipient address = rejected: User unknown in virtual alias table) >=20 > I think the active list is still mdnsext@ietf.org? > See: = http://www.ietf.org/mail-archive/web/mdnsext/current/maillist.html >=20 > And the 'header' information below should now probably read something = like this: >=20 > --- snip --- >=20 > Scalable DNS Service Discovery (dnssd) > ------------------------------------------------ > Current Status: Proposed WG >=20 > Chairs: > Ralph Droms > Tim Chown >=20 > Assigned Area Director: > Ted Lemon >=20 > 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=20 >=20 >=20 > --- snip --- >=20 > Tim >=20 >>=20 >>=20 >>=20 >> On 3October2013Thursday, at 8:42, The IESG wrote: >>=20 >>> 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. >>>=20 >>> Extensions for Scalable DNS Service Discovery (dnssd) >>> ------------------------------------------------ >>> Current Status: Proposed WG >>>=20 >>> Chairs: >>> Ralph Droms >>> Tim Chown >>>=20 >>> Assigned Area Director: >>> Ted Lemon >>>=20 >>> Mailing list >>> Address: dnssdext@ietf.org >>> To Subscribe: dnssdext-request@ietf.org >>> Archive: http://www.ietf.org/mail-archive/web/dnssdext >>>=20 >>> Charter: >>>=20 >>> Background >>> ---------- >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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,=20= >>> scalable, autonomous service discovery solutions for routed networks=20= >>> are coordinated towards producing a single, standards-based = solution. >>>=20 >>> 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. >>>=20 >>> The focus of the WG is to develop a solution for extended, scalable=20= >>> DNS-SD. This work is likely to highlight problems and challenges = with=20 >>> naming protocols, as some level of coexistence will be required = between=20 >>> local zero configuration name services and those forming part of the=20= >>> global DNS. It is important that these issues are captured and=20 >>> documented for further analysis; solving those problems is however = not=20 >>> within the scope of this WG. >>>=20 >>> Working Group Description >>> ------------------------- >>>=20 >>> To that end, the primary goals of the dnssd WG are as follows: >>>=20 >>> 1. To document a set of requirements for scalable, autonomous >>> DNS-based service discovery in routed, multi-link networks in the >>> following five scenarios: >>>=20 >>> (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.=20 >>>=20 >>> (B) Home networks, as envisaged by the homenet WG, consisting of=20 >>> one or more exit routers, with one or more upstream providers=20= >>> or networks, and an arbitrary internal topology with=20 >>> heterogeneous media where routing is automatically configured.=20= >>> The home network would typically be a single zero configuration=20= >>> administrative domain with a relatively limited number of=20 >>> devices.=20 >>>=20 >>> (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. >>>=20 >>> (D) Enterprise networks, consisting of larger routed networks,=20 >>> with large numbers of devices, which may be deployments=20 >>> spanning over multiple sites with multiple upstreams, and >>> one more more administrative domains (depending on internal >>> administrative delegation). The large majority of the=20 >>> forwarding and security devices are configured. These may >>> be commercial or academic networks, with differing levels=20 >>> of administrative control over certain devices on the network, >>> and BYOD devices commonplace in the campus scenario. >>>=20 >>> (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,=20 >>> HomePlug AV and GP, and ZigBee IP.=20 >>>=20 >>> In the above scenarios, the aim is to facilitate service discovery=20= >>> across the defined site. It is also desirable that a user or = device,=20 >>> when away from such a site, is still able to discover services=20 >>> within that site, e.g. a user discovering services in their home=20 >>> network while remote from it. >>>=20 >>> 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. >>>=20 >>> 2. To develop an improved, scalable solution for service discovery=20= >>> 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.=20 >>>=20 >>> The solution should include documentation or definition of the >>> interfaces that can be implemented, separately to transport of=20 >>> the information. >>>=20 >>> 3. To document challenges and problems encountered in the = coexistence=20 >>> of zero configuration and global DNS name services in such=20 >>> multi-link networks, including consideration of both the name=20 >>> resolution mechanism and the namespace. >>>=20 >>> 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. >>>=20 >>> Deliverables: >>>=20 >>> 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=20 >>> that is applicable to those scenarios; and an Informational RFC=20 >>> describing the problems arising when developing the extended SD = solution=20 >>> and how it affects the integration of local zero configuration and = global >>>=20 >>> DNS name services. >>>=20 >>> 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=20 >>> 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=20 >>> Sep 2014 - Submit the zeroconf and unicast DNS "problems and >>> challenges" draft to the IESG as Informational. >>>=20 >>>=20 >>=20 >=20 From marc@let.de Sun Oct 6 20:47:05 2013 Return-Path: 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 D2E6321E813B for ; Sun, 6 Oct 2013 20:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] 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 YeTaIcrQsdEP for ; Sun, 6 Oct 2013 20:47:01 -0700 (PDT) Received: from www.let.de (www.let.de [178.77.75.147]) by ietfa.amsl.com (Postfix) with ESMTP id 3035021E8133 for ; Sun, 6 Oct 2013 20:47:00 -0700 (PDT) X-No-Relay: not in my network Received: from [192.168.1.101] (f048160138.adsl.alicedsl.de [78.48.160.138]) by www.let.de (Postfix) with ESMTPA id A5AB39E0C031 for ; Mon, 7 Oct 2013 05:46:37 +0200 (CEST) Message-ID: <52522EA4.5050207@let.de> Date: Mon, 07 Oct 2013 05:46:44 +0200 From: macbroadcast User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mdnsext@ietf.org References: <20131003154254.13078.69905.idtracker@ietfa.amsl.com> <72B4B7B0-2B15-4B64-AEC1-23B01F89AD71@isi.edu> <9C2D0B1D-C493-41F5-B459-166098EAFC8D@ecs.soton.ac.uk> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 03:47:06 -0000 Am 03.10.2013 21:05, schrieb manning bill: > but the "To Subscribe" pointer is busted…. > > > /bill and your system time is incorrect ;) /marc -- Les enfants terribles / Marc Manthey 50823 Köln, germany Vogelsangerstr.97 Mobile : 0049-1577-3329231 Fingerprint: B045 9750 C2CB 06C3 3782 A264 A47F 3645 0E19 8512 Website: https://let.de Twitter: https://twitter.com/macbroadcast Facebook: https://www.facebook.com/opencu From javi.jimenez@guifi.net Fri Oct 11 05:06:06 2013 Return-Path: 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 2FC3411E80E8 for ; Fri, 11 Oct 2013 05:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.376 X-Spam-Level: X-Spam-Status: No, score=0.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1] 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 l8bpRi8EN378 for ; Fri, 11 Oct 2013 05:06:01 -0700 (PDT) Received: from smtp1.elserrat.org (109-69-9-53-guifi-gurb.ip4.guifi.net [109.69.9.53]) by ietfa.amsl.com (Postfix) with ESMTP id 2800B11E8152 for ; Fri, 11 Oct 2013 05:05:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.elserrat.org (Postfix) with ESMTP id D69503401354 for ; Fri, 11 Oct 2013 14:05:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=guifi.net; h= content-transfer-encoding:content-type:content-type:subject :subject:mime-version:user-agent:from:from:date:date:message-id :received:received:received; s=dkim; t=1381493152; x=1383307553; bh=vwbfDs5vSHeYBe8GyJo6wBmGSjC6j/VmiJLdWgrd/rM=; b=Km6iuKtDdaFF x5hGDE1BVaBeY0St54Ub98vBquggD9yO46hSwNPjtRU0HcQxixr4JWj2zn2uX9vf kvqyPPv0hz0xk+zCGJRfVLPLDWZmqitk9GEJOu3eH3tDQAnX5cXsEsVtLt31rQ8R h8yy/8zARhiWz6vQ3lGveHafzs4RxBMBdoo1tlAC6mGuHDk1KuWeFElKndHnq35q nOtxpTHB1jhnV5eE31OJO2JojwuxRUuf5QqRQzd9nx99GtHtVBvnqCkjUWTLVOSv JtYxqBmGw3i2kBzp3NYPy4G5Kjl3B1XR10uF+iyEIvpV2H/WG6vDrMueMSBZStEV uI5pB+05Ww== X-Virus-Scanned: Scrollout F1 on Debian amavisd-new at elserrat.org Received: from smtp1.elserrat.org ([127.0.0.1]) by localhost (smtp1.elserrat.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id lMZoNiXO3MFm for ; Fri, 11 Oct 2013 14:05:52 +0200 (CEST) Received: from mail.elserrat.org (109-69-9-9-guifi-gurb.ip4.guifi.net [109.69.9.9]) by smtp1.elserrat.org (Postfix) with ESMTP id C64CD3401340 for ; Fri, 11 Oct 2013 14:05:51 +0200 (CEST) Received: from [192.168.4.222] (81.202.101.225.dyn.user.ono.com [81.202.101.225]) by mail.elserrat.org (Postfix) with ESMTPSA id 7A1CE6A92BE for ; Fri, 11 Oct 2013 14:05:51 +0200 (CEST) Message-ID: <5257E99E.1050308@guifi.net> Date: Fri, 11 Oct 2013 14:05:50 +0200 From: =?ISO-8859-1?Q?Javi_Jim=E9nez?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: mdnsext@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [mdnsext] New participant from guifi.net Community Network and the Clommunity project 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:13:14 -0000 Greetings, Recently we got news about the WG in the mailing list of the Clommunity project [1] a project about building a cloud in a box for Community Networks. One subtask of the Clommunity project is related to the subject of the mdnsext mailing list. In the received message we were invited to participate in the current mailing list. We'd like to present a project [2] (ddnsc) related to the pourpose of this working group, we're in the first developing stages of the project and it's an script which publishes DNS registers to a global DNS server using the 'nsupdate' program. At the moment it's possible to publish and browse services, we need to test and improve it. The work is related to GNU/Linux and the Avahi Zeroconf implementation. We continue developing the idea, which is basically to publish the services of a Community Network in a DNS server reachable using an anycast address for all the distributed DNS servers, with the anycast address we can replicate the servers (we already replicate DNS servers in the CN using geographical zones), with the anycast we try to avoid the overloading of unique DNS servers. The services are in a particular subdomain, as for example 'guifi', and all the users could browse the services inside the Community Network. Related to the script, have to say that security is a problem, because right now anyone is allowed to update the bind DNS registers (allow-update {any}; it's aimed for all the users who want to publish services), perhaps we need an ACL to only allow to publish (only) new services pointing to the IP which is sending the publication. Due that reaseon, we've not public DNS service yet, it's being worked only under a development environment. We don't know if the linked code it could be useful but the linked project is part of current research. The referred code is a result of various documents, meetings and working groups present in the references and covers it in part. Personally I work for the "Fundació Privada per a la Xarxa Oberta, Lliure i Neutral guifi.net" [3] (guifi.net Foundation Network Common Open, Free and Neutral) Foundation about the guifi.net Community Network [4] with more than 22.000 nodes and we're participating in the Clommunity European project. I'm not representing but giving information, and with your permission, willing to participate in the mailing list discussing topics as best as I can. Best Regards. [1] http://clommunity-project.eu/ [2] https://github.com/javi-jimenez/ddnsc [3] http://blogs.guifi.net/fundacio/ [4] http://guifi.net/ - English: http://guifi.net/en/node/38392 -- Javi Jiménez Fundació Privada per a la Xarxa Oberta, Lliure i Neutral guifi.net