Summary

  • On 15 September 2003, VeriSign inserted wildcard records into the already delegated .COM and .NET registries. Queries for many uninstantiated names that had produced a negative DNS answer instead received a synthesised address associated with Site Finder. VeriSign could make that operational change because it ran the authoritative registry infrastructure. ICANN did not directly edit the zones; it first requested voluntary suspension and then issued a deadline-backed contractual demand for reversion. VeriSign suspended the service by 4 October while expressly disputing ICANN’s evidence, authority and contract interpretation.
  • The technical record did not reduce to a claim that wildcards were forbidden by the DNS protocol. The Internet Architecture Board and ICANN’s Security and Stability Advisory Committee focused on a different problem: a high-level registry wildcard changed an architectural assumption used by web browsers, mail systems, filters and other applications. VeriSign said it had tested the service and challenged the methodology and magnitude of the alleged harms. The advisory bodies could analyse and recommend, but neither possessed the operational switch or contractual enforcement power.
  • Litigation created places to contest ICANN’s conduct, yet the located terminal orders do not establish a final merits holding that Site Finder breached the 2001 registry agreements. The durable institutional response was prospective. The 2005 .NET agreement, the ICANN Board’s November 2005 consensus-policy decision, the 2006 .COM agreement and the Registry Services Evaluation Policy converted an improvised launch-and-rollback conflict into prior notification, an initial staff screen, competition referral where appropriate, expert and public review of significant security or stability questions, a Board decision, and bounded reconsideration.

Two dates, and two different kinds of power

On 15 September 2003, a user who mistyped an unregistered .COM or .NET name no longer necessarily encountered the ordinary signal that the name did not exist. VeriSign had placed wildcard records into the authoritative zones. For affected queries, the registry’s servers returned a synthesised address that led web traffic towards Site Finder, a VeriSign-operated search and navigation service. Four days later, ICANN’s advisory described the change, identified effects reported by network operators and software users, requested that VeriSign suspend it voluntarily, and sent technical questions to the Internet Architecture Board and ICANN’s Security and Stability Advisory Committee.

On 3 October, ICANN escalated from request to demand. In Paul Twomey’s letter to VeriSign, ICANN asserted that Site Finder conflicted with several provisions of the .COM and .NET agreements, required restoration of pre-launch operation by 6 p.m. Pacific time on 4 October, and warned that the organisation would take steps to enforce the contracts if VeriSign did not comply. VeriSign’s same-day response said the demand was groundless, rejected the asserted factual and legal premises, agreed to suspend within the deadline, and reserved its rights. The wildcard was removed. ICANN’s archived wildcard chronology records the 15 September deployment and 4 October suspension, while the contemporaneous letters establish the parties’ opposed positions. The actor with the capacity to alter the authoritative zones had complied operationally without conceding that the actor asserting contractual authority was right.

That separation is the institutional core of the case. VeriSign had control of implementation. ICANN had a contract, an asserted power to enforce it, and the capacity to raise the cost of refusal. The IAB and SSAC had expertise and public standing but no switch. Registrars, network operators, software developers and users could report effects, adapt systems and participate in policy work, but they could not compel suspension. Courts, an arbitral forum and ICANN accountability mechanisms offered routes to challenge institutional action, not automatic restoration of the service or compensation.

The Board could adopt a prospective policy, but adoption was distinct from operating the registry. Site Finder was stopped because the operator removed it in response to a threatened enforcement chain, not because a court issued a permanent injunction after deciding the contract merits.

The distinction matters because institutions often describe an urgent response as though authority, evidence and remedy arrive together. Here they did not. ICANN’s demand was consequential before its contract theory had been adjudicated. VeriSign’s compliance reduced immediate operational conflict before its legal objections had been resolved. Technical advice shaped the legitimacy of the demand without itself making the demand enforceable. The later policy was therefore not merely a codification of who had “won” in 2003.

It was an attempt to change the sequence so that the hardest questions would be considered before a registry-level service altered the behaviour of systems outside the registry.

An existing delegation, not a new application

The .COM and .NET zones were not applicants waiting to enter the root. They were long-standing delegations governed in 2003 by separate agreements executed in 2001. The 16 April 2001 .COM Registry Agreement and the 25 May 2001 .NET Registry Agreement recognised VeriSign as the registry operator and assigned it the operational functions through which authoritative answers were produced. The root delegated .COM and .NET to authoritative servers run by VeriSign, which maintained the registry data and served the answers. Site Finder therefore arose inside an existing relationship. There was no new-gTLD application, contention set, community priority evaluation, contracting stage or IANA redelegation for ICANN to approve or deny.

The 2001 agreements nevertheless supplied the legal objects over which ICANN and VeriSign fought. Their provisions defined registry services, specified technical and functional obligations, regulated registrar access, and created routes for enforcement and dispute resolution. The .NET agreement, for example, differentiated changes that could be made with prior notice from material functional changes requiring mutual written consent or an applicable consensus-policy route. It also contained equal-access and code-of-conduct obligations.

ICANN’s 3 October letter drew on that contractual architecture to argue that Site Finder was an unauthorised registry service and that its implementation affected neutral registry operation, registrar protocols and equal treatment. VeriSign answered that the service complied with the agreements and technical standards. The existence of a contract made the demand possible; it did not make ICANN’s interpretation self-proving.

Nor did the contracts establish that ICANN possessed a direct technical kill switch. The 2001 .NET agreement contained an emergency remedy under which ICANN, after notice and an uncured reasonable determination of endangerment, could suspend the agreement for five calendar days while applying for more extended injunctive relief. That was a legal mechanism directed at the contractual relationship. The located record does not show a court or arbitral panel finally deciding that the clause applied to Site Finder, and the clause did not authorise ICANN to enter VeriSign’s production environment and remove the wildcard itself.

What the record shows is a demand, a deadline, threatened contractual steps and operator execution of the rollback. Treating those facts as equivalent to an ICANN-operated switch would collapse enforcement leverage into infrastructure control.

The same care is required when describing “suspension”. VeriSign suspended Site Finder; ICANN did not suspend the .COM or .NET delegations. The root-zone delegations and the underlying registry relationships remained in place. The disputed wildcard function was removed without a successor transition or redelegation. That bounded operational outcome is less dramatic than a registry shutdown, but institutionally more revealing: the conflict concerned what an incumbent operator could add to a critical service, and what process had to precede that addition.

Why a wildcard was more than a search page

At the DNS level, the important change occurred before a browser displayed anything. An authoritative server normally distinguishes among at least three relevant states. A requested name and record type may exist, producing a positive answer. The name may exist without the requested record type, producing a negative answer for that type. Or the name itself may not exist, producing an NXDOMAIN response. Applications and intermediate systems had learned to use those distinctions. Site Finder altered the third state for many .COM and .NET queries by synthesising an A record through a wildcard.

To software receiving the answer, the missing name now appeared to resolve to an Internet address.

The IAB’s September 2003 commentary on DNS wildcards was careful about the protocol point. Wildcards were part of the DNS design; the issue was not that every wildcard was syntactically prohibited. The issue was deployment at a high level in a heavily used public zone. A technically conforming answer could violate assumptions accumulated in applications, resolver libraries, filtering systems and operational practices. The IAB treated the burden of demonstrating that such a change was safe as resting with the party introducing it, and stressed informed consent where a change could affect users or applications beyond the intended service.

That architectural distinction explains why “it was only a web search service” was inadequate. A DNS query does not reliably announce the application that caused it. The same existence test might be triggered by a browser, a mail transfer agent, a spam filter, a security product, a command-line tool, an automated provisioning system or software written years before Site Finder. The registry could direct HTTP traffic towards a landing page, but it could not confine the altered DNS answer to HTTP. Mail software might treat a mistyped domain as deliverable rather than fail immediately.

Filters that used non-existence as a signal might behave differently. Diagnostic tools could receive a positive address where operators expected an error. Privacy consequences could arise when queries that would otherwise have terminated as negative answers instead reached VeriSign’s service.

The SSAC report issued in July 2004 described this as a substitution of a synthesised response for the error condition on which applications had relied. It documented effects on email, anti-spam tools, privacy expectations and network workarounds. It also rejected some of the strongest rhetoric surrounding the episode: the report did not conclude that Site Finder had shattered the Internet, and it acknowledged that the record did not permit a reliable quantitative measure of every effect. Its institutional case rested on the combination of architectural dependency, the scale and diversity of .COM and .NET, insufficiently shared evidence, limited advance notice and the costs shifted to outsiders who had not chosen the change.

This is also where a claim often made about the controversy must be narrowed. The primary record does not support saying that VeriSign conducted no testing. In its 21 September letter, the company said it had undertaken months of testing and analysis, that the service complied with technical standards, and that it was establishing an independent technical review panel. Later submissions continued to dispute SSAC’s methods and conclusions. The procedural deficiency was not a proven absence of internal testing. It was the absence, before launch, of a shared and reviewable record capable of testing how an authoritative-zone change would affect parties outside VeriSign’s own systems.

That difference between internal assurance and externally reviewable evidence became central to the later policy. A registry can test whether its own servers remain available, whether a wildcard answers as designed, and whether a landing page accepts traffic. Those tests do not necessarily reveal what a remote mail system, a resolver with unusual caching behaviour, an enterprise security appliance or a legacy application will do. Nor do they disclose how much traffic will be redirected, what data will be logged, or which workarounds operators will deploy. The relevant evidence set is therefore partly outside the registry.

Preclearance was designed to make those external effects a governance object rather than a post-launch argument.

The first request: suspend voluntarily while the record is built

ICANN’s 19 September advisory did not begin with a formal declaration of breach. It described the service, reported concerns from technical operators, asked VeriSign to suspend voluntarily, and referred questions to SSAC and the IAB. That sequencing signalled uncertainty as well as urgency. ICANN was trying to create a technical record after the service had already changed production behaviour. The request carried institutional weight, but it did not identify a completed adjudication or an agreed emergency procedure tailored to registry-service launches.

VeriSign’s 21 September response opposed immediate suspension. It presented Site Finder as an innovation intended to improve navigation for users, emphasised prior testing and standards compliance, and argued that ICANN should review the evidence before demanding withdrawal. The company’s position exposed a predictable incentive problem. An operator that has invested in a service and launched it at scale gains facts on the ground: users encounter it, commercial relationships begin, and the cost of rollback becomes visible. Other actors, meanwhile, must diagnose effects under operational pressure. Launch-first governance therefore places the burden of uncertainty on those who did not choose the service.

The affected outsiders did not have equivalent authority. Registrars could object that the change altered the environment in which their customers used names. Network operators could install local patches or filters. Software developers could release updates. Users could complain or change settings. Technical bodies could convene, test and publish. But those responses were participatory or defensive. None authorised a third party to remove the wildcard from the .COM and .NET zones. The structure rewarded whoever controlled the authoritative layer unless another institution could make continued deployment legally or commercially costly.

ICANN’s initial request also revealed the limitations of transparency after deployment. Public discussion can improve the evidentiary record, but a public record assembled while a service is live does not restore the pre-change baseline. Operators may already be implementing workarounds; measurements may be contaminated by those adaptations; and the registry may already be collecting traffic generated by the new behaviour. Transparency is not the same as prior consent, and it is not a remedy. The policy question was therefore not simply whether ICANN should publish more. It was whether the operator should have to wait.

The 3 October demand: authority asserted before merits were settled

By 3 October, ICANN had moved from an appeal for voluntary restraint to an asserted contractual command. Twomey’s demand letter identified several theories. It argued that Site Finder constituted an unauthorised registry service or functional change; interfered with neutral registry operation and equal access; created inconsistencies with registry-registrar protocols and registration provisions; and produced documented effects beyond web navigation. It demanded reversion to the state before 15 September and set a specific deadline. If VeriSign refused, ICANN said it would take steps to enforce the agreements.

The letter was powerful because it joined evidence, legal interpretation, a deadline and threatened remedies. It was not equivalent to a judgment. ICANN was a contracting party and the central policy institution in the registry relationship, but it was also an interested party whose interpretation VeriSign disputed. The contract offered routes to specific performance, arbitration and judicial relief; those routes existed precisely because an enforcement assertion did not end the dispute. The demand changed VeriSign’s risk calculation before any neutral tribunal had decided whether Site Finder breached the agreements.

VeriSign’s 3 October reply made that separation explicit. The company described ICANN’s action as unsupported and overreaching, maintained that Site Finder was standards-compliant and had been extensively tested, criticised ICANN’s treatment of the evidence, and said it would suspend only after ICANN denied additional time. It reserved claims and remedies and stated that compliance should not be treated as waiver or concession. The wording matters. A party may obey a demand because the threatened consequences are serious while preserving the argument that the demand is unlawful. Operational compliance is evidence that enforcement leverage worked; it is not proof that the underlying theory was correct.

ICANN’s own letter pointed towards a more durable answer. It asked the Generic Names Supporting Organization to develop a process that would make review of proposed registry services timely, transparent and predictable. The request itself shows the institutional gap exposed by the controversy: the existing arrangements had not supplied an uncontested, complete and proportionate pre-launch procedure for a disputed registry service.

The rollback therefore resolved one question and left several others open. It restored negative-answer behaviour for the affected names. It did not decide whether VeriSign’s tests had been adequate, whether every claimed effect was material, whether each cited contract provision applied as ICANN said, or what damages—if any—followed from the suspension. It also did not create a permanent legal prohibition on every registry wildcard. The operator could no longer rely on Site Finder’s continued operation while those questions were argued, but the argument itself moved into advisory, policy and litigation channels.

Advice could legitimate a response, but not execute it

The IAB and SSAC occupied a difficult position. Their expertise was central because the dispute involved protocol semantics, application dependencies and operational risk. Yet their formal powers were narrow. The IAB could issue architectural guidance. SSAC could advise ICANN’s Board and community. Neither body was a regulator with independent power to command VeriSign, award damages or amend a registry agreement. SSAC’s report described its role as advisory rather than adjudicative or enforcement-based.

The IAB’s analysis supplied a disciplined way to move beyond the claim that standards compliance ended the inquiry. Protocol specifications necessarily leave room for operational choices. A choice can be permitted by a protocol and still be dangerous at a particular layer or scale because other software has come to rely on a stable convention. The IAB highlighted implicit assumptions, cross-application effects and the need for informed consent.

In governance terms, it reframed the burden: the operator proposing a high-level change should demonstrate that it will not impose unreasonable external costs, rather than requiring every affected party to prove harm after deployment.

SSAC’s longer investigation assembled reports, public meetings and technical observations. Its record included the October 2003 public forum and hearing sequence, comments from operators and users, and examination of mail, privacy, error handling and mitigation. The report found that Site Finder changed the meaning of negative responses and forced some outside systems to adapt. It also recognised evidentiary limits. The magnitude of effects could not be reduced to one reliable number, the record did not demonstrate every predicted effect at measurable scale, and some workarounds reduced immediate disruption.

Those qualifications strengthen rather than weaken the institutional lesson. A pre-launch process is most valuable when consequences are uncertain, distributed and difficult to measure—not only when catastrophe is already proved.

VeriSign’s August 2004 response to SSAC contested the report’s methods and conclusions. It argued that SSAC had not quantified alleged harm adequately, had discounted VeriSign’s testing and had approached the service with a predisposition against it. Those objections did not give VeriSign a veto over the advisory record, just as SSAC’s report did not give SSAC power to enforce a rollback. They did, however, prevent the record from being treated as a technical consensus free of institutional conflict. The dispute concerned who defined adequate evidence, when outsiders could inspect it, and what level of uncertainty justified intervention.

The ICANN Board’s 23 July 2004 resolutions converted that advisory work into a policy direction, though not yet the later preclearance machinery. The Board cautioned against additional wildcard deployments pending clarification and supported deliberate notice, review, community discussion and consensus-building for material registry-service changes. The resolutions demonstrated decision power: the Board could adopt an institutional position and direct policy work. They did not themselves supply the complete request form, screening clock, expert-panel rules or decision standard that would later define RSEP.

This allocation of roles is easy to blur because all the actors appeared in the same public controversy. Participation gave registrars, engineers, users, companies and governments an opportunity to place evidence in the record. Expertise gave the IAB and SSAC influence over how risk was understood. The policy-development process gave the GNSO a formal route to recommend generally applicable rules. Board authority gave ICANN the capacity to adopt those rules. Contractual and operational control determined whether a particular service could be deployed or removed.

The later system was built by connecting these roles without pretending they were equal.

Litigation supplied review access, not a Site Finder merits judgment

VeriSign did not accept ICANN’s 2003 intervention as the final legal word. In February 2004 it filed a federal complaint alleging antitrust violations and asserting contract and related state-law claims. Site Finder formed part of a broader dispute over ICANN’s treatment of proposed services and contractual authority. VeriSign sought declaratory and injunctive relief, specific performance and damages. Its pleading alleged that ICANN had lacked a proper basis for the suspension ultimatum and that Site Finder was contractually permissible and technically sound. Those propositions were claims presented to a court, not findings made by one.

The August 2004 federal order did not decide that Site Finder breached the registry agreements. It dismissed the federal antitrust claim with prejudice and dismissed the remaining state-law claims without prejudice after declining supplemental jurisdiction, leaving those claims available for pursuit in another forum. That disposition narrowed the forum and changed litigation leverage, but it did not transform ICANN’s October 2003 contract theories into adjudicated facts.

The dispute then spread across related proceedings. ICANN’s official litigation index records the federal action, an appeal, California state proceedings and an International Chamber of Commerce arbitration track. The chain matters because the availability of several forums can look like extensive accountability. Yet multiple routes do not guarantee a merits remedy. Jurisdictional dismissal, refiling, appeal, arbitration and settlement may close a dispute without a tribunal ever determining the specific contract question that prompted it.

That is what the located terminal documents show here. The California action was dismissed with prejudice in December 2006 after settlement, and the Ninth Circuit dismissed the appeal later that month on the parties’ stipulation. ICANN’s February 2006 settlement announcement linked resolution of the wider disputes to a new .COM agreement, subject at that stage to United States Department of Commerce approval. The accessible orders establish closure. They do not establish a final judicial ruling that the 2001 agreements prohibited Site Finder, an award of damages tied to the 2003 suspension, or a permanent injunction against the service.

This is the difference between review access and remedy. VeriSign could plead, appeal, arbitrate and negotiate. Those avenues increased its capacity to resist, seek relief and negotiate a broader settlement. But the immediate service had already been suspended. The located record contains no later merits judgment restoring it or compensating the suspension on a Site Finder-specific theory. Conversely, ICANN did not obtain a final judgment validating every theory in its demand.

The legal ambiguity remained bounded by an operational fact: Site Finder was off, and the parties had incentives to replace future emergency disputes with a more predictable process.

The final settlement instruments and the complete arbitral termination record would be necessary before making precise claims about admissions, releases or the disposition of every Site Finder-related theory. The located sources do not support those stronger propositions. They support a narrower conclusion: litigation was consequential as leverage and as a forum for challenge, but the institutional legacy emerged principally through negotiated contracts and policy rather than a final judicial doctrine.

From an emergency response to a policy-development process

The Generic Names Supporting Organization’s work transformed the controversy from a bilateral fight into a general question: how should ICANN evaluate changes to registry services before deployment? The GNSO process was broader than Site Finder. Registries differed in size, services and technical architecture; many proposed changes were routine; confidentiality could be commercially important; and delay could deter beneficial innovation. A policy written as a disguised permanent punishment for one operator would have been difficult to justify as a generally applicable consensus rule.

The GNSO final report on approval of changes to registry services, dated 30 June 2005, designed a tiered process. It favoured an initial, rapid review for most requests rather than automatic Board proceedings. It addressed the information a registry should provide, the treatment of confidential material, the criteria for security, stability and competition concerns, third-party technical review, public comment, decision clocks and accountability. The report recognised that most proposed services were likely to be straightforward and should not require public or expert escalation.

The design redistributed burdens without making ICANN a product manager. A registry would have to describe the service from the perspective of external users, explain its purpose and identify reasonably foreseeable external effects. ICANN staff would conduct a preliminary screen within a specified period. A finding that no significant security, stability or competition issue appeared would permit deployment. A competition concern would be referred to the appropriate governmental competition authority, with a temporary standstill.

A significant security or stability concern would go to independent technical evaluation and public comment, followed by a Board decision.

Each gate reflected a different form of authority. Staff could classify and screen; it was not intended to replace competition regulators or make the final decision in a referred security case. Technical experts could analyse risk; their report would inform but not legally substitute for the Board’s decision. Public commenters could add evidence, identify affected systems and contest assumptions; they did not vote on approval. Competition authorities could investigate under their own legal powers; ICANN’s process did not manufacture those powers. The Board could decide whether the defined risk threshold barred the service under the policy.

A registry retained the operational capacity to deploy only after the process allowed it to do so.

The report also confronted confidentiality. A registry may have legitimate reasons not to disclose source code, commercial plans or security-sensitive implementation details to the world. Yet secrecy can deprive affected parties of the ability to identify external effects. The process therefore separated information that could receive confidential treatment from the basic purpose and user-facing impact of a proposed service. This was not perfect transparency. It was an institutional compromise: enough disclosure to test public consequences, with bounded protection for material not necessary to public understanding.

Timing was equally important. An unbounded review would allow ICANN to suppress innovation through delay even without a formal refusal. A purely voluntary deadline would not discipline staff. The emerging procedure used clocks: an initial review period, a defined competition standstill, a deadline for expert analysis and a period for Board action. Time limits do not make a process fair by themselves, but they convert delay into an observable institutional performance measure. They also make the cost of escalation more predictable for the registry.

Accountability remained narrower than approval. The GNSO record discussed reconsideration and wider review mechanisms, but reconsideration did not promise a fresh technical merits hearing whenever a registry disagreed. The contemporary policy record described defined grounds such as a staff action inconsistent with established policy or a Board action taken without material information. That route could correct a recognised institutional failure; it did not automatically authorise a service, award damages, or substitute for a competition authority, expert panel or Board decision. The applicable Bylaws remained the authoritative source, so the policy summary should not be treated as a complete statement of every accountability power available at the time—or now.

The GNSO’s role itself illustrates participation without ultimate control. Constituencies, registries, registrars and other participants supplied evidence and negotiated recommendations. The Council could approve a policy recommendation through the procedures assigned to it. The Board still had to adopt a consensus policy and direct implementation. The contracts then had to make that discipline enforceable against particular operators where applicable. Policy development was an indispensable stage, but it did not itself remove or add a line in a registry zone.

Contractualising preclearance in .NET and .COM

The first durable machinery appeared through more than one route. The 2005 .NET Registry Agreement incorporated a negotiated registry-services review structure. It required advance notice and sufficient information, provided for a preliminary determination, distinguished competition concerns from security or stability concerns, and created escalation paths. Its definitions and confidentiality treatment became an important implementation model. This was a contract applying to one registry relationship, not yet by itself a universally applicable consensus policy.

On 8 November 2005, the ICANN Board adopted the registry-services procedure as a consensus policy after the GNSO Council’s unanimous recommendation. The Board directed that implementation be guided by the .NET agreement’s definitions and confidentiality provisions. This was a distinct legal step. Negotiated terms in .NET had demonstrated a workable model; the Board’s decision gave the procedure the status and reach of consensus policy under the relevant contracts. It would be inaccurate to treat either step as merely duplicating the other.

An SEC-filed copy of the 2006 .COM Registry Agreement shows the review discipline embedded in the relationship at the centre of the Site Finder dispute. It defined registry services broadly enough to include services only a registry operator could provide and material changes to approved services. It required written notification and sufficient information for ICANN to make a preliminary determination, while preventing the service’s purpose and effect on DNS users from being hidden as confidential. It set out the initial screen, competition referral and security-or-stability review.

The security pathway used a standing technical panel from which a smaller group could be selected for a particular request, subject to conflict restrictions. The panel analysed whether the proposed service created a significant risk to security or stability. Public comment supplemented that analysis. The Board then applied the policy’s decision standard. If it found a reasonable risk of a meaningful adverse effect, the registry was not to offer the service. The technical panel’s role was influential but non-binding; the enforceable “do not offer” outcome followed from the Board decision under the contractual and policy framework.

The .COM text also preserved the unresolved history with unusual specificity. Its traffic-data provision stated that it did not constitute consent or acquiescence to the reintroduction of Site Finder or a substantially similar universal wildcard service. That clause was not a general judicial holding that all such services were unlawful. It was a contractual reservation preventing another provision from being used as implied permission. It demonstrates how settlement-era drafting can contain a conflict without adjudicating it: the parties define what cannot be inferred, then channel any future proposal through a different process.

It would still overstate the evidence to say Site Finder alone caused every element of the 2005 and 2006 arrangements. The GNSO process addressed wider registry-community concerns, and the .NET and .COM provisions emerged from separate contracting tracks. Site Finder was the catalytic demonstration of the launch-first problem: a registry-level change, contested external effects, incomplete advance review, an emergency demand and litigation. The eventual safeguards also reflected broader interests in innovation, confidentiality, competition and predictable administration. The institutional lineage is strong; exclusive causation is not.

RSEP: changing the sequence of action

The Registry Services Evaluation Policy was posted on 25 July 2006 and took effect on 15 August. It operationalised the consensus decision as a repeatable administrative process. The later announcement of the Registry Services Technical Evaluation Panel and Registry Request Service recorded that the secure request system became live on 22 August and was publicly announced on 30 August. Those dates should not be collapsed: posting, effective date and administrative launch were separate stages.

A proposed service under RSEP moves through a series of gates.

First, the registry must notify ICANN and provide enough information to permit an informed preliminary determination. The description must address the service’s purpose and reasonably foreseeable effects on users and the DNS. The registry may consult staff before formal submission, and some information may receive confidential treatment, but user-facing purpose and impact cannot disappear behind a commercial-confidentiality label. The request is inside an existing registry agreement; filing it does not reopen the operator’s application for the top-level domain or create a new delegation proceeding.

Second, ICANN staff conducts a preliminary review, generally within 15 calendar days after receiving sufficient information. If staff finds no significant security, stability or competition issue, the registry is free to deploy, subject to its other contractual obligations. This is the fast path. It preserves room for routine innovation and prevents every change from becoming a Board case. “No significant issue identified” is not a certification that the service can never cause harm; it is the policy’s threshold determination on the record presented.

Third, a significant competition concern is referred to the appropriate governmental competition authority or authorities. The registry generally must not deploy for 45 days after the referral unless the authority indicates sooner that the service may proceed. ICANN does not become a competition court. Its power at this stage is to identify the issue, refer it and enforce the temporary contractual standstill. The external authority’s own legal powers and procedures govern the competition inquiry.

Fourth, a significant security or stability concern is referred to the Registry Services Technical Evaluation Panel. The panel examines the proposal, and public comment allows affected parties to add evidence. The panel has 45 calendar days to report. Its analysis is not a veto. After receiving the report, the Board has 30 calendar days to decide whether the proposed service creates a reasonable risk of a meaningful adverse effect on security or stability. A negative Board determination produces the enforceable prospective result: the registry must not offer the service.

Fifth, the policy points an affected registry operator or sponsoring organisation to the existing Bylaws reconsideration process. In the 2006 policy text, that route was described in terms of staff action contradicting ICANN policy or Board action taken without material information. Review access does not erase the allocation of decision power: reconsideration is not automatic product approval, a damages proceeding, a fresh expert panel, or a substitute for the Board’s security determination. Nor does it amend the registry agreement, transfer the registry or alter the root.

The policy therefore changed not just who spoke, but when the operator was entitled to act. In 2003, VeriSign launched and others had to build the record under operational pressure. Under RSEP, the registry carries an initial burden of description and external-impact analysis before deployment. Staff must identify whether escalation criteria are met. Experts and commenters can test the proposal before dependencies are disrupted. The Board can prohibit deployment under a stated threshold.

The operator retains the technical switch, but for a service within RSEP’s scope the contractual and policy framework removes the entitlement to use it first and argue later.

A short implementation coda: search.travel

The value of a procedure is clearest when it changes an operational outcome before launch. In 2006, Tralliance proposed a wildcard-based service for .travel that would direct otherwise non-resolving queries towards search.travel. The RSTEP technical evaluation did not treat the proposal as identical to Site Finder, nor did it say wildcard code was inherently impossible. It found that Tralliance could implement the proposed service and that the test plan and prior art appeared adequate for that purpose, but concluded that the service presented a reasonable risk of a meaningful adverse effect because a registry-level wildcard could affect present and future DNS-dependent applications and could not be confined to web browsing.

On 22 November 2006, after considering the RSTEP report, SSAC and At-Large input and other public comments, the ICANN Board directed staff to inform Tralliance that the proposal was not approved. The significance is procedural rather than analogical. Unlike Site Finder, the .travel proposal reached technical and Board scrutiny before registry-wide deployment. The expert panel supplied analysis; commenters supplied evidence; the Board exercised decision power; the registry did not first create a production fact and force outsiders to seek rollback.

What the case establishes—and what it leaves unresolved

The primary record supports a bounded conclusion. VeriSign controlled the authoritative implementation and removed Site Finder. ICANN used contractual leverage and a deadline to obtain that removal, but the located documents do not establish that ICANN had a separate technical kill switch. The IAB and SSAC built a technically serious record while lacking enforcement power. VeriSign disputed both the evidence and the contract interpretation and preserved its legal claims. Litigation gave the parties review forums and settlement leverage but produced no located final Site Finder merits judgment.

The prospective discipline became enforceable through negotiated agreements and consensus policy.

Several factual gaps remain material. The accessible record does not fully establish which detailed test artefacts, traffic data and external-impact analyses VeriSign supplied before launch, what ICANN received at each point, or what outsiders could independently reproduce. The final executed settlement instruments and complete arbitral termination record would be needed to describe admissions, releases or every disposed claim precisely.

ICANN’s February 2006 announcement establishes that finalisation of the settlement package then depended on United States Department of Commerce approval; it does not, by itself, establish the later approval date. The located material also does not establish whether VeriSign later submitted Site Finder or a substantially similar service through RSEP. Suspension in October 2003 should therefore not be rewritten as proof of permanent abandonment.

Those limits do not weaken the central institutional finding. Site Finder’s legacy was a change in the burden and order of decision. The operator no longer received the benefit of launching a material registry service first and asking everyone else to prove the problem afterward. ICANN no longer had to rely only on an improvised emergency demand assembled after production behaviour changed.

The later process required a service to become a reviewable object before deployment: described, screened, referred where necessary, tested by independent expertise and public evidence, and finally permitted or withheld by the actor assigned decision power.

That is a narrower achievement than a complete settlement of the underlying law. RSEP did not decide every question about DNS wildcards. It did not make ICANN the operator of .COM or .NET. It did not convert commenters into voters, advisers into enforcers, reconsideration into damages, or a service request into an application for a top-level domain. It did something more practical. It converted a disputed technical intervention from an accomplished fact into a proposed act that had to pass institutional gates before the switch was used.