On Jun 27, 2008, at 1:32 PM, Roger Marquis wrote:
Phil Regnauld wrote:
As business models go, it's a fine example of how to build demand
without really servicing the community.
Of all the ways new tlds could have been implemented this has to be
the
most poorly thought out.
Oh, no. There are plenty of worse thought out approaches. _Plenty_.
Security-aware programmers will now be unable to
apply even cursory tests for domain name validity.
I'm not sure how much I'd trust a 'security-aware programmer' that
relies on top-level domain name labels for _anything_, much less
domain name validity. But perhaps I misunderstand your point.
Phishers and spammers
will have a field day with the inevitable namespace collisions.
I believe an attempt at limiting this is found in the restriction to
disallow 'confusingly similar' names.
It is,
however, unfortunately consistent with ICANN's inability to address
other
security issues such as fast flush DNS, domain tasting (botnets), and
requiring valid domain contacts.
I suspect you might not be fully aware of how ICANN works. ICANN is
not the Internet's mommy and it can't make problems go away (even
those it created itself) by waving a magic wand. It works via a
bottom-up policy definition process that involves a large number of
parties, many of which are directly at odds with each other. Efforts
are underway in several of ICANN's constituencies and advisory
councils to propose solutions to all of these (e.g., for domain
tasting see http://www.icann.org/minutes/resolutions-26jun08.htm#_Toc76113173)
, but (as I have discovered painfully) it is exceedingly difficult to
have rapid forward motion in such an environment. If you try, you get
accused of acting in non-open, non-transparent, non-accountable, etc.
ways by all sorts of people. Really.
[de rigueur ICANN bashing]
It is easy to criticize (trust me, I do it all the time :-)). It is
more difficult to participate to try and get things fixed.
Regards,
-drc
