Note: Jeff Neuman is one of the two Co-Chairs of the New gTLD Subsequent Procedures Working Group within ICANN’s GNSO (“SubPro WG”). However, the opinions expressed herein are my personal opinions and may not necessarily reflect the views of the Working Group, its leadership and/or Members. The Draft Final Report of the Working Group is currently out for public comment at : https://gnso.icann.org/en/drafts/draft-final-report-new-gtld-subsequent-20aug20-en.pdf
In Part 1, I explored the number one complaint about the 2012 process to introduce new gTLDs: namely, that that process was not predictable. Although there was a comprehensive Applicant Guidebook that laid down the rules of the road, there was no predictable process to handle proposed changes to the program when issues arose. This led to substantial delays, ad hoc unilateral changes to the program by ICANN staff/board, forced changes to applicant business models, and an overall loss in trust and confidence in the new gTLD program.
To address this paramount issue, the SubPro WG recommends that a “Predictability Framework” be adopted to address potential changes to the new gTLD program as issues arise. It described the Predictability Framework as:
A framework for analyzing the type/scope/context of an issue and if already known, the proposed or required Program change, to assist in determining the impact of the change and the process/mechanism that should be followed to address the issue. The framework is therefore a tool to help the community understand how an issue should be addressed as opposed to determining what the solution to the issue should be; the framework is not a mechanism to develop policy. (Draft Final Report at p. 16).
To be clear, this new Predictability Framework does not prevent any changes from being introduced into the new gTLD program (even after applications are submitted), but rather just ensures that any such changes follow a predictable process before being made. It also contains significant checks and balances to ensure that those who are most impacted have the ability to weigh in.
In addition, the Framework also delineates the types of changes that can be made to the new gTLD Program by ICANN staff (ICANN Org) unilaterally (eg., changes to ICANN’s internal processes that do not have a material impact on applicants or the community), and the changes that must involve impacted stakeholders and other parts of the ICANN community.
The proposed Predictability Framework also makes it clear that any potential changes to the policies underlying the new gTLD Program must, at a minimum, involve the Generic Names Supporting Organization (GNSO), the “policy-development body…responsible for developing and recommending to the Board substantive policies relating to generic top-level domains…” See ICANN Bylaws Section 11.1.
The SPIRT (Pronounced) “Spirit”
The SubPro WG recommends that a Standing Predictability Implementation Review Team (“SPIRT”)(Pronounced “Spirit”) be created to assist ICANN Org and the Board with: (a) identifying issues that inevitably arise, (b) evaluating those issues, and (c) ensuring that the appropriate body(ies) address those issues. The SPIRT will be overseen by the GNSO Council (the group responsible for managing policy within the GNSO).
The SPIRT is intended to be body empowered to provide input to the GNSO Council, the ICANN Board, ICANN Org, and the ICANN community on issues regarding the new gTLD Program after the approval of the Applicant Guidebook. It will be responsible for reviewing potential issues related to the new gTLD Program, conducting analysis utilizing the framework, and recommending the process/mechanism that should be followed to address the issues (i.e., utilize the Predictability Framework). A detailed description of the Predictability Framework and the SPIRT are contained in the Draft Final Report Annex E at pages 223 – 232.
Although the SPIRT team, like most other ICANN working groups, is intended to be open to all interested parties, the SubPro Working Group recommends that the GNSO Council should make every effort to recruit members who have extensive knowledge and experience with the new gTLD Program and each of its core elements. This does not mean, however, that the group should be limited to existing registries, registrars, and gTLD applicants. Rather, that those who participate in the SPIRT should have a generalized understanding of the issues faced by gTLD applicants, registries and registrars, as well as those faced by other members of the community that participate in the public comment process, dispute resolution processes, and applicant support program (to name a few).
How will this work?
As described in the Draft Final Report, issues forwarded to the SPIRT should be subject to thoughtful analysis and have an impact beyond a single applicant. Therefore, the SubPro WG recommends that issues may only be forwarded to the SPIRT by the ICANN Board, ICANN Org, or the GNSO Council. Members of the SubPro team were concerned that if others would be allowed to refer issues to the SPIRT, that the SPIRT could be susceptible to lobbying and other outside influence. This is not to say that the ICANN Board, ICANN Org and the GNSO Council are not susceptible to such lobbying, but at least there other checks and balances with those groups to mitigate outside influence.
Once the SPIRT receives an issue, it will be responsible for classifying that issue as either operational or policy in nature. If operational, the SPIRT will look at assessing the impact that the change would have on gTLD applicants and/or other community members. If the proposed change(s) could have a significant impact on applicants and/or other community members, the SPIRT team will collaborate with ICANN org to help develop a solution.
On the other hand, if the issue or proposed change (or an element of the change or proposed issues) will likely have a policy implication, then the SPIRT team shall refer that issue or proposed change to the GNSO Council for the Council to handle under its existing operating procedures. This allows the GNSO Council to address that issue or proposed change by initiating a new policy development process, an expedited policy development process, or one of the other mechanisms at its disposal.
All recommendations of the SPIRT shall be provided to the GNSO Council for its review and consideration. If the GNSO Council disagrees with the assessment of the SPIRT, it may either refer the issue back to the SPIRT to continue working on their recommendations, or it may address the issue itself through one of its own processes.
How does the Report Address Past Concerns about the Predictability Framework
The Predictability Framework was initially published for public comment in the Initial Report. At the time, the following concerns were expressed by members of the community:
The SPIRT may develop policy undermine GNSO Council Remit
Under the proposed model, ICANN Org can still make changes on its own if it believes the change is a “minor operational change”? What if it is wrong?
Can a line really be drawn separating policy changes from operational changes?
The SPIRT sounds complicated and may not be worth the extra bureaucracy
I believe that these concerns were valid, but I believe some of the refinements of the model that the SubPro Working Group made, more than address these concerns.
First, we clarified that the SPIRT is not a policy development body. Its role is strictly limited to identifying issues, classifying them and making sure that they are addressed by the appropriate entity in the appropriate manner. If, and only if, an issue is operational in nature, will the SPIRT directly collaborate with ICANN Org on a potential solution. That solution will, like all recommendations by the SPIRT, will be subject to oversight and review by the GNSO Council. If the GNSO Council does not agree with what has been recommended, the GNSO can reject the recommendation and commence its own review of the issue.
Second, although we want to increase predictability, we also need to recognize that in administering the new gTLD program ICANN Org does need flexibility to make necessary operational changes. There is a lot that happens behind the scenes and the community needs to be able to trust ICANN to make changes to improve the efficacy of the process. That said, transparency of those changes and how they are made is of utmost importance. This is why the SubPro Working Group is also recommending that a “Change Log” be published and kept up to date for the community to review. That added transparency will allow the ICANN community to provide input in cases where they believe ICANN may have acted outside of the process. It is yet another check and balance introduced to provide applicants with more predictability.
Third, it is true that drawing a distinction between policy changes and operational changes is difficult at best. One person's policy change can easily be classified as an operational change by others. This is a legitimate point and unfortunately there is no easy answer. However, during the 2012 round, ICANN Org (and the Board) made this distinction on its own, without the assistance of outside experts or stakeholder representatives. Having a group of experts and representatives in the SPIRT will provide ICANN Org (and the Board) with additional input into the complex classification of issues. Is this solution perfect? No. But it is a lot better than what we had in 2012.
Finally, the SPIRT does add extra steps into the new gTLD process for making changes, but it is designed to ensure that all changes to the program have appropriate input from impacted stakeholders. Unlike in 2012, when all decisions were made by the ICANN Board in a vacuum, this new process ensures that experts will be able to weigh in on changes, make ICANN aware of the true impacts on applicants and the community, and put ICANN Org. and the Board in a better position to make informed decisions. By doing so, hopefully, this will bring more predictability to the new gTLD program.
A pdf copy of the above picture can be downloaded below.