All,

After extensive discussion of the document in the WG, the chairs were asked to consider a call for adoption for this draft:
http://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/
as part of the work surrounding RFC6761 and Special-Use Domain Names. Pursuant to the process and discussion, the decision is not to pursue this draft in DNSOP.

The discussion on this draft was quite lengthy, but also narrow. The justification offered for adding the proposed names to the special use names registry was based on the risk of name collision in the event that ICANN, in its role of providing policy for the public DNS root zone, changes its current policy regarding these names and delegates them.

Concerns were raised in the WG, particularly around our interim meeting on May 12, about defending, generalizing, and scaling the rationale provided for these names. We haven't seen these concerns addressed. The names aren’t being used to signal some sort of semantic or protocol shift, as .onion and various other names we’ve been discussing do. No objective standard was suggested for determining whether other names should be eligible for the special use names registry on the same basis. But using a subjective standard raises questions, from fairness to scalability, that we don’t seem to be well-equipped to answer.

The only reason consistently offered for taking on this draft was that another body might make a decision that we don’t like, and that we should use standards action to stop them. It doesn’t seem to us that such a rationale is workable, either in this specific case or as a general principle for the IETF.

The discussion of this draft and the issues it raised have been helpful to the larger questions of how the IETF might administer the special use names registry in the future. In particular we hope to move beyond “beauty contests” under the process in RFC 6761 to consistent guidelines for applications developers, DNS administrators, and others.

There seemed to be strong feelings among many WG participants that ICANN shouldn’t delegate names into the public DNS that are at serious risk of collision. While we don’t feel this is a good basis for standards action, the IETF has other ways of conveying this message, primarily through its ICANN liaison relationship, and we’ll pursue the possibility of a liaison statement.


Thanks,
The Chairs

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to