Posted to Council list on behalf of Jeff Neuman
-----Original Message----- From: Neuman, Jeff [mailto:Jeff.Neuman@neustar.us] Sent: Wednesday, 27 July 2005 1:24 p.m. To: bruce.tonkin@melbourneit.com.au; Bhavin Turakhia; Marilyn Cade; harris@cabase.org.ar; tony.ar.holmes@bt.com; Ken Stubbs; ck@nic.museum; pcolebrook@gnr.com; rader@tucows.com; grant.forsyth@team.telstraclear.co.nz; rader@tucows.com; Philip Sheppard; Thomas Keller; Alick. Wilson; robin@robingross.com; niklas_lagergren@mpaa.org; Maureen@asmconsultants.ca; ktsuru@bgmt.com.mx; lucy.nichols@nokia.com; Bret Fausett Cc: Secretariat@gnso.icann.org; jeffrey@icann.org; pritz@icann.org; twomey@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@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.
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).
I believe that it will be helpful to have the General Counsel join us for a segment of our call, in order for us to discuss very pragmatically, what the options are. IT is important to understand the following: [perhaps this is only a partial list and others would want to help to develop the questions we need answered]: * What is the situation in terms of the impact of the negotiated terms in the .net agreement on other contracts, including .com? * What is the role of consensus policy related to the .net agreement in the two areas where it appears that there is variance: definition of security and stability, and consensus policy on new registry services: e.g., is there a time lapse when consensus policy, whatever it is, again is in force? * Are other registries actually disadvantaged by being subject to consensus policy in a way that is "disparate" as suggested in Mr. Neuman's email. * I do appreciate receiving it, and thank Alick for forwarding it to Council. The subject has been much on my mind since Luxembourg. And I've spent a good deal of time on this item, including reading contracts, and looking for information in different agreements. I may say more about the support that is needed for Council in the area of legal advice on our call. However, since we have discussed this point previously with senior management, perhaps it is only necessary to gently mention it. I will say only that I feel a sense of deep disappointment about where we are in this situation, after being quite impressed by the hard work of the Council/Chair on this rather arduous, in depth, and detailed amount of work in developing a balanced process. These are NOT circumstances where I expect, ever again, to find Council. I expect better. And assume the "collective we" will strive for better. However, having said that, I want to fully understand Council's options, and the implications of where we are. Creating balanced policy is our job. And understanding the implications and parameters of our options is as well. That takes supportive activity from the staff. Thus, we need the General Counsel, or the deputy on the call to provide clarifications. My initial questions are above. The clearer we can be on our questions, the quicker we can get through the background and legal clarification we need, and the quicker we can get to the discussion of the policy and our vote. _____ From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Philip Sheppard Sent: Wednesday, July 27, 2005 5:11 AM To: council@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).
Dear all, Unfortunately the ICANN legal counselo will be unable to join us on tomorrow's Council call. John and Dan are both fully engaged with the Board call which is running simultaneously. They will be happy to provide any requested response to the Council, and the usefulness of that response will be helped by them having clear questions to respond to. The questions Marilyn raises are very helpful in that regard. Do other Council members have further questions? The staff are, as always, committed to fully supporting the policy development process. Having targetted and specific questions helps our legal counsel to provided considered and authoritative answers. I cannot commit to my colleagues' ability to produce answers to these questions within 24 hours, but we will certainly endeavour to get a thorough answer to the Council as quickly as possible. I can tell you more about the timing when the Marina del Rey office comes online later on today. All the best, Maria _____ From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Marilyn Cade Sent: Wednesday, July 27, 2005 1:04 PM To: 'Philip Sheppard'; council@gnso.icann.org; Bruce Tonkin Cc: John Jeffrey Subject: RE: [council] Registry services - consensus policy- dot net I believe that it will be helpful to have the General Counsel join us for a segment of our call, in order for us to discuss very pragmatically, what the options are. IT is important to understand the following: [perhaps this is only a partial list and others would want to help to develop the questions we need answered]: * What is the situation in terms of the impact of the negotiated terms in the .net agreement on other contracts, including com? * What is the role of consensus policy related to the .net agreement in the two areas where it appears that there is variance: definition of security and stability, and consensus policy on new registry services: e.g., is there a time lapse when consensus policy, whatever it is, again is in force? * Are other registries actually disadvantaged by being subject to consensus policy in a way that is "disparate" as suggested in Mr. Neuman's email. * I do appreciate receiving it, and thank Alick for forwarding it to Council. The subject has been much on my mind since Luxembourg. And I've spent a good deal of time on this item, including reading contracts, and looking for information in different agreements. I may say more about the support that is needed for Council in the area of legal advice on our call. However, since we have discussed this point previously with senior management, perhaps it is only necessary to gently mention it. I will say only that I feel a sense of deep disappointment about where we are in this situation, after being quite impressed by the hard work of the Council/Chair on this rather arduous, in depth, and detailed amount of work in developing a balanced process. These are NOT circumstances where I expect, ever again, to find Council. I expect better. And assume the "collective we" will strive for better. However, having said that, I want to fully understand Council's options, and the implications of where we are. Creating balanced policy is our job. And understanding the implications and parameters of our options is as well. That takes supportive activity from the staff. Thus, we need the General Counsel, or the deputy on the call to provide clarifications. My initial questions are above. The clearer we can be on our questions, the quicker we can get through the background and legal clarification we need, and the quicker we can get to the discussion of the policy and our vote. _____ From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Philip Sheppard Sent: Wednesday, July 27, 2005 5:11 AM To: council@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).
Further to Maria's invitation to post specific questions for ICANN's GC let me add one further question to the three (repeated 1,2,3 below) already asked by Marilyn Cade. Questions 1. What is the situation in terms of the impact of the negotiated terms in the .net agreement on other contracts, including .com? 2. What is the role of Consensus Policy related to the .net agreement in the two areas where it appears that there is variance: definition of security and stability, and Consensus Policy on new registry services: e.g., is there a time lapse when consensus policy, whatever it is, again is in force? 3. Are other registries actually disadvantaged by being subject to Consensus Policy in a way that is "disparate" as suggested in Mr. Neuman's email? ------- 4. The GNSO Council wants to fulfil its duty under the by-laws to develop Consensus Policy in good faith. How do you advise the GNSO Council to proceed, if there will indeed be a potential competitive variance between the treatment of the .net registry and others, with respect to the GNSO Council's current PDP on Registry Services? Philip
participants (4)
-
Alick Wilson -
Maria Farrell -
Marilyn Cade -
Philip Sheppard