top of page
  • Writer's pictureJeff Neuman

ICANN New gTLDs Rounds - The Steady State of New gTLD Applications



A. Background


Though not in the ICANN Board Scorecard directly, ICANN Board Members’ Becky Burr and Avri Doria discussed the ICANN Board’s ideas for a “steady state” open window for new gTLD applications after one or two “rounds” as envisaged by the Final Outputs of the Subsequent Procedures Working Group.


The following sets forth some more details about the SubPro Working Group’s extensive consideration of this issue and the rationale for why by unanimous consensus it recommended that there always be rounds.


After a discussion of the history, this paper describes a potential new proposal which mitigates some, but not all of the issues involving first-come, first-served (FCFS) processes.


B. SubPro’s Extensive Discussions regarding Applications being Assessed in Rounds

The SubPro Working Group deliberated for hundreds of hours on whether applications for

new gTLDs should be assessed in Rounds or whether ultimately, they should be assessed purely on a first-come, first served basis. At the end of the day, there was full consensus of the SubPro PDP Working Group that applications must be assessed in rounds and not on a first-come, first served basis.


Prior to its publication of its Initial Report, the Working Group thoroughly considered 6 options on how to assess applications and each of their associated benefits and drawbacks.


The 6 options under consideration were:

  1. Conduct one additional “round” followed by an undefined review period to determine how future applications for new gTLDs should be accepted.

  2. Conduct two or three additional application “rounds” separated by predictable periods for the purpose of major “course corrections,” to determine the permanent process for the acceptance of new gTLDs in the future. For illustration purposes only, this could include commencing an application window in Q1 of Year 1, a second application window in Q1 of Year 2, and a final application window in Q1 of Year 3 followed by a lengthy gap to determine the permanent process moving forward after Year 3.

  3. Conduct all future new gTLD procedures in “rounds” separated by predictable periods for the purpose of course corrections indefinitely. Policy development processes would then be required to make substantial, policy-driven changes to the program and would then only apply to the opening of the application round following the date in which the PDP recommendations were adopted by the ICANN Board.

  4. Conduct one additional “round” followed by the permanent opening up of a first-come, first-served process of new gTLD applications.

  5. Commence two or three additional application “rounds” separated by predictable periods for the purpose of major course corrections, followed shortly thereafter by the permanent opening up of a first-come, first-served process of accepting new gTLD applications

  6. Immediately commence a permanent first-come, first-served process of accepting new gTLD Applications.

Pages 31-35 lay out the pros and cons of each of the models, which are briefly summarized below.


Models 1 and 2: Conduct one additional “round” followed by an undefined review period to determine how future applications for new gTLDs should be accepted. This was viewed as the most conservative approach and is similar to what has happened to date. Although there may be an implied commitment to introduce additional new gTLDs after this next round, as stated by the Intellectual Property Constituency in response to Community Comment 1, it believes that this may “have the potential to create false demand as they can create fear that a future round may not come promptly in the future (such fear is duly based on the actual history of ICANN’s various new gTLD efforts).” [1] In other words, this model did not provide much predictability to potential applicants about when they will be able to apply, creates artificial scarcity and demand, increases time to marks for TLDs. This model was not supported by any members of the PDP Working Group.


Model 2 where two or three additional application “rounds” would be separated by predictable periods for the purpose of major “course corrections,” to determine the permanent process for the acceptance of new gTLDs in the future. Though this model does help with some of the “Cons” of Model 1, at the end of the day it ultimately suffered form the same types of problems.


Model 3: Conduct all future new gTLD procedures in “rounds” separated by predictable periods for the purpose of course corrections indefinitely. Policy development processes would then be required to make substantial, policy-driven changes to the program and would then only apply to the opening of the application round following the date in which the PDP recommendations were adopted by the ICANN Board. The Working group called this model the “steady state of rounds”. In terms of mechanics, it has talked about annual/ biannual windows, or something similar (e.g., three months of application acceptance, remaining nine months devoted to completing evaluation, objections, contention resolution, etc., and then repeating on a regular cycle. These time frames are for illustrative purposes and would be derived from operational realities). This was the model ultimately chosen by the Working Group in its Final Outputs.


On the positive side, this model, (i) provides for a regular, predictable opportunity for applicants to apply for new gTLDs, (ii) provides a regular, predictable opportunity to review applications and provide objections, (iii) potentially puts less strain on ICANN systems compared to a first-come, first-served mode, (iv) through batching, it encourages innovation by leveling the playing field, and (v) relieves pent up demand to some degree by not pressuring applicants to apply in the next round for fear of their not being another round.

On the downside, (i) Applicants will not be able to apply for a new gTLD until the next cycle, (ii) rounds or windows result in contention sets, which require contention resolution - thereby requiring batching processes, community prioritization, potential issues with private resolution, (iii) requires the thorough review of all applications submitted for single string regardless of whether selected, (iv) requires objections and advice to be heard on all applications, whether or not selected, etc. and (vi) could make it tougher to course correct.


Models 4-5: Conduct one additional “round” (or two or three additional rounds followed by the permanent opening up of a FCFS process of new gTLD applications. By conducting an additional “round,” some of the pros are maintained (e.g., conservative approach, allows for course correction, allows for outsiders to the program to have more time to prepare, etc.) but allows the program to set a course and transition to first-come, first-served model discussed in Model 6 below.


Model 6: First Come, First Served from the Beginning. Employing a first-come, first-served model has the following advantages. It: (i) offers the greatest degree of flexibility to first-mover applicants; (ii) is responsive to applicants as their business needs develop and change; (iii) does not create artificial pent-up demand associated with the rounds model, (iv) potentially reduces complex and resource intensive contention resolution processes, (v) may create incentives to develop new creative ideas for applicants that may not be able to win at auction against applicants with more financial means, (vi) eliminates contention sets, (v) eliminates contention set resolution and auctions; and (vi) eliminates the need for applicants to designate themselves as community-based applications.


However, it (i) may advantage ICANN insiders and disadvantage applicants that are less aware of ICANN and the New gTLD Process, (ii) may disadvantage certain applicants that need time to prepare applications, such as community applicants seeking to build community support, (iii) makes it more difficult to monitor applications and raise objections as applications may be submitted at any time, (iv) may cause strain on ICANN systems, (v) may result in hastily prepared applications, (vi) may reduce competition in the marketplace as rounds allow multiple applicants to compete through contention resolution (including community prioritization), (vii) eliminates any incentives to apply for community-based TLDs (because why would one apply as a community with all of the restrictions inherent with that designation if they can just apply for an open string without any of those restrictions), and (ix) incentivizes being the first to apply as opposed to quality.


Comments on all of these options can be found at https://docs.google.com/spreadsheets/d/15zDdzlBwLCz5m2sNXui6N6pporbUq-lDFEwfh4rKi4A/edit#gid=1627799531. The ALAC strongly opposed the use of first come first served models out of the gate, but also emphasized that at the end of the day applications must be batched for an assessment to allow for not only fair competition in string selection, but also to facilitate manageable review procedures by various stakeholders.[2] The Business Constituency also opposed FCFS finding that “rounds are better for underserved countries” to “help businesses and communities plan their involvement and use of the gTLD Program.[3] The NCSG also supported the notion of rounds and believed like the Business Constituency, that those in the Global South and underserved communities would be disadvantaged by a FCFS model. The International Trademark Association (INTA) supported the use of rounds, but advocated for a possible exception for brands to be allowed to apply outside of rounds.[4] No commenter supported immediately going to FCFS and only some members of the Registry Stakeholder Group supported ever using FCFS (with some of the Registries such as the Brand Registry Group and Google stating that it could be used after one or several “rounds”).


At the end of the day. The Working Group chose Model 3. Although the first-come, first-served model had support from a few participants, there was no consensus in the group in support of using a first-come, first-served model. Rather, the group determined that rounds enhance the predictability for applicants (e.g., preparation), the ICANN community and other third-party observers to the program (e.g., public comments, objections).


C. Proposal for Hybrid First-Come, First-Served / Evaluation in Windows in Steady State


Given the pent-up demand of the last decade for new gTLDs and the unanimous recommendations of the community, the very next subsequent application process (and potentially one or two more after that) must be done in the form of a round as described in the SubPro Final Report. To avoid further periods of “pent-up demand”, and in compliance with the Final Report, ICANN must announce specific dates or milestones for the launch of the immediately subsequent application process prior to the start of the next process.

At some point, the organization and community may desire to convert to a more-steady state model that need not be addressed in round. This proposal does not address how to ascertain what precisely would signal the transition to the new steady state, but rather makes a proposal for what the new steady state could look like.


In the proposed model, ICANN would accept applications on a first come, first-served basis, by providing a time stamp for the applications it receives. Although ICANN would post the string that was applied for (to serve as notice to others), none of the details of the application would be disclosed at the time it is received. Rather, ICANN would only post applications 2X per year (once every six months). This would open the public comment period, objection period, GAC Early Warning period, etc. The following could illustrate the model:


  • January 1, 2027: ICANN accepts applications on a FCFS basis. As applications come in, ICANN time stamps the application and does its administrative check to make sure that it is complete. ICANN may start performing evaluations on the applications on a rolling basis if it desires.

  • July 1, 2027: ICANN posts all applications received between January 1st through June 30th. This begins the public comment period for those applications as well as the objection period, GAC Early Warnings, etc. If evaluations have not already been performed, they could be performed now. If the are multiple applications for the same string that are received, only the one with the first time stamp would initially be posted for public comment, objections, etc. If there were multiple applications for a string, and the first application in time fails for any reason, then and only then, would ICANN post the second application for the string (during the next public comment period). During this time period, ICANN would continue to accept new applications (for strings not already applied for).

  • January 1, 2028: ICANN posts all applications received between July 1st through December 31st the prior year. This begins the public comment period for those applications as well as the objection period, GAC Early Warnings, etc.

Benefits: The major benefits of this process are that it eliminates string contention, contention resolution, auctions (both private and ICANN), etc. In addition, it allows entities to apply at the time an idea is conceived as opposed to waiting to submit an application. At the same time, given that all applications are posted only twice per year, it is predictable for applicants as well as for the community looking to file comments, objectors to object, and the GAC to consider Early Warnings and GAC Advice.


Drawbacks: Although this model has some of the benefits of the FCFS model, those benefits are tempered somewhat because even if one could apply for a TLD when an idea is conceived, applications could be delayed up to six months just waiting for it to be posted. That would not be seen as allowing for speedy innovation. Other than mitigating the predictability issues, this model still has all of the issues with Model 6 described in Section B above. Namely, it emphasizes speed to file over quality, disincentivizes community applications or others that take time to garner support, and likely advantages those that are insiders within the ICANN process and those that apply for speculation purposes. Many in the community see these reasons as bigger issues with the FCFS model than the lack of predictability and always having to monitor applications. In addition, it is unclear how Applicant Support would be figured in here. If an applicant would like to have applicant support, how would an applicant come forward to ICANN seeking to apply for a string? Would it have to submit everything all at once, or could it apply for applicant support without disclosing a string. What if another entity applies for a string, while the first applicant was waiting to hear about applicant support?

274 views0 comments

Comments


bottom of page