ICANN ICANN Email List Archives

[gtld-council]


<<< Chronological Index >>>    <<< Thread Index >>>

[gtld-council] John Levine, Paul Hoffman: joint posting Comments on new GTLDs]

  • To: gtld-council@xxxxxxxxxxxxxx
  • Subject: [gtld-council] John Levine, Paul Hoffman: joint posting Comments on new GTLDs]
  • From: "GNSO.SECRETARIAT@xxxxxxxxxxxxxx" <gnso.secretariat@xxxxxxxxxxxxxx>
  • Date: Wed, 01 Feb 2006 20:38:53 +0100


More TLDs: why and how

This is a joint posting; John Levine posted it to his blog at
http://weblog.johnlevine.com/ICANN/whydom.html and Paul Hoffman posted
it to his blog at http://lookit.proper.com.

Susan Crawford, a new member of the ICANN board, asked about <a
auctions and lotteries for new gTLDs in a message at
http://scrawford.blogware.com/blog/_archives/2006/1/17/1682410.html. Lots
of people responded in the comments, and then the two of us kind of
took over. We have now stopped, and wrote this.

The two of us agree on some things, and disagree on others. We agree
that:

 * The best thing for the internet is to release the next batch of
gTLDs all at once, and to have that batch be about 50 new gTLDs. That
way, no one gets much advantage of having a new TLD other than the
semantics of the TLD's name.

 * Anyone even considered being awarded a gTLD needs to prove in
advance that they have the technical ability and skills to run a
gTLD. This means existing DNS nameservers in geographically and
topologically diverse areas, lots of bandwidth to those nameservers,
and the ability to maintain a large number of queries on each one.
Fortunately, these numbers can be agreed to ahead of time, and simple
tests can be created to test the applicants.  This is like the
qualification process for a CLEC (competitive local phone company) in
the US.  In many cases, we expect applicants would simply contract
with someone that already runs other TLDs to provide the technical
infrastructure.

 * ICANN should not profit from releasing the new gTLDs.  If ICANN
thinks it needs a bigger budget, it should go through a budget process
to justify that budget, not just get windfall money from the gTLD
process.

 * The winners of the new gTLDs get no exclusivity over any other
names issued by ICANN. That is, the first round might include
.rugs and .carpets, or the first round might include
.tooth</i> and the next round might include .teeth</i>; the
winner of .rugs</i> cannot prevent .carpets</i> from being
created.

 * Generic (non-country) TLDs have failed at being directories, and
that failure is getting worse over time. Users will always prefer to
use search engines to find which sites relate to a particular topic
than to assume that only domain names with a TLD that is semantically
linked to that topic are of interest.

 * There are probably only two plausible routes to a successful TLD:
.com clones and certification. The clones are just like .com</i>, only less
crowded; we already have two of those, and a few more could probably be
useful. The other route is certification.  The reason that .edu</i> is a
success while .coop</i> and .museum</i> aren't is that people care whether
something is an actual degree granting institution, while few people
care about "real" museums and "real" co-ops.  ("What a fool I was, they
said they were a co-op but really they were only a producer's
collaborative.") For a certified TLD to be useful, it has to cover
an area that is relevant to many Internet users and be managed by
an organization that will ensure that only bona fide SLDs are issued.

 * Some of the most useful domains like .edu</i> are not
particularly large or lucrative. None of the proposed schemes (including
our own) are likely to find them. If there is a place for creativity to
be focused, it should be on figuring out which new TLDs are the most
useful to typical Internet users and make sure those TLDs exist and are
well-managed.

The two of us disagree on the best way to make these bunches of 50
gTLDs appear.

John sees two routes to selecting TLDs. For TLDs intended to make
money, the best approach is an auction, with the N highest bids
getting to pick their N favorite domain strings, and the money given
away to a suitable worthy cause, not ICANN. Other people have made
more detailed proposals to deal with the obvious trademark issues,
e.g., only IBM can pick .ibm but they still need a winning bid to do
so. As Paul notes below, ICANN's beauty contest has picked losers, and
a lottery tends to turn into auctions where the lottery winners keep
the auction proceeds. Possible approaches include a separate lottery
for five or ten names for which only non-profits can apply, or giving
virtuous bidders funny money they can use in the auction, as was tried
in the PCS frequency auctions in the US. John doesn't have any great
confidence that these will work, but if the auction process can be
made simple and predictable enough, it should be possible to try one
approach this year, another next year, and so on until one turns out
to work.

Paul believes that there is no way to predict which TLDs might be
"best". The track record so far is abysmal.  Having an auction might
get people to think harder about which gTLDs would work best, but it
is completely unclear who should profit from the auction. Instead, a
lottery based on the desires of the organizations who qualify to be
gTLD owners could be designed to get a wide variety of TLDs, with some
organizations becoming big winners and the rest having ones that don't
cost much to run. A lottery would prevent ICANN from making
unnecessary money on the system, and would open the market to many
companies who might otherwise be locked out.

Both of us agree that once the 50 gTLDs are assigned, there will be a
lot of buying and selling of assets, regardless of what the rules for
the auction or lottery say. Just live with it; that is how big business
works. But the values of the new gTLDs will be much lower than might be
expected because there are so many of them, with maybe another 50 or 100
a year later.


--
Glen de Saint Géry
GNSO Secretariat - ICANN
gnso.secretariat[at]gnso.icann.org
http://gnso.icann.org



<<< Chronological Index >>>    <<< Thread Index >>>