Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

本内容仅提供以下语言版本

  • English

.com/.net/.org Registry Agreements: Appendix R

ICANN | .com/.net/.org Registry Agreements: Appendix R

  ICANN Logo

.com/.net/.org Registry Agreements: Appendix R

(25 May 2001)

 


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.

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

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

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




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

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.

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 Reporta 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 Completenessb and Integrityc by a third party.

EXHIBIT B1 - Phase I Verification Process

The goal of the Verification Process is to verify Completenessb and Integrityc 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 Reporta 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 Completenessb , Correctnessc , and Integrityd 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 Completenessb , Correctnessc , and Integrityd 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
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.


Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.

Page Updated 25-May-2001

(c) 2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.