Summary

  • The ICANN Board's 21 August reply to six GNSO groups says it should not adopt a fixed outer deadline that might interfere with the Bylaws review of recommendations that differ in complexity. Instead, it promises expected timing, a status update before every ICANN Public Meeting and a standing workshop review.
  • Those commitments can reveal the current state, but not the history behind it. A recommendation-to-decision clock should retain receipt, required inputs, questions, owners, revised expectations and the final per-recommendation disposition without turning dialogue, a liaison or a dashboard into Board authority.

ICANN has answered a request for a policy-review deadline with a reporting cadence.

On 25 May, leaders from six groups across the Generic Names Supporting Organization wrote to Board Chair Tripti Sinha. Their problem was not that the Bylaws contain no timing language. Annex A says the Board should meet to discuss a GNSO Council recommendation as soon as feasible, preferably no later than the second meeting after receiving the Recommendations Report. Their problem was what that sentence does not say: when review must finish.

The signatories proposed a standard timeframe, perhaps combining a target number of Board meetings with a maximum number of months. Six months was an example, not an existing rule. They also asked for consistent status updates, a permanent home for the Consolidated Policy Scorecard and a way for the Board to ask the GNSO Council and relevant Working Group leaders questions while recommendations were under consideration.

The Board's 21 August reply accepted the concern about predictability and declined the proposed control. Recommendations vary, it said, and a fixed outer deadline could interfere with the review required under the Bylaws. The Board instead committed to expected timing and status reporting. It intends to issue an update before each ICANN Public Meeting, place policy status on the agenda of the workshop held ahead of each meeting, and continue dialogue with the Council and stakeholder groups.

That is a genuine governance choice. A deadline controls elapsed time. A reporting cadence controls when the institution must describe its state. The second can discipline the first, but only if the description preserves enough evidence to be tested.

The two examples changed state before the reply

The May letter named two recommendations packages that were then awaiting completion of Board review. The IDN EPDP Phase 2 package had been transmitted in December 2024. The Transfer Policy Review package had been transmitted in April 2025. By 7 June 2026, both had moved.

At its 7 June meeting, the Board adopted all 47 Transfer Policy Review recommendations and all 14 policy recommendations from IDN EPDP Phase 2. For both, it directed the President and CEO, or designees, to proceed with implementation subject to prioritization and to operational, technical, legal, security or resource considerations that might emerge.

The Board rationales acknowledged the community's concern about the timing and process of review. They also showed the material considered: Final Reports, Public Comment records, feasibility work, GAC notice and topic-specific evidence. Those decisions did not make the timing dispute disappear. They converted the two examples into completed case studies.

The current policy implementation page now places both projects in the implementation queue. That is a later institutional state than “pending Board action.” It is not the same as implementation having started. A queue entry says where work waits; it does not identify assigned capacity, a first work date, a draft policy, an Implementation Review Team or an effective rule.

That distinction is exactly why a snapshot needs history. A reader who saw only the May letter might think the two packages remain before the Board. A reader who saw only the current queue might think the timing issue concerned implementation rather than Board review. A connected record would show both states and the event that changed one into the other.

“Discuss” is not “dispose”

The timing language in Annex A is carefully limited. It asks the Board to meet to discuss the recommendation as soon as feasible, preferably by the second meeting after receipt. It does not say that the Board must approve or reject the package at that meeting. Nor does the public record reviewed for this article establish when every relevant discussion occurred or how the institution counted a meeting for this purpose.

It would therefore be careless to turn the elapsed calendar into a finding that ICANN violated its Bylaws. The better reading is narrower: the current rule places an expectation near the beginning of Board consideration but no fixed endpoint at the end.

That flexibility protects a real responsibility. A GNSO supermajority recommendation carries substantial institutional weight. Under the Bylaws, the Board generally must adopt it unless more than two-thirds of directors determine that adoption is not in the best interests of the ICANN community or ICANN. The threshold is designed to respect bottom-up policy work without eliminating the Board's duty to examine legality, feasibility, security, cost and public interest.

Automatic approval at month six would weaken that allocation. So would indefinite review whose public record says only “in progress.” The governance problem is not solved by choosing one failure mode over the other. It is solved by preserving the reasons for time.

Dialogue can clarify the record; it cannot relocate the decision

The August reply identifies Board liaisons, proactive exchanges with the GNSO Council and Board Caucus Groups as ways to improve preparation. The 2025 Board Readiness report had described the underlying gap. Traditionally, it said, the Board began considering recommendations months after a PDP team had issued its Final Report and disbanded. By then, the people most familiar with compromises, rejected alternatives and drafting history had returned to ordinary work.

Earlier questions can prevent that loss. A Board liaison can signal that a recommendation may create a Bylaws, cost or implementation concern while the Working Group can still explain its reasoning. A caucus can organize directors' analysis. Staff can assemble feasibility and Public Comment materials. Working Group leaders can distinguish an intentional balance from an accidental ambiguity.

None of those participants should acquire a hidden amendment power. A liaison conveys and surfaces; it does not determine GNSO consensus. A staff assessment informs; it does not replace the recommendation. A bilateral conversation may produce clarification, but if the substance changes, the record must identify who had authority to approve that change and whether it returned to the policy body.

The Board's own reply recognizes this line. It says interaction can clarify the record and surface questions without altering the respective roles of the Board and Council. That is the right institutional test. Speed gained by collapsing roles is not process improvement.

A scorecard answers “where”; a clock must answer “how”

ICANN org says it publishes the Consolidated Policy Scorecard periodically to bring community-developed policy and other outcomes into one status resource. The value is obvious. A reader should not need to reconstruct every project from correspondence, Board minutes, GNSO pages and implementation sites.

But “periodically” leaves an evidence problem. Suppose an item changes from “under Board consideration” to “implementation queue.” A current scorecard can display the new state. Unless prior states and transition events remain available, it cannot answer when the Board first had a complete record, what delayed scheduling, which question was material, whether the target date changed or whether one recommendation was pended while others were adopted.

Status vocabularies can also compress unlike conditions. “Pending” might mean Public Comment remains open, the GAC response date has not arrived, a feasibility analysis is incomplete, directors asked a legal question, a workshop is scheduled, or no owner has set the next action. Those conditions impose different duties and support different conclusions.

The answer is not to publish privileged legal advice or protected security material. A bounded public reason—legal review, technical feasibility, resource analysis, public-policy input, clarification requested, agenda capacity—can identify the class of dependency. The institution can disclose more later if the justification expires.

Build a recommendation-to-decision clock

Daniel Kade's proposed clock begins when the Board receives the authoritative Recommendations Report. It records the package identity and hash, the GNSO vote, the applicable Bylaws path and voting threshold. It then lists required inputs and the date each one becomes available: Public Comment, GAC notice, feasibility analysis and any other named record.

The clock separates coordination from authority. It may name a liaison, caucus or staff owner responsible for moving information, but labels the Board as the decision-maker. It records the first discussion and later material deliberations without pretending that an observer's attendance proves an outcome.

Its status vocabulary should be narrow: received, inputs pending, ready for deliberation, clarification requested, decision scheduled, adopted, rejected, pended, withdrawn or superseded. Each state needs an evidence date, next action, owner and expectation. If the expectation changes, the prior value remains visible with a reason; it is not overwritten by the latest estimate.

At decision, the clock stores disposition per recommendation, not merely per report. It links the vote, rationale, conditions and any material question returned to the Council. If adoption leads to an implementation queue, a separate handoff records the project identity and the difference between queued and started.

This is not a demand for a mechanical deadline. It is a demand that discretion leave a trace. A complex recommendation may take longer than six months for good reasons. A public clock would let the Board show those reasons rather than asking the community to infer them from a sequence of reassuring updates.

Sources

  1. ICANN correspondence index
  2. Tripti Sinha to Mason Cole, Rafik Dammak et al., 21 August 2026
  3. Owen Smigelski, Mason Cole et al. to Tripti Sinha, 25 May 2026
  4. ICANN Board approved resolutions, 7 June 2026
  5. Current ICANN Bylaws
  6. ICANN policy implementation page
  7. GNSO Board Readiness Small Team Final Report
  8. GNSO IDN EPDP project page
  9. GNSO Transfer Policy Review project page