VeriSign Inc. Contracts
Sample Business Contracts
.Com Registry Agreement - Internet Corporation for Assigned Names and Numbers (ICANN) and VeriSign Inc.
Services Forms
.COM REGISTRY AGREEMENT
-----------------------
This REGISTRY AGREEMENT ("Agreement") is by and between the Internet Corporation
for Assigned Names and Numbers ("ICANN"), a not-for-profit corporation, and
VeriSign, Inc. ("Registry Operator").
I. Definitions
For purposes of this Agreement, the following definitions shall apply:
1. "Consensus Policies" are those specifications or policies established based
on a consensus among Internet stakeholders represented in the ICANN process, as
demonstrated by (1) action of the ICANN Board of Directors establishing the
specification or policy, (2) a recommendation, adopted by at least a two-thirds
vote of the council of the ICANN Supporting Organization to which the matter is
delegated, that the specification or policy should be established, and (3) a
written report and supporting materials (which must include all substantive
submissions to the Supporting Organization relating to the proposal) that (i)
documents the extent of agreement and disagreement among impacted groups, (ii)
documents the outreach process used to seek to achieve adequate representation
of the views of groups that are likely to be impacted, and (iii) documents the
nature and intensity of reasoned support and opposition to the proposed
specification or policy.
A. In the event that Registry Operator disputes the presence of such a
consensus, it shall seek review of that issue from an Independent Review
Panel established under ICANN's bylaws. Such review must be sought within
fifteen working days of the publication of the Board's action adopting the
specification or policy. The decision of the panel shall be based on the
report and supporting materials required by the first paragraph of
Definition 1 above. In the event that Registry Operator seeks review and
the Independent Review Panel sustains the Board's determination that the
specification or policy is based on a consensus among Internet stakeholders
represented in the ICANN process, then Registry Operator must implement
such specification or policy unless it promptly seeks and obtains
injunctive relief under Section 15 below.
B. If, following a decision by the Independent Review Panel convened under
Subsection (A) above, Registry Operator still disputes the presence of such
a consensus, it may seek further review of that issue within fifteen
working days of publication of the decision in accordance with the dispute
resolution procedures set forth in Section 15 below; provided, however,
that Registry Operator must continue to implement the specification or
policy unless it has obtained injunctive relief under Section 15 below or a
final decision is rendered in accordance with the provisions of Section 15
that relieves Registry Operator of such obligation. The decision in any
such further review shall be based on the report and supporting materials
required by the first paragraph of Definition 1 above.
1
<PAGE>
C. A specification or policy established by the ICANN Board of Directors on
a temporary basis, without a prior recommendation by the council of an
ICANN Supporting Organization, shall also be considered to be a Consensus
Policy if adopted by the ICANN Board of Directors by a vote of at least
two-thirds of its members, so long as the Board reasonably determines that
immediate temporary establishment of a specification or policy on the
subject is necessary to maintain the operational stability of Registry
Services, the DNS or the Internet, and that the proposed specification or
policy is 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 refer
the matter to the appropriate Supporting Organization for its evaluation
and review with 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 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 meets the standard set
forth in the first paragraph of Definition 1 above. If the standard set
forth in the first paragraph of Definition 1 above is not met within the
temporary period set by the Board, or the council of the Supporting
Organization to which it has been referred votes to reject the
specification or temporary policy, it will no longer be a "Consensus
Policy."
D. For all purposes under this Agreement, the policies identified in
Appendix V shall be treated in the same manner and have the same effect as
"Consensus Policies."
E. Registry Operator shall be afforded a reasonable period of time, not to
exceed four months (unless the nature of the specification or policy
established under the first paragraph of Definition 1 above reasonably
requires, as agreed to by ICANN and Registry Operator, a longer period)
after receiving notice of the establishment of a specification or policy
under the first paragraph of Definition 1 above in which to comply with
that specification or policy, taking into account any urgency involved.
F. In the event that, at the time the ICANN Board establishes a
specification or policy under the first paragraph of Definition 1 above
during the term of this Agreement, ICANN does not have in place an
Independent Review Panel established under ICANN's bylaws, the fifteen
working day period allowed under subsection (A) above to seek review shall
be extended until fifteen working days after ICANN does have such an
Independent Review Panel in place and Registry Operator shall not be
obligated to comply with the specifications or policy in the interim.
2
<PAGE>
2. "DNS" refers to the Internet domain name system.
3. "Effective Date" is the date specified as such in Section 3 of the Agreement
for Restructured Relationship among ICANN, VeriSign, and Network Solutions, Inc.
4. "Expiration Date" is November 10, 2007, unless further extended pursuant to
this Agreement.
5. "Personal Data" refers to data about any identified or identifiable natural
person.
6. "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 Registry Operator 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).
7. "Registry Data" means all Registry Database data maintained in electronic
form in the Registry Database, and shall include Zone File Data, all data used
to provide Registry Services submitted by registrars in electronic form, and all
other data used to provide Registry Services concerning particular domain name
registrations or nameservers maintained in electronic form in the Registry
Database.
8. "Registry Database" means a database comprised of data about one or more DNS
domain names within the domain of the Registry TLD that is used to generate
either DNS resource records that are published authoritatively or responses to
domain name availability lookup requests or Whois queries, for some or all of
those names.
9. "Registry Services" means services provided as an integral part of the
Registry TLD, including all subdomains. These services include: receipt of data
concerning registrations of domain names and nameservers from registrars;
provision to registrars of status information relating to the Registry TLD zone
servers, dissemination of TLD zone files, operation of the Registry zone
servers, dissemination of contact and other information concerning domain name
and nameserver registrations in the Registry TLD, and such other services
required by ICANN through the establishment of Consensus Policies as set forth
in Definition 1 of this Agreement. Registry Services shall not include the
provision of name service for a domain used by a single entity under a
Registered Name registered through an ICANN-accredited registrar.
10. "Registry TLD" refers to the .com TLD.
11. "Term of this Agreement" begins on the Effective Date and runs through the
earlier of (a) the Expiration Date, or (b) termination of this Agreement.
12. "TLD" refers to a top-level domain in the DNS.
3
<PAGE>
13. "Zone File Data" means all data contained in DNS zone files for the Registry
TLD, or for any subdomain for which Registry Services are provided and that
contains Registered Names, as provided to TLD nameservers on the Internet.
II. Agreements
Registry Operator and ICANN agree as follows:
1. Designation of Registry Operator. ICANN hereby continues to recognize
--------------------------------
Registry Operator as the sole operator for the Registry TLD during the Term of
this Agreement.
2. Recognition in Authoritative Root Server System. 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 (a) 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 (b) any changes to TLD zone server
designation submitted to ICANN by Registry Operator will be implemented by ICANN
within five business days of submission. In the event that this Agreement is
terminated (a) under Section 16 or Section 18(B) of this Agreement by Registry
Operator or (b) under Section 26 of this Agreement due to the withdrawal of
recognition of ICANN by the US Department of Commerce("DOC"), ICANN's
obligations concerning TLD zone server designations for the Registry TLD in the
authoritative root server system shall be as stated in a separate agreement
between ICANN and DOC.
3. General Obligations of Registry Operator.
----------------------------------------
A. During the Term of this Agreement:
(i) Registry Operator agrees that it will operate the registry for
the Registry TLD in accordance with this Agreement;
(ii) Registry Operator shall comply, in its operation of the registry,
with all Consensus Policies insofar as they:
(a) are adopted by ICANN in compliance with Section 4 below,
(b) relate to one or more of the following: (1) issues for
which uniform or coordinated resolution is reasonably
necessary to facilitate interoperability, technical
reliability and/or stable operation of the Internet or DNS,
(2) registry policies reasonably necessary to implement
Consensus Policies relating to registrars, or (3) resolution
of disputes regarding the registration of domain names (as
opposed to the use of such domain names), and
(c) do not unreasonably restrain competition.
4
<PAGE>
B. Registry Operator agrees that upon the earlier of (i) the Expiration
Date or (ii) termination of this Agreement by ICANN pursuant to Section 16
below, it will cease to be the Registry Operator for the Registry TLD,
unless prior to the end of the Term of this Agreement Registry Operator is
chosen as the successor registry in accordance with the provisions of this
Agreement.
C. To the extent that Consensus Policies are adopted in conformance with
Section 4 of this Agreement, the measures permissible under Section
3(A)(ii)(b) above shall include, without limitation:
(i) principles for allocation of Registered Names (e.g., first-come,
first-served, timely renewal, holding period after expiration);
(ii) prohibitions on warehousing of or speculation in domain names by
registries or registrars;
(iii) reservation of Registered Names 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., "example.com" and single-letter/digit names);
(iv) the allocation among continuing registrars of the Registered
Names sponsored in the registry by a registrar losing accreditation;
and
(v) dispute resolution policies that take into account the use of a
domain name.
Nothing in this Section 3 shall limit or otherwise affect Registry
Operator's obligations as set forth elsewhere in this Agreement.
4. General Obligations of ICANN. With respect to all matters that impact the
----------------------------
rights, obligations, or role of Registry Operator, ICANN shall during the Term
of this Agreement
A. exercise its responsibilities in an open and transparent manner;
B. not unreasonably restrain competition and, to the extent feasible,
promote and encourage robust competition;
C. not apply standards, policies, procedures or practices arbitrarily,
unjustifiably, or inequitably and not single out Registry Operator for
disparate treatment unless justified by substantial and reasonable cause;
and
D. ensure, through its reconsideration and independent review policies,
adequate appeal procedures for Registry Operator, to the extent it is
adversely affected by ICANN standards, policies, procedures or practices.
5
<PAGE>
5. Use of ICANN Name. ICANN hereby grants to Registry Operator a non-exclusive,
-----------------
worldwide, royalty-free license during the Term of this Agreement (a) to state
that it is recognized by ICANN as the Registry Operator for the Registry TLD,
(b) to use a logo specified by ICANN to signify that Registry Operator is an
ICANN-designated registry, and (c) to link to pages and documents within the
ICANN web site. No other use of ICANN's name is licensed hereby. This license
may not be assigned or sublicensed by Registry Operator.
6. Protection from Burdens of Compliance With ICANN Policies. ICANN shall
---------------------------------------------------------
indemnify, defend, and hold harmless Registry Operator (including its directors,
officers employees, and agents) from and against any and all claims, damages,
liabilities, costs, and expenses, including reasonable legal fees and expenses,
arising solely from Registry Operator's compliance as required by this Agreement
with an ICANN specification or policy (including a Consensus Policy) established
after the Effective Date; except that Registry Operator shall not be indemnified
or held harmless hereunder to the extent that the claims, damages or liabilities
arise from the particular manner in which Registry Operator has chosen to comply
with the specification or policy, where it was possible for Registry Operator to
comply in a manner by which the claims, damages, or liabilities would not arise.
As an alternative to providing the indemnity stated in this Section 6, ICANN
may, at the time it establishes a specification or policy after the Effective
Date giving rise to an indemnity obligation under this Section 6, state ICANN's
election that the Registry Operator shall bear the cost of insuring the claims,
damages, liabilities, costs, and expenses that would otherwise be indemnified by
ICANN under this Section 6, in which case the reasonable cost to Registry
Operator of such insurance shall be treated under Subsection 22(A) as a cost of
providing Registry Services arising from the newly established ICANN
specification or policy.
7. Registry-Level Financial Support of ICANN. During the Term of this Agreement,
-----------------------------------------
Registry Operator shall pay to ICANN the following fees:
A. Fixed Registry-Level Fee. Registry Operator shall pay ICANN a quarterly
------------------------
Fixed Registry-Level Fee in an amount established by the ICANN Board of
Directors, in conformity with the ICANN bylaws and articles of
incorporation, not to exceed one quarter of the annual Fixed Registry-Level
Fee Cap described in Subsection 7(D).
B. Variable Registry-Level Fee. Registry Operator shall pay ICANN a
---------------------------
quarterly Variable Registry-Level Fee in an amount calculated according to
a formula and method established from time to time by the ICANN Board of
Directors, in conformity with the ICANN by laws and articles of
incorporation. The formula and method shall allocate the total variable fee
among all TLDs sponsored or operated under a sponsorship or registry
agreement with ICANN (whether the fee is collected at the registry or
registrar level) based on the relative size of the registries for those
TLDs. It shall be permissible for the formula and method so established (a)
to measure the size of a TLD's registry by the number of names under
administration within the TLD by the registry's operator, (b) to deem the
6
<PAGE>
number of domain names under administration within the Registry TLD to be
the number of Registered Names, and (c) to provide for a deduction in
computing a sponsor's or operator's Variable Registry-Level Fee of some or
all of that sponsor's or operator's Fixed Registry-Level Fee. It shall
also be permissible for the formula and method to consider accreditation
fees collected from registrars as a credit applied to the Variable
Registry-Level Fee for the TLD to which the fees pertain. Groups of
registries for two or more TLDs may, with the agreement of their sponsors
or operators and ICANN, agree to allocate the variable fee collected from
them in a manner not based on the relative size of the registries within
the group, provided that the combined variable fees collected for all TLDs
within the group is based on the combined size of the registries in the
group.
C. Payments Must Be Timely. Registry Operator shall pay the quarterly Fixed
-----------------------
and Variable Registry-Level Fees within thirty days after the date of
ICANN's invoice for those fees. These payments shall be made in a timely
manner throughout the Term of this Agreement and notwithstanding the
pendency of any dispute between Registry Operator and ICANN. Registry
Operator shall pay interest on payments not timely made at the rate of 1%
per month or, if less, the maximum rate permitted by California law.
D. Fee Caps. The Fixed Registry-Level Fee Cap shall be US$ 100,000 per year
--------
until and including June 30, 2002; shall automatically increase by 15% on
July 1 of each year beginning in 2002; and may be increased by a greater
amount through the establishment of Consensus Policies as set forth in
Definition 1 and Section 3 of this Agreement. The sum of the Fixed
Registry-Level Fees and the Variable Registry-Level Fees due to be paid in
any year ending on any June 30 during or within one year after the Term of
this Agreement by all TLD sponsors and registry operators having
sponsorship or registry agreements with ICANN shall not exceed the Total
Registry-Level Fee Cap described in the following sentence. The Total
Registry-Level Fee Cap shall be US$ 5,500,000 for the fiscal year ending
June 30, 2002; shall increase by 15% each fiscal year thereafter; and may
be increased by a greater amount through the establishment of Consensus
Policies as set forth in Definition 1 and Section 3 of this Agreement.
E. Adjustments to Price. The maximum pricing for initial and renewal
--------------------
registrations set forth in Appendix G shall be adjusted at the beginning of
each calendar quarter by adding, to the amount specified in that Appendix
(after adjustment according to Section 22(a)) as the applicable annual
charge for initial or renewal registration of a domain name, an amount
calculated according to the following three sentences. For calendar
quarters in which the variable fee is collected at the registrar level, the
amount shall be US$0.00. For the first two calendar quarters during the
Term of this Agreement in which the variable fee is collected at the
registry level, the amount shall be four times the per-name variable
accreditation fee charged to registrars for the quarter beginning six
months earlier. For subsequent calendar quarters, the amount shall be four
times the quarterly Variable Registry-Level Fee reflected in the invoice to
Registry
7
<PAGE>
Operator for such a fee for the quarter beginning six months earlier
divided by the number of Registered Names that the invoice shows was used
to calculate that quarterly Variable Registry-Level Fee. The adjustments
permitted by this Subsection 7(E) shall only apply for periods of time as
to which the Registry Operator does not have in effect a provision in its
Registry-Registrar Agreement permitting it to require ICANN-Accredited
Registrars to pay to Registry Operator a portion of Registry Operator's
payments of variable registry-level fees to ICANN.
8. Reports Provided to ICANN. Within twenty days after the end of each month
-------------------------
during the Term of this Agreement, Registry Operator shall provide ICANN a
written report, giving information specified by ICANN, on operation of the
registry during the month. The initial specification of information is set forth
in Appendix T. Changes to that specification 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 Definition 1 of this Agreement.
9. Data Escrow. 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. 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 established by ICANN from time to
time. The initial schedule, content, format, and procedure shall be as set forth
in Appendix R. 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 Definition 1 of this Agreement. The escrow
shall be held under an agreement, substantially in the form of Appendix S, among
ICANN, Registry Operator, and the escrow agent.
10. Registry Operator's Handling of Personal Data. Registry Operator shall
---------------------------------------------
notify registrars sponsoring registrations in the registry for the Registry TLD
of the purposes for which Personal Data submitted to Registry Operator by
registrars is collected, the 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.
11. Publication by Registry Operator of Registry Data.
-------------------------------------------------
A. At its expense, Registry Operator shall provide free public query-based
access to up-to-date data concerning domain name and nameserver
registrations
8
<PAGE>
maintained by Registry Operator in connection with the Registry TLD. The
data elements reported, format of responses to queries, data update
frequency, query types supported, and protocols through which access is
provided shall be as established by ICANN. The initial specification of the
data elements reported, format of responses to queries, minimum data update
frequency, query types supported, and protocols through which access is
provided are set forth in Appendix O. Registry Operator may request
supplementation of the specification to include additional data elements
reported or query types supported, in which event ICANN shall act to
supplement the specification in a reasonable manner within a reasonable
time. Other changes to the specification 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 Definition 1 of this Agreement.
B. To ensure operational stability of the registry, Registry Operator may
temporarily limit access under Subsection 11(A) in which case Registry
Operator shall immediately notify ICANN of the nature of and reason for the
limitation. Registry Operator shall not continue the limitation longer than
a period established by ICANN if ICANN objects in writing, which objection
shall not be unreasonably made. The period shall initially be five business
days; changes to that period 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 Definition 1 of this Agreement. Such temporary limitations
shall be applied in a non-arbitrary manner and shall apply fairly to all
ICANN-accredited registrars.
C. In providing query-based public access to registration data as required
by this Subsection 11(A), Registry Operator shall not impose terms and
conditions on use of the data provided except as permitted by policy
established by ICANN. Unless and until ICANN establishes a different
policy, Registry Operator shall permit use of data it provides in response
to queries for any lawful purposes except to: (a) allow, enable, or
otherwise support the transmission by e-mail, telephone, or facsimile of
mass unsolicited, commercial advertising or solicitations to entities other
than the data recipient's own existing customers; or (b) enable high
volume, automated, electronic processes that send queries or data to the
systems of Registry Operator or any ICANN-accredited registrar, except as
reasonably necessary to register domain names or modify existing
registrations. Changes to that policy 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 Definition 1 of this Agreement.
D. To comply with applicable statutes and regulations and for other
reasons, ICANN may from time to time establish Consensus Policies as set
forth in Definition 1 of this Agreement establishing limits on the data
concerning registrations that Registry Operator may make available to the
public through a
9
<PAGE>
public-access service described in this Subsection 11(A) and on the manner
in which Registry Operator may make them available.
E. At its expense, 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 in the following two
ways:
(i) 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 content and format of this data,
and the procedures for providing access, shall be as established by
ICANN. The initial content, format, and procedures are set forth in
Appendix P. Changes to that content and format and those procedures
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 Definition 1
of this Agreement.
(ii) on a continuous basis, to ICANN in the manner which ICANN may
from time to time reasonably specify, only for purposes of verifying
and ensuring the operational stability of Registry Services, the DNS,
and the Internet. The content and format of this data, and the
procedures for providing access, shall be as established by ICANN. The
initial content, format, and procedures are set forth in Appendix Q.
Changes to that content and format and those procedures 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 Definition 1 of
this Agreement.
12. Rights in Data. Except as permitted by the Registry-Registrar Agreement,
--------------
Registry Operator shall not be entitled to claim any intellectual property
rights in data in the registry supplied by or through registrars. In the event
that Registry Data is released from escrow under Section 9, any rights 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.
13. Limitation of Liability. ICANN's aggregate monetary liability for violations
-----------------------
of this Agreement shall not exceed the amount of Fixed or Variable Registry-
Level Fees paid by Registry Operator to ICANN within the preceding twelve-month
period under Section 7 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 OTHERWISE PROVIDED IN
10
<PAGE>
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.
14. Specific Performance. During the Term of this Agreement, either party may
--------------------
seek specific performance of any provision of this Agreement as provided by
Section 15, provided the party seeking such performance is not in material
breach of its obligations.
15. Resolution of Disputes Under This Agreement. Disputes arising under or in
-------------------------------------------
connection with this Agreement, including requests for specific performance,
shall be resolved in a court of competent jurisdiction or, at the election of
both parties (except for any dispute over whether a policy adopted by the Board
is a Consensus Policy, in which case at the election of either party), by an
arbitration conducted as provided in this Section pursuant to the International
Arbitration Rules of the American Arbitration Association ("AAA"). The
arbitration shall be conducted in English and shall occur in Los Angeles County,
California, USA. 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 AAA. The parties shall bear the
costs of the arbitration in equal shares, subject to the right of the
arbitrators to reallocate the costs in their award as provided in the AAA rules.
The parties shall bear their own attorneys' fees in connection with the
arbitration, and the arbitrators may not reallocate the attorneys' fees in
conjunction with their award. The arbitrators shall render their decision within
ninety days of the initiation of arbitration. In all litigation involving ICANN
concerning this Agreement (whether in a case where arbitration has not been
elected or to enforce an arbitration award), jurisdiction and exclusive venue
for such litigation shall be in a court located in Los Angeles, 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 temporary or
preliminary injunctive relief from the arbitration panel or a court located in
Los Angeles, California, USA, which shall not be a waiver of this arbitration
agreement.
16. Termination.
-----------
A. In the event an arbitration award or court judgment is rendered
specifically enforcing any provision of this Agreement or declaring a
party's rights or obligations under this Agreement, either party may, by
giving written notice, demand that the other party comply with the award or
judgment. In the event that the other party fails to comply with the order
or judgment within ninety days after the giving of notice (unless relieved
of the obligation to comply by a court or arbitration order before the end
of that ninety-day period), the first party may terminate this Agreement
immediately by giving the other party written notice of termination.
11
<PAGE>
B. In the event of termination by DOC of its Cooperative Agreement with
Registry Operator pursuant to Section 1.B.8 of Amendment __ to that
Agreement, ICANN shall, after receiving express notification of that fact
from DOC and a request from DOC to terminate Registry Operator as the
operator of the Registry TLD, terminate Registry Operator's rights under
this Agreement, and shall cooperate with DOC to facilitate the transfer of
the operation of the Registry Database to a successor registry.
C. This Agreement may also be terminated in the by ICANN on written notice
given at least forty days after the final and nonappealable occurrence of
either of the following events:
(i) Registry Operator:
(a) is convicted by a court of competent jurisdiction of a
felony or other serious offense related to financial
activities, or is the subject of a determination by a court
of competent jurisdiction that ICANN reasonably deems as the
substantive equivalent of those offenses; or
(b) is disciplined by the government of its domicile for
conduct involving dishonesty or misuse of funds of others.
(ii) Any officer or director of Registry Operator is convicted of a
felony or of a misdemeanor related to financial activities, or is
judged by a court to have committed fraud or breach of fiduciary duty,
or is the subject of a judicial determination that ICANN deems as the
substantive equivalent of any of these, and such officer or director
is not immediately removed in such circumstances.
D. If Registry Operator becomes bankrupt or insolvent, ICANN may
immediately terminate this Agreement upon notice to Registry Operator.
E. If Registry Operator fails to pay to ICANN the final amount of sanctions
determined to be appropriate under the sanctions program described in
Appendix Y within thirty days after the amount of sanctions is deemed
final, ICANN may, by giving written notice, demand that Registry Operator
pay that amount. In the event that Registry Operator fails to pay within
ninety days after the giving of notice (unless relieved of the obligation
to comply by a court or arbitration order before the end of that ninety-day
period), ICANN may terminate this Agreement immediately by giving Registry
Operator written notice of termination.
17. Assignment. Neither party may assign this Agreement without the prior
----------
written approval of the other party, such approval not to be unreasonably
withheld. Notwithstanding the foregoing sentence, a party may assign this
Agreement by giving
12
<PAGE>
written notice to the other party in the following circumstances, provided the
assignee agrees in writing with the other party to assume the assigning party's
obligations under this Agreement: (a) Registry Operator may assign this
Agreement as part of the transfer of its registry business and (b) ICANN may, in
conjunction with a reorganization or re-incorporation of ICANN and with the
written approval of the DOC, assign this Agreement to another non-profit
corporation organized for the same or substantially the same purposes as ICANN.
18. Relationship to Cooperative Agreement Between VeriSign/NSI and U.S.
-------------------------------------------------------------------
Government.
----------
A. Registry Operator's obligations under this Agreement are conditioned on the
concurrence by DOC through an amendment to Cooperative Agreement NCR-9218742.
B. If within a reasonable period of time ICANN has not made substantial progress
towards having entered into agreements with competing registries and Registry
Operator is adversely affected from a competitive perspective, Registry Operator
may terminate this Agreement with the approval of the DOC.
C. In the case of conflict while they are both in effect, and to the extent that
they address the same subject in an inconsistent manner, the term(s) of
Cooperative Agreement NCR-9218742 shall take precedence over this Agreement.
19. Registry Operator Agreements with Registrars. Registry Operator shall make
--------------------------------------------
access to the Shared Registration System available to all ICANN-accredited
registrars subject to the terms of the Registry-Registrar Agreement (attached as
Appendix F). Such agreement may be revised by Registry Operator, provided
however, that any such revisions must be approved in advance by ICANN.
20. Performance and Functional Specifications for Registry Services. Unless and
---------------------------------------------------------------
until ICANN adopts different standards as a Consensus Policy pursuant to
Definition 1 and Section 3, Registry Operator shall provide Registry Services to
ICANN-accredited registrars in a manner that meets the performance and
functional specifications set forth in Appendices C and D, and the Registry
Service Level Agreement attached as Appendix E. In the event ICANN adopts
different performance and functional standards for the registry as a Consensus
Policy in compliance with Definition 1 and Section 3, Registry Operator shall
comply with those standards to the extent practicable, provided that
compensation pursuant to the provisions of Section 22(A) below has been resolved
prior to implementation. In no event shall Registry Operator be required to
implement any different functional standards before November 10, 2002.
21. Bulk Access to Zone Files. Registry Operator shall provide bulk access to
-------------------------
the zone files for the Registry TLD as follows:
A. to third parties on the terms set forth in the TLD zone file access
agreement established by ICANN. The terms of the agreement are set forth as
Appendix N
13
<PAGE>
to this Agreement. Changes to the terms of the TLD zone file access
agreement 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 Definition
1 of this Agreement.
B. to ICANN on a continuous basis in the manner which ICANN may from time
to time specify.
22. Price for Registry Services.
---------------------------
A. The price(s) to ICANN-accredited registrars for entering initial and
renewal domain name registrations into the Registry Database and for
transferring a domain name registration from one ICANN-accredited registrar
to another will be as set forth in Section 5 of the Registry-Registrar
Agreement (attached as Appendix F). These prices shall be increased through
an amendment to this Agreement as approved by ICANN and Registry Operator,
such approval not to be unreasonably withheld, to reflect reasonably
demonstrated increases in the net costs of providing Registry Services
arising from (i) new or revised ICANN specifications or policies adopted
after the Effective Date, or (ii) legislation specifically applicable to
the provision of Registry Services adopted after the Effective Date, to
ensure that Registry Operator recovers such costs and a reasonable profit
thereon; provided that such increases exceed any reductions in costs
arising from (i) or (ii) above.
B. Registry Operator may, at its option and with thirty days written notice
to ICANN and to all ICANN-accredited registrars, revise the prices charged
to registrars under the Registry-Registrar Agreement, provided that (i) the
same price shall be charged for services charged to all ICANN-accredited
registrars (provided that volume adjustments may be made if the same
opportunities to qualify for those adjustments is available to all ICANN-
accredited registrars) and (ii) the prices shall not exceed those set forth
in Appendix G.
23. Fair Treatment of ICANN-Accredited Registrars.
---------------------------------------------
A. Registry Operator shall provide all ICANN-accredited registrars that are
signatories to the Registry-Registrar Agreement, and that are in compliance
with the terms of such agreements, equivalent access to Registry Operator's
Registry Services, including to its shared registration system.
B. Registry Operator shall certify to ICANN every six months, using the
objective criteria set forth in Appendix H, that Registry Operator is
providing all such ICANN-accredited registrars with equivalent access to
its Registry Services, including to its shared registration system.
C. Registry Operator shall not act as a registrar with respect to the
Registry TLD.
14
<PAGE>
This shall not preclude Registry Operator from registering names within the
domain of the Registry TLD in compliance with Section 24. This also shall
not preclude an affiliate (including wholly-owned subsidiaries) of Registry
Operator from acting as a registrar with respect to the Registry TLD,
provided that Registry Operator complies with the provisions of Subsection
23(E).
D. Registry Operator shall comply with its Code of Conduct attached as
Appendix I. Any changes to that Code of Conduct will require ICANN's
approval.
E. Registry Operator will ensure, in a form and through ways described in
Appendix H, that the revenues and assets of Registry Operator are not
utilized to advantage registrars that are affiliated with Registry Operator
to the detriment of other ICANN-accredited registrars. For purposes of this
Subsection 23(E), funds distributed to debt or equity participants in
Registry Operator shall no longer be deemed revenues and assets of Registry
Operator once they are distributed.
F. With respect to its obligations under Subsections 24(A) through 24(E)
and Appendices H and I, Registry Operator agrees to participate in and
comply with the sanctions program described in Appendix Y, provided that
all other registry operators having registry agreements with ICANN for the
operation of unsponsored top-level domains (i.e. top-level domains, other
than country-code and infrastructure domains, not having a sponsoring
organization) are obligated to participate in and comply with a sanctions
program with substantially the same provisions as Appendix Y. Registry
Operator agrees that the Sanctions Program described in Appendix Y shall be
a non-exclusive and additional option ICANN to promote compliance with
Subsections 24(A) through 24(E) and Appendices H and I, and that (except as
stated in Appendix Y) the availability of that option does not limit or
affect in any way ICANN's ability to employ any other compliance measures
or remedies available under this Agreement. In the event that the gTLD
Constituency of the Domain Name Supporting Organization proposes a
substitute Appendix Y at any time prior to May 1, 2002, and ICANN
determines (following an appropriate process of public notice and comment)
that substitution by that Appendix Y would serve the interests of the
Internet community, the substitution shall be made.
24. Registrations Not Sponsored by Registrars Under Registry-Registrar
------------------------------------------------------------------
Agreements. Registry Operator shall register domain names within the domain of
----------
the Registry TLD, other than on a request submitted by a registrar pursuant to
that registrar's Registry-Registrar Agreement, only as follows:
A. Registry Operator may register the domain names listed on Appendix X
(Part A) for its own use in operating the registry and providing Registry
Services under this Agreement, provided the total number of domain names
listed on Appendix X at any time does not exceed 5000. At the conclusion of
its designation by ICANN as the operator for the Registry TLD, Registry
Operator shall transfer all such domain name registrations to the entity or
person specified by ICANN. Appendix
15
<PAGE>
X may be revised upon written notice by Registry Operator to ICANN and
written consent by ICANN, which shall not be unreasonably withheld.
B. Registry Operator may register the domain names listed on Appendix X
(Part B) for its own use, provided the total number of domain names
listed on Appendix X at any time does not exceed 5000. Registry
Operator may retain registration of those names at the conclusion of
its designation by ICANN as the operator for the Registry TLD, provided
registration fees are paid and all other requirements for registration
by third parties are met. Appendix X may be revised upon written notice
by Registry Operator to ICANN and written consent by ICANN, which shall
not be unreasonably withheld.
C. As instructed from time to time by ICANN, Registry Operator shall
maintain the registration of up to 5000 domain names within the domain
of the Registry TLD for use by ICANN and other organizations
responsible for coordination of the Internet's infrastructure.
D. This Section 24 shall not preclude Registry Operator from
registering domain names within the domain of the Registry TLD through
an ICANN-accredited registrar pursuant to that registrar's
Registry-Registrar Agreement.
25. Procedure for Subsequent Agreement.
----------------------------------
A. Registry Operator may, no earlier than twenty-four and no later than
eighteen months prior to the Expiration Date, submit a written proposal
to ICANN for the extension of this Agreement for an additional term of
four years (the "Renewal Proposal"). The Renewal Proposal shall contain
a detailed report of the Registry Operator's operation of the Registry
TLD and include a description of any additional Registry Services,
proposed improvements to Registry Services, or changes in price or
other terms of service.
B. ICANN shall consider the Renewal Proposal for a period of no more
than six months before deciding whether to call for competing proposals
from potential successor registry operators for the Registry TLD.
During this six month period, ICANN may request Registry Operator to
provide, and Registry Operator shall provide, additional information
concerning the Renewal Proposal that ICANN determines to be reasonably
necessary to make its decision. Following consideration of the Renewal
Proposal, Registry Operator shall be awarded a four-year renewal term
unless ICANN demonstrates that: (a) Registry Operator is in material
breach of this Registry Agreement, (b) Registry Operator has not
provided and will not provide a substantial service to the Internet
community in its performance under this Registry Agreement, (c)
Registry Operator is not qualified to operate the Registry TLD during
the renewal term, or (d) the maximum price for initial and renewal
registrations proposed in the Renewal Proposal exceeds the price
permitted under Section 22 of this Registry Agreement. The terms of the
registry agreement for the renewal term shall be in substantial
conformity with
16
<PAGE>
the terms of registry agreements between ICANN and operators of other
open TLDs then in effect, provided that this Section 25 shall be
included in any renewed Registry Agreement unless Registry Operator and
ICANN mutually agree to alternative language.
C. In the event that ICANN fails to award a renewal registry agreement
to Registry Operator within the six month period described above,
Registry Operator shall have the right to challenge the reasonableness
of that failure under the provisions of Section 15.
D. In the event ICANN does not award Registry Operator a renewal
registry agreement according to Subsection 25(B), ICANN shall call for
competitive proposals and Registry Operator shall be eligible, to the
same extent as similarly situated entities, to submit a proposal in
response to such a call and to be considered for such award.
26. Withdrawal of Recognition of ICANN by the Department of Commerce. In the
----------------------------------------------------------------
event that, prior to the expiration or termination of this Agreement under
Section 16 or 18(B), the DOC withdraws its recognition of ICANN as NewCo under
the Statement of Policy pursuant to the procedures set forth in Section 5 of
Amendment 1 (dated November 10, 1999) to the Memorandum of Understanding between
ICANN and the DOC, this Agreement shall terminate.
27. Option to Substitute Generic Agreement. At Registry Operator's option, it
--------------------------------------
may substitute in its entirety any generic ICANN-Registry Operator Agreement
that may be adopted by ICANN for this Agreement.
28. Additional Covenants of Registry Operator. Throughout the Term of the
-----------------------------------------
Agreement, Registry Operator shall abide by the covenants contained in Appendix
W.
29. Notices, Designations, and Specifications. All notices to be given under
-----------------------------------------
this Agreement shall be given in writing at the address of the appropriate party
as set forth below, unless that party has given a notice of change of address in
writing. Any notice required by this Agreement shall be deemed to have been
properly given when delivered in person, when sent by electronic facsimile, or
when scheduled for delivery by internationally recognized courier service.
Designations and specifications by ICANN under this Agreement shall be effective
when written notice of them is deemed given to Registry Operator.
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: Chief Executive Officer
17
<PAGE>
If to Registry Operator, addressed to:
General Counsel
VeriSign, Inc.
1350 Charleston Road
Mountain View, California 94043
Telephone: 1/650/961/7500
Facsimile: 1/650/961/8853; and
General Manager
VeriSign Registry
21345 Ridgetop Circle
Dulles, Virginia 20166
Telephone: 1/703/948/3200
Facsimile: 1/703/421/2129; and
Deputy General Counsel
VeriSign, Inc.
505 Huntmar Park Drive
Herndon, Virginia 20170
Telephone: 1/703/742/0400
Facsimile: 1/703/742-7916
30. Subcontracting. Registry Operator shall not subcontract portions of the
--------------
technical operations of the Registry TLD accounting for more than 80% of the
value of all Registry TLD operations without ICANN's written consent. When
ICANN's consent to subcontracting is requested, ICANN shall respond within
fifteen business days, and the consent shall not be unreasonably withheld. In
any subcontracting of the technical operations of the Registry TLD, the
subcontract shall state that the subcontractor shall not acquire any right in
the Registry TLD by virtue of its performance under the subcontract.
31. Force Majeure. Neither party shall be liable to the other for any loss or
-------------
damage resulting from any cause beyond its reasonable control (a "Force Majeure
Event") including, but not limited to, insurrection or civil disorder, war or
military operations, national or local emergency, acts or omissions of
government or other competent authority, compliance with any statutory
obligation or executive order, industrial disputes of any kind (whether or not
involving either party's employees), fire, lightening, explosion, flood
subsidence, weather of exceptional severity, and acts or omissions of persons
for whom neither party is responsible. Upon occurrence of a Force Majeure Event
and to the extent such occurrence interferes with either party's performance of
this Agreement, such party shall be excused from performance of its obligations
(other than payment obligations) during the first six months of such
interference, provided that such party uses best efforts to avoid or remove such
causes of nonperformance as soon as possible.
18
<PAGE>
32. 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.
33. Dates and Times. All dates and times relevant to this Agreement or its
---------------
performance shall be computed based on the date and time observed in Los
Angeles, California, USA.
34. Language. All notices, designations, and specifications made under this
--------
Agreement shall be in the English language.
35. 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 Registry TLD and supersedes all prior agreements,
understandings, negotiations and discussions, whether oral or written, between
the parties on that subject. In the event of any conflict between the provisions
in the body of this Agreement (Section 1 to Subsection 5.20) and any provision
in its appendices, the provisions in the body shall prevail.
36. 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 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.
37. 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.
IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed
in duplicate by their duly authorized representatives.
INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS
By:_____________________________
M. Stuart Lynn
President and CEO
Date:
19
<PAGE>
By:_____________________________
Stratton Sclavos
President and CEO
Date:
20
<PAGE>
Appendix A
----------
Internet Assigned Numbers Authority
Format and Technical Requirements for Requests to Change TLD Nameservers in
the Root Zone
(This document applies only to TLDs as to which a written agreement is in effect
between ICANN and the TLD delegee, sponsor, or operator.)
1. Requests for changes in TLD nameserver delegations to be reflected in the
root zone are to be submitted by e-mail to [email protected].
2. Requests should be submitted by filling out the template available at <URL>.
3. Nameserver change requests are subject to verification of authenticity and
authorization. Both the listed technical contact and the listed administrative
contact should be available to verify that the request is authentic and they
authorize the requested change. Except where a written agreement between ICANN
and the TLD delegee, sponsor, or operator expressly states to the contrary, the
IANA shall be entitled to rely on authorization of either the administrative or
technical contact as constituting a request for nameserver change by the TLD
delegee, sponsor, or operator.
4. Requests for changes to nameservice for ccTLDs (i.e. TLDs having two-letter
labels) must result in delegation to at least two nameservers, preferably on
different networks. Requests for changes to nameservice for other TLDs must
result in delegation to nameservers on at least five different networks.
5. Delegations of a TLD to more than thirteen nameservers are not supported.
6. Prior to submitting the request, nameservice should be set up at all the
nameservers to which delegation is to be made. Lame delegations will not
ordinarily be made.
7. The IANA must have zone file access. Except where other arrangements are made
(such as for TLDs with large zones), this means that zone file transfers must be
enabled at all nameservers for transfers to at least 128.9.0.0/16 and
192.0.32.0/20.
(6 April 2001)
21
<PAGE>
Appendix B
----------
Internet Assigned Numbers Authority
Format, Content, and Technical Requirements for Requests to Change TLD
Contact Information
(This document applies only to TLDs as to which a written agreement is in effect
between ICANN and the TLD delegee, sponsor, or operator.)
1. Requests for changes in TLD contact data are to be submitted by e-mail to
[email protected]>.
2. Requests should be submitted by filling out the template available at <URL>.
3. Requests for changes to TLD contact data must include all applicable elements
of data requested in items 3-5 of the template. All information submitted must
be accurate.
4. Contact change requests are subject to verification of authenticity and
authorization. Both the listed technical contact and the listed administrative
contact should be available to verify that the request is authentic and they
authorize the requested change. Except where a contract between ICANN and the
TLD delegee, sponsor, or operator expressly states to the contrary, the IANA
shall be entitled to rely on authorization of either the administrative or
technical contact as constituting a request for a contact change by the TLD
delegee, sponsor, or operator, except that any change of the identity of the
sponsoring organization, administrative contact, or technical contact must
comply with notice requirements stated in the agreement.
(26 February 2001)
22
<PAGE>
Appendix C
----------
Functional Specification
This functional specification for the Registry TLD consists of the following
elements:
1. Verisign Registry Registrar Protocol Version 1.1.0 (May 2000) (RFC
2832);
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 provreg standard.
In addition, functional specifications are set forth in other parts of the
registry agreement and its appendices. For example, specifications for Whois
service are set forth in Appendix O.
23
<PAGE>
1. Verisign Registry Registrar Protocol Version 1.1.0 (May 2000)
-------------------------------------------------------------
Network Working Group S. Hollenbeck
Request for Comments: 2832 M. Srivastava
Category: Informational Network Solutions, Inc. Registry
May 2000
NSI Registry Registrar Protocol (RRP) Version 1.1.0
Status of this Memo
This memo provides information for the Internet community. It does not
specify an Internet standard of any kind. Distribution of this memo is
unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes a protocol for the registration and management of
second level domain names and associated name servers in both generic Top
Level Domains (gTLDs) and country code Top Level Domains (ccTLDs). This
protocol was developed by the Network Solutions Registry for use within the
Shared Registration System and is being published "as-is" to document the
protocol implementation developed by the Network Solutions, Inc. Registry.
Internet domain name registration typically involves three entities: a
registrant who wishes to register a domain name, a registrar who provides
services to the registrant, and a registry that provides services to the
registrar while serving as the authoritative repository of all functional
information required to resolve names registered in the registry's TLDs. This
document describes a protocol for registry-registrar communication only. The
protocol does not provide any registrant services.
This document is being discussed on the "rrp" mailing list. To join the list,
send a message to [[email protected]] with the words "subscribe rrp"
in the body of the message. There is also a web site for the mailing list
archives at [http:/www.NSIRegistry.net/afhmaillist/rrp].
Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD]. Further,
24
<PAGE>
the term "implicit attribute" refers to an entity attribute whose value is
derived either from another attribute or is dependent on an established RRP
session.
In examples, "C:" represents lines sent by the registrar client and
"S:" represents lines sent by the registry server.
The term "System" is used in this document to collectively refer to this
protocol and the software and hardware that implements the protocol.
Table of Contents
1. Introduction ................................................. 3
2. Security Services ............................................ 4
2.1 Connection Security ......................................... 4
2.2 System Data Security ........................................ 5
3. Connection Model ............................................. 5
4. Protocol Description ......................................... 6
4.1 Request Format .............................................. 7
4.2 Response Format ............................................. 8
4.3 Protocol Commands ........................................... 8
4.3.1 ADD ....................................................... 8
4.3.2 CHECK ..................................................... 11
4.3.3 DEL ....................................................... 12
4.3.4 DESCRIBE .................................................. 14
4.3.5 MOD ....................................................... 14
4.3.6 QUIT ...................................................... 16
4.3.7 RENEW ..................................................... 17
4.3.8 SESSION ................................................... 18
4.3.9 STATUS .................................................... 18
4.3.10 TRANSFER ................................................. 21
5. Response Codes ............................................... 23
5.1 Response Code Summary ....................................... 23
5.2 Command-Response Correspondence ............................. 28
6. Domain Status Codes .......................................... 29
6.1 Domain Status Code Description .............................. 30
7. Formal Syntax ................................................ 30
8. Internationalization ......................................... 35
9. Known Issues ................................................. 35
10. Security Considerations ..................................... 37
11. IANA Considerations ......................................... 37
12. References .................................................. 37
13. Acknowledgments ............................................. 38
14. Authors' Addresses .......................................... 38
15. Full Copyright Statement .................................... 39
25
<PAGE>
1. Introduction
This document describes the specifications for the NSI Registry Registrar
Protocol (RRP) version 1.1.0, a TCP-based, 7-bit US-ASCII text protocol that
permits multiple registrars to provide second level Internet domain name
registration services in the top level domains (TLDs) administered by a TLD
registry. RRP is specified using Augmented Backus-Nauer Form (ABNF) as
described in [ABNF]. Note that all ABNF string literals are case-insensitive
and the examples provided in this document may use mixed case to improve
readability.
RRP was developed by the Network Solutions, Inc. Registry under the auspices
of the Shared Registration System program. The protocol was initially
deployed in April 1999 as part of a test bed implementation of the Shared
Registration System with five registrars. Additional registrars began using
the protocol in July 1999. The operational experiences of both the registry
and the registrars identified several "lessons learned" which have been
documented here as "Known Issues".
This document provides both a description of a protocol and notice of learned
operational issues that may be useful as first steps in developing a
standards track domain registration services protocol. This document and the
protocol it describes may be modified in the future based on continued
operational experience and community reaction.
The registry stores information about registered domain names and associated
name servers. A domain name's data includes its name, name servers,
registrar, registration expiration date, and status. A name server's data
includes its server name, IP addresses, and registrar. A registrar MAY
perform the following registration service procedures using RRP:
- Determine if a domain name has been registered.
- Register a domain name.
- Renew the registration of a domain name.
- Cancel the registration of a domain name.
- Update the name servers of a domain name.
- Transfer a domain name from another registrar.
- Examine the status of domain names that the registrar has registered.
- Modify the status of domain names that the registrar has registered.
- Determine if a name server has been registered.
- Register a name server.
- Update the IP addresses of a name server.
26
<PAGE>
- Delete a name server.
- Examine the status of name servers that the registrar has registered.
All RRP commands include features to provide idempotency. That is, the effect
of each command is the same if the command is executed once or if the command
is executed multiple times. This property is extremely useful in situations
when a command is retried due to an error condition that results in a missed
command response and a command retry is attempted. Command retries will be
caught by the System and rejected with an appropriate error response code.
Command parameters that do not provide idempotency will be explained fully as
part of the appropriate command description.
2. Security Services
RRP provides only basic password-based registrar authentication services.
Additional security services, including privacy and registrar authentication
using public key cryptography, are provided through other System features.
2.1 Connection Security
Each RRP session MUST be encrypted using the Secure Socket Layer (SSL) v3.0
protocol as specified in [SSL]. SSL provides privacy services that reduce
the risk of inadvertent disclosure of registrar-sensitive information, such
as the registrar's user identifier and password.
SSL supports mutual authentication of both the client and server using
signed digital certificates. The Shared Registration System implemented by
the NSI Registry requires digital certificates issued by a commercial
certification authority for both registrar clients and public registry RRP
servers. Both the registrar client and the public registry RRP server are
authenticated when establishing an SSL connection. Further, a registrar MUST
be authenticated when establishing an RRP connection via the RRP SESSION
command by providing a registrar user identifier and password known only to
the registrar and the System. Registrars may change their session password
at any time using the RRP SESSION command.
The SSL protocol is not an IETF Standards Track protocol. The Transport
Layer Security protocol, specified in [TLS], is a Standards Track protocol
that provides SSL v3.0 compatibility features.
27
<PAGE>
2.2 System Data Security
The System stores information about the registered domain names and their
name servers. Only the current registrar of a registered domain name is
authorized to query it, update its name servers, and cancel or renew it. Any
registrar can request a transfer of a domain name and its associated name
servers from another registrar to the requesting registrar. Only the current
sponsoring registrar can receive and explicitly approve or reject domain
transfer requests.
Only a name server's registrar can query, update, and delete it. In general,
name servers must be registered through the current registrar of the name
server's parent domain name, though an implementation MAY allow use of name
servers registered in other TLDs without specifying IP addresses or
requiring parent domain registration. Use of ccTLD name servers for a gTLD
domain name is one such example.
Name servers are implicitly transferred by the System when their parent
domain name is transferred. In addition, a name server cannot be deleted if
it is hosting domain names.
3. Connection Model
IANA has assigned TCP port 648 for RRP use. All RRP implementations MUST
provide RRP services over SSL on TCP port 648. An RRP server MUST return a
banner in the following format to confirm that a connection has been
established:
(registry name) RRP Server version (version)(crlf)
(server build date and time)(crlf)
Each line ends with carriage return and line feed characters. The server
build date and time string includes the day, month, date, time (specified in
hours, minutes, and seconds), the local time zone, and the four-digit year.
A dot (".") in column one on a line by itself marks the end of banner text.
Example
A registrar successfully establishes a connection with the NSI Registry on
TCP port 648:
S:NSI RRP Server version 1.1.0
S:Mon Oct 25 20:20:34 EDT 1999
S:.
28
<PAGE>
4. Protocol Description
A typical RRP session will go through a number of states during its lifetime.
Figure 1 illustrates the possible states of an RRP server.
Initially, the server waits for a client connection and authentication (PRE).
All client connections MUST be authenticated.
v
+-----------------+ Timeout
Waiting for -------------------+
Authentication Succeeded Client
+--------- Authentication Authentication
(PRE) -----+ Failed
+-----------------+
V V
+-----------+ Succeeded +--------------------+
Waiting for +----------------- Waiting for
Command ----------+ Authentication Retry
(WFC) Timeout (WFR)
+-----------+ +--------------------+
+
Timeout Failed
Request V Response
+-----------+ V V V
Executing +--------------------+
Command +---------+ Disconnected
(EXE) --------------------+ (DIS)
+-----------+ QUIT +--------------------+
Figure 1: RRP Server Finite State Machine
If the authentication fails, the server gives the client another chance to
identify itself (WFR). If the authentication fails again, the server
disconnects (DIS). Otherwise, the server waits for a request from the client
(WFC). Upon receiving a request, the server executes it and responds to the
client with the result (EXE). The server then waits again for another request
from the client (WFC). If the client sends a QUIT command, the server ends
the session and disconnects (DIS). To keep its state in sync with that of the
server, the client SHOULD wait for a response from the server before sending
another request on the same connection. The following table summarizes these
states:
29
<PAGE>
PRE Waiting for client connection and authentication
WFR Waiting for authentication retry
WFC Waiting for a command from an authenticated client
EXE Executing a command
DIS Disconnected
The WFR and WFC states MAY time out. An implementation SHOULD define
inactivity timeout periods for these states based on System-specific factors,
including (but not limited to) resource availability and security risk. In
the absence of other factors, a default timeout period of 10 minutes SHOULD
be used. The server MAY disconnect if the server is in one of these states
and no message is received from the client during the timeout period.
4.1 Request Format
An RRP request nominally consists of a command name, an entity block, command
options, and an end-of-command delimiter. Command options and entity blocks
collectively define command parameters and their specification is order
independent; examples provided in this document specify entity blocks before
command options.
CommandName [EntityBlock] [CommandOptions] EndOfCommand
A command name specifies the type of an RRP request. A command is a word or
abbreviation terminated by a carriage-return linefeed (crlf) sequence.
CommandName<crlf>
An entity block specifies the data in an RRP request. It consists of
attribute name-value pairs specifying the entity and all of the attributes of
the entity. Each attribute name-value pair starts with the attribute name,
followed by a colon, the attribute value, and is finally terminated by a
carriage-return linefeed sequence. Entity blocks are optional for some
requests.
entityName:entityValue<crlf>
attributeName:attributeValue<crlf>
Command options specify control parameters for an RRP request. A command
option starts with a dash, followed by the option name, a colon, the option
value, and is finally terminated by a carriage-return linefeed sequence.
-commandOptionName:commandOptionValue<crlf>
30
<PAGE>
An EndOfCommand delimiter specifies the end of an RRP request. It
consists of a dot (".") in column one followed by a carriage-return
linefeed sequence.
.<crlf>
4.2 Response Format
An RRP response starts with a three-digit response code, followed by a space,
an ASCII text description of the response, a carriage-return linefeed
sequence, and zero or more attribute name-value pair lines. An RRP response
is terminated by a dot in column one followed by a carriage-return linefeed
sequence.
ResponseCode<space>responseDescription<crlf>
[attributeName:attributeValue<crlf>]
.<crlf>
4.3 Protocol Commands
Implementations of RRP commands MUST provide "all or nothing" success and
failure operation. Failed command execution MUST leave the System in the same
state it was in before the command was attempted and failed.
All RRP commands include features to provide idempotency. Command features
that are not idempotent are explained fully as needed as part of the
appropriate command description.
4.3.1 ADD
This command allows a registrar to register a domain name or a name
server in the System.
4.3.1.1 Registering a Domain Name
The request to register a domain name MUST contain the following data:
- The "EntityName" parameter set to value "Domain".
- Fully qualified second level domain name in the "DomainName" parameter.
31
<PAGE>
The request to register a domain name MAY contain 1 or more, and a
maximum of 13, fully qualified name servers hosting the domain name
in multiple instances of the "NameServer" parameter. The name servers
MUST have already been registered in the registry. Implementations
MAY allow specification of name servers associated with domains
registered in other TLDs. For example, an implementation MAY allow
use of ccTLD name servers for gTLD domain name registration.
The request to register a domain name MAY contain the initial
registration period in years for the domain being registered in a
single instance of the "Period" parameter. The System MUST provide a
default initial registration period in years if the "Period"
parameter is not provided. The acceptable year values for the
"Period" parameter are implementation specific.
The System will register the domain name to the registrar for the
period specified by the registrar. If the registrar does not specify
a registration period, a System-specified default value MUST be used
for the initial registration period. If the domain name is
successfully registered, the System MUST return the registration
expiration date in the "registration expiration date" attribute in
the response.
Authorized User: All registrars MAY use the ADD command to register
domain names.
Examples
A registrar registers a domain name without specifying name servers:
C:add<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:-Period:10<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:registration expiration date:2009-09-22 10:27:00.0<crlf>
S:status:ACTIVE<crlf>
S:.<crlf>
32
<PAGE>
A registrar registers a domain name using previously-registered name
servers:
C:add<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example2.com<crlf>
C:-Period:10<crlf>
C:NameServer:ns1.example.com<crlf>
C:NameServer:ns2.example.com<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:registration expiration date:2000-09-22 10:27:00.0<crlf>
S:status:ACTIVE<crlf>
S:.<crlf>
4.3.1.2 Registering a Name Server
The request to register a name server MUST contain the following
data:
- The "EntityName" parameter set to value "NameServer".
- Fully qualified server name of the name server in the "NameServer"
parameter.
If the name server being registered is the child of a registered domain name,
the name server registration request MUST include one or more, and a maximum
of 13, name server IP addresses in multiple instances of the "IPAddress"
parameter. Name servers associated with domains registered in other TLDs
SHOULD NOT be specified with IP addresses to reduce the possibility of
duplicating DNS NS records for the name servers in multiple zone files.
The registrar MUST register the name server in the System before
using it to host domain names. Further, the name server MUST be
registered through the same registrar that is the current registrar
of its parent domain name. The System MAY allow any registrar to use
the name server to host domain names.
Authorized User: All registrars MAY use the ADD command to register
name servers.
33
<PAGE>
Examples
A registrar registers a new name server in an existing domain name:
C:add<crlf>
C:EntityName:NameServer<crlf>
C:NameServer:ns1.example.com<crlf>
C:IPAddress:198.41.1.11<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
4.3.2 CHECK
This command allows a registrar to determine if a domain name or name
server has been registered in the System.
4.3.2.1 Domain Name Check
The request to determine if a domain name is registered MUST contain
the following data:
- The "EntityName" parameter set to value "Domain".
- Fully qualified second level domain name in the "DomainName"
parameter.
The System MUST provide a positive or negative response to document
domain name availability at the moment the command is executed.
Authorized User: All registrars MAY use the CHECK command to
determine if a domain name has been registered or not.
Examples
A registrar checks the availability of a domain name in the System:
C:check<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:.<crlf>
S:211 Domain name not available<crlf>
S:.<crlf>
34
<PAGE>
4.3.2.2 Name Server Check
The request to determine if a name server is registered MUST contain
the following data:
- The "EntityName" parameter set to value "NameServer".
- Fully qualified server name in the "NameServer" parameter.
The System MUST provide a positive or negative response to document
name server availability at the moment the command is executed. If
the name server has been registered, the System MUST return the IP
address(es) of the name server.
Authorized User: All registrars MAY use the CHECK command to
determine if a name server has been registered or not.
Examples
A registrar checks the availability of a server name in the System:
C:check<crlf>
C:EntityName:Nameserver<crlf>
C:Nameserver:ns1.example.com<crlf>
C:.<crlf>
S:213 Name server not available<crlf>
S:ipAddress:192.10.10.10<crlf>
S:.<crlf>
4.3.3 DEL
This command allows a registrar to delete (cancel the registration)
of a domain name or delete a name server.
4.3.3.1 Deleting a Domain Name
The request to cancel the registration of a domain name MUST contain
the following data:
- The "EntityName" parameter set to value "Domain".
- Fully qualified second level domain name in the "DomainName"
parameter.
A request to delete a domain name SHOULD cause the deletion of all
name servers that are children of the domain name being deleted. The
name servers SHOULD be deleted if they are not actively hosting other
domains. A domain MUST not be deleted if it has child name servers
hosting other domains.
35
<PAGE>
Authorized User: The current registrar of a domain name MAY use the
DEL command to delete a domain name from the System.
Examples
A registrar deletes a domain name, implicitly deleting all name
servers registered in the domain:
C:del<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
4.3.3.2 Deleting a Name Server
The request to delete a name server MUST contain the following data:
- The "EntityName" parameter set to value "NameServer".
- Fully qualified name of the name server in the "NameServer"
parameter.
A name server MUST not be deleted if it is hosting domains. Deleting
such domains or name servers is prohibited because their deletion
WILL result in orphaning the hosted domains.
Authorized User: The current registrar of a name server MAY use the
DEL command to delete a name server from the System.
Examples
A registrar deletes a name server that is not hosting domains:
C:del<crlf>
C:EntityName:NameServer<crlf>
C:NameServer:ns1.registrarA.com<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
36
<PAGE>
A registrar tries to delete a name server that is hosting domains:
C:del<crlf>
C:EntityName:NameServer<crlf>
C:NameServer:ns1.registrarA.com<crlf>
C:.<crlf>
S:532 Domain names linked with name server<crlf>
S:.<crlf>
4.3.4 DESCRIBE
This command allows a registrar to obtain general information about
an RRP implementation. The command MAY contain the following
parameters:
- The "Target" parameter set to value "Protocol".
The implementation MUST return the protocol version number whether or
not the request contains the "Target" parameter.
Authorized User: All registrars MAY use the DESCRIBE command.
Examples
A registrar obtains general information about an RRP implementation:
C:describe<crlf>
C:-Target:Protocol<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:Protocol:RRP 1.1.0<crlf>
S:.<crlf>
4.3.5 MOD
This command allows a registrar to update a registered domain name or
a name server. The command allows the following operations on an
attribute value for both single-valued and multi-valued attributes:
- Add an attribute value. The value to be added MUST be unique among
the values of the attribute. For a single-valued attribute, it
replaces the current value.
- Remove an attribute value. The value to be removed MUST exist.
Further, an attribute value cannot be removed if it is the only
value of a required attribute.
Attribute values to be removed are identified by tagging with an "="
suffix.
37
<PAGE>
4.3.5.1 Domain Modification
The request to modify a registered domain name MUST contain the
following data:
- The "EntityName" parameter set to value "Domain".
- Fully qualified second level domain name in the "DomainName"
parameter.
The registrar can perform the following update operations on the
domain name:
- Update the name servers of the domain name by setting one or more
instances of the "NameServer" parameter.
- Update the status of the domain name by setting one or more
instances of the "Status" parameter. Valid values for the "Status"
parameter are defined in Section 6.
Authorized User: The current registrar of a domain name MAY use the
MOD command to modify the attributes of a domain name.
Examples
A registrar removes one name server (ns1) from a domain and adds a
new name server (ns3) to the same domain:
C:mod<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:NameServer:ns3.registrarA.com<crlf>
C:NameServer:ns1.registrarA.com=<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
4.3.5.2 Name Server Modification
The request to update a name server MUST contain the following data:
- The "EntityName" parameter set to value "NameServer".
- Fully qualified server name of the name server in the "NameServer"
parameter.
38
<PAGE>
The registrar can perform the following update operations on the name
server:
- Update the "NameServer" attribute of the name server. This allows a
registrar to change the name of a name server while preserving all
existing associations.
- Update the IP addresses of the name server by setting one or more
instances of the "IPAddress" parameter.
Authorized User: The current registrar of a name server MAY use the
MOD command to modify the attributes of a domain name.
Examples
A registrar changes the name and IP address of a name server:
C:mod<crlf>
C:EntityName:NameServer<crlf>
C:NameServer:ns1.registrarA.com<crlf>
C:NewNameServer:ns2.registrarA.com<crlf>
C:IPAddress:198.42.1.11<crlf>
C:IPAddress:198.41.1.11=<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
4.3.6 QUIT
This command allows a registrar to close an RRP connection. A
response MUST be sent before closing the connection.
Authorized User: All registrars MAY use the QUIT command.
Examples
A registrar ends an RRP session and closes an existing connection:
C:quit<crlf>
C:.<crlf>
S:220 Command completed successfully. Server closing connection<crlf>
S:.<crlf>
39
<PAGE>
4.3.7 RENEW
This command allows a registrar to renew a domain name in the System.
The request to renew a domain name MUST contain the following data:
- The "EntityName" parameter set to value "Domain".
- Fully qualified second level domain name in the "DomainName"
parameter.
The request to renew a domain name MAY contain the renewal period in
years for the domain being renewed in a single instance of a "Period"
parameter and a single instance of a "CurrentExpirationYear"
parameter. These parameters MUST appear together if either is
specified, though the order in which the parameters appear is
insignificant. The "Period" parameter identifies the number of years
to be added to the registration. The "CurrentExpirationYear"
parameter identifies the current expiration year, and is required to
ensure that repeated attempts to retry this command do not result in
multiple successful renewals. The System MUST provide a default
number of renewal years if the "Period" and "CurrentExpirationYear"
parameters are not provided. Repeated use of this command without the
"Period" and "CurrentExpirationYear" parameters may result in
repeated successful renewals since idempotency is not provided when
these parameters are not used. The acceptable year values for the
"Period" parameter are implementation specific subject to syntax
restrictions.
The System renews the domain name for a period specified by the
registrar. If the domain name renewal is completed successfully, the
System MUST return the new registration expiration date in the
"RegistrationExpirationDate" attribute in the response.
Authorized User: The current registrar of a domain name MAY use the
RENEW command.
Examples
A registrar renews a domain name using a specified renewal period:
C:renew<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:-Period:9<crlf>
C:-CurrentExpirationYear:2001<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:registration expiration date:2010-09-22 10:27:00.0<crlf>
S:.<crlf>
40
<PAGE>
4.3.8 SESSION
This command allows a registrar to establish an RRP session. A
registrar can also use this command to change their password. The
request to establish an RRP connection MUST contain the following
command parameters:
- The "Id" parameter set to the registrar's System user ID.
- The "Password" parameter set to the registrar's current System
password.
The request to establish an RRP session MAY contain a new password
for the registrar in a single instance of the "NewPassword"
parameter.
The registrar MUST send this command to the System before any other
command. If the command fails due to invalid information (such as an
invalid registrar ID or password), the registrar can resend this
request with corrected information. If the command fails a second
time, the System SHOULD close the connection.
Authorized User: All registrars MAY use the SESSION command.
Examples
A registrar establishes an RRP session:
C:session<crlf>
C:-Id:registrarA<crlf>
C:-Password:i-am-registrarA<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
4.3.9 STATUS
This command allows a registrar to determine the current status of a
domain name or name server.
4.3.9.1 Domain Status
The request to query a domain name MUST contain the following data:
- The "EntityName" parameter set to value "Domain".
- Fully qualified second level domain name in the "DomainName"
parameter.
41
<PAGE>
The response from the System MAY contain the following data:
- Fully qualified server names of name servers hosting the domain
name in multiple instances of the "nameserver" attribute.
- Registration expiration date in the "registration expiration date"
attribute.
- ID of the current registrar of the domain name in the "registrar"
attribute.
- Date the domain name was transferred by the current registrar in
the "registrar transfer date" attribute.
- Current statuses of the domain name in multiple instances of the
"status" attribute.
- Date the domain name was originally registered in the "created
date" attribute.
- ID of the registrar that originally registered the domain name in
the "created by" attribute.
- Date the domain name was last updated in the "updated date"
attribute.
- ID of the entity (either a registrar or the registry) that last
updated the domain name in the "updated by" attribute.
Authorized User: The current registrar of a domain name MAY use the
STATUS command to view current domain name attributes.
Examples
The current registrar of a domain name queries the domain name:
C:status<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:nameserver:ns2.registrarA.com<crlf>
S:nameserver:ns3.registrarA.com<crlf>
S:registration expiration date:2010-09-22 10:27:00.0<crlf>
S:registrar:registrarA<crlf>
S:registrar transfer date:1999-09-22 10:27:00.0<crlf>
S:status:ACTIVE<crlf>
S:created date:1998-09-22 10:27:00.0<crlf>
S:created by:registrarA<crlf>
S:updated date:2002-09-22 10:27:00.0<crlf>
S:updated by:registrarA<crlf>
S:.<crlf>
42
<PAGE>
A registrar queries a domain name currently registered by another
registrar:
C:status<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:.<crlf>
S:531 Authorization failed<crlf>
S:.<crlf>
4.3.9.2 Name Server Status
The request to query a name server MUST contain the following data:
- The "EntityName" parameter set to value "NameServer".
- Fully qualified name of the name server in the "NameServer"
parameter.
The response from the System MAY contain the following data:
- Fully qualified name of the name server in the "nameserver"
attribute.
- IP addresses of the name server in multiple instances of the
"ipaddress" attribute.
- ID of the current registrar of the name server in the "registrar"
attribute.
- Date the name server was transferred by the current registrar in
the "registrar transfer date" attribute.
- Date the name server was registered in the "created date"
attribute.
- ID of the entity that registered the name server in the "created
by" attribute.
- Date the name server was last updated in the "updated date"
attribute.
- ID of the entity that last updated the name server in the "updated
by" attribute.
Authorized User: The current registrar of a name server MAY use the
STATUS command to view current domain name attributes.
Examples
The current registrar of a name server queries the name server:
C:status<crlf>
C:EntityName:NameServer<crlf>
C:NameServer:ns1.registrarA.com<crlf>
C:.<crlf>
43
<PAGE>
S:200 Command completed successfully<crlf>
S:ipaddress:198.42.1.11<crlf>
S:registrar:registrarA<crlf>
S:registrar transfer date:1999-09-22 10:27:00.0<crlf>
S:CreatedDate:1998-09-22 10:27:00.0<crlf>
S:CreatedBy:registrarA<crlf>
S:UpdatedDate:2002-09-22 10:27:00.0<crlf>
S:UpdatedBy:registrarA<crlf>
S:.<crlf>
A registrar queries a name server that was registered by another
registrar:
C:status<crlf>
C:EntityName:NameServer<crlf>
C:NameServer:ns1.registrarA.com<crlf>
C:.<crlf>
S:531 Authorization failed<crlf>
S:.<crlf>
4.3.10 TRANSFER
This command allows a registrar to request transfer of domain name
sponsorship from a second registrar and to approve or reject transfer
requests initiated by other registrars. The request to transfer a
domain name MUST contain the following data:
- The "EntityName" parameter set to value "Domain".
- Fully qualified second level domain name in the "DomainName"
parameter.
The identity of the requesting registrar is derived from the current
active session. The identity of the current sponsoring registrar (the
registrar who must approve or reject the transfer request) is known
by the registry and does not need to be known by the requesting
registrar in advance of issuing the transfer request.
The System MUST notify the potential losing registrar when a domain
transfer request has been received using an out-of-band transport
mechanism such as electronic mail and/or transaction reporting. The
losing registrar SHOULD then explicitly approve or reject the
transfer. A request to approve or reject a transfer request MUST
contain a single instance of the "Approve" parameter with a value of
"Yes" to approve the transfer or a value of "No" to reject the
transfer. A server implementation MAY provide a default approval or
rejection action to be taken if the losing registrar does not
explicitly approve or reject the transfer request within a fixed
amount of time. The criteria used by registrars to approve or deny
44
<PAGE>
requested transfers are typically based on business policies that are
beyond the scope of this document.
Approval of a transfer by the current sponsoring registrar results in
a change of sponsorship to the original requesting registrar.
Approval attempts by any other registrar MUST result in explicit
failure of the attempted approval. Rejection of the transfer by the
current sponsoring registrar results in an end to the transfer
request with no change in sponsorship. Rejection attempts by any
other registrar MUST result in explicit failure of the attempted
rejection.
Name servers MUST be implicitly transferred when their parent domain
name is transferred.
Authorized User: All registrars MAY use the TRANSFER command to
request transfer of registration service authority to the requesting
registrar. Only the current sponsoring registrar of a domain name may
explicitly approve or reject a requested transfer. The registry MAY
implicitly approve or reject requested transfers after a fixed amount
of time.
Examples
A registrar requests transfer of a domain name from another
registrar:
C:transfer<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
The original registrar approves the transfer request:
C:transfer<crlf>
C:-Approve:Yes<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
45
<PAGE>
5. Response Codes
RRP commands may return a variety of response codes to signify normal
completion or error conditions. This section documents all of the defined
RRP response codes.
5.1 Response Code Summary
200 Command completed successfully This is the normal response for
successful completion of most RRP commands.
210 Domain name available
This is the normal response for successful completion of an RRP CHECK
command for a domain name that is not currently registered.
211 Domain name not available
This is the normal response for successful completion of an RRP CHECK
command for a domain name that is currently registered.
212 Name server available
This is the normal response for successful completion of an RRP CHECK
command for a name server that is not currently registered.
213 Name server not available
This is the normal response for successful completion of an RRP CHECK
command for a name server that is currently registered.
220 Command completed successfully. Server closing connection This is
the normal response for successful completion of an RRP QUIT command. It
may also be returned by other RRP commands if a transient situation is
noted that requires closing the connection after successfully completing
the RRP command.
420 Command failed due to server error. Server closing connection A
transient server error has caused RRP command failure and session
termination. A new session must be established before continued processing
can be attempted.
421 Command failed due to server error. Client should try again A
transient server error has caused RRP command failure. A subsequent retry
may produce successful results.
500 Invalid command name
A client-specified RRP command name was not recognized as a valid RRP
command name.
46
<PAGE>
501 Invalid command option
A client-specified RRP command parameter was not recognized as a valid RRP
command parameter.
502 Invalid entity value
The "value" of an entity name-value pair is invalid. Command blocks that
require an "EntityName" parameter also require a value that specifies the
entity name, and the provided value is invalid.
503 Invalid attribute name
A client-specified RRP command parameter was not recognized as a valid RRP
command parameter.
504 Missing required attribute
A parameter required to execute the RRP command was not provided by the
client. The command should be retried with all required parameters
specified.
505 Invalid attribute value syntax
A supplied parameter value is syntactically incorrect. For example, a year
value digit such as "5" may be required but the client provided a string of
characters such as "five".
506 Invalid option value
A client-specified value for an RRP command parameter is out-of-bounds or
otherwise not within acceptable System limits.
507 Invalid command format
The specified command does not resemble a well-formed RRP command. The
command should be retried using the proper command structure and syntax.
508 Missing required entity
An entity required for command completion was not provided by the client.
For example, the CHECK command requires specification of either a "Domain"
entity or a "Nameserver" entity.
509 Missing command option
A command parameter that isn't really optional (such as the registrar ID in
a SESSION command) was not provided by the client. The command should be
retried with all needed parameters.
520 Server closing connection. Client should try opening new
connection; <why>
A timeout event has been detected, and the client's session is being
ended. The System SHOULD define timeout periods to begin a client
47
<PAGE>
command, complete a client command, and for the duration of an open session.
The reason for the timeout MUST be provided at the end of the response code
string.
521 Too many sessions open. Server closing connection
A System-defined limit on the number of open connections has been exceeded, and
it is impossible to establish a new session at the moment. It may be possible
to establish a session by waiting for a few moments or by closing existing
unused sessions.
530 Authentication failed
The client-supplied registrar identifier or password was not recognized by the
System. A subsequent retry with valid values may produce successful results.
Repeated authorization failures MAY result in termination of the TCP
connection.
531 Authorization failed
Registrars may not view or alter data associated with either the registry or
another registrar. This response code is typically returned when a registrar
attempts to view or modify data belonging to either the registry or another
registrar. A typical situation includes doing a STATUS command for a domain
registered to another registrar.
532 Domain names linked with name server
The name server is hosting active domains. This error occurs when a registrar
is trying to delete a server that is the name server for active domains. The
registry MUST not allow the registrar to delete this server. All of the domain
names using this server MUST be modified to use a different name server before
the name server can be deleted.
533 Domain name has active name servers
The domain name has active name servers. The registrar is trying to delete a
domain name that is a parent domain of an active name server, i.e., a server
that is hosting active domains. All of the name servers within the domain MUST
be removed from service before the domain can be deleted.
534 Domain name has not been flagged for transfer
The registrar is trying to approve or reject a domain name transfer for a
domain name that is not pending transfer.
535 Restricted IP address
IANA identifies certain IP address ranges that are not valid for normal use.
The registrar is trying to use an IP address that is in a restricted IP address
range as identified by IANA.
48
<PAGE>
536 Domain already flagged for transfer
The registrar tried to perform a transfer command for a domain name that is
awaiting approval of an earlier transfer request.
540 Attribute value is not unique
A supplied attribute value is not unique. This occurs when the registrar is
adding a domain name that already exists in the registry, a server that already
exists in the registry, or an IP address that is already being used by another
server in the registry. Another possibility occurs when performing domain
modifications and the registrar is adding a server that is already in the list
of servers for the domain name or setting a domain name to a status to which it
is already set. The RRP STATUS command MAY be used to determine current domain
name status before attempting to change the status. When modifying or adding a
name server, the IP address of the name server might not be unique. The
registry MUST not allow IP addresses to be used by more than one server.
541 Invalid attribute value
A supplied parameter value is invalid. Examples of invalid attribute values
include an invalid IP address, an invalid domain name, an invalid server name,
or an invalid renewal period.
542 Invalid old value for an attribute
A current attribute value to be modified is invalid. The registrar is trying to
modify an attribute of a server or a domain name that does not exist in the
registry.
543 Final or implicit attribute cannot be updated
The registrar is attempting to modify an attribute that is only modifiable by
the registry. Registrars can not modify final or implicit attribute values.
544 Entity on hold
The attempted operation was rejected because the entity is on HOLD status. If
the HOLD status was set by the registrar, the status can be changed using the
MOD command and the requested command can be retried. If the HOLD status was
set by the registry, the registrar must contact the registry to change the
status before the command can be successful.
545 Entity reference not found
A required entity reference was not found. This occurs when the registrar tries
to add a new name server and the parent domain of the name server does not
exist in the registry. It also occurs when the user is trying to add a new name
server to a domain name when the name server does not exist in the registry.
49
<PAGE>
546 Credit limit exceeded
The registrar's credit limit has been exceeded. This is an implementation
specific error that occurs when a potentially billable operation, such as
adding a domain name, renewing a domain name, or transferring a domain name, is
attempted and the registrar does not have sufficient financial standing with
the registry to complete the operation.
547 Invalid command sequence
RRP commands are issued using a well-formed syntax that requires entry of
command structures in particular sequences. This response code indicates that
an ill-formed command was received and rejected.
548 Domain is not up for renewal
A RENEW command was attempted during a period in which the domain can not be
renewed. Implementations MAY limit renewal periods to particular time frames,
such as within 90 days of the domain's expiration. This response indicates that
the RENEW command was received outside of the System-defined domain renewal
period.
549 Command failed
A System error prevented successful completion of the requested RRP command.
Retrying the command might produce success, but a repeated failure indicates a
System error condition.
550 Parent domain not registered
The parent domain of a name server being registered is not registered. This
occurs when the registrar tries to add a new name server and the parent domain
for the server does not exist in the registry.
551 Parent domain status does not allow for operation
The status of the parent domain does not allow the requested operation. This
occurs when a registrar tries to modify a server whose parent domain is flagged
as LOCK or HOLD in the registry.
552 Domain status does not allow for operation
The status of the domain does not allow the requested operation. This occurs
when a registrar tries to modify or delete a domain that is flagged as LOCK or
HOLD in the registry.
553 Operation not allowed. Domain pending transfer
The status of the domain does not allow the requested operation. The registrar
is attempting to delete a domain that is pending approval or denial of a
transfer request.
50
<PAGE>
554 Domain already registered
A registrar tried to register a domain name that has already been
registered by the same registrar.
555 Domain already renewed
A registrar tried to renew a domain using the same parameters as specified
for an earlier, successful renewal. This will commonly occur when executing
the same RENEW command more than once.
556 Maximum registration period exceeded
A registrar tried to renew a domain registration, and the resulting new
registration period exceeds the System-defined maximum registration period.
If there is renewal time available with the System-defined maximum
registration period it may be possible to retry the RENEW command with
specified renewal period parameters.
5.2 Command-Response Correspondence
The session between the client and the server is intended to be an
alternating dialogue. Each command issued by a client MUST be acted upon by
the server, which MUST return a response code to document the success or
failure of command execution. "Success" means that the command completed
normal execution without error. "Failure" means that the System did not
complete the command as requested. Failure may be due to either syntax,
semantic, data, or System errors.
A complete list of response codes for each RRP command is listed below.
Command: ADD
Success: 200, 220
Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535,
540, 541, 545, 546, 547, 549, 550, 554
Command: CHECK
Success: 210, 211, 212, 213
Failure: 220, 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 541,
547, 549
Command: DEL
Success: 200, 220
Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532,
533, 541, 544, 545, 547, 549, 551, 552, 553
Command: DESCRIBE
Success: 200, 220
Failure: 420, 421, 500, 501, 506, 507, 509, 520, 547, 549
51
<PAGE>
Command: MOD
Success: 200, 220
Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535,
540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553
Command: QUIT
Success: 220
Failure: 420, 421, 500, 507, 520, 547, 549
Command: RENEW
Success: 200, 220
Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 541,
545, 546, 547, 548, 549, 552, 553, 555, 556
Command: SESSION
Success: 200, 220 Failure: 420, 421, 500, 501, 506, 507, 508, 509, 520,
521, 530, 531, 547, 549
Command: STATUS
Success: 200, 220
Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520,
531, 541, 545, 547, 549
Command: TRANSFER
Success: 200, 220
Failure: 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520,
531, 534, 536, 541, 544, 545, 546, 547, 549, 552, 553
6. Domain Status Codes
The status of a domain can be viewed using the RRP STATUS command and
modified using the RRP MOD command. Both the registry and the sponsoring
registrar MAY view and change the status of a domain. The criteria for
status changes are highly dependent on registry and registrar business
models and are thus beyond the scope of this specification.
The domain's status SHOULD have a direct bearing on whether or not the
domain appears in the appropriate TLD zone file and whether or not the
domain can be modified. A domain can have more than one assigned status,
e.g., REGISTRAR-HOLD and REGISTRAR-LOCK. If a domain is in ACTIVE status,
then the domain name can only be in this status. When a registrar sets a
domain name to REGISTRAR-LOCK, the registry MUST automatically remove the
ACTIVE status. When the registrar removes the REGISTRAR-LOCK and other
domain statuses, the registry MUST automatically set the domain name status
to ACTIVE.
52
<PAGE>
6.1 Domain Status Code Description
ACTIVE: This is the default status of a domain at registration time. The
registry sets the domain to this status. The domain is modifiable by the
registrar. The domain can be renewed. The domain SHALL be included in the
zone file when in this status if the domain has at least one associated
name server.
REGISTRY-LOCK: The registry sets the domain to this status. The domain
cannot be modified or deleted by the registrar. The registry MUST remove
the REGISTRY-LOCK status for the registrar to modify the domain. The domain
can be renewed. The domain SHALL be included in the zone file when in this
status if the domain has at least one associated name server.
REGISTRY-HOLD: The registry sets the domain to this status. The domain
cannot be modified or deleted by the registrar. The registry MUST remove
the REGISTRY-HOLD status for the registrar to modify the domain. The domain
can be renewed. The domain SHALL NOT be included in the zone file when in
this status.
REGISTRAR-HOLD: The registrar of the domain sets the domain to this status.
The domain can not be modified or deleted when in this status. The
registrar MUST remove REGISTRAR-HOLD status to modify the domain. The
domain can be renewed. The domain SHALL NOT be included in the zone file
when in this status.
REGISTRAR-LOCK: The registrar of the domain sets the domain to this status.
The domain cannot be modified or deleted when in this status. The registrar
MUST remove REGISTRAR-LOCK status to modify the domain. The domain can be
renewed. The domain SHALL be included in the zone file when in this status.
REGISTRY-DELETE-NOTIFY: A domain is set on this status if it has expired
and has child name servers that are hosting other domains. Only the
registry may set this status. The domain SHALL be included in the zone file
when in this status if the domain has at least one associated name server.
7. Formal Syntax
The following syntax specification uses the augmented Backus-Naur Form
(BNF) as described in [ABNF].
; ABNF specification for Registry Registrar Protocol (RRP) v1.1.0
; Note that character string literals are case insensitive.
53
<PAGE>
; Lexical tokens
space = %x20 ; " "
dot = %x2E ; "."
dash = %x2D ; "-"
underscore = %x5F ; "-"
colon = %x3A ; ":"
cr = %x0D ; ASCII carriage return
lf = %x0A ; ASCII linefeed
crlf = cr lf
alpha = %x41-5A / %x61-7A ; A-Z / a-z
digit = %x30-39 ; 0-9
dns-char = alpha / digit / dash
id-char = alpha / digit / underscore / dash
id-prefix = alpha / digit
id-word = id-prefix *id-char
printable-char = %x20-7E ; ASCII " " - "~"
; Start of basic grammar.
year = 4digit
month = 2digit
day = 2digit
ymd = year dash month dash day
hour = 2digit
minute = 2digit
second = 2digit
split-second = 1digit
hms = hour colon minute colon second dot split-second
time-stamp = ymd space hms
ip-address = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit
password = 4*16printable-char
option-name = 1*128id-word
option-tag = dash option-name
option-value = 1*128id-word
attribute-name = 1*128id-word
attribute-value = 1*128printable-char
attribute-line = attribute-name colon attribute-value crlf
response = 3digit space 1*printable-char crlf
version-number = "RRP" space 1*digit dot 1*digit dot 1*digit
label = id-prefix [*61dns-char id-prefix]
sldn = label dot label
servername = *(label dot) sldn
period = %x31-39 / (%x31-39 %x30-39) ; "1" - "9" or "10" - "99"
period-option = dash "Period" colon period crlf
yesno = "Yes" / "No"
domainstatus = "Active" / "Registry-Lock" / "Registry-Hold" /
"Registrar-Lock" / "Registrar-Hold" /
"Registry-Delete-Notify"
54
<PAGE>
; RRP commands and responses.
rrp = add / check / delete / describe / mod / quit / renew /
session / status / transfer
add = add-request add-response
check = check-request check-response
delete = del-request del-response
describe = describe-request describe-response
mod = mod-request mod-response
quit = quit-request quit-response
renew = renew-request renew-response
session = session-request session-response
status = status-request status-response
transfer = transfer-request transfer-response
; ADD command.
add-request = add-domain-request / add-nameserver-request
add-response = add-domain-response / add-nameserver-response
add-domain-request = "add" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
[period-option]
0*13("NameServer" colon servername crlf)
dot crlf
add-nameserver-request = "add" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
1*("IPAddress" colon ip-address crlf)
dot crlf
add-domain-response = response
"RegistrationExpirationDate" colon time-stamp crlf
"status" colon domainstatus crlf
dot crlf
add-nameserver-response = response
dot crlf
; CHECK command.
check-request = check-domain-request / check-nameserver-request
check-response = check-domain-response / check-nameserver-response
check-domain-request = "check" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
dot crlf
check-nameserver-request = "check" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
dot crlf
check-domain-response = response
55
<PAGE>
dot crlf
check-nameserver-response = available-check-nameserver-response /
notavailable-check-nameserver-response
available-check-nameserver-response = response
dot crlf
notavailable-check-nameserver-response = response
1*("IPAddress" colon ip-address crlf)
dot crlf
; DEL command.
del-request = del-domain-request / del-nameserver-request
del-response = response
dot crlf
del-domain-request = "del" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
dot crlf
del-nameserver-request = "del" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
dot crlf
; DESCRIBE command.
describe-request = "describe" crlf
[target-option]
*(option-tag colon option-value crlf)
dot crlf
describe-response = response
"Protocol" colon version-number crlf
*attribute-line
dot crlf
target-option = dash "Target" colon "Protocol" crlf
; MOD command.
mod-request = mod-domain-request / mod-nameserver-request
mod-response = response
*attribute-line
dot crlf
mod-domain-request = "mod" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
*(add-attribute-value-line /
remove-attribute-value-line /
replace-attribute-value-line)
56
<PAGE>
dot crlf
mod-nameserver-request = "mod" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
["NewNameServer" colon attribute-value crlf]
*(add-attribute-value-line /
remove-attribute-value-line /
replace-attribute-value-line)
dot crlf
add-attribute-value-line =
attribute-name colon new-attribute-value
remove-attribute-value-line =
attribute-name colon old-attribute-value "="
replace-attribute-value-line =
attribute-name colon old-attribute-value "="
new-attribute-value
old-attribute-value = attribute-value
new-attribute-value = attribute-value
; QUIT command.
quit-request = "quit" crlf
dot crlf
quit-response = response
dot crlf
; RENEW command.
renew-request = "renew" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
[renew-period-option]
dot crlf
expiration-year-option = dash "CurrentExpirationYear" colon year crlf
renew-period-option = period-option expiration-year-option /
expiration-year-option period-option
renew-response = response
"RegistrationExpirationDate" colon time-stamp crlf
dot crlf
; SESSION command.
session-request = "session" crlf
registrar-id-option
registrar-password-option
[registrar-newpassword-option]
dot crlf
session-response = response
dot crlf
registrar-id-option = dash "Id" colon option-value crlf
registrar-password-option =
57
<PAGE>
dash "Password" colon password crlf
registrar-newpassword-option =
dash "NewPassword" colon password crlf
; STATUS command.
status-request = status-domain-request /
status-nameserver-request
status-response = response
*attribute-line
dot crlf
status-domain-request = "status" crlf
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
dot crlf
status-nameserver-request = "status" crlf
"EntityName" colon "NameServer" crlf
"NameServer" colon servername crlf
dot crlf
; TRANSFER command.
transfer-request = "transfer" crlf
[approve-option]
"EntityName" colon "Domain" crlf
"DomainName" colon sldn crlf
dot crlf
transfer-response = response
"RegistrationExpirationDate" colon time-stamp crlf
dot crlf
approve-option = dash "Approve" colon yesno crlf
; End of grammar.
8. Internationalization
RRP is defined using 7-bit US-ASCII characters. Other character sets
and character codes are not currently supported.
9. Known Issues
RRP was not designed to provide bulk data query features. The primary goal of
the original protocol designers was to provide a fast, light weight
transactional protocol that could be implemented with minimal need for
database queries that would take a "long" time to complete or that would
return a "large" amount of data. Implementers SHOULD consider developing
offline reporting features to provide bulk data for registrar reporting in a
fashion suitable for the given registry-registrar operating environment.
58
<PAGE>
This version of RRP does contain a few limitations noted over the course of
several months of operational experience with live domain name registrars.
Later versions of this protocol or its successors should strive to resolve
or address each of the following issues:
The DESCRIBE command should return information describing System-defined
default implementation values.
Use of the RENEW command without the "CurrentExpirationYear" and "Period"
parameters does not provide idempotency. Repeated execution of a RENEW
command without these parameters can result in multiple successful RENEW
commands, which may not be the desired action if a registrar is retrying a
RENEW command due to network connectivity problems.
Time stamps returned by RRP do not include time zone identifiers and SHOULD
be interpreted as local registry time.
The protocol does not provide features for a registrar to become aware of
domain transfer requests and responses. Systems must rely on means outside
of the protocol, such as electronic mail and/or registry-provided reports,
to inform registrars of transfer requests and responses.
The protocol does not provide features for a registrar to determine all of
the domains served by a name server. Systems must provide this information
using a method outside of the protocol, such as through periodic extracts
from a System database.
The protocol does not provide features to manage lame delegation of name
servers. Any registrar may "use" name servers registered by another
registrar. When a registrar tries to delete a domain or name server it is
quite possible that name servers in the domain to be deleted or the name
server to be deleted will be associated with other live domains, precluding
immediate deletion. Systems must rely on means outside of the protocol to
manage lame delegation of name servers.
The use of "=" within the MOD command to indicate a value to be removed is
somewhat confusing. A more explicit means of identifying old and new
attribute values within the protocol syntax could make this feature more
obvious.
The CHECK command also returns name server IP addresses when returning
positive confirmation of the registration of a name server. This extra
information may be useful, but it is inconsistent with the limited function
of the command. The command should return a positive or negative response
and nothing more.
59
<PAGE>
The formal protocol syntax described in this document requires a specific
order for the elements of a command entity block and command options. The
NSI Registry's server-side implementation of the protocol provides the
additional flexibility of allowing order independent specification of
options and entity block elements. Client-side implementers are strongly
urged to observe the order of command elements as specified here to ensure
compliance if the more restricted form is enforced in the future.
RRP does not return time stamps or transaction identifiers to track
transactions. The NSI Registry provides registrars with daily and weekly
reports that include time stamps in local registry time to document and
synchronize data on a per-registrar basis.
10. Security Considerations
Misuse of the Registry Registrar Protocol can have catastrophic operational
consequences for registrants, registrars, and registries. As such, all
registrars must be authenticated prior to all interactions with the
registry. In addition, all data exchanged between the registrar and the
registry must be protected to avoid unintended disclosure of information.
11. IANA Considerations
IANA assigned TCP port 648 for RRP use in November 1998. No other action is
required of IANA to support operation of this protocol.
IANA has reserved certain IPv4 address ranges as described in [ALLOCATION].
Implementers MUST ensure that name server IP addresses do not fall into one
of the reserved address ranges to avoid operational DNS errors.
12. References
[ABNF] Crocker, D. (Editor) and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, November 1997.
[ALLOCATION] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J.
Postel, "Internet Registry IP Allocation Guidelines", BCP 12,
RFC 2050, November 1996.
[MUSTSHOULD] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
60
<PAGE>
[SSL] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol",
Netscape Communications Corp., November 18, 1996.
[TLS] Dierks T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
January 1999.
13. Acknowledgments
Many people have contributed significantly to this document and the
protocol it describes. Brad McMillen and Neeran Saraf deserve special
mention as co-authors of an earlier internal protocol specification. Other
content contributors to the earlier internal specification include
Aristotle Balogh, Chris Bason, Mark Kosters, Jasdip Singh, and Yibing Wu.
Finally, significant contributors to the review of this document include
Steve Mahlstedt and Chris Smith.
14. Authors' Addresses
Scott Hollenbeck
Network Solutions, Inc. Registry
505 Huntmar Park Dr.
Herndon, VA 20170
USA
EMail: [email protected]
Manoj Srivastava
Network Solutions, Inc. Registry
505 Huntmar Park Dr.
Herndon, VA 20170
USA
EMail: [email protected]
61
<PAGE>
15. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist in
its implementation may be prepared, copied, published and distributed, in
whole or in part, without restriction of any kind, provided that the above
copyright notice and this paragraph are included on all such copies and
derivative works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed, or
as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked
by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY
RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet
Society.
62
<PAGE>
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 a minimum of one year or in multiples of one-year increments 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 in
multiples of one-year increments, provided that the maximum unexpired (i.e. into
the future) term of the registration of an unexpired name shall not exceed ten
years.
c. Upon change of sponsorship of the registration of a Registered Name from
one registrar to another, according to Part A of Exhibit B to Appendix F of the
registry agreement, the term of registration of the Registered Name shall be
extended by one year, provided that the maximum unexpired (i.e. into the future)
term of the registration of an unexpired name 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 Exhibit B to Appendix F of the
registry agreement shall not result in the extension of the term of the
registrations.
63
<PAGE>
3. Grace period policy
-------------------
1. Introduction
This document describes VeriSign Global Registry Services (VGRS) 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
the domain may be deleted 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 RENEW command
or by auto-renewal; registration is accomplished using the RRP ADD command;
deletion/removal is accomplished using the RRP DEL command; and transfer is
accomplished using the RRP TRANSFER command or, where ICANN approves a bulk
transfer under Part B of Exhibit B to the Registry-Registrar Agreement, using
the procedures specified in that Part.
There are four grace periods provided by the VGRS Shared Registration System:
Add Grace Period, Renew/Extend Grace Period, Auto-Renew Grace Period, and
Transfer 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, and
. Deletion of an existing domain.
2. Grace Periods
2.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 Command Renew),
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.
64
<PAGE>
The domain is deleted from the Registry database and is immediately
available for registration by any Registrar. See Section 3 for a
description of overlapping grace period exceptions.
Extend (RRP Command "Renew"). If a domain is extended within the Add Grace
Period, there is no credit for the add. The account of the sponsoring
Registrar at the time of the extension will be charged for the initial add
plus the number of years the registration is extended. The expiration date
of the domain 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 Exhibit B to the Registry-Registrar Agreement 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 currently 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 Exhibit B to the Registry-Registrar Agreement. The expiration dates of
transferred registrations are not affected. The losing Registrar's account
is charged for the initial add.
2.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 is deleted from the Registry database and is
immediately available for registration by any Registrar. See Section 3 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 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.
65
<PAGE>
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 Exhibit B to the Registry-Registrar Agreement. The expiration
dates of transferred registrations are not affected. The losing Registrar's
account is charged for the Renew/Extend operation.
2.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 is deleted from the Registry database and is
immediately available for registration by any Registrar. See Section 3 for
a description of overlapping grace period exceptions.
Extend (RRP Command "Renew"). 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 under Part A of Exhibit B to the Registry-Registrar Agreement
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 by virtue of the transfer 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 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 Exhibit B to the Registry-Registrar Agreement. The expiration
dates of transferred registrations are not affected. The losing Registrar's
account is charged for the Auto-Renew.
2.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 Exhibit B to the Registry-Registrar
Agreement. The
66
<PAGE>
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 is deleted from the Registry database and
is immediately available for registration by any Registrar. See
Section 3 for a description of overlapping grace period exceptions.
Extend (RRP Command "Renew"). If a domain 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 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 is extended by one year up to a maximum
term of ten years.
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 Exhibit B to the Registry-Registrar Agreement.
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.
2.5 Bulk Transfer Grace Period
There is no grace period associated with Bulk Transfer operations according to
Part B of Exhibit B to the Registry-Registrar Agreement. Upon completion of the
Bulk Transfer, any associated fee is not refundable.
3. 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 the Auto-Renew and
the number of years for the extension.
3.1 Overlap Exception
67
<PAGE>
. If a domain is deleted within one or several Transfer Grace Periods, then
only the current sponsoring Registrar is credited for the transfer amount.
For example if a domain is transferred from Registrar A to Registrar B and
then to Registrar C and finally deleted by Registrar C within the Transfer
Grace Period of the first, second and third transfers, then only the last
transfer is credited to Registrar C.
. If a domain is extended (through the RRP command "Renew") 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 transfers, 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.
4. Pending Periods
4.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 TRANSFER request or RRP RENEW request is denied.
b. AUTO-RENEW is allowed.
c. RRP DELETE request is denied.
d. Bulk Transfer operations are allowed.
4.2 Delete Pending Period
The Delete Pending Period is a specified number of calendar days following a
request to delete a domain in which the domain is placed in REGISTRY-HOLD status
without removing the domain from the Registry database. The current value of the
Delete Pending Period for all registrars is five calendar days. Registrars may
request retraction of a Delete request by calling the VGRS Customer Support
staff within the Delete Pending Period. Retraction requests processed during the
Delete Pending Period will be at no cost to the registrar. If no action is taken
within the Delete Pending Period, the domain will be deleted from the Registry
database and returned to the pool of domain names available for registration by
any Registrar. During the Delete Pending Period:
a. RRP RENEW or AUTO-RENEW request is ignored.
b. RRP TRANSFER request is denied.
68
<PAGE>
c. Bulk Transfer operations are allowed.
69
<PAGE>
4. Nameserver functional specifications
------------------------------------
Nameserver operations for the Registry TLD shall comply with RFC 1034, 1035,
and 2182.
70
<PAGE>
5. Patch, update, and upgrade policy
---------------------------------
VeriSign Global Registry Services (VGRS) may issue periodic patches, updates or
upgrades to the Software, RRP 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 C, the following terms have the associated
meanings set forth herein. (1) A "Patch" means minor modifications to the
Licensed Product made by VGRS 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.
VGRS, in its sole discretion, will deploy Patches during scheduled and announced
Shared Registration System maintenance periods.
For Updates and Upgrades, VGRS will give each registrar notice prior to
deploying the Updates and Upgrades into the production environment. The notice
shall be at least sixty (60) days, except that if ICANN's registry agreements
with all other unsponsored TLDs provide that the operators of those TLDs will
provide at least ninety (90) days' notice, then VGRS will provide at least
ninety (90) days' notice. Such notice (whether 60 or 90 days) will include an
initial thirty (30) days' 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. VGRS 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.
71
<PAGE>
6. Migration to provreg standard
VeriSign Global Registry Services (VGRS) is committed to participating in and
supporting the work of the IETF's provreg working group. VeriSign intends to
migrate the current Shared Registration System to the new standard if: (1) The
IETF working group defines a protocol standard; (2) the standard can be
implemented in a way that minimizes disruption to customers; and (3) the
standard provides a solution for which the potential advantages are reasonably
justifiable when weighed against the costs that VGRS and its registrar customers
would incur in implementing the new standard.
72
<PAGE>
Appendix D
----------
Performance Specifications
Monthly Metric Requirement
--------------------------------------------------------------------------------
Total outage 8 hours
--------------------------------------------------------------------------------
Unplanned outage 4 hours
--------------------------------------------------------------------------------
Major upgrade outage 12 hours
--------------------------------------------------------------------------------
Check domain average 3 seconds
--------------------------------------------------------------------------------
Add domain average 5 seconds
--------------------------------------------------------------------------------
Notes
. Two "Major Upgrades" per year are allowed, each of which may last 12
hours.
. Registry Operator and ICANN will discuss in good faith addition of
appropriate metrics for nameserver packet loss and round-trip times.
73
<PAGE>
Appendix E
----------
Service Level Agreement (SLA)
The VeriSign, Inc. ("VeriSign") Registry 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 VeriSign Registry and to provide
accredited and licensed Registrars with credits for certain substandard
performance by the VeriSign Registry under the parties' Registrar License and
Agreement.
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 the VeriSign Registry, 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 VeriSign 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 the VeriSign Registry's 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")
session command.
b) execute a 3 second average round trip for 95% of the RRP check domain
commands and/or less than 5 second average round trip for 95% of the
RRP add 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 the VeriSign Registry in response to a Registrar's
claim of SRS Unavailability for that Registrar through the time
when the Registrar and VeriSign Registry agree the SRS
Unavailability has been resolved with a final fix or a temporary
work around,
74
<PAGE>
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 the VeriSign Registry in the event of SRS
Unavailability that affects all Registrars through the time when
the Registry 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 VeriSign Registry 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 the
VeriSign Registry customer service help desk in the manner required by the
VeriSign Registry (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, the
VeriSign Registry is responsible for opening a blanket trouble ticket and
immediately notifying all Registrars of the trouble ticket number and
details.
3) Both Registrar and the VeriSign Registry 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 VeriSign Registry
problem, the issue will become part of the Unplanned Outage Time.
4) VeriSign Registry 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 commands can be successfully completed.
5) Registrar must inform the VeriSign Registry 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 VeriSign Registry 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 the VeriSign Registry for all Registrars for that month exceed
the VeriSign Registry's 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, the VeriSign Registry agrees
75
<PAGE>
to provide monthly transaction summary reports.
6) The VeriSign Registry will notify Registrar of Planned Outages outside
the Planned Outage Period at least 7 days in advance of such Planned
Outage. In addition, VeriSign Registry will use reasonable commercial
good faith efforts to maintain an accurate 30-day advance schedule of
possible upcoming Planned Outages.
7) The VeriSign Registry will update the WHOIS Service once per day
beginning at 1200 GMT. The VeriSign Registry will notify Registrars in
advance when changes to the WHOIS Service update schedule occur.
8) The VeriSign Registry will allow external monitoring of the SRS via an
acceptable means to both parties.
9) The VeriSign Registry will initiate the Registry zone file transfer
process twice daily at 1000 GMT and 2200 GMT. The VeriSign Registry
will notify Registrar in advance when changes to the schedule occur.
The VeriSign Registry will notify Registrars regarding any scheduled
maintenance and unavailability of the GTLD ROOT-SERVERs.
10) The VeriSign Registry 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) The VeriSign Registry will publish weekly system performance and
availability reports. These reports will include average round trip
for the RRP Check and RRP Add Domain commands for all Registrars as
well as a summary of SRS Availability for the previous week
12) The VeriSign Registry 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, the
VeriSign Registry 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 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,
VeriSign Registry 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
76
<PAGE>
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.
77
<PAGE>
Appendix F
----------
Registry-Registrar Agreement
Note: The notice period in Section 3.3 shall be ninety (90) days only if a
notice period for implementation of material changes to the Registry-Registrar
Protocol, Application Program Interfaces, or reference client software applies
to all unsponsored TLDs under Registry Agreement with ICANN. Otherwise, the
notice period of Section 3.3 shall be sixty (60) days.
*******************************************************************************
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 ("VGRS"), and _________________, a _____________________ corporation, with
its principal place of business located at ___________________________________
("Registrar"). VeriSign 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 VGRS 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, VGRS 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 VGRS 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
78
<PAGE>
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 VGRS 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 RRP, APIs, and software, collectively.
2. OBLIGATIONS OF THE PARTIES
--------------------------
2.1. System Operation and Access. Throughout the Term of this Agreement, VGRS
---------------------------
shall operate the System and provide Registrar with access to the System
enabling Registrar to transmit domain name registration information for the
Registry TLD to the System according to a protocol developed by VGRS and known
as the Registry Registrar Protocol ("RRP").
2.2. Distribution of RRP, APIs and Software. No later than three business days
--------------------------------------
after the Effective Date of this Agreement, VGRS shall provide to Registrar (i)
full documentation of the RRP, (ii) "C" and "Java" application program
interfaces ("APIs") to the RRP with documentation, and (iii) reference client
software ("Software") that will enable Registrar to develop its system to
register second-level domain names through the System for the Registry TLD. If
VGRS elects to modify or upgrade the APIs and/or RRP, VGRS shall provide updated
APIs to the RRP 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 of all Registered
----------------------------
Name registrations in the Registry TLD during the Term of this Agreement,
Registrar shall submit the following data elements using the RRP concerning
Registered Name registrations it processes:
2.4.1. The Registered Name being registered;
2.4.2. The IP addresses of the primary nameserver and secondary
nameserver(s) for the Registered Name;
2.4.3. The corresponding host names of those nameservers;
79
<PAGE>
2.4.4. Unless automatically generated by the registry system, the
identity of the registrar;
2.4.5. Unless automatically generated by the registry system, the
expiration date of the registration; and
2.4.6. Other data required as a result of further development of the
registry system by the Registry.
2.5. License. Registrar grants VGRS as Registry a non-exclusive non-transferable
-------
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.
2.6. Registrar's Registration Agreement and Domain Name Dispute Policy.
-----------------------------------------------------------------
Registrar shall have developed and employ in its domain name registration
business an electronic or paper registration agreement, including a domain name
dispute policy, a copy of which is attached to this Agreement as Exhibit A
(which may be amended from time to time by Registrar, provided a copy is
furnished to VGRS three (3) business days in advance of any such amendment), to
be entered into by Registrar with each Registered Name holder as a condition of
registration. Registrar shall include terms in its agreement with each
Registered Name holder that are consistent with Registrar's duties to VGRS
hereunder.
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 session shall be authenticated and encrypted
using two-way secure socket layer ("SSL") protocol. Registrar agrees to
authenticate every RRP 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.8. Domain Name Lookup Capability. Registrar agrees to employ in its domain
-----------------------------
name registration business VGRS'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 Sponsorship of
Registrations Between Registrars appended hereto as Exhibit B.
80
<PAGE>
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 VGRS records shall control.
2.11. Compliance with Terms and Conditions. Registrar agrees to comply with all
------------------------------------
other reasonable terms or conditions established from time to time, to assure
sound operation of the System, by VGRS in a non-arbitrary manner and applicable
to all registrars, including affiliates of VGRS, and consistent with VGRS's
Cooperative Agreement with the United States Government or VGRS's Registry
Agreement with ICANN, as applicable, upon VGRS'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 RRP and the APIs in conjunction with Registrar's systems. Registrar agrees
that in the event of significant degradation of the System or other emergency,
VGRS may, in its sole discretion, temporarily suspend access to the System. Such
temporary suspensions shall be applied in a nonarbitrary manner and shall apply
fairly to any registrar similarly situated, including affiliates of VGRS.
2.13. Surety Instrument. During the Initial Term and any Renewal Terms,
-----------------
Registrar shall have in place a performance bond, letter of credit or equivalent
instrument (the "Surety Instrument") from a surety acceptable to VGRS, in the
amount of $100,000 U.S. dollars. (A single such Surety Instrument shall satisfy
this obligation and Registrar's obligations under similar provisions of other
Registry-Registrar Agreements between Registrar and VGRS.) The terms of the
Surety Instrument shall indemnify and hold harmless VGRS and its employees,
directors, officers, representatives, agents and affiliates from all costs and
damages (including reasonable attorneys' fees) which it may suffer by reason of
Registrar's failure to indemnify VGRS as provided in Section 6.16 by making
payment(s) up to the full amount of the bond within ten (10) days of VGRS's
having notified the surety of its claim(s) of damages, having identified the
basis for any such claim. VGRS shall not be entitled to payment under the Surety
Instrument until such time as it has certified that it has incurred expenses for
which it is entitled to reimbursement in accordance with the provisions of
Section 6.16 of this Agreement.
2.14. Prohibited Domain Name Registrations. Registrar agrees to comply with the
------------------------------------
policies of VGRS that will be applicable to all registrars and that will
prohibit the registration of certain domain names in the Registry TLD which are
not allowed to be registered by statute or regulation.
2.15. Indemnification Required of Registered Name Holders. Registrar shall
---------------------------------------------------
require each Registered Name holder to indemnify, defend and hold harmless VGRS,
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.
81
<PAGE>
3. LICENSE
-------
3.1. License Grant. Subject to the terms and conditions of this Agreement, VGRS
-------------
hereby grants Registrar and Registrar accepts a non-exclusive, non-transferable,
worldwide limited license to use for the Term and purposes of this Agreement the
RRP, APIs and Software, as well as updates and redesigns thereof, to provide
domain name registration services in the Registry TLD only and for no other
purpose. The RRP, APIs and Software, 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 RRP,
APIs and Software, 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 VGRS, Registrar shall not: (i) sublicense the
RRP, APIs or Software or otherwise permit any use of the RRP, APIs or Software
by or for the benefit of any party other than Registrar, (ii) publish,
distribute or permit disclosure of the RRP, APIs or Software 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 RRP, APIs or Software for any unauthorized purpose, or (iv) use or
permit use of the RRP, APIs or Software 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 Registry Operator or any ICANN-Accredited
Registrar, except as reasonably necessary to register domain names or modify
existing registrations.
3.3. Changes to Licensed Materials. VGRS may from time to time make
-----------------------------
modifications to the RRP, APIs or Software licensed hereunder that will enhance
functionality or otherwise improve the System. VGRS will provide Registrar with
at least ninety (90) days notice prior to the implementation of any material
changes to the RRP, APIs or software licensed hereunder.
4. SUPPORT SERVICES
----------------
82
<PAGE>
4.1. Engineering Support. VGRS agrees to provide Registrar with reasonable
-------------------
engineering telephone support (between the hours of 9 a.m. to 5 p.m. local
Herndon, Virginia time 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, VGRS will
------------------------
provide reasonable telephone and e-mail customer service support to Registrar,
not Registered Name holders or prospective customers of Registrar, for non-
technical issues solely relating to the System and its operation. VGRS will
provide Registrar with a telephone number and e-mail address for such support
during implementation of the RRP, APIs and Software. First-level telephone
support will be available on a 7-day/24-hour basis. VGRS 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 VGRS the non-refundable amounts of US$ 6 for
each annual increment of an initial domain name registration and US$ 6
for each annual increment of a domain name re-registration (collectively,
the "Registration Fees") registered by Registrar through the System.
(b) VGRS reserves the right to adjust the Registration Fees prospectively
upon thirty (30) days prior notice to Registrar, provided that such
adjustments are consistent with VGRS's Cooperative Agreement with the
United States Government or its Registry Agreement with ICANN, as
applicable, and are applicable to all registrars in the Registry TLD.
VGRS will invoice Registrar monthly in arrears for each month's
Registration Fees. All Registration Fees are due immediately upon receipt
of VGRS's invoice pursuant to a letter of credit, deposit account, or
other acceptable credit terms agreed by the Parties.
5.2. Change in Registrar Sponsoring Domain Name. Registrar may assume
------------------------------------------
sponsorship of an Registered Name holder's existing domain name registration
from another registrar by following the policy set forth in Exhibit B to this
Agreement.
(a) For each transfer of the sponsorship of a domain-name registration
under Part A of Exhibit B, Registrar agrees to pay VGRS 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 Exhibit B, Registrar
agrees to pay VGRS US$ 0 (for transfers of 50,000 names or fewer) or US$
50,000 (for transfers of more than 50,000 names).
83
<PAGE>
Fees under this Section 5.2 shall be due immediately upon receipt of VGRS's
invoice pursuant to a letter of credit, deposit account, or other acceptable
credit terms agreed by the Parties.
5.3. Pro-Rata Charges for ICANN Fees. Registrar agrees to pay to VGRS, within
-------------------------------
ten (10) days of VGRS's invoice, a portion of any variable registry-level fees
paid by VGRS to ICANN, pro-rated among all registrars sponsoring registrations
in the Registry TLD based on their relative numbers of domain-name registrations
sponsored.
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, VGRS
may stop accepting new registrations and/or delete the domain names associated
with invoices not paid in full from the Registry database and give written
notice of termination of this Agreement pursuant to Section 6.1(b) below.
6. MISCELLANEOUS
-------------
6.1. Term of Agreement and Termination.
---------------------------------
(a) Term of the Agreement. The duties and obligations of the Parties
----------------------
under 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 VGRS ceases to operate the registry for the Registry
TLD. In the event that revisions to VGRS's Registry-Registrar
Agreement are approved or adopted by the U.S. Department of Commerce,
or ICANN, as appropriate, Registrar will execute an amendment
substituting the revised agreement in place of this Agreement, or
Registrar may, at its option exercised within fifteen (15) days,
terminate this Agreement immediately by giving written notice to
VGRS.
(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 non-breaching
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 VGRS 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.
84
<PAGE>
(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, VGRS 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 VGRS 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 Exhibit B, Part B, or any other procedures established or
approved by the U.S. Department of Commerce or ICANN, as appropriate, and
(ii) either return to VGRS or certify to VGRS 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, 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 VGRS, as stated in
Section 2.15; (iii) the surety's obligations under the Surety Instrument
described in Section 2.13 with respect to matters arising during the term
of this Agreement; and (iv) 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
85
<PAGE>
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. Any amendment or supplement to this Agreement shall
--------------------
be in writing and duly executed by both Parties.
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:
__________________________________________
__________________________________________
__________________________________________
__________________________________________
86
<PAGE>
__________________________________________
__________________________________________
with a copy to:
__________________________________________
__________________________________________
__________________________________________
__________________________________________
__________________________________________
__________________________________________
if to VGRS:
General Counsel
VeriSign, Inc.
1350 Charleston Road
Mountain View, California 94043
Telephone: 1/650/961/7500
Facsimile:1/650/961/8853; and
Business Affairs Office
VeriSign Registry
21345 Ridgetop Circle
Dulles, Virginia 20166
Telephone: 1/703/948/3200
Facsimile: 1/703/421/2129; and
Deputy General Counsel
VeriSign, Inc.
505 Huntmar Park Drive
Herndon, Virginia 20170
Telephone: 1/703/742/0400
Facsimile: 1/703/742/7916
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 VGRS.
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 VGRS.
87
<PAGE>
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 VGRS 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 VGRS 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) VGRS. VGRS 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
88
<PAGE>
and delivery of this Agreement has been duly authorized by VGRS, and (4)
no further approval, authorization or consent of any governmental or
regulatory authority is required to be obtained or made by VGRS in order
for it to enter into and perform its obligations under this Agreement.
(c) Disclaimer of Warranties. The RRP, APIs and Software are provided
------------------------
"as-is" and without any warranty of any kind. VGRS 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. VGRS 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, VGRS 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 VGRS under this paragraph, will indemnify, defend
and hold harmless VGRS and its employees, directors, officers, representatives,
agents and affiliates, against any claim, suit, action, or other proceeding
brought against VGRS or any affiliate of VGRS 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) VGRS provides Registrar with prompt notice of any such claim, and
(b) upon Registrar's written request, VGRS will provide to Registrar all
available information and assistance reasonably necessary for Registrar to
defend such claim, provided that Registrar reimburses VGRS for its actual and
reasonable costs. Registrar will not enter into any settlement or compromise of
any such indemnifiable claim without VGRS'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 VGRS 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, and C, constitutes the entire agreement between the Parties concerning the
subject
89
<PAGE>
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.
IN WITNESS WHEREOF, the Parties hereto have executed this Agreement as of the
date set forth in the first paragraph hereof.
VeriSign, Inc. [Registrar]
By:_________________________ By:_________________________
Name:_______________________ Name:_______________________
Title:______________________ Title:______________________
90
<PAGE>
Exhibit A
---------
Registrar's Dispute Policy
[To be supplied from time to time by Registrar]
91
<PAGE>
Exhibit B
---------
Policy on Transfer of Sponsorship of Registrations Between Registrars
A. Holder-Authorized Transfers.
---------------------------
Registrar Requirements.
The registration agreement between each Registrar and its Registered Name holder
shall include a provision explaining that a Registered Name holder will be
prohibited from changing its Registrar during the first 60 days after initial
registration of the domain name with the Registrar. Beginning on the 61st day
after the initial registration with the Registrar, the procedures for change in
sponsoring registrar set forth in this policy shall apply. Enforcement shall be
the responsibility of the Registrar sponsoring the domain name registration.
For each instance where an Registered Name holder wants to change its Registrar
for an existing domain name (i.e., a domain name that appears in a particular
top-level domain zone file), the gaining Registrar shall:
1) Obtain express authorization from an individual who has the apparent
authority to legally bind the Registered Name holder (as reflected in the
database of the losing Registrar).
a) The form of the authorization is at the discretion of each gaining
Registrar.
b) The gaining Registrar shall retain a record of reliable evidence of
the authorization.
2) In those instances when the Registrar of record is being changed
simultaneously with a transfer of a domain name from one party to another,
the gaining Registrar shall also obtain appropriate authorization for the
transfer. Such authorization shall include, but not be limited to, one of
the following:
a) A bilateral agreement between the parties.
b) The final determination of a binding dispute resolution body.
c) A court order.
3) Request, by the transmission of a "transfer" command as specified in the
Registry Registrar Protocol, that the Registry database be changed to
reflect the new Registrar.
a) Transmission of a "transfer" command constitutes a representation
on the part of the gaining Registrar that:
92
<PAGE>
(1) the requisite authorization has been obtained from the
Registered Name holder listed in the database of the losing
Registrar, and
(2) the losing Registrar will be provided with a copy of the
authorization if and when requested.
In those instances when the Registrar of record denies the requested change of
Registrar, the Registrar of record shall notify the prospective gaining
Registrar that the request was denied and the reason for the denial.
Instances when the requested change of sponsoring Registrar may be denied
include, but are not limited to:
1) Situations described in the Domain Name Dispute Resolution Policy
2) A pending bankruptcy of the Registered Name holder
3) Dispute over the identity of the Registered Name holder
4) Request to transfer sponsorship occurs within the first 60 days after
the initial registration with the Registrar
In all cases, the losing Registrar shall respond to the e-mail notice regarding
the "transfer" request within five (5) days. Failure to respond will result in a
default "approval" of the "transfer."
Registry Requirements.
Upon receipt of the "transfer" command from the gaining Registrar, VGRS will
transmit an e-mail notification to both Registrars.
VGRS shall complete the "transfer" if either:
1) the losing Registrar expressly "approves" the request, or
2) VGRS does not receive a response from the losing Registrar within five
(5) days.
When the Registry's database has been updated to reflect the change to the
gaining Registrar, VGRS will transmit an email notification to both Registrars.
Records of Registration.
Each Registered Name holder shall maintain its own records appropriate to
document and prove the initial domain name registration date, regardless of the
number of
93
<PAGE>
Registrars with which the Registered Name holder enters into a contract for
registration services.
Effect on Term of Registration.
The completion by VGRS of a holder-authorized transfer under this Part A shall
result in a one-year extension of the existing registration, provided that in no
event shall the total unexpired term of a registration exceed ten (10) years.
B. ICANN-Approved Transfers.
------------------------
Transfer of the sponsorship of all the registrations sponsored by one registrar
as the result of acquisition of that registrar or its assets by another
registrar may be made according to the following procedure:
(a) The gaining registrar must be accredited by ICANN for the Registry TLD
and must have in effect a Registry-Registrar Agreement with VGRS for the
Registry TLD.
(b) ICANN must certify in writing to VGRS that the transfer would promote
the community interest, such as the interest in stability that may be
threatened by the actual or imminent business failure of a registrar.
Upon satisfaction of these two conditions, VGRS will make the necessary one-time
changes in the registry database for no charge, for transfers involving 50,000
name registrations or fewer. If the transfer involves registrations of more than
50,000 names, VGRS will charge the gaining registrar a one-time flat fee of US$
50,000.
94
<PAGE>
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 ("VGRS"), 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
95
<PAGE>
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
VGRS 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
96
<PAGE>
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 VGRS 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.
97
<PAGE>
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 VGRS and Registrar have executed this Confidentiality
Agreement in Virginia on the dates indicated below.
("Registrar") VeriSign, Inc. ("VGRS")
By: By: __________________________
___________________________ Title:________________________
Title: Date:_________________________
___________________________
Date:_________________________
98
<PAGE>
Appendix G
----------
Registry Operator Maximum Price Schedule
This schedule specifies the maximum price Registry Operator may charge for
Registry Services. In a manner consistent with Subsection 22(B) of the Registry
Agreement, Registry Operator may charge a lower-than-specified rate for
services, including not charging for a specified service. Except as set forth
herein or otherwise agreed, Registry Operator shall not be entitled to charge
for any Registry Service not specified in this Appendix G.
1. Maximum Initial Registration Fee for Registered Names
Registry Operator may charge a maximum of US $6.00 per year for registration of
each Registered Name (the "Initial Registration Fee") in the Registry TLD.
2. Maximum Renewal Registration Fee for Registered Names
Registry Operator may charge a maximum of US $6.00 per year for renewal (or
extension) of registration of each Registered Name (the "Renewal Fee") in the
Registry TLD.
3. Fees for Transfers of Sponsorship of Domain-Name Registrations
Registrars may assume sponsorship of a Registered Name holder's existing domain
name registration from another registrar by following the policy set forth in
Exhibit B to Appendix F to the Registry Agreement.
For each transfer of the sponsorship of a domain-name registration under Part A
of Exhibit B, Registry Operator may charge the gaining registrar a maximum fee
equal to the renewal registration fee associated with a one-year extension, as
set forth in item 2 above. The losing registrar's registration fees will not be
refunded as a result of any such transfer.
For a transfer approved by ICANN under Part B of Exhibit B, Registry Operator
may charge the gaining registrar US$ 0 (for transfers of 50,000 names or fewer)
or US$ 50,000 (for transfers of more than 50,000 names).
99
<PAGE>
Appendix H
----------
VeriSign Equivalent Access Certification
VeriSign, as Registry Operator ("VGRS"), makes the following certification:
1. All registrars (including any registrar affiliated with VGRS)
connect to the Shared Registration System Gateway via the
Internet by utilizing the same maximum number of IP addresses and
SSL certificate authentication.
2. VGRS 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.
3. All registrars have the same level of access to VGRS customer
support personnel via telephone, e-mail and the VGRS website.
4. All registrars have the same level of access to the VGRS registry
resources to resolve registry/registrar or registrar/registrar
disputes and technical and/or administrative customer service
issues.
5. All registrars have the same level of access to VGRS-generated
data to reconcile their registration activities from VGRS Web and
ftp servers.
6. All registrars may perform basic automated registrar account
management functions using the same registrar tool made available
to all registrars by VGRS.
7. The Shared Registration System does not include any algorithms or
protocols that differentiate among registrars with respect to
functionality, including database access, system priorities and
overall performance.
8. All VGRS-assigned personnel have been directed not to give
preferential treatment to any particular registrar.
9. I have taken reasonable steps to verify that the foregoing
representations are being complied with.
This Certification is dated this the __ day of __________, _____.
VeriSign, Inc.
By: __________________________
Name: Bruce Chovnick
Title: General Manager, VeriSign Global Registry Services
100
<PAGE>
VeriSign Global Registry Services (VGRS)
Organizational Conflict of Interest Compliance Plan
VGRS has implemented the following organizational, physical and procedural
safeguards to ensure that revenues and assets of VGRS are not utilized to
advantage the registrar business of companies affiliated with VGRS to the
detriment of other competing registrars with regard to Registry Services
provided for the .com, .net, and .org TLDs. VGRS recognizes the potential for
organizational conflicts of interest ("OCI") between its Registry Services
business and the ICANN-accredited Registrar business associated with VeriSign
and has placed these generally accepted, US Government recognized safeguards in
place to avoid operational issues.
I. VGRS ORGANIZATIONAL STRUCTURE
In recognition of potential OCI, VeriSign, Inc. established organization
barriers by separating VeriSign's registry business and its registrar business
into separate profit and loss ("P&L") centers, each with its own General
Manager. Each General Manager reports directly to separate division heads who in
turn report directly to the Chief Executive Officer of VeriSign and has
dedicated direct reporting employees in the finance, marketing, engineering,
customer affairs and customer service functions, as appropriate. Each P&L
employee is dedicated to the line of business for which he/she directly works.
The corporate administrative support functions under the Chief Financial
Officer, Customer Experience Officer, Communications Officer, Business and
Corporate Development Officer and Chief Strategy Officer provide support to each
line of business on a cost allocated basis or a dedicated project accounting
basis. These officers and the Chief Executive Officer will be compensated based
on consolidated financial results, versus Registrar or Registry results.
The VGRS General Manager has authority over all operational decisions and is the
business owner of this compliance plan. VGRS employs a Compliance Officer to
administer day-to-day oversight and administration of this plan.
The VeriSign, Inc. General Counsel's office employs an overall OCI compliance
function to oversee corporate adherence to the Plan and to resolve potential
conflicts or actual conflicts among VeriSign functions.
II. FINANCIAL SEPARATION
The registry business accounts for its own costs, revenues, cash flow, etc. as a
separate P&L center, using separate and distinct systems and accounting
functions. Reasonable and independently auditable internal accounting controls
are in place to ensure the adequacy of these systems and functions. The
individual financial statements of each P&L center are then consolidated at the
corporate level for tax and SEC reporting.
101
<PAGE>
III. LOCATION CHANGE
To further separate businesses and, among other things, ensure that the risk of
inadvertent disclosure of sensitive information is effectively mitigated,
VeriSign's Registry and Registrar businesses are located in separate facilities.
IV. PHYSICAL BARRIERS
Each VeriSign business unit employee has a security badge that will provide
him/her access only to the facility he/she works in and the VeriSign
headquarters facilities. At the VGRS facility, only registry-assigned personnel
("Registry Personnel") and other personnel who are identified to have a
legitimate need for access (excluding "Registrar Personnel") will have regular
badge access to the premises and any other person will be treated as a visitor
to the facility and will gain access only through established visitor sign-in
and identification badge procedures.
V. ACCESS TO THE REGISTRY FACILITY
VGRS provides access to all VGRS customers through the following mechanisms and
separates VGRS systems and information from systems and information of any
affiliated registrar through these processes:
1. All registrars (including any registrar affiliated with VGRS) connect
to the Shared Registration System Gateway via the Internet by
utilizing the same maximum number of IP addresses and SSL certificate
authentication.
2. All registrars have the same level of access to VGRS-generated data to
reconcile their registration activities from VGRS Web and ftp servers.
All registrars may perform basic automated registrar account
management functions using the same registrar tool made available to
all registrars by VGRS.
3. The Shared Registration System does not include any algorithms or
protocols that differentiate among registrars with respect to
functionality, including database access, system priorities and
overall performance.
4. No registrar affiliated with VGRS will be given any access to the
registry not available to any other registrar except with regard to
information specific to their registrar.
5. Any information needed by registrars regarding the technical interface
of registry/registrar operations will be made equally available to all
registrars.
VI. INFORMATION CONTROL
102
<PAGE>
VGRS has in place various procedural safeguards to ensure that data and
information of the registry business are not utilized to advantage the business
of any registrar affiliated with VGRS. VGRS has adopted a policy regarding the
marking, access and dissemination of business sensitive information (Exhibit A).
This policy requires employees to mark all Registry sensitive information as
"Registry Sensitive." Furthermore, the policy requires that all sensitive
information be limited in access and disseminated only to those VGRS Personnel
and other personnel who are identified to have a legitimate "need to know,"
which shall not include personnel assigned by any registrar affiliated with
VGRS. The Registry General Manager maintains a matrix that dictates who can
access particular categories of Registry Sensitive information. All sensitive
information is secured in an appropriate manner to ensure confidentiality and
security. Consent of the Registry General Manager is required prior to release
of financial or statistical information relating to the registry business.
VII. TRAINING
All VGRS Personnel and other employees who have a need to know Registry business
undergo a formal OCI Training Program, developed by the Registry Compliance
Officer, providing the staff members with a clear understanding of this Plan and
the staff members' responsibility under the plan. OCI training is required
before any potential staff member is given an assignment or access to Registry
Sensitive material. OCI refresher training is given on an annual basis.
VIII. NON-DISCLOSURE AGREEMENTS/OCI AVOIDANCE CERTIFICATIONS
Upon completion of the training program, all VGRS Personnel and other employees
who have a need to know registry business (which shall not include personnel
assigned by any registrar affiliated with VGRS), are required to sign a non-
disclosure agreement and a Registry Business OCI Avoidance Certification
acknowledging his/her understanding of the OCI requirements, and certifying that
he/she will strictly comply with the provisions of the OCI Plan. Examples of the
agreement and certification are attached as Exhibits B and C. The signed
agreements are maintained in the program files and the individual's personnel
file. Each staff member acknowledges verification of the annual refresher
training required by this Plan.
103
<PAGE>
Exhibit A
Access and Dissemination of Proprietary Information
Introduction
The purpose of this "Use of Proprietary Information" is to protect
Sensitive Information of the Registry Business to ensure that the revenue
and assets of the Registry Business are not utilized to advantage the
Registrar Business to the detriment of other competing registrars. This
document is also designed to establish policies for the protection of
Proprietary Information developed by and/or in the possession of VeriSign,
Inc. ("VeriSign"). This policy is applicable to all employees of VeriSign.
Definitions:
Proprietary Information. Proprietary information includes financial,
personnel, business or other information owned or possessed by VeriSign
that has not been authorized for public release. Proprietary Information
also includes Technical Data, which is described in detail below.
Examples of Proprietary Information include:
A. Financial information, such as:
1. Sales forecast data
2. Financial planning data
3. Budgets and pricing data, including labor rates, indirect rates or
pricing guidelines
4. Operating or contract performance costs
B. Personnel information, such as:
1. Employee lists or resumes giving detailed professional background
2. Salaries of individual personnel
3. Lists of addresses or home telephone numbers of personnel
4. Information which would assist a competitor in the proselytization
of VeriSign
5. Information from employees' personnel files
6. Medical information concerning individual employees
C. Marketing information, such as:
1. Specific proposals that VeriSign is submitting or considering
submitting
2. List of customers seeking proposals
3. Customer list and contracts
D. Corporate Communication, such as:
1. Information posted on the Vault
104
<PAGE>
2. The Style Guide
Such information is frequently referred to as "Proprietary Data," "Trade
Secret," "Confidential Information," "Privileged Information," "Private
Data," and/or "Unpublished Data."
(Proprietary Information does not include financial, administrative, cost
and pricing, and management data, or other information incidental to
contract administration.)
Technical Data. Technical Data is recorded information, regardless of form
or characteristic, of a scientific or technical nature. It may, for
example, document research, experimental, developmental, or engineering
work; or be usable or used to define a design process; or to procure,
produce, support, maintain, or operate equipment/material. The data may be
graphic or pictorial delineations in media such as drawings or photographs,
text in specifications or related performance, or design-type documents or
computer printouts.
Examples of Technical Data include:
1. Research and engineering data,
2. Engineering drawings
3. Products or process information
4. Corporate research plans or research results
5. Computer codes/programs
6. Internal reports or other work product such as notebooks, charts,
drawings, notes of your employees and file material which
employees compiled and used in performing duties as an employee of
VeriSign.
7. Specifications, standards process sheets, manuals, technical
reports, catalog item identifications and related information,
8. Computer software documentation (Computer Software Documentation
includes computer listings and printouts, in human-readable form
which (i) documents the design or details of computer software,
(ii) explains the capabilities of the software, (iii) provides
instructions for using the software to obtain desired results from
a computer, or (iv) printed service code)
Registry v. Registrar Information:
Registry Sensitive information includes Proprietary Information or other
financial, personnel, technical, or business information owned or possessed
by VeriSign relating to its Registry business which could be utilized to
advantage the Registrar business to the detriment of other competing
registrars.
105
<PAGE>
Registrar Sensitive information includes Proprietary Information or other
financial, personnel, technical, or business information owned or possessed
by VeriSign and/or its wholly owned subsidiaries relating to its Registrar
business.
Registry Sensitive information shall not be disclosed to Registrar
personnel at any time.
Examples of the distinction between Registry and Registrar information
include:
a. Engineering information, including schematics, code, and
engineering notes should be considered Registry Sensitive
information.
b. Statistics, such as numbers of registrations, transfers, etc.,
performed by each registrar, as well as processing times, numbers
of failures or any information that is trending negative or
contains negative performance factors not generally available to
the public should be considered either Registry Sensitive
information or Registrar Sensitive information, as applicable.
Unless otherwise approved, registration activity information must
be protected from disclosure to any registrar other than the
registrar to which the information refers. Such protection
extends to precluding VeriSign's Board of Directors, Chief
Executive Officer, Chief Financial Officer, and the General
Manager of the Registrar business from access to Registry
Sensitive information pertaining to any registrar other than that
owned or controlled by VeriSign.
c. Some statistical information will be available for public
consumption. Such information does not require any special
treatment, so long as neither the Registrar nor Registry does not
receive any preferential treatment (e.g., early access to such
information).
d. Financial information and data related to either the Registry or
Registrar is Sensitive Information and will not be released
without the express consent of the applicable General Manager,
Chief Executive Officer or Chief Financial Officer. Monthly
expenses and income shall be kept sensitive and restricted from
disclosure to any party other than the appropriate Registry or
Registrar staff and select members of the company's senior staff.
Procedures for Protection of Proprietary Information:
Responsibility. All employees are responsible for identifying
Proprietary Information, Registry Sensitive information and Registrar
Sensitive information developed, produced, or possessed by their
organizational units and for instructing employees reporting to them
regarding the proper handling and safeguarding of such Proprietary
Information.
Each VeriSign employee should exercise reasonable care to protect
Proprietary Information, Registry Sensitive information and Registrar
Sensitive information from unauthorized or inadvertent disclosure.
106
<PAGE>
Every VeriSign employee must exercise caution and discretion to insure that
divulging such information will not compromise the competitive position of
VeriSign nor infringe on personnel information about specific employees.
Marking of Internal Documents. Employees should, as a matter of routine,
mark each document containing Proprietary Information, Registry Sensitive
information and Registrar Sensitive information with the appropriate legend
at the time the document is produced.
Computer tapes and other recorded material should be identified by proper
labeling which is visible to the ordinary person while the material is
being stored. In addition, all such material should have a warning notice
at the beginning of the material to ensure the user is forewarned about the
proprietary nature of its contents (as soon as access is afforded to a
computer tape or at the beginning of a sound recording, etc.).
For internal documents containing Proprietary Information, the following
legend should appear on the first page of the document:
Copyright (C) 2001 VeriSign, Inc. All rights reserved.
VeriSign, Inc.
Division Name
PRIVILEGED AND CONFIDENTIAL
INTERNAL WORKING DOCUMENT [if appropriate]
[DATE]
The following legend should appear at the top of every page of the internal
document containing Proprietary Information:
VERISIGN PROPRIETARY INFORMATION
The information on this document is proprietary to VeriSign.
It may not be used, reproduced or disclosed without the written approval of
VeriSign.
The following legend should appear at the top of every page of the internal
document containing Registry Sensitive information:
REGISTRY SENSITIVE
The information on this document is proprietary to VeriSign and the VeriSign
Registry business.
It may not be used, reproduced or disclosed without the written approval of the
General Manager of VeriSign(R) Global Registry Services.
Not every piece of Proprietary Information in VeriSign's possession must be
properly marked; for example, salary reviews or medical/insurance records
do not need to be marked. Nevertheless, all such documents must be
protected from unauthorized disclosure.
Policy Concerning Disclosure and Marking of External Documents.
107
<PAGE>
a. Policy Concerning the External Disclosure of Proprietary
Information
As a general rule, no employee may disclose Proprietary Information to
anyone outside of the company. This general rule applies to business
associates, affiliates of the company and personal contacts.
As a general rule, VeriSign employees shall not disclose Proprietary
Information to other VeriSign employees unless the recipient of the
information has a "need to know" that information.
VeriSign recognizes that there are occasions when it is necessary to
disclose Proprietary Information to individuals who are not VeriSign's
employees. Such disclosure must have the prior written approval of
the appropriate VeriSign manager.
All documents containing Proprietary Information that are disclosed to
third parties, must contain the following notice:
Copyright (C) 2001 VeriSign, Inc. All rights reserved.
THIS DOCUMENT CONTAINS PROPRIETARY INFORMATION THAT IS OWNED BY
VERISIGN. THIS DOCUMENT MAY ONLY BE USED BY THE RECIPIENT FOR THE
PURPOSE FOR WHICH IT WAS TRANSMITTED. THIS DOCUMENT MUST BE RETURNED
UPON REQUEST OR WHEN NO LONGER NEEDED BY RECIPIENT. IT MAY NOT BE
COPIED OR ITS CONTENTS COMMUNICATED WITHOUT THE WRITTEN CONSENT OF
VERISIGN.
DISCLAIMER AND LIMITATION OF LIABILITY
VeriSign, Inc. has made efforts to ensure the accuracy and
completeness of the information in this document. However, VeriSign,
Inc. makes no warranties of any kind (whether express, implied or
statutory) with respect to the information contained herein. VeriSign,
Inc. assumes no liability to any party for any loss or damage (whether
direct or indirect) caused by any errors, omissions or statements of
any kind contained in this document. Further, VeriSign, Inc. assumes
no liability arising from the application or use of the product or
service described herein and specifically disclaims any representation
that the products or services described herein do not infringe upon
any existing or future intellectual property rights. Nothing herein
grants the reader any license to make, use, or sell equipment or
products constructed in accordance with this document. Finally, all
rights and privileges related to any intellectual property right
described herein are vested in the patent, trademark, or service mark
owner, and no other person may exercise such rights without express
permission, authority, or license secured from the patent, trademark,
or service mark owner. VeriSign Inc. reserves the right to make
changes to any information herein without further notice.
NOTICE AND CAUTION
Concerning U.S. Patent or Trademark Rights
VeriSign, [insert the specific trademark that is the subject to the
material], and other trademarks, service marks and logos are
registered or unregistered trademarks of VeriSign and its subsidiaries
in the United States and in foreign countries. The inclusion in this
document, the associated on-line file, or the associated software of
any information covered by any other patent, trademark, or service
mark rights does not constitute nor imply a grant of, or authority to
exercise, any right or privilege protected by such patent, trademark,
or service mark. All such rights and privileges are vested in the
patent, trademark, or service mark owner, and no other person may
exercise such rights without express permission, authority, or license
secured from the patent, trademark, or service mark owner.
108
<PAGE>
As a general rule, all recipients of such information should first
sign a Non-Disclosure Agreement. When Proprietary Information is
exchanged between VeriSign and another company with which VeriSign as
a business relationship, the parties must execute a Non-Disclosure
Agreement.
b. Policy Concerning the External Disclosure of Registry Sensitive
Information.
As a general rule, no employee may disclose Registry Sensitive
information to anyone outside of the company. This general rule
applies to business associates, independent contractors, temporary
employees, affiliates of the company and personal contacts.
VeriSign recognizes that there are occasions when it is appropriate to
disclose Registry Sensitive information to individuals who are not
VeriSign's employees, such as independent contractors or temporary
employees. Such disclosure must have the prior approval of the
appropriate VeriSign manager.
No Registry Sensitive information shall be disclosed to any third
party unless that third party has first agreed to a non-disclosure
agreement or similar agreement restricting the third party's
disclosure of the Registry Sensitive information in accordance with
this policy.
All documents containing Registry Sensitive information that are
disclosed to such third parties, must contain the following notice:
REGISTRY SENSITIVE
The information on this document is proprietary to VeriSign and the
VeriSign Registry business.
It may not be used, reproduced or disclosed without the written approval of the
General Manager of VeriSign(R) Global Registry Services.
Procedure for Disclosing Proprietary Information and/or Registry Sensitive
Information. The procedure to disclose Proprietary Information is as
follows:
a. affix the appropriate legend on the document
b. execute Non-Disclosure Agreement
c. send the Proprietary Information through a secure system, such as
overnight courier
d. log or note your disclosure of the information
e. maintain a record of and track your disclosures
Safekeeping:
When not in use, Proprietary Information should be stored in a locked desk,
cabinet or file. Such material should not be left unattended during the
workday and should be turned face down in the presence of visitors or
employees who have no need to know.
109
<PAGE>
Destruction:
Burning, shredding or comparable methods should be used for the destruction
of Proprietary Information.
Terminating Employees:
Terminating employees should be reminded of their responsibilities and
obligations in protecting Proprietary Information as outlined in the
appropriate employee regulations and rules. Permission to retain such
information after termination must be in writing and approved by the
VeriSign's General Counsel prior to removal.
Third-Party Proprietary Information:
Proprietary Information received from other companies through contractual
or precontractual relationships will be afforded the same level of
protection given to VeriSign private information.
Questions:
Questions concerning implementation or interpretation of this policy should
be referred to VeriSign's Legal department.
110
<PAGE>
--------------------------------------------------------------------------------
EXHIBIT B
NON-DISCLOSURE AGREEMENT
I understand I am an employee assigned to VeriSign Global Registry Services
("VGRS") or another employee who has a need to know information related to the
VGRS business (but not an employee assigned by any registrar affiliated with
VGRS) which is proprietary, confidential or business sensitive, belonging to
VGRS, other companies or customers of VGRS ("Need to Know Employee"). I agree
not to disclose or otherwise disseminate such information to anyone other than
Need to Know Employees, except as directed, in writing, by the General Manager
of the Registry Business or his/her designee. This prohibition is specifically
intended to prevent the disclosure of any such information to personnel assigned
by any registrar affiliated with VGRS. I understand that disclosure of such
information to anyone other than a Need to Know Employee or use of such
information could result in personal liability for such unauthorized use or
disclosure.
I agree to use such proprietary, confidential and/or business sensitive
information only in the performance of requirements necessary to carry out my
duties as a Need to Know Employee, and I agree to take suitable precautions to
prevent the use or disclosure of such information to any party, other than Need
to Know Employees. I will report to the General Manager of the VGRS Business or
his/her designee any potential violation of this agreement. I further agree to
surrender any and all data and information, of any type whatsoever, to the
General Manager of the VGRS Business or his/her designee upon the termination of
my employment as an employee of VeriSign, or my assignment with VGRS.
I certify that I have read and fully understand this Non-Disclosure Agreement
and agree to abide by all requirements contained herein. I understand that my
strict compliance is essential to VGRS, and any violation of these requirements
may result in termination of my employment.
Agreed to: Verified:
__________________________ __________________________
Employee General Manager, Registry
Date Date
111
<PAGE>
--------------------------------------------------------------------------------
EXHIBIT C
REGISTRY BUSINESS ORGANIZATIONAL
CONFLICT OF INTEREST AVOIDANCE CERTIFICATION
I hereby certify that I have received training in and understand the
requirements of conflict of interest issues and the requirements of the
Organizational Conflict of Interest Compliance Plan of VGRS. I certify that I
will strictly comply with the provisions of this Plan. I understand my
obligation to (i) refrain from any activities which could pose a personal
conflict of interest and (ii) report to the General Manager of VGRS, any
conflict, whether personal or organizational, which is perceived or identified
during the course of my employment with VGRS.
CERTIFIED
_______________________________
signature date
________________________________
name
112
<PAGE>
Appendix I
----------
Registry Code of Conduct
VeriSign Global Registry Services (VGRS), the registry business of VeriSign,
Inc., will at all times strive to operate as a trusted and neutral third party
provider of Registry Services. VGRS recognizes that domain names are the means
by which businesses, individuals and consumers gain access to, navigate and
otherwise benefit from the global Internet. These benefits cannot be fully
realized, however, unless the DNS resources are administered in a fair,
efficient and neutral manner that makes them available to all qualified parties
in the competitive DNS space. To ensure the provision of neutral Registry
Services, VGRS will comply with the following Code of Conduct:
1. VGRS will not show any preference or provide any special consideration
to any ICANN-accredited registrar with regard to Registry Services
provided for the .com TLD.
2. All registrars accredited by ICANN who are authorized to register
domain names in the .com registry shall have equivalent access to
Registry Services provided by VGRS.
3. VGRS shall not in any way attempt to warehouse, or register domain
names in its own right other than through an ICANN-accredited
registrar, except for names designated for operational purposes in
compliance with Section 24 of the Registry Agreement. VGRS will
certify to ICANN every six months that it is abiding by this
commitment.
4. Any subsidiary or affiliate of VGRS that operates as an ICANN-
accredited registrar shall maintain separate books of account with
respect to its registrar operations.
5. VGRS subsidiaries and affiliates engaged in providing Registry
Services shall not have access to, and VGRS itself will not use,
confidential user data or proprietary information of an ICANN-
accredited registrar served by VGRS, received by VGRS in the course of
providing Registry Services, except as necessary for registry
management and operations.
6. VGRS will take appropriate precautions to prevent the disclosure of
confidential user data or proprietary information from any ICANN-
accredited registrar, received by VGRS in the course of providing
Registry Services, to its affiliates or subsidiaries, except as
necessary for registry management and operations.
7. Confidential information about VGRS's Registry Services for the .com
TLD will not be shared with employees of any ICANN-accredited
registrar, except as necessary for registry management and operations.
113
<PAGE>
8. VGRS will conduct internal neutrality reviews on a regular basis. In
addition, VGRS agrees that it will cooperate with an independent third
party ("Auditor") performing Annual Independent Neutrality Audits
("AIN Audits"), to be conducted during the fourth quarter of each
calendar year. The Auditor will be selected by ICANN, and will be an
accounting firm with significant experience in the review of
contractual and other legal commitments. All costs of the AIN Audits
will be borne by VGRS. The AIN Audit is intended to determine whether
VGRS has been in compliance with Section 23 of the Registry Agreement,
and will utilize such tests and techniques as the auditor deems
appropriate to determine that compliance. The terms of reference of
the AIN Audit will be established by ICANN, subject to the approval of
VGRS (such approval not to be unreasonably withheld), and provided to
the Auditor by ICANN. A complete report of the results of each AIN
Audit shall be provided by the Auditor to ICANN and VGRS no later than
1 December of each calendar year (and by ICANN to the US Departments
of Commerce and Justice promptly thereafter). ICANN shall determine
that VGRS is in compliance with Section 23 if:
(1) any material breach(es) of Section 23 found by the audit that are
susceptible to cure have been cured, or are cured within a
reasonable time; and
(2) in addition and not as an alternative to subparagraph (1) above,
any monetary sanction that ICANN chooses to impose under the
Sanctions Program set forth in Appendix Y for any such breach(es)
has been timely paid.
A summary of each AIN Audit report, excluding any information that
ICANN and VGRS agree (such agreement not to be unreasonably withheld)
is confidential or proprietary, will be posted on the ICANN web site
no later than 31 January of the calendar year immediately following
the audit.
114
<PAGE>
Appendix K
----------
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
. dnso
. icann
. internic
. pso
IANA-related names:
------------------
. afrinic
. apnic
. arin
. example
. gtld-servers
. iab
. iana
. iana-servers
. iesg
. ietf
. irtf
. istf
. lacnic
. latnic
115
<PAGE>
. 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.
. arpa
. biz
. com
. coop
. edu
. gov
. info
. int
. mil
. museum
. name
. net
. org
. pro
C. Tagged Domain Names. All labels with hyphens in the third and fourth
-------------------
character positions (e.g., "bq--1k2n4h4b")
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 under Subsection 24(A), but
upon conclusion
116
<PAGE>
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
117
<PAGE>
Appendix N
----------
Zone File Access Agreement
1. PARTIES
The User named in this Agreement hereby contracts with VeriSign, Inc.
("VeriSign") for a non-exclusive, non-transferable, limited right to access an
Internet host server or servers designated by VeriSign 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 VeriSign, VeriSign 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 VeriSign'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.
118
<PAGE>
3. TERM
This Agreement is effective for a period of three (3) months from the date of
execution by VeriSign (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/.NET/.ORG 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
VeriSign grants to you a non-exclusive, non-transferable, limited right to
access an Internet host server or servers designated by VeriSign 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 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 the
transmission by e-mail, telephone, or facsimile of mass unsolicited,
commercial advertising or solicitations to entities other than your own
existing customers; or (2) enable high volume, automated, electronic
processes that send queries or data to the systems of VeriSign or any
ICANN-accredited registrar, except as reasonably necessary to register
domain names or modify existing registrations. VeriSign 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.
119
<PAGE>
(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
VeriSign, 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 VeriSign a quarterly fee of $0 (USD) for the
right to access the files during either the Initial Term or Renewal Term of this
Agreement. VeriSign 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
VeriSign 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, VeriSign 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." VeriSign 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
120
<PAGE>
In no event shall VeriSign 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 VeriSign 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 in the state or federal court 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 VeriSign at
[address of Registry Operator]. VeriSign 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 VeriSign 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 VeriSign 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.
[Full name of Registry Operator]
By: (sign)
Name: (print)
Title:
Date:
121
<PAGE>
User:
By: (sign)
Name: (print)
Title:
Date:
122
<PAGE>
Appendix O
----------
Whois Specification -- Public Whois
VeriSign Global Registry Services (VeriSign GRS) Whois service is the
authoritative Whois service for all second-level Internet domain names
registered in the .com top-level domains 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 VeriSign GRS 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 Network Solutions, Inc."
. For a nameserver: whois "nameserver ns1.netsol.com" or whois "nameserver
198.41.3.39"
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:
o Domain name including the TLD (e.g., verisign-grs.com)
o Full name of the registrar including punctuation, "Inc.", etc.
(e.g., America Online, Inc.)
o 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, INC.
Whois Server: whois.networksolutions.com
Referral URL: www.networksolutions.com
Name Server: NS1.CRSNIC.NET
123
<PAGE>
Name Server: NS2.NSIREGISTRY.NET
Updated Date: 27-mar-2001
))) Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT (((
For all ICANN-accredited registrars who are authorized to register .com second-
level domain names through VeriSign GRS, 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: AMERICA ONLINE, INC. DBA AOL AND/OR COMPUSERVE-AOL
Address: 22000 AOL Way, Dulles, VA 20166, US
Phone Number: 703 265 5037
Email: [email protected]
Whois Server: whois.compuserve.com
Referral URL: domain.compuserve.com
Admin Contact: Juan C Perez
Phone Number: 703 265 0918
Email: [email protected]
Admin Contact: Ryan M Morrow
Phone Number: 703 265 0910
Email: [email protected]
Billing Contact: Mara A Perrone
Phone Number: 703-265-1337
Email: [email protected]
Technical Contact: Juan C Perez
Phone Number: 703 265 0918
Email: [email protected]
Technical Contact: Ryan M Morrow
Phone Number: 703 265 0910
Email: [email protected]
))) Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT (((
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: NS1.CRSNIC.NET
IP Address: 198.41.3.39
Registrar: NETWORK SOLUTIONS, INC.
Whois Server: whois.networksolutions.com
Referral URL: www.networksolutions.com
124
<PAGE>
))) Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT (((
125
<PAGE>
Appendix P
----------
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.
126
<PAGE>
Appendix Q
----------
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 Registry TLD on a daily schedule, only for
purposes of verifying and ensuring the operational stability of Registry
Services, the DNS, and the Internet. 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.
127
<PAGE>
Appendix R
----------
Data Escrow Specification
EXHIBIT A - Task Order and Statement of Work
TASK ORDER TITLE
Exhibit A to the Registry Data Escrow Agreement dated _______________.
COMPANY NAME
Data Escrow Provider
STATEMENT OF WORK
Establish an escrow account to deposit all Registry Data in an electronic format
mutually approved by VeriSign Global Registry Services, and ICANN. More
specifically, to meet the Data Escrow requirements outlined in the Registry
Agreement, VeriSign Global Registry Services will store in escrow with Data
Escrow Provider a complete set of Registry Data in an electronic format agreed
upon by VeriSign Global Registry Services, and ICANN. Data Escrow Provider will
verify that the data is complete, accurate, and delivered in the intended format
using scripts provided by VeriSign Global Registry Services. A phased approach
will be taken to implement the scripts required for verification. The short-term
escrow process will verify completeness and integrity (accuracy). A long-term
approach is required to create a script to verify that the file format sent is
the format received by Data Escrow Provider (correctness). Refer to Exhibits B1
and B2 to review the short and long-term verification processes. The
Introspection validation, defined in Exhibit B2, 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:
-----------------------
VeriSign Global Registry Services will deposit a complete set of Registry
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.
128
<PAGE>
Daily Escrow Deposits:
----------------------
VeriSign Global Registry Services 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. VeriSign Global Registry Services shall transmit
the Deposit Materials and Additional Deposit to a secure server on a weekly
and daily basis, respectively. VeriSign Global Registry Services 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 4 reports (see Table 1 for
details of reports).
Additional Deposits shall include 1 report (see Table 2 for details of
report).
FILE SIZE ESTIMATES
----------------------------------------------------------------
Daily Weekly
----------------------------------------------------------------
Current Data Escrow Size up to 10 up to 750
Megabytes Megabytes
----------------------------------------------------------------
Forecasted 2001 Data up to 75 up to 1
----------------------------------------------------------------
129
<PAGE>
----------------------------------------------------------------
Escrow Size Megabytes Gigabytes
----------------------------------------------------------------
Total Forecasted Escrow up to 110 up to 4
Size Megabytes 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 all domains associated with a specific
registrar. The domain is listed once with each current status and
associated nameserver.
Fields: domainname
statusname
servername
Examples:
ALPHA.COM:REGISTRY-LOCK:NS1.ALPHA.COM
ALPHA.COM:REGISTRY-LOCK:NS2.ALPHA.COM
ALPHA.COM:REGISTRY-HOLD:NS1.ALPHA.COM
ALPHA.COM:REGISTRY-HOLD:NS2.ALPHA.COM
BETA.COM:ACTIVE:NS1.BETA.COM
BETA.COM:ACTIVE:NS2.BETA.COM
GAMMA.COM::NS1.GAMMA.COM
DELTA.COM:ACTIVE:
--------------------------------------------------------------------------------
2. Registrar Nameserver Report - Listed with IP Address
--------------------------------------------------------------------------------
Title: Registrar Nameserver Report - Listed with IPAddress
Report name: rgr_nameserver
Description: This report contains all nameservers associated with a
specific registrar. The nameserver is listed once with each associated
ipaddress.
Fields: servername
ipaddress
Examples:
NS.ALPHA.COM:111.222.333.001
--------------------------------------------------------------------------------
130
<PAGE>
--------------------------------------------------------------------------------
NS.ALPHA.COM:111.222.333.002
NS.BETA.COM:
--------------------------------------------------------------------------------
3. Registrar Nameserver-Domain Hosting Report
--------------------------------------------------------------------------------
Title: Registrar Nameserver Report - Listed with Domain
Report name: rgr_nameserver_domain
Description: This report contains domains hosted per nameservers
associated with a specific registrar. The nameserver is listed once with
each associated domainname.
Fields: servername
domainname
Examples:
NS.ALPHA.COM:ALPHA1.COM
NS.ALPHA.COM:ALPHA2.COM
NS.ALPHA.COM:ALPHA3.COM
NS.BETA.COM:BETA1.COM
NS.BETA.COM:BETA2.COM
NS.GAMMA.COM:
4. Registrar Common Report
--------------------------------------------------------------------------------
Title: Registrars Report
Report name: Registrars
Description: This report contains one row for each registrar. Fields of
the report contain name, location, contact, financial, and business
information.
Fields: REGISTRARID
REGISTRARNAME
SECURITYPHRASE
PHONENUMBER
FAXNUMBER
LICENSEEXPIRATIONDATE
CREDITLIMIT
AVAILABLECREDIT
LOWERLIMITPCT
EMAIL
--------------------------------------------------------------------------------
131
<PAGE>
GROSSAMOUNTDUE
NETAMOUNTDUE
ORIGINALDUEDATE
DUEDATE
ADDRESSLINE1
ADDRESSLINE2
ADDRESSLINE3
CITY
STATEPROVINCE
POSTALCODE
COUNTRYCODE
STATUSNAME
DESCRIPTION
CANPLACEORDER
Examples: 123:Alpha Registrar:Gazpacho is a dish best served
cold:(123)456-7890:(123)456-
7891:2001.01.01.00.00.00:2000000:218990:.2:[email protected]:::::123 4th
Avenue, 7 1/2th Floor:::NY:NY:10018:US:ACTIVE:Registrar is active and can
use the Registry to issue RRP commands:Y
--------------------------------------------------------------------------------
132
<PAGE>
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 (sigma) (ADD_DOMAIN, MOD_DOMAIN, DEL_DOMAIN) =>
[domainname][servername]
operation (sigma) (ADD_NAMESERVER, MOD_NAMESERVER, DEL_NAMESERVER) =>
[ipaddress][servername]
operation (sigma) (TRANSFER_DOMAIN) => [domainname][null]
Only the seven (7) operation types above are included in the
report.
Fields: transactionid
operationname
domainname | ipaddress
servername | null
transactiondate
Examples:
1000010:ADD-
DOMAIN:ALPHA.COM:NS.ALPHA.COM:1999.04.25.00.01.08
1000020:ADD-
DOMAIN:BETA.COM:NS1.BETA.COM:1999.04.25.00.05.33
1000020:ADD-
DOMAIN:BETA.COM:NS2.BETA.COM:1999.04.25.00.05.33
1000030:ADD-DOMAIN:GAMMA.COM::1999.04.25.00.05.34
2000010:ADD-
NAMESERVER:111.222.333.001:NS.DELTA.COM:1999.04.25.00.06.48
2000020:ADD-
NAMESERVER:444.555.666.001:NS.EPSILON.COM:1999.04.25.00.36.18
--------------------------------------------------------------------------------
133
<PAGE>
2000020:ADD-
NAMESERVER:444.555.666.002:NS.EPSILON.COM:1999.04.25.00.36.18
2000030:ADD-NAMESERVER::NS.ZETA.COM:1999.04.25.00.37.31
3000010:TRANSFER_DOMAIN:ETA.COM::1999.04.25.01.37.31
3000020:TRANSFER_DOMAIN:THETA.COM::1999.04.25.02.37.31
3000030:TRANSFER_DOMAIN:IOTA.COM::1999.04.25.03.37.31
3000040:TRANSFER_DOMAIN:KAPPA.COM::1999.04.25.03.37.31
--------------------------------------------------------------------------------
1. ADDITIONAL TERMS AND CONDITIONS
For .com agreement:
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. 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 established by ICANN
from time to time. The initial schedule, content, format, and procedure
shall be as set forth in Appendix R. 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 Definition 1 of this Agreement. The escrow shall be held under an
agreement, substantially in the form of Appendix S, among ICANN, Registry
Operator, and the escrow agent.
For .net and .org agreements:
Registry Operator shall periodically deposit into escrow all Registry Data
in an electronic format. 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 established by ICANN from time to time. The
initial schedule, content, format, and procedure shall be as set forth in
Appendix R. 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 withhold without reason) or in the manner
provided in Subsections 4.3 through 4.6. The escrow shall be held under an
agreement, substantially in the form of Appendix S, among ICANN, Registry
Operator, and the escrow agent.
2. PERIOD OF PERFORMANCE
134
<PAGE>
3. Period of Performance shall be as defined by section 7(a) of this Escrow
Agreement.
FEE SCHEDULE
Fees to be paid by VeriSign Global Registry Services 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.
135
<PAGE>
Exhibit B1: Phase I Escrow Process
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/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, digitally signed, and digested into a single file. The format of
this encapsulation enables the single file to be verified for Completeness/b/
and Integrity/c/ by a third party.
Exhibit B1: Phase I Verification Process
The goal of the Verification Process is to verify Completeness/b/ and
Integrity/c/ of an Escrow File. The Verification Process uses layers of meta-
data encapsulated in the Escrow File to construct a Verification Report. The
verification report produced by the Verification Process indicates whether the
data file meets the authentication requirements. The report has 2 sections,
action and results. Actions describe each of the actions taken against the data
file and whether those actions met success or failure. Results describe 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. Registrar Report
The existing Daily and Weekly reports associate Registry 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. Integrity
A data file transfer has integrity if no data file was altered by a third party
while in transit.
136
<PAGE>
Exhibit B2: Phase II Escrow Process
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/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/b/, Correctness/c/, and Integrity/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.
Exhibit B2: Phase II Verification Process
The goal of the Verification Process is to verify Completeness/b/,
Correctness/c/, and Integrity/d/ of an Escrow File. The Verification Process
uses layers of meta-data encapsulated in the Escrow File to construct a
Verification Report/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. As part of verification the data format specification is
used to verify the correctness of the format of each record in the file. To
ensure that the Reports are self-consistent, introspection will be implemented
in a later phase. Introspection will analyze Weekly Reports across all
Registrars to verify that fields referenced from outside the report are indeed
valid entries in other weekly reports.
Notes
a. Registrars Report
The existing Daily and Weekly reports associate Registry 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.
137
<PAGE>
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.
138
<PAGE>
Appendix S
----------
Escrow Agreement
This Escrow Agreement ("Agreement") is made as of this ___ day of
_________________, _____, by and between VeriSign, Inc., doing business as
VeriSign Global Registry Services ("VGRS" ), [Escrow Agent] ("Escrow Agent"),
and the Internet Corporation for Assigned Names and Numbers ("ICANN").
Preliminary Statement. VGRS intends to deliver the "Deposit Materials" and
---------------------
any "Additional Deposit" to Escrow Agent as defined and provided for herein.
VGRS 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 VGRS. VGRS 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 to Appendix R and incorporated
herein by reference. VGRS may elect to deliver the Deposit Materials by the
"Electronic Delivery Service," also defined in Exhibits A and B to Appendix R or
in a manner mutually agreed upon by Escrow Agent and VGRS. Upon receipt of the
Deposit Materials via Electronic Delivery Service, Escrow Agent shall download
the Deposit Materials onto CD-ROM and generate a file listing which Escrow Agent
shall, within ten (10) business days, forward to VGRS, via email. 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 B1 and B2 of
Appendix R. 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 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 VGRS, may reasonably require VGRS to promptly
duplicate the Deposit Materials and forward the same to Escrow Agent.
(b) VGRS shall deposit with Escrow Agent the "Additional Deposit," as
defined and described in the attached Exhibit A of Appendix R. 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 B1 and B2 of
Appendix R. 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
139
<PAGE>
fail the verification procedures, Escrow Agent shall notify ICANN 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,
VGRS 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 VGRS 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 VGRS, via email,
that it has received from VGRS 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) VGRS 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 VGRS and ICANN dated [April ____, 2001]
("Registry Agreement") has been validly and legally
terminated by ICANN under Section 14 of the Registry
Agreement or, if not sooner terminated, written
notification that the Registry Agreement has expired
and that it has been finally determined by the ICANN
Board (and no injunction obtained pursuant to
Section 13 of the Registry Agreement has been
obtained) that VGRS will not be designated as the
successor registry under Section 22 of the Registry
Agreement (either event generically referred to
herein as the "Registry Termination");
(ii) evidence satisfactory to Escrow Agent that ICANN has
previously notified VGRS 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 VGRS, or from ICANN (who will then be
reimbursed by VGRS), payable to Escrow Agent in the
amount of one hundred dollars ($100.00); or
(c) Release occurs according to Paragraph 8(b).
4.2 Delivery at VGRS'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
140
<PAGE>
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 VGRS, 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. VGRS
shall then have thirty (30) days from the date on which VGRS 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 VGRS 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 be conducted consistently
and in accordance with any prior arbitration or court decisions involving the
Registry Agreement. The parties further agree that any arbitration brought
pursuant to Paragraph 4.3 shall not examine, re-evaluate, reconsider, or
otherwise be subject to review by any issues, causes of action, or other claims
which were decided, or which a party had a reasonable opportunity to raise, in
an arbitration or court decision involving 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 [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
Paragraph 4.1(b) has been satisfied.
(d) VGRS may, at any time prior to the commencement of
arbitration proceedings, notify Escrow Agent that VGRS has withdrawn the
Objection Notice. Upon receipt of any such notice from VGRS, Escrow Agent shall
promptly deliver any Deposit Materials and Outstanding Additional Deposits to
ICANN in accordance with the instructions provided by ICANN, to the extent such
Deposit Materials and Outstanding Additional Deposits have not already been
delivered.
(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
141
<PAGE>
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 (such as those that were received by Escrow
Agent after Escrow Agent's initial delivery of materials to ICANN pursuant to
Paragraph 4.3). 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 VGRS'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 VGRS. Escrow Agent shall release and
--------------------------------
deliver the Deposit Materials and any Additional Deposit to VGRS upon
termination of this Agreement in accordance with paragraph 7(a) or 7(b) hereof.
5. Indemnity. VGRS 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 VGRS, 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 VGRS 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) VGRS, with
the concurrence of ICANN, notifies the other parties that it wishes to terminate
the Agreement at the end of such term.
142
<PAGE>
(b) In the event VGRS 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 R 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, VGRS 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 VGRS all copies of the Deposit Materials and any
Additional Deposit then in its possession.
8. Fees. VGRS shall pay to Escrow Agent the applicable fees in
----
accordance with Exhibit A of Appendix R 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 VGRS 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 VGRS 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 VGRS.
(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 VGRS and, in such an event, VGRS shall have the
right to pay the unpaid fee within ten (10) days after receipt of notice from
Escrow Agent. If VGRS 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) days of receipt of such notice from Escrow Agent.
Upon payment of the unpaid fee by either VGRS or ICANN, as the case may be, this
Agreement shall continue in full force and effect until the end of the
applicable term. Failure to pay the unpaid fee under this paragraph 8(b) by
either VGRS or ICANN shall result in termination of this Agreement and the
delivery to ICANN, as specifically instructed by ICANN, of the Deposit Materials
and any Additional Deposits held in escrow by Escrow Agent pursuant to this
Agreement.
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 VGRS at all times.
10. Miscellaneous.
-------------
(a) Remedies. Except for misrepresentation, negligence or misconduct
--------
by Escrow Agent, its employees, or contractors, Escrow Agent shall not be liable
to VGRS 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
143
<PAGE>
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 VGRS 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 VGRS 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 VGRS 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 VGRS 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 R,
specifically, Exhibit A (consisting of Task Order and Statement of Work, File
Size Estimates, Table 1, Table 2, and Additional Terms and Conditions), Exhibit
B1 and Exhibit B2, 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) Confidentiality. Escrow Agent will hold and release the Deposit
---------------
Materials only in accordance with the terms and conditions hereof, and will
maintain the confidentiality of the Deposit Materials at all times.
(i) 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.
(j) Survival. Paragraphs 5, 6, 8, 9 and 10 shall survive any
--------
termination of this Agreement.
(k) 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
144
<PAGE>
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:______________________________________________________
______________________________________________________
______________________________________________________
145
<PAGE>
Phone:
Fax:_______________________________
E-mail:
______________________________________________________
Internet Corporation for Assigned Names and Numbers
By:
Title: __________________________
Print
Name:____________________________________________________
Address:______________________________________________________
______________________________________________________
______________________________________________________
Phone:
Fax:_______________________________
E-mail:
______________________________________________________
146
<PAGE>
Appendix T
----------
Registry Operator's Monthly Report
Registry Operator shall provide the following information in its monthly
reports. Information reported in response to items 5-12 shall be kept
confidential by ICANN until three months after the end of the month to which the
report relates.
1. Accredited Registrar Status. State the number of registrars for whom
the Registry Operator had received accreditation notification from ICANN at
the end of the reporting month, grouped into the following three status
categories:
1.1 Operational registrars are those who have authorized access into
the System for processing domain name registrations. It should be
noted that operational registrars are not listed on the InterNIC.net
web site until they specifically request to be listed. This means
that a registrar may be operational from the point of view of the
Registry Operator but not listed on the InterNIC site.
1.2 Registrars in the ramp-up period represent those who have
received a password to access the Registry operational test and
evaluation (OT&E) environment. The OT&E environment is provided to
allow registrars to develop and test their systems with the System.
1.3 Registrars in the pre-ramp-up period are those who have been sent
information regarding the Registry TLD, but have not yet entered the
Ramp-up Period.
2. Service Level Agreement Performance. Compare Service Level Agreement
("SLA") requirements with actual performance measures for the reporting
month.
3. TLD Zone File Access Activity. State the zone file access activity for
the current reporting month including:
3.1 Total # of zone file access passwords at end of previous month
3.2 # of new zone file access passwords issued during the reporting
month
3.3 Total # of zone file access approvals at end of reporting month
4. Completed SRS/System Software Releases. State significant releases
that have occurred since the Effective Date, including:
147
<PAGE>
4.1 Release Name
4.2 Features
4.3 Target Date
4.4 Complete Date
5. Domain Names Under Sponsorship - Per Registrar. State the number of
domain names sponsored by each live ICANN-Accredited Registrar in the TLD
for the current reporting month.
6. Nameservers Registered - Per Registrar. State the number of
nameservers registered by each ICANN-Accredited Registrar in the TLD for
the current reporting month.
7. Domain Names Registered by Registry Operator. Provide a list of all
domain names registered by Registry Operator, other than on a request
submitted by a registrar pursuant to that registrar's Registry-Registrar
Agreement, in the Registry TLD. The list should be broken down in
accordance with Subsections 24(A) and (B) of the Registry Agreement.
8. Whois Service Activity. State the number of Whois queries during the
current reporting month. For registries with fee-based enhanced Whois
Service, state the number of queries for each service (i.e. basic, xWhois,
etc.).
9. Monthly Growth Trends. Tabulate the monthly growth trend in total
Registry transactions. Transactions should be divided into three
categories:
9.1 Write Domain - This category includes the following transactions:
domain, modify domain, delete domain, renew domain, auto-renew domain
(if any) and transfer domain.
9.2 Query Domain - This category includes the following transactions:
query domain and query domain transfer status.
9.3 Check Domain - This category includes the following transaction:
check domain.
9.4 Write Server - This category includes the following transactions:
add name server, modify name server, and delete name server.
9.5 Query Server - This category includes the following transaction:
query name server.
9.6 Check Server - This category includes the following transaction:
check name server.
148
<PAGE>
9.7 Write Contact (where contact information is maintained under
registry model) - This category includes the following transactions:
add contact, modify contact, delete contact, transfer contact.
9.8 Query Contact (where contact information is maintained under
registry model) - This category includes the following transactions:
query contact and query contact transfer status.
9.9 Check Contact (where contact information is maintained under
registry model) - This category includes the following transaction:
check contact.
10. Total Number of Transactions by Subcategory by Month. Tabulate the
monthly growth trend for each transaction in subcategories of the Write
Domain, Write Server, and Write Contact categories described in Subsection
9.1 as follows:
10.1 Add Domain
10.2 Delete Domain
10.3 Modify Domain
10.4 Check Domain
10.5 Renew Domain
10.6 Transfer Domain
11. 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.
12. TLD Geographical Registrations Distribution. Tabulate the number and
percent of total and new domain name registrations in the Registry TLD
broken down by geographical location (country code) as of the end of the
current reporting month. (Only applies where contact information is
maintained under registry model.)
149
<PAGE>
Appendix V
----------
Consensus Policies
The Registry Agreement requires Registry Operators to abide by various
specifically stated procedures and also Consensus Policies. Policies adopted
before the date of the Registry Agreement are deemed to be Consensus Policies.
Policies adopted after the date of the Registry Agreement are applicable to
Registry Operator if those policies meet certain requirements regarding the
demonstration of consensus.
The following policies are specifically identified as having been adopted by the
ICANN Board of Directors as of the dates shown below. As such, they are deemed
Consensus Policies:
. Uniform Domain Name Dispute Resolution Policy - adopted August 26,
1999; form of implementation documents approved October 24, 1999.
150
<PAGE>
Appendix W
----------
Additional Covenants of Registry Operator
1. Centralized Whois
Registry Operator shall develop and deploy a centralized Whois for the .com,
.net, and .org TLDs if mandated by ICANN insofar as reasonably feasible,
particularly in view of Registry Operator's dependence on cooperation of third
parties.
2. Research, Development and Infrastructure Improvements
During the period between the Effective Date of this Agreement and December 31,
2010, Registry Operator agrees to expend a minimum of US$200,000,000 for
research, development, and infrastructure improvements to the .com, .net, and
.org Registries (the "Improvements"). The intent of the Improvements is to
increase the efficiency and stability of the .com, .net and .org Registries.
Registry Operator shall ensure that a substantial portion of expenditures for
the Improvements occurs prior to November 10, 2007. Registry Operator shall
provide ICANN with an annual report on this research and development activity.
Registry Operator agrees that one of the early goals of the Improvements is to
design and develop a Universal Whois Service that will allow public access and
effective use of Whois across all Registries and all TLDs. Registry Operator
shall commence research and development of the Universal Whois Service no later
than December 31, 2001. Registry Operator shall, insofar as is reasonably
possible in view of Registry Operator's dependence on the cooperation of third
parties, strive to achieve significant progress in implementing the Universal
Whois Service by December 31, 2002.
Registry Operator further agrees that if it successfully designs and develops
the Universal Whois Service it will (a) make the Application Program Interfaces
necessary to produce software which can efficiently deploy and use the Universal
Whois Service available to applications developers on an open, non-proprietary,
standards-based and royalty-free basis, and (b) make the Universal Whois Service
available at a standardized reasonable fee to be negotiated with ICANN.
3. Limits on Volume Discounts
Registry Operator will not grant any volume adjustment to pricing under
Subsection 22(B) until such time as ICANN authorizes Registry Operator to do so.
151
<PAGE>
Appendix X
----------
Names Registered to Registry Operator
The domains to be registered by Registry Operator, other than on a request
submitted by a registrar pursuant to that registrar's Registry-Registrar
Agreement, are as follows:
None at this time.
152
<PAGE>
Appendix Y
----------
Sanctions Program
This document describes a program (the "Sanctions Program") under which
violations of Subsections 23(A) through (E) and Appendix H (certification and
separation requirements) and Appendix I (Registry Operator's Code of Conduct) of
the Registry Agreement may be addressed, at ICANN's option, by a separate and
additional set of specific monetary sanctions. The Sanctions Program is
intended to allow ICANN flexibility to address violations of those Subsections
and Appendices by means less extreme than proceedings to terminate the Registry
Agreement. Registry Operator agrees that the Sanctions Program is a non-
exclusive and additional option for promoting compliance with Appendices H and
I, and does not (except as stated below) limit or affect in any way ICANN's
ability to employ any other compliance measures or remedies available under the
Registry Agreement.
Registry Operator agrees to participate in and comply with the Sanctions Program
described in this document, provided that all other registry operators having
registry agreements with ICANN for the operation of unsponsored top-level
domains (i.e., top-level domains, other than country-code and infrastructure
domains, not having a sponsoring organization) are obligated to participate in
and comply with a sanctions program with substantially the same provisions.
Failure by Registry Operator to participate in and comply with this sanctions
program according to the terms of this document constitutes a ground for ICANN
to terminate the Registry Agreement.
ICANN and Registry Operator agree that, should the gTLD Constituency of the
Domain Name Supporting Organization propose a substitute Appendix Y at any time
prior to May 1, 2002, and ICANN determines (following an appropriate process of
public notice and comment) that substitution by that Appendix Y would serve the
interests of the Internet community, the substitution will be made.
Investigation:
ICANN may elect to employ the Sanctions Program by sending Registry Operator a
Confidential Notice of Investigation. Should ICANN choose to initiate an
investigation with regard to any particular activity or conduct, it must do so
(a) within 90 days of the time that such activity or conduct is brought to the
attention of the appropriate ICANN employee, and (b) in any event no later than
one year after the episode in question. The Confidential Notice of
Investigation must be given in the manner described by the Registry Agreement,
but shall not be publicly disclosed or commented upon by ICANN unless Registry
Operator has previously disclosed or confirmed its existence. The Confidential
Notice of Investigation must include all of the following:
1. A statement that an investigation under the Sanctions Program is being
initiated;
153
<PAGE>
2. A statement of the possible violation of Subsections 23(A) through (E)
and Appendices H and I being investigated and the reasons for believing
such violation may have occurred;
3. A request to Registry Operator to provide to ICANN the information,
including copies of any documentation, that ICANN believes is necessary for
it to conduct the investigation, which information must be reasonably
related to the alleged violation; and
4. A specification of the ICANN investigator to whom a response should be
made and the form in which the response should be transmitted.
Registry Operator shall have thirty days (or such larger period as ICANN may
allow) after the date of the Confidential Notice of Investigation to send a
response to the specified ICANN investigator. The response, which shall be
transmitted to the ICANN investigator in the manner stated in the Confidential
Notice of Investigation, shall include:
1. An acknowledgement that an investigation has been initiated;
2. Any of the information requested in the Confidential Notice of
Investigation that Registry Operator chooses to provide in accordance
with clause 3 above;
3. If Registry Operator does not provide any or all of the information
sought by the Confidential Notice of Investigation, the Registry
Operator may state its reason(s) for not providing the information, and
ICANN is free to draw any reasonable inferences from the failure to
provide such information;
4. Any request by the Registry Operator for confidential treatment of any
of the information supplied, and the reason for such confidential
treatment; and
5. A specification of the name and address of the person appointed by the
Registry Operator to receive communications concerning the
investigation ("Authorized Representative").
Any such response shall be treated as confidential by ICANN unless disclosed or
confirmed by Registry Operator. Within thirty days after transmission of the
Registry Operator's response to the Notice of Investigation, ICANN shall do one
of the following:
1. If ICANN chooses to commence a sanctions proceeding based on the
information it has received from the Registry Operator and otherwise,
send the Authorized Representative a Statement of Evidence of Violation
meeting the requirements stated below;
154
<PAGE>
2. If ICANN chooses not to proceed with the sanctions proceeding or a
renewed investigation, send the Authorized Representative a notice that
the Investigation is closed without further action; or
3. If ICANN chooses to seek additional information, send an additional
Confidential Notice of Investigation to the Registry Operator meeting
the requirements stated above.
Statement of Evidence of Violation
If ICANN has reason to believe that a violation has occurred, it shall send the
Authorized Representative a Statement of Evidence of Violation. The Statement
of Evidence of Violation shall not be publicly disclosed or commented on by
ICANN unless Registry Operator has previously disclosed or confirmed its
existence. The Statement of Evidence of Violation shall:
1. Specify the provision(s) of Subsections 23(A) through 23(E) and Appendices
H and I of the Registry Agreement that ICANN has reason to believe Registry
Operator has violated;
2. Provide a reasonably specific statement of the factual basis of the
apparent violation;
3. Include all evidence on which ICANN has relied in concluding it has
reason to believe that a violation has occurred;
4. Give the legal and factual basis for ICANN's conclusion that it has reason
to believe that a violation has occurred, based on a discussion of the
provisions of the Registry Agreement, the included evidence, and any
reasonable inferences drawn therefrom; and
5. State whether the alleged violation would, if established, be a major
violation or a minor violation (see below) and why.
Within thirty days (or such longer period as ICANN may allow) after the
Statement of Evidence of Violation is sent, the Registry Operator shall send a
response to the ICANN investigator.
Finding of Violation
At least thirty days after the Statement of Evidence of Violation is sent, and
after considering any Registry Operator's response to the Statement of Evidence
of Violation, ICANN may issue a Finding of Violation. A Finding of Violation
must be sent to the
155
<PAGE>
person appointed by the Registry Operator to receive communications concerning
the investigation, and shall be posted on ICANN's website, with appropriate
redactions for material that ICANN and Registry Operator agree is confidential.
If no Finding of Violation is sent within ninety days after the Registry
Operator's response to the Statement of Evidence of Violation, the sanctions
proceeding shall be deemed closed without action.
Any Finding of Violation must:
1. Specify the provision(s) of Subsections 23(A) through (E) and
Appendices H and I of the Registry Agreement that ICANN finds Registry
Operator has violated;
2. Provide a specific detailed description of the evidence upon which
ICANN relies in making the finding;
3. Specifically state any inferences that ICANN draws based on the
evidence, upon Registry Operator's failure to provide information requested
in the investigation, or otherwise;
4. Provide a specific detailed description of the nature of the violation
found, and state whether the violation is found to be major or minor and
why; and
5. State the amount of monetary sanctions assessed for each distinct
violation found and reasons why the amount is deemed reasonable.
In finding a violation, ICANN may rely on information provided in response to a
Confidential Notice of Investigation, on any evidence included in the Statement
of Evidence of Violation, and on any information provided in response to the
Statement of Evidence. ICANN may draw inferences from any failure by the
Registry Operator to provide information requested in the investigation,
provided those inferences are reasonable in the circumstances. Only one Finding
of Violation may be issued with respect to any particular episode of activity or
conduct.
A violation shall be classified as major or minor based on (a) the effects of
the violation on competition and competitors, (b) the extent to which the
violation appears to be intentional by Registry Operator, considering the level
of the employees or agents involved, prior notice to the Registry Operator of
the circumstances, and other relevant factors, (c) the extent to which the
Registry Operator has established and effectively enforces policies that
prohibit such violations (where the violation involves actions by employees or
agents of Registry Operator that have not been approved by senior management
that has authority to change such policies), (d) prior findings of violations by
the Registry Operator, and (e) any other relevant circumstances.
Sanctions of up to US$10,000 for each violation may be assessed for each minor
violation found and sanctions of up to US$100,000 for each violation may be
assessed
156
<PAGE>
for each major violation found. The amount of the financial sanction shall be
proportionate to the violation and other relevant facts.
In the event ICANN makes a Finding of Violation and seeks to impose a monetary
sanction, it may not thereafter issue a cure notice or seek any other remedy on
the basis of the assertion that the same specific episode on which the Finding
of Violation is based constitutes a breach of this Agreement, but it may take
into account the fact of the Finding and sanction in determining that another
violation should be dealt with in a particular way, including by deeming it a
material breach of this Agreement
Review of Finding of Violation
Findings of Violation may be reviewed only by ICANN's Reconsideration Policy or
by arbitration under Section 15 of the Registry Agreement.
Registry Operator may seek review of any aspect of any Finding of Violation by a
request for reconsideration under ICANN's Reconsideration Policy (as it may be
amended from time to time), provided that the request is submitted within the
time allowed by the policy after the sending of the Finding of Violation. The
submission of a request for reconsideration shall not be a prerequisite for
seeking review of the Finding of Violation by arbitration.
Registry Operator may also appeal the assessment of sanctions in the Finding of
Violation by giving ICANN written notice of its intention to arbitrate (the
"Arbitration Notice") under Section 15 of the Registry Agreement. Registry
Operator shall deliver the Arbitration Notice no later than fifteen days after
the Finding of Violation is sent, except that if a timely request for
reconsideration is submitted under ICANN's Reconsideration Policy (as it may be
amended from time to time) the deadline shall be fifteen calendar days after
ICANN has provided contractual notice that the ICANN Board has voted to act or
not to act on the request. If Registry Operator does not deliver an Arbitration
Notice within the time described above, or the Registry Operator causes the
arbitration to be discontinued before decision, the amount of the sanctions
assessed in the Finding of Violation shall be deemed final.
If a timely Arbitration Notice is delivered, the arbitration shall determine,
based on the record, whether the Finding of Violation is warranted and the
amount of sanctions is reasonable. The amount of sanctions as determined
appropriate according to the arbitration decision shall be deemed final.
Payment of Sanctions
Registry Operator shall pay to ICANN the final amount of sanctions within thirty
days after the amount of sanctions is deemed final. Failure to do so shall be a
ground for termination under Subsection 16(E) of the Registry Agreement.
157