TLD Sponsorship Agreement: Attachment 18 (.coop)

TLD Sponsorship Agreement: Attachment 18 (.coop) Posted: 5 November 2001

Data Escrow Schedule, Content, Format, and Procedure

This Attachment 18 to the TLD Sponsorship Agreement consists of four of the five exhibits to the Data Escrow Agreement that constitutes Attachment 19 to the TLD Sponsorship 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, Sponsor, and Escrow Agent.

Exhibit A
SCHEDULE FOR ESCROW DEPOSITS

Full Deposit Schedule

Full Deposits shall consist of data that reflects the state of the registry as of 0000 UTC on each Sunday. Pending transactions at that time (i.e. transactions that have not been committed to the Registry Database) shall not be reflected in the Full Deposit.

Full Deposits shall be made, according to the transfer process described in Exhibit C below, within a four-hour window beginning at 0400 UTC on the same Sunday.

Incremental Deposit Schedule

Incremental Deposits shall reflect database transactions made since the most recent Full or Incremental Deposit. Incremental Deposits for Mondays shall include transactions completed through 0000 UTC on that day that had not been committed to the registry database at the time the last Full Deposit was taken. Incremental Deposits on Tuesday through Saturday shall include transactions completed through 0000 UTC on the day of the deposit that were not reflected in the immediately prior Incremental Deposit.

Incremental Deposits shall be made, according to the transfer process described in Exhibit C below, within a four-hour window beginning at 0400 UTC on the day to which the Incremental Deposit relates.

Exhibit B
ESCROW DEPOSIT FORMAT SPECIFICATION

This Exhibit is subject to change by agreement of Sponsor and ICANN during the design process as well as during the IETF standards process. In addition, Sponsor agrees to implement changes to this Attachment specified by ICANN to conform to the IETF provreg working group's protocol specification no later than 135 days after the IETF specification is adopted as a Proposed Standard [RFC 2026, section 4.1.1]. Accordingly, the following provides the target architecture and initial functionality. The escrow data sets (whether full or incremental) will consist of four types of objects:

• Domain object
• Nameserver object
• Contact object
• Registrar object

Additionally, incremental data sets will contain notations of deletion of objects since the last incremental data set.

1. The Domain Object. The domain object which corresponds to a single registered name consists of the following elements:

Domain ID
Domain Name
Domain Sponsoring Registrar (IANA-assigned identifier)
Domain Status
Registrant Identifier
Contact Identifiers for Administrative, Technical and Billing Contacts
Name Servers associated with this domain
Child Name Servers registered in this domain
Domain Creating Registrar (IANA-assigned identifier)
Domain Last Updating Registrar (IANA-assigned identifier)
Domain Registration Date
Domain Expiration Date
Domain Last updated Date
Domain Last Transferred Date
Domain Authorization Information
Additional Fields (Registrar Specified)
Additional Fields (Sponsor Specified)

2. The Name Server Object. The nameserver object which corresponds to a single registered nameserver consists of the following elements:

Nameserver ID
Nameserver Name
Nameserver Status
Nameserver Association Status
Nameserver IP Addresses if applicable
Nameserver Sponsoring Registrar (IANA-assigned identifier)
Nameserver Creating Registrar (IANA-assigned identifier)
Nameserver Last Updating Registrar (IANA-assigned identifier)
Nameserver Creation Date
Nameserver Last Updated Date
Nameserver Last Transferred Date

3. The Contact Object. The contact object, which corresponds to a single contact (whether registrant, administrative, technical or billing contact) consists of the following elements:

Contact ID
Contact Name
Contact Status
Currently Associated
Contact Organization
ENS Identity
Contact Address, City, State/Province, Country
Contact Postal Code
Contact Phone, Fax, E-mail
Sponsoring Registrar (IANA-assigned identifier)
Creating Registrar (IANA-assigned identifier)
Contact Creation Date
Contact Last Updated Date
Contact Last Transferred Date
Contact Authorization Information
Additional fields (Registrar Specified)

4. The Registrar Object. The registrar object, which corresponds to a single registrar consists of the following elements:

Registrar ID (registry specific)
Registrar Object Identifier (Unique object Identifier)
Registrar ID (conforming to the IANA registrar-ids registry)
Contact ID of Registrar
Registrar Status
Contact IDs of Registrar Administrative Contacts
Contact IDs of Registrar Technical Contacts
Contact IDs of Registrar Billing Contacts
Registrar URL
Additional fields (Registrar Specified)
Registrar Creation Date
Registrar Last Updated Date

Additionally, incremental data sets will contain notations of deletion of objects since the last incremental data set. These notations of object deletion are defined as follows:

Name of Element	Type of Element
Del-domain	domain:sNameType
Del-nameserver	host:sNameType
Del-contact	contact:sIDType
Del-registrar	eppcom:clIDType

Objects Contained in Full and Incremental Data Sets. Full data sets include one domain object for each Registered Name within the Sponsored TLD; and nameserver, contact, and registrar objects for each nameserver, contact, and registrar referred to in any domain object. Incremental data sets consist of: (a) those of the objects constituting a full data set that have been added or updated since the last incremental data set and (b) notations of deletion of any objects since the last incremental data set.

Format. Full and incremental data sets will be XML version 1.0, UTF-8 encoded documents. The XML Schema will be based on the Whois provider format specified in Attachment 16, but will be augmented to include all data elements reasonably necessary to permit operation of the Registry Services for the Sponsored TLD in the event the escrow data is released. In the event that ICANN and Sponsor do not agree on the escrow format, ICANN shall reasonably specify that format.

Exhibit C
ESCROW TRANSFER PROCESS

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: "coopSEQN", where "SEQN is a four digit decimal number that is incremented as each report is prepared.

3. Next, the Deposit file will be processed (including by a program to be supplied by ICANN) to 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 results of the deposit checks.

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 PGP and signed using Registry Operator's private key for PGP, both version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that 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 ftp server <(to be specified by Escrow Agent)> within the specified time window.

Exhibit D
ESCROW VERIFICATION PROCEDURES

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. The file(s) will then be decrypted using a method mutually agreed by the Registry Operator and the Escrow Agent.

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 file (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.

5. The decrypted Deposit file will be encrypted by the program using a method mutually agreed by the Registry Operator and the Escrow Agent.

6. The decrypted Deposit file 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 e-mail 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.

Prior draft:

4 November 2001