July 2005 - council - lists.icann.org

Re: [council] Registry services - consensus policy- dot net
by Marilyn Cade July 28, 2005

July 28, 2005

Dear colleagues: After considerable deliberation, reading the bylaws, and reading the desccription of our responsibility, I have concluded that I believe it is our reaponsibility to enact consensus policy in new registry services. therefore, tomorrow, I will make a motion that Council vote to approve the Council drafted version of new registry services. I welcome any questions on why I think that is both our responsibility to the community at large, the right thing for ICANN, and the best safequard for registries themselves. I will clarify the last point. When we established ICANN, we in the community took seriously the risk of gov't regulation in the gTLD space and. And we sought mechanisms to protect the registries from a patchwork of different national laws. As someone VERY familiar with that as a rep of a multi-national Tier I backbone/business ISP in multiple countries, along with others involved in newco, we wanted a framework of ind. Self governance, by contract and agreement of the Community. Consensus policy is a safeguard to the registries. As it is to the users, the registrars, and to the Internet as a whole. Marilyn Regards, Marilyn Cade

1 0

Re: [council] FW: the topic of new gTLDs and the role of gNSO Council
by Marilyn Cade July 27, 2005

July 27, 2005

Dear Avri, my personal views, at a. First read, are in short style below. Am on Blkberry. Limitation. Apologies for abrupt resp. Style. 1. NO. I consider this aberrant from my expectations as someone who participated in the concept of binding consensus policy. If the communities expectations of the role of consensus policy and its intregrity is different from bd, this gap needs to be closed. 2. Can't wait to read the doc. Can't open on blkberry. I would not recommend bd est policy. Is policy council job. 3. More on this tomorrow. Finally, this is a discussion that we should have. Well documented research athat gathers the history, as it seems staff has provided us supports the role and work of Council. Who owns policy mkg in this area, and shares some aspects in some areas, with others. I am on a train and will be home around midnight. I will read Olaf's document with great interest. Sounds like it is a contribution to Council's work. -----Original Message----- From: avri doria <avri(a)acm.org> Date: Wed, 27 Jul 2005 14:21:54 To:Olof Nordling <olof.nordling(a)icann.org>, Maria Farrell <maria.farrell(a)icann.org> Cc:"<council(a)gnso.icann.org>" <council(a)gnso.icann.org> Subject: Re: [council] FW: the topic of new gTLDs and the role of gNSO Council On 27 jul 2005, at 08.38, Olof Nordling wrote: > and here comes a first draft for your reading > enjoyment, see attachment. > > <Rationale for new TLDs.doc> Thank you. I have some initial questions on my first reading of this, very useful, synopsis. If any of these questions is naive, please forgive me. While very interesting, it is a lot to digest. And with the meeting tomorrow, I figured I better get my questions aired while there was still daylight somewhere. 1. The phrase "Where feasible and appropriate", and other similar exit clauses are used frequently. Is there some normalized way of making and substantiating a decision to deviate due to feasible and appropriate circumstances? Or is this completely at the board's discretion. I.e. can they deviate from the by-laws and consensus decisions whenever they, independently, decide that is is appropriate to do so? 2. I found it interesting that a policy body recommended that the Board establish a policy. On reading the recommendations themselves, they seemed to offer more guidelines for policy as opposed to specific policy recommendations. Is this the normal way in which the policy councils interact with the Board and Staff? Should it be? 3. The Yokahama minutes seem to indicate that this decision applies to a pilot or proof of concept. > The extent to which selection of the proposal would lead to an > effective "proof of concept" concerning the introduction of top-level > domains in the future, including the diversity the proposal would > bring to the program, such as fully open top level domains, restricted > and chartered domains with limited scope, noncommercial domains, and > personal domains; and a variety of business models and geographic > locations. Can this be read as indicating that at some point in the future, the concept would have been proved and a new policy would be established. Further, the DNSO council statement from 2000 indicates: > we recommend to the Board that a limited number of new top-level > domains be introduced initially and that the future introduction of > additional top-level domains be done only after careful evaluation of > the initial introduction. > Has this careful evaluation been done. And who is responsible for this evaluation? I would assume that following this evaluation, new policy recommendations might be reasonable. Is this the period for that evaluation? 4. from board minutes 31 July 2003 > Whereas ICANN is also committed to define and implement a predictable > strategy for selecting new gtlds using straightforward, transparent, > and objective procedures that preserve the stability of the Internet > (development of strategy is to be completed by September 30, 2004 and > implementation to commence by December 31, 2004). Has the strategy published 30 September 2004 been adopted? And if so, where are we in its timeline at present? I ask because the document still lists itself as a draft. In any case, it looks like the GNSO, ccNSO, and advsories have certain responsibilities between them in this process: - create and implement procedures for designation of TLD Registries - public explanation of the process - selection criteria - rationale for selection decisions. Is this what we are, or should be, in the midst of doing? Since the recommendations for the initial test run of TLD assignments has pretty much run its course, except perhaps for the final evaluation of success, are we at a point where we should be making policy recommendations for a fair, transparent and predictable ongoing process? Thanks a. Regards, Marilyn Cade

1 0

FW: the topic of new gTLDs and the role of gNSO Council
by Marilyn Cade July 27, 2005

July 27, 2005

Dear colleagues, My posting to the public forum on the new gTLD questions is posted below for your information. I look forward to the discussion on this topic on Thursday. I have just reread the relevant transcript of the Board's public forum to refresh my memory on the discussion. Of course, there is also the discussion that took place in our own meetings to inform our discussion on Thursday as well. _____ From: Marilyn Cade [mailto:marilynscade@hotmail.com] Sent: Tuesday, July 26, 2005 1:26 AM To: 'new-gtld-questions(a)icann.org' Cc: 'Kurt Pritz'; 'Paul Twomey'; 'Olof Nordling'; 'John Jeffrey'; 'Bruce Tonkin' Subject: the topic of new gTLDs and the role of gNSO Council This topic will be discussed at the gNSO Council meeting on Thursday, July 28. At Luxembourg, there were several discussions regarding the role of the gNSO in making policy for gTLDs and how the staff paper fits into that process. This topic came up in the board/council breakfast; in the Cross Constituency meeting with the Board, and in the public forum. In my view, as an elected BC rep to the gNSO Council, I consider the introduction of new gTLDs a policy issue for gTLD space. I believe that the gNSO Council should develop a working plan, and include in that plan the appropriate consultation with the community, other SOs, and advisory committees, including seeking any necessary external studies or advice to fully advise the development of policy in this area. Thus, I will not make substantive comments in this forum. I look forward to the discussion in the gNSO council on establishing a path forward to undertake the necessary work, which should include appropriate outreach and consultation with other entities, both internal and external, as appropriate.. Marilyn Cade

5 13

Re: [council] Registry services - consensus policy- dot net
by Marilyn Cade July 27, 2005

July 27, 2005

I propose we also understand how to limit this from perpetuating itself as well. Isn't that as essential and urgent task? -----Original Message----- From: <tony.ar.holmes(a)bt.com> Date: Wed, 27 Jul 2005 12:28:34 To:<philip.sheppard(a)aim.be>, <council(a)gnso.icann.org> Subject: RE: [council] Registry services - consensus policy- dot net I support Philips position on this Tony -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Philip Sheppard Sent: 27 July 2005 10:11 To: council(a)gnso.icann.org Subject: [council] Registry services - consensus policy- dot net Background Alick posted a request by Neustar for Council not to proceed with a consensus policy on registry services. The argument was that the new .net agreement is different and that would lead to unequal treatment. I am sympathetic to the argument but not to the proposed course of action. Let me explain why. Role of Council It is the role of Council to make consensus policy and that policy should be binding on all parties. We should continue to do this. Dot net agreement The dot net agreement has limitations with respect to the application of consensus policy to Registry Services (see below for clip from the .net agreement), and it establishes its own unique procedure for changes to Registry Services. This seems to be a fundamental corruption of the principle upon which consensus policy rests. It seems to be a violation of the raison d'etre of the GNSO Council itself. I believe this is the issue to discuss. Philip --------------------------------------------------- This seems to be the relevant section from the new .net agreement: Section 3.1 b.(iv) In addition to the other limitations on Consensus Policies, they shall not: (A) prescribe or limit the price of Registry Services; (B) modify the standards for the consideration of proposed Registry Services, including the definitions of Security and Stability (set forth below) and the standards applied by ICANN; (C) for three years following the Effective Date, modify the procedure for the consideration of proposed Registry Services; (D) modify the terms or conditions for the renewal or termination of this Agreement; (E) modify ICANNs obligations to Registry Operator under Section 3.2 (a), (b), and (c); (F) modify the limitations on Consensus Policies or Temporary Specifications or Policies; (G) modify the definition of Registry Services; (H) modify the terms of Sections 7.2 and 7.3, below; and {relates to pricing} (I) alter services that have been implemented pursuant to Section 3.1(d) of this Agreement (unless justified by compelling and just cause based on Security and Stability). Regards, Marilyn Cade

1 0

Re: [council] FW: the topic of new gTLDs and the role of gNSO Council
by Marilyn Cade July 27, 2005

July 27, 2005

Olaf, thanks. I know we started this request in Luxembourg, and it is good to get this. Unfortunately, am traveling. Have only blackberry. Will be online around 10 pm and will read it then. So I will be limited in ability to absorb. But will do my absolute best. Thanks. MsC -----Original Message----- From: "Olof Nordling" <olof.nordling(a)icann.org> Date: Wed, 27 Jul 2005 14:38:27 To:"'Marilyn Cade'" <marilynscade(a)hotmail.com>, "'Bret Fausett'" <bfausett(a)internet.law.pro>, <council(a)gnso.icann.org> Subject: RE: [council] FW: the topic of new gTLDs and the role of gNSO Council Marilyn and all, Indeed, you are SO right - the thought of such a compilation emerged at a contact with Bruce on Monday, and here comes a first draft for your reading enjoyment, see attachment. Regards Olof -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Marilyn Cade Sent: Wednesday, July 27, 2005 1:14 PM To: 'Bret Fausett'; council(a)gnso.icann.org Subject: RE: [council] FW: the topic of new gTLDs and the role of gNSO Council I believe that we are expecting some work from staff to help us look at what the present state of affairs: I would find it helpful to have a summary of what has been done: from board resolutions, to our resolutions, recommendations, and any policy we have created. That shouldn't be too hard to do from the records of the minutes, board minutes, board resolutions. I think we have our own record of minutes as well that contributes, and we have the transcripts from meetings, where in the public forums, it will be apparent what was discussed, and then what action was taken. Such a history, in summary form, in chronological order, should provide a summary for us to start from. Given all else that faces us as a Council, and my "day job", I find myself challenged to focus on this research personally, and look forward to the work of the staff that I believe has been requested. Before I engage in interpretation on what "we" have done so far, that summary will be needed. Make sense to others? -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Marilyn Cade Sent: Wednesday, July 27, 2005 12:00 AM To: 'Bret Fausett'; council(a)gnso.icann.org Subject: RE: [council] FW: the topic of new gTLDs and the role of gNSO Council Bret, I am not so sure that we did answer those questions. I thought we did proof of concept TLDs, and then sponsored gTLDS. /both were limited in their role in an overall consideration, but contribute lessons learned. -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Bret Fausett Sent: Tuesday, July 26, 2005 8:59 PM To: council(a)gnso.icann.org Subject: Re: [council] FW: the topic of new gTLDs and the role of gNSO Council My understanding is that the GNSO and the Board previously answered the question of whether we should have new gTLDs ("yes") and how they should be introduced ("in a measured and responsible manner"). So I would agree that insofar as those questions are concerned, we do no need to revisit the past. There are a number of areas, however, in which the GNSO could provide useful policy work. For instance, what escrow and data retention policy should new registries have to meet so that the damage to registrants of a registry failure can be minimized? But is that policy or implementation? I don't know that it matters much if we *want* to take it on. Perhaps we can use time on Thursday's call to list some of these things we'd like to see addressed. Bret Regards, Marilyn Cade

1 0

Posted to Council list on behalf of Jeff Neuman
by Alick Wilson July 27, 2005

July 27, 2005

-----Original Message----- From: Neuman, Jeff [mailto:Jeff.Neuman@neustar.us] Sent: Wednesday, 27 July 2005 1:24 p.m. To: bruce.tonkin(a)melbourneit.com.au; Bhavin Turakhia; Marilyn Cade; harris(a)cabase.org.ar; tony.ar.holmes(a)bt.com; Ken Stubbs; ck(a)nic.museum; pcolebrook(a)gnr.com; rader(a)tucows.com; grant.forsyth(a)team.telstraclear.co.nz; rader(a)tucows.com; Philip Sheppard; Thomas Keller; Alick. Wilson; robin(a)robingross.com; niklas_lagergren(a)mpaa.org; Maureen(a)asmconsultants.ca; ktsuru(a)bgmt.com.mx; lucy.nichols(a)nokia.com; Bret Fausett Cc: Secretariat(a)gnso.icann.org; jeffrey(a)icann.org; pritz(a)icann.org; twomey(a)icann.org; Tina Dam; Drazek, Keith; Neuman, Jeff Subject: All, I am sending this note to as many members of the GNSO Council as I have e-mail addresses for. I do not mind if someone reposts this to the Council list. I would do so, but am unable to post to that list. I noticed the following item on the GNSO Council Agenda: Item 8: Consideration of final report on process for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture operation of a gTLD registry. - for decision NeuLevel was an initial supporter of the process set out in the final report. However, circumstances have changed completely in the past month or so with the signing of the .net Agreement. As you all know, the .net agreement sets out its own process for considering requests for consent and related contractual amendments to allow changes in the architecture operation of a gTLD registry. Although there are some similarities, there are also a number of significant differences. Unfortunately, the public comment period on this subject closed prior to the .net Agreement being posted. I believe that any process other than a carbon copy of the process set forth in the current executed .net agreement with VeriSign is unacceptable. A policy as important as the one contained in the final report that applies only to some registries and not the others (i.e., .net) is fundamentally unfair as well as anti-competitive. We believe that adopting any process other than what is in the .net agreement, would single out those other registries "for disparate treatment" in violation of Section 2.1 of the unsponsored TLD Agreements as well as ICANN's bylaws to promote competition. Section 2.1 of the Unsponsored Agreements provide: "2.1. General Obligations of ICANN. With respect to all matters that affect the rights, obligations, or role of Registry Operator, ICANN shall during the Term of this Agreement: 2.1.1. exercise its responsibilities in an open and transparent manner; 2.1.2. not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition; 2.1.3. not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause; and . . . ." I ask that the Council and the ICANN staff consider the above before making any decisions on this matter. I would be happy to discuss this matter further with any or all of you. Jeffrey J. Neuman, Esq. Director, Law & Policy NeuStar, Inc. Loudoun Tech Center 46000 Center Oak Plaza Building X Sterling, VA 20166 p: (571) 434-5772 f: (571) 434-5735 e-mail: Jeff.Neuman(a)Neustar.us The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.

4 4

Updated consensus recommendation on improving notification to Registered Name Holders of the public access to contact data via the WHOIS service
by Bruce Tonkin July 27, 2005

July 27, 2005

Hello All, I have updated the consensus recommendation proposal that I posted on 25 June 2005 (following a GNSO Council meeting) based on feedback received from members of the IP constituency and registrars. (1) I have added an explicit reference to RAA Clause 3.7.7.5 as requested by Niklas Lagergren in the GNSO Council meeting in Luxembourg (at the end of the (I) Background). (2) In the (II) Problem statement (second paragraph after ICANN mission and values) - I have made the language a bit more neutral regarding the expectations of registrants regarding public access to information - without implying that registrants at some locations may behave differently from those at other locations with different laws. I have also improved the wording of the following paragraph to make it clearer that a registrant may provide a range of information to a registrar, but that the registrant should be clear as to which pieces of data will be made public. (3) In (III) the Proposed Consensus Recommendation, I have clarified that ICANN will provide information on best practices for making the WHOIS requirements clear in the registration agreement. Regards, Bruce Tonkin (I) Background =============== The obligations of a registrar are governed by the Registrar Accreditation Agreement (RAA) (http://www.icann.org/registrars/ra-agreement-17may01.htm) and ICANN consensus policies (http://www.icann.org/general/consensus-policies.htm) The obligations of a Registered Name Holder (Registrant) is governed by an electronic or paper registration agreement with the Registrar. Each Registrar's agreement is different, and Registered Name Holders (or their agents) should review each agreement when making their choice of Registrar. A registrar is obligated by the RAA to require a Registered Name Holder to agree to provide to the registrar accurate and reliable contact details and promptly correct and update them during the term of the Registered Name registration (clause 3.7.7.1 of the RAA). A registrar is obligated by the RAA to, at its expense, provide an interactive web page and a port 43 Whois service providing free public query-based access to up-to-date (i.e., updated at least daily) data concerning all active Registered Names sponsored by the Registrar (clause 3.3.1 of the RAA). In addition a Registrar must provide third-party bulk access to the data (clause 3.3.6 of the RAA). A registrar is obligated by the RAA (clause 3.7.7.4) to provide notice in the registration agreement with the Registered Name Holder stating: (a) The purposes for which any Personal Data collected from the applicant are intended; (b) The intended recipients or categories of recipients of the data (including the Registry Operator and others who will receive the data from Registry Operator); (c) Which data are obligatory and which data, if any, are voluntary; and (d) How the Registered Name Holder or data subject can access and, if necessary, rectify the data held about them. A registrar is also obligated by the RAA (clause 3.7.7.5) to obtain consent from the registrant to the data processing described above (clause 3.7.7.4). (II) Problem statement with respect to ICANN's mission and Core Values ===================================================================== >From Article 1, Section 1 of the ICANN Bylaws (http://www.icann.org/general/bylaws.htm#I ): "The mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems. In particular, ICANN: 1. Coordinates the allocation and assignment of the three sets of unique identifiers for the Internet, which are a. Domain names (forming a system referred to as "DNS"); b. Internet protocol ("IP") addresses and autonomous system ("AS") numbers; and c. Protocol port and parameter numbers. 2. Coordinates the operation and evolution of the DNS root name server system. 3. Coordinates policy development reasonably and appropriately related to these technical functions." In addition one of ICANN's core values is: "Preserving and enhancing the operational stability, reliability, security, and global interoperability of the Internet." (Core value 1, from Article 1, section 2) The problem with the current system is that although registrars are required to include information in the registration agreement on the purposes for which data is collected and the intended recipients of the data, the information is often hard to find in long agreements, and often the information does not explicitly explain that personal data is freely available to third parties via the WHOIS service (for example sometimes a registrar makes a general statement such as that the information is provided to third parties in accordance with ICANN policies). Some registrants would not expect their personal data to be used for anything other than the registration and renewal of a domain name, and the authentication of an entity claiming to be the registrant. Where data is made public, registrants may expect to be able to opt-out of public display of the information. The lack of knowledge amongst Registered Name Holders can lead to security problems for domain names. Registered Name Holders may provide Personal information to companies that can be used by those companies for authentication (for example home billing address), and separately provide public information (such as post office box and business telephone number, typically via websites, whitepages and yellow pages services) suitable for third parties to contact the Registered Name Holders. Without an understanding of which information will be made public via the WHOIS service, a Registered Name Holder may be inadvertently releasing information to the public normally used for authentication. If a Registered Name Holder inadvertently provides information to a registrar for public display, this may assist domain name hijackers (and those using stolen credit cards) to pretend to be the Registered Name Holder. An improved understanding by Registered Name Holders of the purpose of WHOIS and the data elements displayed in the WHOIS service may improve the security and stability of the DNS. Thus the problem falls under the ICANN mission, and in particular the first core value. (III) Proposed Consensus Recommendation ======================================= (1) Registrars must provide notice in the registration agreement with the Registered Name Holder that is easy to find, clear, and conspicuous within the registration agreement stating: (a) The purposes of the WHOIS service, which consists of the provision of an interactive web page and a port 43 Whois service providing free public query-based access to up-to-date (i.e., updated at least daily) data concerning all active Registered Names sponsored by the Registrar. In addition the WHOIS service includes the provision of third-party bulk access to the data. (b) The purposes of the Registered Name Holder, technical, and administrative contacts (c) Which of the contact data in (b) will be made public via the WHOIS service in (a). (2) ICANN must provide on its website information on industry best practice to meet the obligation in (1) above. The proposed recommendation will help ensure that Registered Name Holders are more fully informed about registrar data handling practices and obligations, and that they provide current and accurate contact information that is appropriate for public access and sufficient for third parties to contact them in accordance with the purposes of the WHOIS service. The purposes will be refined as part of the current WHOIS task force work. Information (which may include Personal Data) that can be used for authentication and billing purposes may be separately provided to registrars.

1 0

RE: [council] Registry services - consensus policy- dot net
by tony.ar.holmes＠bt.com July 27, 2005

July 27, 2005

I support Philip's position on this Tony -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Philip Sheppard Sent: 27 July 2005 10:11 To: council(a)gnso.icann.org Subject: [council] Registry services - consensus policy- dot net Background Alick posted a request by Neustar for Council not to proceed with a consensus policy on registry services. The argument was that the new .net agreement is different and that would lead to unequal treatment. I am sympathetic to the argument but not to the proposed course of action. Let me explain why. Role of Council It is the role of Council to make consensus policy and that policy should be binding on all parties. We should continue to do this. Dot net agreement The dot net agreement has limitations with respect to the application of consensus policy to Registry Services (see below for clip from the .net agreement), and it establishes its own unique procedure for changes to Registry Services. This seems to be a fundamental corruption of the principle upon which consensus policy rests. It seems to be a violation of the raison d'etre of the GNSO Council itself. I believe this is the issue to discuss. Philip --------------------------------------------------- This seems to be the relevant section from the new .net agreement: Section 3.1 b.(iv) In addition to the other limitations on Consensus Policies, they shall not: (A) prescribe or limit the price of Registry Services; (B) modify the standards for the consideration of proposed Registry Services, including the definitions of Security and Stability (set forth below) and the standards applied by ICANN; (C) for three years following the Effective Date, modify the procedure for the consideration of proposed Registry Services; (D) modify the terms or conditions for the renewal or termination of this Agreement; (E) modify ICANN's obligations to Registry Operator under Section 3.2 (a), (b), and (c); (F) modify the limitations on Consensus Policies or Temporary Specifications or Policies; (G) modify the definition of Registry Services; (H) modify the terms of Sections 7.2 and 7.3, below; and {relates to pricing} (I) alter services that have been implemented pursuant to Section 3.1(d) of this Agreement (unless justified by compelling and just cause based on Security and Stability).

1 0

RE:
by Marilyn Cade July 27, 2005

July 27, 2005

Dear Jeff, I find this of interest, and do appreciate your posting it to us. I've copied Council. Others may have as well. Your point has been the topic of discussions I've raised with a variety of players. I am presently intending to vote in support of the new registry procedures. Let me explain why. I am not satisfied that the contract negotiations should "trump" consensus policy. I am under the impression that was a tactic agreement with the community/and I apparently thought, that the bylaws supported that. I'm disappointed, to frustrated, to learn otherwise. However, I have asked our chair/staff to arrange for the General Counsel to advise us on to whom the consensus policy will apply: further new sponsored gTLDS; reauthorizations/.com? I don't know if that will be tomorrow, but I agree time Is limited. _____ From: Neuman, Jeff [mailto:Jeff.Neuman@neustar.us] Sent: Tuesday, July 26, 2005 9:24 PM To: bruce.tonkin(a)melbourneit.com.au; Bhavin Turakhia; Marilyn Cade; harris(a)cabase.org.ar; tony.ar.holmes(a)bt.com; Ken Stubbs; ck(a)nic.museum; pcolebrook(a)gnr.com; rader(a)tucows.com; grant.forsyth(a)team.telstraclear.co.nz; rader(a)tucows.com; Philip Sheppard; Thomas Keller; Alick. Wilson; robin(a)robingross.com; niklas_lagergren(a)mpaa.org; Maureen(a)asmconsultants.ca; ktsuru(a)bgmt.com.mx; lucy.nichols(a)nokia.com; Bret Fausett Cc: Secretariat(a)gnso.icann.org; jeffrey(a)icann.org; pritz(a)icann.org; twomey(a)icann.org; Tina Dam; Drazek, Keith; Neuman, Jeff Subject: All, I am sending this note to as many members of the GNSO Council as I have e-mail addresses for. I do not mind if someone reposts this to the Council list. I would do so, but am unable to post to that list. I noticed the following item on the GNSO Council Agenda: Item 8: Consideration of final report on process for use by ICANN in considering requests for consent and related contractual amendments to allow changes in the architecture operation of a gTLD registry. - for decision NeuLevel was an initial supporter of the process set out in the final report. However, circumstances have changed completely in the past month or so with the signing of the .net Agreement. As you all know, the .net agreement sets out its own process for considering requests for consent and related contractual amendments to allow changes in the architecture operation of a gTLD registry. Although there are some similarities, there are also a number of significant differences. Unfortunately, the public comment period on this subject closed prior to the .net Agreement being posted. I believe that any process other than a carbon copy of the process set forth in the current executed .net agreement with VeriSign is unacceptable. A policy as important as the one contained in the final report that applies only to some registries and not the others (i.e., .net) is fundamentally unfair as well as anti-competitive. We believe that adopting any process other than what is in the .net agreement, would single out those other registries "for disparate treatment" in violation of Section 2.1 of the unsponsored TLD Agreements as well as ICANN's bylaws to promote competition. Section 2.1 of the Unsponsored Agreements provide: "2.1. General Obligations of ICANN. With respect to all matters that affect the rights, obligations, or role of Registry Operator, ICANN shall during the Term of this Agreement: 2.1.1. exercise its responsibilities in an open and transparent manner; 2.1.2. not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition; 2.1.3. not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause; and . . . ." I ask that the Council and the ICANN staff consider the above before making any decisions on this matter. I would be happy to discuss this matter further with any or all of you. Jeffrey J. Neuman, Esq. Director, Law & Policy NeuStar, Inc. Loudoun Tech Center 46000 Center Oak Plaza Building X Sterling, VA 20166 p: (571) 434-5772 f: (571) 434-5735 e-mail: Jeff.Neuman(a)Neustar.us The information contained in this e-mail message is intended only for the use of the recipient(s) named above and may contain confidential and/or privileged information. If you are not the intended recipient you have received this e-mail message in error and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately and delete the original message.

1 0

RE: GNSO Council call Thursday 28 July Dial-in details
by Lucy.Nichols＠nokia.com July 26, 2005

July 26, 2005

Bruce- I would like to add WIPO-II to the agenda for this Thursday's Council Call. I noticed from the GAC's Communique from Luxembourg that, notwithstanding the outstanding report from the ICANN staff on the issue, it "encourages ICANN to proceed swiftly towards implementing these recommendations." It would be useful to know from the ICANN staff what work if any has been completed on the report. It would also be worthwhile to discuss whether or not the Council should take affirmative action on this issue rather than wait for the Staff report. Regards, Lucy >-----Original Message----- >From: ext GNSO.SECRETARIAT(a)GNSO.ICANN.ORG >[mailto:gnso.secretariat@gnso.icann.org] >Sent: Thursday, July 21, 2005 2:17 AM >To: Nichols Lucy (Nokia/Dallas) >Subject: GNSO Council call Thursday 28 July Dial-in details > >Dear Lucy, > >There will be a GNSO Council call on Thursday, 28 July 2005, >at 12:00 UTC. If you are not able to attend, please let me >know who has your proxy. See below for the agenda. > >Dial-in information: > >USA Toll Free Number: 800-475-0212 >USA Toll Number: +1-210-234-0004 >(UIFN) + 800-3537-6216 >(See below for UIFN international access codes and carriers.) >LEADER: MS GLEN DE SAINT GERY >PASSCODE: COUNCIL > > For security reasons, the passcode and the leader's name >will be required to join your call. > > UIFN INTERNATIONAL ACCESS CODES & CARRIERS > ========================================== > Country Access Code Carrier > AUSTRALIA 0011 OPTUS > AUSTRALIA 0011 TELSTRA > BELGIUM 00 BELGACOM > DENMARK 00 TELE DANMARK > FRANCE 00 FRANCE TELECOM > GERMANY 00 DEUTSCHE TELECOM > HONG KONG 001 HONG KONG TELECOM > HONG KONG 001 PCCW > IRELAND 00 TELECOM IRELAND > JAPAN 001 KDDI > JAPAN 0033 NPT > JAPAN 0061 C&W IDC > JAPAN 0041 JAPAN TELECOM > MALAYSIA 00 TELECOM MALAYSIA > MALAYSIA 53 ITFS > NEW ZEALAND 00 TELECOM NEW ZEALAND > SINGAPORE 001 SINGAPORETEL > SWITZERLAND 00 SWISS TELECOM > UNITED KINGDO 00 BT > UNITED KINGDO 00 CABLE AND WIRELESS > >(5:00 Los Angeles, 8:00 Washington DC, 14:00 Brussels, 22:00 Melbourne) > >Draft Agenda >Item 1: Approval of minutes > >Item 2: Staff report >- legal text for WHOIS recommendation >- policy status of new gTLDS (review Board and GNSO Council decisions) >- summary of public comments received during the GNSO Public Forum > >Item 3: Actions arising from ICANN Board meeting >- domain name hijacking report >- GNSO review > >Item 4: Actions arising from IDN workshop >- Cary Karp to request any action required from the GNSO Council > >Item 5: Actions arising from GNSO Public Forum in Luxembourg > >Item 6: Creation of working group to review implementation of >current WHOIS policies related to Accuracy (e.g WHOIS data >reminder policy, and WHOIS problem reporting system) >- Niklas Lagergren proposed as chair >(note this would be a similar process to that used to review >the implementation/compliance with the transfers policy) > >Item 7: Consideration of revised consensus recommendation with >respect to improving notification and consent for the use of >contact data in the Whois system >- updated text due from Bruce Tonkin in response to comments >received so far >- legal text required from ICANN legal team > >Item 8: Consideration of final report on process for use by >ICANN in considering requests for consent and related >contractual amendments to allow changes in the architecture >operation of a gTLD registry. >- for decision > >Item 9: Any other business > >Thank you. >Kind regards, > >Glen de Saint Géry >GNSO Secretariat - ICANN >gnso.secretariat[at]gnso.icann.org >http://gnso.icann.org >

1 0