Summary of Comments and Discussions Regarding The Draft Interim Report of the IDNC WG
Comments on DRAFT Methodology for Fast Track Overview (Public) Comment & Discussion Included are the comments on and summary of public discussions on the Draft Interim report of the IDNC WG. The comments are inserted in the related section of the Report and can be distinguished through the different fonts. The text of the draft report is in Verdana. The reflection of the public discussions, in particular of the Dubai meeting on 2 April 2008 is in Tahoma The submitted comments are in Courier 1. Introduction The purpose of the fast track is to introduce a limited number of non-contentious IDN ccTLDs to meet near term demand. The goal of the IDNC WG is to recommend a Fast Track model that contains a mechanisms for the selection of an IDN ccTLD string, and a mechanism to designate an IDN ccTLD manager. The model needs to take into account the overarching requirements of stability and security; IDNA protocols and IDN guidelines; input of the technical community in respect to implementation of IDNs; and current practices for the delegation of ccTLDs. The IDNC WG published for comment a draft Initial Report, to canvass the topics that need to be covered. There seems to be consensus that the questions raised in the draft Initial Report did canvass the areas that any proposed mechanisms would need to cover. Comment and input was also received addressing some of the possible answers to the questions raised in the draft Initial Report. Based on our understanding of the substantive input to the draft Initial Report we think there is a rough consensus on the following points: A: Ongoing Process The Fast Track should be an ongoing process, which ends when the overall IDN ccTLD policy has been adopted by the ICANN Board. Thus an IDN ccTLD manager can enter the fast track when ready. The window of opportunity has no fixed end-date. RyC IDNC Comments, Chuck Gomes, 24 Apr 2008 * We support efforts to determine the feasibility of an interim solution whereby a limited number of countries or territories designated in the ISO 3166-1 list that have special needs would be granted IDN labels in the near term provided that no IDN TLDs associated with countries or territories are introduced earlier than IDN gTLDs without prior community concurrence. B: Non pre-emption of overall policy The Fast Track must not pre-empt final IDN ccTLD policy so must be a simple, clear and limited solution. C: Purpose of Fast Track is to meet pressing demand The Fast Track should only be available where there is a pressing demand in the territory. The existence of this demand is evidenced by the readiness of the IDN ccTLD manager and relevant stakeholders in the territory to meet the requirements to introduce an IDN ccTLD under the Fast Track. The territory needs to be ready to use the IDN ccTLD and to demonstrate that readiness. Summary of IDN Discussion in Dubai (2 April 2008) Question: What is "pressing demand"?. Answer: The concept of the methodology is that pressing demand is demonstrated by the meeting off the fast track criteria ie. that the registry is technically ready, a string has been defined and certain IANA criteria are fulfilled. RyC IDNC Comments, Chuck Gomes, 24 Apr 2008 Any added IDN label for a country or territory designated in the ISO 3166-1 list should be for the sole purpose of benefiting the language community (or communities) and country or territory designated by the new label. D: Fast Track only for non-Latin scripts As the Fast Track has been initiated to meet near term demand for IDNs and to avoid pre-empting the outcome of the ccPDP, the script has to be a non-Latin script. E: The proposed string and delegation request should uncontroversial within the territory The two mechanisms should only allow for the delegation of a non-contentious string for an IDN ccTLD and designation of a non-contentious IDN ccTLD manager. F: The Fast Track is experimental in nature In devising the mechanisms and the Fast Track process, the experimental nature of the introduction of IDN ccTLD should be taken into consideration. This should be reflected in the implementation of the processes for selection of an IDN ccTLD string and designation of an IDN ccTLD manager. Summary of IDN Discussion in Dubai (2 April 2008) Question: Does this imply that there will be a roll-back if a technical flaw is noticed? Answer: The security and stability of the DNS are paramount. The delegation of IDNs is experimental and nobody knows what will happen when IDNs are deployed so, yes, it is possible that some sort of roll-back procedure will need to be agreed prior to delegation. Further, it is also important to note that the Fast Track itself is experimental also in respect to methodology used and that that the outcome of the fast track experience would feed into ccPDP. Comments from the Arabic team for domain names regarding the fast track draft interim report (Ibaa Oueichek, 22 April 2008) 1) The report clearly identifies the Purpose of Fast Track as "to meet pressing demand". However, it defines its scope as "experimental in nature". Our worry is regarding the meaning of "experimental". "Experimental" should not mean that: - The fast track delegations are temporary - The registered domain names during the fast track could become invalid at a later stage! - It should not discourage the application developers from putting their full support to IDN SaudiNIC's comments on DRAFT Methodology for Fast Track, Abdulaziz Al-Zoman, 23 Apr 2008 Idem comment Ibaa Oueichek (above) ADNPP's Comments on the Discussion Draft of the Interim Report of the IDNC Working Group, Abdulaziz Al-Zoman, Wed, 23 Apr 2008 Idem comment Ibaa Oueichek ( above) Comments by the National Telecom Regulatory Authority of Egypt on the Draft Methodology for Fast Track . Christine Arida, 24 April 2008 * Experimental in nature: The report defines the scope of the fast track as "experimental in nature". This should not mean that the fast track delegations will be temporary. It should rather mean that all parties should collaboratively work together on solving any problems that may occur. G: Limiting the number of applications The criteria to select the IDN ccTLD string, and to designate the IDN ccTLD manager should determine the number of eligible IDN ccTLDs, not an arbitrarily set number. RyC IDNC Comments, Chuck Gomes, 24 Apr 2008 - There should be only one IDN ccTLD string per ISO 3166-1 entry per relevant script. Measures must be taken to limit confusion and collisions due to variants. - Confusingly similar strings should be avoided. In section 2 a model is proposed that we think meets the above points and the guiding principles. This model is based on a four stage approach which maps and follows the activities, roles, and responsibilities of the actors involved. The model is devised to enable the relevant actors in the territory to self-asses and determine whether delegation of IDN ccTLD under Fast Track process is feasible, and enable them to prepare for a delegation request. Section 3 contains notes on definitions and section 4 contains notes on the proposed testing stage (stage 3). 2. Proposed Fast Track model Stage 1: Preparing for the Fast Track in Territory This part of the process is performed in territory by the local actors involved. RyC IDNC Comments, Chuck Gomes, 24 Apr 2008 * An IDN ccTLD string must represent an entry contained in the ISO 3166-1 list. 1. Identify the language and script for the language - criteria: must be 'official' language (see section 3) - criteria: fast track is only for non-Latin scripts 2. Prepare language table - may already exist prepared by another territory using same language/script. - fast track should encourage cooperation, in accordance with IDN guidelines 3. Identify String - must meet technical and meaningful requirements Public Discussion Dubai, 2 April 2008 Comment re 3. Identify String: It would be good if the IDNC group could come up with advice that territories should as a general rule use their short name for the string. Otherwise governments may try to use the full names - which would not be good for stability. RyC IDNC Comments, Chuck Gomes, 24 Apr 2008 * IDN ccTLD strings should be meaningful to the local community and should represent, in scripts of the corresponding country or territory's choice, a meaningful representation of the country or territory's name or abbreviation of the country or territory's name in the selected script. 4. Select intended IDN ccTLD registry 5. Get evidenced endorsement by actors in territory of proposed string and IDN ccTLD registry - Government, Local Internet Community, existing ccTLD manager Stage 2: Evaluation 1. Place language table into IANA Repository 2. Have string checked/evaluated by 'Technical Committee' and 'Language Committee' (see section 3). Intermediate change of Report, by Chris Disspain, 13 April 2008 Stage 2: Evaluation & Confirmation 2. Have string checked by 'Technical Committee' and confirmed by ' Committee of Linguistic Experts' (see section 3). Source: Public Discussion Dubai, 2 April 2008. Question re 2. Have string checked by 'Technical Committee' and confirmed by 'Committee of Linguistic experts' against criteria: What is the role of the 2 committees and how would they operate? Answer: The Technical Committee's role is to check the string to ensure that it meets the IDNA Protocol and guidelines. The Linguistic Committee's role is to confirm that the string meets the official language and meaningful criteria. It is envisaged that the Technical Committee will need to check every string proposed. However the Linguistic Committee's role is much more limited since it would only need to confirm that the string meets the criteria in circumstances where the proposed string was not listed as the short name or formal name in the Technical Reference Manual for the Standardisation of Geographical Names (see http://unstats.un.org/unsd/geoinfo/ungegn%20tech%20ref%20manual_M87_combined.pdf). It is also envisaged that the Linguistic Committee would call on linguistic experts in the particular language to confirm that the string meets the criteria. On Stage 3: Reporting Question: Where testing is done would that require actual registrations? Answer: No. This refers to technical testing not registrations.. Stage 3: Testing 1. Have string.test delegated to ICANN and managed by proposed IDN ccTLD registry. 2. Experiment with string.test for 90 days (see section 4). 3. After 90 days complete and submit report on string.test phase (see section 4). 4. Complete IANA request for delegation documentation. Intermediate change of Report, by Chris Disspain, 13 April 2008 Stage 3: Reporting 1. Document experience with managing IDNs, including use of the proposed language table at second or higher levels & implementation of IDN guidelines and compliance with IDNA protocol. 2. Complete IANA request for delegation documentation. Comments by the National Telecom Regulatory Authority of Egypt on the Draft Methodology for Fast Track. Christine Arida, 24 April 2008 * Reporting: It should be made clear how reporting would affect the delegation on a IDN ccTLD. Only technical problems should delay delegation until they are worked out. Stage 4: Designation of IDN ccTLD Request for delegation - In accordance with current IANA procedures - Insert string in the root according to appropriate procedures - Update Root zone file 3. Definitions Official language: For the purpose of the Fast Track, an 'official' language is one that has a legal status in the territory or that serves as a language of administration. This definition is based on: "Glossary of Terms for the Standardization of Geographical Names", United Nations Group of Experts on Geographic Names, United Nations, New York, 2002. For the purpose of the Fast Track a language could be demonstrated to be an official language: 1. If the language is listed as an ISO 639 language in Part Three of the Technical Reference Manual for the standardisation of Geographical Names, United Nations Group of Experts on Geographical Names (UNGEGN) < http://unstats.un.org/unsd/geoinfo/default.htm>; 2. If listed as administrative language for the relevant territory in ISO 3166-1 standard under column 9 or 10; or 3. It is demonstrated/evidenced that the language is used in official communications of the relevant public authority in the territory and serves as a language of administration. Comments from the Moroccan National Telecommunications Regulatory Agency (ANRT) regarding the DRAFT Methodology for Fast Track EL MAAYATI Afaf, 24 April 2008, The link between point "a" and "b" is not made (if it's an "and" or an"or"). Does it indicate that we should have: condition "a" and (condition "b" or "c")? Meaningful string: For purpose of the Fast Track process a string is meaningful if it is: a) the name of the territory in the selected language; or b) a part of the name of the territory in the selected language denoting the territory in that language; or c) an acronym of the name of the territory in the selected language denoting the territory in that language. If the proposed string is demonstrated to be listed as such in the Technical Reference Manual for the standardisation of Geographical Names, UNGEGN, Part Three column 3 or 4, it is considered to be meaningful for the purpose of the Fast Track. In other cases, it has to be demonstrated in another way. Language Committee: A small committee tasked with checking that the proposed string is in a language that is 'official' in the territory and is meaningful in accordance with the definition. Intermediate change of Report, by Chris Disspain, 13 April 2008 Committee of Lingsuitic Experts: A small committee tasked to confirm that the proposed string is meaningful in accordance with the definition. Technical Committee: A small committee tasked with checking the proposed string against the IDNA Guidelines to ensure it will not cause any technical issues (for example a string in Cyrillic that appears to be the same as a string of ASCII characters). 4. Testing stage The string.test phase of the Fast Track serves the following purposes: a) The intended IDN ccTLD manager gains experience with the IDN ccTLD; b) The stakeholders in the territory are prepared and informed on the possible introduction of the IDN ccTLD and have the opportunity to demonstrate support and endorsement of the selected language, script and string for IDN ccTLD; c) There can be technical testing of the language table and proposed string and the opportunity for the intended IDN ccTLD manager to demonstrate and evidence compliance with IDNA protocols and guidelines and the maintenance of security and stability; d) To enable the IDN ccTLD manager, at the end of the 90 day test period, to provide a report which covers at least following: (i) Compliance with IDNA protocols and guidelines and how it was demonstrated in string.test phase; (ii) Community use of and any potential limitations of language/script table; (iii) Statistics on use; (iv) Overview of any problems using the IDN ccTLD (similar to the current wiki tests in example.test) (v) Involvement in string.test phase of local internet community, relevant public authorities and ccTLD manager, demonstrating near term demand. (for instance by providing user statistics, public consultations and information sessions etc.) Intermediate change of Report, by Chris Disspain, 13 April 2008 4. Reporting experience stage The purposes of reporting is: a) The intended IDN ccTLD manager documents its experience with IDN's; b) The stakeholders in the territory have been prepared and informed on the possible introduction of the IDN and have the opportunity to demonstrate support and endorsement of the selected language, script and string for IDN ccTLD; c) There has been testing of the language table and the opportunity for the intended IDN ccTLD manager to demonstrate and evidence compliance with IDNA protocols and guidelines and the maintenance of security and stability; The intended report would cover at least following: (i) Compliance with IDNA protocols and guidelines and how it was demonstrated in test phase; (ii) Community use of and any potential limitations, and problems relating to the use of the intended language/script table; (iii) description of potential cross-TLD registration conflicts, and intended resolution process, if any (for instance sunrise, dispute resolution methods); (iv) Statistics on use; (v) Involvement in testing of local internet community, relevant public authorities and ccTLD manager, demonstrating near term demand. (for instance by providing user statistics, public consultations and information sessions etc.) Comments from the Moroccan National Telecommunications Regulatory Agency (ANRT) regarding the DRAFT Methodology for Fast Track EL MAAYATI Afaf, 24 April 2008, (iv) Statistics on use; As the IDN domain names are available for an experimental use in the country, the statistics in this case will not be significant. Additional Topics, not covered by methodology Agreement with ICANN: Source: Public discussion Dubai 2 April 2008-06-09 Paul Twomey indicated that ICANN would expect any IDN ccTLD manager to enter into an agreement with ICANN at the very least, specifically relating to IDN issues. It was clarified that it was not the job of the Working Group to make recommendations to the board how to deal with this or recommend such a legal arrangement. However, the Working Group may decide to make a statement such as "Although delegation should be treated the same way as an ordinary ccTLD, there are specific IDN related issues that need to dealt with in an agreement". The attendees were asked whether they felt that the principle of signing a piece of paper between the operators and ICANN was acceptable. There seemed to be a general acceptance of the principle. One of the participants said that it would actually be desirable to have such a document in place but it would need to be provided in a translated format. It was asked whether the ccTLD would need to sign an Accountability Framework for the Ascii ccTLD before the IDN ccTLD will be delegated. It was clarified that this would not be required. A comment was made that in a worst-case scenario, where a delegation needs to be withdrawn due to technical stability issues, some sort of agreement would be useful. ICANN was requested to publish a document prior to the Paris meeting setting out the matters and issues that would need to be covered by an agreement with the IDN ccTLD manager. , Source: Comments from the Arabic team for domain names regarding the fast track draft interim report (Ibaa Oueichek, 22 April 2008) 2) Regarding delegation of IDN ccTLDs - Countries/registries should not be forced to sign documents/agreements they believe would limit their full control over their IDN ccTLDs - Signing documents/agreements may involve very heavy and slow governmental process that contradicts the fast track concept SaudiNIC's comments on DRAFT Methodology for Fast Track Abdulaziz Al-Zoman, 23 Apr 2008 Idem comment Ibaa Oueichek ( above) ADNPP's Comments on the Discussion Draft of the Interim Report of the IDNC Working Group, Abdulaziz Al-Zoman, Wed, 23 Apr 2008 Idem comment Ibaa Oueichek ( above) Comments by the National Telecom Regulatory Authority of Egypt on the Draft Methodology for Fast Track . Christine Arida, 24 April 2008 * Agreements: Countries / registries may be encouraged to sign some light weight agreements with ICANN, yet this should not be a condition for IDN ccTLDs delegation. RyC IDNC Comments, Chuck Gomes, 24 Apr 2008 * Operators of top-level domain registries for IDN TLDs representing territories designated by the ISO 3166-1 list should be required to follow the ICANN IDN Guidelines in the same way as gTLD registries that offer IDNs. * ICANN should have a contract or some other form of agreement with the IDN ccTLD operator that includes appropriate technical, operational and financial requirements. ( confirming position GNSO Council) Objection Procedure: Edmon Chung ( member of the IDNC WG) suggested that such a mechanism should be included along with the technical evaluation or linguistic confirmation procedure as it would increase the integrity of the process. Chris Disspain said that he felt that it would be very challenging having such a mechanism in place, as it was an outside objection mechanism, which would mean that another territory or a company or a registry could object to a string proposed by the territory even if that string met the criteria.. Manal Ismail added that if the government and the community agree that the chosen string denotes the name of the territory, and if necessary the linguistic committee confirms , there should be no further input needed. Comments by the National Telecom Regulatory Authority of Egypt on the Draft Methodology for Fast Track . Christine Arida, 24 April 2008 * Objection procedure: Given that, o Each country has the right to choose the string /name that represents its IDN ccTLD o Fast Track is a fast process o Fast Track deals only with non-contentious stings / names o Fast Track deals only with non-contentious applications o Fast Track accepts only strings/names agreed on by all 3: Government, current registry and local community o Fast Track approves only strings/names approved by the technical committee o Fast Track approves only strings/names confirmed by the linguistic committee There should be no need for an objection procedure seeking more confirmations or approvals before a string is delegated. IANA Guidelines: It was pointed out that IANA needs to update their guidelines for who is eligible to submit language tables to the IANA Repository. Currently, only existing registries can do so. The guidelines need to open up for language table submissions from registries-to-be as well. Comments by the National Telecom Regulatory Authority of Egypt on the Draft Methodology for Fast Track . Christine Arida, 24 April 2008 * Submission of language tables to IANA: Only current registries are allowed to submit language tables to IANA. Process should consider opening up for registries-to-be as well. ICANN Staff Contact: Bart Boswinkel Attachment:
2008-06 Summary of public Discussions on the Draft Interim Report of the IDNC WG (BB) |