draft-ietf-dnssd-hybrid-02.txt		draft-ietf-dnssd-hybrid-03.txt
	Internet Engineering Task Force S. Cheshire		Internet Engineering Task Force S. Cheshire
	Internet-Draft Apple Inc.		Internet-Draft Apple Inc.
	Intended status: Standards Track November 5, 2015		Intended status: Standards Track February 4, 2016
	Expires: May 8, 2016		Expires: August 7, 2016
	Hybrid Unicast/Multicast DNS-Based Service Discovery		Hybrid Unicast/Multicast DNS-Based Service Discovery
	draft-ietf-dnssd-hybrid-02		draft-ietf-dnssd-hybrid-03
	Abstract		Abstract
	Performing DNS-Based Service Discovery using purely link-local		Performing DNS-Based Service Discovery using purely link-local
	Multicast DNS enables discovery of services that are on the local		Multicast DNS enables discovery of services that are on the local
	link, but not (without some kind of proxy or similar special support)		link, but not (without some kind of proxy or similar special support)
	discovery of services that are outside the local link. Using a very		discovery of services that are outside the local link. Using a very
	large local link with thousands of hosts facilitates service		large local link with thousands of hosts facilitates service
	discovery, but at the cost of large amounts of multicast traffic.		discovery, but at the cost of large amounts of multicast traffic.
	skipping to change at page 2, line 6		skipping to change at page 2, line 6
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 8, 2016.		This Internet-Draft will expire on August 7, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 15, line 29		skipping to change at page 15, line 29
	information is inefficient, but not fatal. However, when a Hybrid		information is inefficient, but not fatal. However, when a Hybrid
	Proxy aggregates data from multiple printers on a link, and sends it		Proxy aggregates data from multiple printers on a link, and sends it
	via unicast (via UDP or TCP) this amount of unnecessary TXT record		via unicast (via UDP or TCP) this amount of unnecessary TXT record
	information can result in large responses. A DNS reply over TCP		information can result in large responses. A DNS reply over TCP
	carrying information about 70 printers with an average of 700 bytes		carrying information about 70 printers with an average of 700 bytes
	per printer adds up to about 50 kilobytes of data. Therefore, a		per printer adds up to about 50 kilobytes of data. Therefore, a
	Hybrid Proxy that is aware of the specifics of an application-layer		Hybrid Proxy that is aware of the specifics of an application-layer
	protocol such as AirPrint (which uses IPP) can elide unnecessary key/		protocol such as AirPrint (which uses IPP) can elide unnecessary key/
	value pairs from the DNS-SD TXT record for better network efficiency.		value pairs from the DNS-SD TXT record for better network efficiency.
			Also, the DNS-SD TXT record for many printers contains an "adminurl"
			key something like "adminurl=http://printername.local/status.html".
			For this URL to be useful outside the local link, the embedded dot-
			local hostname needs to be translated to an appropriate name with
			larger scope. Dot-local names are easily translated when they appear
			in well-defined places, either as a record's name, or in the rdata of
			record types like PTR and SRV. In the printing case, some
			application-specific knowledge about the semantics of the "adminurl"
			key is needed for the Hybrid Proxy to know that it contains a name
			that needs to be translated. This is somewhat analogous to the need
			for NAT gateways to contain ALGs (Application-Specific Gateways) to
			facilitate the correct translation of protocols that embed addresses
			in unexpected places.
			As is the case with NAT ALGs, protocol designers are advised to avoid
			communicating names and addresses in nonstandard locations, because
			those "hidden" names and addresses are at risk of not being
			translated when necessary, resulting in operational failures. In the
			printing case, the operational failure of failing to translate the
			"adminurl" key correctly is that, when accessed from a different
			link, printing will still work, but clicking the "Admin" UI button
			will fail to open the printer's administration page. Rather than
			duplicating the host name from the service's SRV record in its
			"adminurl" key, thereby having the same host name appear in two
			places, a better design might have been to omit the host name from
			the "adminurl" key, and instead have the client implicitly substitute
			the target host name from the service's SRV record in place of a
			missing host name in the "adminurl" key. That way the desired host
			name only appears once, and it is in a well-defined place where
			software like the Hybrid Proxy is expecting to find it.
	Note that this kind of Application-Specific Data Translation is		Note that this kind of Application-Specific Data Translation is
	expected to be very rare. It is the exception, rather than the rule.		expected to be very rare. It is the exception, rather than the rule.
	This is an example of a common theme in computing. It is frequently		This is an example of a common theme in computing. It is frequently
	the case that it is wise to start with a clean, layered design, with		the case that it is wise to start with a clean, layered design, with
	clear boundaries. Then, in certain special cases, those layer		clear boundaries. Then, in certain special cases, those layer
	boundaries may be violated, where the performance and efficiency		boundaries may be violated, where the performance and efficiency
	benefits outweigh the inelegance of the layer violation.		benefits outweigh the inelegance of the layer violation.
	As in other similar situations, these layer violations are optional.		These layer violations are optional. They are done primarily for
	They are done only for efficiency reasons, and are not required for		efficiency reasons, and generally should not be required for correct
	correct operation. A Hybrid Proxy can operate solely at the mDNS		operation. A Hybrid Proxy MAY operate solely at the mDNS layer,
	layer, without any knowledge of semantics at the DNS-SD layer or		without any knowledge of semantics at the DNS-SD layer or above.
	above.
	4.6. Answer Aggregation		4.6. Answer Aggregation
	In a simple analysis, simply gathering multicast answers and		In a simple analysis, simply gathering multicast answers and
	forwarding them in a unicast response seems adequate, but it raises		forwarding them in a unicast response seems adequate, but it raises
	the question of how long the Hybrid Proxy should wait to be sure that		the question of how long the Hybrid Proxy should wait to be sure that
	it has received all the Multicast DNS answers it needs to form a		it has received all the Multicast DNS answers it needs to form a
	complete Unicast DNS response. If it waits too little time, then it		complete Unicast DNS response. If it waits too little time, then it
	risks its Unicast DNS response being incomplete. If it waits too		risks its Unicast DNS response being incomplete. If it waits too
	long, then it creates a poor user experience at the client end. In		long, then it creates a poor user experience at the client end. In
	skipping to change at page 23, line 34		skipping to change at page 23, line 34
	disclosure page [IPR2119].		disclosure page [IPR2119].
	10. IANA Considerations		10. IANA Considerations
	This document has no IANA Considerations.		This document has no IANA Considerations.
	11. Acknowledgments		11. Acknowledgments
	Thanks to Markus Stenberg for helping develop the policy regarding		Thanks to Markus Stenberg for helping develop the policy regarding
	the four styles of unicast response according to what data is		the four styles of unicast response according to what data is
	immediately available in the cache. Thanks to Andrew Yourtchenko for		immediately available in the cache. Thanks to Anders Brandt and
	comments about privacy issues. [Partial list; more names to be		Andrew Yourtchenko for their comments. [Partial list; more names to
	added.]		be added.]
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<http://www.rfc-editor.org/info/rfc1034>.		<http://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
End of changes. 7 change blocks.
	13 lines changed or deleted		43 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/