.com Registry Agreement Appendix 1

Data Escrow Specification

(1 December 2012)

This Appendix 1 to the .com Registry Agreement consists of four of the five exhibits to the Data Escrow Agreement that constitutes Appendix 2 to the .com Registry Agreement:

Exhibit A-Schedule for Escrow Deposits
Exhibit B-Escrow Deposit Format Specification
Exhibit C-Escrow Transfer Process
Exhibit D-Escrow Verification Procedures

The fifth exhibit (Exhibit E), which sets forth Escrow Agent's fees, is subject to negotiation between Registry Operator and Escrow Agent.

EXHIBIT A
Schedule for Escrow Deposits

Weekly and daily deposits will include records/transactions generated just before 00:00:00 (EST/EDT) of the next day they relate, e.g., report related to Sunday will include all transactions generated just before 00:00:00 of the following Monday. Date fields will be date-time data expressed in Eastern Standard Time / Eastern Daylight Time using the Gregorian calendar, e.g. "2010-03-29T18.04.32" until a future time, to be mutually agreed by the Parties, when the date fields will include a time zone indicator specifically corresponding to the Eastern Standard Time / Eastern Daylight Time, as appropriate, e.g. "2010-03-29T18.04.32-04:00". Data fields in the specified reports will be colon delimited until a future time, to be mutually agreed by the parties, when the delimiter will be changed to a tilde "~" or other agreed delimiter. Further, the Registrar Whois Report from the Weekly Deposit Materials will be provided in XML.

Weekly Escrow Deposits:

Registry Operator 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 of Exhibit B.

Daily Escrow Deposits:

Registry Operator 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 of Exhibit B.

Electronic Delivery Service Escrow Deposit Method:

The transmitted data will be made available to Data Escrow Provider as follows:

Daily Deposits:

Daily transactional data will be made available no later than 18:00 (EDT/EST) each Tuesday through Sunday for the previous calendar day. For example, transactional data related to Monday would be available to the escrow company on Tuesday no later than 18:00 (EDT/EST). 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 18:00 (EDT/EST) each Monday.

EXHIBIT B
ESCROW DEPOSIT FORMAT SPECIFICATION

Each Weekly and Daily Deposit consists of a series of reports that are concatenated in the escrow process.

Table 1: Weekly Deposit Materials Format

Weekly Reports

1. Registrar Domain Report - com

   Title: Registrar Domain Report - com
   Report name: rgr_domain_com
   Description: This report contains data for domains sponsored by all registrars. Status Information will use Status Values from RFC 5731, Section 2.3. Since a domain may have more than one status, each domain will have separate lines for each domain/nameserver/status combination.

   Fields:

   Domain Name (domainname)
   Server names for all nameservers (servername)
   IANA Registrar ID (registrarid)
   Updated Date (updatedate)
   Creation Date (createdate)
   Expiration Date (expirationdate)
   Status Information (statusname)
   Domain ROID (roid)

2. Registrar Nameserver Report

   Title: Registrar Nameserver Report
   Report name: rgr_nameserver
   Description: This report contains data for all nameservers sponsored by all registrars. The nameserver is listed once with all associated information. Since a nameserver may have more than one IP address, each nameserver will have separate lines for each nameserver/IP address/status combination. Status Information will use Status Values from RFC 5732, Section 2.3.

   Fields:

   Server Name (servername)
   IP Address (ipaddress)
   IANA Registrar ID (registrarid)
   Updated Date (updatedate)
   Creation Date (createdate)
   Expiration Date (expirationdate)
   Status Information (statusname)
   Nameserver ROID (nsroid)

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.

   Fields:

   IANA Registrar ID (REGISTRARID)
   Registrar Name (REGISTRARNAME)
   Address 1 (ADDRESSLINE1)
   Address 2 (ADDRESSLINE2)
   Address 3 (ADDRESSLINE3)
   City (CITY)
   State / Province (STATEPROVINCE)
   Postal Code (POSTALCODE)
   Country (COUNTRYCODE)
   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 Registry Operator requires registrars to provide it with registrant domain name registration data, Registry Operator shall escrow such registrant domain name registration data that is collected from registrars.

5. DNSSEC-Related Data

   At such time that Registry Operator implements DNSSEC and collects DS records, Registry Operator shall escrow such DS records.

   Title: DS Report
   Report name: ds_domain_report_com
   Description: This report contains delegation signer (DS) records associated with domains sponsored by all registrars. Each DS record is listed once.

   Fields:

   Domain Name (domainname)
   Domain ROID (roid)
   Key Tag (keytag)
   Algorithm (algorithm)
   Digest Type (digesttype)
   Digest (digest)

   DS records will be escrowed in DS RR Presentation Format as defined in section 5.3 of RFC 4034.

6. Registry Services Data

   Registry Operator 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. If multiple DS records are associated with a transacton, those records will be comma separated and included on a single line with that transaction. A transactionid is included to allow unique identification of transactions. Operations of type "MOD" (e.g., MOD_DOMAIN, MOD_NAMESERVER, itc.) will include all the associated objects even if they were not affected by the transaction, i.e., a MOD_DOMAIN operation will include a row for each nameserver even for those that were not modified. 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]
   operation Oe (ADD_DS, MOD_ DS, DEL_ DS) => [domainname][dsdata]
   Only the seven (7) operation types above are included in the report.
   The dsdata column will have the following fields in DS RR Presentation Format as defined in section 5.3 of RFC 4033 with pipe delimiter for - <KeyTag>|<Algorithm>|<DigestType>|<Digest>

   Fields:

   transactionid
   operationname
   domainname | ipaddress
   servername | null
   transactiondate
   roid
   dsdata | null

EXHIBIT C
Escrow Transfer Process
Effective: To Be Mutually Agreed Between Registry Operator and Data Escrow Provider

Deposit Transfer Process. Registry Operator shall prepare and transfer the Deposit file by the following steps, in sequence:

1. The Reports making up the Deposit will first be created according to the format specification. (See Exhibit B above, "Escrow Deposit Format Specification").
2. The Reports making up the Deposit will be concatenated. The resulting file shall be named according to the following format: "com-SEQN-YYYYMMDD", where "SEQN" is a four digit decimal number that is incremented as each report is prepared and "YYYY" represents the year, "MM" the month, and "DD" the day of the date to which the file relates.
3. Next, the Deposit files will be processed by a program (provided by ICANN) that will verify that it complies with the format specification and contains reports of the same date/time (for a Full Deposit), count the number of objects of the various types in the Deposit, and append to the file a report of the program's results.
4. Registry Operator may optionally split the resulting file using the Unix SPLIT command (or equivalent) to produce files no less than 1 GB each (except the final file). If Deposit files are split, a .MD5 file (produced with MD5SUM or equivalent) must be included with the split files to isolate errors in case of transfer fault.
5. The Deposit file(s) will then be encrypted using Escrow Agent's public key for GPG or PGP and signed using Registry Operator's private key for GPG or PGP, both version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that GPG or PGP compresses the Deposit file(s) in addition to encrypting it (them).)

The formatted, encrypted and signed Deposit file(s) will be sent, by anonymous file transfer, to Escrow Agent's SFTP server within the specified time window.

Significant changes to the escrow transfer process require extensive integration between the parties. To ensure the registry data is always protected via the escrow process, Registry Operator will continue to run the legacy escrow transfer process and the new escrow transfer process in parallel until such time as all parties agree to retire the legacy escrow transfer process. The legacy escrow process will escrow all data listed in Exhibit B.

EXHIBIT D
Escrow Verification Procedures
Effective: To Be Mutually Agreed Between Registry Operator and Data Escrow Provider

Verification Procedures. Escrow Agent will verify the format and completeness of each Deposit by the following steps:

1. At the conclusion of the deposit window, all Deposit files will be moved to a not-publicly-accessible directory and the existence and size of each will be noted.
2. Each Deposit file will be decrypted using Escrow Agent's private key for GPG or PGP and authenticated using Registry Operator's public key for GPG or PGP. (In this step, GPG or PGP will also automatically decompress the escrow file).
3. If there are multiple files, they will be concatenated in sequence.
4. Escrow Agent will run a program (to be supplied by ICANN) on the Deposit files (without report) that will split it in to its constituent reports (including the format report prepared by the Registry Operator and appended to the Deposit) check its format, count the number of objects of each type, and verify that the data set is internally consistent. This program will compare its results with the results of the Registry-generated format report, and will generate a Deposit format and completeness report. The program will encrypt the report using ICANN's public key for GPG or PGP and signed using Escrow Agent's private key for GPG or PGP, both versions 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that GPG or PGP compresses the Deposit file(s) in addition to encrypting it (them). Escrow Agent will send the encrypted and signed report to ICANN by email.
5. The decrypted Deposit files will be destroyed to reduce likelihood of data loss to intruders in case of partial security failure.

Distribution of Public Keys. Each of Registry Operator and Escrow Agent will distribute its public key to the other party (Registry Operator or Escrow Agent, as the case may be) via email to an email address to be specified. Each party will confirm receipt of the other party's public key with a reply email, and the distributing party will subsequently reconfirm the authenticity of the key transmitted. In this way, public key transmission is authenticated to a user able to send and receive mail via a mail server operated by the distributing party. Escrow Agent, Sponsor and ICANN shall exchange keys by the same procedure.