It was with great interest that I read a recent announcement about a plan by the International Telecommunications Union (ITU) to publish template answers on a wiki for the 22 questions relating to registry technical operations contained within ICANN’s new Top-Level Domain Applicant Guidebook.

As someone who has spent the best part of six years following the development of the program (witnessing first-hand each evolution of the Applicant Guidebook) my first thought was one of bemusement—How can a generic solution taken “off the shelf” accurately demonstrate whether an applicant is capable of understanding the technical requirements for setting up and operating a new Top-Level Domain?

Quite frankly, it can’t.

The application process for new Top-Level Domains (TLD) has been carefully designed by ICANN to thoroughly examine whether an applicant has performed the required research to adequately understand what it means to own and operate a vital piece of Internet infrastructure. Operating a TLD is a huge responsibility that should not be taken lightly. The application process has been created in its current format to determine this.

For the applicant, the risk of landing in Extended Evaluation, ICANN’s special audit system for applications that require further attention, is far too great to be toying with a one size fits all approach. In an attempt to save money, applicants will instead be at risk of losing at least $150,000 should their application fail the evaluation criteria set by ICANN.

While consultants working closely with the ITU are correct in stating that applicants do not have to be currently operating Domain Name Registry Systems, they still must identify the technical solution that supports the specific Registry requirements of the application in question. The financial and organisational descriptions must do the same.

The solution proposed by the ITU becomes even more unrealistic when you consider the following:

• Registry technical operations must identify the intended registry system specifications such as: domain name lifecycle, servers, software, infrastructure, data centres, bandwidth providers, policies & procedures etc. Those who know will agree that this is impossible to do generically.
• Any Registry Services provider worth a pinch of salt is offering the ‘technical operations’ component of the application free of charge with their back-end registry services solution. One has to question whether the approach suggested by the ITU is one that delivers a significant increase in risk without actually delivering any tangible cost reduction?
• This is not a turnkey solution. Applicants will still be required to provide answers to non technical and financial sections, answers which need to be consistent with the information provided in the technical sections of the application, so those who consider the ITU’s approach will struggle to establish consistency throughout all sections of the application.
• Without having properly researched, designed and finally settled on a technical solution, whether that be to outsource to industry experts, or build in-house, Applicants will not have the ability to identify information for other areas of the application such as Registry set up and operational costs that will be critical to the successful development of sound and accurate financials. Further, how will applicants be able to demonstrate to ICANN that the technical specifications provided can be delivered on?

From my perspective, taking answers from another entity (whose content has no relation to any registry system (real or proposed)) clearly demonstrates two things: 1) You are proficient with the cut and paste function of your keyboard and; 2) You clearly lack the understanding necessary to manage a critical piece of Internet infrastructure such as a new Top-Level Domain.

As any high school student can tell you, cutting and pasting answers from a wiki is prone to failure. Although the ITU claim that only ‘approved contributors’ will be able to edit the information, it is unclear how someone would be granted ‘approved contributor’ status. With the highly competitive nature of the TLD process, Applicants should be aware that the accuracy of the information contained within the template has the potential to be highly dubious and potentially even prone to subtle sabotage. I have no doubt that ICANN’s evaluators will be on the lookout for these responses, just like any good teacher would do.

The message to prospective applicants here is simple: If you show disrespect to the evaluators and don’t give the technical criteria of your application the attention it truly deserves, then why should they take your application seriously.

I am left with two equally horrifying questions: 1). Is this simply an attempt by the ITU to devalue and undermine the entire new TLD application process (and therefore ICANN)? 2). Does anyone at the ITU truly understand the goals of the application process and what it is intended to do?

Were the ITU’s ambitions truly altruistic, they would spend their efforts providing capability advice and skills to the community. This approach would be useful and would not water down the quality of submissions to ICANN, as this solution almost certainly will.

Finally, this blog does not set out to be self-serving. Yes, there is a level of confidence that comes with choosing a back-end registry provider that is established and experienced. However, ICANN has ensured that anyone who can fulfil the technical requirements will be awarded a TLD Registry. So, the point I am making is that the process of fulfilling the technical requirements of a new TLD Registry involves more than a simple cut and paste. It requires communicating a level of understanding that a new TLD is a piece of mission critical infrastructure and that there are enormous responsibilities that come with this.