Registry Operator will provide bulk access by ICANN to up-to-date data
concerning domain name and nameserver registrations maintained by Registry
Operator in connection with the Registry 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 Registry Agreement. This Appendix is subject to change by agreement
of Registry Operator and ICANN during the design process as well as during
the IETF standards process. In addition, Registry Operator agrees to implement
changes to this Appendix 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
The Registry Operator will prepare a full data set once 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 names 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. 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
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
Registry Operator's option, according to paragraph b below:
a. Registry Operator will make 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. Registry Operator will write the full data set to DAT (DDS-4)
tape (or other media specified by ICANN) and send 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 fourth calendar day
following the day to which the data set relates.
The full data sets will consist of the objects and contents described
for full data sets in Part B of Appendix P.
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 Appendix
Comments concerning the layout, construction and functionality
of this site
should be sent to email@example.com.
©2001 The Internet Corporation
for Assigned Names and Numbers. All