ICANN and the Registrar Stakeholder Group announced they have reached agreement on a new Registrar Accreditation Agreement (RAA). The script called for a huge collective sigh of relief, but that never materialized in Beijing – the latest stop on the ICANN magical mystery tour of world capitals. This latest incarnation was the largest of these gatherings meaning more people than ever before were incarcerated in meetings rooms for days on end, including weekends, discussing issues of supposed import but making precious few decisions or taking any meaningful action.
Fortunately the Internet continues to function astoundingly well without “improvements” to generic Top Level Domains (gTLDs), the subject of intense conversation, dialogue, and debate at ICANNN for years now. This will continue for the foreseeable future as ICANN struggles to decide such issues as whether bank and banks, bar and bars, or lawyer and lawyers are confusingly similar. The answers to these questions seem obvious enough to anyone even vaguely familiar with taxonomy, for example the average person that has used a book index or the Yellow Pages.
Confusingly Similar, or Simply Confusing
Such a person needing an attorney might look in the lawyer section of the Yellow Pages to obtain contact information for a recommended law firm. Unfortunately, the firm in question has more than one practitioner and has chosen to place their ad in the lawyers (note the plural) section. The average person does not find the firm and is confused, being certain they had remembered the firm name correctly. They might not be aware that the classification system employed distinguished between single and multiple practitioners and therefor might not know to search in the next category.
Of course this is a contrived example because no taxonomist of even modest skill would choose singularity or plurality as a distinguishing characteristic. In addition, even if that classification had been chosen, lawyers being smart people, would advertise in both sections to ensure that the easily confused average person would find them straight away. The Yellow Pages publisher would be pleased because revenue would double for each category that had both singular and plural entries. I leave it as an exercise for the reader to determine who “wins” in this obviously contrived scenario.
If TLDs in the DNS represent a taxonomy, and I believe there is very strong evidence of this, maintaining some semblance of order and sensibility in that taxonomy is desirable. That should be a guiding principle in deciding what strings are delegated into the root. If employed, that principle would clearly inform ICANN that singular and plural gTLDs of the same name must be avoided. Common sense also dictates such a decision.
Costs, Benefits, and Legal Advice
Another way to look at the singular/plural issue is from a cost/benefit perspective. For what benefit might ICANN determine that singular and plural versions of all gTLDs should be allowed? Does the benefit outweigh any costs? Who benefits? Who incurs costs?
A doubling of the number of TLDs could benefit contracted parties who might see increased revenue from registrants that determined registrations in both singular and plural gTLDs were warranted. Similarly, dispute resolution services might be rewarded with additional revenue. Attorneys that prosecute disputes will also benefit from the additional, if repetitive workload. Registrants pay direct costs of multiple registrations and disputes. Everyone will pay the indirect costs of errors in reporting, documenting, and investigating issues related to names in any gTLD that has both singular and plural variants.
Why would the Community subject ourselves to these costs?
One theory is that ICANN the corporation wishes to avoid lawsuits resulting from decisions it makes as part of the new gTLD program. This is a reasonable policy and ICANN’s “stick to the guidebook” fair and equitable treatment of all parties is commendable, to a point. Where the guidebook has missed something crucial, ICANN should step in and “do the right thing”. That’s the case here with the cost to correct almost certainly less than the cost to avoid. Unfortunately, any cost to correct would be borne immediately by ICANN should there be lawsuits resulting from a common sense decision, whereas the bulk of the cost to avoid likely would be borne by registrants over time. One choice introduces negative externality costs to registrants, the other does not. With experience as our guide, negative externalities will likely win.
Fortunately, regardless of the decision ICANN makes, the Internet will continue to grow and provide benefit worldwide. Unfortunately, ICANN’s reputation as steward of the Internet’s name space can be tarnished if it chooses to avoid correcting what can be described as an obvious oversight in the guidebook.
This post started as a review of the proposed RAA but as I continued my reading of the nearly 70 pages that constitute that agreement, I realized that a comprehensive review would require more time than I could likely commit to such an endeavor.
I recognize and appreciate that a number of people devoted countless hours to the process that led to this proposed agreement. They undoubtedly strived to produce an agreement suitable for both parties, and their agreement in principle is evidence that they succeeded. Sadly, they have also produced what I consider an agreement so complex and intricate as to render it inscrutable to the general public and nearly impenetrable to those skilled in the art. How is this “in the public interest”?
I have a single suggestion and that is to start from a clean slate with a Community-developed term sheet that is in the public interest. From there an ICANN-led drafting group should produce standard contract language (boilerplate) and language specific to the Community-developed terms, and no others. This language should be reviewed as it is developed by representatives of the registrar, registry, and registrant communities – the three communities bound by contract directly or indirectly to ICANN. This process should be repeated for registries and registrants in order to ensure that ICANN’s contracts impose fair and equitable requirements on all groups in the Community and that the Community works together to ensure its health and the Security, Stability, and Resilience of the Domain Name System and the Internet.