Comments on "Implementation Plan for Synchronized IDN ccTLDs"

[HiroHOTTA <hotta@xxxxxxxxxx>]

Please find comments to "Implementation Plan for Synchronized 
IDN ccTLDs" below.

Hiro Hotta, JPRS (.JP ccTLD)


===== comments =====

Thank you for giving us opportunity to comment on such an important 
issue - the Implementation Plan for Synchronized IDN ccTLDs. 

In my limited knowledge, I recognize that some mechanism such as 
synchronized IDN ccTLDs should exist for Chinese(Han)-script ccTLDs 
if IDN ccTLDs ever exist for Chinese-language community.  Two 
strings were requested as IDN ccTLDs corresponding to .cn (and to 
.tw) and were claimed to resolve to the same address or value.  I 
support the requester's claim that those two strings should coexist 
and should resolve to the same address or value for 
Chinese-language community.  I believe there are cases where this 
kind of situation stand for other languages/script communities.

Based on this belief, I recognize IDN ccTLD Fast Track Process 
should tolerate an extraordinary case that requires Synchronized 
IDN ccTLD mechanism and I would pay my respects for ICANN that has 
intention to create the procedure and make Synchronized IDN ccTLDs 
in existence.

I comment on the following points on the process to approve
the Synchronized IDN ccTLDs, taking a stance that Synchronized IDN 
ccTLDs under certain conditions should be accepted.


(1)

Traditional Chinese characters and Simplified Chinese characters 
coexist in one script (Han script) that is a written form of 
Chinese language.  The requested two IDN ccTLD strings 
corresponding to .cn differ only by having the so-called 'variant 
characters', one of which has Traditional form and the other has 
Simplified form.  Same applies to requested IDN ccTLD strings 
corresponding to .tw.  Namely, more than one Chinese IDN ccTLD 
strings having variant characters, which are regarded as equivalent 
characters, are presented in ONE LANGUAGE and ONE SCRIPT.

However, "2.1 Synchronized IDN ccTLDs" in the Criteria for
participation says "more than one official language or script
exists within a corresponding country/territory" is required.  
This requirement does not cover cases with variants in one 
official language and one script such as .cn and .tw cases.  So, I 
comment that "more than one official language or script exists 
within a corresponding country/territory" be excluded from the 
definition of Synchronized IDN ccTLDs.


(2)

The procedure for convergence should not be a scheme to merely 
fix divergence which has already occurred, but a mechanism by 
which divergence cannot occur.  Enforcing a procedure to bring 
divergence down is generally difficult when divergence ever takes 
place.

Therefore, if adequately effective technical mechanism is in place 
at this moment, such mechanism should be clearly specified in this
document as an example to address this issue.  If such mechanism 
does not exist, procedure suggested by the requester will be 
evaluated using relatively vague criteria.  However, the 
requirements laid out in page 4 do not clearly present criteria to 
judge how they are satisfied, which will lead to arbitrary
evaluation based on different knowledge level and discretion of
different evaluators.

To address this, either of the following measures will be 
necessary : 
(a) clarify technical solution(s) that is secure enough, and 
    obligate applicant to declare its compliance to the solution(s)
(b) appoint evaluators with sufficient knowledge and ability to 
    make judgment
If measure (a) is nonexistent, taking measure (b) is practical.  It 
is expected that requester proposes a full procedure to take care 
of the divergence.  In addition, selection of very capable 
evaluators is expected.


(3)

In light of the original concept of "Synchronized", divergence must 
be eliminated.

Section 5. of "Evaluation of Requests" in page 6 mentions "to remove 
any divergence that might occur".  This should be interpreted that 
the measures involve removal of Resource Record(s) of (at least the 
second and further) proposed TLD(s) from the root zone at the last 
resort.  Without this measure, the procedure is not regarded secure 
enough.

It should be required for the requesters to indicate in the 
proposed procedure the way to shift to the state of convergence 
when new and safer technical solution(s) comes out, and when 
divergence occurs.  In addition, a last resort process of 
removing Resource Record(s) of (at least the second and further) 
proposed TLD(s) should be added to the requirements for request for 
Synchronized IDN ccTLDs, in order to prepare for the case where 
divergence cannot be removed to a sufficient level.

====