January 18, 2006

How Top Level Domains (TLDs) Should Be Allocated

In the matter of allocating new Top Level Domains (TLDs) ICANN has transformed what ought to be a simple, objective, efficient, and inexpensive process into a kind of idiocy.  ICANN has come to be the modern counterpart of Dickens' Circumlocution Office (from chapter 10 of Little Dorrit).  To paraphrase Dickens: ICANN is beforehand to all others in the art of perceiving HOW NOT TO DO IT.

So here's how I believe TLDs should be allocated.  The method below harkens back to what I proposed in year 2000 in my platform when I ran for the ICANN Board of Directors, back in those days when ICANN had actual elections.

I would retreat ICANN back to a very simple role of handing out what amounts to "permits to operate a TLD in the NTIA root zone" and abandon everything except very minimal and strictly technical evaluation and operational criteria.

Here's how it would work:

  1. ICANN should pick a number of TLD names that the DNS could hold in 100 years from now.  I'd suggest a number that we know from experience that the DNS software and hardware of today can physically support and then reduce that number by a nice comfort factor to accommodate the kinds of human, procedural, and hardware errors that come from handling large numbers of database records.

    We know from experience with .com that today's hardware and software can handle a zone in excess of 40,000,000 names.  Let's create a 40-fold comfort factor and say that in 100 years we want 1/40th of what we know DNS zones can hold today: That number is about 1,000,000.  (If that number scares you, don't worry, read on; I'll be reducing it substantially in a moment.)

  2. Then we drop the notion that ICANN is allocating TLD names and instead adopt the notion that ICANN is allocating TLD slots.

    A slot is the right to operate a TLD.  The person/entity that has a slot gets to pick any character name it wants as a name for the slot (and thus the name of the TLD) subject to the constraints described below.

    In other words, ICANN would be granting permits to operate a TLD, much like cities grant business licenses.  The name assigned to the slot, much like the name assigned to a storefront, is up to the person/entity that gets the permit.

    The constraints would be pretty simple:

    A. That the name is not already used by someone else.

    B. That the name fits within the internationalized domain name constraint of being in exactly one language group (i.e. just as we want to block exact duplicate names, we want to also block names that look like already existing names because the characters in different languages often look the same.)

    Notice that I'd get ICANN out of the business of name semantics and would leave the issue of protecting trade and service marks up to the normal laws regarding such things.  (And thus I'd drop ICANN's UDRP and all those things like "land-rush" and "sunrise" provisions that ICANN has created over the years.)

  3. What would be the requirements I'd ask of those applying for a permit to operate a TLD?

    Well, first I'd make the application fee reasonable: say $50, not $50,000.

    Second I'd ask only a very few questions and require only minimal documentation:

    A. Will the applicant promise on a stack of RFC's and BCP's that he/she/it will follow internet standards and best current practices?

    B. Will the applicant also promise not to use the TLD for illegal activities, like unsolicited commercial email?  (The exact language would be somewhat difficult to write, because I personally don't think we want to make TLD operators liable for the activities of those to whom they grant lower-level names unless the TLD operator is an active participant in that activity.)

    C. Will the applicant also promise to operate the TLD so that it resolves queries from everyone without prejudice or preference, that it will not do data mining of the query stream, and that it will not use its role as TLD operator to manipulate the DNS data in DNS responses unless it has the consent of the concerned name holders within the TLD?

    (The reason I have item C is that I'm busy writing up a note about all the data mining and manipulative things that a root server could do.  And that kind of data mining and manipulation could also be done by a TLD operator to those who have names within that TLD.)

  4. The system of allocation that I suggest is this: We take that number of target slots, my 1,000,000, and we divide it by 100 to come up with a number of new TLDs per year, or divide by 1200 to come up with a number of new TLDs per month.

    Now, a lot of people might be uncomfortable with the fact that after that division we have 10,000 TLDs per year or 833 TLDs per month.  OK, so reduce my numbers to 1/10 and I'll still be happy - 1000 TLDs year/83 month.  Hey, go one step more and reduce my numbers a hundredfold to 100 TLDs per year and 8.3/month and we'd still have a vast improvement over the immobility that has been ICANN's de facto TLD policy over the half decade+ since its formation.

  5. Then take that per-year or per-month allocation and divide it into two pots - one pot is for names that will be put up for auction and the other pot is names that will be put up for a low-cost ($5/ticket) lottery.

  6. Then I'd hold a yearly or monthly auction and lottery.

    The winners get invited up to the great stack of RFCs and BCPs and, if they make the necessary promises, they then get to announce what name they want to slap on their slot.  If the name meets the technical criteria, then we wish 'em godspeed and good luck.

    I'd not investigate their business plans one whit.  Nor would I require that a TLD operator follow any particular model - they might chose to have a registry/registrar model or might not.  They might chose to "sell" names for 1 to 10 years in 1 year increments or they might make 'em very long term or very short term.  (For an example of a system that eschews the registry/registrar model and periodic name renewals see my note about the business plan of my own TLD, .ewe: The .ewe Business Model - or - It's Just .Ewe and Me, .Kid(s))

One thing that I might do is require, or at least ask, the winners to publish a yearly statement from an independent auditor that attests that they have and actually engage in "procedures that in the mind of a prudent operator of a TLD are sufficient to ensure that the domain name assets of the TLD are protected in the event of natural, financial, or human events against loss or damage to the extent that the TLD could resume operation within a reasonable time after such event of could transfer those assets to a buyer who could then resume operation within a reasonable time."  People who want to build long-term, stable internet brands and identities could stay away from those TLDs that can't come up with a believable opinion from an auditor.

As for protecting the registrants inside those TLDs against failure of the TLD: I'd leave that up to existing consumer protection laws. If the TLD operator misleads their customers then the TLD operator deserves to be strung up by his/her/its legal thumbs.

(Note, that I make a distinction in this when it comes to those, like me, who built our names inside the legacy TLDs, like .com, before there has been a chance for the development of TLDs that create products that provide concrete assurances, for a price, that they will take steps to ensure that they, or at least their names, will remain viable on the net for a long time to come.)

I'd leave the fights that might occur over TLD names (.e.g. the kind of fight that might happen should someone over than Verisign try to put .com, or other than PIR try to put a .org, into a root zone that competes with NTIA's) to the legal systems of the world.

Thus, as you can see, I'd pretty much abandon the entire system in which ICANN intrudes into the business arrangements at both the ICANN-TLD level and also the TLD-2nd-tier-name level.

(And ICANN should be reminded that it accepted roughly $2,400,000 in year 2000 from TLD applicants - ICANN still owes those people an answer.)

Posted by karl at January 18, 2006 10:26 AM