draft-adpkja-dnsop-special-names-problem-00 raises several issues, some are non-issues, some, if accepted, may deserve a 6761bis and some do not.
1) "The discussions in the DNSOP WG and the IETF Last Call processes about the .onion registration in the Special Use Domain Names registry (1,200 messages) have made it apparent [...]" This sentence seems to imply that the long and painful discussion of .onion registration was because RFC 6761 is incomplete and/or unclear. But one could say as well that *every* discussion regarding TLD allocation will generate many messages: the subject is hot, and highly political and, I would dare to add, a lot of money is at stake, which makes it even more sensitive. 2) "The requirements of the operators of recursive resolvers in the DNS cannot be relied upon to be implemented" This observation is right. This could be added in a 6761bis, or in a new document "Observations on RFC 6761" but it was obvious from the beginning (we cannot rely on our beautiful RFCs to be implemented everywhere, nothing new, or specific to special-use domain names). 3) "At the time of writing, the [RFC6761] registry does not include direct guidance for any of the seven audiences, relying instead upon a reference for each entry in the Registry to the document that requested its insertion." I've heard (but it does not appear to be in draft-adpkja-dnsop-special-names-problem-00) that some implementors regret there is no formal way to derive code from the special-use domain registry (doing it by hand is not a problem if the registry stays small). Why not mentioning the possibility of an addition to RFC 6761: a formal language to express the expected behaviour of software, allowing programs to be automatically derived from the registry? (Personal note: I could be volunteer to work on it.) Questions like "Can/Should applications do this check dynamically?" could receive a reply there (obvious reply: "that's local policy"). "Useful reservations of top-level domains should be accompanied by documentation of realistic expectations of each of the seven audiences" But it *is* the case. Simply, it is not in the registry (but in the referenced RFC) and it is not in a formal language. But it exists (RFC 6761, section 5). 4) "In particular, if the IETF formalizes this concept in the Internet architecture, coordination will be require between ICANN and IETF on such names." That's why there is an official liaison between IETF and ICANN. I assume ICANN was duly informed of the discussion about .onion. I fail to see why it is regarded as a problem. 5) "For example, it is not clear who is responsible for carrying out an evaluation." Wrong, it is specified in RFC 6761 "an IETF "Standards Action" or "IESG Approval" specification [RFC5226] MUST be published describing the new functionality". (Note the "or", which the draft calls an "inconsistency".) 6) "For example, is large scale prior deployment an acceptable criteria?" Such a criteria would be useless if you cannot define precisely how you measure "large scale prior deployment". Hint: traffic at the DNS root is not a good metric (too easy to fake it). I notice also that the requirments of IETF to P2P developers who want "their" TLD to be reserved, are inconsistent: we ask them to reserve the TLD in advance, before deployment, and at the same time we ask them to prove that there is an existing deployment! 7) "When processing gTLD applications, ICANN has a process to review those to check if the proposed names are potentially offensive to certain communities, have political ramifications, etc.. It is worth asking if the IETF should have a similar process in place to evaluate specific proposed reserved names" Huge NO here: the ICANN process is very expensive, arbitrary, long, and copying it is not certainly the best use of IETF time. Editorial: "the reserved names could be any label in any random string, not just the rightmost one" The draft should say "most significant" (or "last"), not "rightmost", which is not i18n-neutral. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
