<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [council] Registry services - consensus policy- dot net
- To: "'Marilyn Cade'" <marilynscade@xxxxxxxxxxx>, "'Philip Sheppard'" <philip.sheppard@xxxxxx>, <council@xxxxxxxxxxxxxx>, "'Bruce Tonkin'" <bruce.tonkin@xxxxxxxxxxxxxxxxxx>
- Subject: RE: [council] Registry services - consensus policy- dot net
- From: "Maria Farrell" <maria.farrell@xxxxxxxxx>
- Date: Wed, 27 Jul 2005 14:14:26 +0200
- Cc: "'John Jeffrey'" <jeffrey@xxxxxxxxx>
- In-reply-to: <BAY104-DAV17A3A30A8667BE77323C95D3CC0@phx.gbl>
- Sender: owner-council@xxxxxxxxxxxxxx
- Thread-index: AcWSW2aLCrr7TSv4TVeVIPpk0iwaHwAIAa/wAAdpMcAAAopMMA==
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@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] On
Behalf Of Marilyn Cade
Sent: Wednesday, July 27, 2005 1:04 PM
To: 'Philip Sheppard'; council@xxxxxxxxxxxxxx; 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@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx] On
Behalf Of Philip Sheppard
Sent: Wednesday, July 27, 2005 5:11 AM
To: council@xxxxxxxxxxxxxx
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).
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|