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