February 2006 - council - lists.icann.org

Statement of Interests for Ross Rader
by Ross Rader Oct. 14, 2006

Oct. 14, 2006

Statement of Interests I am the Director of Research and Innovation for Tucows Inc., an ICANN accredited registrar and internet services vendor. Tucows is a minority shareholder in Afilias LLC, with roughly an 8% shareholding. Neither Tucows, nor I, is in possession of, nor have access to Registry Sensitive or Registry Proprietary information as defined by any relevant registry operating contracts as a result of this relationship. Tucows provides consulting and application hosting services to other registrars and internet services providers. I am not an officer, director, consultant, or employee of any of these customer organizations nor am I specifically involved in providing services to them. The URL for this statement is: http://www.byte.org/blog/_WebPages/StatementofInterestsforRossRader.html -ross

2 2

People's Daily Online -- China adds top-level domain names
by Maureen Cubberley Feb. 28, 2006

Feb. 28, 2006

.......and more on the same topic. Maureen http://english.people.com.cn/200602/28/eng20060228_246712.html

1 0

Interfax China
by Maureen Cubberley Feb. 28, 2006

Feb. 28, 2006

Of great interest and significance. Regards, Maureen China's Ministry of Information Industry revamps Internet domain names system http://www.interfax.cn/showfeature.asp?aid=10411&slug=INTERNET-POLICY-MII-D…

1 0

GNSO Review: Further information
by Liz Williams Feb. 28, 2006

Feb. 28, 2006

Dear Colleagues I said in my mail last week that I would provide updated information about the GNSO Review as soon as I could. Later today a press release will be issued and a posting to the ICANN website will announce that the London School of Economics' Public Policy Group has been chosen by the ICANN Board to conduct the Review. The relevant Board resolutions are found below -- this is a copy of my email which I sent early last week. That email also set out other things like public comments periods and background documentation. The Review team, lead by Professor Patrick Dunleavy, have begun their work and will be in touch with Constituency Chairs seeking the assistance of constituency members in responding to the Review. I would urge Council members to look at the Terms of Reference again and familiarise themselves with the work that needs to be conducted. A key element of the Review will be an online survey which will be launched later this week. In addition, face to face interviews and sessions will be conducted by the Review team at the Wellington meetings. If I can answer any questions, please don't hesitate to contact me. If you wish to get in touch with the Review team directly, you can email Simon Bastow (s.j.bastow(a)lse.ac.uk) or Jane Tinkler (j.tinkler(a)lse.ac.uk) Kind regards. Liz I have copied here my mail from last week which set out the background to the Review. ... For the benefit of Council members who have not been involved in the establishment of the Review, I've provided some easy to navigate background. I hope this also helps other Council members with their preparation for the Review. 1. The July 2005 Luxembourg Resolution initiated the Review and started a process of discussion between the Board, Council, and Staff on the establishment of the Terms of Reference. (http://www.icann.org/ minutes/resolutions-15jul05.htm#p4) 2. The December 2005 Vancouver Resolution approved the Terms of Reference which had been developed in consultation with individual members of the Board, Council and Staff (http://www.icann.org/minutes/ resolutions-04dec05.htm.) A 21 day public comment period about the draft Terms of Reference was conducted between 27 October 2005 and 17 November 2005. The archive of comments is at http://forum.icannorg/ lists/gnso-review-tor/ 3. The 14 December 2005 ICANN website posting sought requests for proposals from independent evaluators (http://www.icann.org/ announcements/announcement-14dec05.htm). 4. The 21 Feb 2006 Board Resolution approved the appointment of an independent team of evaluators but is not available online as yet. 5. Background documents on the GNSO Review can be found at http:// www.icann.org/gnso/review-tor-background-04nov05.htm. These include the recommendations from the GNSO Council Review, the relevant ICANN By laws and other helpful information. 6. The Terms of Reference can be found at http://www.icann.org/gnso/ review-reference-terms-27oct05.htm. 7. Article IV Section 4 of ICANN's Bylaws (http://www.icann.org/ general/archive-bylaws/bylaws-08apr05.htm#IV) gives guidance about the conduct of the review and I've copied it here for easy reference. I have added some emphasis which may provide clarification about the process. 1. The Board shall cause a periodic review, if feasible no less frequently than every three years, of the performance and operation of each Supporting Organization, each Supporting Organization Council, each Advisory Committee (other than the Governmental Advisory Committee), and the Nominating Committee by an entity or entities independent of the organization under review. The goal of the review, to be undertaken pursuant to such criteria and standards as the Board shall direct, shall be to determine (i) whether that organization has a continuing purpose in the ICANN structure, and (ii) if so, whether any change in structure or operations is desirable to improve its effectiveness. The results of such reviews shall be posted on the Website for public review and comment, and shall be considered by the Board no later than the second scheduled meeting of the Board after such results have been posted for 30 days. The consideration by the Board includes the ability to revise the structure or operation of the parts of ICANN being reviewed by a two- thirds vote of all members of the Board. Finally, ICANN Bylaws Article X, Section 5 which deals with the GNSO's operating procedures. ..................................................... Liz Williams Senior Policy Counselor ICANN - Brussels +32 2 234 7874 tel +32 2 234 7848 fax +32 497 07 4243 mob

3 3

ICANN: IDN Guidelines Update and Posting of Version 2.1
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG Feb. 28, 2006

Feb. 28, 2006

[To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: liaison6c[at]gnso.icann.org; council[at]gnso.icann.org] Please note ICANN's posting about the IDN Guidelines Update and Posting of Version 2.1 http://www.icann.org/announcements/announcement-27feb06.htm The ICANN Board resolution of 8 November 2005 http://www.icann.org/minutes/resolutions-08nov05.htm endorsing the v.2.0 Guidelines http://www.icann.org/topics/idn/implementation-guidelines.htm "tasks the IDN working group to continue its important work and return to the board with specific IDN improvement recommendations before the ICANN Meeting in Morocco, currently scheduled for June 2006." Click here http://www.icann.org/announcements/announcement-27feb06.htm for an update on this work as well as for information about the version 2.1 of the IDN Guidelines. Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

more questions on consensus policy and contracts
by Avri Doria Feb. 26, 2006

Feb. 26, 2006

Hi, During last night's meeting I was trying to understand the relation between PDP consensus policy and contractual arrangements. I realize that this is a less then favored subject, and I apologize for holding up the progress of the meeting with my question last night and apologize if this message causes further distress. I want to see if what I understand, I understand correctly, and I want to clear up areas where I am still confused. And while I did hear Bruce's explanation, the quality of the line made it difficult to follow completely, and I did not want to interfere with the meeting further by asking the questions at that time. In my looking at it, I see at least two different questions: - what can the council propose consensus policy on - the relation between consensus policy and contracts, of which there are three types: - existing - renewing - new - what the council can propose consensus policy on: If I understand correctly, the GNSO council can propose policy, assuming it follows the procedures, on just about anything related to gTLDs that can be shown to be relevant under the Bylaws of 8apr05 Article 1. And the Board is empowered to approve policy, once presented by the GNSO council after all appropriate procedures, on anything interpreted as coming under the Mission as understood in the context of the Values. This include the principles of public accountability, fairness, competitiveness, and transparency etc as well as 'preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet.' And if I understand correctly, the subjective qualities of 'feasible and appropriate' are put in several of the clauses to give the board, the council and the community flexibility in interpreting article 1 - though I am curious as to how these are determined given the relative nature of such appraisals - is the board the jury that must apply the 'reasonable man' criteria. - to what degree is consensus policy applicable to existing contracts and to what degree are existing contracts applicable to the creation of consensus policy? If I understand correctly, the nature or content of current contracts or the clauses in those contracts relating to consensus policy have _no_ effect on which policies can be created and approved, but only affect the degree to which new consensus policies can be applied during the term of that contract. And, as these exclusions from consensus policy clauses are somewhat different in every contract, no general statement can be made about which consensus policies are applicable to the full set of current contracts. - to what degree do consensus policies affect contracts in the process of renewal? On this I am still confused. (at least I know I am confused here, obviously if I am wrong about what I wrote above, then I am also confused about that) When a new contract is being negotiated what is the relationship between existing consensus policy, esp. policy that was created between the time the contract was originally negotiated and the time of renewal, and the renewal. Does policy created during the term of the expiring contract have effect on the contract being renewed or on the clauses in that contract relating to exemptions from consensus policy? - to what degree are negotiations on new contracts bound by consensus policy? I am also confused on this. Does consensus policy determine the nature and content of new contracts negotiated by ICANN staff. Can the negotiators put in clauses exempting the signatories from existing consensus policy as awell as future consensus policy? Can consensus policy that is in effect at the time of negotiation, have an effect on the clauses in the contract that relate to the effect of future consensus policy on the contract conditions? I.e Could there be a consensus policy that said future contracts could not exempt the signatories from a particular consensus policy? I hope my questions do not disturb the debate on the TOR itself or on the important work to come up with recommendations about the creation of new gTLDs. It is just that the contribution by the registry constituency got me thinking about the full extent of the influence, and relevance, of consensus policy. I also apologize for not managing to understand the full issue from what I have read and from what was explained during last night's meeting. thanks a.

2 1

Output of brainstorming session on lessons learnt from the previous introduction of new gTLDs since 1999
by Bruce Tonkin Feb. 26, 2006

Feb. 26, 2006

Hello All, Below is a copy of the points made by those present in the meeting in Washington. It does not represent any consensus but simply is a list of points made by participants. This list was used to help with the discussion on whether to continue with the introduction of new gTLDs. Regards, Bruce Tonkin Negligible impact on security and stability. New strings and strings with more than 3 characters that were not interoperable with End-user application software caused reliability problems. Whole system needs to absorb a new TLD across all software before fully interoperable. No institutional mechanism to inform technical, software development community and potential users. Not enough education that new TLDs have been introduced. Little knowledge amongst Internet users of the new TLDs. Selection and implementation process time consuming, expensive and unpredictable Registry-registrar protocol was standardised (EPP) Sunrise program difficult to design Limitation on the number added caused problems for other applicants that met selection criteria Independent evaluators an improvement after first round Some Selection criteria not objective, clearly defined, and measurable enough to allow independent evaluation to be effective Contracts too constraining to allow a registry operator to evolve their business model in response to market needs No guarantee of financial gains from operating a new TLD Long established TLDs have a powerful legacy advantage over new TLDs. The switching costs for an existing registrant of a domain name from one TLD to another is significant. The legacy TLDs are still continuing to grow strongly in registrations and at higher rate than the new TLDs. Selection process was not a good judge of what succeeded in the market. Selection process doesn't scale. Individual negotiations of registry agreements after Board approves new TLD also time consuming. Discretionary processes can be hijacked politically. Registry operator business models may be limited by the distribution channel of all ICANN accredited registrars. Small TLD is OK if meets the needs of the community that has put forward and doesn't exclude others that are within that Community. The new gtlds introduced so far do not yet cater for parts of the international community that use character sets other than the limited set from the ASCII character range. This has also led to a growth in alternative root implementations and applications work arounds (e.g browser plug-ins). A policy is required for the introduction of IDNs at the top level, and need to consider the political and cultural environments as demand for these IDNs is increasing. Core of the Internet adapts faster than the edges of the Internet. Participation of registries, registrars and resellers, end users required in testing, and identifying clearly the objectives of the test, policy implications, and measuring the outcomes of the test. Need to consider whether to set a price and if so, how price is set in the registry agreement and how it impacts end-users. Describe reasoning/objectives behind "proof-of-concept" rounds and whether objectives of new TLD introductions have been met. Concern about whether open TLDs have resulted in new registrants compared to existing registrants in a legacy TLD simply registering to protect the brand. For existing registrants in a legacy TLD that register in a new TLD, how many of these use the new registration to create a separate website, or a separate user of email, rather than simply use email or URL forwarding to the existing registration in the legacy TLD, or change their advertising/marketing materials to explicitly reference the new TLD in an email or website address. Registry operators have learnt more about the market for new TLDs which may assist a new operator when launching a new TLD.

1 0

Updated terms of reference for PDP-Feb06 for decision on 2 March 2006
by Bruce Tonkin Feb. 26, 2006

Feb. 26, 2006

Hello All, Here is a revised draft based on the discussion in Washington yesterday. I have cleaned up the numbering and added some examples of price controls) There was also some discussion about striking the topic of development and infrastructure. Those participating yesterday undertook to review this with their constituencies. Regards, Bruce Tonkin Terms of Reference for PDP-Feb06 Context The GNSO initiated a policy development process in December 2005 [PDP-Dec05] to develop policy around whether to introduce new gTLDs, and if so, determine the selection criteria, allocation methods, and contractual conditions. During 2005, ICANN commenced a process of revising the .net and .com agreements. There has been substantial discussion amongst members of the GNSO community around both the recently signed .net agreement (dated 29 June 2005), and the proposed .com agreements (dated 24 October 2005 and 29 January 2006). As a result, the GNSO Council recognized that issues such as renewal could be considered as part of the broader issue of contractual conditions for existing gTLDs, and that it may be more appropriate to have policies that apply to gTLDs generally on some of the matters raised by GNSO members, rather than be treated as matters to negotiate on a contract by contract basis. Subsequently on the 17 January 2006, GNSO Council requested that the ICANN staff produce an issues report "related to the dot COM proposed agreement in relation to the various views that have been expressed by the constituencies." This issues report is available at: http://www.gnso.icann.org/mailing-lists/archives/council/msg01951.html . Section D of this issues report provides a discussion of many of the issues that had been raised by the GNSO community in response to the proposed revisions to the .com agreement. In the issues report the ICANN General Counsel advised that it would not be appropriate to consider a policy development process that specifically targets the .com registry agreement. At its meeting on 6 February 2006, members of the GNSO Council clarified that the intention of the request for the issues report was to seek an issues report on the topic of the broader policy issues that relate to the contractual conditions of gTLD agreements, which have been identified from the various views expressed by the GNSO constituencies on the proposed .com agreement. At its meeting on 6 February 2006 the GNSO Council recognised that while the PDP initiated in December 2005 [PDP-Dec05] included within its terms of reference the topic of contractual conditions, a possible outcome of that PDP would be that there should be no additional gTLDs, and thus the Council could not depend on this PDP to address the issues raised by the GNSO community. Thus at its meeting on 6 February 2006, the GNSO Council, by a super-majority decision, decided to initiate a separate PDP [PDP-Feb06] to look at specific areas of contractual conditions of existing gTLDs. The work of PDP-Feb06 will naturally be conducted within the context of the work on PDP-Dec05, and if it is decided that new gTLDS should be introduced, the policy work of PDP-Feb06 will be incorporated into a single gTLD policy. Goal The overall goal of this PDP therefore is to determine what policies are appropriate, for the long term future of gTLDs within the context of ICANN's mission, that relate to the issues identified in the specific terms of reference below. Terms of Reference 1. Registry agreement renewal 1a. Examine whether or not there should be a policy guiding renewal, and if so, what the elements of that policy should be. 1b. Recognizing that not all existing registry agreements share the same Rights of Renewal, use the findings from above to determine whether or not these conditions should be standardized across all future agreements. 2. Relationship between registry agreements and consensus policies 2a. Examine whether consensus policy limitations in registry agreements are appropriate and how these limitations should be determined. 2b. Examine whether the delegation of certain policy making responsibility to sponsored TLD operators is appropriate, and if so, what if any changes are needed. 3. Policy for price controls for registry services 3a. Examine whether or not there should be a policy regarding price controls, and if so, what the elements of that policy should be. (note examples of price controls include price caps, and the same pricing for all registrars) 3b. Examine objective measures (cost calculation method, cost elements, reasonable profit margin) for approving an application for a price increase when a price cap exists. 4. ICANN fees 4a. Examine whether or not there should be a policy guiding registry fees to ICANN, and if so, what the elements of that policy should be. 4b. Determine how ICANN's public budgeting process should relate to the negotiation of ICANN fees. 5. Uses of registry data Registry data is available to the registry as a consequence of registry operation. Examples of registry data could include information on domain name registrants, information in domain name records, and traffic data associated with providing the DNS resolution services associated with the registry. 5a Examine whether or not there should be a policy regarding the use of registry data for purposes other than for which it was collected, and if so, what the elements of that policy should be. 5b. Determine whether any policy is necessary to ensure non-discriminatory access to registry data that is made available to third parties. 6. Investments in development and infrastructure 6a. Examine whether or not there should be a policy guiding investments in development and infrastructure, and if so, what the elements of that policy should be.

1 0

Clean version of 2006 PDP
by Maria Farrell Feb. 25, 2006

Feb. 25, 2006

Dear all, Following the edits done at the ad hoc working session of the GNSO Council in Washington today, attached is the current version of the Terms of Reference of this PDP. (it hasn't been copy-edited yet, so there may be stray commas, etc.) This document was not the subject of a vote by the GNSO Council. It will be voted on by the Council next Thursday, March 2nd. All the best, Maria

1 0

Washington meeting - current text of 6
by Maria Farrell Feb. 25, 2006

Feb. 25, 2006

6. Investments in development and infrastructure . Examine whether or not there should be a policy guiding investments in developments and infrastructure, and, if so, what the elements of that policy should be. be.

1 0

RE: Washington meeting - current text of 5
by Maria Farrell Feb. 25, 2006

Feb. 25, 2006

5. Uses of registry data Registry data is available to the registry as a consequence of registry operation. Examples of registry data could include information on domain name registrants, information in domain name records, and traffic data associated with providing the DNS resolution services associated with the registry. 5a. Examine whether or not there should be a policy regarding the use of registry data for purposes other than those for which it was collected, and, if so, what the elements of that policy should be. 5b. Examine how the use of registry data can enhance services to registry clients. 5c. Determine whether any policy is necessary to ensure non-discriminatory access to registry data that is made available to third parties. 5d is deleted

1 0

Washington meeting - current text of 4
by Maria Farrell Feb. 25, 2006

Feb. 25, 2006

4. ICANN fees 4a. Examine whether ICANN fees defined in registry agreements should be the subject of consensus policy . Examine whether or not there should be a policy guiding registry fees to ICANN, and, if so, what the elements of that policy should be. 4c. Determine how ICANN's public budgeting process should relate to the negotiation of ICANN fees. (4b and deleted)

1 0

RE: Washington meeting - current text of 3
by Maria Farrell Feb. 25, 2006

Feb. 25, 2006

3. Policy for price controls for registry services 3a. Examine whether or not there should be a policy regarding price controls, and, if so, what the elements of that policy should be. 3b. Examine objective measures (cost calculation method, cost elements, reasonable profit margin) for approving an application for a price increase when a price cap exists. (3c and 3d deleted)

1 0

Washington meeting - current text of 3a
by Maria Farrell Feb. 25, 2006

Feb. 25, 2006

3a. Examine whether or not there should be price controls, and, if so, what the elements of that policy should be.

1 0

proposed 3a
by Ross Rader Feb. 25, 2006

Feb. 25, 2006

3a. Examine the role that price controls play in relation to ICANN's core mission and values, especially the promotion of comptition and the net effects on end users.

1 0

RE: Washington meeting - current text of 2b
by Maria Farrell Feb. 25, 2006

Feb. 25, 2006

2b. Examine whether the delegation of certain policy making responsibility to sponsored TLD operators is appropriate, and, if so, what if any changes are needed.

1 0

Proposed 2b
by Ross Rader Feb. 24, 2006

Feb. 24, 2006

2b. Examine whether the delegation of policy making responsibilities to sponsored TLD operators should be re-examined, and if so, what changes would be needed, and under what circumstances, such changes would be applied.

1 0

Washington meeting - current text of 1c
by Maria Farrell Feb. 24, 2006

Feb. 24, 2006

1c. Recognizing that not all existing registry agreements share the same Rights of Renewal, use the findings from above to determine whether or not these conditions should be standardized across all agreements.

1 0

Washington meeting - current text of 1b
by Maria Farrell Feb. 24, 2006

Feb. 24, 2006

subject to change: 1b. Examine whether or not there should be a policy guiding renewal, and, if so, what the elements of that policy should be.

1 0

Registry Operators Statement re Verisign Settlement.DOC
by Ken Stubbs Feb. 24, 2006

Feb. 24, 2006

This was submitted by our constituency as part of the comment process. I thought i would make it available to you directly for the upcoming deliberations regards Ken Stubbs

2 2

please let me know off list who is on the line
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG Feb. 24, 2006

Feb. 24, 2006

Please let me know off the list who is on the line? Please also let me know if will participate for the other parts of the call. Thanks Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

FYI - comparison table of 200 / 2006 statements on introduction of new gTLDs
by Maria Farrell Feb. 24, 2006

Feb. 24, 2006

Dear all, Here is a partial comparison of statements on the introduction of new gTLDs prepared in support of today's working session of the GNSO Council. all the best, Maria

1 0

GNSO new gTLDs P
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG Feb. 24, 2006

Feb. 24, 2006

[To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: liaison6c[at]gnso.icann.org; council[at]gnso.icann.org] Please find the MP3 recording of the GNSO new gTLDs Policy Committee meeting in Washington DC meeting, held on February 24, 2006 at: http://gnso-audio.icann.org/GNSO-council-20060224.mp3 http://gnso.icann.org/calendar/index.html#feb Happy listening! -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

ICANN Board Call
by Michael D. Palage Feb. 22, 2006

Feb. 22, 2006

Dear Council Members: The ICANN Board just concluded its teleconference today and took the following actions. (1) Approval of São Paulo, Brazil as the venue for the 2006 ICANN annual meeting the first week in December; and (2) Approved funds to pay the evaluators for their work in connection with the review of the GNSO; Although there was a discussion regarding the VeriSign settlement negotiation, there was no action taking. There is a scheduled call for next week 28-Feb-2006. Although the Chair and secretariat have not yet finalized the agenda for that call it is most likely to involve further VeriSign discussions as well as those items which have not yet been completed from today's call. As always, I will try to keep the council informed of any developments. Best regards, Michael D. Palage

3 4

Very interesting - CircleID: Examining the Proposed Internationalization of TLDs -
by sophiabekele Feb. 22, 2006

Feb. 22, 2006

Dear All, I am sending this article for your interest. I do not know James, and had no idea he had the same views as I have been expressing these past couple of weeks until I saw the article. Regards, Sophia "Examining the Proposed Internationalization of TLDs" By: James Seng, Nov 30, 2004 http://www.circleid.com/posts/examining_the_proposed_internationalization_o f_tlds/ Last month, John Klensin wrote an article published here on CircleID regarding Internationalized Domain Names (IDN) Top Level Domains (TLD). Based on his Internet Draft, John suggests using language translation in the application for TLD. The advantage of this method is that all existing TLDs can now be represented in any number of languages without additional need for ICANN to create new TLD. While this sounds like a clean solution to the IDN TLD problem, I don’t think it is viable for the following five reasons: 1. Similar idea has been proposed in the IETF IDN Working Group for IDN (See uname and vidn). While John proposal has some minor technical differences, the fact that these similar ideas has been considered and discarded by the IDN Working Group is worth noting1. 2. One of the differences of John proposal is that translations are only done only for TLDs. 2nd Level Domain (2LD) and others remains using IDNA (RFC 3490). From a technical design perspective, such exemption handling are not desirable; it isn’t “keep it short and simple” (KISS)2. Bear in mind that IDNs are fundamental identifiers also used embedded into other technical protocols (e.g. URL, URI, Email Address, Jabber Address, SIP Address), such inconsistency would introduce additional complexity in other Internet protocols. 3. In the article, John said: The country-code list changes only very slowly. ICANN plans for the generic name list to grow moderately, but not dramatically, in the foreseeable future. Maintaining a translation table in which around 300 names are kept together with convenient local forms is a fairly simple matter of programming. While that is technical true, getting the translation table into the application is a big challenge itself as we witness how long it took IDNA to be adopted by browser. In fact, after nearly 2 years, Internet Explorer still lacks IDNA support although we know now it is in its roadmap. draft-klensin-idn-tld also propose that “We suggest that c authors of applications programs may want to maintain a table that contain lists of TLDs and locally-desirable names for each one” But it fails to mention how the table is going to be managed and later updated. Will every applications needs to be updated or download a new text file whenever ICANN adds a new TLD? Who will decide what’s the ‘locally desirable names”? Dealing with such problem with a single text file (e.g. TLD.TXT) downloadable from IANA may seem viable in the short run. But in the long run, just like we can’t cope with HOST.TXT back in 1980s which resulted in the creation of DNS, a TLD.TXT will not scale and we will inevitably fall back to using some sort of directory look-up mechanism, or worst, reinventing DNS. 4. Translation is also a fairly instable with variation based on local and language. And names of countries are even trickier. For example Singapore, officially name is 新加坡 but it is often shorten to be 新国 or 星國. Such inconsistency is not acceptable in a DNS protocol where uniqueness is critical. You just cant ask your user to type in 新国 or星國, depending which application they using or which locale they using. I am quite sure these problems exist for all languages, regardless for country names or generic names. Just for fun, try getting a group of your favorite linguists to translate .COM and .BIZ, and then step back, get lots of donuts and diet cokes and watch the show. 5. While this is the last reason I am going to give you, and I am sure there are more, it is the most important one too and perhaps the easiest to understand. If you can’t remember the above four technical reasons, then just remember this one: How on earth is the Internet community going to explain to the rest of the world that a single company is going to control all .COM in their language? IDN TLD is important and many groups are already asking for one. Some more important then others, like Arabic Domain Names is horrible to use when mixed with Latin TLD. However, ICANN cannot shy away from releasing IDN TLD by using such technical short-cut, by moving their burden to the applications developers. If ICANN indeed is indeed the responsible for “generic and country code Top-Level Domain name system managed” (quote ICANN ), then do so, and make it count. 1 A detail discussion why so those proposals were rejected is an article on its own...some day perhaps. 2 IDNA is design to apply to all internationalized labels, regardless whether it is TLD, 2LD, 3LD etc, in accordance to the KISS principle.

1 0