March 2006 - council - lists.icann.org

FYI.. media stuff
by Sophia B 19 Mar '06

19 Mar '06

FYI... March 17, 2006 *Open letter to the Internet Corporation for Assigned Names and Numbers (ICANN) from the Canadian Internet Registration Authority (CIRA)* http://www.cira.ca/news-releases/171.html ICANN to test non-English domain name http://smh.com.au/news/breaking/icann-to-test-nonenglish-domain-names/2006/… I find the statement below in the article interesting. This is the first time this has been raised in the press. ie. even if DNAMEs testing succeeds and gets to deployment the world may ignore it etc. *********begin quote******** "Even if the tests are successful, though, several policy questions remain. For example, should the incumbent operator of global domains like ".com" automatically get a Chinese version, or does that more properly goes to China, as its government insists? " *********end quote*********

2 1

Final Task Force Report on Purpose of Whois
by Maria Farrell 18 Mar '06

18 Mar '06

Dear Council members, Please find attached the Final Task Force Report on Purpose of Whois. This report and the two formulations of purpose in it have been the subject of a task force vote that closed on 16 March, 2006. The task force now submits the report to council for its consideration. Best regards, Maria Farrell

1 0

Wellington good news
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 18 Mar '06

18 Mar '06

Subject: ICANN Wellington From: "Keith Davidson" <exe.dir(a)internetnz.net.nz> Date: Wed, 8 Mar 2006 17:35:51 -0800 All, Pardon this intrusion, but I thought it might be useful to advise you all my plans regarding some social aspects of the Wellington ICANN meeting... As you are all aware, ICANN attendees are scattered around 7 hotels in Wellington. I have been concerned that the ICANN attendees will therefore tend to drift to their various hotels, and therefore we run the risk of missing out on much of the usual social interaction. I have therefore organised a bar, around 100 metres away from the conference venue, which will be renamed the ICANN bar for the week. I have a number of sponsors aligned to provide a "happy hour" at the ICANN bar from around 5pm to 7pm each night from Sunday 26th. There will be free beer and wine for the duration of the "happy hour". We will run a theme each night, for each of the sponsors and there will be some little prizes for attendees etc etc. Pre-printed invitations to the Happy Hours will be included in the delegates packs at registration, and we'll get details on the website soon also. The location of the ICANN Bar is also shown on the map given to delegates. InternetNZ people will be hovering around the exit doors of the Convention Centre from around 5pm each evening and offering to escort people to the ICANN bar. I am hopeful that you all might assist me by encouraging as much of the ICANN crowd together each night at the ICANN Bar, and therefore ensuring the geographical spread of hotels does not lead to a lack of opportunity for all to mix and mingle? Regards Keith Davidson Executive Director - InternetNZ -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

2 1

pdpfeb06 task force
by Suzanne Sene 17 Mar '06

17 Mar '06

hello everyone, just a short note regarding the recent email message sent from liz williams, i believe, regarding the composition of the pdp task force. i see that i have been included on the list of members, and would ask that my name be taken off the list until i have had the opportunity to raise the issue of gac participation in the task force with my gac colleagues who work with me on the gac gnso working group. thanks, suz. Suzanne R. Sene Senior Policy Advisor NTIA/OIA 202-482-3167 (ph) 202-482-1865 (fax)

1 0

Travel tips
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 17 Mar '06

17 Mar '06

[To: council[at]gnso.icann.org] Some useful travel tips: If you do not fly directly to Wellington,when you arrive in Auckland please be sure you have your return ticket available to show the immigration officer. After going through customs, you will need to change terminals to connect to your flight to Wellington. There is a shuttle available running about every 20 min. or if the weather is nice an you prefer to walk it takes 10-15 minutes. Once you arrive in Wellington, proceed to the exit area where taxis will be waiting. The 15min. ride to the hotel costs approx. NZ$30.00. The Meeting Venue is 4 blocks from the InterContinental Hotel where most of the Councillors will be staying. Small maps of the city center are available at the front desk and they will be happy to point you in the right direction to walk to the Michael Fowler Center. InterContinental Wellington 2 Grey Street PO Box 175 Wellington New Zealand Tel: +64 4 472 2722, Fax: +64 4 472 4724 For the type of adapter needed see http://kropla.com/!i.htm The weather in Wellington is changeable and notoriously windy, hard to keep hats on and skirts down! While it will generally be warm while we are there, it can change and you can have light rain quickly. Just be advised that you will be walking several blocks from the hotel to the conference center so you might want to pack accordingly. Bon voyage! -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Constituency representatives for (PDP-Feb06) task force
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 16 Mar '06

16 Mar '06

[To: council[at]gnso.icann.org] Dear Council Members, The following representatives have been appointed by the constituencies for to serve on the task force (PDP-Feb06)Policy development process on contractual conditions for existing gTLDs: Intellectual Property Interests constituency - Ute Decker - other volunteer(s) are being recruited as participating non-Council members and council will be informed when these names are available. Internet Service Providers' and Connectivity Providers' constituency. - Greg Ruth is the nominated lead. gTLD Registries constituency: David Maher is the representative who will work alongside the council representatives Ken Stubbs and Cary Karp. Commercial and Business Users constituency - There will be 3 members with one observer, Marilyn Cade, Philip Sheppard and Mike Roberts, the third elected BC officer will be an observer. Registrars Constituency Jeff Eckhaus, Register.com Jon Nevett, Network Solutions Ross Rader, Tucows (GNSO Council) Non Commercial Users constituency - Mawaki Chango (GNSO Council) When the task force mailing list and public archives are created you will be informed. Please let me know if you have any questions. Thank you, Kind regards, Glen On 16 February 2006 at the GNSO Council meeting it was resolved: "That the Council wishes to appoint a task force for the PDP initiated on 6 February 2006 (PDP-Feb06) that consists of the full Council, including the Council members appointed by the Nominating Committee, the At Large Advisory Committee (ALAC) and the Government Advisory Committee (GAC) liaisons. That constituencies have the option to appoint representatives to the task force in place of their Council members. That the Council recommends that the constituencies ensure that there is at least one council member from the constituency on the task force. That Council members, who are not members of the task force, have observer status on the task force, and thus receive mail from the mailing lists and be able to attend task force calls and meetings as observers." Could you please let me know by Friday 10 March 2006, who you have appointed to this task force. If you have appointed representatives in place of council members, please add their email contact details. -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

LSE Reviewers request interviews with councillors on 23/24 March in Wellington
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 16 Mar '06

16 Mar '06

[To: council[at]gnso.icann.org] Dear Council Members, The GNSO Reviewers would like to interview GNSO Council Members on Thursday 23rd and Friday 24th March 2006. If you would be available for an interview, could you please contact Oliver Pearce at Lseppg-Gnsoreview(a)lse.ac.uk. to make an appointment. Thank you very much. Kind regards, Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

Revised draft minutes GNSO Council call 2 March 2006
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG 16 Mar '06

16 Mar '06

[To: council[at]gnso.icann.org] Dear Council Members, Please find the revised draft minutes of the GNSO Council meeting held on 2 March 2006. Lucy Nichols's was present and her vote has been added. Please let me know if there are other changes you would like made. Thank you very much. Kind regards, Glen 2 March 2006 Proposed agenda and related documents List of attendees: Philip Sheppard - Commercial & Business Users C. Marilyn Cade - Commercial & Business Users C. Grant Forsyth - Commercial & Business Users C Greg Ruth - ISCPC Antonio Harris - ISCPC Tony Holmes - ISCPC Thomas Keller- Registrars Ross Rader - Registrars Bruce Tonkin - Registrars Ken Stubbs - gTLD registries June Seo - gTLD registries Cary Karp - gTLD registries Lucy Nichols - Intellectual Property Interests C Ute Decker - Intellectual Property Interests C - absent - apologies Kiyoshi Tsuru - Intellectual Property Interests C. Robin Gross - NCUC. - absent Norbert Klein - NCUC. Mawaki Chango - NCUC Sophia Bekele - Nominating Committee appointee Maureen Cubberley - Nominating Committee appointee Avri Doria - Nominating Committee appointee 19 Council Members ICANN Staff Dan Halloran - Deputy General Counsel Kurt Pritz - Vice President, Business Operations Olof Nordling - Manager, Policy Development Coordination Maria Farrell - ICANN GNSO Policy Support Officer Liz Williams - Senior Policy Counselor Tina Dam - Chief gTLD Registry Liaison Glen de Saint Géry - GNSO Secretariat GNSO Council Liaisons Suzanne Sene - GAC Liaison - absent - apologies Bret Fausett - ALAC Liaison Quorum present at 19:08 UTC. MP3 Recording Bruce Tonkin chaired this teleconference. Approval of agenda Marilyn Cade requested the an update on the Wellington schedule under Any Other Business Item 1: Approval of the GNSO Council minutes 6 February 2006 Ross Rader moved the adoption of the minutes. Motion approved. Decision 1: The GNSO Council minutes of 6 February 2006 were adopted. Update on GNSO Review and introduction of the reviewers The London School of Economics (LSE) Public Policy Group has been appointed to undertake the GNSO Review, Prof. Patrick Dunleavy, Simon Bastow, and Oliver Pearce were invited to address the council. The expenditure approved by the Board for the GNSO Review was $150000 USD to be expended over the period of the review process. The group is engaged in academic and research consultancy having worked for the United Kingdom Government, international bodies and foreign governments with a recent work focus on e-government. The Review would consist of several components, - the main one being a web site with a survey for each constituency, accessible in English, Portuguese, French, Spanish, Arabic and Russian, with a user identity and password, - a large outreach team at the LSE e-mailing and communicating directly with people, - press advertising, - a weblog and - discussion group to interactively solicit views. In addition there would be: - a comprehensive series of interviews also taking place during the Wellington meetings, - examination of documentation and other data focused on the areas of representativeness, transparency, effectiveness and compliance in the GNSO Review Terms of Reference. The emphasis is on seeking a broad range of views. To a question raised about the review examining the GNSO role in registry /registrar compliance, the clarification was that it was intended to contextualise comments on how the GNSO was viewed, rather than quantify how GNSO enforced compliance. Item 2: Terms of reference for PDP-Feb06 - Decide the terms of reference for the PDP (Under the provisions of section 7(b) of Annex A of the ICANN bylaws) Bruce Tonkin noted the gTLD Registry constituency statement concerning the PDP Feb06 posted to the Council mailing list. The process to date was that an initial draft Terms of Reference (TOR) for PDP-Feb06 was produced on 8 February 2006, a conference call was scheduled on 16 February 2006, during which some constituencies expressed the need for more time to discuss the issue, after the call the ICANN staff produced a revised draft TOR . At an ad hoc working session of the GNSO council in Washington DC, on Friday 24 February 2006, (present: Bruce Tonkin, Ross Rader Registrar constituency; Marilyn Cade CBUC; Mawaki Chango NCUC; Ken Stubbs, Cary Karp remote participation gTLD registries constituency; Tony Holmes remote participation ISPCPC, remote participation; Avri Doria and Maureen Cubberley, remote participation Nominating committee appointees),the Council members further edited the TOR. The current teleconference was scheduled with the intention to finalise and put the Terms of Reference to the vote. Bruce Tonkin asked whether any councillor wished to make a statement of interest that had not been previously declared. Ross Rader mentioned updating his statement of interest indicating that some of Tucows clients might be active in the GNSO or ICANN. Bruce Tonkin clarified that pursuant to discussion with the General Counsel's office, while the issue topic area was within ICANN's mission and core values, any proposed policy should likewise relate to the mission and the core values of ICANN. Marilyn Cade, seconded by Avri Doria proposed the motion, That Council approves the Terms of Reference for the policy development process on GNSO policies for contractual conditions for existing gTLDs (PDP-Feb06) as drafted with the insertion of the words "and core values" in the paragraph on "Goal" namely; "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 "and core values," that relate to the issues identified in the specific terms of reference below. 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 and core values, 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. The motion carried by roll call vote with 18 votes in favour, 6 votes against. Votes in favour: Philip Sheppard, Marilyn Cade, Grant Forsyth, (CBUC) Tony Holmes, Tony Harris, Greg Ruth, (ISPCPC) Norbert Klein, Mawaki Chango, (NCUC) Lucy Nichols (IPC) Maureen Cubberley, Sophia Bekele, Avri Doria, (Nominating committee appointees) Ross Rader, Tom Keller and Bruce Tonkin, (Registrar constituency each with a double vote) Votes against: Cary karp, Ken Stubbs and June Seo, (gTLD registries constituency each with a double vote). Absent: Robin Gross; absent with apologies: Ute Decker; Kiyoshi Tsuru had dropped off the call at the time of the vote. Decision 2 : That Council approves the Terms of Reference for the policy development process on GNSO policies for contractual conditions for existing gTLDs (PDP-Feb06) as drafted with the insertion of the words "and core values" in the paragraph on "Goal" namely; "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 "and core values," that relate to the issues identified in the specific terms of reference below. 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 and core values, 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. Item 3: Any other business 3.1 Update on Wellington The Secretariat reported that following the proposed draft schedule there would be an administrative session for councillors present on Friday afternoon, 24 March 2006 in the InternetNZ's office. On Saturday 25 and Sunday 26 March 2006, the new gTLD committee would work on policy issues related to new gTLDs.The GAC working group would meet with the GNSO for 2 hours on Sunday morning. There is a proposed working dinner involving the GNSO council and the ICANN board, not yet confirmed, on Sunday night, 25 March2006. Constituency day is scheduled for Monday 27 March. The GNSO Council Public Forum is scheduled for Wednesday, 29 March followed by the GNSO Council meeting on the same day. Bruce Tonkin thanked the council members and the London School of Economics team undertaking the GNSO review for their participation. The meeting ended: 21:10 UTC. Next GNSO Council teleconference 14 March 2006 at 19:00 UTC see: Calendar -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

PDP Dec 05 Document Problems: Please be careful
by Liz Williams 16 Mar '06

16 Mar '06

Colleagues We have had some problems with document versions from yesterday and probably this morning which mean that my two documents are not able to be opened correctly. Please watch for the posting of those two documents on the ICANN GNSO website and download from there. We will rectify technical problems as soon as we can. Liz ..................................................... Liz Williams Senior Policy Counselor ICANN - Brussels +32 2 234 7874 tel +32 2 234 7848 fax +32 497 07 4243 mob

2 2

Cont'd page 2 - Issues consideration for IDN ISSUE report
by Sophia B 16 Mar '06

16 Mar '06

Cont'd Finally, I truly believe *we need policy discussions first *and should at least consider for discussion the *Katoh-committee recommendations as a first step*. Sophia wrote> 3) I may be presumptuous, but ICANN's argument of resorting to > using DNAME seem to come from the perspective of how ICANN > failed to be responsive for long and now "China" and others > are threatening to "break the single root". Therefore, > perhaps, we were left to a single view and a quick solution, > neglecting to entertain the CHOICES we may have for IDN. So, > the easiest implementation approach is DNAME, which is is to > just give the big registries all the languages without having > to change much in the technical stuff - ie. just re-point.com > to every language equivalent - no new TLDs etc. John wrote: - Show quoted text - Actually, I think you misunderstand both the situation and the history. First, DNAMEs are, in Internet time, a relatively old proposal and protocol specification. I didn't invent them and neither did Verisign. Second, there was a proposal from the original ICANN IDN committee that no IDN TLDs be permitted in the root except on a separate application for new TLDs process. For an number of reasons --almost all of them consequences of how the DNS actually works and what is and is not possible as a result-- I still believe that was a wise recommendation, independent of anything China, Verisign, or others might "want" to do. Some of those who are still on the GNSO Council will probably remember that, because of issues with the number of languages in the world, I recommended that we try to sort out the use of IDNs at the second level and below in relevant ccTLDs before permitting them to be used at all... and recommended that several years before China made essentially the same suggestion (of course, by the time they made that suggestion, it was already too late since several gTLDs were doing production IDN registrations). Now, there has been a good deal of pressure from a number of directions to create aliases for country names in national languages. That pressure has actually been much more intense, with more threats, from other directions than from China. If an alias is what is really wanted and that alias must, for technical or political reasons, be in the root, then DNAMEs are the right way to do so. Other solutions are simply not aliases, they are separate domain names. To me, for separate domain names, the original IDN Committee/Katoh-san recommendation should still apply. As with IDNs below the top level and the "what languages" question, I understand the idea of an alias for a ccTLD in the relevant country's national language(s) much better than I understand what to do about gTLDs. Indeed, if I could make recommendations for the GNSO, I would seriously consider a recommendation that, at least for the next several years, the top-level IDN issue is, except for possible completely new applications domains with IDN-style names, entirely a ccTLD problem and that the gTLDs should not participate in any way in the evaluation of what is possible and reasonable other than continuing to register second-level IDNs under existing rules. Sophia wrote: I am aware that DNAMES has existed for a long time as a technical part of the DNS structure. You and Patrick pointed it out in your recent IETF document that was circulated. But you also point out DNAMEs was never really invented with IDN in mind and in fact there is some hesitancy for "borrowing" it for this purpose of IDN. From my crude understanding the reasoning appears to be it would be ideal not to use something for which it was not really intended. *In any case in my understanding the DNAMEs approach is being championed right now - it was not the case I believe in the previous 6 years of ICANN IDN history. *The Katon-committee didn't consider it after 3 years of IDN history at ICANN. If this thing has been around for as long as the Internet, then why all of a sudden this proposal is being championed - whatever the true reasons, it certainly has the suggestions of technical expediency in the face of potential external threats/pressure. *Well, its great that you bring up the Katoh-committee recommendations that you too seem to agree with *, and at some level these are against the grain of the direction in which a DNAMES like deployment would head - awarding incumbent existing gTLD registries equivalents. Saying that DNAMEs is just a technology and how it need not be given to existing registries in principle is true technically. But the real issue is that's where it is likely to head and that's why the POLICY needs to be discussed first. Why are we not even discussing them after having invested so much time and effort on their recommendation? *I understand that the Versign testbed was done badly and everybody acknowledges that* . Now when China came up with a solution they liked, it was already too late because we at ICANN had gone ahead and gone beyond "bad testbed' to actual production registrations under a few major commercial registries ( gTLDs and ccTLDs I guess) and it was too late to go back. Perhaps it is no little wonder that the same China and others are now forging their own path ahead. *So two mistakes - not just one - presumably all driven by the stronger commercial registries wanting to increase sales in their existing ascii TLDs by way of promoting somewhat insulting two-language/script hybrid domain names. * If there is pressure from other sources - other than China to move - would it not be useful or proper for those of us who believe policy issues are equally or more important than technical testing of fairly well-established technology (perhaps as old as the Internet you suggested for DNAMES) to know what these "pressures" are if we as members of various ICANN boards have to endorse the eventual policy chosen. No matter what the spin from wherever, it is abundantly clear that the current IDN activity within ICANN after 2 or 3 year relative hiatus, is happening because of considerable external pressure *. I am not sure I am speaking for all the GNSO members, but for my part I generally viewed the pressure from China as the biggest one while I have heard rumors of others and unhappiness from various other quarters *. If as you say the pressure from China is not the main one and there are multiple others, it would appear that we would need to discuss this pronto! *Could someone please share this with us? So that our job is NOT to simply endorse everything.** * Incidentally I would not be surprised if many of our board members learnt of the China deployed/commercial activity while reading a recent Wall Street Journal article. I have since learnt reliably that this activity was launched initially in a small way with full backing by their Ministry (published statements by Ministers) more than 4 years ago, and starting about 18 months ago it has been extensively deployed all over China. A large fraction of the 130M+ Chinese Internet population is already enabled-to use it and many tens of registrars have actually been selling these domains (which for all external purposes look like real IDN TLDs as described in the Wall Street Journal article) for well over a year and many tens of thousands of names registered and in use. A quick visit to the CNNIC web-site confirms all this. It would be *nice to know of these things earlier and* not from the likes of the Wall Street journal. Sophia wrote> John's statement butters this point: > > If a such programmer in China were to decide that, for her > users to have a good experience, .US and .COM should be able > to be referenced by using Chinese names, there is nothing that > the GNSO, ICANN, IETF, ITU, or the Great Pumpkin could do to > stop or prevent it. Even the control of the Chinese government > would be _extremely_ limited, since those Chinese names would > be visible only to users of that particular application with > that particular extension, and not "on the wire" or to either > DNS servers or the sites or hosts being reached. > > I think if this is the way we have looked at it, it seem that > our response is shortsighted (because it technical-oriented > only and did not consider the business issues) and is perhaps > why ICANN has failed achieve success in the IDN arena. > Instead of worrying about the political, policy and cultural > implications, first, we may have focused on the easy way > out...technical. In this case, contrary to what Cary said, I > think issuing DNAME is equally reckless as using new TLDs in > IDN. > The fact that the Chinese has already launched this process > (if we out to call them reckless) and ICANN who ought to know > better, is forced to 'follow' the same (can we call ICANN > "reckless") as well? Uhmm. John wrote: - Show quoted text - Again, please understand enough about how the DNS works, and how name resolution and applications on the Internet work more generally, to be able to understand what is said above. The Chinese have not already "launched" anything along the lines of what I suggested. That proposal is not "technical-oriented only" and does consider the business issues (even if the business and cultural issues it considers critical might not be the same ones you would choose). That proposal was actually almost exclusively focused on political, policy, and cultural issues -- many of the technical folks, who prefer a less complex world, actually don't like it. And that proposal is not, in any way, related to DNAMEs -- it is a third alternative. As to whether "issuing DNAME" is "equally reckless" as "using new TLDs in IDN" (whatever that means), I would, again, encourage you to understand what is being proposed and what its technical implications are, if only because doing so is prerequisite to talking intelligently about the business issues (or even most of the political and cultural ones). The "new domain" issues are simply a superset (a rather large superset) of those associated with DNAMEs. DNAMEs supply aliases but, as I pointed out long before the GNSO became actively concerned with this, one still needs to decide who gets which names and what they point to. New domains raise the much more complex issues of allocations and operation, and domain-specific policies as well as those of name selection and assignment, issues that are largely invisible from the DNAME case. Could one adopt a DNAME model and reserve names for later "independent TLD" allocation? Of course. Could one restrict the DNAMEs that would be associated with gTLDs to some limited set, or even to zero if that were felt to be wise? Of course. There is nothing that is "all languages in the world or nothing" about any of the proposals I have heard seriously raised. Sophia wrote> *Ok, pls correct me if I am wrong when I am trying to speak > DNAME implementation approach:* eg. CEO of mybrand.com has to > be protected in every language under a gTLD that means "com" > in every language, right ? meaning they have to come up with > 200 language translations of ".com" and ICANN can approve > DNAMES. John wrote: No, they do not. And the fact that they do not is actually one of the attractions of the DNAME approach (except to the registrars and registries who are anxious to mount "there is now another new domain in which you need to register to protect your brand... please send money" campaigns. _That_ approach requires separate domains). Sophia wrote> Then these companies, like Versign, can go and get > everyone of their.com name holders (40 million in this case) > names translated / transliterated into 200 languages to > everyone's satisfaction and register them all to get 200 x 45 > million DNAMES. *I hope I am on right track so far.* John wrote: No, you are not. Please read the comments above and, more important, please make an effort to understand how the DNS works in general and how DNAMEs work in particular. Sophia> Are they also going to charge the CUSTOMER (who has already paid > some $6 already) for the translation/transliteration work? > Also, if the customer then is upset by the accuracy of > translation or if the customer is sued by some other third > party saying that the wrong translation now impinges on their > own business, will VERISIGN pay for all lawsuit damages? I am > almost certain that these companies will NOT agree to this - > but this is the result of DNAMES. John wrote: No, it is not. Sophia> Finally, from where I see it, *policy is to be made first in > complex situations as these.* Technology is a second - fact is > these systems seem to have been working for years already, as > China seem to have has deployed it for years on a large scale > - far larger than anything ICANN has done to date, I believe. John wrote: No, China has done something else, and only relatively recently. Once you understand, throughly, how the DNS works and, in particular, the difference between the actions of a caching forwarder and a different TLD, I'll be happy to try to explain just what they are doing, and why, to you. ... Sophia wrote> Therefore, as Avil suggested, I propose the alternatives and > solution should be explored by a joint consultation with > relevant IDN circles and the Council. John wrote: Sure. As long as the capabilities and operations of the DNS are sufficiently well understood, and at a policy level, the range and scope of potential ICANN authority is reasonably well understood, that discussions of policies that imply flat earths and more convenient values of PI are avoided. Otherwise, while the discussions would certainly be interesting, the GNSO will waste its time and the world will ignore ICANN and move forward on its own path. Sophia wrote> I myself recommend the POLICY option. Go for a solution > letting the people speaking a specific language (or script as > they like to say) is a part of their culture – to take care > of it. We can talk about specific implementation strategies > once we agree with the policy option! ---- John wrote: First, the proposal that comes closest to the type of solution you seem to propose above is one that you have rejected out of hand. *Sophia wrote: *Answering each of your points in order* * *First,* I have come to understand that technical people tend to view things in only technically acceptable terms, and in this case multilingual domain names serving the need for non-English speakers to reach web-sites in their own character sets. *However, in my experience, in the real world - particularly so in disenfranchised parts of the world - often choices are made that cannot only be technically acceptable but they must also be "emotionally" acceptable*. My understanding is that for IDNs the peoples of the different languages would strongly prefer an approach where IDN TLDs in so much as possible mirror and be "parallel" to ASCII TLDs. (and saying ASCII is not English is a worthless argument that only the adamantly technical people insist on - the wise accept the emotional reality and work around it). Thus the "proposal I am to have rejected out of hand" lacks the emotional merits of IDN TLDs that work more in a "parallel" manner. And emotion has a lot do with it - one can build highly efficient and better designer homes but everyone still wants a "doll house" to live in. John wrote: ----Second, scripts and not the same as languages and people don't speak scripts: not understanding the difference can only increase your confusion. Sophia wrote: *Second*, *it is refreshing to know that there are knowledgeable individuals like you who work so hard to decrease the confusion of the less gifted like me.** * I suppose the fact that *the Amharic script* is used for various languages in Ethiopia and Somalia including *Amharic*, Tigre and Tigrinya by a mere 30 million or so people, all without the benefit of the great knowledge you have, must leave them all confused and speaking in twisted tongues and many languages at once, *just like me.* And I can only be ever so grateful for having escaped that many-language-to-one-script mess to speaking the one-script-to-one-language-English (even though I hear some rumors that some 200 million Indonesians may have borrowed it too*). *However, I admit I must also be not so good at English, since I cannot understand the phrase "scripts and not the same as languages" in your discussion above.** John wrote: --Third, as long as the DNS is to remain a global resource, a solution that involves letting those who speak a particular language to "take care of it" and go in their own direction is essentially impossible. Or, to put it differently, it is possible in only two ways: with client-level aliasing (which you have rejected) and with different DNS roots for each language group. The latter is inconsistent with both unambiguous global references on a global Internet and, by the way, with your having any possible hope of protecting your business name or trademark globally... except by legal action in each country in which a similar name might be used *Sophia wrote:* * Third,* the *notion of different roots for different languages is impossible you suggest*. But from my understanding recent reports suggest that some 100M + people in China (maybe accounting for some half of the world's truly IDN-needy population) have been enabled to do just that for over a few years, with no deaths or no calamities reported. I understand that you have been quoted in the press as suggesting that the Chinese are solving this by "appending" .cn in English characters and thus not really dealing with a different root. *However even the BBC quotes eminent Internet-aware professors and Cambridge university researchers as having tested the Chinese deployment and that there is much much, more to it than meets the eye (see links below) *and that the long-deployed system is in essence a different language root or very close to it. I also understand, that in past years, many technical people have talked about so-called multiple roots-of-authority - I believe these include prominent previous ICANN Board of Directors like Karl Auberach etc. I am puzzled why you think it's impossible, unless in a very very narrow sense but then again my lot in life seems to be always confused.** http://news.bbc.co.uk/1/hi/technology/4779660.stm http://news.bbc.co.uk/1/hi/technology/4767972. As for the "tragedy" that one would have to legally protect one's business names and trademarks as domain names in every sovereign country independently, I think that is exactly what we do with trademarks today and it would appear its no more onerous to protect one's domains in conjunction with trademark protection than just trademark protection, if your business needs that protection in country "x" (domains cost far less than trademark protection). *And I believe that is why sovereign-nation states exist.* Of course one can solve it all by simply globalizing the whole world into one federated galactic empire and put Captain Kirk in charge of it. And while at it, we could force everyone to learn English - then the problem simply goes away. Should have thought of that, far easier than solving these intractable technical problems that only the Chinese and certain largest-European ISPs like Tiscali seem to be rumored to be able to solve.

1 0