Responses to comments on revised project plan

[Andrew Sullivan <asullivan@xxxxxxx>]

Dear IDN Variant TLD Program members,

On behalf of Dynamic Network Services, Inc (Dyn), I am pleased to
provide some comments on the Revised Program Plan discussion.

The Revised Program Plan has attracted support for some of the plan
changes.  Dyn shares that support.  We observe, however, that the CDNC
and to a lesser extent the RySG express support for proceeding at a
different pace for different scripts.  We are troubled by that
suggestion.

The plan makes a distinction -- correctly, in our view -- between
processes and implementation of processes.  On the one hand, the
project addresses both the process by which Unicode code points might
be permitted in the root and the process by which variants might be
determined.  In a subsequent phase, the plan turns to the actual
implementation of those processes.

It is certainly true that, if we can get everyone to agree on the
processes, then the implementation of those processes for different
groups of code points might happen at different rates.  Some code
points will probably not attract very much interest.  But there is no
way to move ahead at different speeds until there is agreement both on
how one would determine what code points are to be permitted, and how
one could determine variants of code points.  Those are procedural
matters that pertain both to the whole of Unicode (including versions
of Unicode not yet published) and to the root zone as a whole.  Such
procedures cannot be developed differently for different language
communities, no matter how well those communities' techniques work in
other parts of the DNS hierarchy.

It might be that people are confused on this matter because of the
Project's unfortunate reversion to the term "tables".  The Integrated
Issues Report distinguished between the code point repertoire for a
zone on the one hand, and the code point variant rules (i.e. the rules
over the repertoire) on the other.  Because these turn out to be
separable (although linked) problems, we think it makes sense to try
to retain the distinction, and to use the terminology the Integrated
Issues Report offered in order to keep the distinctions in mind.  We
think the reversion to the "tables" terminology risks causing people
to start to conflate these different problems, as well as the problem
of other tables in subordinate zones, once again.  That might be what
is happening in the comments received.  There are indeed tables that
are already in use for other zones in the DNS, but the management of
these processes for the root zone is a matter entirely unlike that of
a zone with a more constrained user base.

We believe that the project plan correctly recognizes that any further
action is completely dependent on developing the necessary processes,
and we think it would be a grave error to attempt to proceed
otherwise.

Respectfully submitted,

-- 
Andrew Sullivan
Dyn Labs
asullivan@xxxxxxx