Draft Final Report
Introduction of New Generic Top-Level Domains
Table of Contents
10 PRINCIPLES
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
|
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, 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 Web site's URL, e.g. www.wikipedia.org. This type of domain name is also called a hostname. The product that Domain name registrars provide to their customers. These names are often called registered domain names. Names used for other purposes in the Domain Name System (DNS), for example the special name which follows the @ sign in an email address, or the Top-level domains like .com, or the names used by the Session Initiation Protocol (VoIP), or DomainKeys. |
|
Domain Name System |
On the Internet, the domain name system (DNS) stores and associates many types of information with domain names; most importantly, it translates domain names (computer hostnames) to IP addresses. It also lists mail exchange servers accepting e-mail for each domain. In providing a worldwide 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 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 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 |
|
Reserved Names |
All ICANN’s registry agreements have Reserved Names provisions. See, for example, the .aero agreement http://www.icann.org/tlds/agreements/sponsored/sponsorship-agmt-att11-20aug01.htm |
|
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 DNS server that answers requests for the root namespace domain, and redirects requests for a particular 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 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 IP address. The empty string after the final dot is called the 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[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 Final Report reflects the updated work
of the Committee at its 23 & 24 February 2007 Los Angeles meetings[2].
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.
PRINCIPLES
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.[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
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.
Recommendation 1
|
ICANN must implement a process that
allows the introduction of new top-level domains.
|
Recommendation 2
|
Strings must not be confusingly similar[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[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[17] must be
followed. |
Recommendation 20
|
Registries
must use ICANN accredited registrars. |
Table 0-1: new gTLDs recommendations
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
[19]
.
|
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
Table 0‑1: DRAFT new TLDs
Implementation Plan
TERM OF
REFERENCE ONE – DISCUSSION
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[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 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[21]. These papers augmented a full
set of GNSO Constituency Statements[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.
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[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[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[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[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 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 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 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 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[29].
i.
The
Committee engaged in comprehensive discussion about this recommendation and
took advice from a number of experts within the group[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[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[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 (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 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 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[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.[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.
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[37].
TERM OF
REFERENCE FOUR -- DISCUSSION
16. Recommendation 16 -- There must be renewal
expectancy.
17. Recommendation 17 -- Registries must apply existing
Consensus Policies[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[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[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[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.
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 (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.
a. string
differentiation (http://forum.icann.org/lists/gtld-council/msg00190.html);
b. proposed requirements to provide an operational plan (http://forum.icann.org/lists/gtld-council/msg00191.html)
c. treatment of application fees (http://forum.icann.org/lists/gtld-council/msg00194.html)
d. allocation methods (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 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 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 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 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
http://forum.icann.org/lists/gtld-council/msg00234.html) for consideration whilst the drafting of the 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.
ANNEX TWO -- PARTICIPATION TABLE
aa = absent apologies
na = not available – one constituency member funded or
other conflict
rp = remote participation
|
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 |
|
|
|
|
|
||||||||