Unsponsored TLD Agreement: Appendix R (.pro)
26 August 2003
Data Escrow Schedule, Content, Format, and Procedure
This Appendix R to the Registry Agreement consists of four of the five exhibits to the Data Escrow 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.
Exhibit A-Schedule for Escrow Deposits
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 12:00 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.
Exhibit B-Escrow Deposit Format Specification
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].
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
Registration Type
Sponsoring Registrar ID
Domain Status
Registrant Identifier (Contact ID)
Contact IDs for Administrative and Technical Contacts
Nameservers associated with this domain
Domain Created by Registrar
Domain Last Updated by Registrar
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date
Domain Last Transfer Date
Trademark Information2. The Nameserver 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)
Sponsoring Registrar ID
Created by Registrar ID
Nameserver Creation Date
Nameserver Last Updated Date
Nameserver Last Transfer Date3. The Contact Object. The contact object, which corresponds to a single contact (whether registrant, administrative, technical, or billing (for registrars only) 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
Professional Accreditation
Sponsoring Registrar ID
Created by Registrar ID
Contact Creation Date
Contact Last Updated Date
Contact Last Transfer Date
Contact Authorization Information4. 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 will consist of specially named objects that identify the domain, nameserver, contact, or registrar element being deleted. The names of these objects are:
| Name of Deletion Object | Type of Object Deleted |
| del-domain | domain |
| del-nameserver | nameserver |
| del-contact | contact |
| del-registrar | registrar |
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.
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 file 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: "proSEQN", 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, 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, a 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.
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 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 and complete. This program will compare its results with the results of the Registry-generated format report, and will generate a Deposit format and completeness report. This program will encrypt the report using ICANN's public key for PGP and signed using Escrow Agent's private key for PGP, both versions 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).)
5. 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 e-mail to an e-mail address to be specified. Each party will confirm receipt of the other party's public key with a reply e-mail, and the distributing party will make contact via an alternate channel (telephone, fax, paper mail) in order to verify the authenticity of the key transmitted. . In this way, public key transmission is authenticated to a user able to send and receive e-mail via a mail server operated by the distributing party. Escrow Agent, Sponsor, and ICANN shall exchange keys by the same procedure.
Earlier draft:
27 April 200127 December 2001
Comments concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
Page Updated
14-Jan-2008
©2001, 2002 The Internet Corporation for Assigned
Names and Numbers. All rights reserved.