|
|
Registrar
Data Escrow
Posted: 8 November
2001
|
These draft documents were not implemented and are provided for historical purposes. Details of the implementation of the Registrar Data Escrow program are posted at http://www.icann.org/en/news/announcements/announcement-2-09nov07-en.htm.
Registrar
Data Escrow
Table of Contents
Introduction
After consultation with
a committee of registrars, plans are moving forward for implementing
periodic escrow of gTLD registrar data as soon as possible. When operational,
the escrow program will enhance the stability of customers' domain
name registrations in gTLDs. In particular, it will preserve domain
registration information to permit continuing registrar services even
in the case of total failure of a registrar's data storage systems
-- thereby increasing consumer confidence in the gTLD shared registry
architecture.
Prior to a full rollout
of the escrow system to all accredited registrars, implementation
will begin with a testbed consisting of a small number of volunteer
registrars. Several major registrars have already agreed to participate
in this testbed. Additional accredited registrars interested in volunteering
for early participation in the escrow system should e-mail <data-escrow@icann.org>,
or contact Chief Registrar Liaison Dan Halloran.
The current version of
the ICANN Registrar
Accreditation Agreement ("RAA") obliges registrars to
periodically submit a copy of their registration database to ICANN
or a mutually-approved third-party escrow agent. This escrowed data
could be used by another registrar assigned by ICANN (or even temporarily
by ICANN itself) to continue the provision of registrar services to
the customers of a registrar whose accreditation is terminated or
expires without renewal.
The Data Escrow provision
is set forth in RAA subsection
3.6, which provides as follows:
"During the Term
of this Agreement, on a schedule, under the terms, and in the format
specified by ICANN, Registrar shall submit an electronic copy of
the database described in Subsection 3.4.1 to ICANN or, at Registrar's
election and at its expense, to a reputable escrow agent mutually
approved by Registrar and ICANN, such approval also not to be unreasonably
withheld by either party. The data shall be held under an agreement
among Registrar, ICANN, and the escrow agent (if any) providing
that (1) the data shall be received and held in escrow, with no
use other than verification that the deposited data is complete,
consistent, and in proper format, until released to ICANN; (2) the
data shall be released from escrow upon expiration without renewal
or termination of this Agreement; and (3) ICANN's rights under the
escrow agreement shall be assigned with any assignment of this Agreement.
The escrow shall provide that in the event the escrow is released
under this Subsection, ICANN (or its assignee) shall have a non-exclusive,
irrevocable, royalty-free license to exercise (only for transitional
purposes) or have exercised all rights necessary to provide Registrar
Services."
Under the testbed escrow
program:
- Full escrow will take
place weekly.
- Escrow will follow one
of two formats specified by ICANN: "text-delimited" or
XML.
- Escrow data will be
encrypted and transmitted via FTP from registrar to the designated
escrow agent.
- Each registrar may
choose to escrow its data with either a third-party escrow agent
(at the registrar's own expense) or with ICANN. Third-party escrow
agents will process data received with validation scripts (to be
provided by ICANN), and will send script output to ICANN for verification.
- Third-party escrow agents
and ICANN will maintain escrow data in secure facilities, and escrow
data will only be used in case of registrar de-accreditation.
- ICANN will publish registrar
escrow deposit success statistics.
- Registrars in compliance
with the data escrow program will be entitled to display the logo
above.
ICANN seeks advice from
the Internet community (including registrars) on several additional
details:
- How should the testbed
voluntary program be broadened to other registrars, and under what
schedule?
- Should a list of approved
third-party escrow agents be established, or should they be selected
and approved on a case-by-case basis?
- Should other options
for deposit transmission (such as by mailed tape/CD-R) be opened
in a further rollout of the program?
- Should registrar escrow
success results be published to the public? If so, on what level
of granularity and with what frequency?
- What disaster recovery
procedures should be established to enable the use of the escrowed
data in the event it becomes necessary?
- Should customers of
a failed registrar all be allocated to one registrar, or be split
among several registrars, or should customers choose?
A task force including
technical experts from the Registrars Constituency created the specification
for the format of the escrowed data. The committee created two recommended
data format specifications: "text-delimited" and XML. (*We
extend our sincere thanks to Rick Wesson of Alice's
Registry, CTO of ICANN's Registrar Constituency, who authored
the DTD for the XML format. Also, we are grateful to Ben Edelman for
his coordination of the Registrar Data Escrow Task Force.) These draft
specifications have been incorporated as an exhibit to a new "Registrar
Data Escrow Appendix" (to the Registrar Accreditation Agreement)
that is being discussed with the testbed participants. This appendix
also sets forth the deposit procedures, data security provisions,
release conditions, right-to-use terms, and the license for a new
ICANN Data Escrow Program logo.
Registrars and other interested
parties are invited to suggest improvements that might be made as
the escrow program expands beyond the initial testbed, and to offer
advice on the questions raised above. Technical corrections are also
invited. A Public Comment Forum on Registrar Data Escrow has been
established for this purpose at <http://forum.icann.org/escrow/>.
Registrar
Data Escrow Appendix
This Registrar Data Escrow
Appendix ("Escrow Appendix") is made and entered into by
and between [Registrar Name] ("Registrar") and the Internet
Corporation for Assigned Names and Numbers ("ICANN"). ICANN
and Registrar have entered into a Registrar Accreditation Agreement
("Accreditation Agreement"), which shall govern this Escrow
Appendix and of which this Escrow Appendix is a part. All capitalized
terms not defined in this Escrow Appendix shall have the meanings
set forth in the Accreditation Agreement.
In accordance with the
Accreditation Agreement, Registrar intends to deliver periodically
to ICANN or a third-party escrow agent an electronic copy of its current
database containing data for each active Registered Name sponsored
by Registrar within each TLD for which Registrar is accredited, as
detailed in Subsection 3.4.1 of the Accreditation Agreement (each
such delivery referred to as a "Deposit"). Pursuant to and
subject to the Accreditation Agreement, Registrar and ICANN hereby
agree as follows:
1. Escrow Agent.
Unless Registrar indicates otherwise in writing prior to or simultaneous
with the execution and delivery of this Escrow Appendix, Registrar
shall deliver the Deposits to be held in escrow to ICANN as the escrow
agent according to the terms and conditions in this Escrow Appendix,
which refers to ICANN as both "ICANN" and "Escrow Agent."
ICANN may, as the Escrow Agent, engage third parties to furnish the
escrow services hereunder, provided that such engagement will not
relieve ICANN from any of its obligations under this Escrow Appendix.
Registrar may elect at any time to have a third-party escrow agent
hold the Deposits, in which case:
1.1. Registrar shall
notify ICANN of such election in writing;
1.2. Any third-party
escrow agent shall be mutually approved by Registrar and ICANN,
such approval not to be unreasonably withheld by either party;
1.3. Registrar shall
use its best efforts to negotiate a written escrow agreement with
such mutually approved third-party escrow agent that includes any
provisions or language provided by ICANN and Exhibits A and B attached
hereto, and Registrar shall present to ICANN, for ICANN's approval
not to be unreasonably withheld, an unexecuted draft(s) of such
escrow agreement;
1.4. Such escrow agreement
between Registrar and the third-party escrow agent, once approved
by ICANN and executed, shall govern the delivery, holding, release,
and other aspects of such Deposits, subject to this Escrow Appendix
and the Accreditation Agreement; and
1.5. During any period
when Deposits are not being made by Registrar pursuant to such an
escrow agreement with a third-party escrow agent (due to termination
of the escrow agreement, unsuccessful negotiation and/or approval
of such an agreement, or otherwise) Registrar agrees to deliver
such Deposits to ICANN pursuant to the sections of this Escrow Appendix
that follow.
2. Deposit Content and
Procedure.
2.1. Content of Deposits.
Each Deposit will consist of data that reflects the current and
complete database containing data for each active Registered Name
sponsored by Registrar within each TLD for which Registrar is accredited,
as detailed in Subsection 3.4.1 of the Accreditation Agreement.
2.2. Format of Deposits.
The data in each Deposit shall follow the data format(s) specified
in the Data Format Specification (the "Format Specification"),
attached hereto as Exhibit B, which may be amended from time to
time by ICANN.
2.3. Schedule for Deposits.
Registrar must create and deliver to Escrow Agent a new, updated
Deposit once per week, according to the schedule specified in Exhibit
A, which may be amended from time to time by ICANN. In the interests
of openness and transparency, the parties agree that ICANN may disclose
statistics indicating Registrar's timely deposit rate for Deposits
made pursuant to this Escrow Appendix.
2.4. Procedure for Deposits.
Each properly formatted Deposit shall be processed and electronically
delivered in encrypted form to Escrow Agent according to the transfer
process described in Exhibit A.
2.5. Notification of
Deposits. Simultaneously with the delivery to Escrow Agent of any
Deposit, Registrar shall deliver to ICANN a written delivery report
(as described in Exhibit A) which states that the Deposit has been
inspected by Registrar according to the procedures described in
Exhibit A and is complete and accurate.
2.6. Verification. After
receiving any Deposit, Escrow Agent shall verify the format and
completeness of each such Deposit by performing the verification
procedures in Exhibit A. Upon notification that any Deposit has
failed the verification procedures, Registrar shall begin developing
modifications, updates, corrections, and other fixes of the Deposit
necessary for the Deposit to pass the verification procedures and
shall deliver the remediated Deposit to Escrow Agent as promptly
as possible. The failure of any Deposit to meet the verification
procedures and any efforts by Registrar to remedy such failure shall
not delay the delivery of any subsequent scheduled Deposits pursuant
to the schedule in Exhibit A.
3. Data Security.
3.1. Retention. Escrow
Agent shall hold and maintain the Deposits in a secure, locked,
and environmentally safe facility which is accessible only to authorized
representatives. The Deposits shall be received and held in escrow,
with no use other than verification that the Deposits are complete,
consistent, and in proper format, until released to ICANN.
3.2. Confidentiality.
Escrow Agent shall use commercially reasonable efforts to protect
the integrity and confidentiality of the Deposits. Escrow Agent
shall not disclose or use any Deposit except as provided in this
Escrow Appendix. Escrow Agent shall not be held liable for any disclosure
required by governmental, legislative, judicial, or arbitral order,
statute, or rule.
3.3. Destruction and
Duplication. At all times, Escrow Agent shall retain the four (4)
most recent Deposits, all of which must have passed the verification
procedures specified in Exhibit A. Escrow Agent may destroy any
Deposits prior to these four (4) most recent Deposits. Escrow Agent
may duplicate any Deposit by any commercially reasonable means in
order to comply with the terms and provisions of this Escrow Appendix.
4. Release of Deposit
to ICANN.
4.1. Release Conditions.
All Deposits in Escrow Agent's possession (in decrypted form and/or
along with all necessary decryption keys) shall be released to ICANN,
at ICANN's discretion, request, and instruction, upon the occurrence
of any of the following:
4.1.1. Expiration
of the Accreditation Agreement without renewal;
4.1.2. Termination
of the Accreditation Agreement; or
4.1.3. Written notice
by Registrar requesting the release of the Deposits to ICANN.
4.2. Right to Use Deposits.
Upon release of the Deposits to ICANN, ICANN (or its assignee) shall
immediately have a non-exclusive, irrevocable, royalty-free license
to exercise (only for transitional purposes) or have exercised all
rights necessary to provide Registrar Services, as detailed in the
Accreditation Agreement. Any claims or disputes relating to or arising
out of this Escrow Appendix shall be resolved pursuant to Section
5.6 of the Accreditation Agreement. The parties agree that any election
to resolve a dispute pursuant to Section 5.6 of the Accreditation
Agreement shall not delay release of any Deposits to ICANN pursuant
to Section 4.1.
5. ICANN Data Escrow
Program Logo License.
5.1. Grant of License.
ICANN grants to Registrar a non-exclusive, worldwide right and license
to use the ICANN Data Escrow Program Logo attached as Exhibit C
hereto (the "Logo"), during the term of this Escrow Appendix
and solely in connection with the provision and marketing of Registrar
Services in order to indicate that Registrar is accredited as a
registrar of domain names by ICANN and has been and is depositing
its registration data in accordance with this Escrow Appendix. Except
as provided in this subsection, Registrar shall not use the Logo,
any term, phrase, or design which is confusingly similar to the
Logo or any portion of the Logo in any manner whatsoever. Registrar
shall not sublicense any of its rights under this Section 5 to any
other person or entity (including any of Registrar's resellers)
without the prior written approval of ICANN.
5.2. Ownership of Logo.
Any and all rights in the Logo that may be acquired by Registrar
shall inure to the benefit of, and are hereby assigned to, ICANN.
Registrar shall not assert ownership of the Logo or any associated
goodwill. Registration and any other form of protection for the
Logo shall only be obtained by ICANN in its name and at its expense.
5.3. Enforcement. Registrar
shall promptly notify ICANN of any actual or suspected infringement
of the Logo by third parties, including Registrar's resellers or
affiliates. ICANN shall have the sole discretion to initiate and
maintain any legal proceedings against such third parties; Registrar
shall not take any such actions without the prior written approval
of ICANN; and ICANN shall retain any and all recoveries from such
actions.
5.4. Further Assurances.
Registrar agrees to execute such other documents and to take all
such actions as ICANN may request to effect the terms of this Section
5, including providing such materials (for example URLs and samples
of any promotional materials bearing the Logo), cooperation, and
assistance as may be reasonably required to assist ICANN in obtaining,
maintaining, and enforcing trademark registration(s) and any other
form of protection for the Logo.
6. Term and Termination.
This Escrow Appendix shall be effective from the date it is signed
below by both parties until the Expiration Date, unless and until
the Accreditation Agreement is earlier terminated. Sections 3.2, 4,
and 6 shall survive any termination of this Escrow Appendix.
IN WITNESS WHEREOF each
of the parties has caused its duly authorized officer to execute this
Escrow Appendix as of the date and year written below.
INTERNET CORPORATION
FOR ASSIGNED NAMES AND NUMBERS
4676 Admiralty Way, Suite 330
Marina del Rey, California 90292 USA
Telephone: 1/310/823-9358
Facsimile: 1/310/823-8649
By:__________________________
Name:
Title:
Dated:_________________,
200___
|
[Registrar Name]
[registrar street address]
[registrar city and state]
Telephone:
Facsimile:
By:__________________________
Name:
Title:
Dated:_________________,
200___
|
EXHIBIT
A
ESCROW
PROCEDURE AND DETAILS
1. DEPOSIT
FILE CREATION SCHEDULE
[No less than once per
week; day(s) to be specified by Escrow Agent].
2. DEPOSIT DELIVERY
SCHEDULE
[Within 24 hours of Deposit
creation; at a time window specified by Escrow Agent from time to
time].
3. DEPOSIT TRANSFER
PROCESS
Registrar shall prepare
and transfer the Deposit file by the following steps, in sequence:
A. The Deposit file
will first be created according to the selected format specification.
(See Exhibit B - "Format of Deposit"). Filenames will
follow a naming convention to be specified by ICANN.
B. Next, the Deposit
file will be processed by a program (provided by ICANN) that will
verify that it complies with the format specification, count the
number of domain objects in the file, and append to the file a
report of the program's results.
C. Registrar may optionally
split the resulting file using the Unix SPLIT command (or equivalent)
to produce files no less than 1GB 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.
D. The Deposit file(s)
will then be encrypted using Escrow Agent's public key for PGP
and signed using Registrar'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 in addition to encrypting
it.)]
E. The formatted,
encrypted and signed Deposit file will be sent, by anonymous file
transfer, to Escrow Agent's ftp server <ftp://_______________>
within the specified time window.
4. VERIFICATION OF TRANSFER
Escrow Agent will verify
the format and completeness of each Deposit by the following steps:
A. At the conclusion
of the deposit window, the Deposit will be moved to a not-publicly-accessible
directory and its existence and size will be noted.
B. The Deposit file
will be decrypted using Escrow Agent's private key for PGP and
authenticated using Registrar's public key for PGP. (In this step,
PGP will also automatically decompress the escrow file).
C. If there are multiple
files, they will be concatenated in sequence.
D. The format report
generated by Registrar will be detached from the file and stored.
E. Escrow Agent will
run a program on the Deposit file (without report) that will check
its format, count the number of objects, and verify that the data
set is internally consistent. This program will compare its results
with the results of the Registrar-generated format report, and
will generate a Deposit format and completeness report. Escrow
Agent will use the escrow completeness and format report to verify
that Deposits are being made in proper format and with complete
data. Escrow Agent may compare object counts in the reports with
other data to further verify completeness.
F. The decrypted Deposit
file will be destroyed to reduce likelihood of data loss to intruders
in case of partial security failure.
G. Escrow Agent shall
retain the encrypted Deposit as well as the decryption keys necessary
to decrypt the Deposit in the event of release to ICANN.
5. DISTRIBUTION OF PUBLIC
KEYS
Each of Registrar and
Escrow Agent will distribute its public key to the other party (Registrar
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
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.
6. FEE SCHEDULE
Fees to be paid by Registrar
shall be as follows: [________________]
EXHIBIT
B
DATA FORMAT
SPECIFICATION
This document
defines the formats in which ICANN-accredited registrars make escrow
Deposits. There are two alternative formats, from which the registrar
may choose: text-delimited and XML.
The text-delimited format
is designed to be a simple format that supports flat-file export of
domain objects (records). The XML format is more complex, but can
support additional features. For example, in the XML format domain
objects may be written with server and contact objects contained within
the domain objects (i.e. a flat-file model), or they written as separate
objects and referenced in domain objects (i.e. a relational model).
ESCAPE-CHARACTER AND
FORMATTING REQUIREMENTS
In compliance with the
XML 1.0 specification, data escrowed using the XML format the following
characters in any data elements must be replaced with the corresponding
delimiters listed here:
Character |
Delimiters |
"
|
" |
& |
& |
' |
' |
< |
< |
> |
> |
In the text-delimited format,
only the right angle-bracket ("<") and ampersand must
be replaced with their corresponding delimiters. The carriage return
may not be used in the text-delimited format except for record termination
and in the header.
Throughout both text-delimited
and XML format escrow files, dates will be specified in format day-month-year
hour:minutes:seconds AM/PM, with [_____________________]
XML
FORMAT
The escrow file may also
be formatted in XML format. The XML format offers all the features
of the text-delimited format as well additional flexibility to represent
data in a related-object model. The required escrow information is
the same for XML as for text-delimited, but it often can be represented
in a shorter file in XML format. The XML format is also more flexible,
as described in the following discussion of the schema of the XML
data format specification.
The Escrow Container.
At its highest level, the XML format consists of an escrow container
with header attributes followed by escrow data:
o The header attributes
are required and include the version of escrow (1.0), registrar
number, and date and time of escrow. The registrar number will be
uniquely assigned in coordination with Network Solutions Registry
and the IANA (http://www.iana.org/numbers.htm).
The date and time of escrow will be specified in UTC.
o The remainder of the
escrow file contains the actual data being escrowed. It contains
one domain element for each domain name sponsored by the registrar
in the registry. It may also include other elements (such as server
and contact elements), as described below.
The Domain Container.
The domain element has the property "fqdn" (the fully qualified
name of the domain) and is a container consisting of the following
elements:
o Zero to thirteen ns
elements, representing the nameservers configured for the domain.
NS elements give the name, IP address(es) of the nameserver(s) (via
one or more IP elements), and dates of creation and modification
of nameservers. They may be specified inline, as follows:
<ns name="ns.isi.edu">
<ip>128.9.128.127</ip>
<created>3-Mar-1994</created>
<modified>4-Mar-1995</modified>
</ns>
Alternatively, the ns
object may point to a nameserver object directly under the escrow
container, with the following syntax:
<ns handle="ns.isi.edu"
/>
The nameserver element
would then have the following format:
<ns name="ns.isi.edu">
<ip>128.9.128.127</ip>
<created>3-Mar-1994</created>
<modified>4-Mar-1995</modified>
</ns>
o Created element. There
should be exactly one created element for each domain. This element
gives the date of the domain-name's original registration. Times
are specified as stored by the registry, in the local date and time
used by NSI Registry. This element has the following format:
<created date="04-Jul-1995"
/>
o Expires element. There
should be exactly one expires element for each domain. This element
gives the date of the registration's expiration. Times are specified
as stored by the NSI Registry, in the local date and time used by
registry. This element has the following format:
<expires date="05-Jul-2005"
/>
o Modified element.
There should be exactly one modified element for each domain. This
element gives the date of the registration's expiration date. Times
are specified as stored by the NSI Registry, in the local date and
time used by registry. This element has the following format:
<modified date="16-Sep-2000"
/>
o Organization element.
There should be exactly one organization element for each domain.
This gives the organization that registered the domain name. It
must give name and address data. This can be done inline by including
a name element and an address element in the container formed by
the organization element. This is one format for doing that:
<organization>
<name>Internet Assigned Numbers Authority</name>
<address>
<line>4676 Admiralty Way, Suite
330</line>
<line>Marina del Rey, CA 90292</line>
<line>US</line>
</address>
</organization>
It should be noted that
the elements within the address container may be modified by the
registrar. Thus, the following would also be valid:
<organization>
<name>Internet Assigned Numbers Authority</name>
<address>
<street>4676 Admiralty Way</street>
<room>Suite 330</room>
<city>Marina del Rey</city>
<state>CA</state>
<postalcode>90292</postalcode>
<country>US</country>
</address>
</organization>
o Contact element. There
must at least three contact elements within the domain container.
Each contact element has a type attribute; within each domain container
there must be at least one contact element of type "admin",
one of type "tech", and one of type "billing."
There may be more than one of each of these types.
Contact elements must
give name, address, e-mail, voice, and fax information as well as
dates of creation and last modification. They optionally can also
give title information. This can be done inline (i.e. within the
domain element) as follows:
<contact type="admin">
<name>Karrenberg, Daniel</name>
<address>
<line>RIPE NCC</line>
<line>Singel 258</line>
<line>Amsterdam</line>
<line>NH</line>
<line>1016 AB</line5>
<line>NL</line6>
</address>
<e-mail>dfk@ripe.net</e-mail>
<voice>+31-20-535-4444</voice>
<fax>+31-20-535-4445</fax>
<created>15-Aug-1993</created>
<modified>16-Aug-1994</modified>
</contact>
(Note that the remarks
above about flexible format within address elements apply here
as well.)
Alternatively, the contact
element within the domain container can simply give a reference
to the handle of a contact element contained directly under the
escrow container. Under this approach, the following contact element
might appear within the domain element:
<contact type="admin"
handle="DK58" />
The following contact
element would then appear directly within the escrow container:
<contact type="admin"
handle="DK58">
<name>Karrenberg, Daniel</name>
<address>
<line>RIPE NCC</line>
<line>Singel 258</line>
<line>Amsterdam</line>
<line>NH</line>
<line>1016 AB</line5>
<line>NL</line6>
</address>
<e-mail>dfk@ripe.net</e-mail>
<voice>+31-20-535-4444</voice>
<fax>+31-20-535-4445</fax>
<created>15-Aug-1993</created>
<modified>16-Aug-1994</modified>
</contact>
o Language element. The
language element is included to support multilingual domain names
within the registry. It has a single attribute, named "tag".
This element is optional and may be omitted.
o Extensions element.
The extensions element is a container in which remarks inserted
by the registrar, in UTF-8 format, may be included. It is the only
portion of the escrowed data that need not be in 7-bit ASCII, non-control
characters. (However, the five characters listed above must still
be escaped.) It may be used, for example, to escrow the non-ASCII
equivalents of domain names, organization names, addresses, etc.
As these features evolve, this element will be better defined. Until
then, registrars may optionally use it at their discretion.
Document Type Definition.
(Authored by Rick Wesson of Alice's Registry.)
<!ELEMENT escrow (domain|contact|ns)*>
<!ATTLIST escrow
version CDATA #FIXED "1.0"
registrar CDATA #REQUIRED
date CDATA #REQUIRED >
<!ELEMENT ns ((ip)*,
contact?)?>
<!-- ns Name Server
this container must be either be primary or secondary
-->
<!ATTLIST ns
id ID #IMPLIED
ref IDREF #IMPLIED
handle CDATA #IMPLIED
name CDATA #IMPLIED
created CDATA #IMPLIED
modified CDATA #IMPLIED>
<!ELEMENT ip (#PCDATA)
>
<!ELEMENT created
(#PCDATA) >
<!ATTLIST created date CDATA #REQUIRED >
<!ELEMENT expires
(#PCDATA) >
<!ATTLIST expires date CDATA #REQUIRED >
<!ELEMENT modified
(#PCDATA) >
<!ATTLIST modified date CDATA #REQUIRED >
<!-- the line syntax is an alternate method of specifying an
unformatted address listing. -->
<!ELEMENT line (#PCDATA) >
<!ELEMENT address
(line*| (street*,(city,(state)?)?, postalcode,country))?>
<!ELEMENT contact (name,title?,organization?,address?,voice?,fax?,e-mail?)?>
<!ATTLIST contact
id ID #IMPLIED
ref IDREF #IMPLIED
handle CDATA #IMPLIED
type (admin | tech | billing
| zone ) #IMPLIED>
<!ELEMENT name (#PCDATA)
>
<!ELEMENT title (#PCDATA) >
<!ELEMENT organization (name,address) >
<!ELEMENT street (#PCDATA) >
<!ELEMENT city (#PCDATA) >
<!ELEMENT state (#PCDATA) >
<!ELEMENT postalcode (#PCDATA) >
<!ELEMENT country (#PCDATA) >
<!ELEMENT voice (#PCDATA) >
<!ELEMENT fax (#PCDATA) >
<!ELEMENT created (#PCDATA) >
<!ELEMENT modified (#PCDATA) >
<!ELEMENT e-mail (#PCDATA) >
<!ELEMENT extensions (#PCDATA) >
<!ELEMENT lang (#PCDATA) >
<!ELEMENT domain ((organization?)?,
(ns*)?, contact*, created?, expires?, modified?, extentions?)>
<!ATTLIST domain
fqdn CDATA #REQUIRED
lang CDATA #IMPLIED "ascii">
Example of XML Format
Escrow File (flatfile XML format)
<?xml version="1.0"
encoding='UTF-8' ?>
<!DOCTYPE escrow SYSTEM "whois-export.dtd" >
<escrow version="1.0" registrar="51" date="26-Aug-2000
3:15:00AM">
<domain
fqdn="example.com">
<organization>
<name>Internet Assigned
Numbers Authority</name>
<address>
<line>4676
Admiralty Way, Suite 330</line>
<line>Marina
del Rey, CA 90292</line>
<line>US</line>
</address>
</organization>
<ns
name="venera.isi.edu">
<ip>128.9.176.32</ip>
<created>3-Feb-1994</created>
<modified>4-Feb-1995</modified>
</ns>
<ns name="ns.isi.edu">
<ip>128.9.128.127</ip>
<created>13-Feb-1994</created>
<modified>14-Feb-1995</modified>
</ns>
<contact
type="admin">
<name>Internet Assigned Numbers Authority</name>
<address>
<line>IANA</line>
<line>4676 Admiralty Way,
Suite 330</line>
<line>Marina del Rey,
CA 90292</line>
<line>US</line>
</address>
<voice>+1-310-823-9358</voice>
<fax>+1-310-823-8649</fax>
<email>iana@iana.org</email>
<created>15-Aug-1995</created>
<modified>16-Aug-1996</modified>
</contact>
<contact
type="tech">
<name>Internet Assigned Numbers Authority</name>
<address>
<line>IANA</line>
<line>4676 Admiralty Way,
Suite 330</line>
<line>Marina del Rey,
CA 90292</line>
<line>US</line>
</address>
<voice>+1-310-823-9358</voice>
<fax>+1-310-823-8649</fax>
<email>iana@iana.org</email>
<created>15-Aug-1995</created>
<modified>16-Aug-1996</modified>
</contact>
<contact
type="billing">
<name>Internet Assigned Numbers Authority</name>
<address>
<line>IANA</line>
<line>4676 Admiralty Way,
Suite 330</line>
<line>Marina del Rey,
CA 90292</line>
<line>US</line>
</address>
<voice>+1-310-823-9358</voice>
<fax>+1-310-823-8649</fax>
<email>iana@iana.org</email>
<created>15-Aug-1995</created>
<modified>16-Aug-1996</modified>
</contact>
<created
date="14-Aug-1995" />
<expires date="15-Aug-2010" />
<modified date="16-Sep-2000" />
</domain>
<domain fqdn="root-servers.net">
<organization>
<name>NSI Registry</name>
<address>
<line>505
Huntmar Park Drive</line>
<line>Herndon,
VA 20170</line>
<line>US</line>
</address>
</organization>
<ns
name="a.root-servers.net">
<ip>198.41.0.4</ip>
<created>3-Mar-1994</created>
<modified>4-Mar-1995</modified>
</ns>
<ns name="f.root-servers.net">
<ip>192.5.5.241</ip>
<created>13-Mar-1994</created>
<modified>14-Mar-1995</modified>
</ns>
<ns name="j.root-servers.net">
<ip>198.41.0.10</ip>
<created>23-Mar-1994</created>
<modified>24-Mar-1995</modified>
</ns>
<ns name="k.root-servers.net">
<ip>193.0.14.129</ip>
<created>29-Mar-1994</created>
<modified>30-Mar-1995</modified>
</ns>
<contact
type="admin">
<name>Internet Assigned
Numbers Authority</name>
<address>
<line>IANA</line>
<line>4676
Admiralty Way, Suite 330</line>
<line>Marina
del Rey, CA 90292</line>
<line>US</line>
</address>
<voice>+1-310-823-9358</voice>
<fax>+1-310-823-8649</fax>
<email>iana@iana.org</email>
<created>15-Aug-1995</created>
<modified>16-Aug-1996</modified>
</contact>
<contact
type="tech">
<name>NSI Registry</name>
<address>
<line>Network
Solutions, Inc.</line>
<line>505
Huntmar Park Drive</line>
<line>Herndon,
VA 20170</line>
<line>US</line>
</address>
<voice>+1-703-742-0400</voice>
<fax>+1-703-742-5427</fax>
<email>hostmaster@nsiregistry.net</email>
<created>15-Aug-1993</created>
<modified>16-Aug-1994</modified>
</contact>
<contact
type="billing">
<name>idNames, Accounting</name>
<address>
<line>idNames
from Network Solutions, Inc.</line>
<line>440
Benmar</line>
<line>Suite
#3325</line>
<line>Houston,
TX 77060</line>
<line>US</line>
</address>
<voice>+1-703-742-4777</voice>
<fax>+1-281-447-1160</fax>
<email>accounting@idnames.com</email>
<created>15-Aug-1993</created>
<modified>16-Aug-1994</modified>
</contact>
<created
date="04-Jul-1995" />
<expires date="05-Jul-2005"
/>
<modified date="16-Sep-2000"
/>
</domain>
</escrow>
Example of XML Format
Escrow File (relational XML format)
<?xml version="1.0"
encoding="UTF-8"?>
<!DOCTYPE escrow SYSTEM "whois-export.dtd" >
<escrow version="1.0" registrar="51" date="26-Aug-2000
3:15:00AM" >
<contact handle="IANA" >
<name>Internet Assigned
Numbers Authority</name>
<address>
<line>IANA</line>
<line>4676
Admiralty Way, Suite 330</line>
<line>Marina
del Rey, CA 90292</line>
<line>US</line>
</address>
<voice>+1-310-823-9358</voice>
<fax>+1-310-823-8649</fax>
<email>iana@iana.org</email>
<created>15-Aug-1995</created>
<modified>16-Aug-1996</modified>
</contact>
<contact
handle="NSIRegistry">
<name>NSI Registry</name>
<address>
<line>Network
Solutions, Inc.</line>
<line>505
Huntmar Park Drive</line>
<line>Herndon,
VA 20170</line>
<line>US</line>
</address>
<voice>+1-703-742-0400</voice>
<fax>+1-703-742-5427</fax>
<email>hostmaster@nsiregistry.net</email>
<created>15-Aug-1993</created>
<modified>16-Aug-1994</modified>
</contact>
<contact
handle="IDNames">
<name>idNames, Accounting</name>
<address>
<line>idNames
from Network Solutions, Inc.</line>
<line>440
Benmar</line>
<line>Suite
#3325</line>
<line>Houston,
TX 77060</line>
<line>US</line>
</address>
<voice>+1-703-742-4777</voice>
<fax>+1-281-447-1160</fax>
<email>accounting@idnames.com</email>
<created>15-Aug-1993</created>
<modified>16-Aug-1994</modified>
</contact>
<ns name="venera.isi.edu">
<ip>128.9.176.32</ip>
<created>3-Feb-1994</created>
<modified>4-Feb-1995</modified>
</ns>
<ns name="ns.isi.edu">
<ip>128.9.128.127</ip>
<created>13-Feb-1994</created>
<modified>14-Feb-1995</modified>
</ns>
<ns name="a.root-servers.net">
<ip>198.41.0.4</ip>
<created>3-Mar-1994</created>
<modified>4-Mar-1995</modified>
</ns>
<ns name="f.root-servers.net">
<ip>192.5.5.241</ip>
<created>13-Mar-1994</created>
<modified>14-Mar-1995</modified>
</ns>
<ns name="j.root-servers.net">
<ip>198.41.0.10</ip>
<created>23-Mar-1994</created>
<modified>24-Mar-1995</modified>
</ns>
<ns name="k.root-servers.net">
<ip>193.0.14.129</ip>
<created>29-Mar-1994</created>
<modified>30-Mar-1995</modified>
</ns>
<domain fqdn="example.com">
<organization>
<name>Internet Assigned
Numbers Authority</name>
<address>
<line>4676
Admiralty Way, Suite 330</line>
<line>Marina
del Rey, CA 90292</line>
<line>US</line>
</address>
</organization>
<ns
handle="venera.isi.edu" />
<ns handle="ns.isi.edu" />
<contact
handle="IANA" type="billing" />
<contact handle="IANA" type="tech"
/>
<contact handle="IANA" type="admin"
/>
<created
date="14-Aug-1995" />
<expires date="15-Aug-2010" />
<modified date="16-Sep-2000" />
</domain>
<domain fqdn="root-servers.net">
<organization>
<name>NSI Registry</name>
<address>
<line>505
Huntmar Park Drive</line>
<line>Herndon,
VA 20170</line>
<line>US</line>
</address>
</organization>
<ns handle="a.root-servers.net" />
<ns handle="f.root-servers.net" />
<ns handle="j.root-servers.net" />
<ns handle="k.root-servers.net" />
<contact
handle="IANA" type="admin" />
<contact handle="NSIRegistry" type="tech"
/>
<contact handle="IDNames" type="billing"
/>
<created
date="04-Jul-1995" />
<expires date="05-Jul-2005" />
<modified date="16-Sep-2000" />
</domain>
</escrow>
TEXT-DELIMITED
FORMAT
The escrow file may be
formatted in delimited text as specified below. This format offers
easier implementation for some back-end registrar implementations.
In contrast, the XML format offers all the features of the text-delimited
format as well additional flexibility to represent data in a related-object
model. The required escrow information is the same for XML as for
text-delimited, but in many cases it can be represented in a shorter
file in XML format.
Except within the ExtensibilityFields
(see below), all text within the text-delimited format must be 7-bit
ASCII. The text-delimited format uses the right angle-bracket ("<")
as a field separator, while a standard carriage return terminates
each record.
Header
A file in text delimited
format begins with a header giving basic information about the
information to follow. The first line of the header gives the
registrar code (to be uniquely assigned in coordination with
Network Solutions Registry and the IANA (http://www.iana.org/numbers.htm).
The second line notes the date and time of escrow (specified
in UTC). The third line states the version of the escrow format
(currently 1.0 and subject to change by ICANN from time to time).
The fourth line consists of the field list, a list of field
names (selected from the list below, not case sensitive) separated
by the field delimiter ("<").
The presence of each
field in the data section must be declared via a corresponding
entry in the header, but if a field is empty in all records
in the data section, the field may be omitted both from the
header and from all records in the data section. This allows
registrars to omit fields not used by any of their customers.
Each of the four
lines of the header is followed by a carriage return.
Data Section
For each record in
the escrow file, the data section contains a series of field
data elements, separated by the field delimiter ("<"),
followed by a carriage return. Fields must follow the order
of fields specified in the field list (header line four).
For each domain in
the escrow, the following data must be included: SLDName, CreationDate,
ExpirationDate, ModifiedDate, SLDHName, SLDHStreet, SLDHCity,
SLDHState, SLDHPostalCode, SLDHCountry, TechName, TechStreet,
TechCity, TechState, TechPostalCode, TechCountry, TechEmail,
TechVoiceTel, TechFax, TechCreated, TechModified, AdminName,
AdminStreet, AdminCity, AdminState, AdminPostalCode, AdminCountry,
AdminEmail, AdminVoiceTel, AdminFax, AdminCreated, AdminModified,
BillingName, BillingStreet, BillingCity, BillingState, BillingPostalCode,
BillingCountry, BillingEmail, BillingVoiceTel, BillingFax, AdminCreated,
AdminModified.
For each domain in
the escrow, the following data may optionally be included (but
must be included if present in the domain registration as stored
in a registrar's internal databases): NS1, IPAddress1-1,...,
IPAddress1-13, ... NS13, IPAddress13-1, ...IPAddress13-13, NS1Created,
..NS13Created,
NS1Modified,
NS13Modified. NS1 gives
the fully-qualified domain name of the domain's first (primary)
name server, while NS2 through NS13 give names of secondary
name servers. IPAddress1-1 gives the first IP address of the
first name server, while additional addresses of the same server
can be given in IPAddress1-2 through IPAddress1-13 if needed.
IP addresses for other name servers are given in similar format.
Dates of creation and most recent modification of the corresponding
name servers follow.
Registrars may choose
to use an alternative address format via fields of name [addresstype]Address1
through [addresstype]Address6, where [addresstype] is replaced
with SLDH, Tech, Admin, or Billing as needed for the four addresses.
If these fields are used, they replace the Street, City, State,
PostalCode, and Country fields described above. As for other
fields, registrars may omit unneeded fields to the extent possible
(i.e. use only Address1 through Address4 if all addresses have
four or fewer lines).
Registrars may optionally
escrow non-ASCII data in a field called ExtensibilityFields
(but in no other field). In addition, registrars participating
in the NSI Registry multilingual program may use the optional
LanguageTag field to escrow the language of a domain name registration.
Registrars may optionally
add additional fields to enable the escrow of additional data
as needed. Such fields of the registrar's own creation must
be declared in the header with names beginning OPT.
If a field is empty
in all records in the data section, the field may be omitted
both from the header and from all records in the data section.
Example of Text-Delimited Format Escrow File
Here is an example
escrow file in text-delimited format for the domain example.com
(Note: this example has been modified for display in a web browser
--the spaces before and after the brackets would not be included
in the actual data files.)
51
26-Aug-2000 3:15:00AM
1.0
SLDName < CreationDate < ExpirationDate < ModifiedDate
< SLDHName < SLDHStreet < SLDHCity < SLDHState <
SLDHPostalCode < SLDHCountry < TechName < TechStreet
< TechCity < TechState < TechPostalCode < TechCountry
< TechEmail < TechVoiceTel < TechFax < TechCreated
< TechModified < AdminName < AdminStreet < AdminCity
< AdminState < AdminPostalCode < AdminCountry <
AdminEmail < AdminVoiceTel < AdminFax < AdminCreated
< AdminModifiedBillingName < BillingStreet < BillingCity
< BillingState < BillingPostalCode < BillingCountry
< BillingEmail < BillingVoiceTel < BillingFax <
BillingCreated < BillingModified < NS1 < IPAddress1-1
< NS2 < IPaddress2-1 < NS1Created < NS2Created <
NS1Modified < NS2Modified
Example.com < 14-Aug-1995 < 15-Aug-2010 < 16-Sep-2000
< Internet Assigned Numbers Authority < 4676 Admiralty
Way < Suite 330 < Marina del Rey < CA < 90292 <
US < Internet Assigned Numbers Authority < 4676 Admiralty
Way < Suite 330 < Marina del Rey < CA < 90292 <
US < iana@iana.org < +1-310-823-9358 < +1-310-823-8649
< 10-Aug-1993 < 11-Aug-1994 < Internet Assigned Numbers
Authority < 4676 Admiralty Way < Suite 330 < Marina
del Rey < CA < 90292 < US < iana@iana.org < +1-310-823-9358
< +1-310-823-8649 < 10-Aug-1993 < 11-Aug-1994 <
Internet Assigned Numbers Authority < 4676 Admiralty Way
< Suite 330 < Marina del Rey < CA < 90292 < US
< iana@iana.org < +1-310-823-9358 < +1-310-823-8649
< 10-Aug-1993 < 11-Aug-1994 < venera.isi.edu < 128.9.176.32
< ns.isi.edu < 128.9.128.127 < 3-Mar-1994 < 4-Mar-1994
< 4-Apr-1995 < 5-Apr-1995
EXHIBIT
C
ICANN DATA
ESCROW PROGRAM LOGO
Comments
concerning the layout, construction and functionality of this site
should be sent to webmaster@icann.org.
Page Updated
08-Nov-2001
(c) 2001
The Internet Corporation for Assigned Names and Numbers.
All rights
reserved.
|