ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

[registrars] Registrars Statement on .com agreement

  • To: <registrars@xxxxxxxxxxxxxx>
  • Subject: [registrars] Registrars Statement on .com agreement
  • From: "Nevett, Jonathon" <jnevett@xxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 22 Nov 2005 09:00:21 -0500
  • Sender: owner-registrars@xxxxxxxxxxxxxx
  • Thread-index: AcXp610Fl4yr7Nv6RK6jYaiFojuf/gAAK+0wAQJVcTAAE+x54AA00e0gABTeLKA=
  • Thread-topic: Registrars Statement on .com agreement

Registrar Colleagues:

 

The Registrar Constituency .com Working Group set up by Bhavin has
drafted the following statement.  Please feel free to sign on to the
statement and to post it to the ICANN website -- to post comments,
please send an e-mail to: settlement-comments@xxxxxxxxx.

 

Thanks.

 

Jon      

 

We, the undersigned registrars, recommend against ICANN signing the

proposed .com Registry Agreement.   The following reflects those issues

that are of foremost concern to registrars:

 

 

1.    New Registry Services 

 

The proposed .com contract locks ICANN and VeriSign in for three years

on a version of the consensus policy covering the standards and process

for consideration of new registry services.  The new registry services

consensus policy process that recently was approved by the ICANN board

is untested, and it is likely that the ICANN community will need to

refine and improve it after it is implemented.  A three year lock will

unnecessarily handcuff ICANN and the ICANN community.

 

We recommend the deletion of Sections 3.1(b)(v)(B) and 3.1(b)(v)(C), and

allowing the existing ICANN policy development and refinement process to

be used during the term of the agreement.

 

 

2.    Registry Agreement Renewal

 

According to its own Bylaws and the Memorandum of Understanding between

ICANN and the United States Department of Commerce, one of ICANN's core

missions is to promote competition.  We understand that the current .com

contract contains a "presumptive renewal" provision, which by its nature

hinders competition.  The proposed .com contract, however, goes much

farther than the existing contract by strengthening the presumptive

renewal and termination provisions on behalf of VeriSign, thereby making

it virtually impossible for VeriSign to lose the .com registry and

impossible to reap the benefits of competition.  VeriSign should be

appointed as the administrator of the .com registry, not its owner.

 

We recommend reverting from Section 4.2 of the proposed .com agreement

to the renewal terms of Section 25 of the current .com agreement, which

requires a six month review of a "Renewal Proposal" provided by VeriSign

and only under terms that are in "substantial conformity with the terms

of registry agreements between ICANN and operators of other open TLDs.

. ."   ICANN also should strengthen the termination provisions currently

contained in Section 6.1 of the proposed agreement by using the relevant

text from Sections 16(B-E) of the current agreement.

 

 

3.    Registry Fees

 

The proposed .com contract would permit VeriSign to unilaterally raise

registration fees by 7% per year.  The existing .com contract and all

gTLD registry agreements (other than the .net agreement with VeriSign,

which was entered into without community input in violation of ICANN's

Bylaws) require the registries to cost-justify any price increases.  In

an industry where the economics suggest that fees should be going down

when there is competition, it is particularly troublesome and

anti-competitive to grant a monopolist or a single source provider the

unilateral right to increase costs without justification.

Unfortunately, these fee increases would result in cost increases to

individual registrants.  We note that in the recent competitive process

for .net, VeriSign significantly lowered its registry fees.  There is no

reason for unilateral cost increases for the larger .com registry.   

 

We recommend that the Board delete the current text of Section

7.3(d)(ii) and replace it with Section 22(A) of the current .com

agreement requiring VeriSign to justify and ICANN to approve any

proposed fee increase.  If there is a dispute between ICANN and VeriSign

over a cost increase, ICANN should have the right to seek competitive

price proposals from other registry operators to ensure that the ICANN

community receives the benefits of competition.

 

 

4.    New ICANN Fees

 

ICANN and VeriSign propose a new ICANN fee that would be assessed on

VeriSign and passed on to the registrars.  This fee would result in

excess of approximately $150 million dollars to ICANN, and would be an

end run around the existing ICANN budget approval process.  As proposed,

ICANN staff has removed an important check on the ICANN budget process.

All ICANN fees that impact registrants should be subject to the ICANN

budget approval process and should not only be the subject of

negotiations between VeriSign and ICANN.   

 

In addition to the changes suggested in number 3 above, we recommend the

removal of Sections 7.3(g-h) in the proposed contract.  Any transaction

fees that ICANN needs to collect from registrars (and hence registrants)

should be assessed through the current transaction fees charged by ICANN

to registrars and be subject to the existing budget approval process.

 

 

While we understand the desire to finalize the litigation, it should not

be done so without a sufficient review process nor at the expense of

major tenets of ICANN's mission.  In its current form, it is a bad

settlement for ICANN, the ICANN community, and the public-at-large.  We,

therefore, urge the ICANN Board to take advantage of the six month

review of a "Renewal Proposal" contemplated in the existing .com

agreement, which doesn't expire until November 2007.  The Board should

use this time to review the complicated contracts in their entirety,

have a public comment period commensurate with the importance of the

issue, and make the changes necessary to improve the agreement.



<<< Chronological Index >>>    <<< Thread Index >>>