Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
- The following addresses had permanent fatal errors - dnssdext-requ...@ietf.org (reason: 550 5.1.1 dnssdext-requ...@ietf.org: Recipient address rejected: User unknown in virtual alias table) 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.i...@gmail.com Tim Chown t...@ecs.soton.ac.uk Assigned Area Director: Ted Lemon ted.le...@nominum.com Mailing list Address: dnssd...@ietf.org To Subscribe: dnssdext-requ...@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
Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
On 3 Oct 2013, at 18:07, manning bill bmann...@isi.edu wrote: - The following addresses had permanent fatal errors - dnssdext-requ...@ietf.org (reason: 550 5.1.1 dnssdext-requ...@ietf.org: Recipient address rejected: User unknown in virtual alias table) I think the active list is still mdns...@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.i...@gmail.com Tim Chown t...@ecs.soton.ac.uk Assigned Area Director: Ted Lemon ted.le...@nominum.com Mailing list Address: dn...@ietf.org To Subscribe: dnssd-requ...@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.i...@gmail.com Tim Chown t...@ecs.soton.ac.uk Assigned Area Director: Ted Lemon ted.le...@nominum.com Mailing list Address: dnssd...@ietf.org To Subscribe: dnssdext-requ...@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
Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
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 bmann...@isi.edu wrote: - The following addresses had permanent fatal errors - dnssdext-requ...@ietf.org (reason: 550 5.1.1 dnssdext-requ...@ietf.org: Recipient address rejected: User unknown in virtual alias table) I think the active list is still mdns...@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.i...@gmail.com Tim Chown t...@ecs.soton.ac.uk Assigned Area Director: Ted Lemon ted.le...@nominum.com Mailing list Address: dn...@ietf.org To Subscribe: dnssd-requ...@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.i...@gmail.com Tim Chown t...@ecs.soton.ac.uk Assigned Area Director: Ted Lemon ted.le...@nominum.com Mailing list Address: dnssd...@ietf.org To Subscribe: dnssdext-requ...@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
Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
Discussion of IETF consensus activities is supposed to occur on the IETF mailing 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. Sorry for the confusion.
Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
On Oct 3, 2013, at 3:05 PM, manning bill bmann...@isi.edu wrote: but the To Subscribe pointer is busted…. Correct. I should have gotten the information right before sending out the announcement, but I blew it—sorry about that.
Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
but the To Subscribe pointer is busted. According to https://www.ietf.org/mailman/listinfo the list is supposed to be https://www.ietf.org/mailman/listinfo/mdnsext. jaap
Re: [mdnsext] WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
On Oct 3, 2013, at 3:46 PM, Jaap Akkerhuis j...@nlnetlabs.nl wrote: but the To Subscribe pointer is busted. According to https://www.ietf.org/mailman/listinfo the list is supposed to be https://www.ietf.org/mailman/listinfo/mdnsext. mdns...@ietf.org was used for the two BoFs. The WG will be dnssd, and the mailing list will be dn...@ietf.org (which, I air, is not what is shown in the charter header). - Ralph jaap ___ mdnsext mailing list mdns...@ietf.org https://www.ietf.org/mailman/listinfo/mdnsext
WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
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.i...@gmail.com Tim Chown t...@ecs.soton.ac.uk Assigned Area Director: Ted Lemon ted.le...@nominum.com Mailing list Address: dnssd...@ietf.org To Subscribe: dnssdext-requ...@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
Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
Discussion of IETF consensus activities is supposed to occur on the IETF mailing 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. Sorry for the confusion.
Re: WG Review: Extensions for Scalable DNS Service Discovery (dnssd)
On Oct 3, 2013, at 3:05 PM, manning bill bmann...@isi.edu wrote: but the To Subscribe pointer is busted…. Correct. I should have gotten the information right before sending out the announcement, but I blew it—sorry about that.
