ICANN approves "digital archery" batching process

ICANN has formally approved a process for deciding which applications for new Internet extensions will be given priority.

The "digital archery" approach was approved at a special Board meeting last week with details released late Friday. It follows the approach outlined by ICANN staff a fortnight ago at the organization's meeting in Costa Rica - where it was met with significant criticism.

File, sorry, fire when ready

If there are "significantly more" than 500 applications for new gTLDs, ICANN will break applications into batches of 500. It is widely expected there will be between 1,000 and 1,500 applications, and consequently three different groups of applications.

How applications are placed into different batches has been the focus of significant interest, particularly given the uncertain market for new Internet extensions and a clear commercial advantage to launching early. There will be at least a 12-month gap between the first and third batch.

Under the "digital archery" plan, each applicant will be asked to register in an online system and set a future time "target". The ability of applicants to "hit" that target at the selected time will then be used to determine which applications are placed into the first, second, third, or subsequent batches.

Applicants log into the online system at the relevant time and "try to hit submit as close as they can to their target time". Graphics supplied by ICANN show the time interval being measured in seconds, rather than hundreds or thousandths of a second.

What could possibly go wrong (with this fundamentally flawed approach)?

Not popular

This approach - seemingly designed to avoid the possibility that ICANN could be sued for running an illegal lottery - faced significant criticism when it was outlined a fortnight ago.

Members of the organization's main policy council complained that network latency would introduce randomness (which it is specifically designed not to do); that it was clearly a "first-come, first-served" process - which the organization had explicitly ruled out; that it was open to gaming; and a range of other concerns.

That criticism continued over to the ICANN's public forum where the plan received no support and a stream of further criticism from the Internet community, along with suggestions for alternatives.

Recognizing dislike of the system, the ICANN Board's formal resolution mentions that "some members of the community have expressed concerns about whether the digital archery proposal is sensible and fair". In response, it notes that "an informal subgroup of the Board has studied the feasibility, benefits, and risks of the proposal as well as alternative batching mechanisms such as auction".

That "informal" group clearly decided that the staff proposal was the best way forward although the final resolution is notable in that it does not include voting details or notes of any discussion of the proposal. The last time the Board approved the mechanism in principle, the subsequent meeting report revealed concerns expressed by six different Board members. The report of this meeting is also expected to show significant Board-member concern.

The system for splitting applications will be crucial

Bigger problem?

The process and its approval raises broader concerns about how ICANN is handling the complex task of adding thousands of new extensions to the Internet.

With the application window closing in under two weeks, and the first extensions expected to go live before the end of the year, there are numerous elements of the program that remain undecided, and the method by which the batching process was decided has not engendered much confidence in the organization.

After months of purposefully vague announcements from ICANN's staff over how the process would actually work, the final batching system was unveiled at the last minute, and immediately met with a long list of concerns.

Partly through necessity in order to hit its self-imposed deadlines, and partly out of a strong cultural desire for control, ICANN's staff devised the batching process internally and only provided details just before the Board meeting that approved it. Public comment was overwhelmingly negative but seemingly had no impact at all on the final approved solution.

The result is that a key process has not been put through ICANN's defining multi-stakeholder process where everyone affected gets to comment on and refine a process. The idea behind that process is that flaws, inconsistencies and potential future problems are identified before a policy is approved. By stepping outside this system, ICANN risks not only creating a bad process but also losing the support of the broader Internet community if it hits problems.

Examples and other issues

A similar issue recently arose in the approval of special protections for the Red Cross and International Olympic Committee. The protections were approved by the ICANN Board at the last minute in order to move the new gTLD process forward; only afterwards were they referred back to ICANN's constituencies.

Subsequent discussion by the ICANN community questioned whether the protections should have been granted in the first place, and highlighted a number of broader problems that themselves required additional solutions. Discussion grew particularly heated at ICANN's main policy body, the GNSO Council, with angry exchanges finally requiring a special meeting in order to resolve a deadlock. There was also disagreement within the Governmental Advisory Committee (GAC).

With a number of other crucial processes still to be decided - most significantly a trademark clearinghouse and uniform rapid suspension system - ICANN's overwhelmed staff and critical but ultimately supportive Board may find itself making repeated critical errors by rushing through decisions and disregarding external review in an effort to keep the new gTLD process on track.

With each shortcut taken, ICANN risks undermining its flagship process. And with the world's attention soon turning to the creation of hundreds of new Internet extensions, as well as the effectiveness of the organization itself, that it something ICANN can ill-afford to do.