Revised VeriSign Registry Agreements: Appendix R Posted: 16 April 2001

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.

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

2. Registrar Nameserver Report - Listed with IP Address

3. Registrar Nameserver-Domain Hosting Report

4. Registrar Common Report

Table 2: Daily Additional Deposit Format

Registrar Daily Additional Deposits

1. Registrar Transaction Report

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

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

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

EXHIBIT 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.

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.

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