Summary

  • Fundamental Bylaws amendments effective 3 July put both the CSC effectiveness review and periodic IANA Naming Function Review on clocks measured from delivery of the previous final report; the former recurring CSC interval also moves from three years to five.
  • The design creates room to finish and implement a review, but duration now stretches the gap between review starts. ICANN should publish a two-clock ledger showing every anchor, outer date, early trigger, delay, final report and reset.

Two amendments, one timing decision

The change reached operative text through a defined corporate chain. The ICANN Board approved amendments to Articles 17 and 18 on 3 May 2026. Its Secretary notified the Empowered Community on 11 May and proposed that the two items be considered together because both govern oversight of the IANA naming function. The public action record then shows support from the ccNSO, ASO, ALAC and GNSO, an abstention from the GAC and no objection. The Bylaws require at least three supporting Decisional Participants and no more than one objector for this kind of Fundamental Bylaws amendment. The current Bylaws say they were amended on 3 July 2026.

That record establishes the instrument and its authority. It is not a popular vote by Internet users, and it need not pretend to be one. The Empowered Community exercised the approval power assigned to it by ICANN's corporate constitution. The useful accountability question is therefore narrower: what exactly did the approved text do, and how will readers know when each new deadline arrives?

The two clocks perform different jobs. The Customer Standing Committee continuously monitors Public Technical Identifiers against the IANA Naming Function Contract and service expectations. A CSC effectiveness review asks whether that oversight body itself works. A periodic IANA Naming Function Review examines PTI's performance and the wider oversight arrangements. Combining their amendment process did not merge their mandates.

The CSC clock grew and acquired a reset rule

The former Article 17 text required an initial CSC effectiveness review two years after the committee's first meeting, then a review every three years. The amended provision removes that historical first-review clause and sets the recurring interval at five years, calculated from delivery of the prior review's final report.

The clause retains a pressure-release mechanism. The CSC, ccNSO, GNSO, ICANN Board or PTI Board may request a review sooner. If an off-cycle review occurs, its final report becomes the anchor for the next five-year period. The same amendment also authorises appointing groups to name alternate CSC members and alternate liaisons, with their role and selection method defined by the CSC.

The five-year interval was not accepted without a warning. The public-comment record says seven commenters fully supported the cadence change, while two individuals suggested annual self-assessment or a mid-cycle audit because performance problems might mature before the next full review. Eight commenters supported alternates; one warned that alternates could become long-serving, second-class participants without equivalent attendance and term controls. The Board changed neither proposal, but said the next effectiveness review should revisit the cadence and the actual operation of alternates.

An early-review power is useful, but it is not self-executing. Someone must observe a problem, decide the threshold has been met, place the request on the record and accept that the resulting final report will reset the ordinary clock. Without those events in one visible register, “a review can happen sooner” remains a possibility rather than an accountable safeguard.

The IFR clock kept five years but moved its starting line

Article 18 makes the arithmetic concrete. Before the amendment, a periodic IANA Naming Function Review had to be convened at least every five years from the date the previous review team was convened. It is now measured from the date that the previous team submitted its final report to the ICANN Board.

IFR2 shows the consequence. It was convened on 10 September 2023 and delivered its report on 4 September 2025. Under the old anchor, the next periodic review would have been due by 9 September 2028. The Board says the new anchor moves that outer date to 3 September 2030. The formal interval remains five years, but the possible interval between review starts has grown by almost the entire duration of IFR2.

There is a defensible reason. A review team needs time to investigate, consult and finish, and the institution needs time to consider and implement recommendations before another team begins. ICANN's official synthesis found broad support for the change. The Bylaws also preserve a Special IFR for a deficiency or problem affecting PTI performance. A separate clause permits a periodic review to be delayed while a Special IFR is underway, but only with ccNSO and GNSO supermajorities, an identified period and a delay that should generally end within 12 months after the special review.

The trade-off should nevertheless be visible. A final-report anchor rewards completion and reduces overlap, but a slow review extends the next starting horizon. That is not proof of avoidance. It is a reason to publish duration alongside cadence.

Build the two-clock ledger

ICANN already has the source events. It should join them into a small, permanent control record for every CSC effectiveness review and every periodic or Special IFR. Each row should identify:

  • the review type, governing clause, initiator and authority;
  • the calculated outer date and the event used as its anchor;
  • the planned and actual convening date;
  • the expected and actual final-report date;
  • recommendations, Board disposition and implementation status;
  • any early-review request, Special IFR trigger or overlap assessment;
  • any approved delay, voting record and stated outer limit;
  • the next date calculated after a final report resets the clock;
  • corrections, superseding records and links to controlling documents.

The ledger should distinguish a due-by date from an actual start. It should also distinguish implementation time from unrecorded delay. If a review finishes early, the next outer date should become visible immediately. If a review runs long, readers should be able to see how much of the widened interval came from deliberation, report production, implementation or a separately authorised delay.

The approval record needs two small corrections

The operative result is clear, but ICANN's explanatory record contains two inconsistencies worth fixing. The Empowered Community action page labels the final approval-letter row “3 July 2025,” while the page says the action ended on 3 July 2026, the linked letter is a 2026 instrument and the current Bylaws carry the 2026 amendment date.

The public-comment page and Board rationale also describe the old CSC arrangement in places as a “two-year cycle.” Their own background and the former Bylaws show the more precise rule: the first review after two years, then recurring reviews every three years. Neither discrepancy makes the amendment ineffective. Both make the audit trail harder to read. A correction note should preserve the original record, state the corrected fact and link the controlling text.

That is the purpose of the proposed ledger. Oversight does not become real because a document says “five years.” It becomes reviewable when the public can identify the actor, the clock, the event that moved it and the decision available if performance deteriorates before the next ordinary date.

Sources