Comments on Proposed Implementation Plan for Synchronized IDN ccTLDs

[John C Klensin <klensin@xxxxxxx>]

Thanks for the opportunity to comment on the proposed
Implementation Plan for Synchronized IDN ccTLDs and the
associated decisions and processes. 

I want to stress that nothing in this note should be taken as
an objection to assigning, and delegating, pairs of Simplified
Chinese and Traditional Chinese names to China and Taiwan.
Given my understanding, which began with the JET work described
in RFC 3743, of the writing system involved, the implications
of not having the paired names, and the administrative policies
and experience of the two registries, I believe that the
decision to allocate and delegate the pairs of names is both
necessary and appropriate.  Reasonable fairness suggests that
those who requested them should not be penalized for following
advice and directions from ICANN Staff and Management by having
their delegations delayed.  My concern is, instead, about the
mechanisms ICANN appears to be using in an attempt to allocate
those names, the implications of those mechanisms, and what the
process being followed says about ICANN's ability to deal with
complex issues in a competent, open, and transparent way that
promotes and retains a strong foundation for DNS-based naming
on the Internet. 

The rest of this message is fairly long because, of necessity,
it reviews some of the misunderstandings and missteps that have
led to where we are today, including the difficulties with
Nairobi Resolution 13 and the "synchronized IDN ccTLDs" plan in
its current form.  I want to summarize key observations and a
suggested plan for action first.  Details about each of these
suggestions appear below.

        (1) The Fast Track implementation procedure, Resolution 13,
        and the proposed Implementation Plan for Synchronized IDN
        ccTLDs (referred to simply as "synchronized domains" below)
        contain a good deal of confusing or incorrect terminology,
        some of which serves to disguise policy issues as technical
        ones, but ones that are not actionable (at least consistent
        with interoperability and stability) from an implementation
        and/or operational standpoint.  The ICANN Board has, and
        needs to take, ultimate responsibility for taking those
        policy decisions, and for expressing them clearly.  It must
        not use committees, panels, task forces, lengthy and
        obscure reports, and very long review processes to avoid or
        obscure that responsibility.  In this particular case, if
        the goal is to allocate separate TLDs for Simplified and
        Traditional Chinese, the Board should say that, making
        adjustments and clarifications as described below.

        (2) Evaluation of whether there is a significant and
        substantial need for some capability is entirely a policy
        matter as described above.  There may be technical (or, in
        this case, linguistic or writing system) arguments on one
        side or the other, but they always involve tradeoffs and
        the resolution of those tradeoffs is a matter of policy,
        not a deterministic and objective balancing of facts.  It
        is probably useful to recall something that ICANN knew at
        the very beginning of the IDN discussions: if DNS
        predictability, stability, and security were absolute
        goals, then we have no business doing IDNs at all: even if
        there were no other issues, moving from a repertoire of a
        few dozen characters to tens of thousands is inherently
        problematic.  Paraphrasing Nikolas Wirth, any given
        proposal or plan should be as simple as possible, but no
        simpler.  The current "synchronized domains" model, with
        its reliance on undefined terminology and hidden subjective
        evaluations that are disguised as technical or staff
        functions, violates these principles in several ways.

        (3) There are many deficiencies and gaps in our experience
        with IDNs.  In any case, rules that would be appropriate
        for some kinds of TLDs are not appropriate for others (see
        detailed discussion below). Given those circumstances, no
        one should be surprised that a new procedure is not
        perfect.  Being able to acknowledge flaws, correct them,
        and move forward --and to do so without huge delays or
        complex and time-consuming reevaluation and review
        procedures-- should be seen as a sign of organizational
        maturity and organizational ability to adapt to changing
        information in a changing and evolving Internet, not
        something to be avoided.  If some of the definitions or
        procedures of the Fast Track have proven to be inadequate
        or incomplete, then it is ICANN's responsibility to fix
        them, not to try to convince the community that the Fast
        Track plan was perfect and simply needs some contrived and
        contradictory addition(s).  As a particular example,
        consider the Fast Track procedure's "one string per
        official language or script per country or territory"
        restriction (Section 3.4), (repeated in slightly different
        form in Resolution 13).  That provision effectively
        prohibits allocation of more than one name to a country
        unless it uses at least two languages or writes one
        language in more than one script.  Such a provision is a
        poor match for operational and writing system realities.
        The procedure needs to be fixed to recognize the complex of
        real situations, not obscured through imprecise and
        confusing terminology, the assumption that all strings
        that can be classified as "variants" are the same and
        hence have the same solution, and so on.

        (4) Internationalization is a complicated business, if only
        because cultures, languages, and writing systems differ
        around the world.  The requirements of the DNS, especially
        its simplistic matching rules, do not mesh well with
        reasonable user expectations about internationalization.
        No amount of assuming or pretending that things are simple,
        or even that there are many simple cases, will make it so.
        For IDN purposes, there is also an important distinction
        between Han-derived scripts and alphabetic ones, i.e.,
        everything else (the reasons for this are discussed below).
        Trying to force some "generic" arrangement by treating them
        as the same requires using the same words to describe
        different situations without being clear about the
        redefinition and, by doing so, puts the stability and
        predictability of the DNS at risk.  ICANN probably needs to
        accept that there are issues unique to Han-derived scripts
        (and how they were handled in Unicode) and (different)
        issues unique to alphabetic-based scripts (and how they
        were handled in Unicode) and write its rules accordingly,
        rather than pretending that there are no differences. 



Now, to address the proposed Implementation Plan for
Synchronized IDN ccTLDs ("synchronized domains") document and
the Resolution that called for it:

First of all, the apparent goal of this procedure, stated in
plain English, seems to be to permit countries who have a
significant and substantive requirement to simultaneously
register two (or more) IDN TLDs in the Fast Track to do so.
Resolutions and procedures that try to cloak that goal in
vague, and possibly misleading, terminology about languages and
scripts do not help the community or the applicants and will
probably introduce confusion, confusion that may potentially be
harmful.  Part of what might be obscured is the fact that
evaluation of what I describe as a "significant and substantial
need" is entirely a policy matter for which authority and
responsibility rests in the ICANN Board.  It is not a technical
matter and cannot be decided on narrow, objective, or technical
criteria.  The Board should act like a Board and make the
policy decisions.  An attempt, deliberate or not, to treat it
as a technical matter that can be decided upon by panels,
committees, or staff using objective technical criteria is not
ultimately helpful to the Internet community and leads,
inevitably, to criteria that do not quite work and the need for
retuning processes of which Resolution 13 is an unfortunate
example.

Conversations with people familiar with the development of the
principles described in Resolution 13, including several Board
members, suggest that the (undocumented) intention is to limit
the applicability of the "synchronized TLDs" exception to China
and Taiwan, by establishing criteria that would be
exceptionally difficult or impossible for any other applicant
to satisfy. Needless to say, that is a poor way to formulate
and implement a policy decision. If the Board is convinced that
the Fast Track process should be modified to recognize the
special circumstances of Chinese (as described below) -- an
entirely plausible and defensible conclusion -- it should say
so. Trying to achieve the same effect indirectly, by inventing
terminology and procedures that appear to apply generally to
all applicants, is at best disingenuous.

The document also indicates that all requirements of the Fast
Track still stand.  But the Fast Track procedures give special
treatment to "variants", consigning them to a "hold" status
until and unless a technical solution has been agreed by the
community.  By introducing "synchronized domains" Resolution 13
creates an inherent contradiction:  names associated with such
domains are either "variants" given special treatment outside
the Fast Track or they need to be somehow disjoint from
"variants".   It is not possible for both the "variant-hold"
and "synchronized domain" rules to apply without creating a
contradiction unless the strings associated with "synchronized
domains" are somehow distinct from "variants".  But the latter
distinction is not made in Resolution 13 or elsewhere.

In addition, a technical solution for "variants" is not in the
offing for the near future, in large measure because there has
never been a clear and precise description of requirements.
Given the many constraints imposed by the DNS's protocol and
operational models, including loose convergence, the absence of
facilities to determine the path to a name, and complete
inability to handle lookup or matching differently based on
language or locale, ICANN must allow for the possibility that
some legitimate problem statements will have no adequate
technical solutions.  More generally, many descriptions of
"variants" are possible, with different possible approaches
(some available now as either technical or administrative
procedures; most requiring some DNS changes) being appropriate
for different ones of them.  Given the difference between
strings that are related because of orthographic differences,
visual confusion, variations in input methods, and writing
system reforms, it is nearly certain that the term "variant" is
being used to describe many different situations that require
different solutions.  The odds are low that there is a either
single problem statement or a single technical or
administrative approach that would resolve all problem
statements.  But, as far as I can determine, ICANN has never
made a serious effort to get even one of the problem statements
or set of requirements identified, much less considered the
broader range of issues carefully.  Indeed, ICANN's pattern of
making statements in the IDN area that use language that
different people can interpret in different ways may have
significantly contributed to the present confusion about what
is needed.

If the goal is actually to allocate one extra domain (for
Traditional or Simplified Chinese) to country-applicants for
registration in Chinese script (see below), there are ample
ways to justify that without resorting to this circuitous and
dangerous language.

In particular, it is worth noting that most scholarship on
contemporary writing systems indicates that there are only two
systems in use today -- (i) those derived from a common early
"alphabetic"/ phonetic script and (ii) Chinese and those
derived from it.  (For those interested, more references on
request, but Johanna Drucker's _The Alphabetic Labyrinth_ is
perhaps the most comprehensive work that is easily accessible
to the non-specialist.)  Treating these two very broad
groupings as the same, and trying to use identical rules
without careful consideration, is fraught with danger, whether
one is considering IDN administration, lengths of identifiers,
similarity of glyphs, or other properties or definitions.
There are other ways to look at the situation that can justify
thinking about the Chinese situation differently from other
writing systems without resorting to made-up definitions,
convoluted explanations, vague evaluation criteria, or
"implementation plans" that rest on definitions that have no
clear technical interpretation (see below).

If that doesn't suffice, note that there are other facts that
might justify selecting one particular script and treating it
differently from others without getting involved with
hand-waving or creative wording.  They include:

        *  The number of languages in the world that have undergone
        major writing systems changes within the last hundred
        years, retaining the same script but modifying it
        graphemically: 1 (Russian might be a second candidate, but
        the number of characters affected was around two, not 2000.)
        
        * Number of scripts in active use today with more than
        1000 characters total (to say nothing of "more than
        10000 characters total"): 1
        
        * Number of scripts in active use today with hundreds
        (or more) orthographic variations at the script level: 1
        (Arabic has some of those variations, but only a handful
        of them).


Second, it is almost never helpful to use terminology in a new
way without offering new, and clear, definitions.  It certainly
is not helpful in this case.  In particular, it has bred a
number of discussions in which the one of the two parties
simply did not understand what the other one was talking about
and took a long time to even figure that out.  Throughout the
IDN development process and discussions --in ICANN, in the
IETF, and elsewhere-- the term "script" has been used a way
that is consistent with the Unicode definition and specific
categorization, i.e., as a grouping of closely-related
characters that may be used to write one of more languages and
for which there is a mechanism for determining that a character
belongs to one particular script and no other.  In the Unicode
case, the association of each character (code point) with a
script is part of the Unicode character definition tables.
Consequently, we talk about "Latin script" (really "extended
Latin" or "Latin-based", but the Unicode term is just "Latin")
and not "English script", "Spanish script", "Vietnamese
Script", and so on.  Similarly, we talk about "Arabic script"
and not "script for Arabic language", "Persian script", "Urdu
script" and the like.  And the term "Chinese script" (or "Han
script" or sometimes "CJK") refers to the an enumerated
collection of characters used to write Chinese, Japanese (in
"Kanji" -- "Chinese characters" -- rather than some phonetic
form), and Korean (in Hanji --"Chinese characters"-- rather
than the phonetic Hangul).  In that context, Traditional
Chinese and Simplified Chinese are different subsets of Chinese
script.  Because only a few thousand characters were redesigned
in the early 1950s ("simplified") out of five to seven thousand
in regular use and more than forty thousand recognized
characters, "Simplified Chinese" uses many "Traditional"
characters: "Simplified Chinese" does not represent a list of
characters that are distinct from "Traditional Chinese".

A few people have suggested that an ISO Standard, ISO
15924:2004, can be used to justify the argument that Simplified
Chinese and Traditional Chinese are actually two different
scripts.  That reading of 15924 is clearly inappropriate and,
worse, may illustrate either lack of understanding of, or
indifference to, the issues raised in this comment and
elsewhere.  ISO 15924 is simply a code-registration standard to
facilitate communication about scripts.  It doesn't classify
scripts, identify which characters belong to which scripts, or
put any real restrictions on the assignment of codes other than
an ability to fill out an application that justifies such
assignments.  In it, HANS and HANT are listed as "variants of
Chinese Script" (HANI) without further discussion.  That does
not make them separate scripts any more than the assignment of
LATF and LATG (Latin in Fraktur and Latin in Gaelic) makes the
latter two separate from Latin.

Considered from that perspective, if a specification says "two
scripts", it either needs to use a Unicode-like definition (in
which case Chinese is one script) or it needs to define
"script" much more precisely and, in my opinion at least,
justify that alternate definition and the confusion it causes.
See
http://www.icann.org/en/announcements/announcement-2-22mar10-en.htm
as an example of the problem.  A better solution would be to
define what is actually intended without use of words that mean
something else.

The comments above about "variant" are another instance of this
problem with vague, misleading, or contradictory uses of
terminology.


Third, at a somewhat more technical level, ICANN should avoid
using terms that have no meaning in context with the protocols
that are involved, again at least without precisely defining
them.  Talking about "synchronization" in the DNS is
problematic because the DNS inherently uses a very relaxed
updating procedure.  If that procedure --which just about
guarantees the some sites will see different values than others
if queries are issued at or near the time of update-- is
adequate with reasonable values for refresh times ("slave
update") and time-to-live ("cache update"), then the document
should say so.  If something else is contemplated, then the
document should say that.  While synchronization has a
relatively clear meaning, at least if those time-dependencies
are clear, the document defines synchronized domains in terms
of "convergence" (see paragraph numbered 4ff on page 6), a term
that is reasonably clear in a DNS context, a meaning that
appears to be inconsistent with the way these documents are
using it, and whose common-sense meaning is probably
inappropriate.

Similarly, in DNS contexts, "allocation", "registration", and
"delegation" all have reasonably clear, but different,
meanings.  However, some of the relevant ICANN documents use
the terms as if they were interchangable, thereby adding to
confusion about what is being discussed.

I know that at least some of the Board members who were on (or
should have been on) the ES-WG understand DNS operations to a
more than adequate degree to understand the problems with
casual use of such terms.  I don't know why their understanding
was not reflected in the Board resolution, but clearly it was
not.  Even if that knowledge were not present on the Board, it
would not have taken a great deal of consultation with the
community to make that information available (indeed, some of
that consultation did occur, but did not affect the
Resolution).  I suggest that the Board may need to review its
own procedures in order to avoid this type of disconnect in the
future.


Finally, it is a well-established administrative principle that
one should not make requirements that one has no hope of
enforcing.  The Fast Track, including these new proposed
procedures, applies to ccTLDs and hence, in most cases, to the
activities of sovereign states.  It is traditionally very
difficult to enforce contracts (or other agreements) between a
private sector entity in one country and sovereign states.
Unless ICANN has discovered a way to avoid that issue, e.g., by
assuming judicial powers and getting countries to formally
submit to ICANN jurisdiction, it would be much more helpful for
a procedure like this one to carefully examine the criteria for
compliance, the consequences of non-compliance, and hence why
it is in the best interests of a country and of the Internet
for that country to comply.  Instead, ICANN elaborates on
development of "adequate and verifiable" procedures (with no
clear evaluation criteria) that, presumably, ICANN intends to
enforce but where no one else will take that intent seriously.

In conclusion, the uniqueness-preserving and stability
requirements that are prominent among ICANN's objectives
require both precision of language and definitions and complete
alignment with technical and operational realities so that all
actors can ensure, to the degree possible, that they know what
is required and that they actually are sharing assumptions and
information.  This document stands in contradiction to those
objectives.  It should be revised to be more clear about
objectives (e.g., dropping hand waving about "more than one
language or script"), to take responsibility for clear and
unambiguous statement of goals and, as appropriate,
technological and administrative expectations, and to be sure
that all terminology is either consistent with common usage in
the relevant areas or is carefully and precisely defined in the
documents.