Skip to main content

New gTLD Program Delegation Deadlines

Newgtld program delegation deadlines 750x425 21apr16 en

Tremendous progress has been made in implementing the 2012 round of the New gTLD Program. To date, registry agreements are in place for more than 1,230 new generic top-level domains (gTLDs), and more than 950 of these new gTLDs have been delegated into the root zone. The ICANN team is here to help registry operators navigate the final few steps toward the shared goal of delegation. Our tasks include informing registry operators of key deadlines and their associated impacts.

The New gTLD Registry Agreement defines a 12-month period after contract execution during which the registry operator must delegate its TLD. ICANN expects registry operators to honor this commitment, and most do. However, we've recently seen an uptick in registry operators who either haven't met their deadline or aren't on track to do so.

There are about 200 TLDs with approaching delegation deadlines between now and the end of August 2016. ICANN is working directly with these registry operators to support them in this process. Additional information for registry operators is on the Pre-Delegation Testing page on the New gTLD Program microsite.

If a registry operator does not meet its delegation deadline, ICANN has the option to terminate the registry agreement, as per Section 4.3(b) of the agreement:

§4.3 Termination by ICANN

(b) ICANN may, upon notice to Registry Operator, terminate this Agreement if Registry Operator fails to complete all testing and procedures (identified by ICANN in writing to Registry Operator prior to the date hereof) for delegation of the TLD into the root zone within twelve (12) months of the Effective Date. Registry Operator may request an extension for up to additional twelve (12) months for delegation if it can demonstrate, to ICANN's reasonable satisfaction, that Registry Operator is working diligently and in good faith toward successfully completing the steps necessary for delegation of the TLD. Any fees paid by Registry Operator to ICANN prior to such termination date shall be retained by ICANN in full.

Although ICANN expects registry operators to meet the 12-month deadline, Section 4.3(b) provides an opportunity for a registry operator to request an extension. If the registry operator is working diligently and in good faith to achieve delegation within the agreed-upon timeframe, ICANN will work with the registry operator to provide a reasonable extension and avoid termination.

Contracted parties often ask for examples of what ICANN defines as "working diligently and in good faith." Generally, activities such as scheduling and following through with Pre-Delegation Testing (PDT) appointments and completing the Onboarding process fall into this category. If ICANN grants an extension to the delegation deadline, interim deadlines for the remaining milestones to delegation will be established. Meeting these milestones within the defined timeline shows continued diligence and good faith.

So what happens if circumstances lead to a termination by either the registry operator or ICANN? After a notice of termination is issued and ICANN consults with the registry operator, we publish information regarding the termination on the ICANN website (see Registry Agreement Termination Information) to ensure that termination information is transparent and available to the public. This information includes the termination notice and ICANN's preliminary determination on whether the TLD should be transitioned to a successor registry operator. Interested parties may review and submit feedback on ICANN's preliminary determinations, which are publicly available.

I hope this message has provided some clarity on this topic. If you have questions or comments, please email the team at


    amitzale  09:25 UTC on 15 December 2016

    thanks for sharing

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."