Meeting Agenda for Rework Group

Meeting Agenda for Rework Group Meeting

re. GNSO Response to ccNSO/GAC Issues Paper on IDN ccTLDs

29 January 2008

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

Reminder – using the current Google document, all group members are encouraged to do the following before the meeting:
• Review the changes made during the 22 January call and be prepared in the meeting to quickly identify any additional changes needed as well as to confirm the changes. (Agenda item 5 below)
• Review the remaining part of the main body of the document to facilitate ready discussion of it during the meeting. (Agenda item 6 below)
• Review the revised Executive Summary. (Agenda item 7 below)
• Cut and paste a copy of the latest Google online document shortly before the meeting for reference during the call as needed.

1. Welcome
2. Agenda approval
3. Rework Group Schedule [with responsible party (parties) in parentheses]
   • Today’s meeting: finalize draft document (all)
   • 29 January after meeting: incorporate all edits from today’s meeting into the Google document (Liz)
   • 30 January: review revised Google document and communicate any additional content edits on the group list by COB (all) – Note that minor edits could be made directly on the Google document.
   • 31 January: make any final edits and distribute to the Council list (Liz with assistance from Chuck as needed)
   4. Document editor: Liz Gasster 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 not possible.
   
   5. Discuss and confirm edits made on the 22 January call.

   • Section B - Comments regarding issues and questions in the ccNSO/GAC report
   1. General issues regarding IDN ccTLDs
   • Number of characters in the string?
   a) 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?
   b) Does moving outside the current 2 symbol limitation create any security, stability or integrity issues?
   c) 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?
   a) 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?
   b) 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’?
   c) 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?
   a) Is such a list necessary?
   b) Who would develop such a list?
   c) Should such a list be mandated?
   d) If yes, by whom?
   e) Who would develop the criteria and relevant policies for identifying IDN ccTLDs?
   f) Under what policy or authority would the list be created?
   g) 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? – We ended today’s meeting in the middle of the response to this question and will pick up from the start of the quote from the GNSO IDN WG titled ‘4.1.1 Avoidance of ASCII-Squatting’.
   • 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’?
   a) What are the criteria and policies to determine who can submit a request for the designation of an IDN ccTLD?
   b) Who will develop the criteria and policies for determining the designation of an IDN ccTLD?
   c) How will such issues as competing requests (both domestic and international) be dealt with?
   d) 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:
   a) Who are the appropriate actors?
   b) What are their roles?
   c) 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:
   a) Who can apply to have the IDN ccTLD delegated or to be the delegate for that ccTLD?
   b) Who decides on the delegation and in particular:
   o 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?
   o Is consent/involvement/knowledge of government required?
   o Is there any presumptive right of the ASCII ccTLD manager over a corresponding IDN ccTLD?
   c) Who will formulate the policy for these processes?
   d) 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?
   e) 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?
   5. Introduction of IDN ccTLDs
   • Should a list of IDN ccTLD strings be mandated?
   a) Is such a list necessary?
   b) Who would develop such a list?
   c) Should such a list be mandated?
   d) If yes, by whom?
   e) Who would develop the criteria and relevant policies for identifying IDN ccTLDs?
   f) Under what policy or authority would the list be created?
   g) 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? (We ended the 22 January meeting in the middle of the response to this question and will pick up from the start of the quote from the GNSO IDN WG titled ‘4.1.1 Avoidance of ASCII-Squatting’ today.

   6. Continue discussion of the document from the end point of discussion on 22 January
   5. Introduction of IDN ccTLDs
   • What precedence should be given to ccTLDs in the IDN implementation process? – We ended the 22 January meeting in the middle of the response to this question and will pick up from the start of the quote from the GNSO IDN WG titled ‘4.1.1 Avoidance of ASCII-Squatting’.
   • 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’?
   e) What are the criteria and policies to determine who can submit a request for the designation of an IDN ccTLD?
   f) Who will develop the criteria and policies for determining the designation of an IDN ccTLD?
   g) How will such issues as competing requests (both domestic and international) be dealt with?
   h) 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:
   d) Who are the appropriate actors?
   e) What are their roles?
   f) Do the GAC ccTLD principles need to be revised in the light of the introduction of IDN ccTLDs?
   6. Delegation of IDN ccTLDs
   • Do existing ccTLD delegation policies apply to the delegation of IDN ccTLDs?
   If not:
   a) Who can apply to have the IDN ccTLD delegated or to be the delegate for that ccTLD?
   b) Who decides on the delegation and in particular:
   o 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?
   o Is consent/involvement/knowledge of government required?
   o Is there any presumptive right of the ASCII ccTLD manager over a corresponding IDN ccTLD?
   c) Who will formulate the policy for these processes?
   d) 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?
   e) 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?
   7. 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?

   7. Review and finalize the revised Executive Summary
   
   8. Action items for the next two days:
   • 30 January: review revised Google document and communicate any additional edits on the group list by COB (all)
   • 31 January: make any final edits and distribute to the Council list (Liz with assistance from Chuck as needed)
   
   9. Thanks for the great work.
   • For those on the Council, please be prepared to contribute to the full Council discussions on the document in New Delhi.