dnssdext-charter-BoF87.txt		dnssdext-charter-02.txt
	Currently, zeroconf networking protocols are generally used to		dnssdext Draft Charter, rev -02
	discover services within the scope of a single link. In particular,
			Group Nam: Extensions for Scalable DNS Service Discovery
			Acronym: dnssdext
			Area: Internet Area (int)
			State: Active
			Charter:
			Personnel
			Chairs: <TBD>
			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
			http://www.ietf.org/mail-archive/web/mdnsext (1st/2nd BoF)
			Jabber Chat
			Room Address: xmpp:dnssdext@jabber.ietf.org
			Logs: http://jabber.ietf.org/logs/dnssdext
			http://jabber.ietf.org/logs/mdnsext (1st BoF)
			Background
			----------
			Currently, zero configuration 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		the Bonjour protocols suite, comprising mDNS (RFC 6762) and DNS-SD
	(RFC 6763), are widely used for discovery and resolution of services		(RFC 6763), are widely used for discovery and resolution of services,
	and names on a single link.		as well as names, on a single link.
	The Bonjour protocol suite is commonly used in many scenarios,		The Bonjour protocol suite is commonly used in many scenarios,
	including home networks, commercial and campus enterprise networks,		including home networks, commercial and campus enterprise networks,
	and may be of use in certain mesh networks. However, the multicast		and may be of use in certain mesh networks. However, the zero
	Bonjour protocols are constrained to link-local scope, so can only be		configuration multicast Bonjour protocols are constrained to
	used to discover services on the same link.		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		In a typical current home network, which is commonly a single link,
	should experience the desired discovery behavior. However, in future		users should experience the desired discovery behaviour, because all
	multi-link home networks (as envisaged by the homenet WG) and in		devices share that link. However, in future multi-link home networks
	routed campus or enterprise networks, devices and thus users can only		(as envisaged by the homenet WG) and in routed campus or enterprise
	discover services on the same link, which is a significant		networks, devices and thus users can only discover services on the
	limitation. Such limitations have led to calls, such as those by the		same links, which is a significant limitation. This has led to calls,
	Educause petition, to develop an appropriate solution to span multiple		such as those by the Educause petition, to develop an appropriate
	links, or to perform discovery across a wide area (not necessarily on		service discovery solution to span multiple links, or to perform
	directly connected links).		discovery across a wide area, not necessarily on directly connected
			links, e.g., on links elsewhere on the same site, or links at a remote
			site.
	In addition, the ZigBee Alliance Smart Energy Profile 2.0 commercial		In addition, the "Smart Energy Profile 2 Application Protocol
	standard currently under development has specified the Bonjour		Standard", published by ZigBee Alliance and Homeplug Alliance
	protocols as its method of zero configuration discovery. However, its		specifies the Bonjour protocols as its method of zero configuration
	use of wireless mesh multi-link subnets and its use across traditional		discovery. However, its use of wireless mesh multi-link subnets and
	routed networks will require extensions to the Bonjour protocols to		its use across traditional routed networks will require extensions to
	allow operation across multiple links.		the Bonjour 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		As demand for service discovery across wider area routed networks
	grows, some vendors are beginning to ship their own early solutions.		grows, some vendors are beginning to ship their own early solutions.
	It is thus both timely and important that efforts to develop improved,		It is thus both timely and important that efforts to develop improved,
	scalable, autonomous service discovery solutions for routed networks		scalable, autonomous service discovery solutions for routed networks
	are coordinated towards producing a single, standards-based solution.		are coordinated towards producing a single, standards-based solution.
	Goals:		The WG will consider the tradeoffs between reusing/extending existing
			protocols, and developing entirely new ones. But it is highly
			desirable that any new solution is backwardly compatible with existing
			mDNS and DNS-SD deployments. Any solution developed by the dnssdext
			WG wil 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 dnssdext WG are as follows:		To that end, the primary goals of the dnssdext WG are as follows:
	To document a set of requirements for scalable DNS-based service		1. To document a set of requirements for scalable, autonomous
	discovery in routed, multi-link networks in the following four		DNS-based service discovery in routed, multi-link networks in the
	scenarios:		following five scenarios:
	a) Commercial enterprise networks		(A) Personal Area networks, e.g., one laptop and one printer.
	b) Academic/educational/university campus networks		This is the simplest example of a service discovery network,
	c) Multi-link home networks, such as those envisaged by the		and may or may not have external connectivity.
	HOMENET WG
	d) Multi-link/single subnet (mesh) networks, such as those
	described by the ZigBee Alliance Z-IP specification
	To develop an improved, scalable solution for wide-area service		(B) Home networks, as envisaged by the homenet WG, consisting of
	discovery that can operate in multi-link networks, applicable to		one or more exit routers, with one or more upstream providers
	the scenarios above.		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.
	To develop a BCP for the coexistence of zeroconf (mDNS) and unicast		(C) Wireless 'hotspot' networks, which may include wireless networks
	(global DNS) name services in such multi-link networks, which		made available in public places, or temporary or permanent
	should include consideration of both the name resolution mechanism		infrastructures targeted towards meeting or conference style
	and the namespace.		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 amps scenario.
			(D) Mesh networks such as RPL/6LoWPAN, multi-link but single prefix
			networks, which may or may not have external connectivity.
			The topology may use technologies including 802.11 wireless,
			HomePlug AV and GP, and ZigBee IP.
			It is desirable that remote service discovery is supported, e.g.,
			a user being able to discover services in their home network while
			away from the network, and that co-resident services can be
			discovered, e.g., a printer on a hotel network while the user is
			on a separately administered network at the same location.
			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 neighbouring or non-neighbouring 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 publish an Informational RFC that documents challenges and
			problems encountered in the coexistence of zero configuration and
			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 dnssdext WG takes input from stakeholders in		It is important that the dnssdext WG takes input from stakeholders in
	the scenarios it is considering. For example, the homenet WG is		the scenarios it is considering. For example, the homenet WG is
	currently evaluating its own requirements for naming and service		currently evaluating its own requirements for naming and service
	discovery; it is up to the homenet WG as to whether it wishes to		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		recommend adoption of the solution developed in the dnssdext WG, but
	thus coordination between the WGs is desirable.		coordination between the WGs is desirable.
	Deliverables:		Deliverables:
	The WG will produce three documents: an Informational RFC on the		The WG will produce three documents: an Informational RFC on the
	requirements for wide-area service discovery protocols; a Standards		requirements for service discovery protocols operating on potentially
	Track RFC documenting a wide-area service discovery solution that is		non-neighbouring multi-link networks as described above; a Standards
	applicable to those scenarios; and a BCP document describing the most		Track RFC documenting an extended, scalable service discovery solution
	effective method to integrate mDNS and global DNS name services.		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.
End of changes. 12 change blocks.
	41 lines changed or deleted		135 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/