This document is a draft
for public comment posted on 23 June 2003. Please be sure to check
the ICANN website for any later versions of this document before
you submit your application.
Establishment of new sTLDs: Request
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
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
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
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
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
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
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
(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
(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;
(e) the Sponsor must commit to adhere to ICANN policies as they may
change from time to time through consensus processes.
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
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
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
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.
Every application must contain a New
sTLD Application Transmittal Form; a New sTLD Sponsoring Organization
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
for New sTLD Sponsoring Organization Proposal. The proposal contains
- 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
- 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
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
The Option chosen by the applicant is affirmed in the New sTLD Application
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
Sponsoring Organization's Fitness Disclosure Form:
Every application must include a Sponsoring Organization's Fitness
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
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
The printed version of the application should arrive no later than
this absolute deadline at:
New sTLD Applications
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
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:
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
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
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 <email@example.com>.
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 <firstname.lastname@example.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 email@example.com
(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
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.
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
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:
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
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
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 <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).
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.
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
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.
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
concerning the layout, construction and functionality of this site
should be sent to firstname.lastname@example.org.
The Internet Corporation for Assigned Names and Numbers. All rights