Establishment of new sTLDs:
Request for Proposals

(Draft for public comment)

Posted: 23 June 2003

Establishment of new sTLDs: Request for Proposals

Background and Overview

This Request for Proposal (RFP) is being issued by ICANN to solicit applications for a limited number of new Sponsored Top-Level-Domains (sTLDs). It is issued in response to a directive to ICANN staff by the ICANN Board of Directors at its meeting in Amsterdam on 15 December, 2002, following submission by then President Stuart Lynn of a Plan for Action regarding new TLDs in general. The Plan for Action itself was in response to a directive from the ICANN Board at its 23 August 2002 meeting.

That Plan for Action proposed that ICANN could proceed with a limited number (the Plan actually called for three, but community comment encouraged not staying with a fixed number) of new sponsored TLDs prior to completing a full evaluation of the Proof of Concept initiated in the Fall of 2000. The Proof of Concept, following an open solicitation of proposals to establish new TLDs, eventually led to the establishment of four new unsponsored TLDs (.info, .biz, .name, and .pro) and three sponsored TLDs (.museum, .aero, and .coop). The Plan for Action stated – and the Board accepted the views expressed – that the unresolved issues inherent in launching new unsponsored TLDs (uTLDs), prior to the evaluation and a full review of how to proceed in the future, were too great to support proceeding at this time in soliciting applications for new uTLDs. Conversely, the Plan for Action stated the view that there was far less risk in proceeding presently with a limited number of new sTLDs, as an extension of the original Fall 2002 Proof of Concept.

This RFP follows the Board's preliminary decision (subject to approving the RFP itself) to proceed with a solicitation for applications for a limited number of new sTLDs as an extension of the Proof of Concept. However, in a refinement of the Plan of Action, the Board proposes to limit applications to those applicants (or their affiliates or successors as subsequently defined in this RFP) who submitted applications for sponsored TLDs in the original Fall 2000 round of applications, but were not approved at that time. This RFP reflects the Board's thinking in that regard, and is therefore limited in scope of eligible applicants.

The Board, in consultation with ICANN President Paul Twomey, is also considering initiating a comprehensive study by ICANN of whether and how to proceed with additional TLDs at the same time as the creation of new sTLDs is being considered through this RFP process, and as the evaluation of the original Proof of Concept is being completed. The outcome of that study may or may not support the continued growth of additional TLDs and may or may not continue the concepts of sTLDs and uTLDs. Until this more substantive review is completed, the Board does not feel it is appropriate to commit to a substantial expansion of sTLDs. The Board does, however, feel that there should be an opportunity to allow those who submitted applications for sTLDs in Fall 2000, but whose applications were not successful, to have an opportunity to submit updated and revised applications at this time, as an extension of the original Proof of Concept. For the reasons presented in the Plan of Action, this opportunity is not being extended to uTLD applicants.

This RFP, and the accompanying documents listed in Appendix D, follows much of the same process that accompanied the original round of applications in Fall 2000. However, it has been updated based on experiences gained in the original round. In particular:

• It provides for the optional use of a simplified application (Option A) when the applicant plans to employ the services of a Registry Operator with whom ICANN already has an existing agreement and which is currently itself operating a registry in compliance with that agreement.
• It provides more precision and detail in the methodology to be used for evaluating applications and in the definition of the criteria to be used in those evaluations;
• It proposes the retention of independent external consultants for evaluation of the applications;
• It eliminates or simplifies much of the material required in the original round of solicitations either because the material was applicable to uTLDs but not to sTLDs or because experience has indicated that the material was duplicative or unnecessary. Two documents required in the original round have been eliminated. Two additional documents are not required if an applicant selects Option A.

Particularly in view of the refinements of this RFP, the original applications submitted in the Fall of 2000 would not meet the requirements and criteria for selection for establishment of a new sTLD under the standards required for applications submitted under this RFP. Only new applications with revised and updated information designed to comply with the requirements of this RFP can be expected to receive serious consideration. It is expected, however, that much of the material submitted in connection with the prior application will still prove useful as a starting point for the new application. The new applications, however, afford applicants the opportunity to improve over their original applications.

This RFP provides an overview of what is required to apply for a new sTLD. The documents listed in Appendix D, however, provide the details of what is required for each application. Eligible applicants are encouraged to read and consider all these materials carefully to assist in deciding whether they wish to submit new applications.

The provisional schedule listed in Planned Evaluation and Decision Schedule contemplates the Board taking action with respect to selecting successful new sTLD applicants as indicated in that schedule. This schedule, however, may change depending on intervening circumstances. Potential and actual applicants should carefully monitor ICANN's website for any changes to schedule or process.

Eligibility and Restrictions

This RFP is only open to those entities listed in Appendix B, or affiliates or successors of those entities as defined below, who applied in Fall 2000 to ICANN as sponsors for a new sTLD.

Affiliates or successors of Appendix B entities are organizations authorized in the New sTLD Application Transmittal Form to act on behalf of the original applicant in submitting the application, but for the same name(s) and for substantively the same purposes as defined in the original application. Affiliates and successors will be required to provide detail on their relationship with the original applicant in the Sponsored TLD Application Transmittal Form and provide evidence of their authorization from the original applicant.

Other Important Issues in Considering Whether to Apply

The requirements for sponsoring or operating a new sTLD are very stringent. Only applications with very high qualifications will be accepted in this round of applications, namely those that meet or exceed the requirements and score high on the selection criteria stated in the document Evaluation Methodology and Selection Criteria. ICANN reserves the right not to select any application for further negotiation if indeed none meet the stated requirements.

All approved applications will still be subject to the applicant's execution of a final agreement conforming to the Model Agreement attached as Appendix A together with applicable appendices to that Agreement. This Model Agreement substantially conforms to those agreements signed in 2001 between ICANN and the Sponsoring Organizations for the sTLD applications approved in November 2000. Organizations that believe they cannot or will not accept the terms of the Model Agreement should not submit an application as the agreement will not be re-negotiated.

The non-refundable fee payable to ICANN that must accompany each sTLD application for it to be considered for evaluation is US$25,000. This is in addition to the US$50,000 fee that accompanied initial proposals in 2000. Because of changing conditions and resulting refinements of the application materials, applications submitted in the first round in 2000 will not satisfy the requirements of this RFP. Applicants, therefore, should also expect to invest additional resources in preparation of their new applications.

This RFP is open to all entities (or their named and authorized affiliates or successors) who submitted an application for a sponsored TLD in 2000, but who were not selected in that round of applications. However, the fact of submission of the application at that time does not guarantee that the Sponsoring Organization's structure proposed by the applicant at that time qualifies as meeting the requirements for a Sponsoring Organization as defined in this RFP. Indeed, several of the applications were not accepted at that time precisely because they did not meet the requirements for a Sponsoring Organization. Potential applicants responding to this RFP are urged to review carefully the requirements for a sponsored TLD and for a Sponsoring Organization (see Definition of Key Terms below) to ensure that their application meets these requirements. An application that does not meet the requirements for a Sponsoring Organization will be rejected and not considered further.

Before deciding whether to apply, ICANN strongly recommends that prospective applicants do all of the following:

• Read the instructions contained in this RFP completely and be sure you thoroughly understand them.
• In particular, familiarize yourself with the How Applications Will Be Evaluated section of this RFP and the document Evaluation Methodology and Selection Criteria that details the factors that will be used in evaluating an application to ensure that your application meets or exceeds the requirements. These criteria will be used as the basis for the final decision.
• Secure professional assistance of experts (e.g., technical, financial, legal, business, management) to help you evaluate the chances that your application will be successful. If you decide to go forward with the application process, the help of these experts will be vital in formulating the proposal and preparing the application.
• Review all of the materials contained in this RFP, including those referenced in Appendix D, thoroughly to ascertain what information you will need to assemble and what arrangements and agreements you must make.
• Ensure that you are prepared, if selected, to enter into an agreement that conforms to the Model Agreement attached as Appendix A. You should also review the agreements, including attachments that have been entered into with the sponsors of .museum, .aero, and .coop that substantively conform to the Model Agreement. These can be found at Proposed TLD Sponsership Agreement.
• Regularly peruse the ICANN website for any updates on the process and schedule.

Applicants should also be aware that acceptance of their proposal by ICANN and entering into an agreement with ICANN does not guarantee that the new TLD will immediately function throughout the Internet. Past experience has indicated that ISPs and webhosters do not automatically allow passage of or access to new TLD strings even when these strings are authorized by ICANN, since software modifications may be required that may not happen until there is a business case for doing so. Similarly, web applications often validate namestrings on data entry and may filter out new or unknown strings. ICANN has no authority or ability to require acceptance of new TLD namestrings although ICANN does prominently publicize ICANN-authorized TLD strings on its website. As such, successful applicants may find themselves expending considerable efforts post-implementation in persuading providers of the need to accept their new TLD namestring.

The ICANN gTLD Registries Constituency has recently issued a statement on this subject (see Appendix E).

Definition of Key Terms

As the RFP is for proposals for establishment of sTLDs only, an understanding of the definition and purpose of an sTLD is critical to the development of successful applications. In particular, the terms Sponsoring Organization (the organization that sponsors the sTLD), also referred to as a “Sponsor” and Registry Operator (the organization that operates the sTLD registry) also require definition and understanding.

Sponsored TLD (sTLD) and Sponsoring Organization

A uTLD, in contrast with an sTLD, generally operates under policies established by the global Internet community directly through the ICANN process. An sTLD, however, is a specialized TLD that has a Sponsoring Organization representing a narrower but well-defined community that is most affected by policies that govern the operation of the sTLD. The Sponsor thus carries out policy formulation responsibilities, delegated from ICANN to the Sponsor, over many matters concerning the TLD.

A Sponsoring Organization is an organization to which ICANN delegates some defined level of ongoing policy-formulation responsibility and authority regarding the manner in which a particular sponsored TLD is operated. A sponsored TLD has a Charter to be observed by the Sponsoring Organization, which defines the purpose for which the sponsored TLD has been created and will be operated. The Sponsoring Organization 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 (see below) and to varying degrees for establishing the roles played by registrars and their relationship with the Registry Operator.

ICANN is responsible to the broad Internet community and the public interest in its policy development and maintenance activities. Since a Sponsor of a sTLD exercises delegated policy authority from ICANN, the Sponsoring Organization in exercising its policy development and maintenance activities must, in turn, be structured so as to be responsive primarily to the Sponsored TLD Community and the public interest as a whole. The Sponsor must exercise its delegated authority according to fairness standards and in a manner that is representative of the Sponsored TLD Community. In exercising this role, the Sponsoring Organization must not, for example, be primarily responsible and responsive to a group of individuals, such as shareholders in a corporation, or to any other primarily self-interested group. To reiterate: the primary beneficiaries of the policy development, implementation and maintenance activities of the Sponsoring Organization must be the Sponsored TLD Community and the public interest as a whole; serving these interests objectively is paramount. Furthermore, the Sponsoring Organization must maintain this mode of representative operation continuously, not just during the start-up period. Applications will be carefully screened to ensure that all these conditions are met.

The extent to which policy-formulation responsibilities are appropriately delegated to a Sponsor depends upon the characteristics of the organization. These characteristics may include: the mechanisms the Sponsor uses to formulate policies; its mission or purpose; its guarantees of independence from the Registry Operator and registrars; the extent to which the Registry Operator and registrars will participate in the Sponsor's policy-development efforts; and the Sponsor's degree and type of accountability to the Sponsored TLD Community.

The following characteristics, among others, should be present in an sTLD:

(a) registrations must be limited to registrants from a well-defined and limited community, including members of a Sponsoring Organization (if indeed the Sponsoring Organization is a membership organization);

(b) the scope of activity and the limits of registrations must be circumscribed by a clear charter;

(c) in a hierarchical policy environment, the charter must clearly define which policy responsibilities are delegated from ICANN to the Sponsor;

(d) open and transparent structures must be in place that allow for orderly policy development and the ability of members and registrants to influence the policy development and implementation process and for the Sponsoring Organization to be receptive to such influence; and

(e) the Sponsor must commit to adhere to ICANN policies as they may change from time to time through consensus processes.

Registry Operator:

The Registry Operator is an entity that is responsible for the actual operation of the registry for a TLD, including accepting registration requests (whether from registrars or directly from registrants), maintaining a database of the necessary registration data, generating zone files, and providing nameservers to publish the zone file data throughout the Internet. Although these services may be subcontracted, the Registry Operator is responsible overall for ensuring that the services are reliably provided. The Sponsoring Organization is responsible for selecting the Registry Operator for an sTLD.

A single organization can be both a Sponsoring Organization and a Registry Operator for an sTLD, provided it has the features described above that make it suitable for both roles. If a Registry Operator does not have features appropriate to a Sponsoring Organization, then the Sponsoring Organization must be structurally independent of the Registry Operator.

Application Process for a new sTLD

This section describes what is required for an application for a new sTLD to be considered for evaluation by ICANN.

Any submitted application must meet the eligibility requirements described above.

Confidential Material in Applications

All applications and supporting documentation will be posted on the ICANN website; they should not contain any confidential material.

The Non-Refundable Application Fee

Every application must be accompanied by payment of US$25,000 at the time of initial submission. Applications submitted without payment in full of the application fee will not be considered. The fee will not be refunded under any circumstances. Payment can be made (a) by certified check, drawn on a United States bank and payable to the Internet Corporation for Assigned Names and Numbers or (b) by wire transfer, in accordance with the instructions included in the form of Sponsored TLD Application Transmittal Form.

There is absolutely no assurance that any application will be approved or, if it is approved, that an agreement with ICANN will be entered into, or lead to the establishment of an sTLD. Indeed, it is possible that ICANN will not choose to proceed with any of the submitted applications or to create any new sTLDs.

Proposing Multiple sTLDs

A single application may propose up to three sTLD strings ranked in order of preference, provided those strings were proposed in the original application in Fall 2000. In the event two or three sTLD strings are proposed in an application, (a) all parts of the application must apply, without significant variation, to each string and (b) if ICANN determines in its sole discretion that one or more parts apply to different proposed sTLD strings in a significantly different manner, the applicant may be required to elect which of the strings to pursue in the application.

Application Contents

Every application must contain a New sTLD Application Transmittal Form; a New sTLD Sponsoring Organization Proposal (see Requirements for New sTLD Sponsoring Organization Proposal); a Registry Operator's Proposal (if Option B is selected: see Requirements for New sTLD Registry Operator Proposal); the Sponsoring Organization Fitness Disclosure Form; the Registry Operator's Fitness Disclosure Form; and the Application Fee. These are outlined below, but the detailed descriptions of the required documents (linked in Appendix D) should be reviewed for a complete understanding of what is needed.

Applicants are encouraged to be as thorough and complete as possible, since the submitted documents will form the basis for the evaluation of the overall proposal.

The required documents are as follows (see Appendix D for links to documents that describe what is needed in more detail):

Sponsored TLD Application Transmittal Form:

Every applicant must complete and submit the New sTLD Application Transmittal Form.

New sTLD Sponsoring Organization Proposal:

Every applicant must submit a complete proposal as described in the document Requirements for New sTLD Sponsoring Organization Proposal. The proposal contains descriptions of:

• the proposed sTLD;
• the proposed Sponsoring Organization, including the proposed extent of its policy-making authority, its proposed policy-making process, and an indication of the level of support from the proposed Sponsored TLD Community;
• how the proposed new sTLD adds value to the DNS;
• how the proposed sTLD would reach and enrich broad global communities;
• how the Sponsoring Organization would implement policies and processes to protect the rights of others; and
• how the Sponsoring Organization and its selected Registry Operator would assure stable registry operation, including provisions for assuring continuity of service in the event of business failure.

A signed Letter of Commitment or a registry services contract from the proposed Registry Operator must be attached to every New sTLD Sponsoring Organization Proposal. The requirements for the Letter of Commitment are outlined below in the description of the Registry Operator's Proposal.

Applicants would be well advised to review carefully the section below on how the proposals will be evaluated and the document Evaluation Methodology and Selection Criteria. There is a close correlation between the evaluation criteria and the information contained in the New sTLD Sponsoring Organization Proposal.

Registry Operator's Proposal:

There are two options:

Option A: This option may be used when an applicant (Sponsoring Organization) proposes to enter into a contract for registry operation services with a Registry Operator that already has an existing agreement with ICANN for the operation of one or more unsponsored gTLDs (and has therefore already previously satisfied all the requirements intended to be addressed in the material to be provided in a Registry Operator's Proposal), provided that: (a) the proposed Registry Operator is in compliance with all material terms of its existing agreement with ICANN for the provision of registry services and (b) the proposed Registry Operator is indeed itself currently providing the registry services under its existing agreement with ICANN and has not subcontracted these operations to another party. The eligible Registry Operators are listed in Appendix C.

Option B: This option must be used when an applicant plans to enter into a contract with a Registry Operator that is not listed in Appendix C.

The Option chosen by the applicant is affirmed in the New sTLD Application Transmittal Form.

Only applicants that elect Option B must complete a Registry Operator's Proposal. An applicant that elects Option A does not have to complete a Registry Operator's Proposal. Instructions for completing a Registry Operator's Proposal are detailed in the document Requirements for New sTLD Registry Operator Proposal.

All applicants (whether choosing Option A or Option B) must submit a signed Letter of Commitment (or a signed registry services contract) from the proposed Registry Operator, attached to the New sTLD Sponsoring Organization Proposal. The Letter of Commitment must indicate at a minimum (a) the willingness of the proposed Registry Operator to enter into an appropriate agreement for services with the Sponsoring Organization if the latter is successful in its application and in negotiating an agreement with ICANN; (b) the general terms and conditions of such an agreement, including its duration, that is, a term sheet; (c) an understanding that in the event of business failure of the Sponsoring Organization, the rights of the sponsor must be assignable at ICANN's request to ICANN or its designee for a period of at least one year; (d) the Registry Operator's performance obligations; and (e) provisions for handling changes of the Registry Operator, non-performance, and termination.

Sponsoring Organization's Fitness Disclosure Form:

Every application must include a Sponsoring Organization's Fitness Disclosure Form.

Registry Operator's Fitness Disclosure Form:

Every application must include a Registry Operator's Fitness Disclosure Form completed by the proposed Registry Operator.

Format of Submitted Materials

All documents listed in Appendix D must be submitted in both electronic form and printed form according to the formats specified in each document and reiterated in the Application Transmittal Form. All submissions must be in the English language (copies in other languages will be received for posting purposes, but only the English language version will be evaluated).

Each document submitted in electronic form should be submitted as an Adobe pdf (Portable Document Format) file. Each document listed in Appendix D should be submitted as a separate pdf file. The name of the file should indicate the name of the applicant and the short form name of the document (see Appendix D), such as: abc_sTLD_Transmittal.pdf.
In general, applications should answer each request in a numbered paragraph corresponding to the number of the question. Where additional comprehensive material is requested, there is only need for a single cross reference to the paragraph number of the question being addressed.

Please follow carefully these instructions and any specific instructions contained in the documents referenced in Appendix D.

Where and When to Send the Completed Application

ICANN will accept completed applications for new sTLD registries no later than [date to be announced later on the ICANN website]. This date is the absolute deadline for receipt of applications, in both electronic and printed form, and applications received after this date will not be considered.

The printed version of the application should arrive no later than this absolute deadline at:

ICANN
New sTLD Applications
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
U.S.A.

The electronic version of the application (containing pdf files; see Format of Submitted Materials, above) should be e-mailed no later than this absolute deadline to:

stld-applications@icann.org

and submitted on a CD-ROM along with the printed version.

Shortly after receiving your complete application, ICANN will send an e mail to the e-mail address listed under item C18. of your New sTLD Application Transmittal Form.

Applications must be complete in providing the information requested in this RFP and in the accompanying documents listed in Appendix D. They must also follow the required formats. Applicants are encouraged to ensure that their applications meet these requirements; material failure to do so could jeopardize ICANN's consideration of the application for evaluation and further processing, and result in summary rejection of the application.

How Applications Will Be Evaluated

Applications will be evaluated according to the methodology and the criteria defined in Evaluation Methodology and Selection Criteria. Applicants are encouraged to read this document carefully. An understanding of this document is essential to the completion of a successful application.

It is ICANN's intention to engage the services of one or more external consultants to provide an objective and independent evaluation of the applications with reference to the requirements stated in the RFP and following the selection criteria and evaluation methodology described in this document. ICANN staff may prepare reports for posting or for the Board summarizing the findings of the consultant or consultants, particularly if more than one consultant is employed or if there are additional legal or other pertinent issues that the Board must consider. Although ICANN staff will not be performing the substance of the evaluation, staff may assist in compiling, synthesizing or tabulating information for review by the Board. The ICANN Board's role will be either to accept or reject the resulting evaluations. The Board itself will not perform evaluations. If the Board comes to a determination that the evaluative process undertaken is insufficient, the Board may decide to engage in further review by either the same or a different consultant or consultants. Applicants should understand and appreciate the risk that all applications will be found deficient and rejected.

Planned Evaluation and Decision Schedule

ICANN intends to use its best efforts to adhere to the following schedule. Past experience, however, indicates that for unforeseen reasons it is not always possible to adhere to the originally stated schedule. Applicants or potential applicants, therefore, should closely monitor ICANN's website for updates to this proposed schedule.

• Release of this RFP: R-day [to be announced later]
• Deadline for receipt of questions regarding RFP: R-day + 2 weeks
• Posting of answers to questions received: R-day + 3 weeks
• Deadline for receipt of applications (Application Deadline): R-day + 4 weeks
• Evaluation period: R-day + 4 weeks through R-day + 8 weeks
• Posting of initial consultant recommendation: R-day + 8 weeks
• Deadline for comments on initial recommendation: R-day + 10 weeks
• Posting of final consultant recommendation: R-day + 11 weeks
• Posting of additional comment by ICANN staff: R-day + 12 weeks
• Deadline for comments on final recommendation: R-day + 13 weeks
• Action by ICANN Board: R-day + 14 weeks (closest Board meeting)
• Formal announcement of successful applicants: R-day + 14 weeks
• Deadline for signing of final agreements between all successful applicants and ICANN: R-day + 18 weeks, depending on number of successful applicants.

The application period as referenced in other parts of this RFP is considered to commence with the Release of this RFP and terminate with the deadline for receipt of applications.

Obtaining Additional Information

During the application period, questions regarding the new TLD application process may be sent to <stld-applications@icann.org>. To help provide all applicants with equitable access to information about the process as they prepare their applications, until the Application Deadline all requests to ICANN for information about the process or issues arising in preparation of an application must be submitted in written form to <stld-applications@icann.org>. Requests for personal or telephone consultations regarding these matters will not be granted.

Ordinarily, any responses to substantive written questions submitted during the application period will be posted on the ICANN web site. Those sending questions should take this into account in framing their questions.

After the close of the application period, all of the completed applications received will be evaluated. This process will involve not only reviewing what has been submitted, but also consulting with external experts and gathering additional information that may be pertinent to the application.

As needed, after the application period is concluded the ICANN staff may gather additional information by sending applicants e-mails asking for the information, by conducting telephone or in-person interviews with applicants, by attending (possibly with ICANN-retained experts) presentations by applicants or their experts, or by other means. These inquires will be initiated by the ICANN staff; if you feel a presentation to ICANN is necessary to properly present your proposal you should suggest that in your written application.

All materials submitted in connection with applications are subject to being posted on the ICANN web-site, accordingly, in light of privacy concerns, please redact any personally identifying information from your submitted materials (e.g., contact information on resumes). ICANN anticipates seeking comments from various groups and from the public generally on the proposals that are received.

Any other questions regarding this RFP following the application period should be addressed in writing to general-counsel@icann.org (oral inquiries will not be accepted). Directing questions, or attempting to engage in conversations with members of the ICANN staff, Board of Directors, outside legal counsel, or consultants between the time this RFP is issued and until the Board makes its final decision could be grounds for summary rejection of the application (see Open and Transparent Communications below).

Open and Transparent Communications

ICANN, consistent with its Mission and Core Values, operates in an open and transparent manner. This has implications for acceptance of applications under this RFP, treatment of these applications, and for all communications between applicants' staff and supporters, on the one hand, and, on the other, members of the ICANN Board of Directors, ICANN staff, contractors, or external legal counsel. All documents received by any ICANN Director, staff member, or contractor from applicants subsequent to the application deadline, not limited to just the application itself, will be posted on the ICANN website. Thus no confidential material should be submitted as part of the application. Direct oral communications with any ICANN director, staff member, or contractor are considered inappropriate and may be grounds for disqualifying the application, unless previously sanctioned by ICANN as part of the application process.

Appendices

A. Model Agreement

B. List of Sponsored TLD Applicants in 2000

C. List of Eligible Registry Operators for Purposes of the Option A under the description of the requirements of the Registry Operator's Proposal

D. Documents Required To Complete an Application

The following documents are required, except as indicated, to form a complete proposal:

a. Sponsored TLD Application Transmittal Form (see Requirements for New sTLD Application Transmittal Form). Electronic (pdf) filename: abc_stld_transmit.pdf, where abc is the name of the applicant.

b. New sTLD Sponsoring Organization Proposal (see Requirements for New sTLD Sponsoring Organization Proposal). A signed Letter of Commitment or registry services contract from the Proposed Registry Operator must be attached. Electronic (pdf) filename: abc_sTLD_spons_prop.pdf.

c. Option B only: Registry Operator Proposal (see Requirements for Registry Operator Proposal). Electronic (pdf) filename: abc_reg_prop.pdf.

d. Sponsoring Organization Fitness Disclosure Form (see Requirements for Sponsoring Organization Fitness Disclosure Form). Electronic (pdf) filename: abc_spons_fitness.pdf.

e. Registry Operator Fitness Disclosure Form (see Requirements for Registry Operator Fitness Disclosure Form). Electronic (pdf) filename: abc_reg_fitness .pdf.

In addition, all applicants are strongly encouraged to review and understand the document Evaluation Methodology and Selection Criteria, since this will determine how the above documents are evaluated; and also review the Model Agreement, as this will be what applicants are required to enter into if their applications are approved.

E. Statement of ICANN gTLD Registries Constituency

The following statement has been issued by the ICANN gTLD Registries Constituency:

FILTERING OF NEW TOP LEVEL DOMAINS BY THE ISP's

Since new domain names (DNS) were first introduced, top-level domains (both gTLDs and ccTLDs) have been predominantly two or three characters. Although one four letter TLD was initially created (.arpa), such domain has not been in use by the general public. Prior to November 2000, the list of valid TLDs very seldom changed, and only a few ccTLDs were added to the list, including Palestine (.ps) and Afghanistan (.af).

FILTERING NEW TOP LEVEL DOMAINS

In November 2000, however, seven new TLDs were approved by ICANN and subsequently added to the root. These included several TLDs with 4 or more characters (.aero, .coop, .info, .name, and .museum). Although the implementation of these new TLDs began in 2001, they found considerable barriers for being accepted by most ISPs worldwide. Even several of the three letter new TLDs, including .biz, ran into some difficulty in being accepted by many of the world's leading ISPs.

Some ISPs are using incomplete domain name lists for filtering e-mail and URL addresses[1] <outbind://39/#_ftn1> and it is obvious their systems that filter top-level domain names do not check and update the current validation list of TLDs ("generic" and country code-related) published by IANA at http://www.iana.org/domain-names.htm.

This is critical because when an incomplete list is used, new TLDs will not be recognized as valid domains and the system may try to reach them via different domains. For example, "entity.xxxx" is a valid name because it is included in the IANA list; however, if ISPs do not recognize "xxxx." as a valid TLD, this is turned into "entity.xxxx.com" and http://www.entity.xxxx.com" instead (and then fails or finds the wrong host).

ICANN PLANS

According to several recent reports, ICANN intends to expand the list of new gTLDs. Such expansion may take place at regular intervals. Thus, it is essential that ICANN and its constituencies, in particularly the ISPs, are aware that at present this problem exists and, as a result, new gTLDs are not able to function adequately.

New potential registry operators should be aware that this barrier exists and ICANN should consider coordinating these issues more closely. Global acceptance of all valid domain names is an integral part of maintaining Internet stability.

CONCLUSION

It is important to note:

• New TLDs, added to the TLD list in Nov 2000, are not yet globally accepted by ISPs, web hosts and e-commerce sites.

• Security techniques, which have been designed to protect the DNS system, are creating barriers for non-accessibility (acting as filters).

• ISPs, when rejecting valid forms of domain names, email addresses or URLs, effectively deny service to the user of those entities or cyber communities.

• ICANN seeks to extend new TLDs to the current TLD list despite the above-described problem.

• New potential TLDs should be made aware of this problem before submitting applications at the next opening.

RECOMMENDATIONS

As this problem is causing economical hardship to sponsors, registry operators and consumers, we recommend that the ISP Constituency along with the ICANN community collaborate more closely to minimize these problems.