Home / Blogs

The Biggest Glitch of All - ICANN’s Batching Program for New gTLDs

ICANN’s batching program, called digital archery, is deeply flawed and should be abandoned before it causes havoc with the new gTLD program. As well as arbitrarily creating winners and losers, creating unfair advantages for certain types of applicants and for certain regions, the program may be suffering from another software “glitch” of the kind that damaged the application process. There is a much better solution: a single batch for all applications.

ICANN has determined that it can only evaluate 500 applications at a time. It is therefore using something called “digital archery” to separate applications into batches. An applicant picks a time, then attempts to click a mouse as close to that time as possible. The closer you are, the higher batch number you achieve. Combined with this is a round-robin method meant to assure that applications for different regions are fairly represented, though in practice it is grossly unfair. This entire program is flawed, unfair, and will create mayhem and ill-will. And it is completely unnecessary.

Artificially Creating Winners and Losers

ICANN’s batching system arbitrarily creates winners (those in the first batch) and losers (those in the second and subsequent batches). The advantages to going first may be enormous from an economic and market acceptance perspective. This does not comport with the principles enunciated by ICANN again and again—that winners and losers will be determined by choice and competition.

Different Than Chance?

In addition to the new “glitch” discussed below, there are other factors that make digital archery not a game of skill, but of chance. Network latencies, vagaries of the DNS, and other factors can all have an impact on how close a click comes to the target. We have also observed slowdowns on ICANN’s servers, as if caused by other processes running on them, resulting in skewed times. Fearful of being accused of running an illegal lottery, ICANN is billing digital archery as a game of skill. But really it’s a game of trying to reduce random elements—even the most skillful game players cannot be assured of winning, but only of reducing their chances of losing. Lottery players can achieve the same results by buying lots of tickets, which doesn’t make it any less a game of chance.

Unfair to Poorer Applicants

Although ICANN says this is a game of skill, to the extent that you can improve your odds with digital archery, it is a question of resources, not skill. As an example, we built software to test and calibrate our clicks. We have skilled engineers and multiple locations to test. These resources are not available to everyone.

Unfair to Certain Regions

The round-robin geographical distribution introduces another element of unfairness. Region 1 will have its best digital archery score entered into Batch 1, then the best one from Region 2, and so on, until all 5 Regions have had one turn each. Then the system will repeat the process. What this means in practice is that all applications from Africa (with few applications) will be in Batch 1, while North America, with many applications, will end up with very few in Batch 1 (disclosure: ICANN considers that TLDH’s applications are from Europe). ICANN promised that their regional selection would be proportional, but this system does not accomplish that aim, because a proportional system would have more apps from North America than from Africa, instead of the other way around.

Unfair to Non-Generics

Another feature of the ICANN’s batching system is that all applications in contention sets will be dragged into the batch of the application in that set with the best score. In practice, this means that generic names (e.g., .MUSIC) will have a much greater chance of being in Batch 1 than non-generics (e.g., .NYC and brand applications). And even though ICANN has said that it will treat all applications in a contention set as a single application for purposes of batching, this still creates a system tilted in favor of generic applications.

Another Glitch?

In testing digital archery, we discovered disturbing data that suggests the algorithm used by ICANN’s digital archery program may be flawed. This data was communicated to ICANN Friday, June 8, before close of business. This data has been replicated on several different sets of hardware, used from different locations, over several days. If our data is correct, the times recorded by the digital archery program may be subject to variations caused by an error in the digital archery system. We have an appointment to talk to ICANN staff about this issue, and they may provide a correction, but that won’t help any applicants who have already used the digital archery system.

To play the digital archery “game,” applicants enter ICANN’s TAS system and select a target time, then click a button as close to the target time as possible. The button triggers a signal at ICANN’s servers, and the timestamp recorded. The difference between the target time and the recorded time is the offset that determines the applicant’s score, referred to by ICANN as the “secondary timestamp.”

We wrote an application to click on the test button and measure the time offset. For each target time, an offset in milliseconds is determined to click before the time, to allow for network latency and other delaying factors. The time we clicked was measured, as well as the time reported by ICANN, and these times were recorded in the table below. As can be seen, the times are typically between 1 and 20 milliseconds, but with some wildly larger numbers of nearly 1000 milliseconds (shown in yellow).

Figure 1 – Digital archery tests showing discrepancy (Click to Enlarge)

Readers will notice very large times (far right column) when registering a click 1 to 5 milliseconds earlier than the target time. It is our belief that the ICANN application is creating the secondary timestamp with the wrong seconds value, but with the right milliseconds value.

A screenshot of the ICANN TAS showing the error is reproduced below:

Figure 2 – Screenshot of digital archery test with discrepancy (Click to Enlarge)

In order for applicants to adequately to assess this potential error, we urge ICANN to release the full source code of the server side application that is used to capture the timestamp.

We also note that ICANN does not report the final click times on non-test clicks. If we tried to take these readings on the one decisive click, we would not be shown our results. This strange withholding of information denies applicants the information necessary to dispute or correct any errors.

A Better Way

ICANN does not need to proceed this way. A single evaluation period for all applications would eliminate these problems. We maintain that a single batch would not actually take much longer, if only ICANN would admit what is obvious—that in large parts many applications are nearly identical.

ICANN is still operating under a premise that some observers1 have long considered dubious, and with the announcements in recent days is now no longer credible—that evaluators would have to consider a separate, distinct technical section for each application. We now know that there are about 15 to 25 registry service providers, and their technical sections are nearly identical for each application—in other words, for the vast bulk of the applications, evaluators will need to consider not 1900 technical systems, but 15 to 25. Furthermore, many of the financial sections will also be quite similar, and require less evaluation time.

As first proposed by Adrian Kinderis of ARI, ICANN should simply put all evaluations into a single batch and be done with this harmful batching process. Furthermore, there is no reason not to begin pre-delegation testing soon for the registry service providers who indicate their readiness.


As the Financial Times recently observed, “ICANN is about to get it deeply wrong” with respect to batching, and most serious observers of the digital archery process agree. The lack of transparency, the (apparent) errors in the ICANN system, the unfairness of the process and the results, and the lack of any appeal or accountability, will engender suspicion and lawsuits.

There are very few winners with the current system, and many losers. It forces single-application applicants into a binary outcome, where a bad outcome (long delays) could be highly detrimental, if not fatal. Furthermore, they are less likely that larger players to be able to achieve a high score in digital archery. Even for larger applicants, results are uncertain and could easily come out “bad.” In particular, contested applications are more likely than uncontested applications to end up in the first batch, requiring applicants to spend resources and time sorting out these with no offsetting opportunity for revenue from uncontested apps.

North American applicants in particular will be in bad shape. Both Google and VeriSign are accomplished tech companies with resources for digital archery that are orders of magnitude larger than all other applicants. Google has servers covering (almost) every inch of the planet, and it is probably unacceptable for them to lose in this “game.” If we take Google’s applications and VeriSign’s together, they may take up the entire North American allotment for Batch 1.

We believe that our company, and the program in general, will do better if there is a general acceptance that the allocation method was fair. As now conceived, it isn’t. Given ICANN’s proven expertise in glitches, we wouldn’t be surprised to see many losers demand to see the logs, examine all the systems, and in general question whether the system gave everyone an equal shot. If that were backed up by a court order, *that* would be a bottleneck that could take a very long time to unstick. With the stakes as high as they are, aggrieved Batch 3-ers are likely to turn to the courts.

ICANN should go back to its principles of promoting competition and consumer choice. Batching and digital archery undermine both of these goals. A single batch would preserve them.

1 See, for instance, my blog post of October 2011, which says, “ICANN’s reluctance to accredit registry service providers is the greatest source of unnecessary cost and delay in the post-application period.

Without a doubt the biggest inefficiency of ICANN’s new gTLD process is the silly requirement of answering the entire tech section for each and every application. There are only a few registry service providers—Minds + Machines is one of perhaps ten—and nearly every application will use one of them. Although it’s theoretically possible to file an application for a system that’s not yet built, the level of detail required by the application effectively requires an existing, working registry. And yet for each new gTLD application, the tech section, the bulk of the application, will be reviewed anew in its entirety. So if there are 1000 applications, the evaluation of the tech section will be duplicated effort for 990 of them. I defy anyone to defend this as sensible.

Why did ICANN not simply accredit registry service providers, so that applications using accredited providers would not need to be tested and retested? Given that the application fee is based on cost recovery, an accreditation process would surely have reduced the $185,000 to something more manageable. Now that this opportunity has passed, accrediting registry providers for the five core registry functions is surely possible.” (Italics in the original.)

Filed Under


Why Not Process on First Come First Served Basis? Is ICANN "Out of Touch" ? William Sandler  –  Jun 11, 2012 3:35 PM

Presumably the applications are time-date stamped. Seems that the first come first served model is simple. Sure, it gives advantage to those with deeper pockets (to pay the lawyers and technical professionals needed to prepare/perfect application speedily), but seems as simple and fair as a supermarket cue.

If its “too late” for this (because it was not announced in advance and applicants did not “race” to apply first), administering an online game ‘requiring skill’ is counter intuitive, fixes nothing and will exacerbate the problem itself.

TLD’s that come live sooner in time have commercial advantage over those coming later in time. Duh. ICANN knew this and so too did the domain industry and most of the public too. In light of this, shame on ICANN for dealing with this so poorly and in a way that further erodes trust and legitimacy.

ICANN has become, by historical accident a large bureaucracy, whose decisions have every greater impact upon governments, companies and individuals world wide. The approval of .xxx was made with disregard for the externalities caused (and to be caused) around the world: ICANN’s desire to thumb its nose at the US Dept of Commerce drove ICANN’s decision, not “safety and security of the root” which lies at its mission.

By handling affairs in semi transparent way, and utilizing unnecessary and byzantine complexity, ICANN has “poison pilled” itself. That is, ICANN is handling affairs in ways that make it appear that their underlying mission and work is more difficult than it really is - - dissuading prospective replacements.

The relationship between the new gTLD program and ICANN’s own budget (including executive pay) would be a nice dissertation topic or some good work for small team of investigative journalists.

Seems likely that one or more (or perhaps a certified class of plaintiffs) applicant’s will sue ICANN, which will be a bonanza mostly for the lawyers This in turn could cause ICANN to raise its fees to cover ever increasing litigation costs and barriers to entry into the DNS space will climb ever higher. One of the benefits of this litigation, however, will be exposure of the internal machinations of ICANN, which are - - despite their own protestations to the contrary - - opaque.

Alternatives to ICANN? Organization(s) with authority/competence of oversee ICANN? Utilize international audit firm to help ICANN administer itself and the root?

What to do about ICANN, governance and the public interest? That is one of the most important topics of the day, is not going away rather getting more urgent over time. 

William Sandler

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



New TLDs

Sponsored byRadix


Sponsored byDNIB.com

Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global


Sponsored byVerisign

Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign