ICANN Rio de Janeiro Meeting Topic: Criteria to Be Used in the Selection of New Sponsored TLDs
Posted: 25 March 2003
Criteria to Be Used in the Selection of New Sponsored TLDs
In "A Plan for Action Regarding New gTLDs", ICANN's President recommended that the ICANN Board consider immediately initiating a round for selecting three sponsored top-level domains (sTLDs), subject to verification that the sTLDs introduced in 2001 had not admitted significant numbers of registrants that lie outside of their charters. A study of that question has now been completed and shows general adherence to the sTLD charters.
In resolution 02.152, the ICANN Board directed the ICANN President to develop a draft Request for Proposals for the purpose of soliciting proposals for a limited number of new sTLDs. This paper describes proposed criteria and a proposed process for evaluating sTLD proposals, and is intended to prompt discussion that will lead to completion of a finalized Request for Proposals.
Comments are invited; they should be made at the 26
March 2003 ICANN Public Forum in Rio de Janeiro, Brazil, or by sending
e-mail to <stld-rfp-comments@icann.org>.
Contents
A. Overview
C. RFP Process
D. Criteria for Selection1. Ensure stable registry operation (30)
(a) Provisions conform with high standards in technical operation of a TLD registry (10)
(b) Demonstrates experience with registry operation (4)
(c) Provides full range of registry services (6)
(d) Assures continuity in the event of business failure (10)
2. Conform to requirements of sponsored TLD (45)
(a) Definition of community (10)
(b) Appropriateness of the sponsor and policy-formulation environment (15)
(c) Responsiveness to community (15)
(d) Commitment to ICANN policies (5)
3. Add new value to the DNS (25)
(a) Value of name (15)
(b) Enhanced diversity of the DNS (10)
4. Reach and enrich broad global communities (30)
(a) Demographic reach (7)
(b) Global reach and accessibility (8)
(c) Level of support from community (15)
5. Protect the rights of others (20)
(a) Ensures that only charter-compliant persons may obtain registrations (8)
(b) Ensures adequate mechanism for resolution of disputes (6)
This document is intended as a basis for discussion of the criteria to be used and the evaluation methodology to be followed regarding the selection of a limited number of new sTLDs following a Request for Proposals (RFP). This is consistent with Board resolution 02.152.
The document is being posted at this time for community comment and feedback. It will be discussed at the Public Forum in Rio de Janeiro, Brazil, on 26 March 2003.
Comments and suggestions should be sent to <stld-rfp-comments@icann.org>.
The document is intended to provide a framework for the development of an RFQ to be presented to the Board for consideration. It provides the following:
- A definition of what constitutes a sponsored TLD (B. Sponsored TLD)
- A brief introduction to the RFP Process (C. RFP Process)
- A full discussion of proposed criteria to be used in the selection process (D. Criteria for Selection). The numbers in parentheses after each section heading represent weights to be used in the "weights and scoring" process proposed to be used in the evaluation of proposals, as described in E. Evaluation of Criteria.
- A brief introductory suggestion as to how the proposals might be evaluated (F. Evaluation of Proposals).
Besides providing a framework for evaluation and selection methodology regarding this particular round of new sTLDs, the document equally provides a framework for future selection of new sTLDs should the Board decide that this can be made a routine process, that is, at the point when ICANN might consider the regular introduction of qualified sTLDs rather than such happening at sporadic and infrequent intervals. Presumably this would not happen at least until after the evaluation of the initial round of new TLDs, launched over the past two years, is complete.
The RFP is for proposals for sponsored TLDs only (sTLDs). The difference between sponsored and unsponsored TLDs has been described as follows:
Generally speaking, an unsponsored TLD operates under policies established by the global Internet community directly through the ICANN process, while a sponsored TLD is a specialized TLD that has a sponsor representing the narrower community that is most affected by the TLD. The sponsor thus carries out delegated policy-formulation responsibilities over many matters concerning the TLD.
A Sponsor is an organization to which is delegated some defined ongoing policy-formulation authority regarding the manner in which a particular sponsored TLD is operated. The sponsored TLD has a Charter, which defines the purpose for which the sponsored TLD has been created and will be operated. The Sponsor 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 and to varying degrees for establishing the roles played by registrars and their relationship with the registry operator. The Sponsor must exercise its delegated authority according to fairness standards and in a manner that is representative of the Sponsored TLD Community.
The extent to which policy-formulation responsibilities are appropriately delegated to a Sponsor depends upon the characteristics of the organization that may make such delegation appropriate. These characteristics may include the mechanisms the organization uses to formulate policies, its mission, its guarantees of independence from the registry operator and registrars, who will be permitted to participate in the Sponsor's policy-development efforts and in what way, and the Sponsor's degree and type of accountability to the Sponsored TLD Community.
See ICANN's "Top-Level Domains" web page at <http://www.icann.org/tlds/>.
The following characteristics, among others, should be present in an sTLD:
(a) that it be limited to registrants from a well defined and limited community, including members of a sponsoring organization;
(b) that the scope of activity and the limits of registrations be circumscribed by a clear charter;
(c) that, in a hierarchical policy environment, the charter also clearly define which policy responsibilities are delegated from ICANN to the sTLD;
(d) that open and transparent structures be in place that allow for orderly policy development and the ability of members and registrants to influence the policy development and implementation process.
(e) that the sTLD commit to adhere to applicable ICANN policies.
It is proposed, consistent with Board resolution 02.152 to prepare an RFP for the Board's consideration for a limited number of sTLDs. A prerequisite to the RFP is to obtain concurrence on the criteria to be used to select among proposals and the methodology to be followed in the evaluation. This document addresses those two points.
The RFP itself would largely mirror the format used in the recent .org re-assignment. It would be framed, however, as an extension of the Proof of Concept that was commenced through the selection of the seven new TLDs in November 2000. However, since only sponsored TLDs are under consideration, some of the considerations of that process would not be applicable. In general, however, the RFP, bidding, evaluation, and selection processes would be expected to be self-supporting from application fees to be charged. Since, however, applicants would be expected – as a condition of proposal evaluation – to agree to enter into the same (substantively) agreement framework as the original sTLDs selected in November 2000 (.museum, .aero, and .coop), it is expected that the application fee would be less than the fee charged in 2000.
If agreement on these criteria can be obtained about four weeks following their posting and discussion in the Public Forum on 26 March 2003 in Rio de Janeiro, it can be expected that an RFP can be posted for community comment shortly thereafter, subject to Board approval of the RFP.
As with this entire document, the following suggested criteria are presented for community discussion. They should be seen as preliminary thoughts subject to modification based on feedback to be received. They are presented in outline form to facilitate comment. Based on feedback received and other considerations, they will be fleshed out for inclusion in the RFP itself.
In summary then, a proposal submitted in response to the RFP will be evaluated highly to the extent it is complete and well-structured, and its acceptance would:
1. Ensure stable registry operation (30)
The overarching concern in the introduction of any new TLD is to ensure that it does not affect the stability of the DNS. There is little real concern that the addition of a few new sTLDs will significantly affect the performance of the root. However, it is important to ensure that the new registry would itself perform reliably, continuously, and in compliance with technical standards, and that provisions are made to ensure continuity of operation in the face of any business or other catastrophic failure of the registry operator.
Proposals will be evaluated more positively the more they would result in well-run operating registries that would ensure stable and continuous operation.
(a) Provisions conform with high standards in technical operation of a TLD registry (10)
The registry is expected to be operated at a performance level commensurate with standards of other gTLDs. Proposals will be evaluated with regard to this expectation. Among other considerations in this regard, proposals will be evaluated with respect to the extent that the proposed registry:
(i) Ensures continuous and correct operation;
(ii) Provides a high quality of service and minimizes unscheduled outages;
(iii) Provides for adequate data backup and recovery; and
(iv) Is able and committed to support, function in, and adapt to protocol changes in the shared registry system.
(b) Demonstrates experience with registry operation (4)
There is a lower barrier for demonstrated experience in the case of a new registry than in the assumption of responsibility of operating an existing registry (such as with the dot org re-assignment). Nevertheless, confidence in stability is enhanced if there is demonstrated experience, and credit will be given for association with an experienced operator. However, this is not a mandatory requirement.
(i) Registry operator either has itself, or plans to contract with another entity that has, experience in the operation of a name registry.
(c) Provides full range of registry services (6)
Registrants and ICANN-accredited registrars depend on registry services. The proposed registry operation should provide:
(i) At least the full range of essential services, with positive consideration being given to additional, diversified services appropriate for the TLDs purpose
(d) Assures continuity in the event of business failure (10)
Any business can fail. In the case of registries, it is critical that registry operations can continue through a business failure. Regular data escrow is a key pre-requisite to ensure this, including defining the rules of access by named third-parties to such escrow data and including providing adequate legal safeguards that survive a bankruptcy or other organizational challenge to continuity of service. Adequate and regular testing of alternate third-party backup registry capabilities is also a vital facet of survivability of service to the TLD.
This approach to ensuring business continuity replaces the approach used in the original "Proof of Concept" evaluation round in 2000. The latter largely relied on evaluation of the business stability of the proposer using largely financial criteria. This proved extremely difficult in practice. As events in the marketplace over the past two years have shown, current financial status may or may not be a good predictor of future viability. Since that time, many have suggested that the kind of criteria proposed in this subsection are more useful in addressing the problems of continuity in the face of potential business failure.
(i) Registry provides for third-party escrow of data
(ii) Regular testing of independent third-party backup capabilities and means for quick transfer of operational responsibility in the event of business failure.
(iii) Registry operator has established adequate legal framework for transfer of responsibility in the event of business failure.
These requirements might not satisfy those who would rather allow unfettered entries into the marketplace (the "Let a Thousand Flowers Bloom" school of thought), and allow the marketplace to determine winners and losers regardless of the effect that business failures would have on registrants. However, it would allow for responsible entries into the marketplace that provides for future continuity for registrants in the face of possible business failure.
2. Conform to requirements of sponsored TLD (45)
This RFP is for sponsored TLDs only. There are several key elements to the definition of a sponsored TLD that are outlined in Section B. Sponsored TLD. Because the definition of "sponsored" is key to this RFP, proposers would need to satisfy all three subsections of this Section as a minimum requirement in order to qualify for further consideration (see E. Evaluation of Criteria for further discussion).
Organizations sponsoring proposals, and the proposals themselves, will be evaluated more positively the more closely that they conform to the stated requirements for sTLDs and their sponsoring organizations.
(a) Definition of community (10)
The sTLD should be proposed to address the needs and interests of a clearly defined community, which can benefit from establishment of a TLD operating under a policy-formulation environment in which the community would participate. Thus, the community should be:
(i) susceptible of clear definition, so it can readily be determined which persons or entities make up that community that should be involved in policy formulation.
(ii) have needs and interests in common that are differentiated from those of the general global Internet community, so that there is a significant advantage to delegating specified aspects of ICANN's policy-formulation role for gTLDs.
(b) Appropriateness of the sponsor and policy-formulation environment (15)
An appropriately functioning sTLD must have a sponsor that will provide a policy-formulation environment that it appropriate to the needs and interests of the defined community. The sTLD sponsoring organization should be a not-for-profit membership organization, with a clear charter that defines permissible registrants and provides for appropriate participation of the affected community (which may be broader than the class of potential registrants) in the formulation of policies for the sTLD. The policy-formulation environment should also be clearly defined and should allow and promote participation, in an open manner appropriate for the particular community, in the formulation of policies for the TLD. The scope of delegation of the policy-formulation role need not be (and is not) uniform for all sTLDs, but is tailored to meet the particular needs of the defined community and the characteristics of the policy-formulation environment.
(i) Charter is well-defined
(ii) Sponsoring organization is a not-for-profit membership organization
(iii) Extent to which the delegated policy-formulation role is well-defined
(iv) Extent to which delegated policy development/approval mechanisms are well-designed to meet the needs of the defined community and the sTLD
(c) Responsiveness to community (15)
Mechanisms should be in place to ensure responsiveness to membership and user input, including for policy formulation and modification. There must also be demonstrated support for the sTLD, the sponsor, and the proposed policy-formulation process from the significant sectors of the defined community.
(i) Quality of processes for responding to user input
(ii) Extent of role of user community in influencing policy and services.
(iii) Support within defined community for the sTLD, the sponsor, and the policy-formulation process
(d) Commitment to ICANN policies (5)
Proposing sponsor must indicate commitment to abide by all applicable ICANN policies.
3. Add new value to the DNS (25)
The purpose of introducing new TLDs is to make the Internet and the DNS more useful and more accessible to broader communities of interest and to more end users. There must be a good reason to add a name at the top level. The objective is not simply to elevate the second level to the top level.
Proposals will be evaluated more positively the more value they would add to the DNS in this sense.
A top-level gTLD name must have broad significance and have clear, lasting value and utility. The name must also be appropriate to the defined community. (For example, a name suggestive of broad scope should not be established for an sTLD intended to serve a community that is defined to exclude significant segments of the broader scope of the name.)
(i) Proposed name categorizes broad and lasting field of human, institutional, or social endeavor or activity.
(ii) Proposed name represents an endeavor or activity that has importance across multiple geographic regions (a name suggestive of "baseball", for example, might not qualify, whereas one suggestive of "sports" might).
(iii) Proposed name/TLD has lasting value.
(iv) Proposed name is appropriate to the scope of the defined community.
(b) Enhanced diversity of the DNS (10)
The purpose of adding a new TLD is to create a new and clearly differentiated space, and to satisfy needs that cannot be readily met through the existing gTLDs. Whereas the market will largely dictate the eventual viability of new gTLDs, the purpose of launching is not just to litter the top level with names that could function just as well at the second level, nor to raise to the top level all of the many problems associated with second-level names.
(i) Proposed TLD is clearly differentiated from existing TLDs.
(ii) Proposed TLD meets needs that cannot reasonably be met in existing TLD at second level.
(iii) Proposed TLD attracts new "supplier" and "user" communities to the Internet.
4. Reach and enrich broad global communities (30)
The purpose of introducing new sTLDs at this time is not to launch a large number of sTLDs that will only serve small and very narrowly – in both the functional and geographic sense – communities, but to launch a few sTLDs with broad geographic and functional impact. Number of projected registrations is only one measure – and not necessarily the best measure – of impact; one can conceive of smaller sTLDs that nevertheless have a significant impact because they meet the needs of broad communities of users desiring to find resources on the Internet that would be served by the sTLD.
Nevertheless, given that choices need to be made, all other things being equal, greater weight should be given to sTLDs that will serve larger user communities and attract a greater number of registrants. There are issues of economic viability involved as well that add weight to this consideration. But beyond size, the scope of the charter must be given weight in an evaluation. An sTLD that solely considers apples, for example, might be less attractive than one that encompasses fruit as a whole.
Proposals, therefore, will be evaluated more positively the broader the scope and the broader the community(ies) addressed by the sTLD.
Proposals should realistically project the demographics of planned uptake, and the basis for projections. Weight will be given to those proposals that realistically anticipate broader utilization.
(b) Global reach and accessibility (8)
gTLDs are intended to serve broad global communities. The mnemonic value of the name should have broad global comprehension and appeal to the extent possible.
(c) Level of support from community (15)
A key requirement of an sTLD is that the evidence broad-based support from the community they are intended to support. There must be support from the significant segments of the defined community for the establishment of the sTLD, the sponsor, and the proposed policy-formulation process.
(i) Evidence of community support for sTLD, the sponsor, and the proposed policy-formulation process
5. Protect the rights of others (20)
Creation of new registrants in new TLDs does not imply freedom from responsibility to avoid abusive registration activities and other activities that affect legal rights of others. sTLDs by definition avoid many problems in this area since registrants are limited to defined communities of individuals or institutions, which participate in the formulation of policies for the sTLD. sTLDs, however, are required to implement safeguards against allowing unqualified registrations, and to ensure compliance with other ICANN policies designed to protect rights of others.
Proposals will be evaluated more positively the more that they protect rights of those with claims on those domain names, whether or not those claims lead to possession of those names.
(a) Ensures that only charter-compliant persons may obtain registrations (8)
Operators of sTLDs are expected to implement safeguards to ensure that non-compliant applicants cannot register domain names.
(i) Mechanisms to filter non-compliant applications
(ii) Actions to be taken if non-compliant registrations occur
(b) Ensures adequate mechanism for resolution of disputes (6)
All gTLDs are expected to adhere to the ICANN Uniform Dispute Resolution Policy. Particular dispute resolution mechanisms may be implemented to support particular situations, such as priority of acceptance of applicants in competition for the same name during start-up periods.
(c) Provides ICANN-policy compliant Whois service (6)
All gTLDs must provide accessible Whois database services to provide legitimate information on registrants for purposes that are in compliance with ICANN policies.
(i) Plans for establishment and availability of database
(ii) Any proposed limitations
6. Provide complete and well-structured proposals (20)
Proposals must be completed in responding to the criteria requirements and in providing other required information. Proposals must also be well-structured to allow for ease of evaluation.
As an aid to evaluating the various characteristics of proposals received, a point allocation is proposed among the various attributes to be considered. Each criterion receives the number of points indicated in parentheses after the criteria. Thus, the criterion "Conforms to requirements of sponsored TLDs" receives 45 points, made up of:
- Definition of community (10 points)
- Establishment of policy environment (15 points)
- Responsiveness to user community (15 points)
- Commitment to ICANN policies (5 points)
In each of the first five criteria, a proposal must receive at least 75% of allowable points (rounded up), otherwise the proposal is eliminated. Thus, in the above example, a proposal must receive 34 points, otherwise it is eliminated. There is no such restriction on the sixth criterion.
The maximum number of points possible is 170.
There is unavoidably some degree of subjectivity in the evaluation of proposals. No system can be completely objective, since degrees of judgment are involved. There is no such thing as a perfect evaluation. To minimize the consequences of this, however, multiple evaluation teams, working independently of each other, can be used with good effect.
It is proposed that two or three (depending on what the budget allows) independent external evaluation teams will be selected. By external is meant teams that are not involved in ICANN activities and are not subject to ICANN political nuances and pressures, teams that can be seen to act objectively. However, to compensate for possible lack of knowledge, a cross-constituency panel of "experts", including technical experts, would be assembled to provide advice to the evaluation teams as needed.
Evaluation teams would first reject any proposal that does not meet the minimum criteria as described in the previous section. Remaining proposals would be grouped by each evaluation team into two or three (according to the number of remaining viable proposals) "tiers" according to their evaluation scores. Proposals would be selected that were in the top tier of both evaluation teams (in the event there are two teams); or in the top tier of two out of the three evaluation teams, but not in the lowest tier of the third team (in the case of three evaluation teams).
This evaluation methodology would provide for independent assessment. Except to opine on legal questions and to provide administrative support, ICANN staff would not enter the evaluation process, although staff would synthesize the outcomes for presentation to the Board. Similarly, the Board would not intrude in the evaluation process itself; its options would be to accept or to reject the results of the evaluation.
Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
Page Updated
03-May-2003
©2003 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.