STATEMENT OF THE PROBLEM:
In June 2012 ICANN published close to 2,000 applications for new gTLDs. The processing of these applications consists broadly of two phases: Evaluation followed by Pre-delegation steps, then Delegation.
Given that there is a constraint on scaling the Root Zone at a rate not exceeding 1,000 new gTLDs per year, an ordering of these applications is required either at the Evaluation phase (called Batching) or at the Pre-delegation phase (called Metering).
An attempt to use the digital archery technique for Batching was ruled out at the ICANN meeting in Prague after consultation with the ICANN community. As published recently, ICANN's current plan (which might be amended by results of public comment) is to undertake the Evaluation of all the new gTLD applications in a "single batch". This process can be completed in 11-12 months, possibly less – resulting in the simultaneous publication of all initial results of the Evaluation phase in June-July 2013.
The initial results are likely to create some form of natural filtering of applications into the Delegation phase, nevertheless ICANN must plan for the possibility that Metering will still be needed.
Proposed solutions for Metering are being considered in coordination with the ICANN community. Solutions will take some time to implement, and the timeline is ultimately dependent on developmental work as well as the consultation process.
Examples of Metering techniques include:
- Restricting the number of applications as they enter into the Evaluation phase, resulting in an even flow of applications through the process. While random selection and digital archery have been ruled out, another method might be developed. It is important to note that applications are already being evaluated so a new mechanism would have to be developed quickly.
- Restricting reporting of initial results of the Evaluation phase, rather than reporting them all at once. Put another way, deciding which of the passed applications can be moved into the contract execution stage first. Criteria for deciding which applications would advance first would have to be determined.
- Advancing those applications that agree to the standard contract first. This will cause some smoothing but cannot be relied upon to resolve the problem fully. Applicants are expected to agree to standard terms.
- Advancing those applications falling into a specific category, such as IDN applications or applications originating in developing countries. This will cause some smoothing but cannot be relied upon to resolve the problem fully.
- Ordering, by some means, the pre-delegation testing of TLDs. One example would be to provide "appointments" for pre-delegation testing, limit the number of appointments, and place any who failed the testing at the end of the queue. As with other solutions, the means of determining processing order must be determined and we rely on applicant and community feedback for that.
- Ordering, by some means, the delegation of TLDs. As with other solutions, the mechanism for this is not determined and we rely on applicant and community feedback to develop this.
ICANN's objective is to provide certainty to applicants and a solution for Metering should be developed as efficiently as possible.
However at this stage it is only possible to provide a tentative roadmap for the processing of new gTLD applications. If community support emerges for a single Metering solution, the Board might be able to approve an approach after a single round of public comment. Otherwise, an additional round of community consultation might be necessary to develop community consensus.
Development of a Metering solution (tentative):
[numbers in bracket represent the ID numbers on the schedule below]
-  July 31 – August 20: Solicit input from applicants / community
-  August 21 – October 1: (Six weeks): Develop proposed solutions with the community. Publish results.
- Hold interactive sessions with applicants to collect additional information and answer questions.
-  October 2-6: Develop Board Briefing Paper: describing applicant and community suggestions, implications for applicants, risks and the degree of agreement on a proposed solution.
-  October 6: Submit Board Briefing Paper
-  October 13: Board Workshop discussion in Toronto
-  October 14 – November 11 (four weeks): applicant/community input, including a public session during ICANN's Toronto meeting.
-  November 12 – 26 (two weeks): Further develop proposed solutions.
-  December 1 – 8: Develop Board Briefing Paper describing applicant and community suggestions, implications for applicants, risks and the degree of agreement on a proposed solution.
-  December 10: Submit Board Briefing Paper
-  December 18: Board Call
-  December 19, 2012 – January 18, 2013: Solution implementation.
-  September 26, 2012: End of New gTLD application comments
-  August 27, 2012: First clarifying questions released
-  October 14-19, 2012: ICANN Toronto meeting (public session on issue)
-  October – November 2012: GAC early warnings anticipated
-  April 7-12, 2013: ICANN Beijing meeting
-  April 2013: Earliest expected GAC Advice (follows Beijing meeting)
-  May 2013: Planned finish for initial Evaluation by all panels
-  June 2013: Publication of Initial Evaluation results
-  August 2013: First delegation request
Other significant dates (tentative):
Important notes about the tentative roadmap:
- The current Evaluation phase is estimated at eleven months. This has been significantly accelerated from previously posted timelines. Additional acceleration is being sought and will be reported if and when new timelines are agreed.
- Within the Delegation phase, the timelines for contract execution and pre-delegation testing are consistent with those in the Guidebook. Acceleration of the dates for the completion of the first contract execution and the first pre-delegation test might be achieved.
- A solution for the Metering technique must be implemented before the end of the Evaluation phase on May 15, 2013. There is, therefore, some "slack" in the schedule, but it would be preferable not to wait until the last moment, as some solutions may take longer than others to implement and may no longer be viable as time passes
A graphic representation of the tentative roadmap is furnished below.