.net Registry Agreement: Appendix 1
.NET Agreement Appendix 1
Data Escrow Specification
EXHIBIT A - Task Order and Statement of Work
TASK ORDER TITLE
Exhibit A to the Escrow Agreement dated _______________.
Data Escrow Provider
STATEMENT OF WORK
Establish an escrow account to deposit all data identified in Section 3.1(c)(i) of the Registry Agreement between VeriSign, Inc. ("VNDS") and the Internet Corporation for Assigned Names and Numbers ("ICANN") ( the "Data") in an electronic format mutually approved by VNDS and ICANN. More specifically, to meet the Data Escrow requirements outlined in the Registry Agreement, VNDS will store in escrow with Data Escrow Provider a complete set of Data in an electronic format agreed upon by VNDS and ICANN. Data Escrow Provider will verify that the data is complete, accurate, and delivered in the intended format using scripts provided by VNDS. The escrow deposit verification process will validate completeness and integrity (accuracy) of the data as well as validate that the file format sent is the format received by Data Escrow Provider (correctness). Refer to Exhibit B to review the verification processes. The Introspection validation, defined in Exhibit B, 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:
VNDS will deposit a complete set of 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:
VNDS 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: VNDS shall transmit the Deposit Materials and Additional Deposit to a secure server on a weekly and daily basis, respectively. VNDS 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 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 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 the Registrar Domain Report, Registrar Nameserver Report, and Registrar Whois Report, and may include Domain Name Registrant Data, DNSSEC-Related Data and Registry Service Data as set forth below.
FILE SIZE ESTIMATES
|Current Data Escrow Size||up to 400 Megabytes||up to 4 Gigabytes|
|Forecasted 2005 Data Escrow Size||up to 600 Megabytes||up to 7.5 Gigabytes|
|Total Forecasted Escrow Size||up to 1.5 Gigabytes||up to 15 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 data for domains sponsored by all registrars. Each domain is listed once with the current status and associated nameserver.
Domain Name (domainname)
Server name for each nameserver (servername)
Registrar ID (GURID)
Updated Date (updatedate)
Creation Date (createdate)
Expiration Date (expirationdate)
Status Information (statusname)
DNSSEC-Related Key Material (dnssec) [as applicable]
2. Registrar Nameserver ReportTitle: Registrar Nameserver Report
Server Name (servername)
IP Address (ipaddress)
Registrar ID (gurid)
Updated Date (updatedate)
Creation Date (createdate)
Expiration Date (expirationdate)
Status Information (statusname)
3. Registrar Whois Report
Title: Registrar Whois Report
Report name: Registrar Whois
Description: This report contains data for registrars sponsoring registered domains and nameservers and will consist of one record for each registrar.
Registrar ID (REGISTRARID)
Registrar Name (REGISTRARNAME)
Address 1 (ADDRESSLINE1)
Address 2 (ADDRESSLINE2)
Address 3 (ADDRESSLINE3)
State / Province (STATEPROVINCE)
Postal Code (POSTALCODE)
Telephone Number (PHONENUMBER)
Fax Number (FAXNUMBER)
E-Mail Address (EMAIL)
Whois Server (WHOISSERVER)
Web URL (URL)
Updated Date (UPDATEDATE)
Administrative Contact First Name(ADMINFNAME)
Administrative Contact Last Name (ADMINLNAME)
Administrative Contact Telephone Number (ADMINPHONE)
Administrative Contact E-Mail (ADMINEMAIL)
Billing Contact First Name (BILLINGFNAME)
Billing Contact Last Name (BILLINGLNAME)
Billing Contact Telephone Number (BILLINGPHONE)
Billing Contact E-Mail (BILLINGEMAIL)
Technical Contact First Name (TECHFNAME)
Technical Contact Last Name (TECHLNAME)
Technical Contact Telephone Number (TECHPHONE)
Technical Contact E-Mail (TECHEMAIL)
4. Domain Name Registrant Data
If VNDS requires registrars to provide it with registrant domain name registration data, VNDS shall escrow such registrant domain name registration data that is collected from registrars.
5. DNSSEC-Related Data
If VNDS requires registrars to provide it with DNSSEC related material necessary to sign the .NET zone (e.g., public and private portions of the .NET zone) key-signing keys and zone-signing keys, VNDS shall escrow such DNSSEC-related material.
6. Registry Services Data
VNDS shall escrow data collected from registrars as part of offering Registry Services introduced after the Effective Date of its Registry Agreement with ICANN, if any.
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 Oe (ADD_DOMAIN, MOD_DOMAIN, DEL_DOMAIN) => [domainname][servername]
operation Oe (ADD_NAMESERVER, MOD_ NAMESERVER, DEL_ NAMESERVER) => [ipaddress][servername]
operation Oe (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 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:
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 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.
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.