Re: [ga] Do we need TLDs at all?

[Sandy Harris <sandy@storm.ca>]

gavin.stokes@autodesk.com wrote:
> 
> Maybe this is a technical question, but the collision discussion prompted it:
> 
> Is there a reason that we can't have any old string as the last component of
> a domain name?

There are length and character set restrictions.

Changing the character set restrictions to allow "international" domain names
has been discussed in the IETF technical groups and documents on how to do it
drafted. Some sort of experimental implementation based on those drafts was
announced last year by NSI. I haven't been paying attention to the details,
so I know neither how far the drafts have progressed toward standards status
nor how the NSI experiment works.

Other than those simple restrictions, "any old string" is technically allowed.

The complications are mostly non-technical. .biz or .smut might be marketable.
.xfdwqyy probably isn't. .ibm would have trademark problems unless IBM ran
it, and it isn't clear they need that since they already have ibm.com.

500 new domains this month is certainly technically possible in theory, but
in practice it might break various bits of software and therefore much of
the net infrastructure. Also, it would certainly confuse quite a few users,
and upset various people's business plans.

> Does the administration of various name servers require a finite collection
> of TLDs?

Finite, of course. Small, not necessarily.

It is easier to manage servers, in particular to get good performance, if
each level of the database is small. A small database fits in memory, even
of a fairly limited server. For a large database, you either need huge
memory (expensive server) or you have to use disk (much slower).

There are currently, I think, roughly 200 TLDs, mostly two-letter country
codes plus .com, .org, .net, .int, .gov, .mil, the new ones, .arpa for
reverse lookups and likely a few I've forgotten. 

Increasing that to 300, or even 500 or 1000, would make administration
harder, but not intractable. The difference might not even be noticeable
since automated procedures work as well for 1000 entries as for 200.

Technically, the hard problem is how do you support .com with its several
million registered domains?

If the only concern were making management of DNS servers easy, and we had
the authority to fix the problem, then we'd open at least a few dozen new
TLDs tommorrow and start kicking people out of .com.

   Tell all the companies that registered 100 different names in .com
   that "there can be only one". Force Autodesk, for example, to give up
   3dstudio.com and either use 3dstudio.autodesk.com or register a
   3dstudio domain elsewhere.

   Enforce a charter; boot non-commercial entites out of .com.

   Kill unused domains.

Of course, that is far from the only concern, it is doubtful that ICANN
has the authority for such measures, there would be serious difficulties
defining the terms in the above proposals, and none of them would fly
politically.   

Still, it is interesting that the only solutions we even discuss are new
TLDs or charter enforcement in other domains, like .org, when the obvious
problem is how to handle the over-used and over-marketed .com.

Hell, we don't even discuss obvious steps like just cutting off .com
registration as soon as some new TLDs are up, or setting up a price
differential.

Registrations of second level domains in the global TLDs currently
cost about $20. ICANN happily imposed a $50,000 fee just to apply
for a new TLD. There's absolutely no technical reason for that.
Arguably, a more useful move would be to bump .com registration to
perhaps $500 to get people out of there, of course with some sort
of grace period to let domain owners plan for change.
 
> If the intended meaning of many TLDs is not being enforced (or isn't enforceable),
> why have a limited set of them?

Good question.
--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html