Reserved Names Working Group - Final Report

Last Updated: 4 September 2009
Date: 
23 May 2007

GNSO New TLDs Committee

Reserved Names Working Group

Final Report

23 May 2007

TABLE OF CONTENTS

DEFINITIONS.................................................................... 5

BACKGROUND................................................................. 9

SECTION ONE - PROCEDURAL BACKGROUND AND RECOMMENDATIONS TABLE......................................... 10

Summary of Existing Reserved Name Requirements................................................................ 15

Roles of Reserved Names.............................................................................................................. 16

FULL RECOMMENDATION TABLE.......................................................................................................... 19

SECTION TWO - OVERVIEW OF RN-WG PROCESS..... 30

SECTION THREE - OUT OF SCOPE AREAS.................. 34

SECTION FOUR -- RECOMMENDATIONS FOR NEW WORK 37

SECTION FIVE - REFERENCE MATERIAL...................... 40

ANNEX ONE - ICANN/IANA SUB GROUP REPORT........ 41

DEFINITIONS......................................................................................................................................... 42

EXECUTIVE SUMMARY.......................................................................................................................... 42

Supporting Information................................................................................................................ 46

ANNEX TWO -- SINGLE AND TWO CHARACTER RESERVED NAMES SUB GROUP REPORT (Including Symbols) 51

DEFINITIONS......................................................................................................................................... 52

EXECUTIVE SUMMARY.......................................................................................................................... 54

Supporting Information................................................................................................................ 59

RECOMMENDATION ONE: SYMBOLS................................................................................................ 60

RECOMMENDATION TWO: SINGLE AND TWO CHARACTER IDNs....................................................... 61

RECOMMENDATION THREE: SINGLE LETTERS AT THE TOP LEVEL................................................... 65

RECOMMENDATION FOUR: SINGLE LETTERS AND DIGITS AT THE SECOND LEVEL.......................... 68

RECOMMENDATION FIVE: DIGITS AT THE TOP LEV........................................................................... 70

RECOMMENDATION SIX: SINGLE LETTER, SINGLE DIGIT COMBINATIONS AT THE TOP LEVEL........... 72

RECOMMENDATION SEVEN: TWO LETTERS AT THE TOP LEVEL...................................................... 73

RECOMMENDATION EIGHT: ANY COMBINATION OF TWO LETTERS, DIGITS AT THE SECOND LEVEL 75

ANNEX THREE -- TAGGED NAMES SUB GROUP REPORT 90

DEFINITION........................................................................................................................................... 91

EXECUTIVE SUMMARY.......................................................................................................................... 91

Supporting Information................................................................................................................ 94

ANNEX FOUR -- NIC/WHOIS/WWW SUB GROUP REPORT 103

DEFINITION......................................................................................................................................... 104

EXECUTIVE SUMMARY........................................................................................................................ 104

Supporting Information.............................................................................................................. 107

ANNEX FIVE -- GEOGRAPHICAL AND GEOPOLITICAL NAMES SUB GROUP REPORT.......................................................... 114

DEFINITIONS....................................................................................................................................... 115

EXECUTIVE SUMMARY........................................................................................................................ 115

Supporting Information.............................................................................................................. 119

ANNEX SIX -- Sub-Group Report - gTLD Strings 130

Sub-Group Report - gTLD Strings..................... 130

DEFINITION......................................................................................................................................... 131

EXECUTIVE SUMMARY........................................................................................................................ 131

Supporting Information.............................................................................................................. 133

ANNEX SEVEN -- CONTROVERSIAL NAMES SUB GROUP REPORT...................................................................................... 145

DEFINITIONS....................................................................................................................................... 146

EXECUTIVE SUMMARY........................................................................................................................ 146

Supporting Information.............................................................................................................. 151

ANNEX EIGHT -- Alphabetical Listing of Recommended Reserved Names...................................................... 158

ANNEX NINE -- PARTICIPATION DATA: RN-WG Meeting Dates & Locations.................................................................. 161




A Label

ASCII-compatible (ACE) form of an IDNA-valid string. See http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt. An example is xn--1lq90i.

Character

A character may be a letter, digit, hyphen or symbol.

For the purposes of discussing IDNs, a "character" can best be seen as the basic graphic unit of a writing system, which is a script plus a set of rules determining how it is used for representing a specific language. However, domain labels do not convey any intrinsic information about the language with which they are intended to be associated, although they do reveal the script on which they are based. This language dependency can unfortunately not be eliminated by restricting the definition to script because in several cases (see examples below) languages that share the same script differ in the way they regard its individual elements. The term character can therefore not be defined independently of the context in which it is used.

In phonetically based writing systems, a character is typically a letter or represents a syllable, and in ideographic systems (or alternatively, pictographic or logographic systems) a character may represent a concept or word.

The following examples are intended to illustrate that the definition of a character is at least two-fold, one being a linguistic base unit and the other is the associated code point.

U-label 酒 : Jiu; the Chinese word for 'alcoholic beverage'; Unicode code point is U+9152 (also referred to as: CJK UNIFIED IDEOGRAPH-9152); A-label is xn-jj4

U-label 北京 : the Chinese word for 'Beijing', Unicode code points are U+5300 U+4EAC; A-label is xn-1lq90i

U-label 東京 : Japanese word for 'Tokyo', the Unicode code points are U+6771 U+4EAC; A-label is xn-1lqs71d

U-label ایكوم; Farsi acronym for ICOM, Unicode code points are U+0627 U+06CC U+0643 U+0648 U+0645; A-label is xn-mgb0dgl27d.

Controversial Names

A name is designated as a controversial name if it qualifies as a TLD under the then prevailing String Criteria, does not fall under any other Reserved Name category and is disputed for reasons other than that it either falls under any other Reserved Name category or that it infringes on the prior legal rights of others.

Controversial Names - Dispute Resolution Panel

CN-DRP

Geographical Names

Geographical names refer to those names in the ISO 3166-1 list (e.g., Portugal, India, Brazil, China, Canada) & names of territories, distinct geographic locations (or economies), and other geographic names as ICANN may direct from time to time.

Geopolitical Names

The reserved name category titled 'Geographic and Geopolitical Names' is contained in a subset of existing ICANN registry agreements. Geopolitical names is a term that has not been widely used within the broader geographical identifier discussion. In fact, the term is only used once in a parenthetical in the entire WIPO II Process final report. See http://www.wipo.int/amc/en/processes/process2/report/html/report.html Paragraph 55.

gTLD strings

gTLD strings refer to gTLDs (i.e., .com, .net .org, .mobi) that are reserved from registration at the second level and third level where applicable as a contractual condition (e.g., .net, .travel, .org, .jobs, .mobi, .asia). Reservation is based upon the list contained at http://data.iana.org/TLD/tlds-alpha-by-domain.txt

Reserved Names

Working definition: For th

For the purpose of developing recommendations that are readily usable in the GNSO New gTLD PDP report and in response to direction received from the GNSO Council in Lisbon, the Reserved Name Working Group (RN-WG) focused attention in its final recommendations only on reserved name requirements that apply to all new gTLDs for which clear requirements could be defined. Depending on the specific reserved name category as well as the type (ASCII or IDN), the reserved name requirements recommended may apply in any one or more of the following levels as indicated:

  1. At the top level regarding gTLD string restrictions
  2. At the second-level as contractual conditions
  3. At the third-level as contractual conditions for any new gTLDs that offer domain name registrations at the third-level.

Therefore, the final RN-WG reserved name recommendations fall into the following categories:

  1. ICANN/IANA names
  2. Single & two-character names, including the use of symbols
  3. Tagged names
  4. NIC, Whois and www
  5. gTLD names at the second level (or third level if applicable).

In its work, the RN-WG also focused on the following categories of names:

·         Geographical and geopolitical names

·         Specific names reserved by particular gTLD registries at the second and third level

·         Controversial names.

In the case of the second category, the lists of registry specific names were unique to particular gTLD registries rather than to all gTLDs and thus did not fit the focus of the group. In the case of geographical/geopolitical names and controversial names, it was very difficult if not impossible to define clear reservation requirements that could be applied for all new gTLDs; at the same time, the work completed by the group seemed to be very applicable to the processes developed as part of the New gTLD PDP, so recommendations are included in this report for consideration as part of those processes.

Single & Two Character Labels

Prior to the release of IDNA, the characters available for inclusion in domain names consisted of a limited number of alphanumeric elements (a,...z; 0,..., 9; "-"), and policies could easily be based on the number of characters any label contained. There is no similar generally applicable way to compare the length of, for example, an ideographic and an alphabetic string, or even a sequence of characters taken from the basic Latin alphabet with a decorated version of the same sequence.

In Czech, <ch> is a single letter (or character -- the concepts do not differ in this regard) whereas in English it is two. In Danish, <æ> is the 27th letter of the alphabet. It is a single character and does not decompose to <a e>. Depending on who you ask and their linguistic background, there are either 12 or 13 characters in the English word <encyclopædia>.  If written as <encyclopaedia>, all would agree on 13. Differentiation by considering semantic value does not help. In Turkish, there is a difference between a dotted <i> and a dotless <ı>. In English, there is no such distinction. Whether the dot is to be counted as a character in its own right or not will again depend on who you ask and what language they view the word as being written in.

Symbol

While the DNS supports all of the printable characters in the US-ASCII character table not all such characters are made available in domain names. Symbols, such as #, $, &, !, *, -, _, +, =, are not available for registration in domain names because the top-level domain registries decided (before internationalization) to adopt the hostname rule for registration of domain names. The hostname rule, defined in RFC 952[1] and updated in RFC 1123[2], specifies that only letters, digits and hyphens (a-z, 0-9, -) are valid characters in hostnames.

Tagged Names

All labels with hyphens in both the third and fourth character positions (e.g., "bq-1k2n4h4b" or "xn-ndk061n")

U-Label

An IDNA-valid string of Unicode-coded characters; the representation of the Internationalised Domain Name (IDN) in Unicode. See http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt. An example is 北京, the U-Label for the Chinese word "Beijing".



BACKGROUND

1.      This Report is an additional input from the GNSO's Committee on the Introduction of New Top-Level Domains Reserved Names Working Group (RN-WG). The Report builds upon the 16 March 2007 Reserved Names Working Group Report[3]. There are four sections to this Report that map directly to the Statement of Work released by the RN-WG Chair on 10 April 2007[4] for consideration by the GNSO Council at its 12 April 2007 meeting[5]. This Report will be used as further input into the new TLDs Final Report which is due to be released in early June 2007.

2.      The first section of the Report sets out the procedural elements of the Working Group's remit and, in table form, provides the Group's full set of recommendations.

3.      The second section discusses the RN-WG work.

4.      The third section of the report identifies areas that have been determined to be out of scope for the Working Group.

5.      The fourth section includes recommendations for the GNSO Council to consider as new work for a later date.

6.      The fifth section contains a full set of annexures and additional references which has informed the Working Group's deliberations.


SECTION ONE - PROCEDURAL BACKGROUND AND RECOMMENDATIONS TABLE

1.      The work discussed in this report is a continuation of the original work of the Reserved Names Working Group as found in the report[6] posted 19 March 2007 and from which the extended work program was devised. On 12 April 2007 the GNSO Council extended the RN-WG by 30 days.

Statement of Work for the additional 30-days

General Tasks

1.      Define reserved names per direction provided during meetings in Lisbon

2.      Reorganize the RN-WG report so that recommendations are grouped in the following categories:

a.      Reserved name recommendations ready for input into the New gTLD PDP report

b.      Recommendations for possible use in the New gTLD evaluation process, not as reserved names

                                                                                                              i.      Geographical and geopolitical names

                                                                                                            ii.      Controversial names

c.      Categories of names deemed to be out of scope for the RN-WG

                                                                                                              i.      Three character names at the third level

                                                                                                            ii.      Registry specific names at the second level

                                                                                                          iii.      Other reserved names at the second level

3.      Review GAC Principles for New gTLDs

4.      Review IDN-WG Report

5.      Add the GAC Principles for New gTLDs to the RN-WG report and reference them in applicable name categories

6.      Request that the SSAC identify any possible security or stability issues with regard to RN-WG recommendations as well as suggestions as to how any such issues might be mitigated

7.      Create an annex as feasible (with no explanations) which is simply the full proposed list of reserved names listed alphanumerically

8.      Use format specifications to be provided by Liz Williams

 

Tasks regarding Recommendations

1.      ICANN/IANA reserved names

a.      Restate recommendations in the RN-WG report so that they can be readily transferred into the New gTLD PDP report

                                                                                                              i.      Maintain status quo for now regarding ASCII names

                                                                                                            ii.      Confirm that these names are already reserved at the third level for .name and .pro and edit the document accordingly

                                                                                                          iii.      Reword recommendation for "example" at all levels for ASCII and IDN names

1.      Provide examples

2.      Incorporate any relevant comments from the IDN-WG report

                                                                                                          iv.      Provide a brief rationale in support of the recommendations, referring to the role of the category as applicable

b.      Finalize guidelines for additional work

2.      Use of symbols in Reserved Names

a.      Restate recommendations in RN-WG report so that they can be readily transferred into the New gTLD PDP, including fine-tuning of language

                                                                                                              i.      Provide examples as possible

                                                                                                            ii.      Maintain status quo for now regarding ASCII names

b.      Provide a brief rationale in support of the recommendations, referring to the role of the category as applicable

3.      Single & two-character reserved names

a.      Consult further with IDN experts regarding single and two-character IDN names including definition of the term 'character' as it relates to non-roman scripts

b.      Consult further with experts in the technical community regarding single letter ASCII names, single-number ASCII names and two-character ASCII names involving at least one number.

c.      Consult with the GAC as possible regarding single and two-character IDN names

d.      Restate recommendations in RN-WG report so that they can be readily transferred into the New gTLD PDP report

                                                                                                              i.      Provide examples as possible for both the top and second levels, ASCII and IDN, single and two-character

                                                                                                            ii.      Incorporate any relevant comments from the IDN-WG report

e.      Provide a brief rationale in support of the recommendations, referring to the role of the category as applicable

f.        Finalize guidelines for additional work for ASCII single character names at all levels

g.      As necessary, finalize guidelines for additional work for IDN single and two-character names at all levels

4.      Tagged names

a.      Restate recommendations in RN-WG report so that they can be readily transferred into the New gTLD PDP report

                                                                                                              i.      To ensure clarity, change all occurrences of 'in the third and fourth character positions' to 'in both the third and fourth character positions'

                                                                                                            ii.      Move recommendation 2 for IDN gTLDs from ASCII, top level to IDN top level

                                                                                                          iii.      In recommendation 2 for IDN gTLDs, change wording to use the terms 'ASCII compatible encoding' and 'Unicode display form'

                                                                                                          iv.      Provide examples, including an example of what new applicants for an IDN gTLD would have to provide

                                                                                                            v.      Incorporate any relevant comments from the IDN-WG report

b.      Provide a brief rationale in support of the recommendations, referring to the role of the category as applicable

5.      NIC, Whois and www

a.      Restate recommendations in RN-WG report so that they can be readily transferred into the New gTLD PDP report

                                                                                                              i.      Provide examples

                                                                                                            ii.      Incorporate any relevant comments from the IDN-WG report

b.      Provide a brief rationale in support of the recommendations, referring to the role of the category as applicable

6.      Geographical & geopolitical names

a.      Review the GAC Principles for New gTLDs with regard to geographical and geopolitical names

b.      Consult with WIPO experts regarding geographical and geopolitical names and IGO names

c.      Consult with the GAC as possible

d.      Reference the treaty instead of the Guidelines and identify underlying laws if different than a treaty

e.      Consider restricting the second and third level recommendations to unsponsored gTLDs only

f.        Restate recommendations in RN-WG report for possible use in the New gTLD evaluation process, not as reserved names

                                                                                                              i.      Describe process flow

                                                                                                            ii.      Provide examples as possible

                                                                                                          iii.      Incorporate any relevant comments from the IDN-WG report

g.      Provide a brief rationale in support of the recommendations, referring to the role of the category as applicable

h.      Edit other text of the individual subgroup report as applicable to conform with the fact that geographical and geopolitical names will not be considered reserved names

i.        Finalize guidelines for additional work as necessary

7.      Third level names

a.      Replace recommendations with a statement about the direction by the Council that this category is not in the scope of the RN-WG

b.      Edit other text of the individual subgroup report as applicable with the statement regarding scope

8.      gTLD names at the 2nd (or 3rd level if applicable)

a.      Complete consultation with gTLD registries and incorporate final results in the RN-WG report

b.      Determine whether final recommendations can be made

c.      State recommendations in RN-WG report so that they can be readily transferred into the New gTLD PDP report

                                                                                                              i.      Provide examples

                                                                                                            ii.      Incorporate any relevant comments from the IDN-WG report

d.      Provide a brief rationale in support of the recommendations, referring to the role of the category as applicable

e.      If additional work is needed, finalize guidelines for that work

9.      Other names at the second level

a.      Replace recommendations with a statement about the direction by the Council that this category is not in the scope of the RN-WG

b.      Edit other text of the individual subgroup report as applicable with the statement regarding scope

10. Controversial names

a.      Review the GAC Principles for New gTLDs with regard to controversial names

b.      Consult with the GAC as possible

c.      Consider the possibility of creating a disputed name list (not a reserved name list) that would be updated whenever controversial names are rejected and would be used for guideline purposes only

d.      Restate recommendations in RN-WG report for possible use in the New gTLD evaluation process, not as reserved names

                                                                                                              i.      Describe process flow

                                                                                                            ii.      Provide examples as possible

                                                                                                          iii.      Incorporate any relevant comments from the IDN-WG report

e.      Provide a brief rationale in support of the recommendations, referring to the role of the category as applicable

f.        Edit other text of the individual subgroup report as applicable to conform with the fact that controversial names will not be considered reserved names

g.      Finalize guidelines for additional work as necessary

2.      In response to the above statement of work, the Working Group met weekly by teleconference from 11 April through 10 May. The calls were recorded and the MP3 versions of the calls are available on the GNSO website at http://gnso.icann.org/calendar/#May. The Working Group was chaired by Chuck Gomes and the full participation records can be found in Annex Nine.

3.      The Working Group set out, in its initial report, the categories (p8 of previous report) and the roles of reserved names (p10 of previous report). Those tables are repeated here for clarity.


Summary of Existing Reserved Name Requirements

Category of Names

TLD Level(s)

Reserved Names

Applicable gTLDs

ICANN & IANA related

2nd (and 3rd if applicable)

ICANN: aso, gnso, icann, internic, ccNSO

IANA: afrinic, apnic, arin, example, gtld-servers, iab, iana, iana-servers, iesg, ietf, irtf, istf, lacnic, latnic, rfc-editor, ripe, root-servers

All 16 gTLDs

Single Character

2nd level

All 36 alphanumeric ASCII characters (e.g., a.biz, b.aero)

All 16 gTLDs (some of these were registered prior to the requirement)

Two Character

2nd level

1296 combinations of ASCII letters and digits(e.g., xy.org, b2.info)

All 16 gTLDs (with some exceptions for certain gTLDs)

Tagged

2nd (and 3rd if applicable)

All labels with hyphens in the third and fourth character positions (e.g.,

"bq--1k2n4h4b" or

"xn--ndk061n")

All 16 gTLDs

NIC, Whois, www

2nd level

NIC, Whois, www (reserved for registry operations only)

All 16 gTLDs

Geographic & Geopolitical

2nd (and 3rd if applicable)

All geographic & geopolitical names in the ISO 3166-1 list (e.g., Portugal, India, Brazil, China, Canada) & names of territories, distinct geographic locations (or economies), and other geographic and geopolitical names as ICANN may direct from time to time

.asia, .cat, .jobs, .mobi, .tel & .travel

Third Level

3rd level

See Section 1.B of the subgroup report in Appendix H.

.pro and .name

Other 2nd Level

2nd level

See the section titled 'Other names reserved at the 2nd level' in Appendix I

Varying lists for .aero, .biz, .coop, .info, .museum, .name and .pro

Controversial

No current requirement

N/A

None

Roles of Reserved Names

Category of Names

Reserved Names

Role

ICANN & IANA related

ICANN: aso, gnso, icann, internic, ccNSO

IANA: afrinic, apnic, arin, example, gtld-servers, iab, iana, iana-servers, iesg, ietf, irtf, istf, lacnic, latnic, rfc-editor, ripe, root-servers

The role of the reserved names held by IANA and ICANN has been to maintain for those organizations the exclusive rights to the names of ICANN (icann), its bodies (aso, ccnso, pso, etc.) or essential related functions (internic) of the two organizations.

Single Character

All 36 alphanumeric ASCII characters (e.g., a.biz, b.aero)

It appears that the original purpose for reserving the single characters was driven by technical concerns.

Two Character

1296 combinations of ASCII letters and digits(e.g., xy.org, b2.info)

Two letter reservations appear to have been based on concerns about confusion with two letter country codes.

Tagged

All labels with hyphens in the third and fourth character positions (e.g.,

"bq--1k2n4h4b" or

"xn--ndk061n")

The role of the tagged name reservation requirement is to be able to provide a way to easily identify an IDN label in the DNS and to avoid confusion of non-IDN ASCII labels. Implicit in this role is the need to reserve tagged names for future use in case the ASCII IDN prefix is changed.

NIC, Whois, www

NIC, Whois, www (reserved for registry operations only)

The rationale for the reservation of these names for use by registry operators is based upon long standing and well established use of these strings by registry operators (both gTLD and ccTLDs) in connection with normal registry operations.

Geographic & Geopolitical

All geographic & geopolitical names in the ISO 3166-1 list (e.g., Portugal, India, Brazil, China, Canada) & names of territories, distinct geographic locations (or economies), and other geographic and geopolitical names as ICANN may direct from time to time

Protection afforded to Geographic indicators is an evolving area of international law in which a one-size fits all approach is not currently viable. The proposed recommendations in this report are designed to ensure that registry operators comply with the national laws for which they are legally incorporated/organized.

Third Level

See Section 1.B of the subgroup report in Appendix H.

The role of the names specifically reserved at the third level is primarily to combat security concerns (e.g., a party registering www.med.pro could pose as the registrar for that domain). As a secondary matter, they may be needed to overcome technical challenges presented by 'double' addresses (e.g., www.www.med.pro) and, to a lesser extent, consumer confusion.

Other 2nd Level

See the section titled 'Other names reserved at the 2nd level' in Appendix I.

1) reservation of gTLD strings at the second level was put in place by ICANN in order to avoid consumer confusion in relation to TLD.TLD addresses; 2) the reservation of registry-related names came about during contract negotiations and are in place in order to protect the Registries and their successors and to avoid consumer confusion; 3) for the .name, .mobi, .coop, .travel and .job Registries, certain non-ICANN reserved names directly benefit the communities that they represent and / or the reserved names are an integral part of the Registry's business model.

Controversial

N/A

There is no apparent role for controversial names among the existing categories of names reserved at the second level within gTLDs. The role of controversial second level names within several ccTLDs varies and includes an array of concepts such as the protection of national interests, illegal activities, obscenity, and social disorder.

4.      The input from the Working Group will now be included, where applicable, in the Final Report on the Introduction of New Top-Level Domains.


FULL RECOMMENDATION TABLE

Detailed information for each of the recommendations in this table can be found in the applicable report annex shown in the last column.

Reserved Name Category

Domain Name Level(s)

Recommendation

Annex

1

ICANN & IANA

All ASCII

Maintain the existing reservation requirement and extend it to the top level until further work is completed. Further work is recommended to send questions, receive and compile responses from organizations with related reserved names, and draft a report to the GNSO Council. Examples are icann.net, or admin.iana.

One

2

ICANN & IANA

Top level, IDN

For all but "example", reservations are not required for Unicode versions in various scripts, or ACE versions of such translations or transliterations if they exist.

All possible Unicode versions of the name "example" must be reserved

The New gTLD Committee should validate this recommendation with IDN experts.

One

3

ICANN & IANA

2nd & 3rd levels, IDN

For all but "example", reservations are not required for Unicode versions in various scripts, or ACE versions of such translations or transliterations if they exist.

Do not try to translate 'example' into Unicode versions for various scripts or to reserve any ACE versions of such translations or transliterations if they exist, except on a case by case basis as proposed by given registries.

The New gTLD Committee should validate this recommendation with IDN experts.

One

4

Symbols

ALL

We recommend that current practice be maintained, so that no symbols other than the '-' [hyphen] be considered for use at any level, unless technology at some time permits the use of symbols.[7]

Two

5

Single and Two Character IDNs

IDNA-valid strings at all levels

Single and two-character U-labels on the top level and second level of a domain name should not be restricted in general. At the top level, requested strings should be analyzed on a case by case basis in the new gTLD process depending on the script and language used in order to determine whether the string should be granted for allocation in the DNS. Single and two character labels at the second level and the third level if applicable should be available for registration, provided they are consistent with the IDN Guidelines.[8]

Examples of IDNs include .酒, 東京.com, تونس.icom.museum.

Two

6

Single Letters

Top Level

We recommend reservation of single letters at the top level based on technical questions raised. If sufficient research at a later date demonstrates that the technical issues and concerns are addressed, the topic of releasing reservation status can be reconsidered.

Examples of names that would not be allowed include .a, .z.

Two

7

Single Letters and Digits

2nd Level

We recommend that single letters and digits be released at the second level in future gTLDs, and that those currently reserved in existing gTLDs should be released. This release should be contingent upon the use of appropriate allocation frameworks. More work may be needed.

Examples include a.com, i.info.

Two

8

Single and Two Digits

Top Level

We recommend digits be reserved at the top level, in order to avoid potential confusion with IP addresses within software applications. Examples include .3, .99.

Two

9

Single Letter, Single Digit Combinations

Top Level

Applications may be considered for single letter, single digit combinations at the top level in accordance with the terms set forth in the new gTLD process. Examples include .3F, .A1, .u7.

Two

10

Two Letters

Top Level

We recommend that the current practice of allowing two letter names at the top level, only for ccTLDs, remain at this time.[9]

Examples include .AU, .DE, .UK.

Two

11

Any combination of Two Letters, Digits

2nd Level

Registries may propose release provided that measures to avoid confusion with any corresponding country codes are implemented.[10] Examples include ba.aero, ub.cat, 53.com, 3M.com, e8.org.

Two

12

Tagged Names

Top Level ASCII

In the absence of standardization activity and appropriate IANA registration, all labels with hyphens in both the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n") must be reserved in ASCII at the top level.[11]

Three

13

N/A

Top Level IDN

For each IDN gTLD proposed, applicant must provide both the "ASCII compatible encoding"  ("A-label") and the "Unicode display form" ("U-label")[12] For example:

  • If the Chinese word for 'Beijing' is proposed as a new gTLD, the applicant would be required to provide the A-label (xn--1lq90i) and the U-label (北京).

If the Japanese word for 'Tokyo' is proposed as a new gTLD, the applicant would be required to provide the A-label (xn--1lqs71d) and the U-label (東京).

Three

14

Tagged Names

2nd Level ASCII

The current reservation requirement be reworded to say, "In the absence of standardization activity and appropriate IANA registration, all labels with hyphens in both the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n") must be reserved in ASCII at the second (2nd) level.[13] - added words in italics. (Note that names starting with "xn--" may only be used if the current ICANN IDN Guidelines are followed by a gTLD registry.)

Three

15

Tagged Names

3rd Level ASCII

All labels with hyphens in both the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n") must be reserved in ASCII at the third (3rd level) for gTLD registries that register names at the third level."[14] - added words in italics. (Note that names starting with "xn--" may only be used if the current ICANN IDN Guidelines are followed by a gTLD registry.)

Three

16

NIC/WHOIS/WWW

Top ASCII

The following names must be reserved: NIC, Whois, www.

Four

17

NIC/WHOIS/WWW

Top IDN

Do not try to translate NIC, Whois and www into Unicode versions for various scripts or to reserve any ACE versions of such translations or transliterations if they exist.

Four

18

NIC/WHOIS/WWW

Second and Third* ASCII

The following names must be reserved for use in connection with the operation of the registry for the Registry TLD: NIC, Whois, www. Registry Operator may use them, but upon conclusion of Registry Operator's designation as operator of the registry for the Registry TLD, they shall be transferred as specified by ICANN. (*Third level only applies in cases where a registry offers registrations at the third level.)

Four

19

NIC/WHOIS/WWW

Second and Third* IDN

Do not try to translate NIC, Whois and www into Unicode versions for various scripts or to reserve any ACE versions of such translations or transliterations if they exist, except on a case by case basis as proposed by given registries. (*Third level only applies in cases where a registry offers registrations at the third level.)

Four

20

Geographic and geopolitical

Top Level ASCII and IDN

There should be no geographical reserved names (i.e., no exclusionary list, no presumptive right of registration, no separate administrative procedure, etc.). The proposed challenge mechanisms currently being proposed in the draft new gTLD process would allow national or local governments to initiate a challenge, therefore no additional protection mechanisms are needed. Potential applicants for a new TLD need to represent that the use of the proposed string is not in violation of the national laws in which the applicant is incorporated.

However, new TLD applicants interested in applying for a TLD that incorporates a country, territory, or place name should be advised of the GAC principles, and the advisory role vested to it under the ICANN bylaws. Additionally, a summary overview of the obstacles encountered by previous applicants involving similar TLDs should be provided to allow an applicant to make an informed decision. Potential applicants should also be advised that the failure of the GAC, or an individual GAC member, to file a challenge during the TLD application process, does not constitute a waiver of the authority vested to the GAC under the ICANN bylaws.

Five

21

Geographic and geopolitical

All Levels ASCII and IDN

The term 'geopolitical names' should be avoided until such time that a useful definition can be adopted. The basis for this recommendation is founded on the potential ambiguity regarding the definition of the term, and the lack of any specific definition of it in the WIPO Second Report on Domain Names or GAC recommendations.

Five

22

Geographic and geopolitical

Second Level & Third Level if applicable, ASCII & IDN

The consensus view of the working group is given the lack of any established international law on the subject, conflicting legal opinions, and conflicting recommendations emerging from various governmental fora, the current geographical reservation provision contained in the sTLD contracts during the 2004 Round should be removed, and harmonized with the more recently executed .COM, .NET, .ORG, .BIZ and .INFO registry contracts. The only exception to this consensus recommendation is those registries incorporated/organized under countries that require additional protection for geographical identifiers. In this instance, the registry would have to incorporate appropriate mechanisms to comply with their national/local laws.

For those registries incorporated/organized under the laws of those countries that have expressly supported the guidelines of the WIPO Standing Committee on the Law of Trademarks, Industrial Designs and Geographical Indications as adopted by the WIPO General Assembly, it is strongly recommended (but not mandated) that these registries take appropriate action to promptly implement protections that are in line with these WIPO guidelines and are in accordance with the relevant national laws of the applicable Member State.

Five

23

gTLD Reserved Names

Second &

Third Level ASCII and

IDN (when applicable)

Absent justification for user confusion[15], the recommendation is that gTLD strings should no longer be reserved from registration for new gTLDs at the second or when applicable at the third level. Applicants for new gTLDs should take into consideration possible abusive or confusing uses of existing gTLD strings at the second level of their corresponding gTLD, based on the nature of their gTLD, when developing the startup process for their gTLD.

Six

24

Controversial Names

All Levels, ASCII & IDN

There should not be a new reserved names category for Controversial Names.

Seven

25

Controversial Names

Top Level, ASCII & IDN

There should be a list of disputed names created as a result of the dispute process to be created by the new gTLD process.

Seven

26

Controversial Names

Top Level, ASCII & IDN

In the event of the initiation of a CN-DRP process, applications for that label will be placed in a HOLD status that would allow for the dispute to be further examined. If the dispute is dismissed or otherwise resolved favorably, the applications will reenter the processing queue. The period of time allowed for dispute should be finite and should be relegated to the CN-DRP process. The external dispute process should be defined to be objective, neutral, and transparent. The outcome of any dispute shall not result in the development of new categories of Reserved Names.[16]

Seven

27

Controversial Names

Top Level, ASCII & IDN

The new GTLD Controversial Names Dispute Resolution Panel should be established as a standing mechanism that is convened at the time a dispute is initiated. Preliminary elements of that process are provided in this report but further work is needed in this area.

Seven

28

Controversial Names

Top Level, ASCII & IDN

Within the dispute process, disputes would be initiated by the ICANN Advisory Committees (e.g., ALAC or GAC) or supporting organizations (e.g., GNSO or ccNSO). As these organizations do not currently have formal processes for receiving, and deciding on such activities, these processes would need to be defined:

o       The Advisory Groups and the Supporting Organizations, using their own processes and consistent with their organizational structure, will need to define procedures for deciding on any requests for dispute initiation.

o       Any consensus or other formally supported position from an ICANN Advisory Committee or ICANN Supporting Organization must document the position of each member within that committee or organization (i.e., support, opposition, abstention) in compliance with both the spirit and letter of the ICANN bylaws regarding openness and transparency.

Seven

29

Controversial Names

Top Level, ASCII & IDN

Further work is needed to develop predictable and transparent criteria that can be used by the Controversial Resolution Panel. These criteria must take into account the need to:

§     Protect freedom of expression

§     Affirm the fundamental human rights, in the dignity and worth of the human person and the equal rights of men and women

Take into account sensitivities regarding terms with cultural and religious significance.

Seven

30

Controversial Names

Top Level, ASCII & IDN

In any dispute resolution process, or sequence of issue resolution processes, the Controversial name category should be the last category considered.

Seven

Annex Eight contains an alphabetical listing of all recommended reserved names as possible.


SECTION TWO - OVERVIEW OF RN-WG PROCESS

1.      This section provides a brief overview of the extended phase Statement of Work by name category: ICANN/IANA names; single and two character names (including symbols); tagged names; nic/whois/www; geographic and geopolitical names; gTLD names at the second and third level; and controversial names.

2.      The final subgroup reports are found, in full, in Annexes One through Seven. The Supporting Information section in each of the subgroup reports contains the following detailed information: background information; discussion of recommendations, rationale for the recommendations, description of consultations with experts and a summary of relevant information sources used.

3.      ICANN/IANA Names

3.1.  The subgroup report for this category contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding ICANN and IANA reserved names.

3.2.  The subgroup consisted of Mike Rodenbaugh (chair) and Edmon Chung.

3.3.  The subgroup recommends that the existing reservations be maintained until further work to evaluate the reservation of these names is completed.

3.4.  There was no disagreement in the WG regarding the recommendations.

3.5.  For detailed information, see Annex One.

4.      Single and Two Character Names (including symbols)

4.1.  The subgroup report for this category contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding single and two character labels.

4.2.  The subgroup members included: Greg Shatan (chair); Neal Blair; Marilyn Cade; Alistair Dixon; Avri Doria; Patrick Jones; Jonathan Nevett; Mike Rodenbaugh; Victoria McEvedy (Resigned from RN-WG on 24 April 2004).

4.3.  The original recommendations that formed the basis of this report were approved by the RN WG for inclusion in the 19 March 2007 RN-WG report. Following the ICANN meeting in Lisbon, Portugal, and throughout the 30-day extension period, the subgroup refined the recommendations and incorporated additional information. The recommendations represent the consensus of the full WG.

4.4.  The minority statement below was submitted for the following subcategory: two letters at the top level.

4.4.1.     Author: Mike Rodenbaugh

4.4.2.     Statement: "I recommend that two letter ASCII gTLDs be allowed. A standardized approach should be used which ensures consultation with appropriate parties, including the ccNSO and ISO 3166 Maintenance Agency, and where security and stability issues are identified, SSAC. While there may be political reasons, there appears no strong policy reason to withhold every possible two-letter TLD from use, on the assumption that some of them may be desired by countries that may be created in the future. The GAC principle assumes there will be 'user confusion' if two letter codes are allowed other than for ccTLDs, but this is not substantiated -- and there are many ccTLDs that are visually very similar to other ccTLDs (including .ch and .cn which are two of the larger ccTLDs). In addition, this concern would diminish if countries were able to use their own name as a TLD, including in its IDN form, or in an IDN two letter ccTLD."

4.5.  For detailed information, see Annex Two.

5.      Tagged Names

5.1.  The subgroup report for this category contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding tagged names.

5.2.  Chuck Gomes and Patrick Jones served as the subgroup for this report.

5.3.  The recommendations of this report were approved by the full RN-WG.

5.4.  There was no disagreement in the WG with the recommendations and hence no minority positions.

5.5.   For detailed information, see Annex Three.

6.      NIC, Whois and www

6.1.  The subgroup report for this category contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding Names Reserved for Registry Operations, NIC, Whois and www.

6.2.  Tim Denton served as a one-person subgroup for this category with support from Chuck Gomes and ICANN staff in the preparation of the final subgroup report.

6.3.  The recommendations of this report were approved by the full RN-WG.

6.4.  There was no disagreement with the recommendations and hence no minority positions.

6.5.  For detailed information, see Annex Four.

7.      Geographic and Geopolitical Names

7.1.  The subgroup report for this category contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding Geographical and Geopolitical Names.

7.2.  The Reserved Names subgroup on Geographical and Geopolitical Names was composed of Alistair Dixon, Caroline Greer, Michael Palage (chair), and Tim Ruiz.

7.3.  The full RN-WG supported the recommendations in this report.

7.4.  There was no disagreement with the recommendations and hence no minority positions.

7.5.  For detailed information, see Annex Five.

8.      gTLD Names at the Second and Third Levels

8.1.  The subgroup report for this category contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding gTLD reserved names at the second and third level.

8.2.  Ray Fassett (chair), Edmon Chung, and Patrick Jones served as the subgroup for this report.

8.3.  The recommendations of this report were approved by the full RN-WG.

8.4.  There were no minority statements from the RN-WG members. Minority opinions from individuals from various GNSO constituencies who were not part of the RN-WG are included in Section 3 of the subgroup report in the section titled Consultation with Experts.

8.5.  For detailed information, see Annex Six.

9.      Controversial Names

9.1.  The subgroup report for this category contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding Controversial Names.

9.2.  The members of the subgroup were: Marilyn Cade; Avri Doria (chair); Victoria McEvedy; Michael Palage; and Tamara Reznik.

9.3.  The RN-WG reached consensus on the recommendations.

9.4.  There was no disagreement in the WG regarding the recommendations.

9.5.  For detailed information, see Annex Six.


SECTION THREE - OUT OF SCOPE AREAS

1.      This section sets out the work that was determined to be out of scope for the Working Group.

2.      In its original work, the RN-WG focused on three categories of names that are reserved by certain gTLD registries but are not reserved name requirements for all gTLD registries[17]. These are third level reserved names; registry specific names reserved at the second level and other names reserved at the second level.

3.      The original RN-WG report (sent to the GNSO Council on 16 March 2007) contains subgroup reports that address these categories[18]. In sessions held during the ICANN meetings in Lisbon in March 2007, the GNSO Council concluded that the names in these categories were out of scope for the RN-WG. Therefore, no further work on these three categories of names was done by the RN-WG and no recommendations are included for them in this report.

4.      For information purposes, a brief overview of these two categories of names is provided below.

5.      Third-Level Reserved Names

·           There are currently two gTLDs that expressly reserve names at the third level, .pro and .name. Appendix L to the registry agreements for .pro (http://www.icann.org/tlds/agreements/pro/registry-agmt-appl-30sep04.htm ) and .name (http://www.icann.org/tlds/agreements/name/registry-agmt-appl-8aug03.htm ) specify certain strings (or "labels") that are not available for registration. Both .pro and .name prohibit the following labels at the third-level: dir, directory, email, http, mail, mx, mx [followed by a number from 0 to 100], ns, ns [followed by a number from 0 to 100], wap, www and www [followed by a number from 0 to 100]. In addition, each TLD prohibits certain additional labels. Specifically, .Pro prohibits av, ca, cca, cert, certificate, grpa, pro, RegistryPro, verify, and verification, while .Name prohibits genealogy.

·           The full subgroup report for this category of names can be found in Appendix H of the above referenced RN-WG Report.

6.      Registry Specific Names Reserved at the Second-Level

·           The gTLD registry agreements for .biz and .org each contain a category of reserved names that are unique to these gTLDs. The List of Reserved TLD Strings in Appendix 6 of the .biz agreement (http://www.icann.org/tlds/agreements/biz/appendix-06-08dec06.htm ) contains a category of names called Additional Reservations by Registry Operator. The Schedule of Reserved Names in Appendix 6 of the .info agreement (http://www.icann.org/tlds/agreements/info/appendix-06-08dec06.htm ) contains a category of names called Registry and Registry Operator Reserved Names. The name reservations include Registry-related names (words and phrases associated with the day-to-day operations of a Registry) and reservations relating to the actual entity's name. The reservations came about during contract negotiations between ICANN and the respective registry.

·           The subgroup report for this category of names is contained in Part B of Appendix I of the above referenced first RN-WG Report.

7.      Other Names Reserved at the Second-Level

·           These names differ from other reserved names in that the names are actually intended to be allocated by the Registries. For example, .coop reserves non-ICANN names as referenced in Attachment 13 of its agreement at http://www.icann.org/tlds/agreements/coop/sponsorship-agmt-att13-28oct01.htm. .jobs reserves non-ICANN names per Schedule S of its agreement at http://www.icann.org/tlds/agreements/jobs/appendix-S-05may05.htm. .mobi reserves Premium Names as referenced in Appendix S of its Agreement at http://pc.mtld.mobi/documents/Premium_Name_List_16Jan07.pdf and .name reserves 'common names', 'community reservations', 'registry common names' and 'post-fix reservations' as listed in Section D of Appendix K in its Agreement at http://www.icann.org/tlds/agreements/name/registry-agmt-appk-8aug03.htm . The .travel agreement reserves non-ICANN names per Schedule S of its agreement at http://www.icann.org/tlds/agreements/travel/.

·           The subgroup report for this category of names is contained in Part C of Appendix I of the above referenced RN-WG Report.


SECTION FOUR -- RECOMMENDATIONS FOR NEW WORK

1.      The RN-WG recommends that the new work described in this section be undertaken at the direction of the GNSO Council. The work is organized according to reserved name category. Tasks that must be done before completion of the New gTLD Report is completed are shown in bold font.

2.      ICANN and IANA Names

2.1.  Proposed work tasks

2.1.1.     Validate the two IDN recommendations in this report (recommendations 2 & 3) with IDN experts

2.1.2.     Evaluate whether there is justification to continue reserving ICANN and IANA ASCII names at all levels as recommended in this report

2.2.  Guidelines for work

2.2.1.     There are lots of IDN experts who could be consulted regarding work task 2.1.1 but it is recommended that the experts already used by the RN-WG be used because they already have a good frame of reference for the work: Tina Dam, Cary Karp, and Ram Mohan.

2.2.2.     Regarding task 2.1.2, it is suggested that Mike Rodenbaugh, chair of the ICANN/IANA names subgroup and ICANN staff be consulted regarding ways to proceed.

3.      Single Letter Names at the Second and Third Level (recommendation 7)

3.1.  Proposed work tasks[19]

3.1.1.     Determine whether an allocation method is needed before release of single letter names at the second level

3.1.2.     If it is decided that an allocation method is needed, implement a process for developing an allocation method

3.1.3.     Regardless of whether an allocation method is needed or not, coordinate with ICANN staff to modify contractual terms of registry agreements regarding reservation of single letter names at the second and (if applicable) the third level.

3.2.  Guidelines for work

3.2.1.     It may be helpful to consult with the ICANN General Counsel's office as a first step regarding task 3.1.1.

3.2.2.     The members of the Single-Character/Two-Character Name subgroup did considerable work on this topic and as such could serve as helpful resources in any additional work that is authorized.

4.      Geographic and Geopolitical Names (recommendations 20 - 22)

4.1.  Proposed work task: It is recommended that the New gTLD Committee (Dec05 PDP) consider whether and how recommendations 20 to 22 can be incorporated into the selection process for the introduction of new gTLDs.

4.2.  Guidelines for work: The subgroup did not propose any specific guidelines but did provide extensive rationale for the recommendations; that rationale may prove useful in evaluating the recommendations for inclusion in the selection process.

5.      Controversial Names (recommendations 23 -30)

5.1.  Proposed work task: It is recommended that the New gTLD Committee (Dec05 PDP) consider whether and how recommendations 23 to 30 can be incorporated into the selection process for the introduction of new gTLDs.

5.2.  Guidelines for work:

5.2.1.     Recommendations 25 - 28 provide specific ideas that can be developed further by the New gTLD Committee.

5.2.2.     Recommendation 29 provides the following guidelines for additional work:

5.2.2.1.    Further work is needed to develop predictable and transparent criteria that can be used by the Controversial Resolution Panel. These criteria must take into account the need to:

·        Protect freedom of expression

·        Affirm the fundamental human rights, in the dignity and worth of the human person and the equal rights of men and women

5.2.2.2.    Take into account sensitivities regarding terms with cultural and religious significance.

5.2.3.     Recommendation 30 suggests the following for consideration by the New gTLD Committee: In any dispute resolution process, or sequence of issue resolution processes, the Controversial name category should be the last category considered.


SECTION FIVE - REFERENCE MATERIAL

GNSO Working Group Original Report:

http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf

Previous subgroup reports:

http://gnso.icann.org/drafts/

IDN Guidelines:

http://www.icann.org/announcements/announcement-2-11may07.htm

GAC Public Policy Principles:

http://gac.icann.org/web/home/gTLD_principles.pdf

Each subgroup report in annexes one through seven contains additional reference material used by the subgroup.


ANNEX ONE - ICANN/IANA SUB GROUP REPORT

GNSO new TLDs Committee

Reserved Names Working Group

Sub-Group Report

ICANN & IANA Reserved Names

10 May 2007


DEFINITIONS

ICANN & IANA names

ICANN: aso, gnso, icann, internic, ccNSO

IANA: afrinic, apnic, arin, example, gtld-servers, iab, iana, iana-servers, iesg, ietf, irtf, istf, lacnic, latnic, rfc-editor, ripe, root-servers

EXECUTIVE SUMMARY

1.      This Report contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding ICANN and IANA reserved names.

2.      The subgroup consists of Mike Rodenbaugh, BCUC, and Edmon Chung, RyC.

3.      The subgroup recommends that the existing reservations be maintained, until further work to evaluate the reservation of these names is completed.

4.      There was no disagreement in the subgroup regarding the below recommendations.

5.      The table below contains the recommendations for ICANN/IANA names.


SoW number

(RN-WG 30-day extension SoW)

Reserved Name Category

Domain Name Level(s)

Recommendation

Recommendation task 1

ICANN & IANA

All ASCII

Maintain the existing reservation requirement and extend it to the top level until further work is completed. Further work is recommended to send questions, receive and compile responses from organizations with related reserved names, and draft a report to the GNSO Council. Examples are icann.net, or admin.iana.

Recommendation task 1

ICANN & IANA

Top level, IDN

For all but "example", reservations are not required for Unicode versions in various scripts, or ACE versions of such translations or transliterations if they exist.

All possible Unicode versions of the name "example" must be reserved

The New gTLD Committee should validate this recommendation with IDN experts.

Recommendation task 1

ICANN & IANA

2nd & 3rd levels, IDN

For all but "example", reservations are not required for Unicode versions in various scripts, or ACE versions of such translations or transliterations if they exist.

Do not try to translate 'example' into Unicode versions for various scripts or to reserve any ACE versions of such translations or transliterations if they exist, except on a case by case basis as proposed by given registries.

The New gTLD Committee should validate this recommendation with IDN experts.

Minority Position from Mike Palage

(Originally submitted as part of the original RN-WG Report dated, 16-March-2007.)

In accordance with Article I, Section 2 subparagraph 8 of the ICANN bylaws it states that in performing its mission, the following core values should guide the decisions and actions of ICANN "[m]aking decisions by applying documented policies neutrally and objectively, with integrity and fairness." Unlike other reservations that are based upon long standing and well established principles, ICANN/IANA staff has sought to continue reservation of a compilation of strings in which they have been unable to provide any documentation regarding the legal authority for such reservation. For ICANN/IANA to continue to reserve these names while similarly situated parties, in this case sovereign national governments (country names), IGOs and nationally recognized trademark holders, are not provided equal protection appear to be a clear violation of the bylaw provision cited above. More detailed discussion regarding the legal concerns regarding these reservations has been documented on the working group's mailing list, see
http://forum.icann.org/lists/gnso-rn-wg/msg00169.html.

In order for this or any other working group to make a determination based upon documented fact, the following inquiries should be explored:

- ICANN should make available to the group all written and historical references to the original basis of these reservations;
- ICANN should contact all organizations that have had their name reserved, and ask for documentation in connection with any actual confusion or security/stability concerns that have arisen in connection with the use of these strings in legacy gTLD (.com, .net and .org);
- ICANN should ask these organizations if they would prefer to have ICANN continue to reserve these names in existing and future TLDs, and the basis of this reservation request; and

- ICANN should undertake an analysis to determine any third parties that may have rights in the reserved strings (i.e. nationally registered trademarks, etc) and how this reservation potentially negatively impacts those rights."


Supporting Information

1.      Background

This report provides an overview and assesses the current status of the category of reserved names related to ICANN and IANA. As such, the reserved names are not available for registration by members of the public.

More specifically, the Registry Agreements negotiated by ICANN state that "the following names shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations".

The two tables below present the set of reserved names for two organizations: ICANN and IANA. In the case of ICANN, there are five reserved names for each registry. In the case of the IANA, there are seventeen (17) for each registry.

Table 1: ICANN-related names,

in order of year of ICANN-Registry agreement

GTLD

Reserved Names

Date of Agreement

.aero

aso

dnso

icann

internic

pso

2001

.coop

aso

dnso

icann

internic

pso

2001

.museum

aso

dnso

icann

internic

pso

2001

.name

aso

dnso

icann

internic

pso

2001

.pro

aso

dnso

icann

internic

pso

2002

.jobs

aso

gnso

icann

internic

ccnso

2005

.mobi

aso

gnso

icann

internic

ccnso

2005

.net

aso

gnso

icann

internic

ccnso

2005

.travel

aso

gnso

icann

internic

ccnso

2005

.cat

aso

gnso

icann

internic

ccnso

2005

.tel

aso

gnso

icann

internic

ccnso

2006

.asia

aso

gnso

icann

internic

ccnso

2006

.biz

aso

gnso

icann

internic

ccnso

2006

.com

aso

gnso

icann

internic

ccnso

2006

.info

aso

gnso

icann

internic

ccnso

2006

.org

aso

gnso

icann

internic

ccnso

2006


Table 2: IANA-Related Names

TLD

Reserved Names

.aero

.asia

.biz

.cat

.com

.coop

.info

.jobs

.mobi

.museum

.name

.net

.org

.pro

.tel

.travel

All names in Reserved Names column at right are reserved in each TLD at left.

afrinic

apnic

arin

example

gtld-servers

iab

iana

iana-servers

iesg

ietf

irtf

istf

lacnic

latnic

rfc-editor

ripe

root-servers

Justification for ICANN reserved names

The words reserved by ICANN are mostly acronyms that basically relate to the organization structures (bodies) and functions, as it has evolved, and the justification for reservation was deemed by the original RN-WG subgroup as "obvious." The current subgroup believes further work should be done to justify these reservations, and/or to consider their release.

The "schedule of reserved names" was born with the new TLD registry agreements in early 2001. A consultation with ICANN officials resulted in the following: no one recalls any record of any public or private document that describes the rationale for having a scheduled names list, or that describes the reasons why particular strings were included (or excluded).

Some members of the Working Group on Reserved Names believe that ICANN and IANA should not be able to reserve names corresponding to those entities, since all other entities must register names in order to keep them from public use.

A further point was made by Patrick Jones of ICANN, in relation to ICANN- and IANA-reserved names.

"… just to clarify that IANA/ICANN names are reserved, provided that if ICANN/IANA or the related entities whose names are on reserve wanted to use one of the names, those names could be registered by the requesting entity. For example, ICANN registered and paid for the registration costs to un-reserve ICANN.jobs. If ICANN wanted to use ICANN.info in the future, it should be able to un-reserve the name."

Justification for IANA's reserved names

There has been little need in the past to justify decisions about some reserved names, some of which must date from the days of John Postel. A search by ICANN Staff has revealed only a few paragraphs here and there of justification. The current subgroup believes further work should be done to justify these reservations, and/or to consider their release.

The IANA-reserved names relate to functions and institutions within the purview of IANA: subordinate name servers, IANA's regional nodes, the request for comment editor, and so forth.

The standard explanation offered to those seeking to register such names is basically given by IANA along the following lines.

General responses to other reserved domains:



Thank you for your enquiry.

Domain names reserved by the Internet Assigned Numbers Authority are not available for sale, registration or transfer. These have been reserved on policy grounds, and include single letter domains, domains with hyphens in the third and fourth positions, and other reserved words.

Should the policies regarding these rules change, they will be released from IANA's registration according to revised policy.

A note on http, https, and html

In the course of the work of the Working Group, the question of whether the following names should also be reserved has come up. They are:

http, https and html.

A review of the Whois sites showed that, as of March 5, http.org had been registered. All three names are currently registered in .com and there appear to be no issues with them: 

https.com since 1999 (monetized)

http.com since 1995 (not currently resolving)

html.com since 1993 (hosting company)

2.      Rationale for the recommendations

The original WG report found no historical support for the reservations, stating that 'the justification for the reservation is … obvious.' The further work recommended by the subgroup is designed to justify the reservation, or consider release of these names.

Process description

3.      Expert Consultation

Affected organizations with related names on the ICANN and IANA reserved name lists and other ICANN stakeholder groups should be consulted as follows.

The subgroup has requested ICANN Staff to send the following request to all such organizations, with responses requested by a specific date that allows reasonable time for responses:

As part of the input into its Policy Development Process regarding new gTLDs, the GNSO formed a Working Group to examine current name reservations in registry operator agreements and to recommend whether those reservations should be continued, modified or discontinued.  The Registry Agreements negotiated by ICANN state that "the following names shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations".

The Working Group has stated thus far:  The role of the reserved names held by IANA and ICANN has been to maintain for those organizations the exclusive rights to the names of ICANN (icann), its bodies (aso, ccnso, pso, etc.) or essential related functions (internic) of the two organizations.

Do you believe that names on the attached table -- which correspond or relate to your organization -- should continue to be reserved, at all levels, in all current and future gTLDs?  

If yes, please state the reasons why you believe such exclusive rights should be reserved in all gTLDs, and describe how you have used or may intend to use these domains in the 16 existing gTLDs, any existing ccTLDs, and in any other TLDs that may be added in the future.

If no, please state which name reservations need not continue, or if you believe the reservation should be modified (i.e., reservations only needed at top level) then please state this.

Please provide the name of the person completing this questionnaire, and any additional comments or questions that you or your organization may have for the WG. Your response is requested not later than 30 May 2007.

4.      Summary of Relevant Information Sources

The original RN-WG ICANN/IANA subgroup report can be found at:

http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf


ANNEX TWO -- SINGLE AND TWO CHARACTER RESERVED NAMES SUB GROUP REPORT (Including Symbols)

GNSO new gTLDs Committee

Reserved Names Working Group

Sub-Group Report - Single and Two Character Labels

10 May 2007


DEFINITIONS

A-Label

ASCII-compatible (ACE) form of an IDNA-valid string. See http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt. An example is xn--1lq90i.

Character

A character may be a letter, digit, hyphen or symbol.

For the purposes of discussing IDNs, a "character" can best be seen as the basic graphic unit of a writing system, which is a script plus a set of rules determining how it is used for representing a specific language. However, domain labels do not convey any intrinsic information about the language with which they are intended to be associated, although they do reveal the script on which they are based. This language dependency can unfortunately not be eliminated by restricting the definition to script because in several cases (see examples below) languages that share the same script differ in the way they regard its individual elements. The term character can therefore not be defined independently of the context in which it is used.

In phonetically based writing systems, a character is typically a letter or represents a syllable, and in ideographic systems (or alternatively, pictographic or logographic systems) a character may represent a concept or word.

The following examples are intended to illustrate that the definition of a character is at least two-fold, one being a linguistic base unit and the other is the associated code point.

U-label 酒 : Jiu; the Chinese word for 'alcoholic beverage'; Unicode code point is U+9152 (also referred to as: CJK UNIFIED IDEOGRAPH-9152); A-label is xn-jj4

U-label 北京 : the Chinese word for 'Beijing', Unicode code points are U+5300 U+4EAC; A-label is xn-1lq90i

U-label 東京 : Japanese word for 'Tokyo', the Unicode code points are U+6771 U+4EAC; A-label is xn-1lqs71d

U-label ایكوم; Farsi acronym for ICOM, Unicode code points are U+0627 U+06CC U+0643 U+0648 U+0645; A-label is xn-mgb0dgl27d.

Single and Two Character Labels

Prior to the release of IDNA, the characters available for inclusion in domain names consisted of a limited number of alphanumeric elements (a, . . . , z; 0,..., 9; "-"), and policies could easily be based on the number of characters any label contained. There is no similar generally applicable way to compare the length of, for example, an ideographic and an alphabetic string, or even a sequence of characters taken from the basic Latin alphabet with a decorated version of the same sequence.

In Czech, <ch> is a single letter (or character -- the concepts do not differ in this regard) whereas in English it is two. In Danish, <æ> is the 27th letter of the alphabet. It is a single character and does not decompose to <a e>. Depending on who you ask and their linguistic background, there are either 12 or 13 characters in the English word <encyclopædia>.  If written as <encyclopaedia>, all would agree on 13. Differentiation by considering semantic value does not help. In Turkish, there is a difference between a dotted <i> and a dotless <ı>. In English, there is no such distinction. Whether the dot is to be counted as a character in its own right or not will again depend on who you ask and what language they view the word as being written in.

Symbols

While the DNS supports all of the printable characters in the US-ASCII character table not all such characters are made available in domain names. Symbols, such as #, $, &, !, *, -, _, +, =, are not available for registration in domain names because the top-level domain registries decided (before internationalization) to adopt the hostname rule for registration of domain names. The hostname rule, defined in RFC 952 and updated in RFC 1123, specifies that only letters, digits and hyphens (a-z, 0-9, -) are valid characters in hostnames.

Tagged Names

All labels with hyphens in both the third and fourth character positions (e.g., "bq-1k2n4h4b" or "xn-ndk061n").

U-Label

An IDNA-valid string of Unicode-coded characters; the representation of the Internationalised Domain Name (IDN) in Unicode. See http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt. An example is 北京, the U-Label for the Chinese word "Beijing".


EXECUTIVE SUMMARY

1.      This Report contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding single and two character labels.

2.      The subgroup members included:

Greg Shatan (IPC - Subgroup Chair)

Neal Blair (BC)

Marilyn Cade (BC)

Alistair Dixon (BC)

Avri Doria (Nom Com appointee)

Patrick Jones (ICANN Staff)

Jonathan Nevett (Registrars)

Mike Rodenbaugh (BC)

Victoria McEvedy (NCUC) (Resigned from RN-WG on 24 April 2004)

3.      The original recommendations that formed the basis of this report were approved by the RN WG for inclusion in the 19 March 2007 RN-WG report. Following the ICANN meeting in Lisbon, Portugal, and throughout the 30-day extension period, the subgroup refined the recommendations and incorporated additional information. These recommendations represent the consensus of the subgroup.

4.      A minority position has been inserted in the explanation for the following subcategory: two letters at the top level.

5.      The table below contains the recommendations for single and two character labels (for letters, digits, symbols and IDNs).

SoW number

(RN-WG 30-day extension SoW)

Reserved Name Category

Domain Name Level(s)

Recommendation

Recommendation task 2

Symbols

ALL

We recommend that current practice be maintained, so that no symbols other than the '-' [hyphen] be considered for use at any level, unless technology at some time permits the use of symbols.[20]

Recommendation task 3(a)

Single and Two Character IDNs

IDNA-valid strings at all levels

Single and two-character U-labels on the top level and second level of a domain name should not be restricted in general. At the top level, requested strings should be analyzed on a case by case basis in the new gTLD process depending on the script and language used in order to determine whether the string should be granted for allocation in the DNS. Single and two character labels at the second level and the third level if applicable should be available for registration, provided they are consistent with the IDN Guidelines.[21]

Examples of IDNs include .酒, 東京.com, تونس.icom.museum.

Recommendation task 3(b)

Single Letters

Top Level

We recommend reservation of single letters at the top level based on technical questions raised. If sufficient research at a later date demonstrates that the technical issues and concerns are addressed, the topic of releasing reservation status can be reconsidered.

Examples of names that would not be allowed include .a, .z.

Recommendation task 3(b)

Single Letters and Digits

2nd Level

We recommend that single letters and digits be released at the second level in future gTLDs, and that those currently reserved in existing gTLDs should be released. This release should be contingent upon the use of appropriate allocation frameworks. More work may be needed.

Examples include a.com, i.info.

Recommendation task 3(b)

Single and Two Digits

Top Level

We recommend digits be reserved at the top level, in order to avoid potential confusion with IP addresses within software applications. Examples include .3, .99.

Recommendation task 3(b)

Single Letter, Single Digit Combinations

Top Level

Applications may be considered for single letter, single digit combinations at the top level in accordance with the terms set forth in the new gTLD process. Examples include .3F, .A1, .u7.

Recommendation task 3

Two Letters

Top Level

We recommend that the current practice of allowing two letter names at the top level, only for ccTLDs, remain at this time.[22]

Examples include .AU, .DE, and .UK.

Recommendation task 3(b)

Any combination of Two Letters, Digits

2nd Level

Registries may propose release provided that measures to avoid confusion with any corresponding country codes are implemented.[23] Examples include ba.aero, ub.cat, 53.com, 3M.com, e8.org.

 

 

 

Minority Statement

 

Mike Rodenbaugh on two letters at the top level:

I recommend that two letter ASCII gTLDs be allowed. A standardized approach should be used which ensures consultation with appropriate parties, including the ccNSO and ISO 3166 Maintenance Agency, and where security and stability issues are identified, SSAC. While there may be political reasons, there appears no strong policy reason to withhold every possible two-letter TLD from use, on the assumption that some of them may be desired by countries that may be created in the future. The GAC principle assumes there will be 'user confusion' if two letter codes are allowed other than for ccTLDs, but this is not substantiated -- and there are many ccTLDs that are visually very similar to other ccTLDs (including .ch and .cn which are two of the larger ccTLDs). In addition, this concern would diminish if countries were able to use their own name as a TLD, including in its IDN form, or in an IDN two letter ccTLD.


Supporting Information

Background

Recommendations are provided for each of the following eight subcategories:

  • Symbols
  • Single and two-character IDNs
  • Single letters at the top level
  • Single letters and digits at the second level
  • Digits at the top level
  • Single letter, single digit combinations at the top level
  • Two letters at the top level
  • Any combination of two letters and digits at the second level

This report will examine the above subcategories, recognizing that the technical and policy issues may differ across each of the subcategories. The purpose of this report is to examine whether there are any technical, policy or practical concerns about releasing these names. Domain names are defined in RFC 1034 (published in November 1987 and recognized as an Internet Standard, ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt).

The initial treatment of using a 'reservation' developed with Jon Postel and involved both single and two character strings. Some discussion about reserved names can be traced back to specific RFCs, while the 'reservation category' has also evolved via gTLD registry agreements. The reserved names list was created during the proof-of-concept round of new gTLDs in 2001. The reserved names list was a topic of discussion during the ICANN Meeting in Melbourne, Australia in March 2001. An information page on the registry agreement appendices was first posted in February 2001 (http://www.icann.org/melbourne/new-tld-agreements-topic.htm). Subsequently, the category of Geographical and Geopolitical names was added to some of the Reserved Names appendices.

In all gTLD registry agreements as of 1 May 2007, single-character labels are reserved at the second-level and two-character labels are initially reserved.[24]

It appears that the original purpose for reserving the single characters was driven by technical concerns. Two letter reservations appear to have been based on concerns about confusion with two letter country codes.

The work of the Single and Dual Character Reserved Names Subgroup (now Single and Two Character Labels Subgroup) was originally included as Appendix E in the GNSO Reserved Names Working Group Report dated 19 March 2007, http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf. This update incorporates inputs received during the ICANN meeting in Lisbon, Portugal, references the GAC Principles on New gTLDs, http://gac.icann.org/web/home/gTLD_principles.pdf, the GNSO IDN Working Group Outcomes Report, http://gnso.icann.org/drafts/idn-wg-fr-22mar07.htm, and inputs received during the 30 day extension of the Reserved Names Working Group.

RECOMMENDATION ONE: SYMBOLS

We recommend that current practice be maintained, so that no symbols other than the '-' [hyphen] be considered for use at any level, unless technology at some time permits the use of symbols.

Rationale

The hostname convention defined in RFC 952[25] (later modified by RFC 1123) states that domain names must consist of the letters a-z; the numbers 0-9, and the hyphen-dash (-). "." has a special status: it is permitted by the DNS but used as a "separator" for labels. Only letters, digits and hyphens are permitted at present in the DNS, to the left of the TLD.

Consultation with experts

Discussions with technology experts indicate that there would not be support for making any changes to allow the release of symbols in one or two character domain names, at any level.

RECOMMENDATION TWO: SINGLE AND TWO CHARACTER IDNs

Single and two-character U-labels on the top level and second level of a domain name should not be restricted in general. At the top level, requested strings should be analyzed on a case by case basis in the new gTLD process depending on the script and language used in order to determine whether the string should be available for allocation in the DNS. This is notwithstanding the rule that the ISO-3166 list will continue to be reserved and as such all two character ASCII strings (i.e., LDH-labels) will remain reserved at the top level and second level of a domain name, although registries may propose release of two character strings at the second level provided that measures to avoid confusion with any corresponding country codes are implemented. Single and two character labels at the second level should be available for registration, provided they are consistent with the IDN Guidelines.

Rationale

In a resolution approved by the ICANN Board on 25 September 2000, the Board recognized "it is important that the Internet evolve to be more accessible to those who do not use the ASCII character set" but stressed that "the internationalization of the Internet's domain name system must be accomplished through standards that are open, non-proprietary, and fully compatible with the Internet's existing end-to-end model and that preserve globally unique naming in a universally resolvable public name space."[26]

Once ICANN opens the process for new TLD applications, it is expected that many of those applications may be for IDNs. In some scripts, such as Chinese, Japanese and Korean, single and two characters frequently translate into words, concepts or phrases. Because of this, it is not advisable to maintain the existing reservation against single and two-character U-Label strings for IDNs. Applications should be reviewed on a script by script basis.

As examples, single and two character IDNs currently exist as second and third level domain names in both ccTLDs and gTLDs.

http://中国.icom.museum directs visitors to http://china.icom.museum/.

http://한국.icom.museum directs visitors to http://www.icomkorea.org/board/index2.php.

The GAC Communique released in Lisbon, Portugal acknowledged the joint GAC-ccNSO-GNSO IDN Working Group, and noted a draft issue paper on the selection of IDN ccTLDs associated with the ISO-3166 list. The GAC is continuing to work with the ccNSO on this issue, because in many languages and scripts country names cannot be abbreviated, and it may be difficult to assign internationalized versions of the ISO-3166 list. The GAC is continuing to develop guidance on IDN TLDs that will be incorporated into the new gTLD process.

While not specifically written for IDNs, the GAC Principles regarding New gTLDs released in Lisbon contain a number of recommendations relevant to single and two character IDNs:[27]

1.3 A gTLD is a top level domain which is not based on the ISO 3166 two-letter country code list. For the purposes and scope of this document, new gTLDs are defined as any gTLDs added to the Top Level Domain space after the date of the adoption of these principles by the GAC.

2.4 In the interests of consumer confidence and security, new gTLDs should not be confusingly similar to existing gTLDs. To avoid confusion with country-code Top Level Domains no two letter gTLDs should be introduced.

The GAC Principles do not address single and two character labels in IDNs.

The GNSO IDN Working Group (IDN WG) Report (http://gnso.icann.org/drafts/idn-wg-fr-22mar07.htm) provides some guidance on single and two character IDNs. The IDN WG found broad agreement in:

4.1.3, Language Community Input for Evaluation of New gTLD Strings

4.1.5, Limit Variant Confusion and Collision

4.1.6, Limit Confusingly Similar Strings

The IDN WG found support in:

4.2.9, Support for a country's rights to define/reserve IDN strings for the country name

4.2.22, Support for regarding "confusingly similar" as "visually confusingly similar" or "typographically confusingly similar"

4.2.23, Support for IDN considerations for extension of reserved names list, possibly by introducing the notion of "reserved concepts" (for example; the concept of "example" as expressed in other languages/scripts)

The IDN WG and GAC Principles recognize that there may be issues of user confusion related to the introduction of IDNs at the top level. ICANN should be concerned about the potential for user confusion in scripts that share similarities, such as confusion between single and two character labels in Cyrillic, Greek and Latin scripts, or confusion between Chinese, Japanese and Korean scripts that share characters, or Farsi and Arabic, etc.

Previous ICANN Board resolutions on IDNs also provide guidance to the Reserved Names Working Group on single and two character labels in IDNs. On 27 March 2003, the ICANN Board endorsed the IDN Implementation approach in the Guidelines for the Implementation of Internationalized Domain Names (http://www.icann.org/minutes/minutes-27mar03.htm). On 18 February 2004, the Board adopted a resolution to permit VeriSign and Public Interest Registry to begin test bed registration of IDNs in the .COM, .NET and .ORG gTLDs.

On 8 December 2006, the ICANN Board issued a detailed resolution on IDNs (http://www.icann.org/minutes/minutes-08dec06.htm). The Board requested "the ccNSO and the GAC, through a joint collaborative effort, in consultation as needed with the relevant technical community, to produce an issues paper relating to the selection of IDN ccTLDs associated with the ISO 3166-1 two-letter codes."

Additional examples of existing registrations of single and two character IDNs at the second level include:

U-label: 円.biz

A-label: xn--w6q.biz

Translation: Japanese Yen

Pronunciation (Romanji): en

Script: Han

U-label: 龙.biz

A-label: xn--yi7a.biz

Translation: Dragon

Pronunciation (Mandarin): long2

Script: Han

U-label: 信息.biz

A-label: xn--vuq861b.biz

Translation: information

Pronunciation (Mandarin): xin4 xi2

Script: Han

U-label: ラブ.biz

A-label: xn--tdkub.biz

Translation: "love" transliterated into Japanese Pronunciation (Romanji): rabu

Script: Katakana

U-label: すし.biz

A-label: xn--68jd.biz

Translation: sushi

Pronunciation: sushi

Script: Hiragana

U-label: 寿司.biz

A-label: xn--sprr0q.biz

Translation: sushi

Pronunciation: sushi

Script: Han

[Examples provided by William Tan at NeuStar, http://forum.icann.org/lists/gnso-sl-wg/msg00019.html.]

On 28 March 2007, during the ICANN meeting in Lisbon, Portugal, the GAC-ccNSO-GNSO joint working group on IDNs held a workshop focusing on policy issues related to the introduction of IDNs at the top level (http://www.icann.org/meetings/lisbon/agenda-idn-wg-28mar07.htm). A transcript from the workshop is available at http://www.icann.org/meetings/lisbon/transcript-idn-wg-28mar07.htm. This session generated good discussion on issues related to implementation of IDNs, including single and two character labels in IDNs.

On 16 April 2007, the GAC and GNSO had a telephone conference to discuss IDN issues within the context of the GAC Principles on New gTLDs.[28] As part of this discussion, GAC members were asked about single and two character IDNs. Cary Karp asked a question "about scripts where the concept of letter is irrelevant, such as two Chinese ideograms." Bill Dee, the EU representative on the GAC, stated "I think that is something we need to cover when we come with our IDN Principles, but we need to discuss it within the GAC first. So this is really useful that you have raised this. You have started a train of thought that we are going to have to pursue, obviously."

Based on the 16 April 2007 conference call, the GAC is likely to provide further guidance to ICANN on single and two character labels in IDNs as part of the GAC Principles on IDNs. The GAC may benefit from the consideration of single and two character labels by the Reserved Names Working Group.

Consultations with experts

A number of consultations have occurred with IDN experts, linguistic experts, and members of the Subgroup, the full RN Working Group and with members of the GNSO IDN Working Group. The full RN Working Group had a conference call with Cary Karp and Ram Mohan on 1 March 2007. Several discussions occurred on IDN implications for Reserved Names during the ICANN meeting in Lisbon, Portugal. The GAC and GNSO discussed IDN issues as part of the discussion of the GAC Principles regarding New gTLDs on 16 April 2007.

Extensive consultation has occurred with Cary Karp and Tina Dam in the consideration of single and two character labels in IDNs.

Consultations on definition of character

Consultations occurred with Michael Everson, Tina Dam, Cary Karp, and Chuck Gomes. Cary Karp and Tina Dam provided extensive analysis of the draft definition and examples.

According to a 26 April 2006 email from Cary Karp, "Digits are also characters, but the status of what an Anglophone would regard as diacritical marks, is far less clear in other contexts where what is sometimes term[ed] 'decoration' is added to 'base' characters. Graphic symbols such as punctuation marks may also be termed characters, and the status of other graphic devices such as dingbats and smiley faces can also be argued."

RECOMMENDATION THREE: SINGLE LETTERS AT THE TOP LEVEL

We recommend reservation of single letters at the top level, based on technical questions raised. If sufficient research at a later date demonstrates that the technical issues and concerns are addressed, the topic of releasing reservation status can be reconsidered. Examples of names that would not be allowed include .a, .z.

Rationale

Single letter gTLDs have never been released by ICANN. In 2000, ICANN received an application for .i. This application was not approved (see http://www.icann.org/tlds/i1/).

RFC 1035 (see http://www.ietf.org/rfc/rfc1035.txt) states that domain names "must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less."[29] RFC 1035 was updated by RFC 1123 (ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1123.txt.pdf), so that domain names may start with either a letter or a digit.

There may be potential user confusion from mistaking certain single letters and digits (i.e., .l versus .1, .m versus .n, .q versus .g) due to visual similarity.

Some businesses own trademarks in single letters, such as Overstock, Nissan Motors, T-Mobile and Yahoo! [Examples are provided merely for illustration and discussion.] Such trademark owners may be interested in registering a corresponding gTLD.

According to research conducted by IANA, out of 9540 possible combinations of single-character LDH names at the second level (containing 26 letters, 10 numbers, but not symbols, across 265 TLDs), 1225 delegations of single-character LDH names exist in the zone. 63 TLDs have at least one single-character LDH delegation (see http://forum.icann.org/lists/gnso-rn-wg/msg00039.html).

During the discussions, consideration was given to releasing single letters at the top level. The Sub Group considered that that single letter and digit domains are widely in use at the second level in country codes and as IDNs, and initially thought it would be feasible to examine how to release and allocate single letter top level names. Members of the Sub Group were aware from RFC reviews and other sources that there could be technical concerns and potential 'resolution' issues regarding the use of single letter and digit domains at the second level in a single letter TLD (e.g., 1.a or a.a), and undertook outreach to two technical experts to learn more about the technical issues.

The release and allocation of single letters at the second level has been subject of some discussion during the PDP regarding contractual terms for TLD registries; this is addressed as a separate recommendation.

Consultation with experts

In addition to reviewing relevant RFCs, an interactive consultation was held on 23 April 2007 by the Subgroup with two technical experts, Steve Bellovin (http://www.cs.columbia.edu/~smb/) and Mark McFadden (http://www3.uwm.edu/sce/instructor.cfm?id=249). Both experts discussed the concern with interaction with letters at both the top and the second level as a problem. The transcript for that discussion can be found in the subgroup archive at (http://forum.icann.org/lists/gnso-sl-wg/).

RFC 1535 points out that there can be search order issues where an application attempts to resolve a domain name string.

On May 8, a follow up email was received from Steven Bellovin and is provided below, describing in more detail the technical issues associated with letters at the top level.

Sent: Tuesday, May 08, 2007 9:51 PM

"I read just the portions you cited.

Mostly ok, but...

1.5:

This is wrong:

     However, due to technical concerns, we recommend that single character (LDH) names be reserved at the second level in any single letter TLD.

Single-letter TLDs are bad if there are single-letter second level names anywhere, and vice-versa.  The problem is not restricted to direct descendants.  For example, suppose that .a and .foo are TLDs.  If I'm on host xyzzy.foo and ask for 'a', do I get a. -- the TLD? -- or a.foo? This is the problem described in RFC 1535. (Yes, it can happen with longer names; it was a real incident that inspired that RFC.)

The same concerns apply to this text:

       However, there may be technical concerns regarding the use of       single letter and digit domains at the second level in a single letter TLD (e.g., 1.a or a.a).  Allocation of single letters at both the top level and second level in combination may [will??] cause certain older DNS software applications to incorrectly resolve.   

and

      If single letter TLDs are unreserved, single letters at the second level would need to be reserved in these domains.

and

      Single letters at the second level would need to be reserved in single letter TLDs until this problem has been eliminated."

[email snipped. Relevant section provided under recommendation 5].

References

RFC 1535

23 April 2007 RN WG - Subgroup Teleconference with Technical Experts (http://forum.icann.org/lists/gnso-sl-wg/msg00006.html).

GAC Principle 1.4: referencing ICANN core values/bylaw: "preserving operational stability, reliability, security and global interoperability of the Internet."

GAC Principle 2.6: "It is important that the selection process for new gTLDs ensures the security, reliability, global interoperability and stability of the Domain Name System (DNS) and promotes competition, consumer choice, geographical and service provider diversity".

RECOMMENDATION FOUR: SINGLE LETTERS AND DIGITS AT THE SECOND LEVEL

We recommend that single letters and digits be released at the second level in future gTLDs, and that those currently reserved in existing gTLDs should be released. This release should be contingent upon the development of an appropriate allocation framework.

Rationale

Currently, all 16 gTLD registry agreements (.aero, asia, .biz, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net, .org, .pro, .tel and .travel) provide for the reservation of single-character names at the second level. ICANN's gTLD registry agreements contain the following provision on single-character names. See Appendix 6 of the .TEL Registry Agreement, http://www.icann.org/tlds/agreements/tel/appendix-6-07apr06.htm ("the following names shall be reserved at the second-level: All single-character labels.").

Letters, numbers and the hyphen symbol are allowed within second level names in both top level and country code TLDs. Single letters and numbers also are allowed as IDNs -- as single-character Unicode renderings of ASCII compatible (ACE) forms of IDNA valid strings.

Before the current reserved name policy was imposed in 1993, Jon Postel took steps to register all available single character letters and numbers at the second level, purportedly to reserve them for future extensibility of the Internet (see 20 May 1994 email from Jon Postel, http://ops.ietf.org/lists/namedroppers/namedroppers.199x/msg01156.html). All but six (q.com, x.com, z.com, i.net, q.net, and x.org) of the possible 144 single letters or numbers at the second-level in .COM, .EDU, .NET and .ORG were registered and remain reserved by IANA. Those six registrations have been grandfathered, and several have been used for various purposes and/or transferred amongst different registrants. Under current policy, these names would be placed on reserve if the registrations were allowed to expire.

Since the initial registration of single-letter names by IANA, IANA has uniformly turned down all offers by third parties to purchase the right to register these names, and has advised these parties that the names are reserved for infrastructure purposes to help ensure stable operation of the Internet.

An email of 27 May 2000 to the then DNSO-GA list provides further background on single-letter names (see http://www.dnso.org/clubpublic/ga/Arc04/msg00442.html).

According to research conducted by IANA, out of 9540 possible combinations of single-character ASCII names (containing 26 letters, 10 numbers, but not symbols, across 265 TLDs), 1225 delegations of single-character LDH names exist in the zone. 63 TLDs have at least one single-character LDH delegation (see http://forum.icann.org/lists/gnso-rn-wg/msg00039.html).

We understand that some businesses may own trademarks in single letters, such as Overstock, Nissan Motors, T-Mobile and Yahoo! [Examples have been provided merely for illustration and discussion.] These trademark owners, if they have not already registered their single-character trademarks as domain names, may be interested in doing so across a number of TLDs.

There may be potential user confusion from mistaking certain single letters and digits at the top level due to visual similarity (i.e., 1.com versus l.com, m.com versus n.com, q.com versus g.com).

Given that single letter and number second level domains are widely used in country codes and as IDNs, and six letters are used in the existing legacy generic top level domains at the second level, it seems feasible to examine how to release and allocate single letter and number second level names. The release and allocation of single letters has been subject of some discussion during the PDP regarding contractual terms for TLD registries.

Consultation with experts

Single letters and numbers are widely delegated at the second level, in 63 TLDs and as IDN (U-label) versions. Therefore, we presume there is no technical reason why remaining letters, at least, should remain reserved.

While it appears that single letters and digits at the second level can be released, further examination of allocation options is needed.

In relation to the special case of single letter second level names in single letter TLDs, consultation with technical experts identified the problem that RFC 1535 discusses as likely to be experienced with combinations of single letters at the top and second level. (RFC1535 discusses security problems posed by some resolvers that attempt to resolve a partial name by processing a search list of partial domains to be added to portions of the specified host name until a DNS record is found.) .

RECOMMENDATION FIVE: DIGITS AT THE TOP LEVEL

We recommend continuation of the reserved status for digits at the top level, in order to avoid potential confusion with IP addresses, within software applications. Examples include .3, .99. Note: see later recommendation which proposes to continue to allow allocation of digits at the second and third levels, including single digits.

Rationale

Allocation of numbers at both the top level and second level in combination may cause DNS software applications to incorrectly deem a URL composed only of numbers as an IP address.

In addition to the DNS software issue, there are also legacy software applications that will interpret if certain numbers, such as "00", are omitted, and, if they are, insert numbers into a string, thus causing misdirection.

Consultation with experts

Single numbers have been denied in previous gTLD rounds. Discussions among the full RN WG have identified the concern about conflict with IP addresses, when numbers appear at both the second and top levels.

In addition to reviewing relevant RFCs, an interactive consultation was held on 23 April 2007 by the Subgroup with two technical experts, Steve Bellovin and Mark McFadden. Both experts discussed the concern with interaction with numbers at both the top and the second level as a problem. The transcript for that discussion can be found in the subgroup archive at (http://forum.icann.org/lists/gnso-sl-wg/).

On May 8 and 9, two emails were received from Steven Bellovin and relevant sections are provided below, describing in more detail the technical issues associated with digits.

Sent: Tuesday, May 08, 2007 9:51 PM

"I read just the portions you cited.

Mostly ok, but...

Section of email produced in 1.4 is not reproduced here. .

1.6:

Numbers at the top and second level *will* cause problems.  Here's some text from RFC 3493 -- not an IETF standard, but I think it is a Posix standard, and it is present on all modern UNIX systems, i.e.., it's not just legacy software.

   If the nodename argument is not null, it can be a descriptive name or can be an address string.  If the specified address family is AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host names. If the specified address family is AF_INET or AF_UNSPEC, address strings using Internet standard dot notation as specified in inet_addr() are valid.

This RFC doesn't define the behavior of inet_addr(), but Solaris and Linux specify that it accepts ddd.ddd.  I think (but haven't verified) that Posix requires that."

Sent: Wednesday, May 9, 2007

"I confirmed that UNIX standards *require* that ddd.ddd be interpreted as described; see http://www.opengroup.org/onlinepubs/000095399/functions/getaddrinfo.html

and

http://www.opengroup.org/onlinepubs/000095399/functions/inet_addr.html

To be quite explicit: any program that uses IEEE standard 1003.1 *will* be confused by ddd.ddd." end of email.

References related to digits at the top level

RFC 1535

GAC Principle 1.4: referencing ICANN core values/bylaw: "preserving operational stability, reliability, security and global interoperability of the Internet."

GAC Principle 2.6: "It is important that the selection process for new gTLDs ensures the security, reliability, global interoperability and stability of the Domain Name System (DNS) and promotes competition, consumer choice, geographical and service provider diversity".

RECOMMENDATION SIX: SINGLE LETTER, SINGLE DIGIT COMBINATIONS AT THE TOP LEVEL

Applications may be considered for two character names combining a single letter and single digit, in either order at the top level in accordance with the terms set forth in the new gTLD process. Release of combinations of one letter and one digit at the top level can be allowed. Examples may be L0, or 2K.

Rationale

Combinations of numbers and letters exist at the second level, and there appears to be no technical prohibition to a single letter and a single number combination at the top level.

There may be further considerations regarding how numbers and letters may be mistaken for each other by the user, due to visual similarity, such as '10', versus 'lO' (lower case 'l' and upper case 'O', where a user searching for a domain name, where numbers are allowed at the second level, and a user is searching for a 333.1O, but types '333.10. Numbers at the top level are not recommended - see recommendation five.)

Consultation with experts

In addition to reviewing RFC 1535, an interactive consultation was held with Steve Bellovin and Mark McFadden. A transcript is available in the subgroup archive at (http://forum.icann.org/lists/gnso-sl-wg/). Except for user confusion in mistaking a letter for a number and then mistyping certain combinations, there does not appear to be a technical issue with a combination of number and letter at the top level.

References

RFCs 952, 1123, 1535

Expert discussion with Steve Bellovin and Mark McFadden was held on 23 April 2007. They did not suggest that there are likely to be problems per se.

RECOMMENDATION SEVEN: TWO LETTERS AT THE TOP LEVEL

We recommend that the current practice of allowing two letter names at the top level, only for ccTLDs, remain at this time. The subgroup was encouraged by the ccNSO not to consider removing the restriction on two-letter names at the top level. IANA has based its allocation of two-letter names at the top level on the ISO 3166 list. There is a risk of collisions between any interim allocations, and ISO 3166 assignments which may be desired in the future.

Minority Statement by Mike Rodenbaugh

I recommend that two letter ASCII gTLDs be allowed. A standardized approach should be used which ensures consultation with appropriate parties, including the ccNSO and ISO 3166 Maintenance Agency, and where security and stability issues are identified, SSAC. While there may be political reasons, there appears no strong policy reason to withhold every possible two-letter TLD from use, on the assumption that some of them may be desired by countries that may be created in the future. The GAC principle assumes there will be 'user confusion' if two letter codes are allowed other than for ccTLDs, but this is not substantiated -- and there are many ccTLDs that are visually very similar to other ccTLDs (including .ch and .cn which are two of the larger TLDs). In addition, this concern would diminish if countries were able to use their own name as a TLD, including in its IDN form, or in an IDN two letter ccTLD.

Rationale

To date, two-character TLDs have been released only as two letter ccTLDs. No combinations of letters and numbers, and no two-number strings have been allocated at the top level. The subgroup conducted expert outreach to examine any implications of release of such combination or two-digit TLDs.

An early RFC issued in October 1984 (RFC 920) defined country codes as the "The English two letter code (alpha-2) identifying a country according the ISO Standard for 'Codes for the Representation of Names of Countries'. This RFC was issued before ccTLDs had been established (see ftp://ftp.rfc-editor.org/in-notes/rfc920.txt, page 7).

RFC 1032, issued in November 1987, states that "countries that wish to be registered as top-level domains are required to name themselves after the two-letter country code listed in the international standard ISO-3166."

Two character/letter strings at the top level are now identified with the ISO 3166 list, which has a two letter code associated with all of the over 200 countries and recognized economies. Country code or ccTLDs correspond directly to the two character letters on the ISO 3166 list. The ISO 3166Maintenance Agency governs the list of country codes. Further information on the ISO 3166 list is available at http://www.iso.org/iso/en/prods-services/iso3166ma/index.html. According to RFC 1591, "IANA is not in the business of deciding what is and is not a country" (http://www.rfc-editor.org/rfc/rfc1591.txt). "The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list."

Further, RFC 1591 defines a country code as "a domain in the top level of the global domain name system assigned according to a two-letter code based on the ISO 3166-1 standard 'Codes for the Representation of Names of Countries and Their Subdivisions."

In the 2000 round, ICANN received an application for .GO. This string was not allocated on the ISO 3166 list to a country. This application was rejected.

The GAC Principles and Guidelines for the Delegation and Administration of Country-Code Top Level Domains (5 April 2005) contains a statement on ccTLDs:

4.1.2. Every country or distinct economy with a government or public authority recognized in accordance with article 3.8 above should be able to ask for its appropriate country code to be represented as a ccTLD in the DNS and to designate the Registry for the ccTLD concerned.

A 27 February 2007 email from IANA Technical Liaison Kim Davies provides context to support the reservation of two-letter strings at the top level for use as future ccTLDs (see http://forum.icann.org/lists/gnso-rn-wg/msg00163.html).

A 4 March 2007 email from ccNSO Council Chair Chris Disspain states in part:

"gTLDs in ASCII - there is, if I understand it correctly, a current prohibition on issuing new gTLDs with 2 characters. I imagine the vast majority of the ccTLD community would be in favour of this prohibition being retained. Apart from anything else, reservation of 2 characters at the top level is the only way of ensuring that a new ccTLD code will be available for new territories."

There may be potential user confusion from mistyping combinations of letters and numbers (e.g., .c0 versus .co, .t0 versus .to, .1I versus .li, m0 versus .mo), with two-number strings (.00 versus .oo, .11 versus .ll, .l0 versus .1o), and with two-letter strings (ll versus li, .vy versus .yv, .pq vs. .pg).

The GAC Principles regarding New gTLDs, released on 28 March 2007, state:

1.3 A gTLD is a top level domain which is not based on the ISO 3166 two-letter country-code list.

2.4 In the interests of consumer confidence and security, new gTLDs should not be confusingly similar to existing TLDs. To avoid confusion with country-code Top Level Domains no two letter gTLDs should be introduced.

Consultation with experts

Two letter strings at the top level have only been allowed for country codes as defined by the ISO 3166 list. Chris Disspain, Chair of the ccNSO, believes the vast majority of the ccTLD community would be in favour of this practice being retained. Kim Davies, IANA Technical Liaison believes the current practice should be continued, as a policy matter, due to potential need for some two-letter strings by future countries.

RECOMMENDATION EIGHT: ANY COMBINATION OF TWO LETTERS, DIGITS AT THE SECOND LEVEL

We recommend that registries may propose release of two letter and/or digit strings at the second level, provided that measures to avoid confusion with any corresponding country codes are implemented. A standardized approach should be used which ensures consultation with appropriate parties, including the ccNSO and ISO-3166 Maintenance Agency, and where security and stability issues are identified, RSTEP.

The existing gTLD registry agreements provide for a method of potential release of two-character LDH names at the second level. In addition, two character LDH strings at the second level may be released through the process for new registry services, which process involves analysis of any technical or security concerns and provides opportunity for public input. Technical issues related to the release of two-letter and/or number strings have been addressed by the RSTEP Report on GNR's proposed registry service. The GAC has previously noted the WIPO II Report statement that "If ISO 3166 alpha-2 country code elements are to be registered as domain names in the gTLDs, it is recommended that this be done in a manner that minimizes the potential for confusion with the ccTLDs."

Rationale

In 2001, in considering a proposal from .AERO for the limited release of two-letter airline codes, a GAC Communique (http://www.icann.org/committees/gac/communique-09sep01.htm) noted that the WIPO II report addressed this category of names and recommended that "If ISO 3166 alpha-2 country code elements are to be registered as domain names in the gTLDs, it is recommended that this be done in a manner that minimizes the potential for confusion with the ccTLDs." This recommendation has been incorporated into the reserved names appendix of 14 of ICANN's current, gTLD registry agreements.

The WIPO II Report is available at http://www.wipo.int/amc/en/processes/process2/report/html/report.html and included in this report under Section 5(k).

Fourteen out of sixteen of the present gTLD registry agreements (.aero, asia, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net, .pro, .tel and .travel) provide for the reservation of two-character names at the second level, via the following provision. (See, e.g., Appendix 6 of the .TEL Registry Agreement, http://www.icann.org/tlds/agreements/tel/appendix-6-07apr06.htm.)

Except to the extent that ICANN otherwise expressly authorizes in writing, the Registry Operator shall reserve names formed with the following labels from initial (i.e. other than renewal) registration within the TLD: … All two-character labels shall be initially reserved. The reservation of a two-character label string shall be released to the extent that the Registry Operator reaches agreement with the government and country-code manager, or the ISO 3166 maintenance agency, whichever appropriate. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes.

Two of the sixteen present gTLD strings, .BIZ and .ORG registry agreements say only "Registry Operator shall reserve names formed with the following labels from initial (i.e. other than renewal) registration within the TLD: … All two-character labels shall be initially reserved." See http://www.icann.org/tlds/agreements/biz/appendix-06-08dec06.htm and http://www.icann.org/tlds/agreements/org/appendix-06-08dec06.htm).

There may be potential user confusion between the combination of letters and numbers (e.g., c0.com versus co.com; t0.com versus to.com; 1I.com versus li.com, m0.com versus mo.com), with two-number strings (00.com versus oo.com, 11.com versus ll.com), and with two-letter strings (ll.com versus li.com, vy.com versus yv.com).

At the second level, two-character names have been registered, re-sold directly or via auction, and/or transferred by a wide variety of parties for many years. The GNR RSTEP report noted that there have been 18 UDRP cases involving two-character names at the second level.

Some businesses use two letter identifiers or two-character abbreviations, such as FT for Financial Times, GM for General Motors, DT for Deutsche Telecom, BT for British Telecom, HP for Hewlett-Packard, or have corporate names of characters and number, such as 3M. [Examples are provided merely for illustration and discussion.] These trademark owners, if they have not already registered their two-character trademarks as domain names, may be interested in doing so across a number of TLDs.

In the past, ICANN has approved the release of certain two-character names from the reserved names lists through one-on-one communication with the requesting registry operator. There are no public information sources on the release of these names, but in the past ICANN has agreed to the release of e8.org, a2.coop, nz.coop and uk.coop. NZ.coop and UK.coop were released with the approval of the UK and NZ government representatives and ccTLD managers. A2.coop and e8.org were released without objection from the ISO 3166-Maintenance Agency. On 25 May 2004, the ICANN Board approved the limited release of two-character airline codes in .AERO (http://www.icann.org/minutes/resolutions-25may04.htm). On 16 January 2007, the ICANN Board approved the limited use of two-character names in .NAME (http://www.icann.org/minutes/prelim-report-16jan07.htm) (see summary of relevant information sources below for further information on the GNR proposal).

On 21 February 2007, Fundacío puntCAT proposed release of three two-character names from the .CAT Sponsorship Agreement (UB.cat, UV.cat and UA.cat). Only UA.cat corresponds to a country code TLD (Ukraine). ICANN approved this release on 7 March 2007, subject to certain conditions.

On 13 March 2007, EmployMedia proposed release of two-character names from the .JOBS Sponsorship Agreement. On 28 March 2007, ICANN approved this release, subject to certain conditions.

The existing registry agreement provisions provide a mechanism for the release of two-character names at the second level, as set forth above. In addition, registries may submit a proposal for the release of two-character names through the process for new registry services (also known as the "Funnel"), which was approved as a GNSO Consensus Policy on 8 November 2005 (http://www.icann.org/minutes/resolutions-08nov05.htm) and implemented 25 July 2006 (http://www.icann.org/announcements/rsep-advisory-25jul06.htm and http://www.icann.org/registries/rsep/rsep.html).

Consultation with experts

Second level strings with two letters and/or digits have been widely used for a long time. Therefore we presume there is no technical reason why remaining strings should remain reserved. There may be other policy or political reasons to maintain the present reservation process, unless registries follow the previously given GAC advice and propose release of two-character names using methods to avoid confusion with any corresponding country codes.

In 2001 the GAC addressed potential release of two-character names at the second level as part of its consideration of a request from .AERO for the limited release of two-letter airline codes. This issue has been addressed in 14 registry agreements as set forth above. Two-digit or letter-digit combinations, and two-letter combinations that are not likely to correspond to country codes, should be possible at the second level.

SUMMARY OF RELEVANT INFORMATION SOURCES

1. ICANN Staff's Status Report on Single-Level Domains, dated 12 September 2005.

2. Recent data from Kim Davies at IANA, showing single-letters delegated in 63 TLDs (http://forum.icann.org/lists/gnso-rn-wg/msg00039.html), and from Patrick Jones, showing almost 3000 single- and dual-character domains for sale at Sedo: 7 February 2007 email from Patrick Jones on Sedo auction (http://forum.icann.org/lists/gnso-rn-wg/msg00041.html and http://forum.icann.org/lists/gnso-rn-wg/msg00042.html). .

3. Correspondence:

·        29 April 2007 email from William Tan to Patrick Jones, http://forum.icann.org/lists/gnso-sl-wg/msg00019.html.

·        8 March 2007 email from Roberto Gaetano to GA list on single-letter names (http://gnso.icann.org/mailing-lists/archives/ga/msg06100.html).

·        8 March 2007 email from Patrick Jones to RN WG on TRAFFIC auction of two-character names (http://forum.icann.org/lists/gnso-rn-wg/msg00275.html)

·        20 January 2007 email from John Klensin on single-letter names to GNSO Council (http://gnso.icann.org/mailing-lists/archives/council/msg03166.html)

·        20 January 2007 email from Patrick Jones to Liz Williams for GNSO Council on GNR proposal and Funnel process (http://gnso.icann.org/mailing-lists/archives/council/msg03165.html)

·        18 January 2007 email from John Klensin on single-letter names to GNSO Council list (http://gnso.icann.org/mailing-lists/archives/council/msg03164.html)

·        Policy Recommendation from Overstock.com, May 2006 (insert hyperlink)

·        Letter from Overstock.com, 28 November 2006 (http://www.icann.org/correspondence/warren-to-board-28nov06.pdf).

·        Letter from Yahoo to ICANN, 12 December 2005 (http://www.icann.org/correspondence/filo-to-icann-12dec05.pdf).

·        Letter from Lisa Martens to John Jeffrey, 12 December 2005 (http://www.icann.org/correspondence/martens-to-jeffrey-12dec05.pdf).

·        Letter from Overstock.com, 11 November 2005 (http://www.icann.org/correspondence/byrne-to-twomey-11nov05.pdf).

·        Letter from K Computing, 30 June 2005 (http://www.icann.org/correspondence/dankwardt-to-pritz-30jun05.htm).

4. GNR proposal re two-character names, and supporting docs, 2006.

·        GNR Proposal: http://www.icann.org/registries/rsep/GNR_Proposal.pdf

·        Submitted Applications page on GNR proposal (http://www.icann.org/registries/rsep/submitted_app.html#2006004).

·        20 October 2006 ICANN letter to RSTEP (http://www.icann.org/registries/rsep/icann-to-rstep20oct06.pdf)

·        RSTEP Report on GNR Two-character name proposal (http://www.icann.org/registries/rsep/RSTEP-GNR-proposal-review-team-report.pdf).

·        16 January 2007 ICANN Board Resolution approving GNR service (http://www.icann.org/minutes/prelim-report-16jan07.htm).

5. "Rainbow document" from Chuck Gomes re existing gTLD contract conditions re Reserved Names - see Appendix K in the original RN-WG report at http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf.

6. Additional historical information on two-character names:

·        25 May 2004 Board resolution approving release of two-character strings in .AERO: http://www.icann.org/minutes/resolutions-25may04.htm.

·        9 Sept 2001 GAC Communique: http://www.icann.org/committees/gac/communique-09sep01.htm.

·        30 Aug 2001 Letter from ISO 3166/MA to Louis Touton & Paul Twomey: http://www.icann.org/tlds/wischhoefer-to-touton-30aug01.htm.

7. Correspondence from Kim Davies to Tim Denton, dated 7 January 2007:

"The single-letter/number domains in .com, .net, .org, .edu, .biz, .info, .name, .pro, .aero, .coop, and .museum are reserved by the IANA.

Accordingly, these names are not for "sale" or subject to transfer under established policy. A few of the single-letter names were registered before this reservation was made.

The IANA obtained the registration for most single-character names under .com in 1993 to implement a policy designed to enhance the extensibility of the domain-name space.

Since then, these names have been continuously under registration by the IANA. The IANA has received many inquiries from people seeking to register these names. As required by the existing policy, the IANA advises those inquiring that these names are already registered to the IANA and reserved for infrastructure purposes to help ensure stable operation of the Internet. The IANA has uniformly turned down all offers by third parties to purchase the right to register these names.

Four of the single-character names under .com were registered by other parties before the IANA entered its registration of these names. The registrations of these names have been (and are) grandfathered for the time being. Recently some of these registrations have been transferred from one third party to another. Those transfers are consistent with the grandfathering policy.

Having assumed the responsibility for operating the IANA, and for overall technical management of the Internet, ICANN is following the same policies for the operation of the IANA as were followed by Dr. Postel and his colleagues at the Information Sciences Institute. ICANN's charter and bylaws, together with its obligations under its various agreements with the United States Government, establish consensus-based procedures for modification of existing policies, fostering participation by affected parties. Until the policy is changed by the established procedures, ICANN is required to continue its registration of the single-letter .com domain names for the benefit of the Internet community."

There is also an Information page at http://res-dom.iana.org/.

8. Email correspondence from Kim Davies, IANA Technical Liaison, to Patrick Jones, posted on RN WG list 27 February 2007: http://forum.icann.org/lists/gnso-rn-wg/msg00163.html.

RFC 1591, sect 2 reads:

"In the Domain Name System (DNS) naming of computers there is a hierarchy of names. The root of system is unnamed. There are a set of what are called "top-level domain names" (TLDs). These are the generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two letter country codes from ISO-3166."

As any possible two-letter combination is eligible to be allocated or reserved in the ISO 3166-1 alpha-2 standard in the future, the working group is strongly encouraged not to consider using these possibilities for other applications. There is a risk of collisions between such allocations, and future ISO-3166 assignments, and in such cases would mean ICANN is unable to grant a ccTLD to a valid country.

IANA has, since the introduction of the DNS, relied upon the determinations within the ISO-3166 standard to identify what constitutes a country, and what is the appropriate two-letter code for that country. This shields the organisation from making value judgments that would be very political, and instead lets and independent third party decide (the ISO 3166 Maintenance Agency, which is guided by the United Nations Statistics Office). On this matter, RFC 1591 is clear:

"The IANA is not in the business of deciding what is and what is not a country."

The selection of the ISO 3166 list as a basis for country code top-level domain names was made with the knowledge that ISO has a procedure for determining which entities should be and should not be on that list."

The ISO-3166 standard is not static, and evolves with changes to countries and their territories. Most importantly, new codes are added for new regions and countries. Just this year "AX", "ME" and "RS" have been new additions. One can assume there will be more changes in the future that we can not predict.

If a conflict is introduced between a newly created ccTLD code, and an allocated gTLD, IANA's neutrality would be compromised. It would either need to deprive a country of a country-code top-level domain, or it would need to stop adhering to the ISO 3166 standard which would be problematic. It would represent a key divergence from one of the most central tenets of ccTLD policy.

9. Email from Chris Disspain to Patrick Jones, dated March 4, 2007:

I am copying this to the ccNSO members and council lists. Those who wish to comment, will you please send your comments to Gabi (gabriella.schittek@icann.org) who will collate them and forward to Patrick.

I am unclear as to whether the draft report is intended to deal only with reserved names/characters in ASCII and so I'd like to make the following general points in respect to reserved names/characters at the top level. I believe this issue splits into 2 categories:

gTLDs in ASCII - there is, if I understand it correctly, a current prohibition on issuing new gTLDs with 2 characters. I imagine the vast majority of the ccTLD community would be in favour of this prohibition being retained. Apart from anything else, reservation of 2 characters at the top level is the only way of ensuring that a new ccTLD code will be available for new territories.

IDNs - here is where the problems start. I won't go into details here of the myriad challenges of .idn but the issue of reserved names serves to illustrate my serious concerns about the GNSO's decision to couple new gTLD policy with IDN policy. What is a relatively simple issue for new ASCII gTLDs (see paragraph above) becomes a minefield in respect to .idn. This is because there are currently no rules and no precedents.

So, for example, we could say that all 2 character names at the top level are reserved for ccTLD registrations in both ASCII and IDN characters but that assumes that new .idn ccTLDs will be limited to 2 characters and that is an assumption which cannot be made at this stage. It might end up being the case but we can't assume it now.

Further, the ccTLD community cannot sensibly create ccTLD .idn policy on an issue by issue basis. Reserved names is but one issue of many and whilst we can sensibly comment on it in regard to ASCII names we cannot in regard to IDNs.

If the report on single and dual characters is intended to cover only ASCII (and if that is the case then it needs to say so clearly) then I imagine that you will be able to get input from the cc community within a reasonable time. However, if it is also intended to cover IDNs the ccNSO will, I suspect, be unable to respond at this stage and the matter will need to be placed in the 'further time and research' category that you have outlined below.

Finally, I believe that this situation is not isolated and my response above is likely to arise time and time again with respect to IDNs where there are cc and g crossover issues.

10. GAC Principles and Guidelines for the Delegation and Administration of Country-Code Top Level Domains (5 April 2005)

4.1.2. Every country or distinct economy with a government or public authority recognized in accordance with article 3.8 above should be able to ask for its appropriate country code to be represented as a ccTLD in the DNS and to designate the Registry for the ccTLD concerned.

11. WIPO II Report (Second WIPO Internet Domain Name Process, published 3 September 2001), http://www.wipo.int/amc/en/processes/process2/report/html/report.html.

19. The ccTLDs are those top-level domains which bear two letter codes essentially derived from the International Organization for Standardization's (ISO) Standard 3166.

ISO 3166 Country Code Elements

254.   The origin of the codes reflecting country top-level domains is the International Organization for Standardization (ISO).  ISO, which was established in 1947 as a non-governmental organization, is a worldwide federation of national standards bodies from 137 countries.  Its mission is to promote the development of standardization and related activities in the world with a view to facilitating the international exchange of goods and services, and to developing cooperation in the spheres of intellectual, scientific, technological and economic activity. [244] One of ISO's most famous standards is Part 1 of ISO 3166 concerning codes for the representation of names of countries and their subdivisions.  Part 1 of ISO 3166 contains two letter country codes (alpha-2 codes; for example, au for Australia) and three letter country codes (alpha-3 codes, for example, aus for Australia).  It is on the basis of the alpha-2 codes that the country code top-level domains (ccTLDs) were created by the Internet Authority for Assigned Names and Numbers (IANA) during the late eighties and early nineties. [245]  Since the creation of the ccTLDs, registrations in the country domains have flourished, as the use of the Internet has spread throughout the world.  It is expected that the importance of the ccTLDs will continue to grow in the future.

255.   A phenomenon concerning ccTLDs that merits attention is the registration at the second level in the gTLDs of the country code elements (for example, uk.com).  Often these domain names are registered by persons or entities in order to make them available to the public for the registration of names at the third level (for example, company.uk.com). [246]  The implications of such practices are discussed below.

ISO 3166 Country Code Elements

268.   The Interim Report recommended the exclusion of the ISO 3166 alpha-2 country code elements from registration as domain names in the new gTLDs, in the absence of an agreement to the contrary from the relevant competent authorities.  Furthermore, the Interim Report recommended that persons or entities who have registered such codes at the second level in the existing gTLDs and who accept registrations of names under them should take measures to render the UDRP applicable to such lower level registrations.

269.   Several commentators favored the exclusion mechanism proposed in the Interim Report for the ISO 3166 alpha-2 country code elements, [278] while others opposed it. [279]  Some of the entities offering the possibility of registrations under the codes in the existing gTLDs have expressed a willingness to adopt the UDRP or a similar procedure, as recommended in the Interim Report.[280]  Few administrators of ccTLDs submitted comments on the Interim Report's recommendations in this area.  Trademark owners have expressed concerns that the exclusion mechanism proposed in the Interim Report would prevent the legitimate registration of two-letter trademarks or acronyms of trademarks. [281]

ISO 3166 Alpha-2 Country Code Elements

290.   The Interim Report formulated two recommendations in relation to ISO 3166 country code elements.  First, it proposed that these codes be excluded from registration in the new gTLDs, unless the relevant authorities grant permission for their registration.  Secondly, it recommended that persons or entities who have registered such codes at the second level in the existing gTLDs and who accept registrations of names under them take measures to ensure that the UDRP applies to such lower level registrations. 

291.   In connection with the first recommendation, we note that the current version of Appendix K to the Registry Agreements between ICANN and the sponsors and operators of the new gTLDs states that [a]ll two-character labels shall be initially reserved.  The reservation of a two-character label string shall be released to the extent that the Registry Operator reaches agreement with the government and country-code manager, or the ISO 3166 maintenance agency, whichever appropriate.  The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes. [292]

Exclusions for ISO 3166 Country Code Elements.  A number of factors, highlighted in the comments and reactions received on the Interim Report, have lead us to re-consider our recommendation that the ISO 3166 alpha-2 country code elements should be excluded from registration as domain names in the gTLDs.  These factors are as follows:

(i)     While, on the Internet, the ISO 3166 codes have been associated in particular with country code top-level domains, in the physical world they find broad application and use throughout a wide variety of industries.  This is consistent with the nature and purpose of the standard, which itself states that [it] provides universally applicable coded representations of names of countries and that [it] is intended for use in any application requiring the expression of current country names in coded form. (Emphasis added)[293]  We observe that some of the industries which traditionally have used the ISO 3166 codes to structure themselves in the physical world are migrating some aspects of their operations to the online world, and that this trend may intensify in the future.  As they move to the Internet, these industries may wish to rely on the same codes to replicate their structures in the networked environment, including the DNS.  Excluding the registration of the ISO 3166 codes as domain names may, under certain circumstances, unfairly hamper those industries in their on-line activities, by establishing an overly exclusive linkage between the codes in question and the country domains.

(ii)     Certain ISO 3166 country codes correspond to the acronyms of other identifiers, in particular trademarks.  Excluding the codes from registration in the DNS would prevent such other identifiers from being registered as domain names without seeming justification.

292.   In light of the above considerations, we no longer subscribe to the view that the ISO 3166 country code elements should be excluded from registration in the new gTLDs under all circumstances.  Nonetheless, we remain concerned that, depending on the manner in which these codes are registered and used in the DNS, confusion may be created with the ccTLDs.  That being the case, we believe that the proper focus should be on the avoidance of confusion with regard to those codes, rather than on an absolute prohibition of their registration and use.

293.   If ISO 3166 alpha-2 country code elements are to be registered as domain names in the gTLDs, it is recommended that this be done in a manner that minimizes the potential for confusion with the ccTLDs.

12. Transcript from Reserved Names Working Group meeting in Lisbon, Portugal, 24 March 2007, http://www.icann.org/meetings/lisbon/transcript-gnso-new-gtlds-24mar07.htm.

13. GAC Principles on New gTLDs, http://gac.icann.org/web/communiques/gac27com.pdf

14. RFCs & BCPs

RFC 920, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc920.txt.pdf

RFC 952, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc952.txt.pdf

RFC 1032, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1032.txt.pdf

RFC 1034, ftp://ftp.rfc-editor.org/in-notes/rfc1034.txt

RFC 1035, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1035.txt.pdf

RFC 1123, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1123.txt.pdf. 
RFC 1535, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1535.txt.pdf.    
RFC 1591, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1591.txt.pdf 

RFC 1815, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1815.txt.pdf

RFC 3454, http://www.ietf.org/rfc/rfc3454.txt

RFC 3490, Internationalizing Domain Names in Applications (IDNA), ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc3490.txt.pdf

RFC 3491,ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc3491.txt.pdf

RFC 3492, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc3492.txt.pdf

RFC 3743, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc3743.txt.pdf

RFC 4185, National and Local Characters for DNS Top Level Domain (TLD) Names (ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc4185.txt.pdf).

RFC 4290, Suggested Practices for Registration of Internationalized Domain Names (ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc4290.txt.pdf).

RFC 4690, Review and Recommendations for Internationalized Domain Names (http://www.ietf.org/rfc/rfc4690.txt).

http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt

http://www.ietf.org/internet-drafts/draft-faltstrom-idnabis-tables-01.txt

BCP 18, IETF Policy on Character Sets and Languages (http://www.rfc-editor.org/rfc/bcp/bcp18.txt).



15. The GNSO IDN Working Group used the following definition of 'character': "a member of a set of elements used for the organization, control, or representation of data." This definition is identical to the definition appearing in ISO 10646 (http://std.dkuug.dk/JTC1/SC2/WG2/) and appears in the Unicode Consortium definition of 'character' (http://www.unicode.org/glossary/#C).

16. Definition of character used by GNSO IDN Working Group: http://idn.wat.ch/wiki/index.php?title=Working_Definitions#.E2.80.9Ccharacter.E2.80.9D.

17. January 2002 Internet Draft, written by Paul Hoffman, http://www.icann.org/committees/idn/draft-hoffman-i18n-terms-05.txt

18. ISO 10646 Technical Report: Information Technology - An operational model for characters and glyphs (1998), http://std.dkuug.dk/JTC1/SC2/WG2/docs/tr15285:1998.pdf

19. 30 March 2007 Letter from Bruce Tonkin to Janis Karklins, http://gnso.icann.org/correspondence/tonkin-to-karklins-30mar07.pdf.

20. 16 April 2007 GAC-GNSO New gTLD Committee Teleconference transcript, http://gnso.icann.org/meetings/transcript-gac-gnso-new-gtlds-16apr07.pdf.

21. 13 June 2002 IDN Committee paper on Non-ASCII TLD Policy Issues, http://www.icann.org/committees/idn/non-ascii-tld-paper-13jun02.htm.

22. 13 June 2002 IDN Committee paper on Registry Selection Considerations for Non-ASCII TLDs, http://www.icann.org/committees/idn/registry-selection-paper-13jun02.htm

23. Link to Outcomes Report of the GNSO IDN Working Group: http://gnso.icann.org/drafts/idn-wg-fr-22mar07.htm.

24. RN WG Teleconference 1 March 2007, expert consultation on IDNs with Cary Karp and Ram Mohan, http://gnso.icann.org/meetings/transcript-rn-wg-01mar07.pdf.

25. GAC, GNSO, ccNSO Workshop on IDNs, 28 March 2007, http://www.icann.org/meetings/lisbon/transcript-idn-wg-28mar07.htm.

26. GAC-GNSO New gTLD Committee Teleconference, 16 April 2007, http://gnso-audio.icann.org/gtld-gac-20070416.mp3.

27. Information on current gTLD registry implementations of IDNs is available at the following links:

.BIZ - http://www.neulevel.biz/idn/

.INFO - http://www.afilias.info/faqs/idn_registrant_faq

.MUSEUM - http://about.museum/idn/

.ORG - http://www.pir.org/GetAOrg/IDN.aspx

.COM/.NET - http://www.verisign.com/information-services/naming-services/internationalized-domain-names/index.html.

28. 27 June 2002 IDN Committee Final Report, http://www.icann.org/committees/idn/final-report-27jun02.htm.

29. Unicode Consortium, Chapter 4, http://www.unicode.org/versions/Unicode4.0.0/ch04.pdf.

30. Panel discussion on IDNs at Yale University, Access to Knowledge Conference, 27 April 2007, http://research.yale.edu/isp/a2k/wiki/index.php/Internationalized_Domain_Names




ANNEX THREE -- TAGGED NAMES SUB GROUP REPORT

GNSO new TLDs Committee

Reserved Names Working Group

Sub-Group Report - Tagged Names


DEFINITION

Tagged Names

All labels with hyphens in both the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")

EXECUTIVE SUMMARY

1.      This Report contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding tagged names.

2.      Chuck Gomes and Patrick Jones served as the subgroup for this report.

3.      The recommendations of this report were approved by the full RN-WG.

4.      There was no disagreement with the recommendations and hence no minority positions.

5.      The table below contains the recommendations for ASCII tagged names as well as one recommendation with regard to application requirements for IDN gTLDs. Note that the concept of tagged names is not applicable because only ASCII names are allowed in the DNS.

SoW number

(RN-WG 30-day extension SoW)

Reserved Name Category

Domain Name Level(s)

Recommendation

Recommendation task 4

Tagged Names

Top Level ASCII

In the absence of standardization activity and appropriate IANA registration, all labels with hyphens in both the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n") must be reserved in ASCII at the top level.[30]

Recommendation task 4

N/A

Top Level IDN

For each IDN gTLD proposed, applicant must provide both the "ASCII compatible encoding"  ("A-label") and the "Unicode display form" ("U-label")[31] For example:

  • If the Chinese word for 'Beijing' is proposed as a new gTLD, the applicant would be required to provide the A-label (xn--1lq90i) and the U-label (北京).
  • If the Japanese word for 'Tokyo' is proposed as a new gTLD, the applicant would be required to provide the A-label (xn--1lqs71d) and the U-label (東京).

Recommendation task 4

Tagged Names

2nd Level ASCII

The current reservation requirement be reworded to say, "In the absence of standardization activity and appropriate IANA registration, all labels with hyphens in both the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n") must be reserved in ASCII at the second (2nd) level.[32] - added words in italics. (Note that names starting with "xn--" may only be used if the current ICANN IDN Guidelines are followed by a gTLD registry.)

Recommendation task 4

Tagged Names

3rd Level ASCII

All labels with hyphens in both the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n") must be reserved in ASCII at the third (3rd level) for gTLD registries that register names at the third level."[33] - added words in italics. (Note that names starting with "xn--" may only be used if the current ICANN IDN Guidelines are followed by a gTLD registry.)


Supporting Information

1.      Background

All existing ICANN registry agreements as of 25 April 2007 contain the requirement for gTLD registries to reserve all labels with hyphens in the third and fourth positions (e.g., "xn--ndk061n"). This requirement comes directly from the approved technical standards for Internationalized Domain Names (IDNs) (found on the ICANN website at http://www.icann.org/topics/idn/implementation-guidelines.htm). Note that this reservation requirement does not specify any domain name level, so it is assumed that it applies to all levels of names registered by a given gTLD registry.

Only ASCII characters are permitted in the Domain Name System (DNS) thereby limiting characters to the letters a-z, the numbers 0-9 and the hyphen-dash (-), the last of which cannot be the first or last character of a domain name. Consequently, to be able to allow representation of domain names in non-ASCII characters, standards were developed in the Internet Engineering Task Force (IETF) that map international scripts to strings of ASCII characters. Those standards require that all ASCII representations of IDNs begin with a 4-character prefix with hyphens in the third and fourth positions.

The current prefix is "xn--". To avoid confusion of IDNs with ASCII names having the same prefix, it is necessary to reserve the "xn--" prefix. Prior to the finalization of the IDN standards, other prefixes were used, the most recent of which was "bq--". At that time, speculators started registering ASCII names with the "bq--" prefix. To avoid this possibility with future prefixes, it was decided to reserve all prefixes of this form.

It is also important to note that the current prefix might need to be changed in the future. If that happens, confusion will be avoided by the fact that all labels with hyphens in the third and fourth positions are reserved.

For further information regarding IDNs, please refer to the ICANN Internationalized Domain Names (IDN) information area: http://www.icann.org/topics/idn/.

2.      Rationale for the recommendations

The role of the tagged name reservation requirement is to be able to provide a way to easily identify an IDN label in the DNS and to avoid confusion of non-IDN ASCII labels. Implicit in this role is the need to reserve tagged names for future use in case the ASCII IDN prefix is changed.

The rationale for the recommendations of tagged ASCII names then is to avoid user confusion that might result in not being able to tell the difference between a legitimate IDN name and an illegitimate one and to provide maximum flexibility in the unlikely case that the xn-- prefix should ever need to be changed.
The reason for recommending that applicants for IDN gTLDs be required to provide both the A-label and the U-label is to ensure that there is a one-to-one mapping between the ASCII compatible (ACE) form of an IDNA valid string and Unicode representations.


3.      Consultation with experts

The Tagged Name Subgroup relied on the advice of Ram Mohan (Chair of the GNSO IDN Working Group, Member of the ICANN President's IDN Committee, and Member of the ICANN IDN Guidelines Working Group), Cary Karp (Member of the GNSO IDN Working Group, Member of the ICANN President's IDN Committee, and Member of the ICANN IDN Guidelines Working Group) and Tina Dam (ICANN IDN Program Director) as experts and did not believe that additional expert consultation was needed for the topic of tagged name reservations. On 1 March 2007 a full WG consultation with Ram, Cary and Tina was held to assist in the finalization of reports for other reserved name categories with regard to IDNs.

The following questions were asked of Ram and Tina:

Would it be possible to only reserve a subset of the tagged names of the form character-character-dash-dash instead of all 1296 variations?

If so, how big a subset would be needed?

Would we need feedback from the technical community in this regard?

If so, who do you think we should contact in that regard?

Here is Ram's response:

"The IETF has defined "xn--" for IDNA, as you know.  It is safe to say that questions of defining a subset of the available CCHH range should definitely be run by the IAB, with a note sent to the IAB Chair (Leslie).

"To your question regarding how big a subset would be "needed", the fact is that all CCHH names are restricted so that we don't have charlatans who sell unwitting customers some other CCHH name(s) that will absolutely not work with the existing technical protocols for resolving IDN names worldwide.  Therefore, my sense is that it is much safer to restrict all CCHH combinations than to allow just a few, because the end-user is just not going to be able to tell the difference between a legitimate IDN name and an illegitimate one."

Here is Tina's response:

". . I agree with Ram. There is no reason currently to believe that the xn prefix will change but I still think it might be a good pre-caution to keep all labels with "--" in third and fourth place reserved.

One additional comment. The reservation of these kinds of labels must include a process for allowing such reserved labels to be registered (at the time where internationalized top level labels are available for registration) and possible some reference to the Unicode version of that label (following the IDNA protocol) is reserved as well. The latter is to make sure that both the stored and displayed names are reserved together. More specific and clear terminology for the stored/displayed label will come for the protocol revision work. As soon as this is available I will send you another note for potential inclusion in the RN-WG work."

Numerous exchanges occurred involving Tina and Ram to clarify Tina's suggestion regarding Unicode versions of labels. Rather than pasting all of the email (the full mail archive is found at http://forum.icann.org/lists/gnso-idn-wg/ ), we report that the basic suggestion is that, for any IDN gTLDs that are proposed, the applicant should be required to provide the "ASCII compatible (ACE) form of an IDNA valid string" representations along with the corresponding Unicode representation to ensure that there is a one-to-one mapping between the "ASCII compatible (ACE) form of an IDNA valid string" and Unicode representations.

Tina also reported that clearer terminology will come from the protocol revision group and suggests that all IDN related WGs incorporate this terminology. It is expected that the protocol revision, soon to be released, will likely recommend against the use of the term "punycode string" and instead recommend the use of "ASCII compatible (ACE) form of an IDNA valid string". She went on to clarify that "an IDNA valid string is a string that fulfills the requirements of the IDNA protocol" and noted that "the protocol document goes into further details of what this means". She suggested using the following term: "ASCII compatible (ACE) form of an IDNA protocol valid string". Finally, she stated that under the revised protocol, "Every ACE label will begin with the IDNA ACE prefix, 'xn--'."

4.      Summary of Relevant Information Sources

a.      ICANN Registry Agreement Requirements

All 16 existing gTLD registry agreements posted on ICANN's website as of 2 February 2007 (.aero, asia, .biz, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net, .org, .pro, .tel and .travel) contain the following requirement[34]

Except to the extent that ICANN otherwise expressly authorizes in writing, the Registry Operator shall reserve names formed with the following labels from initial (i.e. other than renewal) registration within the TLD:

C. Tagged Domain Names. All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n").

ICANN also has ccTLD Sponsorship Agreements and MOUs in place with 12 ccTLD managers.[35] Each of those agreements contains the following requirement on tagged names:

4. Tagged Domain Names. In addition, domain names in the Delegated ccTLD (excluding sub-domain names under domains registered to third parties) having labels with hyphens in the third and fourth character positions (e.g., "rq--1k2n4h4b") are reserved from initial (i.e. other than renewal) registration, except as authorized by ICANN policy or by written exception from ICANN.[36]

b.      RFC 3490 (found at http://www.faqs.org/rfcs/rfc3490.html ), Internationalizing Domain Names in Applications (IDNA)[37]

The Introduction of RFC 3490 says:

"IDNA works by allowing applications to use certain ASCII name labels (beginning with a special prefix) to represent non-ASCII name labels.

"To allow internationalized labels to be handled by existing applications, IDNA uses an "ACE label" (ACE stands for ASCII Compatible Encoding). An ACE label is an internationalized label that can be rendered in ASCII and is equivalent to an internationalized label that cannot be rendered in ASCII . . . Every ACE label begins with the ACE prefix specified in section 5."  
Section 5 (ACE Prefix) reads:
"The ACE prefix, used in the conversion operations (section 4), is two    alphanumeric ASCII characters followed by two hyphen-minuses. It cannot be any of the prefixes already used in earlier documents, which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--", "ra--", "wq--" and "zq--". . . . 
"The ACE prefix for IDNA is "xn--" or any capitalization thereof. This means that an ACE label might be "xn--de-jg4avhby1noc0d", where "de-jg4avhby1noc0d" is the part of the ACE label that is generated by the encoding steps in [PUNYCODE].
"While all ACE labels begin with the ACE prefix, not all labels beginning with the ACE prefix are necessarily ACE labels. Non-ACE labels that begin with the ACE prefix will confuse users and SHOULD NOT be allowed in DNS zones."  (Bold font added - this is the primary reason for reserving the ACE prefix.)


c.      RFC 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA), March 2003[38]

The Introduction of this RFC says the following:


"[IDNA] describes an architecture for supporting internationalized domain names. Labels containing non-ASCII characters can be represented by ACE labels, which begin with a special ACE prefix and contain only ASCII characters. The remainder of the label after the prefix is a Punycode encoding of a Unicode string satisfying certain constraints. For the details of the prefix and constraints, see [IDNA] and [NAMEPREP]."

d.      GNSO Preliminary Issues Report Policy Issues relating to IDN at the top-level, 28 May 2006[39]

An introduction of PUNYCODE is provided in this document:

"Punycode is a bootstring encoding that will convert the local characters in a domain name into the limited character set that is supported by the DNS. The encoding is applied to each component of a domain name and a prefix 'xn--' is added to the translated Punycode string. For example, the first component of the domain name rødgrødmedfløde.dk becomes 'xn--rdgrdmedflde-vjbdg', and the domain will be represented as xn--rdgrdmedflde-vjbdg.dk. This kind of encoding would apply for top-level labels with characters from non-Latin scripts."

e.      Informational RFC 4690, Review and Recommendations for Internationalized Domain Names (IDNs), September 2006[40]

The following excerpt relates to the possibility of the need to change the Punycode prefix:

"It is worth noting that sufficiently extreme changes to IDNA would require a new Punycode prefix, probably with long-term support for both the old prefix and the new one in both registration arrangements and applications. An alternative, which is almost certainly impractical, would be some sort of "flag day", i.e., a date on which the old rules are simultaneously abandoned by everyone and the new ones adopted. However, preliminary analysis indicates that few, if any, of the changes recommended for consideration elsewhere in this document would require this type of version change. For example, suppose additional restrictions, such as those implied above, are imposed on what can be registered. Those restrictions might require policy decisions about how labels are to be disposed of if they conformed to the earlier rules but not to the new ones. But they would not inherently require changes in the protocol or prefix."

f.        Internet Draft, Proposed Issues and Changes for IDNA - An Overview, October 16, 2006[41]

Section 5, The Question of Prefix Changes, says the following:
"The conditions that would require a change in the IDNA "prefix" ("xn--" for the version of IDNA specified in [RFC3490]) have been a great concern to the community. A prefix change would clearly be necessary if the algorithms were modified in a manner that would create serious ambiguities during subsequent transition in registrations. This section summarizes our conclusions about the conditions under which changes in prefix would be necessary.
"5.1. Conditions requiring a prefix change
"An IDN prefix change is needed if a given string would resolve or otherwise be interpreted differently depending on the version of the protocol or tables being used. Consequently, work to update IDNs would require a prefix change if, and only if, one of the following four conditions were met:
1. The conversion of a Punycode string to Unicode yields one string under IDNA2003 (RFC3490) and a different string under IDNA200x.
2.   An input string that is valid under IDNA2003 and also valid under IDNA200x yields two different Punycode strings with the different versions. This condition is believed to be essentially equivalent to the one above.
Note, however, that if the input string is valid under one version and not valid under the other, this condition does not apply. See the first item in Section 5.2, below.
3.   A fundamental change is made to the semantics of the string that is inserted in the DNS, e.g., if a decision were made to try to include language or specific script information in that string, rather than having it be just a string of characters.
4.      Sufficient characters are added to Unicode that the Punycode mechanism for offsets to blocks does not have enough capacity to reference the higher-numbered planes and blocks. This condition is unlikely even in the long term and certain to not arise in the next few years."

g.      Internet Draft, Proposed Issues and Changes for IDNA - An Overview (IDNAbis Issues), February 23, 2007[42]

(Note: This is version 01, an update to the previously listed Internet Draft of the same name, version 00.)

Section 8.1, Design Criteria, says the following regarding tagged names:
"3. Anyone entering a label into a DNS zone must properly validate that label -- i.e., be sure that the criteria for an A-label are met -- in order for Unicode version-independence to be possible. In particular:
·        Any label that contains hyphens as its third and fourth characters MUST be IDNA-valid. This implies in particular that, (i) if the third and fourth characters are hyphens, the first and second ones MUST be "xn" until and unless this specification is updated to permit other prefixes and (ii) labels starting in "xn--" MUST be valid A-labels, as discussed in Section 3 above."
Section 8.3, The Question of Prefix Changes, says:
"The conditions that would require a change in the IDNA "prefix" ("xn--" for the version of IDNA specified in [RFC3490]) have been a great concern to the community. A prefix change would clearly be necessary if the algorithms were modified in a manner that would create serious ambiguities during subsequent transition in registrations. This section summarizes our conclusions about the conditions under which changes in prefix would be necessary.
"8.3.1. Conditions requiring a prefix change
"An IDN prefix change is needed if a given string would resolve or otherwise be interpreted differently depending on the version of the protocol or tables being used. Consequently, work to update IDNs would require a prefix change if, and only if, one of the following four conditions were met:
1. The conversion of a Punycode string to Unicode yields one string under IDNA2003 (RFC3490) and a different string under IDNA200x.
2. An input string that is valid under IDNA2003 and also valid under IDNA200x yields two different Punycode strings with the different versions of IDNA. This condition is believed to be essentially equivalent to the one above.
Note, however, that if the input string is valid under one version and not valid under the other, this condition does not apply. See the first item in Section 8.3.2, below.
3. A fundamental change is made to the semantics of the string that is inserted in the DNS, e.g., if a decision were made to try to include language or specific script information in that string, rather than having it be just a string of characters.
4. A sufficiently large number of characters is added to Unicode so that the Punycode mechanism for block offsets no longer has enough capacity to reference the higher-numbered planes and blocks. This condition is unlikely even in the long term and certain not to arise in the next few years."
"Section 8.3.2, Conditions not requiring a prefix change, says:
"In particular, as a result of the principles described above, none of the following changes require a new prefix:
1. Prohibition of some characters as input to IDNA. This may make names that are now registered inaccessible, but does not require a prefix change.
2. Adjustments in Stringprep tables or IDNA actions, including normalization definitions that do not affect characters that have already been invalid under IDNA2003.
3. Changes in the style of definitions of Stringprep or Nameprep that do not alter the actions performed by them."


ANNEX FOUR -- NIC/WHOIS/WWW SUB GROUP REPORT

GNSO new TLDs Committee

Reserved Names Working Group

Sub-Group Report - NIC, Whois, www


DEFINITION

NIC, Whois & www

Names reserved for registry operations at the second-level

EXECUTIVE SUMMARY

1.      This Report contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding Names Reserved for Registry Operations, NIC, Whois and www.

2.      Tim Denton served as a one-person subgroup for this category with support from Chuck Gomes and ICANN staff in the preparation of the final subgroup report.

3.      The recommendations of this report were approved by the full RN-WG.

4.      There was no disagreement with the recommendations and hence no minority positions.

5.      The table below contains the recommendations for Names Reserved for Registry Operations, NIC, Whois and www.

SoW number

(RN-WG 30-day extension SoW)

Reserved Name Category

Domain Name Level(s)

Recommendation

Recommendation task 5

NIC, Whois, www

Top level, ASCII

The following names must be reserved: NIC, Whois, www.

Recommendation task 5

NIC, Whois, www

Top level, IDN

Do not try to translate NIC, Whois and www into Unicode versions for various scripts or to reserve any ACE versions of such translations or transliterations if they exist.

Recommendation task 5

NIC, Whois, www

2nd level, ASCII

The following names must be reserved for use in connection with the operation of the registry for the Registry TLD: NIC, Whois, www. Registry Operator may use them, but upon conclusion of Registry Operator's designation as operator of the registry for the Registry TLD, they shall be transferred as specified by ICANN.

Recommendation task 5

NIC, Whois, www

2nd level, IDN

Do not try to translate NIC, Whois and www into Unicode versions for various scripts or to reserve any ACE versions of such translations or transliterations if they exist, except on a case by case basis as proposed by given registries.

Recommendation task 5

NIC, Whois, www

3rd level,

ASCII

For gTLDs with registrations as the third level, the following names must be reserved for use in connection with the operation of the registry for the Registry TLD: NIC, Whois, www. Registry Operator may use them, but upon conclusion of Registry Operator's designation as operator of the registry for the Registry TLD, they shall be transferred as specified by ICANN.

Recommendation task 5

NIC, Whois, www

3rd level, IDN

For gTLDs with registrations at the third level, do not try to translate NIC, Whois and www into Unicode versions for various scripts or to reserve any ACE versions of such translations or transliterations if they exist, except on a case by case basis as proposed by given registries.


Supporting Information

1.      Background

In all gTLD registry agreements as of 25 April 2007, the following three names are reserved for use in connection with the operation of the registry for the Registry TLD.

NIC

Whois

www

All 16 of the current gTLD registry agreements prohibit these from being used by any other gTLD registry at the second-level: .aero, asia, .biz, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net, .org, .pro, .tel and .travel.

Fourteen (14) out of 16 agreements have a successor rights clause that specifies that the Registry Operator may use them, but upon conclusion of the Registry Operator's designation as operator of the registry for the Registry TLD, they shall be transferred as specified by ICANN. These include the following 14 agreements: .aero, asia, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net, .pro, .tel and .travel. The successor rights clause does not appear in the cases of: .biz, .org.

Names

Registries affected

Successor Rights clause not found in

Who may use the names

NIC

Whois

www

.aero, asia, .biz, .cat, .com, .coop, .info, .jobs, .mobi, .museum, .name, .net, .org, .pro, .tel and .travel

.biz, .org

Only the registries in question, no one else

In the course of the work, the question arose whether to reserve html, http and https. That issue is dealt with in the report on ICANN and IANA reserved names. Because the names which this report addresses (NIC, Whois, www) are for registry operational uses and because there does not seem to be any identified registry operational need for html, http and https, it is not recommended that html, http and https be added to this category.

2.      Rationale for the recommendations

The rationale for the reservation of these ASCII names below the top level for use by registry operators is based upon long standing and well established use of these strings by registry operators (both gTLDs and ccTLDs) in connection with normal registry operations.

At the top level, use of NIC, Whois or www could possibly cause user confusion with regard to uses of the same names below the top-level by certain registry operators. In the case of Whois at the top level, if there ever was a centralized or universal Whois service, the use of a 'Whois' top level domain would seem to be a natural TLD for that use. In the case of www at the top level, there could possibly be confusion at the application level with regard to URLs that often include www.

Regarding the IDN implications of these three names, there are two primary reasons why no general reservation requirement is recommended: 1) these names are "integral designators" in Internet usage and as such were never intended to be used with translation; 2) in many scripts, it is difficult or impossible to translate or transliterate acronyms or unique strings. In cases where it is possible to find translated or transliterated versions of NIC, Whois or www, the applicable registry operators could reserve such IDN names on a case-by-case basis.

3.      Consultation with experts

Three kinds of questions arose in connection with these names: 1) Why is there a difference in the reservation of names for .biz and .org (successor rights clause)? 2) Based on general principle, should these names be reserved? 3) Should IDN versions of the names be reserved? Each of these questions is discussed in the subsections below.

3.1 Successor rights clause

The successor rights clause does not appear in the registry agreements of .biz and .org. Upon inquiry of Jeff Neuman, Senior Director, Law and Advanced Systems, of NeuStar, operator of .biz, he replied:

"To tell you the truth, we did not focus on this exhibit at all during the renegotiation and did not realize that this was any different than the other operators. Any deviation from the original 2001 agreement we signed was inadvertent and missed by both us and ICANN during the renegotiations."

David Maher, Senior Vice President, Law and Policy, of the Public Interest Registry, wrote as follows:

"The answer appears to be that these second level names are in use. They were registered before there was a policy limiting their use. If the registrations were ever terminated, then they would become reserved."

3.2 Reservations of these names in principle

The official contact people within top-level and country code registries were consulted via email and in one case by telephone. Responses were received from representatives of .aero, .org, .name, .travel, .biz, .museum and .jobs.

David Maher of .org responded: "Yes, the names should be kept reserved."

Marie Zitkova of .aero responded as follows:

1) As a registry, do you wish to keep those names reserved?

"Yes, these names are traditionally used by TLDs to designate specific functions key to the operation of registry and it makes sense for ICANN to maintain a certain standard across the board."

2) If they were not reserved, what actions would you take to protect your interests in those names?

"I am not sure I understand the question. First, these names were reserved from day 1 so no such question ever came up and it cannot come up anymore because the names are in use.

"Second, I certainly do not understand what is implied by 'our interest' in those names. We are not talking about trade names or trademarks. Surely, the reservation above was mandated not because of an interest of any individual sponsor or registry operator but because it makes sense for the entire system of TLDs to have some minimum level of predictability to locate elementary functions associated with the operation of the TLD.

"Third, and that is answering the very hypothetical question what would happen before the launch of our TLD if these three names were not reserved by ICANN. We are a Sponsor of a sponsored TLD, availability of names and eligibility criteria for the registration would be determined by the policies set by the Sponsor in consultation with the sponsored community and in the best interests of the aviation community, same process as we follow in all other cases, and the Registry Operator would implement those policies upon the request from the Sponsor."

Hakon Haugnes of .name responded:

"1) Yes, they are in use and are expected to exist by the community.

2) They are in use by the Registry so I guess that would be protection enough. It would be silly to have to defend them under UDRP, for example. We believe, though, that they belong to the Registry and not to the Company, of course.

 

"I must admit I am not fully aware of the work of the WG, but what would be the purpose of not making them reserved?"

 

Cherian Mathai of .travel was reached by telephone. When asked whether he wanted those three names reserved, he responded "yes".

 Eric Brown of .biz responded as follows:

"1. We believe that NIC and WHOIS should remain reserved.  They are used to denote functionality to the .BIZ registry.  For example, if one types in WHOIS.BIZ, they will be taken to our official WHOIS website for .BIZ domain names.  In addition, with respect to NIC.BIZ, this is essential to keep reserved as well.  This is because there are a number of people that do not know who a particular registry operator is and therefore have no way to get to the official registry site.  NIC.TLD is important because it is a predictable place that one could (and should) always go when they know the TLD, but not the operator.

"2. It is not that we believe we have some sort of intellectual property rights in the names so there are no actions we would take to protect it from an IP perspective.  However, to not reserve these names (at least NIC and WHOIS), would cause confusion among consumers looking for the official WHOIS database of the TLD or looking for the official website of the registry (when they do not know the name)."

Cary Karp of .museum responded as follows:

1) As a registry, do you wish to keep those names reserved?

" . . . in my conceptual frame of reference, reservation places constraints on the circumstances under which a name may be registered. By definition, the reservation is terminated (or suspended, if you'd prefer) when that registration takes place. If such name should subsequently ever be removed from the DNS it could be placed back on the reserved list. In the hope that it properly answers your question, that is what I would intend to happen with the labels NIC, Whois, and www if they are ever removed from the .museum zone."

2) If they were not reserved, what actions would you take to protect your interests in those names?

"If they had not been reserved we would have protected our interests in them by registering them in precisely the manner that we have."


Ray Fassett of .jobs responded as follows:


 1) As a registry, do you wish to keep those names reserved?

"Before I can answer this question, I must qualify how I define a reserved name: A name that is prohibited to be allocated by the TLD operator to a third party of the contract.

"I believe it is appropriate for the names www, NIC, and Whois to be prohibited from allocation by the TLD operator to a third party of the contract."


2) If they were not reserved, what actions would you take to protect your interests in those names?

"I believe an interest - or expectation - from the user community has evolved for these 3 names more so than an 'interest' to us as the TLD operator in need of 'protecting'.  Given the hypothetical nature of this question, the best I can answer would be an action felt to be in the best interests of the HR Community, consistent to the mission of .jobs."

It is likely that these names could be removed from the reserved list by negotiation between each registry and ICANN, if they thought this was to their respective advantages. Second, the fact that these names were not in contention suggests that the reservation of these names is not controversial.

To generalize from a few respondents, it appears that country codes are rather freer to follow less consistent policies. Michael Haberler of .at wrote:

"What we did in the past is register 'interesting' (which might be contentious if held by the wrong party) names like www.at, internet.at etc. on trustworthy registrants, like ourselves, or the ISP association. We do register others for our own purposes or likely fields of activity. But conceptually that's just a registration, not a reservation. We had the issue come up with registrars bitching about it and I just told them that we reserve the right to acquire names for our own purposes, and that's it, period."

Sabine Dolderer (representing .de at the time) responded as follows:

1) Does .de have reserved names?

"We have only some minor restrictions for domains which could not be registered but that are no real reservations. They are:

·        No domain name with less than 3 characters is allowed

·        No domain name which is equal to an existing TLD is allowed (actually only com/net/org/edu/int) because of problems related to RFC1535

·        No domains which are equal to local community car plate numbers are allowed. This is done because when the rule was created it was unclear if one would need a future structuring mechanism."

2) Does it reserve /NIC, www/, and or /Whois/?

"No."

3) Does it give a reason for these reservations, if it has them?

"The reason for reserving 2-character and existing TLDs is because of problems with TLD.TLD as described in RFC 1535. Car plate numbers were reserved because of the potential structuring issue. The reasons are no longer really valid but most have 1- or 2-character abbreviations."

Canada's Bernard Turcotte wrote back in relation to .ca that these names are not reserved in the case of CIRA, but that, on reflection, he thought they ought to have been reserved.

A more systematic process of consultation with country code operators might enlighten us about their practices but would not be directly pertinent to whether the three names should be reserved at the generic TLD level.

3.3 Consultations with IDN experts

Regarding the IDN implications of these three names, both Cary Karp and Ram Mohan were consulted in a teleconference call held on March 1, 2007. The advice received was that these names were "integral designators" to be used "without translation". In other words, there was no need to reserve these strings in other languages. Ram Mohan suggested "Find the equivalent and reserve them at that time" and added "Don't try to translate them", referring to the acronyms and/or abbreviations."

4.      Summary of Relevant Information Sources

The primary source of information for this category of reserved names is the set of ICANN-registry agreements, found at http://www.icann.org/registries/agreements.htm In particular refer to the Schedule of Reserved Names appendix for each agreement (Appendix 6 in most cases).

There do not appear to be any documented rationales or explanations.


ANNEX FIVE -- GEOGRAPHICAL AND GEOPOLITICAL NAMES SUB GROUP REPORT

GNSO new TLDs Committee

Reserved Names Working Group

Sub-Group Report

Geographic and Geopolitical Names

10 May 2007


DEFINITIONS

Geographical Names

Geographical names refer to those names in the ISO 3166-1 list (e.g., Portugal, India, Brazil, China, Canada) & names of territories, distinct geographic locations (or economies), and other geographic names as ICANN may direct from time to time.

Geopolitical Names

The reserved name category titled 'Geographic and Geopolitical Names' is contained in a subset of existing ICANN registry agreements. Geopolitical names is a term that has not been widely used within the broader geographical identifier discussion. In fact, the term is only used once in a parenthetical in the entire WIPO II Process final report. See http://www.wipo.int/amc/en/processes/process2/report/html/report.html Paragraph 55.

EXECUTIVE SUMMARY

1.      This Report contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding Geographical and Geopolitical Names

2.      The Reserved Names Working Group on Geographical and Geopolitical Names was composed of Alistair Dixon, Caroline Greer, Michael Palage, and Tim Ruiz.

3.      The Working Group on Geographical and Geopolitical Names reached unanimous agreement on the recommendations in this report.

4.      There was no disagreement with the recommendations and hence no minority positions.

5.      The table below contains the consensus recommendations for Geographic and Geopolitical Reserved Names.

SoW number

(RN-WG 30-day extension SoW)

Reserved Name Category

Domain Name Level(s)

Recommendation

Recommendation task 6

Geographical

Top Level (ASCII and IDN)

There should be no geographical reserved names (i.e., no exclusionary list, no presumptive right of registration, no separate administrative procedure, etc.). The proposed challenge mechanisms currently being proposed in the draft new gTLD process would allow national or local governments to initiate a challenge, therefore no additional protection mechanisms are needed. Potential applicants for a new TLD need to represent that the use of the proposed string is not in violation of the national laws in which the applicant is incorporated.

However, new TLD applicants interested in applying for a TLD that incorporates a country, territory, or place name should be advised of the GAC principles, and the advisory role vested to it under the ICANN bylaws. Additionally, a summary overview of the obstacles encountered by previous applicants involving similar TLDs should be provided to allow an applicant to make an informed decision. Potential applicants should also be advised that the failure of the GAC, or an individual GAC member, to file a challenge during the TLD application process, does not constitute a waiver of the authority vested to the GAC under the ICANN bylaws.

Recommendation task 6

Geopolitical

All Levels (ASCII and IDN)

The term 'geopolitical names' should be avoided until such time that a useful definition can be adopted. The basis for this recommendation is founded on the potential ambiguity regarding the definition of the term, and the lack of any specific definition of it in the WIPO Second Report on Domain Names or GAC recommendations.

Recommendation task 6

Geographical

Second Level & Third Level if applicable

The consensus view of the working group is given the lack of any established international law on the subject, conflicting legal opinions, and conflicting recommendations emerging from various governmental fora, the current geographical reservation provision contained in the sTLD contracts during the 2004 Round should be removed, and harmonized with the more recently executed .COM, .NET, .ORG, .BIZ and .INFO registry contracts. The only exception to this consensus recommendation is those registries incorporated/organized under countries that require additional protection for geographical identifiers. In this instance, the registry would have to incorporate appropriate mechanisms to comply with their national/local laws.

For those registries incorporated/organized under the laws of those countries that have expressly supported the guidelines of the WIPO Standing Committee on the Law of Trademarks, Industrial Designs and Geographical Indications as adopted by the WIPO General Assembly, it is strongly recommended (but not mandated) that these registries take appropriate action to promptly implement protections that are in line with these WIPO guidelines and are in accordance with the relevant national laws of the applicable Member State.


Supporting Information

1.      Background

Geographic and geopolitical domain name reservations are a relatively new class of reservations that were first incorporated into the ICANN registry contracts in connection with the 2004 sTLD round. However, the genesis for this type of reservation can be specifically tracked back to ICANN Board resolution 01-92[43] involving issues surrounding the rollout of the .INFO gTLD. This topic has also received significant attention in other International fora, most notably the World Intellectual Property Organization's Second WIPO Internet Domain Name Process (hereinafter WIPO II Process).[44] As the WIPO II Process accurately notes, "[t]his is a difficult area on which views are not only divided, but also ardently held."[45]

It is important to note at the outset that "geopolitical" domain name reservations is a term that has not been widely used within the broader geographical identifier discussion. In fact, the term is only used once in a parenthetical in the entire WIPO II Process final report.[46] Given the lack of any legal construct involving the term geopolitical domain names, it is most prudent to use the terminology contained in the WIPO II Process final report as a framework for discussion. Specifically, geographical identifiers should serve as an umbrella term that includes not only country names, but names of places within countries[47], geographical indications[48], and names of indigenous peoples[49].

The first action by ICANN to affirmatively seek protection for this class of names was in connection with ICANN Board Resolution 01-92. This action was taken by the ICANN Board in response to the 9 September 2001 Government Advisory Committee (GAC) communiqué[50] sent by Dr. Paul Twomey acting in his capacity as GAC Chair which states in relevant part:

A.                 The GAC confirmed that this is an issue of considerable political importance and complexity that merits thorough study by qualified and competent experts. The issue also relates to the overall taxonomy of the DNS and its evolution concerning the expansion of the TLD space.

B.               

C.                The GAC notes that the issue of geographical and geopolitical names is very complex and the subject of ongoing international discussion. Without prejudice to any future discussions, general policy or international rules in this area, and considering the very special nature of .info, and problems that have become apparent with the registration of such names in the sunrise period, the GAC agreed that interim ad hoc measures should be taken by ICANN and the Registries to prevent avoidable conflicts in .info. The GAC agreed that the use of names of countries and distinct economies as recognized in international fora as second level domains in the .info TLD should be at the discretion of the respective governments and public authorities.

It is important to note that GAC communiqué was limited to just the .INFO top-level domain (TLD) citing "the very special nature" of that TLD. Also noteworthy is the fact that none of the other six proof of concept TLDs had formerly launched.[51]

Notwithstanding the narrow construct of the GAC communiqué and the corresponding board action, the new registry contract language resulting from the 2004 sTLD round included several provisions dealing with geographic and geopolitical names which are summarized below.

E. Geographic and Geopolitical Names. All geographic and geopolitical names contained in the ISO 3166-1 list from time to time shall initially be reserved at both the second level and at all other levels within the TLD at which the Registry Operator provides for registrations. All names shall be reserved both in English and in all related official languages as may be directed by ICANN or the GAC.

NOTE: This is the exact provision contained with the .ASIA registry contract. The other 2004 sTLD registry contracts (.CAT, .JOBS, .MOBI, .TEL and .TRAVEL include the same language with the exception of "as may directed by ICANN or the GAC" which has been excluded in these contracts. There is no such corresponding provision in the .AERO, .BIZ, .COM, .COOP, .INFO, .MUSEUM, .NAME, .NET, .ORG or .PRO registry contracts.

In addition, Registry Operator shall reserve names of territories, distinct geographic locations, and other geographic and geopolitical names as ICANN may direct from time to time. Such names shall be reserved from registration during any sunrise period, and shall be registered in ICANN's name prior to start-up and open registration in the TLD. Registry Operator shall post and maintain an updated listing of all such names on its website, which list shall be subject to change at ICANN's direction. Upon determination by ICANN of appropriate standards and qualifications for registration following input from interested parties in the Internet community, such names may be approved for registration to the appropriate authoritative body.

NOTE: This is the exact provision contained with the .ASIA registry contract. The other 2004 sTLD registry contracts (.CAT, .JOBS, .MOBI, .TEL and .TRAVEL include the same language but "geographic locations" is replaced by "economies". There is no such corresponding provision in the .AERO, .BIZ, .COM, .COOP, .INFO, .MUSEUM, .NAME, .NET, .ORG or .PRO registry contracts

2.      Rationale for the recommendations

As noted above in the WIPO II report, "[t]his is a difficult area in which views are not only divided, but also ardently held."[52] Therefore, this subgroup undertook a very cautious approach to ensure that "there is a solid and clear basis in existing international law which can be applied so as to prevent erosion of the integrity of geographical indicators and enhance the creditability of the DNS."[53]

The work of this subgroup began with a review of this subgroup's previous work and the final GAC Principles Regarding New gTLDs, specifically Paragraph 2.7 that states in relevant part:

Applicant registries for new gTLDs should pledge to:

A) Adopt, before the new gTLD is introduced, appropriate procedures for blocking, at no cost and upon demand of governments, public authorities or IGOs, names with national or geographic significance at the second level of any new TLDs.

B) Ensure procedures to allow governments, public authorities or IGOs to challenge abuses of names with national or geographic significance at the second level of any new gTLD.

In reviewing this GAC principle, the subgroup was concerned about the apparent "rights in gross" that the principle seems to imply in connection with geographic identifiers. This concern was based on several factors. First, the GAC provided no legal basis for their claim. Second, per se rights in gross regarding geographical identifiers were specifically considered in the WIPO II report, but not adopted.[54] Third, the GAC principle on its face appears to be inconsistent with the recommendations of the WIPO General Assembly that conducted a multi-year and detailed international consultation on this exact topic. Finally, some of the legal decisions involving geographical identifiers and domain names appear to support the statements in the WIPO II report that concluded that "we have reached the limits of what can be achieved legitimately through consultation processes, such as the WIPO Internet Domain Name Processes or any similar ICANN processes." (emphasis added).[55]

Lack of International Legal Authority Cited in the GAC Principles:

In response to the lack of authority cited in the GAC Principles, the subgroup submitted through ICANN staff a list of questions (see Section 3 below) seeking to understand the international legal authority upon which the GAC Principles were based. While we recognize that the short turn around would likely limit any in-depth response to our inquiries, upon the finalization of this report, no responses had been received.

In the absence of any response from the GAC, the subgroup revisited the comprehensive work of the WIPO on this subject matter, with particular attention focused on the legal treaties that member states have entered into. There are four treaties that provide "a well established framework for the prohibition of the misuse of geographical identifiers at the international, regional and national levels."[56] These treaties are the Paris Convention for the Protection of Industrial Property (Paris Convention), to which 162 States are party; the Madrid Agreement for the Repression of False or Deceptive Indications of Source on Goods (the Madrid (indications of Source) Agreement), to which 33 States are party; the Lisbon Agreement for the Protection of Appellations of Origin (the Lisbon Agreement), to which 20 States are party; and the Agreement on Trade-Related Aspects of Intellectual Property Rights (the TRIPS Agreement), which has 142 Contracting Parties.[57]

This international framework of protection for geographical identifiers consists of two elements: (i) a prohibition of the false descriptions of the geographic source of goods; and (ii) a more extensive set of rules prohibiting the misuse of one class of geographic source indicators, known as geographic indicators."[58]

The first element that prohibits the use of false indications of geographical source on goods is established in three treaties: the Paris Convention; the Madrid Agreement, and the TRIPS Agreement.[59] However, the scope of this protection is primarily limited to goods, and does not extent to services. The WIPO II Report expands upon other potential considerations limiting the extension of these treaties to cover the false use of geographical identifiers in the DNS.[60]

With regard to the second element relating to a more extensive set of rules prohibiting the misuse of geographical indications, one needs to refer to Article 22.1 of the TRIPS Agreement that prohibits:

    (a) The use of any means in the designation or presentation of a good that indicates or suggests that the good in question originates in a geographical area other than the true place of origin in a manner which misleads the public as to the geographical origin of the good;

    (b) Any use which constitutes an act of unfair competition within the meaning of Article 10bis of the Paris Convention (1967).

"The essential difference between the rules relating to geographical indications and those relating to false indications of geographical source is that the former place emphasis on a certain quality attached to a limited class of geographical terms, rather than establishing a rule of market behaviors which may be violated through the false use of any geographical term."[61]

In reviewing the WIPO II report and these treaties, the subgroup could find no legal basis for the recommendations included in the GAC Principles regarding New TLDs.

The Non-Existence of Per Se Rights in Gross with regard to Geographical Indicators:

The proposed GAC Principles call for the new gTLDs to provide for "blocking, at no cost and upon demand of governments, public authorities or IGOs, names with national or geographic significance at the second level of any new TLDs." This could be interpreted to imply a unilateral claim by governments for rights in gross to an undefined universe of names that they themselves are entitled to establish. Such a claim would be unusual and extraordinary because the WIPO II report specifically analyzed the preference and protection for geographical terms per se, and elected not to recognize such claims. Providing any party rights in gross in connection with a specific designation would be inconsistent with fundamental tenets of international trademark law.[62]

GAC Principles Appear on their Face to be Inconsistent with the WIPO General Assembly Recommendations:

While respecting the authority of the GAC under the ICANN bylaws to provide advice, the subgroup struggled to reconcile the GAC advice with the output of the WIPO multi-lateral consultative processes. Specifically, the GAC provided no underlying legal analysis to support their expansive claim of rights in gross to a yet undefined list of names of national or geographic significance. This was in contrast to the WIPO processes that described in great detail the underlying legal analysis surrounding the issue, and included an extensive record of written submissions of numerous Member States. It is also important to note that the final recommendations of the WIPO General Assembly called for an administrative process to balance a series of factors prior to making a determination if such use was inappropriate, not a per se claim for rights in gross as claimed in the GAC principles.

Balancing these factors, the subgroup elected to recommend the use of the WIPO General Assembly guidelines, for those registries incorporated under the laws of those Member States that voted in favour of these guidelines.

Conflicting Legal Decisions:

The lack of a uniform body of international law on this subject can be easily ascertained by a brief review of a number of legal decisions from various national courts that have dealt with this issue. For example, in litigation involving the domain name solingen.info, a German Federal High Court ruled in favour of the city of Solingen. However, in its ruling the court noted the unique nature of .info and distinguished it from other TLDs such as .com, .biz and .pro. This is an important distinction that was also noted in the original GAC 2001 Communiqué that provided the initial foundation for the discussion.

This ruling is in contrast to a recent decision involving French city of Lavallois Perret that filed suit against 1&1 Internet over the domain name lavallois.tv. In this case the Tribunal de grande instance de Nanterre Ordonnance de référé 30 janvier 2007 Commune de Levallois Perret / Loïc L., 1 & 1 Internet, ruled against the city of Lavallois Perret and they were ordered to pay 1,000 euros and the costs of the action to 1&1.

In response to these types of legal proceedings, domain name registrants have begun to proactively seek redress through the court system. For example, in response to claims by the city of Paris, the domain name owners of paris.com and paris.tv are now suing the city of Paris in the U.S. Federal Court in New York and Virginia respectively.

Another reason for ICANN to carefully consider imposing via contract any consensus policies not based on sound legal principles, is because of the potential litigation risk that it might be exposing registration authorities to, as was the case in the 1&1 litigation. This concern is even more valid as ICANN has been systematically removing from registry contracts the provision that provided registries indemnification from ICANN in connection with consensus policies that they implement.

Conclusion

Protection afforded to Geographic indicators is an evolving area of international law in which a one-size fits all approach is not currently viable. The proposed recommendations of this subgroup are designed to ensure that registry operators comply with the national laws under which they are legally incorporated/organized.

3.      Expert Consultation

Listed below are the questions that the group asked ICANN staff to submit to WIPO, the GAC and the ccNSO in connection with its work. If and when responses to the questions are received, it is recommended that the New gTLD Committee or the GNSO Council review and consider them in their deliberations.

As of 10 may 2007, no responses were received.

Question #1 to WIPO:

In Francis Gurry's correspondence to ICANN dated 21 February 2003, in Annex 2 Paragraph 7 (iv) states in relevant part that "the protection should be extended to all future registrations of domain names in generic top-level domains (gTLDs)" citing the Summary by the Chair of the SCT dated 15 November 2002. This appears to be a narrowing of the scope of protection originally sought during the second Special Session of the SCT in May 2002, where the chair concluded that "the protection should be extended to all top-level domains, both gTLD and ccTLDs." However, in document WO/GA/30/2, prepared for the WIPO Generally Assembly and dated 7 August 2003, Paragraph 14 cites the original May 2002 report affording protection of country names in both gTLDs and ccTLDs.

Are WIPO Member States seeking protection for country names in just gTLDs as noted in Summary of the Chair dated 15 November 2002, or protection for country names in both gTLDs and ccTLDs as noted in the May 2002 and August 2003 documentation?

Question #2 to WIPO

If WIPO Member States are only seeking protection for country names in gTLDs, can WIPO point to any interventions or documentation following the May 2002 report that lead to the narrowing of this protection to just gTLDs?

Question #3 to GAC:

Paragraph 2.7 of the GAC Principles regarding New TLDs states:

Applicant registries for new gTLDs should pledge to:

A) Adopt, before the new gTLD is introduced, appropriate procedures for blocking, at no cost and upon demand of governments, public authorities or IGOs, names with national or geographic significance at the second level of any new TLDs.

B) Ensure procedures to allow governments, public authorities or IGOs to challenge abuses of names with national or geographic significance at the second level of any new gTLD.

The scope of this protection on its face appears to represent an expanse of the protection documented through the WIPO Member States in the Standing Committee on the Law of Trademarks, Industrial Designs and Geographical Indications which calls for the following protection:

(i) Protection should be extended to the long and short names of countries, as provided by the United Nations Terminology Bulletin;

(ii) the protection should be operative against the registration or use of a domain name which is identical or misleadingly similar to a country name, where the domain name holder has no right or legitimate interest in the name and the domain name is of a nature that is likely to mislead users into believing that there is an association between the domain name holder and the constitutional authorities of the country in question;

(iii) Each country name should be protected in the official language(s) of the country concerned and in the six official languages of the United Nations; and

(iv) The protection should be extended to all future registrations of domain names in generic top-level domains (gTLDs).

Can the GAC provide any basis for the broadened scope of protection they are seeking under Paragraph 2.7 of the GAC Principles regarding New TLDs that call for an absolute right of blocking a country's name while apparently abandoning the SCT recommendations that call for legal determination based on a number of factors.

Question #4 to the GAC:

Can the GAC please attempt to reconcile these two different standards. Specifically, the GAC Principles regarding New gTLDs provide the government with "rights in gross" where as the WIPO General Assembly provides a balancing test including several factors for resolving potential challenges.

Question #5 to the GAC:

Coupled with the fact that this specific principle suggests just a "pledge" (not a mandated requirement) on behalf of new gTLD applicants, would the GAC be in support of mandating that registry operators comply with the national laws under which they are incorporated, similar to that of a ccTLD operator?

Question #6 to the GAC and the ccNSO:

Paragraph 261 of the WIPO II Report cites eight ccTLD administrators that have adopted policies for "excluding the names of places in their countries from registration as domain names, at least under certain conditions." Is the GAC or ccNSO aware of a ccTLD administrator that has provided protection for geographic indicators from another county, if so which ones?

Question #7 to the GAC and the ccNSO:

Is the GAC or ccNSO aware of any ccTLD administrator that has provided the protection sought by the GAC in Paragraph 2.7 of the GAC Principles regarding New gTLDs and if so which ones?

4.      Summary of Relevant Information Sources

GAC Principles regarding New gTLDs:

http://gac.icann.org/web/home/gTLD_principles.pdf

Second WIPO Internet Domain Name Process

http://www.wipo.int/amc/en/processes/process2/report/html/report.html

WIPO General Assembly, Twenty-Eighth (13th Extraordinary) Session; Geneva, September 23 to October 1, 2002

http://www.wipo.int/documents/en/document/govbody/wo_gb_ga/index_28.htm

http://www.wipo.int/edocs/mdocs/sct/en/sct_9/sct_9_8.pdf

WIPO Presentation to the GAC on GIs and WIPOII

http://gac.icann.org/web/meetings/mtg15/RioPresentations/WIPOSecondProcess/WIPOSecondProcess.ppt

Letter from WIPO to ICANN

http://www.icann.org/correspondence/gurry-letter-to-cerf-lynn-21feb03.htm

GAC Communiqués:

http://gac.icann.org/web/communiques/gac10com.htm

ICANN Board Resolution:

http://www.icann.org/minutes/minutes-10sep01.htm

ICANN Country Name Action Plan wrt Afilias (.INFO)

http://www.icann.org/montevideo/action-plan-country-names-09oct01.htm

DNSO Resolution on Geographical Identifiers

http://www.dnso.org/clubpublic/council/Arc06/msg00202.html

GAC Commentary to DNSO Resolution:

http://www.icann.org/committees/gac/names-council-resolution-commentary-26oct01.htm

.COOP Community Names Program involving country names

http://www.icann.org/tlds/agreements/coop/

http://www.nic.coop/information.asp

www.coop/downloads/registrars/RegistrarBackgroundInfo.doc

http://www.australia.coop

.INFO Country Name Plan of action

http://www.icann.org/montevideo/action-plan-country-names-09oct01.htm


ANNEX SIX -- Sub-Group Report - gTLD Strings

GNSO new TLDs Committee

Reserved Names Working Group

Sub-Group Report - gTLD Strings

10 May 2007


DEFINITION

gTLD Strings

gTLD strings refer to gTLDs (i.e. .com, .net .org, .mobi) that are reserved from registration at the second level and third level where applicable as a contractual condition (e.g., net.travel, org.jobs, mobi.asia). Reservation is based upon the list contained at http://data.iana.org/TLD/tlds-alpha-by-domain.txt

EXECUTIVE SUMMARY

1.      This Report contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding gTLD reserved names at the second and third level.

2.      Ray Fassett, Edmon Chung, and Patrick Jones served as the subgroup for this report.

3.      The recommendations of this report were approved by all three of the subgroup members.

4.      There were no minority statements from the subgroup members. Minority opinions from individuals from various GNSO constituencies who were not part of the RN-WG are included in Section 3 of this report (Consultation with Experts).

5.      The table below contains the recommendation for gTLD reserved names.

SoW number

(RN-WG 30-day extension SoW)

Reserved Name Category

Domain Name Level(s)

Recommendation

Recommendation task 8

gTLD Reserved Names

Second &

Third Level,

IDN (when applicable)

Absent justification for user confusion[63], the recommendation is that gTLD strings should no longer be reserved from registration for new gTLDs at the second or when applicable at the third level. Applicants for new gTLDs should take into consideration possible abusive or confusing uses of existing gTLD strings at the second level of their corresponding gTLD, based on the nature of their gTLD, when developing the startup process for their gTLD.


Supporting Information

1.      Background

Language INCLUDED within the main body Registry Agreements for .asia, .biz, .cat, .com, .info, .jobs, .mobi, .net, .org, .travel and .tel (the later modified slightly) states that:

''Registry Operator shall reserve, and not register any TLD strings  appearing on the list of reserved TLD strings attached as Appendix 6 hereto or located at http://data.iana.org/TLD/tlds-alpha-by-domain.txt for initial (i.e., other than renewal) registration at the second level within the TLD." 

That particular language is NOT INCLUDED in older TLD Agreements: .aero (2001), .coop (2001), .museum (2001), .name (2001) and .pro (2002) - those TLDs reserve the following names either as per Appendix 11 or Appendix K of their contracts in addition to two letter labels:

·         aero

·         arpa

·         biz

·         com

·         coop

·         edu

·         gov

·         info

·         int

·         mil

·         museum

·         name

·         net

·         org

·         pro

2.      Rationale for the recommendations

Guiding Principle 1: TLD1.TLD2 (e.g., com.travel) has recently been identified as not being a risk to the security and stability of the DNS by an expert technical panel (http://www.icann.org/registries/rsep/RSTEP-GNR-proposal-review-team-report.pdf)

Guiding Principle 2: Evidence has not been presented to justify that user confusion would exist as a result of TLD1.TLD2 with the addition of new gTLDs.

Guiding Principle 3: There is market evidence to indicate that TLD1.TLD2 has not resulted in user confusion.

Consultation with ICANN staff identified that this measure was originally put in place by ICANN in order to avoid consumer confusion in relation to 'double' TLD addresses (i.e., TLD1.TLD2 such as com.travel and travel.jobs). For existing gTLDs, reservation of gTLD strings is a contractual condition imposed upon the TLD operator, not a result of ICANN policy development.

As new gTLDs came on board as of 2005, the hyperlink to the IANA list was referenced in the gTLD contract so that there would not be a static list of gTLDs, rather a dynamic list. For contractual compliance, existing registries need to consult this list on an ongoing basis. The goal of the GNSO Dec05 PDP (Introduction of New gTLDs) is to develop an objective process to allow many new gTLDs to exist on the Internet that would have the effect of expanding the IANA list contained at http://data.iana.org/TLD/tlds-alpha-by-domain.txt.

The primary reasons for the sub-group recommendation are 1) TLD1.TLD2 has recently been identified as not being a risk to the security and stability of the DNS and 2) The potential risk of user confusion for new gTLDs has been balanced against a) the fact that thousands of combinations have existed for an extended period of time for TLD1.TLD2 (e.g. www.net.com, www.edu.org, www.jobs.com, www.travel.ca) without any documented side effects of user confusion to corresponding gTLD strings and b) the anticipation of many new gTLDs to the root zone (and the timing of new gTLDs to the root zone) poses a scalability issue for the management of this reserved names category. As a result, the basis for a given gTLD reservation in a given gTLD string contained at http://data.iana.org/TLD/tlds-alpha-by-domain.txt could become confusing for just about anyone to understand the origin of. Scalability of the gTLD reserved names category comes into question under the assumption that an objective process is in place to admit many new gTLD strings at varying points in time in the coming years ahead.



3.      Consultation with experts

The sub-group did not feel the need to seek additional technical expert advice for the reason ICANN's RSTEP recently provided its expert opinion that TLD1.TLD2 was not a risk to the security and stability of the DNS as follows:

"<TLD>.<TLD> combinations are already extremely common, including combinations that seem far more likely to cause problems than two-character SLDs within .name, such as net.uk or de.com. The review team is not aware of any reports of problems attributed to existing <TLD>.<TLD> combinations" (emphasis added).

The gTLD Reserved Name sub-group relied upon additional advice provided by members of ICANN's GNSO constituencies. The primary issue at hand for investigation by the sub-group pertained to the potential risk to user confusion as a result of removing gTLD strings as a reserved names category for future, new TLDs. It is always difficult to gauge potential future risk absent empirical evidence. The sub-group recommendation takes into account that the primary goals of the Dec05 PDP will be achieved, which is a process to introduce many new gTLDs in a manner that is objective and can scale with least amount of subjectivity.

The sub-group took appreciation to the fact that conflicting opinion was in fact the result of the initial work of the gTLD reserved names category (i.e., there was not a clear - or majority view - to the issue of user confusion but instead conflicting views). For this reason, the sub-group - during its extended work - chose the initial approach of challenging the view that user confusion would NOT become the result.

Substantive feedback from GNSO constituency members indicated that the burden of potential user confusion should instead be placed upon those that wish to maintain the status quo of gTLD strings as reserved names. Reasons for this included unfair protectionism for existing gTLD operators, scalability concerns, and unfounded claims for potential user confusion where such have not been shown to exist today. Further investigation by the sub-group of Registry Constituency members found that not all members of the Registry Constituency shared the view of potential user confusion.

In all, members of the Registry, Registrar, and Business Constituency responded to the sub-group's request for feedback. The concern for potential user confusion was voiced the strongest by members of the Registry Constituency - but not an opinion shared by all Registry Constituency members. Also, there was not consistency of opinion based upon whether the Registry Constituency member is sponsored or unsponsored. For example, some sponsored gTLDs felt there would not be a likelihood of user confusion as result of removing gTLD strings as reserved names for future gTLDs while other sponsored gTLDs had the opposite opinion. Likewise, unsponsored gTLDs offered opposite opinions to the issue of potential user confusion.

Feedback from individual members of the Registrar Constituency and Business Constituency supported the notion that there would not be a likelihood of user confusion as the result of TLD1.TLD2 for new gTLDs. Feedback was not received from the IP Constituency, ISP Constituency, and Non Commercial Users Constituency. The subgroup assumed that this indicates the issue is not of material impact to the respective constituency members, including the issue of potential user confusion as a result of removing gTLD strings as reserved names for new gTLDs.

The sub-group examined the GAC Principles regarding New gTLDs (http://gac.icann.org/web/home/gTLD_principles.pdf) and determined that this recommendation did not go against these principles.

The sub-group examined the fact that technical expert opinion recently, and for the first time, cited that TLD1.TLD2 did not pose a threat to the security and stability of the DNS and therefore questioned whether ICANN should be imposing such a reserved names category upon new TLD operators. In this light, the sub-group did take into account ICANN's Core Value 3:

To the extent feasible and appropriate, delegating coordination functions to or recognizing the policy role of other responsible entities that reflect the interests of affected parties.

A common thread of all input received by the sub-group is that gTLD strings can be unreserved without known adverse effect to the security and stability of the DNS. A minority opinion surfaced that any such release of gTLD strings in a new gTLD should be upon some 'condition' for the primary reason of avoiding potential user confusion. The minority opinion was unable to justify that user confusion would exist to substantiate the need for conditional release.

The sub-group members reasoned that those in favor of conditional release would have time to document their justification for potential user confusion in the coming months, such as through various public comment periods inclusive with the Dec05 PDP. In consideration of this, the sub-group has noticeably prefaced its recommendation with: "Absent justification for user confusion…"

The sub-group examined the findings of the GNSO Internationalized Domain Names Working Group (http://gnso.icann.org/drafts/idn-wg-fr-22mar07.htm), notably 4.1.5 (Limit Variant Confusion and Collision) and 4.1.6 (Limit Confusingly Similar Strings). The sub-group reasoned that SLD.TLD, where SLD is a different script than TLD, can already exist in a manner that is ICANN compliant (http://www.icann.org/topics/idn/).

Comments the sub-group interpreted as in favor of the recommendation are contained below. (Comments in support of the minority opinion to maintain the status quo to reserve gTLD strings for new gTLDs follow after.)

Marie Zitkova, SITA, .aero registry operator:

Strictly speaking, the current "system" is favoring incumbents, i.e.,

aero.com exists but we are not allowed to register com.aero no matter how much the Coleman airport in the US using this airport code may need it.

Also it in no way addresses the same situation in ccTLDs, i.e., coop.cc is perfectly acceptable to ICANN although if we are talking consumer confusion, that is much more likely.

b) could be confusing if specific rules are not set. I assume that most registries will not know who will register the released name and cannot guarantee how such names would be used once registered so making a registry-registry agreement does not seem to make much sense. If specific rules are set (such as in case of two char names - to implement measure which prevents confusion), this would create additional eligibility requirement and de facto new eligibility policy for some names set for all TLDs. While this is possible, I am not sure about feasibility for all TLDs.

Pat Kane, VeriSign, com/net registry operator:

I think that there is a difference in this space for us as to whether we are sponsored or unsponsored gTLDs.

From a practical perspective, the com and net registries will likely have the names we are talking about for the future already registered, even if new IDN gTLDs are introduced.  So from a consistency approach I believe that there should be no restrictions on unsponsored TLDs.   Whereas sponsored TLDs support a specific community or sponsoring organization, a reserved list should be completely up to that sponsored TLD, but should be in line with the mission of the TLD.  Some of the categories they may choose may be ISO lists of country codes if they have a geography foundation, SIC codes if they have an industry categorization component, or whatever.

Keith Drazek, NeuStar, .biz registry operator:

NeuStar supports recommendation (a) that the reservation requirement be removed from future TLD contracts, and (b) that existing registries are able to release in agreement with each other. Please let me know if you have any other questions.

Ray Fassett, Employ Media, .jobs registry operator[64]:

.jobs is not opposed to removing the reservation requirement for two reasons:

1.      No technical security or stability issue has been identified for the reservation requirement.
2.      The fact that some of the more recent TLD strings have long been released as second level domains in prior released gTLDs.  In effect it is different rules for different circumstances that a general user population is not going to understand the origin of.

Tim Ruiz, Go Daddy registrar:

I would suggest that this reserved name requirement be dropped for all new gTLDs, and that existing gTLDs be allowed to request these strings to be unreserved and that ICANN would not unreasonably deny such requests.

Peter Stevenson, Fabulous.com registrar:

I agree with Tim and believe that the reserving of gTLD strings from registration at a second level should be dropped for all new gTLDs.

All new gTLDs should be treated the same as each other.

I do not believe or know of any adverse affects that would occur from this being dropped.

Ross Radar, Tucows registrar:

I don't believe that we need policy in this area at this time. The number of reservations and the size of the "problem" are both small enough that continuing to pursue this in an ad hoc manner between ICANN staff and the registry in question seems appropriate. Until it can be demonstrated that there are security or stability issues, I believe ICANN's policy community should continue to focus its efforts in areas where there is clear harm as a higher priority.

Mike Rodenbaugh, member of Business Constituency:

I very much doubt users would be confused to thinking, for example, that jobs.travel must be affiliated with the .jobs registry or that org.jobs must be affiliated with the .org registry.  I also think it is an unfair advantage for existing TLD registries to reserve their name at the second level in every new TLD, while new gTLD operators can have no such protection in existing TLDs.  Indeed that is the case now with all the 'newer' TLD strings registered in com, net and org.  In the world of 1000 TLDs that everyone envisions, this reservation requirement makes no sense and it has not been justified in any way by anyone to date.  I think therefore that the WG should recommend it be eliminated, and existing domains reserved on this basis should be released.  

If this is not the majority opinion, then I would like to make this a minority statement.

Alistair Dixon, Member of Business Constituency:

I have similar concerns to Mike: a requirement for permission from the relevant gTLD registry for release of a gTLD string seems to me as much a device to restrict competition as to unreserve names.  As was pointed out on the call, gTLD strings are present in many cc domains, e.g., .com.au, .net.nz, .mil.nz, .org.uk, etc.  There is certainly no evidence of user confusion with these strings and why there would be with jobs.travel or mobi.net is unclear to me.  The RSTEP report seems to confirm this.  I would therefore agree with Mike's proposed recommendation that existing names reserved on this basis be released.

John Berryhill (in part):

If there is an issue relating to how the strings are used, that is probably outside of the scope of domain name policy per se.

MINORITY OPINIONS:

David Maher, PIR, .org registry operator:

PIR votes to preserve the reserved names provisions (with some conditions for release) as they exist for .ORG, and to maintain a similar reserved names provision for new gTLDs.

Caroline Greer, mTLD, .mobi registry operator:

DotMobi agrees with the pre recommendation-i.e., lifting of the requirement if agreement is reached between the relevant Registries and subsequent notification to ICANN.

Cherian Mathai, Tralliance, .travel registry operator:

.travel supports the second proposition - to preserve the reservation of gTLD strings for new TLDs.

We believe it should continue because otherwise

(a) it can lead to confusion as to what a TLD is, and

(b) for a sponsored TLD, the name string belongs to a particular community and if it is not reserved it could lead to usage of that string by extraneous elements in a way detrimental to community's TLD.

A case in point would be the .travel string promoted by new.net that took the .travel domain name at the third level and started marketing .travel.

It took us more than three years and counting at an enormous cost to educate the travel community that new.net's .travel is not a TLD. This is what we referred to as the confusion with regard to what a TLD is. We had to keep on harping the theme that we are the ICANN approved TLD and the other is a third level domain name, even though with the use of the freely downloadable software they were able to confuse the market place and mask itself as a TLD. As the only TLD who had been a victim of new.net we feel that this reservation has a lot of merit.

If such an entity can do an end-run on a bonafide TLD at the third-level, imagine what it would be like if the name is available at the second-level in all future TLDs. We do not know whether this is a security and stability issue according to SSAC. But as seen in the case of new.net and also possibly in the future it would lead to confusion and mis-appropriation of domain names under false pretenses. This would make a mockery of the ICANN TLD award process.

We are not sure … that if the reservation of existing TLDs is released, the current and future TLD operators are bound by the name eligibility policies of an existing sponsored TLD. We do not believe that travel.mobi or travel.tel or a future travel.bank will be bound by the name eligibility policies of the global travel community conceived and developed through the .travel sponsor, The Travel Partnership Corporation.

True, there is no protection for future TLD strings in existing TLDs. But it is better to limit the damage that could be caused by upstart elements creating confusion and chaos in the domain name marketplace rather than provide them with an "open season".

Simon Heard, Global Name Registry, .name registry operator:

.name's supports preserving current practice with certain conditions for release.

 

Philip Colebrook, Telnic, .tel registry operator

Support reservation of gtld strings with release under certain circumstances.

Edmon Chung, dotASIA, .asia registry operator:

I do not quite understand the point about restriction of competition.  This particular whole process for creating new gTLDs creates competition for registries, which I do not find any problem with.  I personally do think that it is a sensible idea to caution new gTLDs on the release of names that correspond to other TLDs.  That is no different than cautioning new gTLDs on releasing names that have some form of registered prior right that may or may not be confusing given a particular TLD.

What I am suggesting I think makes sense in a way that would caution new TLD operators that it is important to take into consideration the other TLDs when you allocate these names.  As mentioned, the idea is that consent be sought from existing registry operator for which must not be unreasonably withheld.  For example, it is unreasonable to withhold such consent due to anti-competition reason.

So I don't quite understand the issue with restricting competition.

The other part about managing the process, well even at the 1000 gTLDs level, I do not think it will be overly burdensome if these names required such a consideration.  Again, back to the point that giving some consideration and not prevention is important in my mind.

Furthermore, before we get to that volume, I am sure many other policies have to be revised as well... and this would not be on top of the list I feel.

Marcus Faure, CORE registrar:

While I can see that damage has already been done, this should not mean we deliberately increase the level of damage. The cc.com business relies on confusing users and leaves them in the hands of a commercial institution with no oversight; hence I see this as counterproductive to the development of the DNS. I therefore suggest to stay with the current restrictions and moreover ask to have the effect of cc.com registrations on us investigated.

I do not have a problem with a company using tld.com for their own website. I do have a problem with a "registrar" offering 3rd level registrations under tld.com, especially if they tell you that this is the way the internet is structured, and the reason it is structured like that is because they have a good deal with [insert name of big icann registrar].

This may not be within our scope, but if I were king I'd rule this out.

4.      Summary of Relevant Information Sources

h.      ICANN Registry Agreement Requirements

Language INCLUDED within the main body Registry Agreements for .asia, .biz, .cat, .com, .info, .jobs, .mobi, .net, .org, .travel and .tel (the latter modified slightly) states that:

''Registry Operator shall reserve, and not register any TLD strings  appearing on the list of reserved TLD strings attached as Appendix 6 hereto or located at http://data.iana.org/TLD/tlds-alpha-by-domain.txt for initial (i.e., other than renewal) registration at the second level within the TLD." 

That particular language is NOT INCLUDED in older TLD Agreements: .aero (2001), .coop (2001), .museum (2001), .name (2001) and .pro (2002) - those TLDs reserve the following names either as per Appendix 11 or Appendix K of their contracts in addition to two letter labels:

·         aero

·         arpa

·         biz

·         com

·         coop

·         edu

·         gov

·         info

·         int

·         mil

·         museum

·         name

·         net

·         org

·         pro

a. GAC Principles Regarding New gTLDs

http://gac.icann.org/web/home/gTLD_principles.pdf

    1. ICANN Registry Services Technical Evaluation Panel http://www.icann.org/registries/rsep/RSTEP-GNR-proposal-review-team-report.pdf

    1. GNSO Internationalized Domain Names Working Group http://gnso.icann.org/drafts/idn-wg-fr-22mar07.htm

Report on Internet Security and Stability Implications

of the Global Name Registry, LTD

Proposal for the Limited Release of Initially Reserved

Two-Character Names

December 4, 2006

Excerpt below. Full report at: http://www.icann.org/registries/rsep/RSTEP-GNR-proposal-review-team-report.pdf

3 Analysis of Security and Stability Issues

In order to assess the potential security and stability impact of introducing two-character SLDs into .name, the review team began by considering the current practices regarding two-character SLDs within various TLDs, as well as the presence of <TLD>.<TLD> combinations. The review team noted that there are a significant number of TLDs that allow the registration of TLDs as SLDs. A systematic walk through the DNS shows the following numbers:

Number of TLDs registered in the root zone 265

Possible <TLD>.<TLD> combinations 70225

<TLD>.<TLD> combinations with NS or A

Records 11592

In addition to considering the frequency of two-character SLDs and

<TLD>.<TLD> combinations, the team reviewed known problems with <TLD>.<TLD> combinations. A recent overview of known problems with the DNS was presented at the RIPE53 meeting by Duane Wessels of The Measurement Factory/CAIDA. It recited a list of 32 known problems with the DNS, categorized as follows:

Protocol Issues 9

Implementation Issues 8

Operational Issues 10

Registry/Registrar Issues 5

Of the eight implementation issues, two were related to a combination of the presence of <TLD>.<TLD> domains and bad software behavior. The most significant of these problems is described in RFC 1535 and is discussed in detail in Section 3.1.1 below. The review team also conducted an exhaustive investigation of the potential security- and stability-related effects in each of the potential problem areas.

In addition, the review team conducted two kinds of analysis on the data collected from the behavior of actual DNS servers. First, we reviewed name server data from one of the .uk name servers.

Second, we conducted an experiment in an attempt to produce the problems theoretically caused by <TLD>.<TLD> combinations.

We also considered special characteristics of the .name domain.

Taking these factors into consideration, the review team concludes that:

(1) Name server and experimental data reveal that inadvertent queries for <TLD>.<TLD> domains are fairly uncommon. More often than not, these queries seem to be the result of user error or temporary failures as opposed to software errors.

(2) <TLD>.<TLD> combinations are already extremely common, including combinations that seem far more likely to cause problems than two-character SLDs within .name, such as net.uk or de.com. The review team is not aware of any reports of problems attributed to existing <TLD>.<TLD> combinations.

(3) On balance, and taking into account theoretical security and stability effects as a result of the introduction of two-character

SLDs within .name, these SLDs are unlikely to have any meaningful net increase in the level of these security or stability issues.


ANNEX SEVEN -- CONTROVERSIAL NAMES SUB GROUP REPORT

GNSO new TLDs Committee

Reserved Names Working Group

Sub-Group Report

Controversial Names

10 May 2007


DEFINITIONS

Controversial Names

A name is designated as a controversial name if it qualifies as a gTLD under the then prevailing String Criteria, does not fall under any other Reserved Name category and is disputed for reasons other than that it either falls under any other Reserved Name category or that infringes on the prior legal rights of others.

CN-DRP

Controversial Names - Dispute Resolution Panel

EXECUTIVE SUMMARY

1.      This Report contains the recommendations and supporting information from the GNSO Reserved Names Working Group (RN-WG) regarding Controversial Names.

2.      The members of the group are:

l        Marilyn Cade

l        Avri Doria (chair)

l        Victoria McEvedy

l        Michael Palage

l        Tamara Reznik

3.      The subgroup reached full consensus on the recommendations below.

4.      There was no disagreement in the subgroup regarding the recommendations below.

5.      The table below contains the recommendations for Controversial names.

SoW number

(RN-WG 30-day extension SoW)

Reserved Name Category

Domain Name Level(s)

Recommendation

Recommendation task 10

Controversial Names

All Levels, ASCII & IDN

There should not be a new reserved names category for Controversial Names.

Recommendation task 10

Controversial Names

Top Level, ASCII & IDN

There should be a list of disputed names created as a result of the dispute process to be created by the new gTLD process.

Recommendation task 10

Controversial Names

Top Level, ASCII & IDN

In the event of the initiation of a CN-DRP process, applications for that label will be placed in a HOLD status that would allow for the dispute to be further examined. If the dispute is dismissed or otherwise resolved favorably, the applications will reenter the processing queue. The period of time allowed for dispute should be finite and should be relegated to the CN-DRP process. The external dispute process should be defined to be objective, neutral, and transparent. The outcome of any dispute shall not result in the development of new categories of Reserved Names.[65]

Recommendation task 10

Controversial Names

Top Level, ASCII & IDN

The new GTLD Controversial Names Dispute Resolution Panel should be established as a standing mechanism that is convened at the time a dispute is initiated. Preliminary elements of that process are provided in this report but further work is needed in this area.

Recommendation task 10

Controversial Names

Top Level, ASCII & IDN

Within the dispute process, disputes would be initiated by the ICANN Advisory Committees (e.g., ALAC or GAC) or supporting organizations (e.g., GNSO or ccNSO). As these organizations do not currently have formal processes for receiving, and deciding on such activities, these processes would need to be defined:

l     The Advisory Groups and the Supporting Organizations, using their own processes and consistent with their organizational structure, will need to define procedures for deciding on any requests for dispute initiation.

l     Any consensus or other formally supported position from an ICANN Advisory Committee or ICANN Supporting Organization must document the position of each member within that committee or organization (i.e., support, opposition, abstention) in compliance with both the spirit and letter of the ICANN bylaws regarding openness and transparency.

Recommendation task 10

Controversial Names

Top Level, ASCII & IDN

Further work is needed to develop predictable and transparent criteria that can be used by the Controversial Resolution Panel. These criteria must take into account the need to:

l     Protect freedom of expression

l     Affirm the fundamental human rights, in the dignity and worth of the human person and the equal rights of men and women

l     Take into account sensitivities regarding terms with cultural and religious significance.

Recommendation task 10

Controversial Names

Top Level, ASCII & IDN

In any dispute resolution process, or sequence of issue resolution processes, the Controversial name category should be the last category considered.


Supporting Information

1.      Background

The work items for the subgroup contained the following elements:

a.        Review the GAC Principles regarding New gTLDs with regard to controversial names

b.        Consult with the GAC as possible

c.         Consider the possibility of creating a disputed name list (not a reserved name list) that would be updated whenever controversial names are rejected and would be used for guideline purposes only

d.        Restate recommendations in the original RN-WG report for possible use in the New gTLD evaluation process, not as reserved names

e.        Describe process flow

2.      Rationale for the recommendations

The following reflects the work that was done on each of the work items listed in the SOW.

a. The GAC principles were reviewed.

One that was discussed in particular and that created some concern:

If individual GAC members or other governments express formal concerns about any issues related to the new gTLDs, the ICANN board should fully consider those concerns and clearly explain how it will address them.

Some of the subgroup members indicated a concern that the GAC principle points to an issue with the original position that was supported by the RN WG. Specifically in recommendation number 1 from the RN WG report of 19 March 2007:

A label that is applied for would be considered Controversial if during the Public Comment phase of the new gTLD application process the label becomes disputed by a formal notice of a consensus position from an ICANN Advisory Committee or ICANN Supporting Organization, and otherwise meets the definition of Controversial Names as defined above.

This previous recommendation indicated that the dispute process would only be activated by a consensus position of an Advisory Committee such as the GAC, whereas the GAC principle indicates that the concern of an individual government be considered by the ICANN board before making a decision on a new gTLD. In the discussion, several considerations came to light:

·        The GAC principle does not specifically relate to the new gTLD dispute process under review but to the consideration given by the ICANN Board to issues raised by an individual government. In some respects, this is a restatement of the common respect that the ICANN board should give to any appeal it receives. It is also an extension of the ICANN Board's obligation under its bylaws to consider the advice and concerns of the GAC.

·        While the GAC principle may not directly relate to the dispute process being defined by the new gTLD PDP process as it addresses board behavior, one of the guiding scalability principles of that PDP process is that, to the maximum extent possible, the process should provide a predictable and transparent method for approving new gTLDs that does not rely on the Board having to handle each and every dispute.

·        On the other hand, the same scalability principle requires that the disputes be filtered before reaching the dispute process. A concern has been expressed by some members of the subgroup that it is very likely that a great number of candidate gTLDs might be controversial in the view of some individuals, groups or individual countries. It is for this reason that the original RN working group recommended that the threshold for a dispute be set at the consensus level for an ICANN advisory committee or supporting organization.

·        There was, however, some concern raised that it may not be appropriate for a GNSO process to set the internal criteria for a decision made by the GAC or another Advisory group. It was acknowledged that it may be advisable to modify the original RN working groups recommendation to read:

o       A label that is applied for would be considered Controversial if during the Public Comment phase of the new gTLD application process the label becomes disputed by a formal notice of a consensus or other formally supported decision process position from an ICANN Advisory Committee or ICANN Supporting Organization, and otherwise meets the definition of Controversial Names as defined above.

·        It was discussed that in the event the proposal being recommended in this report is accepted, each of the Advisory Committees and Supporting Organizations would need to develop a process, appropriate to its organizational constraints, to allow it to initiate disputes.

·        As part of the discussion over who could initiate a dispute, several other concerns where raised with how organizations external to ICANN could raise disputes concerning controversial names.

·        Again, applying the principles of scalability there was some concern expressed that the dispute process could not be open to any and all who might dispute a candidate gTLD.

·        Recognizing that the constituency and advisory groups of ICANN are, in principle, responsible for representing all of the stakeholders involved in the allocation and use of TLDs, it was considered by some in the subgroup sufficient that all of the supporting organizations, composed of the constituencies and other stakeholders, and advisory groups be empowered to initiate dispute actions on potentially controversial TLDs. One value of using the Advisory Groups and Supporting Organizations for such purpose was that these groups were optimally placed to understand both the concerns of the participating stakeholders and the processes of ICANN.

·        There was a concern expressed that perhaps all stakeholders were not adequately represented by the current ICANN structures and that in this case these individuals and other stakeholders would not have adequate access to the dispute process. This issue, however, was larger than the scope of the subgroup and it is already the subject of other remedial processes within ICANN.

·        There was also an option expressed in the subgroup for allowing any organizational entity with standing to initiate a dispute using the CN-DRP process. Under this formulation, the definition of 'standing' would require further work.

·        There was also an option expressed for allowing any individual or organization to initiate a dispute. In order to support process scalability, a fee could be charged for initiating a dispute. A concern raised about this option concerned the financial barrier to disputes this might create. One possibility mentioned (in private conversations) was that this option could be combined with the option that allowed ICANN Advisory Committees to also initiate disputes.

b. Consult with the GAC

 

It was considered by the subgroup that the general consultation held with the GAC on 16 April 2007, was adequate to the subgroup's needs. The subgroup does, however, look forward to discussing any of the recommendations made in this report with the Advisory Committees or their members.

c. Consider the possibility of creating a disputed name list

The subgroup supported the idea that a disputed name list would be created as a result of the dispute process. This was not, however, to be considered a reserved name list, and the names on the list could still be approved in future allocations. For discussion purposes[66]:

·        The gTLD .god (or even .g-d) might be disputed as controversial

·        The CN-DRP might agree with the case for controversy brought forward and might decide to refuse the application and to put the name on the disputed name list.

·        During a separate application round another application, perhaps even including the previous applicants, might apply with the backing of the World Council of Religions and many of the world's religions. In such a case, the CN-DRP might recommend removing the name from the disputed name list and assigning it to the applications.

d. Restate recommendations in RN-WG report for possible use in the New gTLD evaluation process, not as reserved names

 

This report includes a restatement of the proposal for creation of a CN-DRP dispute evaluation process and the creation of a disputed name list.

e. Describe process flow

The purpose is to consider and to propose procedural options and concepts that could be used as a basis for the development of a standing panel to handle objections on the basis of 'controversial names' for binding dispute resolution.

The ICANN RSTEP process was used as a model for this proposal.

Some of the recommended elements of a proposed Controversial Names - Dispute Resolution Panel (CN-DRP) include:

1.      Establish a 'standing group' with identified 'experts' and a procedure for the selection of such experts. This could be by selection of existing service providing organizations such as WIPO, CPR, NAF or others. Alternatively a group could be appointed by public tender based on recognized qualifications.

2.      Identify a senior individual, e.g., a retired judge, to act as chair, but establish two or more, vice-chairs with expertise in other areas who are well respected, and senior members with different kinds of expertise.

3.      Use the Chair and vice chairs as a standing committee of 3-4 people, whose task it is to help to identify 'neutral experts' to act as panelists. Chair and vice-chairs, in particular, must not have current relationships with ICANN and should be highly respected and credible individuals. The concern here is to avoid any perception that the dispute process may not be independent and to avoid even the perception that insiders can be influenced and decisions politicized.

4.      For Panelists as well, great care should be taken to ensure neutrality, and avoid conflicts of interests or the perception of a conflict of interest. An initial list of participants in 'panels' can be pre-qualified to act, on an invited basis, when a name is disputed as controversial. The role of the chair would function much like the chair of the RSTEP. The chair could appoint knowledgeable experts from areas, such as culture, to advise the 'panel' on language, or cultural, or technical issues with a particular controversial string.

5.      An initial list of panelists could be developed, with the understanding that additions will be possible, depending on the categories of names that are referred to the CN-DRP.

6.      Each dispute shall be determined and accompanied by a decision with reasoned grounds. The report of the decision will be published, as part of the routine publication of the application.

7.      Further work needs to be done on drafting, with the help of expert advice, a set of procedural rules to govern the decision process of the CN-DRP. It is important going forward to avoid lists of examples, categories or any other attempt to list and predict in advance what is controversial as this will inevitably become entrenched. Avoiding such entrenchment and pre-determined lists is key to the recommendation in the first report of the Reserved Names WG.

8.      The CN-DRP's decisions are binding. One issue under discussion was whether further work is needed to develop an appeals process.

9.      The CN-DRG will have access to legal counsel external to ICANN that it may consult for questions of national law, etc.

10. Where the CN-DRP review team or the ICANN staff identify that a name brought to the CN-DRP might also have other stability or stability concerns, all other comment period challenges and reserved name evaluations must occur prior to evaluation by the CN_DRP.

11. Funding

                                                              i.      Reimbursement: Create a compensation framework that would pay a retainer to the chair and vice chairs to be available on a 'standing basis'. Develop a compensation fee schedule, to be developed by the Chair, working with ICANN staff and administered by the chair/staff manager, with a flat amount for an estimated number of hours devoted to the consideration, documentation, etc. by the Panel members.

                                                            ii.      Initially, since there is no experience in what the fees might be, task the chair and vice chairs, supported by ICANN operational staff, to develop an 'interim budget' and fee schedule.

                                                          iii.      Applicants should expect that the cost of ICANN fees will include the cost of convening the Panel.

                                                           iv.      Consistent with the overall fee structure established for new gTLDs, the fees established should include a cost recovery element that supports the additional costs that ICANN incurs.

12. Further work for creation of the CN-DRP includes, but is not limited to:

                                                              i.      Development of criteria for the background of the chair, vice chairs and panelists

                                                            ii.      Further development of what might constitute transparent and predictable criteria/guidance to the panels

                                                          iii.      Whether it is possible to have a 'quick look' by the chair/vice chairs to determine whether to accept a referral or not, and what appeal of that would be available, if any

                                                           iv.      Under consideration of how to recoup the fees for providing the dispute procedure, discussion of who should fund the procedure should include whether the applicant pays or whether the costs are shared by the entity filing the dispute, etc.

                                                             v.      Further work is needed in scoping and scaling the anticipated number(s) of possibly controversial applications and what time frame should be established to give a panel an assignment, research/discuss/reach a decision, and whether and what documentation would be expected from the applicant and the entity that files the dispute.



3.      Summary of Relevant Information Sources

  • Previous discussion and work related to controversial names done by the New gTLD Task force can be found in the current version of the GNSO new TLDs Committee Draft Final Report at:

http://gnso.icann.org/drafts/pdp-dec05-draft-fr.htm

  • The GAC Principles regarding New gTLDs can be found at:

http://gac.icann.org/web/communiques/gac27com.pdf

  • The original Controversial Names Subgroup report contains much additional information that was not duplicated in this report. It is in Appendix J of the original RN-WG report at:

http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf


ANNEX EIGHT -- Alphabetical Listing of Recommended Reserved Names

The tables below are intended to be brief summaries of all names that the RN-WG recommends be reserved, ordered alphabetically by name where possible in the first table and alphabetical by category in the second table. These tables are provided for convenience only; please refer to the recommendations provided in Section One for complete reservations recommended. The names listed are not case-sensitive.

ASCII

IDN

Top Level

2nd Level

3rd Level

Top Level

2nd Level

3rd Level

0

1

2

3

4

5

6

7

8

9

a

AFRINIC

APNIC

ARIN

ASO

b

c

ccNSO

d

e

Example

f

g

GNSO

gtld-servers

h

i

IAB

IANA

iana-servers

ICANN

IESG

IETF

Internic

IRTF

ISTF

j

k

l

LACNIC

LATNIC

m

n

NIC

o

p

q

r

rfc-editor

RIPE

root-servers

s

t

u

v

w

Whois

www

x

y

z

AFRINIC

APNIC

ARIN

ASO

ccNSO

Example

GNSO

gtld-servers

IAB

IANA

iana-servers

ICANN

IESG

IETF

Internic

IRTF

ISTF

LACNIC

LATNIC

NIC*

rfc-editor

RIPE

root-servers

Whois*

www*

AFRINIC

APNIC

ARIN

ASO

ccNSO

Example

GNSO

gtld-servers

IAB

IANA

iana-servers

ICANN

IESG

IETF

Internic

IRTF

ISTF

LACNIC

LATNIC

NIC*

rfc-editor

RIPE

root-servers

Whois*

www*

All Unicode versions of 'Example'

All Unicode versions of 'Example' **

All Unicode versions of 'Example' **

* For use by registry operators only.

** Do not try to translate 'example' into Unicode versions for various scripts or to reserve any ACE versions of such translations or transliterations if they exist, except on a case by case basis as proposed by given registries.

Reserved Names Summary by Category

RN

ASCII

IDN

Category

Top Level

2nd Level

3rd Level

Top Level

2nd Level

3rd Level

Controversial

No

No

No

No

No

No

Geographic & Geopolitical

No

No

No

No

No

No

gTLDs at the 2nd & 3rd Level

N/A

No

No

N/A

No

No

ICANN & IANA related

Yes

Yes

Yes

No*

No*

No*

NIC, Whois, www

Yes

Yes**

Yes**

No

No

No

Single Letter, Single Digit Combinations

No

No

No

N/A

N/A

N/A

Single Characters

Yes

No

No

No***

No

No

Symbols

Yes#

Yes#

Yes#

N/A

N/A

N/A

Tagged

Yes

Yes

Yes

N/A

N/A

N/A

Two Digits

Yes

No

No

N/A

N/A

N/A

Two IDN Characters

N/A

N/A

N/A

No***

No

No

Two Letters

Yes##

No

No

N/A

N/A

N/A

* Except for Unicode versions of 'example'.

** For use by registries only.

*** At the top level, requested strings should be analyzed on a case by case basis in the new gTLD process depending on the script and language used in order to determine whether the string should be granted for allocation in the DNS.

# Except for the use of the hyphen (-) where allowed.

## For ccTLD use only.


ANNEX NINE -- PARTICIPATION DATA: RN-WG Meeting Dates & Locations

p = present rp = remote participation aa = absent apologies noted Tel = teleconference MdR = Marina del Rey

Location:

Tel

Tel

Tel

MdR

Tel

Tel

Tel

Tel

Tel

Tel

Lisbon

Tel

Tel

Tel

Tel

Tel

Name Date:

1/25

2/8

2/15

1/24

3/1

3/5

3/7

3/8

3/12

3/15

3/24

4/11

4/18

4/25

5/3

5/10

Alistair Dixon

p

p

p

rp

p

p

p

p

aa

p

rp

 

 

p

p

p

Bilal Beiram

 

 

 

 

 

 

 

 

 

p

 

 

 

 

 

p

Neal Blair

p

p

p

p

p

p

p

p

p

p

p

p

p

p

p

p

Marilyn Cade

p

p

p

p

p

p

p

p

aa

p

p

p

p

p

p

p

Mike Rodenbaugh

 

aa

p

p

p

 

 

p

aa

p

p

p

p

 

aa

p

Avri Doria

p

p

p

p

p

p

p

p

p

p

p

p

p

p

p

p

Sophia Bekele

 

 

 

p

p

p

p

p

 

p

p

 

aa

aa

aa

 

Dan Dougherty

p

p

p

p

p

p

p

p

 

p

 

 

 

 

 

 

Gregory S. Shatan

p

p

p

p

p

p

p

p

p

p

 

p

p

p

p

p

Lucila King

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Tamara Reznik

p

 

p

rp

p

p

p

p

p

p

 

p

p

p

aa

p

Mawaki Chango

 

 

 

 

 

 

 

 

 

 

p

 

 

 

 

 

Victoria McEvedy

 

 

 

 

p

p

p

p

p

p

p

p

 

 

 

 

Jonathon Nevett

p

p

p

p

p

 

 

p

p

p

p

aa

p

 

aa

aa

Seth Jacoby

p

 

 

 

p

 

 

 

 

 

 

 

 

 

 

 

Tim Ruiz

p

p

aa

 

p

p

p

p

p

p

p

aa

 

 

 

aa

Edmon Chung

 

 

 

aa

p

p

p

p

 

p

p

p

 

 

 

 

Caroline Greer

p

p

aa

rp

aa

p

aa

 

 

 

 

 

p

p

 

p

Ray W. Fassett

 

 

 

p

 

 

 

 

 

 

p

 

p

p

p

p

Chuck Gomes

p

aa

p

p

p

p

p

p

p

p

p

p

p

p

aa

p

Michael D. Palage

p

aa

p

p

p

p

p

p

p

p

p

p

p

p

 

p

Minjung Park

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Dr. Kung-Chung Liu

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Timothy Denton

 

p

p

p

p

p

p

p

p

p

rp

 

 

 

 

 

Denise Michel

p

 

 

p

 

 

 

 

 

 

p

 

 

 

 

 

Glen de Saint Géry

p

p

p

rp

p

p

p

p

p

p

p

p

p

p

p

p

Liz Williams

p

 

aa

p

 

 

 

 

 

 

p

p

p

p

p

p

Tina Dam

 

 

 

p

 

 

 

 

 

 

 

 

 

 

 

 

Dan Halloran

 

 

 

p

 

 

 

 

 

 

 

 

 

 

 

 

Patrick Jones

p

p

p

p

p

p

p

p

p

p

p

p

p

p

p

p

Ram Mohan

 

 

 

p

 

 

 

 

 

 

 

 

 

 

 

 

Cary Karp

 

 

 

rp

 

 

 

 

 

 

 

 

 

 

 

 



[1] Posted at http://www.ietf.org/rfc/rfc952.txt

[2] Posted at http://www.ietf.org/rfc/rfc1123.txt

[3] Posted for the Lisbon meeting at http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf

[4] Posted at http://forum.icann.org/lists/gnso-rn-wg/msg00476.html

[5] Agenda posted at http://gnso.icann.org/meetings/agenda-12apr07.shtml

[6] Posted at http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf

[7] The following RFCs require that domain names must begin with a letter or a digit so the use of the hyphen as a top level domain or the use of names beginning or ending with a hyphen at any level is not allowed: RFC 952, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc952.txt.pdf. This RFC was later modified by RFC 1123, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1123.txt.pdf.

[8] This is notwithstanding two letter TLDs will be allowed only as ccTLDs, when added to the ISO-3166 list, and as such all two letter ASCII strings will remain reserved at the top level and second level of a domain name, although registries may propose release of two letter LDH strings at the second level provided that measures to avoid confusion with any corresponding country codes are implemented.

[9] The subgroup was encouraged by the ccNSO not to consider removing the restriction on two-letter names at the top level. IANA has based its allocation of two-letter names at the top level on the ISO 3166 list. There is a risk of collisions between any interim allocations, and ISO 3166 assignments which may be desired in the future.

[10] The existing gTLD registry agreements provide for a method of potential release of two-character LDH names at the second level. In addition, two character LDH strings at the second level may be released through the process for new registry services, which process involves analysis of any technical or security concerns and provides opportunity for public input. Technical issues related to the release of two-letter and/or number strings have been addressed by the RSTEP Report on GNR's proposed registry service. The GAC has previously noted the WIPO II Report statement that "If ISO 3166 alpha-2 country code elements are to be registered as domain names in the gTLDs, it is recommended that this be done in a manner that minimises the potential for confusion with the ccTLDs."

[11] Considering that the current requirement in all 16 registry agreement reserves "All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")", this requirement reserves any names having any of a combination of 1296 different prefixes (36x36).

[12] Internet Draft IDNAbis Issues: http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt (J. Klensin), Section 3.1.1.1

[13] Considering that the current requirement in all 16 registry agreement reserves "All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")", this requirement reserves any names having any of a combination of 1296 different prefixes (36x36).

[14] Considering that the current requirement in all 16 registry agreement reserves "All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")", this requirement reserves any names having any of a combination of 1296 different prefixes (36x36).

[15] With its recommendation, the sub-group takes into consideration that justification for potential user confusion (i.e., the minority view) as a result of removing the contractual condition to reserve gTLD strings for new TLDs may surface during one or more public comment periods.

[16] Note that this recommendation is a continuation of the recommendation in the original RN-WG report, modified to synchronize with the additional work done in the 30-day extension period.

[17] The full list of registry agreements is found at http://www.icann.org/registries/agreements.htm.

[19] Note that these work tasks are only a prerequisite for the Introduction of New gTLDs if the requirement to reserve single letter names is not included in new gTLD registry agreements.

[20] The following RFCs require that domain names must begin with a letter or a digit so the use of the hyphen as a top level domain or the use of names beginning or ending with a hyphen at any level is not allowed: RFC 952, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc952.txt.pdf. This RFC was later modified by RFC 1123, ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1123.txt.pdf.

[21] This is notwithstanding two letter TLDs will be allowed only as ccTLDs, when added to the ISO-3166 list, and as such all two letter ASCII strings will remain reserved at the top level and second level of a domain name, although registries may propose release of two letter LDH strings at the second level provided that measures to avoid confusion with any corresponding country codes are implemented.

[22] The subgroup was encouraged by the ccNSO not to consider removing the restriction on two-letter names at the top level. IANA has based its allocation of two-letter names at the top level on the ISO 3166 list. There is a risk of collisions between any interim allocations, and ISO 3166 assignments which may be desired in the future.

[23] The existing gTLD registry agreements provide for a method of potential release of two-character LDH names at the second level. In addition, two character LDH strings at the second level may be released through the process for new registry services, which process involves analysis of any technical or security concerns and provides opportunity for public input. Technical issues related to the release of two-letter and/or number strings have been addressed by the RSTEP Report on GNR's proposed registry service. The GAC has previously noted the WIPO II Report statement that "If ISO 3166 alpha-2 country code elements are to be registered as domain names in the gTLDs, it is recommended that this be done in a manner that minimises the potential for confusion with the ccTLDs."

[24] The gTLD registry agreements provide a mechanism for release of two-character labels at the second level. "The reservation of a two-character label string shall be released to the extent that the Registry Operator reaches agreement with the government, country-code manager, or the ISO 3166 maintenance agency, whichever appropriate. The Registry Operator may also propose release of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes." See Appendix 6, .ASIA Registry Agreement, http://www.icann.org/tlds/agreements/asia/appendix-6-06dec06.htm.

[26] ICANN Board Resolutions 00.77-00.80, 25 September 2000, http://www.icann.org/minutes/minutes-25sep00.htm.

[27] GAC Principles on New gTLDs (28 March 2007), http://gac.icann.org/web/communiques/gac27com.pdf.

[28] A recording of the 16 April 2007 GAC-GNSO conference call is available at http://gnso-audio.icann.org/gtld-gac-20070416.mp3.

[29] Please note that RFC 1123 (October 1989) updated the host name convention relaxing the restriction on the first character to allow either a letter or digit.

[30] Considering that the current requirement in all 16 registry agreement reserves "All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")", this requirement reserves any names having any of a combination of 1296 different prefixes (36x36).

[31] Internet Draft IDNAbis Issues: http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt (J. Klensin), Section 3.1.1.1

[32] Considering that the current requirement in all 16 registry agreement reserves "All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")", this requirement reserves any names having any of a combination of 1296 different prefixes (36x36).

[33] Considering that the current requirement in all 16 registry agreement reserves "All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")", this requirement reserves any names having any of a combination of 1296 different prefixes (36x36).

[34] See "Comparison of gTLD Registry Reserved Names" prepared for the RN-WG and ICANN Registry Agreements located at (http://www.icann.org/registries/agreements.htm).

[35] ICANN ccTLD Agreements located at (http://www.icann.org/cctlds/agreements.html).

[36] .AU ccTLD Sponsorship Agreement, Attachment F, http://www.icann.org/cctlds/au/sponsorship-agmt-attf-25oct01.htm. The identical provision appears in the other 11 ccTLD agreements.

[40] http://www.ietf.org/rfc/rfc4690.txt?number=4690 (J. Klensin, P. Faltstrom, C. Karp)

[43] http://www.icann.org/minutes/minutes-10sep01.htm. It is also noteworthy that the passage of the resolution by the ICANN Board was far from unanimous (11 in favor, 7 in opposition).

[45] Paragraph 237, Second WIPO Internet Domain Process II

[46] See Paragraph 55,

[47] As the Second WIPO Internet Domain Process acknowledges "the list of names of places in the world that may have been registered as domain names is virtually limitless" See Paragraphs 256, Second WIPO Internet Domain Process.

[48] Geographical indications refer to "indications which identify a good as originating in the territory of a Member, or a region or locality in that territory, where a given quality, reputation or other characteristic of the good is essentially attributable to its geographical origin." See Paragraph 217, Second WIPO Internet Domain Name Process. Examples of Geographical Indicators include Champaign, Napa Valley, Cognac

[49] See Paragraphs 262 thru 263 of the WIPO II Process.

[51] Although other proof of concept registry strings had already been added to the root, i.e. .BIZ, no other proof of concept registry were allowing domain name registrants to register resolving names at the time of the GAC communiqué.

[52] Paragraph 237, Second WIPO Internet Domain Process II

[53] Paragraph 238, Second WIPO Internet Domain Process II

[54] Paragraphs 246 thru 248, Second WIPO Internet Domain Process II

[55] Paragraph 287, Second WIPO Internet Domain Process II

[56] Paragraphs 206, Second WIPO Internet Domain Process II.

[57] Paragraph 207, Second WIPO Internet Domain Process II.

[58] Paragraph 210, Second WIPO Internet Domain Process II.

[59] Paragraph 211, Second WIPO Internet Domain Process II.

[60] Paragraph 213, Second WIPO Internet Domain Process II.

[61] Paragraph 219, Second WIPO Internet Domain Process II.

[62] See J. Crew International, Inc. v. crew.com, a WIPO UDRP decision that discusses both in a majority and minority opinion the limitations involving trademark principles and rights in gross. http://www.wipo.int/amc/en/domains/decisions/html/2000/d2000-0054.html

[63] With its recommendation, the sub-group takes into consideration that justification for potential user confusion (i.e., the minority view) as a result of removing the contractual condition to reserve gTLD strings for new TLDs may surface during one or more public comment periods.

[64] Ray Fassett served as the Chair of this sub-group.

[65] Note that this recommendation is a continuation of the recommendation in the original RN-WG report, modified to synchronize with the additional work done in the 30-day extension period.

[66] Although the SOW asked for specific examples, there was an opinion expressed within the group that in the case of allegedly controversial names, citing examples or even categories of examples, was potentially dangerous as even the mention of an example created a future presumption of controversy.