SECURITIES AND EXCHANGE COMMISSION WASHINGTON, D.C. 20549 ________________ FORM 8-K CURRENT REPORT Pursuant to Section 13 or 15(d) of the Securities Exchange Act of 1934 Date of report (Date of earliest event reported): May 25, 2001 VERISIGN, INC. (Exact name of Registrant as specified in its charter) Delaware 0-23596 94-3221585 (State or Other Jurisdiction of (Commission (IRS Employer Incorporation or Organization) File Number) Identification No.) 1350 Charleston Road, Mountain View, CA 94043-1331 (Address of Principal Executive Offices) (Zip Code) Registrant's telephone number, including area code: (650) 961-7500
Item 5: Other Events. On May 25, 2001, VeriSign, Inc. ("VeriSign" or the "Company"), the U.S. Department of Commerce ("DoC") and the Internet Corporation for Assigned Names and Numbers ("ICANN") executed new agreements relating to the operation of the domain name registries for .com, .net and .org (the "Agreements"). Previously, the Company announced that the DoC, ICANN and the Company had agreed in principle to the terms of the new Agreements. A copy of the Company's press releases, dated May 18, 2001 and May 21, 2001, and the Agreements are attached hereto as Exhibits 99.1, 99.2, 99.3, 99.4, 99.5 and 99.6, respectively, and are incorporated by reference herein. The press releases contain descriptions of some of the provisions of the Agreements, but the exact provisions are contained in the Agreements themselves. Statements in this report and the Company's press releases attached hereto, other than historical data and information, constitute forward-looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934. These statements involve risks and uncertainties that could cause VeriSign's actual results to differ materially from those stated or implied by such forward-looking statements. The potential risks and uncertainties include, among others, VeriSign's limited operating history under its current business structure, uncertainty of future revenue and profitability and potential fluctuations in quarterly operating results, increased competition, risks associated with the company's international business and risks related to potential security breaches. More information about potential factors that could affect the company's business and financial results is included in VeriSign's filings with the Securities and Exchange Commission, especially in the Company's Annual Report on Form 10-K for the year ended December 31, 2000 and its Quarterly Report on Form 10-Q for the period ended March 31, 2001. Item 7. Financial Statements and Exhibits. (c) Exhibits 99.1 Text of Press Release dated May 18, 2001 99.2 Text of Press Release dated May 21, 2001 99.3 .com Registry Agreement between VeriSign and ICANN 99.4 .net Registry Agreement between VeriSign and ICANN 99.5 .org Registry Agreement between VeriSign and ICANN 99.6 Amendment No. 24 to Cooperative Agreement #NCR 92-18742 between the DoC and Network Solutions, Inc.
SIGNATURES Pursuant to the requirements of the Securities Exchange Act of 1934, Registrant has duly caused this report to be signed on its behalf by the undersigned thereunto duly authorized. VERISIGN, INC. Date: May 31, 2001 By: /s/ Dana L. Evan Dana L. Evan Executive Vice President of Finance and Administration and Chief Financial Officer
Exhibit Index Exhibit No. Description - ----------- ----------- Exhibit 99.1 Text of Press Release dated May 18, 2001 Exhibit 99.2 Text of Press Release dated May 21, 2001 Exhibit 99.3 .com Registry Agreement between VeriSign and ICANN Exhibit 99.4 .net Registry Agreement between VeriSign and ICANN Exhibit 99.5 .org Registry Agreement between VeriSign and ICANN Exhibit 99.6 Amendment No. 24 to Cooperative Agreement #NCR 92-18742 between the DoC and Network Solutions, Inc.
EXHIBIT 99.1 ------------ VeriSign Commends U.S. Department of Commerce Decision To Approve New Registry Agreements Mountain View, California, May 18, 2001 - VeriSign, Inc. (NASDAQ:VRSN), the leading provider of Internet trust services, commended the U.S. Department of Commerce's decision today to ratify the new registry agreements approved by the Internet Corporation for Assigned Names and Numbers (ICANN) and VeriSign. "These complex agreements mark an important step forward for the Internet," said Stratton Sclavos, president and CEO of VeriSign. "We fully appreciate the Department of Commerce's effort to promote stability and competitiveness in the Internet infrastructure." The terms of the agreements include the following: VeriSign will operate the .com registry function of its business until 2007, with presumable right of renewal afterwards. VeriSign will keep the Registrar function of its business (with VeriSign agreeing to an independent audit of the Registry/Registrar firewall annually). VeriSign agrees to divest of its .org registry in 2002. The .org registry will be maintained by a not for profit organization to be determined by ICANN. VeriSign's .net registry agreement will now expire on June 30, 2005, unless market measurements indicate competition in the registry or registrar market is not growing and meeting established goals. More detailed information on the terms of the new agreements can be found at the Department of Commerce's website at http://www2.osec.doc.gov/public.nsf/docs/icann-verisign-0518. - ------------------------------------------------------------ About VeriSign VeriSign, Inc. (Nasdaq:VRSN) is the leading provider of trusted infrastructure services to Web sites, enterprises, electronic commerce service providers and individuals. The Company's domain name, digital certificate and payment services provide the critical web identity, authentication and transaction infrastructure that online businesses require to conduct secure e-commerce and communications. VeriSign's services are available through its Web site (www.verisign.com) or ---------------- through its direct sales force and reseller partners around the world. Statements in this announcement other than historical data and information constitute forward-looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934. These statements involve risks and uncertainties that could cause VeriSign's actual results to differ materially from those stated or implied by such forward-looking statements. The potential risks and uncertainties include, among others, VeriSign's limited operating history under its current business structure, uncertainty of future revenue and profitability and potential fluctuations in quarterly operating results, increased competition, risks associated with the company's international business and risks related to potential security breaches. More information about potential factors that could affect the company's business and financial results is included in VeriSign's filings with the Securities and Exchange Commission, especially in the company's Annual Report on Form 10-K for the year ended December 31, 2000. VeriSign undertakes no obligation to update any of the forward-looking statements after the date of this press release. VeriSign is a registered trademark of VeriSign, Inc. Other names may be trademarks of their respective owners. VeriSign Contacts: Media Contact: Brian O'Shaughnessy, boshaughnessy@verisign.com, +1-650/429 -5270; Investor Contact: Katie Ochsner, - -------------------------- kochsner@verisign.com, +1-650/429-3512 - ---------------------
EXHIBIT 99.2 ------------ VeriSign Applauds Department of Commerce Decision on New Registry Agreements Mountain View, California, May 21, 2001 - VeriSign, Inc. (NASDAQ:VRSN), the leading provider of Internet trust services, recognized the U.S. Department of Commerce's effort in approving the new registry agreements passed by the Internet Corporation for Assigned Names and Numbers (ICANN) and VeriSign. "On Friday the Department of Commerce, ICANN and VeriSign agreed to terms that are fundamentally important to the core infrastructure of the Internet," Stratton Sclavos, president and CEO of VeriSign. "With these new agreements on .com and .net and the impending rollout of new generic top level domains, the Internet has taken several steps forward to truly becoming a more open and stable global medium for businesses and consumers alike." The terms of the agreements include the following: VeriSign will operate the .com registry function of its business until 2007, with presumable right of renewal afterwards. VeriSign will keep the Registrar function of its business (with VeriSign agreeing to an independent audit of the Registry/Registrar firewall annually). VeriSign agrees to divest of its .org registry in 2002. The .org registry will be maintained by a not for profit organization to be determined by ICANN. VeriSign's .net registry agreement will now be open to recompetition on June 30, 2005, unless market measurements indicate competition in the registry or registrar market is not growing and meeting established goals. More detailed information on the terms of the new agreements can be found at the Department of Commerce's website at http://www2.osec.doc.gov/public.nsf/docs/icann-verisign-0518. - ------------------------------------------------------------ About VeriSign VeriSign, Inc. (Nasdaq:VRSN) is the leading provider of trusted infrastructure services to Web sites, enterprises, electronic commerce service providers and individuals. The Company's domain name, digital certificate and payment services provide the critical web identity, authentication and transaction infrastructure that online businesses require to conduct secure e-commerce and communications. VeriSign's services are available through its Web site (www.verisign.com) or ---------------- through its direct sales force and reseller partners around the world. Statements in this announcement other than historical data and information constitute forward-looking statements within the meaning of Section 27A of the Securities Act of 1933 and Section 21E of the Securities Exchange Act of 1934. These statements involve risks and uncertainties that could cause VeriSign's actual results to differ materially from those stated or implied by such forward-looking statements. The potential risks and uncertainties include, among others, VeriSign's limited operating history under its current business structure, uncertainty of future revenue and profitability and potential fluctuations in quarterly operating results, increased competition, risks associated with the company's international business and risks related to potential security breaches. More information about potential factors that could affect the company's business and financial results is included in VeriSign's filings with the Securities and Exchange Commission, especially in the company's Annual Report on Form 10-K for the year ended December 31, 2000. VeriSign undertakes no obligation to update any of the forward-looking statements after the date of this press release. VeriSign is a registered trademark of VeriSign, Inc. Other names may be trademarks of their respective owners. VeriSign Contacts: Media Contact: Brian O'Shaughnessy, boshaughnessy@verisign.com, +1-650/429 -5270; Investor Contact: Katie Ochsner, - -------------------------- kochsner@verisign.com, +1-650/429-3512 - ---------------------
EXHIBIT 99.3 ------------ .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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
By:_____________________________ Stratton Sclavos President and CEO Date: 20
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 root-mgmt@iana.org. 2. Requests should be submitted by filling out the template available at
. 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 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 root-mgmt@iana.org>. 2. Requests should be submitted by filling out the template available at
. 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 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
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 [majordomo@NSIRegistry.com] 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
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
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
- 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
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
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
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
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 attributeName:attributeValue 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 30 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. .
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 responseDescription [attributeName:attributeValue ] . 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 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
C:EntityName:Domain C:DomainName:example.com C:-Period:10 C:. S:200 Command completed successfully S:registration expiration date:2009-09-22 10:27:00.0 S:status:ACTIVE S:. 32 A registrar registers a domain name using previously-registered name servers: C:add
C:EntityName:Domain C:DomainName:example2.com C:-Period:10 C:NameServer:ns1.example.com C:NameServer:ns2.example.com C:. S:200 Command completed successfully S:registration expiration date:2000-09-22 10:27:00.0 S:status:ACTIVE S:. 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 Examples A registrar registers a new name server in an existing domain name: C:add
C:EntityName:NameServer C:NameServer:ns1.example.com C:IPAddress:198.41.1.11 C:. S:200 Command completed successfully S:. 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 C:EntityName:Domain C:DomainName:example.com C:. S:211 Domain name not available S:. 34 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
C:EntityName:Nameserver C:Nameserver:ns1.example.com C:. S:213 Name server not available S:ipAddress:192.10.10.10 S:. 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 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
C:EntityName:Domain C:DomainName:example.com C:. S:200 Command completed successfully S:. 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 C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:. S:200 Command completed successfully S:. 36 A registrar tries to delete a name server that is hosting domains: C:del
C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:. S:532 Domain names linked with name server S:. 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 C:-Target:Protocol C:. S:200 Command completed successfully S:Protocol:RRP 1.1.0 S:. 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 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
C:EntityName:Domain C:DomainName:example.com C:NameServer:ns3.registrarA.com C:NameServer:ns1.registrarA.com= C:. S:200 Command completed successfully S:. 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 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
C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:NewNameServer:ns2.registrarA.com C:IPAddress:198.42.1.11 C:IPAddress:198.41.1.11= C:. S:200 Command completed successfully S:. 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 C:. S:220 Command completed successfully. Server closing connection S:. 39 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
C:EntityName:Domain C:DomainName:example.com C:-Period:9 C:-CurrentExpirationYear:2001 C:. S:200 Command completed successfully S:registration expiration date:2010-09-22 10:27:00.0 S:. 40 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
C:-Id:registrarA C:-Password:i-am-registrarA C:. S:200 Command completed successfully S:. 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 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
C:EntityName:Domain C:DomainName:example.com C:. S:200 Command completed successfully S:nameserver:ns2.registrarA.com S:nameserver:ns3.registrarA.com S:registration expiration date:2010-09-22 10:27:00.0 S:registrar:registrarA S:registrar transfer date:1999-09-22 10:27:00.0 S:status:ACTIVE S:created date:1998-09-22 10:27:00.0 S:created by:registrarA S:updated date:2002-09-22 10:27:00.0 S:updated by:registrarA S:. 42 A registrar queries a domain name currently registered by another registrar: C:status
C:EntityName:Domain C:DomainName:example.com C:. S:531 Authorization failed S:. 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 C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:. 43 S:200 Command completed successfully
S:ipaddress:198.42.1.11 S:registrar:registrarA S:registrar transfer date:1999-09-22 10:27:00.0 S:CreatedDate:1998-09-22 10:27:00.0 S:CreatedBy:registrarA S:UpdatedDate:2002-09-22 10:27:00.0 S:UpdatedBy:registrarA S:. A registrar queries a name server that was registered by another registrar: C:status C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:. S:531 Authorization failed S:. 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 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
C:EntityName:Domain C:DomainName:example.com C:. S:200 Command completed successfully S:. The original registrar approves the transfer request: C:transfer C:-Approve:Yes C:EntityName:Domain C:DomainName:example.com C:. S:200 Command completed successfully S:. 45 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
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;
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 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
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
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
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
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
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
; 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
; 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
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
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
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
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
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
[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: shollenb@netsol.com Manoj Srivastava Network Solutions, Inc. Registry 505 Huntmar Park Dr. Herndon, VA 20170 USA EMail: manojs@netsol.com 61
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
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
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
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
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
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
. 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
c. Bulk Transfer operations are allowed. 69
4. Nameserver functional specifications ------------------------------------ Nameserver operations for the Registry TLD shall comply with RFC 1034, 1035, and 2182. 70
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
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
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
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
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
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
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
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
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
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
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
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
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
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
(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
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
__________________________________________ __________________________________________ 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
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
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
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
Exhibit A --------- Registrar's Dispute Policy [To be supplied from time to time by Registrar] 91
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
(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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
- -------------------------------------------------------------------------------- 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
- -------------------------------------------------------------------------------- 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
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
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
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
. 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
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
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
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
(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
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
User: By: (sign) Name: (print) Title: Date: 122
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
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: registrar-agent@registrar.aol.com Whois Server: whois.compuserve.com Referral URL: domain.compuserve.com Admin Contact: Juan C Perez Phone Number: 703 265 0918 Email: webperez@aol.com Admin Contact: Ryan M Morrow Phone Number: 703 265 0910 Email: ryan@aol.net Billing Contact: Mara A Perrone Phone Number: 703-265-1337 Email: perronem@aol.com Technical Contact: Juan C Perez Phone Number: 703 265 0918 Email: webperez@aol.com Technical Contact: Ryan M Morrow Phone Number: 703 265 0910 Email: ryan@aol.net ))) 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
))) Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT ((( 125
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
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
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
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
---------------------------------------------------------------- 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
- -------------------------------------------------------------------------------- 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
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:registrar@alpha.com:::::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
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
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
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
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
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
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
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
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
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
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
(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
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
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
Phone: Fax:_______________________________ E-mail: ______________________________________________________ Internet Corporation for Assigned Names and Numbers By: Title: __________________________ Print Name:____________________________________________________ Address:______________________________________________________ ______________________________________________________ ______________________________________________________ Phone: Fax:_______________________________ E-mail: ______________________________________________________ 146
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
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
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
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
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
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
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
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
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
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
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
EXHIBIT 99.4 ------------ .NET REGISTRY AGREEMENT ----------------------- This REGISTRY AGREEMENT ("Agreement") is by and between the Internet Corporation for Assigned Names and Numbers, a not-for-profit corporation, and VeriSign, Inc. 1. DEFINITIONS. For purposes of this Agreement, the following definitions ----------- shall apply: 1.1 The "Authoritative Root-Server System" means the constellation of DNS root-nameservers specified, from time to time, in the file [ftp://ftp.internic.net/domain/named.root]. 1.2 [Deliberately left blank] 1.3 [Deliberately left blank] 1.4 The "DNS" refers to the Internet domain name system. 1.5 The "Effective Date" is the date specified as such in Section 3 of the Agreement for Restructured Relationship among ICANN, VeriSign, and Network Solutions, Inc. 1.6 The "Expiration Date" is the date specified in Subsection 5.1.1. 1.7 "ICANN" refers to the Internet Corporation for Assigned Names and Numbers, a party to this Agreement. 1.8 An "ICANN-Accredited Registrar" is an entity or person accredited by ICANN to act as a registrar for domain names within the domain of the Registry TLD. 1.9 "Personal Data" refers to data about any identified or identifiable natural person. 1.10 [Deliberately left blank] 1.11 "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). 1.12 "Registry Data" means all Registry Database data maintained in electronic form, and shall include TLD 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. 1
1.13 "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. 1.14 "Registry Operator" refers to VeriSign, Inc., a party to this Agreement, or any assignee of it under Subsection 5.11. 1.15 "Registry-Registrar Agreement" means an agreement between Registry Operator and an ICANN-Accredited Registrar with the provisions specified by Subsection 3.4. 1.16 "Registry Services" means services provided as an integral part of the operation of the Registry TLD, including all subdomains in which Registered Names are registered. These services include: receipt of data concerning registration of domain names and nameservers from registrars, provision to registrars of status information relating to the Registry TLD, dissemination of TLD zone files, operation of the Registry TLD 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 in the manner provided in Subsections 4.3 through 4.6. Registry Services shall not include the provision of nameservice for a domain used by a single entity under a Registered Name registered through an ICANN-Accredited Registrar 1.17 "Registry TLD" refers to the .net TLD. 1.18 [Deliberately left blank] 1.19 "Term of this Agreement" begins on the Effective Date and continues until the earlier of (a) the Expiration Date, or (b) termination of this Agreement. 1.20 "TLD" refers to a top-level domain in the DNS. 1.21 "TLD Zone-File Data" means all data contained in a DNS zone file 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. 2. ICANN OBLIGATIONS. ----------------- 2.1 General Obligations of ICANN. With respect to all matters that affect ---------------------------- the rights, obligations, or role of Registry Operator, ICANN shall during the Term of this Agreement: 2.1.1 exercise its responsibilities in an open and transparent manner; 2.1.2 not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition; 2
2.1.3 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 2.1.4 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. 2.2 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.3 Recognition in Authoritative Root-Server System. During the Term of this ----------------------------------------------- Agreement, Registry Operator may, by notifying ICANN, request (a) delegation of the Registry TLD to specified DNS nameservers and (b) changes in that delegation. Any such request must be made in a format, and otherwise meet technical requirements, specified from time to time by ICANN. The initial format and technical requirements are set forth in Appendix A. Changes to the format and technical requirements 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. ICANN will use commercially reasonable efforts to have such requests implemented in the Authoritative Root-Server System within five business days of the submission. 2.4 Recognition in the Root-Zone Contact Database. To the extent ICANN --------------------------------------------- publishes contact data regarding TLDs, during the Term of this Agreement it will show the Registry TLD's operator as Registry Operator and the Registry TLD's administrative and technical contacts as requested from time to time by Registry Operator. Any such request must be made in a format, include the elements of contact data, and otherwise meet technical requirements, specified from time to time by ICANN. The initial requirements for these requests are set forth in Appendix B. Changes to the requirements for requests 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. 2.5 Other Obligations of ICANN. During the Term of this Agreement, ICANN -------------------------- shall use commercially reasonable efforts to: 2.5.1 maintain, or cause to be maintained, a stable, secure, authoritative and publicly available database of relevant information regarding the delegation of the Registry TLD; 2.5.2 generate, or cause to be generated, authoritative and accurate root zone information from such database and operate, or cause to be operated, the Authoritative Root Server System in a stable and secure manner; 2.5.3 maintain, or cause to be maintained, authoritative records and an audit trail regarding delegations of the Registry TLD and records related to these delegations; and 3
2.5.4 inform Registry Operator in a timely manner of any changes to ICANN's contact information. 2.6 Use of ICANN Name. ICANN hereby grants to Registry Operator a non- ----------------- exclusive, worldwide, royalty-free license during the term of this Agreement (i) to state that it is designated by ICANN as the registry operator for the Registry TLD, (ii) to use a logo specified by ICANN to signify that Registry Operator is an ICANN-designated registry operator, and (iii) 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. 3. REGISTRY OPERATOR OBLIGATIONS. ----------------------------- 3.1 Obligation to Provide Registry Services. During the Term of this --------------------------------------- Agreement, Registry Operator shall operate, or cause to be operated, a registry of Registered Names that meets the functional specifications described by Subsection 3.2 and the performance specifications described by Subsection 3.3. Throughout the Term of this Agreement, Registry Operator shall be obligated to enter into a Registry-Registrar Agreement with any ICANN-Accredited Registrar seeking such an agreement on the terms specified by Subsection 3.4. Throughout the Term of this Agreement, Registry Operator shall provide Registry Services in compliance with any Registry-Registrar Agreement as provided in Subsection 3.4 that is then in effect. 3.2 Functional Specifications for Registry Services. All Registry Services ----------------------------------------------- provided by Registry Operator shall be provided under this Agreement and shall meet the functional specifications established by ICANN. The initial functional specifications are set forth in Appendix C. Non-material changes and additions to the functional specifications may be made by Registry Operator with prior written notice to ICANN and any affected ICANN-Accredited Registrars. All other changes and additions to the functional specifications 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. 3.3 Performance Specifications for Registry Services. All Registry Services ------------------------------------------------ provided by Registry Operator shall meet the performance specifications and comply with the registrar service level agreement established by ICANN. The initial performance specifications are set forth in Appendix D and the initial service level agreement is set forth in Appendix E. Changes to the performance specifications or service level agreement 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. 3.4 Registry-Registrar Agreements. During the Term of this Agreement, ----------------------------- Registry Operator shall enter a Registry-Registrar Agreement with any ICANN- Accredited Registrar desiring to enter such an agreement. All Registry Services provided by Registry Operator for the Registry TLD shall be provided strictly in accordance with that Registry-Registrar Agreement: 4
3.4.1 Initially, the form of the Registry-Registrar Agreement shall be that attached as Appendix F. 3.4.2 The form of the Registry-Registrar Agreement may be revised (a) by Registry Operator with the written consent of ICANN, (b) by ICANN in the manner provided in Subsections 4.3 through 4.6, provided that any additional terms are within the topics set forth in Subsection 4.2., or, (c) with respect to the price charged registrars by Registry Operator for Registry Services, according to Subsection 3.4.3. 3.4.3 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 (a) the same price shall be charged for services charged to all ICANN- Accredited Registrars (provided that volume adjustments may be made if the same opportunity to qualify for those adjustments is available to all ICANN-Accredited Registrars) and (b) the prices shall not exceed those set forth in Appendix G, as adjusted according to Subsection 4.4. Registry Operator shall charge no fee to anyone for Registry Services if such fee is not listed on Appendix G. For Registry Services (a) listed on Appendix G without a stated price, and (b) introduced more than six months after the Effective Date, Registry Operator may propose to ICANN, no later than thirty days before the commencement of that service, the inclusion in Appendix G of an offering price for the Registry Service. The offering price for the Registry Service shall be included in Appendix G only upon the written consent of ICANN, which shall not be unreasonably withheld or delayed. 3.5 Fair Treatment of ICANN-Accredited Registrars. --------------------------------------------- 3.5.1 Registry Operator shall provide all ICANN-Accredited Registrars that have Registry-Registrar Agreements in effect, 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. 3.5.2 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. 3.5.3 Registry Operator shall not act as a registrar with respect to the Registry TLD. This shall not preclude Registry Operator from registering names within the domain of the Registry TLD in compliance with Subsection 3.6. This also shall not preclude an affiliate of Registry Operator from acting as a registrar with respect to the Registry TLD, provided that Registry Operator complies with the provisions of Subsections 3.5.4 and 3.5.5. 3.5.4 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. 5
3.5.5 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 3.5.5, 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. 3.5.6 With respect to its obligations under Subsections 3.5.1 through 3.5.5 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 3.5.1 through 3.5.5 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 1 May 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. 3.6 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: 3.6.1 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 X may be revised upon written notice by Registry Operator to ICANN and written consent by ICANN, which shall not be unreasonably withheld. 3.6.2 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. 6
3.6.3 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. 3.6.4 This Subsection 3.6 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. 3.7 [Deliberately left blank] 3.8 Registration Restrictions Within Registry TLD. --------------------------------------------- 3.8.1 Except to the extent that ICANN otherwise expressly authorizes in writing, Registry Operator shall reserve from registration the domain names specified by a schedule established by ICANN. The initial schedule is attached as Appendix K. Changes to the schedule 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. 3.8.2 [Deliberately left blank] 3.9 Bulk Access to TLD Zone Files. Registry Operator shall provide bulk access ----------------------------- to the zone files for the Registry TLD as follows: 3.9.1 to third parties on the terms set forth in the TLD zone file access agreement established by ICANN. The initial terms of the agreement are set forth as Appendix N 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 3.9.2 to ICANN on a continuous basis in the manner which ICANN may from time to time specify. 3.10 Publication by Registry Operator of Registry Data. ------------------------------------------------- 3.10.1 At its expense, Registry Operator shall provide free public query- based access to up-to-date data concerning domain name and nameserver registrations 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. 7
Other changes to the specification 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. 3.10.2 To ensure operational stability of the registry, Registry Operator may temporarily limit access under Subsection 3.10.1 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. Such temporary limitations shall be applied in a non-arbitrary manner and shall apply fairly to all ICANN-Accredited Registrars. 3.10.3 In providing query-based public access to registration data as required by this Subsection 3.10, 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 3.10.4 To comply with applicable statutes and regulations and for other reasons, ICANN may from time to time establish policies in the manner described by Subsections 4.3 through 4.6 establishing limits on the data concerning registrations that Registry Operator may make available to the public through a public-access service described in this Subsection 3.10 and on the manner in which Registry Operator may make them available. In the event ICANN establishes any such policy, Registry Operator shall abide by it within the time allowed by Subsection 4.5. 3.10.5 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: 3.10.5.1 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 8
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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 3.10.5.2 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 3.11 Data Escrow. 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. 3.12 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 intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and correction of such Personal Data. Registry Operator shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. 3.13 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 supplied by or through registrars. In the event that Registry Data is released from escrow under Subsection 3.11, any rights held by Registry Operator in the data shall automatically be transferred on a non-exclusive, irrevocable, royalty-free, paid-up basis to ICANN or to a party designated in writing by ICANN. 3.14 Registry-Level Financial Support of ICANN. During the Term of this ----------------------------------------- Agreement, Registry Operator shall pay to ICANN the following fees: 9
3.14.1 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 3.14.4. 3.14.2 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 bylaws 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 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. 3.14.3 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. 3.14.4 Fee Caps. The Fixed Registry-Level Fee Cap shall be US$100,000 per -------- year until and including 30 June 2002; shall automatically increase by 15% on July 1 of each year beginning in 2002; and may be increased by a greater amount in the manner provided by Subsection 4.3. The sum of the Fixed Registry-Level Fees and the Variable Registry-Level Fees due to be paid in any year ending on any 30 June 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 30 June 2002; shall increase by 15% each fiscal year thereafter; and may be increased by a greater amount in the manner provided by Subsection 4.3. 10
3.14.5 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 Subsection 4.4) 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 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 3.14.5 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 (see Subsection 3.4) 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. 3.15 Reports Provided to ICANN. ------------------------- 3.15.1 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 3.15.2 [Deliberately left blank] 4. PROCEDURES FOR ESTABLISHMENT OR REVISION OF SPECIFICATIONS AND POLICIES. ----------------------------------------------------------------------- 4.1 Registry Operator's Ongoing Obligation to Comply With New or Revised -------------------------------------------------------------------- Specifications and Policies. During the Term of this Agreement, Registry - --------------------------- Operator shall comply, in its provision of Registry Services, on the schedule provided in Subsection 4.5, with 4.1.1 new or revised specifications (including forms of agreement to which Registry Operator is a party) and policies established by ICANN as Consensus Policies in the manner described in Subsection 4.3, 4.1.2 in cases where: 11
4.1.2.1 this Agreement expressly provides for compliance with revised specifications or policies established in the manner set forth in one or more subsections of this Section 4 or 4.1.2.2 the specification or policy concerns one or more topics described in Subsection 4.2. 4.2 Topics for New and Revised Specifications and Policies. New and revised ------------------------------------------------------ specifications and policies may be established on the following topics: 4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of the Registry Services, the DNS, or the Internet; 4.2.2 functional and performance specifications for the provision of Registry Services; 4.2.3 safety and integrity of the Registry Database; 4.2.4 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving Registered Names affected by such a suspension or termination; 4.2.5 resolution of disputes regarding whether particular parties may register or maintain registration of particular domain names; 4.2.6 principles for allocation of SLD names (e.g., first-come/first- served, timely renewal, holding period after expiration); 4.2.7 prohibitions on warehousing of or speculation in domain names by registries or registrars; 4.2.8 maintenance of and access to accurate and up-to-date contact information for domain name registrants; 4.2.9 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., establishment of reservations of names from registration); and 4.2.10 registry policies reasonably necessary to implement Consensus Policies relating to registrars. 4.3 Manner of Establishment of New and Revised Specifications and Policies. ---------------------------------------------------------------------- 12
4.3.1 "Consensus Policies" are those specifications or policies established based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (a) action of the ICANN Board of Directors establishing the specification or policy, (b) 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 (c) 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 policy. 4.3.2 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 establishing the policy. The decision of the panel shall be based on the report and supporting materials required by Subsection 4.3.1. In the event that Registry Operator seeks review and the Independent Review Panel sustains the Board's determination that the policy is based on a consensus among Internet stakeholders represented in the ICANN process, then Registry Operator must implement such policy unless it promptly seeks and obtains a stay or injunctive relief under Subsection 5.9. 4.3.3 If, following a decision by the Independent Review Panel convened under Subsection 4.3.2, 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 Subsection 5.9; provided, however, that Registry Operator must continue to implement the policy unless it has obtained a stay or injunctive relief under Subsection 5.9 or a final decision is rendered in accordance with the provisions of Subsection 5.9 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 Subsection 4.3.1. 4.3.4 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 13
its reasons for establishing the temporary specification or policy and why the Board believes the policy should receive the consensus support of Internet stakeholders. If the period of time for which the specification or policy is adopted exceeds ninety days, the Board shall reaffirm its temporary establishment every ninety days for a total period not to exceed one year, in order to maintain such specification or policy in effect until such time as it meets the standard set forth in Subsection 4.3.1. If the standard set forth in Subsection 4.3.1 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 temporary specification or policy, it will no longer be a "Consensus Policy." 4.3.5 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." 4.3.6 In the event that, at the time the ICANN Board of Directors establishes a specification or policy under Subsection 4.3.1 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 4.3.2 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 ICANN with the specification or policy in the interim. 4.4 Pricing Adjustments Arising from New or Revised Specifications or Policies. -------------------------------------------------------------------------- The maximum prices stated in Appendix G 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 demonstrated increases in the net costs of providing Registry Services arising from (A) new or revised ICANN specifications or policies adopted after the Effective Date, or (B) 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 (A) or (B) above. 4.5 Time Allowed for Compliance. 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 Subsection 4.3 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 Subsection 4.3 in which to comply with that specification or policy, taking into account any urgency involved. 4.6 Indemnification of Registry Operator. 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, without limitation, 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 14
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 Subsection 4.6, ICANN may, at the time it establishes a specification or policy after the Effective Date giving rise to an indemnity obligation under this Subsection 4.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 Subsection 4.6, in which case the reasonable cost to Registry Operator of such insurance shall be treated under Subsection 4.4 as a cost of providing Registry Services arising from the newly established ICANN specification or policy. 5. MISCELLANEOUS PROVISIONS. ------------------------ 5.1 Expiration of this Agreement. ---------------------------- 5.1.1 The Expiration Date shall be 30 June 2005, provided, however, that the Expiration Date may be adjusted under the following circumstances: 5.1.1.1 31 December 2002 Measurement Date. ---------------------------------- 5.1.1.1.1 The total number of Registered Names for .biz, .info, .name and .pro TLDs as of 31 December 2002, as numerator, shall be compared to the total number of Registered Names for .biz, .info, .name, .pro, .com and .net TLDs as of 31 December 2002, as denominator. 5.1.1.1.2 The net new registrations of Registered Names in the .com and .net TLDs (i.e., the net increase in the number of Registered Names sponsored in the registry) sponsored by the NSI Registrar for the period 1 January 2002 through 31 December 2002, as numerator, shall be compared to the total net new registrations of Registered Names sponsored by all ICANN- accredited registrars, including the NSI Registrar, in the .com and .net TLDsfor the same period, as denominator. 5.1.1.1.3 The Expiration Date shall remain 30 June 2005 and no further measurements will be required if: 5.1.1.1.3.1 the share of Registered Names in the .biz, .info, .name and .pro TLDs, measured pursuant to Subsection 5.1.1.1.1, is 15% or more, or 5.1.1.1.3.2 the NSI Registrar share of net new registrations of Registered Names in .com and .net, measured pursuant to Subsection 5.1.1.1.2, is 20% or less; and ICANN determines that the Registry Operator is in compliance with its obligations under Section 3.5 of this Registry Agreement, in accordance with paragraph 8 of Appendix I. 15
5.1.1.1.4 The Expiration Date shall remain 30 June 2005, but a subsequent measurement will be required on 31 March 2004, as set forth in Subsection 5.1.1.1.1 if: 5.1.1.1.4.1 the share of total Registered Names in the .biz, .info, .name and .proTLDs, measured pursuant to Subsection 5.1.1.1.1, is 10% or more, or 5.1.1.1.4.2 the NSI Registrar share of net new registrations of Registered Names in .com and .net, measured pursuant to Subsection 5.1.1.1.2, is 25% or less; and ICANN determines that the Registry Operator is in compliance with its obligations under Section 3.5 of this Registry Agreement, in accordance with paragraph 8 of Appendix I. 5.1.1.1.5 The Expiration Date shall be adjusted to 10 November 2003 if: 5.1.1.1.5.1 the share of total Registered Names in the .biz, .info, .name and .proTLDs, measured pursuant to Subsection 5.1.1.1.1, is less than 10%, and 5.1.1.1.5.2 the NSI Registrar's share of net new registrations of Registered Names in .com and .net, measured pursuant to Subsection 5.1.1.1.2, is more than 25%; or ICANN determines that Registry Operator is not in compliance with its obligations under Section 3.5 of this Registry Agreement, in accordance with paragraph 8 of Appendix I. 5.1.1.2 31 March 2004 Measurement Date. In the event a subsequent ------------------------------ measurement as set forth in Subsection 5.1.1.1.4 is required, the subsequent measurement shall be calculated as follows: 5.1.1.2.1 The total number of Registered Names in all unsponsored gTLDs introduced by ICANN after 1 January 2001, including but not limited to .biz, .info, .name and .pro but not including .com and .net, as numerator, shall be compared to the total number of Registered Names in all unsponsored gTLDs recognized by ICANN, including .com and .net but not including .org, as denominator. 5.1.1.2.2 The net new registrations of Registered Names in the .com and .net TLDs (i.e., the net increase in the number of Registered Names sponsored in the registry) sponsored by the NSI Registrar for the period 1 April 2003 through 31 March 16
2004, as numerator, shall be compared to the total net new registrations of Registered Names sponsored by all ICANN-accredited registrars, including the NSI Registrar, in the .com and .net TLDs for the same period, as denominator. 5.1.1.2.3 The Expiration Date shall remain 30 June 2005 if: 5.1.1.2.3.1 the share of Registered Names in all unsponsored gTLDs introduced by ICANN after 1 January 2001, measured pursuant to Subsection 5.1.1.2.1, is 13% or more, or 5.1.1.2.3.2 the NSI Registrar share of net new registrations of Registered Names, measured pursuant to Subsection 5.1.1.2.2, is 22% or less; and ICANN determines that Registry Operator is in compliance with its obligations under Section 3.5 of this Registry Agreement, in accordance with paragraph 8 of Appendix I. 5.1.1.2.4 The Expiration Date shall be adjusted to 1 January 2005 if: 5.1.1.2.4.1 the share of Registered Names in all unsponsored gTLDs introduced by ICANN after 1 January 2001, measured pursuant to Subsection 5.1.1.2.1, is less than 13%, and 5.1.1.2.4.2 the NSI Registrar share of net new registrations of Registered Names, measured pursuant to Subsection 5.1.1.1.2, is more than 22%; or ICANN determines that Registry Operator is not in compliance with its obligations under Section 3.5 of this Registry Agreement, in accordance with paragraph 8 of Appendix I. 5.1.1.3 ICANN shall perform the measurements described in Subsections 5.1.1.1.1 and 5.1.1.1.2 above on a quarterly basis, and report the results to Registry Operator on a confidential basis. 5.1.2 Registry Operator acknowledges and agrees that upon the earlier of (i) the Expiration Date or (ii) termination of this Agreement by ICANN pursuant to Subsection 5.4, it will cease to be the operator of the Registry TLD unless ICANN and Registry Operator enter a new registry agreement continuing Registry Operator's status as operator of the Registry TLD. 5.1.3 Upon conclusion of its status as operator of the Registry TLD, Registry Operator shall make all commercially reasonable efforts to cooperate with ICANN, 17
and with any party designated by ICANN as successor operator, to facilitate prompt and smooth transition of the operation of the Registry TLD. 5.1.4 Registry Operator acknowledges and agrees that, except as expressly provided by this Agreement, it shall not acquire any right in the Registry TLD by virtue of its operation of the Registry TLD or its provision of Registry Services hereunder. 5.2 Procedure for Subsequent Agreement. ---------------------------------- 5.2.1 Not later than one year prior to the end of the term of this Agreement, ICANN shall, in accordance with Section 2.1, adopt an open, transparent procedure for designating a successor Registry Operator. The requirement that this procedure be opened one year prior to the end of the Agreement shall be waived in the event that the Agreement is terminated prior to its expiration. 5.2.2 Registry Operator or its assignee shall be eligible to serve as the successor Registry Operator and neither the procedure established in accordance with subsection 5.2.1 nor the fact that Registry Operator is the incumbent shall disadvantage Registry Operator in comparison to other entities seeking to serve as the successor Registry. 5.2.3 If Registry Operator or its assignee is not designated as the successor Registry Operator, Registry Operator or its assignee shall cooperate with ICANN and with the successor Registry Operator in order to facilitate the smooth transition of operation of the registry to successor Registry Operator. Such cooperation shall include the timely transfer to the successor Registry Operator of an electronic copy of the Registry Database and of a full specification of the format of the data. 5.2.4 ICANN shall select as the successor Registry Operator the eligible party that it reasonably determines is best qualified to perform the registry function under terms and conditions developed pursuant to Subsection 4.3 of this Agreement, taking into account all factors relevant to the stability of the Internet, promotion of competition, and maximization of consumer choice, including without limitation: functional capabilities and performance specifications proposed by the eligible party for its operation of the registry, the price at which registry services are proposed to be provided by the party, the relevant experience of the party, and the demonstrated ability of the party to manage domain name or similar databases at the required scale. 5.2.5 In the event that a party other than Registry Operator or its assignee is designated as the successor Registry Operator, Registry Operator shall have the right to challenge the reasonableness of ICANN's failure to designate Registry Operator or its assignee as the successor Registry Operator pursuant to Section 5.9 below. Any such challenge must be filed within 10 business days following any such designation, and shall be decided on a schedule that will produce a final decision no later than 60 days following any such challenge. 18
5.3 [Deliberately left blank] 5.4 Termination by ICANN. This Agreement may be terminated before its -------------------- expiration by ICANN in any of the following circumstances: 5.4.1 [Deliberately left blank] 5.4.2 Registry Operator: 5.4.2.1 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 5.4.2.2 is disciplined by the government of its domicile for conduct involving dishonesty or misuse of funds of others. 5.4.3 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. 5.4.4 Registry Operator fails to cure any material breach of this Agreement (other than a failure to comply with a Consensus Policy adopted by ICANN during the Term of this Agreement as to which Registry Operator has obtained a stay under Subsection 5.9) within fifteen business days (or such longer reasonable period as may be necessary using best efforts to cure such breach) after ICANN gives Registry Operator written notice of the breach. 5.4.5 Registry Operator's action or failure to act has been determined under Subsection 5.9 to be in violation of this Agreement and Registry Operator continues to act or fail to act in the manner that was determined to violate this Agreement for a period stated in the arbitration decision, or if no period is stated, fifteen business days. 5.4.6 Registry Operator acts or continues acting in a manner that ICANN has reasonably determined endangers the operational stability of Registry Services, the DNS, or the Internet after receiving three days notice of that determination. 5.4.7 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. 5.4.8 Registry Operator becomes bankrupt or insolvent. 5.4.9 This Agreement may be terminated in the circumstances described in Subsections 5.4.1 through 5.4.7 above only upon thirty calendar days written notice 19
to Registry Operator (in the case of the circumstances described in Subsections 5.4.4, 5.4.5, and 5.4.6 occurring after Registry Operator's failure to cure), with Registry Operator being given an opportunity during that time to initiate arbitration under Subsection 5.9 to determine the appropriateness of termination under this Agreement. In the event Registry Operator initiates arbitration concerning the appropriateness of termination by ICANN, Registry Operator may at the same time request that the arbitration panel stay the termination until the arbitration decision is rendered, and that request shall have the effect of staying the requirement until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay. If Registry Operator acts in a manner that ICANN reasonably determines endangers the operational stability of Registry Services, the DNS, or the Internet and upon notice does not immediately cure, ICANN may suspend this Agreement for five calendar days pending ICANN's application for more extended injunctive relief under Subsection 5.9. This Agreement may be terminated immediately upon notice to Registry Operator in the circumstance described in Subsection 5.4.8. 5.5 [Deliberately left blank] 5.6 Additional Covenants of Registry Operator. Throughout the Term of this ----------------------------------------- Agreement, Registry Operator shall abide by the covenants contained in Appendix W. 5.7 Indemnification of ICANN. Registry Operator shall indemnify, defend, and ------------------------ hold harmless ICANN (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 out of or relating to: (a) the selection of Registry Operator to operate the Registry TLD; (b) the entry of this Agreement; (c) establishment or operation of the Registry TLD; (d) Registry Services; (e) collection or handling of Personal Data by Registry Operator; (f) any dispute concerning registration of a domain name within the domain of the Registry TLD; and (g) duties and obligations of Registry Operator in operating the Registry TLD; provided that, with respect to items (b) through (g) only, Registry Operator shall not be obligated to indemnify, defend, or hold harmless ICANN to the extent of ICANN's indemnification of Registry Operator under Subsection 4.6 and provided further that, with respect to item (g) only, Registry Operator shall not be obligated to indemnify, defend, or hold harmless ICANN to the extent the claim, damage, liability, cost, or expense arose due to a breach by ICANN of any obligation contained in this Agreement. For avoidance of doubt, nothing in this Subsection 5.7 shall be deemed to require Registry Operator to reimburse or otherwise indemnify ICANN for the costs associated with the negotiation or execution of this Agreement, or with the monitoring of the parties' respective obligations under this Agreement. 5.8 Indemnification Procedures. If any third-party claim is commenced that is -------------------------- indemnified under Subsections 4.6 or 5.7, notice thereof shall be given to the indemnifying party as promptly as practicable. If, after such notice, the indemnifying party acknowledges its obligation to indemnify with respect to such claim, then the indemnifying party shall be entitled, if it so elects, in a notice promptly delivered to the indemnified party, to immediately take control of the defense and investigation of such 20
claim and to employ and engage attorneys reasonably acceptable to the indemnified party to handle and defend the same, at the indemnifying party's sole cost and expense, provided that in all events ICANN shall be entitled to control at its sole cost and expense the litigation of issues concerning the validity or interpretation of ICANN policies or conduct. The indemnified party shall cooperate, at the cost of the indemnifying party, in all reasonable respects with the indemnifying party and its attorneys in the investigation, trial, and defense of such claim and any appeal arising therefrom; provided, however, that the indemnified party may, at its own cost and expense, participate, through its attorneys or otherwise, in such investigation, trial and defense of such claim and any appeal arising therefrom. No settlement of a claim that involves a remedy affecting the indemnifying party other than the payment of money in an amount that is indemnified shall be entered into without the consent of the indemnified party. If the indemnifying party does not assume full control over the defense of a claim subject to such defense in accordance with this Subsection, the indemnifying party may participate in such defense, at its sole cost and expense, and the indemnified party shall have the right to defend the claim in such manner as it may deem appropriate, at the cost and expense of the indemnifying party. 5.9 Resolution of Disputes Under This Agreement. Disputes arising under or in ------------------------------------------- connection with this Agreement, including requests for specific performance, shall be referred in the first instance to arbitration conducted as provided in this Subsection 5.9 pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce ("ICC"). The arbitration shall be conducted in the English language and shall occur in Los Angeles County, California, USA. There shall be three arbitrators: each party shall choose one arbitrator and, if the two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The 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 ICC 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. Either party, if dissatisfied with the result of the arbitration, may challenge that result by bringing suit against the other party in a court located in Los Angeles, California, USA to enforce its rights under this Agreement. In all litigation involving ICANN concerning this Agreement (as provided in the remainder of this Subsection), 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 a temporary stay or 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. 5.10 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 Subsection 3.14. Registry Operator's aggregate monetary liability to ICANN for violations of this Agreement shall be limited to fees and monetary sanctions due and 21
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 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. 5.11 Assignment. Any assignment of this Agreement shall be effective only upon ---------- written agreement by the assignee with the other party to assume the assigning party's obligations under this Agreement. Moreover, neither party may assign this Agreement without the prior written approval of the other party. Notwithstanding the foregoing, a party may assign this Agreement by giving written notice to the other party in the following circumstances: (a) Registry Operator may assign this Agreement as part of the transfer of its registry business if such transfer and assignment are approved in advance by ICANN pursuant to its procedures, and (b) ICANN may assign this Agreement, (i) in conjunction with a reorganization or re-incorporation of ICANN, to another non- profit corporation organized for the same or substantially the same purposes as ICANN or (ii) as required by Section 5 of Amendment 1 (dated 10 November 1999) to the 25 November 1998, Memorandum of Understanding between ICANN and the United States Department of Commerce. 5.12 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. 5.13 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, lightning, 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. 22
5.14 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 SLD holder. 5.15 Notices, Designations, and Specifications. All notices (including ----------------------------------------- determinations, designations, and specifications) 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 an 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. 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 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 21345Ridgetop 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 5.16 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. 23
5.17 Language. All notices, designations, determinations, and specifications -------- made under this Agreement shall be in the English language. 5.18 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. 5.19 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. 5.20 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. 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: VERISIGN, INC. By:__________________________ Stratton Sclavos President and CEO Date: 24
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 root-mgmt@iana.org. 2. Requests should be submitted by filling out the template available at
. 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) 25 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 root-mgmt@iana.org>. 2. Requests should be submitted by filling out the template available at
. 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) 26 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. 27
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 [majordomo@NSIRegistry.com] 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/maillist/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, 28
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 29
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. 30
- 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. 31
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:. 32
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: 33
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
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 attributeName:attributeValue 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 34 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. .
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 responseDescription [attributeName:attributeValue ] . 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. 35 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
C:EntityName:Domain C:DomainName:example.com C:-Period:10 C:. S:200 Command completed successfully S:registration expiration date:2009-09-22 10:27:00.0 S:status:ACTIVE S:. 36 A registrar registers a domain name using previously-registered name servers: C:add
C:EntityName:Domain C:DomainName:example2.com C:-Period:10 C:NameServer:ns1.example.com C:NameServer:ns2.example.com C:. S:200 Command completed successfully S:registration expiration date:2000-09-22 10:27:00.0 S:status:ACTIVE S:. 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. 37 Examples A registrar registers a new name server in an existing domain name: C:add
C:EntityName:NameServer C:NameServer:ns1.example.com C:IPAddress:198.41.1.11 C:. S:200 Command completed successfully S:. 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 C:EntityName:Domain C:DomainName:example.com C:. S:211 Domain name not available S:. 38 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
C:EntityName:Nameserver C:Nameserver:ns1.example.com C:. S:213 Name server not available S:ipAddress:192.10.10.10 S:. 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. 39 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
C:EntityName:Domain C:DomainName:example.com C:. S:200 Command completed successfully S:. 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 C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:. S:200 Command completed successfully S:. 40 A registrar tries to delete a name server that is hosting domains: C:del
C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:. S:532 Domain names linked with name server S:. 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 C:-Target:Protocol C:. S:200 Command completed successfully S:Protocol:RRP 1.1.0 S:. 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. 41 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
C:EntityName:Domain C:DomainName:example.com C:NameServer:ns3.registrarA.com C:NameServer:ns1.registrarA.com= C:. S:200 Command completed successfully S:. 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. 42 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
C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:NewNameServer:ns2.registrarA.com C:IPAddress:198.42.1.11 C:IPAddress:198.41.1.11= C:. S:200 Command completed successfully S:. 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 C:. S:220 Command completed successfully. Server closing connection S:. 43 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
C:EntityName:Domain C:DomainName:example.com C:-Period:9 C:-CurrentExpirationYear:2001 C:. S:200 Command completed successfully S:registration expiration date:2010-09-22 10:27:00.0 S:. 44 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
C:-Id:registrarA C:-Password:i-am-registrarA C:. S:200 Command completed successfully S:. 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. 45 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
C:EntityName:Domain C:DomainName:example.com C:. S:200 Command completed successfully S:nameserver:ns2.registrarA.com S:nameserver:ns3.registrarA.com S:registration expiration date:2010-09-22 10:27:00.0 S:registrar:registrarA S:registrar transfer date:1999-09-22 10:27:00.0 S:status:ACTIVE S:created date:1998-09-2 10:27:00.0 S:created by:registrarA S:updated date:2002-09-22 10:27:00.0 S:updated by:registrarA S:. 46 A registrar queries a domain name currently registered by another registrar: C:status
C:EntityName:Domain C:DomainName:example.com C:. S:531 Authorization failed S:. 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 C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:. 47 S:200 Command completed successfully
S:ipaddress:198.42.1.11 S:registrar:registrarA S:registrar transfer date:1999-09-22 10:27:00.0 S:CreatedDate:1998-09-22 10:27:00.0 S:CreatedBy:registrarA S:UpdatedDate:2002-09-22 10:27:00.0 S:UpdatedBy:registrarA S:. A registrar queries a name server that was registered by another registrar: C:status C:EntityName:NameServer C:NameServer:ns1.registrarA.com C:. S:531 Authorization failed S:. 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 48 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) 49
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. 50
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 51
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. 52
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. 53
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. 54
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 55
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. 56
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. 57
; 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" 58
; 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 59
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) 60
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 = 61
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. 62
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. 63
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. 64
[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: shollenb@netsol.com Manoj Srivastava Network Solutions, Inc. Registry 505 Huntmar Park Dr. Herndon, VA 20170 USA EMail: manojs@netsol.com 65
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. 66
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. 67
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 68
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. 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. 69
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. 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. 70
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 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. 71
. 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 . 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 72
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. c. Bulk Transfer operations are allowed. 73
4. Nameserver functional specifications ------------------------------------ Nameserver operations for the Registry TLD shall comply with RFC 1034, 1035, and 2182. 74
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. 75
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. 76
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. 77
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. 78
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, 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 79
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 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. 80
(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 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. 81
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 .net 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 .net 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 82
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 .net 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; 83
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. 84
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. 85
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 ---------------- 86
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). 87
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 --------------------- this Agreement shall apply from the Effective Date through and including the last day of the calendar month sixty (60) months from the Effective Date (the "Initial Term"). Upon conclusion of the Initial Term, all provisions of this Agreement will automatically renew for successive five (5) year renewal periods until the Agreement has been terminated as provided herein, Registrar elects not to renew, or 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. 88
(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 89
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: __________________________________________ __________________________________________ __________________________________________ __________________________________________ 90
__________________________________________ __________________________________________ 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. 91
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 92
and perform its obligations under this Agreement, (3) the execution, performance 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. 93
6.17. Entire Agreement; Severability. This Agreement, which includes Exhibits A, ------------------------------ B, and C, constitutes the entire agreement between the Parties concerning the subject matter hereof and supersedes any prior agreements, representations, statements, negotiations, understandings, proposals or undertakings, oral or written, with respect to the subject matter expressly set forth herein. If any provision of this Agreement shall be held to be illegal, invalid or unenforceable, each Party agrees that such provision shall be enforced to the maximum extent permissible so as to effect the intent of the Parties, and the validity, legality and enforceability of the remaining provisions of this Agreement shall not in any way be affected or impaired thereby. If necessary to effect the intent of the Parties, the Parties shall negotiate in good faith to amend this Agreement to replace the unenforceable language with enforceable language that reflects such intent as closely as possible. 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:______________________ 94
Exhibit A --------- Registrar's Dispute Policy [To be supplied from time to time by Registrar] 95
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: 96
(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. 97
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 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. 98
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 99
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 100
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. 101
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:_____________________________ 102
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 3.4.3 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). 103
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 Certificat ion is dated this the __ day of __________, _____. VeriSign, Inc. By: __________________________ Name: Bruce Chovnick Title: General Manager, VeriSign Global Registry Services 104
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. 105
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 106
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. 107
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 108
D. Corporate Communication, such as: 1. Information posted on the Vault 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. 109
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. 110
Each VeriSign employee should exercise reasonable care to protect Proprietary Information, Registry Sensitive information and Registrar Sensitive information from unauthorized or inadvertent disclosure. 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 111
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. 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 112
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. 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 113
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. 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. 114
- -------------------------------------------------------------------------------- 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: __________________________ __________________________ General Manager, Registry Employee Date Date 115
- -------------------------------------------------------------------------------- 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 116
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 .net TLD. 2. All registrars accredited by ICANN who are authorized to register domain names in the .net 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 Subsections 3.6.1 and 3.6.2 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 .net TLD will not be shared with employees of any ICANN-accredited registrar, except as necessary for registry management and operations. 117
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 3.5 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 3.5 if: (1) any material breach(es) of Section 3.5 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. 118
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 119
. 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 3.6.1, but upon conclusion of 120
Registry Operator's designation as operator of the registry for the Registry TLD they shall be transferred as specified by ICANN: . nic . whois . www 121
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 122
services, and distribute those products or services for a purpose not prohibited under Section 4 below. 3. TERM This Agreement is effective for a period of three (3) months from the date of execution by 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. 123
(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. 124
10. NO CONSEQUENTIAL DAMAGES 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: 125
Date: User: By: (sign) Name: (print) Title: Date: 126
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.net top-level domain and for all hosts registered using these names. This service is available to anyone. It is available via port 43 access and via links at the 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: . Domain name including the TLD (e.g., verisign-grs.com) . Full name of the registrar including punctuation, "Inc.", etc. (e.g., America Online, Inc.) . Full host name or the IP address (e.g., ns1.crsnic.net or 198.41.3.39) . Click on the "submit" button. For all registered second-level domain names in .net, 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 127
Referral URL: www.networksolutions.com Name Server: NS1.CRSNIC.NET 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 .net 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: registrar-agent@registrar.aol.com Whois Server: whois.compuserve.com Referral URL: domain.compuserve.com Admin Contact: Juan C Perez Phone Number: 703 265 0918 Email: webperez@aol.com Admin Contact: Ryan M Morrow Phone Number: 703 265 0910 Email: ryan@aol.net Billing Contact: Mara A Perrone Phone Number: 703-265-1337 Email: perronem@aol.com Technical Contact: Juan C Perez Phone Number: 703 265 0918 Email: webperez@aol.com Technical Contact: Ryan M Morrow Phone Number: 703 265 0910 Email: ryan@aol.net ))) Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT ((( For all hosts registered using second-level domain names in .net, 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 128
Referral URL: www.networksolutions.com ))) Last update of whois database: Wed, 11 Apr 2001 08:39:18 EDT ((( 129
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. 130
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. 131
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. 132
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 Megabytes up to 750 Megabytes - ------------------------------------------------------------------------------- 133
- ------------------------------------------------------------------------------- Forecasted 2001 Data Escrow Size up to 75 Megabytes up to 1 Gigabytes - ------------------------------------------------------------------------------- Total Forecasted Escrow Size up to 110 Megabytes up to 4 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 jpaddress. Fields: servername ipaddress Examples: - -------------------------------------------------------------------------------- 134
- -------------------------------------------------------------------------------- NS.ALPHA.COM:111.222.333.001 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 - -------------------------------------------------------------------------------- 135
EMAIL 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:registrar@alpha.com:::::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 - -------------------------------------------------------------------------------- 136
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 - -------------------------------------------------------------------------------- 137
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 138
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 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 $ ________ $ ________ - -------------------------------------------------------------------------------- 139
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. 140
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. 141
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 Reportf. 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. c. Correctness 142
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. 143
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 fail the verification procedures, Escrow Agent shall notify ICANN of such nonconformity within forty-eight (48) hours. 144
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 Subsection 5.4 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 Subsection 5.9 of the Registry Agreement has been obtained) that VGRS will not be designated as the successor registry under Subsection 5.2 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 paragraph 4.1(a), deliver the Deposit Materials and Outstanding Additional Deposits in accordance with the applicable instructions. 145
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 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 146
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. (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. 147
(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 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. 148
(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 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. 149
IN WITNESS WHEREOF each of the parties has caused its duly authorized officer to execute this Agreement as of the date and year first above written. Escrow Agent By: _____________________ Title:____________________ Print Name:____________________________________________________ Address:______________________________________________________ _______________________________________________________ _______________________________________________________ Phone: Fax:_______________________________ E-mail: _______________________________________________________ VeriSign, Inc. By: _____________________ Title:____________________ Print Name:___________________________________________________ Address:______________________________________________________ _______________________________________________________ _______________________________________________________ Phone: Fax:_______________________________ E-mail: _______________________________________________________ Internet Corporation for Assigned Names and Numbers By: Title:___________________________ 150
Print Name:______________________________________________________ Address:_________________________________________________________ _________________________________________________________ _________________________________________________________ Phone: Fax:_________________________________ E-mail: _________________________________________________________ 151
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: 152
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 3.6.1 and 3.6.2 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. 153
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.) 154
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. 155
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 31 December 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 10 November 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 31 December 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 31 December 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 3.4.3 until such time as ICANN authorizes Registry Operator to do so. 156
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. 157
Appendix Y ---------- Sanctions Program ----------------- This document describes a program (the "Sanctions Program") under which violations of Subsections 3.5.1 through 3.5.5 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; 158
2. A statement of the possible violation of Subsections 3.5.1 through 3.5.5 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; 159
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 3.5.1 through 3.5.5 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 person appointed by the Registry Operator to receive communications concerning the investigation, and shall be posted on ICANN's website, with appropriate redactions for 160
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 3.5.1 through 3.5.5 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 for each major violation found. The amount of the financial sanction shall be proportionate to the violation and other relevant facts. 161
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 Subsection 5.9 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 Subsection 5.9 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 5.4.7 of the Registry Agreement. 162
EXHIBIT 99.5 ------------ NOTICE REGARDING OMITTED EXHIBITS AND APPENDICES Pursuant to Item 601 of Regulation S-K, Registrant omits from this Current Report on Form 8-K the exhibits and appendices to Exhibit 99.5 (.org Registry Agreement), which are substantially identical in all material respects to the exhibits and appendices attached to Exhibit 99.4 (.net Registry Agreement) filed herewith. 1
EXHIBIT 99.5 ------------ .ORG REGISTRY AGREEMENT ----------------------- This REGISTRY AGREEMENT ("Agreement") is by and between the Internet Corporation for Assigned Names and Numbers, a not-for-profit corporation, and VeriSign, Inc. 1. DEFINITIONS. For purposes of this Agreement, the following definitions shall ----------- apply: 1.1 The "Authoritative Root-Server System" means the constellation of DNS root- nameservers specified, from time to time, in the file [ftp://ftp.internic.net/domain/named.root]. 1.2 [Deliberately left blank] 1.3 [Deliberately left blank] 1.4 The "DNS" refers to the Internet domain name system. 1.5 The "Effective Date" is the date specified as such in Section 3 of the Agreement for Restructured Relationship among ICANN, VeriSign, and Network Solutions, Inc. 1.6 The "Expiration Date" is the date specified in Subsection 5.1.1. 1.7 "ICANN" refers to the Internet Corporation for Assigned Names and Numbers, a party to this Agreement. 1.8 An "ICANN-Accredited Registrar" is an entity or person accredited by ICANN to act as a registrar for domain names within the domain of the Registry TLD. 1.9 "Personal Data" refers to data about any identified or identifiable natural person. 1.10 [Deliberately left blank] 1.11 "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 Registry Services maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. A name in a Registry Database may be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but ---- inactive name). 1.12 "Registry Data" means all Registry Database data maintained in electronic form, and shall include TLD 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. 2
1.13 "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. 1.14 "Registry Operator" refers to VeriSign, Inc., a party to this Agreement, or any assignee of it under Subsection 5.11. 1.15 "Registry-Registrar Agreement" means an agreement between Registry Operator and an ICANN-Accredited Registrar with the provisions specified by Subsection 3.4. 1.16 "Registry Services" means services provided as an integral part of the operation of the Registry TLD, including all subdomains in which Registered Names are registered. These services include: receipt of data concerning registration of domain names and nameservers from registrars, provision to registrars of status information relating to the Registry TLD, dissemination of TLD zone files, operation of the Registry TLD 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 in the manner provided in Subsections 4.3 through 4.6. Registry Services shall not include the provision of nameservice for a domain used by a single entity under a Registered Name registered through an ICANN-Accredited Registrar. 1.17 "Registry TLD" refers to the .org TLD. 1.18 [Deliberately left blank] 1.19 "Term of this Agreement" begins on the Effective Date and continues until the earlier of (a) the Expiration Date, or (b) termination of this Agreement. 1.20 "TLD" refers to a top-level domain in the DNS. 1.21 "TLD Zone-File Data" means all data contained in a DNS zone file for the Registry TLD, or for any subdomain for which Registry Services registered names, as provided to TLD nameservers on the Internet. 2. ICANN OBLIGATIONS. ----------------- 2.1 General Obligations of ICANN. With respect to all matters that affect the ---------------------------- rights, obligations, or role of Registry Operator, ICANN shall during the Term of this Agreement: 2.1.1 exercise its responsibilities in an open and transparent manner; 2.1.2 not unreasonably restrain competition and, to the extent feasible, promote and encourage robust competition; 3
2.1.3 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 2.1.4 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. 2.2 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.3 Recognition in Authoritative Root-Server System. During the Term of this ----------------------------------------------- Agreement, Registry Operator may, by notifying ICANN, request (a) delegation of the Registry TLD to specified DNS nameservers and (b) changes in that delegation. Any such request must be made in a format, and otherwise meet technical requirements, specified from time to time by ICANN. The initial format and technical requirements are set forth in Appendix A. Changes to the format and technical requirements 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. ICANN will use commercially reasonable efforts to have such requests implemented in the Authoritative Root-Server System within five business days of the submission. 2.4 Recognition in the Root-Zone Contact Database. To the extent ICANN publishes --------------------------------------------- contact data regarding TLDs, during the Term of this Agreement it will show the Registry TLD's operator as Registry Operator and the Registry TLD's administrative and technical contacts as requested from time to time by Registry Operator. Any such request must be made in a format, include the elements of contact data, and otherwise meet technical requirements, specified from time to time by ICANN. The initial requirements for these requests are set forth in Appendix B. Changes to the requirements for requests 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. 2.5 Other Obligations of ICANN. During the Term of this Agreement, ICANN shall -------------------------- use commercially reasonable efforts to: 2.5.1 maintain, or cause to be maintained, a stable, secure, authoritative and publicly available database of relevant information regarding the delegation of the Registry TLD; 2.5.2 generate, or cause to be generated, authoritative and accurate root zone information from such database and operate, or cause to be operated, the Authoritative Root Server System in a stable and secure manner; 4
2.5.3 maintain, or cause to be maintained, authoritative records and an audit trail regarding delegations of the Registry TLD and records related to these delegations; and 2.5.4 inform Registry Operator in a timely manner of any changes to ICANN's contact information. 2.6 Use of ICANN Name. ICANN hereby grants to Registry Operator a non-exclusive, ----------------- worldwide, royalty-free license during the term of this Agreement (i) to state that it is designated by ICANN as the registry operator for the Registry TLD, (ii) to use a logo specified by ICANN to signify that Registry Operator is an ICANN-designated registry operator, and (iii) 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. 3. REGISTRY OPERATOR OBLIGATIONS. ----------------------------- 3.1 Obligation to Provide Registry Services. During the Term of this Agreement, --------------------------------------- Registry Operator shall operate, or cause to be operated, a registry of Registered Names that meets the functional specifications described by Subsection 3.2 and the performance specifications described by Subsection 3.3. Throughout the Term of this Agreement, Registry Operator shall be obligated to enter into a Registry-Registrar Agreement with any ICANN-Accredited Registrar seeking such an agreement on the terms specified by Subsection 3.4. Throughout the Term of this Agreement, Registry Operator shall provide Registry Services in compliance with any Registry-Registrar Agreement as provided in Subsection 3.4 that is then in effect. 3.2 Functional Specifications for Registry Services. All Registry Services ----------------------------------------------- provided by Registry Operator shall be provided under this Agreement and shall meet the functional specifications established by ICANN. The initial functional specifications are set forth in Appendix C. Non-material changes and additions to the functional specifications may be made by Registry Operator with prior written notice to ICANN and any affected ICANN-Accredited Registrars. All other changes and additions to the functional specifications 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. 3.3 Performance Specifications for Registry Services. All Registry Services ------------------------------------------------ provided by Registry Operator shall meet the performance specifications and comply with the registrar service level agreement established by ICANN. The initial performance specifications are set forth in Appendix D and the initial service level agreement is set forth in Appendix E. Changes to the performance specifications or service level agreement 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. 5
3.4 Registry-Registrar Agreements. During the Term of this Agreement, Registry ----------------------------- Operator shall enter a Registry-Registrar Agreement with any ICANN-Accredited Registrar desiring to enter such an agreement. All Registry Services provided by Registry Operator for the Registry TLD shall be provided strictly in accordance with that Registry-Registrar Agreement: 3.4.1 Initially, the form of the Registry-Registrar Agreement shall be that attached as Appendix F. 3.4.2 The form of the Registry-Registrar Agreement may be revised (a) by Registry Operator with the written consent of ICANN, (b) by ICANN in the manner provided in Subsections 4.3 through 4.6, provided that any additional terms are within the topics set forth in Subsection 4.2., or, (c) with respect to the price charged registrars by Registry Operator for Registry Services, according to Subsection 3.4.3. 3.4.3 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 (a) the same price shall be charged for services charged to all ICANN- Accredited Registrars (provided that volume adjustments may be made if the same opportunity to qualify for those adjustments is available to all ICANN-Accredited Registrars) and (b) the prices shall not exceed those set forth in Appendix G, as adjusted according to Subsection 4.4. Registry Operator shall charge no fee to anyone for Registry Services if such fee is not listed on Appendix G. For Registry Services (a) listed on Appendix G without a stated price, and (b) introduced more than six months after the Effective Date, Registry Operator may propose to ICANN, no later than thirty days before the commencement of that service, the inclusion in Appendix G of an offering price for the Registry Service. The offering price for the Registry Service shall be included in Appendix G only upon the written consent of ICANN, which shall not be unreasonably withheld or delayed. 3.5 Fair Treatment of ICANN-Accredited Registrars. --------------------------------------------- 3.5.1 Registry Operator shall provide all ICANN-Accredited Registrars that have Registry-Registrar Agreements in effect, 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. 3.5.2 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. 3.5.3 Registry Operator shall not act as a registrar with respect to the Registry TLD. This shall not preclude Registry Operator from registering names within the 6
domain of the Registry TLD in compliance with Subsection 3.6. This also shall not preclude an affiliate of Registry Operator from acting as a registrar with respect to the Registry TLD, provided that Registry Operator complies with the provisions of Subsections 3.5.4 and 3.5.5. 3.5.4 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. 3.5.5 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 3.5.5, 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. 3.5.6 With respect to its obligations under Subsections 3.5.1 through 3.5.5 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 3.5.1 through 3.5.5 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 1 May 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. 3.6 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: 3.6.1 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 X may be revised upon written notice by Registry Operator 7
to ICANN and written consent by ICANN, which shall not be unreasonably withheld. 3.6.2 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. 3.6.3 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. 3.6.4 This Subsection 3.6 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. 3.7 [Deliberately left blank] 3.8 Registration Restrictions Within Registry TLD. --------------------------------------------- 3.8.1 Except to the extent that ICANN otherwise expressly authorizes in writing, Registry Operator shall reserve from registration the domain names specified by a schedule established by ICANN. The initial schedule is attached as Appendix K. Changes to the schedule 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. 3.8.2 [Deliberately left blank] 3.9 Bulk Access to TLD Zone Files. Registry Operator shall provide bulk access ----------------------------- to the zone files for the Registry TLD as follows: 3.9.1 to third parties on the terms set forth in the TLD zone file access agreement established by ICANN. The initial terms of the agreement are set forth as Appendix N 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 8
3.9.2 to ICANN on a continuous basis in the manner which ICANN may from time to time specify. 3.10 Publication by Registry Operator of Registry Data. ------------------------------------------------- 3.10.1 At its expense, Registry Operator shall provide free public query- based access to up-to-date data concerning domain name and nameserver registrations 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 3.10.2 To ensure operational stability of the registry, Registry Operator may temporarily limit access under Subsection 3.10.1 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. Such temporary limitations shall be applied in a non-arbitrary manner and shall apply fairly to all ICANN-Accredited Registrars. 3.10.3 In providing query-based public access to registration data as required by this Subsection 3.10, 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 9
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. 3.10.4 To comply with applicable statutes and regulations and for other reasons, ICANN may from time to time establish policies in the manner described by Subsections 4.3 through 4.6 establishing limits on the data concerning registrations that Registry Operator may make available to the public through a public-access service described in this Subsection 3.10 and on the manner in which Registry Operator may make them available. In the event ICANN establishes any such policy, Registry Operator shall abide by it within the time allowed by Subsection 4.5. 3.10.5 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: 3.10.5.1 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 3.10.5.2 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 the Registry TLD, 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 3.11 Data Escrow. 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 10
(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. 3.12 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 intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and correction of such Personal Data. Registry Operator shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. 3.13 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 supplied by or through registrars. In the event that Registry Data is released from escrow under Subsection 3.11, any rights held by Registry Operator in the data shall automatically be transferred on a non-exclusive, irrevocable, royalty-free, paid-up basis to ICANN or to a party designated in writing by ICANN. 3.14.Registry-Level Financial Support of ICANN. During the Term of this ----------------------------------------- Agreement, Registry Operator shall pay to ICANN the following fees: 3.14.1. 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 3.14.4. 3.14.2. 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 bylaws 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 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 11
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. 3.14.3. 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. 3.14.4. Fee Caps. The Fixed Registry-Level Fee Cap shall be US$100,000 per -------- year until and including 30 June 2002; shall automatically increase by 15% on July 1 of each year beginning in 2002; and may be increased by a greater amount in the manner provided by Subsection 4.3. The sum of the Fixed Registry-Level Fees and the Variable Registry-Level Fees due to be paid in any year ending on any 30 June 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 30 June 2002; shall increase by 15% each fiscal year thereafter; and may be increased by a greater amount in the manner provided by Subsection 4.3. 3.14.5. 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 Subsection 4.4) 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 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 3.14.5 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 (see Subsection 3.4) 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. 12
3.15 Reports Provided to ICANN. ------------------------- 3.15.1 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 withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 3.15.2 [Deliberately left blank] 4. PROCEDURES FOR ESTABLISHMENT OR REVISION OF SPECIFICATIONS AND POLICIES. ----------------------------------------------------------------------- 4.1 Registry Operator's Ongoing Obligation to Comply With New or Revised -------------------------------------------------------------------- Specifications and Policies. During the Term of this Agreement, Registry - --------------------------- Operator shall comply, in its provision of Registry Services, on the schedule provided in Subsection 4.5, with 4.1.1 new or revised specifications (including forms of agreement to which Registry Operator is a party) and policies established by ICANN as Consensus Policies in the manner described in Subsection 4.3, 4.1.2 in cases where: 4.1.2.1 this Agreement expressly provides for compliance with revised specifications or policies established in the manner set forth in one or more subsections of this Section 4 or 4.1.2.2 the specification or policy concerns one or more topics described in Subsection 4.2. 4.2 Topics for New and Revised Specifications and Policies. New and revised ------------------------------------------------------ specifications and policies may be established on the following topics: 4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of the Registry Services, the DNS, or the Internet; 4.2.2 functional and performance specifications for the provision of Registry Services; 4.2.3 safety and integrity of the Registry Database; 13
4.2.4 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving Registered Names affected by such a suspension or termination; 4.2.5 resolution of disputes regarding whether particular parties may register or maintain registration of particular domain names; 4.2.6 principles for allocation of SLD names (e.g., first-come/first- served, timely renewal, holding period after expiration); 4.2.7 prohibitions on warehousing of or speculation in domain names by registries or registrars; 4.2.8 maintenance of and access to accurate and up-to-date contact information for domain name registrants; 4.2.9 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., establishment of reservations of names from registration); and 4.2.10 registry policies reasonably necessary to implement Consensus Policies relating to registrars. 4.3 Manner of Establishment of New and Revised Specifications and Policies. ---------------------------------------------------------------------- 4.3.1 "Consensus Policies" are those specifications or policies established based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (a) action of the ICANN Board of Directors establishing the specification or policy, (b) 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 (c) 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 policy. 4.3.2 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 establishing the policy. The decision of the panel shall be based on the report and supporting materials 14
required by Subsection 4.3.1. In the event that Registry Operator seeks review and the Independent Review Panel sustains the Board's determination that the policy is based on a consensus among Internet stakeholders represented in the ICANN process, then Registry Operator must implement such policy unless it promptly seeks and obtains a stay or injunctive relief under Subsection 5.8. 4.3.3 If, following a decision by the Independent Review Panel convened under Subsection 4.3.2, 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 Subsection 5.9; provided, however, that Registry Operator must continue to implement the policy unless it has obtained a stay or injunctive relief under Subsection 5.9 or a final decision is rendered in accordance with the provisions of Subsection 5.9 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 Subsection 4.3.1. 4.3.4 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 establishing the temporary specification or policy and why the Board believes the policy should receive the consensus support of Internet stakeholders. If the period of time for which the specification or policy is adopted exceeds ninety days, the Board shall reaffirm its temporary establishment every ninety days for a total period not to exceed one year, in order to maintain such specification or policy in effect until such time as it meets the standard set forth in Subsection 4.3.1. If the standard set forth in Subsection 4.3.1 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 temporary specification or policy, it will no longer be a "Consensus Policy." 4.3.5 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." 15
4.3.6 In the event that, at the time the ICANN Board of Directors establishes a specification or policy under Subsection 4.3.1 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 4.3.2 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 ICANN with the specification or policy in the interim. 4.4 Pricing Adjustments Arising from New or Revised Specifications or Policies. -------------------------------------------------------------------------- The maximum prices stated in Appendix G 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 demonstrated increases in the net costs of providing Registry Services arising from (A) new or revised ICANN specifications or policies adopted after the Effective Date, or (B) 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 (A) or (B) above. 4.5 Time Allowed for Compliance. 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 Subsection 4.3 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 Subsection 4.3 in which to comply with that specification or policy, taking into account any urgency involved. 4.6 Indemnification of Registry Operator. 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, without limitation, 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 Subsection 4.6, ICANN may, at the time it establishes a specification or policy after the Effective Date giving rise to an indemnity obligation under this Subsection 4.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 Subsection 4.6, in which case the reasonable cost to Registry Operator of such insurance shall be treated under Subsection 4.4 as a cost of providing Registry Services arising from the newly established ICANN specification or policy. 5. MISCELLANEOUS PROVISIONS. ------------------------ 16
5.1 Expiration of this Agreement. ---------------------------- 5.1.1 The Expiration Date shall be 31 December 2002. 5.1.2 Registry Operator acknowledges and agrees that upon the earlier of (i) the Expiration Date or (ii) termination of this Agreement by ICANN pursuant to Subsection 5.4, it will cease to be the operator of the Registry TLD and neither it nor any affiliated entity will be eligible to seek to continue to operate the Registry TLD. 5.1.3 Registry Operator shall make all commercially reasonable efforts to cooperate with ICANN and the party designated by ICANN as successor operator to facilitate smooth transition of the operation of the Registry TLD. 5.1.4 No later than 90 days prior to the Expiration Date, Registry Operator will pay to ICANN or ICANN's designee the sum of US $5 million, to be used by ICANN in it sole discretion to establish an endowment to be used to fund future operating costs of the non-profit entity designated by ICANN as successor operator of the .org registry. Registry Operator agrees that such funds, once paid to ICANN, will become the property of ICANN and/or ICANN's designee, and that Registry Operator will have no ownership or other rights or interests in such funds or in the manner in which they are used or disbursed. 5.1.5 Registry Operator further agrees that it will make available to the party designated by ICANN as successor operator of the .org registry the use of global resolution and distribution facilities, at no charge until 31 December 2003, and thereafter at a price to be determined, for so long as Registry Operator is also the operator of the .com registry. 5.1.6 Registry Operator acknowledges and agrees that, except as expressly provided by this Agreement, it shall not acquire any right in the Registry TLD by virtue of its operation of the Registry TLD or its provision of Registry Services hereunder. 5.2 [Deliberately left blank] 5.3 [Deliberately left blank] 5.4 Termination by ICANN. This Agreement may be terminated before its expiration -------------------- by ICANN in any of the following circumstances: 5.4.1 [Deliberately left blank] 5.4.2 Registry Operator: 17
5.4.2.1 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 5.4.2.2 is disciplined by the government of its domicile for conduct involving dishonesty or misuse of funds of others. 5.4.3 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. 5.4.4 Registry Operator fails to cure any material breach of this Agreement (other than a failure to comply with a Consensus Policy adopted by ICANN during the Term of this Agreement as to which Registry Operator has obtained a stay under Subsection 5.9) within fifteen business days (or such longer reasonable period as may be necessary using best efforts to cure such breach) after ICANN gives Registry Operator written notice of the breach. 5.4.5 Registry Operator's action or failure to act has been determined under Subsection 5.9 to be in violation of this Agreement and Registry Operator continues to act or fail to act in the manner that was determined to violate this Agreement for a period stated in the arbitration decision, or if no period is stated, fifteen business days. 5.4.6 Registry Operator acts or continues acting in a manner that ICANN has reasonably determined endangers the operational stability of Registry Services, the DNS, or the Internet after receiving three days notice of that determination. 5.4.7 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. 5.4.8 Registry Operator becomes bankrupt or insolvent. This Agreement may be terminated in the circumstances described in Subsections 5.4.1 through 5.4.7 above only upon thirty calendar days written notice to Registry Operator (in the case of the circumstances described in Subsections 5.4.4, 5.4.5, and 5.4.6 occurring after Registry Operator's failure to cure), with Registry Operator being given an opportunity during that time to initiate arbitration under Subsection 5.9 to determine the appropriateness of termination under this Agreement. In the event Registry Operator initiates arbitration concerning the appropriateness of termination by ICANN, Registry Operator may at the same time request that the arbitration panel stay the termination until the arbitration decision is rendered, and that request shall have the 18
effect of staying the requirement until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay. If Registry Operator acts in a manner that ICANN reasonably determines endangers the operational stability of Registry Services, the DNS, or the Internet and upon notice does not immediately cure, ICANN may suspend this Agreement for five calendar days pending ICANN's application for more extended injunctive relief under Subsection 5.9. This Agreement may be terminated immediately upon notice to Registry Operator in the circumstance described in Subsection 5.4.8. 5.5 [Deliberately left blank] 5.6 Additional Covenants of Registry Operator. Throughout the Term of this ----------------------------------------- Agreement, Registry Operator shall abide by the covenants contained in Appendix W. 5.7 Indemnification of ICANN. Registry Operator shall indemnify, defend, and ------------------------ hold harmless ICANN (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 out of or relating to: (a) the selection of Registry Operator to operate the Registry TLD; (b) the entry of this Agreement; (c) establishment or operation of the Registry TLD; (d) Registry Services; (e) collection or handling of Personal Data by Registry Operator; (f) any dispute concerning registration of a domain name within the domain of the Registry TLD; and (g) duties and obligations of Registry Operator in operating the Registry TLD; provided that, with respect to items (b) through (g) only, Registry Operator shall not be obligated to indemnify, defend, or hold harmless ICANN to the extent of ICANN's indemnification of Registry Operator under Subsection 4.6 and provided further that, with respect to item (g) only, Registry Operator shall not be obligated to indemnify, defend, or hold harmless ICANN to the extent the claim, damage, liability, cost, or expense arose due to a breach by ICANN of any obligation contained in this Agreement. For avoidance of doubt, nothing in this Subsection 5.7 shall be deemed to require Registry Operator to reimburse or otherwise indemnify ICANN for the costs associated with the negotiation or execution of this Agreement, or with the monitoring of the parties' respective obligations under this Agreement. 5.8 Indemnification Procedures. If any third-party claim is commenced that is -------------------------- indemnified under Subsections 4.6 or 5.7, notice thereof shall be given to the indemnifying party as promptly as practicable. If, after such notice, the indemnifying party acknowledges its obligation to indemnify with respect to such claim, then the indemnifying party shall be entitled, if it so elects, in a notice promptly delivered to the indemnified party, to immediately take control of the defense and investigation of such claim and to employ and engage attorneys reasonably acceptable to the indemnified party to handle and defend the same, at the indemnifying party's sole cost and expense, provided that in all events ICANN shall be entitled to control at its sole cost and expense the litigation of issues concerning the validity or interpretation of ICANN policies or conduct. The indemnified party shall cooperate, at the cost of the indemnifying party, in all reasonable respects with the indemnifying party and its 19
attorneys in the investigation, trial, and defense of such claim and any appeal arising therefrom; provided, however, that the indemnified party may, at its own cost and expense, participate, through its attorneys or otherwise, in such investigation, trial and defense of such claim and any appeal arising therefrom. No settlement of a claim that involves a remedy affecting the indemnifying party other than the payment of money in an amount that is indemnified shall be entered into without the consent of the indemnified party. If the indemnifying party does not assume full control over the defense of a claim subject to such defense in accordance with this Subsection, the indemnifying party may participate in such defense, at its sole cost and expense, and the indemnified party shall have the right to defend the claim in such manner as it may deem appropriate, at the cost and expense of the indemnifying party. 5.9 Resolution of Disputes Under This Agreement. Disputes arising under or in ------------------------------------------- connection with this Agreement, including requests for specific performance, shall be referred in the first instance to arbitration conducted as provided in this Subsection 5.9 pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce ("ICC"). The arbitration shall be conducted in the English language and shall occur in Los Angeles County, California, USA. There shall be three arbitrators: each party shall choose one arbitrator and, if the two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The 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 ICC 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. Either party, if dissatisfied with the result of the arbitration, may challenge that result by bringing suit against the other party in a court located in Los Angeles, California, USA to enforce its rights under this Agreement. In all litigation involving ICANN concerning this Agreement (as provided in the remainder of this Subsection), 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 a temporary stay or 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. 5.10 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 Subsection 3.14. 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 20
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. 5.11 Assignment. Any assignment of this Agreement shall be effective only upon ---------- written agreement by the assignee with the other party to assume the assigning party's obligations under this Agreement. Moreover, neither party may assign this Agreement without the prior written approval of the other party. Notwithstanding the foregoing, a party may assign this Agreement by giving written notice to the other party in the following circumstances: (a) Registry Operator may assign this Agreement as part of the transfer of its registry business if such transfer and assignment are approved in advance by ICANN pursuant to its procedures, and (b) ICANN may assign this Agreement, (i)in conjunction with a reorganization or re-incorporation of ICANN, to another non- profit corporation organized for the same or substantially the same purposes as ICANN or (ii) as required by Section 5 of Amendment 1 (dated 10 November 1999) to the 25 November 1998, Memorandum of Understanding between ICANN and the United States Department of Commerce. 5.12 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. 5.13 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, lightning, 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. 21
5.14 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 SLD holder. 5.15 Notices, Designations, and Specifications. All notices (including ----------------------------------------- determinations, designations, and specifications) 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 an 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. 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 If to Registry Operator, addressed to: General Counsel VeriSign, Inc. 1350 Charleston Road Mountain View, California 94303 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 22
5.16 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. 5.17 Language. All notices, designations, determinations, and specifications -------- made under this Agreement shall be in the English language. 5.18 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. 5.19 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. 5.20 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. 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: VERISIGN, INC. By:__________________________ Stratton Sclavos President and CEO Date: 23
EXHIBIT 99.6 ------------ SPECIAL AWARD CONDITIONS NCR-92-18742 Amendment Number Twenty-Four (24) 1. Section I.A.4, of Amendment 19, Definitions, is amended as follows: ----------- 4) "NSI" refers to Network Solutions, Inc., a wholly owned subsidiary of VeriSign, Inc., and its successors and assigns. From the date of execution of this amendment, the Cooperative Agreement will refer to "VeriSign" as the non- government party to this agreement. 2. Section I.A.9, of Amendment 19, Definitions, is amended as follows: ----------- 9) "Registry Agreement" means either the .org Registry Agreement, the .net Registry Agreement, or the .com Registry Agreement (collectively, the "Registry Agreements"), attached hereto as Exhibits 1, 2 and 3, respectively, as they may be amended from time to time. 3. Section I.B.2.A, of Amendment 19, VeriSign Relationship with ICANN, is -------------------------------- amended as follows: A. VeriSign shall enter into the Registry Agreements and the Registrar Accreditation Agreement. VeriSign's obligations under the Cooperative Agreement with respect to Registry Services and Registrar Services shall be satisfied by compliance with the Registry Agreements and the Registrar Accreditation Agreement, respectively, for so long as those Agreements (including any renewals of those agreements) are in effect (as determined by the dispute resolution procedures and termination provisions of those Agreements). VeriSign's obligations under the Cooperative Agreement with respect to Other Services (and Registry Services following the expiration or termination by VeriSign) shall be satisfied by compliance with the Cooperative Agreement as amended. 4. Section I.B.2.B, of Amendment 19, VeriSign Relationship with ICANN, is -------------------------------- amended as follows: B. If any Registry Agreement is terminated by ICANN for cause, the Department of Commerce shall be entitled under Section I.B.8 below to terminate VeriSign's obligation for the affected Registry TLD to provide Registry Services under the Cooperative Agreement. 5. Section I.B.2.D, of Amendment 19, VeriSign Relationship with ICANN, is -------------------------------- amended as follows: D. If the Registry Agreements and the Registrar Accreditation Agreement are all terminated by ICANN for cause, VeriSign's obligations to provide Registry Services, Registrar Services, and Other Services under the Cooperative Agreement shall terminate upon 90 days notice by either party of its intention to terminate such services.
6. Section I.B.4.A, of Amendment 19, Other Obligations of the Parties, is -------------------------------- amended as follows: A. The Department of Commerce will assure that the authoritative root will point to the TLD zone servers designated by VeriSign for each of the Registry TLDs (Registry TLD zone server). The Department of Commerce will withdraw such assurance for a particular Registry TLD at the earlier of the termination of this Cooperative Agreement by the Department of Commerce or at such time as ICANN terminates for cause the Registry Agreement corresponding to such Registry TLD. 7. Section I.B.4.B, of Amendment 19, Other Obligations of the Parties, is -------------------------------- amended as follows: B. The Department of Commerce acknowledges and agrees that VeriSign is and will remain the registry for the Registry TLD(s) until the earlier of the termination of this Cooperative Agreement by the Department of Commerce or termination for cause of the Registry Agreement(s) by ICANN. 8. Section I.B.7, of Amendment 19, Specific Performance, is amended as follows: -------------------- During the Term of the Cooperative Agreement, the Department of Commerce may seek specific performance of any provision of the Cooperative Agreement, provided the Department is not in material breach of its obligations hereunder. This provision shall not entitle the Department of Commerce to seek specific performance of any Registry Agreement. This provision shall not entitle the Department of Commerce to seek specific performance of the Registrar Accreditation Agreement unless and until and for so long as such agreement has been assigned to the Department of Commerce by ICANN. 9. Section I.B.8.A, of Amendment 19, Termination, is amended as follows: ----------- A. In the event ICANN designates a successor registry or terminates the .org Registry Agreement, the .net Registry Agreement or the .com Registry Agreement, the Department agrees that upon the conclusion of the transfer when a successor registry is established and operational and VeriSign notifies the Department of the completion of the transfer, the Department will relieve, release and discharge VeriSign from any responsibility for Registry Services for the affected Registry TLD currently performed under the Cooperative Agreement that have been transferred to the successor registry. The final release will be effected by VeriSign sending a letter to the Department stating that: Awardee, VeriSign, Inc. hereby represents and certifies to the Department of Commerce, that in accordance with the requirements contained in Amendment 19, as amended, to the Cooperative Agreement NCR-9218742, all requirements relating to its performance as the Registry have been completed. We therefore request that, as provided by Amendment 19, as amended, to the Cooperative Agreement NCR-9218742, the Department of Commerce sign and return a copy of this letter and, in the block indicated below, acknowledge that we have completed the agreed upon items and are fully and finally relieved, released, and discharged from any responsibility for the Registry for [insert affected
Registry TLD] previously performed by Awardee under Cooperative Agreement NCR-9218742 which are now the subject of a contract between ICANN and [the successor registry]. 10. Section I.B.8.C, of Amendment 19, Termination, is amended as follows: ----------- C. If the Registrar Accreditation Agreement and all Registry Agreements are terminated by ICANN for cause, the Department will relieve, release and discharge VeriSign from any responsibility for continuing to provide Other Services that are required under the Cooperative Agreement. The final release will be effected by VeriSign sending a letter to the Department stating that: Awardee, VeriSign, Inc. hereby represents and certifies to the Department of Commerce, that in accordance with the requirements contained in Amendment 19, as amended, to the Cooperative Agreement NCR-9218742, all requirements relating to its performance of Other Services have been completed. We therefore request that, as provided by Amendment 19, as amended, to the Cooperative Agreement NCR-9218742, the Department of Commerce sign and return a copy of this letter and, in the block indicated below, acknowledge that we have completed the agreed upon items and are fully and finally relieved, released, and discharged from any responsibility for the provision of Other Services previously performed by Awardee under Cooperative Agreement NCR-9218742. 11. Section I.B.8.D, of Amendment 19, Termination, is amended as follows: ----------- D. In the event that a final judgment is rendered specifically enforcing any provision of the Cooperative Agreement, the Department of Commerce may, by giving written notice, demand that VeriSign comply with such judgment. In the event that VeriSign fails to comply with such judgment within ninety days after the giving of notice, the Department of Commerce may terminate the Cooperative Agreement immediately by giving VeriSign written notice of termination and the Department of Commerce may initiate either a competitive action or other transaction pursuant to Section II.9 below or request ICANN to initiate procedures for designating a successor registry in compliance with the provisions of the affected Registry Agreement(s). 12. Section I.B.9, of Amendment 19, Compliance with Section II of this ---------------------------------- Amendment, is amended as follows: - ---------- While the Registry Agreements remain in effect, VeriSign shall not be obligated to comply with the provisions of Section II of this amendment. Upon termination (i) by VeriSign of a particular Registry Agreement, or (ii) due to the withdrawal of the Department's recognition of ICANN, VeriSign shall no longer be required to comply with such Registry Agreement and VeriSign's obligations under Section II of this amendment shall take immediate effect with 3
respect to the affected Registry TLD without further action by the Department of Commerce or VeriSign. Upon such termination, VeriSign agrees to provide prompt written approval to ICANN for the assignment of any data escrow agreement between ICANN and VeriSign related to such Registry Agreement. 13. Section I.B.10, of Amendment 19, Expiration Date, is amended as follows: ---------------- The Expiration Date of the Cooperative Agreement shall be November 10, 2007. 14. Section II.1 of Amendment 19, VeriSign Obligations, is amended as follows: --------------------- A. VeriSign agrees that it will operate the registries for the Registry TLDs in accordance with the Cooperative Agreement; B. VeriSign agrees to comply with Department of Commerce policies and directives regarding material aspects of VeriSign's provision of Registry Services as distinct from the detailed or day to day administration of the registries for the Registry TLDs. C. VeriSign acknowledges and agrees that upon the earlier of the expiration or termination of the Cooperative Agreement pursuant to Section I.B.8 of this amendment, it will cease to be the registry for the particular Registry TLD(s) affected by the expiration or termination, unless prior to the end of the Term of the Cooperative Agreement VeriSign is chosen as a successor registry in accordance with the provisions of the Cooperative Agreement. VeriSign shall cooperate in the transfer of responsibility for operation of the affected registry or registries to a successor registry. Such cooperation shall include the timely transfer to the successor registry of an electronic copy of the registry database and of a full specification of the format of the data. 15. Section II.2 of Amendment 19, Data Escrow, is amended as follows: ------------ VeriSign shall 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 VeriSign and the Department of Commerce, such approval not to be unreasonably withheld by either party. The escrow shall be maintained, at VeriSign's expense, by a reputable escrow agent mutually approved by VeriSign and the Department of Commerce, such approval also not to be unreasonably withheld by either party. The escrow shall be held under an agreement among VeriSign, the Department of Commerce, and the escrow agent providing that (A) the data shall be received and held in escrow, with no use other than verification that the deposited data is complete and in proper format, until released to the Department of Commerce; (B) the data shall be released to the Department of Commerce upon termination by the Department of Commerce of the Cooperative Agreement or upon its expiration if (1) the Cooperative Agreement has not sooner been terminated and (2) VeriSign has not been designated as a successor registry as the result of a competitive action or other transaction in accordance with applicable federal law and regulations. 16. Section II.3 of Amendment 19, VeriSign Handling of Personal Data, is ----------------------------------- amended as follows: 4
VeriSign agrees to notify registrars sponsoring registrations in the registries of the purposes for which Personal data submitted to the registries 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. VeriSign shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. VeriSign shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. 17. Section II.4 of Amendment 19, Publication by VeriSign of Registry Data, is ----------------------------------------- amended as follows: A. VeriSign shall provide an interactive web page and a port 43 Whois service providing free public query-based access to up-to-date (i.e. updated at least daily) registry database data for the Registry TLDs which, in response to input of an SLD name, shall report at least the following data elements in response to queries: (a) the SLD name registered, (b) the TLD in which the SLD is registered; (c) the IP addresses and corresponding names of the primary nameserver and secondary nameserver(s) for such SLD, (d) the identity of the sponsoring Registrar, and (e) the date of the most recent modification to the domain name record in the registry database; provided, however, that if the Department of Commerce adds to or subtracts from these elements, VeriSign will implement that policy. VeriSign shall not discontinue its participation in advanced, centralized or universal Whois services in operation or development at the time of the expiration or termination of the Registry Agreement(s). B. To ensure operational stability of the registries, VeriSign may temporarily limit access under subsection (A), in which case VeriSign shall immediately notify the Department of Commerce in writing or electronically of the nature of and reason for the limitation. VeriSign shall not continue the limitation longer than three business days if the Department of Commerce objects in writing or electronically, which objection shall not be unreasonably made. Such temporary limitations shall be applied in a nonarbitrary manner and shall apply fairly to any registrar similarly situated, including VeriSign. C. VeriSign as operator for the registries shall comply with Departmental direction providing for development and operation of a capability that provides distributed free public query-based (web and command-line) access to current registration data implemented by Accredited Registrars providing for capabilities comparable to WHOIS, including (if called for by Departmental direction) registry database lookup capabilities according to a specified format. If such a service implemented by Accredited Registrars on a distributed basis does not within a reasonable time provide reasonably robust, reliable and convenient access to accurate and up-to-date registration data, VeriSign as operator for the registries shall cooperate and, if reasonably determined to be necessary by the Department of Commerce (considering such possibilities as remedial actions by specific registrars), provide data from the registries' databases to facilitate the development of a centralized service providing equivalent functionality in a manner established by Departmental direction. VeriSign shall also continue any development and deployment of a universal Whois service that allows public access and effective 5
use of Whois across all registries and all top level domains at the direction of the Department. 18. Section II.5 of Amendment 19, Performance and Functional Specification for -------------------------------------------- Registry Services, is amended as follows: - ----------------- Unless and until otherwise directed by the Department of Commerce, VeriSign shall provide Registry Services to Accredited Registrars meeting the performance and functional specifications set forth in the SRS specification then in place under the Registry Agreements. In the event the Department directs different performance and functional standards for a registry, VeriSign shall comply with those standards to the extent practicable, provided that compensation pursuant to the provisions of II.7 of this amendment has been resolved prior to implementation and provided further that VeriSign is given a reasonable time for implementation. VeriSign shall take all reasonable steps to ensure the continued operation, functionality, and accessibility of the Shared Registration System. In the event of operational instability or for the purpose of system maintenance, VeriSign may temporarily limit Accredited Registrars' access to the Shared Registration System on an equitable basis, in which case VeriSign shall immediately notify the Department of Commerce and all affected Accredited Registrars in writing or electronically of the nature of and reason for the limitation and the expected date and time of service restoration. VeriSign shall take all reasonable steps to notify all Accredited Registrars at least 24 hours in advance of any anticipated (non emergency) Shared Registration System service interruption, the reason for the service interruption, and the expected date and time of service restoration. 19. Section II.6 of Amendment 19, Bulk Access to Zone Files, is amended as ------------------------- follows: VeriSign shall provide third parties bulk access to the zone files for the Registry TLDs on the terms set forth in the zone file access agreement then in effect under the Registry Agreement corresponding to the affected Registry TLD. VeriSign may not change the access agreement without the prior written approval of the Department of Commerce. 20. Section II.7 of Amendment 19, Price for Registry Services, is amended as --------------------------- follows: The price to licensed registrars for entering initial and renewal SLD registrations into the registry and for transferring a SLD registration from one accredited registrar to another will be as set forth in the Registry Agreements for the Registry TLDs at the time of its expiration or termination. These prices shall be increased to reflect demonstrated increases in costs of operating the registry arising from (1) changes or additions to the work provided under the Cooperative Agreement directed by the Department of Commerce or (2) legislation specifically applicable to the Registry Services. 21. Section II.9 of Amendment 19, Designation of Successor Registry, is amended --------------------------------- as follows: VeriSign agrees that upon (a) one year prior to the expiration or (b) VeriSign's receipt of notice of termination of the Cooperative Agreement pursuant to Section I.B.8 of this amendment, the 6
Department of Commerce may initiate a competitive action or other transaction in accordance with applicable federal law and regulations to designate a successor registry or successor registries. Not later than 30 days after VeriSign's receipt of a notice of termination, VeriSign shall submit to the Department of Commerce, for the Department's immediate use in designating the successor registry for a particular Registry TLD, an electronic copy of all software (excluding the SRS software) and data related to its provision of Registry Services for the Registry TLD generated under the Cooperative Agreement through the date of the notice of termination. Not later than 60 days after VeriSign's receipt of a notice of termination, VeriSign shall submit to the Department of Commerce, for its immediate use in designating such successor registry, all existing documentation for such software (excluding the SRS software) and data related to VeriSign's provision of such Registry Services generated under the Cooperative Agreement through the date of the notice of termination. If, after the expiration or termination pursuant to Section I.B.8 of this amendment, VeriSign or its assignee is not designated as a successor registry for a particular Registry TLD pursuant to the competitive action or transaction, VeriSign shall cooperate with the Department of Commerce and with the successor registry in order to facilitate the smooth transition of operation of the registry to the successor registry. Such cooperation shall include timely transfer to the successor registry of an electronic copy of the registry database and of a full specification of the format of the data. Thereafter VeriSign shall be relieved of further obligations under the Cooperative Agreement. 22. Section II.10 of Amendment 19, Rights in Data, is amended as follows: -------------- Except as permitted by the Registrar License and Agreement, VeriSign shall not be entitled to claim any intellectual property rights in data or any database or portion thereof in the registries supplied by or through registrars other than VeriSign. In the event that Registry Data is released from escrow under Section II.2 or transferred to a successor registry under Sections I.B.8 or II.9, any rights held by VeriSign as operator of such registry in said Registry Data shall automatically be licensed on a non-exclusive, transferable, irrevocable, royalty-free, paid-up basis to the recipient of the data. 23. Section III.2 of Amendment 19, Other Provisions, is amended as follows: ---------------- 2. Articles 9, 10 and 14 of the Cooperative Agreement Special Conditions, as amended, are hereby suspended as of the date of this amendment and VeriSign shall have no obligations under such provisions for so long as the Registry Agreements remain in effect. Upon termination of the Registry Agreements, the withdrawal of the Department's recognition of ICANN under Section 26 of the .com Registry Agreement, or with the approval of the Department of Commerce under Section 18(b) of the .com Registry Agreement, such provisions shall return to effect immediately without further action by the Department of Commerce or VeriSign. 24. Section III.5 of Amendment 19, Other Provisions, is amended as follows: ---------------- Article 12 of the Cooperative Agreement Special Conditions, as amended, is hereby amended to 7
read: The following individuals shall serve as points of contact at VeriSign: Philip Sbarbaro Chuck Gomes 25. The Department of Commerce hereby approves the .org Registry Agreement, the .net Registry Agreement, and the .com Registry Agreement, attached hereto as Exhibits 1, 2, and 3 respectively. This approval is not intended to confer federal antitrust immunity on VeriSign with respect to the Registry Agreements. Upon signature of both parties, provide copies of the Registry Agreements to both the Grants Officer and the Federal Programs Officer. 26. Except as modified by this Amendment, the terms and conditions of this Cooperative Agreement, as previously amended, remain unchanged. 8