Public Comment

Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.

Контент доступен только на следующих языках

  • English

Name: Benson King'Ori Mugure
Date: 20 Mar 2026
Other Comments

1. Rigid Sequencing Endangers Technical Security

While I understand the need to reduce overlapping review fatigue, the proposed sequencing heavily prioritizes administrative reviews over critical security evaluations. The draft dictates that the Security, Stability, and Resiliency Review (SSR) cannot start until 18 months after the Accountability and Transparency Review (ATR). Given the urgent, evolving nature of DNS abuse and infrastructure threats, treating security audits with the same administrative pause as governance reviews leaves the global ecosystem vulnerable.

My Proposed Solution: Decouple the SSR from the ATR dependency. Security reviews should be put on an independent, expedited track. If a full review is too burdensome during the pause, mandate a lightweight, continuous technical monitoring framework for SSR-related metrics to ensure risk mitigation doesn't stagnate while we sort out governance administration.


2. Risk of Opacity and Poor Capacity Planning A pause of up to 24 months provides necessary breathing room, but it risks creating a "black box" where the community loses sight of implementation progress. Furthermore, restarting reviews like the Competition, Consumer Trust and Consumer Choice (CCT) Review without ensuring that we actually have the volunteer bandwidth and meaningful, measurable data ready will simply recreate the exact bottlenecks this amendment is trying to fix.

My Proposed Solution: Institutionalize transparency during the pause. Require ICANN to publish quarterly "Readiness Reports" detailing volunteer bandwidth, implementation capacity, and data maturity (especially for the next gTLD round) so that the eventual restart is driven by empirical readiness rather than arbitrary calendar dates.


3. Hardcoded Restart Intervals Guarantee Future Overlap Section 27.6(c) dictates that the SSR will start 18 months after the initiation of the ATR, and the RDS will start 18 months after the initiation of the SSR. This is a severe structural flaw. By measuring intervals from the initiation of the previous review rather than its completion, we are mathematically guaranteeing that review teams will overlap if any single review takes longer than 18 months. This completely contradicts the stated goal of preventing community overload.

My Proposed Solution: Replace the static "initiation-based" timers with dynamic, "completion-based" triggers. The Bylaws should state that subsequent reviews are initiated within a specific window (e.g., 6 months) after the publication of the preceding review's Final Report. This guarantees a serialized timeline and permanently prevents concurrent Specific Reviews.


4. The Extension Mechanism Forces Unprepared Restarts The draft states the pause automatically ends at 12 months unless a high bar is met—such as four out of seven Supporting Organizations and Advisory Committees (SO/ACs) issuing a statement to support a further pause (up to 24 months). This means if three SO/ACs are completely exhausted and lack the volunteers to proceed, they can be outvoted and forced back into the review cycle before they are ready, defeating the purpose of community relief.

My Proposed Solution: Invert the extension trigger to act as a "Readiness Gate." Instead of requiring a supermajority to delay the restart, require an affirmative statement of readiness from a simple majority of SO/ACs to resume the reviews at the 12-month mark. If capacity is not confirmed, the pause should automatically extend toward the 24-month hard stop to protect community health.

Summary of Submission

I agree that the proposed rigid sequencing and initiation-based timers are counterproductive, as they mathematically guarantee the very overlap and community burnout the amendment seeks to avoid. Your point about the "black box" risk during a 24-month pause is also spot on; a total cessation of oversight without transparency invites stagnation. However, I disagree with the idea of a "Readiness Gate" requiring an affirmative majority to resume. While intended to protect volunteers, it risks giving a small minority of the community an indefinite pocket veto over ICANN’s accountability mechanisms, potentially stalling vital reviews for years.


To fix these structural flaws, the bylaws should transition from static "initiation-based" timers to "completion-based" triggers, ensuring a review only begins six months after the previous one concludes. To maintain security, the SSR review should be decoupled from administrative pauses and placed on an independent, expedited track or replaced by a continuous technical monitoring framework. Furthermore, ICANN should be mandated to publish Quarterly Readiness Reports during any pause to track data maturity and volunteer bandwidth. Finally, the extension mechanism should be simplified to prioritize empirical capacity rather than arbitrary calendar dates, ensuring the community is actually prepared to contribute before the clock restarts.