DRAFT GNSO Recommendation Summary

Table of Contents

PRINCIPLES

RECOMMENDATIONS

1 WHETHER TO INTRODUCE NEW TOP LEVEL DOMAINS

2 SELECTION CRITERIA

3 ALLOCATION METHODS

4 CONTRACTUAL CONDITIONS

Principles

The following Recommendations have been derived from the work of the GNSO Committee on the introduction of new top level domains in accordance with the Terms of Reference set by the GNSO, with reference to ICANN's Mission and Core Values.

a) That new generic top level domains (gTLDs) will be introduced in anorderly and predictable way.

b) That some new generic top level domains will be internationalised domain names (IDNs). IDNs use characters drawn from a large repertoire (Unicode). There is a mechanism called Internationalizing Domain Names in Applications (IDNA) that allows the non-ASCII characters to be representing using only the ASCII characters already allowed in so-called host names today (see RFC3490).

c) That the principal objective of the introduction of new top level domains is to permit market mechanisms to support competition and consumer choice in the technical management of the DNS. This competition will lower costs, promote innovation, and enhance user choice and satisfaction.

d) That a set of "technical criteria" for a new gTLD registry applicant minimises the risk of harming the operational stability, reliability, security, and global interoperability of the Internet.

f) That a set of "business capability criteria" for a new gTLD registry applicant provides an assurance that an applicant has the capability to meet its business ambitions.

Recommendations

1 Whether to introduce new top level domains

1.1 Additional new generic top-level domains should be introduced and work should proceed to enable the introduction of new generic top level domains, taking into account the recommendations found in the following sections.

2 Selection Criteria

2.1 The process for introducing new top level domains will follow a prepublished application system including the levying of an application fee to recover the costs of the application process. The application process will also include probity rules and clear timelines.

2.2 Application fees will be set at the start of the process and application materials will be available prior to any application round. Some applications may cost different amounts to evaluate. Therefore, different fees may be levied depending on what stage in the process the application reaches. If applicants find the application fee a barrier to entry, ICANN could have a system of grants to assist applicants. This grant would only allow the applicant to apply, without any presumption that the application would be successful. Grant applications would go through an evaluation process. ICANN should evaluate options for

funding the grants.

2.3 Technical criteria will include compliance with a minimum set of technical standards that would include IETF Requests for Comment related to the operation of the DNS and other technical standards. Standards may include RFC3730-3735, RFC2246, RFC1035, RFC2181, RFC2182, and the ICANN Guidelines for the Implementation of Internationalized Domain Names.

2.4 Applicants must comply with all ICANN consensus policies as and when they are developed.

2.5 Applicants must choose a string of characters for the new generic top level domain name that complies with the process for string checks below.

2.5.1 ICANN will use the following process for TLD string checks.

2.5.1.1 ICANN will make a preliminary determination on whether the application complies with the string requirements and may seek expert advice in order to make its preliminary determination.

2.5.1.2 ICANN will establish public comment processes (which may include input from governments or the Governmental Advisory Committee) that are specific to the criteria for the new string.

2.5.1.3 In the event that ICANN reasonably believes that the application for a particular string may not be compliant with the string requirements, ICANN will refer the issue to a panel of experts with appropriate backgrounds.

2.5.2 String Criteria

2.5.2.1 The gTLD string should not be confusingly similar to an existing TLD string. Confusingly similar means there is a likelihood of confusion on the part of the relevant public.

2.5.2.2 The string must not infringe the legal rights of any third party (consistent with the current requirements of Registered Name Holders�V see Clause 3.7.7.9 of the gTLD Registrar Accreditation Agreement).

2.5.2.3 The string should not cause any technical issues, for example, .localhost and .exe would be unacceptable name strings.

2.5.2.4 The string should not be in conflict with national or international laws or cause conflicts with public policy [for example, controversial, political, cultural religious terms]. (Develop text related to public policy issues with GAC assistance).

2.5.2.5 The string should not be a reserved word (for example, RFC2606).

2.5.3 Dispute resolution with respect to ICANN accepting a new string.

2.5.3.1 ICANN must establish a dispute resolution process, using independent arbitrators, where existing registry operators could challenge a decision made by ICANN regarding whether a new gTLD string is confusingly similar to an existing gTLD string. If a string application is successfully challenged as being confusingly similar, then no other operator may subsequently apply for it.

2.5.3.2 ICANN may establish a new dispute resolution process, using independent arbitrators, where existing trademark holders could challenge an ICANN decision regarding a string. This new dispute resolution process would be modeled on use existing Uniform Domain-Name Dispute Resolution Processes (UDRP).

2.6 An applicant for a new gTLD must use ICANN accredited registrars to provide registration services to Registered Name Holders (registrants). The registry shall not act as a registrar with respect to the TLD (consistent with the current registry-registrar structural separation requirements, for example, see clause 7.1 (b) and (c) of the .jobs registry agreement). An organization wishing to become a registrar for a new gTLD would need to become accredited using ICANN's existing accreditation process.

2.7 An applicant must demonstrate that they have the capability to operate a new gTLD that meets the minimum technical criteria to preserve the operational stability, reliability, security, and global interoperability of the Internet.

2.8 The applicant must provide a financial and business plan that provides an assurance that the applicant has the capability to meets its business ambitions.

3 Allocation Methods

3.1 To ensure an orderly introduction of new TLDs, the applications should be accessed in rounds to allow issues of contention between applicants for the same string to be resolved. First come first served (FCFS) is the preferred method of assessing applications within an initial round. Subsequently, processes may be developed that would enable an "apply as you go" system.

3.1.1 The start date for the round should be at least four months after the ICANN Board has issued the Request for Applications. ICANN must promote the opening time and details of the new round of applications to the broader worldwide Internet community.

3.1.2 Applications will be date stamped as they are received and will form a queue with the ability to work on multiple applications in parallel.

3.1.3 The closing date for the first round of new applications should be at least thirty days after the start date.

3.1.4 Applications for strings are not published until after the closing date.

3.2 The following process should be used to resolve contention between multiple applicants for the same new gTLD.

3.2.1 Ensure each application for the same gTLD (or a set of gTLDs that may be considered to be confusingly similar) is compliant with the selection criteria (with some flexibility to correct minor application form errors).

3.2.2 Establish a timeframe for a mediation process amongst the applicants to identify a solution amongst competing applications. A possible solution is for the applicants to choose different TLD strings to avoid the conflict, or for the applicants to combine their resources.

3.2.3 If there is no agreement between the applicants, ICANN will evaluate the additional criteria of the level of support of the community of potential registrants within that TLD to resolve contention. Both applicants would have a timeframe (e.g 90 days) to supply this additional material for evaluation. ICANN will determine what evidence is acceptable, and the evidence must be measurable and verifiable. An applicant that is not successful will need to wait until the next application round to submit a new application.

3.2.4 If ICANN staff are unable to distinguish between the level of support for each applicant for the gTLD, then the Board will make a choice based on the ICANN Mission and Core Values which include introducing and promoting competition in the registration of domain names where practicable and beneficial in the public interest; and supporting the functional, geographic and cultural diversity of the Internet. An applicant that is not successful will need to wait until the next application round to submit a new application.

3.3 An applicant who is granted a gTLD string has an obligation to begin using it within an appropriate time-frame.

4 Contractual Conditions

4.1 There should be a frame agreement to provide some level of consistency (for example, as for the registrars accreditation agreement) amongst gTLD agreements, with the ability for staff to have delegated authority to approve. Any material alterations to the frame agreement, will be subject to public comments before approval by the ICANN Board.

4.2 The contract should strike the right balance between ensuring certainty for market players and preserving flexibility of ICANN to accommodate the rapidly changing market, technological and policy conditions.

4.3 The initial term of the new gTLD agreement should be of commercially reasonable length (for example, default 10 years, although may be changed on a case-by-case basis).

4.4 There should be renewal expectancy. A contract would be renewed provided that the license holder is not in material breach of the contract, or has not been found in repeated non-performance of the contract, and provided the license holder agrees to the any new framework contract conditions that are reasonably acceptable. Any new framework contract would take into account the consensus policies in place at that time.

4.5 There should be a clear sanctions process outlined within the frame agreement to terminate a contract if the new gTLD operator has been found in repeated non-performance of the contract.

4.6 During the term of the agreement, the registry must comply with new or changed consensus policies to one or more of the following areas: ICANN Policy Development

- (1) issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or DNS;

- (2) functional and performance specifications for the provision of Registry Services (as defined in Section 3.1(d)(iii) below);

- (3) security and stability of the registry database for the TLD;

- (4) registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars;

- or (5) resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names).

4.7 Any deviation from consensus policies should be explicitly stated and justified in the agreement.

4.8 Where a registry provides IDNs, the contract should require that the registry adhere to IDN standards, and ICANN guidelines for IDNs.

4.9 Initially rely on the appropriate external competition/anti-trust Government authorities to ensure compliance with laws relating to market power or pricing power. This can be reviewed after an initial term.

4.10 ICANN should take a consistent approach with respect to registry fees �V taking into account differences in regional, economic and business models

4.11 Use of Personal Data: limit it to the purpose for which it is collected, and the registry operator must define the extent to which it is made available to third parties.