X-Apparently-To: [log in to unmask] via 206.190.49.197; Tue, 08 Aug 2006 03:01:22 -0700 X-Originating-IP: [192.0.35.121] Authentication-Results: mta246.mail.re4.yahoo.com from=melbourneit.com.au; domainkeys=neutral (no sig) Received: from 192.0.35.121 (EHLO greenriver.icann.org) (192.0.35.121) by mta246.mail.re4.yahoo.com with SMTP; Tue, 08 Aug 2006 03:01:21 -0700 Received: from greenriver.icann.org (greenriver [127.0.0.1]) by greenriver.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k789wvX5004823; Tue, 8 Aug 2006 02:58:58 -0700 Received: (from majordomo@localhost) by greenriver.icann.org (8.12.11.20060308/8.12.11/Submit) id k789wv3w004822; Tue, 8 Aug 2006 02:58:57 -0700 X-Authentication-Warning: greenriver.icann.org: majordomo set sender to [log in to unmask] using -f Received: from pechora2.icann.org (pechora2.icann.org [192.0.34.37]) by greenriver.icann.org (8.12.11.20060308/8.12.11) with ESMTP id k789wvoA004819 for <[log in to unmask]>; Tue, 8 Aug 2006 02:58:57 -0700 Received: from melbourneit.com.au (mail.MelbourneIT.com.au [203.31.199.194]) by pechora2.icann.org (8.13.7/8.13.7) with ESMTP id k789wiEC022657 for <[log in to unmask]>; Tue, 8 Aug 2006 02:58:49 -0700 Received: from balius.mit (localhost.mit [127.0.0.1]) by melbourneit.com.au (8.11.6/8.11.6) with ESMTP id k789whR29168 for <[log in to unmask]>; Tue, 8 Aug 2006 19:58:43 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [council] Regarding Redrafted IDN ToR Date: Tue, 8 Aug 2006 19:58:43 +1000 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding Redrafted IDN ToR Thread-Index: Aca33NSQViYkQVe2TROFpiATru6cxAC8eeOQ From: "Bruce Tonkin" <[log in to unmask]> To: "Council GNSO" <[log in to unmask]> X-Virus-Scanned: ClamAV 0.88.3/1640/Mon Aug 7 18:11:04 2006 on pechora2.icann.org X-Virus-Status: Clean X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-1.6 (pechora2.icann.org [192.0.34.37]); Tue, 08 Aug 2006 02:58:50 -0700 (PDT) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by greenriver.icann.org id k789wvoA004820 Sender: [log in to unmask] Precedence: bulk Content-Length: 2569 Hello All, I have updated Olof's last draft slightly - by adding in a few examples to help clarify the meaning of the text. See below. Regards, Bruce Tonkin Preamble The following terms of reference for further work are focused on GNSO activities and therefore address gTLD considerations. Subsequent to working group assessment of the Preliminary Issues Report, the terms of reference were adopted by the GNSO Council on xx August 2006. In addition, the GNSO Council resolved 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: I. 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. II. Policy development will proceed under the assumption that top-level IDN labels will be added to the root zone, awaiting the outcome of the requisite initial trials. III. Determining that a proposed new IDN label is adequately differentiated from a pre-existing label requires comparison in graphic, phonetic, and semantic terms. Two levels of differentiation are necessary, of which the one pertains to situations where the two labels are being considered for delegation to the same organization, and the other where the labels are to be delegated to independent organizations. The former case can be further subdivided into two situations. In the one, the intention is for the same set of sub-domain names to appear under multiple TLD labels (e.g given example.tld1, you will also find the equivalent example.tld2), and in the other independent name trees are to be established (ie given example.tld1, the label "example" may not exist in .tld2). IV. It is necessary to be particularly mindful of detail which, although initially considered in the IDN context, may otherwise be relevant to the New gTLD PDP. The association of two separate TLD labels with the same meaning is an example of this (e.g .warm and .chaud, or .lib and .bib), given that the linguistic justification for such action can as easily be derived from two languages that can be adequately represented using ASCII characters as it can from a situation where one or both labels require IDN representation. V. The implementation of policies based on an aliasing mechanism (e.g where example.tld1 resolves to the same location as example.tld2) may require the development of new technical resources if the tests of the currently available alternatives (as referenced in I above) determine that none are viable. In general, care should be taken to recognize distinctions between technical and policy concerns, as well as cultural and political considerations. Addressing their manifold interdependencies should be approached as collaborative action with other organizations as appropriate to any given case. VI. In view of the complexities and interdependencies involved in the policy development task, the pre-determined standard PDP timeline must be adapted to allow sufficient time for all the necessary activities and interaction steps. Terms of Reference 1. Initial and General Provisions a. As an initial task, in line with Consideration VI above, plan the necessary activities and interaction steps for this PDP in cooperation with ICANN staff, and develop a suitable timeline for the PDP 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. b. In general, during this PDP, 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. 2. Selection Criteria for Top-Level Domains with IDN Labels a. Taking into account the background, considerations and findings regarding selection criteria in the New gTLD PDP [PDP-Dec05], develop modified or additional criteria for the inclusion of IDN labels in subsequent action toward ICANN's goals of expanding the use and usability of the Internet. 3. Allocation Methods for Top-Level Domains with IDN Labels a. Taking into account the background, considerations and findings regarding allocation methods in the New gTLD PDP [PDP-Dec05], develop modified or additional allocation methods that may be applied to gTLDs with IDN labels. 4. Policy to Guide Contractual Conditions for Top-Level Domains with IDN Labels a. Taking into account the background, considerations and findings regarding contractual conditions in the New gTLD PDP [PDP-Dec05], develop policies to guide the specific contractual criteria needed for gTLDs with IDN labels, to be made publicly available prior to any application rounds. 5. Additional Policy Aspects Regarding Top-Level Domains with IDN Labels a. With specific regard to Consideration III above, determine whether the script used for an IDN-gTLD label can, or should, 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). If such a procedure is viable, intention to implement it may serve as a differentiation criterion or otherwise be invoked in the consideration of a request for a new label.