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

[Lyman Chapin <[e-mail]>]

On May 14, 2015, at 4:10 PM, David Conrad wrote:

> Lyman,
> 
>> 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.
> 
> It's not so obvious to me that dangerous/not is a red herring, particularly since that was one of the primary rationales for (appropriately, IMHO) holding up CORP/MAIL/HOME.

No, I meant the call for a bright-line distinction - one that could be objectively determined from measurements. The distinction between "dangerous" and "not" is of course relevant.

>> 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.
> 
> Ignoring the question of how one proves a negative, that would seem to run contrary to the "permissionless innovation" theory of why Internet protocols are good.

Again, I'm not talking about "proving" in an algorithmic sense (of course "proving" a negative in that sense would be a meaningless directive). And I hope it's obvious that "permissionless innovation" isn't a license for anyone to harm others. You're welcome to try out any new idea you like on the Internet, without asking for anyone's permission - unless your new idea breaks something important that other Internet users depend on, in which case, not so much.

>> The "prove that it's dangerous or we'll put it in the root" mindset is explicitly commercial.
> 
> Talk about red herring. In my view, whether it is commercial or not is not relevant here. AFAICT, we're talking about bucketizing labels, either "OK to be in the DNS" or "Placed on the Special Use Registry".

The mindset is commercial in the way in which it prioritizes values in the discussion that we are having about bucketizing labels. I agree that that's what we're talking about.

> 
> I believe that if you want to put something in the latter bucket, there should be a reason and preferably one that can be objectively measured.

I believe that if you want to put something in the former bucket, there should be a reason :-) Really, what we're arguing about is the default condition. The two alternatives are "OK to be in the DNS" and "Not OK to be in the DNS"; "Placed on the Special Use Registry" is a mechanism that is available to implement the second alternative. You are saying that the default is "everything is in the first bucket, and there has to be a good reason to move it into the second bucket." I'm saying the the default should be "everything is in the second bucket, and there has to be a good reason to move it into the first bucket."

> For example, in the case of .ONION, it seems to me that:
> 
> 1) there is a well defined and non-DNS spec for the protocol
> 2) there are multiple independent implementations in active use
> 3) there is a "large" installed base that is growing that is already using the protocol
> 4) the public exposure of queries for the ONION label could be considered a privacy/operational risk
> 
> The first two and last of these are objectively measurable.  The third is a bit sticky since "large" isn't well defined or measurable and thus, you get into a subjective evaluation. I'd personally like to come up with something concrete for (3) to avoid stupid rathole arguments, but due the facts of of (1) and (2) along with my personal assumptions about (3), I support putting ONION into the special use names registry.
> 
> If we apply the above criteria to .CORP:
> 
> 1) there is sort of a spec, in the sense that folks documented .CORP as a recommendation for private namespaces
> 2) there are multiple independent "implementations" in the sense that lots of folks have independently made use of .CORP
> 3) there is a "large" installed base, albeit hopefully it is shrinking
> 4) the public exposure of queries for the CORP label could be considered a privacy/operational risk
> 
> The first and last is objectively measurable. The second and third are a bit unclear, but based on the quantity of queries to the root over a long period of time (at least as far as we can tell from the yearly DITL samples), I personally am comfortable that .CORP would fall into the special use names registry. I would be much happier if we actually had some clear threshold that we could pointed to, but at the above would be a good start.

I would be too.

> You'll note that none of the above takes into consideration any form of commercialization.

No, it doesn't. My original reference was to a commercial mindset, without which we wouldn't be arguing about whether or not CORP should be in the root.

> 
>> The "prove that it's *not* dangerous or we won't allow it in the root" mindset is explicitly operational.
> 
> As far as I am aware, that is not what we're discussing here. For good or ill, my understanding is that RFC 2860 assigned the policy role of what goes into the root to ICANN. What I thought we were talking about was the identification of labels that are to be preempted from consideration of delegation, similar to the IETF reserving 10/8.

That's not what RFC 2860 actually says, but again, I'm talking about mindset - which default condition is the starting point. We are indeed talking about the identification of labels that should not be delegated as TLD names. We disagree (and not very much, at that) about the way in which that identification should be done (and justified).

> 
>> 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.
> 
> This seems unrelated to the Special Use Names registry, but if this mindset were applied to the routing system, the email system, or pretty much any protocol system operationally deployed on the Internet, we might as well close down the IETF because there will always be someone who will argue that the risk associated with introducing new technology outweighs the benefit.

Of course - that's why we have a consensus process in the IETF.

- Lyman