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. > 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. > 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". 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. 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. You'll note that none of the above takes into consideration any form of commercialization. > 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. > 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. Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
