Summary

  • On 6 September, ICANN’s Board authorized a contract for system development and support for the New gTLD Program: 2026 Round. The decision, published on 9 September, names functionality, incident response, stability and critical business processes but redacts the vendor, amount and much of the rationale.
  • A 3 May authorization had described enhanced on-call support as a six-month measure spanning application opening through anticipated String Confirmation, with the team expected to reduce to regular business hours afterwards.
  • The public record does not establish whether the September contract continues the same vendor, scope or arrangement. It does establish that the earlier support model had a stated temporal boundary whose outcome is now worth recording.
  • ICANN could publish a non-sensitive sunset test showing the steady-state owner, normal coverage, transferred functions, unresolved exceptions, decision date and next review without exposing commercial terms or incident playbooks.

The second authorization changes the question

The Board resolutions approved on 6 September authorize ICANN’s President and CEO, or his designees, to enter a contract and make related disbursements for “system development and support” needed by the 2026 Round. The public clauses point to four needs: adequate system functionality, timely incident response, system stability and support for critical business processes. They say the cost is accounted for in the FY27 budget and future budgets.

Those statements explain why support matters. They do not publish its service catalogue, hours, severity definitions, transition conditions, term, supplier or price. A paragraph that might have supplied more context is redacted, along with negotiation information in the authorization and rationale. ICANN classifies the decision as an Organizational Administrative Function that does not require public comment.

There is nothing inherently suspicious about either fact. A technology programme can require specialist support after its launch, and an organization should not publish terms that weaken a live negotiation or details that make systems easier to attack. The gap lies elsewhere: the September record is easier to read when placed beside the Board’s 3 May decision.

In May, ICANN described contract extensions for an enhanced on-call support model. The stated period ran from the application window opening on 30 April through String Confirmation, then anticipated on 30 October. Expanded hours were intended to provide incident coverage outside ordinary business hours during six months of elevated demand and complexity. At the end, the support team was expected to reduce and operate during regular business hours.

That was a testable operating promise, even though it was not framed as a formal performance commitment. It supplied a before-and-after state. The September authorization now makes the transition itself the material governance object. Will enhanced coverage shrink as expected? Has the processing calendar changed? Are some functions ready for steady state while others need an exception? Is continued support development work, incident coverage or ordinary maintenance?

The public sources do not answer those questions. They also do not prove that the May and September decisions concern the same vendor, contract or scope. The defensible response is not to join the two records by assumption. It is to ask ICANN to publish the boundary at which temporary resilience becomes an accepted operating baseline.

Submission ended; the system journey did not

The 2026 Round passed a visible milestone on 12 August. ICANN reported more than 1,600 primary applications, with more than 1,100 replacement-string applications attached. The organization then moved into administrative review and preparation for Reveal Day. That number describes applications, not transactions, tickets, concurrency or incident volume. It cannot prove how much on-call capacity is needed.

It does show why “the window closed” is not an operational finish line. The Applicant Journey continues through public disclosure, community input, objections and appeals, string evaluation, applicant and application evaluation, contention resolution, contracting, onboarding and delegation. Different stages put different demands on systems, staff and applicants.

The February programme status report makes that layered architecture visible. It said TAMS build 5 and user-acceptance testing were complete, end-to-end integration testing had begun, and builds 6, 7 and 8 were still planned for evaluation and contracting functions later in the processing phase. It separately described governance, infrastructure development, operationalization, readiness for staff and vendors, and supporting functions such as finance, vendor management, human resources and legal.

The consequence is important. A support contract can span software development, production response and business-process assistance without those activities reaching steady state on the same day. Turning off enhanced coverage everywhere at one calendar boundary may be reckless. Continuing it everywhere without a recorded decision may be equally uninformative. The transition needs a function-by-function result, not a ceremonial expiry date.

What a sunset test would record

A useful public sunset test could fit on one page. It would begin with a stable identifier for the decision and the assessment date. It would name broad service classes—application intake, payment and administrative checks, evaluation workflow, disclosure, contracting, or other accurate categories chosen by ICANN—without publishing architecture or vendor secrets.

For each class, the record would answer six questions:

  1. What coverage was exceptional, and what is the intended normal-hours baseline?
  2. Which ICANN role owns service acceptance and the decision to reduce, continue or redesign support?
  3. What evidence was reviewed: tested recovery, support-hour data, unresolved defects, workload forecast, runbook transfer or another bounded measure?
  4. Which functions have moved to steady state, and on what date?
  5. Which exceptions remain, why are they still open, and when will they be reconsidered?
  6. What is the next public decision point?

This is not a request for a universal uptime percentage. Averages can conceal the few periods in which timing matters most. Nor should ticket totals be presented without definitions: one reporting system’s incident may be another system’s request, defect or planned change. A good record states the unit before displaying the count.

The outcome need not be “end the contract.” A sunset test is a decision gate, not a predetermined verdict. It could find that ordinary-hours support is now sufficient; that a named class needs temporary extended coverage; that internal ownership is ready but a particular build still requires specialist assistance; or that the operating baseline has legitimately changed. Each result becomes more credible when it carries an owner, evidence date and next review.

Confidentiality and accountability can coexist

ICANN’s Documentary Information Disclosure Policy starts from public availability while recognizing reasons to withhold information, including material that could prejudice commercial interests. Its publication practices likewise explain that Board resolutions, preliminary reports and minutes are published under the Bylaws, with specified grounds for omission.

A sunset record can respect that boundary. It need not identify the supplier, quote the price, describe vulnerabilities, reveal credentials, publish a live escalation tree or expose a person’s shift. “Evaluation workflow remains on extended coverage until a dated readiness review” conveys a governance fact without becoming a map for attack or a negotiating brief.

The Contracting and Disbursement Policy supplies a separate financial control: Board approval is required above USD 750,000, and the CFO periodically reports significant disbursement activity. The September amount is hidden, so the policy does not license an estimate. More importantly, financial authorization and operational acceptance answer different questions. A properly approved payment does not by itself show that temporary support can be retired.

That distinction keeps this proposal clear of the redaction debate. A future release of supplier and price information may improve the procurement record. It would not show which support functions transferred, whether normal coverage was restored or why an exception remained. The public sunset test is about operating state, not bargaining detail.

Evidence boundaries

No cited source reports a failed handover, missed response target, outage, breach, poor vendor performance, budget overrun or lock-in. The application total does not measure platform load. TAMS, RSP and ASP appear in the May history, but the September wording may encompass other functions; this article does not equate the two scopes.

Nor does the September authorization prove that ICANN abandoned the May expectation. The later decision could support planned work, a distinct phase, a different agreement or a carefully managed transition. Most of its rationale is not public. The point is narrower: when a public rationale creates a temporal operating boundary, a later public result should say what crossed it.

Sources

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. ICANN — Approved Resolutions, 6 September 2026
  5. ICANN — Approved Resolutions, 3 May 2026
  6. ICANN — New gTLD Program: 2026 Round Status Update for ICANN85
  7. ICANN — 2026 Round Closes with More Than 1,600 New gTLD Applications
  8. ICANN New gTLD Program — 2026 Round Applicant Journey
  9. ICANN — Documentary Information Disclosure Policy
  10. ICANN — Publication Practices
  11. ICANN — Contracting and Disbursement Policy