icannwiki

Policy Development Process for New gTLD Subsequent Procedures: Difference between revisions

← Older edit
VisualWikitext
Dustin Loup (talk | contribs)
Bureaucrats, Interface administrators, lookupuser, staff, Administrators, translator
11,770 edits
No edit summary
Jessica (talk | contribs)
Bureaucrats, Check users, lookupuser, Administrators, translator
14,952 edits
No edit summary
 
(67 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{ICANN Working Group
{{ICANN Working Group
|Type=GNSO
|Organizer=GNSO
|Status=Active
|Status=Active
|Issue Areas=New gTLDs
|Issue Areas=New gTLDs
|Process=PDP
|Type=PDP
}}In 2012, the [[new Generic Top-Level Domains (TLDs) Program]] opened to applicants interested in being part of the unprecedented increase in the number of new gTLDs. During this round 1930 applications were received and 1227 new gTLDs have been delegated as of the end of September 2017.
|Date Established=January 2016
|Charter=https://community.icann.org/display/NGSPP/2.+WG+Charter
|Workspace=https://community.icann.org/display/NGSPP/New+gTLD+Subsequent+Procedures+PDP+Home
}}


The process leading up to this expansion of the DNS Root Zone was no easy task. It began back in ICANN’s infancy. In 1999, ICANN established Working Group C to examine if new generic top-level domains should be introduced. Prior to this, there were only 7 gTLDs and one special TLD (.arpa), plus a long-list of ccTLDs. After deliberation, the WG concluded that ICANN should add new gTLDs to the root zone, with a preliminary round of 6-10, followed by an evaluation period. The WG’s findings were accepted and ICANN carried out the first round of introducing new gTLDs in 2000, followed by an evaluation period. This was then followed by another round of gTLD expansion in 2003 and 2004, increasing the number of gTLDs to 22.
In 2012, the [[New gTLD Program|new Generic Top-Level Domains (TLDs) Program]] opened to applicants interested in being part of the unprecedented increase in the number of new [[GTLD|gTLDs]]. During this round, 1930 applications were received and 1239 new gTLDs have been delegated as of March 2021.<ref>[https://newgtlds.icann.org/en/program-status/statistics New gTLD Program Statistics], ICANN.org</ref>


In 2005, Following the successful implementation of these two expansion rounds, the GNSO developed an Issues Report to determine whether or not to continue introducing new gTLDs and recommended Policy Development Process (PDP). With community input, including the “GAC Principles Regarding New gTLDs” the GNSO released its Final Report on the Introduction of New Generic Top-Level Domains in 2007 and they were adopted by the ICANN board in 2008. Subsequently, in 2011 the Application Guidebook (AGB) and the new gTLD Program was approved bi the ICANN Board, finally launching in January 2012.
The process leading up to this expansion of the [[Root Zone|DNS Root Zone]] was no easy task. It began back in [[ICANN]]’s infancy. In 1999, ICANN instructed the [[DNSO]] to form a [[Working Group]] (Working Group C) to examine if new generic top-level domains should be introduced. Prior to this, there were only 7 gTLDs and one special TLD ([[.arpa]]), plus a long-list of [[CcTLD|ccTLDs]]. After deliberation, the WG concluded that ICANN should add new gTLDs to the root zone, with a preliminary round of 6-10 new TLDs, followed by an evaluation period.<ref>[http://archive.icann.org/en/dnso/wgc-report-21mar00.htm Report (Part 1) of Working Group C], March 21, 2000 (ICANN.org Archive)</ref>  The WG’s findings were accepted and ICANN carried out the first round of introducing new gTLDs in 2000, followed by an evaluation period. This was then followed by another round of gTLD expansion in 2003 and 2004, increasing the number of gTLDs to 22.<ref name="facts">[https://www.icann.org/en/topics/new-gtlds/factsheet-new-gtld-program-14apr11-en.pdf Fact Sheet - New gTLD Program], April 14, 2011 (PDF)</ref>


In the AGB it stated the intention the introducing new gTLDs on an ongoing basis and that the timing of future application rounds would be based on the “experiences gained and changes required” after the completion of the first round. After the application period closed, the GNSO created a Discussion Group (DG) to evaluate the first round of applications and use experiences to identify potential areas for policy development for subsequent rounds. The DG released its findings in June 2015 and the GNSO Council requested a single Issue Report, which was submitted in December 2015 and led the Council to initiate the New gTLD Subsequent Procedures Policy Development Process (PDP), adopting its charter in January 2016.
In 2005, Following the successful implementation of these two trial expansion rounds, the GNSO developed an Issues Report to determine whether or not to continue introducing new gTLDs and recommended Policy Development Process (PDP). With community input, including the “[[Governmental Advisory Committee|GAC]] Principles Regarding New gTLDs,<ref>[https://gac.icann.org/contentMigrated/gac-principles-regarding-new-gtlds GAC Principles Regarding New gTLDs], March 28, 2007</ref>, the [[Generic Names Supporting Organization|GNSO]] released its Final Report on the Introduction of New Generic Top-Level Domains in 2007.<ref>[https://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm GNSO Final Report], August 8, 2007</ref> The recommendations in the Final Report were adopted by the ICANN board in 2008. After further policy development work, the Applicant Guidebook ([[AGB]])<ref name="agb">[https://newgtlds.icann.org/en/applicants/agb Applicant Guidebook], ICANN.org</ref> and the new gTLD Program<ref>[https://newgtlds.icann.org/en/ New gTLD Program], ICANN.org</ref> were approved by the ICANN Board in 2011.<ref name="facts /> The New gTLD Program launched in January 2012.<ref name="facts" />


== Current Status ==
ICANN stated the intention to introduce new application rounds of gTLDs on an ongoing basis after the first round.<ref name="agb" /> The AGB explains that the timing of future application rounds would be based on the “experience gained and changes required” after the completion of the first round.<ref name="agb" /> After the application period closed, the GNSO created a Discussion Group (DG) to evaluate the first round of applications and use experiences to identify potential areas for policy development for subsequent rounds.<ref>[https://community.icann.org/display/DGNGSR Discussion Group on New gTLD Subsequent Rounds], Archived Wiki, ICANN.org</ref> The DG submitted its Final Issue Report in December 2015<ref>[https://gnso.icann.org/en/issues/new-gtlds/subsequent-procedures-final-issue-04dec15-en.pdf Final Issue Report on New gTLD Subsequent Procedures], December 4, 2015 (PDF)</ref> After review, the GNSO Council initiated the New gTLD Subsequent Procedures Policy Development Process Working Group in January 2016.<ref>[https://community.icann.org/display/NGSPP/New+gTLD+Subsequent+Procedures+PDP+Home New GTLD Subsequent Procedures PDP Workspace]</ref>
The WG for the New gTLD Subsequent Procedures PDP is currently examining what, if any, changes need to be made to policy adopted from the GNSO’s 2007 report. If the WG does not recommend any changes, the current policy would remain in place for future rounds.


There are currently four work tracks underway, examining the following areas:
During [[ICANN 76]], the [[ICANN Board]] adopted 98 recommendations contained in the [[SUBPRO|New gTLD Subsequent Procedures Policy Development Process Final Report]], setting in motion the implementation process for the next round of [[New gTLD Program|new generic top-level domains]].<ref>[https://www.icann.org/en/announcements/details/icann-board-moves-to-begin-preparations-for-the-next-round-of-new-gtlds-16-03-2023-en ICANN Board Moves to Begin Preparations for the next round of nTLDs, ICANN Announcements]</ref>
* WT1 - Overall Process/Support/Outreach
 
{|align=right
  |__TOC__
  |}
==Foundational Documents==
The Working Group's Final Report on New gTLD Subsequent Procedures makes extensive reference to the following documents:<ref name="subpro">[https://gnso.icann.org/sites/default/files/file/field-file-attach/final-report-newgtld-subsequent-procedures-pdp-02feb21-en.pdf Final Report - New gTLD Subsequent Procedures], February 2, 2021 (PDF)</ref>
*[https://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm The GNSO's 2007 Report] on the Introduction of New gTLDs;
*The [https://newgtlds.icann.org/en/reviews/implementation/program-review-29jan16-en.pdf Program Implementation Review Report] (PDF), last revised in January 2016;
*The [https://newgtlds.icann.org/en/applicants/agb Applicant Guidebook];
*ICANN's [https://www.icann.org/resources/pages/governance/bylaws-en Bylaws]; and
*ICANN's [https://www.icann.org/en/registry-agreements Registry Agreement]
 
==Deference to other ACs, SOs, and PDPs==
The scope of the Working Group was substantial and had the potential to cross into territory being separately investigated by other PDP working groups. For example, the SubPro Working Group declined to engage with intellectual property issues, to avoid duplication of effort with the [[PDP Review of All Rights Protection Mechanisms in All gTLDs|Policy Development Process to Review All Rights Protection Mechanisms in All gTLDs]].<ref>[https://community.icann.org/pages/viewpage.action?pageId=60490775 Work Track 2 - Scope], SubPro Workspace</ref> The Working Group also identified possible overlaps in scope with the [[CCWG-IG|Cross Community Working Group on Enhancing ICANN Accountability]] and endeavored to ensure that they were not overstepping their charter in such areas.<ref>[https://community.icann.org/pages/viewpage.action?pageId=60490779 Work Track 3 - Scope], SubPro Workspace</ref> The Working Group also deferred to the decision making of the [[Universal Acceptance Steering Group]] on the topic of [[Internationalized Domain Name|internationalized domain names]].<ref>[https://community.icann.org/pages/viewpage.action?pageId=60490781 Work Track 4 - Scope], SubPro Workspace</ref>
 
== Working Group Tracks and Output ==
The WG for the New gTLD Subsequent Procedures PDP was tasked with determining what, if any, changes to policy were required from those adopted pursuant to the GNSO’s 2007 report and recommendations. The Final Issue report identified a broad range of topics and issues for discussion. Initially, four work tracks (WTs) were established to divide the issues into subject areas. In 2018, a fifth work track was initiated to examine the issue of geographic names at the top level.
 
* WT1 - Overall Process, Support, and Outreach
* WT2 - Legal/Regulatory/Contractual Obligations
* WT2 - Legal/Regulatory/Contractual Obligations
* WT3 - String Contention/Objections and Disputes
* WT3 - String Contention/Objections and Disputes
* WT4 - Internationalized Domain Name/Technical and Operational
* WT4 - Internationalized Domain Names, Technical/Operational Issues
Work Track 5
* WT5 - Geographic Names at the Top Level
 
===WT1: Overall Process, Support & Outreach===
Work Track 1 focused on applicant support, outreach, and process concerns. Key topics included applicant support, clarity of application process, application fees, and equity issues.
 
===WT2: Legal, Regulatory, & Contractual Obligations===
Work Track 2 focused on reserved names, the base [[Registry Agreement|registry agreement]], a refined policy for implementation of registrant safeguards, and conceptualizing how the global public interest might be represented, defended, or addressed in policy-making around new gTLDs.
 
===WT3: String Contention, Objections, & Disputes===
Work Track 3 focused on a review of the processes and engagement with string contention and objections to applications. It also addressed issues related to [[Public Interest Commitment Dispute Resolution Procedure|PICDRP]] and [[Registration Restrictions Dispute Resolution Procedure|RRDRP]], the two established dispute resolution procedures from the New gTLD Program that do not involve intellectual property.
 
===WT4: [[Internationalized Domain Name|Internationalized Domain Names]], Technical & Operational Issues===
Work Track 4 addressed internationalized domain names and engaged in a review of applicant requirements related to technical, financial, and operational concerns.
 
===WT5: Geographic Names at the Top Level===
WT5 utilized a shared leadership model, with co-leaders from ALAC, GAC, ccNSO, and GNSO. The subject of geographic names was a topic of much discussion at [[ICANN 59]], with two cross-community sessions. The Working Group submitted this work track's final report as an annex to their final report, without amendment.<ref name="subpro" /> Although the Work Track examined a variety of issues related to inconsistencies between the AGB and the GNSO's 2007 Report guidance, it was unable to reach consensus on any changes to the policies outlined in the Applicant Guidebook. The Final Report of the Work Track concluded in part:
<blockquote>After extensive discussion, the Work Track was unable to agree to recommendations that depart from the 2012 implementation, which it has considered the baseline throughout deliberations. Therefore, it recommends updating the GNSO policy to be consistent with the 2012 Applicant Guidebook and largely maintaining the Applicant Guidebook provisions for subsequent procedures. This brings GNSO policy in line with implementation, which the Work Track considers a significant achievement given the diversity of perspectives on this issue and the challenges in finding a compromise acceptable to all parties.<ref>For more detail on Work Track 5's process, refer to [https://community.icann.org/display/NGSPP/Work+Track+5%3A+Geographic+Names+at+the+Top-Level Work Track 5] in the PDP workspace</ref></blockquote>
 
==Final Report and Recommendations==
The Working Group's Final Report was submitted to the GNSO Council on January 20, 2021.<ref>[https://myemail.constantcontact.com/Read-the-SubPro-PDP-Newsletter---January-2021-Edition.html?soid=1122025845763&aid=qJxZ65sQtok SubPro Newsletter], January 2021.</ref> The Council approved the Final Report and submitted its "Final Outputs for ICANN Board Consideration" to the ICANN Board on February 2, 2021.<ref name="subpro" />
===Central Recommendations and Themes===
====Predictability Framework and SPIRT====
The report emphasizes the need for consistent, predictable outcomes for application and dispute procedures. The Working Group recommended the adoption of a Predictability Framework (contained in Annex E of the Final Report), as well as the creation of a Standing Predictability Implementation Review Team (SPIRT, pronounced "spirit") to monitor, assess, and propose resolutions to situations that might impact the operation of the New gTLD Program.<ref name="subpro" /> The Predictability Framework identifies a limited number of such situations, including changes in ICANN's operations, changes to policies related to or affecting the New gTLD Program, and new policy proposals that may affect the program. Under the guidance, emergency decisions that may impact the program should be "narrowly tailored to address the emergency situation."<ref name="subpro" /> The Working Group recommended the maintenance of a change log, so that the GNSO and applicants may be kept apprised of changes to the program. In addition, the WG proposed an amendment to the refund procedure so that applicants who are adversely affected by policy changes may withdraw and receive a refund of fees.
In its rationale for these proposals, the WG noted:
<blockquote>Applicants and other parties interested in the New gTLD Program, however, believed that there were a number of changes that were made after the commencement of the 2012 program which hindered the program’s predictability. Therefore, the Working Charter asked the Working Group to consider the question, “How can changes to the program be introduced after launch (e.g., digital archery/prioritization issues, name collision, registry agreement changes, public interest commitments (PICs), etc.) be avoided?” In addition, the ICANN Board commented that “The Board is concerned about unanticipated issues that might arise and what mechanism should be used in such cases.”<br />
The Predictability Framework intends to address the concerns raised in the Charter and by the ICANN Board by creating an efficient, independent mechanism to analyze and manage issues that arise in the New gTLD Program after the Applicant Guidebook is approved which may result in changes to the program and its supporting processes. The recommendations from this Working Group are intended and expected to lessen the likelihood of unaccounted for issues in the future, but this framework is a recognition that despite best efforts, some issues may be missed and circumstances may simply change over time.<ref name="subpro" /></blockquote>
 
====Publicized and Predictable Timeframes for New Rounds====
Many of the recommendations address the substantial length of time between the first application round and the present. The Working Group recommends not waiting for all outstanding applications to resolve before launching a new application round, and provides guidelines for new applications for strings that were involved in a previous round, but not delegated. The report also recommends that any policy alterations for an upcoming round should not be retroactive to prior rounds if the application period for that prior round has passed.<ref name="subpro" />
 
====Registry Service Provider Pre-Evaluation====
Acknowledging that some applicants applied for hundreds of strings, and were obligated to pass separate evaluations for each string, the Working Group recommended an optional pre-evaluation process for Registry Service Providers (RSP). This evaluation would be the same as the evaluation that would normally take place during the application process.<ref name="subpro" />
* RSPs would bear the economic cost of pre-approval - the Implementation Review Team to determine the appropriate fees;
* Applicants for strings could elect to apply using a pre-approved RSP;
* "The only difference between a pre-evaluated RSP and one that is evaluated during the application process is the timing of when the evaluation and testing takes place."<ref name="subpro" />
 
====Minimal Changes to Registry Voluntary Commitments ("Voluntary PICs")====
The enforcement of [[Public Interest Commitments|Registry Voluntary Commitments]] was a subject of much discussion at [[ICANN 70]]. The SubPro Working Group's guidance on the subject largely maintains the status quo regarding the use of RVCs by applicants. The WG did recommend expanding the jurisdiction of the [[PICDRP]] to expressly incorporate Registry Voluntary Commitments. On page 49, in response to the ICANN Board's follow-up query regarding ICANN's Bylaws (which have changed since the 2012 round); the WG provided this explanation:
<blockquote>To the extent that some registries will want to make voluntary commitments in response to public comments, Government Early Warnings, GAC Advice, etc., it is understood by the Working Group that having these commitments reflected in Registry Agreements even if they fall outside of ICANN’s core mission is consistent with the Bylaws where neither ICANN itself nor any third party under ICANN’s control is required to pass judgment on ‘content’. In such cases, it is understood that using an independent third party as an arbiter to determine whether there has been a violation of the commitment would be consistent with ICANN’s mission even if ICANN were ultimately required to rely on that third party decision to enforce a pre-arranged contractual remedy, which could include sanctions and/or termination of the Registry Agreement.<ref name="subpro" /></blockquote>
 
===Failure to Achieve Consensus===
====Closed Generics====
The Working Group was unable to come to an agreement on the handling of closed (aka exclusive) generic TLDs.
 
====Resolution of Contention Sets====
Also notable among the outputs of the final report was a failure to achieve consensus on two issues within Topic 35 - Auctions: Mechanisms of Last Resort / Private Resolution of [[Contention Set]]s. Recommendations 35.2 and 35.4 received "Strong Support but Significant Opposition" designations. As a result, the Council approved the other recommendations but declined to submit the two contested recommendations to the board.
* Recommendation 35.2 would have subjected all private resolutions of contention sets (including private auctions) to the "Contention Resolution Transparency Requirements" contained in Recommendation 35.5. The requirements would obligate all parties of interest participating in a private resolution process to report their interest to ICANN within 72 hours of the resolution of the contention set.
* Recommendation 35.4 would have mandated that ICANN [[Auctions of Last Resort|auctions of last resort]] "must be conducted using the second-price auction method," and proposed additional procedures (including a period of time for competing applicants to resolve the contention set privately) for ICANN auctions.<ref name="subpro" />
 
Those opposed to the adoption of the recommendations in Topic 35 were opposed to the use of private auctions as a mechanism of resolving contention sets. They stated that ICANN should prohibit private auctions and that the protections proposed by the working group under Topic 35 were insufficient to prevent another round of "profiteering" off of failed applications for gTLD strings.<ref>[https://community.icann.org/download/attachments/155191129/AL-ALAC-ST-0121-01-00-EN.pdf ALAC Minority Statement, Final Report of the SUBPRO WG]</ref><ref>[https://community.icann.org/download/attachments/155191129/Minority%20Statement%20on%20Recommendation%2035.pdf Minority Statement of Alan Greenberg et al., Final Report of the SUBPRO WG]</ref>
===Summary Table of Recommendations & Affirmations of Procedures===
{| class="wikitable"
|-
! Topic
! Status Quo
! Recommendation
|-
| 1 - Continuing Subsequent Procedures
| Systematized manner of applying for gTLDs; ongoing, orderly, timely, and predictable administration of application program; primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS
| Affirm and continue principles and purposes of  the program
|-
| 2 - Predictability
| No mechanism to deal with changes in procedures after initiation of the first new gTLD round
| Establish a Predictability Framework as described in Annex E to the Final Report; establish a Standing Predictability Implementation Review Team (SPIRT)
|-
| 3 - Applications Assessed in Rounds
| Applications must initially be assessed in rounds until the scale of demand is clear
| Affirm the commitment to rounds of applications; remove "until the scale of demand is clear;" create clear and transparent criteria for initiation of subsequent rounds
|-
| 4 - Different TLD Types
| Application types were identified based on specific programmatic needs, and corresponding program elements associated with these types were developed to meet the needs established.
| Affirm the separation of applications into types based on either the application type, the string type, or the applicant type; create different application types only when exceptional circumstances merit differentiation
|-
| 5 - Application Submission Limits
| No limits on the number of applications in total and from any particular firm or entity
| Affirm existing implementation
|-
| 6 - Registry Service Provider (RSP) Pre-evaluation
| "[W]here a single RSP provided registry services for multiple TLD applications in the 2012 application round, the RSP was subject to duplicative evaluation and testing (in some cases hundreds of times)."
| Allow for optional pre-evaluation program for Registry Service Providers
|-
| 7 - Metrics and Monitoring
| No structured collection of data
| Implementation team to determine relevant metrics and means of measuring them, in order to evaluate the effectiveness of the New gTLD program in meeting the goals of fostering diversity, encouraging competition, and enhancing the utility of the DNS; consider inputs/collaborate with [[First Competition, Consumer Trust, and Consumer Choice Review|the CCT1]] review team.
|-
| 8 - Conflicts of Interest
| Insufficient provisions in place to effectively guard against conflict of interest among dispute resolution provider panelists, the Independent Objector, and application evaluators
| Develop a transparent process to ensure that program decision makers are free of conflicts of interest
|-
| 9 - Registry Voluntary Commitments/Public Interest Commitments
| Specification 11 PICs were implemented in 2012 during the launch of the application round; the mandatory PICs contained in Specification 11 were not actually codified in policy
| Affirm and continue the mandatory PICs as implemented in 2012; allow exemptions/waivers for certain applicants (e.g. single registrant gTLDs); affirm and continue the NGPC policies for strings applicable to highly sensitive or regulated industries; maintain the policy of allowing applicants to adopt Registry Voluntary Commitments (previously referred to as voluntary PICs)
|-
| 10 - Applicant Freedom of Expression
| 2007 Final Report stated that the string evaluation process "must not infringe the applicant's freedom of expression rights;" but "strings must not infringe the legal rights of others"
| Affirm and continue these principles.
|-
| 11 - Universal Acceptance
| Universal Acceptance Initiative & Steering Group working toward awareness and implementation of standards for universal acceptance
| Affirm and continue to emphasize the importance of UA; provide applicants with information on UA issues and risks for ASCII and IDN strings
|-
| 12 - Applicant Guidebook
| Applicant Guidebook was the bible for applicants and decision-makers
| Affirm and continue the use of the AGB; provide AGB in all six UN languages; publish the final version in English at least 4 months prior to the opening of an application round
|-
| 13 - Communications
| 2007 Final Report emphasized the need for ICANN to frequently communicate with applicants and the community; establish mechanisms through which communications could occur in languages other than English
| Affirm these recommendations; general "do better" recommendations
|-
| 14 - Systems
| Systems for applicant interactions were put in place during the 2012 implementation
| "Recommendations and implementation guidance aimed at improving usability and user experience seek to minimize unnecessary logistical barriers to completing the application process. The Working Group further emphasizes security and stability to ensure that trust with potential applicants is maintained and users have a high-level of confidence that data is being handled safely and appropriately."
|-
| 15 - Application Fees
| One base fee for all applications
| Affirm the single base fee concept; propose a "technical evaluation" fee for applicants that are not using a pre-evaluated RSP; program should assess fees on a cost-recovery basis, and consider refunds or credits if fees are over-collected
|-
| 16 - Applications Submission Period
| 3-month application window
| Recommend an application period of no less than 12 weeks and no more than 15 weeks
|-
| 17 - Applicant Support
| Fee reductions for approved applicants
| Recommend the continuation and expansion of fee reduction offerings; improve outreach, awareness-raising, application evaluation; and program evaluation elements; create a separate Implementation Team for Applicant Support issues and recommendations
|-
| 18 - Terms & Conditions
| 2012 Terms & Conditions
| Revise Section 3 of the 2012 Terms & Conditions to state that the rationale for rejecting an application must stem from a provision of the Applicant Guidebook; reasons that include confidential information from the applicant will not be published (or will be redacted); Include a covenant not to sue (Section 6 of the 2012 T&C) only if the appeals/challenge mechanisms recommended in Topic 32 are implemented; refund application fees in the event of substantial changes to AGB, or determination that an applied-for string creates a risk of name collisions
|-
| 19 - Application Queueing
| Random draw for application processing
| Affirm and continue the use of a "prioritization draw"
|-
| 20 - Application Change Requests
| High-level, criteria-based change request process
| Affirm and maintain a high-level, criteria-based change request process; provide guidance on change requests likely to be approved or denied; identify change requests that would require a re-evaluation of some or all of the aspects of the application; document the types of changes that would require an operational comment period (with examples of such changes); allow changes based on business combinations or joint ventures which resolve string contention sets; allow .brand TLD applications to change the applied-for string to avoid string contention sets (under certain parameters)
|-
| 21 - Reserved Names
| 2007 Final Report & 2012 round implemented various procedures and policies regarding reserved strings
| Affirm and continue a system of reserving words that may not be applied for; Work Track 5 worked on the subject of Geographic Names at the Top Level (Annex J of the Final Report)
|-
| 22 - Registrant Protections
| Technical, operational, and financial continuity protections were established, including [[EBERO]]
| Affirm and maintain protections; provide TLDs that are exempt from the [[Registry Agreement]] Code of Conduct (such as .brand TLDs) with an exemption to the Continued Operations Instrument requirement contained within the registrant protective provisions
|-
| 23 - Closed Generics (aka Exclusive Generics)
| No closed generics were delegated in the 2012 round
| No agreement on the appropriate policy measures for closed gTLDs. "The Working Group believes that if this issue were to be considered in future policy work, it should also involve experts in the areas of competition law, public policy, and economics. In addition, it should be performed by those in the community that are not associated with any past, present, or expectations of future work in connection with new gTLD applications or objections to new gTLD applications. Absent such independence, any future work is unlikely to result in an outcome any different than the one achieved in this Working Group."
|-
| 24 - String Similarity Evaluations
| 2012 AGB: "'similar' means 'strings so similar that they create a probability of user confusion if more than one of the strings is delegated into the root zone.' Established criteria for visual similarity.
| Affirm and continue the baseline standard & visual criteria from 2012; increase clarity on the evaluation of similarity of singular/plural versions of strings, which led to some unpredictability and confusion in 2012; set a deadline for string confusion objections
|-
| 25 - [[IDN|Internationalized Domain Names]]
| Allowed IDN applications and required consistency with root zone label generation rules
| Affirm and continue the processing of IDN applications and the use of RZ-LGR; consider the use of single-character TLDs in cases where the character is an ideogram or ideograph; allow IDN variant TLDs for existing or applied-for strings only if the strings are applied for / operated by the same registry.
|-
| 26 - Security and Stability
| Strings must not cause instability
| Affirm and continue existing principles; shift focus on the rate of change to monthly growth of the root zone (with implementation guidance around acceptable rates of change in a month), rather than delegated strings per year; "Emoji in domain names, at any level, must not be allowed"
|-
| 27 - Applicant Reviews: Technical & Operational, Financial, and Registry Services
| 2007 Policy established technical, capability, criteria for evaluation and assessment
| Affirm and maintain principles from 2007; Evaluation scores on all criteria should be limited to pass/fail (1/0); be as precise as possible to limit clarifying questions; publish all clarifying questions and responses; adjust 2012 evaluation so that applicants are not required to submit their full Security Policy; limit technical & operational evaluation if applicant opts to use a pre-evaluated RSP; simplify financial evaluation to ensure that the applicant can sustain long-term operations without imposing a "one size fits all" set of criteria
|-
| 28 - Role of Application Comment
| 2012 round allowed for a public comment period on each evaluation, and such public comments could affect the scoring of the application
| Affirm and continue the practice of soliciting community comments and the possibility that comments will impact scores; be transparent and consistent in explaining the impact of comment submission, the process of accepting comments, and the opportunities for applicants to respond; ensure that commenters validate an email address before commenting, and make best efforts to verify the commenter's identity; require commenters to reveal affiliations with the applicant; Emphasize ease of use in comment submission and allow attachments to comments; allow comments on confidential portions of the application, or submissions of confidential material, and allow applicants to respond under the same shield of confidentiality
|-
| 29 - Name Collisions
| [[New gTLD Collision Occurrence Management]] framework
| Affirm and continue use of the current collision management framework unless and until the ICANN Board approves a new one; ICANN must have a mechanism in place to evaluate the risk of name collisions prior to the launch of the application period
|-
| 30 - GAC Consensus Advice and GAC Early Warning
| [[ICANN Bylaws]] cover consensus advice; 2012 AGB: “Concurrent with the [public] comment period, ICANN’s Governmental Advisory Committee (GAC) may 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.”
| Consensus advice should be submitted to the Board prior to the finalization of the Applicant Guidebook for a given round; replace the "strong presumption that an application will be rejected" language from the AGB with a description of the voting threshold for the ICANN Board to reject consensus advice; either permit GAC Early Warnings within the application comment period, or specifically define a timeframe in which GAC Early Warnings may be submitted; permit applicants to submit changes to their application in response to consensus advice or early warnings
|-
| 31 - Objections
| 2007 Policy established objection mechanisms, rationales, and criteria for assessment of objections
| "The Working Group affirms the overall approach to the public objection and dispute resolution process described in Section 3.2 of the 2012 Applicant Guidebook, subject to the recommendations below. The Working Group further affirms that parties with standing should continue to be able to file formal objections with designated third-party dispute resolution providers on specific applications based on the following grounds: (i) String Confusion Objection (ii) Existing Legal Rights Objection (iii) Limited Public Interest Objection (iv) Community Objection;" Affirms the role of the Independent Objector, subject to incorporation of conflict of interest protections; transparent and clear process & explainers for objection proceedings; expand "quick look" process to allow dismissal of of "frivolous and/or abusive objections;" allow applicants to amend application or adopt RVCs to address and resolve objections; reduce risk of varying outcomes in string confusion objections (specific guidance provided)
|-
| 32 - Limited Challenge/Appeal Mechanism
| [[ICANN Accountability]] measures, and in particular [[Reconsideration]], were available to applicants
| "The Working Group recommends that ICANN establish a mechanism that allows specific parties to challenge or appeal certain types of actions or inactions that appear to be inconsistent with the Applicant Guidebook;" establish clear procedures and rules for use of the mechanism; apply a "clearly erroneous" standard to all appeals except conflict of interest appeals, which will be reviewed de novo; remedies, process and other suggested rules are detailed in Annex F of the Final Report
|-
| 33 - Dispute Resolution Procedures After Delegation
| [[PICDRP]] and [[RRDRP]]
| Affirm and continue the PICDRP and RRDRP; enhance, clarify, and better define guidance on the scope and uses of those appeal processes; Working Group declined to issue a recommendation on the [[Trademark Post-Delegation Dispute Resolution Procedure]], as that was being reviewed by the [[PDP Review of All Rights Protection Mechanisms in All gTLDs]]
|-
| 34 - Community Applications
| [[Community Priority Evaluation]] process to give priority to applicants who submit a community application
| Affirm and continue the CPE process, with several amendments to the Applicant Guidebook delineating the rules of that process; Selection of CPE provider, and portions of the contract with the CPE provider that describe or provide specifications of the CPE process, should be public and subject to public comment; CPE procedures must be finalized and published prior to the start of the application period; amend AGB to set parameters around independent research by CPE provider: "The Community Priority Evaluation Panel may perform independent research deemed necessary to evaluate the application (the 'Limited Research'), provided, however, that the evaluator shall disclose the results of such Limited Research to the applicant and the applicant shall have an opportunity to respond. The applicant shall be provided 30 days to respond before the evaluation decision is rendered. When conducting any such Limited Research, panelists are cautioned not to assume an advocacy role either for or against the applicant or application."
|-
| 35 - Auctions: Mechanisms of Last Resort / Private Resolution of Contention Sets
| [[Auction of Last Resort]] mechanism
| Affirm and expand the means by which applicants may resolve contention sets, including business combinations or joint ventures, as well as auctions of last resort; applicants must affirmatively attest to a bona fide intention to operate a registry for the applied-for string; utilize the second-price auction method for ICANN auctions, with additional recommendations for rules and procedure; introduce "Contention Resolution Transparency Requirements"
|-
| 36 - Base Registry Agreement
| Single Base [[Registry Agreement]] with Specifications
| Affirm the use of a single base agreement with specifications; Affirm many recommendations and implementation guidelines from the 2007 policy; create a clearer, more transparent, and more predictable way to apply for, negotiate, and obtain exemptions to certain provisions of the base RA based on the unique circumstances of the operation of a particular registry; ICANN must add a covenant that the registry operator will not engage in "fraudulent or deceptive practices"
|-
| 37 - Registrar Non-Discrimination & Registry/Registrar Standardization
| Registries must use ICANN accredited registrars, and may not discriminate between them
| Affirm with modifications permitting a registry to request an exemption, subject to public comment
|-
| 38 - Registrar Support for New gTLDs
| Registrars may choose which gTLDs to carry
| Affirm
|-
| 39 - Registry System Testing
| No current method
| ICANN must develop a set of Registry System tests that demonstrate the technical capabilities of the registry operator; testing must be efficient (i.e. not duplicative of technical evaluation tests), but ICANN should not rely on registry self-certification unless testing would be disruptive of the security of the DNS
|-
| 40 - TLD Rollout
| 2012 [[Applicant Guidebook]] and base [[Registry Agreement]]: successful applicants have nine (9) months following the date of being notified that is successfully completed the evaluation process to enter into a Registry Agreement; and registry operators must complete all testing procedures for delegation of the TLD into the root zone within twelve (12) months of the Effective Date of the Registry Agreement. Extensions of time are permitted.
| Affirm and maintain current policies
|-
| 41 - Contractual Compliance
| [[Registrar Accreditation Agreement]] and [[Registry Agreement]] must contain "a clear compliance and sanctions process"
| Affirm, with the addition of more detailed reporting from [[Contractual Compliance]] regarding the context of the opening and closing of compliance actions (e.g. why an action was closed), and the standards or thresholds that Contractual Compliance utilizes in evaluating and accepting complaints for further action
|}
 
===Public Comment===
The public comment period for the GNSO's report was closed on June 1, 2021. The report received 14 comments during the comment period.<ref>[https://mm.icann.org/pipermail/comments-gnso-gtld-subsequent-procedures-final-outputs-22apr21/ ICANN.org Listserv Archive - Public Comment on SUBPRO Final Outputs], April 29 - June 2, 2021</ref> Several overarching themes were identified in the staff report on the public comment proceeding:
* Many commenters found the final outputs to be a triumph of the [[Multistakeholder Model]], and a large subset of those commenters also encouraged the board to approve the final outputs as-is, out of deference to community consensus and the bottom-up approach of the entire PDP;
* Several comments emphasized the need to quickly implement subsequent procedures (and by extension to launch the second round of new gTLD applications), whether because of public perception of ICANN's capacity to perform its role, or because of perceived pent-up demand for a new application round; and
* Some commenters, while broadly supportive of the recommendations in the report, had reservations about particular topic areas or foresaw other dependencies to be resolved before a new application round could commence.<ref name="finalpc">[https://www.icann.org/en/system/files/files/report-comments-gnso-gtld-subsequent-procedures-final-outputs-15jun21-en.pdf Staff Report on Public Comment Proceeding], June 15, 2021</ref>
 
==Board Actions ==
* The board placed the final report on the agenda for its regular meeting on June 21, 2021.<ref>[https://www.icann.org/resources/board-material/agenda-2021-06-21-en ICANN.org Archive - Board Material: Agenda], June 21, 2021</ref> At [[ICANN 71]], when conversation touched upon SUBPRO, there was a general expectation that the board would launch an [[Operational Design Phase]] regarding the recommendations in the Final Outputs document.<ref>[https://71.schedule.icann.org/meetings/s6yQ7pydosLKtJFDM# ICANN 71 Session - GAC Discussion on Subsequent Rounds of New gTLDs, Future GAC Meetings], June 15, 2021</ref><ref>[https://cdn.filestackcontent.com/content=t:attachment,f:%22I71_RTM-Tue15June2021__GAC%20Disc%20on%20Subsequent%20Rounds%20of%20New%20gTLDs%20(1%20of%202)-en.pdf ICANN 71 Transcript - GAC Discussion of Subsequent Rounds of New gTLDs], June 15, 2021</ref>
* On September 12, 2021, the Board directed the [[ICANN CEO]] to organize the resources required to begin work on the [[ODP]] for SubPro and advise the Board when the work of the ODP begins. The Board requested regular updates on the progress and the delivery of an Operational Design Assessment (ODA) (the output of the ODP), within '''ten months''' of the date of initiation. The Board also authorized Goran Marby up to US$9 million to fund the ODP, and its requisite community engagement, formation and delivery of an ODA to the Board, and any additional work required to support the ICANN Board's consideration of the SubPro final report.<ref>[https://www.icann.org/en/system/files/files/presentation-new-gtld-subsequent-procedures-odp-webinar-28sep21-en.pdf SubPro Webinar, ICANN Sept 2021]</ref>
 
==Operational Design Phase==
On December 12, 2022, [[ICANN Organization]] delivered the Operational Design Assessment (ODA), which is the final product of the Operational Design Phase ([[ODP]]) to the ICANN Board, ending a phase that began on 12 September 2021, when the Board directed the [[ICANN CEO]] to organize the resources required to begin this process.<ref name="odpdash">[https://www.icann.org/subpro-odp ICANN.org - SUBPRO ODP]</ref>
 
===Foundational Documents and Resources===
*[https://www.icann.org/en/system/files/files/draft-new-gtld-subsequent-procedures-odp-scoping-07sep21-en.pdf ODP Scoping Document]
*[https://mm.icann.org/pipermail/subpro-odp/ SUBPRO ODP Listserv]
*[https://www.icann.org/subpro-odp SUBPRO ODP Dashboard]
 
===Project Timeline===
In February, the ODP team published their anticipated timeline for the project:<ref name="odpdash" />
 
<timeline>
# All measures are in pixels
 
ImageSize  = width:1200 height:auto barincrement:25
PlotArea  = left:20 right:20 bottom:20 top:20
AlignBars  = early
 
DateFormat = mm/dd/yyyy
Period    = from:01/01/2022 till:12/31/2022
TimeAxis  = orientation:horizontal
ScaleMajor = unit:year increment:1 start:01/01/2022
ScaleMinor = unit:month increment:1 start:01/01/2022
Colors =
  id:grid value:rgb(0.9,0.9,0.9)
 
BarData=
    Barset:Phases
 
PlotData=
  align:left textcolor:black fontsize:M mark:(line,black) width:15
  barset:Phases color:yellowgreen
      at:01/03/2022 shift:(8,-5) text:"Jan. 3 - ODP Launched"
      at:02/22/2022 shift:(8,-5) text:"Feb. 22 - Begin Drafting ODA"
      at:03/07/2022 shift:(8,-5) text:[https://73.schedule.icann.org/meetings/GzLD4X2x8wqi5B4dp|March 7 - ICANN 73 Presentation on Updated Assumptions]
      at:03/21/2022 shift:(8,-5) text:"March 21 - Team Debrief and Refine Assumptions"
      at:03/28/2022 shift:(8,-5) text:"March 28 - Community Status Update #1"
      at:05/02/2022 shift:(8,-5) text:"May 2 - ODP Project Team Workshop"
      at:05/16/2022 shift:(8,-5) text:"May 16 - Community Status Update #2 (Halfway Point)"
      at:05/23/2022 shift:(8,-5) text:"May 23 - Work Track Project Teams Begin to Finalize Analyses"
      at:06/13/2022 shift:(8,-5) text:[https://74.schedule.icann.org/|June 13-17 - ICANN 74]
      at:06/27/2022 shift:(8,-5) text:"June 27 - Work Track Analysis Wrap-up"
      at:08/15/2022 shift:(8,-5) text:"Aug. 15 - Community Status Update #3"
      at:09/12/2022 shift:(8,-5) text:"Sept. 12 - Final Draft of ODA complete - public comments"
      at:09/19/2022 shift:(8,-5) text:"Sept. 19 - Present ODA at ICANN 75"
      at:10/31/2022 shift:(8,-5) text:"Dec. 12 - Submit ODA to Board"
     
</timeline>
===Process and Developments===
In the wake of [[ICANN 72]], ICANN org responded to questions and comments that arose during the meeting sessions and in the "hallways."<ref name="odpfaqpost">[https://www.icann.org/en/blogs/details/update-answers-to-questions-related-to-icanns-upcoming-subsequent-procedures-odp-1-12-2021-en ICANN.org Blog - Answers to Questions Related to ICANN's Upcoming SUBPRO ODP], December 1, 2021</ref> [[Karen Lentz]] responded to some of the questions and issues raised and addressed the community's interest in the rapid implementation of SubPro and the next new gTLD round. Lentz stated that the ODP would streamline the process and shorten the overall time to launch a new application round. She also noted that the SubPro work was intended to establish a solid, enduring foundation from which multiple application rounds can be launched.<ref name="odpfaqpost" />
 
On December 20, 2021, ICANN announced the launch of the ODP.<ref name="odplaunch">[https://www.icann.org/en/announcements/details/icann-launches-new-gtld-subsequent-procedures-operational-design-phase-20-12-2021-en ICANN.org - ICANN Launches New gTLD Subsequent Procedures Operational Design Phase], December 20, 2021</ref> Under the board's intended schedule, the ODP should be completed in October 2022.
 
On January 18 and February 28, [[Karen Lentz]] posted updates on the ICANN blog regarding the ODP's work tracks.<ref name="worktrackblog">[https://www.icann.org/en/blogs/details/icann-subsequent-procedures-odp-introducing-the-work-tracks-18-1-2022-en ICANN Blog - SUBPRO ODP: Introducing the Work Tracks], January 18, 2022</ref> She reminded the ICANN community that the SubPro ODP will be complicated, as it requires synthesizing more than 300 affirmations, recommendations, and implementation guidance from the SubPro Final Report and the policies, processes, procedures, and lessons learned from the 2012 New gTLD Program.<ref>[https://www.icann.org/en/blogs/details/icann-subpro-odp-update-highlighting-the-project-governance-work-track-28-2-2022-en SubPro Update Feb 28, 2022, ICANN Blogs]</ref> The assessment and design process would be organized across nine tracks:
* Project Governance - coordinating the 60 unique projects within the ICANN org to develop the Operational Design Assessment, providing the required tools, resources, guidance, and consistency in the activities, strategy, status reporting, project assumptions, and overall risk assessment oversight and management of the ODP<ref>[https://www.icann.org/en/blogs/details/icann-subpro-odp-update-highlighting-the-project-governance-work-track-28-2-2022-en SubPro Update Feb 28, 2022, ICANN Blogs]</ref>
* Policy Development and Implementation Materials - org & implementation shepherd work on policies, redrafting the Applicant Guidebook per approved recommendations, and other implementation work
* Operational Readiness - getting the org ready for the influx of applicants, processing, and increase in contracted parties
* Systems and Tools - methods and practices for subsequent rounds, including maintenance and continuous improvement
* Vendors - identifying needs and procuring outside expertise
* Communications and Outreach - keeping the community and others updated
* Resources, Staffing, and Logistics - planning staffing and resource requirements
* Finance - planning, budgeting, and disbursement
* Overarching - monitoring dependencies and overlap with other community and org work<ref name="worktrackblog" />
 
===Community Status Update #1===
ICANN org released its first community update in March 2022, describing its work to date and discussing the future direction of the ODP.<ref name="csu1">[https://www.icann.org/en/system/files/files/community-status-updates-28mar22-en.pdf SUBPRO ODP - Community Status Update], March 28, 2022</ref> ICANN org reported that it was working toward the finalization of the Operational Design Assessment by October 2022. The update also provided figures on hours and resources devoted to the project. A total of 7 full time equivalent (FTE) staff hours had been devoted to the ODP since its initiation in January. The org noted that it intended to allocate and/or hire a total of 22-24 FTE in order to complete the work of the ODP.<ref name="csu1" /> This level of activity would be in line with the budget allocation approved by the board for the project.<ref name="csu1" />
 
===Community Status Update #2===
ICANN or released its second community update in May 2022.<ref name="csu2">[https://www.icann.org/en/system/files/files/community-status-update-new-gtld-subpro-odp-16may22-en.pdf SUBPRO ODP - Community Status Update], May 16, 2022</ref> The update included a compilation of all policy question sets submitted to the GNSO Council to help clarify issue areas. In addition, the update compiled all of the published assumptions from the ODP team regarding strategic needs and processes.<ref name="csu2" /> Shortly thereafter, the ODP team released another iteration of the team's assumptions document.<ref>[https://www.icann.org/en/system/files/files/assumptions-subsequent-procedures-odp-25may22-en.pdf ICANN.org Archive - Assumptions re: Subsequent Procedures ODP], May 25, 2022 (PDF)</ref>
 
Following the release of the status update, [[Karen Lentz]] posted a blog regarding operational readiness for the next round of applications.<ref name="522blog">[https://www.icann.org/en/blogs/details/icann-subpro-odp-update-focusing-on-the-operational-readiness-work-track-26-05-2022-en ICANN.org Blog - SUBPRO Update - Focusing on the Operational Readiness Work Track], May 26, 2022</ref> The post described the creation of a roadmap based on applicant experience and interactions:
<blockquote>The Operational Readiness work track includes development of a high-level design of the operational aspects of the next round. This operational blueprint will include a description of the applicant's experience, from prior to the opening of the application window through contracting and delegation (entering the string into the root zone and making it visible on the Internet).<ref name="522blog" /></blockquote>
 
===ICANN 74===
During Prep Week of ICANN 74, ICANN org presented an update to the community on the progress of the ODP.<ref name="74prep">[https://74.schedule.icann.org/meetings/ZwGFKyDZpR69khesm ICANN 74 Archive - New gTLD Subsequent Procedures ODP Update], May 31, 2022</ref> The presentation included an overview of the process for the ODP and the current state of the project.<ref>[https://cdn.filestackcontent.com/content=t:attachment,f:%22SubProODP_ICANN74_PrepWeek.pdf%22/1LiJb1oAQCOODHkzcfDY ICANN 74 Archive - SUBPRO ODP Slides (PDF)]</ref> The presentation included a walk-through of the analysis applied to each of the recommendations of the Final Report.<ref name="74prep" />
 
During the meeting, the ODP team hosted a session to engage stakeholders and receive feedback on specific work areas in progress.<ref name="74odp">[https://74.schedule.icann.org/meetings/Q5k7NyhhFhLwmbkgY ICANN 74 Archive - Plenary Session: New gTLD Subsequent Procedures - Working Together], May 13, 2022</ref>
 
==ODA==
ICANN spent $6.8 million on the ODP to generate and deliver the Operational Design Assessment in mid-December 2022. This amount fell under the low-end of the $7 million to $9 million the ICANN board approved for its budget. Fifteen full-time equivalents, mostly [[:Category:ICANN staff|ICANN Staff]], spent over 27,000 hours in making the ODA report.<ref>[https://domainincite.com/28594-new-gtlds-report-came-in-under-budget nTLD ODA Report Under Budget, Domain Incite]</ref>
===Key Take-Aways from the ODA ===
ICANN Org
 
*determined that most of the SubPro Final Report outputs<ref>[https://www.icann.org/en/system/files/files/subpro-oda-12dec22-en.pdf SubPro ODA, Executive Summary]</ref>
#  are implementable in the New gTLD Program
# have mechanisms to support diversity, predictability, and innovation and
# refer to Global Public Interest (GPI) pilot framework terms
 
*analyzed the potential timeline, costs, resource requirements, systems needs, and risks of implementing all 300+ SubPro Final Report outputs.<ref>[https://www.icann.org/en/system/files/files/subpro-oda-12dec22-en.pdf SubPro ODA, Executive Summary] </ref>
 
*proposed a Business Process Design (Appendix 6) outlining the key components of how the next round could be implemented, from foundational concepts to post-contracting, with the aim of supporting the Implementation Review Team (IRT) and found that the overall implementation cost for the next round of the New TLD Program would be significantly higher than the 2012 round.<ref>[https://www.icann.org/en/system/files/files/subpro-oda-12dec22-en.pdf SubPro ODA, Executive Summary] </ref>
====Application Period Options====
*presented two options for the application process: a single application submission period per round (the assumed route) or cyclical application submission periods (the alternative; Appendix 19).
::'''Option 1''' may take at least five years from the Board directing ICANN org to begin implementation to the opening of the application submission window, cost approximately USD $457 million, involve 18 system services and 125 full-time equivalents, and incur the risk of material financial losses if demand is low.<ref>[https://www.icann.org/en/system/files/files/subpro-oda-12dec22-en.pdf SubPro ODA, Executive Summary], Pgs 12-14</ref>
::'''Option 2''' would take 18 months to begin implementing, split the immediate next round into four annual application submission periods, create predictability for the New TLD Program,  moderate the influx of applications in the first cycle, rely on a processing capacity limit of 450 applications per cycle, offer flexibility to potential applicants, and may be beneficial to new entrants who may need to invest more time and resources. However, this option contains the risks of
::#limited space leading to competition,
::#giving an advantage to applicants already engaged in the current DNS ecosystem, and
::#being less efficient than the processing of portfolio applications available with option 1.<ref>[https://www.icann.org/en/system/files/files/subpro-oda-12dec22-en.pdf SubPro ODA, Executive Summary], Pg 17</ref>
===Reactions to the ODA===
On January 20, 2023, the GNSO Council provided feedback to the ICANN Board about the SubPro ODA. The Council encouraged the ICANN Board to adopt the New gTLD Subsequent Procedures Final Report ASAP. In particular, the Small Team:
*explained that it couldn’t differentiate Options 1 and 2 and their impacts on the overall new gTLD program;
*believed that the bulk of the applications would come in the first cycle, regardless of what ICANN org internally designs;
*suggested that the next round should not be more complex or time and resource intensive than is necessary;
*requested that the org use existing know-how and lessons learned (and the general approach of outsourcing or buying in and adapting systems);
*distinguished between what is necessary to support the program and what is a wish list; and
*felt that the design could be simplified to minimize the risks identified by using customizable existing software and platforms instead of building in-house and from scratch.<ref>[https://www.icann.org/en/system/files/correspondence/ducos-to-sinha-20jan23-en.pdf Ducos to Sinha Jan 20, 2023, Correspondence, ICANN Files]</ref>
==Implementation Planning Phase==
At [[ICANN 76]], the [[GNSO Council]] agreed to form a small team of councilors to review the pending recommendations and suggest how to address the underlying concerns. The Council SubPro Small Team completed an initial run-through of the issues chart and proposed paths forward for each pending recommendation to be presented in the Council's dialogue with the ICANN Board on May 22, 2023.<ref>[https://community.icann.org/display/gnsocouncilmeetings/Final+Proposed+Agenda+2023-05-25 Final Proposed Agenda for 05/25/2023, GNSO Council Meetings]</ref>


The Co-chair’s are currently developing a fifth working track that will focus on geographic names at the top level. Work Track 5 will have a shared leadership model, with co-leaders from ALAC, GAC, ccNSO and GNSO. Currently, the ALAC, ccNSO, and GNSO have made their nominations, with the GAC yet to release their appointee. After the co-leadership team is finalized, they will issue a formal call for volunteers.
==References==
{{reflist}}


The subject of geographic names was a topic of mu ch discussion at ICANN59, with two cross-community sessions.
[[Category:PDPs]]
Retrieved from "https://icannwiki.org/Policy_Development_Process_for_New_gTLD_Subsequent_Procedures"