In “IP: 3 tips for navigating ICANN's new gTLD roadmap,” we showed you the contours of the Internet Corporation for Assigned Names and Numbers's (ICANN) new “roadmap” for its New gTLD Program. Now we explore ICANN's directions for applicants that have made a wrong turn or two on this long and winding journey.

On Sept. 5, ICANN announced the process and evaluation parameters for applicants to request changes to their applications. While some wrong turns are mistakes that require a simple U-turn to get back on the right road, others are more fortuitous, providing shortcuts and back ways to reach the same destination. ICANN's limited guidance on the change process leaves open the question of whether applicants can use the process strategically or tactically.

The process ICANN outlined is straightforward. Applicants complete and submit a form, ICANN evaluates the requested changes and approves (or denies) them, successful applicants confirm that approved changes are correct, and ICANN posts “relevant changes” to public portions of applications, and “summarizes” changes to confidential portions of applications. All approved changes will be reported in a “change log” that ICANN expects to be make available “soon” on the gTLD microsite.

The evaluation criteria—and how they factor into ICANN's decisions—are less clear. According to its statement, ICANN will “balance” the following seven factors:

1. Explanation: Is a reasonable explanation provided?
2. Evidence that original submission was in error: Are there indicia to support an assertion that the change merely corrects an error?
3. Other third parties affected: Does the change affect other third parties materially?
4. Precedents: Is the change similar to others that have already been approved? Could the change lead others to request similar changes that could affect third parties or result in undesirable effects on the program?
5. Fairness to applicants: Would allowing the change be construed as fair to the general community? Would disallowing the change be construed as unfair?
6. Materiality: Would the change affect the evaluation score or require re-evaluation of some or all of the application? Would the change affect string contention or community priority consideration?
7. Timing: Does the timing interfere with the evaluation process in some way?

ICANN has not provided any direction on the weight it will give each factor, the interplay of the factors or whether a minimum number of factors must weigh in the applicant's favor.  While the form only requires that applicants provide the “reason” for the change, ICANN will undoubtedly be cautious about approving changes. Applicants should expect additional questions and might consider commenting on the factors in their initial submission.

Applicants thinking of seeking an amendment should also bear in mind that while they have an affirmative duty to “promptly” notify ICANN if any previously submitted information becomes untrue or inaccurate, according to Section 1.2.7 of the Applicant Guidebook, seeking changes means delay. ICANN has not limited its time to evaluate amendments—and it plans to hold amended applications for at least 30 days before passing them to the next phase to allow for public comment. ICANN also reserves the right to require re-evaluation of materially amended applications.

Making a U-turn or Charting a New Route?

ICANN reportedly has received at least 57 requests for changes. While it has not provided information on the nature of those requests, the language of the ICANN guidance and the change request form, taken together, suggest that the purpose of the new change process is to allow applicants to fix errors in their application, rather than to make strategic changes during the evaluation process.

But even arguably “typo corrections” may prove controversial. Despite the high stakes and high application fees, mistakes can—and did—happen, including the now oft-cited misspelling of “logistics” in Kerry Trading Co.'s application for “.kerrylogisitics,” (only misspelled once among several times on the application that the domain is noted, but in the field designating the string), and the inadvertent application for the geographic TLD .dotAfrica rather than .Africa, which the applicant, Dot Connect Africa, claims resulted from the way in which ICANN set up the application and which has set off a controversy, in part because another applicant, UniForum SA, claims to have the only application for this geographic domain.

Based on the little guidance that ICANN has offered, a request by Kerry to fix the misspelled string likely would be approved. That mistake was the result of an error in typing and proofreading, and no other applicant reportedly applied for the same or similar strings. ICANN's approval of a request by DCA to change .dotAfrica to .Africa appears less likely, given the current controversy, despite the fact that DCA claims that .dotAfrica was the result of an error at least in part caused by ICANN itself.

Even if ICANN's intent is to provide a vehicle for the correction of typos and misunderstandings in directions, applicants may attempt to use the new process to make strategic changes to their applications in order to gain some ground on any competition. Applicants looking for avenues to proactively diffuse concerns raised by public comments, for example, may look to the ICANN's change request policy as a short cut around impending objections or clarifying questions that may lead to an extended evaluation period. Applicants might also attempt to use this opportunity to jump start the string contention process by joining forces with another applicant, or otherwise using the process to resolve any differences. Although these efforts are strictly prohibited by the Applicant Guidebook, they may nonetheless provide an efficient avenue for resolving competition. Because no precedent yet exists—at least not publically reported precedent—navigating the change process will be much like driving in fog, at least until ICANN begins to approve, and publish, change requests. At the very least, the change process gives all interested parties—whether applicants or not—another aspect of the new gTLDs program to monitor.