Changes

==Final Report and Recommendations==

==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 Febrary 2, 2021.<ref name="subpro" />  

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

===Central Recommendations and Themes===

====Predictability Framework and SPIRT====

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

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:  

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

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

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>

===Failure to Achieve Consensus===

===Failure to Achieve Consensus===

====Closed Generics====

====Closed Generics====

The Working Group was unable to come to agreement on the handling of closed (aka exclusive) generic TLDs. No such TLDs were delegated in the 2012 round, as the Working Group noted:

The Working Group was unable to come to an agreement on the handling of closed (aka exclusive) generic TLDs.

====Resolution of Contention Sets====

====Resolution of Contention Sets====

| 9 - Registry Voluntary Commitments/Public Interest Commitments

| 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

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

| 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

| 10 - Applicant Freedom of Expression

|-

|-

| 12 - Applicant Guidebook

| 12 - Applicant Guidebook

| Applicant Guidebook was the bible for applicants and decision makers

| 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

| 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

| 13 - Communications

|-

|-

| 16 - Applications Submission Period

| 16 - Applications Submission Period

| 3 month application window

| 3-month application window

| Recommend an application period of no less than 12 weeks and no more than 15 weeks

| Recommend an application period of no less than 12 weeks and no more than 15 weeks

|-

|-

| 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

| 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

| 18 - Terms & Conditions

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

| 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

|-

|-

| 24 - String Similarity Evaluations

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

| 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

| 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

|-

|-

| 26 - Security and Stability

| 26 - Security and Stability

| Strings must not cause instability

| Strings must not cause instability

| Affirm and continue existing principles; shift focus on 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"

| 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

| 27 - Applicant Reviews: Technical & Operational, Financial, and Registry Services

| 28 - Role of Application Comment

| 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

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

| 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

| 29 - Name Collisions

| 33 - Dispute Resolution Procedures After Delegation

| 33 - Dispute Resolution Procedures After Delegation

| [[PICDRP]] and [[RRDRP]]

| [[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 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]]

| 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

| 34 - Community Applications

|-

|-

| 37 - Registrar Non-Discrimination & Registry/Registrar Standardization

| 37 - Registrar Non-Discrimination & Registry/Registrar Standardization

| Registries must use ICANN accredited registrars, and may not discriminte between them

| 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

| Affirm with modifications permitting a registry to request an exemption, subject to public comment

|-

|-

*[https://www.icann.org/subpro-odp SUBPRO ODP Dashboard]

*[https://www.icann.org/subpro-odp SUBPRO ODP Dashboard]

===Process and Developments===

===Project Timeline===

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" />

In February, the ODP team published their anticipated timeline for the project:<ref name="odpdash" />

 

 

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:

 

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" />

 

The update also provided a timeline that was first published in February, establishing some milestones and significant moments in the ODP process:<ref name="csu1" />

<timeline>

<timeline>

DateFormat = mm/dd/yyyy

DateFormat = mm/dd/yyyy

Period    = from:01/01/2022 till:12/31/2022

Period    = from:01/01/2022 till:12/31/2022

TimeAxis  = orientation:horizontal  

TimeAxis  = orientation:horizontal

ScaleMajor = unit:month increment:1 start:01/01/2022

ScaleMajor = unit:year increment:1 start:01/01/2022

ScaleMinor = unit:month increment:1 start:01/01/2022

ScaleMinor = unit:month increment:1 start:01/01/2022

Colors =

Colors =

       at:09/12/2022 shift:(8,-5) text:"Sept. 12 - Final Draft of ODA complete - public comments"

       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:09/19/2022 shift:(8,-5) text:"Sept. 19 - Present ODA at ICANN 75"

       at:10/31/2022 shift:(8,-5) text:"Oct. 31 - Submit ODA to ICANN Board"

       at:10/31/2022 shift:(8,-5) text:"Oct. 31 - Submit ODA to Board"

        

        

</timeline>

</timeline>

==References==

==References==