This excerpt taken from the VRSN 10-K filed Jul 12, 2007.
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.
domainname | ipaddress
servername | null
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 Operators 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:
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.
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 Licensees or Producers
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.
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.
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.
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.
A data file transfer is complete if all data files transferred from the source machine are present on the destination machine.
A data file transfer is correct if each data file on the destination machine has the same information content as that on source machine.
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:
This section describes each of the actions taken against the Data File and whether those actions met SUCCESS or FAILURE.
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.