Policy Development Process for New gTLD Subsequent Procedures

Policy Development Process for New gTLD Subsequent Procedures
Status:	Active
Issue Areas:	New gTLDs
Date Established:	January 2016
Charter:	WG Charter
Workspace:	Community Wiki

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 1239 new gTLDs have been delegated as of March 2021.

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 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 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. 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 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 “GAC Principles Regarding New gTLDs,, the GNSO released its Final Report on the Introduction of New Generic Top-Level Domains in 2007. The recommendations in the Final Report were adopted by the ICANN board in 2008. After further policy development work, the Applicant Guidebook (AGB) and the new gTLD Program were approved by the ICANN Board in 2011. The New gTLD Program launched in January 2012.

ICANN stated the intention to introduce new application rounds of gTLDs on an ongoing basis after the first round. 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. 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 submitted its Final Issue Report in December 2015 After review, the GNSO Council initiated the New gTLD Subsequent Procedures Policy Development Process Working Group in January 2016.

Foundational Documents

The Working Group's Final Report on New gTLD Subsequent Procedures makes extensive reference to the following documents:

• The GNSO's 2007 Report on the Introduction of New gTLDs;
• The Program Implementation Review Report (PDF), last revised in January 2016;
• The Applicant Guidebook;
• ICANN's Bylaws; and
• ICANN's 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 Policy Development Process to Review All Rights Protection Mechanisms in All gTLDs. The Working Group also identified possible overlaps in scope with the Cross Community Working Group on Enhancing ICANN Accountability and endeavored to ensure that they were not overstepping their charter in such areas. The Working Group also deferred to the decision making of the Universal Acceptance Steering Group on the topic of internationalized domain names.

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
• WT3 - String Contention/Objections and Disputes
• WT4 - Internationalized Domain Names, Technical/Operational Issues
• 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, 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 PICDRP and RRDRP, the two established dispute resolution procedures from the New gTLD Program that do not involve intellectual property.

WT4: 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. 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:

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.

Final Report and Recommendations

The Working Group's Final Report was submitted to the GNSO Council on January 20, 2021. The Council approved the Final Report and submitted its "Final Outputs for ICANN Board Consideration" to the ICANN Board on Febrary 2, 2021.

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. 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." 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:

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 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.”
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.

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.

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.

• 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."

Minimal Changes to Registry Voluntary Commitments ("Voluntary PICs")

The enforcement of 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:

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.

Failure to Achieve Consensus - Resolution of Contention Sets

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 Sets. 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 "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.

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.

Summary Table of Recommendations & Affirmations of Procedures

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 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 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 final version in English at least 4 months prior to 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 & Conditons	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 ifmore 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 - 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.

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. 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.

Board Actions

• The board placed the final report on the agenda for its regular meeting on June 21, 2021. 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.
• 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.

Operational Design Phase

ICANN Org's work on the SUBPRO ODP is ongoing. ICANN has established a dashboard for announcements, documents, and events related to the ODP.

Foundational Documents and Resources

• ODP Scoping Document
• SUBPRO ODP Listserv

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." Karen Lentz responded to some of the questions and issues raised, and particularly addressed the community's interest in 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 of 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.

On December 20, 2021, ICANN announced the launch of the ODP. Under the board's intended schedule, the ODP should be completed in October 2022.

On January 18, Karen Lentz posted an update on the ICANN blog regarding the ODP's work tracks. The assessment and design process would be organized across nine tracks:

• Project Governance - oversight and management of the ODP, work tracks, and other administrative tasks
• 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 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 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

Top-Level Domain

Generic Names Supporting Organization. Develops and recommends to the Board substantive policies relating to generic top-level domains and other responsibilities set forth in the Bylaws (ICANN Bylaws).

Policy Development Process

At-Large Advisory Committee. Considers and provides advice on the activities of ICANN related to the interests of individual Internet users (ICANN Bylaws). Not to be confused with the Non-Commercial Stakeholder Group.

Governmental Advisory Committee. Considers and provides 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 (ICANN Bylaws).

Country Code Names Supporting Organization. Develops and recommends to the Board global policies relating to country-code top-level domains (ICANN Bylaws).

Internationalized Domain Name