Meeting Agenda for Rework Group Meeting re. GNSO Response to ccNSO/GAC Issues Paper on IDN ccTLDs

8 January 2008

Members: Belal Beirm, Edmon Chung, Olga Cavalli, Tina Dam, Avri Doria, Liz Gasster, Chuck Gomes, Adrian Kinderis, Stefanie Lai, Denise Michel, Olof Nordling

1. Welcome
2. Agenda approval
3. Meeting schedule
1. Tuesday, 8 January - 20:00 UTC [ 04:00 Hong Kong, 07:00 Melbourne (next day), 12:00 PST, 15:00 EST, 17:00 Buenos Aires, 21:00 CET]
2. Tuesday, 15 January - 22:00 UTC [06:00 Hong Kong, 09:00 Melbourne (next day), 14:00 PST, 17:00 EST, 19:00 Buenos Aires, 23:00 CET]
3. Tuesday, 22 January - 22:00 UTC [06:00 Hong Kong, 09:00 Melbourne (next day), 14:00 PST, 17:00 EST, 19:00 Buenos Aires, 23:00 CET]
4. Suggestion: Keep Tuesday, 29 January open at 22:00 UTC if possible.
4. Discuss and confirm live meeting approach used in the last meeting:
1. Liz will serve as the group editor during the meeting, making live edits as possible and making edits shortly after the call in cases where that is no possible.
2. All group members are encouraged to cut and paste a copy of the latest Google online document in advance of the meeting for reference during the call as needed.
5. Discuss edits made in the 18 December call.
1. Confirm footnote 1 in the Introduction.
2. Any additional questions or comments regarding the Introduction?
3. Defer discussion of the Executive Summary until the end.
4. Section A (Responses to Issues Paper Questions - Interim and Overall Approach to IDN ccTLDs):
   • GNSO recommendations 1 & 2
   • GNSO recommendation 3 – note the parenthetical insert
   • GNSO recommendation 4
6. Continue discussion of the document from the end point of discussion on 18 December
1. Section A (Responses to Issues Paper Questions - Interim and Overall Approach to IDN ccTLDs)
   • GNSO recommendation 5
   • 2 nd ¶
   • 3 rd ¶
2. Section B - Comments regarding issues and questions in the ccNSO/GAC report [Note: 1) Questions from the issues paper have been copied for frame of reference; 2) It will not be possible to cover all remaining questions in this meeting.]
   1. General issues regarding IDN ccTLDs
      • Which ‘territories’ are eligible for an IDN ccTLD?The existence of IDNs as ccTLDs assumes a direct relationship between an IDN TLD string and a ‘territory’ as in ASCII ccTLDs.
        1. Should this relationship be maintained?
        2. If so, should the ‘territories’ which are potentially eligible for IDN ccTLDs be exactly the same as the ‘territories’ that are listed in the ISO-3166-1 list?
        3. If not, should another list be used or should another mechanism be developed?
        4. Should anything be done about ccTLDs already being used as gTLDs?
      • Should an IDN ccTLD string be “meaningful”?
        1. Is there an obligation to make the IDN ccTLD string 'meaningful' in its representation of the name of a ‘territory’? For example, whereas .uk is 'meaningful' because it is a commonly used abbreviation for United Kingdom, .au is not 'meaningful' because the commonly used abbreviations for Australia are Oz or Aus.
        2. If so, how is “meaningful” determined and by whom?
      • How many IDN ccTLDs per script per ‘territory’?
        1. Should there similarly be only a single IDN ccTLD for a given script for each ‘territory’ or can there be multiple IDN ccTLD strings? For example, should there be only one equivalent of .cn in Chinese script for China or .ru in Cyrillic for Russia?
        2. Could there be several IDN strings for a ‘territory’ in a script? If so, who would determine the number and what are the criteria?
        3. If an IDN ccTLD string is not applied for, for whatever reason, should an IDN ccTLD string that could be associated with a particular ‘territory’ be reserved or protected in some way?
      • How many scripts per ‘territory’?
        1. Can a ‘territory’ apply for more than one IDN ccTLD string in different scripts if more than one script is used to represent languages spoken in that location? For example in Japan more than one script is used to represent the Japanese language. In other words, should there be a limit on the number of scripts each territory can apply for?
        2. In what circumstances would it be appropriate to seek to introduce a limit on the number of scripts a ‘territory’ may choose to introduce for a ccTLD or any TLD with a national connection?
        3. Can a ‘territory’ apply for an IDN ccTLD string even if the script is not used in a language with any ‘official status’ in that ‘territory’? For example, if the Kanji script is accepted under the IDNA protocol, can Australia apply for a representation of Australia in that script even though neither the script nor any language deriving from it has any 'official' status in Australia?
        4. If ‘official status’ is required who will define it and who will determine it in each case?
      • Number of characters in the string?
        1. Should all IDN ccTLD strings be of a fixed length, for example by retaining the two-character limitation that applies to ASCII ccTLD labels, or can they be of variable length? If a variable string length is introduced for IDN ccTLDs, should it also be introduced for ASCII ccTLDs?
        2. Does moving outside the current 2 symbol limitation create any security, stability or integrity issues?
        3. Who determines the appropriate label used to represent a new IDN ccTLD string, and how are the set of characters used to represent this label selected?
      • Are there any ‘rights’ attached to a given script?
        1. In purely technical terms, a script is a collection of symbols. However, each of those collections of symbols when put together in particular ways produce the ‘languages’ of groups of people sometimes defined by borders, although very often not. These groups are often referred to as language communities. Should such groups (or their governments) have special rights regarding those scripts? For example, should the Korean language community be entitled to restrict the use of the Hangul script? If special rights exist what is the procedure to exert these rights and resolve conflicts?
        2. Can anyone get acceptance of a script under the IDNA protocol or are there restrictions? For example, can a gTLD registry get the Kanji script accepted under the IDNA protocol? Should that use be vetted/approved by Japan? If yes, would the same requirement apply if a script is used in more then one ‘territory’?
        3. Should it be possible to adopt two or more ‘versions’ of a script with only minor differences for use under the IDNA protocol and are there issues or concerns should this occur?
   2. Introduction of IDN ccTLDs
      • Should a list of IDN ccTLD strings be mandated?
        1. Is such a list necessary?
        2. Who would develop such a list?
        3. Should such a list be mandated?
        4. If yes, by whom?
        5. Who would develop the criteria and relevant policies for identifying IDN ccTLDs?
        6. Under what policy or authority would the list be created?
        7. If additional criteria and or policies are required, who is responsible for formulating that policy?
      • What precedence should be given to ccTLDs in the IDN implementation process?
      • Who selects the IDN ccTLD string in the absence of a mandated list? If IDN ccTLD strings are not going to come from a mandated list then, how does an IDN ccTLD string become designated as the string for a particular ‘territory’?
        1. What are the criteria and policies to determine who can submit a request for the designation of an IDN ccTLD?
        2. Who will develop the criteria and policies for determining the designation of an IDN ccTLD?
        3. How will such issues as competing requests (both domestic and international) be dealt with?
        4. What will happen if 2 ‘territories’ are eligible for the same or confusingly similar strings for IDN ccTLD?
      • What coordination should exist between the different actors? The deployment of IDN ccTLDs will require coordination among various actors, within territories and ICANN constituencies. Irrespective of the methodology employed, some coordination questions must be addressed, such as:
        1. Who are the appropriate actors?
        2. What are their roles?
        3. Do the GAC ccTLD principles need to be revised in the light of the introduction of IDN ccTLDs?
   3. Delegation of IDN ccTLDs
      • Do existing ccTLD delegation policies apply to the delegation of IDN ccTLDs? If not:
        1. Who can apply to have the IDN ccTLD delegated or to be the delegate for that ccTLD?
        2. Who decides on the delegation and in particular:
           • Are there specific reasons for deviating from the standard practice/guidelines that a zone should only be delegated with the support of the local internet community, which includes the government?
           • Is consent/involvement/knowledge of government required?
           • Is there any presumptive right of the ASCII ccTLD manager over a corresponding IDN ccTLD?
        3. Who will formulate the policy for these processes?
        4. Do existing US-ASCII ccTLD delegation policies for dealing with multiple applications, objections to applications or disputes apply to the same issues in the delegation of IDN ccTLDs? If not who will formulate the policies for these issues?
        5. Taking into account all experiences ICANN has acquired - should there be an agreement between ICANN and the IDN ccTLD operator on the operation of the IDN ccTLD string?
   4. Operation of IDN ccTLDs
      • Is the operation and management of an IDN ccTLD different to that of an existing US-ASCII ccTLD such that there are specific global technical requirements, in addition to the general IDN standards, needed for the operation of an IDN ccTLD? If so, how are those requirements developed and who would develop them?