TLD Sponsorship Agreement: Attachment 17

TLD Sponsorship Agreement: Attachment 17 Posted: 4 September 2001

Sponsor shall ensure Registry Operator provides bulk access by ICANN to up-to-date data concerning domain name and nameserver registrations maintained by Registry Operator in connection with the Sponsored TLD on a daily schedule, only for purposes of verifying and ensuring the operational stability of Registry Services, the DNS, and the Internet.

The procedures for providing access, and the specification of the content and format of this data, will be as stated below, until changed according to the Sponsorship Agreement. This Attachment 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 require Registry Operator 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 represents the target architecture and initial functionality.

A. Procedures for Providing Access

Sponsor shall ensure Registry Operator prepares a full data set for one day of each week (the day to be designated by ICANN). Full data sets shall be up-to-date and coherent as of 1200 UTC on the day to which they relate. Until a different day is designated by ICANN, the full data sets will be prepared for Sundays.

1. Preparation of Files Containing Data Sets. Each full data set consists of an XML document meeting the content and format requirements of Parts B and C of this document. Once the XML document is generated, the following preparation steps will be performed:

a. The XML document will be placed in a file named according to the following convention:

"wfYYMMDD" where "YYMMDD" is replaced with the date (YY=last two digits of year; MM=number of month; DD=day; in all cases a single-digit number should be left-padded with a zero).

b. The Registry Operator may optionally split the document using the Unix SPLIT command (or equivalent) to produce files no less than 1GB each (except the final file). If files are split, an .MD5 file (produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors. The Registry Operator may optionally compress the document using the Unix GZIP command (or equivalent) to reduce the filesize.

c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the escrow file in addition to encrypting it.) An ICANN public key will be used for the encryption and the Registry Operator's private key will be used for the signature. Public keys will be exchanged between the Registry Operator and ICANN by e-mail, physical delivery of floppy diskettes or other agreed means.

2. Transmission of Full Data Sets. Once prepared, full data sets will be provided according to paragraph a below or, at Sponsor and Registry Operator's option, according to paragraph b below:

a. Sponsor shall ensure Registry Operator makes full data sets available for download by ICANN by Internet File Transfer Protocol (FTP) (FTP access will be password protected and limited to prespecified IP ranges). The data sets will be made available for download beginning no later than 2000 UTC on the day to which they relate and until the next full data set becomes available for download.

b. Sponsor shall ensure Registry Operator writes the full data set to DAT (DDS-4) tape (or other media specified by ICANN) and sends it to ICANN by expedited delivery service (such as FedEx or DHL). The full data set will be scheduled for arrival at ICANN no later than the second calendar day following the day to which the data set relates.

B. Content

The full data sets will consist of four types of the objects and contents described for full data sets in Part B of Attachment 16.

C. Format

Full data sets will be XML version 1.0, UTF-8 encoded documents conforming to the schema/document type declaration set forth in Part C of Attachment 16.