On April 12, ICANN closed the TLD Application System (TAS) to ensure security of applicant data. For more than a month, the system outage has cost applicants and others millions of dollars. Here’s how to make up for lost time and money.

Donuts supported ICANN’s decision to close TAS when it realized there was a data security risk. At a critical moment, ICANN made the right choice. The company also agrees with ICANN’s offer to fully refund impacted applicants who elect to withdraw their application.

However, now that staff has communicated to affected applicants (including Donuts) and is preparing to re-open the TAS system, efficiency has grown to become a crucial element of the process. The offer to return an extra $5,000 of the application fee surely is appreciated. For many applicants, though, the real cost is continued delay.

Weeks of system interruption means continued investment of time, money, and resources. Delays on the eve of evaluation—when applicants are more fully staffed and have invested in systems, hardware, office space and, in some cases, pre-funded COIs—cost applicants far more than delays in previous years.

Or, perhaps recovery is not as hard as it might seem. ICANN could exercise reasonable discretion and make up for some of the lost time without overtaxing itself and without harming participants in the process (both applicants and non-applicants). In doing so, ICANN would probably improve a measure of its tarnished reputation.

Why this is important to everyone

This isn’t important just to applicants:

• The burden on all parts of the community must be kept to a minimum, including time and resources for review and evaluation. The more efficient this process is, the more the community’s full menu of work can be kept in balance.

• The higher the costs are on applicants, the higher the costs will become to end-users.

• The longer the delay, the more acute risks become. As we noted in a previous post, file and user names aren’t particularly actionable—but to the extent they might have been any unfair benefit is lost when the application window closes. ICANN should move quickly to reopen and close TAS as soon as is practical.

• Crisp execution brings credibility back to the machinery and processes of TLD expansion.

• Tightening the process brings much-needed predictability to all parts of the community, including, most importantly, consumers and Internet users.

The culture of risk vs. confidence

A risk-averse culture prevails over many of ICANN’s decisions and methods. This is evident in the painstaking packet-layer review of the TAS glitch. Donuts understands the Board’s and staff’s desire to be careful and thorough and to report the full set of facts.

However, how much more efficient and well regarded would ICANN be if it confidently relied on its significant accomplishments, rather than on obsessive war-room “what ifs”?

Such a change in culture is a tall order for an organization constantly dealing with outside choruses of “do it my way or else.” The TAS glitch notwithstanding, ICANN has every right to be confident in the soundness of its efforts in the new TLD program.

How to manage the clock going forward

With the clock ticking, end-users waiting, investors marking time with thousands of dollars by the day, now is the time for ICANN to make up the time lost to the TAS glitch. Here’s how:

1. Make realistic assessments of the time needed for processes and trim the excess

ICANN has mapped out timelines it anticipates it will need to complete various parts of evaluation. However, the full measure of time for many of these tasks probably isn’t needed.

Further, ICANN will gain efficiency as it works through tasks. Look at technical review as an example—a large chunk of ICANN’s evaluation task. Although there are several thousand applications, there are probably only 10 to 15 technical operators supporting those applications, and technical operators provide essentially the same set of answers for each client.

Verisign announced it’s the back-end for about 220 applications. When evaluators look at the application for Verisign’s second client, they will assess the same technical data as they did for Verisign’s first client. Put another way, there will be only 10 to 15 technical evaluations—not two thousand. Efficiencies such as these should be applied to reducing the time necessary to handle evaluations.

As Kurt Pritz said in the 17 May 2012 Registry-Registrar regional meeting, “as you realize efficiencies, you should accelerate your plan.” That is certainly the case here.

Another example is the Administrative Completeness Check, an eight-week phase between TAS closure and the start of Initial Evaluation. This three-step check was written into the guidebook to ensure: a) all mandatory questions are answered, b) required supporting documents are in correct format, and c) evaluation fees have been received.

However, two of those three items are checked at the time TAS closes (an application can’t be submitted in TAS unless all mandatory questions are answered and the evaluation fee is received). There remains just one check—that supporting documents are in the correct format. This check is merely to ensure correct formatting and does not look at the quality of answers. Is eight weeks—the current estimated time for Administrative Completeness Check—necessary for checking file formats?

2. Think well ahead, anticipate bottlenecks early

ICANN would do well to take a few hours with a whiteboard to envision where the potential for bottlenecks exist in the pipeline, from TAS closing to delegation and beyond. It’s far better to plan ahead for contingencies rather than wait until a problem is upon the community and more likely to cause another interruption.

Examples:

• How will the Board consider string approvals?

• Could ICANN conduct a test scenario for various types of string contention resolution to see what outcomes are likely and how to prepare for them?

• How will ICANN’s legal team deal with finalizing and executing the registry agreements?

3. Keep GAC early warning period to 60 days only

As staff said in its advisory on 5 January 2012, “applicants should know as soon as possible if there is a governmental concern with their application. There is a significant investment in preparing to launch a new registry and ICANN should provide answers to applicants in a timely manner. That is why the GAC commitment to a 60-day window is so valuable.”

It can’t be better written than that. With a known number of applications, the GAC’s capability to handle a preliminary review of strings and lodge early warnings within 60 days total is reasonable. Further, as Donuts has said for many years, the likelihood will be that the GAC’s blood pressure will drop dramatically when members see the actual strings applied for (no doubt 99% will be a big yawn for the GAC).

4. Don’t change batching method

Digital archery is a reasonable method for organizing batches; it’s fair, and it will work. Arguments that it’s ripe for “gaming”—whatever the definition of gaming—ring hollow. A skill that anyone can perform is a reasonable method. If an applicant were to have expertise in network operations, however, and thus a theoretical advantage in digital archery, perhaps that’s not a bad qualification for a prospective registry operator.

What would introduce new delay into the system, and thus shouldn’t be considered, are alternative methods to digital archery. This includes categorization of types of applications, having non-contested strings batched first, and other alternative means. We’ve looked at a number of alternate methods and each of them would have at least as many criticisms as digital archery does.

Further, there have been calls for changing the approach of batching contested strings together (based on the best archer in the contention set). However, there seems to be reasonable logic behind the current approach. Only one party can prevail in a contention set, but while evaluation is in progress all parties in the contention set must continue to pay salaries, office space, travel, COI, and other expenses—a significant collective sum. It’s reasonable to let these parties know as soon as possible who must withdraw. Applicants for uncontested strings incur costs as well, but they will eventually have a TLD to operate. Most applicants in contention sets will not.

Finally, there should be no delay between evaluations of batches. The second batch shouldn’t be delayed because, for example, one or more applications in the first are subject to extended evaluation. Similarly, if the evaluators specialize by question(s), there’s no reason an evaluator who finished batch one answers couldn’t start evaluating their piece of the next batch (even if some other evaluators are still on batch one). Parallel versus serial processing is far more efficient.

5. Reduce evaluation timeframes by rewarding evaluator performance

In 1994, the US state of California experienced the “Northridge” earthquake, which destroyed a section of a vital highway. The contractor awarded the repair work was incentivized to complete reconstruction as early as possible. It was in fact completed early; commuters, taxpayers, and the contractor all were winners.

A de minimis part of the application fee could be devoted to incentivizing evaluation service providers (string similarity, DNS stability, technical and operational, financial, registry service, etc.), with aggregate time savings applied toward moving delegation timelines closer.

ICANN: Manage the process more efficiently

The TAS delay hasn’t caused lasting damage to ICANN’s reputation yet, but further delays might.

ICANN should respect the interests of the new TLD applicants it so actively encouraged to apply. They will be an exciting and vibrant new part of the ICANN community. Don’t repay applicants with a few dollars for dropping out. Demonstrate professional excellence by publishing a complete timeline now, and by completing the program on time, or even early.

Richard Tindal is Chief Operating Officer of Donuts Inc., a TLD applicant.