At the end of July, ICANN opened a public comment period to gather input from the community about how it should handle the issue of batching new gTLD applications. gTLD Strategy readers will remember that once Digital Archery met its bitter end during the last ICANN Public Meeting in Prague, the ICANN Board had not yet come up with a fair but feasible solution to the quandary of limiting the number of gTLDs entered into the root to 1,000 in a year.
Having worked with over 50 companies to prepare their new gTLD applications, and as new gTLD applicants ourselves (for .FAIRWINDS), we set our minds to coming up with our own solution for how ICANN should deal with this issue. We considered a variety of options: ICANN could simply let the natural delays inherent in the application evaluation process (Contention Sets, Extended Evaluation, etc.) basically “batch” the applications organically. Or, ICANN could release the results of Initial Evaluation on a rolling basis, thus letting applications move toward delegation on a rolling basis. Or, ICANN could prioritize applications for community-based gTLDs and IDNs (new gTLDs in non-Latin characters) above standard applications, of which there are just 116.
Unfortunately, each of these options raised almost as many issues as they resolved. So after a great deal more thought, and close consideration with 28 clients who participated on a special conference call to discuss the matter, we ultimately arrived at what we believe is an effective but equitable solution for most applicants. We dubbed our process FIFO after the accounting principle: First In, First Out.
You can read the full comment that we submitted to ICANN here, but our FIFO plan consists of a few key elements that ensure greater transparency and fairness:
- First, all results of Initial Evaluation should be posted at once.
- Any applications that must proceed to Extended Evaluation or Contention Sets, or must deal with Objections, should do so.
- All other applications should proceed to the Registry Agreement negotiation phase. As applicants return their signed Agreements, ICANN should process the Agreements and pass applicants on to pre-delegation testing on a FIFO basis.
- Once applicants have passed all pre-delegation tests, their applications will be inserted into a queue for delegation, again on a FIFO basis.
- Finally, ICANN should establish a portal that tracks the progress of all applications through the pre-delegation process so that the community may see where each new gTLD stands.
The process itself is fairly straightforward and takes advantage of the natural ebbs and flows of the application evaluation process. This is key because, as we have written previously here on the blog, there are technical limitations to how rapidly ICANN can delegate gTLDs into the root zone – the current wisdom is that no more than 1,000 gTLDs may be inserted into the root within a year.
A key component of this approach is that it puts control in the hands of applicants. If applicants want to delegate their gTLDs early, they must be willing to be more flexible in negotiating their Registry Agreements with ICANN. If they prefer to wait to delegate their gTLDs later, they don’t have to rush the negotiation of their Agreements. But perhaps more important than putting the control in the hands of applicants, we emphasize a great deal of transparency on ICANN’s part throughout the whole process. In addition to posting all the results of Initial Evaluation in a public forum, we also encourage ICANN to open a public comment period to discuss the current Registry Agreement, and we believe many aspects of it should change in light of the scale of the New gTLD Program as well as the diversity of applicants.
We submitted our comment to ICANN over the weekend, and according to the recent “Roadmap” that ICANN posted on the new gTLD site, a solution should be finalized later this year, most likely after the Public Meeting in Toronto. We’re looking forward to continuing to participate in this process and encourage our clients and readers to do the same.