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