[council] Registry services - consensus policy- dot net

tony.ar.holmes at bt.com tony.ar.holmes at bt.com
Wed Jul 27 11:28:34 UTC 2005


I support Philip's position on this

 

Tony

-----Original Message-----
From: owner-council at gnso.icann.org [mailto:owner-council at gnso.icann.org]
On Behalf Of Philip Sheppard
Sent: 27 July 2005 10:11
To: council at 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). 

  
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20050727/98e3342e/attachment.html>


More information about the council mailing list