GNSO New TLDs Committee

Reserved Names Working Group

Final Report

23 May 2007

TABLE OF CONTENTSname="_Toc118169794">

DEFINITIONS....................................................................

BACKGROUND.................................................................

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

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

15

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

16

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

19

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

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

SECTION FOUR
-- RECOMMENDATIONS FOR NEW WORK

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

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

DEFINITIONS.........................................................................................................................................

42

EXECUTIVE SUMMARY..........................................................................................................................

42

Supporting Information................................................................................................................

46

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

DEFINITIONS.........................................................................................................................................

52

EXECUTIVE SUMMARY..........................................................................................................................

54

Supporting Information................................................................................................................

59

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

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

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

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

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

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

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

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

ANNEX THREE
-- TAGGED NAMES SUB GROUP REPORT

DEFINITION...........................................................................................................................................

91

EXECUTIVE SUMMARY..........................................................................................................................

91

Supporting Information................................................................................................................

94

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

DEFINITION.........................................................................................................................................

104

EXECUTIVE SUMMARY........................................................................................................................

104

Supporting Information..............................................................................................................

107

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

DEFINITIONS.......................................................................................................................................

115

EXECUTIVE SUMMARY........................................................................................................................

115

Supporting Information..............................................................................................................

119

ANNEX SIX -- Sub-Group
Report - gTLD Strings

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

DEFINITION.........................................................................................................................................

131

EXECUTIVE SUMMARY........................................................................................................................

131

Supporting Information..............................................................................................................

133

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

DEFINITIONS.......................................................................................................................................

146

EXECUTIVE
SUMMARY........................................................................................................................

146

Supporting Information..............................................................................................................

151

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

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

name="_Toc167705583">DEFINITIONS

name="_Toc25123613">

A Label

ASCII-compatible
(ACE) form of an IDNA-valid string. See href="http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt">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 href="http://www.wipo.int/amc/en/processes/process2/report/html/report.html">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 href="http://data.iana.org/TLD/tlds-alpha-by-domain.txt">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 style='mso-footnote-id:ftn1' href="#_ftn1" name="_ftnref1" title="">[1] and updated in RFC 1123 style='mso-footnote-id:ftn2' href="#_ftn2" name="_ftnref2" title="">[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 href="http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt">http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt. An example is 北京, the U-Label for
the Chinese word "Beijing".

name="_Toc167705584">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 Reportstyle='mso-footnote-id:ftn3' href="#_ftn3" name="_ftnref3" title="">[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 2007style='mso-footnote-id:ftn4' href="#_ftn4" name="_ftnref4" title="">[4] for consideration by the GNSO Council at its 12 April
2007 meetingstyle='mso-footnote-id:ftn5' href="#_ftn5" name="_ftnref5" title="">[5]. This Report will be used as further input into the style='mso-bidi-font-style:normal'>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.

style='page-break-before:always'>

name="_Toc167705585">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 reportstyle='mso-footnote-id:ftn6' href="#_ftn6" name="_ftnref6" title="">[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 Tasksstyle='mso-bidi-font-style:normal'>

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

style='mso-bidi-font-style:normal'>                                                                                                           
ii.     
Controversial
names

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

style='mso-bidi-font-style:normal'>                                                                                                             
i.     
Three
character names at the third level

style='mso-bidi-font-style:normal'>                                                                                                           
ii.     
Registry
specific names at the second level

style='mso-bidi-font-style:normal'>                                                                                                         
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

style='mso-bidi-font-style:normal'>                                                                                                             
i.     
Maintain
status quo for now regarding ASCII names

style='mso-bidi-font-style:normal'>                                                                                                           
ii.     
Confirm that
these names are already reserved at the third level for .name and .pro and edit
the document accordingly

style='mso-bidi-font-style:normal'>                                                                                                         
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

style='mso-bidi-font-style:normal'>                                                                                                         
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

style='mso-bidi-font-style:normal'>                                                                                                             
i.     
Provide
examples as possible

style='mso-bidi-font-style:normal'>                                                                                                           
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

style='mso-bidi-font-style:normal'>                                                                                                             
i.     
Provide
examples as possible for both the top and second levels, ASCII and IDN, single
and two-character

style='mso-bidi-font-style:normal'>                                                                                                           
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

style='mso-bidi-font-style:normal'>                                                                                                             
i.     
To ensure
clarity, change all occurrences of 'in the third and fourth character
positions' to 'in both the third and fourth character positions'

style='mso-bidi-font-style:normal'>                                                                                                           
ii.     
Move
recommendation 2 for IDN gTLDs from ASCII, top level to IDN top level

style='mso-bidi-font-style:normal'>                                                                                                         
iii.     
In
recommendation 2 for IDN gTLDs, change wording
to use the terms 'ASCII compatible encoding' and 'Unicode display form'

style='mso-bidi-font-style:normal'>                                                                                                         
iv.     
Provide
examples, including an example of what new applicants for an IDN gTLD would
have to provide

style='mso-bidi-font-style:normal'>                                                                                                           
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

style='mso-bidi-font-style:normal'>                                                                                                             
i.     
Provide
examples

style='mso-bidi-font-style:normal'>                                                                                                           
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

style='mso-bidi-font-style:normal'>                                                                                                             
i.     
Describe
process flow

style='mso-bidi-font-style:normal'>                                                                                                           
ii.     
Provide
examples as possible

style='mso-bidi-font-style:normal'>                                                                                                         
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 2^nd (or 3^rd 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

style='mso-bidi-font-style:normal'>                                                                                                             
i.     
Provide
examples

style='mso-bidi-font-style:normal'>                                                                                                           
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. style='mso-bidi-font-style:normal'>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

style='mso-bidi-font-style:normal'>                                                                                                             
i.     
Describe
process flow

style='mso-bidi-font-style:normal'>                                                                                                           
ii.     
Provide
examples as possible

style='mso-bidi-font-style:normal'>                                                                                                         
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
href="http://gnso.icann.org/calendar/#May">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

2^nd (and 3^rd
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

2^nd 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

2^nd level

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

All 16 gTLDs (with some exceptions
for certain gTLDs)

Tagged

2^nd (and 3^rd
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

2^nd level

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

All 16 gTLDs

Geographic & Geopolitical

2^nd (and 3^rd
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

3^rd level

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

.pro and .name

Other 2^nd Level

2^nd level

See the section titled 'Other
names reserved at the 2^nd 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 2^nd Level

See the section titled 'Other names reserved at the 2^nd 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 style='mso-bidi-font-style:normal'>Final Report on the Introduction of New Top-Level Domains.

name="_Toc167705588">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

2^nd & 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. style='mso-footnote-id:ftn7' href="#_ftn7" name="_ftnref7" title="">[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. style='mso-footnote-id:ftn8' href="#_ftn8" name="_ftnref8" title="">[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

2^nd 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. style='mso-footnote-id:ftn9' href="#_ftn9" name="_ftnref9" title="">[9]

Examples include .AU, .DE, .UK.

Two

11

Any combination of Two Letters,
Digits

2^nd Level

Registries may propose release provided that measures to avoid
confusion with any corresponding country codes are implemented. style='mso-footnote-id:ftn10' href="#_ftn10" name="_ftnref10" title="">[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. style='mso-footnote-id:ftn11' href="#_ftn11" name="_ftnref11" title="">[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") style='mso-footnote-id:ftn12' href="#_ftn12" name="_ftnref12" title="">[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

2^nd Level ASCII

The current reservation requirement be reworded to say, " style='mso-bidi-font-style:normal'>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 (2^nd) level. style='mso-footnote-id:ftn13' href="#_ftn13" name="_ftnref13" title="">[13] - added words in style='mso-bidi-font-style:normal'>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

3^rd 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 (3^rd level) for gTLD registries
that register names at the third level." style='mso-footnote-id:ftn14' href="#_ftn14" name="_ftnref14" title="">[14] - added words in style='mso-bidi-font-style:normal'>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 style='mso-footnote-id:ftn15' href="#_ftn15" name="_ftnref15" title="">[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. style='mso-footnote-id:ftn16' href="#_ftn16" name="_ftnref16" title="">[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.

name="_Toc167705589">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
registriestitle="">[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 categorieshref="#_ftn18" name="_ftnref18" title="">[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
style='mso-special-character:line-break'>

·          
There are
currently two gTLDs that expressly reserve names at the third level, .pro and
.name. Appendix L to the registry
agreements for .pro (href="http://www.icann.org/tlds/agreements/pro/registry-agmt-appl-30sep04.htm">http://www.icann.org/tlds/agreements/pro/registry-agmt-appl-30sep04.htm ) and .name (href="http://www.icann.org/tlds/agreements/name/registry-agmt-appl-8aug03.htm">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.
style='mso-special-character:line-break'>

·          
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 (href="http://www.icann.org/tlds/agreements/biz/appendix-06-08dec06.htm">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 (href="http://www.icann.org/tlds/agreements/info/appendix-06-08dec06.htm">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 href="http://www.icann.org/tlds/agreements/coop/sponsorship-agmt-att13-28oct0…">http://www.icann.org/tlds/agreements/coop/sponsorship-agmt-att13-28oct0…. .jobs
reserves non-ICANN names per Schedule S of its agreement at href="http://www.icann.org/tlds/agreements/jobs/appendix-S-05may05.htm">http://www.icann.org/tlds/agreements/jobs/appendix-S-05may05.htm. .mobi reserves Premium Names as referenced in
Appendix S of its Agreement at href="http://pc.mtld.mobi/documents/Premium_Name_List_16Jan07.pdf">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 href="http://www.icann.org/tlds/agreements/name/registry-agmt-appk-8aug03.htm">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 href="http://www.icann.org/tlds/agreements/travel/">http://www.icann.org/tlds/agreements/travel/.
style='mso-special-character:line-break'>

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

style='page-break-before:always'>

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 taskshref="#_ftn19" name="_ftnref19" title="">[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.

style='page-break-before:always'>

SECTION
FIVE - REFERENCE MATERIAL

GNSO
Working Group Original Report:

href="http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf">http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf

Previous
subgroup reports:

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

IDN Guidelines:

href="http://www.icann.org/announcements/announcement-2-11may07.htm">http://www.icann.org/announcements/announcement-2-11may07.htm

GAC Public Policy Principles:

href="http://gac.icann.org/web/home/gTLD_principles.pdf">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.

style='mso-special-character:line-break;page-break-before:always'>

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

2^nd & 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

title="http://forum.icann.org/lists/gnso-rn-wg/msg00169.html">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."

style='page-break-before:always'>

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

style='page-break-before:always'>

Table 2:
IANA-Related Names

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

style='page-break-before:always'>

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

clear=all style='page-break-before:always'>

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".

clear=all style='page-break-before:always'>

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. style='mso-footnote-id:ftn20' href="#_ftn20" name="_ftnref20" title="">[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. style='mso-footnote-id:ftn21' href="#_ftn21" name="_ftnref21" title="">[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

2^nd 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. href="#_ftn22" name="_ftnref22" title="">[22]

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

Recommendation task 3(b)

Any combination of
Two Letters, Digits

2^nd Level

Registries may propose
release provided that measures to avoid confusion with any corresponding
country codes are implemented. name="_ftnref23" title="">[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.

clear=all style='page-break-before:always'>

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.style='mso-footnote-id:ftn24' href="#_ftn24" name="_ftnref24" title="">[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, href="http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf">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, href="http://gac.icann.org/web/home/gTLD_principles.pdf">http://gac.icann.org/web/home/gTLD_principles.pdf,
the GNSO IDN Working Group Outcomes Report, href="http://gnso.icann.org/drafts/idn-wg-fr-22mar07.htm">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."style='mso-footnote-id:ftn26' href="#_ftn26" name="_ftnref26" title="">[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.

href="http://中国.icom.museum/">http://中国.icom.museum directs
visitors to http://china.icom.museum/.

href="http://한국.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 (href="http://www.icann.org/minutes/minutes-27mar03.htm">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 (href="http://www.icann.org/minutes/minutes-08dec06.htm">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, href="http://forum.icann.org/lists/gnso-sl-wg/msg00019.html">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 (href="http://www.icann.org/meetings/lisbon/agenda-idn-wg-28mar07.htm">http://www.icann.org/meetings/lisbon/agenda-idn-wg-28mar07.htm).
A transcript from the workshop is available at href="http://www.icann.org/meetings/lisbon/transcript-idn-wg-28mar07.htm">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.name="_ftnref28" title="">[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 href="http://en.wikipedia.org/wiki/Cary_Karp">Cary Karp and href="http://en.wikipedia.org/wiki/Ram_Mohan">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 href="http://www.evertype.com/misc/bio.html">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."name="_ftnref29" title="">[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:

     style='mso-bidi-font-style:normal'>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 style='mso-bidi-font-style:normal'>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 href="http://www.wipo.int/amc/en/processes/process2/report/html/report.html">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 (href="http://www.icann.org/minutes/resolutions-25may04.htm">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 (href="http://www.icann.org/minutes/prelim-report-16jan07.htm)">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 (href="http://www.icann.org/minutes/resolutions-08nov05.htm">http://www.icann.org/minutes/resolutions-08nov05.htm)
and implemented 25 July 2006 (href="http://www.icann.org/announcements/rsep-advisory-25jul06.htm">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 (href="http://forum.icann.org/lists/gnso-rn-wg/msg00039.html)">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 (href="http://forum.icann.org/lists/gnso-rn-wg/msg00041.html">http://forum.icann.org/lists/gnso-rn-wg/msg00041.html
and href="http://forum.icann.org/lists/gnso-rn-wg/msg00042.html">http://forum.icann.org/lists/gnso-rn-wg/msg00042.html).
.

3.
Correspondence:

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

·       
8 March 2007 email from Roberto Gaetano to GA list on
single-letter names (href="http://gnso.icann.org/mailing-lists/archives/ga/msg06100.html">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 (href="http://forum.icann.org/lists/gnso-rn-wg/msg00275.html)">http://forum.icann.org/lists/gnso-rn-wg/msg00275.html)

·       
20 January 2007 email from John Klensin on single-letter
names to GNSO Council (href="http://gnso.icann.org/mailing-lists/archives/council/msg03166.html)">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 (href="http://gnso.icann.org/mailing-lists/archives/council/msg03165.html">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 (href="http://gnso.icann.org/mailing-lists/archives/council/msg03164.html">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 (href="http://www.icann.org/correspondence/warren-to-board-28nov06.pdf">http://www.icann.org/correspondence/warren-to-board-28nov06.pdf).

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

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

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

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

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

·       
GNR Proposal: href="http://www.icann.org/registries/rsep/GNR_Proposal.pdf">http://www.icann.org/registries/rsep/GNR_Proposal.pdf

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

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

·       
RSTEP Report on GNR Two-character name proposal
(href="http://www.icann.org/registries/rsep/RSTEP-GNR-proposal-review-team-rep…">http://www.icann.org/registries/rsep/RSTEP-GNR-proposal-review-team-rep…).

·       
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: href="http://www.icann.org/minutes/resolutions-25may04.htm">http://www.icann.org/minutes/resolutions-25may04.htm.

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

·       
30 Aug 2001 Letter from ISO 3166/MA to Louis Touton &
Paul Twomey: href="http://www.icann.org/tlds/wischhoefer-to-touton-30aug01.htm">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: href="http://forum.icann.org/lists/gnso-rn-wg/msg00163.html">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), href="http://www.wipo.int/amc/en/processes/process2/report/html/report.html">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, href="http://www.icann.org/meetings/lisbon/transcript-gnso-new-gtlds-24mar07…">http://www.icann.org/meetings/lisbon/transcript-gnso-new-gtlds-24mar07….

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

14.
RFCs & BCPs

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

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

RFC 1032, href="ftp://ftp.rfc-editor.org/in-notes/pdfrfc/rfc1032.txt.pdf">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

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.

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

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.

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.

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

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.

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 goodsis 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

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.

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.txtfor 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.txtcould 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.txtfor 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

9. ICANN Registry Services Technical Evaluation Panel http://www.icann.org/registries/rsep/RSTEP-GNR-proposal-review-team-report.pdf

10. 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

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.

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.

* 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

* 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