name="_Toc118169792">
name="_Toc118102443">
name="_Toc118093959">
name="_Toc118087504">GNSO new TLDs
Committee

Draft Final Report

Introduction of New Generic Top-Level Domains

Table of Contents

name="_Toc118169794">

4 GLOSSARY & DEFINITIONS

7 EXECUTIVE SUMMARY

10 PRINCIPLES

12 RECOMMENDATIONS

16 IMPLEMENTATION GUIDELINES

20 TERM OF REFERENCE ONE ? DISCUSSION

23 TERM OF REFERENCE TWO -- DISCUSSION

34 TERM OF REFERENCE THREE -- DISCUSSION

37 TERM OF REFERENCE FOUR -- DISCUSSION

40 ANNEX ONE -- POLICY DEVELOPMENT PROCESS INFORMATION

46 ANNEX TWO -- PARTICIPATION TABLE

49 ANNEX THREE -- REFERENCE MATERIALS

GLOSSARY & DEFINITIONS
name="_Toc25123613">

style='border-collapse:collapse;border:none'>

Commercial & Business Users Constituency

CBUC

http://www.bizconst.org/

Consensus Policy

A defined term in all ICANN registry contracts
usually found in Article 3 (Covenants).

See, for example,
href="http://www.icann.org/tlds/agreements/biz/registry-agmt-08dec06.htm">http://www.icann.org/tlds/agreements/biz/registry-agmt-08dec06.htm

Country Code Names Supporting Organization

ccNSO

http://ccnso.icann.org/

Domain Names

The term domain name has
multiple related meanings: A name that identifies a computer or computers on
the internet. These names appear as a component of a
href="http://en.wikipedia.org/wiki/Web_site">Web site's URL, e.g. www.wikipedia.org. This
type of domain name is also called a hostname.

The product that
href="http://en.wikipedia.org/wiki/Domain_name_registrar">Domain name
registrars

provide to their customers. These names are often called registered domain
names.

Names used for other purposes in the
href="http://en.wikipedia.org/wiki/Domain_Name_System">Domain Name
System (DNS), for example
the special name which follows the @ sign in an
href="http://en.wikipedia.org/wiki/Email">email address, or the Top-level
domains like .com, or the
names used by the
href="http://en.wikipedia.org/wiki/Session_Initiation_Protocol">Session
Initiation Protocol (
href="http://en.wikipedia.org/wiki/VoIP">VoIP), or DomainKeys.

http://en.wikipedia.org/wiki/Domain_names

Domain Name System

On the Internet, the domain name system (DNS) stores
and associates many types of information with
href="http://en.wikipedia.org/wiki/Domain_name">domain names; most importantly, it translates domain names
(computer
href="http://en.wikipedia.org/wiki/Hostname">hostnames) to IP addresses. It also lists
href="http://en.wikipedia.org/wiki/Mail_exchange_server">mail exchange
servers accepting
href="http://en.wikipedia.org/wiki/E-mail">e-mail for each domain. In providing a worldwide
href="http://en.wikipedia.org/wiki/Keyword">keyword-based redirection service, DNS is an essential
component of contemporary Internet use.

http://en.wikipedia.org/wiki/Domain_name_system

Governmental Advisory Committee

GAC

http://gac.icann.org/web/index.shtml http://gac.icann.org/web/index.shtml

Intellectual Property Constituency

IPC

http://www.ipconstituency.org/

Internet Service & Connection Providers
Constituency

ISPCP

 

Internationalized Domain Names Working Group

IDN-WG

Nominating Committee

NomCom

Non-Commercial Users Constituency

NCUC

http://www.ncdnhc.org/

Policy Development Process

PDP

See
href="http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#AnnexA">http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#AnnexA

Protecting the Rights of Others Working Group

PRO-WG

See the mailing list archive at http://forum.icann.org/lists/gnso-pro-wg/

Registrar Constituency

RC

http://www.icann-registrars.org/

Registry Constituency

RyC

http://www.gtldregistries.org/

Request for Comment

A full list of all Requests for Comment
href="http://www.rfc-editor.org/rfcxx00.html">http://www.rfc-editor.org/rfcxx00.html

Specific references used in this report are shown in
the next column.

This document uses language, for example, ?should?,
?must? and ?may?, consistent with RFC2119.

RFC

href="ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt">ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt

href="ftp://ftp.rfc-editor.org/in-notes/rfc2606.txt">ftp://ftp.rfc-editor.org/in-notes/rfc2606.txt

Reserved Names

All ICANN?s registry agreements have Reserved Names
provisions. See, for example, the .aero agreement
href="http://www.icann.org/tlds/agreements/sponsored/sponsorship-agmt-att11-2…">http://www.icann.org/tlds/agreements/sponsored/sponsorship-agmt-att11-2…

Reserved Names Working Group

RN-WG

See the mailing list archive at http://forum.icann.org/lists/gnso-rn-wg/

Root server

A root nameserver is a
href="http://en.wikipedia.org/wiki/Domain_Name_System">DNS server that answers requests for
the root namespace domain, and redirects requests for a particular
href="http://en.wikipedia.org/wiki/Top-level_domain">top-level domain to that TLD's nameservers.
Although any local implementation of DNS can implement its own private root
nameservers, the term "root nameserver" is generally used to
describe the thirteen well-known root nameservers that implement the root
namespace domain for the Internet's official global implementation
of the Domain Name System.

All domain names on the Internet can be regarded as ending in a
href="http://en.wikipedia.org/wiki/Full_stop">full stop character e.g. "en.wikipedia.org.". This
final dot is generally implied rather than explicit, as modern DNS software
does not actually require that the final dot be included when attempting to
translate a domain name to an
href="http://en.wikipedia.org/wiki/Internet_Protocol">IP address. The empty
href="http://en.wikipedia.org/wiki/String_%28computer_science%29">string after the final dot is called the
href="http://en.wikipedia.org/wiki/DNS_root_zone">root domain, and all other domains (i.e. .com, .org, .net,
etc.) are contained within the root domain. http://en.wikipedia.org/wiki/Root_server

EXECUTIVE SUMMARY

1.     
The section
sets out the principles
style='mso-footnote-id:ftn1' href="#_ftn1" name="_ftnref1" title="">[1], policy recommendations and implementation guidelines
the GNSO Council?s Committee on the introduction of new top-level domains has
developed through its policy development process. The development of all elements of the
Committee?s work has been done in close consultation with an ICANN staff team
who have provided advice on policy, operational and legal matters for the
Committee. This version of the draft
style='mso-bidi-font-style:normal'>Final Report reflects the updated work
of the Committee at its 23 & 24 February 2007 Los Angeles meetings
style='mso-footnote-id:ftn2' href="#_ftn2" name="_ftnref2" title="">[2].

style='mso-special-character:line-break'>




2.     

The
style='mso-bidi-font-style:normal'>Report is now structured around four
main areas. This includes an explanation
of the principles that have guided the work; a comprehensive set of draft
recommendations which have majority Committee support; a set of implementation
guidelines and a detailed record of the Committee?s work which can be found in
Annexes One and Two of the Report. Annex Three is a list of reference
material on which the Committee have relied.

3.     

The Committee
is expected to discuss its recommendations in a public forum at the 26 ? 30
March 2007 ICANN meeting in Lisbon, Portugal.
At the same time, a number of face-to-face consultations will take place
with a variety of organisations and working groups including the Governmental
Advisory Committee (GAC), the Country Code Names Supporting Organization
(ccNSO), the Internationalised Names Working Group (IDN-WG), the Reserved Names
Working Group (RN-WG) and the Protecting the Rights of Others Working Group
(PRO-WG).

4.     
The major
changes captured in this version of the Report are to re-emphasise the Committee?s key
principles that reflect ICANN?s Mission and Core Values; clarification of the
Committee?s draft policy recommendations and the further explanation of the
Committee?s implementation guidelines which are designed to assist ICANN staff
to implement the policy recommendations in a transparent and cohesive manner.

5.     

The
style='mso-bidi-font-style:normal'>Report sets out the key findings from a
multi-phase, multi-stakeholder policy development process that has taken place
during 2006 and which will continue through 2007. The Committee has been guided by the GNSO?s
policy development process requirements which are part of ICANN?s ByLaws
style='mso-footnote-id:ftn3' href="#_ftn3" name="_ftnref3" title="">

[3]

.

6.     

In each of the
sections below the Committee?s recommendations are discussed in more detail
with an explanation of the rationale for the decisions. The recommendations have been the subject of numerous public comment periods and
intensive discussion across a range of stakeholders including ICANN?s GNSO
Constituencies, ICANN Supporting Organisations and Advisory Committees and
members of the broader Internet-using public that is interested in ICANN?s work
style='mso-footnote-id:ftn4' href="#_ftn4" name="_ftnref4" title="">

[4]

. In
particular, detailed work has been conducted through the Internationalised
Domain Names Working Group (IDN-WG)
style='mso-footnote-id:ftn5' href="#_ftn5" name="_ftnref5" title="">

[5]

and the Reserved Names Working Group (RN-WG)
style='mso-footnote-id:ftn6' href="#_ftn6" name="_ftnref6" title="">

[6]

to comprehensively examine important elements of new
TLDs. A working group to examine the
protection of the rights of others (PRO-WG) has been formed and work has begun
on its Statement of Work
style='mso-footnote-id:ftn7' href="#_ftn7" name="_ftnref7" title="">

[7]

.

7.     

The GNSO
Committee has conducted five separate face-to-face consultations, in Washington
DC, Wellington, Brussels, Amsterdam and Los Angeles to discuss each of the
Terms of Reference in the context of ICANN?s Bylaws, Mission and Core Values.

name="_Toc35657633">PRINCIPLES

1.     
This set of
principles relates to the introduction of new top-level domains. The full listing of existing top-level
domains, for example, .com, .org and .info, can be found on ICANN?s website
style='mso-footnote-id:ftn8' href="#_ftn8" name="_ftnref8" title="">[8]. There are
also two letter country code top-level domains such as .de, .cc and .at
style='mso-footnote-id:ftn9' href="#_ftn9" name="_ftnref9" title="">[9]. The addition
of new gTLDs will be done in accordance with ICANN?s primary mission which is
to ensure the security and stability of the Domain Name System (DNS) and, in
particular, the Internet?s root server system
style='mso-footnote-id:ftn10' href="#_ftn10" name="_ftnref10" title="">[10].

2.     
The principles
are a combination of Committee priorities and ICANN staff implementation
principles which have been developed in tandem with the Committee
style='mso-footnote-id:ftn11' href="#_ftn11" name="_ftnref11" title="">[11].

style='border-collapse:collapse;mso-border-alt:solid windowtext .5pt;
mso-yfti-tbllook:191;mso-padding-alt:0pt 5.4pt 0pt 5.4pt;mso-border-insideh:
.5pt solid windowtext;mso-border-insidev:.5pt solid windowtext'>

Principle 1

New generic top-level domains (gTLDs)
must be introduced in an orderly, timely and predictable way.

Principle 2

Some new generic top-level domains may be internationalised domain
names (IDNs) subject to the approval of IDNs being available in the root.
style='mso-footnote-id:ftn12' href="#_ftn12" name="_ftnref12" title="">[12]

Principle 3

The reasons for introducing new top-level domains include that there
is demand from potential applicants for new top-level domains in both ASCII
and IDN formats and that the new TLD process promotes
competition, consumer choice and geographical and service-provider diversity.

Principle 4

A set of technical criteria must be used for assessing a new gTLD
registry applicant to minimise the risk of harming the operational stability,
security and global interoperability of the Internet.

Principle 5

A set of capability criteria for a new gTLD registry applicant must be
used to provide an assurance that an applicant has the capability to meets
its obligations under the terms of ICANN?s registry agreement.

Principle 6

A set of
operational criteria must be set out in contractual conditions in the
registry agreement to ensure compliance with ICANN policies.

Table 0‑1: new gTLDs
principles

name="_Toc35657634">RECOMMENDATIONS
style='mso-footnote-id:ftn13' href="#_ftn13" name="_ftnref13" title="">

[13]

1.     
This set of
recommendations is the result of widespread consultation with a variety of
interested stakeholders, ICANN Supporting Organizations and interested
observers. A full record of the
Committee?s work can be found on the GNSO?s website
style='mso-footnote-id:ftn14' href="#_ftn14" name="_ftnref14" title="">[14].

2.     
The
recommendations have majority support from a range of GNSO Committee
representatives and have been subjected to detailed discussion through a series
of ICANN meetings in addition to five face-to-face meetings of the
Committee. In addition, detailed
meetings have taken place between Committee members and ICANN staff on a wide
range of implementation issues. The sections
below relating to each Term of Reference show how the Committee has reached its
decisions.

style='border-collapse:collapse;mso-border-alt:solid windowtext .5pt;
mso-yfti-tbllook:191;mso-padding-alt:0pt 5.4pt 0pt 5.4pt;mso-border-insideh:
.5pt solid windowtext;mso-border-insidev:.5pt solid windowtext'>

Recommendation 1

ICANN must implement a process that
allows the introduction of new top-level domains.

Recommendation 2

Strings must not be confusingly similar
style='mso-footnote-id:ftn15' href="#_ftn15" name="_ftnref15" title="">[15] to an existing top-level
domain.

Recommendation 3

Strings must not infringe the existing legal rights of others that are
recognized or enforceable under generally accepted and internationally
recognized principles of law.

Recommendation 4

Strings must not cause any technical instability.

Recommendation 5

Strings must not be a Reserved Word.

Recommendation 6

Strings must not be contrary to
generally accepted legal norms relating to morality and public order.

Recommendation 7

Applicants must be able to demonstrate
their technical capability to run a registry operation.

Recommendation 8

Applicants must be able to demonstrate their financial and
organisational operational capability.

Recommendation 9

There must be a clear and pre-published
application process using objective and measurable criteria.

Recommendation 10

There must be a base contract provided
to applicants at the beginning of the application process.

Recommendation 11

Staff Evaluators will be used to make
preliminary determinations about applications as part of a process which
includes the use of expert panels to make decisions.

Recommendation 12

Dispute resolution and challenge
processes must be established prior to the start of the process.

Recommendation 13

Applications must initially be assessed
in rounds until the scale of demand is clear and there is a reduction to zero
of applications for the same string.

Recommendation 14A

If there is contention for strings,
applicants may:

i)                   
resolve contention between them within
a pre-established timeframe

ii)                 
if there is no mutual agreement, a
process will be put in place to enable efficient resolution of contention
and;

iii)               
the ICANN Board may be used to make a
final decision, using advice from staff and expert panels.

Recommendation 14B

Where an applicant lays any claim that
the TLD is intended to support a particular community such as a sponsored
TLD, or any other TLD intended for a specified community, that claim will be
taken on trust with the following exception:

i)                   
the claim relates to a string that is
also subject to another application and the claim to support a community is
being used to gain priority for the application

Under this exception, Staff
Evaluators will devise criteria and procedures to investigate the claim.

Recommendation 14C

An application will be rejected or
otherwise deferred if it is determined, based on public comments or
otherwise, that there is substantial opposition to it from among significant
established institutions of the economic sector, or cultural or language
community, to which it is targeted or which it is intended to support. Staff Evaluators will develop criteria and
procedures for making this determination.

Recommendation 15

The initial registry agreement term
must be of a commercially reasonable length.

Recommendation 16

There must be renewal expectancy.

Recommendation 17

Registries must apply existing
Consensus Policies
style='mso-footnote-id:ftn16' href="#_ftn16" name="_ftnref16" title="">[16] and
adopt new Consensus Polices as they are approved.

Recommendation 18

A clear compliance and sanctions
process must be set out in the base contract which could lead to contract
termination.

Recommendation 19

If an
applicant offers an IDN service, then ICANN?s IDN guidelines
style='mso-footnote-id:ftn17' href="#_ftn17" name="_ftnref17" title="">[17] must be
followed.

Recommendation 20

Registries
must use ICANN accredited registrars.

Table 0-1: new gTLDs recommendations

name="_Toc35657635">IMPLEMENTATION GUIDELINES

1.     

This set of
implementation guidelines is the result of detailed discussion, particularly
with respect to the ICANN Staff
Discussion Points
style='mso-footnote-id:ftn18' href="#_ftn18" name="_ftnref18" title="">

[18]

document which was prepared to facilitate
consultation with the GNSO Committee prior to the 2006 Sao Paulo meeting and
used again at the February 2007 Los Angeles meeting.

2.     
Since that
meeting, the ICANN staff has met weekly to discuss ongoing implementation
planning and have had further consultations with members of the Committee. Many additional implementation comments were
received from the Committee and observers at the Los Angeles meeting. These have been incorporated into a list of
questions for the implementation team

3.     

The draft
Implementation Flowchart was developed through discussion at the Los Angeles
meeting and as part of the ongoing internal implementation discussions which
have focused on ensuring that draft recommendations proposed by the Committee
are implementable in an efficient and transparent manner
style='mso-footnote-id:ftn19' href="#_ftn19" name="_ftnref19" title="">

[19]

.

style='border-collapse:collapse;mso-border-alt:solid windowtext .5pt;
mso-yfti-tbllook:191;mso-padding-alt:0pt 5.4pt 0pt 5.4pt;mso-border-insideh:
.5pt solid windowtext;mso-border-insidev:.5pt solid windowtext'>

Implementation Guideline 1

The application process will provide a pre-defined roadmap for
applicants that encourages the submission of
applications for new top-level domains.

Implementation Guideline 2

Application
fees will be designed to ensure that adequate resources exist to cover the
total cost to administer the new gTLD process.

Application
fees may differ for applicants.

Implementation Guideline 3

ICANN will provide frequent
communications with applicants and the public including comment forums which
will be used to inform evaluation panels.

Implementation Guideline 4

A first
come first served processing schedule within the application round will be
implemented and will continue for an ongoing process, if necessary.

Applications
will be time and date stamped on receipt.

Implementation Guideline 5

The
application submission date will be at least four months after the issue of
the Request for Proposal and ICANN will promote the opening of the
application round.

Implementation Guideline 6

ICANN will provide for the ability to settle
conflicts between applicants (such as string contention) at any time. A defined mechanism and a certain period
for resolution of identified conflicts will be provided.

Implementation Guideline 7

Evaluation panels established by ICANN
will be used to make decisions relating to technical criteria consistent with
ICANN's mission.

Implementation Guideline 8

External dispute providers will give
decisions on complaints.

Implementation Guideline 9

An
applicant granted a TLD string must use it within an appropriate timeframe.

Implementation Guideline 10

The base
contract should balance market certainty and flexibility for ICANN to
accommodate a rapidly changing market place.

Implementation Guideline 11

ICANN
should take a consistent approach to the establishment of registry fees.

>

Implementation Guideline 12

The use of personal data is limited to the purpose
for which it is collected.

>

Implementation Guideline 12B

Procedures related to Recommendations 14B and 14C
could be based on ICANN?s existing procedures to examine sponsored TLD
applications.

Implementation Guideline 13

(NCUC suggestions)

ICANN may establish a capacity
building and support mechanism aiming at facilitating effective communication
on important and technical Internet governance functions in a way which no
longer requires all participants in the conversation to be able to read and
write English.

ICANN may put in place a fee
reduction scheme for gTLD applicants from developing economies, and make the
financial and the operational threshold for market entry easier for those
from less developed economies.

ICANN may put in place systems that could provide information about
the gTLD process

in major languages other than English, for example, in the six working languages of the United Nations.

Table 0‑1: new gTLDs
implementation guidelines

name="_Toc35657636">
name="_Toc35656275">
name="_Toc35511694">src="pdp-dec05-fr-160307_files/image003.gif" v:shapes="_x0000_i1026">

Table

0

‑

1

: DRAFT new TLDs
Implementation Plan

name="_Toc35657637">TERM OF
REFERENCE ONE ? DISCUSSION

1.     

The
GNSO Committee on new top-level domains was asked to answer the question of
whether to introduce new top-level domains.
The Committee recommends that ICANN should implement a process that
allows the introduction of new top level domains and that work should proceed to develop policies that will enable the introduction
of new generic top-level domains, taking into account the recommendations found
in the latter sections of the Report concerning Selection Criteria (Term of
Reference 2), Allocation Methods (Term of Reference 3) and Policies for
Contractual Conditions (Term of Reference 4).

2.     
ICANN?s work on the introduction of
new top-level domains has been ongoing since 1999. The early work included the 2000 Working
Group C Report
style='mso-footnote-id:ftn20' href="#_ftn20" name="_ftnref20" title="">[20] that also asked the question of ?whether there should be new
TLDs?. By mid-1999, the Working Group
had quickly reached consensus on two issues, namely that ??ICANN should add new gTLDs to the root. The second is that ICANN should begin the
deployment of new gTLDs with an initial rollout of six to ten new gTLDs,
followed by an evaluation period?. This
work was undertaken throughout 2000 and saw the introduction of, for example,
.coop, .aero and .biz.

3.     
After an evaluation period, a further
round of sponsored TLDs was introduced during 2003 and 2004 which included,
amongst others, .mobi and .travel.

4.     
In addressing Term of Reference One,
the Committee arrived at its recommendation by reviewing and analysing a wide
variety of materials including Working Group C?s findings; the evaluation
reports from the 2003 & 2004 round of sponsored top-level domains and full
range of other historic materials which are posted at
href="http://gnso.icann.org/issues/new-gtlds/">http://gnso.icann.org/issues/new-gtlds//

5.     
In addition, the Committee considered
the responses to a Call for Expert Papers which was issued at the beginning of
the policy development process
style='mso-footnote-id:ftn21' href="#_ftn21" name="_ftnref21" title="">[21]. These papers augmented a full
set of GNSO Constituency Statements
style='mso-footnote-id:ftn22' href="#_ftn22" name="_ftnref22" title="">[22].

6.     
The Committee was asked, at its
February 2007 Los Angeles meeting, to confirm its rationale for recommending
that ICANN introduce new top-level domains.
In summary, there are five threads which have emerged:

a.     
It is consistent with the reasons
articulated in 1999 when the first proof-of-concept round was initiated

b.     
There are no technical impediments to
the introduction of new top-level domains as evidenced by the two previous
rounds

c.     
Expanding the domain name space to
accommodate the introduction of both new ASC-II and internationalised domain
name (IDN) top-level domains will give end users more choice about the nature
of their presence on the Internet. In
addition, users will be able to communicate in their language of choice and in
a way which meets community needs.

d.     
There is evidence of demand for
additional top-level domains as a business opportunity. The opportunity for adding new top-level
domain names stimulates competition for both registry service providers and
registrars which is consistent with ICANN?s Core Value 6

e.     
No compelling reason has been
articulated to not proceed with accepting applications for new top-level
domains.

name="_Toc35657638">TERM OF
REFERENCE TWO -- DISCUSSION

1.     
The
Committee was asked to develop policy recommendations about string criteria for
new top-level domain applications. Three main elements have emerged in relation
to string criteria -- ?string? criteria, ?applicant? criteria and ?process?
criteria.

2.     
Recommendation 2 Discussion -- Strings must not be confusingly
similar[23] to an existing top-level domain
style='mso-footnote-id:ftn24' href="#_ftn24" name="_ftnref24" title="">[24].

i)       
The
Committee spent many hours on discussing the nature of confusingly similar to
determine if and how its current recommendation could be implemented. There were many diverging points of view;
many differing perspectives and many different interpretations.

ii)     
The
Committee looked in detail at the existing provisions of ICANN?s Registrar
Accreditation Agreement, particularly Section 3.7.7.9
style='mso-footnote-id:ftn25' href="#_ftn25" name="_ftnref25" title="">[25] which says that ??The
Registered Name Holder shall represent that, to the best of the Registered Name
Holder's knowledge and belief, neither the registration of the Registered Name
nor the manner in which it is directly or indirectly used infringes the legal
rights of any third party.?

iii)   
In addition, the concept of ?confusingly similar?
is used to mean that there is a likelihood of confusion on the part of the
relevant public
style='mso-footnote-id:ftn26' href="#_ftn26" name="_ftnref26" title="">[26].
In international trade mark law, confusion may be visual, phonetic or
conceptual. The Committee used a wide
variety of existing law to come to some agreement that strings should not be
confusingly similar either to existing top-level domains like .com and .net or to
existing trademark and famous names
style='mso-footnote-id:ftn27' href="#_ftn27" name="_ftnref27" title="">[27].

iv)   
In
broader international treaty, the concept of creating confusion is contained in
the 1883 Paris Convention and says ?to create confusion by any means whatever?
{Article 10bis (3) (1} and, further, being ?liable to mislead the public?
{Article 10bis (3) (3)}. The treatment
of confusingly similar is also contained in European Union law and is
structured as follows -- ?because of its
identity with or similarity to?there exists a likelihood of confusion on the
part of the public?; the likelihood of confusion includes the likelihood of
association?? {Article 4 (1) (b) of the 1988 EU Trade Mark directive
89/104/EEC}. Article 8 (1) (b) of the
1993 European Union Trade Mark regulation 40/94 is also relevant.

v)     
In
the United States, existing trade mark law states that ??to the best of the
verifier's knowledge and belief, no other person has the right to use such mark
in commerce either in the identical form thereof or in such near resemblance
thereto as to be likely, when used on or in connection with the goods of such
other person, to cause confusion, or to cause mistake, or to deceive?? which is
contained in Section 1051 (3) (d) of the US Trademark Act 2005 (found at
href="http://www.bitlaw.com/source/15usc/1051.html">http://www.bitlaw.com/source/15usc/1051.html.)

vi)   
In
Australia, the Australian Trade Marks Act 1995 Section 10 says that ??For the
purposes of this Act, a trade mark is taken to be deceptively similar to
another trade mark if it so nearly resembles that other trade mark that it is
likely to deceive or cause confusion? (found at
href="http://www.ipaustralia.gov.au/resources/legislation_index.shtml">http://www.ipaustralia.gov.au/resources/legislation_index.shtml)

vii) 
A
number of different trademark offices provide guidance on how to interpret
confusion. For example, the European
Union Trade Mark Office provides guidance on how to interpret confusion. ??confusion
may be visual, phonetic or conceptual. A
mere aural similarity may create a likelihood of confusion. A mere visual similarity may create a
likelihood of confusion. Confusion is
based on the fact that the relevant public does not tend to analyse a word in
detail but pays more attention to the distinctive and dominant components. Similarities are more significant than
dissimilarities. The visual comparison
is based on an analysis of the number and sequence of the letters, the number
of words and the structure of the signs.
Further particularities may be of relevance, such as the existence of
special letters or accents that may be perceived as an indication of a specific
language. For words, the visual
comparison coincides with the phonetic comparison unless in the relevant
language the word is not pronounced as it is written. It should be assumed that the relevant public
is either unfamiliar with that foreign language, or even if it understands the
meaning in that foreign language, will still tend to pronounce it in accordance
with the phonetic rules of their native language. The length of a name may influence the effect
of differences. The shorter a name, the more easily the public is able to
perceive all its single elements. Thus, small differences may frequently lead
in short words to a different overall impression. In contrast, the public is
less aware of differences between long names.
The overall phonetic impression is particularly influenced by the number
and sequence of syllables.? (found
at
href="http://oami.europa.eu/en/mark/marque/direc.htm">http://oami.europa.eu/en/mark/marque/direc.htm).

viii)An extract from the United Kingdom?s
Trade Mark Office?s Examiner?s Guidance Manual is useful in explaining further
the Committee?s approach to developing its Recommendation. ?For
likelihood of confusion to exist, it must be probable, not merely possible that
confusion will arise in the mind of the average consumer. Likelihood of
association is not an alternative to likelihood of confusion, ?but serves to
define its scope?. Mere association, in the sense that the later mark brings the
earlier mark to mind is insufficient to find a likelihood of confusion, unless
the average consumer, in bringing the earlier mark to mind, is led to expect
the goods or services of both marks to be under the control of one single trade
source. ?The risk that the public might believe that the goods/services in
question come from the same undertaking or, as the case may be, from
economically-linked undertakings, constitutes a likelihood of confusion??. (found at
href="http://www.patent.gov.uk/tm/t-decisionmaking/t-law/t-law-manual.htm">http://www.patent.gov.uk/tm/t-decisionmaking/t-law/t-law-manual.htm)

ix)   
The
proposed implementation plan deals with a comprehensive range of potentially
controversial (for whatever reason) string applications which balances the need
for reasonable protection of existing legal rights and the capacity to innovate
with new uses for top level domains that may be attractive to a wide range of
users[28].

3.     
Recommendation 3 Discussion -- Strings must not infringe
the existing legal rights of others that are recognized or enforceable under
generally accepted and internationally recognized principles of law
style='mso-footnote-id:ftn29' href="#_ftn29" name="_ftnref29" title="">[29].

                         
i.     
The
Committee engaged in comprehensive discussion about this recommendation and
took advice from a number of experts within the group
style='mso-footnote-id:ftn30' href="#_ftn30" name="_ftnref30" title="">[30].
The original text of the recommendation has been modified to recognised
that an applicant will be bound by the laws of the country where they are
located, and an applicant may be bound by another country that has jurisdiction
over them.

                       
ii.     
An
application may be rejected or deferred if it is determined, based on public
comments or otherwise, that there is substantial opposition to it from
significant established institutions of the economic sector, or cultural or
language community, to which it is targeted or which it is intended to
support. ICANN staff will develop
criteria and procedures for making this determination, which may be based upon
ICANN?s procedures which were used to examine the 2003 round of sponsored TLD
applications
style='mso-footnote-id:ftn31' href="#_ftn31" name="_ftnref31" title="">[31].

                     
iii.     
There
are a number of ways in which ICANN could approach the resolution of this type
of problem which includes the full range of ?ICANN saying nothing; ICANN
identifies a possible issue and ICANN files a complaint; ICANN identifies a
possible issue but relies on a complainant to file it formally; ICANN
identifies an issue, makes a decision and the applicant can appeal.?

                      
iv.     
The
final approach to this set of potentially controversial problems will be
resolved through ongoing discussions with members of the Committee and ICANN?s
implementation team.

4.     
Recommendation 4 Discussion ? Strings must not cause any
technical instability.

                         
i.     
It
was agreed by the Committee that the string should not cause any technical that threatened the stability and security of
the Internet. As the policy development
process proceeds, further detailed technical assistance will be sought from
both ICANN expert committees and advisors.

5.     
Recommendation 5 Discussion -- Strings must not be a Reserved
Word.[32]

                         
i.     
The
notion of Reserved Words has a specific meaning within the ICANN context. Each of the existing ICANN registry contracts
have provisions within them that govern the use of reserved words.

                       
ii.     
The
Reserved Names Working Group (RN-WG) Statement of Work was developed to enable
a small group to examine a wide variety of reserved names issues. The Group is due to report to the Committee
at the Lisbon meeting with a series of recommendations on the treatment of
reserved names for new top-level domains.

6.     
Recommendation 6 Discussion - Strings must not be contrary to generally
accepted legal norms relating to morality and public order.

                         
i.     
There was
detailed discussion about a general category of potential strings which may
have public policy impacts of interest to national governments. In response to correspondence from the GNSO
Council Chair, the Governmental Advisory Committee
style='mso-footnote-id:ftn33' href="#_ftn33" name="_ftnref33" title="">[33] has responded to a request to provide guidance
on public policy issues. It is expected
that these principles will be finalised shortly. After those guidelines are formalised, the
ICANN staff proposed implementation plan may be modified to take into account
ways to address the public policy concerns of governments in relation to the
introduction of new top level domains.

                       
ii.     
The
Committee spent considerable time considering the public policy aspects of new
top-level domains. In particular,
concerns about ?public policy and morality? were raised. This phrasing is consistent with
international laws including Article 3 (1) (f) of the 1988 European Union Trade
Mark Directive 89/104/EEC and within Article 7 (1) (f) of the 1993 European
Union Trade Mark Regulation 40/94. In
addition, the phrasing ?contrary to morality or public order and in particular
of such a nature as to deceive the public? comes from Article 6quinques (B)(3)
of the 1883 Paris Convention. The
reference to the Paris Convention remains relevant to domain names even though,
when it was drafted, domain names were completely unheard of.

                     
iii.     
The
concept of ?morality? is captured in Article 19 United Nations Convention on
Human Rights (
href="http://www.unhchr.ch/udhr/lang/eng.htm">http://www.unhchr.ch/udhr/lang/eng.htm) says ??Everyone has the right to
freedom of opinion and expression; this right includes freedom to hold opinions
without interference and to seek, receive and impart information and ideas
through any media and regardless of frontiers.?
Article 29 continues by saying that ??In the exercise of his rights and
freedoms, everyone shall be subject only to such limitations as are determined
by law solely for the purpose of securing due recognition and respect for the
rights and freedoms of others and of meeting the just requirements of morality,
public order and the general welfare in a democratic society?.

                      
iv.     
The
EU Trade Mark Office?s Examiner?s guidelines provides assistance on how to
interpret morality and deceit.
??Contrary to morality or public order. Words or images which are
offensive, such as swear words or racially derogatory images, or which are
blasphemous are not acceptable. There is a dividing line between this and words
which might be considered in poor taste. The latter do not offend against this
provision.? The further element is
deception of the public which is treated in the following way. ??Deceive the public. To deceive the public,
is for instance as to the nature, quality or geographical origin. For example,
a word may give rise to a real expectation of a particular locality which is
untrue.? For more information, see
Sections 8.7 and 8.8 at
href="http://oami.europa.eu/en/mark/marque/direc.htm">http://oami.europa.eu/en/mark/marque/direc.htm

                        
v.     
The
UK Trade Mark office provides similar guidance in its Examiner?s Guidance
Manual. ?Marks which offend fall broadly
into three types: those with criminal connotations, those with religious
connotations and explicit/taboo signs.
Marks offending public policy are likely to offend accepted principles
of morality, e.g. illegal drug terminology, although the question of public
policy may not arise against marks offending accepted principles of morality,
for example, taboo swear words. If a
mark is merely distasteful, an objection is unlikely to be justified, whereas
if it would cause outrage or would be likely significantly to undermine
religious, family or social values, then an objection will be appropriate. Offence may be caused on matters of race,
sex, religious belief or general matters of taste and decency. Care should be taken when words have a
religious significance and which may provoke greater offence than mere distaste,
or even outrage, if used to parody a religion or its values. Where a sign has a
very sacred status to members of a religion, mere use may be enough to cause
outrage.? For more information, see
href="http://www.patent.gov.uk/tm/t-decisionmaking/t-law/t-law-manual.htm">http://www.patent.gov.uk/tm/t-decisionmaking/t-law/t-law-manual.htm)

                      
vi.     
In
summary, the development of selection
criteria for new top-level domains has been the subject of intense discussion
throughout the Committee?s work. This
work will be clarified further when the GAC public policy principles are
completed.

7.     
Recommendation 7 Discussion -
Applicants must be able to demonstrate their technical capability to run
a registry operation.

                         
i.     
The
Committee agreed that the technical requirements for applicants would include
compliance with a minimum set of technical standards and that this requirement
would be part of the new registry operator?s contractual conditions included in
the proposed base contract. The more
detailed discussion about technical requirements has been moved to the
contractual conditions section.

                       
ii.     
Reference
was made numerous Requests for Comment (RFCs) and other technical standards
which apply to existing registry operators.
For example, Appendix 7 of the June 2005 .net agreement
style='mso-footnote-id:ftn34' href="#_ftn34" name="_ftnref34" title="">[34] provides a comprehensive listing of
technical requirements in addition to other technical specifications in other
parts of the agreement. These
requirements are consistent with that which is expected of all current registry
operators. These standards would form
the basis of any new top-level domain operator requirements.

8.      Recommendation 8 Discussion - Applicants must be able to
demonstrate their financial and organisational operational capability.

                         
i.     
The
Committee discussed this requirement in detail and determined that it was both reasonable
to request this information from potential applicants and it was consistent
with past practices including the prior new TLD rounds; the .net and .org
rebids and the conditions associated with ICANN registrar accreditation.

                       
ii.     
The
challenging aspect of this recommendation is to develop robust and objective
criteria against which applicants can be measured, recognising a vast array of
business conditions and models. This
will be an important element of the ongoing development of the Implementation
Plan.

9.     
Recommendation 9 Discussion -- There must be a clear and
pre-published process using objective and measurable criteria.

                         
i.     
This
recommendation has been made consistent with ICANN?s previous TLD rounds in
2000 and 2003/2004 and with its re-bid of both the .net and .org registry
contracts.

                       
ii.     
It
is also consistent with ICANN?s Mission and Core Values especially 7, 8 and 9
which address openness in decision making processes and the timeliness of those
process.

                     
iii.     
The
Committee decided that the ?process? criteria for introducing new
top-level domains would follow a pre-published application system including the
levying of an application fee to recover the costs of the application process.
This is consistent with ICANN?s approach to the introduction of new TLDs
in the previous 2000 and 2004 round for new top level domains.

10.
Recommendation 10 Discussion - There must be a base contract
provided to applicants at the beginning of the process.

                         
i.     
The
General Counsel?s office has been involved in discussions about the provision
of a base contract which would assist applicants both during the application
process and in any contract negotiation phase.

                       
ii.     
Whilst
a framework for this base contract has been developed, it would be prudent to
complete the policy recommendations prior to the draft of the base contract
being distributed.

11. Recommendation 11 Discussion ? Staff Evaluators will be used to
make preliminary determinations about applications as part of a process which
includes the use of expert panels to make decisions.
style='mso-footnote-id:ftn35' href="#_ftn35" name="_ftnref35" title="">[35]

                         
i.     
ICANN would, to implement the policy,
develop an implementation plan that included Staff Evalutors being able to make
preliminary
determinations on whether the application complies with the string requirements
and that ICANN may engage appropriate expert advice in order to make a
determinations about string contention.

                       
ii.     
It was
clear from Committee discussions and from staff input that ICANN would continue
to conduct public comment processes including input from the full range of
ICANN Advisory Committees.

12. Recommendation 12 Discussion -- Dispute resolution and challenge
processes must be established prior to the start of the process.

                         
i.     
The
draft Implementation Plan found at the beginning of the document sets out, in a
high level form, the points in the process which may need dispute resolution
and challenge processes.

                       
ii.     
The
Committee has provided clear direction on its expectations that all the dispute
resolution and challenge process would be established prior to the opening of
the application round.

                     
iii.     
Further
input will be sought from ICANN?s other Supporting Organizations and Advisory
Committees. Adjustment to the proposals
may need to be made to take into account the recommendations of, for example,
the RN-WG and the PRO-WG.

name="_Toc35657639">TERM OF
REFERENCE THREE -- DISCUSSION

13. Recommendation 13 Discussion ? Applications must be assessed in
rounds.

                         
i.     
This
is straightforward recommendation which suggests an application round would be
opened on Day 1 and closed on Day x with an unspecified number of applications
to be processed within that round.

                       
ii.     
This
recommendation may be amended, after an evaluation period and report which may
suggest modifications to this system.

14. Recommendation 14 Discussion -
If there is contention for strings applicants may i) resolve contention
between them within a pre-established timeframe; ii) if there is no mutual
agreement, a process will be put in place to enable efficient resolution of
contention and iii) the ICANN Board may
be used to make a final decision, using advice from staff and expert panels

                         
i.     
Allocation methods for new top level domains
have been the subject of detailed discussion within the Committee and with
ICANN operational staff.

                       
ii.     
The
discussion about allocation methods has taken place through analysis of the
formal Constituency Statements; public comments and email discussions which
were used to modify and clarify the language of the Recommendations.

                     
iii.     
Comparative
evaluations have been a consistent theme throughout the policy development
process with some discussants suggesting that auctions were a more suitable
method of resolving conflict between applicants with similar string ideas. On balance, a comparative evaluation system
will be used to analyse all applications and, where there is string contention
between applicants for the same string, a different process may be
necessary.

                      
iv.     
ICANN
staff has received some detailed advice about the utility and practicality of
using auctions to resolve string contention at particular points in the
application process. The key features of
auctions[36] are, properly designed, they are
objective and stand up well to challenge; they are administratively efficient;
they assign resources to the highest valued use and they generate revenue.

                        
v.     
The
draft Recommendations recognize past experiences with comparative evaluations
in the ICANN environment, particularly those relating to sponsored top-level
domains where measures of ?community? support needed to be determined. The evaluations, for example in the case of
the .net and .org rebids and the introduction of new sTLDs like .jobs and
.travel, show that the Internet-using community takes a keen interest in
ICANN?s decision making process. In
addition, ICANN?s Supporting Organisations and Advisory Committees outside the
GNSO play a key role in determining the success of potential applications.

                      
vi.     
Further
work is required on two key elements ? the question of support and the absence
of relevant opposition. The use of
public comments also needs to be further defined in terms of their utility in
assisting evaluation panels. These
questions have been raised in the context of the RN-WG and the PRO-WG and
potential recommendations are expected from those two groups for the Committee
to consider.

                    
vii.     
In
addition, questions were raised about establishing incentives for applicants to
reach agreement about contention. These
could be in the form of fees for the next stage of the evaluation process
and/or demonstrating the attractiveness of a ?fast path? to avoid a ?slow and
expensive path?. Committee members
suggested at the LA meetings that applicants could choose an auction model to
resolve the contention or applicants could choose an arbitration model and pay
the appropriate fee. ICANN staff will
consider these options and other suggestions in the ongoing development of the
Implementation Plan as it was clear that there was no agreement on which
particular model to use. There is,
however, strong support to create an environment to resolve contention which
could include internal mediation, enforced mediation, auctions or comparative
evaluations
style='mso-footnote-id:ftn37' href="#_ftn37" name="_ftnref37" title="">[37].

name="_Toc35657640">TERM OF
REFERENCE FOUR -- DISCUSSION

15. Recommendation 15 -- The initial registry agreement
term must be of a commercially reasonable length.

16. Recommendation 16 -- There must be renewal
expectancy.

17. Recommendation 17 -- Registries must apply existing
Consensus Policies
style='mso-footnote-id:ftn38' href="#_ftn38" name="_ftnref38" title="">[38] and adopt new Consensus Polices as
they are approved.

18. Recommendation 18 -- A clear compliance and sanctions process must be set out in the
base contract which could lead to contract termination.

                         
i.     
Referring
to all four recommendations above, this section sets out the discussion of the
policies for contractual conditions for new top-level domain registry
operators. The recommendations are
consistent with the existing provisions for registry operators which were the
subject of detailed community input throughout 2006
style='mso-footnote-id:ftn39' href="#_ftn39" name="_ftnref39" title="">[39].

                       
ii.     
The
Committee developed its recommendations during the Brussels and Amsterdam
face-to-face consultations, with particular assistance from the ICANN General
Counsel?s office. The Committee has
focused on the key principles of consistency, openness and transparency. It was also determined that a scalable and
predictable process is consistent with industry best practice standards for
services procurement. The Committee
referred in particular to standards within the broadcasting, telecommunications
and Internet services industries to examine how regulatory agencies in those
environments conducted, for example, spectrum auctions, broadcasting licence
distribution and media ownership frameworks.

                     
iii.     
The
Committee found a number of expert reports
style='mso-footnote-id:ftn40' href="#_ftn40" name="_ftnref40" title="">[40] beneficial. In particular, the World Bank report on
mobile licensing conditions provides some guidance on best practice principles
for considering broader market investment conditions. ??A major challenge facing regulators in
developed and developing countries alike is the need to strike the right
balance between ensuring certainty for market players and preserving
flexibility of the regulatory process to accommodate the rapidly changing
market, technological and policy conditions.
As much as possible, policy makers and regulators should strive to
promote investors? confidence and give incentives for long-term
investment. They can do this by favoring
the principle of ?renewal expectancy?, but also by promoting regulatory
certainty and predictability through a fair, transparent and participatory
renewal process. For example, by
providing details for license renewal or reissue, clearly establishing what is
the discretion offered to the licensing body, or ensuring sufficient lead-times
and transitional arrangements in the event of non-renewal or changes in
licensing conditions. Public
consultation procedures and guaranteeing the right to appeal regulatory
decisions maximizes the prospects for a successful renewal process. As technological changes and convergence and
technologically neutral approaches gain importance, regulators and policy
makers need to be ready to adapt and evolve licensing procedures and practices
to the new environment.?

                      
iv.     
The
Recommendations which the Committee has developed with respect to the
introduction of new TLDs are consistent with the World Bank principles.

19. Recommendation 19 Discussion -- If an applicant offers an IDN
service, then ICANN?s IDN guidelines must be followed

                         
i.     
The
introduction of internationalised domain names at the root presents ICANN with
a series of implementation challenges.
The initial technical testing
style='mso-footnote-id:ftn41' href="#_ftn41" name="_ftnref41" title="">[41] has been completed and a series of
live root tests will take place shortly.

                       
ii.     
The
Committee recognises that there is ongoing work in other parts of the ICANN
organisation that needs to be factored into the application process that will
apply to IDN applications. The work
includes the President?s Committee on IDNs, the GAC and ccNSO joint working
group on IDNs in addition to the GNSO IDN WG.
Further consultation will take place at the upcoming ICANN meeting in
Lisbon which will provide additional clarity on IDN related policy issues.

20. Recommendation 20 Discussion ? Registries must use ICANN
accredited registrars.

                         
i.     
In
order to facilitate the stable and secure operation of the DNS, the Committee
agreed that it was prudent to continue the current requirement that registry
operators be obliged to use ICANN accredited registrars.

name="_Toc25129598">ANNEX ONE -- POLICY DEVELOPMENT
PROCESS INFORMATION

1.      This section provides detailed information about the
progress of the policy development process and the documentation produced
throughout the series of teleconferences and face-to-face consultations that
have taken place during 2006 and 2007.
All of the meetings were open to observers and many different
stakeholders attended the meetings taking an active part in the
discussion. In addition, all meetings
were open to remote participation by teleconference and through the use of the
Shinkuro (
href="http://www.shinkuro.com/">www.shinkuro.com) file-sharing technology. A full table found at Annex Two illustrates
participation by GNSO Constituencies and other observers. This table will be included in full for the
Board Report which is part of the PDP requirements.

2.      The Issues
Report was released on 5 December 2005.
The Report sets out an early
collation of issues that the GNSO wished to take into account in developing the
Terms of Reference for future rounds.
For example, the selection criteria used in previous application rounds
for new top-level domains were used to guide the development of Term of
Reference Two in this PDP. An evaluation
of the selection criteria and methods used in the re-bidding of the .org and
.net registry contracts was also conducted.
The Issues Report contained
Staff Recommendations about potential terms of reference and, in the majority,
those Recommendations were adopted by the GNSO Council. The Report
is found at
href="http://gnso.icann.org/issues/new-gtlds/gnso-issues-rpt-gtlds-05dec05.pdf">http://gnso.icann.org/issues/new-gtlds/gnso-issues-rpt-gtlds-05dec05.pdf.

3.     

A Public Comment Period was launched on 6 December
2005 to solicit input from the ICANN community about the proposed Terms of
Reference (found at
href="http://www.icann.org/announcements/announcement-06dec05.htm">http://www.icann.org/announcements/announcement-06dec05.htm). The Public
Comment Period ran until 31 January 2006.
For this PDP public comment periods have been used in different ways
than in the past. In general, public
comment calls have been far more targeted and highly structured to get
responses on particular areas of concern to the Committee. This was a successful initiative enabling
information to be collected in a consistent way that improved the quality of
subsequent Reports. The archive of comments can be found at
href="http://forum.icann.org/lists/new-gtlds-pdp-comments/">http://forum.icann.org/lists/new-gtlds-pdp-comments/).

4.     

In addition to a Public Comment Period, a
style='mso-bidi-font-style:normal'>Call for Expert Papers was announced on
3 January 2006 (found at
href="http://icann.org/announcements/announcement-03jan06.htm">http://icann.org/announcements/announcement-03jan06.htm). The request
for input was advertised widely in the international press and yielded eleven
responses from a diverse range of stakeholders.
The authors of the papers were invited to present their papers and
participate in a question and answer session at the 23 - 25 February 2006 Washington
meeting. A full listing of all the
inputs, including the Expert Papers,
can be found at
href="http://gnso.icann.org/issues/new-gtlds/new-gtld-pdp-input.htm">http://gnso.icann.org/issues/new-gtlds/new-gtld-pdp-input.htm.

5.     

The ICANN Board has been regularly updated on the
progress of and taken a keen interest in the work of the new TLDs
Committee. For example, the Board
meeting of 10 January 2006 shows discussion within the Board about its
involvement in new TLDs policy development process (found at
href="http://www.icann.org/minutes/minutes-10jan06.htm">http://www.icann.org/minutes/minutes-10jan06.htm)

6.      A draft Initial
Report was released on 19 February 2006 (found at
href="http://icann.org/topics/gnso-initial-rpt-new-gtlds-19feb06.pdf">http://icann.org/topics/gnso-initial-rpt-new-gtlds-19feb06.pdf) and a request for public comments was announced at
the same time that was open between 20 February 2006 and 13 March 2006. The archives for those comments are found at
href="http://forum.icann.org/lists/new-gtlds-pdp-initial-report/">http://forum.icann.org/lists/new-gtlds-pdp-initial-report/. The draft
style='mso-bidi-font-style:normal'>Initial Report was used to facilitate
discussion at subsequent Committee meetings and to give some guide to the
broader community about the Committee?s progress in its early stages.

7.     

The GNSO?s new TLDs Committee held a three day meeting
in Washington DC between 23 and 25 February 2006. The meeting notes can be found on the GNSO?s
Committee archive at (http://forum.icann.org/lists/gtld-council/msg00030.html). A central element of the discussion focused
on re-visiting ICANN?s Mission and Core Values to ensure that the deliberations
on the Terms of Reference were tightly constrained. The substantive discussion over the three-day
meeting also included discussion on whether to introduce new top-level domains
(
href="http://forum.icann.org/lists/gtld-council/msg00027.html">http://forum.icann.org/lists/gtld-council/msg00027.html) and potential selection criteria which could be used
in a new round of top-level domain applications (
href="http://forum.icann.org/lists/gtld-council/msg00026.html">http://forum.icann.org/lists/gtld-council/msg00026.html).

8.     

Analysis of the lessons learned from previous TLD
rounds was included in the broader discussions held in Washington DC (
href="http://forum.icann.org/lists/gtld-council/msg00030.html">http://forum.icann.org/lists/gtld-council/msg00030.html). In addition
to discussing general selection criteria, detailed discussion of technical
requirements also took place (
href="http://forum.icann.org/lists/gtld-council/msg00028.html">http://forum.icann.org/lists/gtld-council/msg00028.html). Following
the Washington meetings, it was clear that further information about technical
criteria was necessary to inform the Committee?s work. On 15 March 2006 a formal call was made for
additional information on technical criteria (found at
href="http://gnso.icann.org/issues/new-gtlds/tech-criteria-15mar06.htm">http://gnso.icann.org/issues/new-gtlds/tech-criteria-15mar06.htm). No responses
were received to that specific call but, in the resulting recommendations,
particular attention has been paid to addressing relevant technical standards
across the full range of registry operations, including those that relate to
Internationalised Domain Names.

9.     

In response to the Committee?s work and to discussions
at the March 2006 Wellington meeting, the Board indicated its intention to
facilitate the implementation of new top-level domains (found at
href="http://www.icann.org/minutes/minutes-31mar06.htm">http://www.icann.org/minutes/minutes-31mar06.htm.)

10.

The new TLDs Committee met in Brussels between 11 and
13 May 2006 to discuss, in further detail, the work that had been undertaken on
refining the selection criteria and allocation methods. In addition, a full day was spent on
discussing policies for contractual conditions with a special presentation from
ICANN?s Deputy General Counsel. The
Committee has archived, on 18 May 2006, records of the Brussels discussion and
output from the meeting can be found at
http://forum.icann.org/lists/gtld-council/msg00133.html

11.

At the Brussels meeting, a revised work plan was
devised (found at
href="http://forum.icann.org/lists/gtld-council/msg00130.html">http://forum.icann.org/lists/gtld-council/msg00130.html) which include a high level commitment to producing
an Initial Report in time for
discussion at ICANN?s June 2006 Marrakech meeting.

12.

A draft Initial
Report was released on 15 June 2006 (found at
href="http://gnso.icann.org/issues/new-gtlds/issues-report-15jun06.pdf">http://gnso.icann.org/issues/new-gtlds/issues-report-15jun06.pdf) and further discussion took place on the Committee?s
mailing list prior to the Marrakech meeting.

13.

The ICANN Board meeting of 30 June 2006 showed, again,
the Board?s interest in facilitating the policy development process on new
top-level domains, particularly in encouraging ongoing discussions with the
GAC. (found at
href="http://www.icann.org/minutes/resolutions-30jun06.htm">http://www.icann.org/minutes/resolutions-30jun06.htm). After inputs
from the Marrakech meeting a final version of the Initial Report was released on 28 July 2006 (found at
href="http://gnso.icann.org/drafts/newgtlds-issues-report-01-28jul06.htm">http://gnso.icann.org/drafts/newgtlds-issues-report-01-28jul06.htm).

14.

The Committee conducted another set of face-to-face
consultations in Amsterdam between 29 and 31 August 2006 to further refine the
Committee?s findings and to develop a set of draft Recommendations. Prior to
the Amsterdam meeting, a comprehensive public comment period was
conducted. These public comments (found
at http://forum.icann.org/lists/gtld-council/msg00189.html) were used as
working materials for the Committee to consider, in addition to Constituency
Statements, the previous set of Expert Papers and comprehensive commentary for
a wide variety of observers to the meetings.

15.

The Committee met with the GAC on two occasions during
the course of the consultations ? in Wellington and again in Marrakech ? where
progress on the Committee?s work was shared with GAC members.

16.

The most important aspects of the discussion were
further clarification about:

a.      string
differentiation (
href="http://forum.icann.org/lists/gtld-council/msg00190.html">http://forum.icann.org/lists/gtld-council/msg00190.html);

b.      proposed requirements to provide an operational plan (
href="http://forum.icann.org/lists/gtld-council/msg00191.html">http://forum.icann.org/lists/gtld-council/msg00191.html)

c.      treatment of application fees (
href="http://forum.icann.org/lists/gtld-council/msg00194.html">http://forum.icann.org/lists/gtld-council/msg00194.html)

d.      allocation methods (
href="http://forum.icann.org/lists/gtld-council/msg00202.html">http://forum.icann.org/lists/gtld-council/msg00202.html); and

e.      string checking
(http://forum.icann.org/lists/gtld-council/msg00203.html)

17. Considering all the materials derived from the
face-to-face meetings, discussions on email lists, expert materials and expert
papers, on 14 September 2006 a set of draft Recommendations
was released by the Committee for broader consideration (found at
href="http://gnso.icann.org/issues/new-gtlds/recom-summary-14sep06.htm">http://gnso.icann.org/issues/new-gtlds/recom-summary-14sep06.htm).

18. Between 14 September and 5 October 2006 email
discussion took place that improved and clarified the language of the
style='mso-bidi-font-style:normal'>Recommendations and ensured that
Constituencies had sufficient time to rework their recommendations where
necessary.

19. On 5 October 2006, the Committee conducted a two hour
teleconference to discuss the draft Recommendations
(the MP3 recording can be found at
href="http://forum.icann.org/lists/gtld-council/msg00224.html)/">http://forum.icann.org/lists/gtld-council/msg00224.html)/. The purpose
of the meeting was to confirm that the Recommendations
reflected the intentions of the Committee and to conduct further work on
refining elements of the Recommendations,
particularly with respect to the selection criteria and allocation methods
to resolve contention between string applications.

20. On 11 October 2006, the GNSO Committee Chairman and
GNSO Chair, Dr Bruce Tonkin, sent formal correspondence to the Chair of the
Governmental Advisory Committee and the Chair of GAC Working Group I,
requesting the GAC?s assistance with the public policy impacts of the
introduction of new TLDs (found at
href="http://gnso.icann.org/mailing-lists/archives/council/msg02891.html">http://gnso.icann.org/mailing-lists/archives/council/msg02891.html).

21. Based on the substantive nature of the Committee?s
email traffic on the draft Recommendations,
a further update was released to the Committee on 18 October 2006 (found at

href="http://forum.icann.org/lists/gtld-council/msg00234.html">http://forum.icann.org/lists/gtld-council/msg00234.html) for consideration whilst the drafting of the
style='mso-bidi-font-style:normal'>Final Report takes place.

22. The remainder of the process is set out in the main
body of the document. This information
will be reworked as the PDP comes to a conclusion.

name="_Toc33183284">ANNEX TWO -- PARTICIPATION TABLE

UPDATE TO BE INSERTED

Legend:

a = absent

aa = absent apologies

na = not available ? one constituency member funded or
other conflict

rp = remote participation

style='width:100.0%;border-collapse:collapse;border:none'>

NEW TLDs COMMITTEE MEETINGS

Brussels

TC

Amsterdam

TC

NAME

24 & 25 Feb 06 Washington DC

25 Mar 06 Wellington, NZ

26 Mar 06 Wellington, NZ

11 May 06

12 May 06

13 May 06

15 Jun 06

29 Aug 06

30 Aug 06

31 Aug 06

5 Oct 06

CBUC

Marilyn Cade

X

x

x

x

x

x

aa

x

x

x

x

Philip Shepherd

A

x

x

x

x

x

x

x

x

x

Alistair Dixon

Rp

x

rp

rp

x

na

rp

na

aa

Grant Forsyth

Rp

x

ISPC

Tony Holmes

Rp

x

x

na

na

na

aa

x

x

x

aa

Tony Harris

A

x

x

x

x

x

x

na

na

na

x

Greg Ruth

Rp

x

na

na

na

x

rp

rp

aa

Mark McFadden

X

Maggie Mansourkia

X

IPC

Lucy Nichols

X

a

x

x

x

aa

na

na

na

aa

Ute Decker

A

a

x

x

x

aa

x

x

x

x

Kiyoshi Tsuru

X

x

x

na

na

na

a

na

na

na

Steve Metalitz

X

NCUC

Robin Gross

Na

x

x

na

na

na

x

na

na

na

Mawaki Chango

X

a

x

x

x

a

x

x

x

a

Norbert Klein

Na

x

x

na

na

na

a

na

na

na

aa

Registrars

Bruce Tonkin

X

x

x

x

x

x

x

x

x

x

x

Ross Rader

X

x

x

na

na

na

a

na

na

na

aa

Tom Keller

Na

a

na

na

na

a

x

x

x

Registry

Cary Karp

Na

x

x

na

na

na

x

na

na

x

x

Ken Stubbs

X

x

x

x

x

x

x

x

x

x

x

June Seo

x

x

na

na

na

a

rp

Nominating Committee

Avri Doria

Rp

x

x

x

x

x

x

x

x

x

x

Sophia Bekele

X

x

x

a

a

a

a

a

a

a

Maureen Cubberley

Rp

x

x

na

na

na

rp

rp

rp

aa

ALAC

Bret Fausett

Rp

x

rp

rp

rp

x

x

x

x

GAC

Suzanne Sene

X

Observers

Marcus Faure

x

x

x

Chuck Gomes

X

x

x

x

x

x

x

x

x

x

x

Werner Staub

x

x

x

x

x

x

x

x

x

x

Ray Fassett

X

x

x

x

x

x

x

x

x

x

Elmar Knipp

x

x

x

David Maher

x

x

x

Kristina Rosette

x

Matthew Embrescia

x

x

Danny Younger

X

Dirk Kirschenowski

Rp

x

x

x

x

x

x

Alexander Schubert

x

x

x

x

x

X

Jon Nevett

x

x

x

x

x

Philip Grabensee

x

x

x

M. M-Schönherr

x

x

x

Becky Burr

x

x

Keith Drazek

X

x

x

Sebastien Bachelot

x

x

Staff

Liz Williams

X

x

x

x

x

x

x

x

x

x

x

Glen de Saint Gery

X

x

x

x

x

x

x

x

x

x

x

Dan Halloran

x

x

x

x

x

x

Kurt Pritz

X

x

x

x

x

x

x

x

Donna Austin

x

Craig Schwartz

x

x

x

x

Maria Farrell

x

x

x

x

Tina Dam

x

x

x

x

Denise Michel

x

name="_Toc35657643">ANNEX THREE -- REFERENCE MATERIALS

Davis and Holt, Experimental
Economics, Princeton University Press, Princeton: 1993. (Materials for auction models is also
available at the University of Haifa website http://www.gsb.haifa.ac.il)

DNJournal, Global
TLD Registrations Pass 50 Million as New Users Stream

Online.
July 30 2005. On line version at http://dnjournal.com/columns/50million.htm.

Guermazi, Boutheina and
Isabel Neto, Mobile License Renewal: What are the issues? What is at stake?, available at
href="http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/2…">http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/23
href="http://www-wds.worldbank.org/servlet/WDSContentServer/WDSP/IB/2005/09/2…">/000016406_20050923113019/Rendered/PDF/wps3729.pdf

Johnson, David and Susan Crawford,
style='mso-bidi-font-style:normal'>Old Delusions and new TLDs, comments
submitted 13 November 2002 as part of ICANN Amsterdam meeting topic
(http://www.icann.org/amsterdam/gtld­action­plan­topic.htm).

On line version available at
http://forum.icann.org/gtld­plan­comments/general/msg00003.html.

Johnson, David and Susan Crawford,
style='mso-bidi-font-style:normal'>A Concrete ?Thin Contract Proposal, submitted 23 August 2003 as comments on new TLD
contracts. On line version including proposed draft contract available at
http://forum.icann.org/mtg­ cmts/stld­rfp­comments/general/msg00039.html.

Klemperer, Paul. Auctions: Theory
and Practice. The Toulouse Lectures in Economics. (2004).
href="http://www.nuff.ox.ac.uk/users/klemperer/VirtualBook/VirtualBookCoverSh…">http://www.nuff.ox.ac.uk/users/klemperer/VirtualBook/VirtualBookCoverSh…

Klensin, John, RFC
3071 (Reflections on the DNS, RFC 1591, and Categories of Domains).
2001. On line version at http://rfc.net/rfc3071.html.

Klensin, John, RFC
3467 (Role of the Domain Name System).
2003. On line version at http://rfc.net/rfc3467.html.

Mannheim,
Karl and Lawrence Solum. ?The Case for gTLD Auctions.? Research Paper #2003-11,
Loyola Law School.
href="http://papers.ssrn.com/sol3/papers.cfm?abstract_id=515183">http://papers.ssrn.com/sol3/papers.cfm?abstract_id=515183

Matsui, Masayuki, Comparing
Domain Name Administration in OECD Countries, available at
href="http://www.oecd.org/dataoecd/46/38/2505946.pdf">http://www.oecd.org/dataoecd/46/38/2505946.pdf

Mueller,
Milton and Lee McKnight. ?The Post-.com Internet: Toward Regular and Objective
Procedures for Internet Governance.? Telecommunications Policy 28 (7/8),
487-502 (2004) http://dcc.syr.edu/miscarticles/NewTLDs2-MM-LM.pdf

National Research Council, Signposts in Cyberspace: The
Domain Name

System and
Internet Navigation, Committee on
Internet Navigation and the

Domain Name System: Technical
Alternatives and Policy Implications;

Washington, DC: 2005. ISBN:
0­309­09640­5. Executive
summary found at http://www.nap.edu/execsumm_pdf/11258.pdf ).

Paltridge, Sam and Masayuki Matsui,
style='mso-bidi-font-style:normal'>Generic Top-level Domain Names: Market Development and Allocation Issues,
Working Party
on Telecommunications and Information
Services Policies. Paris: 2004.

DSTI/ICCP/TISP(2004)/2Final. On line version at
href="http://www.oecd.org/dataoecd/56/34/32996948.pdf">http://www.oecd.org/dataoecd/56/34/32996948.pdf

Perset, Karin and Dimitri Ypsilanti,
style='mso-bidi-font-style:normal'> The Secondary Market for Domain Names,
available at http://www.oecd.org/dataoecd/14/45/36471569.pdf

Summit Strategies International, Evaluation of the New
gTLDs: Policy and Legal Issues, August 2004. On line version at http://icann.org/tlds/new­gtld­eval­
31aug04.pdf. On line version of
presentation at ICANN?s Rome meeting http://www.icann.org/presentations/sapiro­forum­rome­04mar04.pdf.

VeriSign, The
Domain Name Industry Brief, Volume 2, Issue 2, May 2005. On line version at http://www.verisign.com/stellent/groups/public/documents/newsletter/030725.pdf

World Intellectual Property Organisation,
style='mso-bidi-font-style:normal'>New Generic Top­Level Domains: Intellectual
Property Considerations, WIPO Arbitration and Mediation Center, 2004. On line
version at http://arbiter.wipo.int/domains/reports/newgtld­ip/index.html.

ICANN Links

For a full listing of all inputs including Constituency Statements,
Public Comment archives and Expert Papers,
http://gnso.icann.org/issues/new-gtlds/new-gtld-pdp-input.htm.

GNSO gTLDs Committee Final Report on New gTLDs, May­ June 2003

9 May, v4: http://www.dnso.org/dnso/notes/20030509.gTLDs­committee­conclusions­v4.html

21 May, v5:
http://www.dnso.org/dnso/notes/20030521.gTLDs­committee­conclusions­v5.html

02 Jun, v6:
http://www.dnso.org/dnso/notes/20030602.gTLDs­committee­conclusions­v6.html

12 Jun, v7: http://www.dnso.org/dnso/notes/20030612.gTLDs­committee­conclusions­v7­1.html

IANA Listing of all TLDs

http://data.iana.org/TLD/tlds­alpha­by­domain.txt.

List of Registry Agreements
http://www.icann.ORG/registries/agreements.htm