Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

.coop Agreement Appendix 1

.coop Agreement Appendix 1

  ICANN Logo

Appendix 1

(1 July 2007)


Appendix 1

Data Escrow Specification

This Appendix 1 to the Sponsored TLD Registry Operator Agreement consists of four of the five exhibits to the Data Escrow Agreement that constitutes Appendix 2 to the Sponsored TLD Registry Operator 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 and Escrow Agent and is not included in this document.


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 daily deposits will be made on a daily basis when, and as specified in the TLD Sponsorship Agreement.

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

Each Full and Incremental Deposit consists of a series of reports that are concatenated in the escrow process.

Full Deposit Contents. The reports involved in a Full Deposit are:

Domain Object Report–This reports on the contents of all domain objects in the registry database.

Host Object Report–This reports on the contents of all host objects in the registry database.

Contact Object Report–This reports on the contents of all contact objects in the registry database.

Registrar Object Report–This reports on the contents of all registrar objects in the registry database.

Incremental Deposit Contents. The report involved in an Incremental Deposit is:

Transaction Report–This reports on the contents of all transaction records included in the Incremental Deposit.

Format of Reports. All reports are to be formatted in XML format. In compliance with the XML 1.0 specification, certain characters in the data must be escaped, as described in item 1 below. Each Report shall then be prepared according to the format described in items 2 to 8 below. Item 2 describes the report container that is common to all reports. Items 3 to 7 describe the contents of the report container for each of the specific reports. Item 8 describes the XML schema which formally defines the structure and concatenation of these reports and the connection between the data in these reports and the EPP data stored by the registry.

1. Escape-Character Requirements. In compliance with the XML 1.0 specification, in data escrowed using the XML format the following characters in any data elements must be replaced with the corresponding escape sequences listed here:

Character

Escape Sequence

"

"

&

&

'

'

<

&lt;

>

&gt

2. The Report Container. At its highest level, the XML format consists of an escrow element with header attributes followed by escrow data. The header attributes are required and include the version of escrow (1.1), the Sponsored TLD ("coop"), the report type (domain, host, contact, registrar, or transaction), and database-committed date and time as to which the escrow relates. The date and time of the escrow will be specified in UTC. The general format of the report container is as follows:

<?xml version="1.0" encoding='UTF-8' ?>
<!DOCTYPE escrow SYSTEM "whois-export.dtd" >
<escrow version="1.1" tld="coop" date="26-Mar-2007 3:15:00AM">

{Here the report contains the actual data being escrowed. It contains one element for each object of the type (domain, host, contact, registrar, or transaction) covered by the report. The contents and structure of each element are described in items 3 to 8 below.}

</escrow>

3. The Domain Element. The domain element has the property "fqdn" (the fully qualified name of the domain) and is a container consisting of the following elements:

a. roid: Unique identifier of the domain name

b. status: The EPP domain status codes.

c. registrant: Contact-id that references the contact records for the registrant of this domain.

d. contact-id: Multiple contact-ids that reference the contact records for this domain. Contact-id has the property "type" to denote the type of contact. "Type" can be one of: Administrative, Technical, or Billing

e. host: Up to thirteen (13) host names that are nameservers for the domain to which the domain object relates.

f. owned-by: An identification of the current registrar of the domain. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

g. authinfo: EPP authorization code.

h. created-on: The date/time the domain object was originally created.

i. created-by: An identification of the registrar that created the domain object. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

j. renewed-on: The date/time the domain was last renewed.

k. expires-on: The date the registration expires.

l. updated-by: An identification of the registrar that last updated the domain object. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

m. updated-on: The date/time the domain object was last updated.

n. transferred-by: An identification of the registrar that last transferred the domain object. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

o. transferred-on: The date/time when the domain object was last transferred.

 

An example domain element appears below:

<domain fqdn="example.coop">
  <roid>0001-COOP</roid>
  <status s=”ok”>ok</status>
  <registrant> 0001-COOP</registrant>
  <contact-id type="Administrative"> 0002-COOP</contact-id>
  <contact-id type="Technical"> 0003-COOP</contact-id>
  <contact-id type="Billing"> 0004-COOP</contact-id>
  <host>dns1.example.coop</host>
  <host>dns2.example.coop</host>
  <owned-by>42</owned-by>
  <authinfo>uWxg5aks</ authinfo>
  <created-on>2007-03-01T12:42:22:41.5Z</created-on>
  <created-by> 042</created-by>
  <expires-on>2009-03-01T12:42:22:41.5Z </expires-on>
  <updated-by>42</updated-by>
  <updated-on>2007-09-01T12:42:22:41.5Z </updated-on>
</domain>















4. The Host Element. The host element has the property "fqdn" (the fully qualified name of the host) and is a container consisting of the following elements:

a. roid: Identifier for the host as registered by the sponsoring registrar.

b. owned-by: An identification of the sponsoring registrar of the host. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

c. created-on: The date/time the host object was originally created.

d. updated-by: An identification of the registrar that last updated the host object. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

e. updated-on: The date/time the host object was last updated.

f. ip-address: Any number of IP addresses associated with this host.

g. status: The EPP host status codes associated with the host.

An example host element appears below:

<host fqdn="dns1.example.coop">
  <roid> 0001-COOP</roid>
  <owned-by>42</owned-by>
  <created-on>2007-03-01T12:42:22:41.5Z </created-on>
  <updated-by>42</updated-by>
  <updated-on>2007-07-01T12:42:22:41.5Z </updated-on>
  <ip-address>192.168.1.1</ip-address>
  <ip-address>192.168.122.1</ip-address>
  <status s="ok">ok</status>
</host>








5. The Contact Element. The contact element has the property "id" containing the registrar given id for the contact and is a container consisting of the following elements:

a. roid: Registry assigned unique identifier of the contact

An ASCII version of the postal information (elements b – j below) for the contact will be stored in an element called ascii-postalinfo. If there is an equivalent localized version of these details in Unicode as well, this should be stored in an element called unicode-postalinfo.

b. name: The name of the contact.

c. organization: The organization for the contact.

d. street: The first part of the street address of the contact.

e. street: The second part of the street address of the contact.

f. street: The third part of the street address of the contact.

g. city: The name of the city of the contact.

h. sp: The name of the state/province of the contact.

i. pc: The postal/zip code of the contact.

j. cc: The two letter ISO 3166 code for the contact's geographic location.

k. voice: The voice phone number of the contact in E164a format.

l. fax: The fax number of the contact in E164a format.

m. email: The e-mail address of the contact.

n. owned-by: An identification of the sponsoring registrar of the contact. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

o. created-by: An identification of the registrar that created the contact object. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

p. created-on: The date/time the contact object was originally created.

q. updated-by: An identification of the registrar that last updated the contact object. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

r. updated-on: The date/time the contact object was last updated.

s. transferred-by: An identification of the registrar that last transferred the contact object. The sponsoring registrar is designated by a number uniquely assigned by the IANA.

t. transferred-on: The date/time when the contact object was last transferred.

u. authinfo: EPP authorization code.

v. status: Contact status.

w. coop-specific: Any coop-specific information about the contact.

An example contact appears below:

<contact id="1">
 <roid>0025-COOP</roid>
 <ascii-postalinfo>
  <name>John Doe</name>
  <organization>aol</organization>
  <street>1234 East 11th Street</street>
  <street></street>
  <street></street>
  <city>New York</city>
  <sp>NY</sp>
   <pc>12345</pc>
  <cc>US</cc>
 <ascii-postalinfo>
  <voice>+212.1234567</voice>
  <fax>+212.1234568</fax>
  <email>jdoe@example.coop</email>
  <owned-by>42</owned-by>
  <created-by>42</created-by>
  <created-on>2007-03-01T12:42:22:41.5Z</created-on>
  <updated-by>42</updated-by>
  <updated-on>2007-03-02T12:42:22:41.5Z </updated-on>
  <authInfo>
   <contact:pw>xSd0SE1I2GpMvhUw</contact:pw>
  </authInfo>
  <status s=”ok”>ok</status>
  <coop-specific>
  <coopExt:langPref>en-gb</coopExt:langPref>
  <coopExt:mailingListPref>0</coopExt:mailingListPref>
 </coop-specific>
</contact>




























6. The Registrar Element. The registrar element has the property "id" containing the registry given id for the registrar and is a container consisting of the following elements:

a. password: The password for the registrar.

b. full-name: The full name of the registrar.

m. iana-id: The IANA id of the registrar.

n. web-url: The URL of the registrar’s website.

c. status: The registrar status code.

d. address: The registered address of the registrar comprising street address, city, state/province, postal code and country

i. voice: The phone number of the registrar

j. fax: The fax number of the registrar

l. contact: Any number of contacts associated with this registrar. Contact has the property "type" to denote the type of contact. "type" can be one of: Registrar, Administrative, Technical, Legal or Billing. Each contact contains its own name, address information, phone, fax and email.

o. created-on: Date the registrar became active for the registry.

p. updated-on: The date/time the registrar information was last updated.

An example registrar container appears below:

<registrar id="REG-id">
 <password>registrarrus</password>
 <full-name>Registrar R Us</full-name>
 <iana-id>42 </iana-id>
 <weburl>www.registrar.coop</weburl>
 <status>active</status>
 <address>
  <street>1234 East 11th Street</street>
  <street></street>
  <street></street>
  <city>New York</city>
  <sp>NY</sp>
  <pc>12345</pc>
  <cc>US</cc>
 </address>














 <voice>+212.1234567</voice>
 <fax>+212.1234568</fax>
 <contact type="administrative">
  <name>John Doe</name>
  <org>aol</org>
  <street>1234 East 11th Street</street>
  <city>New York</city>
  <sp>NY</sp>
   <pc>12345</pc>
  <cc>US</cc>
  <voice>+212.1234567</voice>
  <fax>+212.1234568</fax>
  <email>jdoe@example.coop</email>
 </contact >
 <created-date>2007-03-08T00:00:00.0Z</created-date>
</registrar>















7. The Transaction Element. The transaction element has the properties "operation" and "type.” "Operation" can be one of: add, modify or delete. "Type" can be one of: domain, host, contact or registrar. Within the transaction element is a corresponding element of the correct type as described above. For example, a transaction element with a "type" of "host" appears below:

<transaction operation="modify" type="host">
<host fqdn="dns1.example.coop">
  <roid> 0001-COOP</roid>
  <owned-by>42</owned-by>
  <created-on>2007-03-01T12:42:22:41.5Z </created-on>
  <updated-by>42</updated-by>
  <updated-on>2007-07-01T12:42:22:41.5Z </updated-on>
  <ip-address>192.168.1.1</ip-address>
  <ip-address>192.168.122.1</ip-address>
  <status s="ok">ok</status>
</host>
</transaction>










8. Format. Full and incremental data sets will be XML version 1.0, UTF-8 encoded documents conforming to the following schema:

<?xml version="1.0"?>
<schema targetNamespace="urn:dotcooperation:whoisdb"  xmlns="http://www.w3.org/2001/XMLSchema" 
xmlns:whoisdb="urn:dotcooperation:whoisdb" xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0" 
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0" xmlns:contact="urn:ietf:params:xml:ns:contact-1.0" 
xmlns:domain="urn:ietf:params:xml:ns:domain-1.0" xmlns:host="urn:ietf:params:xml:ns:host-1.0" 
xmlns:coopExt="http://www.nic.coop/contactCoopExt-1.0" elementFormDefault="qualified">
<!--Import EPP Element Types-->
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" schemaLocation="eppcom-1.0.xsd" />
<import namespace="urn:ietf:params:xml:ns:epp-1.0" schemaLocation="epp-1.0.xsd" />
<import namespace="urn:ietf:params:xml:ns:contact-1.0" schemaLocation="contact-1.0.xsd" />
<import namespace="urn:ietf:params:xml:ns:domain-1.0" schemaLocation="domain-1.0.xsd" />
<import namespace="urn:ietf:params:xml:ns:host-1.0" schemaLocation="host-1.0.xsd" />
<import namespace="http://www.nic.coop/contactCoopExt-1.0" schemaLocation="contactCoopExt-1.0.xsd" />
<!--Escrow Container Element-->
<element name="escrow" type="whoisdb:whoisDbType" />
<complexType name="whoisDbType">
<choice>
   <element name="full" type="whoisdb:fullsetType" />
   <element name="incremental" type="whoisdb:partialType" />
</choice>
<attribute name="tld" type="whoisdb:tldType" use="required" />
<attribute name="date" type="dateTime" use="required" />
<attribute name="version" type="decimal" use="required" />
</complexType>
<simpleType name="tldType">
<restriction base="string">
   <enumeration value="coop" />
</restriction>
</simpleType>
<!--Container elements for full and incremental sets-->
<complexType name="fullsetType">
<sequence minOccurs="1">
   <element name="contact" type="whoisdb:contactType" minOccurs="0" maxOccurs="unbounded" />
   <element name="domain" type="whoisdb:domainType" minOccurs="0" maxOccurs="unbounded" />
   <element name="host" type="whoisdb:hostType" minOccurs="0" maxOccurs="unbounded" />
   <element name="registrar" type="whoisdb:registrarType" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="partialType">
<sequence minOccurs="1">
   <element name="contact" type="whoisdb:contactType" minOccurs="0" maxOccurs="unbounded" />
   <element name="domain" type="whoisdb:domainType" minOccurs="0" maxOccurs="unbounded" />
   <element name="host" type="whoisdb:hostType" minOccurs="0" maxOccurs="unbounded" />
   <element name="registrar" type="whoisdb:registrarType" minOccurs="0" maxOccurs="unbounded" />
   <element name="transaction" type="whoisdb:transactionType" minOccurs="0" maxOccurs="unbounded" />
</sequence>
</complexType>
<!--Domain element-->
<complexType name="domainType">
<sequence>
   <element name="roid" type="eppcom:roidType" />
   <element name="status" type="domain:statusType" minOccurs="1" maxOccurs="14" />
   <element name="registrant" type="domain:contactType" maxOccurs="1" />
   <element name="contact-id" type="domain:contactType" minOccurs="0" maxOccurs="unbounded" />
   <element name="host" type="eppcom:labelType" minOccurs="0" maxOccurs="13" />
   <element name="owned-by" type="whoisdb:registrarIanaIDType" />
   <element name="authInfo" type="domain:authInfoType" />
   <element name="created-on" type="dateTime" />
   <element name="created-by" type="whoisdb:registrarIanaIDType" />
   <element name="renewed-on" type="dateTime" minOccurs="0" />
   <element name="expires-on" type="dateTime" />
   <element name="updated-by" type="whoisdb:registrarIanaIDType" minOccurs="0" />
   <element name="updated-on" type="dateTime" minOccurs="0" />
   <element name="transferred-by" type="whoisdb:registrarIanaIDType" minOccurs="0" />
   <element name="transferred-on" type="dateTime" minOccurs="0" />
</sequence>
<attribute name="fqdn" type="eppcom:labelType" use="required" />
</complexType>

<!--Host element-->
<complexType name="hostType">
<sequence>
   <element name="roid" type="eppcom:roidType"/>
   <element name="owned-by" type="whoisdb:registrarIanaIDType" />
   <element name="created-on" type="dateTime" />
   <element name="updated-by" type="whoisdb:registrarIanaIDType" minOccurs="0" />
   <element name="updated-on" type="dateTime" minOccurs="0" />
   <element name="ip-address" type="host:addrType" minOccurs="0" maxOccurs="unbounded"/>
   <element name="status" type="host:statusType" maxOccurs="7"/>
</sequence>
<attribute name="fqdn" type="eppcom:labelType" use="required" />
</complexType>

<!--Contact element-->
<complexType name="contactType">
<sequence>
   <element name="roid" type="eppcom:roidType" />
   <element name="ascii-postalinfo" type="contact:postalInfoType" maxOccurs="1" />
   <element name="unicode-postalinfo" type="contact:postalInfoType" minOccurs="0" maxOccurs="1" />
   <element name="voice" type="contact:e164Type" minOccurs="0" />
   <element name="fax" type="contact:e164Type" minOccurs="0" />
   <element name="email" type="eppcom:minTokenType" />
   <element name="owned-by" type="whoisdb:registrarIanaIDType" />
   <element name="created-by" type="whoisdb:registrarIanaIDType" />
   <element name="created-on" type="dateTime" />
   <element name="updated-by" type="whoisdb:registrarIanaIDType" minOccurs="0" />
   <element name="updated-on" type="dateTime" minOccurs="0" />
   <element name="transferred-by" type="whoisdb:registrarIanaIDType" minOccurs="0" />
   <element name="transferred-on" type="dateTime" minOccurs="0" />
   <element name="authInfo" type="contact:authInfoType" minOccurs="0" />
   <element name="status" type="contact:statusType" maxOccurs="8" />
   <element name="coop-specific" type="coopExt:infDataType" />
</sequence>
<attribute name="id" type="eppcom:clIDType" use="required" />
</complexType>

<!--Registrar elements-->
<complexType name="registrarType">
<sequence>
   <element name="password" type="token" />
   <element name="full-name" type="whoisdb:registrarNameType" />
   <element name="iana-id" type="whoisdb:registrarIanaIDType" />
   <element name="web-url" type="whoisdb:registrarWebUrlType" />
   <element name="status" type="whoisdb:registrarStatusType" />
   <element name="address" type="contact:addrType" />
   <element name="voice" type="contact:e164Type" />
   <element name="fax" type="contact:e164Type" minOccurs="0" />         
   <element name="contact" type="whoisdb:registrarContactType" maxOccurs="unbounded" />
   <element name="created-on" type="dateTime" />
   <element name="updated-on" type="dateTime" minOccurs="0" />
</sequence>
<attribute name="id" type="whoisdb:registrarNameType" use="required" />
</complexType>

<complexType name="sRegistrarIanaIDType">
<sequence>
   <element name="id" type="whoisdb:registrarIanaIDType" />
</sequence>
</complexType>

<simpleType name="registrarIanaIDType">
<restriction base="token" />
</simpleType>   

<simpleType name="registrarNameType">
<restriction base="token">
   <minLength value="1" />
   <maxLength value="128" />
</restriction>
</simpleType>

<simpleType name="registrarWebUrlType">
<restriction base="token" />
</simpleType>

<complexType name="registrarContactType">
<sequence>
   <element name="address" type="contact:postalInfoType" />
   <element name="voice" type="contact:e164Type" minOccurs="0" />
   <element name="fax" type="contact:e164Type" minOccurs="0" />
   <element name="email" type="eppcom:minTokenType" />
</sequence>
<attribute name="type" type="whoisdb:registrarContactStatusType" use="required" />
</complexType>

<simpleType name="registrarContactStatusType">
<restriction base="string">
   <enumeration value="administrative" />
   <enumeration value="billing" />
   <enumeration value="technical" />
   <enumeration value="legal" />
</restriction>
</simpleType>

<simpleType name="registrarStatusType">
<restriction base="string">
   <enumeration value="active" />
   <enumeration value="suspended" />
   <enumeration value="defunct" />
</restriction>
</simpleType>

<!-- Transaction types-->
<complexType name="transactionType">
<choice minOccurs="1" maxOccurs="1">
   <element name="contact" type="whoisdb:contactType" minOccurs="1" maxOccurs="1" />
   <element name="domain" type="whoisdb:domainType" minOccurs="1" maxOccurs="1" />
   <element name="host" type="whoisdb:hostType" minOccurs="1" maxOccurs="1" />
   <element name="registrar" type="whoisdb:registrarType" minOccurs="1" maxOccurs="1" />
</choice>
<attribute name="operation" type="whoisdb:transactionOperationType" use="required" />
<attribute name="type" type="whoisdb:transactionObjectType" use="required" />
</complexType>

<simpleType name="transactionOperationType">
<restriction base="string">
   <enumeration value="add" />
   <enumeration value="modify" />
   <enumeration value="delete" />
</restriction>
</simpleType>

<simpleType name="transactionObjectType">
<restriction base="string">
   <enumeration value="domain" />
   <enumeration value="host" />
   <enumeration value="registrar" />
   <enumeration value="contact" />
</restriction>
</simpleType>
</schema>



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

3. Next, the Deposit file will be processed by a program (within 90 days of such time as program is 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.

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 .MDS file (produced with MDSSUM 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 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. Each Deposit file will be decrypted using Escrow Agent's private key for PGP and authenticated using Registry Operator's public key for PGP. (In this step, PGP will also automatically decompress the escrow file).

3. If there are multiple files, they will be concatenated in sequence.

4. Escrow Agent will run a program (within 90 days of such time as the program is 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. The 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 email to an email 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.