Delegation wait time varies wildly for new gTLDs

New gTLDs get delegated on average 70 days after they sign their ICANN Registry Agreement, but the duration of the wait varies quite a lot by registry, according to DI research.
For the 145 delegated new gTLDs I looked at, the delegation has come 39 to 151 days after contract signing.
After signing an RA, registries have to enter into Pre-Delegation Testing before their strings are handed off to IANA, Verisign and the US Department of Commerce for delegation.
The Applicant Guidebook states that this transition to delegation phase is expected to take approximately two months. On average, ICANN seems to be only slightly missing that target.
The differing wait times could be attributed to any number of reasons. Difficulties during PDT, registry choice, geography and holidays could all see some take longer than others.
Donuts, which is responsible for almost two thirds of the gTLDs I looked at, seems to have refined the process to an art, getting its gTLDs delegated on average 62 days after contract signing.
There are currently 125 gTLDs that have contracts but have not yet been delegated, according to our records.
Here’s the table of delegation wait times, for those interested.
[table id=27 /]

dotShabaka Diary — Day 2

This is the second in DI’s series following the progress of شبكة. applicant dotShabaka Registry as it prepares to be one of the first new gTLD registries to launch.
The following journal entry was written by dotShabaka general manager Yasmin Omer:

Date: Saturday 10 August 2013
It has been nearly a month since we signed our Registry Agreement with ICANN and we are still confused about TMCH Integration Testing, which is a concern given it’s now seven weeks out from ICANN’s first delegation date.
Whilst we have access to the Sandbox LORDN file test environment, ICANN happened to mention that the ‘OT&E environment’ is available in this week’s webinar. That’s new information.
We still have no idea what the process is for TMCH integration testing or how we access the environment. Are there test cases? What’s the schedule?
The lack of information is a concern as we need to pass TMCH Integration to provide Sunrise notice. Let’s hope it’s not as complicated as PDT.
In other news, we received an email from Wendy Profit (Registry Product Manager) yesterday. It’s the first formal email we have received since signing our contract nearly a month ago.
The email contained a copy of the contract and a spreadsheet for contact details. Not sure if Wendy is indeed our account manager or if we even have one. We have sent an email asking her the same. Clearly we have a few questions for an Account Manager once we get one.

You can read past and future entries in this series here.

Delay not certain as new gTLD contracts reopened

The launch window for new gTLDs may have just got pushed back another month or two, following the announcement of a new 42-day comment period on registry and registrar contracts.
But ICANN CEO Fadi Chehade said he’s looking at ways to streamline the process to offset the delays.
During the public forum in Beijing yesterday, ICANN CEO Fadi Chehade said that he’d cancelled a scheduled April 20 meeting of its board of directors, during which the new agreements were targeted for approval.
Instead, new versions of the 2013 Registrar Accreditation Agreement and new gTLDs base Registry Agreement will be posted for public comment next week.
As these are expected to be the final versions of both documents, they’re also expected to have full comment periods of 42 days — 21 for comments and 21 for replies.
“I believe that putting the last version of RAA for 2013 out for full public comment process is actually strengthening that agreement,” Chedhade said today. “It makes it an agreement of the community.”
For the Registry Agreement, Chehade said talks with registries are going well and that he hopes to have a version ready for public comment agreed with negotiators in less than a week.
Assuming an April 19 start, that puts the earliest possible date for ICANN board approval at May 31, assuming the board waits for the comment period to end before giving it the rubber stamp.
Before the contracts are approved, they can’t be signed by registries and registrars, and before they are signed new gTLD applicants cannot progress to the final pre-launch stages of the delegation process.
But Chehade is weighing an idea put forward during the public forum by Donuts’ Jon Nevett: why not allow applicants to complete pre-delegation technical testing before contract signing?
“We could potentially do something about advancing this step ahead of contracting, finding a way to start pre-delegation testing before contracting is done,” Chehade said.

Swedish registry wins new gTLD testing contract

The registry operator for Sweden’s .se ccTLD has been picked to provide pre-delegation testing for new gTLDs.
ICANN announced at the weekend that Stiftelsen för Internetinfrastruktur has won the two-year contract, which will see the organization scratch-build a testing suite and have it up and running by March.
ICANN said .se “has proven track of technical capability, operations excellence, and significant experience in the industry”.
The registry has a pretty good record when it comes to cutting-edge domain name technologies — .se was the first TLD to implement DNSSEC, preceding .com by about five years.
All new gTLDs will have to run DNSSEC, the cryptographically signed DNS protocol, from the outset, and testing such services is part of the pre-delegation testing provider’s remit.

ICANN expecting to approve most new gTLDs?

Good news for new gTLD applicants?
ICANN appears to be assuming that the vast majority of applications will pass their evaluations and make it at least as far as pre-delegation testing, judging from recent comments.
Of the 1,400-odd unique strings being applied for, ICANN reckons that “close to the maximum” will need to be tested before being added to the DNS root.
The hint came in a Q&A with respondents to ICANN’s pre-delegation testing provider RFP published yesterday.
With added emphasis, here’s what ICANN just said:

Question 7: Can ICANN provide a definitive statement of the anticipated minimum number of pre-delegation tests?
The total number of applied-for strings that will be approved is unknown at this point. Therefore, we cannot assert the minimum number of registries to be tested but only the maximum: 1,400. We expect that the actual numbers of registries tested should be close to the maximum.

It’s a positive sign for applicants, but there are obviously some big unknowns in the process, most notably Governmental Advisory Committee interventions, which are a little under a week away.
On the negative side, ICANN seems to be digging its heels in on the number of pre-delegation tests that will be required, despite recent requests from applicants to streamline the process:

Question 17: Is it possible to execute a single test per Back-End Registry Service Provider (as this would limit the requirement to about 80 such tests)?
The AGB [Applicant Guidebook] specifies one Pre-Delegation Test per Registry Operator (contracted party to ICANN).

This appears to mean that multiple applications using Verisign or Afilias, for example, as their back-ends will have to be individually tested, despite possible duplicative work.

ICANN looking for new gTLD testing provider on very tight deadline

ICANN is seeking one or more pre-delegation testing providers for its new gTLD program on a very ambitious timetable.
An RFP issued yesterday calls for a company that can scratch-build a testing suite to put new gTLD applicants through the ringer before they go live, and have it up and running by March 25, 2013.
Pre-delegation testing is the last stage of the new gTLD program’s approval process.
Some new gTLD applicants have recently called on ICANN to begin testing as soon as possible — before even Initial Evaluation has finished — in order to speed up time to market.
The Applicant Guidebook suggests that ICANN itself would be doing the testing, and some applicants had made that assumption, but that’s clearly not the case.
The RFP spells out exactly what is required of the testing providers.
First, they’re expected to build bespoke software to run the tests.
In addition to load-testing and verifying the registry’s compliance with standards such as EPP, DNSSEC and Whois, it also needs a custom-made user interface for applicants and back-end integration with ICANN’s wobbly TLD Application System.
ICANN also wants to be able to open-source the software, which seems to rule out any off-the-shelf testing suites.
RFP respondents also need to be able test 20 applicants’ back-ends per week — potentially scaling up to 100 per week — as soon as ICANN starts signing registry agreements next year.
ICANN does not expect to announce the winning provider(s) until December 5. The deadline for responses is November 20.
In short, it looks like a challenging project on a very tight deadline.
I wonder how much institutional knowledge there is out there of, say, DNSSEC, in companies that are not also involved in new gTLD applications as either applicant or back-end.
The pool of possible RFP respondents is likely very small indeed.
The ability to run tests on the testing suite itself may also be limited by the timetable and the possible shortage of guinea-pig registry back-ends.
Why ICANN has waited until this very late date to issue the RFP is a real head-scratcher.
ICANN is offering a 24-month contract with a possible 12-month extension. The RFP can be downloaded here.