ICANN|ARCHIVES
Internet Corporation for Assigned Names and Numbers
Please note:
You are viewing archival ICANN material. Links and information may be outdated or incorrect. Visit ICANN's main website for current information.
Statement of Work Regarding Preparation of the Request for Proposals for New gTLDs
6 September 2007
1.1. ICANN is seeking a provider to write a request for proposals (RFP) that will establish the application process for new generic top-level domains (gTLDs). The provider may also be considered as a potential provider of evaluation services for the applications received.
1.2. The Internet Corporation for Assigned Names and Numbers (ICANN) is an internationally organized, non-profit public benefit corporation that has responsibility for Internet Protocol (IP) address space allocation, protocol identifier assignment, generic (gTLD) and country code (ccTLD) Top-Level Domain name system management, and root server system management functions. ICANN's mission is to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems. It coordinates policy development reasonably and appropriately related to these technical functions, consistent with ICANN's core values. Among these values are:
1.2.1. Preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet;
1.2.2. Where feasible and appropriate, depending on market mechanisms to promote and sustain a competitive environment;
1.2.3. Introducing and promoting competition in the registration of domain names where practicable and beneficial in the public interest; and
1.2.4. Seeking and supporting broad, informed participation reflecting the functional, geographic, and cultural diversity of the Internet at all levels of policy development and decision-making.
1.3. gTLDs are part of the structure of the Internet's Domain Name System (DNS). Examples of gTLDs include .COM, .EDU and .JOBS. A complete listing of gTLDs is available at http://www.iana.org/gtld/gtld.htm. The responsibility for operating each gTLD (including maintaining a registry of the domain names within the gTLD) is delegated to a particular organization. These organizations are referred to as "registry operators" or "sponsors," depending upon the type of agreement they have with ICANN.
1.4. New gTLDs have previously been established based on proposals that were submitted to ICANN during two specific application periods. Materials from the 2000 application round, which led to the delegation of .AERO, .BIZ, .COOP, .INFO, .MUSEUM, .NAME and .PRO, are available at http://www.icann.org/tlds/app-index.htm. Materials from the 2004 round, which led to the delegation of .ASIA, .CAT, .JOBS, .MOBI, .TEL and .TRAVEL, are available at http://www.icann.org/tlds/stld-apps-19mar04.[1] Applications received during both of these rounds were evaluated on the basis of instructions and criteria contained in the respective RFPs published by ICANN. Applicants that were successful went on to negotiate and enter TLD agreements with ICANN.
1.5. ICANN has previously issued RFPs related to gTLDs in the cases of a rebid for the .ORG gTLD in 2002 (see http://www.icann.org/tlds/org) and for the .NET gTLD in 2004-5 (see http://www.icann.org/tlds/dotnet-reassignment/dotnet-general.htm).
1.6. Planning has begun to develop and implement a strategy that will lead to the delegation of new gTLDs. This is a complex endeavor, drawing on technical, economic, operational, legal, public policy and other expertise to build a process that is as efficient, effective and objective as possible. The Generic Names Supporting Organization (GNSO), ICANN's volunteer-based policy-making body, has created a set of policy recommendations for the introduction of new gTLDs (see http://gnso.icann.org/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm). The GNSO is expected to vote on its final policy recommendations in September. The ICANN Board of Directors will then consider the GNSO's work.
1.7. In the meantime, ICANN staff has begun developing the various processes that will be needed to implement the GNSO's policy recommendations, taking into account the GNSO's work so far, the lessons learned from two previous rounds of gTLD expansion, and the .ORG and .NET rebid experiences. Another important source of guidance is the Principles Regarding New gTLDs, which were developed by ICANN's Governmental Advisory Committee (GAC) in March 2007, see http://gac.icann.org/web/home/gTLD_principles.pdf.
1.8. Once preliminary work is complete, ICANN staff will seek Board approval to issue the RFP to solicit applications for new gTLDs.
1.9. ICANN now seeks to select a provider to prepare the RFP that will launch this round of new gTLDs in 2008, as defined by this Statement of Work (SOW). The successful candidate will develop the necessary criteria, the evaluation process and draft the RFP document. The provider will also incorporate into the RFP certain processes that are being developed by others, such as the Objection Resolution Process described below.
2. Objectives
2.1. The objective of the RFP is to provide a comprehensive description of the application criteria and the process that will be used to evaluate applications for new gTLDs. It is important that all potential applicants for a new gTLD have a full understanding of the complete process and timing surrounding the various aspects involved.
2.2. Required aspects of the application process are:
2.2.1. The process must accommodate evaluation of a wide range of numbers of applications. The number of anticipated applications is unknown.
2.2.2. The evaluation and selection process must utilize objective and measurable criteria.
2.2.3. The RFP must be comprehensive and include all selection criteria. All applications will be evaluated against these criteria, which must be transparent, predictable and publicly available at the outset of the process and described fully in the RFP.
2.2.4. The evaluation and selection process must respect the principles of fairness, transparency and non-discrimination.
2.2.5. The RFP must also provide timelines for all steps in the process. Potential applicants must be made aware that there will be other rounds after this first round in the near future, i.e., other opportunities to apply for new gTLDs.
2.2.6. An applicant may only propose one string in each application.
2.2.7. The process must accommodate internationalized domain names (IDNs). (For more information about IDNs, see http://www.icann.org/topics/idn).
3. Evaluation Process Overview
3.1. The entire evaluation and review process will be conducted on a cost-recovery basis. The costs associated with the initial evaluation will be covered by the application fee. The costs associated with extended evaluation and contention resolution will be borne by those parties utilizing those processes (including the applicant and objectors).
3.1.1. There will be an initial fee that will cover the Initial Evaluation process (described below).
3.1.2. If additional scrutiny or process is required an additional fee may be required of the applicants. The amount will vary by the type of subsequent process required. This Extended Evaluation is described below.
3.1.3. If there is a formal objection to the application (process described below) the objector must pay a fee as part of the standing to object requirement.
3.1.4. The applicant may wish to withdraw the application rather than pay additional fees and extend the evaluation process.
3.2. The evaluation of the application against the criteria specified in the RFP will be performed by independent evaluation panels with expertise in all relevant areas.
3.3. There are three major phases to the evaluation:
3.3.1. The Initial Evaluation period describes those parts of the process that are focused primarily on evaluation of the applications against the criteria specified in the RFP. It is important that the criteria be objective and that the evaluators be guided and enabled to complete the evaluation without iteration. The Initial Evaluation involves a review of the following areas:
3.3.1.1. Technical. The evaluation panels will review the technical components of each application against the criteria contained in the RFP, in order to determine whether the applicant is technically capable of operating a new gTLD registry. The overarching concern in the introduction of any new TLD is to ensure that it does not negatively affect the stability and integrity of the DNS. Therefore, the technical evaluation panel may also raise issues that relate to the stability and security of the DNS, and pertain to a specific application.
3.3.1.2. Operational. The evaluation panels will review each application against the relevant business, financial, and organizational criteria contained in the RFP, to determine whether the applicant is capable of operating a registry.
3.3.1.3. DNS Stability. All proposed TLD strings will be reviewed to determine whether any proposed string would lead to technical instability or unexpected results in the DNS. This review is expected to be done by ICANN, drawing on technical expertise as needed.
3.3.1.4. Reserved Names. As part of the administrative review of each application, ICANN staff will determine whether the proposed string is on the Reserved Names list that will be published by ICANN.
3.3.1.5. Confusing Similarity. All applications for TLD strings will be assessed to determine whether the proposed string is confusingly similar to an existing TLD, another application, or a Reserved Name. Ideally, this determination would be made by applying an algorithm. ICANN will furnish a sample algorithm to the provider, but it will be for the provider to assess whether it is possible to design an algorithm that could provide guidance on which applications require further scrutiny.
3.3.1.6. Objections. Determination that there has been the filing of a bona fide formal objection by a party with standing will trigger a dispute resolution process during the Extended Evaluation phase (see below for the grounds on which a formal objection may be filed).
3.3.1.7. The areas that comprise the Initial Evaluation are depicted in this graphic:
3.3.2. The Extended Evaluation period occurs when the results of the Initial Evaluation invite extended scrutiny or there has been a bona fide objection on specific grounds to the application by a third party with standing. The extended evaluation will be conducted by independent panels and dispute resolution providers. If there are unresolved issues as a result of the Initial Evaluation, these will be addressed during Extended Evaluation. The duration of this phase and the additional fees involved will depend upon the type of unresolved issues and must be defined for potential applicants in the RFP.
3.3.2.1. Extended technical and operational evaluation. The RFP must define an iterative process where the evaluators and applicants have the opportunity to clarify elements of the application or answer evaluator queries.
3.3.2.2. Extended DNS Stability evaluation. The RFP must define a process by which the evaluators may further study aspects of the application that could lead to technical instability or unexpected results in the DNS.
3.3.2.3. Objections. Collectively, formal objections will be handled through an Objection Resolution Process that will be established and administered by an external provider of dispute resolution services. The RFP must explain all facets of the Objection Resolution Process, including the role of the external dispute resolution provider; the process the applicant and third parties must follow; the grounds for filing an objection; how objections will be evaluated; and mechanisms for appeals. (Note: Much of this process will be developed by the provider administering the Objection Resolution Process, ICANN staff and outside counsel, for insertion into the RFP. The RFP provider will be responsible for integrating all aspects of the process into the RFP.)
3.3.2.4. The grounds for objection that have been identified based on the GNSO's recommendations are set forth below in general terms.
3.3.2.4.1. Confusingly Similar: Objection that the string proposed is confusingly similar to an existing TLD or to a Reserved Name. In this context, the determination of confusing similarity is of a technical nature. The RFP must explain, with as much precision as possible, the term "confusingly similar" as used in this context, and describe the process that will be used to make determinations. (Anyone may file an objection on this ground.)
3.3.2.4.2. Legal Rights of Others: Objection that the string will infringe the legal rights of others that are recognized or enforceable under generally accepted and internationally recognized principles of law. (Only potentially harmed rights holders may file an objection on this ground.)
3.3.2.4.3. Morality & Public Order: Objection that the string is contrary to generally accepted legal norms relating to morality and public order that are recognized under international principles of law. (Anyone may file an objection on this ground.)
3.3.2.4.4. Community Opposition: Objection on the ground that there is substantial opposition to the applicant by a significant portion of the community to which the string may be explicitly or implicitly targeted. (Only the established institutions representing the specified community may file an objection on this ground.)
3.3.2.5. The areas that comprise the Extended Evaluation are depicted in this graphic :
3.3.3. Contention Resolution provides for resolving cases where two or more applications, which have been judged qualified and have overcome formal objections, are competing for the same string, or for strings that have been determined to be "confusingly similar." Contention may be resolved informally by the parties themselves, or through comparative evaluation or auction.
3.3.3.1. The parties may voluntarily submit to mediation, arbitration or other means to resolve contention at any stage of the process.
3.3.3.2. If mediation is not utilized or does not resolve the contention, the subsequent method is a comparative evaluation process. This process will be available if one or more of the contending applicants is an established institution purporting to represent a well-defined community. If the parties select comparative evaluation, an independent panel will be asked to score the applications. Weight will be given to indicate that community representation adds value to the DNS. The basis, process and timeline for conducting a comparative evaluation must be established in the RFP.
3.3.3.3. If neither method above is available, the selection will be made by auction. An independent party will conduct the auction. The RFP should describe the auction process.
4. Deliverables to be included in the RFP
4.1. The provider is expected to develop:
4.1.1. The complete set of technical criteria referenced in Section 3.3.1.1;
4.1.2. The complete set of operational criteria referenced in Section 3.3.1.2;
4.1.3. The technical and operational evaluation processes referenced in Sections 3.3.1 and 3.3.2 as well as the comparative evaluation process methodology referenced in Section 3.3.3.2;
4.1.4. Guidance on means for determinations of confusing similarity referenced in 3.3.1.5;
4.1.5. The complete set of questions to be used in the online application form;
4.1.6. Procedural and substantive instructions for completing and submitting applications;
4.1.7. Timelines for each step in the evaluation process and an overall timeline taking into account the interdependencies of the various steps;
4.1.8. Costs at each stage of the process; and,
4.1.9. Publication of a fee structure for evaluations.
4.2. Certain elements of the RFP will be developed externally and furnished to the provider for incorporation into the RFP. These include:
4.2.1. The Reserved Names list;
4.2.2. The Objection Resolution Process;
4.2.2.1. Procedure for making a valid objection;
4.2.2.2. Standards under which objections will be analyzed, except for the case of confusingly similar TLDs. The provider is expected to furnish the standard in this case; and
4.2.2.3. Dispute resolution procedure for resolving objections filed.
4.2.3. Technical instructions for electronic submission of applications;
4.2.4. The base contract which successful applicants will enter into with ICANN;
4.2.5. Terms and conditions associated with application submission;
4.2.6. Fees for applications based upon the costs calculated by the provider; and,
4.2.7. Timeline for future RFPs.
4.3. This SOW should be considered as initial guidance; the successful candidate is welcome to suggest additional elements that could be included in the RFP.
5. Schedule
The final RFP is presently expected to be posted and launch the application process for new gTLDs by mid-April 2008. To meet this goal, the draft RFP should be delivered to ICANN by mid-December 2007 for staff review, with milestones for interim deliverables to be negotiated. Under this timeline, the draft RFP would be posted for public comment in January 2008. The provider would then work with ICANN to incorporate appropriate modifications to the draft based on public comment, and prepare the revised RFP for Board review in March 2008.
6. Provider Proposal Requirements
6.1. Given the information provided in this document and the materials cited therein, and responding specifically to the requests for further information, provider candidates responding to this SOW must provide:
6.1.1. Statement of Suitability. The Statement of Suitability must include a detailed outline of the provider's ability to perform the work demonstrating knowledge, experience and expertise, including but not limited to: projects, consultancies, research, publications and other relevant information, and references. The successful provider candidate will be expected to utilize its technical and policy expertise to develop a full, complete and robust RFP for ICANN and the community. The RFP team is expected to:
6.1.1.1. Have extensive knowledge of and experience with the preparation and evaluation of RFPs of a technical nature and related complexity, preferably also involving challenging policy issues;
6.1.1.2. Have prior experience in running large procurement projects in the information technology field;
6.1.1.3. Be familiar with all materials relevant to the launch of this application process, including but not limited to the information about prior gTLD application processes and the policy development process noted above;
6.1.1.4. Be knowledgeable about ICANN and its structure and processes including its past gTLD application and evaluation rounds; and
6.1.1.5. Be knowledgeable about and follow best practice guidelines on procurement (e.g., World Bank and Asian Development Bank guidance).
6.2. Team Curriculum Vitae. The provider proposal must include Curriculum Vitae for each member of the team, showing each individual's suitability for the proposed work and proposed role they would play. This information should indicate which members are comfortable working with languages other than English, as well as their experience with IDNs.
6.3. ICANN Contractual Compliance. Provider candidates must warrant that they will operate under ICANN's non-disclosure agreement and standard consulting agreement, and that they have no known conflicts of interest with ICANN.
6.4. Work Schedule: The provider candidate must provide a proposed work schedule including key milestone dates, consistent with but more detailed than those specified above. (Note: the provider will be expected to attend the ICANN public meeting to be held in Los Angeles from 29 October – 2 November 2007.)
6.5. Statement of Proposed Fees. The provider candidate must provide a detailed statement of proposed fees.
6.6. (Optional) Provider candidates may indicate if they wish to also be considered by ICANN when it seeks an external provider to establish and administer the evaluation process described in Section 3.3 above. If they wish to be considered for this role, provider candidates will be requested to provide a separate statement of proposed fees.
6.7. (Optional) Provider candidates may indicate if they wish to also be considered by ICANN in a consulting capacity for designing and conducting auctions as referenced in Section 3.3.3.3 above.
6.8. Deadline / requirements: Interested candidates must submit proposals by email to rfpgtlds@icann.org to the attention of Craig Schwartz, Chief gTLD Registry Liaison, by 8 October 2007. A confirmation email will be sent for each proposal received. The successful provider candidate is expected to be retained in October 2007 and must be ready to begin work immediately thereafter.
ANNEX A – GNSO's Final Report Summary: Principles, Recommendations & Implementation Guidelines (6 August 2007)
ANNEX A
GNSO Committee on the Introduction of New Top-Level Domains
SUMMARY -- PRINCIPLES, RECOMMENDATIONS & IMPLEMENTATION GUIDELINES
(6 August 2007)
| PRINCIPLES | |
| A | New generic top-level domains (gTLDs) must be introduced in an orderly, timely and predictable way. |
| B | Some new generic top-level domains should be internationalised domain names (IDNs) subject to the approval of IDNs being available in the root. |
| 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.
|
| 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. |
| 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. |
| F | A set of operational criteria must be set out in contractual conditions in the registry agreement to ensure compliance with ICANN policies. |
| G | The string evaluation process must not infringe the applicant's freedom of expression rights that are protected under internationally recognized principles of law. |
| IMPLEMENTATION GUIDELINES | |
IG A |
The application process will provide a pre-defined roadmap for applicants that encourages the submission of applications for new top-level domains. |
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. |
IG C |
ICANN will provide frequent communications with applicants and the public including comment forums. |
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. |
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. |
IG F |
If there is contention for strings, applicants may:
|
IG G |
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. |
IG H |
External dispute providers will give decisions on objections. |
IG I |
An applicant granted a TLD string must use it within a fixed timeframe which will be specified in the application process. |
IG J |
The base contract should balance market certainty and flexibility for ICANN to accommodate a rapidly changing market place. |
IG K |
ICANN should take a consistent approach to the establishment of registry fees. |
IG L |
The use of personal data must be limited to the purpose for which it is collected. |
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. |
IG N |
ICANN may put in place a fee reduction scheme for gTLD applicants from economies classified by the UN as least developed. |
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. |
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.
|
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. |
[1] Note that certain gTLDs (.COM, .EDU, .GOV, .INT, .MIL, .NET, .ORG) were in existence prior to the formation of ICANN.