--- 1/draft-ietf-dnssd-hybrid-02.txt 2016-02-04 22:20:00.138373768 -0800 +++ 2/draft-ietf-dnssd-hybrid-03.txt 2016-02-04 22:20:00.258376773 -0800 @@ -1,18 +1,18 @@ Internet Engineering Task Force S. Cheshire Internet-Draft Apple Inc. -Intended status: Standards Track November 5, 2015 -Expires: May 8, 2016 +Intended status: Standards Track February 4, 2016 +Expires: August 7, 2016 Hybrid Unicast/Multicast DNS-Based Service Discovery - draft-ietf-dnssd-hybrid-02 + draft-ietf-dnssd-hybrid-03 Abstract Performing DNS-Based Service Discovery using purely link-local Multicast DNS enables discovery of services that are on the local link, but not (without some kind of proxy or similar special support) discovery of services that are outside the local link. Using a very large local link with thousands of hosts facilitates service discovery, but at the cost of large amounts of multicast traffic. @@ -41,25 +41,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -572,33 +572,63 @@ information is inefficient, but not fatal. However, when a Hybrid Proxy aggregates data from multiple printers on a link, and sends it via unicast (via UDP or TCP) this amount of unnecessary TXT record information can result in large responses. A DNS reply over TCP carrying information about 70 printers with an average of 700 bytes per printer adds up to about 50 kilobytes of data. Therefore, a Hybrid Proxy that is aware of the specifics of an application-layer protocol such as AirPrint (which uses IPP) can elide unnecessary key/ 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 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 the case that it is wise to start with a clean, layered design, with clear boundaries. Then, in certain special cases, those layer boundaries may be violated, where the performance and efficiency benefits outweigh the inelegance of the layer violation. - As in other similar situations, these layer violations are optional. - They are done only for efficiency reasons, and are not required for - correct operation. A Hybrid Proxy can operate solely at the mDNS - layer, without any knowledge of semantics at the DNS-SD layer or - above. + These layer violations are optional. They are done primarily for + efficiency reasons, and generally should not be required for correct + operation. A Hybrid Proxy MAY operate solely at the mDNS layer, + without any knowledge of semantics at the DNS-SD layer or above. 4.6. Answer Aggregation In a simple analysis, simply gathering multicast answers and 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 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 risks its Unicast DNS response being incomplete. If it waits too long, then it creates a poor user experience at the client end. In @@ -928,23 +958,23 @@ disclosure page [IPR2119]. 10. IANA Considerations This document has no IANA Considerations. 11. Acknowledgments Thanks to Markus Stenberg for helping develop the policy regarding the four styles of unicast response according to what data is - immediately available in the cache. Thanks to Andrew Yourtchenko for - comments about privacy issues. [Partial list; more names to be - added.] + immediately available in the cache. Thanks to Anders Brandt and + Andrew Yourtchenko for their comments. [Partial list; more names to + be added.] 12. References 12.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and