VeriSign (VRSN)

Table 2: Daily Additional Deposit Format

Registrar Daily Additional Deposits

1. Registrar Transaction Report

Title: Registrar Transaction Report

Report name: rgr_transaction

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

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

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

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

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

Fields:

transactionid

operationname

domainname | ipaddress

servername | null

transactiondate

1. ADDITIONAL TERMS AND CONDITIONS

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

2. PERIOD OF PERFORMANCE

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

3. FEE SCHEDULE

Fees to be paid by VNDS shall be as follows:

Initialization fee (one time only) $                     

*Annual maintenance/storage fee $                     

*includes two cubic feet of storage space

Additional Services Available:

Electronic Updates

Transmitted once daily $                     

Price quoted is limited to 650 MB per update.

Electronic Updates over 650 MB $                     

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

Additional Services

Verification / File Listing Services $                     

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

Additional Storage Space $                     

Payable by Licensee or Producer Only Upon Release Request:

Due Only Upon Licensee’s or Producer’s

Request for Release of Deposit Materials $                     

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

EXHIBIT B

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

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

Verification Process

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

Notes

a. Registrars Report

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

b. Completeness

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

c. Correctness

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

d. Integrity

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

e. Regular Expression Algebra

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

f. Verification Report

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

Actions

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

Results

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

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