Comments on IDN Variant TLD Program - Revised Program Plan

[John C Klensin <klensin@xxxxxxx>]

Hi.

I believe all of what I'm about to say has been said before in
comments on earlier documents.  But, since those comments do not
appear to have been reflected in the later documents and
proposals, I'm going to summarize once again for the record,
skipping the many details and contradictions in the draft
program.

There are four fundamental problems with the proposed program
plan (there are others as well, but I don't want to make this
over-long):

(1) A rational reading of the earlier reports and comments is
that we still do not really know what "variants" are, especially
in a language-independent way, that most of the notions of
variant TLDs are incompatible with the actual workings of the
DNS, and probably that the various ideas associated with the
term "variant" are better supported by a single canonical form
in the DNS and user interface localization work as needed.  Put
differently, the strongest arguments for variants are basically
localization issues and the DNS is very poorly suited for direct
support of localization.  While I believe we know more than
enough to reach those conclusions and hence that alternate forms
of "the same" label should be permitted only under very unusual
circumstances, others disagree.  However, the plan does not
admit of the possibility of those conclusions.  It is not
written to encourage ongoing evaluation of the issues and
tradeoffs with a significant possibility of concluding that
variants should not go forward.  It assumes that they not only
will go forward but that it is useful to create a rather complex
and structure to attempt to regularize them and encourage their
use.

(2) While pushing topics such as whole-string variants and
visual similarity studies off into other areas makes superficial
sense, they don't go away.  For example, some of the issues with
whole-string variants will reemerge as issues about conflicts
with trademarks and requirements to defend them.  The effect of
pulling issues like this into separate projects and deferring
others into FY2014 or later is that it becomes that much more
difficult for the Board and other decision-makers to get a
picture of a complex issue with many parts and
interrelationships that is complete enough to make a good
evaluation of tradeoffs and risks.

(3) Complex as it is, this plan ignores important interactions,
such as those between having associated names and the
organization and content of registrant databases.

(4) There is a less expensive, faster, and probably more
effective approach to all of this which has been proposed before
and not considered.  It starts with the observations that there
are few common rules (or generating principles) across scripts
-- a conclusion that is fairly obvious from the first phase
study -- and that the DNS (especially in a world with DNSSec,
storing of many things in the DNS other than address records,
and different applications using the DNS in different ways) is
not very hospitable to names that are somehow considered "the
same".  It also avoids the need for try to figure out what is
and is not a variant in some global algorithmic sense --
something that ICANN has been told repeatedly just won't work
because of language differences within a script but the Program
Plan pretends is right around the corner-- preferring instead to
recognize that two strings are variants if someone is really
certain that they are.    That alternative is to let people
apply  for labels they consider related at the same time, focus
any special efforts on a streamlined objection procedure and
blocking, and permit proactive notification of strings that
would be considered in conflict.  This is not a new
recommendation; it is consistent with the recommendations made
by two committeess reporting to the Board at ICANN 17 in 2003.
And it is simple and straightforward in a context where
complexity (as in the plan unfolding in the project project
plans) is the enemy of transparency and of Internet Stability
and Security.

Thanks for your consideration.
   John C Klensin