GNSO Issues Report - Technical Criteria

A. Background

B. Technical Criteria — 2000 & 2004

C. Technical Criteria — .ORG

D. Technical Criteria — .NET

E. Technical Criteria — Common Elements

F. Technical Criteria — More Information Required

G. Next Steps

A. Background

1. This document reflects output from the GNSO Council New TLD Committee Meeting held in Washington DC on 24 and 25 February 2006 in relation to the technical criteria for registry services for new top level domains¹. It also recognizes the input received from a wide range of public comments, Constituency Statements and responses to a formal Call for Papers.

2. It was clear that there was a general consensus around the need for technical selection criteria to remain as a key element of any new application round for top-level domains. There was no consensus around what those technical criteria ought to look like nor how a new top-level domain application would be allocated using those criteria. The "user experience" has not been fully addressed in these discussions and needs further review, based on the PDP Terms of Reference and consideration of end user expectations.

3. The most important element of the Washington Committee Meeting was to expose the Policy Development Process' Terms of Reference to further input, in the context of ICANN's Bylaws which include a core mission and set of values that constrain policy development activities within the GNSO². Particular effort was made to ensure that lessons were learnt from the previous rounds of new TLDS and analysis of the reassignment of registry management contracts for .ORG and .NET. It is important to note the very different contexts for the 2000 and 2004 rounds and for the .ORG and .NET reassignments. The approach to the management of registry services reflects more than shifts in technical innovation — economics, size of markets, broader policy intentions and pressure from other external factors are also important considerations.

4. To recap briefly, the key issue areas under examination in this PDP are whether to introduce new gTLDs, the selection criteria associated with any introduction of new gTLDs, any allocation methods that could be used to enable the introduction of new gTLDs and the contractual conditions associated with the introduction of new gTLDs.

5. It is clear that some consensus³ has developed around the first term of reference — whether there should be new top-level domains. This "yes" answer is conditional for some constituencies on the appropriate development of robust selection criteria, allocation methods and contractual conditions⁴. Each constituency supported the introduction of new TLDs. In addition, there was little disagreement from the public comments or call for papers contributors about whether new TLDs should be should be introduced. Term of Reference 2 relates, in particular, to selection criteria which ought to be taken into account - "a) Taking into account the existing selection criteria from previous top level domain application processes and relevant criteria in registry services re-allocations, develop modified or new criteria which specifically address ICANN's goals of expanding the use and usability of the Internet. In particular, examine ways in which the allocation of new top level domains can meet demands for broader use of the Internet in developing countries. B) Examine whether preferential selection criteria (e.g. sponsored) could be developed which would encourage new and innovative ways of addressing the needs of Internet users. C) Examine whether additional criteria need to be developed which address ICANN's goals of ensuring the security and stability of the Internet." With respect to Section C) a more accurate characterization of ICANN's mission is to co-ordinate and ensure the stable and secure operation of the Internet's "unique identifier system".

6. Before turning directly to a more detailed discussion about technical criteria and the previous 2000 and 2004 rounds and the .ORG and .NET reassignments, we have outlined below some key questions which require further constituency input.

7. For example:

B. Technical Criteria — 2000 & 2004

1. The technical criteria used in the 2000 round can be found at http://www.icann.org/tlds/tld-criteria-15aug00.htm . There were nine key elements which include items that have a direct bearing on "business capacity" for registry operations:

1. The need to maintain the Internet's stability
2. The extent to which selection of the proposal would lead to an effective "proof of concept" concerning the introduction of top-level domains in the future
3. The enhancement of competition for registration services
4. The enhancement of the utility of the DNS
5. The extent to which the proposal would meet previously unmet types of needs
6. The extent to which the proposal would enhance the diversity of the DNS and of registration services generally
7. The evaluation of delegation of policy-formulation functions for special-purpose TLDs to appropriate delegations
8. Appropriate protections of rights of others in connection with the operation of the TLD
9. The completeness of the proposals submitted and the extent to which they demonstrate realistic business, financial, technical, and operational plans and sound analysis of market needs
10. There are two parts to the technical criteria required for the 2004 sTLD round. Part E of the sTLD application sets out the main areas where technical competence is required (http://www.icann.org/tlds/new-stld-rfp/new-stld-application-parte-15dec03.htm )
    1. A descriptive analysis of the registry operator's technical capabilities including key personnel, the size of the technical workforce and significant technical achievements
    2. A technical plan for the proposed registry operations (highly detailed including a description of facilities and systems; the registry/registrar model and protocol; database capabilities; zone file management; backups and escrow, WHOIS services, system and physical security; peak capacity management; system reliability; outage prevention and recovery procedures and technical support
11. The 2004 sTLD technical specification outlined above is different from the criteria for assessing compliance with the technical specification. The "measurement" criteria were used by the evaluators to analyse whether applicants could verify their claims of technical competence (http://www.icann.org/tlds/stld-apps-19mar04/PostAppA.pdf.) The main elements of the technical measurement criteria were:
    1. Evidence of the ability to ensure stable registry operation
    2. Evidence that the registry applicant conforms with best practice technical standards
    3. Evidence of a full range of registry services
    4. Assurance of continuity of registry operation in the event of business failure of the proposed registry

C. Technical Criteria — .ORG

1. The technical and registry operations criteria used in the reassignment of the .ORG registry contract can be found at http://www.icann.org/tlds/org/criteria.htm .
2. The main elements of the .ORG selection criteria were:
   1. Need to preserve a stable, well-functioning .ORG registry
   2. Ability to comply with ICANN-developed policies
   3. Enhancement of competition for registration services
   4. Differentiation of the .ORG TLD
   5. Inclusion of mechanisms for promoting the registry's operations in a manner that is responsive to the needs, concerns, and views of the noncommercial Internet user community
   6. Level of support for the proposal from .ORG registrants
   7. The type, quality, and cost of the registry services proposed
   8. Ability and commitment to support, function in, and adapt protocol changes in the shared registry system
   9. Transition considerations
   10. Ability to meet and commitment to comply with the qualification and use requirements of the VeriSign endowment and proposed use of the endowment
   11. The completeness of proposals submitted and the extent to which they demonstrate realistic plans and sound analysis

3. Compliance with the .ORG technical criteria was evaluated by an expert academic team whose results were published at http://www.icann.org/tlds/org/academic-cio-evaluation-report-19aug02.htm . The technical evaluation team focused on four key technical elements:

   1. The need to preserve a stable and well functioning .ORG registry
   2. The type, quality, and cost of the registry services proposed
   3. The ability and commitment to support, function in, and adapt protocol changes in the shared registry system
   4. Transition considerations

4. In addition, the Gartner Group evaluated elements of the .ORG reassignment process. Their reports can be found at (http://www.icann.org/tlds.org/final-evaluation-report-23sep02.htm and http://www.icann.org/tlds/org/gartner-evaluation-report-19sep02.pdf )

5. As with the .NET reassignment and the 2000 and 2004 rounds of new TLD applications, the technical criteria were exposed to public comment periods. The relevance and effectiveness of broad public comment periods about essentially very detailed and specialized registry operations require further consideration.

D. Technical Criteria — .NET

1. The .NET selection criteria were divided into absolute and relative criteria, with many of the technical criteria being absolute pre-conditions for consideration of an applicant's bid. The technical criteria were grouped with financial and business criteria. The relevant absolute technical criteria included:

   1. ICANN Policy Compliance (warranting that the applicant would comply with ICANN's consensus policies)
   2. Equivalent Access for Registrars (including specific reference to a long list of RFC standards and requirements)
   3. Registry Operations (with detailed requirements)
   4. Technical Competence (with multiple appendices to ensure technical veracity)
   5. General criteria that demonstrate, for example, technical capabilities, plans, proposed facilities, stability of resolution and performance capabilities, registry/registrar protocol models, database capabilities, network coverage, billing and collection systems, backups and escrow, system and physical security, system reliability and recovery procedures
   6. Security and stability (addressing technical and business failure)
   7. Transition and Migration Plans (addressed in Part 8)

2. The independent evaluators' report can be found at http://www.icann.org/tlds/dotnet-reassignment/net-rfp-finalreport-28mar05.pdf and an updated report with some revised scoring details can be found at http://www.icann.org/announcements/announcement-28mar05.htm . The technical evaluators themselves were required to meet minimum knowledge thresholds including "skills and experiences developed through the implementation, management and design of complex systems and demonstrated, at both standard-protocol and operational levels, understanding of the components, process and features of the Domain Name System...".

E. Technical Criteria — Common Elements

1. There are three common elements across the four instances of technical criteria being used:

   1. Stability and security of the DNS
   2. Operational capability
   3. Compliance with ICANN's consensus polices and compliance with technical standards developed by the IETF and similar technical organizations

2. Each different instance has required applicants to provide more detailed information about how they meet the technical criteria and "raised the bar" on technical and operational competence.

3. Given the views expressed by participants at the Washington meetings and through the submissions received, it is clear that demonstrated technical competence was a baseline element of any new top-level domain application process.

4. There are some other related elements to consider which include whether it is effective and relevant to conduct public comment periods on technical criteria; whether applicants should expect that their technical competence be the subject of public comment (given that this is, in many cases, proprietary and market sensitive information) and whether raising technical standards and expectations beyond that which is required to run a registry doesn't create artificial barriers to entry in the registry services business sector.

5. Finally, some analysis of risk factors is required. For example, a 2002 report on a denial of service attack http://www.rssac.org/notes_papers/2002_oct_DDoS_attack.html highlights potential risks that have been addressed at the time. No doubt, there are new and different risks that need to be quantified. A balance needs to be drawn between protecting the stability and security of the DNS and reasonable selection criteria that do not unfairly disadvantage potential new entrants to the registry services market.

F. Technical Criteria — More Information Required

1. In light of the views of constituencies and the broader user community, further information about appropriate technical criteria is required to address the Terms of Reference adequately.

2. Recapping briefly on the Constituency Statements, the NCUC argues that the best way for ICANN to do that is to make "selection criteria as simple, predictable and content-neutral as possible". The RyC, the ISPCP and the IPC all argue that the selection criteria used in previous rounds are a good starting point for new gTLDs with a focus on compliance with technical standards and network stability. The ALAC argues "ICANN should accept all applications from qualified entities that either benefit the public interest or enhance competition in the registration of domain names".

3. There is some agreement about principles of differentiation (of name spaces), certainty (of business operations), good faith (registration of names), competition (between different registry providers) and diversity (of usability). The RyC includes a detailed set of questions designed to determine what selection criteria could be removed based on analysis of whether particular selection criteria meet ICANN's technical objectives, provide objectivity, encourage different users and different uses of the Internet, allow market forces some element of influence and enable policy decisions to be made in the best interests of all stakeholders.

4. The NCUC argues that the only relevant criteria are those that would determine whether an application meets minimum technical standards established to safeguard against harm to the domain name system.

5. There is consensus on security and stability as primary objectives although how that could be achieved through selection criteria remains unclear. The NCUC suggests a "simple and objective 'registry accreditation' process, similar to the registrar accreditation process".

6. Therefore, outstanding questions which need further constituency input are, for example:

   1. Should the minimum technical criteria for registry operations be set according to the current registry operations of, for example, .NET requirements

   2. Should the minimum technical criteria make some reference to the proposed size of a new registry [to enable appropriate adjustments to be made based on the number of names under management]

   3. Should a separate registry operator's accreditation scheme be established and, if so, what should that scheme look like. For example, could compliance with existing RFCs and IETF standards be used as objective measures of technical capacity?

   4. Should other business operations criteria continue to be included in a registry operator's application to ensure that any registry operator is adequately funded and professionally managed

G. Next Steps

1. Given the timelines of the PDP, it would be helpful to have further constituency positions on the four questions posed above in time for the upcoming Wellington meetings.

2. It is proposed to conduct two full working days on Selection Criteria and Allocation Methods of which any technical criteria forms an integral part.

3. Once constituency input is received, this can be incorporated into a further draft of the Initial Report that can then be transmitted to other Supporting Organizations for their early consideration and commentary.