Re: [DNSOP] Interim DNSOP WG meeting on Special Use Names: some reading material

[Lyman Chapin <[e-mail]>]

On May 14, 2015, at 11:21 AM, David Conrad wrote:

> <snip>
> However, as I said, how it is labeled is somewhat irrelevant. What matters to me is figuring out the objective criteria by which we can determine whether and/or how a particular label is being used so much that its delegation in the DNS would damage the Internet's security/stability.  So far, all the criteria I've seen to date boils down to Justice Stewart's "I know it when I see it" which makes me uncomfortable.

I understand the desire to have objective criteria, but in this case your call for a bright-line distinction between "dangerous" and "not dangerous" labels is an obvious red herring. Among other things, it assumes a default mindset that is the opposite of what I hope the IETF would embrace. You seem to be saying that unless we can prove, using a numerical algorithm that could be published in an RFC, that a particular label is dangerous, then by default it should be permitted in the root as a TLD name. My argument is that the burden of proof should run in the other direction: that unless we are very sure that putting something in the root will *not* cause stability or security problems, we should keep it out.

The "prove that it's dangerous or we'll put it in the root" mindset is explicitly commercial. It assumes that the default value is the economic benefit to a potential registry operator, and that in order to justify denying that benefit, we must be convinced that allowing it would cause damage to the Internet. (The actual criterion promoted by ICANN is "clear and present danger to human life," which sets the bar rather higher than "damage to the Internet.")

The "prove that it's *not* dangerous or we won't allow it in the root" mindset is explicitly operational. It assumes that the default value is the stable operation of the Internet for the benefit of its users, and that in order to justify risking that benefit, we must be convinced that the gain outweighs the potential loss.

My sense is that for most people, particularly those in the IETF who are directly concerned with the engineering and operation of the Internet, the gain (to be generous) from adding a particular new TLD to the root is not even close to commensurate with the potential loss if that new TLD arrives with the risks that corp/home/mail (at least) carry. It's not about quantifying "how many SSL certs" or "how much pre-delegation traffic to the root" constitutes "danger"; it's about assessing all of the dimensions of operational risk and deciding in favor of stability as the core value. Of course that shouldn't be done frivolously, and of course there are ways to artificially promote other strings as "risky" - but sorting those concerns is what the IETF's consensus development process does.

I realize that if the answer to the question "why can't we delegate CORP as a new TLD?" is "because the consensus of the IETF is that doing so would present an unjustifiable risk to the operational stability of the Internet," the people who stand to benefit from that delegation will be less happy than if the answer were "because we have measured X, Y, and Z, and have found that X and Y both exceed the thresholds established by RFC 9000 for acceptable stability risk." I agree that that is a legitimate concern for ICANN. But I don't think it's a legitimate concern for the IETF -

- Lyman