> I would be very interested in understanding what technical errors I made and I > would appreciate if you would share the details with me, perhaps off-line. The message sent to the IETF list contains several major technical errors, including: a. Confusing DNS resolver behavior with the behavior of LLMNR implementations. The sending of .local queries to the global DNS, while potentially a serious problem, results from the behavior of existing DNS resolver implementations. This problem exists today on the vast majority of Internet hosts, which do not implement either mDNS or LLMNR. Given this, putting language into the LLMNR specification to "fix" an orthogonal issue makes no sense. Even fixing the issue in another IETF specification could prove sticky, because it can be argued that the IANA has authority over the allocation of new TLDs such as ".local" not the IETF, which is why the DNSEXT WG recommended early on that the ".local.arpa" domain be used instead of ".local". b. Confusion between security issues and namespace separation. In peer-to-peer name resolution protocols, it is possible for a responder to demonstrate ownership of a name, via mechanisms such as DNSSEC. It is also possible for a responder to demonstrate membership in a trusted group, such as via TSIG or IPsec. If DNSSEC is available, spoofing attacks are not possible, and querying for FQDNs does not expose the sender to additional vulnerabilities. Both the mDNS and LLMNR specifications agree on this point. c. Lack of consideration of existing practice. Internet hosts have used multiple name resolution mechanisms based on a single API for more than two decades, with no ill effects. For example, *NIX systems have utilized /etc/host files, NIS and DNS; Windows systems utilize LMHOSTS, DNS and NetBIOS. The issue of integration of multiple name services is dealt within multiple RFCs, including RFC 1001 which defines NetBIOS and describes how it coexists with DNS and RFC 2937, which describes the Name Service Search Option for DHCP. In practice, hundreds of millions of Internet hosts use these mechanisms every day. If you type "http://foo/"; in the browser of a Windows host, a DNS query for "foo" is not sent over the wire; only a NetBIOS query is sent. This is not rocket science. > Please remember, though, that most of my note was not meant to express my own > technical opinion, it was an attempt to summarize the issues that were raised > by others in this discussion. The job of an IESG member is not to repeat mistatements, it is to use their judgement. In this and other instances, the IESG appears to have lost sight of its mission. The best interest of the Internet community lies not in blocking the publication of documents that fall outside today's orthodoxy, but rather in providing information to the Internet community. In this case, that interest would be best served by publishing *all* documents relating to mDNS and LLMNR, especially the ones that the DNSEXT WG has found most objectionable (such as DNS-SD, and Bill Manning's DISCOVER OPCODE draft). I must admit that at one point, I did not see value in funding the RFC Editor to publish documents outside of the IETF process, via the RFC Editor Individual Submission route, described in RFC 3932. However, now it has become abundantly evident that this represents an important safety mechanism that needs to be preserved going forward. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf