6 ways to solve new top level domain “metering” problem
Saturday, August 18th, 2012
Six examples of ways to meter top level domains, but many of them are basically the same things.
ICANN plans to allow only 1,000 new top level domain names into the root per year, and as evenly as possible over a 12 months time span.
Its initial idea for figuring out which domains go first — so called “digital archery” — was scrapped. Now the non-profit has come up with six new alternatives. It hopes to figure out a solution by December.
Here are six examples of metering techniques ICANN is considering, along with my comments. You’ll note that four of them are basically batching done at different stages.
1. 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.
[Since it seems ICANN is already evaluating all applications in a single batch, reversing course now would cause problems.]
2. 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.
[This is basically batching, but done after a single batch evaluation process is complete. That is counter-productive; it will slow down the entire process. If you're going to batch, you may as well batch evaluations as well to decrease the time before the first TLD goes live.]
3. 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.
[Makes sense, but most applicants will accept the standard terms and thus it doesn't solve the problem.]
4. 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.
[I can't wait to see how it's determined which types of domains or applicants get favored status. I don't see this happening. Even if it did, it would only solve the initial couple hundred domains.]
5. 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.
[Similar issues as 1 and 2. Basically batching after the fact.]
6. 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.
[See numbers 1, 2, 5, and 6]