EXHIBIT 10.26

REGISTRY AGREEMENT

This REGISTRY AGREEMENT (this “Agreement”) is entered into by and between the
Internet Corporation for Assigned Names and Numbers, a California nonprofit
public benefit corporation (“ICANN”), and VeriSign, Inc. a Delaware corporation.

WHEREAS, the parties wish to work together cooperatively to promote and
facilitate the security and stability of the Internet and the DNS, and to that
end, hereby agree as follows:

ARTICLE I INTRODUCTION

Section 1.1 Effective Date. The effective date (“Effective Date”) for purposes
of this Agreement shall be March 1, 2006.

Section 1.2 Top-Level Domain. The Top-Level Domain to which this Agreement
applies is .com (“TLD”).

Section 1.3 Designation as Registry Operator. Upon the Effective Date, until the
Expiration Date as defined in Section 4.1 hereof, ICANN shall continue to
recognize VeriSign, Inc. as the sole registry operator for the TLD (“Registry
Operator”).

ARTICLE II REPRESENTATIONS AND WARRANTIES

Section 2.1 Registry Operator’s Representations and Warranties.

(a) Organization; Due Authorization and Execution. Registry Operator is a
corporation, duly organized, validly existing and in good standing under the
laws of Delaware, and Registry Operator has all requisite power and authority to
enter into this Agreement. All corporate approvals and actions necessary for the
entrance by Registry Operator into this Agreement have been obtained and this
Agreement has been duly and validly executed and delivered by Registry Operator.

(b) Statements made During Negotiation Process. The factual statements made in
writing by Registry Operator in negotiating this Agreement were true and correct
in all material respects at the time made. A violation or breach of any such
representation or warranty shall not be a basis for termination, rescission or
other equitable relief, and, instead shall only give rise to a claim for
damages.

Section 2.2 ICANN’s Representations and Warranties.

(a) Organization; Due Authorization and Execution. ICANN is a nonprofit public
benefit corporation duly organized, validly existing and in good standing under
the laws of California. ICANN has all requisite corporate power and authority to
enter into this Agreement. All corporate approvals and actions necessary for the
entrance by ICANN into this Agreement have been obtained and this Agreement has
been duly and validly executed and delivered by ICANN.

--------------------------------------------------------------------------------

ARTICLE III COVENANTS

Section 3.1 Covenants of Registry Operator. Registry Operator covenants and
agrees with ICANN as follows:

(a) Preserve Security and Stability.

(i) ICANN Temporary Specifications or Policies. Registry Operator shall comply
with and implement all specifications or policies established by the ICANN Board
of Directors on a temporary basis, if adopted by the ICANN Board of Directors by
a vote of at least two-thirds of its members, so long as the ICANN Board of
Directors reasonably determines that immediate temporary establishment of a
specification or policy on the subject is necessary to maintain the Stability or
Security (as defined in Section 3.1(d)(iv)(G)) of Registry Services or the DNS
(“Temporary Specification or Policies”). Such proposed specification or policy
shall be as narrowly tailored as feasible to achieve those objectives. In
establishing any specification or policy under this provision, the ICANN Board
of Directors shall state the period of time for which the specification or
policy is temporarily adopted and shall immediately implement the Consensus
Policy development process set forth in ICANN’s Bylaws. ICANN shall also issue
an advisory statement containing a detailed explanation of its reasons for
adopting the temporary specification or policy and why the Board believes the
specification or policy should receive the consensus support of Internet
stakeholders. If the period of time for which the specification or policy is
adopted exceeds 90 days, the ICANN Board shall reaffirm its temporary adoption
every 90 days for a total period not to exceed one year, in order to maintain
such policy in effect until such time as it shall become a Consensus Policy as
described in Section 3.1(b) below. If during such one year period, the temporary
policy or specification does not become a Consensus Policy meeting the standard
set forth in Section 3.1(b) below, Registry Operator shall no longer be required
to comply with or implement such temporary policy or specification.

(b) Consensus Policies.

(i) At all times during the term of this Agreement and subject to the terms
hereof, Registry Operator will fully comply with and implement all Consensus
Policies found at http://www.icann.org/general/consensus-policies.htm, as of the
Effective Date and as may in the future be developed and adopted in accordance
with ICANN’s Bylaws and as set forth below.

(ii) “Consensus Policies” are those specifications or policies established
(1) pursuant to the procedure set forth in ICANN’s Bylaws and due process, and
(2) covering those topics listed in Section 3.1(b)(iv) below. The Consensus
Policy development process and procedure set forth in ICANN’s Bylaws may be
revised from time to time in accordance with ICANN’s Bylaws, and any Consensus
Policy that is adopted through such a revised process and covering those topics
listed in Section 3.1(b)(iv) below shall be considered a Consensus Policy for
purposes of this Agreement.

 

- 2 -

--------------------------------------------------------------------------------

(iii) For all purposes under this Agreement, the policies identified at
http://www.icann.org/general/consensus-policies.htm shall be treated in the same
manner and have the same effect as “Consensus Policies.”

(iv) Consensus Policies and the procedures by which they are developed shall be
designed to produce, to the extent possible, a consensus of Internet
stakeholders, including the operators of gTLDs. Consensus Policies shall relate
to one or more of the following: (1) issues for which uniform or coordinated
resolution is reasonably necessary to facilitate interoperability, Security
and/or Stability of the Internet or DNS; (2) functional and performance
specifications for the provision of Registry Services (as defined in
Section 3.1(d)(iii) below); (3) Security and Stability of the registry database
for the TLD; (4) registry policies reasonably necessary to implement Consensus
Policies relating to registry operations or registrars; or (5) resolution of
disputes regarding the registration of domain names (as opposed to the use of
such domain names). Such categories of issues referred to in the preceding
sentence shall include, without limitation:

(A) principles for allocation of registered names in the TLD (e.g., first-come,
first-served, timely renewal, holding period after expiration);

(B) prohibitions on warehousing of or speculation in domain names by registries
or registrars;

(C) reservation of registered names in the TLD that may not be registered
initially or that may not be renewed due to reasons reasonably related to
(a) avoidance of confusion among or misleading of users, (b) intellectual
property, or (c) the technical management of the DNS or the Internet (e.g.,
establishment of reservations of names from registration);

(D) maintenance of and access to accurate and up-to-date information concerning
domain name registrations;

(E) procedures to avoid disruptions of domain name registration due to
suspension or termination of operations by a registry operator or a registrar,
including procedures for allocation of responsibility for serving registered
domain names in a TLD affected by such a suspension or termination; and

(F) resolution of disputes regarding whether particular parties may register or
maintain registration of particular domain names.

(v) In addition to the other limitations on Consensus Policies, they shall not:

(A) prescribe or limit the price of Registry Services;

 

- 3 -

--------------------------------------------------------------------------------

(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 two 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

(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).

(vi) Registry Operator shall be afforded a reasonable period of time following
notice of the establishment of a Consensus Policy or Temporary Specifications or
Policies in which to comply with such policy or specification, taking into
account any urgency involved.

In the event of a conflict between Registry Services (as defined in
Section 3.1(d)(iii) below), on the one hand, and Consensus Policies developed in
accordance with this Section 3.1(b) or any Temporary Specifications or Policies
established pursuant to Section 3.1(a)(i) above, on the other hand, the
Consensus Polices or Temporary Specifications or Policies shall control,
notwithstanding any other provisions contained within this Agreement.

(c) Handling of Registry Data.

(i) Data Escrow. Registry Operator shall establish at its expense a data escrow
or mirror site policy for the Registry Data compiled by Registry Operator.
Registry Data, as used in this Agreement, shall mean the following: (1) data for
domains sponsored by all registrars, consisting of domain name, server name for
each nameserver, registrar id, updated date, creation date, expiration date,
status information, and DNSSEC-related key material; (2) data for nameservers
sponsored by all registrars consisting of server name, each IP address,
registrar id, updated date, creation date, expiration date, and status
information; (3) data for registrars sponsoring registered domains and
nameservers, consisting of

 

- 4 -

--------------------------------------------------------------------------------

registrar id, registrar address, registrar telephone number, registrar e-mail
address, whois server, referral URL, updated date and the name, telephone
number, and e-mail address of all the registrar’s administrative, billing, and
technical contacts; (4) domain name registrant data collected by the Registry
Operator from registrars as part of or following registration of a domain name;
and (5) the DNSSEC-related material necessary to sign the .com zone (e.g.,
public and private portions of .com zone key-signing keys and zone-signing
keys). The escrow agent or mirror-site manager, and the obligations thereof,
shall be mutually agreed upon by ICANN and Registry Operator on commercially
reasonable standards that are technically and practically sufficient to allow a
successor registry operator to assume management of the TLD. To this end,
Registry Operator shall periodically deposit into escrow all Registry Data on a
schedule (not more frequently than weekly for a complete set of Registry Data,
and daily for incremental updates) and in an electronic format mutually approved
from time to time by Registry Operator and ICANN, such approval not to be
unreasonably withheld by either party. In addition, Registry Operator will
deposit into escrow that data collected from registrars as part of offering
Registry Services introduced after the Effective Date of this Agreement. The
escrow shall be maintained, at Registry Operator’s expense, by a reputable
escrow agent mutually approved by Registry Operator and ICANN, such approval
also not to be unreasonably withheld by either party. The schedule, content,
format, and procedure for escrow deposits shall be as reasonably established by
ICANN from time to time, and as set forth in Appendix 1 hereto. Changes to the
schedule, content, format, and procedure may be made only with the mutual
written consent of ICANN and Registry Operator (which neither party shall
unreasonably withhold) or through the establishment of a Consensus Policy as
outlined in Section 3.1(b) above. The escrow shall be held under an agreement,
substantially in the form of Appendix 2, as the same may be revised from time to
time, among ICANN, Registry Operator, and the escrow agent.

(ii) Personal Data. Registry Operator shall notify registrars sponsoring
registrations in the registry for the TLD of the purposes for which Personal
Data (as defined below) submitted to Registry Operator by registrars, if any, is
collected, the intended recipients (or categories of recipients) of such
Personal Data, and the mechanism for access to and correction of such Personal
Data. Registry Operator shall take reasonable steps to protect Personal Data
from loss, misuse, unauthorized disclosure, alteration or destruction. Registry
Operator shall not use or authorize the use of Personal Data in a way that is
incompatible with the notice provided to registrars. “Personal Data” shall refer
to all data about any identified or identifiable natural person.

(iii) Bulk Zone File Access. Registry Operator shall provide bulk access to the
zone files for the registry for the TLD to ICANN on a continuous basis in the
manner ICANN may reasonably specify from time to time. Bulk access to the zone
files shall be provided to third parties on the terms set forth in the TLD zone
file access agreement reasonably established by ICANN, which initially shall be

 

- 5 -

--------------------------------------------------------------------------------

in the form attached as Appendix 3 hereto. Changes to the zone file access
agreement may be made upon the mutual written consent of ICANN and Registry
Operator (which consent neither party shall unreasonably withhold).

(iv) Monthly Reporting. Within 20 days following the end of each calendar month,
Registry Operator shall prepare and deliver to ICANN a report providing such
data and in the format specified in Appendix 4. ICANN may audit Registry
Operator’s books and records relating to data contained in monthly reports from
time to time upon reasonable advance written notice, provided that such audits
shall not exceed one per quarter. Any such audit shall be at ICANN’s cost,
unless such audit shall reflect a material discrepancy or discrepancies in the
data provided by Registry Operator. In the latter event, Registry Operator shall
reimburse ICANN for all costs and expenses associated with such audit, which
reimbursement shall be paid together with the next Registry-Level Fee payment
due following the date of transmittal of the cost statement for such audit.

(v) Whois Service. Registry Operator shall provide such whois data as set forth
in Appendix 5.

(d) Registry Operations.

(i) Registration Restrictions. Registry Operator shall reserve, and not register
any TLD strings (i) appearing on the list of reserved TLD strings attached as
Appendix 6 hereto or (ii) located at
http://data.iana.org/TLD/tlds-alpha-by-domain.txt for initial (i.e., other than
renewal) registration at the second level within the TLD.

(ii) Functional and Performance Specifications. Functional and Performance
Specifications for operation of the TLD shall be as set forth in Appendix 7
hereto, and shall address without limitation DNS services; operation of the
shared registration system; and nameserver operations. Registry Operator shall
keep technical and operational records sufficient to evidence compliance with
such specifications for at least one year, which records ICANN may audit from
time to time upon reasonable advance written notice, provided that such audits
shall not exceed one per quarter. Any such audit shall be at ICANN’s cost.

(iii) Registry Services. Registry Services are, for purposes of this Agreement,
defined as the following: (a) those services that are both (i) operations of the
registry critical to the following tasks: the receipt of data from registrars
concerning registrations of domain names and name servers; provision to
registrars of status information relating to the zone servers for the TLD;
dissemination of TLD zone files; operation of the registry zone servers; and
dissemination of contact and other information concerning domain name server
registrations in the TLD as required by this Agreement; and (ii) provided by the
Registry Operator for the .com registry as of the Effective Date; (b) other
products or services that the Registry Operator is required to provide because
of the establishment of a Consensus Policy (as defined in Section 3.1(b) above);
(c)

 

- 6 -

--------------------------------------------------------------------------------

any other products or services that only a registry operator is capable of
providing, by reason of its designation as the registry operator; and
(d) material changes to any Registry Service within the scope of (a), (b) or
(c) above. Only Registry Services defined in (a) and (b) above are subject to
the maximum price provisions of Section 7.3, below.

(iv) Process for Consideration of Proposed Registry Services. Following written
notification by Registry Operator to ICANN that Registry Operator may make a
change in a Registry Service within the scope of the preceding paragraph:

(A) ICANN shall have 15 calendar days to make a “preliminary determination”
whether a Registry Service requires further consideration by ICANN because it
reasonably determines such Registry Service: (i) could raise significant
Security or Stability issues or (ii) could raise significant competition issues.

(B) Registry Operator must provide sufficient information at the time of
notification to ICANN that it may implement such a proposed Registry Service to
enable ICANN to make an informed “preliminary determination.” Information
provided by Registry Operator and marked “CONFIDENTIAL” shall be treated as
confidential by ICANN. Registry Operator will not designate “CONFIDENTIAL”
information necessary to describe the purpose of the proposed Registry Service
and the effect on users of the DNS.

(C) ICANN may seek expert advice during the preliminary determination period
(from entities or persons subject to confidentiality agreements) on the
competition, Security or Stability implications of the Registry Service in order
to make its “preliminary determination.” To the extent ICANN determines to
disclose confidential information to any such experts, it will provide notice to
Registry Operator of the identity of the expert(s) and the information it
intends to convey.

(D) If ICANN determines during the 15 calendar day “preliminary determination”
period that the proposed Registry Service, does not raise significant Security
or Stability (as defined below), or competition issues, Registry Operator shall
be free to deploy it upon such a determination.

(E) In the event ICANN reasonably determines during the 15 calendar day
“preliminary determination” period that the Registry Service might raise
significant competition issues, ICANN shall refer the issue to the appropriate
governmental competition authority or authorities with jurisdiction over the
matter within five business days of making its determination, or two business
days following the expiration of such 15 day period, whichever is earlier, with
notice to Registry Operator. Any such referral communication shall be posted on
ICANN’s website on the date of transmittal. Following such referral, ICANN shall
have no further responsibility, and Registry Operator shall have no further
obligation to ICANN, with respect to any competition issues relating to the
Registry Service. If

 

- 7 -

--------------------------------------------------------------------------------

such a referral occurs, the Registry Operator will not deploy the Registry
Service until 45 calendar days following the referral, unless earlier cleared by
the referred governmental competition authority.

(F) In the event that ICANN reasonably determines during the 15 calendar day
“preliminary determination” period that the proposed Registry Service might
raise significant Stability or Security issues (as defined below), ICANN will
refer the proposal to a Standing Panel of experts (as defined below) within five
business days of making its determination, or two business days following the
expiration of such 15 day period, whichever is earlier, and simultaneously
invite public comment on the proposal. The Standing Panel shall have 45 calendar
days from the referral to prepare a written report regarding the proposed
Registry Service’s effect on Security or Stability (as defined below), which
report (along with a summary of any public comments) shall be forwarded to the
ICANN Board. The report shall set forward the opinions of the Standing Panel,
including, but not limited to, a detailed statement of the analysis, reasons,
and information upon which the panel has relied in reaching their conclusions,
along with the response to any specific questions that were included in the
referral from ICANN staff. Upon ICANN’s referral to the Standing Panel, Registry
Operator may submit additional information or analyses regarding the likely
effect on Security or Stability of the Registry Service.

(G) Upon its evaluation of the proposed Registry Service, the Standing Panel
will report on the likelihood and materiality of the proposed Registry Service’s
effects on Security or Stability, including whether the proposed Registry
Service creates a reasonable risk of a meaningful adverse effect on Security or
Stability as defined below:

Security: For purposes of this Agreement, an effect on security by the proposed
Registry Service shall mean (1) the unauthorized disclosure, alteration,
insertion or destruction of Registry Data, or (2) the unauthorized access to or
disclosure of information or resources on the Internet by systems operating in
accordance with all applicable standards.

Stability: For purposes of this Agreement, an effect on stability shall mean
that the proposed Registry Service (1) is not compliant with applicable relevant
standards that are authoritative and published by a well-established, recognized
and authoritative standards body, such as relevant Standards-Track or Best
Current Practice RFCs sponsored by the IETF or (2) creates a condition that
adversely affects the throughput, response time, consistency or coherence of
responses to Internet servers or end systems, operating in accordance with
applicable relevant standards that are authoritative and published by a
well-established, recognized and authoritative standards body, such as relevant
Standards-Track or Best Current Practice RFCs and relying on Registry Operator’s
delegation information or provisioning services.

 

- 8 -

--------------------------------------------------------------------------------

(H) Following receipt of the Standing Panel’s report, which will be posted (with
appropriate confidentiality redactions made after consultation with Registry
Operator) and available for public comment, the ICANN Board will have 30
calendar days to reach a decision. In the event the ICANN Board reasonably
determines that the proposed Registry Service creates a reasonable risk of a
meaningful adverse effect on Stability or Security, Registry Operator will not
offer the proposed Registry Service. An unredacted version of the Standing
Panel’s report shall be provided to Registry Operator upon the posting of the
report. The Registry Operator may respond to the report of the Standing Panel or
otherwise submit to the ICANN Board additional information or analyses regarding
the likely effect on Security or Stability of the Registry Service.

(I) The Standing Panel shall consist of a total of 20 persons expert in the
design, management and implementation of the complex systems and
standards-protocols utilized in the Internet infrastructure and DNS (the
“Standing Panel”). The members of the Standing Panel will be selected by its
Chair. The Chair of the Standing Panel will be a person who is agreeable to both
ICANN and the registry constituency of the supporting organization then
responsible for generic top level domain registry policies. All members of the
Standing Panel and the Chair shall execute an agreement requiring that they
shall consider the issues before the panel neutrally and according to the
definitions of Security and Stability. For each matter referred to the Standing
Panel, the Chair shall select no more than five members from the Standing Panel
to evaluate the referred matter, none of which shall have an existing
competitive, financial, or legal conflict of interest, and with due regard to
the particular technical issues raised by the referral.

(e) Fees and Payments. Registry Operator shall pay the Registry-Level Fees to
ICANN on a quarterly basis in accordance with Section 7.2 hereof.

(f) Traffic Data. Nothing in this Agreement shall preclude Registry Operator
from making commercial use of, or collecting, traffic data regarding domain
names or non-existent domain names for purposes such as, without limitation, the
determination of the availability and health of the Internet, pinpointing
specific points of failure, characterizing attacks and misconfigurations,
identifying compromised networks and hosts, and promoting the sale of domain
names; provided, however, that such use does not disclose domain name
registrant, end user information or other Personal Data as defined in
Section 3.1(c)(ii) for any purpose not otherwise authorized by this agreement.
The process for the introduction of new Registry Services shall not apply to
such traffic data. Nothing contained in this section 3.1(f) shall be deemed to
constitute consent or acquiescence by ICANN to a re-introduction by Registry
Operator of the SiteFinder service previously introduced by the Registry
Operator on or about September 15, 2003, or the introduction of any
substantially similar service employing a universal wildcard function intended
to achieve the same or substantially similar effect as the SiteFinder service.
To the extent that traffic data subject to this provision is made available,
access shall be on terms that are non-discriminatory.

 

- 9 -

--------------------------------------------------------------------------------

(g) Security and Stability Review. Twice annually Registry Operator shall engage
in discussions with executive staff of ICANN and the Chairman of the Board of
ICANN on trends impacting the Security and/or Stability of the Registry, the DNS
or the Internet pursuant to the terms of confidentiality agreements executed
both by the executive staff of ICANN and the Chairman of the Board.

(h) Centralized Whois. Registry Operator shall develop and deploy a centralized
Whois for the .com TLD if mandated by ICANN insofar as reasonably feasible,
particularly in view of Registry Operator’s dependence on cooperation of third
parties.

Section 3.2 Covenants of ICANN. ICANN covenants and agrees with Registry
Operator as follows:

(a) Open and Transparent. Consistent with ICANN’s expressed mission and core
values, ICANN shall operate in an open and transparent manner.

(b) Equitable Treatment. ICANN shall not apply standards, policies, procedures
or practices arbitrarily, unjustifiably, or inequitably and shall not single out
Registry Operator for disparate treatment unless justified by substantial and
reasonable cause.

(c) TLD Zone Servers. In the event and to the extent that ICANN is authorized to
set policy with regard to an authoritative root server system, it will ensure
that (i) the authoritative root will point to the TLD zone servers designated by
Registry Operator for the Registry TLD throughout the Term of this Agreement;
and (ii) any changes to the TLD zone server designation submitted to ICANN by
Registry Operator will be implemented by ICANN within seven days of submission.

(d) Nameserver Changes. Registry Operator may request changes in the nameserver
delegation for the Registry TLD. Any such request must be made in a format, and
otherwise meet technical requirements, specified from time to time by ICANN.
ICANN will use commercially reasonable efforts to have such requests implemented
in the Authoritative Root-Server System within seven calendar days of the
submission.

(e) Root-zone Information Publication. ICANN’s publication of root-zone contact
information for the Registry TLD will include Registry Operator and its
administrative and technical contacts. Any request to modify the contact
information for the Registry Operator must be made in the format specified from
time to time by ICANN.

 

- 10 -

--------------------------------------------------------------------------------

Section 3.3 Cooperation. The parties agree to cooperate with each other and
share data as necessary to accomplish the terms of this Agreement.

ARTICLE IV TERM OF AGREEMENT

Section 4.1 Term. The initial term of this Agreement shall expire on
November 30, 2012. The “Expiration Date” shall be November 30, 2012, as extended
by any renewal terms.

Section 4.2 Renewal. This Agreement shall be renewed upon the expiration of the
term set forth in Section 4.1 above and each later term, unless the following
has occurred : (i) following notice of breach to Registry Operator in accordance
with Section 6.1 and failure to cure such breach within the time period
prescribed in Section 6.1, an arbitrator or court has determined that Registry
Operator has been in fundamental and material breach of Registry Operator’s
obligations set forth in Sections 3.1(a), (b), (d) or (e); Section 5.2 or
Section 7.3 and (ii) following the final decision of such arbitrator or court,
Registry Operator has failed to comply within ten days with the decision of the
arbitrator or court, or within such other time period as may be prescribed by
the arbitrator or court. Upon renewal, in the event that the terms of this
Agreement are not similar to the terms generally in effect in the Registry
Agreements of the 5 largest gTLDs (determined by the number of domain name
registrations under management at the time of renewal), renewal shall be upon
terms reasonably necessary to render the terms of this Agreement similar to such
terms in the Registry Agreements for those other gTLDs. The preceding sentence,
however, shall not apply to the terms of this Agreement regarding the price of
Registry Services; the standards for the consideration of proposed Registry
Services, including the definitions of Security and Stability and the standards
applied by ICANN in the consideration process; the terms or conditions for the
renewal or termination of this Agreement; ICANN’s obligations to Registry
Operator under Section 3.2 (a), (b), and (c); the limitations on Consensus
Policies or Temporary Specifications or Policies; the definition of Registry
Services; or the terms of Section 7.3.

Section 4.3 Failure to Perform in Good Faith. In the event Registry Operator
shall have been repeatedly and willfully in fundamental and material breach of
Registry Operator’s obligations set forth in Sections 3.1(a), (b), (d) or (e);
Section 5.2 or Section 7.3, and arbitrators in accordance with Section 5.1(b) of
this Agreement repeatedly have found Registry Operator to have been in
fundamental and material breach of this Agreement, including in at least three
separate awards, then the arbitrators shall award such punitive, exemplary or
other damages as they may believe appropriate under the circumstances.

ARTICLE V DISPUTE RESOLUTION

Section 5.1 Resolution of Disputes.

(a) Cooperative Engagement. In the event of a disagreement between Registry
Operator and ICANN arising under or out of this Agreement, either party

 

- 11 -

--------------------------------------------------------------------------------

may by notice to the other invoke the dispute resolution provisions of this
Article V. Provided, however, that before either party may initiate arbitration
as provided in Section 5.1(b) below, ICANN and Registry Operator must attempt to
resolve the dispute by cooperative engagement as set forth in this
Section 5.1(a). If either party provides written notice to the other demanding
cooperative engagement as set forth in this Section 5.1(a), then each party
will, within seven calendar days after such written notice is deemed received in
accordance with Section 8.6 hereof, designate a single executive officer as its
representative under this Section 5.1(a) with full authority to act on such
party’s behalf to resolve the dispute. The designated representatives shall,
within 2 business days after being designated, confer by telephone or in person
to attempt to resolve the dispute. If they are not able to resolve the dispute
during such telephone conference or meeting, they shall further meet in person
at a location reasonably designated by ICANN within 7 calendar days after such
initial telephone conference or meeting, at which meeting the parties shall
attempt to reach a definitive resolution. The time schedule and process set
forth in this Section 5.1(a) may be modified with respect to any dispute, but
only if both parties agree to a revised time schedule or process in writing in
advance. Settlement communications within the scope of this paragraph shall be
inadmissible in any arbitration or litigation between the parties.

(b) Arbitration. Disputes arising under or in connection with this Agreement,
including requests for specific performance, shall be resolved through binding
arbitration conducted as provided in this Section 5.1(b) pursuant to the rules
of the International Court of Arbitration of the International Chamber of
Commerce (“ICC”). The arbitration shall be conducted in the English language and
shall occur in Los Angeles County, California, USA only following the failure to
resolve the dispute pursuant to cooperative engagement discussions as set forth
in Section 5.1(a) above. There shall be three arbitrators: each party shall
choose one arbitrator and, if the two arbitrators are not able to agree on a
third arbitrator, the third shall be chosen by the ICC. The prevailing party in
the arbitration shall have the right to recover its costs and reasonable
attorneys’ fees, which the arbitrators shall include in their awards. Any party
that seeks to confirm or vacate an arbitration award issued under this
Section 5.1(b) may do so only pursuant to the applicable arbitration statutes.
In any litigation involving ICANN concerning this Agreement, jurisdiction and
exclusive venue for such litigation shall be in a court located in Los Angeles
County, California, USA; however, the parties shall also have the right to
enforce a judgment of such a court in any court of competent jurisdiction. For
the purpose of aiding the arbitration and/or preserving the rights of the
parties during the pendency of an arbitration, the parties shall have the right
to seek a temporary stay or injunctive relief from the arbitration panel or a
court, which shall not be a waiver of this agreement to arbitrate.

Section 5.2 Specific Performance. Registry Operator and ICANN agree that
irreparable damage could occur if any of the provisions of this Agreement was
not

 

- 12 -

--------------------------------------------------------------------------------

performed in accordance with its specific terms. Accordingly, the parties agree
that they each shall be entitled to seek from the arbitrators specific
performance of the terms of this Agreement (in addition to any other remedy to
which each party is entitled).

Section 5.3 Limitation of Liability. ICANN’s aggregate monetary liability for
violations of this Agreement shall not exceed the amount of Registry-Level Fees
paid by Registry Operator to ICANN within the preceding twelve-month period
pursuant to Section 7.2 of this Agreement. Registry Operator’s aggregate
monetary liability to ICANN for violations of this Agreement shall be limited to
fees and monetary sanctions due and owing to ICANN under this Agreement. In no
event shall either party be liable for special, indirect, incidental, punitive,
exemplary, or consequential damages arising out of or in connection with this
Agreement or the performance or nonperformance of obligations undertaken in this
Agreement, except as provided pursuant to Section 4.3 of this Agreement. EXCEPT
AS OTHERWISE EXPRESSLY PROVIDED IN THIS AGREEMENT, REGISTRY OPERATOR DOES NOT
MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES RENDERED BY
ITSELF, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR WORK,
INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY,
NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE.

ARTICLE VI TERMINATION PROVISIONS

Section 6.1 Termination by ICANN. ICANN may terminate this Agreement if and only
if: (i) Registry Operator fails to cure any fundamental and material breach of
Registry Operator’s obligations set forth in Sections 3.1(a), (b), (d) or (e);
Section 5.2 or Section 7.3 within thirty calendar days after ICANN gives
Registry Operator written notice of the breach, which notice shall include with
specificity the details of the alleged breach; and (ii) (a) an arbitrator or
court has finally determined that Registry Operator is, or was, in fundamental
and material breach and failed to cure such breach within the prescribed time
period and (b) following the decision of such arbitrator or court, Registry
Operator has failed to comply with the decision of the arbitrator or court.

Section 6.2 Bankruptcy. This Agreement shall automatically terminate in the
event Registry Operator shall voluntarily or involuntarily be subject to
bankruptcy proceedings.

Section 6.3 Transition of Registry upon Termination of Agreement. Upon any
termination of this Agreement as provided in Sections 6.1 and 6.2, the parties
agree to work cooperatively to facilitate and implement the transition of the
registry for the TLD in accordance with this Section 6.4. Registry Operator
shall agree to provide ICANN or any successor registry authority that may be
designated for the TLD with any data regarding operations of the registry for
the TLD necessary to maintain operations that may be reasonably requested in
addition to that data escrowed in accordance with Section 3.1(c)(i) hereof.

Section 6.4 Rights in Data. Registry Operator shall not be entitled to claim any
intellectual property rights in Registry Data. In the event that Registry Data
is released

 

- 13 -

--------------------------------------------------------------------------------

from escrow as set forth in Section 3.1(c)(i), rights, if any, held by Registry
Operator in the data shall automatically be licensed on a non-exclusive,
irrevocable, royalty-free, paid-up basis to ICANN or to a party designated in
writing by ICANN.

Section 6.5 No Reimbursement. Any and all expenditures, capital investments or
other investments made by Registry Operator in connection with this Agreement
shall be at Registry Operator’s own risk and ICANN shall have no obligation to
reimburse Registry Operator for any such expense, capital expenditure or
investment. Registry Operator shall not be required to make any payments to a
successor registry operator by reason of registry fees paid to Registry Operator
prior to the effective date of (i) any termination or expiration of this
Agreement or (ii) transition of the registry, unless any delay in transition of
the registry to a successor operator shall be due to the actions of Registry
Operator.

ARTICLE VII SPECIAL PROVISIONS

Section 7.1 Registry-Registrar Agreement.

(a) Access to Registry Services. Registry Operator shall make access to Registry
Services, including the shared registration system, available to all
ICANN-accredited registrars, subject to the terms of the Registry-Registrar
Agreement attached as Appendix 8 hereto. Registry Operator shall provide all
ICANN-accredited registrars following execution of the Registry-Registrar
Agreement, provided registrars are in compliance with such agreement,
operational access to Registry Services, including the shared registration
system for the TLD. Such nondiscriminatory access shall include without
limitation the following:

(i) All registrars (including any registrar affiliated with Registry Operator)
can connect to the shared registration system gateway for the TLD via the
Internet by utilizing the same maximum number of IP addresses and SSL
certificate authentication;

(ii) Registry Operator has made the current version of the registrar toolkit
software accessible to all registrars and has made any updates available to all
registrars on the same schedule;

(iii) All registrars have the same level of access to customer support personnel
via telephone, e-mail and Registry Operator’s website;

(iv) All registrars have the same level of access to registry resources to
resolve registry/registrar or registrar/registrar disputes and technical and/or
administrative customer service issues;

(v) All registrars have the same level of access to data generated by Registry
Operator to reconcile their registration activities from Registry Operator’s Web
and ftp servers;

 

- 14 -

--------------------------------------------------------------------------------

(vi) All registrars may perform basic automated registrar account management
functions using the same registrar tool made available to all registrars by
Registry Operator; and

(vii) The shared registration system does not include, for purposes of providing
discriminatory access, any algorithms or protocols that differentiate among
registrars with respect to functionality, including database access, system
priorities and overall performance.

Such Registry-Registrar Agreement may be revised by Registry Operator from time
to time, provided however, that any such revisions must be approved in advance
by ICANN.

(b) Registry Operator Shall Not Act as Own Registrar. Registry Operator shall
not act as a registrar with respect to the TLD. This shall not preclude Registry
Operator from registering names within the TLD to itself through a request made
to an ICANN-accredited registrar.

(c) Restrictions on Acquisition of Ownership or Controlling Interest in
Registrar. Registry Operator shall not acquire, directly or indirectly, control
of, or a greater than fifteen percent ownership interest in, any
ICANN-accredited registrar.

Section 7.2 Fees to be Paid to ICANN.

(a) Initial Fees. On the Effective Date, Registry Operator shall make a one-time
lump sum payment of US$625,000 to an account designated by ICANN. The uses of
these initial fees shall include meeting the costs associated with establishing
structures to implement the provisions of this Agreement.

(b) Fixed Registry-Level Fee. Registry Operator shall pay ICANN, to an account
designated by ICANN, a Fixed Registry-Level Fee as provided below. Payments
shall be made as follows: Beginning 1 July 2006 through 31 December 2006,
Registry Operator shall begin prepayment of the 2007 Fixed Registry-Level Fee in
equal monthly payments such that the total payments per quarter is US$1,500,000.
Beginning 1 January 2007, equal monthly payments for quarters ended 31 March
2007 and 30 June 2007 shall be paid such that the total payments per quarter,
calculated net of the prepayments during the quarters ended 30 September 2006
and 31 December 2006, is US$1,500,000. Beginning 1 July 2007, equal monthly
payments for quarters ended 30 September 2007, 31 December 2007, 31 March 2008,
and 30 June 2008, shall be paid such that the total payments per quarter is
US$2,000,000. Beginning 1 July 2008, equal monthly payments will increase such
that the total payments per quarter will equal US$3,000,000. Equal monthly
payments shall continue such that the total payment per quarter will equal
US$3,000,000 except that after 1 July 2009: (i) if the total number of annual
domain name registrations increases by a total of ten million over the total
number of domain name registrations on the Effective Date

 

- 15 -

--------------------------------------------------------------------------------

of the Agreement, the equal monthly payments shall increase by an amount
totaling $750,000 per quarter, for each quarter that the increased level of
annual domain name registrations is maintained; (ii) if the total number of
annual domain name registrations increases by a total of twenty million over the
total number of domain name registrations at the time of the Effective Date of
the Agreement, the equal monthly payments shall increase by an amount in
addition to that set forth in 7.2(a)(i), totaling $750,000 per quarter, for each
quarter that the increased level of annual domain name registrations is
maintained; provided, however, if at any time after the Effective Date, the
total number of annual domain name registrations falls below the total number of
domain name registrations on the Effective Date of the Agreement, or, if
applicable, the total number of annual domain name registrations in 7.2(a)(i)
and 7.2(a)(ii) above, the equal monthly payments shall be reduced by US$25,000
per month for every 1 million annual domain name registrations reduction.

(c) Variable Registry-Level Fee. For fiscal quarters in which ICANN does not
collect a variable accreditation fee from all registrars, upon receipt of
written notice from ICANN, Registry Operator shall pay ICANN a Variable
Registry-Level Fee. The fee will be calculated by ICANN. The Registry Operator
shall invoice and collect the fees from the registrars who are party to a
Registry-Registrar Agreement with Registry Operator and paid to ICANN by the
Registry Operator by the 20th day following the end of each calendar quarter
(i.e., on April 20, July 20, October 20 and January 20 for the calendar quarters
ending March 31, June 30, September 30 and December 31) of the year to an
account designated by ICANN. The fee will consist of two components; each
component will be calculated by ICANN for each registrar:

(i) The transactional component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year but shall not exceed US[$0.25].

(ii) The per-registrar component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year, but the sum of the per-registrar fees calculated
for all registrars shall not exceed the total Per-Registrar Variable funding
established pursuant to the approved 2004-2005 ICANN Budget.

(d) Interest on Late Payments. For any payments ten days or more overdue,
Registry Operator shall pay interest on late payments at the rate of 1.5% per
month or, if less, the maximum rate permitted by applicable law.

Section 7.3 Pricing for Domain Name Registrations and Registry Services.

(a) Scope. The Registry Services to which the provisions of this Section 7.3
shall apply are:

(i) the Registry Services defined in Section 3.1(d)(iii)(a), above, and

 

- 16 -

--------------------------------------------------------------------------------

(ii) other products or services that the Registry Operator is required to
provide within the scope of Section 3.1(d)(iii)(b), above, because of the
establishment of a Consensus Policy (as defined in Section 3.1(b) above):

(1) to implement changes in the core functional or performance specifications
for Registry Services (as defined in Section 3.1(d)(iii)(a)); or

(2) that are reasonably necessary to facilitate: (A) Security and/or Stability
of the Internet or DNS; (B) Security and Stability of the registry database for
the TLD; or (C) resolution of disputes regarding the registration of domain
names (as opposed to the use of such domain names).

Nothing contained herein shall be construed to apply the provisions of this
Section 7.3 to the services enumerated in Appendix 9 of this Agreement.

(b) No Tying. Registry Operator shall not require, as a condition of the
provision or use of Registry Services subject to this Section 7.3 in accordance
with the requirements of this Agreement, including without limitation
Section 7.1 and Appendix 10, that the purchaser of such services purchase any
other product or service or refrain from purchasing any other product or
service. Notwithstanding any other offering that may include all or any portion
of the Registry Services at any price, Registry Operator shall offer to all
ICANN-accredited registrars the combination of all Registry Services subject to
this Section 7.3 at a total price for those Registry Services that is no greater
than the Maximum Price calculated pursuant to Section 7.3(d) and that otherwise
complies with all the requirements of Section 7.3.

(c) Price for Registry Services. The price for all Registry Services subject to
this Paragraph 7.3 shall be the amount, not to exceed the Maximum Price, that
Registry Operator charges for each annual increment of a new and renewal domain
name registration and for each transfer of a domain name registration from one
ICANN-accredited registrar to another.

(d) Maximum Price. The Maximum Price for Registry Services subject to this
Paragraph 7.3 shall be as follows:

(i) from the Effective Date through 31 December 2006, US$6.00;

(ii) for each calendar year beginning with 1 January 2007, the smaller of the
preceding year’s Maximum Price or the highest price charged during the preceding
year, multiplied by 1.07; provided, however, that such increases shall only be
permitted in four years of any six year term of the Agreement. In any year,
however, where a price increase does not occur, Registry Operator shall be
entitled to increase the Maximum Price by an amount sufficient to cover any
additional incremental costs incurred during the term of the Agreement due to
the imposition of any new Consensus Policy or documented extraordinary expense

 

- 17 -

--------------------------------------------------------------------------------

resulting from an attack or threat of attack on the Security or Stability of the
DNS, not to exceed the smaller of the preceding year’s Maximum Price or the
highest price charged during the preceding year, multiplied by 1.07.

(e) No price discrimination. Registry Operator shall charge the same price for
Registry Services subject to this Section 7.3, not to exceed the Maximum Price,
to all ICANN-accredited registrars (provided that volume discounts and marketing
support and incentive programs may be made if the same opportunities to qualify
for those discounts and marketing support and incentive programs is available to
all ICANN-accredited registrars).

(f) Adjustments to Pricing for Domain Name Registrations. Registry Operator
shall provide no less than six months prior notice in advance of any increase
for new and renewal domain name registrations and for transferring a domain name
registration from one ICANN-accredited registrar to another and shall continue
to offer for periods of up to ten years new and renewal domain name
registrations fixed at the price in effect at the time such offer is accepted.
Registry Operator is not required to give notice of the imposition of the
Variable Registry-Level Fee set forth in Section 7.2(c).

(g) Maximum Price does not include ICANN Variable Registry-Level Fee. The
Maximum Price does not include, and shall not be calculated from a price that
includes, all or any part of the ICANN Variable Registry-Level Fee set forth in
Section 7.2(c), above, or any other per-name fee for new and renewal domain name
registrations and for transferring a domain name registration from one
ICANN-accredited registrar to another.

ARTICLE VIII MISCELLANEOUS

Section 8.1 No Offset. All payments due under this Agreement shall be made in a
timely manner throughout the term of this Agreement and notwithstanding the
pendency of any dispute (monetary or otherwise) between Registry Operator and
ICANN.

Section 8.2 Use of ICANN Name and Logo. ICANN grants to Registry Operator a
non-exclusive royalty-free license to state that it is designated by ICANN as
the Registry Operator for the Registry TLD and to use a logo specified by ICANN
to signify that Registry Operator is an ICANN-designated registry authority.
This license may not be assigned or sublicensed by Registry Operator.

Section 8.3 Assignment and Subcontracting. Any assignment of this Agreement
shall be effective only upon written agreement by the assignee with the other
party to assume the assigning party’s obligations under this Agreement.
Moreover, neither party may assign this Agreement without the prior written
approval of the other party. Notwithstanding the foregoing, ICANN may assign
this Agreement (i) in conjunction with a reorganization or re-incorporation of
ICANN, to another nonprofit corporation organized for the same or substantially
the same purposes, or (ii) as may be required pursuant to the terms of that
certain Memorandum of Understanding between ICANN

 

- 18 -

--------------------------------------------------------------------------------

and the U.S. Department of Commerce, as the same may be amended from time to
time. Registry Operator must provide notice to ICANN of any subcontracting
arrangements, and any agreement to subcontract portions of the operations of the
TLD must mandate compliance with all covenants, obligations and agreements by
Registry Operator hereunder. Any subcontracting of technical operations shall
provide that the subcontracted entity become party to the data escrow agreement
mandated by Section 3.1(c)(i) hereof.

Section 8.4 Amendments and Waivers. No amendment, supplement, or modification of
this Agreement or any provision hereof shall be binding unless executed in
writing by both parties. No waiver of any provision of this Agreement shall be
binding unless evidenced by a writing signed by the party waiving compliance
with such provision. No waiver of any of the provisions of this Agreement or
failure to enforce any of the provisions hereof shall be deemed or shall
constitute a waiver of any other provision hereof, nor shall any such waiver
constitute a continuing waiver unless otherwise expressly provided.

Section 8.5 No Third-Party Beneficiaries. This Agreement shall not be construed
to create any obligation by either ICANN or Registry Operator to any non-party
to this Agreement, including any registrar or registered name holder.

Section 8.6 Notices, Designations, and Specifications. All notices to be given
under or in relation to this Agreement shall be given either (i) in writing at
the address of the appropriate party as set forth below or (ii) via facsimile or
electronic mail as provided below, unless that party has given a notice of
change of postal or email address, or facsimile number, as provided in this
agreement. Any change in the contact information for notice below shall be given
by the party within 30 days of such change. Any notice required by this
Agreement shall be deemed to have been properly given (i) if in paper form, when
delivered in person or via courier service with confirmation of receipt or
(ii) if via facsimile or by electronic mail, upon confirmation of receipt by the
recipient’s facsimile machine or email server. Whenever this Agreement shall
specify a URL address for certain information, Registry Operator shall be deemed
to have been given notice of any such information when electronically posted at
the designated URL. In the event other means of notice shall become practically
achievable, such as notice via a secure website, the parties shall work together
to implement such notice means under this Agreement.

If to ICANN, addressed to:

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina Del Rey, California 90292

Telephone: 1-310-823-9358

Facsimile: 1-310-823-8649

Attention: President and CEO

With a Required Copy to: General Counsel

Email: (As specified from time to time.)

 

- 19 -

--------------------------------------------------------------------------------

If to Registry Operator, addressed to:

VeriSign, Inc.

21355 Ridgetop Circle

Dulles, VA 20166

Telephone: 1-703-948-4463

Facsimile: 1-703-450-7326

Attention: VP, Associate General Counsel, VNDS

With a Required Copy to: General Counsel

Email: (As specified from time to time.)

Section 8.7 Language. Notices, designations, determinations, and specifications
made under this Agreement shall be in the English language.

Section 8.8 Counterparts. This Agreement may be executed in one or more
counterparts, each of which shall be deemed an original, but all of which
together shall constitute one and the same instrument.

Section 8.9 Entire Agreement. This Agreement (including its Appendices, which
form a part of it) constitutes the entire agreement of the parties hereto
pertaining to the operation of the TLD and supersedes all prior agreements,
understandings, negotiations and discussions, whether oral or written, between
the parties on that subject. In the event of a conflict between the provisions
in the body of this Agreement and any provision in its Appendices, the
provisions in the body of the Agreement shall control.

 

- 20 -

--------------------------------------------------------------------------------

IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed
by their duly authorized representatives.

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

 

  By:  

/s/ Paul Twomey

    Paul Twomey     President and CEO   Date: 1 March 2006   VeriSign, Inc.  
By:  

/s/ Stratton Scalvos

    Stratton Sclavos     President and CEO, VeriSign, Inc.   Date: 1 March 2006

 

- 21 -

--------------------------------------------------------------------------------

.COM Agreement Appendix 1

Data Escrow Specification

EXHIBIT A—Task Order and Statement of Work

TASK ORDER TITLE

Exhibit A to the Escrow Agreement dated                                 .

COMPANY NAME

Data Escrow Provider

STATEMENT OF WORK

Establish an escrow account to deposit all data identified in Section 3.1(c)(i)
of the Registry Agreement between VeriSign, Inc. (“VNDS”) and the Internet
Corporation for Assigned Names and Numbers (“ICANN”) ( the “Data”) in an
electronic format mutually approved by VNDS and ICANN. More specifically, to
meet the Data Escrow requirements outlined in the Registry Agreement, VNDS will
store in escrow with Data Escrow Provider a complete set of Data in an
electronic format agreed upon by VNDS and ICANN. Data Escrow Provider will
verify that the data is complete, accurate, and delivered in the intended format
using scripts provided by VNDS. The escrow deposit verification process will
validate completeness and integrity (accuracy) of the data as well as validate
that the file format sent is the format received by Data Escrow Provider
(correctness). Refer to Exhibit B to review the verification processes. The
Introspection validation, defined in Exhibit B, will be implemented in a later
phase, as mutually agreed by the parties hereto.

Data will be securely and electronically transmitted on a daily and weekly basis
as follows:

Weekly Escrow Deposits:

VNDS will deposit a complete set of Data into escrow on a weekly basis by
electronically and securely transmitting a snapshot of each operational
Registrar’s data (the “Deposit Materials”). The snapshot captures the state of
each Registrar’s data at the time the snapshot was created. Specific data
elements contained in the Deposit Materials are identified in Table 1.

Daily Escrow Deposits:

VNDS will securely and electronically deposit a transaction log for each
operational Registrar representing transactions that occurred over the previous
24 hour period (the “Additional Deposit”). The logs will be escrowed daily,
being in the form of Additional Deposit each Tuesday through Sunday, and being
in the form of the Weekly Deposit Materials each Monday, which shall capture
that Sunday’s data. The Daily Additional Deposit will act as incremental updates
to the Weekly Deposit Materials and will include all Registrar activity, such as
add, delete, and transfer of a domain name. Specific data elements contained in
the Additional Deposit are identified in Table 2.

--------------------------------------------------------------------------------

Electronic Delivery Service Escrow Deposit Method:

The “Electronic Delivery Service” escrow deposit method shall mean and refer to
the following: VNDS shall transmit the Deposit Materials and Additional Deposit
to a secure server on a weekly and daily basis, respectively. VNDS shall provide
a secure ID and password for Data Escrow Provider. Data Escrow Provider shall
pull the transmitted data from the server and store it in a secured location.
The transmitted data will be made available to Data Escrow Provider as follows:

Daily Deposits:

Daily transactional data will be made available at the close of business each
Tuesday through Sunday for the previous calendar day. For example, transactional
data created on Monday would be available to the escrow company on Tuesday at
the close of business. The results of transactions completed on Sunday will be
made available in the Weekly Deposit Materials, thus no separate Daily
Additional Deposit will be made for Sunday activity.

Weekly Deposits:

Weekly database snapshots taken at midnight on Sundays will be available not
later than 6 p.m. each Monday.

Data Transmission File Sizes:

The Weekly Deposit Materials shall include the Registrar Domain Report,
Registrar Nameserver Report, and Registrar Whois Report, and may include Domain
Name Registrant Data, DNSSEC-Related Data and Registry Service Data as set forth
below.

FILE SIZE ESTIMATES

 

   

Daily

     

Weekly

    Current Data Escrow Size   up to 400 Megabytes     up to 4 Gigabytes  
Forecasted 2005 Data Escrow Size   up to 600 Megabytes     up to 7.5 Gigabytes  
Total Forecasted Escrow Size   up to 1.5 Gigabytes     up to 15 Gigabytes  

Table 1: Weekly Deposit Materials Format

Registrar Weekly Reports

--------------------------------------------------------------------------------

1. Registrar Domain Report

Title: Registrar Domain Report

Report name: rgr_domain

Description: This report contains data for domains sponsored by all registrars.
Each domain is listed once with the current status and associated nameserver.

Fields:

Domain Name (domainname)

Server name for each nameserver (servername)

Registrar ID (GURID)

Updated Date (updatedate)

Creation Date (createdate)

Expiration Date (expirationdate)

Status Information (statusname)

DNSSEC-Related Key Material (dnssec) [as applicable]

 

2. Registrar Nameserver Report

Title: Registrar Nameserver Report

Report name: rgr_nameserver

Description: This report contains data for all nameservers sponsored by all
registrars. The nameserver is listed once with all associated information.

Fields:

Server Name (servername)

IP Address (ipaddress)

Registrar ID (gurid)

Updated Date (updatedate)

Creation Date (createdate)

Expiration Date (expirationdate)

Status Information (statusname)

 

3. Registrar Whois Report

Title: Registrar Whois Report

Report name: Registrar Whois

Description: This report contains data for registrars sponsoring registered
domains and nameservers and will consist of one record for each registrar.

Fields:

Registrar ID (REGISTRARID)

Registrar Name (REGISTRARNAME)

Address 1 (ADDRESSLINE1)

Address 2 (ADDRESSLINE2)

--------------------------------------------------------------------------------

Address 3 (ADDRESSLINE3)

City (CITY)

State / Province (STATEPROVINCE)

Postal Code (POSTALCODE)

Country (COUNTRYCODE)

Telephone Number (PHONENUMBER)

Fax Number (FAXNUMBER)

E-Mail Address (EMAIL)

Whois Server (WHOISSERVER)

Web URL (URL)

Updated Date (UPDATEDATE)

Administrative Contact First Name(ADMINFNAME)

Administrative Contact Last Name (ADMINLNAME)

Administrative Contact Telephone Number (ADMINPHONE)

Administrative Contact E-Mail (ADMINEMAIL)

Billing Contact First Name (BILLINGFNAME)

Billing Contact Last Name (BILLINGLNAME)

Billing Contact Telephone Number (BILLINGPHONE)

Billing Contact E-Mail (BILLINGEMAIL)

Technical Contact First Name (TECHFNAME)

Technical Contact Last Name (TECHLNAME)

Technical Contact Telephone Number (TECHPHONE)

Technical Contact E-Mail (TECHEMAIL)

 

4. Domain Name Registrant Data

If VNDS requires registrars to provide it with registrant domain name
registration data, VNDS shall escrow such registrant domain name registration
data that is collected from registrars.

 

5. DNSSEC-Related Data

If VNDS requires registrars to provide it with DNSSEC related material necessary
to sign the .com zone (e.g., public and private portions of the .com zone)
key-signing keys and zone-signing keys, VNDS shall escrow such DNSSEC-related
material.

 

6. Registry Services Data

VNDS shall escrow data collected from registrars as part of offering Registry
Services introduced after the Effective Date of its Registry Agreement with
ICANN, if any.

Table 2: Daily Additional Deposit Format

Registrar Daily Additional Deposits

1. Registrar Transaction Report

Title: Registrar Transaction Report

--------------------------------------------------------------------------------

Report name: rgr_transaction

Description: This report contains transactions associated with a specific
registrar. Domain operations produce one row for each associated nameserver.
Nameserver operations produce one row for each associated ipaddress. A
transactionid is included to allow unique identification of transactions. The
content of columns 3 and 4 is dependent on the operation in the following ways:

operation Œ (ADD_DOMAIN, MOD_DOMAIN, DEL_DOMAIN) => [domainname][servername]

operation Œ (ADD_NAMESERVER, MOD_ NAMESERVER, DEL_ NAMESERVER) =>
[ipaddress][servername]

operation Œ (TRANSFER_DOMAIN) => [domainname][null]

Only the seven (7) operation types above are included in the report.

Fields:

transactionid

operationname

domainname | ipaddress

servername | null

transactiondate

1. ADDITIONAL TERMS AND CONDITIONS

Registry Operator shall periodically deposit into escrow all Data on a schedule
(not more frequently than weekly for a complete set of Data, and daily for
incremental updates) and in an electronic format mutually approved from time to
time by Registry Operator and ICANN, such approval not to be unreasonably
withheld by either party. The escrow shall be maintained, at Registry Operator’s
expense, by a reputable escrow agent mutually approved by Registry Operator and
ICANN, such approval also not to be unreasonably withheld by either party. The
schedule, content, format, and procedure for escrow deposits shall be as
reasonably established by ICANN from time to time. Changes to the schedule,
content, format, and procedure may be made only with the mutual written consent
of ICANN and Registry Operator (which neither party shall unreasonably withhold)
or through the establishment of Consensus Policies as set forth in
Section 3.1(b) of the Registry Agreement between VNDS and ICANN. The escrow
shall be held under an agreement, substantially in the form of Appendix 2, among
ICANN, Registry Operator, and the Escrow Agent.

2. PERIOD OF PERFORMANCE

Period of Performance shall be as defined by section 7(a) of this Escrow
Agreement.

3. FEE SCHEDULE

Fees to be paid by VNDS shall be as follows:

Initialization fee (one time only) $                     

--------------------------------------------------------------------------------

*Annual maintenance/storage fee $                     

*includes two cubic feet of storage space

Additional Services Available:

Electronic Updates

Transmitted once daily $                     

Price quoted is limited to 650 MB per update.

Electronic Updates over 650 MB $                     

Fee incurred for updates over 650 MB will be billed on a monthly basis.

Additional Services

Verification / File Listing Services $                     

(This includes up to one hour of service for each deposit)

Additional Storage Space $                     

Payable by Licensee or Producer Only Upon Release Request:

Due Only Upon Licensee’s or Producer’s

Request for Release of Deposit Materials $                     

Fees due in full, in US dollars, upon receipt of signed contract or deposit
material, whichever comes first. Thereafter, fees shall be subject to their
current pricing, provided that such prices shall not increase by more than
10% per year. The renewal date for this Agreement will occur on the anniversary
of the first invoice. If other currency acceptance is necessary, please contact
your Account Manager to make arrangements.

EXHIBIT B

The goal of the Escrow Process is to periodically encapsulate all
Registrar-specific information into a single Escrow File and to make this file
available to a third party for escrow storage. Existing Daily and Weekly reports
as well as a Registrars Report (note a) will be used to construct the Escrow
File because these reports, when taken together, describe completely the entire
set of domains, nameservers, and Registrars.

The Escrow Process employs a method of encapsulation whereby the Daily, Weekly,
and Registrar reports are concatenated, compressed, signed, and digested into a
single file. The format of this encapsulation enables the single file to be
verified for Completeness (note b), Correctness (note c), and Integrity (note d)
by a third party. The Escrow Process includes data format specification for each
report file using regular expression algebra. This format specification is
stored with the report file itself and is used for format verification later.
The report file along with data format specification is then digitally signed
for authentication, non-repudiation and message integrity verification.

--------------------------------------------------------------------------------

Verification Process

The goal of the Verification Process is to verify Completeness (note b),
Correctness (note c), and Integrity (note d) of an Escrow File. The Verification
Process uses layers of meta-data encapsulated in the Escrow File to construct a
Verification Report (note f). The verification report produced by the
verification process indicates whether the data file meets the authentication
requirements. The report has 2 sections actions and results. Actions section
describes each of the actions taken against the data file and whether those
actions met success or failure. Results section describes the results of the
Verification Process. If there was a failure in the Actions section then the
Results section will describe details of the failure and indicate that the Data
File is corrupt and cannot be verified. If no errors are present the Results
section will indicate that the file is valid.

Notes

a. Registrars Report

The existing Daily and Weekly reports associate Data and transactions to
specific Registrars by naming each report with a specific Registrar Id. The
Registrar report provides a mapping between these Registrar Ids and other
associated Registrar information such as name, credit, billing address, contact
info, and location.

b. Completeness

A data file transfer is complete if all data files transferred from the source
machine are present on the destination machine.

c. Correctness

A data file transfer is correct if each data file on the destination machine has
the same information content as that on source machine.

d. Integrity

A data file transfer has integrity if no data file was altered by a third party
while in transit.

e. Regular Expression Algebra

The regular expression algebra is a powerful data description language. The data
structure description can be as specific or generic as necessary.

f. Verification Report

The verification report produced by the Verification Process indicates whether a
Data File meets the authentication requirements. The report has 2 sections:

Actions

This section describes each of the actions taken against the Data File and
whether those actions met “SUCCESS” or “FAILURE”.

Results

This section describes the results of the Verification Process. If there was a
“FAILURE” in the Actions section then the Results section will describe details
of

--------------------------------------------------------------------------------

the failure and indicate that the Data File is corrupt and cannot be verified.
If no errors are present the Results section will enumerate the Report Files
contained within the Data File and indicate that the file is valid.

--------------------------------------------------------------------------------

.COM Agreement Appendix 2

Escrow Agreement

This Escrow Agreement (“Agreement”) is made as of this      day of
                        ,         , by and between VeriSign, Inc. (“VNDS”),
[Escrow Agent] (“Escrow Agent”), and the Internet Corporation for Assigned Names
and Numbers (“ICANN”).

Preliminary Statement. VNDS intends to deliver the “Deposit Materials” and any
“Additional Deposit” to Escrow Agent as defined and provided for herein. VNDS
desires Escrow Agent to hold the Deposit Materials and, upon certain events
described herein, deliver the Deposit Materials (or a copy thereof) to ICANN in
accordance with the terms hereof.

Now, therefore, in consideration of the foregoing, of the mutual promises
hereinafter set forth, and for other good and valuable consideration, the
receipt and sufficiency of which are hereby acknowledged, the parties agree as
follows:

1. Delivery by VNDS. VNDS shall be solely responsible for delivering to Escrow
Agent the Deposit Materials, as defined and described in Exhibit A, the “Task
Order and Statement of Work,” attached as Appendix 1 to the .com Registry
Agreement between VNDS and ICANN and incorporated herein by reference. VNDS may
elect to deliver the Deposit Materials by the “Electronic Delivery Service,”
defined in Exhibit A to Appendix 1 or in a manner mutually agreed upon by Escrow
Agent and VNDS. Upon receipt of the Deposit Materials via Electronic Delivery
Service, Escrow Agent shall download the Deposit Materials onto CD-ROM, or other
electronic storage media as mutually agreed upon by Escrow Agent and VNDS, and
generate a file listing, which Escrow Agent shall, within ten (10) business days
of the end of each calendar month, forward to VNDS, via email or United States
mail. Within two (2) business days after receiving them, Escrow Agent shall
verify that any Deposit Materials are in the proper format and appear to be
complete by performing the verification procedures specified in Exhibit B of
Appendix 1. Escrow Agent shall deliver, on the last business day of each month,
a written certification to ICANN that it has performed those verification
procedures on all Deposit Materials received during the last month and shall
deliver to ICANN a copy of the verification reports generated by those
procedures. If Escrow Agent discovers that any Deposit Materials fail the
verification procedures, Escrow Agent shall notify ICANN and VNDS of such
nonconformity within forty-eight (48) hours. Escrow Agent shall then hold the
Deposit Materials in accordance with the terms and conditions hereof.

2. Duplication; Periodic Updates

(a) Escrow Agent may duplicate the Deposit Materials by any means in order to
comply with the terms and provisions of this Agreement. Alternatively, Escrow
Agent, by notice to VNDS, may reasonably require VNDS to promptly duplicate the
Deposit Materials and forward the same to Escrow Agent.

--------------------------------------------------------------------------------

(b) VNDS shall deposit with Escrow Agent the “Additional Deposit,” as defined
and described in the attached Exhibit A of Appendix 1. Within two (2) business
days after receiving them, Escrow Agent shall verify that any Additional
Deposits are in the proper format and appear to be complete by performing the
verification procedures specified in Exhibit B of Appendix 1. Escrow Agent shall
deliver, on the last business day of each month, a written certification to
ICANN that it has performed those verification procedures on all Additional
Deposits received during the last month and shall deliver to ICANN a copy of the
verification reports generated by those procedures. If Escrow Agent discovers
that any Additional Deposits fail the verification procedures, Escrow Agent
shall notify ICANN and VNDS of such nonconformity within forty-eight (48) hours.

3. Notification of Deposits. Simultaneous with the delivery to Escrow Agent of
the Deposit Materials or any Additional Deposit, as the case may be, VNDS shall
deliver to Escrow Agent a written statement, via email, specifically identifying
all items deposited and stating that the Deposit Materials and/or any Additional
Deposit have been inspected by VNDS and are complete and accurate. Escrow Agent
shall, within ten (10) business days of receipt of any Deposit Materials or
Additional Deposit, send notification to VNDS, via email, that it has received
from VNDS such Deposit Materials and/or any such Additional Deposit. In
addition, Escrow Agent shall also include a copy of the verification report as
confirmation that it has run the verification process.

4. Delivery by Escrow Agent

4.1 Delivery by Escrow Agent to ICANN. Escrow Agent shall deliver the Deposit
Materials and any Additional Deposits received since the last submission of
Deposit Material (“Outstanding Additional Deposits”), or a complete copy
thereof, to ICANN only in the event that:

(a) VNDS notifies Escrow Agent to effect such delivery to ICANN at a specific
address, the notification being accompanied by a check payable to Escrow Agent
in the amount of one hundred dollars ($100.00); or

(b) Escrow Agent receives from ICANN:

(i) Written notification that the Registry Agreement between VNDS and ICANN
dated                         , 2005 (“Registry Agreement”) has been finally,
validly and legally terminated under Section 6 of the Registry Agreement and no
injunction or similar order has been obtained from an arbitrator or court
prohibiting ICANN from securing the data in this escrow (“Registry
Termination”);

(ii) evidence satisfactory to Escrow Agent that ICANN has previously notified
VNDS of such Registry Termination in writing;

--------------------------------------------------------------------------------

(iii) a written demand that the Deposit Materials and Outstanding Additional
Deposits be released and delivered to ICANN;

(iv) a written undertaking from ICANN that the Deposit Materials and Outstanding
Additional Deposits being supplied to ICANN will be used only as permitted under
the terms of the Registry Agreement;

(v) specific instructions from ICANN for this delivery; and

(vi) a check from VNDS, or from ICANN (who will then be reimbursed by VNDS),
payable to Escrow Agent in the amount of one hundred dollars ($100.00); or

(c) Release occurs according to Paragraph 8(b) below.

4.2 Delivery at VNDS’s Request. If the provisions of 4.1(a) are satisfied,
Escrow Agent shall, within five (5) business days after receipt of the
notification and check specified in Paragraph 4.1(a), deliver the Deposit
Materials and Outstanding Additional Deposits in accordance with the applicable
instructions.

4.3 Delivery at ICANN’s Request. If the provisions of Paragraphs 4.1(b) or
4.1(c) are satisfied, Escrow Agent within five (5) business days after receipt
of all the documents specified in these paragraphs, shall deliver the following:
(i) to VNDS, a photostatic copy of all such documents; (ii) to ICANN, as
specifically instructed by ICANN, electronic copies of the Deposit Materials and
electronic copies of the Outstanding Additional Deposits; provided, however,
that if the delivery is commenced by reason of Paragraph 4.1 (c), VNDS may make
the payment owing to Escrow Agent during the five (5) business day period
referenced above, and Escrow Agent shall not thereafter deliver to ICANN the
materials specified in subpart (ii), above. Following receipt of the notice to
VNDS under subpart (i) of the preceding sentence, VNDS shall have thirty
(30) days from the date on which VNDS receives such documents (“Objection
Period”) to notify Escrow Agent of its objection (“Objection Notice”) to the
release of the Deposit Materials to ICANN and request that the issue of
entitlement to a copy of the Deposit Materials be submitted to arbitration in
accordance with the following provisions:

(a) The sending of an Objection Notice shall not delay delivery of Deposit
Materials and Outstanding Additional Deposits to ICANN.

(b) If VNDS shall send an Objection Notice to Escrow Agent during the Objection
Period, the matter shall be submitted to and settled by arbitration by a panel
of three (3) arbitrators chosen by the American Arbitration Association in
accordance with the rules of the American Arbitration Association. The
arbitrators shall apply the law of California exclusive of its conflicts of laws
rules. At least one (1) arbitrator shall be reasonably familiar with the
Internet industry. The decision of the arbitrators shall be binding and
conclusive on all parties involved, and judgment upon their decision may be
entered in a court of competent jurisdiction. All costs of the arbitration
incurred by Escrow Agent, including reasonable attorneys’ fees and costs, shall
be paid by the party which does not

--------------------------------------------------------------------------------

prevail in the arbitration; provided, however, if the arbitration is settled
prior to a decision by the arbitrators, the parties involved in the arbitration
shall each pay an equal percentage of all such costs.

(c) Notwithstanding Paragraph 4.3(b), the parties agree that any arbitration
brought pursuant to Paragraph 4.3 shall not re-evaluate, reconsider, or
otherwise subject to review any issues, causes of action, or other claims which
were decided, in an arbitration or court decision involving the parties hereto
concerning the Registry Agreement and/or the Cooperative Agreement, and that any
decision regarding such issues or claims in an arbitration brought pursuant to
Paragraph 4.3 would be invalid, unenforceable, and not binding. The propriety,
validity, legality, or effectiveness of any terminations or actions under the
Registry Agreement and/or Cooperative Agreement shall be determined solely
through procedures and remedies provided for by those respective agreements, not
through any arbitration brought pursuant to Paragraph 4.3. Any arbitration
proceeding brought pursuant to Paragraph 4.3 shall be limited to a determination
of whether Paragraphs 4.1(b) and (c) have been satisfied.

(d) VNDS may, at any time prior to the commencement of arbitration proceedings,
notify Escrow Agent that VNDS has withdrawn the Objection Notice. Upon receipt
of any such notice from VNDS, Escrow Agent shall promptly deliver Deposit
Materials and Outstanding Additional Deposits to ICANN in accordance with the
instructions provided by ICANN.

(e) If the release of materials to ICANN pursuant to Paragraph 4.3 is judged to
be proper in any arbitration brought in accordance with Paragraph 4.3, Escrow
Agent shall promptly deliver to ICANN, in accordance with the instructions
specified in Paragraph 4.1(b)(v) above, any Deposit Materials and Outstanding
Additional Deposits that have not previously been delivered. All parties agree
that Escrow Agent shall not be required to deliver such Deposit Materials and
Outstanding Additional Deposits until all such fees then due to Escrow Agent
have been paid.

(f) If the release of the Deposit Materials and Outstanding Additional Deposits
to ICANN pursuant to Paragraph 4.3 is judged to have been improper in any
arbitration brought in accordance with Paragraph 4.3, ICANN shall promptly
return or destroy, at VNDS’s discretion, those Deposit Materials and Outstanding
Additional Deposits that were received by ICANN pursuant to Paragraph 4.3.

4.4 Delivery by Escrow Agent to VNDS. Escrow Agent shall release and deliver the
Deposit Materials and any Additional Deposit to VNDS upon termination of this
Agreement in accordance with Paragraph 7(a) or 7(b) hereof.

5. Indemnity. VNDS and ICANN shall jointly and severally indemnify and hold
harmless Escrow Agent and each of its directors, officers, agents, employees and
stockholders (“Escrow Agent Indemnitees”) absolutely and forever, from and
against any and all claims, actions, damages, suits, liabilities, obligations,
costs, fees, charges, and any other expenses whatsoever, including reasonable

--------------------------------------------------------------------------------

attorneys’ fees and costs, that may be asserted by a third party against any
Escrow Agent Indemnitee in connection with this Agreement or the performance of
Escrow Agent or any Escrow Agent Indemnitee hereunder. Escrow Agent shall
likewise indemnify VNDS, ICANN, and each of their directors, officers, agents,
employees and stockholders (“Indemnitees”) absolutely and forever, from and
against any and all claims, actions, damages, suits, liabilities, obligations,
costs, fees, charges, and any other expenses whatsoever, including reasonable
attorneys’ fees and costs, that may be asserted by a third party against any
Indemnitee in connection with the misrepresentation, negligence or misconduct of
Escrow Agent, its employees, or contractors in satisfying Escrow Agent’s
obligations under this Agreement.

6. Disputes and Interpleader.

(a) Escrow Agent may submit any dispute under this Agreement to any court of
competent jurisdiction in an interpleader or similar action other than a matter
submitted to arbitration after Escrow Agent’s receipt of an Objection Notice
under Paragraph 4 and the parties under this Agreement submit the matter to such
arbitration as described in Paragraph 4 of this Agreement. Any and all costs
incurred by Escrow Agent in connection therewith, including reasonable
attorneys’ fees and costs, shall be borne 50% by each of VNDS and ICANN.

(b) Escrow Agent shall perform any acts ordered by any court of competent
jurisdiction, without any liability or obligation to any party hereunder by
reason of such act.

7. Term and Renewal.

(a) The initial term of this Agreement shall be two (2) years, commencing on the
date hereof (the “Initial Term”). This Agreement shall be automatically extended
for an additional term of one year (“Additional Term”) at the end of the Initial
Term and at the end of each Additional Term hereunder unless, on or before
ninety (90) days prior to the end of the Initial Term or an Additional Term, as
the case may be, either (i) Escrow Agent or (ii) VNDS, with the concurrence of
ICANN, notifies the other parties that it wishes to terminate the Agreement at
the end of such term.

(b) In the event VNDS gives notice of its intent to terminate pursuant to
Paragraph 7(a), and ICANN fails to concur according to Paragraph 7(a), ICANN
shall be responsible for payment of all subsequent fees in accordance with
Exhibit A of Appendix 1 and shall have the right to terminate this Agreement at
the end of the Initial Term or any Additional Term upon giving the other parties
ninety (90) days notice.

(c) In the event of termination of this Agreement in accordance with Paragraph
7(a) or 7(b) hereof, VNDS shall pay all fees due Escrow Agent and shall promptly
notify ICANN that this Agreement has been terminated and that Escrow Agent shall
return to VNDS all copies of the Deposit Materials and any Additional Deposit
then in its possession.

--------------------------------------------------------------------------------

8. Fees. VNDS shall pay to Escrow Agent the applicable fees in accordance with
Exhibit A of Appendix 1 as compensation for Escrow Agent’s services under this
Agreement. The first year’s fees are due upon receipt of the signed contract or
Deposit Materials, whichever comes first, and shall be paid in U.S. Dollars.

(a) Payment. Escrow Agent shall issue an invoice to VNDS following execution of
this Agreement (“Initial Invoice”), on the commencement of any Additional Term
hereunder, and in connection with the performance of any additional services
hereunder. Payment is due upon receipt of an invoice. All fees and charges are
exclusive of, and VNDS is responsible for the payment of, all sales, use and
like taxes. Escrow Agent shall have no obligations under this Agreement until
the Initial Invoice has been paid in full by VNDS.

(b) Nonpayment. In the event of non-payment of any fees or charges invoiced by
Escrow Agent, Escrow Agent shall give notice of non-payment of any fee due and
payable hereunder to VNDS and, in such an event, VNDS shall have the right to
pay the unpaid fee within ten (10) business days after receipt of notice from
Escrow Agent. If VNDS fails to pay in full all fees due during such ten (10) day
period, Escrow Agent shall give notice of non-payment of any fee due and payable
hereunder to ICANN and, in such event, ICANN shall have the right to pay the
unpaid fee within ten (10) business days of receipt of such notice from Escrow
Agent. Upon payment of the unpaid fee by either VNDS or ICANN, as the case may
be, this Agreement shall continue in full force and effect until the end of the
applicable term. Upon a failure to pay the unpaid fee under this Paragraph 8(b)
by either VNDS or ICANN, or by VNDS under 4.3, the Escrow Agent shall proceed as
set forth in Paragraph 4.3 as though ICANN had requested delivery of the Deposit
Materials.

9. Ownership of Deposit Materials. The parties recognize and acknowledge that
ownership of the Deposit Materials during the effective term of this Agreement
shall remain with VNDS at all times.

10. Retention and Confidentiality.

(a) Retention. Escrow Agent shall hold and maintain the Deposit Materials in a
secure, locked, and environmentally safe facility which is accessible only to
authorized representatives of Escrow Agent. Escrow Agent shall use commercially
reasonable efforts to protect the integrity of the Deposit Materials. Each of
ICANN and VNDS shall have the right to inspect Escrow Agent’s written records
with respect to this Agreement upon reasonable prior notice and during normal
business hours.

(b) Confidentiality. Escrow Agent shall at all times protect the confidentiality
of the Deposit Materials. Except as provided in this Agreement, Escrow Agent
shall not disclose, transfer, make available, or use any Deposit Materials (or
any

--------------------------------------------------------------------------------

copies of any Deposit Materials). Should Escrow Agent be put on notice that it
is required to disclose any Deposit Materials by statute, rule, regulation,
order, or other requirement of a governmental agency, legislative body, court of
competent jurisdiction, or binding arbitral body (other than any requirement
pursuant to Sections 4 or 8(b) of this Agreement), Escrow Agent shall notify
ICANN and VNDS within seven (7) days or as soon as practicable and reasonably
cooperate with VNDS and/or ICANN in any contest of the disclosure. Should any
contest prove unsuccessful, Escrow Agent shall not be held liable for any
disclosure pursuant to such governmental, legislative, judicial, or arbitral
order, statute, rule, regulation, or other requirement.

11. Miscellaneous.

(a) Remedies. Except for misrepresentation, negligence or misconduct by Escrow
Agent, its employees, or contractors, Escrow Agent shall not be liable to VNDS
or to ICANN for any act, or failure to act, by Escrow Agent in connection with
this Agreement. Any liability of Escrow Agent regardless of the cause shall be
limited to the fees exchanged under this Agreement. Escrow Agent will not be
liable for special, indirect, incidental or consequential damages hereunder.

(b) Permitted Reliance and Abstention. Escrow Agent may rely and shall be fully
protected in acting or refraining from acting upon any notice or other document
believed by Escrow Agent in good faith to be genuine and to have been signed or
presented by the proper person or entity. Escrow Agent shall have no duties or
responsibilities except those expressly set forth herein.

(c) Independent Contractor. Escrow Agent is an independent contractor and is not
an employee or agent of either VNDS or ICANN.

(d) Amendments. This Agreement shall not be modified or amended except by
another agreement in writing executed by each of the parties hereto.

(e) Assignment. Neither VNDS nor ICANN may assign or transfer this Agreement (by
merger, sale of assets, operation of law, or otherwise), except that the rights
and obligations of VNDS or ICANN automatically shall be transferred to the
assignee of one of those parties’ rights and obligations under the Registry
Agreement. Escrow Agent may not assign or transfer this Agreement without the
prior written consent of both VNDS and ICANN.

(f) Entire Agreement. This Agreement, including all exhibits hereto, supersedes
all prior discussions, understandings and agreements between Escrow Agent and
the other parties with respect to the matters contained herein, and constitutes
the entire agreement between Escrow Agent and the other parties with respect to
the matters contemplated herein. All exhibits attached to Appendix 1,
specifically, Exhibit A (consisting of Task Order and Statement of Work, File
Size Estimates, Table 1, Table 2, and Additional Terms and Conditions), Exhibit
B, are by this reference made a part of this Agreement and are incorporated
herein.

--------------------------------------------------------------------------------

(g) Counterparts; Governing Law. This Agreement may be executed in counterparts,
each of which when so executed shall be deemed to be an original and all of
which when taken together shall constitute one and the same Agreement. This
Agreement shall be governed by and interpreted in accordance with the laws of
California, without regard to its conflicts of law principles. Except as
specifically provided for herein, all of the parties additionally consent to the
personal jurisdiction of California, acknowledge that venue is proper in any
state and Federal court in California, agree to any action related to this
Agreement properly brought in one of these courts, and waive any objection it
has or may have in the future with respect to any of the foregoing.

(h) Notices. All notices, requests, demands or other communications required or
permitted to be given or made under this Agreement shall be in writing and shall
be delivered by hand or by commercial overnight delivery service which provides
for evidence of receipt, or mailed by certified mail, return receipt requested,
postage prepaid. If delivered personally or by commercial overnight delivery
service, the date on which the notice, request, instruction or document is
delivered shall be the date on which delivery is deemed to be made, and if
delivered by mail, the date on which such notice, request, instruction or
document is received shall be the date on which delivery is deemed to be made.
Any party may change its address for the purpose of this Agreement by notice in
writing to the other parties as provided herein.

(i) Survival. Paragraphs 5, 6, 8, 9, 10 and 11 shall survive any termination of
this Agreement.

(j) No Waiver. No failure on the part of any party hereto to exercise, and no
delay in exercising any right, power or single or partial exercise of any right,
power or remedy by any party will preclude any other or further exercise thereof
or the exercise of any other right, power or remedy. No express waiver or assent
by any party hereto to any breach of or default in any term or condition of this
Agreement shall constitute a waiver of or an assent to any succeeding breach of
or default in the same or any other term or condition hereof.

IN WITNESS WHEREOF each of the parties has caused its duly authorized officer to
execute this Agreement as of the date and year first above written.

 

Escrow Agent

By:   Title:  

 

Print Name:  

 

Address:  

 

 

--------------------------------------------------------------------------------

 

Phone:

 

 

Fax:  

 

E-mail:  

 

VeriSign, Inc.

By:   Title:  

 

Print Name:  

 

Address:  

 

 

 

Phone:  

 

Fax:  

 

E-mail:  

 

Internet Corporation for Assigned Names and Numbers By:   Title:  

 

Print Name:  

 

Address:  

 

 

 

Phone:  

 

Fax:  

 

E-mail:  

 

--------------------------------------------------------------------------------

.COM Registry Agreement: Appendix 3

Zone File Access Agreement

1. PARTIES

The User named in this Agreement hereby contracts with VeriSign, Inc. (“VNDS”)
for a non-exclusive, non-transferable, limited right to access an Internet host
server or servers designated by VNDS from time to time, and to transfer a copy
of the described Data to the User’s Internet host machine specified below, under
the terms of this Agreement. Upon execution of this Agreement by VNDS, VNDS will
return a copy of this Agreement to you for your records with your UserID and
Password entered in the spaces set forth below.

2. USER INFORMATION

 

(a) User:  

 

  

(b) Contact Person:  

 

  

(c) Street Address:   

 

  

(d) City, State or Province:   

 

  

(e) Country and Postal Code:   

 

  

(f) Telephone Number:   

 

  

(including area/country code)      

(g) Fax Number:

  

 

  

(including area/country code)      

(h) E-Mail Address:

  

 

  

(i) Specific Internet host machine which will be used to access VNDS’s server to
transfer copies of the Data:

 

Name:

  

 

  

IP Address:

  

 

  

(j) Purpose(s) for which the Data will be used: During the term of this
Agreement, you may use the data for any legal purpose, not prohibited under
Section 4 below. You may incorporate some or all of the Data in your own
products or services, and distribute those products or services for a purpose
not prohibited under Section 4 below.

3. TERM

This Agreement is effective for a period of three (3) months from the date of
execution by VNDS (the “Initial Term”). Upon conclusion of the Initial Term,
this

--------------------------------------------------------------------------------

Agreement will automatically renew for successive three-month renewal terms
(each a “Renewal Term”) until terminated by either party as set forth in
Section 12 of this Agreement or one party provides the other party with a
written notice of termination at least seven (7) days prior to the end of the
Initial Term or the then current Renewal Term.

NOTICE TO USER: CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS. YOU MAY USE
THE USER ID AND ASSOCIATED PASSWORD PROVIDED IN CONJUNCTION WITH THIS AGREEMENT
ONLY TO OBTAIN A COPY OF .COM TOP-LEVEL DOMAIN (“TLD”) ZONE FILES, AND ANY
ASSOCIATED ENCRYPTED CHECKSUM FILES (COLLECTIVELY THE “DATA”), VIA THE FILE
TRANSFER PROTOCOL (“FTP”) OR HYPERTEXT TRANSFER PROTOCOL (“HTTP”) PURSUANT TO
THESE TERMS.

4. GRANT OF ACCESS

VNDS grants to you a non-exclusive, non-transferable, limited right to access an
Internet host server or servers designated by VNDS from time to time, and to
transfer a copy of the Data to the Internet host machine identified in Section 2
of this Agreement no more than once per 24 hour period without the express prior
written consent of VNDS using FTP or HTTP for the purposes described in this
Section 4. You agree that you will:

(a) use this Data only for lawful purposes but that under no circumstances will
you use this Data to: (1) allow, enable, or otherwise support any marketing
activities, regardless of the medium used. Such media include but are not
limited to e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts;
or (2) enable high volume, automated, electronic processes that send queries or
data to the systems of VNDS or any ICANN-accredited registrar, except as
reasonably necessary to register domain names or modify existing registrations.
VNDS reserves the right, with the approval of the Internet Corporation for
Assigned Names and Numbers (“ICANN”), to specify additional specific categories
of prohibited uses by giving you reasonable written notice at any time and upon
receiving such notice you shall not make such prohibited use of the Data you
obtain under this Agreement.

(b) copy the Data you obtain under this Agreement into a machine-readable or
printed form only as necessary to use it in accordance with this Agreement in
support of your use of the Data.

(c) comply with all applicable laws and regulations governing the use of the
Data.

(d) not distribute the Data you obtained under this Agreement or any copy
thereof to any other party without the express prior written consent of VNDS,
except that you may redistribute the Data insofar as it has been incorporated by
you into a value-added product or service that does not permit the extraction of
a substantial portion of the Data from the value-added product or service,
provided you prohibit the recipient of the Data from using the Data in a manner
contrary to Section 4(a).

--------------------------------------------------------------------------------

(e) take all reasonable steps to protect against unauthorized access to, use,
and disclosure of the Data you obtain under this Agreement.

5. FEE

You agree to remit in advance to VNDS a quarterly fee of $0 (USD) for the right
to access the files during either the Initial Term or Renewal Term of this
Agreement. VNDS reserves the right to adjust, with the approval of ICANN, this
fee on thirty days’ prior notice to reflect a change in the cost of providing
access to the files.

6. PROPRIETARY RIGHTS

You agree that no ownership rights in the Data are transferred to you under this
Agreement. You agree that any copies of the Data that you make will contain the
same notice that appears on and in the Data obtained under this Agreement.

7. METHOD OF ACCESS

VNDS reserves the right, with the approval of ICANN, to change the method of
access to the Data at any time. You also agree that, in the event of significant
degradation of system processing or other emergency, VNDS may, in its sole
discretion, temporarily suspend access under this Agreement in order to minimize
threats to the operational stability and security of the Internet.

8. NO WARRANTIES

The Data is being provided “as-is.” VNDS disclaims all warranties with respect
to the Data, either expressed or implied, including but not limited to the
implied warranties of merchantability, fitness for a particular purpose, and
non-infringement of third party rights. Some jurisdictions do not allow the
exclusion of implied warranties or the exclusion or limitation of incidental or
consequential damages, so the above limitations or exclusions may not apply to
you.

9. SEVERABILITY

In the event of invalidity of any provision of this Agreement, the parties agree
that such invalidity shall not affect the validity of the remaining provisions
of this Agreement.

10. NO CONSEQUENTIAL DAMAGES

In no event shall VNDS be liable to you for any consequential, special,
incidental or indirect damages of any kind arising out of the use of the Data or
the termination of this Agreement, even if VNDS has been advised of the
possibility of such damages.

--------------------------------------------------------------------------------

11. GOVERNING LAW

This Agreement shall be governed and construed in accordance with the laws of
the Virginia, USA. You agree that any legal action or other legal proceeding
relating to this Agreement or the enforcement of any provision of this Agreement
shall be brought or otherwise commenced only in the state or federal courts in
Fairfax County and the Eastern District of the Commonwealth of in Virginia, USA.
You expressly and irrevocably agree and consent to the personal jurisdiction and
venue of the federal and states courts located Virginia, USA (and each appellate
court located therein) for maters arising in connection with this Agreement or
your obtaining, use, or distribution of the Data. The United Nations Convention
on Contracts for the International Sale of Goods is specifically disclaimed.

12. TERMINATION

You may terminate this Agreement at any time by erasing the Data you obtained
under this Agreement from your Internet host machine together with all copies of
the Data and providing written notice of your termination to VNDS at 21345
Ridgetop Circle, Dulles, VA 20169, Attention: Customer Service. VNDS has the
right to terminate this Agreement immediately if you fail to comply with any
term or condition of this Agreement. You agree upon receiving notice of such
termination of this Agreement by VNDS or expiration of this Agreement to erase
the Data you obtained under this Agreement together with all copies of the Data.

13. DEFINITION

“Data” means all data contained in a DNS zone file for the Registry TLD as
provided to TLD nameservers on the Internet.

14. ENTIRE AGREEMENT

This is the entire agreement between you and VNDS concerning access and use of
the Data, and it supersedes any prior agreements or understandings, whether
written or oral, relating to access and use of the Data.

 

VeriSign, Inc.      User:    By:      By:    (sign)      (sign)    Name:     
Name:    (print)      (print)    Title:      Title:    Date:      Date:   

ASSIGNED USERID AND PASSWORD

(To be assigned by VNDS upon execution of this Agreement):

 

USERID:

   PASSWORD:

--------------------------------------------------------------------------------

.COM Agreement: Appendix 4

Registry Operator’s Monthly Report

Registry Operator shall provide the following information in its monthly
reports. Reports shall be submitted via email to <registry-reports@icann.org>.
ICANN shall use reasonable commercial efforts to preserve the confidentiality of
the information reported until three months after the end of the month to which
the report relates.

1. Accredited Registrar Status. State the number of registrars in each of the
following three categories: (1) operational, (2) ramp-up (registrars that have
received a password for access to OT&E), and (3) pre-ramp-up (registrars that
have requested access, but have not yet entered the ramp-up period).

2. Service Level Agreement Performance. Compare Service Level Agreement
requirements with actual performance measures for the reporting month.

3. TLD Zone File Access Activity. State the total number of zone file access
passwords at end of the reporting month.

4. Completed System Software Releases. Describe significant releases during the
reporting month, including release name, features, and completion date.

5. Whois Service Activity. State the number of Whois queries during the
reporting month.

6. Total Number of Transactions by Subcategory by Month. State the total number
of transactions during the reporting month, in the following subcategories:
adds, deletes, modifies, checks, renews, transfers, restores.

7. Daily Transaction Range. Tabulate the number of total daily transactions. The
range of transaction volume should be shown for each month, along with the
average daily transaction volume.

8. Per-Registrar Activity Report. This report shall be transmitted to ICANN
electronically in comma or pipe separated-value format, using the following
fields per registrar:

 

Field #

  

Field Name

  

Notes

01

   registrar-name   

registrar’s full corporate name

02

   iana-id   

http://www.iana.org/assignments/registrar-ids

03

   total-domains   

total domains under sponsorship

04

   total-nameservers   

total nameservers registered

--------------------------------------------------------------------------------

05

  

net-adds-1-yr

   domains successfully added (and not deleted within the add grace period)

06

   net-adds-2-yr   

number of domains successfully registered with an initial term of two years

07

   net-adds-3-yr   

number of domains successfully registered with an initial term of three years

08

   net-adds-4-yr   

etc.

09

   net-adds-5-yr   

“ “

10

   net-adds-6-yr   

“ “

11

   net-adds-7-yr   

“ “

12

   net-adds-8-yr   

“ “

13

   net-adds-9-yr   

“ “

14

   net-adds-10-yr   

“ “

15

   net-renews-1-yr   

domains renewed either automatically or by command (and not deleted within the
renew grace period)

16

   net-renews-2-yr   

number of domains successfully renewed with a new renewal period of two years

17

   net-renews-3-yr   

number of domains successfully renewed with a new renewal period of three years

18

   net-renews-4-yr   

etc.

19

   net-renews-5-yr   

“ “

20

   net-renews-6-yr   

“ “

21

   net-renews-7-yr   

“ “

22

   net-renews-8-yr   

“ “

23

   net-renews-9-yr   

“ “

24

   net-renews-10-yr   

“ “

25

   transfer-gaining-successful    transfers initiated by this registrar that
were ack’d by the other registrar – either by command or automatically

26

   transfer-gaining-nacked   

transfers initiated by this registrar that were n’acked by the other registrar

--------------------------------------------------------------------------------

27

   transfer-losing-successful   

transfers initiated by another registrar that this registrar ack’d – either by
command or automatically

28

   transfer-losing-nacked   

transfers initiated by another registrar that this registrar n’acked

29

   transfer-disputed-won   

number of transfer disputes in which this registrar prevailed

30

   transfer-disputed-lost   

number of transfer disputes this registrar lost

31

   transfer-disputed-nodecision   

number of transfer disputes involving this registrar with a split or no decision

32

   deleted-domains-grace   

domains deleted within the add grace period

33

   deleted-domains-nograce   

domains deleted outside the add grace period

34

   restored-domains   

domain names restored from redemption period

35

   restored-noreport   

total number of restored names for which the registrar failed to submit a
restore report

--------------------------------------------------------------------------------

.COM Agreement Appendix 5

Whois Specifications

Public Whois Specification

Registry Operator’s Whois service is the authoritative Whois service for all
second-level Internet domain names registered in the .com top-level domain and
for all hosts registered using these names. This service is available to anyone.
It is available via port 43 access and via links at the Registry Operator’s web
site. It is updated daily.

To use Registry Whois via port 43 enter the applicable parameter on the command
line as illustrated below:

 

  •  

For a domain name: whois “domain verisign.com”

 

  •  

For a registrar name: whois “registrar Go Daddy Software, Inc.”

 

  •  

For a nameserver: whois “DNS3.REGISTER.COM” or whois “nameserver 216.21.234.72”

By default, Whois performs a very broad search, looking in all record types for
matches to your query in these fields: domain name, nameserver name, nameserver
IP address, and registrar names. Use keywords to narrow the search (for example,
‘domain root’). Specify only part of the search string to perform a “partial”
search on domain. Every domain starting with the string will be found. A
trailing dot (or dots) after your text or the partial keyword indicates a
partial search. For example, entering ‘mack.’ will find “Mack”, “Mackall”,
“Mackay”, and so on.

To use Registry Whois using the web interface:

 

  •  

Go to www.verisign-grs.com

 

  •  

Click on the appropriate button (“domain,” “registrar” or “nameserver”)

 

  •  

Enter the applicable parameter:

 

  •  

Domain name including the TLD (e.g., verisign-grs.com)

 

  •  

Full name of the registrar including punctuation, “Inc.”, etc. (e.g., America
Online, Inc.)

 

  •  

Full host name or the IP address (e.g., ns1.crsnic.net or 198.41.3.39)

 

  •  

Click on the “submit” button.

--------------------------------------------------------------------------------

For all registered second-level domain names in .com, information as illustrated
in the following example is displayed, where the entry parameter is the domain
name (including the TLD):

Domain Name: VERISIGN-GRS.COM

Registrar: NETWORK SOLUTIONS, LLC.

Whois Server: whois.networksolutions.com

Referral URL: http://www.networksolutions.com

Name Server: NS1.CRSNIC.NET

Name Server: NS2.NSIREGISTRY.NET

Name Server: NS3.VERISIGN-GRS.NET

Name Server: NS4.VERISIGN-GRS.NET

Status: REGISTRAR-LOCK

Updated Date: 20-oct-2004

Creation Date: 08-sep-2000

Expiration Date: 08-sep-2008

>>> Last update of whois database: Wed, 2 Feb 2005 07:52:23 EST <<<

For all ICANN-accredited registrars who are authorized to register .com
second-level domain names through Registry Operator, information as illustrated
in the following example is displayed, where the entry parameter is the full
name of the registrar (including punctuation, “Inc.”, etc.):

Registrar Name: SAMPLE REGISTRAR, INC. DBA SAMPLE NAMES

Address: 1234 Any Way, Anytown, VA 20153, US

Phone Number: 703-555-5555

Email: registrar-agent@samplenames.net

Whois Server: whois.registrar.samplenames.com

Referral URL: www.registrar.samplenames.com

Admin Contact: Jane Doe

Phone Number: 703-555-5556

Email: janedoe@samplenames.com

Admin Contact: John Smith

Phone Number: 703-555-5557

Email: johnsmith@samplenames.com

Admin Contact: Domain Name Administrator

Phone Number: 703-555-5558

Email: dns-eng@samplenames.com

Billing Contact: Petranella Jones

Phone Number: 703-555-5559

Email: pjones@samplenames.com

Technical Contact: Harry Nerd

Phone Number: 703 555-6000

Email: harrynerd@samplenames.com

Technical Contact: Harry Nerd II

Phone Number: 703-555-6001

Email: harrynerd@samplenames.com

--------------------------------------------------------------------------------

>>> Last update of whois database: Wed, 2 Feb 2005 07:52:23 EST <<<

For all hosts registered using second-level domain names in .com, information as
illustrated in the following example is displayed, where the entry parameter is
either the full host name or the IP address:

Server Name: DNS.MOMINC.COM

IP Address: 209.143.112.34

Registrar: BULKREGISTER, LLC.

Whois Server: whois.bulkregister.com

Referral URL: http://www.bulkregister.com

>>> Last update of whois database: Wed, 2 Feb 2005 07:52:23 EST <<<

Whois Provider Data Specification

Registry Operator shall provide bulk access to up-to-date data concerning domain
name and nameserver registrations maintained by Registry Operator in connection
with the Registry TLD on a daily schedule, only for purposes of providing free
public query-based access to up-to-date data concerning domain name and
nameserver registrations in multiple TLDs, to a party designated from time to
time in writing by ICANN. The specification of the content and format of this
data, and the procedures for providing access, shall be as stated below, until
changed according to the Registry Agreement.

Content

The data shall be provided in three files:

A. Domain file. One file shall be provided reporting on the domains sponsored by
all registrars. For each domain, the file shall give the domainname, servername
for each nameserver, registrarid, and updateddate.

B. Nameserver file. One file shall be provided reporting on the nameservers
sponsored by all registrars. For each registered nameserver, the file shall give
the servername, each ipaddress, registrarid, and updateddate.

C. Registrar file. A single file shall be provided reporting on the registrars
sponsoring registered domains and nameservers. For each registrar, the following
data elements shall be given: registrarid, registrar address, registrar
telephone number, registrar e-mail address, whois server, referral URL,
updateddate and the name, telephone number, and e-mail address of all the
registrar’s administrative, billing, and technical contacts.

Format

The format for the above files shall be as specified by ICANN, after
consultation with Registry Operator.

--------------------------------------------------------------------------------

Procedures for Providing Access

The procedures for providing daily access shall be as mutually agreed by ICANN
and Registry Operator. In the absence of an agreement, the files shall be
provided by Registry Operator sending the files in encrypted form to the party
designated by ICANN by Internet File Transfer Protocol.

Whois Data Specification – ICANN

Registry Operator shall provide bulk access by ICANN to up-to-date data
concerning domain name and nameserver registrations maintained by Registry
Operator in connection with the .com TLD on a daily schedule, only for purposes
of verifying and ensuring the operational stability of Registry Services and the
DNS. The specification of the content and format of this data, and the
procedures for providing access, shall be as stated below, until changed
according to the Registry Agreement.

Content

The data shall be provided in three files:

A. Domain file. One file shall be provided reporting on the domains sponsored by
all registrars. For each domain, the file shall give the domainname, servername
for each nameserver, registrarid, and updateddate.

B. Nameserver file. One file shall be provided reporting on the nameservers
sponsored by all registrars. For each registered nameserver, the file shall give
the servername, each ipaddress, registrarid, and updateddate.

C. Registrar file. A single file shall be provided reporting on the registrars
sponsoring registered domains and nameservers. For each registrar, the following
data elements shall be given: registrarid, registrar address, registrar
telephone number, registrar e-mail address, whois server, referral URL,
updateddate and the name, telephone number, and e-mail address of all the
registrar’s administrative, billing, and technical contacts.

Format

The format for the above files shall be as specified by ICANN, after
consultation with Registry Operator.

Procedures for Providing Access

The procedures for providing daily access shall be as mutually agreed by ICANN
and Registry Operator. In the absence of an agreement, an up-to-date version
(encrypted using a public key supplied by ICANN) of the files shall be placed at
least once per day on a designated server and available for downloading by ICANN
by Internet File Transfer Protocol.

--------------------------------------------------------------------------------

.COM Agreement Appendix 6

Schedule of Reserved Names

Except to the extent that ICANN otherwise expressly authorizes in writing, the
Registry Operator shall reserve names formed with the following labels from
initial (i.e. other than renewal) registration within the TLD:

A. Labels Reserved at All Levels. The following names shall be reserved at the
second level and at all other levels within the TLD at which Registry Operator
makes registrations:

ICANN-related names:

 

  •  

aso

 

  •  

gnso

 

  •  

icann

 

  •  

internic

 

  •  

ccnso

IANA-related names:

 

  •  

afrinic

 

  •  

apnic

 

  •  

arin

 

  •  

example

 

  •  

gtld-servers

 

  •  

iab

 

  •  

iana

 

  •  

iana-servers

 

  •  

iesg

 

  •  

ietf

 

  •  

irtf

 

  •  

istf

 

  •  

lacnic

 

  •  

latnic

--------------------------------------------------------------------------------

  •  

rfc-editor

 

  •  

ripe

 

  •  

root-servers

B. Additional Second-Level Reservations. In addition, the following names shall
be reserved at the second level:

 

  •  

All single-character labels.

 

  •  

All two-character labels shall be initially reserved. The reservation of a
two-character label string shall be released to the extent that the Registry
Operator reaches agreement with the government and country-code manager, or the
ISO 3166 maintenance agency, whichever appropriate. The Registry Operator may
also propose release of these reservations based on its implementation of
measures to avoid confusion with the corresponding country codes.

C. Tagged Domain Names. All labels with hyphens in the third and fourth
character positions (e.g., “bq—1k2n4h4b” or “xn—ndk061n”)

D. Second-Level Reservations for Registry Operations. The following names are
reserved for use in connection with the operation of the registry for the
Registry TLD. They may be used by Registry Operator, but upon conclusion of
Registry Operator’s designation as operator of the registry for the Registry TLD
they shall be transferred as specified by ICANN:

 

  •  

nic

 

  •  

whois

 

  •  

www

--------------------------------------------------------------------------------

.COM Agreement Appendix 7

Functional and Performance Specifications

These functional specifications for the Registry TLD consist of the following
parts:

1. Verisign Registry Operator Registrar Protocol;

2. Supported initial and renewal registration periods;

3. Grace period policy;

4. Nameserver functional specifications;

5. Patch, update, and upgrade policy; and

6. Migration to Extensible Provisioning Protocol Plan.

7. Performance Specifications

1. Registry Operator Registrar Protocol

1.1 EXTENSIBLE PROVISIONING PROTOCOL

Registry Operator intends to implement the Extensible Provisioning Protocol
(“EPP”) in conformance with the Proposed Standard and Informational RFCs 3730,
3731, 3732, 3733, 3734, 3735, and 3915 published by the Internet Engineering
Task Force (“IETF”) and/or any successor standards, versions, modifications or
additions thereto as Registry Operator deems reasonably necessary. Subject to
the Migration to Extensible Provisioning Protocol Plan described in Section 6
below, Registry Operator will support EPP in conformance with the aforementioned
standards. Implementation of EPP is subject to Registry Operator reasonably
determining that (i) the standard can be implemented in a way that minimizes
disruption to customers; and (ii) the standard provides a solution for which the
potential advantages are reasonably justifiable when weighed against the costs
that Registry Operator and its registrar customers would incur in implementing
the new standard.

1.2 Registry Registrar Protocol

Subject to the Migration to Extensible Provisioning Protocol Plan described in
Section 6 below, Registry Operator will support Registry Registrar Protocol
(“RRP”) Version 2.1.2 in accordance with the patch, update, and upgrade policy
below, or any successor standards, versions, upgrades, modifications or
additions thereto as it deems reasonably necessary. Registry Operator will
provide the current version of the protocol for download on its website by
registrars.

--------------------------------------------------------------------------------

2. Supported initial and renewal registration periods

a. Initial registrations of Registered Names (where available according to
functional specifications and other requirements) may be made in the registry
for terms of up to ten years.

b. Renewal registrations of Registered Names (where available according to
functional specifications and other requirements) may be made in the registry
for terms not to exceed a total of ten years.

c. Upon change of sponsorship of the registration of a Registered Name from one
registrar to another, according to Part A of the ICANN Policy on Transfer of
Registrations between Registrars, the term of registration of the Registered
Name shall be extended by one year, provided that the maximum term of the
registration as of the effective date of sponsorship change shall not exceed ten
years.

d. The change of sponsorship of registration of Registered Names from one
registrar to another, according to Part B of the ICANN Policy on Transfer of
Registrations between Registrars shall not result in the extension of the term
of the registrations and Registry Operator may assist in such change of
sponsorship.

3. Grace period policy

This section describes Registry Operator’s practices for operational “Grace” and
“Pending” periods, including relationships among sequential operations that
occur within given time frames. A Grace Period refers to a specified number of
calendar days following a Registry operation in which a domain action may be
reversed and a credit may be issued to a registrar. Relevant registry operations
in this context are:

 

  •  

Registration of a new domain,

 

  •  

Extension of an existing domain,

 

  •  

Auto-Renew of an existing domain;

 

  •  

Transfer of an existing domain; and

 

  •  

Deletion of an existing domain.

Extension of a registration period is accomplished using the RRP or EPP RENEW
command or by auto-renewal; registration is accomplished using the RRP ADD
command or the EPP CREATE command; deletion/removal is

--------------------------------------------------------------------------------

accomplished using the RRP DEL command or the EPP DELETE command; transfer is
accomplished using the RRP or EPP TRANSFER command or, where ICANN approves a
bulk transfer under Part B of the ICANN Policy on Transfer of Registrations
between Registrars, using the procedures specified in that Part. Restore is
accomplished using the RRP RESTORE command or EPP UPDATE command.

There are five grace periods provided by Registry Operator’s Shared Registration
System: Add Grace Period, Renew/Extend Grace Period, Auto-Renew Grace Period,
Transfer Grace Period, and Redemption Grace Period.

A Pending Period refers to a specified number of calendar days following a
Registry operation in which final Registry action is deferred before the
operation may be completed. Relevant Registry operations in this context are:

 

  •  

Transfer of an existing domain,

 

  •  

Deletion of an existing domain, and

 

  •  

Restore of a domain name in Redemption Grace Period.

3.1 Grace Periods

3.1.1 Add Grace Period

The Add Grace Period is a specified number of calendar days following the
initial registration of a domain. The current value of the Add Grace Period for
all registrars is five calendar days. If a Delete, Extend (RRP or EPP Renew
command), or Transfer operation occurs within the five calendar days, the
following rules apply:

Delete. If a domain is deleted within the Add Grace Period, the sponsoring
Registrar at the time of the deletion is credited for the amount of the
registration; provided, however, that Registry Operator shall have the right to
charge Registrars a fee as may be set forth in its Registry-Registrar Agreement
for disproportionate deletes during the Add Grace Period. The domain is deleted
from the Registry database and is immediately available for registration by any
Registrar. See Section 3.2 for a description of overlapping grace period
exceptions.

Extend (RRP or EPP Renew command). If a domain is extended within the Add Grace
Period, there is no credit for the add. The expiration date of the domain
registration is extended by the number of years, up to a total of ten years, as
specified by the registrar’s requested Extend operation.

Transfer (other than ICANN-approved bulk transfer). Transfers under Part A of
the ICANN Policy on Transfer of Registrations between Registrars may not occur
during the Add Grace Period or at any other time within the first 60 days after
the initial registration. Enforcement is the responsibility of the Registrar
sponsoring the domain name registration and is enforced by the SRS.

--------------------------------------------------------------------------------

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be
made during the Add Grace Period according to the procedures in Part B of the
ICANN Policy on Transfer of Registrations between Registrars. The expiration
dates of transferred registrations are not affected. The losing Registrar’s
account is charged for the initial add.

3.1.2 Renew/Extend Grace Period

The Renew/Extend Grace Period is a specified number of calendar days following
the renewal/extension of a domain name registration period through an RRP
Command Renew. The current value of the Renew/Extend Grace Period is five
calendar days. If a Delete, Extend, or Transfer occurs within that five calendar
days, the following rules apply:

Delete. If a domain is deleted within the Renew/Extend Grace Period, the
sponsoring Registrar at the time of the deletion receives a credit of the
renew/extend fee. The domain immediately goes into the Redemption Grace Period.
See Section 3.2 for a description of overlapping grace period exceptions.

Extend (RRP Command “Renew”). A domain can be extended within the Renew/Extend
Grace Period for up to a total of ten years. The account of the sponsoring
Registrar at the time of the additional extension will be charged for the
additional number of years the registration is extended.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred
within the Renew/Extend Grace Period, there is no credit. The expiration date of
the domain registration is extended by one year and the years added as a result
of the Extend remain on the domain name up to a total of 10 years.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be
made during the Renew/Extend Grace Period according to the procedures in Part B
of the ICANN Policy on Transfer of Registrations between Registrars. The
expiration dates of transferred registrations are not affected. The losing
Registrar’s account is charged for the Renew/Extend operation.

3.1.3 Auto-Renew Grace Period

The Auto-Renew Grace Period is a specified number of calendar days following an
auto-renewal. An auto-renewal occurs if a domain name registration is not
renewed by the expiration date; in this circumstance the registration will be
automatically renewed by the system the first day after the expiration date. The
current value of the Auto-Renew Grace Period is 45 calendar days. If a Delete,
Extend, or Transfer occurs within the Auto-Renew Grace Period, the following
rules apply:

Delete. If a domain is deleted within the Auto-Renew Grace Period, the
sponsoring Registrar at the time of the deletion receives a credit of the
Auto-Renew fee. The domain immediately goes into the Redemption Grace Period.
See Section 3.2 for a description of overlapping grace period exceptions.

--------------------------------------------------------------------------------

Extend. A domain can be extended within the Auto-Renew Grace Period for up to a
total of ten years. The account of the sponsoring Registrar at the time of the
additional extension will be charged for the additional number of years the
registration is extended.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred
within the Auto-Renew Grace Period, the losing Registrar is credited with the
Auto-Renew charge and the year added by the Auto-Renew operation is cancelled.
The expiration date of the domain is extended by one year up to a total maximum
of ten and the gaining Registrar is charged for that additional year, even in
cases where a full year is not added because of the 10-year registration term
maximum limitation.

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be
made during the Auto-Renew Grace Period according to the procedures in Part B of
the ICANN Policy on Transfer of Registrations between Registrars. The expiration
dates of transferred registrations are not affected. The losing Registrar’s
account is charged for the Auto-Renew.

3.1.4 Transfer Grace Period

The Transfer Grace Period is a specified number of calendar days following the
transfer of a domain according to Part A of the ICANN Policy on Transfer of
Registrations between Registrars. The current value of the Transfer Grace Period
is five calendar days. If a Delete, Extend, or Transfer occurs within that five
calendar days, the following rules apply:

Delete. If a domain is deleted within the Transfer Grace Period, the sponsoring
Registrar at the time of the deletion receives a credit of the transfer fee. The
domain immediately goes into the Redemption Grace Period. See Section 3.2 for a
description of overlapping grace period exceptions.

Extend. If a domain registration is extended within the Transfer Grace Period,
there is no credit for the transfer. The Registrar’s account will be charged for
the number of years the registration is extended. The expiration date of the
domain registration is extended by the number of years, up to a maximum of ten
years, as specified by the registrar’s requested Extend operation.

Transfer (other than ICANN-approved bulk transfer). If a domain is transferred
within the Transfer Grace Period, there is no credit. The expiration date of the
domain registration is extended by one year up to a maximum term of ten years.
The ICANN Policy on Transfer of Registrations between Registrars does not allow
transfers within the first 60 days after another transfer has occurred; it is
registrars’ responsibility to enforce this restriction.

--------------------------------------------------------------------------------

Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be
made during the Transfer Grace Period according to the procedures in Part B of
the ICANN Policy on Transfer of Registrations between Registrars. The expiration
dates of transferred registrations are not affected. The losing Registrar’s
account is charged for the Transfer operation that occurred prior to the Bulk
Transfer.

3.1.5 Bulk Transfer Grace Period

There is no grace period associated with Bulk Transfer operations. Upon
completion of the Bulk Transfer, any associated fee is not refundable.

3.1.6 Redemption Grace Period

A domain name is placed in REDEMPTIONPERIOD status when a registrar requests the
deletion of a domain that is not within the Add Grace Period. A name that is in
REDEMPTIONPERIOD status will not be included in the zone file. A registrar can
not modify or purge a domain in REDEMPTIONPERIOD status. The only action a
registrar can take on a domain in REDEMPTIONPERIOD is to request that it be
restored. Any other registrar requests to modify or otherwise update the domain
will be rejected. Unless restored, the domain will be held in REDEMPTIONPERIOD
status for a specified number of calendar days. The current length of this
Redemption Period is 30 calendar days.

3.2 Overlapping Grace Periods

If an operation is performed that falls into more that one grace period, the
actions appropriate for each grace period apply (with some exceptions as noted
below).

 

  •  

If a domain is deleted within the Add Grace Period and the Extend Grace Period,
then the Registrar is credited the registration and extend amounts, taking into
account the number of years for which the registration and extend were done.

 

  •  

If a domain is auto-renewed, then extended, and then deleted within the Extend
Grace Period, the registrar will be credited for any Auto-Renew fee charged and
the number of years for the extension.

3.2.1 Overlap Exception

 

  •  

If a domain registration is extended within the Transfer Grace Period, then the
current Registrar’s account is charged for the number of years the registration
is extended.

Note: If several billable operations, including a transfer, are performed on a
domain and the domain is deleted within the grace periods of each of those
operations, only those operations that were performed after the latest transfer,
including the latest transfer, are credited to the current Registrar.

--------------------------------------------------------------------------------

3.3 Pending Periods

3.3.1 Transfer Pending Period

The Transfer Pending Period is a specified number of calendar days following a
request from a registrar (registrar A) to transfer a domain in which the current
registrar of the domain (registrar B) may explicitly approve or reject the
transfer request. The current value of the Transfer Pending Period is five
calendar days for all registrars. The transfer will be finalized upon receipt of
explicit approval or rejection from the current registrar (registrar B). If the
current registrar (registrar B) does not explicitly approve or reject the
request initiated by registrar A, the registry will approve the request
automatically after the end of the Transfer Pending Period. During the Transfer
Pending Period:

a. RRP or EPP TRANSFER request or RRP or EPP RENEW request is denied.

b. SYNC is not allowed.

c. RRP DEL or EPP DELETE request is denied.

d. Bulk Transfer operations are allowed.

e. RRP MOD or EPP UPDATE request is denied.

After a transfer of a domain, the RRP or EPP TRANSFER request may be denied for
60 days.

3.3.2 Pending Delete Period

A domain name is placed in PENDING DELETE status if it has not been restored
during the Redemption Grace Period. A name that is in PENDING DELETE status will
not be included in the zone file. All registrar requests to modify or otherwise
update a domain in PENDING DELETE status will be rejected. A domain name is
purged from the registry database a specified number of calendar days after it
is placed in PENDING DELETE status. The current length of this Pending Delete
Period is five calendar days.

4. Nameserver functional specifications

Nameserver operations for the Registry TLD shall comply with RFCs 1034, 1035,
and 2182.

5. Patch, update, and upgrade policy

Registry Operator may issue periodic patches, updates or upgrades to the
Software, RRP/EPP or APIs (“Licensed Product”) licensed under the
Registry-Registrar Agreement (the “Agreement”) that will enhance functionality
or otherwise improve the Shared Registration System under the Agreement. For the
purposes of this Part 5 of Appendix 7, the following terms have the associated
meanings set forth herein.

--------------------------------------------------------------------------------

1. A “Patch” means minor modifications to the Licensed Product made by Registry
Operator during the performance of error correction services. A Patch does not
constitute a Version.

2. An “Update” means a new release of the Licensed Product which may contain
error corrections, minor enhancements, and, in certain circumstances, major
enhancements, and which is indicated by a change in the digit to right of the
decimal point in the version number of the Licensed Product.

3. An “Upgrade” means a new release of the Licensed Product which involves the
addition of substantial or substantially enhanced functionality and which is
indicated by a change in the digit to the left of the decimal point in the
version of the Licensed Product.

4. A “Version” means the Licensed Product identified by any single version
number.

Each Update and Upgrade causes a change in version.

 

•  

Patches do not require corresponding changes to client applications developed,
implemented, and maintained by each registrar.

 

•  

Updates may require changes to client applications by each registrar in order to
take advantage of the new features and/or capabilities and continue to have
access to the Shared Registration System.

 

•  

Upgrades require changes to client applications by each registrar in order to
take advantage of the new features and/or capabilities and continue to have
access to the Shared Registration System.

Registry Operator, in its sole discretion, will deploy Patches during scheduled
and announced Shared Registration System maintenance periods.

For Updates and Upgrades, Registry Operator will give each registrar notice
prior to deploying the Updates and Upgrades into the production environment. The
notice shall be at least ninety (90) days. Such notice will include an initial
notice before deploying the Update that requires changes to client applications
or the Upgrade into the Operational Test and Evaluation (“OT&E”) environment to
which all registrars have access. Registry Operator will maintain the Update or
Upgrade in the OT&E environment for at least thirty (30) days, to allow each
registrar the opportunity to modify its client applications and complete
testing, before implementing the new code in the production environment.

This notice period shall not apply in the event Registry Operator’s system is
subject to the imminent threat of a failure or a material security threat, the
discovery of a major security vulnerability, or a Denial of Service (DoS) attack
where the Registry Operator’s systems are rendered inaccessible by being subject
to:

 

  i) excessive levels of data traffic

--------------------------------------------------------------------------------

  ii) unauthorized traffic

 

  iii) data traffic not conforming to the protocols used by the Registry

6. Migration to Extensible Provisioning Protocol Plan

Support of RRP and EPP:

Subject to this Section 6, Registry Operator will support the RRP as a “thin”
registry. Registry Operator will continue to support RRP until all impacted
registrars have migrated to EPP, but in no event later than 18 months after the
deployment date of EPP unless otherwise agreed upon in writing by Registry
Operator.

Dual RRP and EPP Operations:

 

  1. Registry Operator will provide an extended period for impacted registrars
to transition from RRP to EPP on a timeframe acceptable to registrars, but in no
event later than18 months after the deployment date of EPP unless otherwise
agreed upon in writing by Registry Operator.

 

  2. Registry Operator’s RRP implementation will be completely replaced by EPP
on a date determined jointly by Registry Operator, ICANN, and the registrar
community, which date shall not be later than 18 months after the deployment
date of EPP unless otherwise agreed upon in writing by Registry Operator.

 

  3. Registry Operator’s EPP implementation will not support the use of authinfo
codes to verify transfers until all registrars have migrated to EPP.

7. Performance Specifications

For purposes of this Section 7, “DNS Name Server” means the service complying
with RFC 1034 made available on TCP/UDP port 53 on Registry Operator’s selected
servers; “Round-trip” means the amount of time that it takes for a remote
nameserver to respond to queries; “Core Internet Service Failure” means
extraordinary and identifiable events beyond the control of Registry Operator
affecting the Internet services to be measured pursuant to this section,
including but not limited, to congestion collapse, partitioning, power grid
failures, and routing failures; DNS Name Server unavailability shall mean less
than four (4) sites on the Registry Operator’s constellation are returning
answers to queries with less than 2% packet loss averaged over a Monthly
Timeframe; and “Monthly Timeframe” means each single calendar month beginning
and ending at 0000 Coordinated Universal Time (UTC). The requirements in this
Section 7 set forth below are not matters subject to SLA Credits under the
Service Level Agreement set forth on Appendix 10 or obligations upon which a
breach by Registry Operator of the Registry Agreement may be asserted.

--------------------------------------------------------------------------------

A. Cross-Network Name Server Performance Requirements. The committed performance
specification for cross-network name server performance is a measured Round-trip
of under 300 milliseconds and measured packet loss of under 10% over the course
of a Monthly Timeframe. Cross-network name server performance measurements may
be conducted by ICANN, pursuant to the terms of confidentiality agreements
executed both by ICANN and its employee or consultant conducting the testing, in
the following manner:

1. The measurements may be conducted by sending strings of DNS request packets
from each of four measuring locations to each of the .com DNS Name Servers and
observing the responses from the .com DNS Name Servers. (These strings of
requests and responses are referred to as a “CNNP Test”.) The measuring
locations will be four root name server locations on the US East Coast, US West
Coast, Asia, and Europe.

2. Each string of request packets will consist of 100 UDP packets at 10 second
intervals requesting nameserver records for arbitrarily selected .com
second-level domains, preselected to ensure that the names exist in the Registry
TLD and are resolvable. The packet loss (i.e. the percentage of response packets
not received) and the average Round-trip time for response packets received may
be noted.

3. To meet the packet loss and Round-trip requirements for a particular CNNP
Test, all three of the following must be true:

(a) The Round-trip and packet loss from each measurement location to at least
one .com name server must not exceed the required values;

(b) The packet loss to each of the .com name servers from at least one of the
measurement locations must not exceed the required value; and

(c) Any failing CNNP Test result obtained during an identified Core Internet
Service Failure shall not be considered.

4. To ensure a properly diverse testing sample, ICANN will conduct the CNNP
Tests at varying times (i.e. at different times of the day, as well as on
different days of the week). Registry Operator may only be deemed to have
persistently failed to meet the cross-network name server performance
requirement only if the .com DNS Name Servers fail the CNNP Tests (see
Section 7.3 above) with no less than three consecutive failed CNNP Tests.

5. In the event of persistent failure ( defined as failure of three consecutive
tests) of the CNNP Tests, ICANN will give Registry Operator written notice of
the failures (with backup data) and Registry Operator will have sixty days to
cure the failure.

6. Sixty days prior to the commencement of testing under this provision, ICANN
will provide Registry Operator with the opportunity to evaluate the testing
tools, root name server locations and procedures to be used by ICANN. In the
event that Registry Operator does not approve of such tools and procedures,
ICANN will work directly with Registry Operator to make necessary modifications.

--------------------------------------------------------------------------------

7. ICANN will provide written notification to Registry Operator of the results
of any testing within 5 days of completion of testing, including the method used
for testing, administrator used to conduct the test and the location of testing.
Within 30 days of receipt of notice the testing results, Registry Operator may
request that the test be re-administered in the presence of a Registry Operator
employee. This second test must be administered within 30 days of Registry
Operator’s request.

B. Service Availability—DNS Name Server = 100% per Monthly Timeframe. Service
Availability as it applies to the DNS Name Server refers to the ability of the
DNS Name Server to resolve a DNS query from an Internet user. DNS Name Server
unavailability will be logged with the Registry Operator as Unplanned Outage
Minutes. Registry Operator will log DNS Name Server unavailability when such
unavailability is detected by VeriSign monitoring tools. Any DNS Name Server
unavailability occurring during an identified Core Internet Service Failure
shall not be considered.

 

Monthly Metric

  

Requirement

Total outage

   8 hours

Unplanned outage

   4 hours

Major upgrade outage

   12 hours (two allocated per year)

Check domain average

   3 seconds

Add domain average

   5 seconds

--------------------------------------------------------------------------------

.COM Agreement Appendix 8

Registry-Registrar Agreement

This Registry-Registrar Agreement (the “Agreement”) is dated as of
                    ,          (“Effective Date”) by and between VeriSign, Inc.,
a Delaware corporation, with a place of business located at 21345 Ridgetop
Circle, Dulles, , Virginia 20166 (“VNDS”), and
                                        , a
                                         corporation, with its principal place
of business located at                                         
                     (“Registrar”). VNDS and Registrar may be referred to
individually as a “Party” and collectively as the “Parties.”

WHEREAS, multiple registrars provide Internet domain name registration services
within the .COM top-level domain wherein VNDS operates and maintains certain TLD
servers and zone files;

WHEREAS, Registrar wishes to register second-level domain names in the multiple
registrar system for the .COM TLD.

NOW, THEREFORE, for and in consideration of the mutual promises, benefits and
covenants contained herein and for other good and valuable consideration, the
receipt, adequacy and sufficiency of which are hereby acknowledged, VNDS and
Registrar, intending to be legally bound, hereby agree as follows:

1. DEFINITIONS

1.1. “DNS” refers to the Internet domain name system.

1.2. “ICANN” refers to the Internet Corporation for Assigned Names and Numbers.

1.3. “IP” means Internet Protocol.

1.4. “Registered Name” refers to a domain name within the domain of the Registry
TLD, whether consisting of two or more (e.g., john.smith.name) levels, about
which VNDS or an affiliate engaged in providing registry services maintains data
in a registry database, arranges for such maintenance, or derives revenue from
such maintenance. A name in a registry database may be a Registered Name even
though it does not appear in a TLD zone file (e.g., a registered but inactive
name).

1.5. “Registry TLD” means the .COM TLD.

1.6. The “System” refers to the multiple registrar system operated by VNDS for
registration of Registered Names in the Registry TLD.

--------------------------------------------------------------------------------

1.7. A “TLD” is a top-level domain of the DNS.

1.8. The “Licensed Product” refers to the intellectual property required to
access the Supported Protocol, and to the APIs, and software, collectively.

1.9. “EPP” means the Extensible Provisioning Protocol.

1.10. “RRP” means the Registry Registrar Protocol.

1.11. “Supported Protocol” means VNDS’s implementation of RRP, EPP, or any
successor protocols supported by the System.

2. OBLIGATIONS OF THE PARTIES

2.1. System Operation and Access. Throughout the Term of this Agreement, VNDS
shall operate the System and provide Registrar with access to the System to
transmit domain name registration information for the Registry TLD to the
System.

2.2. Distribution of RRP, EPP, APIs and Software. No later than three business
days after the Effective Date of this Agreement, VNDS shall make available to
Registrar (i) full documentation of the Supported Protocol, (ii) “C” and/or
“Java” application program interfaces (“APIs”) to the Supported Protocol with
documentation, and (iii) reference client software (“Software”) that will allow
Registrar to develop its system to register second-level domain names through
the System for the Registry TLD. If VNDS elects to modify or upgrade the APIs
and/or Supported Protocol, VNDS shall provide updated APIs to the Supported
Protocol with documentation and updated Software to Registrar promptly as such
updates become available.

2.3. Registrar Responsibility for Customer Support. Registrar shall be
responsible for providing customer service (including domain name record
support), billing and technical support, and customer interface to accept
customer (the “Registered Name Holder”) orders.

2.4. Data Submission Requirements. As part of its registration and sponsorship
of Registered Names in the Registry TLD, Registrar shall submit complete data as
required by technical specifications of the System that are made available to
Registrar from time to time.

2.5. License. Registrar grants VNDS as Registry a non-exclusive nontransferable
worldwide limited license to the data elements consisting of the Registered
Name, the IP addresses of nameservers, and the identity of the registering
registrar for propagation of and the provision of authorized access to the TLD
zone files or as otherwise required or permitted by VNDS’s Registry Agreement
with ICANN concerning the operation of the Registry TLD, as may be amended from
time to time.

--------------------------------------------------------------------------------

2.6. Registrar’s Registration Agreement and Domain Name Dispute Policy.

Registrar shall have in effect an electronic or paper registration agreement
with the Registered Name Holder. The initial form of Registrar’s registration
agreement is attached as Exhibit A (which may contain multiple alternative forms
of the registration agreement). Registrar may from time to time amend its
form(s) of registration agreement or add alternative forms of registration
agreement, provided a copy of the amended or alternative registration agreement
is made available to VNDS in advance of the use of such amended registration
agreement. Registrar shall include in its registration agreement those terms
required by this Agreement and other terms that are consistent with Registrar’s
obligations to VNDS under this Agreement. Registrar shall have developed and
employ in its domain name registration business a domain name dispute policy, a
copy of which is attached to this Agreement as Exhibit B (which may be amended
from time to time by Registrar, provided a copy is made available to VNDS in
advance of any such amendment).

2.7. Secure Connection. Registrar agrees to develop and employ in its domain
name registration business all necessary technology and restrictions to ensure
that its connection to the System is secure. All data exchanged between
Registrar’s system and the System shall be protected to avoid unintended
disclosure of information. Each RRP or EPP session shall be authenticated and
encrypted using two-way secure socket layer (“SSL”) protocol. Registrar agrees
to authenticate every RRP or EPP client connection with the System using both an
X.509 server certificate issued by a commercial Certification Authority
identified by the Registry and its Registrar password, which it shall disclose
only to its employees with a need to know. Registrar agrees to notify Registry
within four hours of learning that its Registrar password has been compromised
in any way or if its server certificate has been revoked by the issuing
Certification Authority or compromised in any way.

2.7.1 Authorization Codes. At such time as Registrar employs EPP, Registrar
shall not provide identical Registrar-generated authorization <authinfo> codes
for domain names registered by different registrants with the same Registrar.
VNDS in its sole discretion may choose to modify <authinfo> codes for a given
domain and shall notify the sponsoring registrar of such modifications via EPP
compliant mechanisms (i.e. EPP<poll> or EPP<domain:Info>). Documentation of
these mechanisms shall be made available to Registrar by VNDS. The Registrar
shall provide the Registered Name Holder with timely access to the authorization
code along with the ability to modify the authorization code. Registrar shall
respond to any inquiry by a Registered Name Holder regarding access to and/or
modification of an authorization code within ten (10) calendar days.

--------------------------------------------------------------------------------

2.8. Domain Name Lookup Capability. Registrar agrees to employ in its domain
name registration business VNDS’s registry domain name lookup capability to
determine if a requested domain name is available or currently unavailable for
registration.

2.9. Transfer of Sponsorship of Registrations. Registrar agrees to implement
transfers of Registered Name registrations from another registrar to Registrar
and vice versa pursuant to the Policy on Transfer of Registrations Between
Registrars as may be amended from time to time by ICANN (the “Transfer Policy”).

2.10. Time. Registrar agrees that in the event of any dispute concerning the
time of the entry of a domain name registration into the registry database, the
time shown in the VNDS records shall control.

2.11. Compliance with Operational Requirements. Registrar agrees to comply with,
and shall include in its registration agreement with each Registered Name Holder
as appropriate, operational standards, policies, procedures, and practices for
the Registry TLD established from time to time by VNDS in a non-arbitrary manner
and applicable to all registrars (“Operational Requirements”), including
affiliates of VNDS, and consistent with VNDS’s Registry Agreement with ICANN, as
applicable, upon VNDS’s notification to Registrar of the establishment of those
terms and conditions.

2.12. Resolution of Technical Problems. Registrar agrees to employ necessary
employees, contractors, or agents with sufficient technical training and
experience to respond to and fix all technical problems concerning the use of
the Supported Protocol and the APIs in conjunction with Registrar’s systems.
Registrar agrees that in the event of significant degradation of the System or
other emergency, or upon Registrar’s violation of Operational Requirements, VNDS
may, in its sole discretion, temporarily suspend or restrict access to the
System. Such temporary suspensions or restrictions shall be applied in a
nonarbitrary manner and shall apply fairly to any registrar similarly situated,
including affiliates of VNDS.

2.13. Prohibited Domain Name Registrations. In addition to complying with ICANN
standards, policies, procedures, and practices limiting domain names that may be
registered, Registrar agrees to comply with applicable statutes and regulations
limiting the domain names that may be registered.

2.14. Indemnification Required of Registered Name Holders. In its registration
agreement with each Registered Name Holder, Registrar shall require each
Registered Name holder to indemnify, defend and hold harmless VNDS, and its
directors, officers, employees, agents, and affiliates from and against any and
all claims, damages, liabilities, costs and expenses, including reasonable legal
fees and expenses arising out of or relating to the Registered Name holder’s
domain name registration.

--------------------------------------------------------------------------------

3. LICENSE

3.1. License Grant. Subject to the terms and conditions of this Agreement, VNDS
hereby grants Registrar and Registrar accepts a non-exclusive, nontransferable,
worldwide limited license to use for the Term and purposes of this Agreement the
Licensed Product, as well as updates and redesigns thereof, to provide domain
name registration services in the Registry TLD only and for no other purpose.
The Licensed Product, as well as updates and redesigns thereof, will enable
Registrar to register domain names in the Registry TLD with the Registry on
behalf of its Registered Name Holders. Registrar, using the Licensed Product, as
well as updates and redesigns thereof, will be able to invoke the following
operations on the System: (i) check the availability of a domain name,
(ii) register a domain name, (iii) re-register a domain name, (iv) cancel the
registration of a domain name it has registered, (v) update the nameservers of a
domain name, (vi) transfer a domain name from another registrar to itself with
proper authorization, (vii) query a domain name registration record,
(viii) register a nameserver, (ix) update the IP addresses of a nameserver,
(x) delete a nameserver, (xi) query a nameserver, and (xii) establish and end an
authenticated session.

3.2. Limitations on Use. Notwithstanding any other provisions in this Agreement,
except with the written consent of VNDS, Registrar shall not: (i) sublicense the
Licensed Product or otherwise permit any use of the Licensed Product by or for
the benefit of any party other than Registrar, (ii) publish, distribute or
permit disclosure of the Licensed Product other than to employees, contractors,
and agents of Registrar for use in Registrar’s domain name registration
business, (iii) decompile, reverse engineer, copy or re-engineer the Licensed
Product for any unauthorized purpose, (iv) use or permit use of the Licensed
Product in violation of any federal, state or local rule, regulation or law, or
for any unlawful purpose. Registrar agrees to employ the necessary measures to
prevent its access to the System granted hereunder from being used to (i) allow,
enable, or otherwise support the transmission by e-mail, telephone, or facsimile
of mass unsolicited, commercial advertising or solicitations to entities other
than Registrar’s customers; or (ii) enable high volume, automated, electronic
processes that send queries or data to the systems of VNDS or any
ICANN-Accredited Registrar, except as reasonably necessary to register domain
names or modify existing registrations.

3.3. Changes to Licensed Materials. VNDS may from time to time replace or make
modifications to the Licensed Product licensed hereunder. In the event of a
change in the Supported Protocol from RRP to EPP, Registrar shall migrate to, or
implement, such Supported Protocols within eighteen (18) months of notice of
such modification. For all other changes, VNDS will provide Registrar with at
least ninety (90) days notice prior to the implementation of any material
changes to the Supported Protocol, APIs or software licensed hereunder.

--------------------------------------------------------------------------------

4. SUPPORT SERVICES

4.1. Engineering Support. VNDS agrees to provide Registrar with reasonable
engineering telephone support (between the hours of 9 a.m. to 5 p.m. EST or at
such other times as may be mutually agreed upon) to address engineering issues
arising in connection with Registrar’s use of the System.

4.2. Customer Service Support. During the Term of this Agreement, VNDS will
provide reasonable telephone and e-mail customer service support to Registrar,
not Registered Name Holder or prospective customers of Registrar, for
nontechnical issues solely relating to the System and its operation. VNDS will
provide Registrar with a telephone number and e-mail address for such support
during implementation of the Supported Protocol, APIs and Software. First-level
telephone support will be available on a 7-day/24-hour basis. VNDS will provide
a web-based customer service capability in the future and such web-based support
will become the primary method of customer service support to Registrar at such
time.

5. FEES

5.1. Registration Fees.

(a) Registrar agrees to pay VNDS the non-refundable fees set forth in Exhibit D
for initial and renewal registrations and other services provided by VNDS
(collectively, the “Registration Fees”).

(b) VNDS reserves the right to adjust the Registration Fees, provided that any
price increase shall be made only upon six (6) months prior notice to Registrar,
and provided that such adjustments are consistent with VNDS’s Registry Agreement
with ICANN.

(c) Registrars shall provide VNDS a payment security comprised of an irrevocable
letter of credit, cash deposit account or other acceptable credit terms agreed
by the Parties (the “Payment Security”). VNDS will invoice Registrar monthly in
arrears for each month’s Registration Fees. All Registration Fees are due
immediately upon receipt of VNDS’s invoice and shall be secured by the Payment
Security. If Registrar’s Payment Security is depleted, registration of domain
names for the Registrar will be suspended and new registrations will not be
accepted until the Payment Security is replenished.

5.2. Change in Registrar Sponsoring Domain Name. Registrar may assume
sponsorship of a Registered Name Holder’s existing domain name registration from
another registrar by following the Transfer Policy.

--------------------------------------------------------------------------------

(a) For each transfer of the sponsorship of a domain-name registration under the
Transfer Policy, Registrar agrees to pay VNDS the renewal registration fee
associated with a one-year extension, as set forth above. The losing registrar’s
Registration Fees will not be refunded as a result of any such transfer.

(b) For a transfer approved by ICANN under Part B of the Transfer Policy,
Registrar agrees to pay VNDS US $0 (for transfers of 50,000 names or fewer) or
US $50,000 (for transfers of more than 50,000 names).

Fees under this Section 5.2 shall be due immediately upon receipt of VNDS’s
invoice pursuant to the Payment Security.

5.3. Charges for ICANN Fees. Registrar agrees to pay to VNDS, within ten
(10) days of VNDS’s invoice, any variable registry-level fees paid by VNDS to
ICANN, which fees shall be secured by the Payment Security. The fee will consist
of two components; each component will be calculated by ICANN for each
registrar:

(a) The transactional component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year but shall not exceed US$0.25.

(b) The per-registrar component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year, but the sum of the per registrar fees calculated
for all registrars shall not exceed the total Per-Registrar Variable funding
established pursuant to the approved 2004-2005 ICANN Budget.

5.4. Non-Payment of Fees. Timely payment of fees owing under this Section 5 is a
material condition of performance under this Agreement. In the event that
Registrar fails to pay its fees within five (5) days of the date when due, VNDS
may: (i) stop accepting new initial or renewal registrations from Registrar;
(ii) delete the domain names associated with invoices not paid in full from the
Registry database; (iii) give written notice of termination of this Agreement
pursuant to Section 6.1(b) below; and (iv) pursue any other remedy under this
Agreement.

6. MISCELLANEOUS

6.1. Term of Agreement and Termination.

(a) Term of the Agreement; Revisions. The duties and obligations of the Parties
under this Agreement shall apply from the Effective Date through and including
the last day of the calendar month sixty (60) months from the Effective Date
(the “Initial Term”). Upon conclusion of the Initial Term, all provisions of
this

--------------------------------------------------------------------------------

Agreement will automatically renew for successive five (5) year renewal periods
until the Agreement has been terminated as provided herein, Registrar elects not
to renew, or VNDS ceases to operate the registry for the Registry TLD. In the
event that revisions to VNDS’s Registry-Registrar Agreement are approved or
adopted by ICANN, Registrar shall have thirty (30) days from the date of notice
of any such revision to review, comment on, and execute an amendment
substituting the revised agreement in place of this Agreement, or Registrar may,
at its option exercised within such thirty (30) day period, terminate this
Agreement immediately by giving written notice to VNDS; provided, however, that
in the event VNDS does not receive such executed amendment or notice of
termination from Registrar within such thirty (30) day period of the date of the
notice, Registrar shall be deemed to have executed such amendment as of the
thirty-first (31st) day after the date of the notice.

(b) Termination For Cause. In the event that either Party materially breaches
any term of this Agreement including any of its representations and warranties
hereunder and such breach is not substantially cured within thirty (30) calendar
days after written notice thereof is given by the other Party, then the
nonbreaching Party may, by giving written notice thereof to the other Party,
terminate this Agreement as of the date specified in such notice of termination.

(c) Termination at Option of Registrar. Registrar may terminate this Agreement
at any time by giving VNDS thirty (30) days notice of termination.

(d) Termination Upon Loss of Registrar’s Accreditation. This Agreement shall
terminate in the event Registrar’s accreditation for the Registry TLD by ICANN,
or its successor, is terminated or expires without renewal.

(e) Termination in the Event that Successor Registry Operator is Named. This
Agreement shall terminate in the event that the U.S. Department of Commerce or
ICANN, as appropriate, designates another entity to operate the registry for the
Registry TLD.

(f) Termination in the Event of Bankruptcy. Either Party may terminate this
Agreement if the other Party is adjudged insolvent or bankrupt, or if
proceedings are instituted by or against a Party seeking relief, reorganization
or arrangement under any laws relating to insolvency, or seeking any assignment
for the benefit of creditors, or seeking the appointment of a receiver,
liquidator or trustee of a Party’s property or assets or the liquidation,
dissolution or winding up of a Party’s business.

(g) Effect of Termination. Upon expiration or termination of this Agreement,
VNDS will, to the extent it has the authority to do so, complete the
registration of all domain names processed by Registrar prior to the date of
such expiration or termination, provided that Registrar’s payments to VNDS for
Registration Fees are current and timely. Immediately upon any expiration or
termination of this

--------------------------------------------------------------------------------

Agreement, Registrar shall (i) transfer its sponsorship of Registered Name
registrations to another licensed registrar(s) of the Registry, in compliance
with Part B of the Transfer Policy, or any other procedures established or
approved by the U.S. Department of Commerce or ICANN, as appropriate, and
(ii) either return to VNDS or certify to VNDS the destruction of all data,
software and documentation it has received under this Agreement.

(h) Survival. In the event of termination of this Agreement, the following shall
survive: (i) Sections 2.5, 2.6, 2.14, 6.1(g), 6.2, 6.6, 6.7, 6.10, 6.12, 6.13,
6.14, and 6.16; (ii) the Registered Name Holder’s obligations to indemnify,
defend, and hold harmless VNDS, as stated in Section 2.14; and (iii) Registrar’s
payment obligations as set forth in Section 5 with respect to fees incurred
during the term of this Agreement. Neither Party shall be liable to the other
for damages of any sort resulting solely from terminating this Agreement in
accordance with its terms but each Party shall be liable for any damage arising
from any breach by it of this Agreement.

6.2. No Third Party Beneficiaries; Relationship of the Parties. This Agreement
does not provide and shall not be construed to provide third parties (i.e.,
non-parties to this Agreement), including any Registered Name Holder, with any
remedy, claim, cause of action or privilege. Nothing in this Agreement shall be
construed as creating an employer-employee or agency relationship, a partnership
or a joint venture between the Parties.

6.3. Force Majeure. Neither Party shall be responsible for any failure to
perform any obligation or provide service hereunder because of any Act of God,
strike, work stoppage, governmental acts or directives, war, riot or civil
commotion, equipment or facilities shortages which are being experienced by
providers of telecommunications services generally, or other similar force
beyond such Party’s reasonable control.

6.4. Further Assurances. Each Party hereto shall execute and/or cause to be
delivered to each other Party hereto such instruments and other documents, and
shall take such other actions, as such other Party may reasonably request for
the purpose of carrying out or evidencing any of the transactions contemplated
by this Agreement.

6.5. Amendment in Writing. Except as otherwise provided in this Agreement, any
amendment or supplement to this Agreement shall be in writing and duly executed
by both Parties. Any new services approved by ICANN and purchased by Registrar
will be subject to such terms and conditions as may be established by VNDS
through an appendix to this Agreement executed by Registrar and VNDS.

6.6. Attorneys’ Fees. If any legal action or other legal proceeding (including
arbitration) relating to the performance under this Agreement or the enforcement

--------------------------------------------------------------------------------

of any provision of this Agreement is brought against either Party hereto, the
prevailing Party shall be entitled to recover reasonable attorneys’ fees, costs
and disbursements (in addition to any other relief to which the prevailing Party
may be entitled).

6.7. Dispute Resolution; Choice of Law; Venue. The Parties shall attempt to
resolve any disputes between them prior to resorting to litigation. This
Agreement is to be construed in accordance with and governed by the internal
laws of the Commonwealth of Virginia, United States of America without giving
effect to any choice of law rule that would cause the application of the laws of
any jurisdiction other than the internal laws of the Commonwealth of Virginia to
the rights and duties of the Parties. Any legal action or other legal proceeding
relating to this Agreement or the enforcement of any provision of this Agreement
shall be brought or otherwise commenced in any state or federal court located in
the eastern district of the Commonwealth of Virginia. Each Party to this
Agreement expressly and irrevocably consents and submits to the jurisdiction and
venue of each state and federal court located in the eastern district of the
Commonwealth of Virginia (and each appellate court located in the Commonwealth
of Virginia) in connection with any such legal proceeding.

6.8. Notices. Any notice or other communication required or permitted to be
delivered to any Party under this Agreement shall be in writing and shall be
deemed properly delivered, given and received when delivered (by hand, by
registered mail, by courier or express delivery service, by e-mail or by
telecopier during business hours) to the address or telecopier number set forth
beneath the name of such Party below, unless party has given a notice of a
change of address in writing:

 

if to Registrar:

 

 

 

 

 

 

 

with a copy to:

 

 

 

 

 

 

if to VNDS:

General Counsel

--------------------------------------------------------------------------------

VeriSign, Inc.

487 E. Middlefield Road

Mountain View, California 94043

Telephone: 1/650/961/7500

Facsimile:1/650/426/5113; and

General Manager

VeriSign Naming and Directory Services

21345 Ridgetop Circle

Dulles, Virginia 20166

Telephone: 1/703/948/3200

Facsimile: 1/703/421/4873; and

Associate General Counsel

VeriSign, Inc.

21355 Ridgetop Circle

Dulles, VA 20166

Telephone: 1/703/948/3200

Facsimile: 1/703/450/7492

6.9. Assignment/Sublicense. Except as otherwise expressly provided herein, the
provisions of this Agreement shall inure to the benefit of and be binding upon,
the successors and permitted assigns of the Parties hereto. Registrar shall not
assign, sublicense or transfer its rights or obligations under this Agreement to
any third person without the prior written consent of VNDS.

6.10. Use of Confidential Information. The Parties’ use and disclosure of
Confidential Information disclosed hereunder are subject to the terms and
conditions of the Parties’ Confidentiality Agreement (Exhibit C) that will be
executed contemporaneously with this Agreement. Registrar agrees that the RRP,
APIs and Software are the Confidential Information of VNDS.

6.11. Delays or Omissions; Waivers. No failure on the part of either Party to
exercise any power, right, privilege or remedy under this Agreement, and no
delay on the part of either Party in exercising any power, right, privilege or
remedy under this Agreement, shall operate as a waiver of such power, right,
privilege or remedy; and no single or partial exercise or waiver of any such
power, right, privilege or remedy shall preclude any other or further exercise
thereof or of any other power, right, privilege or remedy. No Party shall be
deemed to have waived any claim arising out of this Agreement, or any power,
right, privilege or remedy under this Agreement, unless the waiver of such
claim, power, right, privilege or remedy is expressly set forth in a written
instrument duly executed and delivered on behalf of such Party; and any such
waiver shall not be applicable or have any effect except in the specific
instance in which it is given.

6.12. Limitation of Liability. IN NO EVENT WILL VNDS BE LIABLE TO

--------------------------------------------------------------------------------

REGISTRAR FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR
CONSEQUENTIAL DAMAGES, OR ANY DAMAGES RESULTING FROM LOSS OF PROFITS, ARISING
OUT OF OR IN CONNECTION WITH THIS AGREEMENT, EVEN IF VNDS HAS BEEN ADVISED OF
THE POSSIBILITY OF SUCH DAMAGES.

6.13. Construction. The Parties agree that any rule of construction to the
effect that ambiguities are to be resolved against the drafting Party shall not
be applied in the construction or interpretation of this Agreement.

6.14. Intellectual Property. Subject to Section 2.5 above, each Party will
continue to independently own its intellectual property, including all patents,
trademarks, trade names, service marks, copyrights, trade secrets, proprietary
processes and all other forms of intellectual property.

6.15. Representations and Warranties

(a) Registrar. Registrar represents and warrants that: (1) it is a corporation
duly incorporated, validly existing and in good standing under the law of the
                            , (2) it has all requisite corporate power and
authority to execute, deliver and perform its obligations under this Agreement,
(3) it is, and during the Term of this Agreement will continue to be, accredited
by ICANN or its successor, pursuant to an accreditation agreement dated after
November 4, 1999, (4) the execution, performance and delivery of this Agreement
has been duly authorized by Registrar, (5) no further approval, authorization or
consent of any governmental or regulatory authority is required to be obtained
or made by Registrar in order for it to enter into and perform its obligations
under this Agreement, and (6) Registrar’s Surety Instrument provided hereunder
is a valid and enforceable obligation of the surety named on such Surety
Instrument.

(b) VNDS. VNDS represents and warrants that: (1) it is a corporation duly
incorporated, validly existing and in good standing under the laws of the State
of Delaware, (2) it has all requisite corporate power and authority to execute,
deliver and perform its obligations under this Agreement, (3) the execution,
performance and delivery of this Agreement has been duly authorized by VNDS, and
(4) no further approval, authorization or consent of any governmental or
regulatory authority is required to be obtained or made by VNDS in order for it
to enter into and perform its obligations under this Agreement.

(c) Disclaimer of Warranties. The RRP, EPP, APIs and Software are provided
“as-is” and without any warranty of any kind. VNDS EXPRESSLY DISCLAIMS ALL
WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY OR SATISFACTORY QUALITY
AND FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
VNDS DOES NOT WARRANT THAT THE

--------------------------------------------------------------------------------

FUNCTIONS CONTAINED IN THE RRP, APIs OR SOFTWARE WILL MEET REGISTRAR’S
REQUIREMENTS, OR THAT THE OPERATION OF THE RRP, APIs OR SOFTWARE WILL BE
UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE RRP, APIs OR SOFTWARE WILL
BE CORRECTED. FURTHERMORE, VNDS DOES NOT WARRANT NOR MAKE ANY REPRESENTATIONS
REGARDING THE USE OR THE RESULTS OF THE RRP, APIs, SOFTWARE OR RELATED
DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR
OTHERWISE. SHOULD THE RRP, APIs OR SOFTWARE PROVE DEFECTIVE, REGISTRAR ASSUMES
THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION OF REGISTRAR’S
OWN SYSTEMS AND SOFTWARE.

6.16. Indemnification. Registrar, at its own expense and within thirty (30) days
of presentation of a demand by VNDS under this paragraph, will indemnify, defend
and hold harmless VNDS and its employees, directors, officers, representatives,
agents and affiliates, against any claim, suit, action, or other proceeding
brought against VNDS or any affiliate of VNDS based on or arising from any claim
or alleged claim (i) relating to any product or service of Registrar;
(ii) relating to any agreement, including Registrar’s dispute policy, with any
Registered Name Holder of Registrar; or (iii) relating to Registrar’s domain
name registration business, including, but not limited to, Registrar’s
advertising, domain name application process, systems and other processes, fees
charged, billing practices and customer service; provided, however, that in any
such case: (a) VNDS provides Registrar with prompt notice of any such claim, and
(b) upon Registrar’s written request, VNDS will provide to Registrar all
available information and assistance reasonably necessary for Registrar to
defend such claim, provided that Registrar reimburses VNDS for its actual and
reasonable costs. Registrar will not enter into any settlement or compromise of
any such indemnifiable claim without VNDS’s prior written consent, which consent
shall not be unreasonably withheld. Registrar will pay any and all costs,
damages, and expenses, including, but not limited to, reasonable attorneys’ fees
and costs awarded against or otherwise incurred by VNDS in connection with or
arising from any such indemnifiable claim, suit, action or proceeding.

6.17. Entire Agreement; Severability. This Agreement, which includes Exhibits A,
B, C, D and E constitutes the entire agreement between the Parties concerning
the subject matter hereof and supersedes any prior agreements, representations,
statements, negotiations, understandings, proposals or undertakings, oral or
written, with respect to the subject matter expressly set forth herein. If any
provision of this Agreement shall be held to be illegal, invalid or
unenforceable, each Party agrees that such provision shall be enforced to the
maximum extent permissible so as to effect the intent of the Parties, and the
validity, legality and enforceability of the remaining provisions of this
Agreement shall not in any way be affected or impaired thereby. If necessary to
effect the intent of the Parties, the Parties shall negotiate in good faith to
amend this Agreement to replace the unenforceable language with enforceable
language that reflects such intent as closely as possible.

--------------------------------------------------------------------------------

6.18. Service Level Agreement. Appendix 10 of the Registry Agreement shall be
incorporated into this Agreement and attached hereto as Exhibit E.

IN WITNESS WHEREOF, the Parties hereto have executed this Agreement as of the
date set forth in the first paragraph hereof.

 

VeriSign, Inc.

By:

 

 

Name:

 

 

Title:

 

 

[Registrar]

By:

 

 

Name:

 

 

Title:

 

 

--------------------------------------------------------------------------------

Exhibit A

Registrar’s Registration Agreement

[To be supplied from time to time by Registrar]

--------------------------------------------------------------------------------

Exhibit B

Registrar’s Dispute Policy

[To be supplied from time to time by Registrar]

--------------------------------------------------------------------------------

Exhibit C

Confidentiality Agreement

THIS CONFIDENTIALITY AGREEMENT is entered into by and between VeriSign, Inc., a
Delaware corporation, with a place of business located at 21345 Ridgetop Circle,
Dulles, , Virginia 20166 (“VNDS”), and                                         ,
a                      corporation having its principal place of business in
                             (“Registrar”), through their authorized
representatives, and takes effect on the date executed by the final party (the
“Effective Date”). Under this Confidentiality Agreement (“Confidentiality
Agreement”), the Parties intend to disclose to one another information which
they consider to be valuable, proprietary, and confidential.

NOW, THEREFORE, the parties agree as follows:

1. Confidential Information

1.1. “Confidential Information”, as used in this Confidentiality Agreement,
shall mean all information and materials including, without limitation, computer
software, data, information, databases, protocols, reference implementation and
documentation, and functional and interface specifications, provided by the
disclosing party to the receiving party under this Confidentiality Agreement and
marked or otherwise identified as Confidential, provided that if a communication
is oral, the disclosing party will notify the receiving party in writing within
15 days of the disclosure.

2. Confidentiality Obligations

2.1. In consideration of the disclosure of Confidential Information, the Parties
agree that:

(a) The receiving party shall treat as strictly confidential, and use all
reasonable efforts to preserve the secrecy and confidentiality of, all
Confidential Information received from the disclosing party, including
implementing reasonable physical security measures and operating procedures.

(b) The receiving party shall make no disclosures whatsoever of any Confidential
Information to others, provided however, that if the receiving party is a
corporation, partnership, or similar entity, disclosure is permitted to the
receiving party’s officers, employees, contractors and agents who have a
demonstrable need to know such Confidential Information, provided the receiving
party shall advise such personnel of the confidential nature of the Confidential
Information and of the procedures required to maintain the confidentiality
thereof, and shall require them to acknowledge in writing that they have read,
understand, and agree to be individually bound by the terms of this
Confidentiality Agreement.

(c) The receiving party shall not modify or remove any Confidential legends
and/or copyright notices appearing on any Confidential Information.

2.2. The receiving party’s duties under this section (2) shall expire five
(5) years after the information is received or earlier, upon written agreement
of the Parties.

3. Restrictions On Use

3.1. The receiving party agrees that it will use any Confidential Information
received under this Confidentiality Agreement solely for the purpose of
providing domain name registration services as a registrar and for no other
purposes whatsoever.

--------------------------------------------------------------------------------

3.2. No commercial use rights or any licenses under any patent, patent
application, copyright, trademark, know-how, trade secret, or any other VNDS
proprietary rights are granted by the disclosing party to the receiving party by
this Confidentiality Agreement, or by any disclosure of any Confidential
Information to the receiving party under this Confidentiality Agreement.

3.3. The receiving party agrees not to prepare any derivative works based on the
Confidential Information.

3.4. The receiving party agrees that any Confidential Information which is in
the form of computer software, data and/or databases shall be used on a computer
system(s) that is owned or controlled by the receiving party.

4. Miscellaneous

4.1. This Confidentiality Agreement shall be governed by and construed in
accordance with the laws of the Commonwealth of Virginia and all applicable
federal laws. The Parties agree that, if a suit to enforce this Confidentiality
Agreement is brought in the U.S. Federal District Court for the Eastern District
of Virginia, they will be bound by any decision of the Court.

4.2. The obligations set forth in this Confidentiality Agreement shall be
continuing, provided, however, that this Confidentiality Agreement imposes no
obligation upon the Parties with respect to information that (a) is disclosed
with the disclosing party’s prior written approval; or (b) is or has entered the
public domain through no fault of the receiving party; or (c) is known by the
receiving party prior to the time of disclosure; or (d) is independently
developed by the receiving party without use of the Confidential Information; or
(e) is made generally available by the disclosing party without restriction on
disclosure.

4.3. This Confidentiality Agreement may be terminated by either party upon
breach by the other party of any its obligations hereunder and such breach is
not cured within three (3) calendar days after the allegedly breaching party is
notified by the disclosing party of the breach. In the event of any such
termination for breach, all Confidential Information in the possession of the
Parties shall be immediately returned to the disclosing party; the receiving
party shall provide full voluntary disclosure to the disclosing party of any and
all unauthorized disclosures and/or unauthorized uses of any Confidential
Information; and the obligations of Sections 2 and 3 hereof shall survive such
termination and remain in full force and effect. In the event that the Registrar
License and Agreement between the Parties is terminated, the Parties shall
immediately return all Confidential Information to the disclosing party and the
receiving party shall remain subject to the obligations of Sections 2 and 3.

4.4. The terms and conditions of this Confidentiality Agreement shall inure to
the benefit of the Parties and their successors and assigns. The Parties’
obligations under this Confidentiality Agreement may not be assigned or
delegated.

4.5. The Parties agree that they shall be entitled to seek all available legal
and equitable remedies for the breach of this Confidentiality Agreement.

4.6. The terms and conditions of this Confidentiality Agreement may be modified
only in a writing signed by VNDS and Registrar.

4.7. EXCEPT AS MAY OTHERWISE BE SET FORTH IN A SIGNED, WRITTEN

--------------------------------------------------------------------------------

AGREEMENT BETWEEN THE PARTIES, THE PARTIES MAKE NO REPRESENTATIONS OR
WARRANTIES, EXPRESSED OR IMPLIED, AS TO THE ACCURACY, COMPLETENESS, CONDITION,
SUITABILITY, PERFORMANCE, FITNESS FOR A PARTICULAR PURPOSE, OR MERCHANTABILITY
OF ANY CONFIDENTIAL INFORMATION, AND THE PARTIES SHALL HAVE NO LIABILITY
WHATSOEVER TO ONE ANOTHER RESULTING FROM RECEIPT OR USE OF THE CONFIDENTIAL

INFORMATION.

4.8. If any part of this Confidentiality Agreement is found invalid or
unenforceable, such part shall be deemed stricken herefrom and the Parties
agree: (a) to negotiate in good faith to amend this Confidentiality Agreement to
achieve as nearly as legally possible the purpose or effect as the stricken
part, and (b) that the remainder of this Confidentiality Agreement shall at all
times remain in full force and effect.

4.9. This Confidentiality Agreement contains the entire understanding and
agreement of the Parties relating to the subject matter hereof.

4.10. Any obligation imposed by this Confidentiality Agreement may be waived in
writing by the disclosing party. Any such waiver shall have a one-time effect
and shall not apply to any subsequent situation regardless of its similarity.

4.11. Neither Party has an obligation under this Confidentiality Agreement to
purchase, sell, or license any service or item from the other Party.

4.12. The Parties do not intend that any agency or partnership relationship be
created between them by this Confidentiality Agreement.

IN WITNESS WHEREOF, and intending to be legally bound, duly authorized
representatives of VNDS and Registrar have executed this Confidentiality
Agreement in Virginia on the dates indicated below.

 

(“Registrar”)   By:  

 

  Title:  

 

  Date:  

 

  VeriSign, Inc. (“VNDS”)   By:  

 

  Title:  

 

  Date:  

 

 

--------------------------------------------------------------------------------

Exhibit D

REGISTRATION FEES

1. Domain-Name Initial Registration Fee

Registrar agrees to pay US $6.00 per annual increment of an initial domain name
registration, or such other amount as may be established in accordance with
Section 5.1(b) above.

2. Domain-Name Renewal Fee

Registrar agrees to pay US $6.00 per annual increment of a domain name
registration renewal, or such other amount as may be established in accordance
with Section 5.1(b) above.

3. Domain Name Transfer

Registrar agrees to pay US $6.00 per domain name that is transferred to
Registrar from another ICANN-Accredited Registrar, or such other amount as may
be established in accordance with Section 5.1(b) above.

4. Restore or Update

Registrar agrees to pay US $40.00 per use of the RRP Restore or EPP Update
command for a domain name, or such other amount as may be established in
accordance with Section 5.1(b) above.

5. Sync

Registrar agrees to pay US $2.00, plus $1.00 per month of the sync, for each use
of the Supported Protocol Sync command, or such other amount as may be
established in accordance with Section 5.1(b) above.

--------------------------------------------------------------------------------

Exhibit E

Service Level Agreement

--------------------------------------------------------------------------------

.COM Agreement: Appendix 9

Approved Services

The Registry Agreement specifies a “Process for Consideration of Proposed
Registry Services.” The following services are specifically identified as having
been approved by ICANN prior to the effective date of the Registry Agreement. As
such, notwithstanding any other provisions of the Registry Agreement, VeriSign
shall be free to deploy the following services:

 

  •  

ConsoliDate, in accordance with VeriSign’s Registrar Reference Manual (v2.2)
Section 2.14 to 2.14.3;

 

  •  

Internationalized Domain Names, in accordance with the Letter from Rusty Lewis
to Paul Twomey dated 13 October 2003;

 

  •  

Restore, which allows use of the RRP Restore or EPP Update command to retrieve a
previously deleted domain name registration during the Redemption Grace Period
(approved by ICANN in accordance with VeriSign’s Registrar Reference Manual
(v2.2) Section 2.5.1.1-2.5.1.3);

 

  •  

Wait Listing Service, in accordance with the letter from John O. Jeffrey to
Russell Lewis dated 26 January 2004; and

 

  •  

Transfer Dispute Resolution, in accordance with the Registrar Transfer Dispute
Resolution Policy, dated 12 July 2004 (as may be amended or superseded by
ICANN), and VeriSign’s Supplemental Rules for Registrar Transfer Disputes.

--------------------------------------------------------------------------------

.COM Agreement Appendix 10

Service Level Agreement (SLA)

VeriSign, Inc. (“VNDS”) strives to provide a world-class level of service to its
customers. This Service Level Agreement provides metrics and remedies to measure
performance of the .com TLD registry operated by VNDS and to provide accredited
and licensed Registrars with credits for certain substandard performance by
VNDS.

A) DEFINITIONS:

1) Monthly Timeframe shall mean each single calendar month beginning and ending
at 0000 Greenwich Mean Time (GMT).

2) Planned Outage shall mean the periodic pre-announced occurrences when the SRS
will be taken out of service for maintenance or care. Planned Outages will be
scheduled only during the following window period of time each week, 0100 to
0900 GMT on Sunday (the “Planned Outage Period”). This Planned Outage Period may
be changed from time to time by VNDS, in its sole discretion, upon prior notice
to each Registrar. Planned Outages will not exceed 4 hours per calendar week
beginning at 12:00 am GMT Monday nor total more than 8 hours/per month.
Notwithstanding the foregoing, each year VNDS may incur 2 additional Planned
Outages of up to 12 hrs in duration during the Planned Outage Period for major
systems or software upgrades (“Extended Planned Outages”). These Extended
Planned Outages represent total allowed Planned Outages for the month.

3) Shared Registration System (“SRS”) Availability shall mean when the SRS is
operational. By definition, this does not include Planned Outages or Extended
Planned Outages.

4) SRS Unavailability shall mean when, as a result of a failure of systems
within VNDS’ control, the Registrar is unable to either:

a) establish a session with the SRS gateway which shall be defined as:

1) successfully complete a TCP session start,

2) successfully complete the SSL authentication handshake, and

3) successfully complete the registry registrar protocol (“RRP”) or extensible
provisioning protocol (“EPP”) session command.

b) execute a 3 second average round trip for 95% of the RRP or EPP check domain
commands and/or less than 5 second average round trip for 95% of the RRP add or
EPP create domain commands, from the SRS Gateway, through the SRS system, back
to the SRS Gateway as measured during each Monthly Timeframe.

5) Unplanned Outage Time shall mean all of the following:

a) the amount of time recorded between a trouble ticket first being opened by
VNDS in response to a Registrar’s claim of SRS Unavailability for that Registrar
through the time when the Registrar and VNDS agree the SRS Unavailability has
been resolved with a final fix or a temporary work around, and the trouble
ticket has been closed. This will be considered SRS Unavailability only for
those individual Registrars impacted by the outage.

--------------------------------------------------------------------------------

b) the amount of time recorded between a trouble ticket first being opened by
VNDS in the event of SRS Unavailability that affects all Registrars through the
time when VNDS resolves the problem with a final fix or a temporary work around,
and the trouble ticket has been closed.

c) the amount of time that Planned Outage time exceeds the limits established in
A.2 above.

d) the amount of time that Planned Outage time occurs outside the window of time
established in A.2 above.

6) Monthly Unplanned Outage Time shall be the sum of minutes of all Unplanned
Outage Time during the Monthly Timeframe. Each minute of Unplanned Outage Time
subtracts from the available Monthly Planned Outage Time up to 4 hours.

7) WHOIS Service shall mean the Whois server running on port 43 of
whois.crsnic.net and whois.verisign-grs.net.

8) Global Top Level Domain (“GTLD”) Name Server shall mean any GTLD Name Server
under SLD GTLD-SERVERS.NET (e.g. A.GTLD-SERVERS.NET).

B) RESPONSIBILITIES OF THE PARTIES

1) Registrar must report each occurrence of alleged SRS Unavailability to VNDS
customer service help desk in the manner required by VNDS (i.e., e-mail, fax,
telephone) in order for an occurrence to be treated as SRS Unavailability for
purposes of the SLA.

2) In the event that all Registrars are affected by SRS Unavailability, VNDS is
responsible for opening a blanket trouble ticket and immediately notifying all
Registrars of the trouble ticket number and details.

3) Both Registrar and VNDS agree to use reasonable commercial good faith efforts
to establish the cause of any alleged SRS Unavailability. If it is mutually
determined to be a VNDS problem, the issue will become part of the Unplanned
Outage Time.

4) VNDS will perform monitoring from at least two external locations as a means
to verify that a) sessions can effectively be established and b) all RRP or EPP
commands can be successfully completed.

--------------------------------------------------------------------------------

5) Registrar must inform VNDS any time its estimated volume of transactions
(excluding check domain commands), will exceed Registrar’s previous month’s
volume by more than 25%. In the event that Registrar fails to inform VNDS of a
forecasted increase of volume of transactions of 25% or more and the Registrar’s
volume increases 25% or more over the previous month, and should the total
volume of transactions added by VNDS for all Registrars for that month exceed
VNDS’ actual volume of the previous month’s transactions by more than 20%, then
Registrar will not be eligible for any SLA credits (as defined in section C) in
that Monthly Timeframe. The Registrar shall provide such forecast at least 30
days prior to the first day of the next month. In addition, VNDS agrees to
provide monthly transaction summary reports.

6) VNDS will notify Registrar of Planned Outages outside the Planned Outage
Period at least 7 days in advance of such Planned Outage. In addition, VNDS will
use reasonable commercial good faith efforts to maintain an accurate 30-day
advance schedule of possible upcoming Planned Outages.

7) VNDS will update the WHOIS Service once per day beginning at 1200 GMT. VNDS
will notify Registrars in advance when changes to the WHOIS Service update
schedule occur.

8) VNDS will allow external monitoring of the SRS via an acceptable means to
both parties.

9) VNDS will initiate the zone file transfer process at least twice daily at
scheduled intervals. VNDS will notify Registrar in advance when changes to the
schedule occur. VNDS will notify Registrars regarding any scheduled maintenance
and unavailability of the GTLD ROOT-SERVERs.

10) VNDS will use commercial reasonable efforts to restore the critical systems
of the SRS within 24 hours in the event of a force majeure and restore full
system functionality within 48 hours. Outages due to a force majeure will not be
considered SRS Unavailability.

11) VNDS will publish weekly system performance and availability reports. These
reports will include average round trip for the RRP or EPP Check and Add Domain
commands for all Registrars as well as a summary of SRS Availability for the
previous week

12) VNDS will provide a 99.4% SRS Availability during each Monthly Timeframe.

C) CREDITS:

1) If SRS Availability is less than 99.4% in any Monthly Timeframe, VNDS will
provide a credit to affected Registrar(s) who have complied with Sections B.1
and B.5 above as follows:

(i) In the case of SRS Unavailability as described in A.4.b, a credit will be
given for the combined % total RRP or EPP add and check commands that fall below

--------------------------------------------------------------------------------

the 95% performance threshold established in A.4.b. For each affected Registrar,
this will be calculated by multiplying the % below 95% by Registrar’s monthly
Add Domain volume x the average initial registration price charged to that
Registrar during the month. The maximum credit to each Registrar shall not
exceed 5% of the Registrar’s total monthly Add Domain volume x that average
registration price.

(ii) In the case of SRS Unavailability as described in A.4.a, and following the
Monthly Timeframe when the Unplanned Outage began, VNDS will provide a credit to
Registrar by multiplying Registrar’s monthly Add Domain volume x the average
initial registration price charged to that Registrar during the month and
multiplying that product by the percentage of time that the Monthly Unplanned
Outage Time exceeded 0.6% of the minutes in the Monthly Timeframe. The maximum
credit to each Registrar under this subparagraph shall not exceed 10% of the
Registrar’s total monthly Add Domain volume x that average registration price.

Under no circumstances shall credits be applied when the availability problems
are caused by network providers and/or the systems of individual Registrars.

D) MISCELLANEOUS:

1) As an addendum to the Registry-Registrar Agreement (RRA), no provision in
this addendum is intended to replace any term or condition in the RRA.

2) Dispute Resolution will be handled per RRA Section 6.7.

3) Any interruption of SRS service that occurs, as a direct result of RRA
Sections 2.12,, 5.4, or 6.3 or any other applicable RRA contract term, will not
be determined SRS Unavailability per this SLA.