New gTLD Delegation Date Calculator – UPDATED

NOTE TO READERS: I originally posted this via the DomainDiction blog on 11 January, but since have updated the calculator and updated my comments below.  You can download the updated version here.

I’ve put together a little scenario calculator on a spreadsheet in the quest to figure out some idea of when a new gTLD might be delegated into the root zone by simply entering in the known ‘Draw number’ for the TLD application.

Hopefully it’s simple enough to understand on its own, but if you care to watch my 4-minute explanation video it might give you a better flavor for my logic in the assumptions.

My assumptions are based on the following metrics:

  • Assumed Initial Evaluation Rate (IE) Processing Rate per week by ICANN
  • I’m saying it’s 30 per week for now, but ICANN says it could ramp up to 150 per week.
  • Assumed Metering Rate per Week for pre-delegation testing (PDT) and Root Zone Entry (Delegation Processing).
  • ICANN says no more than 1,000 new gTLDs delegated in a year, so that implies a PDT and delegation rate of about 20 per week. It’s been stated that this could be ramped up to 80 or 100 per week.
  • Date ICANN has stated it will start process of releasing IE results
    • That’s 23 March 2013 at the moment
  • “Fudge Factor” – # of days PDT and beyond processes are delayed due to uknown/unforeseen issues
    • We all know there have been/will be delays. At present ICANN says on it’s microsite that first delegation requests begin on 1 August 2013, so for now I’ve added 110 days to the process as the ‘fudge factor’ to force a first delegation date in the calculated results for Priority String 1 to = 1 Aug 2013. You can change this if you believe otherwise.
    • Of course if Fadi’s comments at the recent regional ICANN meeting in Amsterdam come to life then you may want to change this to 365 days. 😦
  • # of days after IE for Contracting
    • I’m going with 7 assuming there is no negotiation and the applicant signs the standard deal. We all know back and forth and paperwork and lawyering can make this longer, but I’m thinking motivated applicants will move very fast and have some advance knowledge what they are dealing with before they even get to this stage
  • # of days to process PDT
    • I’m going with 7 based on what I’ve read. Change it if you don’t agree
  • # of days for ICANN to submit root zone delegation request after applicant passes PDT
    • ICANN is currently thinking the max. would be 10 business days. I translate that to 14 calendar days.
  • # of days for IANA to process root zone delegation request
    • ICANN is currently thinking the max. would be 30 business days. I translate that to 42 calendar days.
  • # of days after Delegation before Sunrise Period begins
    • 30 according to the Strawman proposal that all parties seem to be OK with at this time. That’s the minimum. You can change this if you think it will be longer.

If you don’t agree with my assumption metrics, or just want to play around with various ‘what if’ scenarios then have at it as I’ve designed it so you can change the numbers.

The output of the calculator provides:

  • Date initial evaluation results are released by ICANN (for the input Draw #)
  • Estimated Contracting completion date
  • Estimated PDT completion date
  • Estimated Delegation date
  • Estimated Sunrise Period start date


The calculator assumes no Contention Sets, no negative GAC advice, no Formal Objections, no delays with financials, contracting, PDT, delegation, lawsuits, Fadi decides to stop everything for 1 year, etc. It does not formally take into account that ICANN may not start any delegation requests until 1 August 2013 as currently displayed on the ICANN new gTLD microsite. It does not formally take into account that ICANN has stated that no contracting will begin until after the April ICANN meeting in Beijing is completed.


If you know that x number of contention sets are ahead of your draw #, then consider inputting an artificially lower # to generate an alternative scenario. For example: Your draw # is 942 but you believe 200 contention sets exist where the highest draw # is lower than yours — so input 742 instead.

If you feel that reasonably 100 of the 200 contention sets ahead of you might be resolved ahead of your draw #, then consider entering 842 instead.

NOTE: This tool is purely speculative, based on some facts and plenty of opinion. Finally, as many know over the years following and participating the process, the situation is likely to change. I may have made some mistakes. Don’t rely on this to make business plans.

You can download the updated version here.

The inside track to TLD success

I originally posted these thoughts in June of 2012.  I believe they still hold true today.

So perhaps you have survived reading the Applicant Guidebook, paid your fees and waded through the TAS process. Assuming your application is successful, how are you going to engage your channel(s)? What will you need to do to garner their attention? Why should they care about your TLD? What will you need to do to make them choose to work with you? Or will it be the other way around—in that YOU will need to decide who to target and YOU will need to decide who you want to work with?

I think some new TLDs will need to look beyond the traditional registrar channel, but many others will depend on the established global distribution network to help them quickly build essential new “create” revenue. Most new TLD business models will absolutely have to have this revenue just to survive year one, so let us focus on the registrar channel in this first blog post.

One need not look too far beyond the introduction of the older “original” new TLDs sanctioned by ICANN such as .info, .biz, .mobi, .tel, .asia, .museum, .jobs, .pro, .xxx etc. and “repurposed” ccTLDs such as .tv, .me, .co, .cc to learn what seems to have worked and what does not work.

Here are some things that I know that work:

Relationships. You must have them in the registry/registrar world and the domain investor (domainer) world. As digitally connected as we all are, nothing beats old-fashioned relationships.

Trust. Do what you say you are going to do. Registrars don’t like surprises and they do talk to each other. Your reputation alone may determine whether you can even get in the door.

Plan ahead. Way ahead. Registrars that matter don’t like doing things last minute.

You better have a plan that makes sense, even if you have the relationship–with-the-registrar part down. Flush it out. Twist it around a little with a few test cases, but in the end it better be spot on. Otherwise you are probably toast. You need to communicate how you are different, how your domain will work. Define the problem and what you are doing to solve it, how the registrar and end-user registrant will benefit AND of course how much money the registrar can make!

You must inform registrars of key sunrise, landrush and general registration dates/deadlines/policies well in advance. Registrars must clearly understand your application, technical and OT&E procedures. They must understand payment procedures and all fees.

BD. BD. BD. Market. Market. Market. Sell, sell, sell. If you are not doing all three you are not going to capture revenue. You must first get to the registrar and then, even if they buy your story and your deal, you will have force feed many of them with your messaging/value proposition along with other critical integration information that won’t make them choke on their morning coffee and croissant vs. all the other stuff they have to do that day/week/month/quarter/year.

What doesn’t work:

Registration restrictions. The more you have the more I can guarantee you will lose in new creates and the fewer registrars you will have in your distribution channel. It creates confusion. Besides, registrars don’t like it when they get more support calls and their costs go up. The history of the DNS is littered with restrictive policy TLDs. If you want to join me for a beer sometime I could easily discuss how much money has been made and lost in this industry with overly restrictive TLDs.

Not talking directly and often to prospective and existing end-user registrants. Those who have studied the history of the DNS know of the wall that is supposed to exist between registries, registrars and the registrar’s customers. We all know that has changed and will change again moving forward, but beyond just offering your TLD in a registrar’s storefront you must establish a relationship and build trust with your end user base. That relationship must not end a few months after launch. It must go on, for years.

Marketing and PR programs with no clearly defined goals. How will you gauge success? How will you know you are on track to achieve that success? How many registrations do you need on a daily basis to achieve your goal with your top 10 accredited registrars? Do you even know who your top 10 partners should be?

I’m simplyfing here based on past experience at dotMobi. How the TLD game is played with registrars moving forward is changing and will likely change quite a bit with the introduction of new TLDs.

The introduction of new TLDs, to the scale being contemplated at this time, represents an incredible opportunity for those that understand their market and the channel opportunities to make a difference and ultimately profit to a great extent. I look forward to examining issues in greater detail and to your feedback to get the conversation going!