Revised Draft ToR for GNSO IDN Policy Development Activities

Preamble

The following terms of reference are focused on GNSO activities and therefore address gTLD considerations. Following the posting of the "Issues Report for IDN at the Top-Level", its terms of reference have been reviewed in the light of the outcome of the Amsterdam meeting 29-31 August 2006 on the New gTLD PDP and the subsequent GNSO Council call 28 September. It is proposed that policy development activities relating to the introduction of generic Top-Level Domains with IDN Labels (IDN-gTLDs) shall be guided by the following considerations:

• Given the urgency of current interest in fully localized domain names, and the limited range of potential outcomes of the impending technical tests of devices for entering top-level IDN labels into the root zone, the policy for the inclusion of IDN-gTLDs can begin to be assessed.
• Policy development will proceed under the assumption that top-level IDN labels will be entered into the root zone, conditional upon the outcome of the requisite initial trials.
• The Amsterdam meeting on the New gTLD PDP reached conclusions of both direct and indirect importance for policy aspects on new IDN-gTLDs, inter alia:

1. Each application for a new IDN-gTLD should be regarded as applying for a wholly new gTLD
2. Applicants should be treated consistently, whether from an existing gTLD operator or a new entrant
3. Applications for IDN and non-IDN gTLDs should be judged by applying the same policies, as far as at all possible
4. There should be possibilities to apply for IDN-gTLD labels in the first new gTLD round, with approval to proceed to insert a IDN-gTLD label into the root conditional upon the results of the technical tests
5. The string checking requirements for IDN labels should be consistent with those for non-IDN labels (see section 2.5 of Draft new gTLD recommendations at: http://gnso.icann.org/issues/new-gtlds/recom-summary-14sep06.htm )
6. Contractual conditions for any new gTLD should include obligations to abide by IETF IDN standards and ICANN IDN guidelines. (See also IETF RFC4690: Review and Recommendations for Internationalized Domain Names (IDNs) http://www.rfc-editor.org/rfc/rfc4690.txt dated September 2006)

Terms of Reference

1. Initial and General Provisions, "Phase I"

   1. As an initial task, plan the necessary activities and interaction steps in cooperation with ICANN staff, and develop a suitable timeline that takes into account the timeline for the technical tests. Such interaction would include interaction with the ccNSO, GAC, SSAC, RSAC, and ccTLD managers as required.
   2. In general, during all of the steps, identify and document any policy issue for which it is essential that policy is harmonized for all IDN-TLDs and develop the related policy for IDN-gTLDs in interaction with other relevant entities, including other ICANN Supporting Organizations and Advisory Committees, in a way that ensures harmonization of the policy outcome.

   3. In particular, as a priority activity, identify any specific rules that should apply to the choice of IDN gTLD labels, inter alia:

      c1. What rules should govern IDN-gTLD label minimum length?

      c2. What rules should govern permissible script/language in an IDN-gTLD label? By inference from the ICANN IDN Guidelines it seems advisable that all characters/symbols within a single IDN-gTLD label should be from a single identified script and from a single identified language table within that script.

      c3. Should the script/language used for an IDN-gTLD label be exclusively propagated on all lower levels in the sub-domain tree (allowing for the general exceptions attaching to that script as referenced in the ICANN IDN Guidelines)? (It should be noted that there is no such restriction in place for current gTLDs.)

   4. d. The outcome of the above steps in Phase I, including recommendations regarding issues essential for the first round, should be reported to the Council. If adopted by the Council, such recommendations should be put forward for implementation in the first round, subject to Board approval. Other issues should be addressed in phase 2.

Additional issues to address, "Phase II"

a. Consider all issues identified during Phase I that are not essential to resolve for launching the first round, but may be of importance during future operation. Examples of such issues could be a) Whether modifications of the present UDRP would be needed for IDN gTLDs and b) Whether modifications of the WHOIS rules would be needed to facilitate use for end-users with different scripts.