[DNSOP] Questions about draft-adpkja-dnsop-special-names-problem-00

[Stephane Bortzmeyer <[e-mail]>]

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.