Unsponsored TLD Agreement: Appendix R (.name)

Unsponsored TLD Agreement: Appendix R (.name)

(29 Jun 2001)

Data Escrow Schedule, Content, Format, and Procedure

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.

Full Deposit Schedule

Full Deposits shall consist of data that reflects the state of the registry as of 0000 GMT 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 will start, according to the transfer process described in Exhibit C below, within a four-hour window beginning at 0000 GMT on the following Monday. The time for transferring data will change during the ramp-up period to a start time that is related to the optimal bandwidth, within the 24 hour time limit from 1200 GMT on each Sunday. The escrow agent will be notified about the change within the time that Registry Operator and the escrow agent agree upon.

Incremental Deposit Schedule

Incremental Deposits shall reflect database transactions made since the most recent Full or Incremental Deposit. The Incremental Deposit for Monday shall include transactions completed by 0000 GMT 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 by 0000 GMT on the day of the deposit that were not reflected in the immediately prior Incremental Deposit.

Incremental Deposits will start, according to the transfer process described in Exhibit C below, within a four-hour window beginning at 0000 GMT on following day. The time for transferring data will change during the ramp-up period to a start time that is related to the optimal bandwidth, within 24 hours time limit from 1200 GMT on each day the Incremental Deposit will be made. The escrow agent will be notified about the change within the time that Registry Operator and the escrow agent agree upon.

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].

Each Full and Incremental Deposit consists of a series of files that are generated in the Escrow Process.

Full Deposit Contents. The reports involved in a Full Deposit will include, but not be limited to:

• Registrar Object Report - this will detail the contents of known registrars in the Registry Database.
  
  
  
  
• Domain Object Report - this will detail the contents of valid domains in the Registry Database
  
  
  
  
• SLD Email Object Report - this will detail the contents of valid SLD Email forwarding addresses in the Registry Database
  
  
  
  
• Contacts Object Report - this will detail active contacts within the Registry Database
  
  
  
  
• Nameserver Object Report - this will detail all known nameservers within the Registry Database
  
  
  
  
• Namewatch Object Report - this will detail the contents of valid Namewatch entries in the Registry Database
  
  
  
  
• Defensive Registration Object Report - this will detail the contents of valid Defensive Registrations in the Registry Database
  
  

Incremental Deposit Contents. This will solely consist of a transaction report. The transaction report will detail the contents of all transactions 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 "Escape-Character Requirements" below. Each Report shall then be prepared according to the general XML format described in subsequent items below. Item "The Report Container" describes the report container that is common to all reports. Subsequent items describe the structure of the contents of the report container for each of the specific reports. The format of the reports may be amended or changed upon 90 days notice if the database structure or number or structure of objects change

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

2. The Escrow Container. At its highest level, the XML format consists of an escrow container with header attributes followed by escrow data.

Attributes:
Tld - the name of the top level domain
Date - date of the escrow export
Report - type of data contained in the escrow container
Type - type of export (Full or Incremental)
Version - version number of the escrow

Elements:
Registrar - container for registrar data
Domain - container for domain data
Email - container for SLD Email data
Nameserver - container for nameserver data
Contact - container for contact data
Namewatch - container for Namewatch data
Transaction - container for transaction data
Defensive Registration - container for Defensive Registration data

E.g. an example escrow container may have the following:

<?xml version="1.0" encoding='UTF-8' ?>
<!DOCTYPE escrow SYSTEM "escrow-export.dtd" >
<escrow tld="name" date="19-Aug-2001 3:15:00AM" report="domain" type="Full" version="1.0" >

{Here is where the report containing the actual data being escrowed is placed. It contains one element for each object of the type (domain, SLD email, nameserver, contact, registrar, defensive registration, namewatch or transaction) covered by the report. The specific format for each report is described in the items below.}
</escrow>

3. The Registrar Element. The registrar element is a container consisting of the following data:

Attributes:
ID - unique identifier for this object type (corresponding to an entry in the IANA registrar-id database)
Status - the current status of the Registrar Element

Elements:
ContactID - contact point of registrar
URL - the home page for the company
Created - timestamp detailing when this record was created
Modified - timestamp detailing when this record was last altered

E.g. an example registrar container may have the following:

<registrar id="42" status="ok">
<contactid type="REGISTRAR">123</contactid>
<url>www.acmeregistrar.co.uk</url>
<created>2001-08-10-01.01.01</created>
<modified>2001-08-10-01.01.01</modified>
</registrar>

The Domain Element. This element will be a container holding the following data:

Attributes:
ID - unique identifier for this object type
FQDN - Fully Qualified Domain Name
Status - the current position of the domain

Elements:
RegistrarID - the identifier for the registrar within the Registry Database
Created - the timestamp detailing when this record came into existence
Expires - when the active status of the domain will expire
Modified - the timestamp stating when this record was last altered
NameServerID - up to 13 different nameservers for this particular domain record
ContactID - up to 4 different types of contact id for this particular domain record

E.g. an example domain container may have the following :

<domain id="123" fqdn="john.smith.name" status="ok">
<registrarid>42</registrarid>
<created>2001-08-10-12.34.56</created>
<expires>2002-08-10-12.34.56</expires>
<modified>2001-08-10-12.34.56</modified>
<nameserverid>312</nameserverid>
<nameserverid>321</nameserverid>
<contactid type="REGISTRANT">111</contactid>
<contactid type="ADMINISTRATIVE">222</contactid>
<contactid type="TECHNICAL">333</contactid>
<contactid type="BILLING">444</contactid>
</domain>

The SLD Email Element. This element will be a container holding the following data :

Attributes:
ID - unique identifier for this object type
Address - email address for the SLD Email object
Status - the current position of the SLD Email

Elements:
RegistrarID - the identifier for the registrar within the Registry Database
Forward - recipient of forwarded mail
Created - the timestamp detailing when this record came into existence
Expires - when the active status of the SLD Email will expire
Modified - the timestamp stating when this record was last altered
ContactID - up to 4 different types of contact id for this particular record

Example:

<email id="123" address="john@smith.name" status="ok">
<registrarid>42</registrarid>
<forward>john@acme.co.uk</forward>
<created>2001-08-10-12.34.56</created>
<expires>2002-08-10-12.34.56</expires>
<modified>2001-08-10-12.34.56</modified>
<contactid type="REGISTRANT">111</contactid>
<contactid type="ADMINISTRATIVE">222</contactid>
<contactid type="TECHNICAL">333</contactid>
<contactid type="BILLING">444</contactid>
</email>

The Nameserver Element. This element consists of the following data:

Attributes:
ID - unique identifier for this object type
FQDN - Fully Qualified Domain Name for the nameserver
Status - current standing

Elements:
RegistrarID - the identifier for the registrar within the Registry Database
Created - timestamp detailing when this record was created
Modified - timestamp detailing when this record was last altered
Ipaddress - up to 13 unique IP addresses for each nameserver

E.g. an example nameserver container may have the following :

<nameserver id="312" fqdn="dns1.example.name" status="ok">
<registrarid>42</registrarid>
<created>2001-08-10-22.31.12</created>
<modified>2001-08-10-22.31.12</modified>
<ipaddress>192.168.1.11</ipaddress>
<ipaddress>192.168.1.12</ipaddress>
</nameserver>

The Contact Element. The contact element is a container consisting of the following data:

Attributes:
ID - unique identifier for this object type
Status - current standing

Elements:
Name - the name of the contact
RegistrarID- the sponsoring registrar for this record
Address - a free form field for the address of the contact
City - the town or city where the contact resides
State/Province - the state/province where the contact resides
Country - the country for this contact point
PostCode - the postal code where the contact resides
Telephone - the voice telephone number for this contact
Fax - a facsimile number for this contact
Email - an electronic address to reach the contact by
Created - timestamp detailing when this record was created
Modified - the timestamp detailing the time of the last update

E.g. an example contact container may have the following :

<contact id="111" status="ok">
<name>John Smith</name>
<registrarid>222</registrarid>
<address>32, Hill Avenue</address>
<city>New Town</city>
<state>Beluga</state>
<country>UK</country>
<postcode>PP1 2PP</postcode>
<telephone>+44.2055551111</telephone>
<fax>+44.2072061234</fax>
<emailaddress>john@acmework.co.uk</emailaddress>
<created>2001-08-10-02.31.12</created>
<modified>2001-08-10-10.58.12.123456</modified>
</contact>

The Namewatch Element. This element consists of the following data:

Attributes:
ID - unique identifier for this object type
Status - current standing of this record

Elements:
RegistrarID - the identifier for the registrar performing the update within the Registry Database
Report - Defines the frequency of reporting
String - The Namewatch string specified by the registrant
Wildcard - Specifies how to match the string.
Level - Specifies which level (second or third level domain or both)
ContactID - Contact id for this particular record
Created - the timestamp detailing when this record came into existence
Expires - when this record will expire
Modified - the timestamp stating when this record was last altered

E.g. a Namewatch container may hold the following data :

<namewatch id="1234" status="ok">
<registrarid>42</registrarid>
<report type="WEEKLY" />
<string>acme</string>
<wildcard type="CONTAINS" />
<level type="SECOND" />
<contactid type="REGISTRANT">111</contactid>
<created>2001-08-10-12.34.56</created>
<expires>2002-08-10-12.34.56</expires>
<modified>2001-08-10-12.34.56</modified>
</namewatch>

The Transaction Element. This element consists of the following data:

Attributes:
ID - unique identifier for this object type
Type - the action which was performed

Elements:
RegistrarID - the identifier for the registrar performing the update within the Registry Database
Object - the identifier to the object with the Registry Database
Timestamp - the time of the transaction within the database, and the moment this record came into existence

E.g. a transaction container may hold the following data :

<transaction id="1234" type="INSERT">
<registrarid>42</registrarid>
<object type="DOMAIN">123</object>
<timestamp>2001-08-10-12.34.56.123456</timestamp>
</transaction>

The Defensive Registrations Element. This element consists of the following data:

Attributes:
ID - unique identifier for this object type
Status - current standing of this record

Elements:
RegistrarID - the identifier for the registrar performing the update within the Registry Database
String - The Defensive Registration string specified by the registrant
Level - Specifies which level (second or third level domain or both)
TrademarkID - Trademark registration identifier
Trademark country - where this trademark is registered
Tm reg date - when the trademark was registered
ContactID - up to 3 Contact IDs for this particular record
Created - the timestamp detailing when this record came into existence
Expires - when this record will expire
Modified - the timestamp stating when this record was last altered

E.g. a defensive registration container may hold the following data :

<defensiveregistration id="1234" status="ok">
<registrarid>42</registrarid>
<string>acme</string>
<level type="THIRD" />
<trademarkid>tm 125549</trademark>
<trademarkcountry>uk</trademarkcountry>
<tmregdate>2001-06-22</tmregdate>
<contactid type="REGISTRANT">111</contactid>
<contactid type="ADMINISTRATIVE">222</contactid>
<contactid type="BILLING">333</contactid>
<created>2001-08-10-12.34.56</created>
<expires>2002-08-10-12.34.56</expires>
<modified>2001-08-10-12.34.56</modified>
</defensiveregistration>

DTD For Escrow Files

The following section defines the DTD for validating Escrow files.

<?xml version="1.0" encoding='UTF-8' ?>
<!ELEMENT escrow (registrar*, domain*, email*, nameserver*, contact*, namewatch*, transaction*, defensiveregistration*)>
<!ATTLIST escrow
tld NMTOKEN #FIXED name
date CDATA #REQUIRED
report (domain | nameserver | contact | registrar | transaction | namewatch | defreg) #REQUIRED
type (Full | Incremental) #REQUIRED
version CDATA #FIXED 1.0>








<!ELEMENT registrar (contactid, url, created, modified)
<!ATTLIST registrar
id CDATA #REQUIRED,
status (inactive | ok) #REQUIRED>




<!ELEMENT domain (registrarid, created, expires, modified, nameserverid+, contactid+)>
<!ATTLIST domain
id CDATA #REQUIRED
fqdn CDATA #REQUIRED
status (clientDeleteProhibited | clientHold | clientRenewProhibited | clientTransferProhibited | clientUpdateProhibited | inactive | ok | pendingDelete | pendingTransfer | pendingVerification | serverDeleteProhibited | serverHold | serverRenewProhibited | serverTransferProhibited | serverUpdateProhibited) #REQUIRED>





<!ELEMENT email (registrarid, forward, created, expires, modified, contactid+)>
<!ATTLIST email
id CDATA #REQUIRED
address CDATA #REQUIRED
status (clientDeleteProhibited | clientHold | clientRenewProhibited | clientTransferProhibited | clientUpdateProhibited | inactive | ok | pendingDelete | pendingTransfer | pendingVerification | serverDeleteProhibited | serverHold | serverRenewProhibited | serverTransferProhibited | serverUpdateProhibited) #REQUIRED>





<!ELEMENT nameserver (registrarid, created, modified, ipaddress+)>
<!ATTLIST nameserver
id CDATA #REQUIRED
fqdn CDATA #REQUIRED
status (clientDeleteProhibited | clientUpdateProhibited | linked | ok | pendingDelete | pendingTransfer | serverDeleteProhibited | serverUpdateProhibited) #REQUIRED>





<!ELEMENT contact (name, registrarid, address, city, state, country, postcode, telephone, fax, emailaddress, created, modified)>
<!ATTLIST contact
id CDATA #REQUIRED
status (clientDeleteProhibited | clientTransferProhibited | clientUpdateProhibited | linked | ok | pendingDelete | pendingTransfer | serverDeleteProhibited | serverTransferProhibited | serverUpdateProhibited) #REQUIRED>




<!ELEMENT namewatch (registrarid, report, string, wildcard, level, contactid, created, expires, modified)>
<!ATTLIST namewatch
id CDATA #REQUIRED
status (inactive | ok) #REQUIRED>




<!ELEMENT transaction (registrarid, object, timestamp)>
<!ATTLIST transaction
id CDATA #REQUIRED
type (INSERT|DELETE|TRANSFER|UPDATE) #REQUIRED>




<!ELEMENT defensiveregistration (registrarid, string, level, trademarkid, trademarkcountry, tmregdate, contactid+, created, expires, modified)>
<!ATTLIST defensiveregistration
id CDATA #REQUIRED
status (clientDeleteProhibited | clientHold | clientRenewProhibited | clientTransferProhibited | clientUpdateProhibited | inactive | ok | pendingDelete | pendingTransfer | pendingVerification | serverDeleteProhibited | serverHold | serverRenewProhibited | serverTransferProhibited | serverUpdateProhibited) #REQUIRED>




<!ELEMENT name (#PCDATA)>

<!ELEMENT address (#PCDATA)>

<!ELEMENT city (#PCDATA)>

<!ELEMENT state (#PCDATA)>

<!ELEMENT country (#PCDATA)>

<!ELEMENT postcode (#PCDATA)>

<!ELEMENT telephone (#PCDATA)>

<!ELEMENT url (#PCDATA)>

<!ELEMENT created (#PCDATA)>

<!ELEMENT modified (#PCDATA)>

<!ELEMENT expires (#PCDATA)>

<!ELEMENT registrarid (#PCDATA)>

<!ELEMENT nameserverid (#PCDATA)>

<!ELEMENT contactid (#PCDATA)>
<!ATTLIST contactid
type (REGISTRANT|REGISTRAR|ADMINISTRATIVE|BILLING|TECHNICAL) #REQUIRED>



<!ELEMENT forward (#PCDATA)>

<!ELEMENT ipaddress (#PCDATA)>

<!ELEMENT fax (#PCDATA)>

<!ELEMENT emailaddress (#PCDATA)>

<!ELEMENT report EMPTY>
<!ATTLIST report
type (DAILY|WEEKLY|MONTHLY) #REQUIRED>



<!ELEMENT string (#PCDATA)>

<!ELEMENT wildcard EMPTY>
<!ATTLIST wildcard
type (STARTS_WITH|CONTAINS|ENDS_WITH) #REQUIRED>



<!ELEMENT level EMPTY>
<!ATTLIST level
type (SECOND|THIRD|BOTH) #REQUIRED>



<!ELEMENT object (#PCDATA)>
<!ATTLIST object
type (DOMAIN|EMAIL|NAMESERVER|CONTACT|NAMEWATCH|DEFREG) #REQUIRED>



<!ELEMENT timestamp (#PCDATA)>

<!ELEMENT trademarkid (#PCDATA)>

<!ELEMENT trademarkcountry (#PCDATA)>

<!ELEMENT tmregdate (#PCDATA)>

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

1. The files making up the Deposit will first be generated 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: "nameSEQN", 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 (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 640MB each (except the final file). If Deposit files are split, a .MD5 file (produced with MD5SUM or equivalent) must be included with the split files to isolate errors in case of transfer fault.

5. Thereafter encrypt the files using escrow agent's public key for PGP and signed using Registry Operator's private key for PGP, both versions 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. The file will be named in the form <TLD>CCYYMMDD.PGP (e.g. name20010810.PGP). (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, e-mail, or similar, which will be agreed by Registry Operator and the escrow agent, starting within the specified time window. The Registry Operator appreciates that after a certain period of time, the size of the files requiring transfer to escrow may exceed a size that will be safe for electronic transmission. At that time manual procedures will be developed to ensure that the escrow transfer obligations of the Registry continue to be complied with.

Verification Procedures. Escrow agent will verify the format and completeness of each Deposit by the following steps:

1. When the transfer is done, 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. The PGP software must be compatible to the software specified in Exhibit C and this will additionally decompress the data therein.

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

4. The escrow agent will run a program on the Deposit file (without report) that will split it into 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 and the database dropped 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 and ICANN shall exchange keys by the same procedure.

Page Updated 24-Dec-2002

©2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.