Summary

  • Booking.com B.V. did not obtain .HOTELS by winning one all-purpose case. ICANN’s initial visual review placed .HOTELS in contention with .HOTEIS; a separate string-confusion expert declined to add .HOTEL; two community-objection determinations declined to stop the application; reconsideration and independent review did not remove the .HOTEIS block; an auction selected Booking.com within that remaining contention set; and a later Registry Agreement, pre-delegation testing and root-zone processing supplied the authority that the earlier decisions could not.
  • The apparent inconsistency—.HOTELS was close enough to .HOTEIS for contention but not close enough to .HOTEL in a later objection—is a product of segmented power. The first panel conducted a visual screening exercise without adversarial submissions. The .HOTEL proceeding placed the burden on an objector in a party-led evidentiary process. Community objectors had standing and proved substantial opposition, but not the required likelihood of material detriment. Accountability bodies could test recognised process, policy, Articles or Bylaws grounds, yet they did not automatically rehear the underlying merits. At every stage, the operative question was not merely who had been heard, but which institution could alter the application’s executable status.

Two records, two outcomes, one mistaken question

On 26 February 2013, ICANN published the results of the new-gTLD String Similarity Review. Most of the contention sets were exact matches. Only two published sets were non-exact: .UNICORN/.UNICOM and .HOTELS/.HOTEIS. That publication did more than express an expert view about resemblance. It created a programme status. Booking.com’s application for .HOTELS and Travel Reservations SRL’s application for .HOTEIS could not both proceed to delegation unless the contention was resolved.

Less than six months later, on 8 August 2013, a sole expert in a separate string-confusion objection dismissed the .HOTEL applicant’s challenge to .HOTELS. The expert accepted that the words “hotel” and “hotels” were similar, but found the evidentiary support limited public evidence to establish probable confusion in the mind of the average, reasonable Internet user. For that proceeding, the strings were sufficiently different visually and aurally. Booking.com prevailed.

Placed side by side, those outcomes tempt a simple accusation: ICANN treated the less obvious pair, .HOTELS and .HOTEIS, as confusing, while allowing the singular and plural pair, .HOTEL and .HOTELS, to remain outside direct contention. Several ICANN directors themselves expressed discomfort. But the useful governance question is not which panel was “right” in the abstract. It is what each panel was authorised to decide, on what record, under what burden, and with what effect.

The initial review was a visual screen embedded in evaluation. Its designated consequence was the creation of a contention set. The later .HOTEL case was an adversarial objection. Its consequence, had the objector succeeded, would have been to add a direct contention relationship between .HOTEL and .HOTELS. Its dismissal meant that no such relationship was added. Under the Applicant Guidebook, a string-confusion objection could augment the preliminary contention structure, but it could not remove an application from a contention set already created by the initial review. The .HOTEL decision therefore had no jurisdictional route to dissolve the .HOTELS/.HOTEIS block.

That distinction is the organising fact of the case. Similar vocabulary—confusion, similarity, the reasonable Internet user—did not produce a single appellate ladder. It produced several bounded proceedings. A victory in one did not erase a loss in another. A review body’s criticism did not itself alter the application. An auction win did not itself create a registry. Contracting did not itself place the string in the root. The history becomes coherent only when each decision is tied to the status switch it controlled.

The application was a sequence, not a referendum

The 2012 Applicant Guidebook organised the round as a gated process. Applications passed through administrative checks, initial evaluation, objections and dispute resolution where applicable, contention resolution where applicable, contracting, pre-delegation testing and finally the steps required for entry into the root zone. Each stage narrowed the set of applications eligible to reach the next. None of the early stages conferred an unconditional right to operate a top-level domain.

That design matters because public discussion often collapses different programme verbs into one: approved, passed, won, contracted, delegated. They are not synonyms. An application may pass financial and technical evaluation while remaining blocked by string contention. It may defeat an objection while still facing another objection. It may prevail in contention but remain ineligible to contract. It may sign a Registry Agreement but still need technical testing and root-zone processing. The application-status record for 1-1016-75482 eventually displays all of those layers in compressed form: Booking.com as applicant, a passed Initial Evaluation, three objection victories, a resolved contention result, a Registry Agreement link and a delegated status. The page is a useful endpoint, but it does not explain how one status became another.

The 10 May 2013 Initial Evaluation report makes the separation unusually clear. Booking.com passed Initial Evaluation. Its background screening, DNS stability, geographic-name, registry-services, technical-and-operational and financial reviews all passed. Yet the same report described the string result as “Pass - Contention”. The application was eligible to continue, but it was not free to proceed to delegation. A pass and a block existed in the same document because they answered different questions.

Five types of status therefore have to be kept separate throughout this case.

Evaluation status concerned whether the application and applicant met the programme’s screening, technical, operational and financial criteria. Objection status concerned whether a particular authorised objector had proved one of the Guidebook’s defined grounds. Contention status concerned whether multiple applications could coexist or whether one had to survive. Accountability status concerned whether ICANN or its agents had acted inconsistently with recognised policy, procedure, Articles or Bylaws. Operational status concerned whether a contracted registry operator had passed the final technical and root-zone gates.

Applicants and objectors participated at several points. They filed applications, objections, evidence, responses, reconsideration requests and an independent-review claim. Their participation could shape the record and trigger institutional action. It did not give them a vote over the evaluator’s conclusion, a right to a merits appeal where none was provided, the power to direct the Board, or the authority to alter the root zone. Control remained distributed among evaluators, dispute-resolution experts, ICANN’s accountability bodies, the Board, the auction process, ICANN’s contracting function and the IANA functions.

This was not accidental administrative clutter. The programme attempted to protect several different interests at once: avoiding confusingly similar root labels, allowing objections by affected parties, maintaining predictable evaluation, resolving mutually exclusive applications, imposing enforceable registry obligations and preserving technical stability at delegation. The cost was institutional fragmentation. A party could obtain a hearing without obtaining the remedy it wanted, expose a design weakness without reversing the result, or win a proceeding whose legal effect was narrower than its public significance.

The visual review made .HOTEIS an executable block

The initial String Similarity Review was deliberately narrow. The Guidebook described it as a preliminary comparison focused on visual similarity. An independent panel was to identify visual resemblances that created a probability of user confusion. The standard required probable, not merely possible, confusion in the mind of the average, reasonable Internet user; mere association was limited public evidence. The panel could use an algorithmic measure as one input, but its final determination remained a matter of panel judgement.

The outcome architecture was more important than the label “preliminary”. If an applied-for string was too similar to another applied-for string, both applications entered a contention set. ICANN would notify the applicants and publish the result. The applicants could later resolve contention privately, or the programme could move towards its prescribed resolution mechanisms. The panel did not select a winner. It created a mutual disability: the two applications could not both move forward to delegation while the contention relationship remained.

The 26 February announcement therefore changed Booking.com’s practical position immediately. Before publication, .HOTELS was an application under evaluation. After publication, it was an application whose path was linked to .HOTEIS. The two applicants could negotiate; one could withdraw; or they could reach the programme’s last-resort auction. What Booking.com could not do was treat its own successful technical or financial evaluation as a substitute for resolving the other application.

The later Initial Evaluation report preserved that status rather than curing it. “Pass - Contention” meant that the panel had not rejected .HOTELS as too similar to an existing TLD or reserved name. Instead, it had found .HOTELS visually similar to another applied-for string. Booking.com remained alive in the programme, but so did the contention obligation. That is why the initial result was neither a rejection nor a mere advisory comment. It was a binding input into the programme’s state machine.

The process also sharply limited applicant participation at the moment the status was created. Unlike some other evaluation components, the visual review did not provide a point for applicants to submit linguistic evidence or answer clarifying questions about confusion. It did not promise an individual reasoned determination explaining why a particular pair crossed the threshold. It did not provide a merits appeal from the panel. Those absences later became central to Booking.com’s accountability challenges.

They did not, however, prove that the published procedure had been violated. That distinction would determine the fate of Reconsideration Request 13-5. A procedure can be thin, and even institutionally unsatisfactory, while still being followed. Reconsideration was designed to test departures from recognised policy or process, not automatically to supply procedural rights omitted from the programme design.

There is also an evidentiary caution. The BGC recommendation discussed historical methodology materials, including an algorithmic input. The source set used here does not independently preserve and validate every underlying tool, quality-assurance file or contemporaneous calculation. The defensible claim is narrower: the Guidebook made any algorithm indicative rather than determinative; the panel’s published outcome placed the strings in contention; and ICANN’s later decisions treated that outcome as operative. The case does not require an unverified numerical score to explain the allocation of power.

The asymmetry was substantial. A short published result could impose years of procedural and financial consequences. Yet the evaluator did not own those later consequences. It could create contention, not resolve it; it could not sign a Registry Agreement, conduct an auction or direct a root-zone change. High-impact initial authority was paired with narrow subject-matter jurisdiction.

The .HOTEL objection could add contention, not subtract it

The .HOTEL applicant, Hotel Top-Level-Domain S.a.r.l., used a different route. A string-confusion objection was available to an existing TLD operator or another applicant in the same round where the challenged string was alleged to be confusingly similar. Because .HOTEL and .HOTELS had not been placed in the same contention set by the initial review, the .HOTEL applicant had standing to ask a dispute-resolution expert to create that relationship.

The ICDR determination records an adversarial process. The objector filed its objection on 13 March 2013. Booking.com responded on 16 May with attachments. The objector bore the burden of proof. The sole expert considered the parties’ submissions and the evidentiary record rather than conducting the same non-adversarial screen used in Initial Evaluation.

The governing language still demanded probable, not merely possible, confusion. But the institutional task was different in three important respects. First, the case was initiated by an objector seeking a defined remedy. Secondly, the objector had to carry the burden on a party-built record. Thirdly, the expert could consider more than the initial panel’s visual screen; the determination addressed visual and aural difference and expressly declined to decide allegations about business motives, competition, detriment and the separate community objections because those matters were outside the assigned task.

The expert found that the objector had not supplied sufficient factual or expert support to establish probable confusion. The singular and plural strings were similar and one might bring the other to mind, but association alone did not meet the standard. The expert found .HOTEL and .HOTELS sufficiently different visually and aurally for string-confusion purposes. The objection was dismissed and Booking.com prevailed.

The status consequence was precise. Had the objection succeeded, .HOTEL and .HOTELS would have entered direct contention, changing the geometry of the relevant contention structure. Because it failed, no direct contention relationship was added. The decision did not affirmatively license both strings, award .HOTELS to Booking.com, invalidate objections on other grounds, or revisit the already established .HOTELS/.HOTEIS set.

This is where the Guidebook’s rule against subtractive objections becomes decisive. The programme said that a string-confusion objection could change preliminary contention sets by adding a relationship, but an objection outcome would not remove an application from a previously established set. The .HOTEL expert therefore had no procedural power to say: because .HOTEL and .HOTELS are not confusing in this case, the separate .HOTELS/.HOTEIS visual result must be wrong. That would have converted a bounded objection into an appeal from another panel.

The .HOTEL applicant tried an accountability route after losing. In Reconsideration Request 13-6, it asked ICANN to disregard the expert determination and provide a new panel or de novo rehearing. On 5 November 2013, the New gTLD Program Committee denied the request. The committee’s rationale repeated the structural limit: reconsideration could address a recognised process or policy failure, but it was not a mechanism for retrying the merits of a dispute-resolution expert’s decision.

The result is not that the two panels applied an identical method badly. The initial panel and the ICDR expert occupied different institutional positions. One screened every applied-for string visually and created preliminary contention. The other decided a bilateral objection on a party-supplied record and could add a direct contention relationship. Their conclusions looked inconsistent only after their jurisdictions and remedies were stripped away.

For Booking.com, the practical ledger after 8 August was mixed but intelligible. One possible new blocker had failed: .HOTEL did not join the contention structure through that objection. The old blocker remained: .HOTEIS still stood between .HOTELS and delegation. Winning against .HOTEL was valuable, but it was not curative.

Community opposition had standing but not the final element

The two community objections tested a third question. They were not claims that .HOTELS looked too much like another string. They alleged that there was substantial opposition from the hotel community and that Booking.com’s application met the Guidebook’s requirements for a successful community objection.

The proceedings were administered by the International Chamber of Commerce’s International Centre for Expertise. The Hotel Consumer Protection Coalition and HOTREC brought separate objections. They were consolidated for administration, but the expert issued separate determinations. That separation matters because each objector had to establish its own standing and carry its own burden, even though the disputes concerned the same application and overlapped in evidence.

Under the Guidebook, standing was not the merits. An objector had to be an established institution with an ongoing relationship to a clearly delineated community strongly associated with the string. Once standing was established, four cumulative merits elements had to be proved: a clearly delineated community; substantial community opposition; a strong association between the community and the string; and a likelihood of material detriment to the rights or legitimate interests of a significant portion of that community.

The Hotel Consumer Protection Coalition determination shows why cumulative tests allocate power differently from a general measure of opposition. The expert found standing. She also found a clearly delineated hotel community, substantial opposition and a strong association with .HOTELS. Those findings recognised the objector and the breadth of concern. They did not give the objector a veto. The objection failed because the evidence did not establish the required likelihood of material detriment to a significant portion of the community.

The determination discussed Booking.com’s proposal, as presented in the then-current record, to operate .HOTELS as a closed gTLD. It also considered changes to the draft Registry Agreement that cast doubt on whether such exclusive operation would be permitted. Even assuming a closed model were allowed, the expert found the claimed harm insufficiently demonstrated. Assertions that community members would incur additional expense or lose a desirable namespace did not establish the required level and likelihood of detriment.

The objector’s own interests could not simply be treated as synonymous with the rights or legitimate interests of the whole community.

The HOTREC determination reached the same terminal result through its own record. HOTREC had standing, and the evidence demonstrated substantial opposition and a strong association between the hotel community and .HOTELS. Yet the material-detriment case remained speculative. The expert noted that allegations about consumer harm, monopoly, redirection and exclusion were not supported by evidence sufficient to prove likely detriment to a significant portion of the hotel community. A focus on possible consumer harm did not automatically satisfy a test framed around community rights and legitimate interests.

The distinction is institutionally important. Public comments, industry letters and organisational support can demonstrate participation, recognition and opposition. They do not necessarily prove the final legal or contractual element required for a binding result. In both proceedings, the objectors were heard and several of their threshold propositions were accepted. They still lost because the test was conjunctive: failure on material detriment defeated the objection.

The remedy was also binary and bounded. The dispute-resolution procedure limited the expert to sustaining or dismissing the objection, along with the prescribed allocation or refund of costs. The expert could not redesign Booking.com’s application, impose a negotiated access regime, transfer .HOTELS to a hotel association or dissolve the .HOTEIS contention set. Had either objection been sustained, Booking.com’s application could not have continued. Because both were dismissed on 19 November 2013, those particular barriers fell away. The contention barrier did not.

This is another example of why “Booking.com won” is too imprecise. It won enough to prevent rejection on two community-objection records. It did not win freedom from contention, a contract or delegation. The community determinations changed the application’s status only by declining to terminate it on the grounds before them.

The 2013 determinations also impose a boundary on later historical claims. They are evidence of what the expert understood Booking.com’s proposal and the draft contractual environment to be at that time. They are not, without version comparison, a complete account of the original 2012 application, every subsequent application amendment or the registry’s eventual operating model. The public application copy available now may reflect later changes. Any assertion about Booking.com’s original design must therefore remain attributed to the contemporaneous determination unless the relevant application versions are separately preserved and compared.

Reconsideration tested compliance with the published process, not the visual merits

Booking.com’s first accountability move was Reconsideration Request 13-5. It asked ICANN to reverse the .HOTELS/.HOTEIS contention finding or, at minimum, to provide a detailed explanation and an opportunity to respond before the result became final. The request translated a substantive disagreement—Booking.com did not accept that the two strings were probably confusing—into an institutional claim: a high-impact determination had been made without applicant submissions, an individual rationale or a merits appeal.

The Board Governance Committee did not treat those concerns as irrelevant. It treated them as limited public evidence for the remedy sought. Under the reconsideration framework then in force, the relevant question was whether staff or Board action contradicted an established ICANN policy or procedure, or whether material information had been ignored in a way recognised by that framework. It was not whether the committee would have reached the same visual-similarity conclusion on a fresh record.

That distinction controlled the recommendation. The committee found that the String Similarity Review had been conducted through the process established for the programme. The Guidebook did not provide an applicant-comment stage within that review, require a narrative determination for every comparison or create a substantive appeal from the expert result. The absence of those safeguards could be criticised as a design choice. It was not, without more, proof that the designated process had been breached. The BGC therefore recommended denial.

On 10 September 2013, the New gTLD Program Committee adopted that recommendation through Resolution 2013.09.10.NG02. The vote itself reveals more institutional discomfort than the bare outcome. Five members voted in favour; four abstained; two were unavailable. Statements recorded in the minutes questioned the lack of a reasoned similarity determination and the absence of an appeal or remand mechanism. Those concerns did not become operative relief. The resolution left the contention set intact.

The episode exposes the difference between formal compliance and institutional legitimacy. ICANN could be correct that it had followed the process it announced and still face a credible concern that the process gave too little explanation for a decision with substantial economic consequences. Reconsideration was capable of policing an established rule. It was not automatically capable of improving a rule after the fact. The applicants’ access to an accountability mechanism therefore produced a record, reasons and internal debate, but no change in executable status.

That is not an empty distinction. A process-review mechanism can deter arbitrary departures, compel an institution to identify its authority and preserve an administrative record. But it should not be described as an appeal unless it can do the work of an appeal. Booking.com could request reconsideration; it could not require the committee to compare .HOTELS and .HOTEIS again on the merits. The committee could recommend that the Board undo an action if a recognised procedural defect were shown; it did not have to substitute its own linguistic judgement for that of the panel merely because the result was contested.

The same structural limit appeared when the .HOTEL applicant challenged its loss in Reconsideration Request 13-6. There, too, the losing party sought a fresh or replacement merits decision. The 5 November 2013 resolution refused to convert reconsideration into de novo dispute resolution. The symmetry is useful: reconsideration did not favour the initial evaluator over the objection expert as such. It protected the finality of both expert processes unless the requester could establish the type of policy or procedural failure that the accountability mechanism was authorised to remedy.

By the end of 2013, Booking.com had therefore defeated three objections and lost one reconsideration request. That combination did not amount to an overall score. The three objection dismissals prevented three possible application failures. The reconsideration denial preserved one existing contention relationship. The application remained viable, evaluated and objection-cleared, but unable to advance until .HOTEIS was removed or the contention was otherwise resolved.

Independent review identified a fairness problem without ordering a reversal

Booking.com next used the Independent Review Process. That route was institutionally more serious than reconsideration, but it was still not an unrestricted merits appeal from the String Similarity Review. The IRP panel’s task was to determine whether ICANN’s challenged conduct was consistent with its Articles of Incorporation and Bylaws under the standards then applicable. Its authority and remedy had to be derived from those governing instruments, not from a general power to choose the better linguistic answer.

The Final Declaration signed on 3 March 2015 rejected Booking.com’s request for relief. The panel concluded that ICANN had followed the process established for the visual review and had not acted inconsistently with the relevant Articles, Bylaws or Guidebook provisions. To the extent Booking.com challenged the design of the process itself rather than its application in this case, the panel treated the claim as untimely. It also declined to substitute its own judgement for the expert panel’s string comparison.

Yet the declaration did not read like an endorsement of every feature of the review. It acknowledged legitimate transparency and fairness concerns arising from a process that permitted no applicant submissions, produced no reasoned determination for the pair and offered no merits appeal. The panel encouraged institutional attention to those concerns and discussed the Board’s residual ability, under the programme’s exceptional-circumstances provision, to consider whether further action was warranted.

Those observations mattered, but not in the way a reversal would have mattered. The panel denied Booking.com’s requested relief, identified ICANN as the prevailing party and allocated the IRP costs equally. It did not order the .HOTELS/.HOTEIS contention set dissolved. It did not direct a new visual review. It did not place the applications into separate processing tracks. It did not instruct IANA to treat either string as delegation-ready.

The difference between a finding, a recommendation and an operative order is central to accountability analysis. An institution can acknowledge that a process is difficult to defend prospectively while concluding that the particular result must stand under the governing standard. An accountability body can generate pressure for reform without supplying a case-specific remedy. A claimant can expose a legitimacy deficit and still lose.

Booking.com’s IRP therefore expanded transparency more than it changed allocation. The proceeding assembled the arguments, required ICANN to defend the architecture and produced a public declaration identifying the design problem. It supplied review access. It did not supply a merits rehearing or an enforceable command to remove the application’s block.

That limit also explains why the Board’s later action cannot be attributed to the IRP panel. The declaration left room for the Board to exercise its own authority. It did not compel a particular exercise. The ultimate decision to resume programme processing belonged to the Board, and the legal significance of that decision depended on what “processing” meant within the Guidebook sequence.

The Board moved the contention set forward; it did not declare the strings compatible

On 26 April 2015, the ICANN Board accepted the IRP findings, directed the President and Chief Executive Officer to move forward with processing the .HOTELS/.HOTEIS contention set and referred the panel’s transparency and fairness concerns to the programme’s broader reviews. The three actions were related but legally distinct.

Accepting the IRP declaration closed the accountability proceeding on its stated terms. Referring the concerns to programme review treated them as lessons for institutional design. Directing processing altered the operational posture of the applications: ICANN staff could resume the contention-resolution sequence rather than hold the set pending further Board consideration.

The Board did not find that .HOTELS and .HOTEIS could safely coexist. It did not cancel the similarity result. “Move forward” meant move forward as a contention set. Unless the applicants reached a private resolution, the programme would still require one application to prevail before the other could proceed. The Board’s intervention changed delay into processing, not contention into compatibility.

Booking.com and Travel Reservations SRL then filed Reconsideration Request 15-7 jointly. They argued, among other things, that the Board should use its residual authority to correct the similarity outcome. In the 28 July 2015 decision, the Board denied the request. It stated that the governing instruments supplied no appeal mechanism for challenging the substance of the expert String Similarity Review determination and declined to second-guess the expert result through exceptional discretion.

The vote—nine in favour of denial, one abstention, two against and four unavailable—again showed that preserving the result was a decision, not an inevitability. Some directors favoured a different institutional response. But the adopted resolution, rather than the dissenting view, controlled programme execution. Debate was participation; the Board resolution was decision power.

The Board’s choice also reflected an incentive problem. A broad willingness to reopen expert evaluations could cure an individual anomaly, but it could also invite every disappointed applicant to seek political reconsideration of technical or evaluative outcomes. Refusing to reopen the merits protected predictability and evaluator finality. It imposed the cost of any mistaken or poorly explained initial result on the affected applicants. The governance question was therefore not simply accuracy versus error. It was who should bear the risk of a hard-to-review expert decision in a programme with hundreds of interdependent applications.

By late July 2015, all available accountability routes in this record had failed to remove the .HOTEIS relationship. The application was not rejected. It was not delegated. It was ready for the programme’s contention-resolution machinery.

The auction selected an applicant but did not create registry authority

The Guidebook treated auction as a last resort after evaluation, objection proceedings and any priority processes had run their course. The auction did not decide whether either string was technically acceptable or whether the initial similarity finding had been correct. It allocated the opportunity to continue where the programme had already decided that the applications could not both survive.

ICANN’s 18 November 2015 auction announcement records that two applicants participated in the .HOTELS/.HOTEIS auction and that Booking.com prevailed at a winning price of US$2.2 million. The final auction report identifies Booking.com B.V. and Travel Reservations SRL, records five rounds and repeats the winning amount and date.

The outcome cleared the allocation question in Booking.com’s favour, subject to explicit conditions. Both the announcement and the report warned that the result was contingent on timely payment and the applicant’s continued satisfaction of programme eligibility criteria. They also warned that an auction result did not guarantee a Registry Agreement or delegation. Those caveats were not ceremonial. They marked the boundary between winning a contention mechanism and receiving later institutional authorisations.

The primary record supplied for this case establishes the announced winning price; it does not independently establish payment completion. It is therefore inaccurate to convert “winning price” into an unqualified assertion that Booking.com paid that amount unless a payment or final settlement record is produced. The same restraint applies to the losing application. The auction report establishes that Travel Reservations SRL participated and did not prevail. It is not, by itself, a complete procedural history of the .HOTEIS application’s terminal withdrawal, termination or later administrative status.

Auction shifted control through price. Once other programme routes had failed to remove contention, the party willing and able to remain in the ascending-clock process secured the right to continue. That mechanism was transparent about rounds, entities and price, but it did not evaluate the comparative public value of the proposed registries. Capital resolved a scarcity condition created by the similarity decision.

For Booking.com, the auction converted a mutually exclusive pair into a surviving application. It did not make Booking.com the registry operator in the contractual sense. ICANN still had to conclude that the applicant remained eligible, execute a Registry Agreement and complete the steps required before root-zone delegation. A bidder could therefore win the decisive commercial allocation and still fail to obtain operational authority.

This separation also clarifies the counterfactual. Had Booking.com lost, its victories against .HOTEL, the Hotel Consumer Protection Coalition and HOTREC would not have kept .HOTELS alive. Those decisions removed grounds for rejecting the application; they did not reserve it for Booking.com against the remaining contender. The auction controlled a different switch, and at that switch the earlier wins supplied no fallback entitlement.

Contract and root-zone processing supplied the authority that evaluation could not

On 7 April 2016, ICANN and Booking.com entered a Base, Non-Sponsored Registry Agreement for .HOTELS. Contracting was the point at which programme expectations became enforceable obligations between ICANN and the designated registry operator. The agreement created duties concerning registry services, data, compliance, fees, rights protection and other operational matters according to the instrument’s terms. It also identified Booking.com as the operator for contractual purposes.

The contract still did not, by its own force, insert .HOTELS into the root zone. New-gTLD agreements contemplated subsequent delegation and root-zone approvals. Contractual designation was necessary but not sufficient for operation. The operator still had to satisfy pre-delegation testing and the technical, contact and processing checks required for a delegation request.

ICANN’s String Delegation Readiness Report, dated 14 September 2016, provides a compact institutional audit of the earlier chain. It confirms that the application had passed the relevant applicant and registry evaluations, prevailed in the objections, prevailed in contention, executed a Registry Agreement and passed pre-delegation testing. Its treatment of string similarity is especially revealing: the checklist answered “No” when asked whether the application had been determined not to be confusingly similar to other applied-for strings, then answered “Yes” when asked whether it had prevailed in contention. The initial finding had not disappeared; it had been satisfied through allocation.

The IANA root-zone record identifies Booking.com B.V. as the sponsoring organisation and gives 16 September 2016 as the registration date. That root record is the clearest evidence that the application had become an operationally delegated top-level domain rather than merely a successful application or signed contract.

A later IANA delegation report dated 3 April 2017 records that delegation eligibility had been deemed satisfied, the applicant matched the party to the Registry Agreement and the relevant contact, technical-conformance and processing checks had been completed. The three dates—14 September 2016 readiness confirmation, 16 September 2016 root registration and 3 April 2017 report—must remain distinct. The sources perform different documentary functions, and the available record does not justify collapsing them into a single undifferentiated “delegation date”.

Nor should current fields on the root page be projected backwards. Administrative contacts, technical-provider details, nameserver data and the page’s current update date may have changed after delegation. They prove present or later root-record information, not necessarily the configuration on 16 September 2016. Historical claims require contemporaneous records.

The contractual record has a similar limit. The registry-agreement landing page establishes the operator, agreement type and agreement date. It does not by itself establish that no amendment, authorisation, waiver or compliance action occurred later. Any account of post-contract enforcement would need the executed agreement, string-specific amendments and relevant compliance records. The current case can establish the transition into enforceable registry status without inventing a complete history of subsequent contractual administration.

This was the final conversion of status. Evaluation had determined that the applicant could remain in the programme. Objection dismissals had prevented defined grounds of rejection. Accountability proceedings had tested ICANN conduct without changing the similarity result. The Board had authorised processing to continue. Auction had selected the survivor. Contracting imposed registry obligations. The IANA functions and wider root-zone processing made the authority operational. Only the completed chain explains why Booking.com could sponsor .HOTELS.

The executable status ledger

The case can be reconstructed without treating any institution as omnipotent. Each event changed one state and left the others alone.

Date Institution or instrument Question controlled Executable result for .HOTELS
26 February 2013 String Similarity Review publication Were applied-for strings visually similar enough to require mutual exclusion? .HOTELS and .HOTEIS entered a non-exact-match contention set.
10 May 2013 Initial Evaluation report Did the applicant and application pass the relevant evaluation modules? Passed Initial Evaluation, but retained “Pass - Contention” status.
8 August 2013 ICDR string-confusion expert Had the .HOTEL objector proved probable confusion with .HOTELS? Objection dismissed; .HOTEL was not added to direct contention with .HOTELS.
10 September 2013 New gTLD Program Committee Did Request 13-5 show a reconsiderable policy or procedural violation? Request denied; .HOTELS/.HOTEIS contention remained.
5 November 2013 New gTLD Program Committee Could the .HOTEL objector obtain a de novo rehearing through reconsideration? Request 13-6 denied; ICDR dismissal remained.
19 November 2013 ICC community-objection determinations Had either objector proved all elements, including likely material detriment? Both objections dismissed; the application survived those grounds.
3 March 2015 Independent Review Process panel Was ICANN’s conduct inconsistent with its Articles, Bylaws or the applicable programme rules? Relief denied; fairness concerns recorded without reversal.
26 April 2015 ICANN Board What should follow the IRP declaration? Staff directed to resume processing the contention set; review issues referred prospectively.
28 July 2015 ICANN Board Did Request 15-7 justify merits reconsideration or exceptional intervention? Request denied; expert similarity result preserved.
18 November 2015 ICANN last-resort auction Which applicant could continue from the remaining contention set? Booking.com announced as winner at US$2.2 million, subject to payment and eligibility conditions.
7 April 2016 Registry Agreement Would ICANN recognise Booking.com as contractually bound registry operator? Base, Non-Sponsored Registry Agreement executed.
14 September 2016 ICANN String Delegation Readiness Report Had the application completed the necessary programme, contract and testing gates? ICANN confirmed readiness.
16 September 2016 Root-zone record Was .HOTELS registered in the authoritative root with a sponsoring organisation? Root record registered with Booking.com B.V. as sponsor.
3 April 2017 IANA delegation report Were applicant identity, contract, contacts and technical checks documented as satisfied? Delegation-processing report recorded completion of those checks.

The ledger also identifies what did not happen. The .HOTEL dismissal did not erase .HOTEIS. The community-objection dismissals did not award the string. The IRP’s fairness observations did not constitute a remand. The Board’s processing direction did not resolve contention. The auction did not execute a contract. The contract did not itself alter the root. Those negatives are not semantic refinements; they locate legal and operational control.

What the record leaves bounded

Several propositions remain outside the available proof. The original 2012 public application and each material application-change version have not been preserved and compared here. The 2013 community determinations may be used to describe the proposal as it appeared to the experts, but not as conclusive evidence of every earlier or later operating commitment.

The auction sources establish entities, rounds, date and winning price. They expressly make continuation contingent on payment and eligibility. Without a separate completion record, the article cannot state as fact that the US$2.2 million was paid. Nor can Booking.com’s winning report substitute for a complete terminal record for Travel Reservations SRL’s .HOTEIS application.

The 7 April 2016 registry-agreement record establishes operator, date and agreement type. It does not prove the absence of subsequent amendments, reserved-name authorisations, waivers or compliance notices. The root page establishes the sponsoring organisation and a 16 September 2016 registration date; its current contact and technical details should not be treated as a frozen image of the 2016 configuration.

Finally, the available accountability record supports a conclusion about authority and remedy, not an independent technical verdict on visual similarity. The panel found .HOTELS and .HOTEIS visually similar under its process; the objection expert found the .HOTEL objector had not proved probable confusion on a different record. The sources do not justify reverse-engineering a universal linguistic rule from those two outcomes.

Counterfactuals reveal which gate mattered

Without the initial non-exact-match finding, Booking.com would not have needed to eliminate or outlast the .HOTEIS application. It would still have faced the three objections and the later contract and delegation stages, but the auction described here would not have been necessary unless another contention relationship arose.

Had the .HOTEL string-confusion objection succeeded, .HOTEL and .HOTELS would have entered direct contention. Success would not have awarded .HOTELS to the objector or corrected the .HOTELS/.HOTEIS result. It would have enlarged the set of mutually exclusive claims and made resolution more difficult.

Had either community objection succeeded, Booking.com’s application could not have continued. That is why the material-detriment element had more practical force than the objectors’ standing or proof of substantial opposition. The first three elements described a community and its relationship to the string; the fourth controlled the application’s survival.

Had Booking.com won every objection and accountability challenge but lost the auction, .HOTELS would not have been preserved for it. Had it won the auction but failed a payment, eligibility, contracting, testing or root-zone processing requirement, the auction result would not have produced a delegated registry. Each counterfactual removes one gate while leaving the others intact.

The most revealing alternative concerns review. A merits appeal from the String Similarity Review could have changed the contention architecture before parties incurred years of accountability and auction costs. But such an appeal would also have introduced delay, strategic litigation and pressure for consistency across hundreds of comparisons. ICANN chose finality with bounded process review. The price was that an outcome openly criticised for its lack of reasons remained executable.

Operational authority arrived last

Why, then, did .HOTELS contend with .HOTEIS but not .HOTEL? Because ICANN did not submit all three strings to one tribunal with one record and one remedy. A visual screening panel created the .HOTEIS relationship. An ICDR expert declined to create the .HOTEL relationship. An ICC expert, in two determinations, decided whether opposition and detriment justified stopping the application. Reconsideration and independent review examined recognised accountability grounds without retrying visual similarity. The Board decided whether programme processing should resume. Auction selected the surviving applicant.

Contracting and root-zone administration supplied enforceable and operational authority.

The institutional lesson is not that procedure explains away every questionable result. It is that a result cannot be evaluated accurately without identifying the switch it controlled. Transparency did not guarantee correction. Participation did not confer decision power. Review access did not assure a remedy. Application success did not equal a contract, and a contract did not equal delegation. Booking.com became the .HOTELS sponsoring organisation only when the final stages converted a surviving application into a bound registry operator and a root-zone entry.