|
According to this article in IHT , those who want deployment of IDNs now are “political gambits”. Cerf said that the technical side is not yet ready and thus the deployment of IDNs should be done very carefully.
I agree to the technical aspects. However, the next question is of course: “when will it be ready for deployment?” Can the ICANN community commit to a deadline it will meet? If not, ICANN should not blame those “political gambits” who wish to go forward because they just cannot afford to wait anymore.
There is a bad habit in the ICANN community that it should set the agenda and the rest of the world should just follow. Trouble is of course that the “rest of the world” represents several billion people, most of them ignoring the very existence of ICANN and even more its legitimity to set the world agenda. ICANN sounds more and more like Major Tom in David Bowie’s Space Oddity: “Ground Control to Major Tom, your circuit’s dead, there’s someting wrong. Can you hear me Major Tom?”
Sponsored byWhoisXML API
Sponsored byVerisign
Sponsored byRadix
Sponsored byVerisign
Sponsored byCSC
Sponsored byDNIB.com
Sponsored byIPv4.Global
The posting is quite misleading. The IHT article says nothing like “those who want deployment of IDNs now are “political gambits””. The IHT article says that Vint “feared the network’s addressing system would break down if “political gambits” by international groups or national agencies interfere with plans to expand the languages used in domain names.” The difference is significant. Vint seems to be warning against some groups or national agencies trying to use different standards than what ICANN is using. That seems like a good warning.
The second paragraph of the IHT article expands on that somewhat to say that his concern also includes interests “that would change the process for “internationalizing” Internet addresses”. That can be read either as technical changes (using something other than IDNA) or procedural changes (such as adding rogue IDN TLDs that are not part of the ICANN root). The latter have nothing to do with IDNs: a rogue TLD is bogus wheter or not it is an IDN.
The statement from the posting “Cerf said that the technical side is not yet ready and thus the deployment of IDNs should be done very carefully.” is completley false. The IHT article says nothing of the sort, as anyone who reads it can see. Patrick may believe this statement, but Vint certainly didn’t say it in the article.
Paul, you may be right I kind of misquoted the article. The core of my post is still that the ICANN/IETF community cannot seem to deliver by the date most people actually want it. It would all be quite easier of ICANN had a real leadership role and could tell the world, with no shadow of doubt that IDN TLDs will be available starting at a precise date.
Vint responded on my blog that “The critical path at this point is the IETF’s work on re-examining how to specify which characters to include from the large UNICODE set for use with IDNs. There are RFCs (4690) and several Internet Drafts on the subject. ICANN is already doing IDN testing in a laboratory copy of the root zone file and live tests could be underway by the end of the year or sooner. we also need to establish the rules for creating new TLDs, including those with IDNs. That work is under way in the GNSO.
Once confidence can be established in the IDN character inclusion rules, then the pacing item will be evaluation of proposals for new TLDs.”
Well noted, but that does not immediately answer the fundamental question of when it will be available for general deployment. The same holds true for DNSSEC, which will only be useful once the root is signed. Until then, it remains fundamentally an academic exercise.
Paul Hoffmann’s correction is well taken. Vint’s warning is against the intrusion of national politics in the standardization of IDNs.
But as always, Vint’s complaints about governmental interference are oddly selective. A perhaps more appropriate warning to ICANN would be: how much legitimacy has ICANN lost not only because of its slow pace (which I agree is a problem), but also because of its unilateral oversight by the U.S. government, which makes ICANN appear as a foreign, illegitimate decision making arena to many countries and participants in internet standards governance?
Had the U.S. sought and won global acceptance for ICANN as a truly autonomous, nongovernmental governance authority for the root, I doubt this would be such a problem.
Patrick says:
I am right, Patrick. It is easy to veryify by reading the IHT article that you pointed to.
We fully agree about ICANN’s inability; that’s not a good enough reason to mis-attribute words to Vint.
Here we disagree. IDN TLDs can be available today, and ICANN’s leadership knows this. Their finally-announced testbed for IDN TLDs is lame and unneeded; at least they picked good people to do it.
This is reasonable, but it would go much faster if ICANN encouraged people to participate in the discussion by reading the documents and then commenting. (Many will probably do the latter without the former, and make the process go more slowly.)
Vint must understand that these “tests” are just windowdressing. Further, they were supposed to have happened at least six months ago, but were delayed by ICANN’s inability to organize itself.
Again, that work is going extremely slowly because ICANN is not encouraging people to be actively involoved. They are afraid of the obvious results, which will point out ICANN’s inability to have a sane policy for a significant number of new TLDs of any flavor.
Meaning: because we get people scared of something they don’t understand and we haven’t explained, we don’t have to meet any particular deadline.
I don’t consider those to be the fundamental question. The fundamental question is why is ICANN so bad at getting technical things done in a timely fashion. To me, the answer is that they constantly try to mix policy into the technical mix, then pretend that there are technical issues. It’s a nice ruse, but it is also incorrect.
This is a little misleading as the topic of the interview (and I believe this post) is really IDN TLD, not IDNs with an ASCII TLD label.