Summary

  • ICANN's Review of Reviews CCG is preparing a Second Draft Report after receiving 23 submissions on its first design. The official record says the new version will reflect both those comments and the group's continuing deliberations.
  • A second consultation should open with a public change ledger: one row for each material provision, linking the First Draft baseline, relevant input, later proposals, disposition, reasons, Second Draft text and unresolved decision rights.

The second draft will answer two different histories

The Review of Reviews is not a minor exercise in document maintenance. The Cross Community Group is designing the future machinery through which ICANN will examine its own accountability, transparency and structure. Its 25 June First Draft proposed two scheduled reviews, a family of On-Demand Reviews, a one-time assessment connected to the Continuous Improvement Program pilot and a standing Reviews Scoping Committee to coordinate the system.

That proposal was opened for comment until 4 August. ICANN's summary report counts 23 submissions: 21 received through the proceeding and two accepted late. It now says the CCG is preparing a Second Draft Report for additional public input.

The important sentence in the official outcome is easy to pass over. The next draft will take account of concerns and suggestions about the First Draft while also reflecting the CCG's continuing deliberations and refinement of its iterative proposals. Those are two different change streams. One begins with an identifiable submission. The other begins inside the working group after, or alongside, the consultation.

Both can be legitimate. A drafting group must be able to think, test and improve its own work. Public comment is not a vote, and the number of submissions does not allocate authority. But when the consulted object changes through two streams at once, a clean replacement document is not enough. Readers need to know which provisions answered which input, which changed for another reason, which were left intact and which new questions appeared only after the first comment window closed.

The First Draft placed authority inside a new coordinator

The baseline matters because the First Draft did more than rearrange a calendar. It proposed a new standing body, the Reviews Scoping Committee, as the central coordinator of the future reviews system. The RSC would help initiate scoping, assess possible topics, consider feasibility and resources, develop shortlists, recommend deferrals and support the drafting of review charters.

The same draft proposed an Accountability and Transparency Review every five years. The clock would run from the Board's resolution on the previous recommendations, with a backstop no later than 12 months after the final report reached the Board. A Structural Review appeared on a bracketed 15-year cadence, using a similar anchor. The document offered On-Demand Reviews for issues that could not wait and a one-time review of the CIP pilot. It also proposed routes for SSR, Registration Directory Services and Competition, Consumer Trust and Consumer Choice topics to enter the new system.

These choices allocate more than workload. They decide who can place an issue inside a review, who can narrow it, when a mandatory exercise may be deferred, which groups must agree, how community capacity is measured, and how long the institution may operate before the next examination begins. A scoping committee can improve discipline. It can also become a gate if its authority, membership, conflicts and reasons are not bounded in public.

The comment summary shows that this was understood. Most contributors who addressed the idea supported some central coordination, but several worried that the RSC could exceed process management and become a gatekeeper or oversight body. Commenters asked for clearer roles among Supporting Organizations and Advisory Committees, the Board, ICANN org and the RSC. They questioned composition, representation, conflicts, disclosure and the possibility of concentrating authority in a small leadership body.

That is not a single objection that can be marked “resolved.” It is a set of design tests. The Second Draft must show whether the RSC's powers were reduced, divided, made reviewable, left unchanged or merely described in more detail. Each outcome carries a different governance effect.

The 23 submissions did not point in one direction

The official summary records broad support for modernizing the system and reducing overlap, delay and workload. It also records disagreement over the matters that determine whether efficiency weakens accountability.

Several SO/AC groups wanted a distinct Security, Stability and Resiliency review preserved because of its relationship to ICANN's Mission. The Security and Stability Advisory Committee viewed the draft's approach as a compromise that could keep SSR issues predictable and visible. Other comments questioned whether SSR, RDS and CCT needed a separate recurring route when an ATR and On-Demand Reviews might address them. There was no simple majority position capable of replacing the design work.

The same tension appeared around timing. Some commenters accepted a Structural Review but sought clearer scope, methodology, expertise, phases and decision points. The proposed 15-year cadence drew disagreement. Comments asked for explicit triggers, real start and end dates, implementation plans and safeguards against repeated delay. On-Demand Reviews were welcomed as flexible, but respondents also warned that they could fragment capacity or remove a guaranteed examination of mission-critical subjects.

ICANN org's own submission asked for clearer authority and decision rights, a simpler scoping process, comparable indicators across successive ATRs, stronger Structural Review methodology, limits on On-Demand workload, recommendations tied to findings and measurable criteria for judging the new framework.

The summary is useful. It is also explicit that it does not replace the submissions. A thematic synthesis tells the reader what kinds of arguments were received. It does not tell the reader how each material provision was disposed of.

The design was still moving after the window closed

The CCG's public list makes that movement visible. Calls in August were devoted to digesting comments and discussing Second Draft updates on the purpose of reviews, the ATR and the Structural Review. On 28 August, the timeline subgroup published a package for discussion by the full group.

The subgroup recommended that ATR scoping begin five years after the Board concludes action on the preceding final report, or 12 months after delivery of that report, whichever comes first. It proposed that the Board deal with ATR recommendations within three months and Structural Review recommendations within four. If action remained incomplete, the Board would report formally at six months and every three months thereafter.

It recommended that an ATR and Structural Review not run concurrently. At the same time, two On-Demand Reviews, or one scheduled review and one On-Demand Review, could overlap at community discretion after an RSC feasibility assessment. It favored 36 months between scheduled reviews, three months for certain SO/AC responses, a 12-month substantive ATR, a 15-year Structural Review cadence and an 18-month combined internal-landscape and consequential-effects phase. It would start the first cycle with an ATR.

These are not final decisions. They are subgroup recommendations awaiting CCG discussion. That distinction is precisely why a ledger is needed. A later reader should not have to infer from an email thread whether a clock became CCG consensus, remained an alternative, was modified in a meeting, or disappeared before publication.

Publish the change ledger with the Second Draft

The ledger does not need to be grand. It needs to be exact. Every material First Draft provision should receive a persistent identifier and one row containing:

  • the First Draft section, page and baseline proposition;
  • links to every relevant submission and later public proposal;
  • the evidence class: commenter request, staff analysis, subgroup recommendation, CCG deliberation or nominating-group direction;
  • a disposition such as accepted, accepted in part, declined, deferred, superseded, open or outside scope;
  • the reason and the actor or forum responsible for that disposition;
  • the Second Draft location and a concise description of the change;
  • the effect on authority, thresholds, timing, representation, funding, concurrency, remedies or implementation;
  • any new question created by the change;
  • the consensus state and any minority or unresolved alternative; and
  • the version, date and link for a correction or later superseding entry.

Two companion records would complete the picture. An open-issues register should name unsettled choices, alternatives, owners and expected resolution points. A decision-rights map should distinguish CCG consensus from SO/AC support, Board consideration, Bylaws amendment, ICANN org implementation and later operational discretion.

This is not a demand to count comments as ballots. A well-designed ledger could reject a widely repeated suggestion and still be accountable if it named the authority, gave the reason and showed the controlling evidence. It could accept a point raised by one commenter without pretending that the commenter held a mandate. Traceability is not plebiscite.

A second consultation should not require institutional archaeology

Without a change ledger, the next respondent will have to compare a 30-page First Draft, 23 submissions, a 15-page summary, meeting notes, public-list discussions, subgroup charts and the Second Draft. That burden rewards people with time, staff and memory. New or intermittent participants see the new text but not the path that produced it.

The cost is larger than inconvenience. Suppose the Second Draft narrows the RSC's gatekeeping power, changes a review clock and introduces a new concurrency rule. A reader needs to know whether each change answers a submitted concern, implements a later subgroup judgment or remains provisional. Otherwise the second consultation mixes old questions and new questions without saying which are which.

The charter already keeps consultation and authorization separate. CCG members act in their individual capacity. The Supporting Organizations and Advisory Committees later decide whether to support the recommendations through their own procedures. The Board then considers what reaches it. A change ledger would not disturb that chain. It would give every actor a common evidentiary record before exercising the authority it already has.

The CCG deserves credit for choosing another consultation rather than treating a materially evolved design as final. The credibility gain will depend on what accompanies the next draft. A second clean document says where the proposal arrived. A public change ledger shows how it got there.

Sources