<<<
Chronological Index
>>> <<<
Thread Index
>>>
[registrars] FW: RRA Changes
- To: "Registrars Constituency" <registrars@xxxxxxxxxxxxxx>
- Subject: [registrars] FW: RRA Changes
- From: "Nevett, Jonathon" <jnevett@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 12 Dec 2006 11:47:17 -0500
- Importance: high
- Sender: owner-registrars@xxxxxxxxxxxxxx
- Thread-index: AccdarxS2NmS3yBrRj++c6qUOLG2BgAlOiwAAAEfRmAAAGlckAABHCqwAABXCIA=
- Thread-topic: RRA Changes
All: I just sent this note to VeriSign. I hope that VeriSign will
handle this issue shortly, but we are waiting until it is resolved
before taking any action with the draft agreement. Thanks. Jon
________________________________
From: Nevett, Jonathon
Sent: Tuesday, December 12, 2006 11:35 AM
To: Dahlquist, Raynor
Cc: 'mshull@xxxxxxxxxxxx'; 'Gomes, Chuck'; kurt.pritz@xxxxxxxxx
Subject: RRA Changes
Importance: High
Dear Raynor:
We received a letter yesterday from VeriSign dated December 6th
requesting that we execute an attached copy of the new
Registry-Registrar Agreement for the .com regsitry. The letter states
that the agreement provided is "the new ICANN approved .COM
Registry-Registrar Agreement that will take effect and supersede your
existing .COM Registry-Registrar Agreement with VeriSign, Inc on 30
December 2006."
In the abundance of caution, we compared the copy of the agreement
attached to the letter with the agreement actually approved by the ICANN
Board and the U.S. Department of Commerce as Exhibit 8 to the .com
Registry Agreement
(http://www.icann.org/topics/vrsn-settlement/revised-appendix8-clean-29j
an06.pdf), and there are both substantive and non-substantive
differences between the version VeriSign sent to us for execution and
the version approved by ICANN and the DOC. These changes include adding
various VeriSign-affiliated parties to the agreement.
I brought this situation to ICANN's attention. According to Kurt Pritz,
ICANN was aware of VeriSign's request to ICANN to make the substantive
and non-substantive changes, but stated in no uncertain terms that ICANN
has not "approved or adopted" any changes to the RRA as required in
Section 6.1. Therefore, VeriSign's statement that ICANN approved the
version of the agreement sent to us is false. Moreover, not only did
VeriSign misrepresent that it received ICANN approval to change the
agreement, it also failed to inform registrars of the changes from the
version posted on the ICANN website.
I find it remarkable that VeriSign would try to change the terms of the
RRA in this manner, regardless of the substance of the changes. This
kind of behavior is unacceptable and violates the terms and spirit of
our relationship. Indeed, we should be trying to engage in a period of
healing after the long and sometimes bitter dispute over the
advisability of the new .com registry agreement. Instead, VeriSign
apparently is engaging in deceptive and obfuscating behavior.
First, please let me know how you plan on rectifying this situation.
Second, we should discuss a procedure for making future changes to the
.com and .net RRAs so we don't continue to repeat this same scenario
every few years. As per the terms of the contract, ICANN must approve
any changes to the agreement. As a transparent organization, ICANN
should give the other party to the agreement - the registrars - an
opportunity to review and comment on proposed changes before they are
approved. It is irrelevant whether VeriSign or ICANN believes that such
changes are substantive. Any changes to a contract to which registrars
are a party should be shared with us before they are approved.
Something that may appear to be benign to ICANN or VeriSign might have
some unintended consequence to other parties to the agreement. Third,
if VeriSign does seek to change certain provisions of the agreement from
the version ICANN and the DOC recently approved, I suggest that it seek
to delete Section 6.15(a)(6), which still refers to a Surety Instrument
that VeriSign removed from all other parts of the contract.
I look forward to hearing back from you.
Best,
Jon
Jonathon L. Nevett
Vice President and Chief Policy Counsel
NetworkSolutions
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|