On 7/14/15, 15:24: >The IESG has received a request from the Domain Name System Operations WG >(dnsop) to consider the following document: >- 'The .onion Special-Use Domain Name' > <draft-ietf-dnsop-onion-tld-00.txt> as Proposed Standard Having read the document plus Ted Hardie's and David Conrad's (who happens to be my boss in real life) comments, I see the documentation as insufficient. As David says, .onion-names use is independent (to some extent) on whether "onion" is registered in the Special Use Domain Names registry. What I am writing here isn't a statement about whether "onion" is to registered, but about the document applying for registration. The document defines the use of the name by referring to a couple of references, none of which appears to be published in a way that can be referenced except by URL. Not to say that the documents seen are poorly written, still there's no evidence of peer review nor stable reference point. (One reference is a well prepared PDF, loaded on Jan 23, 2013 with many other documents to a website that itself has this blurb at the bottom: "Historical page reflecting onion-router.net as of 2005, not regularly maintained. Address questions to...") This is not a critique of the content of the PDF, just the ability to rely on it for a decision. The document also shows no evidence of the deployment of the use of the names below "onion." In David's email, and in others, there are comments regarding an "installed base". I've only seen any discussion about an installed base in email, this is not in the documents. In (say) 50 years, what matters is what is in the published RFC, not the mailing lists. Presence in the documents being put forward is important. (E.g., has anyone consulted the annual DNS-OARC DITL data to measure how often "onion" names are seen at root servers during that collection?) Drilling into the criteria that are presented. Not all of them. 1. Users. The draft states "human users are expected to recognize .onion names as..." How are users supposed to recognize them as (special)? In as much as the document says nothing about evidence of deployment and adoption, how can an expectation be developed? If I hadn't been reading the thread on DNSOP, I wouldn't have thought "onion" was special - but I live in a cave, so what I think isn't important. 4. Caching DNS Servers and 5. Authoritative DNS Servers I really believe that for DNS elements, there should be no change. By intent, the onion names are not to be presented to the DNS by what's in category 2 and 3 (Applications and Name Resolution API's respectively). I see placing any requirement on DNS elements - and by that I mean the software used to implement the DNS standard - as a bad idea, under the heading of "permanent fix to a temporary situation." (I.e., Tor may not be permanent, if it is, as software matures onion names will not be in DNS queries.) 6. DNS Operators Having had experience with that field, I don't see this being a reliable "rule." In general, when a customer loads a zone into a system, there's no way to check whether they have the "right" to use the name. This is more an issue I have with RFC 6761 and in general how the documents are used in operations than a comment on the "onion" application. Nevertheless, I wouldn't rely rule on operators, given that anyone can set up a name server (the code is free and privileged user accounts are easy on laptops), to be an effective means to enforce name restrictions. 7. DNS Registrars/Registries This is the place where a case should be made for the registering "onion" as a Special Use Domain Name. Given the story to date, that "onion" is not to be in the DNS, then don't change the protocol (5,6 above) but then set up barriers to putting it in the DNS (7 here). If you do that, then Name Resolution libraries (3 above) will return "name error" or NXDOMAIN to all queries in the onion domain of names. I see this as where registry policy documents can "point" (by reference) to a list of names that are specially reserved or restricted. I'm agreeing with Ted in that this application is insufficient. I'm agreeing with David in that designating "onion" in such a way as to fix the "CAB Forum" stuff is acceptable. My concern is that, if this application proceeds as documented, the precedent being set could be regrettable.
<<attachment: smime.p7s>>