Unsponsored TLD Agreement: Appendix R (.biz)

Unsponsored TLD Agreement: Appendix R (.biz) Posted: 11 May 2001

This Appendix R to the Registry Agreement consists of four of the five exhibits to the Service Level Agreement that constitutes Appendix S to the 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) to Appendix S, which sets forth the escrow agent's fees, is subject to negotiation between Registry Operator and the escrow agent.

1. Procedures for Providing Access. The Registry Operator will prepare (i) full data sets for one day of each week (the day to be designated by ICANN) and (ii) incremental data sets for all seven days of each week. Full and incremental 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.

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

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

For full data sets: "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).

For incremental data sets: "wiYYMMDD" where "YYMMDD" follows the same format.

3. Start Date for Escrow Procedures. Registry Operator and ICANN shall cooperate in resolving implementation issues, an escrow agent shall be selected, and an escrow agreement shall be entered in time for escrow deposits to begin within ninety days after the Commencement-of-Service Date.

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 sepcified 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
Sponsoring Registrar
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 Created by Registrar
Domain Last Updated by Registrar
Domain Registration Date
Domain Expiration Date
Domain Last updated Date
Domain Last TransferDate
Domain Authorization Information
Additional Fields (Registrar Specified)

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

Name Server ID
Name Server Name
Name Server Status
Name Server Association Status
Name Server IP Addresses if applicable
Sponsoring Registrar
Created by Registrar
Name Server Creation Date
Name Server Last Updated Date
Name Server Last Transfer Date
Additional fields (Registrar Specified)
Name Server Authorization Information

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
Contact Association Status
Contact Organization
Contact Address, City, State/Province, Country
Contact Postal Code
Contact Phone, Fax, E-mail
Sponsoring Registrar
Created by Registrar
Contact Creation Date
Contact Last Updated Date
Contact Last Transfer 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 Name
Registrar Address, City, State/Province, Country
Registrar Administrative Contacts
Registrar Technical Contacts
Registrar Billing Contacts
Registrar URL
Registrar Creation Date
Registrar Last Updated Date
Registrar Authorization Information
Registrar Account Information

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:

Objects Contained in Full and Incremental Data Sets. Full data sets include one domain object for each Registered Name within the Registry 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 definition for the objects and their notations of deletion will be specified after discussions between ICANN and Registry Operator. The format will be based on the Whois provider format specified in Appendix P, Section C "Format", but will be augmented to include all data elements reasonably necessary to permit operation of the Registry Services for the Registry TLD in the event the escrow data is released. In the event that ICANN and Registry Operator do not agree on the escrow format, ICANN shall reasonably specify that format.

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

1. The file(s) making up the Deposit will first be created according to the format specification. (See Exhibit B above, "Escrow Deposit Format Specification"). The resulting file shall be named according to the following format: "bizSEQN", where "SEQN" is a four digit decimal number that is incremented as each report is prepared.

2. Next, the Deposit file 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.

3. 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, an MD5 file (produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors.

4. The file(s) will then be encrypted and signed using a method mutually agreed by the Registry Operator and the Designated Data Recipient.

5. Transmission of Full Data Sets. Once prepared, full data sets will be provided either by the procedures for incremental data sets described in item C(6) below or, at the option of either the Registry Operator or the Designated Recipient, by writing the full data set to DAT tape (or other media mutually agreed by Registry Operator and the Designated Recipient) and sending it to the Designated Recipient by expedited delivery service (such as FedEx or DHL). If sent by expedited delivery service, the full data set will be scheduled for arrival no later than the second calendar day following the day to which the full backup relates.

6. Transmission of Incremental Data Sets. To permit the transmission of incremental data sets, the Registry Operator will make them available for download by the Designated Recipient by Internet file transfer protocol. Incremental data sets will be made available for download no later than 2000 UTC on the day to which they relate.

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 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), confirm receipt by a method mutually agreed by both the parties.

Earlier draft:

27 April 2001