Final Report - Introduction of New Generic Top-Level Domains

Last Updated: 4 September 2009
Date: 
8 August 2007

ICANN Generic Names Supporting Organisation

Final Report

Introduction of New Generic Top-Level Domains

8 August 2007

Part A: Final Report

Introduction of New Generic Top-Level Domains

ABSTRACT

BACKGROUND

SUMMARY -- PRINCIPLES, RECOMMENDATIONS & IMPLEMENTATION GUIDELINES

TERM OF REFERENCE ONE -- WHETHER TO INTRODUCE NEW TOP-LEVEL DOMAINS

TERM OF REFERENCE -- SELECTION CRITERIA

TERM OF REFERENCE THREE -- ALLOCATION METHODS

TERM OF REFERENCE FOUR -- CONTRACTUAL CONDITIONS

NEXT STEPS

Annex A – NCUC Minority Statement: Recommendation 6

Annex B – Nominating Committee Appointee Avri Doria: Individual Comments

Annex C – NCUC Minority Statement: Recommendation 20 and Implementation Guidelines F, H & P

REFERENCE MATERIAL -- GLOSSARY

FINAL REPORT: PART B

ABSTRACT

This is the Generic Names Supporting Organization's Final Report on the Introduction of New Top-Level Domains. The Report is in two parts. Part A contains the substantive discussion of the Principles, Policy Recommendations and Implementation Guidelines and Part B contains a range of supplementary materials that have been used by the Committee during the course of the Policy Development Process.

The GNSO Committee on New Top-Level Domains consisted of all GNSO Council members. All meetings were open to a wide range of interested stakeholders and observers. A set of participation data is found in Part B.

Many of the terms found here have specific meaning within the context of ICANN and new top-level domains discussion. A full glossary of terms is available in the Reference Material section at the end of Part A.

BACKGROUND

1. The Internet Corporation for Assigned Names and Numbers (ICANN) is responsible for the overall coordination of "the global Internet's system of unique identifiers" and ensuring the "stable and secure operation of the Internet's unique identifier systems. In particular, ICANN coordinates the "allocation and assignment of the three sets of unique identifiers for the Internet". These are "domain names"(forming a system called the DNS); Internet protocol (IP) addresses and autonomous system (AS) numbers and Protocol port and parameter numbers". ICANN is also responsible for the "operation and evolution of the DNS root name server system and policy development reasonably and appropriately related to these technical functions". These elements are all contained in ICANN's Mission and Core Values[1] in addition to provisions which enable policy development work that, once approved by the ICANN Board, become binding on the organization. The results of the policy development process found here relate to the introduction of new generic top-level domains.

2. This document is the Final Report of the Generic Names Supporting Organisation's (GNSO) Policy Development Process (PDP) that has been conducted using ICANN's Bylaws and policy development guidelines that relate to the work of the GNSO. This Report reflects a comprehensive examination of four Terms of Reference designed to establish a stable and ongoing process that facilitates the introduction of new top-level domains. The policy development process (PDP) is part of the Generic Names Supporting Organisation's (GNSO) mandate within the ICANN structure. However, close consultation with other ICANN Supporting Organisations and Advisory Committees has been an integral part of the process. The consultations and negotiations have also included a wide range of interested stakeholders from within and outside the ICANN community[2].

3. The Final Report is in two parts. This document is Part A and contains the full explanation of each of the Principles, Recommendations and Implementation Guidelines that the Committee has developed since December 2005[3]. Part B of the Report contains a wide range of supplementary materials which have been used in the policy development process including Constituency Impact Statements (CIS), a series of Working Group Reports on important sub-elements of the Committee's deliberations, a collection of external reference materials, and the procedural documentation of the policy development process[4].

4. The finalisation of the policy for the introduction of new top-level domains is part of a long series of events that have dramatically changed the nature of the Internet. The 1969 ARPANET diagram shows the initial design of a network that is now global in its reach and an integral part of many lives and businesses. The policy recommendations found here illustrate the complexity of the Internet of 2007 and, as a package, propose a system to add new top-level domains in an orderly and transparent way. The ICANN Staff Implementation Team, consisting of policy, operational and legal staff members, has worked closely with the Committee on all aspects of the policy development process[5]. The ICANN Board has received regular information and updates about the process and the substantive results of the Committee's work.

5. The majority of the early work on the introduction of new top-level domains is found in the IETF's Request for Comment series. RFC 1034[6] is a fundamental resource that explains key concepts of the naming system. Read in conjunction with RFC920[7], an historical picture emerges of how and why the domain name system hierarchy has been organised. Postel & Reynolds set out in their RFC920 introduction about the "General Purpose Domains" that ..."While the initial domain name "ARPA" arises from the history of the development of this system and environment, in the future most of the top level names will be very general categories like "government", "education", or "commercial". The motivation is to provide an organization name that is free of undesirable semantics."

6. In 2007, the Internet is multi-dimensional and its development is driven by widespread access to inexpensive communications technologies in many parts of the world. In addition, global travel is now relatively inexpensive, efficient and readily available to a diverse range of travellers. As a consequence, citizens no longer automatically associate themselves with countries but with international communities of linguistic, cultural or professional interests independent of physical location. Many people now exercise multiple citizenship rights, speak many different languages and quite often live far from where they were born or educated. The 2007 OECD Factbook[8] provides comprehensive statistics about the impact of migration on OECD member countries. In essence, many populations are fluid and changing due in part to easing labour movement restrictions but also because technology enables workers to live in one place and work in another relatively easily. As a result, companies and organizations are now global and operate across many geographic borders and jurisdictions. The following illustration[9] shows how rapidly the number of domain names under registration has increased and one could expect that trend to continue with the introduction of new top-level domains.

7. A key driver of change has been the introduction of competition in the registration of domain names through ICANN Accredited Registrars[10]. In June 2007, there were more than 800 accredited registrars who register names for end users with ongoing downward pressure on the prices end-users pay for domain name registration.

8. ICANN's work on the introduction of new top-level domains has been underway since 1999. By mid-1999, Working Group C[11] 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.

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

10. The July 2007 zone file survey statistics from www.registrarstats.com[13] shows that there are slightly more than 96,000,000 top level domains registered across a selection of seven top-level domains including .com, .net and .info. Evidence from potential new applicants provides more impetus to implement a system that enables the ongoing introduction of new top level domains[14]. In addition, interest from Internet users who could use Internationalised Domain Names (IDNs) in a wide variety of scripts beyond ASCII is growing rapidly.

11. To arrive at the full set of policy recommendations which are found here, the Committee considered the responses to a Call for Expert Papers issued at the beginning of the policy development process[15], and which was augmented by a full set of GNSO Constituency Statements[16]. These are all found in Part B of the Final Report and should be read in conjunction with this document. In addition, the Committee received detailed responses from the Implementation Team about proposed policy recommendations and the implementation of the recommendations package as an on-line application process that could be used by a wide array of potential applicants.

12. The Committee reviewed and analysed 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 a full range of other historic materials[17].

13. In the past, a number of different approaches to new top level domains have been considered including the formulation of a structured taxonomy[18] of names, for example, .auto, .books, .travel and .music. The Committee has opted to enable potential applicants to self-select strings that are either the most appropriate for their customers or potentially the most marketable. It is expected that applicants will apply for targeted community strings such as .travel for the travel industry and .cat for the Catalan community as well as some generic strings. The Committee identified five key drivers for the introduction of new top-level domains.

(i) It is consistent with the reasons articulated in 1999 when the first proof-of-concept round was initiated

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

(iii) Expanding the domain name space to accommodate the introduction of both new ASCII 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 use domain names in their language of choice.

(iv) There is demand for additional top-level domains as a business opportunity. The GNSO Committee expects that this business opportunity will stimulate competition at the registry service level which is consistent with ICANN's Core Value 6.

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

14. The remainder of this Report is structured around the four Terms of Reference. This includes an explanation of the Principles that have guided the work taking into account the Governmental Advisory Committee's March 2007 Public Policy Principles for New gTLDs[19]; a comprehensive set of Recommendations which has majority Committee support and a set of Implementation Guidelines which has been discussed in great detail with the ICANN Staff Implementation Team. The Implementation Team has released two ICANN Staff Discussion Points documents (in November 2006 and June 2007). Version 2 provides detailed analysis of the proposed recommendations from an implementation standpoint and provides suggestions about the way in which the implementation plan may come together. The ICANN Board will make the final decision about the actual structure of the application and evaluation process.

15. 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[20]. In particular, detailed work has been conducted through the Internationalised Domain Names Working Group (IDN-WG)[21], the Reserved Names Working Group (RN-WG)[22] and the Protecting the Rights of Others Working Group (PRO-WG) [23]. The Working Group Reports are found in full in Part B of the Final Report along with the March 2007 GAC Public Policy Principles for New Top-Level Domains, Constituency Impact Statements. A minority statement from the NCUC about Recommendations 6 & 20 are found Annexes for this document along with individual comments from Nominating Committee appointee Ms Avri Doria.

SUMMARY -- PRINCIPLES, RECOMMENDATIONS & IMPLEMENTATION GUIDELINES

1. This section sets out, in table form, the set of Principles, proposed Policy Recommendations and Guidelines that the Committee has derived through its work. 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 DNS and, in particular, the Internet's root server system[24].

2. The Principles are a combination of GNSO Committee priorities, ICANN staff implementation principles developed in tandem with the Committee and the March 2007 GAC Public Policy Principles on New Top-Level Domains. The Principles are supported by all GNSO Constituencies.[25]

3. ICANN's Mission and Core Values were key reference points for the development of the Committee's Principles, Recommendations and Implementation Guidelines. These are referenced in the right-hand column of the tables below.

4. The Principles have support from all GNSO Constituencies.

PRINCIPLES

MISSION & CORE VALUES

A

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

M1 & CV1 & 2, 4-10

B

Some new generic top-level domains should be internationalised domain names (IDNs) subject to the approval of IDNs being available in the root.

M1-3 & CV 1, 4 & 6

C

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. In addition the introduction of new top-level domain application process has the potential to promote competition in the provision of registry services, to add to consumer choice, market differentiation and geographical and service-provider diversity.

M3 & CV 4-10

D

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.

M1-3 & CV 1

E

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.

M1-3 & CV 1

F

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

M1-3 & CV 1

G

The string evaluation process must not infringe the applicant's freedom of expression rights that are protected under internationally recognized principles of law.

RECOMMENDATIONS[26]

MISSION & CORE VALUES

1

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

The evaluation and selection procedure for new gTLD registries should respect the principles of fairness, transparency and non-discrimination.

All applicants for a new gTLD registry should therefore be evaluated against transparent and predictable criteria, fully available to the applicants prior to the initiation of the process. Normally, therefore, no subsequent additional selection criteria should be used in the selection process.

M1-3 & CV1-11

2

Strings must not be confusingly similar to an existing top-level domain or a Reserved Name.

M1-3 & C1-6-11

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.

Examples of these legal rights that are internationally recognized include, but are not limited to, rights defined in the Paris Convention for the Protection of Industry Property (in particular trademark rights), the Universal Declaration of Human Rights (UDHR) and the International Covenant on Civil and Political Rights (ICCPR) (in particular freedom of expression rights).

CV3

4

Strings must not cause any technical instability.

M1-3 & CV 1

5

Strings must not be a Reserved Word[27].

M1-3 & CV 1 & 3

6*

Strings must not be contrary to generally accepted legal norms relating to morality and public order that are recognized under international principles of law.

Examples of such principles of law include, but are not limited to, the Universal Declaration of Human Rights (UDHR), the International Covenant on Civil and Political Rights (ICCPR), the Convention on the Elimination of All Forms of Discrimination Against Women (CEDAW) and the International Convention on the Elimination of All Forms of Racial Discrimination, intellectual property treaties administered by the World Intellectual Property Organisation (WIPO) and the WTO Agreement on Trade-Related Aspects of Intellectual Property (TRIPS).

M3 & CV 4

7

Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out.

M1-3 & CV1

8

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

M1-3 & CV1

9

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

M3 & CV6-9

10

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

CV7-9

11

[Replaced with Recommendation 20 and Implementation Guideline P and inserted into Term of Reference 3 Allocation Methods section]

12

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

CV7-9

13

Applications must initially be assessed in rounds until the scale of demand is clear.

CV7-9

14

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

CV5-9

15

There must be renewal expectancy.

CV5-9

16

Registries must apply existing Consensus Policies and adopt new Consensus Policies as they are approved.

CV5-9

17

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

M1 & CV1

18

If an applicant offers an IDN service, then ICANN's IDN guidelines[28] must be followed.

M1 & CV1

19

Registries must use only ICANN accredited registrars in registering domain names and may not discriminate among such accredited registrars.

M1 & CV1

20*

An application will be rejected if an expert panel determines that there is substantial opposition to it from a significant portion of the community to which the string may be explicitly or implicitly targeted.

* The NCUC submitted Minority Statements on Recommendations 6 and 20. The remainder of the Recommendations have support from all GNSO Constituencies.

IMPLEMENTATION GUIDELINES

MISSION & CORE VALUES

IG A

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

CV 2, 5, 6, 8 & 9

IG B

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.

CV 5, 6, 8 & 9

IG C

ICANN will provide frequent communications with applicants and the public including comment forums.

CV 9 & 10

IG D

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.

CV 8-10

IG E

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.

CV 9 & 10

IG F*

If there is contention for strings, applicants may[29]:

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

ii) if there is no mutual agreement, a claim to support a community by one party will be a reason to award priority to that application. If there is no such claim, and 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.

CV 7-10

IG H*

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 exceptions:

(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; and

(ii) a formal objection process is initiated.

Under these exceptions, Staff Evaluators will devise criteria and procedures to investigate the claim.

Under exception (ii), an expert panel will apply the process, guidelines, and definitions set forth in IG P.

CV 7 - 10

IG H

External dispute providers will give decisions on objections.

CV 10

IG I

An applicant granted a TLD string must use it within a fixed timeframe which will be specified in the application process.

CV 10

IG J

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

CV 4-10

IG K

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

CV 5

IG L

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

CV 8

IG M

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

CV 3 - 7

IG N

ICANN may put in place a fee reduction scheme for gTLD applicants from economies classified by the UN as least developed.

CV 3 - 7

IG O

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.

CV 8 -10

IG P*

The following process, definitions and guidelines refer to Recommendation 20.

Process

Opposition must be objection based.

Determination will be made by a dispute resolution panel constituted for the purpose.

The objector must provide verifiable evidence that it is an established institution of the community (perhaps like the RSTEP pool of panelists from which a small panel would be constituted for each objection).

Guidelines

The task of the panel is the determination of substantial opposition.

a) substantial – in determining substantial the panel will assess the following: signification portion, community, explicitly targeting, implicitly targeting, established institution, formal existence, detriment

b) significant portion – in determining significant portion the panel will assess the balance between the level of objection submitted by one or more established institutions and the level of support provided in the application from one or more established institutions. The panel will assess significance proportionate to the explicit or implicit targeting.

c) community – community should be interpreted broadly and will include, for example, an economic sector, a cultural community, or a linguistic community. It may be a closely related community which believes it is impacted.

d) explicitly targeting – explicitly targeting means there is a description of the intended use of the TLD in the application.

e) implicitly targeting – implicitly targeting means that the objector makes an assumption of targeting or that the objector believes there may be confusion by users over its intended use.

f) established institution – an institution that has been in formal existence for at least 5 years. In exceptional cases, standing may be granted to an institution that has been in existence for fewer than 5 years.

Exceptional circumstances include but are not limited to a re-organization, merger or an inherently younger community.

The following ICANN organizations are defined as established institutions: GAC, ALAC, GNSO, ccNSO, ASO.

g) formal existence – formal existence may be demonstrated by appropriate public registration, public historical evidence, validation by a government, intergovernmental organization, international treaty organization or similar.

h) detriment – the objector must provide sufficient evidence to allow the panel to determine that there would be a likelihood of detriment to the rights or legitimate interests of the community or to users more widely.

IG Q

ICANN staff will provide an automatic reply to all those who submit public comments that will explain the objection procedure.

IG R

Once formal objections or disputes are accepted for review there will be a cooling off period to allow parties to resolve the dispute or objection before review by the panel is initiated.

* The NCUC submitted Minority Statements on Implementation Guidelines F, H & P. The remainder of the Implementation Guidelines have support from all GNSO Constituencies.

1. This set of implementation guidelines is the result of detailed discussion, particularly with respect to the two ICANN Staff Discussion Points[31] documents that were prepared to facilitate consultation with the GNSO Committee about the implementation impacts of the proposed policy Recommendations. The Implementation Guidelines will be used to inform the final Implementation Plan which is approved by the ICANN Board

2. The Discussion Points documents contain draft flowcharts which have been developed by the Implementation Team and which will be updated, based on the final vote of the GNSO Council and the direction of the ICANN Board. The Discussion Points documents have been used in the ongoing internal implementation discussions that have focused on ensuring that draft recommendations proposed by the Committee are implementable in an efficient and transparent manner[32]. The flowchart setting out the proposed Contention Evaluation Process is a more detailed component within the Application Evaluation Process and will be amended to take into account the inputs from Recommendation 20 and its related Implementation Guidelines.

3. This policy development process has been designed to produce a systemised and ongoing mechanism for applicants to propose new top-level domains. The Request for Proposals (RFP) for the first round will include scheduling information for the subsequent rounds to occur within one year. After the first round of new applications, the application system will be evaluated by ICANN's TLDs Project Office to assess the effectiveness of the application system. Success metrics will be developed and any necessary adjustments made to the process for subsequent rounds.

4. The following sections set out in detail the explanation for the Committee's recommendations for each Term of Reference.

TERM OF REFERENCE ONE -- WHETHER TO INTRODUCE NEW TOP-LEVEL DOMAINS

1. Recommendation 1 Discussion – All GNSO Constituencies supported the introduction of new top-level domains.

2. The GNSO Committee was asked to address 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).

3. 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[33] 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.

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

5. 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//

6. In addition, the Committee considered the responses to a Call for Expert Papers issued at the beginning of the policy development process[34]. These papers augmented a full set of GNSO Constituency Statements[35] and a set of Constituency Impact Statements[36] that addressed specific elements of the Principles, Recommendations and Implementation Guidelines.

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

(i) It is consistent with the reasons articulated in 1999 when the first proof-of-concept round was initiated

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

(iii) It is hoped that expanding the domain name space to accommodate the introduction of both new ASCII 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 use domain names in their language of choice.

(iv) In addition, the introduction of a new top-level domain application process has the potential to promote competition in the provision of registry services, and to add to consumer choice, market differentiation and geographic and service-provider diversity which is consistent with ICANN's Core Value 6.

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

8. Article X, Part 7, Section E of the GNSO's Policy Development Process requires the submission of "constituency impact statements" which reflect the potential implementation impact of policy recommendations. By 4 July 2007 all GNSO Constituencies had submitted Constituency Impact Statements (CIS) to the gtld-council mailing list[37]. Each of those statements is referred to throughout the next sections[38] and are found in full in Part B of the Report. The NCUC submitted Minority Statements on Recommendations 6 & 20 and on Implementation Guidelines F, H & P. These statements are found in full here in Annex A & C, respectively, as they relate specifically to the finalised text of those two recommendations. GNSO Committee Chair and Nominating Committee appointee Ms Avri Doria also submitted individual comments on the recommendation package. Her comments are found in Annex B here.

9. All Constituencies support the introduction of new TLDs particularly if the application process is transparent and objective. For example, the ISPCP said that, "...the ISPCP is highly supportive of the principles defined in this section, especially with regards to the statement in [principle A] (A): New generic top-level domains must be introduced in an orderly, timely and predictable way. Network operators and ISPs must ensure their customers do not encounter problems in addressing their emails, and in their web searching and access activities, since this can cause customer dissatisfaction and overload help-desk complaints. Hence this principle is a vital component of any addition sequence to the gTLD namespace. The various criteria as defined in D, E and F, are also of great importance in contributing to minimise the risk of moving forward with any new gTLDs, and our constituency urges ICANN to ensure they are scrupulously observed during the applications evaluation process". The Business Constituency's (BC) CIS said that "...If the outcome is the best possible there will be a beneficial impact on business users from: a reduction in the competitive concentration in the Registry sector; increased choice of domain names; lower fees for registration and ownership; increased opportunities for innovative on-line business models." The Registrar Constituency (RC) agreed with this view stating that "...new gTLDs present an opportunity to Registrars in the form of additional products and associated services to offer to its customers. However, that opportunity comes with the costs if implementing the new gTLDs as well as the efforts required to do the appropriate business analysis to determine which of the new gTLDs are appropriate for its particular business model."

10. The Registry Constituency (RyC) said that "...Regarding increased competition, the RyC has consistently supported the introduction of new gTLDs because we believe that: there is a clear demand for new TLDs; competition creates more choices for potential registrants; introducing new TLDs with different purposes increases the public benefit; new gTLDS will result in creativity and differentiation in the domain name industry; the total market for all TLDs, new and old, will be expanded." In summary, the Committee recommended, "ICANN must implement a process that allows the introduction of new top-level domains. The evaluation and selection procedure for new gTLD registries should respect the principles of fairness, transparency and non-discrimination. All applicants for a new gTLD registry should therefore be evaluated against transparent and predictable criteria, fully available to the applicants prior to the initiation of the process. Normally, therefore, no subsequent additional selection criteria should be used in the selection process". Given that this recommendation has support from all Constituencies, the following sections set out the other Terms of Reference recommendations.

TERM OF REFERENCE -- SELECTION CRITERIA

1. Recommendation 2 Discussion -- Strings must not be confusingly similar to an existing top-level domain.

i) This recommendation has support from all the GNSO Constituencies. Ms Doria accepted the recommendation with the concern expressed below[39].

ii) The list of existing top-level domains is maintained by IANA and is listed in full on ICANN's website[40]. Naturally, as the application process enables the operation of new top-level domains this list will get much longer and the test more complex. The RyC, in its Impact Statement, said that "...This recommendation is especially important to the RyC. ... It is of prime concern for the RyC that the introduction of new gTLDs results in a ubiquitous experience for Internet users that minimizes user confusion. gTLD registries will be impacted operationally and financially if new gTLDs are introduced that create confusion with currently existing gTLD strings or with strings that are introduced in the future. There is a strong possibility of significant impact on gTLD registries if IDN versions of existing ASCII gTLDs are introduced by registries different than the ASCII gTLD registries. Not only could there be user confusion in both email and web applications, but dispute resolution processes could be greatly complicated." The ISPCP also stated that this recommendation was "especially important in the avoidance of any negative impact on network activities." The RC stated that "...Registrars would likely be hesitant to offer confusingly similar gTLDs due to customer demand and support concerns. On the other hand, applying the concept too broadly would inhibit gTLD applicants and ultimately limit choice to Registrars and their customers".

iii) There are two other key concepts within this recommendation. The first is the issue of "confusingly similar" [41] and the second "likelihood of confusion". There is extensive experience within the Committee with respect to trademark law and the issues found below have been discussed at length, both within the Committee and amongst the Implementation Team.

iv) The Committee used a wide variety of existing law[42], international treaty agreements and covenants to arrive at a common understanding that strings should not be confusingly similar either to existing top-level domains like .com and .net or to existing trademarks[43]. For example, the Committee considered the World Trade Organisation's TRIPS agreement, in particular Article 16 which discusses the rights which are conferred to a trademark owner.[44] In particular, the Committee agreed upon an expectation that strings must avoid increasing opportunities for entities or individuals, who operate in bad faith and who wish to defraud consumers. The Committee also considered the Universal Declaration of Human Rights[45] and the International Covenant on Civil and Political Rights which address the "freedom of expression" element of the Committee's deliberations.

v) The Committee also benefited from the work of the Protecting the Rights of Others Working Group (PRO-WG). The PRO-WG presented its Final Report[46] to the Committee at the June 2007 San Juan meeting. The Committee agreed that the Working Group could develop some reference implementation guidelines on rights protection mechanisms that may inform potential new TLD applicants during the application process. A small ad-hoc group of interested volunteers are preparing those materials for consideration by the Council by mid-October 2007.

vi) The Committee had access to a wide range of differing approaches to rights holder protection mechanisms including the United Kingdom, the USA, Jordan, Egypt and Australia[47].

vii) In addition, the Committee referred to the 1883 Paris Convention on the Protection of Industrial Property[48]. It describes the notion of confusion and describes creating confusion as "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 (currently covering twenty-seven countries) 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.

viii)In the United States, existing trade mark law requires applicants for trademark registration to state under penalty of perjury 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.)[49]

ix) 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)

x) 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).

xi) 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)

xii) The Committee also looked in detail at the existing provisions of ICANN's Registrar Accreditation Agreement, particularly Section 3.7.7.9[50] 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."

xiii)The implications of the introduction of Internationalised Domain Names (IDNs) are, in the main, the same as for ASCII top-level domains. On 22 March 2007 the IDN-WG released its Outcomes Report[51] that the Working Group presented to the GNSO Committee. The Working Group's exploration of IDN-specific issues confirmed that the new TLD recommendations are valid for IDN TLDs. The full IDN WG Report is found in Part B of the Report.

xiv) The technical testing for IDNs at the top-level is not yet completed although strong progress is being made. Given this and the other work that is taking place around the introduction of IDNs at the top-level, there are some critical factors that may impede the immediate acceptance of new IDN TLD applications. The conditions under which those applications would be assessed would remain the same as for ASCII TLDs.

xv) Detailed work continues on the preparation of an Implementation Plan that reflects both the Principles and the Recommendations. 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[52].

xvi) The draft Implementation Plan (included in the Discussion Points document), illustrates the flow of the application and evaluation process and includes a detailed dispute resolution and extended evaluation tracks designed to resolve objections to applicants or applications.

xvii) There is tension between those on the Committee who are concerned about the protection of existing TLD strings and those concerned with the protection of trademark and other rights as compared to those who wish, as far as possible, to preserve freedom of expression and creativity. The Implementation Plan sets out a series of tests to apply the recommendation during the application evaluation process.

2. 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. Examples of these legal rights that are internationally recognized include, but are not limited to, rights defined in the Paris Convention for the Protection of Industry Property (in particular trademark rights), the Universal Declaration of Human Rights (UDHR) and the International Covenant on Civil and Political Rights (ICCPR) (in particular freedom of expression rights).

i. This recommendation has support from all GNSO Constituencies. Ms Doria supported the recommendation with concern expressed below[53].

ii. This recommendation was discussed in detail in the lead up to the Committee's 7 June 2007 conference call and it was agreed that further work would be beneficial. That work was conducted through a series of teleconferences and email exchanges. The Committee decided to leave the recommendation text as it had been drafted and insert a new Principle G that reads "...The string evaluation process must not infringe the applicant's freedom of expression rights that are protected under internationally recognized principles of law."

iii. Prior to this, the Committee engaged in comprehensive discussion about this recommendation and took advice from a number of experts within the group[54]. The original text of the recommendation has been modified to recognise that an applicant would 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. In addition, the original formulation that included "freedom of speech" was modified to read the more generally applicable "freedom of expression".

iv. Before reaching agreement on the final text, the IPC and the NCUC, in their respective Constituency Impact Statements (CIS), had differing views. The NCUC argued that "...there is no recognition that trade marks (and other legal rights have legal limits and defenses." The IPC says "agreed [to the recommendation], and, as stated before, appropriate mechanisms must be in place to address conflicts that may arise between any proposed new string and the IP rights of others."

3. Recommendation 4 Discussion -- Strings must not cause any technical instability.

i. This recommendation is supported by all GNSO Constituencies and Ms Doria.

ii. It was agreed by the Committee that the string should not cause any technical issues that threatened the stability and security of the Internet.

iii. In its CIS, the ISPCP stated that "...this is especially important in the avoidance of any negative impact on network activities...The ISPCP considers recommendations 7 and 8 to be fundamental. The technical, financial, organizational and operational capability of the applicant are the evaluators' instruments for preventing potential negative impact on a new string on the activities of our sector (and indeed of many other sectors)." The IPC also agreed that "technical and operational stability are imperative to any new gTLD introduction." The RC said "...This is important to Registrars in that unstable registry and/or zone operations would have a serious and costly impact on its operations and customer service and support."

iv. The Security and Stability Advisory Committee (SSAC) has been involved in general discussions about new top level domains and will be consulted formally to confirm that the implementation of the recommendations will not cause any technical instability.

v. A reserved word list, which includes strings which are reserved for technical reasons, has been recommended by the RN-WG. This table is found in the section below.

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

i. This recommendation is supported by all GNSO Constituencies. Ms Doria supported the recommendation but expressed some concerns outlined in the footnote below.[56]

ii. The RN WG developed a definition of "reserved word" in the context of new TLDs which said "...depending on the specific reserved name category as well as the type (ASCII or IDN), the reserved name requirements recommended may apply in any one or more of the following levels as indicated:

1. At the top level regarding gTLD string restrictions

2. At the second-level as contractual conditions

3. At the third-level as contractual conditions for any new gTLDs that offer domain name registrations at the third-level.

iii. The notion of "reserved words" has a specific meaning within the ICANN context. Each of the existing ICANN registry contracts has provisions within it that govern the use of reserved words. Some of these recommendations will become part of the contractual conditions for new registry operators.

iv. The Reserved Names Working Group (RN-WG) developed a series of recommendations across a broad spectrum of reserved words. The Working Group's Final Report[57] was reviewed and the recommendations updated by the Committee at ICANN's Puerto Rico meeting and, with respect to the recommendations relating to IDNs, with IDN experts. The final recommendations are included in the following table.


Reserved Name Category

Domain Name Level(s)

Recommendation

1

ICANN & IANA

All ASCII

The names listed as ICANN and IANA names will be reserved at all levels.

2

ICANN & IANA

Top level, IDN

Any names that appear in the IDN evaluation facility[58] which consist exclusively of translations of 'example' or 'test' that appear in the document at http://www.icann.org/topics/idn/idn-evaluation-plan-v2%209.pdf shall be reserved.

3

ICANN & IANA

2nd & 3rd levels, IDN

Any names that appear in the IDN evaluation facility which consist exclusively of translations of 'example' or 'test' that appear in the document at http://www.icann.org/topics/idn/idn-evaluation-plan-v2%209.pdf shall be reserved.

4

Symbols

All

We recommend that the current practice be maintained, so that no symbols other than the '-' [hyphen] be considered for use, with further allowance for any equivalent marks that may explicitly be made available in future revisions of the IDNA protocol.

5

Single and Two Character IDNs

IDNA-valid strings at all levels

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

6

Single Letters

Top Level

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

7

Single Letters and Digits

2nd Level

In future gTLDS we recommend that single letters and single digits be available at the second (and third level if applicable).

8

Single and Two Digits

Top Level

A top-level label must not be a plausible component of an IPv4 or IPv6 address. (e.g., .3, .99, .123, .1035, .0xAF, .1578234)

9

Single Letter, Single Digit Combinations

Top Level

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

Examples include .3F, .A1, .u7.

10

Two Letters

Top Level

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

Examples include .AU, .DE, .UK.

11

Any combination of Two Letters, Digits

2nd Level

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

12

Tagged Names

Top Level ASCII

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

13

N/A

Top Level IDN

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

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

14

Tagged Names

2nd Level ASCII

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

15

Tagged Names

3rd Level ASCII

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

16

NIC, WHOIS, WWW

Top ASCII

The following names must be reserved: nic, whois, www.

17

NIC, WHOIS, WWW

Top IDN

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

18

NIC, WHOIS, WWW

Second and Third* ASCII

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

19

NIC, WHOIS, WWW

Second and Third* IDN

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

20

Geographic and geopolitical

Top Level ASCII and IDN

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

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

Note New gTLD Recommendation 20

21

Geographic and geopolitical

All Levels ASCII and IDN

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

Note New gTLD Recommendation 20

22

Geographic and geopolitical

Second Level & Third Level if applicable, ASCII & IDN

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

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

Note New gTLD Recommendation 20

23

gTLD Reserved Names

Second &

Third Level ASCII and

IDN (when applicable)

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

24

Controversial Names

All Levels, ASCII & IDN

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

25

Controversial Names

Top Level, ASCII & IDN

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

Note New gTLD Recommendation 6

26

Controversial Names

Top Level, ASCII & IDN

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

Note New gTLD Recommendation 6

27

Controversial Names

Top Level, ASCII & IDN

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

Note New gTLD Recommendation 6

28

Controversial Names

Top Level, ASCII & IDN

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

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

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

Note New gTLD Recommendation 6

29

Controversial Names

Top Level, ASCII & IDN

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

§ Protect freedom of expression

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

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

Note New gTLD Recommendation 6

30

Controversial Names

Top Level, ASCII & IDN

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

Note New gTLD Recommendation 6

v. With respect to geographic terms, the NCUC's CIS stated that "...We oppose any attempts to create lists of reserved names. Even examples are to be avoided as they can only become prescriptive. We are concerned that geographic names should not be fenced off from the commons of language and rather should be free for the use of all...Moreover, the proposed recommendation does not make allowance for the duplication of geographic names outside the ccTLDs – where the real issues arise and the means of resolving competing use and fair and nominative use."

vi. The GAC's Public Policy Principle 2.2 states that "ICANN should avoid country, territory or place names, and country, territory or regional language or people descriptions, unless in agreement with the relevant government or public authorities."

vii. The Implementation Team has developed some suggestions about how this recommendation may be implemented. Those suggestions and the process flow were incorporated into the Version 2 of the ICANN Staff Discussion Points document for consideration by the Committee.

5. Recommendation 6 Discussion -- Strings must not be contrary to generally accepted legal norms relating to morality and public order that are recognized under international principles of law.
Examples of such principles of law include, but are not limited to, the Universal Declaration of Human Rights (UDHR), the International Covenant on Civil and Political Rights (ICCPR), the Convention on the Elimination of All Forms of Discrimination Against Women (CEDAW) and the International Convention of the Elimination of All Forms of Racial Discrimination, intellectual property treaties administered by the World Intellectual Property Organisation (WIPO) and the WTO Agreement on Trade-Related Aspects of Intellectual Property (TRIPS).

i. This Recommendation is supported by all GNSO Constituencies except the NCUC. The NCUC has submitted a Minority Statement which is found in full in Annex A. The NCUC's earlier Constituency Impact Statement is found, along with all the GNSO Constituency Impact Statements, in Part B of this report. Ms Doria has submitted individual comments[67]. The Committee has discussed this recommendation in great detail and has attempted to address the experiences of the 2003-2004 sTLD round and the complex issues surrounding the .xxx application. The Committee has also recognised the GAC's Public Policy Principles, most notably Principle 2.1 a) and b) which refer to both freedom of expression and terms with significance in a variety of contexts. In addition, the Committee recognises the tension respecting freedom of expression and being sensitive to the legitimate concerns others have about offensive terms. The NCUC's earlier CIS says "...we oppose any string criteria based on morality and public order".

ii. Other Constituencies did not address this recommendation in their CISs. The Implementation Team has tried to balance these views by establishing an Implementation Plan that recognises the practical effect of opening a new top-level domain application system that will attract applications that some members of the community do not agree with. Whilst ICANN does have a technical co-ordination remit, it must also put in place a system of handling objections to strings or to applicants, using pre-published criteria, that is fair and predictable for applicants. It is also necessary to develop guidance for independent evaluators tasked with making decisions about objections.

iii. In its consideration of public policy aspects of new top-level domains the Committee examined the approach taken in a wide variety of jurisdictions to issues of morality and public order. This was done not to make decisions about acceptable strings but to provide a series of potential tests for independent evaluators to use should an objection be raised to an application. The use of the phrase "morality and public order" within the recommendation was done to set some guidelines for potential applicants about areas that may raise objections. The phrasing was also intended to set parameters for potential objectors so that any objection to an application could be analysed within the framework of broadly accepted legal norms that independent evaluators could use across a broad spectrum of possible objections. The Committee also sought to ensure that the objections process would have parameters set for who could object. Those suggested parameters are found within the Implementation Guidelines.

iv. In reaching its decision about the recommendation, the Committee sought to be consistent with, for example, 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.

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

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

vii. 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)

viii. This recommendation has been the subject of detailed Committee and small group work in an attempt to reach consensus about both the text of the recommendation and the examples included as guidance about generally accepted legal norms. The work has been informed by detailed discussion within the GAC and through interactions between the GNSO Committee and the GAC.

6. Recommendation 7 Discussion -- Applicants must be able to demonstrate their technical capability to run a registry operation for the purpose that the applicant sets out.

i. This recommendation is supported by all GNSO Constituencies and Ms Doria.

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

iii. Reference was made to 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[68] 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.

iv. This recommendation is referred to in two CISs. "The ISPCP considers recommendations 7 and 8 to be fundamental. The technical, financial, organisational and operational capabilities of the applicant are the evaluators' instruments for preventing potential negative impact on a new string on the activities of our sector (and indeed of many other sectors)." The NCUC submitted "...we record that this must be limited to transparent, predictable and minimum technical requirements only. These must be published. They must then be adhered to neutrally, fairly and without discrimination."

v. The GAC supported this direction in its Public Policy Principles 2.6, 2.10 and 2.11.

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

i. This recommendation is supported by all GNSO Constituencies and accepted with concern by Ms Doria[69].

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

iii. This is also consistent with best practice procurement guidelines recommended by the World Bank (www.worldbank.org), the OECD (www.oecd.org) and the Asian Development Bank (www.adb.org) as well as a range of federal procurement agencies such as the UK telecommunications regulator, Ofcom; the US Federal Communications Commission and major public companies.

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

v. The ISPCP discussed the importance of this recommendation in its CIS, as found in Recommendation 7 above.

vi. The NCUC's CIS addressed this recommendation by saying "...we support this recommendation to the extent that the criteria is truly limited to minimum financial and organizational operationally capability...All criteria must be transparent, predictable and minimum. They must be published. They must then be adhered to neutrally, fairly and without discrimination."

vii. The GAC echoed these views in its Public Policy Principle 2.5 that said "...the evaluation and selection procedure for new gTLD registries should respect the principles of fairness, transparency and non-discrimination. All applicants for a new gTLD registry should therefore be evaluated against transparent and predictable criteria, fully available to the applicants prior to the initiation of the process. Normally, therefore, no subsequent additional selection criteria should be used in the selection process."

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

i. This recommendation is supported by all GNSO Constituencies and by Ms Doria. It is 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 processes.

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.

iv. The RyC reiterated its support for this recommendation in its CIS. It said that "...this Recommendation is of major importance to the RyC because the majority of constituency members incurred unnecessarily high costs in previous rounds of new gTLD introductions as a result of excessively long time periods from application submittal until they were able to start their business. We believe that a significant part of the delays were related to selection criteria and processes that were too subjective and not very measurable. It is critical in our opinion that the process for the introduction of new gTLDs be predictable in terms of evaluation requirements and timeframes so that new applicants can properly scope their costs and develop reliable implementation plans." The NCUC said that "...we strongly support this recommendation and again stress the need for all criteria to be limited to minimum operational, financial, and technical considerations. We all stress the need that all evaluation criteria be objective and measurable."

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

i. This recommendation is supported by all GNSO Constituencies and by Ms Doria.

ii. 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 subsequent contract negotiations.

iii. A framework for the base contract was developed for discussion at the June 2007 ICANN meeting in Puerto Rico. The base contract will not be completed until the policy recommendations are in place. Completion of the policy recommendations will enable the completion of a draft base contract that would be available to applicants prior to the start of the new gTLD process, that is, prior to the beginning of the four-month window preceding the application submittal period.

iv. The RyC, in its CIS, said, "...like the comments for Recommendation 9, we believe that this recommendation will facilitate a more cost-effective and timely application process and thereby minimize the negative impacts of a process that is less well-defined and objective. Having a clear understanding of base contractual requirements is essential for a new gTLD applicant in developing a complete business plan."

10. Recommendation 11 Discussion -- (This recommendation has been removed and is left intentionally blank. Note Recommendation 20 and its Implementation Guidelines).

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

i. This recommendation is supported by all GNSO Constituencies and Ms Doria.

ii. The Committee has provided clear direction on its expectations that all the dispute resolution and challenge processes would be established prior to the opening of the application round. The full system will be published prior to an application round starting. However, the finalisation of this process is contingent upon a completed set of recommendations being agreed; a public comment period and the final agreement of the ICANN Board.

iii. The draft Implementation Plan in the Implementation Team Discussion Points document sets out the way in which the ICANN Staff proposes that disputes between applicants and challenge processes may be handled. Expert legal and other professional advice from, for example, auctions experts is being sought to augment the Implementation Plan.

TERM OF REFERENCE THREE -- ALLOCATION METHODS

12. Recommendation 13 Discussion -- Applications must initially be assessed in rounds until the scale of demand is clear.

i. This recommendation is supported by all GNSO Constituencies and Ms Doria.

ii. This recommendation sets out the principal allocation methods for TLD applications. The narrative here should be read in conjunction with the draft flowcharts and the draft Request for Proposals.

iii. An application round would be opened on Day 1 and closed on an agreed date in the future with an unspecified number of applications to be processed within that round.

iv. This recommendation may be amended, after an evaluation period and report that may suggest modifications to this system. The development of objective "success metrics" is a necessary part of the evaluation process that could take place within the new TLDs Project Office.

v. The ISPCP expressed its support for this recommendation. Its CIS said that "...this is an essential element in the deployment of new gTLDs, as it enables any technical difficulties to be quickly identified and sorted out, working with reduced numbers of new strings at a time, rather than many all at once. Recommendation 18 on the use of IDNs is also important in preventing any negative impact on network operators and ISPs."

13. Recommendation 20 Discussion -- An application will be rejected if an expert panel determines that there is substantial opposition to it from a significant portion of the community to which the string may be explicitly or implicitly targeted.

i. This recommendation is supported by the majority of GNSO Constituencies. Ms Doria supports the recommendation but has concerns about its implementation[70]. The NCUC has submitted a Minority Statement which is found in full in Annex C about the recommendation and its associated Implementation Guidelines F, H and P.

ii. This recommendation was developed during the preparations for the Committee's 7 June 2007 conference call and during subsequent Committee deliberations. The intention was to factor into the process the very likely possibility of objections to applications from a wide variety of stakeholders.

iii. The language used here is relatively broad and the implementation impact of the proposed recommendation is discussed in detail in the Implementation Team's Discussion Points document.

iv. The NCUC's response to this recommendation in its earlier CIS says, in part, "...recommendation 20 swallows up any attempt to narrow the string criteria to technical, operational and financial evaluations. It asks for objections based on entirely subjective and unknowable criteria and for unlimited reasons and by unlimited parties." This view has, in part, been addressed in the Implementation Team's proposed plan but this requires further discussion and agreement by the Committee.


TERM OF REFERENCE FOUR -- CONTRACTUAL CONDITIONS

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

i. The remainder of the recommendations address Term of Reference Four on policies for contractual conditions and should be read in conjunction with Recommendation 10 on the provision of a base contract prior to the opening of an application round. The recommendation is supported by all GNSO Constituencies and Ms Doria.

ii. This recommendation is consistent with the existing registry contract provisions found in, for example, the .com and .biz agreements.

iii. These conditions would form the baseline conditions of term length for new TLD operators. It was determined that a term of ten years would reasonably balance the start up costs of registry operations with reasonable commercial terms.

iv. The RyC commented on this recommendation in its CIS saying that "...the members of the RyC have learned first hand that operating a registry in a secure and stable manner is a capital intensive venture. Extensive infrastructure is needed both for redundant registration systems and global domain name constellations. Even the most successful registries have taken many years to recoup their initial investment costs. The RyC is convinced that these two recommendations [14 & 15] will make it easier for new applicants to raise the initial capital necessary and to continue to make investments needed to ensure the level of service expected by registrants and users of their TLDs. These two recommendations will have a very positive impact on new gTLD registries and in turn on the quality of the service they will be able to provide to the Internet community."

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

i. This recommendation is consistent with the existing registry contract provisions found in, for example, the .com and .biz agreements and is supported by all Constituencies. Ms Doria supported the recommendation and provided the comments found in the footnote below.[71]

ii. These conditions would form the baseline conditions of term length for new TLD operators. It was determined that a term of ten years would reasonably balance the start up costs of registry operations with reasonable commercial terms.

iii. See the CIS comments from the RyC in the previous section.

16. Recommendation 16 -- Registries must apply existing Consensus Policies[72] and adopt new Consensus Policies as they are approved.

i. This recommendation is supported by all GNSO Constituencies and Ms Doria.

ii. The full set of existing ICANN registry contracts can be found here http://www.icann.org/registries/agreements.htm and ICANN's seven current Consensus Policies are found at http://www.icann.org/general/consensus-policies.htm.

iii. ICANN develops binding Consensus Policies through its policy development processes, in this case, through the GNSO[73].

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

i. This recommendation is supported by all GNSO Constituencies and Ms Doria.

ii. Referring to the recommendations on contractual conditions 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[74].

iii. The Committee developed its recommendations during the Brussels and Amsterdam face-to-face consultations, with assistance from the ICANN General Counsel's office. The General Counsel's office has also provided a draft base contract which will be completed once the policy recommendations are agreed. Reference should also be made to Recommendation 5 on reserved words as some of the findings could be part of the base contract.

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

v. Since then ICANN has developed and published a new approach to its compliance activities. These are found on ICANN's website at http://www.icann.org/compliance/ and will be part of the development of base contract materials.

vi. The Committee found a number of expert reports[75] 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 favouring 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."

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

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

i. This recommendation is supported by all GNSO Constituencies and Ms Doria. The introduction of internationalised domain names at the root presents ICANN with a series of implementation challenges. This recommendation would apply to any new gTLD (IDN or ASCII TLD) offering IDN services. The initial technical testing[76] has been completed and a series of live root tests will take place during the remainder of 2007.

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 and the GAC and ccNSO joint working group on IDNs.

19. Recommendation 19 Discussion -- Registries must use only ICANN accredited registrars in registering domain names and may not discriminate among such accredited registrars.

i. This recommendation is supported by all GNSO Constituencies and Ms Doria.

ii. There is a long history associated with the separation of registry and registrar operations for top-level domains. The structural separation of VeriSign's registry operations from Network Solutions registrar operations explains much of the ongoing policy to require the use of ICANN accredited registrars.

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

iv. ICANN's Registrar Accreditation Agreement has been in place since 2001[77]. Detailed information about the accreditation of registrars can be found on the ICANN website[78]. The accreditation process is under active discussion but the critical element of requiring the use of ICANN accredited registrars remains constant.

v. In its CIS, the RyC noted that "...the RyC has no problem with this recommendation for larger gTLDs; the requirement to use accredited registrars has worked well for them. But it has not always worked as well for very small, specialized gTLDs. The possible impact on the latter is that they can be at the mercy of registrars for whom there is no good business reason to devote resources. In the New gTLD PDP, it was noted that this requirement would be less of a problem if the impacted registry would become a registrar for its own TLD, with appropriate controls in place. The RyC agrees with this line of reasoning but current registry agreements forbid registries from doing this. Dialog with the Registrars Constituency on this topic was initiated and is ongoing, the goal being to mutually agree on terms that could be presented for consideration and might provide a workable solution."


NEXT STEPS

1. Under the GNSO's Policy Development Process, the production of this Final Report completes Stage 9. The next steps are to conduct a twenty-day public comment period running from 10 August to 30 August 2007. The GNSO Council is due to meet on 6 September 2007 to vote on the package of principles, policy recommendations and implementation guidelines.

2. After the GNSO Council have voted the Council Report to the Board is prepared. The GNSO's PDP guidelines stipulate that "the Staff Manager will be present at the final meeting of the Council, and will have five (5) calendar days after the meeting to incorporate the views of the Council into a report to be submitted to the Board (the "Board Report"). The Board Report must contain at least the following:

a. A clear statement of any Supermajority Vote recommendation of the Council;

b. If a Supermajority Vote was not reached, a clear statement of all positions held by Council members. Each statement should clearly indicate (i) the reasons underlying each position and (ii) the constituency(ies) that held the position;

c. An analysis of how the issue would affect each constituency, including any financial impact on the constituency;

d. An analysis of the period of time that would likely be necessary to implement the policy;

e. The advice of any outside advisors relied upon, which should be accompanied by a detailed statement of the advisor's (i) qualifications and relevant experience; and (ii) potential conflicts of interest;

f. The Final Report submitted to the Council; and

g. A copy of the minutes of the Council deliberation on the policy issue, including the all opinions expressed during such deliberation, accompanied by a description of who expressed such opinions.

3. It is expected that, according to the Bylaws, "...The Board will meet to discuss the GNSO Council recommendation as soon as feasible after receipt of the Board Report from the Staff Manager. In the event that the Council reached a Supermajority Vote, the Board shall adopt the policy according to the Council Supermajority Vote recommendation unless by a vote of more than sixty-six (66%) percent of the Board determines that such policy is not in the best interests of the ICANN community or ICANN. In the event that the Board determines not to act in accordance with the Council Supermajority Vote recommendation, the Board shall (i) articulate the reasons for its determination in a report to the Council (the "Board Statement"); and (ii) submit the Board Statement to the Council. The Council shall review the Board Statement for discussion with the Board within twenty (20) calendar days after the Council's receipt of the Board Statement. The Board shall determine the method (e.g., by teleconference, e-mail, or otherwise) by which the Council and Board will discuss the Board Statement. At the conclusion of the Council and Board discussions, the Council shall meet to affirm or modify its recommendation, and communicate that conclusion (the "Supplemental Recommendation") to the Board, including an explanation for its current recommendation. In the event that the Council is able to reach a Supermajority Vote on the Supplemental Recommendation, the Board shall adopt the recommendation unless more than sixty-six (66%) percent of the Board determines that such policy is not in the interests of the ICANN community or ICANN. In any case in which the Council is not able to reach Supermajority, a majority vote of the Board will be sufficient to act. When a final decision on a GNSO Council Recommendation or Supplemental Recommendation is timely, the Board shall take a preliminary vote and, where practicable, will publish a tentative decision that allows for a ten (10) day period of public comment prior to a final decision by the Board."

4. The final stage in the PDP is the implementation of the policy which is also governed by the Bylaws as follows, "...Upon a final decision of the Board, the Board shall, as appropriate, give authorization or direction to the ICANN staff to take all necessary steps to implement the policy."


Annex A – NCUC Minority Statement: Recommendation 6

Statement of DISSENT on Recommendation #6 of

GNSO's New GTLD Report from

the Non-Commercial Users Constituency (NCUC)

20 July 2007

NCUC supports most of the recommendations in the GNSO's Final Report, but Recommendation #6 is one we cannot support.[79]

We oppose Recommendation #6 for the following reasons:

1) It will completely undermine ICANN's efforts to make the gTLD application process predictable, and instead make the evaluation process arbitrary, subjective and political;

2) It will have the effect of suppressing free and diverse expression;

3) It exposes ICANN to litigation risks;

4) It takes ICANN too far away from its technical coordination mission and into areas of legislating morality and public order.

We also believe that the objective of Recommendation #6 is unclear, in that much of its desirable substance is already covered by Recommendation #3. At a minimum, we believe that the words "relating to morality and public order" must be struck from the recommendation.

1) Predictability, Transparency and Objectivity

Recommendation #6 poses severe implementation problems. It makes it impossible to achieve the GNSO's goals of predictable and transparent evaluation criteria for new gTLDs.

Principle 1 of the New gTLD Report states that the evaluation process must be "predictable," and Recommendation #1 states that the evaluation criteria must be transparent, predictable, and fully available to applicants prior to their application.

NCUC strongly supports those guidelines. But no gTLD applicant can possibly know in advance what people or governments in a far away land will object to as "immoral" or contrary to "public order." When applications are challenged on these grounds, applicants cannot possibly know what decision an expert panel – which will be assembled on an ad hoc basis with no precedent to draw on – will make about it.

Decisions by expert panels on "morality and public order" must be subjective and arbitrary, because there is no settled and well-established international law regarding the relationship between TLD strings and morality and public order. There is no single "community standard" of morality that ICANN can apply to all applicants in every corner of the globe. What is considered "immoral" in Teheran may be easily accepted in Los Angeles or Stockholm; what is considered a threat to "public order" in China and Russia may not be in Brazil and Qatar.

2) Suppression of expression of controversial views

gTLD applicants will respond to the uncertainty inherent in a vague "morality and public order" standard and lack of clear standards by suppressing and avoiding any ideas that might generate controversy. Applicants will have to invest sizable sums of money to develop a gTLD application and see it through the ICANN process. Most of them will avoid risking a challenge under Recommendation #6. In other words, the presence of Recommendation #6 will result in self-censorship by most applicants.

That policy would strip citizens everywhere of their rights to express controversial ideas because someone else finds them offensive. This policy recommendation ignores international and national laws, in particular freedom of expression guarantees that permit the expression of "immoral" or otherwise controversial speech on the Internet.

3) Risk of litigation

Some people in the ICANN community are under the mistaken impression that suppressing controversial gTLDs will protect it from litigation. Nothing could be further from the truth. By introducing subjective and culturally divisive standards into the evaluation process Recommendation #6 will increase the likelihood of litigation.

ICANN operates under authority from the US Commerce Department. It is undisputed that the US Commerce Department is prohibited from censoring the expression of US citizens in the manner proposed by Recommendation #6. The US Government cannot "contract away" the constitutional protections of its citizens to ICANN any more than it can engage in the censorship itself.

Adoption of Recommendation #6 invites litigation against ICANN to determine whether its censorship policy is compatible with the US First Amendment. An ICANN decision to suppress a gTLD string that would be permitted under US law could and probably would lead to legal challenges to the decision as a form of US Government action.

If ICANN left the adjudication of legal rights up to courts, it could avoid the legal risk and legal liability that this policy of censorship brings upon it.

4) ICANN's mission and core values

Recommendation #6 exceeds the scope of ICANN's technical mission. It asks ICANN to create rules and adjudicate disputes about what is permissible expression. It enables it to censor expression in domain names that would be lawful in some countries. It would require ICANN and "expert panels" to make decisions about permitting top-level domain names based on arbitrary "morality" judgments and other subjective criteria. Under Recommendation #6, ICANN will evaluate domain names based on ideas about "morality and public order" -- concepts for which there are varying interpretations, in both law and culture, in various parts of the world. Recommendation #6 risks turning ICANN into the arbiter of "morality" and "appropriate" public policy through global rules.

This new role for ICANN conflicts with its intended narrow technical mission, as embodied in its mission and core values. ICANN holds no legitimate authority to regulate in this entirely non-technical area and adjudicate the legal rights of others. This recommendation takes the adjudication of people's rights to use domain names out of the hands of democratically elected representatives and into the hands of "expert panels" or ICANN staff and board with no public accountability.

Besides exceeding the scope of ICANN's authority, Recommendation #6 seems unsure of its objective. It mandates "morality and public order" in domain names, but then lists, as examples of the type of rights to protect, the WTO TRIPS Agreement and all 24 World Intellectual Property (WIPO) Treaties, which deal with economic and trade rights, and have little to do with "morality and public order". Protection for intellectual property rights was fully covered in Recommendation #3, and no explanation has been provided as to why intellectual property rights would be listed again in a recommendation on "morality and public order", an entirely separate concept.

In conclusion Recommendation #6 exceeds ICANN's authority, ignores Internet users' free expression rights, and its adoption would impose an enormous burden on and liability for ICANN. It should not be adopted by the Board of Directors in the final policy decision for new gtlds.


Annex B – Nominating Committee Appointee Avri Doria[80]: Individual Comments

Comments from Avri Doria

The "Personal level of support" indications fall into 3 categories:

l Support: these are principles, recommendations or guidelines that are compatible with my personal opinions

l Support with concerns: While these principles, recommendations and guidelines are not incompatible with my personal opinions, I have some concerns about them.

l Accept with concern: these recommendations and guidelines do not necessarily correspond to my personal opinions, but I am able to accept them in that they have the broad support of the committee. I do, however, have concerns with these recommendations and guideline.

I believe these comments are consistent with comments I have made throughout the process and do not constitute new input.

Principles

#

Personal level of support

Explanation

A

Support

B

Support with concerns

While I strongly support the introduction of IDN TLDS, I am concerned that the unresolved issues with IDN ccTLD equivalents may interfere with the introduction of IDN TLDs. I am also concerned that some of these issues could impede the introduction of some new ASCII TLDs dealing with geographically related identifiers.

C

Support

D

Support with concerns

While I favor the establishment of a minimum set of necessary technical criteria, I am concerned that this set actually be the basic minimum set necessary to protect the stability, security and global interoperability.

E-G

Support

Recommendations

#

Level of support

Explanation

1

Support

2

Accept with concern

My concern involves using definitions that rely on legal terminology established for trademarks for what I believe should be a policy based on technical criteria.

l In the first instance I believe that this is essentially a technical issue that should have been resolved with reference to typography, homologues, orthographic neighbourhood, transliteration and other technically defined attributes of a name that would make it unacceptable. There is a large body of scientific and technical knowledge and description in this field that we could have drawn on.

l By using terms that rely on the legal language of trademark law, I believe we have created an implicit redundancy between recommendations 2 and 3. I.e., I believe both 2 and 3 can be used to protect trademarks and other intellectual property rights, and while 3 has specific limitations, 2 remains open to full and varied interpretation.

l As we begin to consider IDNs, I am concerned that the interpretations of confusingly similar may be used to eliminate many potential TLDs based on translation. That is, when a translation may have the same or similar meaning to an existing TLD, that the new name may be eliminated because it is considered confusing to users who know both languages.

3

Support with concerns

My first concern relates to the protection of what can be called the linguistic commons. While it is true that much of trademark law and practice does protect general vocabulary and common usage from trademark protection, I am not sure that this is always the case in practice.

I am also not convinced that trademark law and policy that applies to specific product type within a specific locale is entirely compatible with a general and global naming system.

4

Support

5

Support with concerns

Until such time as the technical work on IDNAbis is completed, I am concerned about establishing reserved name rules connected to IDNs. My primary concern involves policy decisions made in ICANN for reserved names becoming hard coded in the IDNAbis technical solution and thus becoming technical constraints that are no longer open to future policy reconsideration.

6

Accept with concern

My primary concern focuses on the term 'morality'. While public order is frequently codified in national laws and occasionally in international law and conventions, the definition of what constitutes morality is not generally codified, and when it is, I believe it could be referenced as public order.

This concern is related to the broad set of definitions used in the world to define morality. By including morality in the list of allowable exclusions we have made the possible exclusion list indefinitely large and have subjected the process to the consideration of all possible religious and ethical systems. ICANN or the panel of reviewers will also have to decide between different sets of moral principles, e.g, a morality that holds that people should be free to express themselves in all forms of media and those who believe that people should be free from exposure to any expression that is prohibited by their faith or moral principles. This recommendation will also subject the process to the fashion and occasional demagoguery of political correctness. I do not understand how ICANN or any expert panel will be able to judge that something should be excluded based on reasons of morality without defining, at least de-facto, an ICANN definition of morality? And while I am not a strict constructionist and sometimes allow for the broader interpretation of ICANN's mission, I do not believe it includes the definition of a system of morality.

7

Support

8

Accept with concern

While I accept that a prospective registry must show adequate operational capability, creating a financial criteria is of concern. There may be many different ways of satisfying the requirement for operational capability and stability that may not be demonstrable in a financial statement or traditional business plan. E.g., in the case of an less developed community, the registry may rely on volunteer effort from knowledgeable technical experts.

Another concern I have with financial requirements and high application fees is that they may act to discourage applications from developing nations or indigenous and minority peoples that have a different set of financial opportunities or capabilities then those recognized as acceptable within an expensive and highly developed region such as Los Angeles or Brussels.

9,10, 12-14

Support

15

Support with concerns

In general I support the idea that a registry that is doing a good job should have the expectancy of renewal. I do, however, believe that a registry, especially a registry with general market dominance, or specific or local market dominance, should be subject to comment from the relevant user public and to evaluation of that public comment before renewal. When performance is satisfactory, there should an expectation of renewal. When performance is not satisfactory, there should be some procedure for correcting the situation before renewal.

16-19

Support

20

Support with concerns

In general I support the policy though I do have concerns about the implementation which I discuss below in relation to IG (P)

Implementation Guidelines

#

Level of support

Explanation

A-E

Support

F

Accept with concern

In designing a New gTLD process, one of the original design goals had been to design a predictable and timely process that did not include the involvement of the Board of Directors except for very rare and exceptional cases and perhaps in the due diligence check of a final approval. My concern is that the use of Board in step (iii) may make them a regular part of many of the application procedure and may overload both the Board and the process. If every dispute can fall through to Board consideration in the process sieve, then the incentive to resolve the dispute earlier will be lessened.

G-M

Support

N

Support with concerns

I strongly support the idea of financial assistance programs and fee reduction for less developed communities. I am concerned that not providing pricing that enables applications from less developed countries and communities may serve to increase the divide between the haves and the haves nots in the Internet and may lead to a foreign 'land grab' of choice TLD names, especially IDN TLD names in a new form of resource colonialism because only those with well developed funding capability will be able to participate in the process as currently planned.

O

Support

P

Support with concerns

While I essentially agree with the policy recommendation and its implementation guideline, its social justice and fairness depends heavily on the implementation issues. While the implementation details are not yet settled, I have serious concerns about the published draft plans of the ICANN staff in this regard. The current proposal involves using fees to prevent vexatious or unreasonable objections. In my personal opinion this would be a cause of social injustice in the application of the policy as it would prejudice the objection policy in favor of the rich. I also believe that an objection policy based on financial means would allow for well endowed entities to object to any term they found objectionable, hence enabling them to be as vexatious as they wish to be.

In order for an objection system to work properly, it must be fair and it must allow for any applicant to understand the basis on which they might have to answer an objection. If the policy and implementation are clear about objections only being considered when they can be shown to cause irreparable harm to a community then it may be possible to build a just process. In addition to the necessity for there to be strict filters on which potential objections are actually processed for further review by an objections review process, it is essential that an external and impartial professional review panel have a clear basis for judging any objections.

I do not believe that the ability to pay for a review will provide a reasonable criteria, nor do I believe that financial barriers are an adequate filter for stopping vexatious or unreasonable objections though they are a sufficient barrier for the poor.

I believe that ICANN should investigate other methods for balancing the need to allow even the poorest to raise an issue of irreparable harm while filtering out unreasonable disputes. I believe, as recommend in the Reserved Names Working group report, that the ALAC and GAC may be an important part of the solution. IG (P) currently includes support for treating ALAC and GAC as established institutions in regard to raising objections to TLD concerns. I believe this is an important part of the policy recommendation and should be retained in the implementation. I believe that it should be possible for the ALAC or GAC, through some internal procedure that they define, to take up the cause of the individual complainant and to request a review by the external expert review panel. Some have argued that this is unacceptable because it operationalizes these Advisory Committees. I believe we do have precedence for such an operational role for volunteers within ICANN and that it is in keeping with their respective roles and responsibilities as representatives of the user community and of the international community of nations. I strongly recommend that such a solution be included in the Implementation of the New gTLD process.

Q

Support


Annex C – NCUC Minority Statement: Recommendation 20 and Implementation Guidelines F, H & P

Statement of DISSENT on Recommendation #20 &

Implementation Guidelines F, H, & P in the

GNSO New GTLD Committee's Final Report

from the

Non-Commercial Users Constituency (NCUC)

RE: Domain Name Objection and Rejection Process

25 July 2007

Text of Recommendation #20:

"An application will be rejected if an expert panel determines that there is substantial opposition to it from a significant portion of the community to which the string may be explicitly or implicitly targeted."

Text of Implementation Guideline F:

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 claim to support a community by one party will be a reason to award priority to that application. If there is no such claim, and 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.

Text of Implementation Guideline H:

External dispute providers will give decisions on complaints.

Text of Implementation Guideline P:

The following process, definitions, and guidelines refer to Recommendation 20.

Process

Opposition must be objection based.

Determination will be made by a dispute resolution panel constituted for the purpose.

The objector must provide verifiable evidence that it is an established institution of the community (perhaps like the RSTEP pool of panelists from which a small panel would be constituted for each objection).

Guidelines

The task of the panel is the determination of substantial opposition.

a) substantial

In determining substantial the panel will assess the following: significant portion, community, explicitly targeting, implicitly targeting, established institution, formal existence, detriment.

b) significant portion:

In determining significant portion the panel will assess the balance between the level of objection submitted by one or more established institutions and the level of support provided in the application from one or more established institutions. The panel will assess significance proportionate to the explicit or implicit targeting.

c) community

Community should be interpreted broadly and will include for example an economic sector, a cultural community, or a linguistic community. It may also be a closely related community which believes it is impacted.

d) explicitly targeting

Explicitly targeting means there is a description of the intended use of the TLD in the application.

e) implicitly targeting

Implicitly targeting means that the objector makes an assumption of targeting or that the objector believes there may be confusion by users over its intended use.

f) established institution

An institution that has been in formal existence for at least 5 years. In exceptional cases, standing may be granted to an institution that has been in existence for fewer then 5 years. Exceptional circumstance include but are not limited to reorganisation, merger, or an inherently younger community. The following ICANN organizations are defined as established institutions: GAC, ALAC, GNSO, ccNSO, ASO.

g) formal existence

Formal existence may be demonstrated by: appropriate public registration, public historical evidence, validation by a government, intergovernmental organization, international treaty organisation or similar.

h) detriment

<< A >> Evidence of detriment to the community or to users more widely must be provided.

<< B >> [A likelihood of detriment to the community or to users more widely must be provided.]

Recommendation #20

The Non-Commercial Users Constituency (NCUC) Dissenting Statement on Recommendation #20 of the New GTLD Committee's Final Report[81] should be read in combination with Implementation Guidelines F, H & P, which detail the implementation of Recommendation #20. This statement should also be read in conjunction with its statement[82] of 13 June 2007 on the committee's draft report.

NCUC cannot support the committee's proposal for ICANN to establish a broad objection and rejection process for domain names that empowers ICANN and its "experts" to adjudicate the legal rights of domain name applicants (and objectors). The proposal would also empower ICANN and its "experts" to invent entirely new rights to domain names that do not exist in law and that will compete with existing legal rights to domains.

However "good-intentioned", the proposal would inevitably set up a system that decides legal rights based on subjective beliefs of "expert panels" and the amount of insider lobbying. The proposal would give "established institutions" veto power over applications for domain names to the detriment of innovators and start-ups. The proposal is further flawed because it makes no allowances for generic words to which no community claims exclusive "ownership" of. Instead, it wants to assign rights to use language based on subjective standards and will over-regulate to the detriment of competition, innovation, and free expression.

There is no limitation on the type of objections that can be raised to kill a domain name, no requirement that actual harm be shown to deny an application, and no recourse for the wrongful denial of legal rights by ICANN and its experts under this proposal. An applicant must be able to appeal decisions of ICANN and its experts to courts, who have more competence and authority to decide the applicant's legal rights. Legal due process requires maintaining a right to appeal these decisions to real courts.

The proposal is hopelessly flawed and will result in the improper rejection of many legitimate domain names. The reasons permitted to object to a domain are infinite in number. Anyone may make an objection; and an application will automatically be rejected upon a very low threshold of "detriment" or an even lower standard of "a likelihood of detriment" to anyone. Not a difficult bar to meet.

If ICANN attempted to put this policy proposal into practice it would intertwine itself in general policy debates, cultural clashes, business feuds, religious wars, and national politics, among a few of the disputes ICANN would have to rule on through this domain name policy.

The proposal operates under false assumptions of "communities" that can be defined, and that parties can be rightfully appointed representatives of "the community" by ICANN. The proposal gives preference to "established institutions" for domain names, and leaves applicants' without the backing of "established institutions" with little right to a top-level domain. The proposal operates to the detriment of small-scale start-ups and innovators who are clever enough to come up with an idea for a domain first, but lack the insider-connections and financial resources necessary to convince an ICANN panel of their worthiness.

It will be excessively expensive to apply for either a controversial or a popular domain name, so only well-financed "established institutions" will have both the standing and financial wherewithal to be awarded a top-level domain. The proposal privileges who is awarded a top-level domain, and thus discourages diversity of thought and the free flow of information by making it more difficult to obtain information on controversial ideas or from innovative new-comers.

Implementation Guideline F

NCUC does not agree with the part of Implementation Guideline F that empowers ICANN identified "communities" to support or oppose applications. Why should all "communities" agree before a domain name can be issued? How to decide who speaks for a "community"?

NCUC also notes that ICANN's Board of Directors would make the final decisions on applications and thus the legal rights of applicants under proposed IG-F. ICANN Board Members are not democratically elected, accountable to the public in any meaningful way, or trained in the adjudication of legal rights. Final decisions regarding legal rights should come from legitimate law-making processes, such as courts.

"Expert panels" or corporate officers are not obligated to respect an applicant's free expression rights and there is no recourse for a decision by the panel or ICANN for rights wrongfully denied. None of the "expert" panelists are democratically elected, nor accountable to the public for their decisions. Yet they will take decisions on the boundaries between free expression and trademark rights in domain names; and "experts" will decide what ideas are too controversial to be permitted in a domain name under this process.

Implementation Guideline H

Implementation Guideline H recommends a system to adjudicate legal rights that exists entirely outside of legitimate democratic law-making processes. The process sets up a system of unaccountable "private law" where "experts" are free to pick and choose favored laws, such as trademark rights, and ignore disfavored laws, such as free expression guarantees.

IG-H operates under the false premise that external dispute providers are authorized to adjudicate the legal rights of domain name applicants and objectors. It further presumes that such expert panels will be qualified to adjudicate the legal rights of applicants and others. But undertaking the creation of an entirely new international dispute resolution process for the adjudication of legal rights and the creation of new rights is not something that can be delegated to a team of experts. Existing international law that takes into account conflict of laws, choice of laws, jurisdiction, standing, and due process must be part of any legitimate process; and the applicant's legal rights including freedom of expression rights must be respected in the process.

Implementation Guideline P

"The devil is in the details" of Implementation Guideline P as it describes in greater detail the proposed adversarial dispute process to adjudicate legal rights to top-level domain names in Recommendation #20. IG-P mandates the rejection of an application if there is "substantial opposition" to it according to ICANN's expert panel. But "substantial" is defined in such as way so as to actually mean "insubstantial" and as a result many legitimate domain names would be rejected by such an extremely low standard for killing an application.

Under IG-P, opposition against and support for an application must be made by an "established institution" for it to count as "significant", again favoring major industry players and mainstream cultural institutions over cultural diversity, innovative individuals, small niche, and medium-sized Internet businesses.

IG-P states that "community" should be interpreted broadly, which will allow for the maximum number of objections to a domain name to count against an application. It includes examples of "the economic sector, cultural community or linguistic community" as those who have a right to complain about an application. It also includes any "related community which believes it is impacted." So anyone who claims to represent a community and believes to be impacted by a domain name can file a complaint and have standing to object to another's application.

There is no requirement that the objection be based on legal rights or the operational capacity of the applicant. There is no requirement that the objection be reasonable or the belief about impact to be reasonable. There is no requirement that the harm be actual or verifiable. The standard for "community" is entirely subjective and based on the personal beliefs of the objector.

The definition of "implicitly targeting" further confirms this subjective standard by inviting objections where "the objector makes the assumption of targeting" and also where "the objector believes there may be confusion by users". Such a subjective process will inevitably result in the rejection of many legitimate domain names.

Picking such a subjective standard conflicts with Principle A in the Final Report that states domain names must be introduced in a "predictable way", and also with Recommendation 1 that states "All applicants for a new gTLD registry should be evaluated against transparent and predictable criteria, fully available to the applicants prior to the initiation of the process." The subjectivity and unpredictability invited into the process by Recommendation #20 turn Principle A and Recommendation 1 from the same report upside down.

Besides the inherent subjectivity, the standard for killing applications is remarkably low. An application need not be intended to serve a particular community for "community-based" objections to kill the application under the proposal. Anyone who believed that he or she was part of the targeted community or who believes others face "detriment" have standing to object to a domain name, and the objection weighs in favor of "significant opposition". This standard is even lower than the "reasonable person" standard, which would at least require that the belief be "reasonable" for it to count against an applicant. The proposed standard for rejecting domains is so low it even permits unreasonable beliefs about a domain name to weigh against an applicant.

If a domain name does cause confusion, existing trademark law and unfair competition law have dealt with it for years and already balanced intellectual property rights against free expression rights in domain names. There is neither reason nor authority for ICANN processes to overtake the adjudication of legal rights and invite unreasonable and illegitimate objections to domain names.

IG-P falsely assumes that the number of years in operation is indicative of one's right to use language. It privileges entities over 5 years old with objection rights that will effectively veto innovative start-ups who cannot afford the dispute resolution process and will be forced to abandon their application to the incumbents.

IG-P sets the threshold for harm that must be shown to kill an application for a domain name remarkably low. Indeed harm need not be actual or verified for an application to be killed based on "substantial opposition" from a single objector.

Whether the committee selects the unbounded definition for "detriment" that includes a "likelihood of detriment" or the narrower definition of "evidence of detriment" as the standard for killing an application for a domain name is largely irrelevant. The difference is akin to re-arranging the deck chairs on the Titanic. ICANN will become bogged down with the approval of domain names either way, although it is worth noting that "likelihood of detriment" is a very long way from "substantial harm" and an easy standard to meet, so will result in many more domain names being rejected.

The definitions and guidelines detailed in IG-P invite a lobby-fest between competing businesses, instill the "heckler's veto" into domain name policy, privilege incumbents, price out of the market non-commercial applicants, and give third-parties who have no legal rights to domain names the power to block applications for those domains. A better standard for killing an application for non-technical reasons would be for a domain name to be shown to be illegal in the applicant's jurisdiction before it can rejected.

In conclusion, the committee's recommendation for domain name objection and rejection processes are far too broad and unwieldy to be put into practice. They would stifle freedom of expression, innovation, cultural diversity, and market competition. Rather than follow existing law, the proposal would set up an illegitimate process that usurps jurisdiction to adjudicate peoples' legal rights (and create new rights) in a process designed to favor incumbents. The adoption of this "free-for-all" objection and rejection process will further call into question ICANN's legitimacy to govern and its ability to serve the global public interest that respects the rights of all citizens.

NCUC respectfully submits that ICANN will best serve the global public interest by resisting the temptation to stray from its technical mandate and meddle in international lawmaking as proposed by Rec. #20 and IG-F, IG-H, and IG-P of the New GTLD Committee Final Report.

REFERENCE MATERIAL -- GLOSSARY[83]

TERM

ACRONYM & EXPLANATION

A-label

The A-label is what is transmitted in the DNS protocol and this is the ASCII-compatible (ACE) form of an IDNA string; for example "xn--11b5bs1di".

ASCII Compatible Encoding

ACE

ACE is a system for encoding Unicode so each character can be transmitted using only the letters a-z, 0-9 and hyphens. Refer also to http://www.ietf.org/rfc/rfc3467.txt?number=3467

American Standard Code for Information Exchange

ASCII

ASCII is a common numerical code for computers and other devices that work with text. Computers can only understand numbers, so an ASCII code is the numerical representation of a character such as 'a' or '@'. See above referenced RFC for more information.

Advanced Research Projects Agency

ARPA

http://www.darpa.mil/body/arpa_darpa.html

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/

Country Code Top Level Domain

ccTLD

Two letter domains, such as .uk (United Kingdom), .de (Germany) and .jp (Japan) (for example), are called country code top level domains (ccTLDs) and correspond to a country, territory, or other geographic location. The rules and policies for registering domain names in the ccTLDs vary significantly and ccTLD registries limit use of the ccTLD to citizens of the corresponding country.

Some ICANN-accredited registrars provide registration services in the ccTLDs in addition to registering names in .biz, .com, .info, .name, .net and .org, however, ICANN does not specifically accredit registrars to provide ccTLD registration services.

For more information regarding registering names in ccTLDs, including a complete database of designated ccTLDs and managers, please refer to http://www.iana.org/cctld/cctld.htm.

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.

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

Domain Name System

The Domain Name System (DNS) helps users to find their way around the Internet. Every computer on the Internet has a unique address - just like a telephone number - which is a rather complicated string of numbers. It is called its "IP address" (IP stands for "Internet Protocol"). IP Addresses are hard to remember. The DNS makes using the Internet easier by allowing a familiar string of letters (the "domain name") to be used instead of the arcane IP address. So instead of typing 207.151.159.3, you can type www.internic.net. It is a "mnemonic" device that makes addresses easier to remember.

Generic Top Level Domain

gTLD

Most TLDs with three or more characters are referred to as "generic" TLDs, or "gTLDs". They can be subdivided into two types, "sponsored" TLDs (sTLDs) and "unsponsored TLDs (uTLDs), as described in more detail below.

In the 1980s, seven gTLDs (.com, .edu, .gov, .int, .mil, .net, and .org) were created. Domain names may be registered in three of these (.com, .net, and .org) without restriction; the other four have limited purposes.

In 2001 & 2002 four new unsponsored TLDs (.biz, .info, .name, and .pro) were introduced. The other three new TLDs (.aero, .coop, and .museum) were sponsored.

Generally speaking, an unsponsored TLD operates under policies established by the global Internet community directly through the ICANN process, while a sponsored TLD is a specialized TLD that has a sponsor representing the narrower community that is most affected by the TLD. The sponsor thus carries out delegated policy-formulation responsibilities over many matters concerning the TLD.

Governmental Advisory Committee

GAC

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

Intellectual Property Constituency

IPC

http://www.ipconstituency.org/

Internet Service & Connection Providers Constituency

ISPCP

Internationalized Domain Names

IDNs

IDNs are domain names represented by local language characters. These domain names may contain characters with diacritical marks (required by many European languages) or characters from non-Latin scripts like Arabic or Chinese.

Internationalized Domain Names in Application

IDNA

IDNA is a protocol that makes it possible for applications to handle domain names with non-ASCII characters. IDNA converts domain names with non-ASCII characters to ASCII labels that the DNS can accurately understand. These standards are developed within the IETF (http://www.ietf.org)

Internationalized Domain Names – Labels

IDN A Label

The A-label is what is transmitted in the DNS protocol and this is the ASCII-compatible ACE) form of an IDN A string. For example "xn-1lq90i".

IDN U Label

The U-label is what should be displayed to the user and is the representation of the IDN in Unicode. For example "北京" ("Beijing" in Chinese).

LDH Label

The LDH-label strictly refers to an all-ASCII label that obeys the "hostname" (LDH) conventions and that is not an IDN; for example "icann" in the domain name "icann.org"

Internationalized Domain Names Working Group

IDN-WG

http://forum.icann.org/lists/gnso-idn-wg/

Letter Digit Hyphen

LDH

The hostname convention used by domain names before internationalization. This meant that domain names could only practically contain the letters a-z, digits 0-9 and the hyphen "-". The term "LDH code points" refers to this subset. With the introduction of IDNs this rule is no longer relevant for all domain names.

The LDH-label strictly refers to an all-ASCII label that obeys the "hostname" (LDH) conventions and that is not an IDN; for example "icann" in the domain name "icann.org".

Nominating Committee

NomCom

http://nomcom.icann.org/

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/

Punycode

Punycode is the ASCII-compatible encoding algorithm described in Internet standard [RFC3492]. This is the method that will encode IDNs into sequences of ASCII characters in order for the Domain Name System (DNS) to understand and manage the names. The intention is that domain name registrants and users will never see this encoded form of a domain name. The sole purpose is for the DNS to be able to resolve for example a web-address containing local characters.

Registrar

Domain names ending with .aero, .biz, .com, .coop, .info, .museum, .name, .net, .org, and .pro can be registered through many different companies (known as "registrars") that compete with one another. A listing of these companies appears in the Accredited Registrar Directory.

The registrar asks registrants to provide various contact and technical information that makes up the domain name registration. The registrar keeps records of the contact information and submits the technical information to a central directory known as the "registry."

Registrar Constituency

RC

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

Registry

A registry is the authoritative, master database of all domain names registered in each Top Level Domain. The registry operator keeps the master database and also generates the "zone file" which allows computers to route Internet traffic to and from top-level domains anywhere in the world. Internet users don't interact directly with the registry operator. Users can register names in TLDs including .biz, .com, .info, .net, .name, .org by using an ICANN-Accredited Registrar.

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

ftp://ftp.rfc-editor.org/in-notes/rfc1591.txt

ftp://ftp.rfc-editor.org/in-notes/rfc2119.txt

ftp://ftp.rfc-editor.org/in-notes/rfc2606.txt

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

Sponsored Top Level Domain

sTLD

A Sponsor is an organization to which some policy making is delegated from ICANN. The sponsored TLD has a Charter, which defines the purpose for which the sponsored TLD has been created and will be operated. The Sponsor is responsible for developing policies on the delegated topics so that the TLD is operated for the benefit of a defined group of stakeholders, known as the Sponsored TLD Community, that are most directly interested in the operation of the TLD. The Sponsor also is responsible for selecting the registry operator and to varying degrees for establishing the roles played by registrars and their relationship with the registry operator. The Sponsor must exercise its delegated authority according to fairness standards and in a manner that is representative of the Sponsored TLD Community.

U-label

The U-label is what should be displayed to the user and is the representation of the Internationalized Domain Name (IDN) in Unicode.

Unicode Consortium

A not-for-profit organization found to develop, extend and promote use of the Unicode standard. See http://www.unicode.org

Unicode

Unicode is a commonly used single encoding scheme that provides a unique number for each character across a wide variety of languages and scripts. The Unicode standard contains tables that list the code points for each local character identified. These tables continue to expand as more characters are digitalized.

Continue to Final Report: Part B

[1] http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#I

[2] The ICANN "community" is a complex matrix of intersecting organizations and which are represented graphically here. http://www.icann.org/structure/

[3] The Final Report is Step 9 in the GNSO's policy development process which is set out in full at http://www.icann.org/general/archive-bylaws/bylaws-28feb06.htm#AnnexA.

[4] Found here http://gnso.icann.org/issues/new-gtlds/.

[5] The ICANN Staff Discussion Points documents can be found at http://gnso.icann.org/drafts/GNSO-PDP-Dec05-StaffMemo-14Nov06.pdf and http://gnso.icann.org/drafts/PDP-Dec05-StaffMemo-19-jun-07.pdf

[6] Authored in 1987 by Paul Mockapetris and found at http://www.ietf.org/rfc/rfc1034

[7] Authored in October 1984 by Jon Postel and J Reynolds and found at http://www.ietf.org/rfc/rfc920

[8] Found at http://www.oecd.org/dataoecd/15/37/38336539.pdf

[9] From Verisign's June 2007 Domain Name Industry Brief.

[10] The full list is available here http://www.icann.org/registrars/accredited-list.html

[11] Report found at http://www.icann.org/dnso/wgc-report-21mar00.htm

[12] Found at http://www.icann.org/announcements/announcement-31aug04.htm

[13] http://www.registrarstats.com/Public/ZoneFileSurvey.aspx

[14] Verisign produce a regular report on the domain name industry. http://www.verisign.com/Resources/Naming_Services_Resources/Domain_Name_Industry_Brief/index.html

[15] The announcement is here http://icann.org/announcements/announcement-03jan06.htm and the results are here http://gnso.icann.org/issues/new-gtlds/new-gtld-pdp-input.htm

[16] Found here http://gnso.icann.org/issues/new-gtlds/new-gtld-pdp-input.htm

[18] For example, see the GA List discussion thread found at http://gnso.icann.org/mailing-lists/archives/ga/msg03337.html & earlier discussion on IANA lists http://www.iana.org/comments/26sep1998-02oct1998/msg00016.html. The 13 June 2002 paper regarding a taxonomy for non-ASCII TLDs is also illuminating http://www.icann.org/committees/idn/registry-selection-paper-13jun02.htm

[19] Found here http://gac.icann.org/web/home/gTLD_principles.pdf

[20] A list of the working materials of the new TLDs Committee can be found at http://gnso.icann.org/issues/new-gtlds/.

[21] The Outcomes Report for the IDN-WG is found http://gnso.icann.org/drafts/idn-wg-fr-22mar07.htm. A full set of resources which the WG is using is found at http://gnso.icann.org/issues/idn-tlds/.

[22] The Final Report of the RN-WG is found at http://gnso.icann.org/drafts/rn-wg-fr19mar07.pdf

[23] The Final Report of the PRO-WG is found at http://gnso.icann.org/drafts/GNSO-PRO-WG-final-01Jun07.pdf

[24] The root server system is explained here http://en.wikipedia.org/wiki/Rootserver

[25] Ms Doria supports all of the Principles but expressed concern about Principle B by saying "...While I strongly support the introduction of IDN TLDS, I am concerned that the unresolved issues with IDN ccTLD equivalents may interfere with the introduction of IDN TLDs. I am also concerned that some of these issues could impede the introduction of some new ASCII TLDs dealing with geographically related identifiers" and Principle D "...While I favor the establishment of a minimum set of necessary technical criteria, I am concerned that this set actually be the basic minimum set necessary to protect the stability, security and global interoperability."

[26] Note the updated recommendation text sent to the gtld-council list after the 7 June meeting. http://forum.icann.org/lists/gtld-council/msg00520.html

[27] Reserved word limitations will be included in the base contract that will be available to applicants prior to the start of the application round.

[28] http://www.icann.org/general/idn-guidelines-22feb06.htm

[29] The Implementation Team sought advice from a number of auction specialists and examined other industries in which auctions were used to make clear and binding decisions. Further expert advice will be used in developing the implementation of the application process to ensure the fairest and most appropriate method of resolving contention for strings.

[30] Detailed work is being undertaken, lead by the Corporate Affairs Department, on establishing a translation framework for ICANN documentation. This element of the Implementation Guidelines may be addressed separately.

[31] http://gnso.icann.org/drafts/GNSO-PDP-Dec05-StaffMemo-14Nov06.pdf

[32] Consistent with ICANN's commitments to accountability and transparency found at http://www.icann.org/announcements/announcement-26jan07b.htm

[33] Found at http://www.icann.org/dnso/wgc-report-21mar00.htm

[34] The announcement is here http://icann.org/announcements/announcement-03jan06.htm and the results are here http://gnso.icann.org/issues/new-gtlds/new-gtld-pdp-input.htm

[35] Found here http://gnso.icann.org/issues/new-gtlds/new-gtld-pdp-input.htm

[36] Found here http://forum.icann.org/lists/gtld-council/

[37] Archived at http://forum.icann.org/lists/gtld-council/

[38] Business Constituency http://forum.icann.org/lists/gtld-council/msg00501.html, Intellectual Property Constituency http://forum.icann.org/lists/gtld-council/msg00514.html, Internet Service Providers http://forum.icann.org/lists/gtld-council/msg00500.html, NCUC http://forum.icann.org/lists/gtld-council/msg00530.html, Registry Constituency http://forum.icann.org/lists/gtld-council/msg00494.html

[39] "My concern involves using definitions that rely on legal terminology established for trademarks for what I believe should be a policy based on technical criteria.

In the first instance I believe that this is essentially a technical issue that should have been resolved with reference to typography, homologues, orthographic neighbourhood, transliteration and other technically defined attributes of a name that would make it unacceptable. There is a large body of scientific and technical knowledge and description in this field that we could have drawn on.

By using terms that rely on the legal language of trademark law, I believe we have created an implicit redundancy between recommendations 2 and 3. I.e., I believe both 2 and 3 can be used to protect trademarks and other intellectual property rights, and while 3 has specific limitations, 2 remains open to full and varied interpretation.

As we begin to consider IDNs, I am concerned that the interpretations of confusingly similar may be used to eliminate many potential TLDs based on translation. That is, when a translation may have the same or similar meaning to an existing TLD, that the new name may be eliminated because it is considered confusing to users who know both languages."

[40] http://data.iana.org/TLD/tlds-alpha-by-domain.txt

[41] See section 4A -- http://www.icann.org/udrp/udrp-policy-24oct99.htm.

[42] In addition to the expertise within the Committee, the NCUC provided, as part of its Constituency Impact Statement expert outside advice from Professor Christine Haight Farley which said, in part, "...A determination about whether use of a mark by another is "confusingly similar" is simply a first step in the analysis of infringement. As the committee correctly notes, account will be taken of visual, phonetic and conceptual similarity. But this determination does not end the analysis. Delta Dental and Delta Airlines are confusingly similar, but are not like to cause confusion, and therefore do not infringe. ... In trademark law, where there is confusing similarity and the mark is used on similar goods or services, a likelihood of confusion will usually be found. European trademark law recognizes this point perhaps more readily that U.S. trademark law. As a result, sometimes "confusingly similar" is used as shorthand for "likelihood of confusion". However, these concepts must remain distinct in domain name policy where there is no opportunity to consider how the mark is being used."

[43] In addition, advice was sought from experts within WIPO who continue to provide guidance on this and other elements of dispute resolution procedures.

[44] Kristina Rosette provided the reference to the Agreement on Trade-Related Aspects of Intellectual Property Rights which is found online at http://www.wto.org/english/tratop_e/trips_e/t_agm1_e.htm

"...Article 16Rights Conferred 
1. The owner of a registered trademark shall have the exclusive right to prevent all third parties not having the owner's consent from using in the course of trade identical or similar signs for goods or services which are identical or similar to those in respect of which the trademark is registered where such use would result in a likelihood of confusion. In case of the use of an identical sign for identical goods or services, a likelihood of confusion shall be presumed. The rights described above shall not prejudice any existing prior rights, nor shall they affect the possibility of Members making rights available on the basis of use...."

[45] http://www.ohchr.org/english/bodies/hrc/comments.htm

[46] http://gnso.icann.org/drafts/GNSO-PRO-WG-final-01Jun07.pdf

[47] Charles Sha'ban provided a range of examples from Arabic speaking countries. For example, in Jordan, Article 7
Trademarks eligible for registration are

1- A trademark shall be registered if it is distinctive, as to words, letters, numbers, figures, colors, or other signs or any combination thereof and visually perceptible.

2- For the purposes of this Article, "distinctive" shall mean applied in a manner which secures distinguishing the goods of the proprietor of the trademark from those of other persons. Article 8
Marks which may not be registered as trademarks. The following may not be registered as trademarks: 10- A mark identical with one belonging to a different proprietor which is already entered in the register in respect of the same goods or class of goods for which the mark is intended to be registered, or so closely resembling such trademark to the extent that it may lead to deceiving third parties.

12- The trademark which is identical or similar to, or constitutes a translation of, a well-known trademark for use on similar or identical goods to those for which that one is well-known for and whose use would cause confusion with the well-known mark, or for use of different goods in such a way as to prejudice the interests of the owner of the well-known mark and leads to believing that there is a connection between its owner and those goods as well as the marks which are similar or identical to the honorary badges, flags, and other insignia as well as the names and abbreviations relating to international or regional organizations or those that offend our Arab and Islamic age-old values.

In Oman for example, Article 2 of the Sultan Decree No. 38/2000 states:

"The following shall not be considered as trademarks and shall not be registered as such: 
If the mark is identical, similar to a degree which causes confusion, or a translation of a trademark or a commercial name known in the Sultanate of Oman with respect to identical or similar goods or services belonging to another business, or if it is known and registered in the Sultanate of Oman on goods and service which are neither identical nor similar to those for which the mark is sought to be registered provided that the usage of the mark on those goods or services in this last case will suggest a connection between those goods or services and the owner of the known trademark and such use will cause damage to the interests of the owner of the known trademark."

Although the laws In Egypt do not have specific provisions regarding confusion they stress in great detail the importance of distinctiveness of a trade mark.

Article 63 in the IP Law of Egypt No.82 for the year 2002 states:

"A trademark is any sign distinguishing goods, whether products or services, and include is particular names represented in a distinctive manner, signatures, words, letters, numerals, design, symbols, signposts, stamps, seal, drawings, engravings, a combination of distinctly formed colors and any other combination of these elements if used, or meant to be used, to distinguish the precedents of a particular industry, agriculture, forest or mining venture or any goods, or to indicate the origin of products or goods or their quality, category, guarantee, preparation process, or to indicate the provision of any service. In all cases, a trademark shall be a sign that is recognizable by sight."

[48] Found at http://www.wipo.int/treaties/en/ip/paris/trtdocs_wo020.ht with 171 contracting parties.

[49] Further information can be found at the US Patent and Trademark Office's website http://www.uspto.gov/

[50] Found at http://www.icann.org/registrars/ra-agreement-17may01.htm#3

[51] Found at http://gnso.icann.org/drafts/idn-wg-fr-22mar07.htm.

[52] The 2003 correspondence between ICANN's then General Counsel and the then GAC Chairman is also useful http://www.icann.org/correspondence/touton-letter-to-tarmizi-10feb03.htm.

[53] "My first concern relates to the protection of what can be called the linguistic commons. While it is true that much of trademark law and practice does protect general vocabulary and common usage from trademark protection, I am not sure that this is always the case in practice. I am also not convinced that trademark law and policy that applies to specific product type within a specific locale is entirely compatible with a general and global naming system."

[54] For example, David Maher, Jon Bing, Steve Metalitz, Philip Sheppard and Michael Palage.

[55] Reserved Word has a specific meaning in the ICANN context and includes, for example, the reserved word provisions in ICANN's existing registry contracts. See http://www.icann.org/registries/agreements.htm.

[56] "Until such time as the technical work on IDNAbis is completed, I am concerned about establishing reserved name rules connected to IDNs. My primary concern involves policy decisions made in ICANN for reserved names becoming hard coded in the IDNAbis technical solution and thus becoming technical constraints that are no longer open to future policy reconsideration."

[57] Found online at http://gnso.icann.org/issues/new-gtlds/final-report-rn-wg-23may07.htm and in full in Part B of the Report.

[58] The Committee are aware that the terminology used here for the purposes of policy recommendations requires further refinement and may be at odds with similar terminology developed in other context. The terminology may be imprecise in other contexts than the general discussion about reserved words found here.

[59] The subgroup was encouraged by the ccNSO not to consider removing the restriction on two-letter names at the top level. IANA has based its allocation of two-letter names at the top level on the ISO 3166 list. There is a risk of collisions between any interim allocations, and ISO 3166 assignments which may be desired in the future.

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

[61] Considering that the current requirement in all 16 registry agreement reserves "All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")", this requirement reserves any names having any of a combination of 1296 different prefixes (36x36).

[62] Internet Draft IDNAbis Issues: http://www.ietf.org/internet-drafts/draft-klensin-idnabis-issues-01.txt (J. Klensin), Section 3.1.1.1

[63] Considering that the current requirement in all 16 registry agreement reserves "All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")", this requirement reserves any names having any of a combination of 1296 different prefixes (36x36).

[64] Considering that the current requirement in all 16 registry agreement reserves "All labels with hyphens in the third and fourth character positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")", this requirement reserves any names having any of a combination of 1296 different prefixes (36x36).

[65] With its recommendation, the sub-group takes into consideration that justification for potential user confusion (i.e., the minority view) as a result of removing the contractual condition to reserve gTLD strings for new TLDs may surface during one or more public comment periods.

[66] Note that this recommendation is a continuation of the recommendation in the original RN-WG report, modified to synchronize with the additional work done in the 30-day extension period.

[67] Ms Doria said "...My primary concern focuses on the term 'morality'. While public order is frequently codified in national laws and occasionally in international law and conventions, the definition of what constitutes morality is not generally codified, and when it is, I believe it could be referenced as public order. This concern is related to the broad set of definitions used in the world to define morality. By including morality in the list of allowable exclusions we have made the possible exclusion list indefinitely large and have subjected the process to the consideration of all possible religious and ethical systems. ICANN or the panel of reviewers will also have to decide between different sets of moral principles, e.g, a morality that holds that people should be free to express themselves in all forms of media and those who believe that people should be free from exposure to any expression that is prohibited by their faith or moral principles. This recommendation will also subject the process to the fashion and occasional demagoguery of political correctness. I do not understand how ICANN or any expert panel will be able to judge that something should be excluded based on reasons of morality without defining, at least de-facto, an ICANN definition of morality? And while I am not a strict constructionist and sometimes allow for the broader interpretation of ICANN's mission, I do not believe it includes the definition of a system of morality."

[68] http://www.icann.org/tlds/agreements/net/appendix7.html

[69] 'While I accept that a prospective registry must show adequate operational capability, creating a financial criteria is of concern. There may be many different ways of satisfying the requirement for operational capability and stability that may not be demonstrable in a financial statement or traditional business plan. E.g., in the case of an less developed community, the registry may rely on volunteer effort from knowledgeable technical experts.

Another concern I have with financial requirements and high application fees is that they may act to discourage applications from developing nations or indigenous and minority peoples that have a different set of financial opportunities or capabilities then those recognized as acceptable within an expensive and highly developed region such as Los Angeles or Brussels."

[70] "In general I support the policy though I do have concerns about the implementation which I discuss below in relation to IG (P)".

[71] "In general I support the idea that a registry that is doing a good job should have the expectancy of renewal. I do, however, believe that a registry, especially a registry with general market dominance, or specific or local market dominance, should be subject to comment from the relevant user public and to evaluation of that public comment before renewal. When performance is satisfactory, there should an expectation of renewal. When performance is not satisfactory, there should be some procedure for correcting the situation before renewal."

[72] Consensus Policies has a particular meaning within the ICANN environment. Refer to http://www.icann.org/general/consensus-policies.htm for the full list of ICANN's Consensus Policies.

[73] http://www.icann.org/general/bylaws.htm#AnnexA

[74] http://www.icann.org/registries/agreements.htm

[75] The full list of reports is found in the Reference section at the end of the document.

[76] http://www.icann.org/announcements/announcement-4-07mar07.htm

[77] Found at http://www.icann.org/registrars/ra-agreement-17may01.htm

[78] Found at http://www.icann.org/registrars/accreditation.htm.

[79] Text of Recommendation #6: "Strings must not be contrary to generally accepted legal norms relating to morality and public order that are enforceable under generally accepted and internationally recognized principles of law. Examples of such principles of law include, but are not limited to, the Universal Declaration of Human Rights (UDHR), the International Covenant on Civil and Political Rights (ICCPR), the Convention on the Elimination of all forms of Discrimination Against Women (CEDAW) and the International Convention on the Elimination of All Forms of Racial Discrimination, intellectual property treaties administered by the World Intellectual Property Organisation (WIPO) and the WTO Agreement on Trade-Related Aspects of Intellectual Property Rights (TRIPS)."

[80] Ms Doria took over from former GNSO Council Chairman (and GNSO new TLDs Committee Chairman) Dr Bruce Tonkin on 7 June 2007. Ms Doria's term runs until 31 January 2008.

[83] This glossary has been developed over the course of the policy development process. Refer here to ICANN's glossary of terms http://www.icann.org/general/glossary.htm for further information.