Summary

  • Verisign’s 15 April 2026 RSEP 2026013 request proposed ending new third-level .NAME registrations and terminating and deleting the existing ones. ICANN approved it on 7 May and issued a free-to-deploy letter on 28 July. That letter reports Verisign’s estimate of about 22,000 existing registrations, most of which Verisign said were unused.
  • ICANN’s review found no significant security, stability or competition issues under the Registry Services Evaluation Policy. ICANN staff told the Board Accountability Mechanisms Committee that the test addresses the DNS as a whole and that the impact on individual registrants, though understood, is outside its criteria. The committee recommended denial of an initial reconsideration request; ICANN later consolidated six related requests for committee and Board consideration. The published records do not establish a service termination date or show that the names have already been deleted.

The form that tried to have it both ways

Verisign’s request is admirably plain in one place. It asks to discontinue third-level registrations under .NAME. New names would no longer be accepted. Existing third-level names would be terminated and deleted. The registry operator gives declining usage, limited registrar support and operational efficiency as the reasons. In a different answer on the same form, asked what effect the proposal would have on the life cycle of domain names, it says: “None. There will not be any effect on the life cycle of domain names.”

The document makes the contradiction visible without a leak or a hostile interpretation. A name that can be renewed today would have its registration ended when the service stops. Verisign may be using “life cycle” as a term for the technical stages a name passes through, but the form does not explain that distinction beside the answer. It reports deletion in the service description and no effect in the life-cycle box. A reader who owns one of those names experiences a different kind of life cycle from the one that fits neatly into a questionnaire.

The request also draws its own notification chain. Verisign promises at least 90 days’ notice to registrars that support third-level .NAME, a reminder at least 30 days before discontinuation, and customer-service support for those registrars. It says it consulted verbally with a selected group of registrars comprising a majority of the service’s user base, and none reported a security, stability or competition concern. The form does not document an equivalent direct consultation with registrants. The registrars are the communication bridge to people whose actual names are at stake.

This matters because third-level .NAME has a different geometry from a typical new product feature. A user can have first.last.name while a separate second-level label sits between that user and the top-level domain. The operator’s decision to stop offering the service ends new supply. Its decision to terminate existing names reaches backward into registrations already held. Those are two choices with different consequences; the form bundles them into one exit.

Approval did not mean an impact vote

ICANN’s 28 July free-to-deploy letter records a precise sequence. The organization approved RSEP 2026013 on 7 May and posted that approval the next day. After the request and related discussions, it concluded the change raised no significant security, stability or competition issue as the RSEP defines those tests. A pending renewal of the .NAME registry agreement led ICANN to authorize the exit by letter rather than immediate contract amendment. The letter says Verisign is free to discontinue the third-level registration service and repeats the 90-day and 30-day registrar notices.

The same letter reports an estimate: about 22,000 third-level registrations. It attributes that figure, and the assertion that most are unused, to Verisign. “Most unused” is no count of names that are safe to erase. A single name in an old mailbox, an account recovery setting or a software configuration can matter more to its holder than thousands of dormant rows. The official record supplies the operator’s estimate; it does not provide an independently audited use inventory or a list of successful migration arrangements.

ICANN was aware of the scale. The Board Accountability Mechanisms Committee recommendation says the pre-submission conversations included the roughly 22,000 figure. Its treatment of the first challenge concludes that staff considered the relevant information and did not rely on false or inaccurate material in a way warranting reconsideration. The problem is therefore not a secret headcount smuggled past an inattentive reviewer. It is the narrower authority of the test the reviewer applied.

The committee’s 24 August minutes put that authority in unusually direct terms. Staff explained that the security and stability review concerns the DNS as a whole rather than individual registrations. Staff said the impact on individual registrants was understood but was not among the criteria for deciding whether an RSEP request is acceptable. The process has no formal channel for third-party input, staff said, although Verisign reported speaking to relevant registrars. The committee recommended that the Board deny Request 26-2. A procedural test did exactly what it was built to do, and exposed what it was not built to count.

ICANN’s July letter makes the split explicit again. Its RSEP evaluation, it says, is limited by the policy’s language and does not extend to other potential impacts of discontinuing a service. A footnote assigns the relationship with registrants to registrars. ICANN authorized the operator; the operator must notify registrars; registrars deal with registrants. At each handoff, a different institution can truthfully describe its own bounded role. The holder of a third-level name still needs a dated, usable answer about renewal, cancellation, substitutes and old references.

One service leaves; six requests arrive

One registrant challenged the approvals of the third-level registration and associated .NAME email-forwarding services in Reconsideration Request 26-2. The email service is a separate RSEP request, 2026014; it matters to some users, but its technical scope should not be folded into the registration-service decision. The BAMC recommendation found the initial challenge did not show a qualifying process failure or reliance on false relevant information. It also said several requested remedies, including a public comment round, impact reassessment and grandfathering through paid expiry, went beyond reconsideration or belonged in registrar-registrant contracts.

A later request filed by Patrik Fältström draws the line between ending new sales and destroying old registrations. The requester says he has used a particular third-level name for more than 25 years and argues that it cannot simply be moved to another registry operator. He raises a conditional security question: if a corresponding second-level name later becomes available to a stranger, could the former third-level name reappear under new control? That is a proposed risk, not evidence that a takeover has happened. The document asks ICANN to examine it before existing names are removed.

On 14 October, ICANN told Fältström it would consider six requests together: 26-2, 26-5, 26-6, 26-7, 26-9 and 26-10. They concern RSEP 2026013 and/or the separate email-forwarding request. The Board Accountability Mechanisms Committee and then the Board will consider the consolidated group. More qualifying timely requests may join. The August recommendation was a committee position on the first request; the October notice describes a larger proceeding still headed toward a Board decision. Treating the recommendation as a final resolution would skip the very review that the document says comes next.

There is another skipped date to avoid. Approval came in May, authorization in July, and the operator promised notice before discontinuation. None of those dates is proof of actual termination. The RSEP process table marks the request approved. It is not a deletion log. The documents checked here do not give a confirmed final service-stop date or a verified count of names already removed.

The consent buried in an intermediary chain

The request’s registrar consultation is a practical piece of the file, but it is not the same as asking existing holders what continuity they need. A registrar may know how many of its customers use a service, how expensive support will be and how to send a notice. A registrant knows what an old name is still doing in account records, software, contacts and memory. Those types of information meet only if someone deliberately carries the second into the first.

The official letter tells registrars when they must hear from the registry operator. It does not itself promise a direct date by which every registrant will receive and understand notice. Its footnote says registrars manage that relationship. That may be the normal contractual chain, but normality is precisely why its performance should be made visible when an entire registration class is retired. A notice to an intermediary can be perfectly delivered while an old identifier remains embedded in a system its holder no longer remembers.

The .NAME agreement still references the third-level service. Verisign’s RSEP says those provisions should remain until all third-level registrations end, and ICANN’s letter says the service removal will later be reflected in the renewed agreement. The paper trail therefore has a bridge between temporary authorization and final contractual text. That bridge should carry more than permission to close: the treatment of renewals, actual notice dates, registry-state transitions and any protection against re-creation under a different controller are the elements a holder would need to inspect.