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 observers¹ 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.

Conclusion

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.

¹ 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.)