Summary

  • GNSO Operating Procedures v3.8, dated 1 September 2026, incorporates a Board-reversal process that the Council approved on 21 May. It applies only in limited, extraordinary circumstances before implementation has concluded, and it does not establish that any reversal is now under way.
  • The Board should give the GNSO Council enough time for dialogue—about 60 days is offered as an example—but the first mandatory public Board Statement comes after the Board acts. The adopted text requires neither a pre-action public evidence docket nor consultation with the Implementation Review Team.

Picture a policy recommendation halfway between adoption and operation. Contracts have been analysed, systems designed, implementation questions logged and businesses have begun to make plans. Then a new fact appears. The ICANN Board concludes that the recommendation is no longer in the interests of ICANN or its community and considers reversing its earlier adoption.

The difficult question is not whether an institution should ever change its mind. It is when outsiders can inspect the evidence that moves the institution from concern to action. Under the new GNSO rule, the Board should first speak with the GNSO Council. A public explanation is mandatory when the Board carries out the reversal. Between those points sits the first decision, and the procedure does not require a public case file before it is taken.

That is the control boundary exposed by GNSO Operating Procedures v3.8. The process is a real improvement on an unwritten gap. But explanation after action is not the same governance instrument as evidence before action.

Three dates, one operative text

The publication history matters because it prevents a tidy document date from becoming a false policy date. The GNSO procedures page was updated on 2 September and lists v3.8 as dated 1 September. The version-control entry says the consolidated document incorporates updated Annex 2, the Policy Development Process Manual, and Annex 5, the Guidance Process Manual, both approved on 21 May 2026. The standalone manuals themselves are dated 11 May. The rest of the v3.8 changes are described as administrative and editorial, apart from the updated annexes.

The Council resolution of 21 May is therefore the approval event. September is the consolidation and publication event. Neither date is an invocation. No checked source identifies a recommendation currently being reversed under the new procedure.

The distinction also keeps an older example in its proper place. The 2025 Strategic Planning Session report described the procedural gap after the Board encountered concerns about adopted recommendations, including New gTLD Subsequent Procedures Recommendation 20.6. That history motivated the rule. It does not make Recommendation 20.6 a live test case for v3.8, and this article does not revisit its merits.

What the reversal sequence now requires

Section 16 of the updated PDP Manual and Section 10 of the updated GGP Manual use almost the same sequence. Reversal is reserved for limited and extraordinary circumstances. It can be considered when the Board has adopted a recommendation and implementation has not yet concluded. It is unavailable where the recommendation has already been implemented and is in force.

Before acting, the Board should engage the GNSO Council. At minimum, it should communicate its intention, identify the issues, explain the rationale and impact, and say why reversal is the only or best option. The Council must have sufficient time to consider the issue and ask for clarification. The manuals offer “e.g., 60 days”. That is useful guidance, not a fixed statutory clock.

The substantive test combines two elements. The trigger must be new information or changed circumstances. The Board must also find that the recommendation is no longer in the best interest of ICANN or the ICANN community. A change alone is not enough, and a broad assertion of institutional interest without a changed evidentiary basis would not follow the written test.

The voting threshold mirrors the treatment of the original recommendation. If it was adopted following a GNSO Supermajority, reversal requires two-thirds of the Board. If it had less than a GNSO Supermajority, a Board majority is sufficient.

When the Board carries out the action, it must explain its determination in a Board Statement sent to the Council. That statement and any accompanying documentation must be posted publicly. The Council then reviews the statement, discusses it with the Board and meets to affirm or modify its recommendation. Its resulting Supplemental Recommendation goes back to the Board, where the familiar supermajority-sensitive thresholds apply.

This is not unilateral finality disguised as consultation. The Council retains a formal response, and the Board must confront that response. The narrower problem is evidence timing: the first mandatory public artifact follows the first Board action.

The consultation asked for more than the final rule guarantees

The procedure did not arrive without public input. The Public Comment proceeding ran from 20 November 2025 to 22 January 2026 and received ten submissions. Its Summary Report records broad support for a rare procedure with safeguards.

The consultation changed important words. Commenters urged replacing “may adhere” with “should adhere”, and the final manuals use “should”. They also asked that changed circumstances be added to new information as a possible basis; the final rule includes both.

Other requests stopped short of becoming compulsory steps. Several commenters suggested a limited Public Comment or community consultation period before the reversal process concluded. The Registrar and Registry Stakeholder Groups and Tucows supported required consultation with the relevant Implementation Review Team; the Registry group also proposed, where possible, consultation with the original working group. The final manuals do not require those steps.

That omission must not be exaggerated. Councilors can consult their constituencies. The Board and Council can choose an open session, publish material early or seek IRT advice. Nothing in the text requires secrecy or forbids participation. The accurate finding is only that those choices are discretionary rather than conditions of the first action.

The gate depends on an undefined implementation state

The eligibility line looks clear until a real programme approaches it. A recommendation whose implementation “has not yet concluded” may enter the reversal process. A recommendation “implemented and in force” may not. The manuals do not assign a named officer, a certification document or a common evidence test for crossing that line.

Implementation rarely moves as one block. One recommendation can belong to a package. Contract language may be finished while tooling is not. A policy may have an effective date but incomplete migration, open IRT questions or deferred enforcement. One output may depend on another that the Board is not proposing to reverse. A binary label can therefore hide several operational states.

The public-comments record noticed the timing problem from another direction. The At-Large Advisory Committee warned against unwarranted implementation delay, while the Intellectual Property Constituency argued that the proposal did not solve the broader problem of slow implementation. Those positions do not decide the eligibility test. They show why the test needs evidence rather than a label.

If the implementation boundary is classified incorrectly, the mistake affects jurisdiction over the remedy. Too early a declaration of “in force” could close the exceptional route even where new evidence is compelling. Too late a declaration could keep reversal available after registrars, registries, applicants or users have reasonably relied on the adopted rule. Publishing the Board Statement later documents the chosen classification; it does not allow affected actors to correct it before the first vote.

Open a reversal docket before the first vote

The missing instrument is a bounded public reversal docket. It need not be an endless consultation, and it need not expose privileged advice. It should exist before the first Board action and remain tied to the exact recommendation version under review.

At minimum, the docket should identify the triggering notice and date; every recommendation in scope; dependencies on recommendations outside scope; the original adoption record and threshold; the implementation phase; and the named custodian responsible for certifying that phase. The certification should cite a dated evidence snapshot rather than a status word.

It should then record the new information or changed circumstance, its provenance, the expected impact, and the alternatives considered. The Board’s questions and the Council’s answers should have stable versions. A bounded channel should accept relevant IRT, working-group and community evidence, with a visible closing time and a reason when material is protected or excluded.

After action, the same docket can hold the vote, Board Statement, Council discussion, Supplemental Recommendation and final Board disposition. Corrections should append rather than silently replace earlier evidence. A public summary can protect legal or security-sensitive detail while still identifying the claim, custodian, reason for withholding and decision effect.

This proposal is not in v3.8. It is my editorial recommendation. It follows the authority test in Heng Lu’s Policy Mirror, the demand for observable execution in Running-Code Primacy and the separation of fact from institutional self-description in Reality, Not Advocacy.

The new rule correctly accepts that adoption cannot make later information disappear. Its next discipline should be equally simple: do not let post-action transparency impersonate pre-action contestability. Open the evidence window while the first decision can still be changed.

Sources