ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

Comment on Proposed Implementation Plan for Synchronized IDN ccTLDs

  • To: sync-idn-cctlds@xxxxxxxxx
  • Subject: Comment on Proposed Implementation Plan for Synchronized IDN ccTLDs
  • From: Patrik Fältström <patrik@xxxxxxxxxx>
  • Date: Tue, 13 Apr 2010 18:22:20 +0200

These are my personal comments on the proposed implementation plan for 
synchronized IDN ccTLDs.

Let me start with my recommendations, and then try to explain the rationale. 
The recommendations might make things sound very simple, and easy, which of 
course it is not. We talk about very complex deliberations that have to be 
made, but more about that after the recommendations:

A. Treat the current rules and guidelines as what they are, guidelines. I think 
most people do understand what the goal is, specifically if one read the IDNC 
Working Group report, and find that the ultimate goal is "that there is a 
pressing need that Territories after they demonstrate consensus on string(s) in 
their area can request delegation(s) of those strings".

B. Specifically, loosen up the rule "one string in each language/script". 
Having strict such rules will definitely lead to problems, and specifically 
lead to ICANN policy (definition of the terms "script" and "language") might 
conflict with the local definition in the territory that applies for the 

C. Acknowledge (like is done in the Q&A) that technical mechanisms for keeping 
two branches of the DNS namespace in sync does not exist. Because of this, any 
discussions on synchronization is policy and administrative matters.

D. Because of [C], stop completely talking about synchronized idn-ccTLDs. 
Specifically, stop having special contractual agreements with the applicant 
where policing and audit are important parts of the process. Instead, go back 
to the recommendation in the IDNC Working Group Report that say the following, 
so that any ideas on synchronization between two branches of the DNS namespace 
end up being a local policy in the registry/tld, and not an ICANN issue:

D.1. An applicant can if demonstrated there is a need, request delegation of 
multiple strings

D.2. ICANN verifies that the applicant do have a language table and policy in 
place [but not the content of those]

It is my belief that all of these changes are possible by clarifying some 
resolutions by ICANN board, and those changes does not have to be viewed as 
revocations of such decisions. Specifically now when to some degree the board 
resolutions, the paper on synchronization and the Q&A are to some degree 
conflicting with each other, new board resolutions might in fact be needed to 
clarify the confusion that exists in the DNS community.


I have been following the discussions around IDN since long before I was one of 
the editors of the original IDN standard in the IETF. During that time, all of 
us discussing the topic have found many things that sounds simple at first, but 
in reality are very difficult. Like the following things (with comments):

1. The ability to make a decision on what is "the same"

Specifically, knowing what is "the same" of course is the basis for both 
knowing what can be confusing for users (phishing comes into mind) and what one 
want to be equal (as in being "a match" when looking things up in DNS). It is 
in the DNS technically, as others have pointed out, very well defined what is 
equal, and everything else must be various mappings, bundles, language tables 
and what not.

2. The definition of "language", "script" and similar terms

Unfortunately some people have their own view on what these terms (and others) 
might imply. Over time, at least when talking about IDN in the Unicode Context 
(as we do in the IETF) at least "script" is defined as what the Unicode 
Consortium has defined as "scripts" 
[http://unicode.org/Public/UNIDATA/Scripts.txt]. While "language" is still 
pretty undefined. Using these terms in various rules that are supposed to be 
objective of course because of this lead to turn the objective rules to 
subjective decisions. Unintentionally, but that is how things work.

Specifically, I think the following issues are very problematic with the 
current approach by ICANN, and the reason I propose the above:

3. The strict requirement to only delegate one (1) combination of 

This rule of course depends on the definition of "script" and "language", but 
specifically it might create problems  with any limitations on requests related 
to the "script" or language properties. Reason for this is that in many cases 
two potential labels from the same territory might use the same script. One 
typical example is the case if one want to have two strings, one in simplified, 
and one in traditional chinese. Both are in the Han script. There are most 
certainly other examples where, if nothing else, local cultural rules and even 
legislation makes it impossible to allocate only one of two strings in the same 

I specifically want to point out the following in the final document from the 

  Recommendation 4
  In the event that there is more than one Official
  Language in the Territory, it may be possible for
  the Territory to use the Fast Track for the delegation
  of an IDN ccTLD in each of those languages

4. Requirement on registry to ensure synchronization.

I do not feel comfortable with ICANN setting requirements further down the DNS 
tree than the immediate delegation. There is for me a big difference between 
having ICANN ensuring for example language tables exists, and making a 
judgement on the quality of those language tables (that might include bundles, 
similar to some kind of "synchronization"). The actual policy should be set by 
the local internet community, and ICANN can and should only verify that the 
discussion has taken place. All other requirements are on the registry (only). 
ICANN should not interfere in the local policy making process related to the 
TLDs being allocated. Thinking of how ICANN end up being part of the appeals 
process for a possible rejected delegation in the 4th level in the DNS tree do 
make me stay awake at night, specifically when thinking of the need for 
policing and audit that ICANN might have to do. This is not specific for IDN 
ccTLDs, but for all TLDs. ICANN should set overall requirements, based on 
technical criteria (for example, that a TLD is delegation only, that wildcard 
is not to be used etc), on the TLD, and how the registry is operating (that the 
registry uses epp, and acknowledges the ICANN registrar accreditation process 
etc), but be very careful on injecting itself in further discussions related to 
operations and policy.

Attachment: PGP.sig
Description: This is a digitally signed message part

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy