Summary

  • The GAC asked for a pre-ICANN86 webinar and an ICANN86 trilateral dialogue on the registrar 15-day verification timeline; the reserved slot instead became a GNSO informational briefing, with several Board members present only as observers.
  • The Board chair later said that any new or modified registrar obligation under the RDDS Accuracy Program Specification must come through contractual negotiations or gTLD policy development. The public record does not show that either route was selected.
  • ICANN should publish a versioned route-selection receipt after cross-institutional dialogue so that information, observation, prioritization, negotiation and policy development cannot be mistaken for one another.

A meeting changed form before a route was chosen

On 11 May 2026, GAC Chair Nicolas Caballero asked the chairs of the ICANN Board and GNSO Council to reconvene a trilateral setting during ICANN86. The proposed subject was the gap between registration and the point at which a registrar may validate a registrant's contact information. The GAC also sought a pre-meeting webinar so its members could enter the trilateral discussion informed and ready to consider concrete next steps.

The requested sequence was clear: webinar, then trilateral dialogue, then discussion of next steps. The scheduled result was different.

On 26 May, GNSO Chair Susan Payne said there was not enough time to prepare a useful pre-ICANN86 webinar. She proposed using the slot reserved for the trilateral meeting as an informational session instead. The timing also clashed with the Registrar Stakeholder Group's meeting, even though registrars were the parties subject to the existing obligation. The GNSO remained willing to join later dialogue with the GAC and Board.

The ICANN86 public record calls the 9 June session an “Informational Session on Accuracy of Registration Data.” It says the session was intended to explain the background, possible abuse of the timeline, operational consequences of change and possible implementation paths. It also describes the trilateral dialogue as an eventual meeting expected after the Seville forum.

That was not wordplay. An informational session can improve the evidence base. A trilateral dialogue can expose institutional positions. Neither is a mechanism that writes a binding registrar obligation.

Observation was not Board approval

The Board chair's 25 August reply, published on 14 September, supplies the next distinction. Tripti Sinha wrote that the GAC received an initial briefing from the GNSO during ICANN86 at the time originally proposed for the trilateral meeting. Several Board members attended “as observers.”

Observer status matters because attendance is easy to inflate into mandate. The letter does not say the Board voted, approved the GAC preference, selected an implementation path or authorized a contract change. It records presence at an informational event.

The Board did express a shared goal of further reducing DNS Abuse. It also called for diverse data sources so the community could compare the impact of multiple efforts. That statement supports continued examination; it does not collapse evidence review into a policy decision.

The existing duty and the requested result are not the same thing

The RDDS Accuracy Program Specification in the 2013 Registrar Accreditation Agreement already creates obligations. For specified registration, transfer and holder-change events, registrars must validate required fields and verify the relevant contact channel within 15 days. If the registered name holder does not provide the required affirmative response, the registrar must verify manually or suspend the registration until verification occurs.

The GAC's stated preference goes further in timing. Its May letter argues that registrant contact information should be verified before a newly registered name becomes accessible through the DNS. The distinction is not whether accuracy matters. It is whether the current obligation is being explained, or whether its trigger, deadline or consequence is being changed.

That classification determines the authority route. The Board chair wrote that if the goal is to create new obligations or modify existing ones for registrars concerning the RDDS Accuracy Program Specification, only two mechanisms can generate them: contractual negotiations and gTLD policy development.

The sentence is narrow. It concerns this type of registrar obligation. It is not a claim that every DNS Abuse measure must travel through those same two channels, and it is not evidence that either channel has begun.

The issue report is a waypoint, not a route decision

The Board letter points to the GNSO's Final Issue Report on DNS Abuse and says it may facilitate future policy development. The report does discuss the lack of proactive or timely contact verification. It records the concern that the current post-registration window may be exploited, cites research on earlier checks, and notes competing suggestions: immediate contract amendment, later policy work, other GNSO-led work or compliance and technical follow-up for narrower issues.

But the report's first two recommended PDP priorities are Associated Domain Checks and safeguards for API access by new customers. Proactive contact verification appears among remaining gaps that could be considered in later phases, subject to available resources, community bandwidth and Council priorities.

This is precisely why a reference to an issue report cannot be reported as a policy launch. The topic is inside the policy inventory. It is not thereby inside the first authorized work package.

The 70% figure is evidence, not a mandate

The GAC letter quotes the INFERMAL finding that validating phone or email during account creation or before purchase was associated with roughly a 70% decrease in malicious registrations. The underlying report describes a statistically significant coefficient in its model and dataset.

“Associated with” must remain intact. The result does not prove that changing the contractual clock will cause the same reduction everywhere. It does not settle implementation costs, false positives, registrant rights, reseller arrangements or the relative value of other mitigation measures. It informs route selection and policy design; it does not authorize either.

A route-selection receipt would make progress legible

After a cross-institutional discussion, ICANN should publish one compact, versioned receipt. It should state the requested outcome in operational terms. It should classify the request as interpretation of an existing obligation or creation or modification of an obligation. It should name the selected formal route—or say that none has been selected.

The receipt should identify the body or parties able to make the next decision, the resource and prioritization gate, the next authorized act, the matters explicitly not decided, and the status date. If the route changes—from dialogue to contract talks, from inventory to PDP scoping, or back to evidence gathering—the prior state should remain visible.

Applied to this case, the current receipt would say: the requested result is pre-resolution contact verification; the proposal would alter the timing of an existing registrar duty; the Board has identified two legally operative routes; no public source reviewed shows a route selection; the GNSO's prioritization and resource constraints remain relevant; and the briefing and observer attendance did not amend the RAA, launch a PDP or approve the GAC request.

That record would not favor the GAC, the Board, the GNSO or contracted parties. It would do something more basic: keep participation, information and authority in their proper places.

Sources