DRAFT GNSO Recommendation Summary
Table of Contents
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.
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.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
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.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.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.2 The following process should be used to resolve contention between multiple applicants for the same new gTLD.
3.3 An applicant who is granted a gTLD string has an obligation to begin using it within an appropriate time-frame.
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
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.