Comment on Proposed Implementation Plan for Synchronized IDN ccTLDs
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 string(s). 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. Background: 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 script/language. 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 script. I specifically want to point out the following in the final document from the IDNC WG of ICANN [http://www.ccnso.icann.org/workinggroups/idnc-wg-board-proposal-25jun08.pdf]: 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 |