ICANN Draft Applicant Guidebook: Summary of Key Findings

Key Findings 

  • Application Process Changes  
    • The estimated timeline for a standard application has increased from 9 months (2012 AGB) to 15 months due to additional steps in the process. 
    • Updates to program processes, such as amending contention resolution and adding appeals, contribute to the extended duration. 
  • New Complexities in Contention Resolution 
    • “String Replacement” allows applicants to change their applied-for gTLDs to avoid contention but adds new procedural steps post-Reveal Day. 
    • Auctions and Community Priority Evaluations (CPE) remain critical tools for resolving contention sets, with the settlements, joint ventures, and private auctions from 2012 no longer being options. 
  • Introduction of Appeals into Objection Workflows 
    • Appeals are now integrated into all objection categories, enabling applicants to challenge unfavorable decisions — balancing fairness though adding more layers to the overall processes. 
  • TAMS Replaces TAS 
    • ICANN’s prior TLD Application System (TAS) will be replaced by the TLD Application Management System (TAMS), which promises to deliver technical gains in automatically performing pre-validation processes and handling applications securely. 
  • Governmental Advisory Committee (GAC) Influence 
    • The GAC still retains influence on applications through “Early Warnings” like in 2012, as well as the updated “GAC Consensus Advice,” which can now be issued at any stage of the process. 
    • Public Interest Commitments (PICs) and Registry Voluntary Commitments (RVCs) provide tools to address GAC concerns proactively. 

Recommendations 

Organizations preparing to apply for their own dotBrand gTLD during ICANN’s New gTLD Program: Next Round 2026 application window should: 

  1. Strategically Plan for Increased Timelines
    • Account for the longer process and additional evaluation phases. 
  2. Allocate Resources for New Processes
    • Prepare for the possibility of string replacements, appeals, and other process adjustments that are new since the 2012 round. 
  3. Work With the Experts
    • Markmonitor can advise you through the application process, putting you in great position for a successful application that can result in the delegation of your desired gTLD. 

An In-Depth Review of the ICANN Draft Applicant Guidebook

As you may be aware, the final draft of the Applicant Guidebook (AGB for short; referred to hereafter as either 2012 AGB or 2026 AGB by the year of the respective application round) – or the rules and requirements for submitting a generic Top-Level Domain (gTLD) application in the ICANN New gTLD Program: Next Round – was posted for public comment on May 30. The public comment runs through July 23, 2025, and ICANN has provided a number of resources that can help the community to determine what public comments were previously received in the first, second, third, and fourth proceedings from February 2024 to February 2025. The final version of the 2026 AGB is to be approved by the ICANN Board later this year and formally published in December 2025.  

The prior version of the AGB was from the 2012 New gTLD Program, and while similar in many ways, the new draft also includes many new concepts. Like a good meal, it has taken a bit of time to digest the whole guidebook (it is at a ‘light’ 395 pages, up from the 338-page 2012 AGB), so now on to a few thoughts.  

Efficiency, Opportunity, and Fairness… at the Cost of Complexity 

1. The Applicant Journey Grows 

The 2012 AGB was very complex in its own right, but it had relatively straightforward processes – see p. 1-4 for a graphic on processing stages, which had eight action symbols: 

 On the other hand, the 2026 AGB process overview (p. 45) is now up to 28 action symbols:  

Likewise, the 2012 AGB says the “lifecycle for a straightforward application could be approximately 9 months”(p. 1-15). In the 2026 AGB, the estimate for “a simple and standard application” (p.46) is now “15 months” (p. 47).  

Now this isn’t all bad; in the ensuing 13 years of policy development and implementation, ICANN and the community have learned some lessons and tried to better utilize resources in setting up the new process. That is, things like developing the Registry Service Provider Evaluation Program and the Applicant Support Program as their own discrete processes outside of the main application workflow, which should cut wasted time and effort throughout the evaluation process. Similarly, the shifting of Name Collision into an earlier Temporary Delegation period and the splitting of the applicant evaluation and application evaluation should better utilize time and labor efforts overall.    

Now, what are the primary factors in adding time to the 2026 AGB processes? Two things: trying to tame the beast of contention sets while adding appeals to the overarching processes. 

2. Changing Contention Processes – String Replacement / Auctions 

[Editor’s note: For the next section, per the 2026 AGB, the term string means “the string of characters comprising an applied-for gTLD (p. 392)” (or the word or letters to the ‘right of the dot’ in the gTLD).] 

As discussed previously, since the 2012 Round, the ICANN Community and the ICANN Board have negated the idea of settlements, establishing of joint ventures, and private auctions as ways to resolve contention sets. Now, the only ways to break contention are moving to a replacement string after Reveal Day (or for Brands, a Brand String Change later in the process), successfully completing Community Priority Evaluation (CPE), or entering into an “ICANN New gTLD Auction” (formerly called an “auction of last resort” in the 2012 AGB (p. 4-19)). The concepts of changing an applied-for string are new to the 2026 AGB, as it is a way for ICANN to inject flexibility in the process to try and minimize the creation of contention sets, as they can only be broken via auctions (the bulk of the time) and CPE in a likely small number of cases.  

However, by introducing these string change concepts, ICANN adds more steps and time to the overall application process. For instance, there is now a new 14-day post-Reveal Day ‘Replacement Period’ where an applicant can “review the published application information and notify ICANN if it elects to replace the original applied-for string with its replacement string” (pp. 121-124).  

Regarding the “Brand String Change Request,” if “an application for a Brand TLD is found in contention, the applicant will have the option to change the applied-for string to try to avoid further contention by submitting” such a request (p. 131). And a “Brand String Change can only be submitted up to 30 days following: 

  • The formation of contention sets after String Similarity Evaluation; or 
  • The publication of a String Confusion Objection Expert Determination; or 
  • Appellate Expert Determination involving the application subject to the Brand String Change Request (p. 131).” 

Additionally, if a “Brand String Change Request meets the criteria in the Brand String Change Request… then the new Brand TLD will be subject to String Evaluation” (p. 132) and for “any new Brand TLDs that successfully pass string evaluation, the application will be subject to an additional 30-day objections, application comments, and Singular/Plural Notifications window” (p. 133).  

Thus, applicants can have some more opportunities to change their applied for strings, but at the cost of extra days in the process as well as managing new sub-processes within the overall application process. 

The next change was to add appeals to the objection processes.  

3. Appeals, Appeals, Appeals 

Dispute Resolution and Formal Objections were a part of the 2012 AGB (See Module 3 starting on p. 3-2); however, no appeals were formally included in the 2012 processes. That said, the 2026 AGB rectifies this by adding appeal processes into all four objection types (String Confusion Objection, Legal Rights Objection, Limited Public Interest Objection, and Community Objection)(see Module 3 starting on p. 80): “The New gTLD Program includes mechanisms that allow for relevant parties to appeal an Objection Panel Determination of an objection (p. 89).” 

As stated in the 2026 AGB: “The party that does not prevail in an objection has a limited opportunity to appeal the decision. The non-prevailing party must notify the Dispute Resolution Service Provider (DRSP) of its intent to appeal within 15 days following the issuance of the objection determination. Subsequently, the non-prevailing party has an additional 15 days from the notice date to file the appeal and pay the required fees (p. 33).” 

One tweak to the prior objection process happened to the “quick look” which originally existed as:  

“Anyone may file a Limited Public Interest Objection. Due to the inclusive standing base, however, objectors are subject to a “quick look” procedure designed to identify and eliminate frivolous and/or abusive objections. An objection found to be manifestly unfounded and/or an abuse of the right to object may be dismissed at any time (p. 3-6).” 

In the 2026 AGB the “quick look” has now been expanded to cover appeals for all objection types:  

“As part of the dispute proceedings, all objections will be reviewed by a panel of expert(s) designated by the applicable Dispute Resolution Service Provider (DRSP) to determine whether the objector has standing to object. This review will occur as part of the Quick Look Review (p. 93).” 

Similarly, the “quick look” has been expanded to be included in the appeals process as well:  “The Quick Look Review is designed to identify and eliminate appeals that are manifestly unfounded and/or an abuse of the right to appeal (p. 111).” 

Again, most would argue that adding appeals to the general processes would be perceived as fair to the broader internet community, though their inclusion adds time and complexity that also needs to be managed.   

Side note: ICANN recently announced that the Dispute Resolution Service Providers (DRSPs) for the Next Round are the International Chamber of Commerce (ICC) for Limited Public Interest and Community objections and the World Intellectual Property Organization (WIPO) for String Confusion and Legal Rights objections.  

A Shock to the System?

4. From TAS to TAMS

In the 2012 AGB, applicants were informed they would need to submit via an ICANN-specific platform: “Applicants may complete the application form and submit supporting documents using ICANN’s TLD Application System (TAS) (p. 1-37).” 

Unfortunately, this resulted in some technical issues which temporarily delayed the application window in 2012: “ICANN took the TLD application system offline in order to protect applicant data… A technical issue in the system allowed a limited number of users to view a limited number of other users’ file names and user names in certain scenarios.”

ICANN ended up resolving the issue, then restarted the application window and closed it successfully. However, this problem did result in a lot of uncertainty and a lack of confidence in ICANN and its systems at the time.  

Hopefully, ICANN learned from its mistakes. In the 2026 AGB, it states that a new platform will be used, this time called TAMS, the TLD Application Management System: “Applications must be submitted electronically through TAMS (p. 26).” 

In the 2012 Round, TAS theoretically completed the following automatically:  

“In the simple case in which an applied-for gTLD string is identical to an existing TLD or reserved name, the online application system will not allow the application to be submitted (p. 2-6).” 

and 

“If an applicant enters a Reserved Name as its applied-for gTLD string, the application system will recognize the Reserved Name and will not allow the application to be submitted (p. 2-10).” 

But the 2026 AGB calls for the TAMS system to do even more work, such as:  

“The applied-for gTLD string must comply with the following requirements: 

  1. The ASCII label must either be an NR-LDH41 or a valid A-label as described in section 2.3 of RFC 589042. 
  2. The NR-LDH label must consist entirely of letters (alphabetic characters a-z) in accordance with section 2.1 of RFC112343. 
  3. IDN gTLD strings must comply with IDNA200844 (RFCs 5890-5893) and all standards-track RFCs that update IDNA2008. 
  4. IDN gTLD strings must comply with the applicable Root Zone Label Generation Rules45 (see Root Zone Label Generation Rules for additional information on RZ-LGRs and processing of applications). 
  5. If a gTLD string is classified as a variant string of either an existing gTLD in the root zone or an applied-for primary gTLD, it must be an allocatable variant string of that primary gTLD (see Internationalized Domain Names). The RZ-LGR is the sole source for calculating the variant strings of the primary gTLD and their disposition values, whether allocatable or blocked. 

The verifications described above are incorporated into and implemented via the [TAMS]. This means that these verifications will occur automatically when the applicant enters the string into its application (p. 53).” 

Additionally,  

“An applied-for IDN that conforms to the mandatory string requirements, including IDNA 2008, as well as the RZ-LGR, can be submitted through [TAMS]. Where the RZ-LGR calculation during the algorithmic check deems an applied-for gTLD as “invalid” or “blocked” (for example, in case the applied-for string is a variant string), such application for a non-conforming string will not be accepted by the application submission system (see DNS Stability Review for a more complete list of checks performed). The applicant may challenge the RZ-LGR calculation by the application submission system (see details in Applicable RZ-LGR and Scripts and Languages Supported) (p. 57).” 

and 

“Pre-Submission String Validations: Validations on the primary and variant strings, including replacement strings, are automatically incorporated into and implemented via TAMS(p.389).” 

Taking all of this into account, ICANN is committing to having the TAMS created in such a way that it can successfully do this additional technical work successfully. For full disclosure, the 2026 AGB does envision the potential for problems with TAMS as it allows for an “evaluation challenge mechanism allows applicants to challenge an evaluation result based on claims of procedural, factual, or system error in the automatic validations run by TAMS that may have led to an incorrect evaluation outcome. While applicants can provide documentary evidence of a perceived factual or procedural error, they are not allowed to submit any new information that would constitute a material change to the original application (p. 40).” 

While one would hope that with 13+ years of technical improvements since the 2012 application round, TAMS will likely be more secure, stable, and functional than TAS was, it is something that bears watching going forward.  

Governments at Work

5. The GAC in the 2026 AGB

The Governmental Advisory Committee (GAC) “constitutes the voice of Governments and Intergovernmental Organizations (IGOs) in ICANN’s multistakeholder structure.” It is an important part of the ICANN Community and, per the 2012 AGB, “ICANN’s Governmental Advisory Committee was formed to consider and provide advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN’s policies and various laws and international agreements or where they may affect public policy issues (p. 3-2).” 

Likewise, the GAC could “issue a GAC Early Warning notice concerning an application. This provides the applicant with an indication that the application is seen as potentially sensitive or problematic by one or more governments. The GAC Early Warning is a notice only. It is not a formal objection, nor does it directly lead to a process that can result in rejection of the application (p. 1-7).” 

Having the GAC take part in the New gTLD Program was important, but in the 2012 round, the activity of providing ‘Advice’ was time-bound as shown in the 2012 AGB:  

“The GAC may provide public policy advice directly to the ICANN Board on any application. The procedure for GAC Advice on New gTLDs described in Module 3 indicates that, to be considered by the Board during the evaluation process, the GAC Advice on New gTLDs must be submitted by the close of the objection filing period. A GAC Early Warning is not a prerequisite to use of the GAC Advice process (p. 1-11).” 

GAC Advice was so significant in that it likely could affect the outcome of a given gTLD application:  

“If the Board receives GAC Advice on New gTLDs stating that it is the consensus of the GAC that a particular application should not proceed, this will create a strong presumption for the ICANN Board that the application should not be approved. If the Board does not act in accordance with this type of advice, it must provide rationale for doing so (p. 1-11).” 

So why does this matter in the 2026 round? The 2026 AGB continues to include the ideas of GAC Early Warnings and GAC Advice (it is now called ‘GAC Consensus Advice’), but the latter is now not tied to any specific time period within the application evaluation process:  

“The GAC can provide advice to the ICANN Board on any application. While the GAC is encouraged to submit advice in the 90 days following String Confirmation Day, allowing the Board to consider it during the evaluation process, the GAC retains the flexibility to submit advice on a particular application or aspect of the New gTLD Program at any time (p. 85).” 

Also, while the ICANN Board still needs to take GAC Consensus Advice seriously, the “strong presumption for the ICANN Board that the application should not be approved” wording has been removed from the 2026 AGB wording, as follows:  

“The Board will consider the GAC Consensus Advice on applications in accordance with the Bylaws. The Board will make a decision on the advice, and based on that the application may or may not be able to proceed (p.85).” 

Please note that strategizing about GAC Consensus Advice is a complex undertaking and is outside of the scope of this piece, but it would be a mistake to not point out that other concepts in the 2026 AGB (which came about as part of the 2012 New gTLD Program but were not fully conceived at the time of the 2012 AGB) are relevant to this ‘advice:’  

“Public Interest Commitments (PICs), specifically the Mandatory PICs and Safeguard PICs, are one important protection built into the New gTLD Program. Those PICs are binding RA commitments in Specification 11, and ICANN enforces compliance with them. Mandatory PICs and Safeguard PICs are uniform across the relevant RAs, and were implemented in response to the Governmental Advisory Committee (GAC) concerns about applications in the 2012 application round. The primary issues addressed include consumer protection, intellectual property rights, and regulated market sectors such as financial, health, and charities. 

In addition to PICs, an applicant will be permitted to propose one or more Registry Voluntary Commitments (RVCs) to provide additional safeguards with regard to the operation of an applied-for gTLD string. An applicant may propose an RVC to address concerns that are not already addressed by Mandatory and/or Safeguard PICs or via other means (pp. 196-197).” 

Based on the 2012 round, most dotBrand applications will steer clear of GAC Early Warnings or GAC Consensus Advice, but in limited circumstances, some could be affected, so it is good to be aware that GAC Consensus Advice exists and could be submitted at any time.  

Summary: What Do The Updates to ICANN’s Draft Applicant Guidebook Mean?  

The 2026 Applicant Guidebook and the new gTLD application process it describes, when compared to the 2012 AGB, are still:  

  • Complex – The Applicant Journey is longer than in 2012; contention set resolution is trimmed down but has new details incorporating string replacement, and appeals have been added to all four of the objection processes.  
  • Reliant on systems – While we shift from TAS to TAMS, the platform that ICANN utilizes in delivering the New gTLD Program: Next Round will need to be secure, stable, and resilient, just like the DNS that ICANN oversees. 
  • Affected by other parts of the ICANN Community – notably the GAC, via the potential submission of GAC Early Warnings and GAC Consensus Advice. 

Any company that is contemplating applying for a dotBrand gTLD in the 2026 application window should consider these points as well as the 2026 AGB as a whole. Working with the experts at Markmonitor can assist you in making sense of it all and can help you put yourself in the best position to have a successful application that results in the delegation of a dotBrand gTLD — one that will meet all of ICANN’s requirements and be an important part of your domain strategy. Reach out today and let’s start on that path together.  

Learn More About dotBrand gTLDs