BIZ Registry Agreement (8 December 2006)
Exhibit
10.6
|
.BIZ Registry Agreement (8 December 2006) |
This REGISTRY AGREEMENT (this “Agreement”) is entered into as of 18 December 2006 by and between
Internet Corporation for Assigned Names and Numbers, a California nonprofit public benefit
corporation (“ICANN”), and NeuStar, Inc. a Delaware corporation.
ARTICLE 1 INTRODUCTION
Section 1.1 Effective Date. The Effective Date for purposes of this Agreement shall be 8 December
2006.
Section 1.2 Top-Level Domain. The Top-Level Domain to which this Agreement applies is .biz (“TLD”).
Section 1.3 Designation as Registry Operator. Upon the Effective Date, until the Expiration Date as
defined in Section 4.1 hereof, ICANN shall continue to designate NeuStar, Inc. as the sole registry
operator for the TLD (“Registry Operator”).
ARTICLE 2 REPRESENTATIONS AND WARRANTIES
Section 2.1 Registry Operator’s Representations and Warranties.
2.1 (a) Organization; Due Authorization and Execution. Registry Operator is a corporation,
duly organized, validly existing and in good standing under the laws of Delaware, and
Registry Operator has all requisite power and authority to enter into this Agreement. All
corporate approvals and actions necessary for the entrance by Registry Operator into this
Agreement have been obtained and this Agreement has been duly and validly executed and
delivered by Registry Operator.
2.1 (b) Statements made During Negotiation Process. The factual statements made in writing by
both Parties in negotiating this Agreement, were true and correct in all material respects at
the time . A violation or breach of this subsection shall not be a basis for termination,
rescission or other equitable relief, and, instead shall only give rise to a claim for
damages.
Section 2.2 ICANN’s Representations and Warranties.
2.2 (a) Organization; Due Authorization and Execution. ICANN is a nonprofit public benefit
corporation duly organized, validly existing and in good standing under the laws of
California. ICANN has all requisite corporate power and authority to enter
into this Agreement. All corporate approvals and actions necessary for the entrance by ICANN
into this Agreement have been obtained and this Agreement has been duly and validly executed
and delivered by ICANN.
ARTICLE 3 COVENANTS
Section 3.1 Covenants of Registry Operator. Registry Operator covenants and agrees with ICANN as
follows:
3.1 (a) Preserve Security and Stability.
3.1 (a)(i) ICANN Temporary Specifications or Policies. Registry Operator shall comply
with and implement all specifications or policies established by the ICANN Board of
Directors on a temporary basis, if adopted by the ICANN Board of Directors by a vote
of at least two-thirds of its members, so long as the ICANN Board of Directors
reasonably determines that immediate temporary establishment of a specification or
policy on the subject is necessary to maintain the Stability or Security (as defined
in Section 3.1(d)(iv)(G)) of Registry Services or the DNS (“Temporary Specification or
Policies”). Such proposed specification or policy shall be as narrowly tailored as
feasible to achieve those objectives. In establishing any specification or policy
under this provision, the ICANN Board of Directors shall state the period of time for
which the specification or policy is temporarily adopted and shall immediately
implement the Consensus Policy development process set forth in ICANN’s Bylaws. ICANN
shall also issue an advisory statement containing a detailed explanation of its
reasons for adopting the temporary specification or policy and why the Board believes
the specification or policy should receive the consensus support of Internet
stakeholders. If the period of time for which the specification or policy is adopted
exceeds 90 days, the ICANN Board shall reaffirm its temporary adoption every 90 days
for a total period not to exceed one year, in order to maintain such policy in effect
until such time as it shall become a Consensus Policy as described in Section 3.1(b)
below. If during such one year period, the temporary policy or specification does not
become a Consensus Policy meeting the standard set forth in Section 3.1(b) below,
Registry Operator shall no longer be required to comply with or implement such
temporary policy or specification.
3.1 (b) Consensus Policies.
3.1 (b)(i) At all times during the term of this Agreement and subject to the terms
hereof, Registry Operator will fully comply with and implement all Consensus Policies
found at ▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇.▇▇▇, as of the Effective Date
and as may in the future be developed and adopted in accordance with ICANN’s Bylaws
and as set forth below.
3.1 (b)(ii) “Consensus Policies” are those specifications or policies established (1)
pursuant to the procedure set forth in ICANN’s Bylaws and due process, and (2)
covering those topics listed in Section 3.1(b)(iv) below. The Consensus Policy
development process and procedure set forth in ICANN’s Bylaws may be revised from time
to time in accordance
with ICANN’s Bylaws, and any Consensus Policy that is adopted through such a revised process
and covering those topics listed in Section 3.1(b) (iv) below shall be considered a Consensus
Policy for purposes of this Agreement.
3.1 (b)(iii) For all purposes under this Agreement, the policies identified at
▇▇▇▇://▇▇▇.▇▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇▇.▇▇▇ shall be treated in the same manner and have
the same effect as “Consensus Policies.”
3.1 (b)(iv) Consensus Policies and the procedures by which they are developed shall be designed to
produce, to the extent possible, a consensus of Internet stakeholders, including the operators of
gTLDs. Consensus Policies shall relate to one or more of the following: (1) issues for which
uniform or coordinated resolution is reasonably necessary to facilitate interoperability, Security
and/or Stability of the Internet or DNS; (2) functional and performance specifications for the
provision of Registry Services (as defined in Section 3.1(d)(iii) below); (3) Security and
Stability of the registry database for the TLD; (4) registry policies reasonably necessary to
implement Consensus Policies relating to registry operations or registrars; or (5) resolution of
disputes regarding the registration of domain names (as opposed to the use of such domain names).
Such categories of issues referred to in the preceding sentence shall include, without limitation:
3.1 (b)(iv)(A) principles for allocation of registered names in the TLD (e.g., first-come,
first-served, timely renewal, holding period after expiration);
3.1 (b)(iv)(B) prohibitions on warehousing of or speculation in domain names by registries or
registrars;
3.1 (b)(iv)(C) reservation of registered names in the TLD that may not be registered
initially or that may not be renewed due to reasons reasonably related to (a) avoidance of
confusion among or misleading of users, (b) intellectual property, or (c) the technical
management of the DNS or the Internet (e.g., establishment of reservations of names from
registration);
3.1 (b)(iv)(D) maintenance of and access to accurate and up-to-date information concerning
domain name registrations;
3.1 (b)(iv)(E) procedures to avoid disruptions of domain name registration due to suspension
or termination of operations by a registry operator or a registrar, including procedures for
allocation of responsibility for serving registered domain names in a TLD affected by such a
suspension or termination; and
3.1 (b)(iv)(F) resolution of disputes regarding whether particular parties may register or
maintain registration of particular domain names.
3.1 (b)(v) In addition to the other limitations on Consensus Policies,
they shall not:
3.1 (b)(v)(A) prescribe or limit the price of Registry Services;
3.1 (b)(v)(B) modify the standards for the consideration of proposed
Registry Services, including the definitions of Security and Stability
(set forth below) and the standards applied by ICANN;
3.1 (b)(v)(C) for two years following the Effective Date, modify
the procedure for the consideration of proposed Registry Services;
3.1 (b)(v)(D) modify the terms or conditions for the renewal or
termination of this Agreement;
3.1 (b)(v)(E) modify ICANN’s obligations to Registry Operator under
Section 3.2 (a), (b), and (c);
3.1 (b)(v)(F) modify the limitations on Temporary
Specifications or Consensus Policies;
3.1 (b)(v)(G) modify the definition of Registry Services;
3.1 (b)(v)(H) modify the terms of Sections 7.2 below; or
3.1 (b)(v)(I) alter services that have been implemented pursuant to
Section 3.1(d) of this Agreement (unless justified by compelling and
just cause based on Security and Stability.
3.1 (b)(vi) Registry Operator shall be afforded a reasonable period of time
following notice of the establishment of a Consensus Policy or Temporary
Specifications or Policies in which to comply with such policy or
specification, taking into account any urgency involved. In the event of a
conflict between Registry Services (as defined in Section 3.1(d)(iii) below),
on the one hand, and Consensus Policies developed in accordance with this
Section 3.1(b) or any Temporary Specifications or Policies established
pursuant to Section 3.1(a)(i) above, on the other hand, the Consensus Polices
or Temporary Specifications or Policies shall control, notwithstanding any
other provisions contained within this Agreement.
3.1 (c) Handling of Registry Data.
3.1 (c)(i) Data Escrow. Registry Operator shall establish at its expense a
data escrow or mirror site policy for the Registry Data compiled by Registry
Operator. Registry Data, as used in this Agreement, shall mean the following:
(1) data for domains sponsored by all registrars, consisting of domain name,
server name for each nameserver, registrar id, updated date, creation date,
expiration date, status information, and DNSSEC related key material (if
Registry Operator implements DNSSEC); (2) data
for nameservers sponsored by all registrars consisting of server name,
each IP address, registrar id, updated date, creation date, expiration date,
and status information; (3) data for registrars sponsoring registered domains
and nameservers, consisting of registrar id, registrar address, registrar
telephone number, registrar e-mail address, whois server, referral URL,
updated date and the name, telephone number, and e-mail address of all the
registrar’s administrative, billing, and technical contacts; (4) domain name
registrant data collected by the Registry Operator from registrars as part of
or following registration of a domain name; and (5) the DNSSEC-related
material necessary to sign the .biz zone (e.g., public and private
portions of .biz zone key-signing keys and zone-signing keys)(if Registry Operator
implements DNSSEC). The escrow agent or mirror-site manager, and the
obligations thereof, shall be mutually agreed upon by ICANN and Registry
Operator on commercially reasonable standards that are technically and
practically sufficient to allow a successor registry operator to assume
management of the TLD. To this end, Registry Operator shall periodically
deposit into escrow all Registry Data on a schedule (not more frequently than
weekly for a complete set of Registry Data, and daily for incremental updates)
and in an electronic format mutually approved from time to time by Registry
Operator and ICANN, such approval not to be unreasonably withheld by either
party. In addition, Registry Operator will deposit into escrow that data
collected from registrars as part of offering Registry Services introduced
after the Effective Date of this Agreement. The schedule, content, format, and
procedure for escrow deposits shall be as reasonably established by ICANN from
time to time, and as set forth in Appendix 1 hereto. Changes to the schedule,
content, format, and procedure may be made only with the mutual written
consent of ICANN and Registry Operator (which neither party shall unreasonably
withhold) or through the establishment of a Consensus Policy as outlined in
Section 3.1(b) above. The escrow shall be held under an agreement,
substantially in the form of Appendix 2, as the same may be revised from time
to time, among ICANN, Registry Operator, and the escrow agent.
3.1 (c)(ii) Personal Data. Registry Operator shall notify registrars
sponsoring registrations in the registry for the TLD of the purposes for which
Personal Data (as defined below) submitted to Registry Operator by registrars,
if any, is collected, the intended recipients (or categories of recipients) of
such Personal Data, and the mechanism for access to and correction of such
Personal Data. Registry Operator shall take reasonable steps to protect
Personal Data from loss, misuse, unauthorized disclosure, alteration or
destruction. Registry Operator shall not use or authorize the use of Personal
Data in a way that is incompatible with the notice provided to registrars.
“Personal Data” shall refer to all data about any identified or identifiable
natural person.
3.1 (c)(iii) Bulk Zone File Access. Registry Operator shall provide bulk
access to the zone files for the registry for the TLD to ICANN on a continuous
basis in the manner ICANN may reasonably specify from time to time. Bulk
access to the zone files shall be provided to third parties on the terms set
forth in the TLD zone file access agreement reasonably established by ICANN,
which initially shall be in the form attached as Appendix 3 hereto. Changes to
the zone file access agreement may be
made upon the mutual written consent of ICANN and Registry Operator
(which consent neither party shall unreasonably withhold).
3.1 (c)(iv) Monthly Reporting. Within 20 days following the end of each
calendar month, Registry Operator shall prepare and deliver to ICANN a report
providing such data and in the format specified in Appendix 4. ICANN may audit
Registry Operator’s books and records relating to data contained in monthly
reports from time to time upon reasonable advance written notice, provided
that such audits shall not exceed one per quarter. Any such audit shall be at
ICANN’s cost, unless such audit shall reflect a material discrepancy or
discrepancies in the data provided by Registry Operator. In the latter event,
Registry Operator shall reimburse ICANN for all reasonable costs and expenses
associated with such audit, which reimbursement shall be paid together with
the next Registry-Level Fee payment due following the date of transmittal of
the cost statement for such audit.
3.1 (c)(v) Whois Service. Registry Operator shall provide such whois data as
set forth in Appendix 5.
3.1 (d) Registry Operations.
3.1 (d)(i) Registration Restrictions.
3.1 (d)(i)(A) Registry Operator shall reserve, and not register any TLD
strings (i) appearing on the list of reserved TLD strings attached as
Appendix 6 hereto or (ii) located at
▇▇▇▇://▇▇▇▇.▇▇▇▇.▇▇▇/▇▇▇/▇▇▇▇-▇▇▇▇▇-▇▇-▇▇▇▇▇▇.▇▇▇ for initial (i.e.,
other than renewal) registration at the second level within the TLD.
3.1(d)(i)(B) Registry Operator shall apply, monitor, and enforce the
restrictions on registration in the Registry TLD. Appendix 11 sets
forth the restrictions to be applied and sets forth the manner by which
these restrictions shall be applied, monitored, and enforced. Changes
to the restrictions may be made only with the mutual written consent of
ICANN and Registry Operator (which neither party shall unreasonably
withhold).
3.1 (d)(ii) Functional and Performance Specifications. Functional and
Performance Specifications for operation of the TLD shall be as set forth in
Appendix 7 hereto, and shall address without limitation DNS services;
operation of the shared registration system; and nameserver operations.
Registry Operator shall keep technical and operational records sufficient to
evidence compliance with such specifications for at least one year, which
records ICANN may audit from time to time upon reasonable advance written
notice, provided that such audits shall not exceed one per quarter. Any such
audit shall be at ICANN’s cost.
3.1 (d)(iii) Registry Services. Registry Services are, for purposes of this
Agreement, defined as the following: (a) those services that are both (i)
operations of the registry critical to the following tasks: the receipt of data from
registrars concerning registrations of domain names and name servers; provision to registrars of
status information relating to the zone servers for the TLD; dissemination of TLD zone files;
operation of the registry zone servers; and dissemination of contact and other information
concerning domain name server registrations in the TLD as required by this Agreement; and (ii)
provided by the Registry Operator for the .biz registry as of the Effective Date as set forth on
Appendix 9; (b) other products or services that the Registry Operator is required to provide
because of the establishment of a Consensus Policy (as defined in Section 3.1(b) above); (c) any
other products or services that only a registry operator is capable of providing, by reason of its
designation as the registry operator; and (d) material changes to any Registry Service within the
scope of (a), (b) or (c) above.
3.1 (d)(iv) Process for Consideration of Proposed Registry Services. Following
written notification by Registry Operator to ICANN that Registry Operator may
make a change in a Registry Service within the scope of the preceding
paragraph:
3.1 (d)(iv)(A) ICANN shall have 15 calendar days to make a “preliminary
determination” whether a Registry Service requires further
consideration by ICANN because it reasonably determines such Registry
Service: (i) could raise significant Security or Stability issues or
(ii) could raise significant competition issues.
3.1 (d)(iv)(B) Registry Operator must provide sufficient information at
the time of notification to ICANN that it may implement such a proposed
Registry Service to enable ICANN to make an informed “preliminary
determination.” Information provided by Registry Operator and marked
“CONFIDENTIAL” shall be treated as confidential by ICANN. Registry
Operator will not designate “CONFIDENTIAL” information necessary to
describe the purpose of the proposed Registry Service and the effect on
users of the DNS.
3.1 (d)(iv)(C) ICANN may seek expert advice during the preliminary
determination period (from entities or persons subject to
confidentiality agreements) on the competition, Security or Stability
implications of the Registry Service in order to make its “preliminary
determination.” To the extent ICANN determines to disclose confidential
information to any such experts, it will provide notice to Registry
Operator of the identity of the expert(s) and the information it
intends to convey.
3.1 (d)(iv)(D) If ICANN determines during the 15 calendar day
“preliminary determination” period that the proposed Registry Service,
does not raise significant Security or Stability (as defined below), or
competition issues, Registry Operator shall be free to deploy it upon
such a determination.
3.1 (d)(iv)(E) In the event ICANN reasonably determines during the 15 calendar day
“preliminary determination” period that the Registry Service might raise significant competition
issues, ICANN shall refer the issue to the appropriate governmental competition authority or
authorities with jurisdiction over the matter within five business days of making its
determination, or two business days following the expiration of such 15 day period, whichever is
earlier, with notice to Registry Operator. Any such referral communication shall be posted on
ICANN’s website on the date of transmittal. Following such referral, ICANN shall have no further
responsibility, and Registry Operator shall have no further obligation to ICANN, with respect to
any competition issues relating to the Registry Service. If such a referral occurs, the Registry
Operator will not deploy the Registry Service until 45 calendar days following the referral, unless
earlier cleared by the referred governmental competition authority.
3.1 (d)(iv)(F) In the event that ICANN reasonably determines during the 15 calendar day
“preliminary determination” period that the proposed Registry Service might raise significant
Stability or Security issues (as defined below), ICANN will refer the proposal to a Standing Panel
of experts (as defined below) within five business days of making its determination, or two
business days following the expiration of such 15 day period, whichever is earlier, and
simultaneously invite public comment on the proposal. The Standing Panel shall have 45 calendar
days from the referral to prepare a written report regarding the proposed Registry Service’s effect
on Security or Stability (as defined below), which report (along with a summary of any public
comments) shall be forwarded to the ICANN Board. The report shall set forward the opinions of the
Standing Panel, including, but not limited to, a detailed statement of the analysis, reasons, and
information upon which the panel has relied in reaching their conclusions, along with the response
to any specific questions that were included in the referral from ICANN staff. Upon ICANN’s
referral to the Standing Panel, Registry Operator may submit additional information or analyses
regarding the likely effect on Security or Stability of the Registry Service.
3.1 (d)(iv)(G) Upon its evaluation of the proposed Registry Service, the Standing Panel will report
on the likelihood and materiality of the proposed Registry Service’s effects on Security or
Stability, including whether the proposed Registry Service creates a reasonable risk of a
meaningful adverse effect on Security or Stability as defined below:
Security: For purposes of this Agreement, an effect on security by the proposed Registry
Service shall mean (1) the unauthorized disclosure, alteration, insertion or destruction of
Registry Data, or (2) the unauthorized access to or
disclosure of information or resources on the Internet by systems operating in
accordance with all applicable standards.
Stability: For purposes of this Agreement, an effect on stability shall mean that the
proposed Registry Service (1) is not compliant with applicable relevant standards that are
authoritative and published by a well-established, recognized and authoritative standards
body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF or
(2) creates a condition that adversely affects the throughput, response time, consistency or
coherence of responses to Internet servers or end systems, operating in accordance with
applicable relevant standards that are authoritative and published by a well-established,
recognized and authoritative standards body, such as relevant Standards-Track or Best Current
Practice RFCs and relying on Registry Operator’s delegation information or provisioning
services.
3.1 (d)(iv)(H) Following receipt of the Standing Panel’s report, which will be posted (with
appropriate confidentiality redactions made after consultation with Registry Operator) and
available for public comment, the ICANN Board will have 30 calendar days to reach a decision. In
the event the ICANN Board reasonably determines that the proposed Registry Service creates a
reasonable risk of a meaningful adverse effect on Stability or Security, Registry Operator will not
offer the proposed Registry Service. An unredacted version of the Standing Panel’s report shall be
provided to Registry Operator upon the posting of the report. The Registry Operator may respond to
the report of the Standing Panel or otherwise submit to the ICANN Board additional information or
analyses regarding the likely effect on Security or Stability of the Registry Service.
3.1 (d)(iv)(I) The Standing Panel shall consist of a total of 20 persons expert in the design,
management and implementation of the complex systems and standards-protocols utilized in the
Internet infrastructure and DNS (the “Standing Panel”). The members of the Standing Panel will be
selected by its Chair. The Chair of the Standing Panel will be a person who is agreeable to both
ICANN and the registry constituency of the supporting organization then responsible for generic top
level domain registry policies. All members of the Standing Panel and the Chair shall execute an
agreement requiring that they shall consider the issues before the panel neutrally and according to
the definitions of Security and Stability. For each matter referred to the Standing Panel, the
Chair shall select no more than five members from the
Standing Panel to evaluate the referred matter, none of which shall
have an existing competitive, financial, or legal conflict of interest, and
with due regard to the particular technical issues raised by the referral.
3.1 (e) Fees and Payments. Registry Operator shall pay the Registry-Level Fees to ICANN on a
quarterly basis in accordance with Section 7.2 hereof.
3.1 (f) Traffic Data. Nothing in this Agreement shall preclude Registry Operator from making
commercial use of, or collecting, traffic data regarding domain names or non-existent domain
names for purposes such as, without limitation, the determination of the availability and
health of the Internet, pinpointing specific points of failure, characterizing attacks and
misconfigurations, identifying compromised networks and hosts and promoting the sale of
domain names, provided however, that such use does not permit Registry Operator to disclose
domain name registrant or end-user information or other Personal Data as defined in Section
3.1(c)(ii) that it collects through providing domain name registration services for any
purpose not otherwise authorized by this agreement. In this regard, in the event the TLD
registry is a “thick” registry model, the traffic data that may be accessible to and used by
Registry Operator shall be limited to the data that would be accessible to a registry
operated under a “thin” registry model. The process for the introduction of new Registry
Services shall not apply to such traffic data. Nothing contained in this section 3.1(f) shall
be deemed to constitute consent or acquiescence by ICANN to an introduction by Registry
Operator of a service employing a universal wildcard function. To the extent that traffic
data subject to this provision is made available, access shall be on terms that are
nondiscriminatory.
3.1 (g) Cooperation. The parties agree to cooperate with each other and share data as
necessary to accomplish the terms of this Agreement.
Section 3.2 Covenants of ICANN. ICANN covenants and agrees with Registry Operator as follows:
3.2 (a) Open and Transparent. Consistent with ICANN’s expressed mission and core values,
ICANN shall operate in an open and transparent manner.
3.2 (b) Equitable Treatment. ICANN shall not apply standards, policies, procedures or
practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry
Operator for disparate treatment unless justified by substantial and reasonable cause.
3.2 (c) TLD Zone Servers. In the event and to the extent that ICANN is authorized to set
policy with regard to an authoritative root server system, it will use best efforts to ensure
that (i) the authoritative root will point to the TLD zone servers designated by Registry
Operator for the Registry TLD throughout the Term of this Agreement; and (ii) any changes to
the TLD zone server designation submitted to ICANN by Registry Operator will be implemented
by ICANN within seven days of submission.
3.2 (d) Nameserver Changes. Registry Operator may request changes in the nameserver
delegation for the Registry TLD. Any such request must be made in a format, and otherwise
meet technical requirements, specified from time to time by ICANN. ICANN will use
commercially reasonable efforts to have such requests
implemented in the Authoritative Root-Server System within seven calendar days of the
submission.
3.2 (e) Root-zone Information Publication. ICANN’s publication of root-zone contact
information for the Registry TLD will include Registry Operator and its administrative and
technical contacts. Any request to modify the contact information for the Registry Operator
must be made in the format specified from time to time by ICANN.
ARTICLE 4 TERM OF AGREEMENT
Section 4.1 Term. The initial term of this Agreement shall expire on December 31, 2012, the
“Expiration Date,” as extended by any renewal terms.
Section 4.2 Renewal. This Agreement shall be renewed upon the expiration of the term set forth in
Section 4.1 above and each later term, unless the following has occurred: (i) following notice of
breach to Registry Operator in accordance with Section 6.1 and failure to cure such breach within
the time period prescribed in Section 6.1, an arbitrator or court has determined that Registry
Operator has been in fundamental and material breach of Registry Operator’s obligations set forth
in Sections 3.1(a), (b), (d) or (e); Section 5.2 and (ii) following the final decision of such
arbitrator or court, Registry Operator has failed to comply within ten days with the decision of
the arbitrator or court, or within such other time period as may be prescribed by the arbitrator or
court. Upon renewal, in the event that the terms of this Agreement are not similar to the terms
generally in effect in the Registry Agreements of the 5 most reasonably comparable gTLDs (provided
however that if less than five gTLDs are reasonably comparable, then comparison shall be made with
such lesser number, and .com, info, .net and .org are hereby deemed comparable), renewal shall be
upon terms reasonably necessary to render the terms of this Agreement similar to such terms in the
Registry Agreements for those other gTLDs. The preceding sentence, however, shall not apply to the
terms of this Agreement regarding the standards for the consideration of proposed Registry
Services, including the definitions of Security and Stability and the standards applied by ICANN in
the consideration process; the terms or conditions for the renewal or termination of this
Agreement; ICANN’s obligation to Registry Operator under Section 3.2(a), (b) and (c); the
limitations on Consensus Policies or Temporary Specifications or Policies; or the definition of
Registry Services. In addition, upon renewal, registry fees payable to ICANN may be reasonably
modified so long as any increase in such fees shall not exceed the average of the percentage
increase in registry fees for the five most reasonably comparable TLDs (or such lesser number as
provided above) during the prior three year period;
Section 4.3 Changes. While this Agreement is in effect, the parties agree to engage in good faith
negotiations at regular intervals (at least once every three calendar years following the Effective
Date) regarding possible changes to the terms of the Agreement, including to Section 7.2 regarding
fees and payments to ICANN. In addition, ICANN shall consider and discuss with Registry Operator
other appropriate changes to pricing and related terms under the Agreement in the event ICANN shall
obtain further independent data from professional experts providing analysis of the pricing of
domain name registrations and competitive market considerations. The failure by Registry Operator
to agree to an increase in registry fees or other terms shall not constitute a violation of this
provision.
Section 4.4 Failure to Perform in Good Faith. In the event Registry Operator shall have been
repeatedly and willfully in fundamental and material breach of Registry Operator’s obligations set
forth in Sections 3.1(a), (b), (d) or (e); Section 5.2, and arbitrators in accordance with Section
5.1(b) of this Agreement repeatedly have found Registry Operator to have been in fundamental and
material breach of this Agreement, including in at least three separate awards,
then the arbitrators shall award such punitive, exemplary or other damages as they may believe
appropriate under the circumstances.
ARTICLE 5 DISPUTE RESOLUTION
Section 5.1
Resolution of Disputes.
5.1
(a) Cooperative Engagement. In the event of a disagreement between Registry Operator and
ICANN arising under or out of this Agreement, either party may by notice to the other invoke
the dispute resolution provisions of this Article V. Provided, however, that before either
party may initiate arbitration as provided in Section 5.1(b) below, ICANN and Registry
Operator must attempt to resolve the dispute by cooperative engagement as set forth in this
Section 5.1(a). If either party provides written notice to the other demanding cooperative
engagement as set forth in this Section 5.1(a), then each party will, within seven calendar
days after such written notice is deemed received in accordance with Section 8.6 hereof,
designate a single executive officer as its representative under this Section 5.1(a) with
full authority to act on such party’s behalf to resolve the dispute. The designated
representatives shall, within 2 business days after being designated, confer by telephone or
in person to attempt to resolve the dispute. If they are not able to resolve the dispute
during such telephone conference or meeting, they shall further meet in person at a location
reasonably designated by ICANN within 7 calendar days after such initial telephone conference
or meeting, at which meeting the parties shall attempt to reach a definitive resolution. The
time schedule and process set forth in this Section 5.1(a) may be modified with respect to
any dispute, but only if both parties agree to a revised time schedule or process in writing
in advance. Settlement communications within the scope of this paragraph shall be
inadmissible in any arbitration or litigation between the parties.
5.1
(b) Arbitration. Disputes arising under or in connection with this Agreement, including
requests for specific performance, shall be resolved through binding arbitration conducted as
provided in this Section 5.1(b) pursuant to the rules of the International Court of
Arbitration of the International Chamber of Commerce (“ICC”). The arbitration shall be
conducted in the English language and shall occur in Los Angeles County, California, USA only
following the failure to resolve the dispute pursuant to cooperative engagement discussions
as set forth in Section 5.1(a) above. There shall be three arbitrators: each party shall
choose one arbitrator and, if the two arbitrators are not able to agree on a third
arbitrator, the third shall be chosen by the ICC. The prevailing party in the arbitration
shall have the right to recover its costs and reasonable attorneys’ fees, which the
arbitrators shall include in their awards. Any party that seeks to confirm or vacate an
arbitration award issued under this Section 5.1(b) may do so only pursuant to the applicable
arbitration statutes. In any litigation involving ICANN concerning this Agreement,
jurisdiction and exclusive venue for such litigation shall be in a court located in Los
Angeles County, California, USA; however, the parties shall also have the right to enforce a
judgment of such a court in any court of competent jurisdiction. For the purpose of aiding
the arbitration and/or preserving the rights of the parties during the pendency of
arbitration, the parties shall have the right to seek a temporary stay or injunctive relief
from the arbitration panel or a court, which shall not be a waiver of this agreement to
arbitrate.
Section 5.2
Specific Performance. Registry Operator and ICANN agree that irreparable damage could
occur if any of the provisions of this Agreement was not performed in accordance
with its specific terms. Accordingly, the parties agree that they each shall be entitled to
seek from the arbitrators specific performance of the terms of this Agreement (in addition to any
other remedy to which each party is entitled).
Section 5.3
Limitation of Liability. ICANN’s aggregate monetary liability for violations of this
Agreement shall not exceed the amount of Registry-Level Fees paid by Registry Operator to ICANN
within the preceding twelve-month period pursuant to this Agreement. Registry Operator’s aggregate
monetary liability to ICANN for violations of this Agreement shall be limited to fees, and monetary
sanctions under Section 4.4, if any, due and owing to ICANN under this Agreement within the
preceding twelve-month period. In no event shall either party be liable for special, indirect,
incidental, punitive, exemplary, or consequential damages arising out of or in connection with this
Agreement or the performance or nonperformance of obligations undertaken in this Agreement, except
as provided pursuant to Section 4.4 of this Agreement. EXCEPT AS OTHERWISE EXPRESSLY PROVIDED IN
THIS AGREEMENT, REGISTRY OPERATOR DOES NOT MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO
THE SERVICES RENDERED BY ITSELF, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR
WORK, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR
FITNESS FOR A PARTICULAR PURPOSE.
ARTICLE 6 TERMINATION PROVISIONS
Section 6.1
Termination by ICANN. ICANN may terminate this Agreement if and only if: (i) Registry
Operator fails to cure any fundamental and material breach of Registry Operator’s obligations set
forth in Sections 3.1(a), (b), (d) or (e); or Section 5.2 within thirty (30) calendar days after
ICANN gives Registry Operator written notice of the breach, which notice shall include with
specificity the details of the alleged breach; and (ii) (a) an arbitrator or court has finally
determined that Registry Operator is, or was, in fundamental and material breach and failed to cure
such breach within the prescribed time period and (b) following the decision of such arbitrator or
court, Registry Operator has failed to comply with the decision of the arbitrator or court.
Section 6.2
Bankruptcy. This Agreement shall automatically terminate in the event Registry Operator
shall voluntarily or involuntarily be subject to bankruptcy proceedings.
Section 6.3
Transition of Registry upon Termination of Agreement. Upon any termination of this
Agreement as provided in Sections 6.1 and 6.2, the parties agree to work cooperatively to
facilitate and implement the transition of the registry for the TLD in accordance with this Section
6.3. Registry Operator shall agree to provide ICANN or any successor registry authority that may be
designated for the TLD with any data regarding operations of the registry for the TLD necessary to
maintain operations that may be reasonably requested in addition to that data escrowed in
accordance with Section 3.1(c)(i) hereof.
Section 6.4
Rights in Data. Registry Operator shall not be entitled to claim any intellectual
property rights in Registry Data. In the event that Registry Data is released from escrow as set
forth in Section 3.1(c)(i), rights, if any, held by Registry Operator in the data shall
automatically be licensed on a non-exclusive, irrevocable, royalty-free, paid-up basis to ICANN or
to a party designated in writing by ICANN.
Section 6.5
No Reimbursement. Any and all expenditures, capital investments or other investments
made by Registry Operator in connection with this Agreement shall be at Registry Operator’s own
risk and ICANN shall have no obligation to reimburse Registry Operator for any such expense,
capital expenditure or investment. Registry Operator shall not be required to
make any payments to a successor registry operator by reason of registry fees paid to Registry
Operator prior to the effective date of (i) any termination or expiration of this Agreement or (ii)
transition of the registry, unless any delay in transition of the registry to a successor operator
shall be due to the actions of Registry Operator.
ARTICLE 7 SPECIAL PROVISIONS
Section 7.1
Registry-Registrar Agreement.
7.1
(a) Access to Registry Services. Registry Operator shall make access to Registry
Services, including the shared registration system, available to all ICANN-accredited
registrars, subject to the terms of the Registry-Registrar Agreement attached as Appendix 8
hereto. Registry Operator shall provide all ICANN-accredited registrars following execution
of the Registry-Registrar Agreement, provided registrars are in compliance with such
agreement, operational access to Registry Services, including the shared registration system
for the TLD. Such nondiscriminatory access shall include without limitation the following:
7.1 (a)(i) All registrars (including any registrar affiliated with Registry Operator,
if any) can connect to the shared registration system gateway for the TLD via the
Internet by utilizing the same maximum number of IP addresses and SSL certificate
authentication;
7.1 (a)(ii) Registry Operator has made the current version of the registrar toolkit
software accessible to all registrars and has made any updates available to all
registrars on the same schedule;
7.1 (a)(iii) All registrars have equivalent access to customer support personnel via
telephone, e-mail and Registry Operator’s website;
7.1 (a)(iv) All registrars have equivalent access to registry resources to resolve
registry/registrar or registrar/registrar disputes and technical and/or administrative
customer service issues;
7.1 (a)(v) All registrars have equivalent access to data generated by Registry
Operator to reconcile their registration activities from Registry Operator’s Web and
ftp servers;
7.1 (a)(vi) All registrars may perform basic automated registrar account management
functions using the same registrar tool made available to all registrars by Registry
Operator; and
7.1 (a)(vii) The shared registration system does not include, for purposes of
providing discriminatory access, any algorithms or protocols that differentiate among
registrars with respect to functionality, including database access, system priorities
and overall performance.
7.1 (a)(viii) Such Registry-Registrar Agreement may be revised by Registry Operator
from time to time, provided however, that any such revisions must be approved in
advance by ICANN.
7.1
(b) Registry Operator Shall Not Act as Own Registrar. Registry Operator shall
not act as a registrar with respect to the TLD. This shall not preclude Registry Operator
from registering names within the TLD to itself through a request made to an ICANN-accredited
registrar.
7.1
(c) Restrictions on Acquisition of Ownership or Controlling
Interest in Registrar.
Registry Operator shall not acquire, directly or indirectly, control of, or a greater than
fifteen percent ownership interest in, any ICANN-accredited registrar.
Section 7.2
Fees to be Paid to ICANN.
7.2
(a) Registry-Level Transaction Fee.
7.2 (a)(i) Commencing on January 1, 2007, Registry Operator shall pay ICANN a
Registry-Level Fee. Subject to Sections 7.2(a)(ii) and (iii) below, such fee shall
equal the Transaction Fee set forth in the table below multiplied by the number of
annual increments of an initial or renewal domain name registration (including
renewals associated with transfers from one ICANN-accredited registrar to another)
during the applicable calendar quarter:
| YEAR | TRANSACTION FEE | |
2007 |
US$0.15 | |
2008 |
US$0.15 | |
2009 |
US$0.20 | |
2010 |
US$0.20 | |
2011 |
US$0.25 | |
2012 |
US$0.25 |
7.2 (a)(ii) Commencing in 2009, for calendar quarters during the Term for which the
average annual price of registrations during the quarter is between US$3.01 and
US$4.99, the Registry-Level Fee shall be the lesser of (a) the transaction fee
provided in 7.2.a.1 or (b) US$0.15 plus US $0.01 for each increase by US$0.20 above
$3.01 in the average price of domain name registrations, multiplied by the number of
annual increments of an initial or renewal domain name registration during such
quarter (including renewals associated with transfers from one ICANN-accredited
registrar to another); and
7.2 (a)(iii) Following two consecutive calendar quarters during which the average
annual price of registrations during the quarter is US$3.00 or less (disregarding for
these purposes any registry-offered discounts or marketing incentives having the short
term effect of lowering the average annual price of domain name registrations),
Registry Operator may request the parties enter good-faith negotiations to review and
renegotiate the fee obligation considering all relevant factors including but not
limited to Registry Operator’s business needs as well as ICANN’s financial requirements.
7.2
(b) Payment Schedule. Registry Operator shall pay the Registry-Level Fees specified in
Section 7.2(a) and Section 7.2(c), if applicable, by the 20th day following the
end of each calendar quarter (i.e., on April 20, July 20, October 20 and January 20 for the
calendar quarters ending March 31, June 30, September 30 and December 31) of the year to an
account designated by ICANN.
7.2
(c) Variable Registry-Level Fee. For fiscal quarters in which ICANN does not collect a
variable accreditation fee from all registrars, upon receipt of written notice from ICANN,
Registry Operator shall pay ICANN a Variable Registry-Level Fee. The fee will be calculated
by ICANN, paid to ICANN by the Registry Operator in accordance with the Payment Schedule in
Section 7.2(b), and the Registry Operator will invoice and collect the fees from the
registrars who are party to a Registry-Registrar Agreement with Registry Operator. The fee
will consist of two components; each component will be calculated by ICANN for each
registrar:
7.2 (c)(i) The transactional component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year but shall not exceed US $0.25.
7.2 (c)(ii) The per-registrar component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year, but the sum of the per- registrar fees calculated for
all registrars shall not exceed the total Per- Registrar Variable funding established
pursuant to the approved 2004- 2005 ICANN Budget.
Provided, however, that Registry Operator shall only be required to pay the
fees set forth in paragraph (c) above, in the event that ICANN elects to
collect the Variable Registry-Level Fee from all ICANN-Accredited
Registrars. For the avoidance of doubt, Registry Operator shall not be
required to collect the per-registrar component of the Variable
Registry-Level Fee from any registrar unless it is required to do so for all
registrars.
7.2
(d) Interest on Late Payments. For any payments pursuant to Section 7.2(a) thirty days or
more overdue past the time period for payment set forth in Section 7.2 (b), Registry Operator
shall pay interest on late payments at the rate of 1.5% per month or, if less, the maximum
rate permitted by applicable law. Registry Operator shall not be required to pay interest on
late payments under Section 7.2(c), provided that Registry Operator is in good faith making
reasonably diligent efforts to collect the underlying payments from those registrars party to
a Registry-Registrar Agreement with Registry Operator.
Section 7.3.
Pricing for Domain Name Registrations and Registry Services.
(a) Pricing. From the Effective Date through six (6) months following the Effective Date, the price
to ICANN-accredited registrars for new and renewal domain name registrations and for transferring a
domain name registration from one ICANN-accredited registrar to another, shall
not exceed a total fee of US$6.00 (the “Maximum Service Fee”). Commencing on 1 January 2007, the
Maximum Service Fee charged during a calendar year for each annual increment of a new and renewal
domain name registration and for transferring a domain name registration from one ICANN-accredited
registrar to another, may not exceed the Maximum Service Fee during the preceding calendar year
multiplied by 1.10. The same Service Fee shall be charged to all ICANN-accredited registrars for
new and renewal domain name registrations. Volume discounts and marketing support and incentive
programs may be made if the same opportunities to qualify for those discounts and marketing support
and incentive programs is available to all ICANN-accredited registrars.
(b) Adjustments
to Pricing for Domain Name Registrations. Registry Operator shall provide no less
than six months prior notice in advance of any price increase for domain name registrations and
shall continue to offer domain name registrations for periods of up to ten years. Registry Operator
is not required to give notice of the imposition of the Variable Registry-Level Fee set forth in
Section 7.2(c).
ARTICLE 8 MISCELLANEOUS
Section 8.1
Indemnification of ICANN.
8.1 (a) Registry Operator shall indemnify, defend, and hold harmless ICANN (including its
directors, officers, employees, and agents) from and against any and all third-party claims,
damages, liabilities, costs, and expenses, including reasonable legal fees and expenses,
arising out of or relating to: (a) ICANN’s reliance, in connection with its decision to
delegate the TLD to Registry Operator or to enter into this Agreement, on information
provided by Registry Operator in its application for the TLD; (b) Registry Operator’s
establishment or operation of the registry for the TLD; (c) Registry Operator’s provision of
Registry Services; (d) collection or handling of Personal Data by Registry Operator; (e) any
dispute concerning registration of a domain name within the domain of the TLD for the
registry; and (f) duties and obligations of Registry Operator in operating the registry for
the TLD; provided that Registry Operator shall not be obligated to indemnify, defend, or hold
harmless ICANN to the extent the claim, damage, liability, cost, or expense arose due to a
breach by ICANN of any obligation contained in this Agreement. For avoidance of doubt,
nothing in this Section 8.1 shall be deemed to require Registry Operator to reimburse or
otherwise indemnify ICANN for the costs associated with the negotiation or execution of this
Agreement, or with the monitoring or management of the parties’ respective obligations under
this Agreement. Further, this section shall not apply to any request for attorney’s fees in
connection with any litigation or arbitration between or among the parties.
8.1 (b) For any claims by ICANN for indemnification whereby multiple registry operators
(including Registry Operator) have engaged in the actions or omissions that gave rise to the
claim, Registry Operator’s aggregate liability to indemnify ICANN with respect to such claim
shall be limited to a percentage of ICANN’s total claim, calculated by dividing the number of
total domain names under registration with Registry Operator within the TLD (which names
under registration shall be calculated consistently with Section 7.2 hereof for any
applicable quarter) by the total number of domain names under registration within all TLDs
for which the registry operators thereof that are engaging in the same acts or omissions
giving rise to such claim. For the avoidance of doubt, in the event that a registry operator
is engaged in the same acts or omissions giving rise to the claims above, but such registry
operator(s) do not have the same or similar indemnification obligations to
ICANN at set forth in 8.1(a) above, the number of domains under management by such registry
operator(s) shall nonetheless be included in the calculation in the preceding sentence.
Section 8.2
Indemnification Procedures. If any third-party claim is commenced that is indemnified
under Section 8.1 above, notice thereof shall be given to ICANN as promptly as practicable.
Registry Operator shall be entitled, if it so elects, in a notice promptly delivered to ICANN, to
immediately take control of the defense and investigation of such claim and to employ and engage
attorneys reasonably acceptable to the indemnified party to handle and defend the same, at the
indemnifying party’s sole cost and expense, provided that in all events ICANN shall be entitled to
control at its sole cost and expense the litigation of issues concerning the validity or
interpretation of ICANN policies or conduct. ICANN shall cooperate, at its own cost, in all
reasonable respects with Registry Operator and its attorneys in the investigation, trial, and
defense of such claim and any appeal arising there from; provided, however, that the indemnified
party may, at its own cost and expense, participate, through its attorneys or otherwise, in such
investigation, trial and defense of such claim and any appeal arising there from. No settlement of
a claim that involves a remedy affecting ICANN other than the payment of money in an amount that is
indemnified shall be entered into without the consent of ICANN. If Registry Operator does not
assume full control over the defense of a claim subject to such defense in accordance with this
Section, Registry Operator may participate in such defense, at its sole cost and expense, and ICANN
shall have the right to defend the claim in such manner as it may deem appropriate, at the cost and
expense of Registry Operator.
Section 8.3
No Offset. All payments due under this Agreement shall be made in a timely manner
throughout the term of this Agreement and notwithstanding the pendency of any dispute (monetary or
otherwise) between Registry Operator and ICANN.
Section 8.4
Use of ICANN Name and Logo. ICANN grants to Registry Operator a non-exclusive
royalty-free license to state that it is designated by ICANN as the Registry Operator for the
Registry TLD and to use a logo specified by ICANN to signify that Registry Operator is an
ICANN-designated registry authority. This license may not be assigned or sublicensed by Registry
Operator.
Section 8.5
Assignment and Subcontracting. Any assignment of this Agreement shall be effective only
upon written agreement by the assignee with the other party to assume the assigning party’s
obligations under this Agreement. Moreover, neither party may assign this Agreement without the
prior written approval of the other party, which approval shall not be unreasonably withheld.
Notwithstanding the foregoing, ICANN may assign this Agreement (i) in conjunction with a
reorganization or re-incorporation of ICANN, to another nonprofit corporation organized for the
same or substantially the same purposes, or (ii) as may be required pursuant to the terms of that
certain Memorandum of Understanding between ICANN and the U.S. Department of Commerce, as the same
may be amended from time to time. Registry Operator must provide notice to ICANN of any
subcontracting arrangements, and any agreement to subcontract portions of the operations of the TLD
must mandate compliance with all covenants, obligations and agreements by Registry Operator
hereunder. Any subcontracting of technical operations shall provide that the subcontracted entity
become party to the data escrow agreement mandated by Section 3.1(c)(i) hereof.
Section 8.6
Amendments and Waivers. No amendment, supplement, or modification of this Agreement or
any provision hereof shall be binding unless executed in writing by both parties. No waiver of any
provision of this Agreement shall be binding unless evidenced by a writing signed by the party
waiving compliance with such provision. No waiver of any of the provisions of this Agreement or
failure to enforce any of the provisions hereof shall be deemed or shall
constitute a waiver of any other provision hereof, nor shall any such waiver constitute a
continuing waiver unless otherwise expressly provided.
Section 8.7
No Third-Party Beneficiaries. This Agreement shall not be construed to create any
obligation by either ICANN or Registry Operator to any non-party to this Agreement, including any
registrar or registered name holder.
Section 8.8
Notices, Designations, and Specifications. All notices to be given under or in relation
to this Agreement shall be given either (i) in writing at the address of the appropriate party as
set forth below or (ii) via facsimile or electronic mail as provided below, unless that party has
given a notice of change of postal or email address, or facsimile number, as provided in this
agreement. Any change in the contact information for notice below shall be given by the party
within 30 days of such change. Any notice required by this Agreement shall be deemed to have been
properly given (i) if in paper form, when delivered in person or via courier service with
confirmation of receipt or (ii) if via facsimile or by electronic mail, upon confirmation of
receipt by the recipient’s facsimile machine or email server. Whenever this Agreement shall specify
a URL address for certain information, Registry Operator shall be deemed to have been given notice
of any such information when electronically posted at the designated URL. In the event other means
of notice shall become practically achievable, such as notice via a secure website, the parties
shall work together to implement such notice means under this Agreement.
If to ICANN, addressed to:
Internet Corporation for Assigned Names and Numbers
▇▇▇▇ ▇▇▇▇▇▇▇▇▇ ▇▇▇, ▇▇▇▇▇ ▇▇▇
▇▇▇▇▇▇ ▇▇▇ ▇▇▇, ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇
Telephone: ▇-▇▇▇-▇▇▇-▇▇▇▇
Facsimile: ▇-▇▇▇-▇▇▇-▇▇▇▇
Attention: President and CEO
With a Required Copy to: General Counsel
Email: (As specified from time to time.)
Internet Corporation for Assigned Names and Numbers
▇▇▇▇ ▇▇▇▇▇▇▇▇▇ ▇▇▇, ▇▇▇▇▇ ▇▇▇
▇▇▇▇▇▇ ▇▇▇ ▇▇▇, ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇
Telephone: ▇-▇▇▇-▇▇▇-▇▇▇▇
Facsimile: ▇-▇▇▇-▇▇▇-▇▇▇▇
Attention: President and CEO
With a Required Copy to: General Counsel
Email: (As specified from time to time.)
If to Registry Operator, addressed to:
NeuStar, Inc.
▇▇▇▇▇ ▇▇▇▇▇▇ ▇▇▇ ▇▇▇▇▇
▇▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇
Telephone: ▇-▇▇▇-▇▇▇-▇▇▇▇
Facsimile: ▇-▇▇▇-▇▇▇-▇▇▇▇
Attention: Sr. Director, Law, Advanced Services and Business Development
NeuStar, Inc.
With a Required Copy to: General Counsel
Email: (As specified from time to time.)
NeuStar, Inc.
▇▇▇▇▇ ▇▇▇▇▇▇ ▇▇▇ ▇▇▇▇▇
▇▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇
Telephone: ▇-▇▇▇-▇▇▇-▇▇▇▇
Facsimile: ▇-▇▇▇-▇▇▇-▇▇▇▇
Attention: Sr. Director, Law, Advanced Services and Business Development
NeuStar, Inc.
With a Required Copy to: General Counsel
Email: (As specified from time to time.)
Section 8.9
Language. Notices, designations, determinations, and specifications made under this
Agreement shall be in the English language.
Section 8.10
Counterparts. This Agreement may be executed in one or more counterparts, each of
which shall be deemed an original, but all of which together shall constitute one and the same
instrument.
Section 8.11
Entire Agreement. This Agreement (including its Appendices, which form a part of it)
constitutes the entire agreement of the parties hereto pertaining to the operation of the TLD and
supersedes all prior agreements, understandings, negotiations and discussions, whether oral or
written, between the parties on that subject. In the event of a conflict between the
provisions in the body of this Agreement and any provision in its Appendices, the provisions
in the body of the Agreement shall control.
[signature page follows]
IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed by their duly
authorized representatives.
INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS
| By: | /s/ Dr. ▇▇▇▇ ▇▇▇▇▇▇ | |||
| Dr. ▇▇▇▇ ▇▇▇▇▇▇ | ||||
| President and CEO | ||||
| Date: | ||||
NEUSTAR, INC.
| By: | /s/ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇ | |||
| ▇▇▇▇▇▇▇ ▇▇▇▇▇▇ | ||||
| Vice President | ||||
| Date: 12/19/06 | ||||
|
|
.BIZ Agreement Appendix 1 | |
| Data Escrow Specification | ||
| (8 December 2006) | ||
This Appendix 1 to the Registry Agreement consists of four of the five exhibits
to the Escrow Agreement that constitutes Appendix 1 to the Registry Agreement:
Exhibit 1 -Schedule for Escrow Deposits
Exhibit 2-Escrow Deposit Format Specification
Exhibit 3-Escrow Transfer Process
Exhibit 4-Escrow Verification Procedures
Exhibit 1 to Appendix 1
SCHEDULE FOR ESCROW DEPOSITS
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 3 below, within a four-hour window beginning at 1200 UTC on the same
Sunday.
Incremental Deposit Schedule
Incremental Deposits are cumulative since the last full escrow. Each
incremental file will contain all database transactions since the full escrow
file was completed.
Incremental Deposits shall be made, according to the transfer process described
in Exhibit 3 below, within a four-hour window beginning at 1200 UTC on the day
to which the Incremental Deposit relates.
Exhibit 2
ESCROW DEPOSIT FORMAT SPECIFICATION
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.
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 general XML format described in items 2 to 6 below. Item 2 describes the
report container that is common to all reports. Items 3 to 6 describe the
structure of the contents of the report container for each of the specific
reports.
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 | |
”
|
" | |
&
|
& | |
’
|
' | |
<
|
< | |
>
|
> |
2. The Report Container. At its highest level, the XML format consists of an
escrow container with header attributes followed by escrow data. The header
attributes are required and include the version of escrow (1.0), the .biz TLD
(“biz”), the report type (domain, host, contact or registrar), and data
base-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.0” tld=“biz” report=“domain” date=“26-Aug-2001 3:15:00AM”>
<!DOCTYPE escrow SYSTEM “whois-export.dtd” >
<escrow version=“1.0” tld=“biz” report=“domain” date=“26-Aug-2001 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 or registrar)
covered by the report. The specific format for each report is described in
items 3 to 6 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. status: The domain status code.
b. id: Unique identifier of the domain name
c. sponsoring registrar: An identification of the sponsoring registrar of the
domain. The sponsoring registrar is designated by a number uniquely assigned by
the IANA.
d. authcode: authorization code.
e. UIN
f. created-on: The date/time the domain object was originally created.
g. 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.
h. renewed-on: The date/time the domain was last renewed.
i. expires-on: The date the registration expires.
j. 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.
k. updated-on: The date/time the domain object was last updated.
l. transferred-on: The date/time when the domain object was last transferred.
m. host: Up to thirteen (13) host names that are nameservers for the domain to
which the domain object relates.
n. 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: Registrant, Administrative, Technical, or Billing
An example domain container appears below:
<domain fqdn=“▇▇▇▇▇▇▇.▇▇▇">
<id>AAA-0001</id>
<status>ACTIVE</status>
<sponsoring registrar>REG-042</owned-by>
<authcode>BIZ-1221</ens-authid>
<created-on>1-Jul-2001 12:34:56AM</created-on>
<created-by>REG-042</created-by>
<renewed-on></renewed-on>
<expires-on>1-Jul-2003</expires-on>
<updated-by>42</updated-by>
<updated-on>1-Jul-2001 12:34:56AM</updated-on>
<transferred-on></transferred-on>
<host>▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇</host>
<host>▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇</host>
<contact-id type=“Registrant">PER-0001</contact-id>
<contact-id type=“Administrative">PER-0002</contact-id>
<contact-id type=“Technical">PER-0003</contact-id>
<contact-id type=“Billing">PER-0004</contact-id>
</domain>
<id>AAA-0001</id>
<status>ACTIVE</status>
<sponsoring registrar>REG-042</owned-by>
<authcode>BIZ-1221</ens-authid>
<created-on>1-Jul-2001 12:34:56AM</created-on>
<created-by>REG-042</created-by>
<renewed-on></renewed-on>
<expires-on>1-Jul-2003</expires-on>
<updated-by>42</updated-by>
<updated-on>1-Jul-2001 12:34:56AM</updated-on>
<transferred-on></transferred-on>
<host>▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇</host>
<host>▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇</host>
<contact-id type=“Registrant">PER-0001</contact-id>
<contact-id type=“Administrative">PER-0002</contact-id>
<contact-id type=“Technical">PER-0003</contact-id>
<contact-id type=“Billing">PER-0004</contact-id>
</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. id: Identifier of the host.
b. sponsoring registrar: 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. transferred-on: The date/time when the host object was last transferred.
g. ip-address: Any number of IP addresses associated with this host.
An example host container appears below:
<host fqdn=“▇▇▇▇.▇▇▇▇▇▇▇.▇▇▇">
<id>HST-0001</id>
<sponsoring registrar>REG-042</owned-by>
<created-on>1-Jul-2001 12:40:32AM</created-on>
<updated-by>42</updated-by>
<updated-on>1-Jul-2001 12:40:32AM</updated-on>
<transferred-on></transferred-on>
<ip-address>192.168.1.1</ip-address>
<ip-address>192.168.122.1</ip-address>
</host>
<id>HST-0001</id>
<sponsoring registrar>REG-042</owned-by>
<created-on>1-Jul-2001 12:40:32AM</created-on>
<updated-by>42</updated-by>
<updated-on>1-Jul-2001 12:40:32AM</updated-on>
<transferred-on></transferred-on>
<ip-address>192.168.1.1</ip-address>
<ip-address>192.168.122.1</ip-address>
</host>
5. The Contact Element. The contact element has the property “id” and is a
container consisting of the following elements:
a. name: The name of the contact.
b. organization: The organization for the contact.
c. street1: The first part of the street address of the contact.
d. street2: The second part of the street address of the contact.
e. street3: The third part of the street address of the contact.
f. city: The name of the city of the contact.
g. state-province: The name of the state/province of the contact.
h. postal-code: The postal/zip code of the contact.
i. geographic location: The two letter ISO 3166 code for the contact’s
geographic location.
j. voice: The voice phone number of the contact in E164a format.
k. fax: The fax number of the contact in E164a format.
l. email: The e-mail address of the contact.
m. sponsoring registrar: An identification of the sponsoring registrar of the
contact. The sponsoring registrar is designated by a number uniquely assigned
by the IANA.
n. 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.
o. created-on: The date/time the contact object was originally created.
p. 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.
q. updated-on: The date/time the contact object was last updated.
r. transferred-on: The date/time when the contact object was last transferred.
s. status: Contact status.
An example contact container appears below:
<contact id=“1">
<name>▇▇▇▇ ▇▇▇</name>
<organization>NeuStar</organization>
<street1>46000 Center Oak Plaza</street1>
<street2></street2>
<street3></street3>
<city>Sterling</city>
<state-province>VA</state-province>
<postal-code>20166</postal-code>
<country>US</country>
<voice>+1 571.4345400</voice>
<fax>+1 571.4345401</fax>
<email>▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇</email>
<sponsoring registrar>42</owned-by>
<created-by>REG-042</created-by>
<created-on>1-Jul-2001 12:42:22AM</created-on>
<updated-by>42</updated-by>
<updated-on>1-Jul-2001 12:42:22AM</updated-on>
<transferred-on></transferred-on>
<status>ACTIVE</status>
</contact>
<name>▇▇▇▇ ▇▇▇</name>
<organization>NeuStar</organization>
<street1>46000 Center Oak Plaza</street1>
<street2></street2>
<street3></street3>
<city>Sterling</city>
<state-province>VA</state-province>
<postal-code>20166</postal-code>
<country>US</country>
<voice>+1 571.4345400</voice>
<fax>+1 571.4345401</fax>
<email>▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇</email>
<sponsoring registrar>42</owned-by>
<created-by>REG-042</created-by>
<created-on>1-Jul-2001 12:42:22AM</created-on>
<updated-by>42</updated-by>
<updated-on>1-Jul-2001 12:42:22AM</updated-on>
<transferred-on></transferred-on>
<status>ACTIVE</status>
</contact>
6. The Registrar Element. The registrar element has the property “id” and is a
container consisting of the following elements:
a. name: The name of the registrar.
b. status: The registrar status code.
c. contact-id: Any number of contact-id associated with this registrar.
Contact-id has the property “type” to denote the type of contact. “Type” can be
one of: Registrar, Administrative, Technical or Billing
An example registrar container appears below:
<registrar id=“REG-042">
<password>registrarrus</password>
<name>Registrar R Us</name>
<status>ACTIVE</status>
<contact-id type=“Registrar">PER-0009</contact-id>
<contact-id type=“Administrative">PER-0010</contact-id>
<contact-id type=“Administrative">PER-0011</contact-id>
<contact-id type=“Technical">PER-0012</contact-id>
<contact-id type=“Technical">PER-0013</contact-id>
<contact-id type=“Billing">PER-0014</contact-id>
</registrar>
<password>registrarrus</password>
<name>Registrar R Us</name>
<status>ACTIVE</status>
<contact-id type=“Registrar">PER-0009</contact-id>
<contact-id type=“Administrative">PER-0010</contact-id>
<contact-id type=“Administrative">PER-0011</contact-id>
<contact-id type=“Technical">PER-0012</contact-id>
<contact-id type=“Technical">PER-0013</contact-id>
<contact-id type=“Billing">PER-0014</contact-id>
</registrar>
Exhibit 3
ESCROW TRANSFER PROCESS
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 2 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: “bizSEQN”, 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 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 4
ESCROW VERIFICATION PROCEDURES
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 (to be supplied by ICANN) on the Deposit
file (without report) that will split it in to its constituent reports
(including the format report prepared by 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, Registry and ICANN shall exchange keys by the
same procedure.
|
|
.BIZ Agreement Appendix 2 | |
| Registry Data Escrow Agreement | ||
| (8 December 2006) | ||
This Registry Data Escrow Agreement (“Agreement”) is made as of this [enter
date] (the “Beginning Date”), by and between NeuStar, Inc. (“Registry
Operator”), [name of Escrow Agent] (“Escrow Agent”), and the Internet
Corporation for Assigned Names and Numbers (“ICANN”). All capitalized terms not
defined herein shall have the meaning set forth in the Registry Agreement. All
capitalized terms not defined in this Agreement have the meanings set forth in
the Registry Agreement.
RECITALS
A. Registry Operator and ICANN have entered into a Registry Agreement
(“Registry Agreement”), which requires Registry Operator, during the period
Registry Operator operates the registry for the TLD, to submit certain domain
name registration data to a reputable escrow agent to be held in escrow.
B. Pursuant to the Registry Agreement, Registry Operator intends to deliver
periodically to Escrow Agent an electronic copy of the Registry Database, as
detailed in Subsection 3.1(c) of the Registry Agreement (each such delivery
referred to as a “Deposit”).
C. Registry Operator and ICANN each desire Escrow Agent to hold each Deposit,
and, upon certain events, release any retained Deposits (or a copy of the
Deposits) to ICANN, in accordance with the terms of this Agreement or as
ordered by a court of competent jurisdiction.
Now, therefore, in consideration of the premises and mutual obligations
contained herein and for other good and valuable consideration, the receipt and
sufficiency of which are hereby acknowledged, the parties agree as follows:
AGREEMENT
1. Content of Deposits. Deposits will be of two kinds: Full Deposits and
Incremental Deposits. Each Full Deposit will consist of Registry Data that
reflects the current and complete Registry Database. Incremental Deposits will
consist of data that reflects all transactions involving the database that are
not reflected in the last previous Full Deposit or Incremental Deposit, as the
case may be.
2. Schedule for Deposits. Registry Operator must create and deliver to Escrow
Agent a Full Deposit once each week, according to the schedule specified in
Exhibit 1 of Appendix 1. Registry Operator must create and deliver to Escrow
Agent an Incremental Deposit once each day during which a Full Deposit is not
made, according to the schedule specified in Exhibit 1 of Appendix 1.
3. Format of Deposits. The data in each Full Deposit and in each Incremental
Deposit shall follow the data format specified in the TLD Registry Data Escrow:
Format Specification (the “Format Specification”), attached as Exhibit 2 of
Appendix 1.
4. Procedure for Deposits. Each properly formatted Full Deposit and Incremental
Deposit shall be processed and electronically delivered in encrypted form to
Escrow Agent according to the transfer process described in Exhibit 3 of
Appendix 1.
5. Notification of Deposits. Simultaneous with the delivery to Escrow Agent of
any Full or Incremental Deposit, Registry Operator shall deliver to Escrow
Agent and to ICANN a written statement (which may be by authenticated e-mail)
that includes a copy of the report generated upon creation of the Full or
Incremental Deposit by the ICANN-provided software (as described in Exhibit 1)
and states that the Full or Incremental Deposit (as the case may be) has been
inspected by Registry Operator according to the procedures described in Exhibit
3 of Appendix 1 and is complete and accurate. Escrow Agent shall notify ICANN
of all Deposits received, within two business days of receipt.
6. Verification. Within two business days after receiving each Full or
Incremental Deposit, Escrow Agent shall verify the format and completeness of
each Deposit by performing the verification procedures specified in Exhibit 4
of Appendix 1 and shall deliver to ICANN a copy of the verification report
generated for each Deposit (which may be by authenticated e-mail). If Escrow
Agent discovers that any Deposit fails the verification procedures, Escrow
Agent shall notify, including by email, fax and phone, Registry Operator and
ICANN of such nonconformity within forty-eight hours of discovery. Upon
notification of such verification failure, Registry Operator shall begin
developing modifications, updates, corrections, and other fixes of the Full or
Incremental Deposit necessary for the Deposit to pass the verification
procedures and shall deliver such fixes to Escrow Agent as promptly as
possible. Escrow Agent shall verify the accuracy or completeness of any such
corrected Deposit pursuant to the procedures in this Section 6 and shall give
ICANN notice of successful verification within twenty-four hours. The failure
of any Full or Incremental Deposit to meet verification procedures and any
efforts by Registry Operator to remedy such failure shall not delay the
delivery of any subsequent scheduled Full or Incremental Deposits pursuant to
the schedule in Exhibit 1 of Appendix 1. Escrow Agent shall deliver, on the
first business day of each month, (i) a written certification to ICANN that
Escrow Agent has performed such verification procedures on each Deposit
received during the last month, and (ii) copies of the verification reports
generated for each Deposit received during the last month.
7. Retention and Confidentiality.
7.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 of Escrow Agent. Escrow Agent shall use commercially
reasonable efforts to protect the integrity of the Deposits. Each of ICANN and
Registry Operator shall have the right to inspect Escrow Agent’s written
records with respect to this Agreement upon reasonable prior notice and during
normal business hours.
7.2 Destruction of Deposits. At all times, Escrow Agent shall retain the four
most recent Full Deposits and all Incremental Deposits after the earliest of
those four Full Deposits, all of which must have passed the verification
procedures specified in Exhibit 4 of Appendix 1. Registry Operator may destroy
any Deposits prior to these four most recent Full Deposits.
7.3 Confidentiality. Escrow Agent shall use commercially reasonable efforts to
protect the confidentiality of the Deposits. Except as provided in this
Agreement, Escrow Agent shall not disclose, transfer, make available, or use
any Deposit (or any copies of any Deposit). Should Escrow Agent be put on
notice that it is required to disclose any Deposits by statute, rule,
regulation, order, or other requirement of a governmental agency, legislative
body, court of competent jurisdiction, or binding arbitral body (other than any
requirement pursuant to Sections 9.1.6, 11.2, and 13 of this Agreement), Escrow
Agent shall notify ICANN and Registry Operator within seven days or as soon as
practicable and reasonably cooperate with Registry Operator and/or ICANN in any
contest of the disclosure. Should any contest prove unsuccessful, Escrow Agent
shall not be held liable for any disclosure pursuant to such governmental,
legislative, judicial, or arbitral order, statute, rule, regulation, or other
requirement.
8. Duplication. Escrow Agent may duplicate any Deposit by any commercially
reasonable means in order to comply with the terms and provisions of this
Agreement, provided that Registry Operator shall bear the expense of such
duplication. Alternatively, Escrow Agent, by notice to Registry Operator, may
reasonably require Registry Operator to promptly duplicate any Deposit.
9. Release of Deposit. Within five business days after receipt of any required
documents and/or notices specified in this Section 9, Escrow Agent shall
deliver to ICANN or its designee all Deposits in Escrow Agent’s possession, in
the event that the Escrow Agent receives all of the following:
9.1 One of the following notices:
9.1.1 A written notice by the Registry Operator requesting Escrow Agent to
effect such delivery to ICANN; or
9.1.2 A written notice by ICANN that the Registry Agreement has: (i) expired
without renewal, pursuant to Section 4.1 of the Registry Agreement, or (ii)
been terminated, in accordance with Article VI of the Registry Agreement; or
9.1.3 A written notice by ICANN that all of the following have occurred:
9.1.3.1 ICANN failed, with respect to (a) any Full Deposit or (b) five
Incremental Deposits within any calendar month, to receive, within five
calendar days after the Deposit’s scheduled delivery date, to receive
notification of receipt from Escrow Agent; and
9.1.3.2 ICANN gave notice to Escrow Agent and Registry Operator of that
failure; and
9.1.3.3 ICANN has not, within seven calendar days after the notice under
Section 9.1.3.2, received notice from Escrow Agent that the Deposit has been
received; or
9.1.4 A written notice by ICANN that all of the following have occurred:
9.1.4.1 ICANN has received notification from Escrow Agent of failed
verification of a Full Depositor of failed verification of five Incremental
Deposits within any calendar month; and
9.1.4.2 ICANN gave notice to Registry Operator of that receipt; and
9.1.4.3 ICANN has not, within seven calendar days after the notice under
Section 9.1.4.2, received notice from Escrow Agent of verification of a
remediated version of the Deposit; or
9.1.5 A written notice by ICANN that release of the Deposits is mandated by
non-payment of any fees due to Escrow Agent, pursuant to Section 15 of this
Agreement; or
9.1.6 A written notice by ICANN that a court, arbitral, legislative, or
government agency that ICANN finds to be of competent jurisdiction has issued
an order, rule, statute, regulation, or other requirement (a copy of which
ICANN has provided to Registry Operator) that mandates the release of the
Deposits to ICANN; and
9.2 Copies of notices with proof of delivery submitted to Escrow Agent that
ICANN or Registry Operator (whichever gave the notice under Section 9.1) has
previously notified the other party in writing; and
9.3 Written instructions from ICANN that the Deposits be released and delivered
to a designated party; and
9.4 A written undertaking by ICANN that the Deposits will be used only as
permitted under the terms of the Registry Agreement. Upon release of any
Deposits to ICANN, Escrow Agent shall at the same time deliver to Registry
Operator a photostatic copy of the notice it received from ICANN under Sections
9.1.2 to 9.1.6, as applicable.
10. Release of Deposit to Registry Operator. Escrow Agent shall deliver all
Deposits to Registry Operator upon termination of this Agreement in accordance
with Sections 14.1 and 14.2.1 of this Agreement.
11. Procedure After Release.
11.1 Right to Use Deposits. Upon release of any Deposits to Registry Operator
pursuant to Section 9, Registry Operator (or its assignee in accordance with
the Registry Agreement), and subject to Section 9.4 above, shall immediately
have the right to exercise or have exercised all rights in the Deposits
necessary to provide registry services. Upon release of any Deposits to ICANN
pursuant to Section 9, ICANN (or its assignee in accordance with the Registry
Agreement) shall immediately have the right, subject to Section 9.4 above, to
exercise or have exercised all rights in the Deposits pursuant to the Registry
Agreement, including as necessary to provide registry services.
11.2 Objection Notice. Upon release of any Deposits to ICANN pursuant to
Section 9, Registry Operator shall have thirty calendar days to notify Escrow
Agent and ICANN in writing (the “Objection Notice”) of its objection to the
release of the Deposits to ICANN and request that the issue of entitlement to
the Deposits be resolved pursuant to the dispute resolution procedures in the
Registry Agreement (the “Dispute Resolution Procedures”). Registry Operator and
ICANN agree to resolve any disputes they may have as between themselves under
this Agreement in accordance with Section 17.2 hereof. The parties agree that
(i) Registry Operator shall have no rights (other than pursuant to this Section
11.2) to object to any release of the Deposits, and (ii) the delivery of an
Objection Notice and the commencement of Dispute Resolution Procedures shall
not delay release of any Deposits to ICANN pursuant to Section 9.
11.3 Dispute Resolution Procedures. The parties agree that any proceedings
brought pursuant to the Dispute Resolution Procedures shall be conducted
consistently and in accordance with any prior arbitration or court
orders/decisions involving the Registry Agreement. The parties further agree
that any proceedings relating to this Agreement and brought pursuant to the
Dispute Resolution Procedures shall not examine, re-evaluate, reconsider, or
otherwise subject to review any issues, causes of action, or other claims which
were decided, or which a party had a reasonable opportunity to raise, in
proceedings which involved the Registry Agreement.
11.4 Withdrawal of Objection Notice. Registry Operator may, at any time, notify
Escrow Agent and ICANN that Registry Operator wishes to withdraw its Objection
Notice. Upon receipt of such withdrawal from Registry Operator, Escrow Agent
shall promptly deliver to ICANN any Deposits that have not previously been
delivered to ICANN.
11.5 Dispute Resolution Decisions.
11.5.1 If the release of Deposits under Section 9 to ICANN is determined in
Dispute Resolution Procedures to have been proper, Escrow Agent shall promptly
deliver to ICANN, in accordance with the instructions specified in Section 9.3,
any Deposits that have not previously been delivered.
11.5.2 If the release of Deposits to ICANN is determined in Dispute Resolution
Procedures to have been improper, ICANN shall promptly return or destroy, at
Registry Operator’s discretion, the Deposits received by ICANN under Section 9.
12. Indemnity. Registry Operator and ICANN shall, jointly and severally,
indemnify and hold harmless Escrow Agent and each of its directors, officers,
agents and employees (“Escrow Agent Indemnitees”) absolutely and forever, from
and against any and all claims, actions, damages, suits, liabilities,
obligations, costs, fees, charges, and any other expenses whatsoever, including
reasonable attorneys’ fees and costs, that may be asserted by a third party
against any Escrow Agent Indemnitees in connection with this Agreement or the
performance of Escrow Agent or any Escrow Agent Indemnitees hereunder (with the
exception of any claims based on the misrepresentation, negligence, or
misconduct of Escrow Agent, its directors, officers, agents, employees and
contractors). Escrow Agent shall likewise indemnify and hold harmless Registry
Operator and ICANN, and each of their respective directors, officers, agents
and employees (“Indemnitees”) absolutely and forever, from and against any and
all claims, actions, damages, suits, liabilities, obligations, costs, fees,
charges, and any other expenses whatsoever, including reasonable attorneys’
fees and costs, that may be asserted by a third party against any Indemnitee in
connection with the misrepresentation, negligence, or misconduct of Escrow
Agent, its directors, officers, agents, employees, contractors, and
stockholders.
13. Interpleader.
13.1 Escrow Agent may submit any dispute under this Agreement to any court of
competent jurisdiction in an interpleader or similar action. Any and all costs
incurred by Escrow Agent in connection therewith, including reasonable
attorneys’ fees and costs, shall be borne 50% by each of Registry Operator and
ICANN.
13.2 Escrow Agent shall perform any acts ordered by any court of competent
jurisdiction, without any liability or obligation to any party hereunder by
reason of such act.
14. Term and Termination.
14.1 Term. The initial term of this Agreement shall be one year, commencing on
the Beginning Date (the “Initial Term”). This Agreement shall be automatically
renewed for an additional term of one year (“Additional Term”) at the end of
the Initial Term and each Additional Term hereunder unless, on or before ninety
days prior to the end of the Initial Term or an Additional Term, a party
notifies the other parties that it wishes to terminate this Agreement at the
end of such term. In the event a party gives the other parties such notice of
termination, and Registry Operator and ICANN cannot agree to resolve, by the
end of the then-current term, any disputes regarding the renewal of this
Agreement or the establishment of a replacement escrow agent: (i) Registry
Operator and ICANN shall resolve any such disputes through the Dispute
Resolution Procedures; (ii) this Agreement shall continue to remain in effect
during the resolution of any such disputes; and (iii) Escrow Agent shall have
the right to invoice either Registry Operator or ICANN for the data escrow
services provided during this dispute resolution period at the rates listed in
Exhibit E. This paragraph in no way limits the Registry Operator’s rights under
the Registry Agreement to change to a different Escrow Agent mutually approved
by Registry Operator and ICANN, such approval not to be unreasonably withheld
by either of them, provided that such Escrow Agent will agree to substantially
similar terms as in the present document and there is no significant
interruption of Deposits.
14.2 Termination. This Agreement shall terminate upon the occurrence of any of
the following:
14.2.1 Termination of this Agreement by both Registry Operator and ICANN upon
having delivered to Escrow Agent a written notice signed by both Registry
Operator and ICANN indicating their mutual intent to terminate this Agreement
upon ninety days’ notice;
14.2.2 Termination of this Agreement by Escrow Agent pursuant to Section 15; or
14.2.3 Release of the Deposit(s) to ICANN pursuant to Section 9 and, if an
Objection Notice is made and not withdrawn, a final decision that the release
of materials to ICANN was proper at the end of the Dispute Resolution
Procedures.
15. Fees and Payments. Registry Operator shall pay to Escrow Agent the
applicable fees and charges listed in Exhibit E as compensation for Escrow
Agent’s services under this Agreement. If Registry Operator fails to pay any
fees or charges invoiced by Escrow Agent by the due date(s), Escrow Agent shall
give written notice to Registry Operator of non-payment of any such past-due
fees hereunder and, in that event, the Registry Operator shall have the right
to pay the past-due fee(s) within ten business days after receipt of the notice
from Escrow Agent. Upon payment of the past-due fee by Registry Operator, this
Agreement shall continue in full force and effect. If Registry Operator fails
to pay the past-due fee(s) within the applicable periods under this Section 15,
Escrow Agent shall have the right to terminate this Agreement immediately by
sending notice of termination to all other parties, and, upon termination,
Escrow Agent shall deliver to ICANN all Deposits held by Escrow Agent.
16. Ownership of Deposit. Subject to the provisions (including Subsection 6.5)
of the Registry Agreement, the parties recognize and acknowledge that ownership
of the Deposit during the effective term of this Agreement shall remain with
the Registry Operator at all times.
17. Miscellaneous.
17.1 Remedies. For the purposes of fulfilling its obligations under this
Agreement, Escrow Agent may act in good faith reliance on, and shall not be
held liable for, any written notice, instruction, instrument, or other writing
signed or presented by a person with apparent authority to act on behalf of
Registry Operator or ICANN.
17.2 Dispute Resolution. Registry Operator and ICANN further agree to resolve
any disputes they may have as between themselves under this Agreement pursuant
to the Dispute Resolution Procedures.
17.3 Limitation of Liability. The parties shall not be liable to each other for
special, indirect, incidental, or consequential damages hereunder. As between
ICANN and Registry Operator the liability limitations of Subsection 5.3 of the
Registry Agreement also apply.
17.4 Independent Contractor. Escrow Agent is an independent contractor and is
not an employee or agent of either Registry Operator or ICANN.
17.5 No Third-Party Beneficiaries. This Agreement shall not be construed to
create any obligation by Registry Operator, ICANN, or Escrow Agent to any
non-party to this Agreement, including but not limited to any domain-name
holder or registrar.
17.6 Amendments. This Agreement shall not be modified or amended except in
writing executed by each of the parties.
17.7 Assignment. Neither Registry Operator nor ICANN may assign or transfer
this Agreement (by merger, sale of assets, operation of law, or otherwise),
except that the rights and obligations of Registry Operator or ICANN
automatically shall be transferred to the assignee of one of those parties’
rights and obligations under the Registry Agreement. Escrow Agent may not
assign or transfer this Agreement without the prior written consent of both
Registry Operator and ICANN.
17.8 Entire Agreement. This Agreement, including all exhibits, supersedes all
prior discussions, understandings, and agreements between Escrow Agent and the
other parties with respect to the data escrow services for the Registry TLD.
The parties acknowledge and agree that, as between ICANN and Registry Operator,
the Registry Agreement (including all its appendices) is intended to co-exist
with this Agreement, this Agreement is supplementary to the Registry Agreement,
and the Registry Agreement shall control in the event of any conflict.
17.9 Counterparts. This Agreement may be executed in counterparts, each of
which when so executed shall be deemed to be an original and all of which when
taken together shall constitute one and the same Agreement.
17.10 Governing Law. This Agreement shall be construed and enforced in
accordance with the laws of the State of California, without regard to its
conflicts-of-laws principles. The parties consent and agree that jurisdiction
and venue for any legal proceedings relating to this Agreement shall lie with
the state and federal courts of Los Angeles County in the State of California.
17.11 Notices. All notices, requests, demands or other communications required
or permitted to be given or made under this Agreement shall be in writing and
shall be delivered by hand, by commercial overnight delivery service which
provides for evidence of receipt, by certified mail, return receipt requested,
postage prepaid, by facsimile, or by e-mail (e-mail to be followed promptly at
receiver’s request by a copy delivered by one of the other means of delivery)
to the corresponding addresses listed on the signature page of this Agreement.
If delivered personally, by commercial overnight delivery service, by
facsimile, or by e-mail, the date on which the notice, request, instruction or
document is delivered shall be the date on which delivery is deemed to be made,
and if delivered by mail, the date on which such notice, request, instruction
or document is received shall be the date on which delivery is deemed to be
made. Any party may change its address for the purpose of this Agreement by
notice in writing to the other parties as provided herein.
17.12 Survival. The obligation of confidentiality in Section 7, Sections 9, 10,
11, 12, 13, 17.3 and this Section 17.12 shall survive any termination of this
Agreement.
17.13 No Waiver. No failure on the part of any party hereto to exercise, and no
delay in exercising any right, power or single or partial exercise of any
right, power or remedy by any party will preclude any other or further exercise
of that or any other right, power, or remedy. No express waiver or assent by
any party to any breach of or default in any term or condition of this
Agreement shall constitute a waiver of or an assent to any succeeding breach of
or default in the same or any other term or condition.
IN WITNESS WHEREOF each of the parties has caused its duly authorized officer
to execute this Agreement as of the date and year first above written.
|
|
.BIZ Agreement ▇▇▇▇▇▇▇▇ ▇ | |
| ▇▇▇▇ File Access Agreement | ||
| (8 December 2006) | ||
1. Parties
The User named in this Agreement (“User” or “you”) hereby contracts with NeuStar, Inc., a Delaware
Corporation (“Registry Operator”), for a non-exclusive, non-transferable, limited right to access
an Internet host server or servers designated by Registry from time to time, and to transfer a copy
of the described Data to the User’s Internet host machine specified below, under the terms of this
Agreement. Upon execution of this Agreement by Registry Operator, Registry Operator will return a
copy of this Agreement to you for your records with your UserID and Password entered in the spaces
set forth below.
2. User Information
(a) User: |
||||
(b) Contact Person: |
||||
(c) Street Address: |
||||
| (d) City, State or Province: | ||||||
| (e) Country and Postal Code: | ||||||
| (f) Telephone Number: | ||||||||
| (including area/country code) | ||||||||
| (g) Fax Number: | ||||||||
| (including area/country code) | ||||||||
| (h) E-Mail Address: | ||||||||
(i) Specific Internet host machine which will be used to access NeuStar’s server to transfer copies
of the Data:
Name: |
||||||
| IP Address: | ||||||
(j) Purpose(s) for which the Data will be used: During the term of this Agreement, you may use the
data for any legal purpose, not prohibited under Section 4 below. You may incorporate some or all
of the Data in your own products or services, and distribute those products or services for a
purpose not prohibited under Section 4 below.
3. Term
This Agreement is effective for a period of three (3) months from the date of execution by Registry
(the “Initial Term”). Upon conclusion of the Initial Term this Agreement will automatically renew
for successive three-month renewal terms (each a “Renewal Term”) until terminated by either party
as set forth in Section 12 of this Agreement or one party provides the other party with a written
notice of termination at least seven (7) days prior to the end of the Initial Term or the then
current Renewal Term.
NOTICE TO USER: CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS. YOU MAY USE THE USER ID AND
ASSOCIATED PASSWORD PROVIDED IN CONJUNCTION WITH THIS AGREEMENT ONLY TO OBTAIN A COPY OF .BIZ
TOP-LEVEL DOMAIN (“TLD”) ZONE FILES, AND ANY ASSOCIATED ENCRYPTED CHECKSUM FILES (COLLECTIVELY THE
“DATA”), VIA THE FILE TRANSFER PROTOCOL (“FTP”) OR THE HYPERTEXT TRANSFER PROTOCOL (“HTTP”)
PURSUANT TO THESE TERMS.
4. Grant Of Access
Registry Operator grants to you a non-exclusive, non-transferable, limited right to access an
Internet host server or servers designated by Registry Operator from time to time, and to transfer
a copy of the Data to the Internet host machine identified in Section 2 of this Agreement no more
than once per 24 hour period using FTP or HTTP for the purposes described in this Section 4. You
agree that you will:
(a) use this Data only for lawful purposes but that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of
mass unsolicited, commercial advertising or solicitations to entities other than your own existing
customers; or (2) enable high volume, automated, electronic processes that send queries or data to
the systems of Registry Operator or any ICANN-Accredited Registrar, except as reasonably necessary
to register domain names or modify existing registrations. Registry Operator reserves the right,
with the approval of the Internet Corporation for Assigned Names and Numbers (“ICANN”), to specify
additional specific categories of prohibited uses by giving you reasonable written notice at any
time and upon receiving such notice you shall not make such prohibited use of the Data you obtain
under this Agreement.
(b) copy the Data you obtain under this Agreement into a machine-readable or printed form only as
necessary to use it in accordance with this Agreement in support of your use of the Data.
(c) comply with all applicable laws and regulations governing the use of the Data.
(d) not distribute the Data you obtained under this Agreement or any copy thereof to any other
party without the express prior written consent of Registry Operator, except that you may
redistribute the Data insofar as it has been incorporated by you into a value-added product or
service that does not permit the extraction of a substantial portion of the Data from the
value-added product or service, provided
you prohibit the recipient of the Data from using the Data in a manner contrary to Section 4(a).
(e) take all reasonable steps to protect against unauthorized access to, use, and disclosure of the
Data you obtain under this Agreement.
5. Fee
You agree to remit in advance to Registry Operator a quarterly fee of $0 (USD) for the right to
access the files during either the Initial Term or Renewal Term of this Agreement. Registry
Operator reserves the right to adjust, with the approval of ICANN, this fee on thirty days prior
notice to reflect a change in the cost of providing access to the files.
6. Proprietary Rights
You agree that no ownership rights in the Data are transferred to you under this Agreement. You
agree that any copies of the Data that you make will contain the same notice that appears on and in
the Data obtained under this Agreement.
7. Method Of Access
Registry Operator reserves the right, with the approval of ICANN, to change the method of access to
the Data at any time. You also agree that, in the event of significant degradation of system
processing or other emergency, Registry Operator may, in its sole discretion, temporarily suspend
access under this Agreement in order to minimize threats to the operational stability and security
of the Internet.
8. No Warranties
THE DATA IS PROVIDED “AS IS.” REGISTRY OPERATOR DISCLAIMS ALL WARRANTIES WITH RESPECT TO THE DATA,
EITHER EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR
PARTICULAR PURPOSE AND NON-INFRINGEMENT OF THIRD PARTY RIGHTS. Some jurisdictions do not allow the
exclusion of implied warranties or the exclusion or limitation of incidental or consequential
damages, so the above limitations or exclusions may not apply to you.
9. Severability
In the event of invalidity of any provision of this Agreement, the parties agree that such
invalidity shall not affect the validity of the remaining provisions of this Agreement.
10. No Consequential Damages; Limitation of Damages.
In no event shall Registry Operator be liable to you for any consequential, special, incidental or
indirect damages of any kind arising out of the use of the Data or the termination of this
Agreement, even if Registry Operator has been advised of the possibility of such damages. In no
event shall Registry Operator be liable to you for direct damages in an amount in excess of the
fees paid by you to Registry Operator during the one (1) year period preceding the date of your
claim.
11. Governing Law
This Agreement shall be governed and construed in accordance with the laws of the Commonwealth of
Virginia, without reference to conflicts of laws principles You agree that any legal action or
other legal proceeding relating to this Agreement or the enforcement of any provision of this
Agreement shall be brought or otherwise commenced in the United States District Court for the
Eastern District of Virginia or, if such court does not have subject matter jurisdiction over such
claim, in the state courts of Virginia located in Loudoun
County, Virginia. You expressly and irrevocably agree and consent to the personal jurisdiction and
venue of the federal and state courts located in Loudoun County, Virginia (and each appellate court
located therein) for matters arising in connection with this Agreement or your obtaining, use, or
distribution of the Data. The United Nations Convention on Contracts for the International Sale of
Goods is specifically disclaimed.
12. Termination
You may terminate this Agreement at any time by erasing the Data you obtained under this Agreement
from your Internet host machine together with all copies of the Data and providing written notice
of your termination to Registry Operator at ▇▇▇▇▇ ▇▇▇▇▇▇ ▇▇▇ ▇▇▇▇▇, ▇▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇. Registry
Operator has the right to terminate this Agreement immediately if you fail to comply with any term
or condition of this Agreement. You agree upon receiving notice of such termination of this
Agreement by Registry Operator or expiration of this Agreement to erase the Data you obtained under
this Agreement together with all copies of the Data.
13. Definition
“Data” means all data contained in a DNS zone file for the Registry TLD as provided to TLD
nameservers on the Internet.
14. Waiver
Any delay or forbearance by either party in exercising any right hereunder shall not be deemed a
waiver of that right.
15. Entire Agreement
This is the entire agreement between you and Registry Operator concerning access and use of the
Data, and it supersedes any prior agreements or understandings, whether written or oral, relating
to access and use of the Data.
Any modification of this Agreement will be effective only if it is in writing signed by the party
to be charged.
NeuStar, Inc.
|
User: | |
By:
|
By: | |
(sign)
|
(sign) | |
Name:
|
Name: | |
(print)
|
(print) | |
Title:
|
Title: | |
Date:
|
Date: |
ASSIGNED USERID AND PASSWORD
(To be assigned by NeuStar upon execution of this Agreement):
USERID:
|
PASSWORD: |
|
|
.BIZ Agreement Appendix 4 | |
| Registry Operator’s Monthly Report | ||
| (8 December 2006) | ||
Registry Operator shall provide the following information in its monthly reports. Reports shall be
submitted via email to <▇▇▇▇▇▇▇▇-▇▇▇▇▇▇▇@▇▇▇▇▇.▇▇▇>. ICANN shall use reasonable commercial
efforts to preserve the confidentiality of the information reported until three months after the
end of the month to which the report relates.
1. Accredited Registrar Status. State the number of registrars in each of the following three
categories: (1) operational, (2) ramp-up (registrars that have received a password for access to
OT&E), and (3) pre-ramp-up (registrars that have requested access, but have not yet entered the
ramp-up period).
2. Service Level Agreement Performance. Compare Service Level Agreement requirements with actual
performance measures for the reporting month.
3. TLD Zone File Access Activity. State the total number of zone file access passwords at end of
the reporting month.
4. Completed System Software Releases. Describe significant releases during the reporting month,
including release name, features, and completion date.
5. Whois Service Activity. State the number of Whois queries during the reporting month.
6. Total Number of Transactions by Subcategory by Month. State the total number of transactions
during the reporting month, in the following subcategories: adds, deletes, modifies, checks,
renews, transfers, restores.
7. Daily Transaction Range. Tabulate the number of total daily transactions. The range of
transaction volume should be shown for each month, along with the average daily transaction volume.
8.Per-Registrar Activity Report. This report shall be transmitted to ICANN electronically in comma
or pipe separated-value format, using the following fields per registrar:
| Field # | Field Name | Notes | ||
01
|
registrar-name | registrar’s full corporate name | ||
02
|
iana-id | ▇▇▇▇://▇▇▇.▇▇▇▇.▇▇▇/▇▇▇▇▇▇▇▇▇▇▇/▇▇▇▇▇▇▇▇▇-▇▇▇ | ||
03
|
total-domains | total domains under sponsorship | ||
04
|
total-nameservers | total nameservers registered | ||
05
|
net-adds-1-yr | domains successfully added (and not deleted within the add grace period) | ||
06
|
net-adds-2-yr | number of domains successfully registered with an initial term of two years | ||
07
|
net-adds-3-yr | number of domains successfully registered with an initial term of three years | ||
08
|
net-adds-4-yr | etc. | ||
09
|
net-adds-5-yr | ” “ | ||
10
|
net-adds-6-yr | ” “ | ||
11
|
net-adds-7-yr | ” “ | ||
12
|
net-adds-8-yr | ” “ | ||
13
|
net-adds-9-yr | ” “ | ||
14
|
net-adds-10-yr | ” “ | ||
15
|
net-renews-1-yr | domains renewed either automatically or by command (and not deleted within the renew grace period) | ||
16
|
net-renews-2-yr | number of domains successfully renewed with a new renewal period of two years | ||
17
|
net-renews-3-yr | number of domains successfully renewed with a new renewal period of three years | ||
18
|
net-renews-4-yr | etc. | ||
19
|
net-renews-5-yr | ” “ | ||
20
|
net-renews-6-yr | ” “ | ||
21
|
net-renews-7-yr | ” “ | ||
22
|
net-renews-8-yr | ” “ | ||
23
|
net-renews-9-yr | ” “ | ||
24
|
net-renews-10-yr | ” “ | ||
25
|
transfer-gaining-successful | transfers initiated by this registrar that were ack’d by the other registrar – either by command or automatically | ||
26
|
transfer-gaining-nacked | transfers initiated by this registrar that were n’acked by the other registrar | ||
27
|
transfer-losing-successful | transfers initiated by another registrar that this registrar ack’d – either by command or automatically | ||
28
|
transfer-losing-nacked | transfers initiated by another registrar that this registrar n’acked | ||
29
|
transfer-disputed-won | number of transfer disputes in which this registrar prevailed | ||
30
|
transfer-disputed-lost | number of transfer disputes this registrar lost | ||
31
|
transfer-disputed-no decision |
number of transfer disputes involving this registrar with a split or no decision | ||
32
|
deleted-domains-grace | domains deleted within the add grace period | ||
33
|
deleted-domains-nogr ace |
domains deleted outside the add grace period | ||
34
|
restored-domains | domain names restored from redemption period | ||
35
|
restored-noreport | total number of restored names for which the registrar failed to submit a restore report |
|
|
.BIZ Agreement Appendix 5 | |
| Whois Specifications | ||
| (8 December 2006) | ||
Public Whois Specification
RFC954-Conformant Whois
As a thick registry, the standard Whois service will provide a central location for all
authoritative .biz TLD data. Registrars will be able to provide a front-end web interface to the
standard Whois service. In addition, the Registry provides its own front-end web interface to allow
user access to the Whois service.
Due to the nature of the NeuStar thick registry model, the RFC954-conformant Whois service will be
engineered to handle high transaction load and be integral to the standard suite of registry
services. The service will return a single response per domain name or nameserver query. The
RFC954-conformant Whois service will conform to established service level agreements.
The RFC954-conformant service provided by the registry will have the following features:
| • | Standard protocol accessible over port 43. | ||
| • | Consistent format (fields and formatting) for all registrars. | ||
| • | Near real-time updates, eliminating “timing” problems when modifying registry information. | ||
| • | Extensible field capability. |
Whois Service Data Elements
The RFC954-conformant service will include the following data elements:
| • | The name of the domain name registered; | ||
| • | The IP addresses of the primary nameserver and secondary nameserver(s) of the name registered; | ||
| • | The corresponding names of those nameservers; | ||
| • | The identity of the registrar; | ||
| • | The original creation date and term of the registration; | ||
| • | The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the domain name registrant; | ||
| • | The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the name registered; and | ||
| • | The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the name registered. |
Extensible-Field Capability
NeuStar gives the ability for registrars to use EPP to add customized fields to a record in the
registry database. These fields will appear in an “additional information” section of the Whois
data.
Query Control — Object Type Control
The following keywords restrict a search to specific object type:
Domain: Search only by domain objects. The input string is searched in the Name field.
Contact: Search only contact objects. The input string is searched in the ID field.
Nameserver: Search only by nameserver objects. The input string is searched in the nameserver field
or the IP address field.
Registrar: Search only registrar objects. The input string is searched in the Name field.
By default, if no object type control is specified, then the Name field of the Domain object is
searched.
Whois Output Fields
Domain Record:
A Whois query that results in domain information will return the following fields from the Domain
object and the associated data from host and contact objects. This set of data is also referred to
as the Domain Record.
Domain Name
Domain ID
Sponsoring Registrar
Sponsoring Registrar IANA ID
Domain Status
Registrant, Administrative, Technical and Billing Contact Information including
- ID
- Name
- Organization
- Address
- Geographic Location Code
- Phone Number
- Facsimile Number
- Email
Name Server(s)
Created by Registrar
Last Updated by Registrar
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date
Sponsoring Registrar
Sponsoring Registrar IANA ID
Domain Status
Registrant, Administrative, Technical and Billing Contact Information including
- ID
- Name
- Organization
- Address
- Geographic Location Code
- Phone Number
- Facsimile Number
Name Server(s)
Created by Registrar
Last Updated by Registrar
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date
Note: For domains on PendingDelete Status, the Registry’s front-end web interface will provide an
additional explanation of the status as follows:
Up to 30 days after deletion:
|
PendingDelete (Restorable) | |
More than 30 days after deletion:
|
PendingDelete (Scheduled for release) |
Nameserver Record:
Name Server ID
Name Server Name
Name Server Status
Sponsoring Registrar
Sponsoring Registrar IANA ID
Created by Registrar
Name Server Registration Date
Name Server Name
Name Server Status
Sponsoring Registrar
Sponsoring Registrar IANA ID
Created by Registrar
Name Server Registration Date
Contact Record:
A Whois query that results in contact information will return the following. This set of
information is referred to as the Contact Record.
Contact ID
Contact Name
Contact Organization
▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇ ▇▇▇▇
▇▇▇▇▇▇▇ ▇▇▇▇▇/▇▇▇▇▇▇▇▇
Contact Postal Code
Contact Geographic Location
Contact Geographic Location Code
Contact Phone Number
Contact Facsimile Number
Contact Email
Sponsoring Registrar
Sponsoring Registrar IANA ID
Contact ROID
Contact Registration Date
Contact Last Updated Date
Last Updated by Registrar
Contact Status
Created by Registrar
Contact Name
Contact Organization
▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇
▇▇▇▇▇▇▇ ▇▇▇▇
▇▇▇▇▇▇▇ ▇▇▇▇▇/▇▇▇▇▇▇▇▇
Contact Postal Code
Contact Geographic Location
Contact Geographic Location Code
Contact Phone Number
Contact Facsimile Number
Contact Email
Sponsoring Registrar
Sponsoring Registrar IANA ID
Contact ROID
Contact Registration Date
Contact Last Updated Date
Last Updated by Registrar
Contact Status
Created by Registrar
Registrar Record:
A Whois query that results in Registrar information will return the following. This set of
information is referred to as the Registrar Record.
Registrar IANA ID
Registrar Name
Registrar Address1
Registrar Address2
Registrar City
Registrar State/Province
Registrar Geographic Location
Registrar Geographic Location Code
Registrar Postal Code
Registrar Phone
Registrar Fax
Registrar Email
Registrar ROID
Registrar Name
Registrar Address1
Registrar Address2
Registrar City
Registrar State/Province
Registrar Geographic Location
Registrar Geographic Location Code
Registrar Postal Code
Registrar Phone
Registrar Fax
Registrar Email
Registrar ROID
Sample Whois Output
This section provides sample output from the Whois server for each type of Registry Object: Domain,
Contact, Nameserver, and Registrar. The output is structured as key/value pairs, which simplifies
machine-readability.
Domain Record:
Input: |
whois “domain = ▇▇▇▇▇▇▇.▇▇▇” | |||
Output: |
Domain Name | ▇▇▇▇▇▇▇.▇▇▇ | ||
| Domain ID | D618-BIZ | |||
| Sponsoring Registrar | REGISTRY REGISTRAR | |||
| Sponsoring Registrar IANA ID | 666 | |||
| Domain Status | clientDeleteProhibited | |||
| Domain Status | clientTransferProhibited | |||
| Domain Status | clientUpdateProhibited | |||
| Domain Status | serverDeleteProhibited | |||
| Domain Status | serverTransferProhibited | |||
| Domain Status | serverUpdateProhibited | |||
| Registrant ID | NEUSTAR1 | |||
| Registrant Name | NeuStar, Inc. | |||
| Registrant Organization | NeuStar, Inc. | |||
| Registrant Address1 | Loudoun Tech Center | |||
| Registrant Address2 | 45980 Center Oak Plaza | |||
| Registrant City | Sterling | |||
| Registrant State/Province | Virginia | |||
| Registrant Postal Code | ▇▇▇▇▇ | |||
| ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇▇ ▇▇▇▇▇▇ | |||
| Registrant Geographic Location Code | US | |||
| Registrant Phone Number | +1.5714345757 | |||
| Registrant Facsimile Number | +1.5714345758 | |||
| Registrant Email | ▇▇▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇ | |||
| Administrative Contact ID | NEUSTAR1 | |||
| Administrative Contact Name | NeuStar, Inc. | |||
| Administrative Contact Organization | NeuStar, Inc. | |||
| Administrative Contact Address1 | Loudoun Tech Center | |||
| Administrative Contact Address2 | 45980 Center Oak Plaza | |||
| Administrative Contact City | Sterling | |||
| Administrative Contact State/Province | Virginia | |||
| Administrative Contact Postal Code | ▇▇▇▇▇ | |||
| ▇▇▇▇▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇▇ ▇▇▇▇▇▇ | |||
| Administrative Contact Geographic Location | ||||
| Code | US | |||
| Administrative Contact Phone Number | +1.5714345757 | |||
| Administrative Contact Facsimile Number | +1.5714345758 | |||
| Administrative Contact Email | ▇▇▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇ | |||
| Billing Contact ID | NEUSTAR1 | |||
| Billing Contact Name | NeuStar, Inc. |
| Billing Contact Organization | NeuStar, Inc. | |||
| Billing ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇▇▇ ▇▇▇▇ ▇▇▇▇▇▇ | |||
| ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇ Center Oak Plaza | |||
| Billing Contact City | Sterling | |||
| Billing Contact State/Province | Virginia | |||
| Billing Contact Postal Code | ▇▇▇▇▇ | |||
| ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇▇ ▇▇▇▇▇▇ | |||
| Billing Contact Geographic Location Code | US | |||
| Billing Contact Phone Number | +1.5714345757 | |||
| Billing Contact Facsimile Number | +1.5714345758 | |||
| Billing Contact Email | ▇▇▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇ | |||
| Technical Contact ID | NEUSTAR1 | |||
| Technical Contact Name | NeuStar, Inc. | |||
| Technical Contact Organization | NeuStar, Inc. | |||
| Technical ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇▇▇ ▇▇▇▇ ▇▇▇▇▇▇ | |||
| ▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇ Center Oak Plaza | |||
| Technical Contact City | Sterling | |||
| Technical Contact State/Province | Virginia | |||
| Technical Contact Postal Code | ▇▇▇▇▇ | |||
| ▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇▇ ▇▇▇▇▇▇ | |||
| Technical Contact Geographic Location Code | US | |||
| Technical Contact Phone Number | +1.5714345757 | |||
| Technical Contact Facsimile Number | +1.5714345758 | |||
| Technical Contact Email | ▇▇▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇ | |||
| Name Server | ▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇ | |||
| Name Server | ▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇ | |||
| Name Server | ▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇ | |||
| Name Server | ▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇ | |||
| Name Server | ▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇▇ | |||
| Name Server | ▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇.▇▇ | |||
| Created by Registrar | REGISTRY REGISTRAR | |||
| Last Updated by Registrar | KSOERJADI | |||
| Domain Registration Date | Wed Nov 07 00:01:00 GMT 2001 | |||
| Domain Expiration Date | Mon Nov 06 23:59:00 GMT 2006 | |||
| Domain Last Updated Date | Thu May 25 18:32:14 GMT 2006 |
Contact Record:
Input: |
whois “contact = NEUSTAR1” | |||
Output: |
Contact ID | NEUSTAR1 | ||
| Contact Name | NeuStar, Inc. | |||
| Contact Organization | NeuStar, Inc. | |||
| ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇▇▇ ▇▇▇▇ ▇▇▇▇▇▇ | |||
| ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇ Center Oak Plaza | |||
| Contact City | Sterling | |||
| Contact State/Province | Virginia | |||
| Contact Postal Code | ▇▇▇▇▇ | |||
| ▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇▇ ▇▇▇▇▇▇ | |||
| Contact Geographic Location Code | US |
| Contact Phone Number | +1.5714345757 | |||
| Contact Facsimile Number | +1.5714345758 | |||
| Contact Email | ▇▇▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇ | |||
| Sponsoring Registrar | REGISTRY REGISTRAR | |||
| Sponsoring Registrar ID | 666 | |||
| Contact ROID | C591-BIZ | |||
| Contact Registration Date | Sun Sep 30 18:12:56 GMT 2001 | |||
| Contact Last Updated Date | Thu Jan 05 19:45:24 GMT 2006 | |||
| Last Updated by Registrar | KSOERJADI | |||
| Contact Status | ok | |||
| Created by Registrar | REGISTRY REGISTRAR |
Nameserver Record:
Input: |
whois “▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇” | |||
Output: |
||||
| Name ▇▇▇▇▇▇ ▇▇ | ▇▇▇▇▇▇▇▇-▇▇▇ | |||
| Name Server Name | ▇▇▇▇▇.▇▇▇▇▇▇▇▇.▇▇▇ | |||
| Name Server Status | ok | |||
| Sponsoring Registrar | TUCOWS INC. | |||
| Sponsoring Registrar IANA ID | 69 | |||
| Created by Registrar | TUCOWS INC. | |||
| Name Server Registration Date | Fri Feb 25 22:37:50 GMT 2005 |
Registrar Record:
Input: |
whois “registrar registry registrar” | |||
Output: |
||||
| Registrar IANA ID | REGISTRY REGISTRAR | |||
| Registrar Name | 666 | |||
| Registrar Address1 | LOUDOUN TECH CENTER | |||
| ▇▇▇▇▇▇▇▇▇ ▇▇▇▇▇▇▇▇ | ▇▇▇▇▇ CENTER OAK PLAZA | |||
| Registrar City | STERLING | |||
| Registrar State/Province | VA | |||
| Registrar Geographic Location | United States | |||
| Registrar Geographic Location Code | US | |||
| Registrar Postal Code | 20166 | |||
| Registrar Phone | +1.5714345757 | |||
| Registrar Fax | +1.5714345758 | |||
| Registrar Email | ▇▇▇▇▇▇▇@▇▇▇▇▇▇▇.▇▇▇ | |||
| Registrar ROID | R720-BIZ |
Whois Provider Data Specification
Registry Operator will provide bulk access to up-to-date data concerning domain name and nameserver
registrations maintained by Registry Operator in connection with the .biz TLD on a daily schedule,
only for purposes of providing free public query-based access to up-to-date data concerning domain
name and nameserver registrations in multiple TLDs, to a party designated from time to time in
writing by ICANN (the “Designated Recipient”). Any agreement between ICANN and a Designated
Recipient for the license of such data (a “Whois License Agreement”) will provide NeuStar with the
right to enforce the Designated Recipient’s obligations under this Appendix and the Whois License
Agreement directly against the Designated Recipient, whether through being made a party to or
third-party beneficiary of such agreement or through such other means as may be appropriate. In
addition, any Whois License Agreement will include the following provisions governing the use of
such data by the Designated Recipient:
1. The Designated Recipient shall only use the data provided by Registry Operator for the purpose
of providing free public query-based Whois access. The Designated Recipient may not use such data
for any other purpose.
2. The Designated Recipient shall use best efforts to implement any corrections to the data
provided by Registry Operator as soon as practicable.
3. The Designated Recipient must take such technical and organizational security measures as are,
at a minimum, equivalent to those implemented by Registry Operator with respect to such data.
4. Except for providing free public query-based access according to item 1 above, the Designated
Recipient shall not transfer the data to any third party for any purpose except in the event that
such third party becomes bound in the same manner as a Designated Recipient by the provisions of
this Appendix and the Whois License Agreement.
Unless otherwise agreed by the Parties, the procedures for providing access, and the specification
of the content and format of this data, will be as stated below,
A. Procedures for Providing Access
Registry Operator shall prepares (i) full data sets for one day of each week (the day to be
designated by ICANN) and (ii) incremental data sets for all seven days of each week. Full and
incremental data sets shall be up-to-date and coherent as of 1200 UTC on the day to which they
relate. Until a different day is designated by ICANN, the full data sets will be prepared for
Sundays. (Note that on the ICANN-designated day both an incremental and a full data set are
prepared.)
1. Preparation of Files Containing Data Sets. Each full and incremental data set consists of an XML
document meeting the content and format requirements of Parts B and C of this document. Once the
XML document is generated, the following preparation steps will be performed:
a. The XML document will be placed in a file named according to the following convention:
For full data sets: “wfYYMMDD” where “YYMMDD” is replaced with the date (YY=last two digits of
year; MM=number of month; DD=day; in all cases a single-digit number should be left-padded with a
zero).
For incremental data sets: “wiYYMMDD” where “YYMMDD” follows the same format.
b. Registry Operator may optionally split the document using the Unix SPLIT command (or equivalent)
to produce files no less than 1GB each (except the final file). If files are split, an MD5 file
(produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors in
case of transfer fault. Registry Operator may optionally compress the document using the Unix GZIP
command (or equivalent) to reduce the file size.
c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or above, with a key of
DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the escrow file in addition to
encrypting it.) The Data Recipient’s public key will be used for the encryption and Registry
Operator’s private key will be used for the signature. Public keys will be exchanged between
Registry Operator and the Designated Recipient by e-mail, physical delivery of floppy diskettes, or
other agreed means.
2. Transmission of Full Data Sets. Once prepared, full data sets will be provided either by the
procedures for incremental data sets described in item A (3) below or, at the option of either
Registry Operator or the Designated Recipient, by writing the full data set to DAT tape (or other
media mutually agreed by Registry Operator and the Designated Recipient) and sending it to the
Designated Recipient by expedited delivery service (such as FedEx or DHL). If sent by expedited
delivery service, the full data set will be scheduled for arrival no later than the second calendar
day following the day to which the full backup relates.
3. Transmission of Incremental Data Sets. To permit the transmission of incremental data sets,
Registry Operator shall make them available for download by the Designated Recipient by Internet
File Transfer Protocol. Incremental data sets will be made available for download no later than
2000 UTC on the day to which they relate.
4. Objects Contained in Full and Incremental Data Sets. Full data sets include one domain object
for each Registered Name within the Sponsored TLD; and nameserver, contact, and registrar objects
for each nameserver, contact, and registrar referred to in any domain object. Incremental data sets
consist of (a) those of the objects constituting a full data set that have been added or updated
since the last incremental data set and (b) notations of deletion of any objects since the last
incremental data set.
B. Format
Full and incremental data sets will be XML version 1.0, UTF-8 encoded documents conforming to the
following document type definition:
<?xml version=“1.0” encoding=“UTF-8”?>
<schema targetNamespace=“urn:NeuStar:whoisdb-1.0”
xmlns:whoisdb=“urn:NeuStar:whoisdb-1.0”
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=“▇▇▇▇://▇▇▇.▇▇.▇▇▇/▇▇▇▇/▇▇▇▇▇▇▇▇▇”
elementFormDefault=“qualified”>
<schema targetNamespace=“urn:NeuStar:whoisdb-1.0”
xmlns:whoisdb=“urn:NeuStar:whoisdb-1.0”
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=“▇▇▇▇://▇▇▇.▇▇.▇▇▇/▇▇▇▇/▇▇▇▇▇▇▇▇▇”
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 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"/>
<annotation>
<documentation>
XML Schema for WHOIS Data Escrow From NeuStar
</documentation>
</annotation>
<!—
Child Element
—>
<element name=“whois-data” 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”/>
</complexType>
<simpleType name=“tldType”>
<restriction base=“string”>
<enumeration value=“biz”/>
</restriction>
</simpleType>
<complexType name=“fullsetType”>
<sequence>
<element name=“contact” type=“contact:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“domain” type=“domain:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“host” type=“host:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“registrar” type=“whoisdb:registrarType”
minOccurs=“0” maxOccurs=“unbounded”/>
</sequence>
</complexType>
<complexType name=“partialType”>
<sequence>
<element name=“contact” type=“contact:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“domain” type=“domain:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“host” type=“host:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“registrar” type=“whoisdb:registrarType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“del-contact” type=“contact:sIDType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“del-domain” type=“domain:sNameType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“del-host” type=“host:sNameType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“del-registrar” type=“whoisdb:registrarIDType”
minOccurs=“0” maxOccurs=“unbounded”/>
</sequence>
</complexType>
<complexType name=“registrarIDType”>
<sequence>
<element name=“registrar-id” type=“eppcom:clIDType”/>
</sequence>
</complexType>
<documentation>
XML Schema for WHOIS Data Escrow From NeuStar
</documentation>
</annotation>
<!—
Child Element
—>
<element name=“whois-data” 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”/>
</complexType>
<simpleType name=“tldType”>
<restriction base=“string”>
<enumeration value=“biz”/>
</restriction>
</simpleType>
<complexType name=“fullsetType”>
<sequence>
<element name=“contact” type=“contact:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“domain” type=“domain:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“host” type=“host:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“registrar” type=“whoisdb:registrarType”
minOccurs=“0” maxOccurs=“unbounded”/>
</sequence>
</complexType>
<complexType name=“partialType”>
<sequence>
<element name=“contact” type=“contact:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“domain” type=“domain:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“host” type=“host:infDataType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“registrar” type=“whoisdb:registrarType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“del-contact” type=“contact:sIDType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“del-domain” type=“domain:sNameType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“del-host” type=“host:sNameType”
minOccurs=“0” maxOccurs=“unbounded”/>
<element name=“del-registrar” type=“whoisdb:registrarIDType”
minOccurs=“0” maxOccurs=“unbounded”/>
</sequence>
</complexType>
<complexType name=“registrarIDType”>
<sequence>
<element name=“registrar-id” type=“eppcom:clIDType”/>
</sequence>
</complexType>
<!—
Registrar Type derived from EPP Specification
—>
<complexType name=“registrarType”>
<sequence>
<element name=“roid” type=“eppcom:roidType”/>
<element name=“registrar-id” type=“eppcom:clIDType”/>
<element name=“name” type=“whoisdb:registrarNameType”/>
<element name=“address” type=“contact:addrType”/>
<element name=“referral-url” type=“whoisdb:registrarWebUrlType”
minOccurs=“0”/>
<element name=“whois-server” type=“whoisdb:registrarWebUrlType”
minOccurs=“0”/>
<element name=“iana-id” type=“whoisdb:registrarIanaIDType”/>
<element name=“contact” type=“whoisdb:registrarContactType”
maxOccurs=“5”/>
<element name=“crDate” type=“dateTime”/>
<element name=“upDate” type=“dateTime” minOccurs=“0”/>
</sequence>
</complexType>
<simpleType name=“registrarNameType”>
<restriction base=“string”>
<minLength value=“1”/>
<maxLength value=“128”/>
</restriction>
</simpleType>
<simpleType name=“registrarWebUrlType”>
<restriction base=“string”/>
</simpleType>
<simpleType name=“registrarIanaIDType”>
<restriction base=“string”/>
</simpleType>
<complexType name=“registrarContactType”>
<simpleContent>
<extension base=“eppcom:roidType”>
<attribute name=“type” use=“required”>
<simpleType>
<restriction base=“string”>
<enumeration value=“administrative”/>
<enumeration value=“billing”/>
<enumeration value=“technical”/>
</restriction>
</simpleType>
</attribute>
</extension>
</simpleContent>
</complexType>
<simpleType name=“registrarStatusType”>
<restriction base=“string”>
<enumeration value=“active”/>
<enumeration value=“suspended”/>
<enumeration value=“defunct”/>
</restriction>
</simpleType>
</schema>
Registrar Type derived from EPP Specification
—>
<complexType name=“registrarType”>
<sequence>
<element name=“roid” type=“eppcom:roidType”/>
<element name=“registrar-id” type=“eppcom:clIDType”/>
<element name=“name” type=“whoisdb:registrarNameType”/>
<element name=“address” type=“contact:addrType”/>
<element name=“referral-url” type=“whoisdb:registrarWebUrlType”
minOccurs=“0”/>
<element name=“whois-server” type=“whoisdb:registrarWebUrlType”
minOccurs=“0”/>
<element name=“iana-id” type=“whoisdb:registrarIanaIDType”/>
<element name=“contact” type=“whoisdb:registrarContactType”
maxOccurs=“5”/>
<element name=“crDate” type=“dateTime”/>
<element name=“upDate” type=“dateTime” minOccurs=“0”/>
</sequence>
</complexType>
<simpleType name=“registrarNameType”>
<restriction base=“string”>
<minLength value=“1”/>
<maxLength value=“128”/>
</restriction>
</simpleType>
<simpleType name=“registrarWebUrlType”>
<restriction base=“string”/>
</simpleType>
<simpleType name=“registrarIanaIDType”>
<restriction base=“string”/>
</simpleType>
<complexType name=“registrarContactType”>
<simpleContent>
<extension base=“eppcom:roidType”>
<attribute name=“type” use=“required”>
<simpleType>
<restriction base=“string”>
<enumeration value=“administrative”/>
<enumeration value=“billing”/>
<enumeration value=“technical”/>
</restriction>
</simpleType>
</attribute>
</extension>
</simpleContent>
</complexType>
<simpleType name=“registrarStatusType”>
<restriction base=“string”>
<enumeration value=“active”/>
<enumeration value=“suspended”/>
<enumeration value=“defunct”/>
</restriction>
</simpleType>
</schema>
Whois Data Specification – ICANN
Registry Operator will provide bulk access by ICANN to up-to-date data concerning domain name and
nameserver registrations maintained by Registry Operator in connection with the .biz TLD on a daily
schedule, only for purposes of verifying and ensuring the operational stability of Registry
Services, the DNS, and the Internet.
Unless otherwise agreed by the Parties, the procedures for providing access, and the specification
of the content and format of this data, will be as stated below.
A. Procedures for Providing Access
Upon request by ICANN, Registry Operator shall prepare a full data set for one day of each week
(the day to be designated by ICANN). Full data sets shall be up-to-date and coherent as of 1200 UTC
on the day to which they relate. Until a different day is designated by ICANN, the full data sets
will be prepared for Sundays.
1. Preparation of Files Containing Data Sets. Each full data set consists of an XML document
meeting the content and format requirements of Parts B and C of this document. Once the XML
document is generated, the following preparation steps will be performed:
a. The XML document will be placed in a file named according to the following convention:
“wfYYMMDD” where “YYMMDD” is replaced with the date (YY=last two digits of year; MM=number of
month; DD=day; in all cases a single-digit number should be left-padded with a zero).
b. Registry Operator may optionally split the document using the Unix SPLIT command (or equivalent)
to produce files no less than 1GB each (except the final file). If files are split, an .MD5 file
(produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors.
Registry Operator may optionally compress the document using the Unix GZIP command (or equivalent)
to reduce the filesize.
c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or above, with a key of
DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the escrow file in addition to
encrypting it.) An ICANN public key will be used for the encryption and Registry Operator’s private
key will be used for the signature. Public keys will be exchanged between Registry Operator and
ICANN by e-mail, physical delivery of floppy diskettes or other agreed means.
2. Transmission of Full Data Sets. Once prepared, full data sets will be provided according to
paragraph a below or, at ICANN and Registry Operator’s option, according to paragraph b below:
a. Registry Operator shall make full data sets available for download by ICANN by Internet File
Transfer Protocol (FTP) (FTP access will be password protected
and limited to prespecified IP ranges). The data sets will be made available for download beginning
no later than 2000 UTC on the day to which they relate and until the next full data set becomes
available for download.
b. Registry Operator shall write the full data set to DAT (DDS-4) tape (or other media specified by
ICANN) and sends it to ICANN by expedited delivery service (such as FedEx or DHL). The full data
set will be scheduled for arrival at ICANN no later than the second calendar day following the day
to which the data set relates.
B. Content
The full data sets will consist of four types of the objects and contents described above.
C. Format
Full data sets will be XML version 1.0, UTF-8 encoded documents conforming to the schema/document
type declaration set forth in Exhibit 2 of Appendix 1.
|
|
.BIZ Agreement Appendix 6 List of Reserved TLD Strings (8 December 2006) |
Registry Operator shall reserve names formed with the following labels from initial (i.e. other
than renewal) registration within the TLD:
A. Labels Reserved at All Levels. The following names shall be reserved at the second level and at
all other levels within the TLD at which Registry makes registrations:
ICANN-related names:
| • | aso | ||
| • | gnso | ||
| • | icann | ||
| • | internic | ||
| • | ccnso |
IANA-related names:
| • | afrinic | ||
| • | apnic | ||
| • | arin | ||
| • | example | ||
| • | gtld-servers | ||
| • | iab | ||
| • | iana | ||
| • | iana-servers | ||
| • | iesg | ||
| • | ietf | ||
| • | irtf | ||
| • | istf | ||
| • | lacnic | ||
| • | latnic | ||
| • | rfc-editor | ||
| • | ripe | ||
| • | root-servers |
B. Additional Second-Level Reservations. In addition, the following names shall be reserved at the
second level:
| • | All single-character labels. | ||
| • | All two-character labels shall be initially reserved. |
C. Tagged Domain Names. All labels with hyphens in the third and fourth character positions (e.g.,
“bq—1k2n4h4b” or “xn—ndk061n”)
D. Second-Level Reservations for Registry Operations. The following names are reserved for use in
connection with the operation of the registry for the .biz TLD:
| • | nic | ||
| • | whois | ||
| • | www |
E. Additional Reservations by Registry Operator. The following domains have been reserved by
Registry Operator:
Part A: Names staying with the Registry in the event of reassignment
| 1. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 2. | ▇▇▇.▇▇▇ | ||
| 3. | ▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 4. | ▇▇▇▇▇▇▇.▇▇▇ | ||
| 5. | ▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 6. | ▇▇▇▇▇▇▇.▇▇▇ | ||
| 7. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 8. | ▇▇▇▇▇▇▇.▇▇▇ | ||
| 9. | ▇▇▇▇▇▇▇.▇▇▇ | ||
| 10. | ▇▇▇▇▇▇▇.▇▇▇ |
| 11. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 12. | ▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 13. | ▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 14. | ▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 15. | ▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 16. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 17. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 18. | ▇▇▇▇▇.▇▇▇ | ||
| 19. | ▇▇▇▇▇▇.▇▇▇ | ||
| 20. | ▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 21. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 22. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 23. | ▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 24. | ▇▇▇.▇▇▇ | ||
| 25. | ▇▇▇▇▇▇.▇▇▇ | ||
| 26. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 27. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 28. | ▇▇▇▇▇▇▇.▇▇▇ | ||
| 29. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 30. | ▇▇▇▇▇▇.▇▇▇ | ||
| 31. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 32. | ▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 33. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 34. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 35. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 36. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 37. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 38. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 39. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ |
| 40. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 41. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 42. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 43. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 44. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 45. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 46. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 47. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 48. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 49. | ▇▇▇▇.▇▇▇ | ||
| 50. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 51. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 52. | ▇▇▇.▇▇▇ | ||
| 53. | ▇▇▇▇▇▇▇.▇▇▇ | ||
| 54. | ▇▇▇▇▇▇.▇▇▇ | ||
| 55. | ▇▇▇▇.▇▇▇ | ||
| 56. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 57. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 58. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 59. | ▇▇▇▇.▇▇▇ | ||
| 60. | ▇▇▇▇.▇▇▇ | ||
| 61. | ▇▇▇▇.▇▇▇ | ||
| 62. | ▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 63. | ▇▇▇▇▇.▇▇▇ | ||
| 64. | ▇▇▇▇▇▇▇.▇▇▇ | ||
| 65. | ▇▇▇▇.▇▇▇ | ||
| 66. | ▇▇▇.▇▇▇ | ||
| 67. | ▇▇▇▇▇.▇▇▇ | ||
| 68. | ▇▇▇.▇▇▇ |
| 69. | ▇▇▇▇.▇▇▇ | ||
| 70. | ▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 71. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 72. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 73. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 74. | ▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 75. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 76. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 77. | ▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 78. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 79. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 80. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 81. | ▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 82. | ▇▇▇▇▇.▇▇▇ | ||
| 83. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 84. | ▇▇▇▇.▇▇▇ | ||
| 85. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 86. | ▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 87. | ▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 88. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 89. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 90. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 91. | ▇▇▇▇.▇▇▇ | ||
| 92. | ▇▇▇▇.▇▇▇ | ||
| 93. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 94. | ▇▇▇▇▇▇.▇▇▇ | ||
| 95. | ▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 96. | ▇▇▇▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 97. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ |
| 98. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 99. | ▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 100. | ▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 101. | ▇▇▇▇▇▇▇.▇▇▇ | ||
| 102. | ▇▇▇▇▇.▇▇▇ | ||
| 103. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 104. | ▇▇▇.▇▇▇ | ||
| 105. | ▇▇▇▇▇▇.▇▇▇ | ||
| 106. | ▇▇▇▇▇▇▇.▇▇▇ | ||
| 107. | ▇▇▇▇.▇▇▇ | ||
| 108. | ▇▇▇▇▇▇▇▇.▇▇▇ |
Part B: Names staying with Registry Operator in the event of reassignment:
| 1. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 2. | ▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 3. | ▇▇▇-▇▇▇▇▇.▇▇▇ | ||
| 4. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 5. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ | ||
| 6. | ▇▇▇▇▇▇▇▇▇▇▇.▇▇▇ |
|
|
.BIZ Agreement Appendix 7 Functional and Performance Specifications (29 June 2007) |
Functional and Performance Specifications
These functional specifications for the Registry TLD consist of the following parts:
| 1. | Extensible Provisioning Protocol; | |
| 2. | Supported initial and renewal registration periods; | |
| 3. | Grace period policy; | |
| 4. | Nameserver functional specifications; | |
| 5. | Patch, update, and upgrade policy; and | |
| 6. | Performance Specifications |
I. Extensible Provisioning Protocol
Registry Operator shall implement the Extensible Provisioning Protocol (“EPP”) in conformance
with the Proposed Standard and Informational RFCs 3730, 3731, 3732, 3734, 3735, and 3915 published
by the Internet Engineering Task Force (“IETF”) and/or any successor standards, versions,
modifications or additions thereto as Registry Operator deems reasonably necessary.
II. Supported initial and renewal registration periods
a. Initial registrations of Registered Names (where available according to functional
specifications and other requirements) may be made in the registry for terms of up to ten years.
b. Renewal registrations of Registered Names (where available according to functional
specifications and other requirements) may be made in the registry for terms not exceed a total of
ten years.
c. Upon change of sponsorship of the registration of a Registered Name from one registrar to
another, according to Part A of the ICANN Policy on Transfer of Registrations between Registrars,
the term of registration of the Registered Name shall be extended by one year, provided that the
maximum term of the registration as of the effective date of the sponsorship change shall not
exceed ten years.
d. The change of sponsorship of registration of Registered Names from one registrar to another,
according to Part B of the ICANN Policy on Transfer of Registrations between Registrars shall not
result in the extension of the term of the registration and Registry Operator may assist in such
change of sponsorship.
III. Grace period policy
This section describes Registry Operator’s practices for operational “Grace” and “Pending”
periods, including relationships among sequential operations that occur within given time frames. A
Grace Period refers to a specified number of calendar days following a Registry operation in which
a domain action may be reversed and a credit may be issued to a registrar. Relevant registry
operations in this context are:
| • | Registration of a new domain, | ||
| • | Extension of an existing domain, | ||
| • | Auto-Renew of an existing domain; | ||
| • | Transfer of an existing domain; and | ||
| • | Deletion of an existing domain. |
Extension of a registration period is accomplished using the EPP RENEW command or by auto-renewal;
registration is accomplished using the EPP CREATE command; deletion/removal is
accomplished using the EPP DELETE command; transfer is accomplished using the EPP TRANSFER command
or, where ICANN approves a bulk transfer under Part B of the ICANN Policy on Transfer of
Registrations between Registrars, using the procedures specified in that Part. Restore is
accomplished using the EPP RENEW command.
There are five grace periods provided by Registry Operator’s Shared Registration System: Add Grace
Period, Renew/Extend Grace Period, Auto-Renew Grace Period, Transfer Grace Period, and Redemption
Grace Period.
A Pending Period refers to a specified number of calendar days following a Registry operation in
which final Registry action is deferred before the operation may be completed. Relevant Registry
operations in this context are:
| • | Transfer of an existing domain, | ||
| • | Deletion of an existing domain, and | ||
| • | Restore of a domain name in Redemption Grace Period. |
3.1 Grace Periods
3.1.1 Add Grace Period
The Add Grace Period is a specified number of calendar days following the initial registration of a
domain. The current value of the Add Grace Period for all registrars is five calendar days. If a
Delete, Renew, or Transfer operation occurs within the five calendar days, the following rules
apply:
Renew. If a domain is extended within the Add Grace Period, the account of the sponsoring Registrar
at the time of the extension will be charged for the initial add plus the number of years the
registration is extended. The expiration date of the domain is extended by the number of years, up
to a total of ten years, as specified by the registrar’s requested Renew operation.
Transfer (other than ICANN-approved bulk transfer). Transfers under the Registry-Registrar
Agreement may not occur during the Add Grace Period or at any other time within the first 60 days
after the initial registration. Enforcement is the responsibility of the Registrar sponsoring the
domain name registration and is currently enforced by the SRS.
Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the Add
Grace Period. The expiration dates of transferred registrations are not affected. The losing
Registrar’s account is charged for the initial add.
Delete. If a domain is deleted within the Add Grace Period, the sponsoring Registrar at the time of
the deletion is credited for the amount of the registration; provided, however, that Registry
Operator shall have the right to charge Registrars a fee as set forth in its Registry-Registrar
Agreement for disproportionate deletes during the Add Grace Period. The domain is deleted from the
Registry database and is immediately available for registration by any Registrar. See Section 3.2
for a description of overlapping grace period exceptions.
3.1.2 Renew Grace Period
The Renew Grace Period is a specified number of calendar days following the renewal of a domain
name registration period through an EPP Command Renew. The current value of the Renew Grace Period
is five calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the
following rules apply:
Delete. If a domain is deleted within the Renew Grace Period, the sponsoring Registrar at the time
of the deletion receives a credit of the renew fee. The deleted domain is moved to the Redemption
Grace Period (that is, to the PendingDelete status). See below for a description of overlapping
grace period exceptions.
Renew. A domain can be extended within the Renew Grace Period for up to a total of ten years. The
account of the sponsoring Registrar at the time of the
additional extension will be charged for the additional number of years the registration is
extended.
Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Renew
Grace Period, there is no credit to the losing registrar for the renewal fee. The expiration date
of the domain is extended by one year and the years added as a result of the Extend remain on the
domain name up to a total of 10 years.
Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the
Renew Grace Period. The expiration dates of transferred registrations are not affected. The losing
Registrar’s account not credited for the Renew operation.
3.1.3 Auto-Renew Grace Period
The Auto-Renew Grace Period is a specified number of calendar days following an auto-renewal. An
auto-renewal occurs if a domain name registration is not renewed by the expiration date; in this
circumstance the registration will be automatically renewed by the system the first day after the
expiration date. The current value of the Auto-Renew Grace Period is 45 calendar days. If a Delete,
Renew, or Transfer occurs within the Auto-Renew Grace Period, the following rules apply:
Delete. If a domain is deleted within the Auto-Renew Grace Period the deleted domain is moved to
the Redemption Grace Period (that is, to the PendingDelete status). See below for a description of
overlapping grace period exceptions.
Renew. A domain can be Renewed within the Auto-Renew Grace Period for up to a total of ten years.
The account of the sponsoring Registrar at the time of the additional extension will be charged for
the additional number of years the registration is extended.
Transfer (other than ICANN-approved bulk transfer). If a domain is transferred under Section 3.9 of
the Registry-Registrar Agreement within the Auto-Renew Grace Period, the losing Registrar is
credited with the Auto-Renew charge and the year added by the Auto-Renew operation is cancelled.
The expiration date of
the domain is extended by one year up to a total maximum of ten by virtue of the transfer and the
gaining Registrar is charged for that additional year, even in cases where a full year is not added
because of the 10-year maximum limitation.
Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the
Auto-Renew Grace Period. The expiration dates of transferred registrations are not affected. The
losing Registrar’s account is not credited for the Auto-Renew.
3.1.4 Transfer Grace Period
The Transfer Grace Period is a specified number of calendar days following the transfer of a
domain. The current value of the Transfer Grace Period is five calendar days. If a Delete, Extend,
or Transfer occurs within that five calendar days, the following rules apply:
Delete. If a domain is deleted within the Transfer Grace Period, the sponsoring Registrar at the
time of the deletion receives a credit of the transfer fee. The deleted domain is moved to the
Redemption Grace Period (that is, to the PendingDelete status). See below for a description of
overlapping grace period exceptions.
Renew. If a domain is extended within the Transfer Grace Period, there is no credit for the
transfer. The Registrar’s account will be charged for the number of years the registration is
extended. The expiration date of the domain is extended by the number of years, up to a maximum of
ten years, as specified by the registrar’s requested Extend operation.
Transfer (other than ICANN-approved bulk transfer). If a domain is transferred within the Transfer
Grace Period, there is no credit. The expiration date of the domain is extended by one year up to a
maximum term of ten years.
Bulk Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made during the
Transfer Grace Period. The expiration dates of transferred registrations are not affected. The
losing Registrar’s account is charged for the Transfer operation that occurred prior to the Bulk
Transfer.
3.1.5 Overlapping Grace Periods
If an operation is performed that falls into more that one grace period, the actions appropriate
for each grace period apply (with some exceptions as noted below).
| • | If a domain is deleted within the Add Grace Period and the Renew Grace Period, then the Registrar is credited the registration and renew amounts, taking into account the number of years for which the registration and renew were done. The domain is deleted from the Registry database and is immediately available for registration by any Registrar. | ||
| • | If a domain is auto-renewed, then extended, and then deleted within the Renew Grace Period, the registrar will be credited for the Auto-Renew and the number of years for the extension. The years that were added to the Registered Name’s expiration as a result of the auto-renewal and extension are removed.The deleted Registered Name is moved to the Redemption Grace Period (that is, to the PendingDelete status). |
Overlap Exception
| • | If a domain is deleted within one or several Transfer Grace Periods, then only the current sponsoring Registrar is credited for the transfer amount. For example if a domain is transferred from Registrar A to Registrar B and then to Registrar C and finally deleted by Registrar C within the Transfer Grace Period of the first, second and third transfers, then only the last transfer is credited to Registrar C. | ||
| • | If a domain is extended (through the EPP command “Renew”) within the Transfer Grace Period, then the current Registrar’s account is charged for the number of years the registration is extended. |
Note: If several billable operations, including transfers, are performed on a domain and the domain
is deleted within the grace periods of each of those
operations, only those operations that were performed after the latest transfer, including the
latest transfer, are credited to the current Registrar.
3.1.7 Redemption Grace Period
Overview
The Redemption Grace Period Service allows registrars to restore Registered Names that were
unintentionally deleted and are still within a thirty-day Redemption Grace Period (RGP). The RGP
Service cover all names deleted by registrars, with the exception of those names deleted in the Add
Grace Period.
The RGP Service may be implemented in two stages. Stage 1 as described in the following allows
original registrars to restore unintentionally deleted registrations. In the future, ICANN and
Registry Operator will discuss implementation of Stage 2, with the goal, if feasible, of allowing
registrants to choose which registrar will restore their deleted name(s).
Implementation
The .biz Registry RGP is a fully automated and EPP-compliant implementation. Only statuses defined
in the current EPP specifications will be used. As such all domains slated for deletion will remain
in PendingDelete status for 35 days or until they are restored.
PendingDelete Status:
All domains deleted outside the Add Grace Period will be placed on PendingDelete status for a total
of 35 days, after which time the names will be purged from the Registry database and made available
again for registration.
During this PendingDelete timeframe, domain names can only be restored during the first 30 days,
and cannot be otherwise modified. The only action allowed by the original registrar is the
restoration of the domain name.
Note: BULK TRANSFER operations are allowed within the 30-day RGP provided that such transfer is in
accordance with the Registry-Registrar Agreement. The gaining registrar in any ICANN-approved bulk
transfer assumes the role of the
deleting registrar with regards to any name in the PendingDelete status sponsored by the losing
registrar at the time of transfer.
Note: TRANSFER or modification requests are not allowed during the RGP.
Upon being placed in PendingDelete status, domain names will be immediately removed from the DNS,
but will remain in the Whois with a notation about their availability of being restored. (See
Appendix 5 for further details).
At the conclusion of the 30-day RGP, the domain will remain on PendingDelete for an additional five
days. During this time, the domain cannot be restored, modified, deleted, or transferred. At the
conclusion of this five-day period, the domain will be purged from the Registry database and hence
available for re-registration.
Restore Command:
The implementation of the Redemption Grace Period Service involves one command.
RESTORE Command: Registrars may restore names by using the existing EPP Renew command. In addition,
EPP extensions will be used to capture the additional required reporting information, see below. A
successful restore command will terminate the PendingDelete status, remove the deleted status
attribute from the registration and return the registered name to the same state it was in
immediately prior to the delete request.
If the registered name is past its expiration date at the time it is restored, then, following the
restore, its registration term will be extended by the minimum term of years necessary to bring it
current. The registrar will first be debited for the restoration and following for the renewal
term.
There is no Restore Grace Period.
Appropriate Use of the Restore Capability
Registrars may only RESTORE Registered Names in order to correct unintentional deletions caused by
registrant, registrar, or registry mistake (or as required by operation of the UDRP or other
applicable dispute resolution policy in order to implement a court, arbitral tribunal or
Administrative Panel decision).
Restoring Registered Names in order to assume the rights to use or sell them will be considered an
abuse of the system and will give Registry Operator the ability to delete those impacted domain
names or terminate the Registry-Registrar Agreement.
Registrar Reporting Requirement
In order to facilitate verification of registrar compliance with the intended purpose of the
Redemption Grace Period Service, Registrars are required to submit a “Registrar Restore Report” to
the Registry Operator.
The reports will be generated as set forth by the Registry Operator through the restore command
(EPP extensions) and in accordance with the below:
The following data shall be provided by the Registry Operator:
| • | WHOIS data for deleted name, as it existed prior to deletion | ||
| • | WHOIS data for deleted name, as it existed at the time of report submission | ||
| • | Exact date and time of deletion | ||
| • | Exact date and time of restore |
The following data shall be submitted by the registrar as part of the restore command. Failure to
provide all of the following data at the time the restore command is submitted will result in a
failure to restore the domain name.
| • | Written explanation and corresponding reason code as to why registered name was restored (e.g., registrant mistake, registrar mistake, registry mistake, dispute resolution, etc.) |
| • | Written statement affirming that Registrar has not restored the .BIZ domain name in question in order to assume the rights to use or sell the name for itself or for any third party (unless the name was restored as required to give effect to an order or decision from a court, arbitral tribunal or Administrative Panel – in such cases a copy of the order should be provided separately to the Registry Operator by no later than five (5) business days following the restore). | ||
| • | Written statement affirming that information in report is factually accurate to the best of the Registrar’s knowledge, and that the registrar acknowledges that intentionally supplying false information in the Restore Report shall constitute an incurable material breach of the Registry-Registrar Agreement and may result in the deletion of the impacted domain name(s). |
The registry will maintain (for two years) copies of all Restore commands, as well as provide ICANN
with copies of such reports if requested. Further, the registry will include in its monthly report
to ICANN the number of Restore Reports received (see Appendix 4).
Registry Transparency Requirement – Registry Reports
The Registry Operator will provide comprehensive, regularly updated lists of names with a
PendingDelete status to all Registrars via an FTP or SCP mechanism; these lists will include
corresponding dates of deletion. These reports will only include names in the last five days of the
PendingDelete status.
Registry Fees for Restoring Deleted Names
The registry shall be permitted to charge a fee for restoring a deleted name. The Redemption Grace
Period Service fee is separate from, and in addition to, the ordinary charges for registration term
extensions.
IV. Nameserver functional specifications
Nameserver operations for the Registry TLD shall comply with RFCs 1034, 1035, and 2182.
V. Patch, update, and upgrade policy
Registry Operator may issue periodic patches, updates or upgrades to the Software, EPP or APIs
(“Licensed Product”) licensed under the Registry- Registrar Agreement (the “Agreement”) that will
enhance functionality or otherwise improve the Shared Registration System under the Agreement. For
the
purposes of this Part 5 of Appendix 7, the following terms have the associated meanings set forth
herein.
1. A “Patch” means minor modifications to the Licensed Product made by Registry Operator during the
performance of error correction services. A Patch does not constitute a Version.
2. An “Update” means a new release of the Licensed Product which may contain error corrections,
minor enhancements, and, in certain circumstances, major enhancements, and which is indicated by a
change in the digit to right of the decimal point in the version number of the Licensed Product.
3. An “Upgrade” means a new release of the Licensed Product which involves the addition of
substantial or substantially enhanced functionality and which is indicated by a change in the digit
to the left of the decimal point in the version of the Licensed Product.
4. A “Version” means the Licensed Product identified by any single version number. Each Update and
Upgrade causes a change in version.
* Patches do not require corresponding changes to client applications developed, implemented, and
maintained by each registrar.
* Updates may require changes to client applications by each registrar in order to take advantage
of the new features and/or capabilities and continue to have access to the Shared Registration
System.
* Upgrades require changes to client applications by each registrar in order to take advantage of
the new features and/or capabilities and continue to have access to the Shared Registration System.
Registry Operator, in its sole discretion, will deploy Patches during scheduled and announced
Shared Registration System maintenance periods.
For Updates and Upgrades, Registry Operator will give each registrar notice prior to deploying the
Updates and Upgrades into the production environment. The notice shall be at least ninety (90)
days. Such notice will include an initial notice before deploying the Update that requires changes
to client applications or the Upgrade into the Operational Test and Evaluation (“OT&E”) environment
to which all registrars have access. Registry Operator will maintain the Update or Upgrade in the OT&E
environment for at least thirty (30) days, to allow each registrar the opportunity to modify its
client applications and complete testing, before implementing the new code in the production
environment. This notice period shall not apply in the event Registry Operator’s system is subject
to the imminent threat of a failure or a material security threat, the
discovery of a major security vulnerability, or a Denial of Service (DoS) attack where the Registry
Operator’s systems are rendered inaccessible by being subject to:
| i) | excessive levels of data traffic | |
| ii) | unauthorized traffic | |
| iii) | data traffic not conforming to the protocols used by the Registry |
VI. Performance Specifications
1. Introduction. The attached Performance Specification Matrix (“Matrix”) provides a list of
performance specifications as they apply to the three Core Services provided by the Registry — SRS,
Nameserver, and Whois services.
2. Definition. Capitalized terms used herein and not otherwise defined shall have the meaning
ascribed to them in the Registry Agreement.
2.1 “Core Internet Service Failure” refers to an extraordinary and identifiable event beyond the
control of Registry Operator affecting the Internet services to be measured pursuant to Section 3.6
of this Appendix 7. Such events include but are not limited to congestion collapse, partitioning,
power grid failures, and routing failures.
2.2 “Core Services” refers to the three core services provided by the Registry — SRS, Nameserver,
and Whois Services.
2.3 “Performance Specification” refers to the specific committed performance service levels as
specified herein.
2.4 “Performance Specification Priority” refers to the Registry’s rating system for Performance
Specifications. Some Performance Specifications are more critical to the operations of the Registry
than others. Each of the Performance
Specifications is rated as C1 — mission critical, C2 — mission important, C3 — mission beneficial,
or C4 — mission maintenance.
2.5 “Registrar Community” refers to all of the ICANN-Accredited Registrars who have executed
Registry-Registrar Agreements with Registry Operator for the Registry TLD.
2.6 “SRS” refers to the Shared Registration System; the service that the Registry provides to the
Registrar Community. Specifically, it refers to the ability of Registrars to add, modify, and
delete information associated with domain names, nameserver, contacts, and registrar profile
information. This service is provided by systems and software maintained in coactive redundant data
centers. The service is available to approved Registrars via an Internet connection.
2.7 “Nameserver” refers to the nameserver function of the Registry and the nameservers that resolve
DNS queries from Internet users. This service is performed by multiple nameserver sites that host
DNS resource records. The customers of the nameserver service are users of the Internet. The
nameservers receive a DNS query, resolve it to the appropriate address, and provide a response.
2.8 “Service Level Measurement Period” refers to the period of time for which a Performance
Specification is measured. Monthly periods are based on calendar months, quarterly periods are
based on calendar quarters, and annual periods are based on calendar years.
2.9 “Whois” refers to the Registry’s Whois service. The Registry will provide contact information
related to registered domain names and nameserver through a Whois service. Any person with access
to the Internet can query the Registry’s Whois service directly (via the Registry website) or
through a Registrar.
3. Performance Specifications. Registry Operator shall use commercially reasonable efforts to
provide Registry Services for the Registry TLD. The Performance Specifications defined below
establish the basis for the Service Level Exception Credits (“SLE Credits”) provided for in
Appendix 10 to this Registry Agreement.
3.1 Service Availability. Service Availability is defined as the time, in minutes, that the
Registry’s Core Services are responding to its users. Service is unavailable when a service listed
in the Matrix is unavailable to all users, that is, when no user can initiate a session with or
receive a response from the Registry (“Unavailability”). Service Availability is a C1 priority
level.
3.1.1 Service Availability is measured as follows:
Service Availability % = {[(TM — POM) — UOM] / (TM — POM)}*100 where:
TM = Total Minutes in the Service Level Measurement Period (#days*24 hours*60 minutes)
POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages during
the Service Level Measurement Period)
UOM = Unplanned Outage Minutes (Difference between the total number of minutes of Unavailability
during the Service Level Measurement Period minus POM).
Upon written request, and at the sole expense of the requesting Registrar(s), Registry Operator
will retain an independent third party (to be selected by Registry Operator with the consent of the
Registrar(s) to perform an independent calculation of the UOM). The frequency of this audit will be
no more than once yearly during the term of the agreement between Registry Operator and the
Registrar.
This calculation is performed and the results reported for each calendar month for SRS and Whois
availability and for each calendar year for Nameserver availability. Results will be reported to
the Registrar Community via e-mail and to ICANN according to Appendix 4.
3.1.2 Service Availability—SRS = 99.9% per calendar month. Service Availability as it applies to
the SRS refers to the ability of the SRS to respond to Registrars that access and use the SRS
through the EPP protocol. SRS Unavailability will be logged with the Registry Operator as Unplanned
Outage Minutes. The committed Service Availability for SRS is 99.9% and the Service Level
Measurement Period is monthly.
3.1.3 Service Availability—Nameserver = 99.999% per calendar year. Service Availability as it
applies to the Nameserver refers to the ability of the Nameserver to resolve a DNS query from an
Internet user. Nameserver Unavailability will be logged with the Registry Operator as Unplanned
Outage Minutes. The committed Service Availability for Nameserver is 99.999% and the Service Level
Measurement Period is annually.
3.1.4 Service Availability—Whois = 99.95% per calendar month. Service Availability as it applies to
Whois refers to the ability of all users to access and use the Registry’s Whois service. Whois
Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed
Service Availability for Whois is 99.95% and the Service Level Measurement Period is monthly.
3.2 Planned Outage. High volume data centers like the Registry require downtime for regular
maintenance. Allowing for regular maintenance (“Planned Outage”) ensures a high level of service
for the Registry. Planned Outage Performance Specifications are a C4 priority level.
3.2.1 Planned Outage Duration. The Planned Outage Duration defines the maximum allowable time, in
hours and minutes, that the Registry Operator is allowed to take the Registry Services out of
service for regular maintenance. Planned Outages are planned in advance and the Registrar Community
is provided warning ahead of time. This Performance Specification, where applicable, has a monthly
Service Level Measurement Period. The Planned Outage Duration for the Core Services is as follows:
(i) Planned Outage Duration — SRS = 8 hours (480 minutes) per month;
(ii) Planned Outage Duration — Nameserver = (no planned outages allowed); and
(iii) Planned Outage Duration — Whois = 8 hours (480 minutes) per month.
3.2.2 Planned Outage Timeframe. The Planned Outage Timeframe defines the hours and days in which
the Planned Outage can occur. The Planned Outage Timeframe for the Core Services is as follows:
(i) Planned Outage Timeframe — SRS = 0600-1400 UTC Sunday;
(ii) Planned Outage Timeframe — Nameserver = (no planned outages allowed); and
(iii) Planned Outage Timeframe — Whois = 0600-1400 UTC Sunday.
3.2.3 Planned Outage Notification. The Registry Operator must notify all of its Registrars of any
Planned Outage. The Planned Outage Notification Performance Specification defines the number of
days prior to a Planned Outage that the Registry Operator must notify its Registrars. The Planned
Outage Notification for the Core Services is as follows:
(i) Planned Outage Timeframe — SRS = 3 days;
(ii) Planned Outage Timeframe — Nameserver = (no planned outages allowed); and
(iii) Planned Outage Timeframe — Whois = 3 days.
3.3 Extended Planned Outage. In some cases such as software upgrades and platform replacements an
extended maintenance timeframe is required. Extended Planned Outages will be less frequent than
regular Planned Outages but their duration will be longer. Extended Planned Outage Performance
Specifications are a C4 priority level.
3.3.1 Extended Planned Outage Duration. The Extended Planned Outage Duration defines the maximum
allowable time, in hours and minutes, that the Registry Operator is allowed to take the Registry
Services out of service for extended maintenance. Extended Planned Outages are planned in advance
and the Registrar Community is provided warning ahead of time. Extended Planned Outage periods are
in addition to any Planned Outages during any Service Level Measurement Period. This Performance
Specification, where applicable, has a Service Level Measurement Period based on a calendar
quarter. The Extended Planned Outage Duration for the Core Services is as follows:
(i) Extended Planned Outage Duration — SRS = 18 hours (1080 minutes) per calendar quarter;
(ii) Extended Planned Outage Duration — Nameserver = (no planned outages allowed); and
(iii) Extended Planned Outage Duration — Whois = 18 hours (1080 minutes) per calendar quarter.
3.3.2 Extended Planned Outage Timeframe. The Extended Planned Outage Timeframe defines the hours
and days in which the Extended Planned Outage can occur. The Extended Planned Outage Timeframe for
the Core Services is as follows:
(i) Extended Planned Outage Timeframe — SRS = 0600 — 0000 UTC Saturday or Sunday;
(ii) Extended Planned Outage Timeframe — Nameserver = (no planned outages allowed); and
(iii) Extended Planned Outage Timeframe — Whois = 0600 — 0000 UTC Saturday or Sunday.
3.3.3 Extended Planned Outage Notification. The Registry Operator must notify all of its Registrars
of any Extended Planned Outage. The Extended Planned Outage Notification Performance Specification
defines the number of days prior to an Extended Planned Outage that the Registry Operator must
notify its Registrars. The Extended Planned Outage Notification for the Core Services is as
follows:
(i) Extended Planned Outage Timeframe — SRS = 4 weeks;
(ii) Extended Planned Outage Timeframe — Nameserver =(no planned outages allowed); and
(iii) Extended Planned Outage Timeframe — Whois = 4 weeks.
3.4 Processing Time. Processing Time is an important measurement of transaction-based services like
the Registry. The first three Performance Specifications, Service Availability, Planned Outages and
Extended Planned Outages, measure the amount of time that the service is available to its users.
Processing Time measures the quality of that service.
Processing Time refers to the time that the Registry Operator receives a request and sends a
response to that request. Since each of the Registry Services has a unique function the Performance
Specifications for Processing Time are unique
to each of the Registry Services.
For example, a Performance Specification for the Nameserver is
not applicable to the SRS and Whois, etc. Processing Time Performance Specifications are a C2
priority level.
Processing Time Performance Specifications have a monthly Service Level Measurement Period and will
be reported on a monthly basis. The Registry Operator will log the processing time for all of the
related transactions, measured from the time it receives the request to the time that it returns a
response.
3.4.1 Processing Time—Add, Modify, Delete = 3 seconds for 95%.
(i) Processing Time — Add, Modify, and Delete is applicable to the SRS as accessed through the EPP
protocol. It measures the processing time for add, modify, and delete transactions associated with
domain names, nameservers, contacts, and registrar profile information.
(ii) The Performance Specification is 3 seconds for 95% of the transactions processed. That is, 95%
of the transactions will take 3 seconds or less from the time the Registry Operator receives the
request to the time it provides a response.
3.4.2 Processing Time—Query Domain = 1.5 seconds for 95%.
(i) Processing Time — Query Domain is applicable to the SRS as accessed through the EPP protocol.
It measures the processing time for an availability query of a specific domain name.
(ii) The performance specification is 1.5 seconds for 95% of the transactions. That is, 95% of the
transactions will take 1.5 seconds or less from the time the Registry Operator receives the query
to the time it provides a response as to the domain name’s availability.
3.4.3 Processing Time—Whois Query = 1.5 seconds for 95%.
(i) Processing Time — Whois Query is only applicable to the Whois. It measures the processing time
for a Whois Query.
(ii) The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the
transactions will take 1.5 seconds or less from the time the Whois receives a query to the time it
responds.
3.4.4 Processing Time—Nameserver Resolution = 1.5 seconds for 95%.
(i) Processing Time — Nameserver Resolution is only applicable to the Nameserver. It measures the
processing time for a DNS query.
(ii) The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the
transactions will take 1.5 seconds or less from the time Nameserver receives the DNS query to the
time it provides a response.
3.5 Update Frequency. There are two important elements of the Registry that are updated frequently
and are used by the general public; Nameserver and Whois. Registrars generate these updates through
the SRS. The SRS then updates the Nameserver and the Whois. These will be done on a batch basis.
Update Frequency Performance Specifications are a C3 priority level.
The committed Performance Specification with regard to Update Frequency for both the Nameserver and
the Whois is 15 minutes for 95% of the transactions. That is, 95% of the updates to the Nameserver
and Whois will be effectuated within 15 minutes. This is measured from the time that the registry
confirms the update to the registrar to the time the update appears in the Nameserver and Whois.
Update Frequency Performance Specifications have a monthly Service Level Measurement Period and
will be reported on a monthly basis.
3.5.1 Update Frequency—Nameserver = 15 minutes for 95%.
3.5.2 Update Frequency—Whois = 15 minutes for 95%.
3.6 Cross-Network Nameserver Performance Requirements. Nameserver round-trip-time and packet loss
from the Internet are important elements of the quality of service provided by the Registry
Operator. These characteristics, however, are affected by Internet performance and therefore cannot
be closely controlled by Registry Operator. Accordingly, these requirements are not matters subject
to Service Level Exceptions and credits under the Service Level Agreement (Appendix 10).
The committed Performance Specification for cross-network nameserver performance is a measured
round-trip time of under 300 ms and measured packet loss of under 10%. Cross-network nameserver
performance
measurements will be conducted by ICANN at times of its choosing, in the following manner:
3.6.1 The measurements will be conducted by sending strings of DNS request packets from each of
four measuring locations to each of the .biz nameservers and observing the responses from the .biz
nameservers. (These strings of requests and responses are referred to as a “CNNP Test”.) The
measuring locations will be four root nameserver locations (on the US East Coast, US West Coast,
Asia, and Europe).
3.6.2 Each string of request packets will consist of 100 UDP packets at 10 second intervals
requesting ns records for arbitrarily selected .biz second-level domains, preselected to ensure
that the names exist in the Registry TLD and are resolvable. The packet loss (i.e. the percentage
of response packets not received) and the average round-trip time for response packets received
will be noted.
3.6.3 To meet the packet loss and round-trip-time requirements for a particular CNNP Test, all
three of the following must be true:
3.6.3.1 The round-trip time and packet loss from each measurement location to at least one .biz
nameserver must not exceed the required values.
3.6.3.2 The round-trip time to each of 75% of the .biz nameservers from at least one of the
measurement locations must not exceed the required value.
3.6.3.3 The packet loss to each of the .biz nameservers from at least one of the measurement
locations must not exceed the required value.
3.6.4 Any failing CNNP Test result obtained during an identified Core Internet Service Failure
shall not be considered.
3.6.5 To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying
times (i.e. at different times of the day, as well as on different days of the week). Registry
Operator will be deemed to have failed to meet the cross-network nameserver performance requirement
only if the .biz nameservers persistently fail (see Section 3.6.3 above) the CNNP Tests with no
less than three consecutive failed CNNP Tests to be considered to have persistently failed.
3.6.6 In the event of persistent failure of the CNNP Tests, ICANN will give Registry Operator
written notice of the failures (with backup data) and Registry Operator will have sixty days to
cure the failure.
3.6.7 If, following that opportunity to cure, the .biz nameservers continue to persistently fail
CNNP Tests and Registry Operator fails to resolve the problem after thirty days notice of the
continuing failures, Registry Operator will be deemed not to have met its obligations under the
Registry Agreement.
3.6.8 Sixty days prior to the commencement of testing under this provision, ICANN will provide
Registry Operator with the opportunity to evaluate the testing tools and procedures to be used by
ICANN. In the event that Registry Operator does not approve of such tools and procedures, ICANN
will work directly with Registry Operator to make necessary modifications.
4. Responsibilities of the Parties.
4.1 Except in the case of nameserver performance measurements, Registry Operator will perform
monitoring from internally located systems as a means to verify that the availability and
performance measurements in this document are being met.
4.2 The Registry Operator will provide the Whois Service as specified in Appendix 5.
4.3 The Registry Operator will use commercially reasonable efforts to restore the critical systems
of the Core Services within 24 hours after the termination of a force majeure event and restore
full system functionality within 48 hours after the termination of a force majeure event. Outages
due to a force majeure will not be considered Service Unavailability.
5. Miscellaneous.
5.1 This Appendix is not intended to replace any term or condition in the Registry Agreement.
6. Performance Specifications
PERFORMANCE SPECIFICATION MATRIX
| Performance Specification Description | SRS | Nameserver | Whois | |||||
1
|
Service Availability | 99.9% per calendar month | 99.999% per calendar year | 99.95% per calendar month | ||||
2
|
Processing Time–Add, Modify, Delete | 3 sec for 95% | NA | NA | ||||
3
|
Processing Time–Query Domain | 1.5 sec for 95% | NA | NA | ||||
4
|
Processing Time–Whois | NA | NA | 1.5 sec for 95% | ||||
5
|
Processing Time–Nameserver Resolution | NA | 1.5 sec for 95% | NA | ||||
6
|
Update Frequency | NA | 15 min for 95% | 15 min for 95% | ||||
7
|
Planned Outage–Duration | 8 hrs per calendar month | not allowed | 8 hrs per calendar month |
| Performance Specification Description | SRS | Nameserver | Whois | |||||
8
|
Planned Outage–Timeframe | 0600 - 1400 UTC Sun | not allowed | 0600 - 1400 UTC Sun | ||||
9
|
Planned Outage–Notification | 3 days | not allowed | 3 days | ||||
10
|
Extended Planned Outage–Duration | 18 hrs per calendar quarter | not allowed | 18 hrs per calendar quarter | ||||
11
|
Extended Planned Outage–Timeframe | 0600 - 0000 UTC Sat or Sun | not allowed | 0600 - 0000 UTC Sat or Sun | ||||
12
|
Extended Planned Outage–Notification | 28 days | not allowed | 28 days | ||||
13
|
Cross-Network Nameserver Performance | NA | 300 ms RTT and 10% packet loss | NA |
7. Additional Services
7.1 Bulk Transfer After Partial Portfolio Acquisition.
Bulk Transfer After Partial Portfolio Acquisition (BTAPPA) is a registry service available to
consenting registrars in the circumstance where one ICANN-accredited registrar purchases, by means
of a stock or asset purchase, merger or similar transaction, a portion but not all, of another
ICANN-accredited registrar’s domain name portfolio in the .BIZ top-level domain.
At least fifteen days before completing a BTAPPA, the losing registrar must provide to all domain
name registrants for names involved in the bulk transfer, written notice of the bulk change of
sponsorship. The notice must include an explanation of how the Whois record will change after the
bulk transfer occurs, and customer support and technical contact information of the gaining
registrar.
If a domain is transferred under the BTAPPA service during any applicable grace period as described
in Section 3 above, there is no credit. The expiration dates of transferred registrations are not
affected.
Domain names in the following statuses at the time of the Transfer Request will not be transferred
in a BTAPPA: “pending transfer”, “redemption grace period (RGP)”, or “pending delete”. Domain
names that are within the auto-renew grace window are subject to bulk transfer, but NeuStar may
decline to provide a credit
for those names deleted after the bulk transfer, but prior to the expiration of the auto-renew
grace window.
NeuStar has discretion to reject a BTAPPA request if there is reasonable evidence that a transfer
under BTAPPA is being requested in order to avoid fees otherwise due to NeuStar or ICANN, or if a
registrar with common ownership or management or both has already requested BTAPPA service within
the preceding six-month period.
In the event that one or more ICANN-accredited Registrars participate in the BTAPPA service, each
such Registrar shall be required to agree to the pricing, terms and conditions set forth in
Appendix 7, Exhibit A.
|
|
.BIZ Agreement Appendix 8 Registry-Registrar Agreement (8 December 2006) |
Registry-Registrar Agreement
This Registry-Registrar Agreement (the “Agreement”) is between NeuStar, Inc., a Delaware
corporation, with its principal place of business located at Loudoun Tech Center, ▇▇▇▇▇ ▇▇▇▇▇▇ ▇▇▇
▇▇▇▇▇, ▇▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇ (“Registry Operator”), and [Registrar’s name], a [jurisdiction and type
of organization], with its principal place of business located at [Registrar’s
location] (“Registrar”).
WHEREAS, Registry Operator has entered a Registry Agreement with the Internet Corporation for
Assigned Names and Numbers to operate a shared registration system, TLD nameservers, and other
equipment for the .biz top-level domain;
WHEREAS, multiple registrars will provide Internet domain name registration services within the
..biz top-level domain;
WHEREAS, Registrar wishes to act as a registrar for domain names within the .biz top-level domain.
NOW, THEREFORE, for and in consideration of the mutual promises, benefits and covenants contained
herein and for other good and valuable consideration, the receipt, adequacy and sufficiency of
which are hereby acknowledged, Registry Operator and Registrar, intending to be legally bound,
hereby agree as follows:
1. DEFINITIONS
1.1. The “APIs” are the application program interfaces by which Registrar may interact, through the
EPP, with the Registry System.
1.2. “Confidential Information” means all information and materials, including, without limitation,
computer software, data, information, databases, protocols, reference implementation and
documentation, and functional and interface specifications, provided by the Disclosing Party to the
Receiving Party under this Agreement and marked or otherwise identified as Confidential, provided
that if a communication is oral, the Disclosing Party will notify the Receiving Party in writing
within 15 days of the disclosure of its confidentiality.
1.3. “DNS” means the Internet domain name system.
1.4. The “Effective Date” shall be the date on which this Agreement is first executed by both
parties.
1.5. “EPP” means the extensible provisioning protocol, which is the protocol used by the Registry
System.
1.6. “ICANN” means the Internet Corporation for Assigned Names and Numbers.
1.7. “Personal Data” refers to data about any identified or identifiable natural person.
1.8. “Registered Name” refers to a domain name within the domain of the Registry TLD, whether
consisting of two or more (e.g., ▇▇▇▇.▇▇▇▇▇.▇▇▇▇) levels, about which Registry Operator or an
affiliate engaged in providing Registry Services maintains data in a Registry Database, arranges
for such maintenance, or derives revenue from such maintenance. A name in a Registry Database may
be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but
inactive name).
1.9. “Registered Name Holder” means the holder of a Registered Name.
1.10. “Registry Agreement” means the Registry Agreement between Registry Operator and ICANN dated
[date of Registry Agreement] for the operation of the Registry TLD, as the same may be amended from
time to time.
1.11. “Registry Database” means a database comprised of data about one or more DNS domain names
within the domain of the Registry TLD that is used to generate either DNS resource records that are
published authoritatively or responses to domain-name availability lookup requests or Whois
queries, for some or all of those names.
1.12. “Registry TLD” means the .biz TLD.
1.13. “Registry Services” Registry Services are, for purposes of this Agreement, defined as the
following: (a) those services that are both (i) operations of the registry critical to the
following tasks: the receipt of data from registrars concerning registrations of domain names and
name servers; provision to registrars of status information relating to the zone servers for the
TLD; dissemination of TLD zone files; operation of the registry zone servers; and dissemination of
contact and other information concerning domain name server registrations in the TLD as required by
this Agreement; and (ii) provided by the Registry Operator for the .biz registry as of the
effective date of the Registry Agreement; (b) other products or services that the Registry Operator
is required to provide because of the establishment of a Consensus Policy (as defined in the
Registry Agreement); (c) any other products or services that only a registry operator is capable of
providing, by reason of its designation as the registry operator; and (d) material changes to any
Registry Service within the scope of (a), (b) or (c) above.
1.14. The “Registry System” means the registry system operated by Registry Operator for Registered
Names in the Registry TLD.
1.15. The “Registry Tool Kit” shall mean the Tool Kit set forth in Exhibit A.
1.16. “Term” means the term of this Agreement, as set forth in Subsection 8.1.
1.17. A “TLD” means a top-level domain of the DNS.
Other terms used in this Agreement as defined terms shall have the meanings ascribed to them in the
context in which they are defined.
2. OBLIGATIONS OF REGISTRY OPERATOR
2.1. Access to Registry System. Throughout the term of this Agreement, Registry Operator shall
provide Registrar with access as a registrar to the Registry System that Registry Operator operates
according to its arrangements with ICANN. Nothing in this Agreement entitles Registrar to enforce
any agreement between Registry Operator and ICANN.
2.2. Maintenance of Registrations Sponsored by Registrar. Subject to the provisions of this
Agreement, ICANN requirements, and Registry requirements authorized by ICANN, Registry Operator
shall maintain the registrations of Registered Names sponsored by Registrar in the Registry System
during the term for which Registrar has paid the fees required by Subsection 4.1.
2.3. Provision of Tool Kit; License.
2.3.1. Registry Tool Kit. No later than three business days after the
Effective Date, Registry Operator shall provide to Registrar a copy (or hyperlink
to a copy which can be downloaded) of the Registry Tool Kit, which shall provide
sufficient technical specifications to allow Registrar to interface with the
Registry System and employ its features that are available to Registrars.
2.3.2. License. Subject to the terms and conditions of this Agreement,
Registry Operator hereby grants Registrar and Registrar accepts a non-exclusive,
nontransferable, worldwide
limited license to use for the term and purposes of this Agreement the EPP, APIs
and any reference client software included in the Registry Tool Kit, as well as
updates and redesigns thereof, for providing domain name registration services in
the Registry TLD only and for no other purpose.
2.4. Changes to System. Registry Operator may from time to time make modifications to the EPP,
APIs, or other software licensed hereunder that will revise or augment the features of the Registry
System. Registry Operator will provide Registrar with at least ninety (90) days notice prior to the
implementation of any material changes to the EPP, APIs or software licensed hereunder.
2.5. Engineering and Customer Service Support. Registry Operator shall provide Registrar with
engineering and customer service support as set forth in Exhibit B.
2.6. Handling of Personal Data. Registry Operator shall notify Registrar of the purposes for which
Personal Data submitted to Registry Operator by Registrar is collected, the intended recipients (or
categories of recipients) of such Personal Data. Registry Operator shall take reasonable steps to
protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction.
Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible
with the notice provided to registrars. Notwithstanding the above, Registry Operator may from time
to time use the demographic data collected for statistical analysis, provided that this analysis
will not disclose individual Personal Data and provided such use is compatible with the notices
provided to registrars regarding the purpose and procedures for such use.
2.7. Service Level Agreement. Registry Operator shall use commercially reasonable efforts to meet
the performance specifications set forth in Appendix 10 to the Registry Agreement. In the event
that Registry Operator fails to meet such requirements, Registry Operator shall issue credits to
Registrar as described in Appendix 10 to the Registry Agreement, which is hereby incorporated by
reference, as amended from time to time. The remedies set forth in Appendix 10 to the Registry
Agreement shall be the sole and exclusive
remedies available to Registrar for the failure to meet such performance specifications.
2.8. ICANN Requirements. Registry Operator’s obligations hereunder are subject to modification at
any time as a result of ICANN-mandated requirements and consensus policies through the processes
set forth in the Registry Agreement. Notwithstanding anything in this Agreement to the contrary,
Registrar shall comply with any such ICANN requirements in accordance with the timeline defined by
ICANN.
2.9 New Registry Services. Registry Operator shall provide Registrar no less than thirty (30) days
written notice of any new Registry Service that has been approved by ICANN according to the
procedures set forth in the applicable Registry Agreement by and between ICANN and Registry
Operator. Such notice shall include the provision of information on pricing, starting date and any
additional terms and conditions regarding the new Registry Service. Such notice shall not be a
substitute for the notice required in Section 2.4 above.
3. OBLIGATIONS OF REGISTRAR
3.1. Accredited Registrar. During the term of this Agreement, Registrar shall maintain in full
force and effect its accreditation by ICANN as a registrar for the Registry TLD.
3.2. Registrar Responsibility for Customer Support. Registrar shall provide (i) support to accept
orders for registration, cancellation, modification, renewal, deletion or transfer of Registered
Names and (ii) customer service (including domain name record support) and billing and technical
support to Registered Name Holders.
3.3. Registrar’s Registration Agreement. At all times while it is sponsoring the registration of
any Registered Name within the Registry System, Registrar shall have in effect an electronic or
paper registration agreement with the Registered Name Holder. The current form of Registrar’s
registration agreement is attached as Exhibit C (which may contain multiple alternative forms of
the registration agreement). Registrar may from time to time amend those forms of registration
agreement or add alternative forms of registration agreement, provided a copy of the amended or
alternative registration agreement is furnished to the Registry Operator three business days in
advance of the use of such amended registration agreement. Registrar shall include in its
registration agreement those terms required by this Agreement and other terms that are consistent
with Registrar’s obligations to Registry Operator under this Agreement.
3.4. Indemnification Required of Registered Name Holders. In its registration agreement with each
Registered Name Holder, Registrar shall require such Registered Name Holder to indemnify, defend
and hold harmless Registry Operator, and its subcontractors, directors, officers, employees,
affiliates and agents of each of them from and against any and all claims, damages, liabilities,
costs and expenses, including reasonable legal fees and expenses, arising out of or relating to the
Registered Name Holder’s domain name registration. The registration agreement shall further require
this indemnification obligation survive the termination or expiration of the registration
agreement.
3.5. Data Submission Requirements. As part of its registration and sponsorship of Registered Names
in the Registry TLD, Registrar shall submit complete data as required by technical specifications
of the Registry System that are made available to Registrar from time to time. Registrar hereby
grants Registry Operator a non-exclusive, non-transferable, limited license to such data for
propagation of and the provision of authorized access to the TLD zone files and as otherwise
required in Registry Operator’s operation of the Registry TLD.
3.6. Security. Registrar shall develop and employ in its domain name registration business all
necessary technology and restrictions to ensure that its connection to the Registry System is
secure. All data exchanged between Registrar’s system and the Registry System shall be protected to
avoid unintended disclosure of information. Registrar agrees to employ the necessary measures to
prevent its access to the Registry System granted hereunder from being used to (1) allow, enable,
or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited,
commercial advertising or solicitations to entities other than
its own existing customers; or (2) enable high volume, automated, electronic processes that send
queries or data to the systems of Registry Operator, any other registry operated under an agreement
with ICANN, or any ICANN-accredited registrar, except as reasonably necessary to register domain
names or modify existing registrations. In addition, Registry Operator may require other reasonable
security provisions to ensure that the Registry System is secure.
3.7. Resolution of Technical Problems. Registrar shall employ necessary employees, contractors, or
agents with sufficient technical training and experience to respond to and fix all technical
problems concerning the use of the EPP and the APIs in conjunction with Registrar’s systems.
Registrar agrees that in the event of significant degradation of the System or other emergency,
Registry Operator may, in its sole discretion, temporarily suspend or restrict access to the
Registry System. Such temporary suspensions shall be applied in a non-arbitrary manner and shall
apply fairly to any registrar similarly situated, including affiliates of Registry Operator.
3.8. Time. Registrar agrees that in the event of any dispute concerning the time of the entry of a
domain name registration into the Registry Database, the time shown in the Registry records shall
control.
3.9. Transfer of Sponsorship of Registrations. Registrar agrees to implement transfers of
Registered Name registrations from another registrar to Registrar and vice versa pursuant to the
Policy on Transfer of Registrations Between Registrars as may be amended from time to time by ICANN
(the “Transfer Policy”).
3.10. Compliance with Terms and Conditions. Registrar shall comply with, and shall include in its
registration agreement with each Registered Name Holder as appropriate, all of the following:
3.10.1. ICANN standards, policies, procedures, and practices for which Registry
Operator has monitoring responsibility in accordance with the Registry Agreement
or other arrangement with ICANN.
3.10.2. Operational standards, policies, procedures, and practices for the
Registry TLD as set forth in the Registry Agreement and as established from time
to time by Registry Operator in a non-arbitrary manner and applicable to all
registrars, including affiliates of Registry Operator, and consistent with ICANN’s
standards, policies, procedures, and practices and Registry Operator’s Registry
Agreement with ICANN. Among Registry Operator’s operational standards, policies,
procedures, and practices are those set forth in Exhibit D. Additional or revised
Registry Operator operational standards, policies, procedures, and practices for
the Registry TLD shall be effective upon thirty days notice by Registry Operator
to Registrar.
3.11. Restrictions on Registered Names. In addition to complying with ICANN standards, policies,
procedures, and practices limiting domain names that may be registered, Registrar agrees to comply
with applicable statutes and regulations limiting the domain names that may be registered.
3.12. Authorization Codes. Registrar shall not provide identical Registrar-generated authorization
<authinfo> codes for domain names registered by different registrants with the same
Registrar. Registry Operator in its sole discretion may choose to modify <authinfo> codes for
a given domain and shall notify the sponsoring registrar of such modifications via EPP compliant
mechanisms. Documentation of these mechanisms shall be made available to Registrar by Registry
Operator. The Registrar shall provide the Registered Name Holder with timely access to the
authorization code along with the ability to modify the authorization code. Registrar shall respond
to any inquiry by a Registered Name Holder regarding access to and/or modification of an
authorization code within five (5) calendar days. In addition, Registrar may not employ any
mechanism for complying with a Registrant’s request to obtain the applicable “AuthInfo Code” that
is more restrictive than the mechanisms used for changing any aspect of the Registrant’s contact
or name server information.
Registrar must not refuse to release an “AuthInfo Code” to the Registered Name Holder solely
because there is a dispute between the Registered Name Holder and the Registrar over payment.
4. FEES
4.1. Amount of Registry Operator Fees.
4.1.1. Registrar agrees to pay Registry Operator the fees set forth in Exhibit E
for initial and renewal registrations and other services provided by Registry
Operator to Registrar (collectively, “Fees”). Registry Operator reserves the right
to increase the Fees prospectively upon six (6) months prior notice to Registrar.
4.1.2. In addition, Registrar agrees to pay Registry Operator the applicable
variable fees assessed to Registry Operator by ICANN, as permitted by Subsection
7.2(b) of the Registry Agreement by no later ten (10) days after the date of an
invoice from Registry Operator for such fees.
4.2. Payment of Registry Operator Fees. In advance of incurring Fees, Registrar shall establish a
deposit account, or other credit facility accepted by Registry Operator, which acceptance will not
be unreasonably withheld so long as payment is assured. All Fees are due immediately upon receipt
of applications for initial and renewal registrations, or upon provision of other services provided
by Registry Operator to Registrar. Payment shall be made via debit or draw down of the deposit
account or other credit facility approved by Registry Operator. Registry Operator shall provide
monthly invoices to the Registrar.
4.3. Non-Payment of Fees. In the event Registrar has insufficient funds deposited with Registry
Operator, Registry Operator may do any or all of the following: (a) stop accepting new initial,
renewal or transferred registrations from Registrar; (b) delete the domain names associated with
any negative balance
incurred from the Registry database; and (c) pursue any other remedy under this Agreement.
5. CONFIDENTIALITY AND INTELLECTUAL PROPERTY
5.1. Use of Confidential Information. During the Term of this Agreement, each party (the
“Disclosing Party”) may be required to disclose its Confidential Information to the other Party
(the “Receiving Party”). Each party’s use and disclosure of the Confidential Information of the
other party shall be subject to the following terms and conditions:
5.1.1. The Receiving Party shall treat as strictly confidential, and use all
reasonable efforts to preserve the secrecy and confidentiality of, all
Confidential Information of the Disclosing Party, including implementing
reasonable physical security measures and operating procedures.
5.1.2. The Receiving Party agrees that it will use any Confidential Information of
the Disclosing Party solely for the purpose of exercising its right or performing
its obligations under this Agreement and for no other purposes whatsoever.
5.1.3. The Receiving Party shall make no disclosures whatsoever of any
Confidential Information of the Disclosing Party to others; provided, however,
that if the Receiving Party is a corporation, partnership, or similar entity,
disclosure is permitted to the Receiving Party’s officers, employees, contractors
and agents who have a demonstrable need to know such Confidential Information,
provided the Receiving Party shall advise such personnel of the confidential
nature of the Confidential Information and of the procedures required to maintain
the confidentiality thereof, and shall require them to acknowledge in writing that
they have read,
understand, and agree to be individually bound by the confidentiality terms of
this Agreement.
5.1.4. The Receiving Party shall not modify or remove any confidentiality legends
and/or copyright notices appearing on any Confidential Information of the
Disclosing Party.
5.1.5. The Receiving Party agrees not to prepare any derivative works based on the
Confidential Information.
5.1.6. Notwithstanding the foregoing, this Subsection 5.1 imposes no obligation
upon the parties with respect to information that (a) is disclosed with the
Disclosing Party’s prior written approval; or (b) is or has entered the public
domain through no fault of the Receiving Party; or (c) is known by the Receiving
Party prior to the time of disclosure; or (d) is independently developed by the
Receiving Party without use of the Confidential Information; or (e) is made
generally available by the Disclosing Party without restriction on disclosure.
5.1.7. In the event the Receiving Party is required by law, regulation or court
order to disclose any of Disclosing Party’s Confidential Information, Receiving
Party will promptly notify Disclosing Party in writing prior to making any such
disclosure in order to facilitate Disclosing Party seeking a protective order or
other appropriate remedy from the proper authority, at the Disclosing Party’s
expense. Receiving Party agrees to cooperate with Disclosing Party in seeking such
order or other remedy. Receiving Party further agrees that if Disclosing Party is
not successful in precluding the requesting legal body from requiring the
disclosure of the Confidential Information, it will furnish only that portion of
the Confidential Information which is legally required.
5.1.8. The Receiving Party’s duties under this Subsection 5.1 shall expire five
(5) years after the information is received or earlier, upon written agreement of
the parties.
5.2 Intellectual Property.
5.2.1. Subject to Subsection 3.5, each party will continue to independently own its intellectual
property, including all patents, trademarks, trade names, service marks, copyrights, trade secrets,
proprietary processes and all other forms of intellectual property. In addition, Registry Operator,
or its suppliers and/or licensees, shall own all right, title and interest in and to the EPP, APIs,
Registrar Tool Kits, and any software incorporated into the Registry System, as well as all
intellectual property appurtenant thereto.
5.2.2. Without limiting the generality of the foregoing, no commercial use rights or any licenses
under any patent, patent application, copyright, trademark, know-how, trade secret, or any other
intellectual proprietary rights are granted by the Disclosing Party to the Receiving Party by this
Agreement, or by any disclosure of any Confidential Information to the Receiving Party under this
Agreement.
6. INDEMNITIES AND LIMITATION OF LIABILITY
6.1. Indemnification. Registrar, at its own expense and within thirty days after presentation of a
demand by Registry Operator under this Section, will indemnify, defend and hold harmless Registry
Operator and its employees, directors, officers, representatives, agents and affiliates, against
any claim, suit, action, or other proceeding brought against Registry Operator or any affiliate of
Registry Operator based on or arising from any claim or alleged claim: (i) relating to any product
or service of Registrar; (ii) relating to any agreement, including Registrar’s dispute policy, with
any Registered Name Holder of Registrar; or (iii) relating to Registrar’s domain name registration
business, including, but not limited to, Registrar’s advertising, domain name application process,
systems and other processes, fees charged, billing practices and customer service; provided,
however, that in any such case: (a) Registry Operator provides Registrar with prompt notice of any
such claim, and (b) upon Registrar’s written
request, Registry Operator will provide to Registrar all available information and assistance
reasonably necessary for Registrar to defend such claim, provided that Registrar reimburses
Registry Operator for its actual and reasonable costs incurred in connection with providing such
information and assistance. Registrar will not enter into any settlement or compromise of any such
indemnifiable claim without Registry Operator’s prior written consent, which consent shall not be
unreasonably withheld. Registrar will pay any and all costs, damages, and expenses, including, but
not limited to, reasonable attorneys’ fees and costs awarded against or otherwise incurred by
Registry Operator in connection with or arising from any such indemnifiable claim, suit, action or
proceeding.
6.2. Limitation of Liability. EXCEPT AS PROVIDED IN SUBSECTION 6.3 BELOW, IN NO EVENT SHALL EITHER
PARTY BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL
DAMAGES, OR ANY DAMAGES FOR ANY VIOLATIONS OF THIS AGREEMENT. IN ADDITION, IN NO EVENT SHALL
REGISTRY OPERATOR’S LIABILITY EXCEED THE LESSER OF (I) THE AMOUNT OF FEES PAID BY REGISTRAR TO
REGISTRY OPERATOR, EXCLUDING ANY FEES PAID UNDER SECTION 4.1.2 ABOVE, IN THE PRECEDING 12 MONTH
PERIOD OR (II) $100,000.
6.3. Performance Credits. In the event Registry Operator fails to meet the performance
specifications set forth in Exhibit F of this Agreement, Registry Operator shall provide a credit
to Registrar in an amount equal to its proportionate share of applicable performance credits set
forth in Exhibit G to this Agreement. Such performance credits shall constitute the sole and
exclusive remedy available to Registrar with regard to Registry Operator’s failure to meet the
performance specifications.
7. DISPUTE RESOLUTION.
7.1. Dispute Resolution. Disputes arising under or in connection with this Agreement, including
requests for specific performance, shall be resolved through binding arbitration conducted as
provided in this Section pursuant to the
rules of the International Court of Arbitration of the International Chamber of Commerce (“ICC”).
The arbitration shall be conducted in the English language and shall occur in the Commonwealth of
Virginia, USA. There shall be three arbitrators: each party shall choose one arbitrator and, if the
two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC.
The parties shall bear the costs of the arbitration in equal shares, subject to the right of the
arbitrators to reallocate the costs in their award as provided in the ICC rules. The parties shall
bear their own attorneys’ fees in connection with the arbitration, and the arbitrators may not
reallocate the attorneys’ fees in conjunction with their award. The arbitrators shall render their
decision within ninety days of the initiation of arbitration. Any litigation brought to enforce an
arbitration award shall be brought in a Commonwealth or federal court in the eastern district of
the Commonwealth of Virginia, USA; however, the parties shall also have the right to enforce a
judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the
arbitration and/or preserving the rights of a Party during the pendency of an arbitration, each
Party shall have the right to seek temporary or preliminary injunctive relief from the arbitration
panel or a court located in the Eastern District of the Commonwealth of Virginia, USA, which shall
not be a waiver of this arbitration agreement.
8. TERM AND TERMINATION
8.1. Term of the Agreement; Revisions. The Term of this Agreement shall commence on the Effective
Date and, unless earlier terminated in accordance with the provisions of this Agreement, shall
expire on the expiration of the Registry Agreement. In the event that revisions to Registry
Operator’s approved form of Registry-Registrar Agreement are approved or adopted by ICANN,
Registrar will either execute an amendment substituting the revised agreement in place of this
Agreement or, at its option exercised within fifteen days after receiving notice of such amendment,
terminate this Agreement immediately by giving written notice to Registry Operator. In the event
that Registry Operator does not receive such executed amendment or notice of termination from
Registrar within such fifteen day period, Registrar shall be deemed to have terminated this
Agreement effective immediately.
8.2. Termination. This Agreement may be terminated as follows:
8.2.1. Termination For Cause. In the event that either party materially breaches
any of its obligations under this Agreement and such breach is not substantially
cured within thirty calendar days after written notice thereof is given by the
other party, then the non-breaching party may, by giving written notice thereof to
the other party, terminate this Agreement as of the date specified in such notice
of termination.
8.2.2. Termination at Option of Registrar. Registrar may terminate this Agreement
at any time by giving Registry Operator thirty days notice of termination.
8.2.3. Termination Upon Loss of Registrar’s Accreditation. This Agreement shall
terminate in the event Registrar’s accreditation by ICANN is terminated or expires
without renewal.
8.2.4. Termination in the Event of Termination of Registry Agreement. This
Agreement shall terminate in the event that Registry Operator’s Registry Agreement
with ICANN is terminated or expires without entry of a subsequent Registry
Agreement with ICANN and this Agreement is not assigned under Subsection 9.1.1.
8.2.5. Termination in the Event of Insolvency or Bankruptcy. Either party may
terminate this Agreement if the other party is adjudged insolvent or bankrupt, or
if proceedings are instituted by or against a party seeking relief, reorganization
or arrangement under any laws relating to insolvency, or seeking any assignment
for the benefit of creditors, or seeking the appointment of a receiver,
liquidator or trustee of a party’s property or assets or the liquidation,
dissolution or winding up of a party’s business.
8.3. Effect of Termination. Upon the expiration or termination of this Agreement for any reason:
8.3.1. Registry Operator will complete the registration of all domain names
processed by Registrar prior to the effective date of such expiration or
termination, provided that Registrar’s payments to Registry Operator for Fees are
current and timely.
8.3.2. Registrar shall immediately transfer its sponsorship of Registered Names to
another ICANN-accredited registrar in compliance with any procedures established
or approved by ICANN.
8.3.3. All Confidential Information of the Disclosing Party in the possession of
the Receiving Party shall be immediately returned to the Disclosing Party.
8.3.4. All fees owing to Registry Operator shall become immediately due and
payable.
8.4. Survival. In the event of termination of this Agreement, the following shall survive: (i)
Subsections 2.6, 3.5, 5.1, 5.2, 6.1, 6.2, 7.1, 8.3.3, 8.3.4, 8.4, 9.2, 9.3.3, 9.5, 9.6, 9.8, 9.9,
9.10, and 9.13 and (ii) the Registered Name Holder’s indemnification obligation under Subsection
3.4. Neither party shall be liable to the other for damages of any sort resulting solely from
terminating this Agreement in accordance with its terms.
9. MISCELLANEOUS
9.1. Assignments.
9.1.1. Assignment to Successor Registry Operator. In the event the Registry
Operator’s Registry Agreement is terminated (and such termination is deemed final
under the Registry Agreement) or expires without entry by Registry Operator and
ICANN of a subsequent registry agreement, Registry Operator’s rights under this
Agreement may be assigned to a company with a subsequent registry agreement
covering the Registry TLD upon ICANN’s giving Registrar written notice within
sixty days of the termination or expiration, provided that the subsequent registry
operator assumes the duties of Registry Operator under this Agreement.
9.1.2. Assignment in Connection with Assignment of Agreement with ICANN. In the
event that Registry Operator’s Registry Agreement with ICANN for the Registry TLD
is validly assigned, Registry Operator’s rights under this Agreement shall be
automatically assigned to the assignee of the Registry Agreement, provided that
the assignee assumes the duties of Registry Operator under this Agreement. In the
event that Registrar’s accreditation agreement with ICANN for the Registry TLD is
validly assigned, Registrar’s rights under this Agreement shall be automatically
assigned to the assignee of the accreditation agreement, provided that the
subsequent registrar assumes the duties of Registrar under this Agreement.
9.1.3. Other Assignments. Except as otherwise expressly provided in this
Agreement, the provisions of this Agreement shall inure to the benefit of and be
binding upon, the successors and permitted assigns of the parties. Neither party
shall assign or transfer its rights or obligations under this Agreement without
the prior written consent of the other party, which shall not be unreasonably
withheld.
9.2. Notices. Any notice or other communication required or permitted to be delivered to any party
under this Agreement shall be in writing and shall be deemed properly delivered, given and received
when delivered (by hand, by registered mail, by courier or express delivery service, by e-mail or
by telecopier during business hours) to the address or telecopier number set forth beneath the name
of such party below, unless party has given a notice of a change of address in writing:
If to Registrar:
with copy to:
If to Registry Operator:
NeuStar, Inc.
▇▇▇▇▇ ▇▇▇▇▇▇ ▇▇▇ ▇▇▇▇▇
▇▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇
Attn: Senior Director, Law, Advanced Services and Business Development
▇▇▇▇▇ ▇▇▇▇▇▇ ▇▇▇ ▇▇▇▇▇
▇▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇
Attn: Senior Director, Law, Advanced Services and Business Development
with a copy to:
NeuStar, Inc.
▇▇▇▇▇ ▇▇▇▇▇▇ ▇▇▇ ▇▇▇▇▇
▇▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇
Attn: General Counsel
▇▇▇▇▇ ▇▇▇▇▇▇ ▇▇▇ ▇▇▇▇▇
▇▇▇▇▇▇▇▇, ▇▇ ▇▇▇▇▇
Attn: General Counsel
9.3. Representations and Warranties.
9.3.1. Registrar. Registrar represents and warrants that: (1) it is a corporation
duly incorporated, validly existing and in good standing under the law of its
jurisdiction of formation or organization, (2) it has all requisite corporate
power and authority to execute, deliver and perform its obligations under this
Agreement, (3) it is, and during the Term of this Agreement will continue to be,
accredited by ICANN or its successor, (4) the execution, performance and delivery
of this Agreement has been duly authorized by Registrar, (5) no further approval,
authorization or consent of any governmental or regulatory authority is required
to be obtained or
made by Registrar in order for it to enter into and perform its obligations under
this Agreement.
9.3.2. Registry Operator. Registry Operator represents and warrants that: (1) it
is a corporation duly incorporated, validly existing and in good standing under
the laws of the State of Delaware, (2) it has all requisite corporate power and
authority to execute, deliver and perform its obligations under this Agreement,
(3) the execution, performance and delivery of this Agreement has been duly
authorized by Registry Operator, and (4) no further approval, authorization or
consent of any governmental or regulatory authority is required to be obtained or
made by Registry Operator in order for it to enter into and perform its
obligations under this Agreement.
9.3.3. Disclaimer of Warranties. THE EPP, APIs, REGISTRY TOOLKIT, REGISTRY SYSTEM
AND ANY COMPONENT THEREOF ARE PROVIDED “AS-IS” AND WITHOUT ANY WARRANTY OF ANY
KIND. REGISTRY OPERATOR EXPRESSLY DISCLAIMS ALL WARRANTIES AND/OR CONDITIONS,
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND
CONDITIONS OF MERCHANTABILITY OR SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR
PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. REGISTRY OPERATOR DOES NOT
WARRANT THAT THE EPP, APIs, REGISTRAR TOOLKITS, REGISTRY SYSTEM OR ANY COMPONENT
THEREOF WILL MEET REGISTRAR’S REQUIREMENTS, OR THAT THE OPERATION OF EPP, APIs,
REGISTRAR TOOLKITS, THE REGISTRY SYSTEM OR ANY
COMPONENT THEREOF WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE EPP,
APIs, REGISTRAR TOOLKITS, REGISTRY SYSTEM OR ANY COMPONENT THEREOF WILL BE
CORRECTED. FURTHERMORE, REGISTRY OPERATOR DOES NOT WARRANT NOR MAKE ANY
REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE EPP, APIs, REGISTRAR
TOOLKITS, REGISTRY SYSTEM OR ANY COMPONENT THEREOF OR RELATED DOCUMENTATION IN
TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. SHOULD THE EPP,
APIs, REGISTRAR TOOLKITS, THE REGISTRY SYSTEM OR ANY COMPONENT THEREOF PROVE
DEFECTIVE, REGISTRAR ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR
CORRECTION OF REGISTRAR’S OWN SYSTEMS AND SOFTWARE.
9.4. Insurance. During the Term of this Agreement, and any renewal Terms, Registrar shall have in
place at least US $1,000,000 in comprehensive legal liability insurance from a reputable insurance
provider with a rating equivalent to an A.M. Best rating of “A” or better. Registrar shall provide
a copy of the insurance policy to Registry Operator upon Registry Operator’s reasonable request.
9.5. Third-Party Beneficiaries. The Parties expressly agree that ICANN is an intended third-party
beneficiary of this Agreement. Otherwise, this Agreement shall not be construed to create any
obligation by either party to any non-party to this Agreement, including any holder of a Registered
Name. Registrar acknowledges that nothing in this Agreement, including those requirements in this
Agreement that incorporate the Registry Agreement, shall confer upon Registrar the status of an
intended third-party beneficiary to the Registry Agreement.
9.6. Relationship of the Parties. Nothing in this Agreement shall be construed as creating an
employer-employee or agency relationship, a partnership or a joint venture between the parties.
9.7. Force Majeure. Neither party shall be liable to the other for any loss or damage resulting
from any cause beyond its reasonable control (a “Force Majeure Event”) including, but not limited
to, insurrection or civil disorder, war or military operations, national or local emergency, acts
or omissions of government or other competent authority, compliance with any statutory obligation
or executive order, industrial disputes of any kind (whether or not involving either party’s
employees), fire, lightning, explosion, flood, subsidence, weather of exceptional severity,
equipment or facilities shortages which are being experienced by providers of telecommunications
services generally, or other similar force beyond such Party’s reasonable control, and acts or
omissions of persons for whom neither party is responsible. Upon occurrence of a Force Majeure
Event and to the extent such occurrence interferes with either party’s performance of this
Agreement, such party shall be excused from performance of its obligations (other than payment
obligations) during the first six months of such interference, provided that such party uses best
efforts to avoid or remove such causes of nonperformance as soon as possible.
9.8. Amendments. Except as otherwise provided herein, no amendment, supplement, or modification of
this Agreement or any provision hereof shall be binding unless executed in writing by both parties.
9.9. Waivers. No failure on the part of either party to exercise any power, right, privilege or
remedy under this Agreement, and no delay on the part of either party in exercising any power,
right, privilege or remedy under this Agreement, shall operate as a waiver of such power, right,
privilege or remedy; and no single or partial exercise or waiver of any such power, right,
privilege or remedy shall preclude any other or further exercise thereof or of any other power,
right, privilege or remedy. Neither party shall be deemed to have waived any claim arising out of
this Agreement, or any power, right, privilege or remedy under this
Agreement, unless the waiver of such claim, power, right, privilege or remedy is expressly set
forth in a written instrument duly executed and delivered on behalf of such party; and any such
waiver shall not be applicable or have any effect except in the specific instance in which it is
given.
9.10. Attorneys’ Fees. If any legal action or other legal proceeding (including arbitration)
relating to the performance under this Agreement or the enforcement of any provision of this
Agreement is brought against either Party hereto, the prevailing Party shall be entitled to recover
reasonable attorneys’ fees, costs and disbursements (in addition to any other relief to which the
prevailing Party may be entitled).
9.11. Construction. The Parties agree that any rule of construction to the effect that ambiguities
are to be resolved against the drafting party shall not be applied in the construction or
interpretation of this Agreement.
9.12. Further Assurances. Each party hereto shall execute and/or cause to be delivered to each
other Party hereto such instruments and other documents, and shall take such other actions, as such
other Party may reasonably request for the purpose of carrying out or evidencing any of the
transactions contemplated by this Agreement.
9.13. Entire Agreement. This Agreement (including its exhibits, which form a part of it)
constitutes the entire agreement between the parties concerning the subject matter of this
Agreement and supersedes any prior agreements, representations, statements, negotiations,
understandings, proposals or undertakings, oral or written, with respect to the subject matter
expressly set forth herein.
9.14. Counterparts. This Agreement may be executed in one or more counterparts, each of which shall
be deemed an original, but all of which together shall constitute one and the same instrument.
IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the date set forth in the
first paragraph hereof.
NeuStar, Inc.
|
[Registrar] | |||
By:
|
By: | |||
Name:
|
Name: | |||
Title:
|
Title: |
Exhibit A
Registrar Tool Kits
Registrar Tool Kits
The Registry ToolKit includes:
| • | Reference client implementations: |
| o | Java | ||
| o | Language bindings | ||
| o | Interface Definition Language (IDL) |
| • | Interface definition: |
| o | ABNF | ||
| o | XML schema |
| • | Registry Operational Profile (our extensions) | ||
| • | Authentication and Encryption guidelines | ||
| • | Epp “feature freeze” drafts | ||
| • | Epp test plan and coverage matrix | ||
| • | Java, API documentation |
Exhibit B
Engineering and Customer Service Support
Engineering and Customer Service Support
During the Term of this Agreement, Registry Operator will provide reasonable telephone and
electronic customer support to Registrar, not Registered Name holders or prospective customers of
Registrar, for non-technical issues solely relating to the Registry System and its operation.
Registry Operator will provide Registrar with a telephone number and e-mail address for such
support during implementation of the EPP, APIs and Software. While e-mail and FAQs are the primary
method of help, Registry Operator will provide support on a 7-day/24-hour basis.
The Registry Operator provides a clear, concise and efficient deliberation of customer support
responsibilities. Registrars provide support to registrants and
registries provide support for Registrars. This allows the Registry to focus its support on the
highly technical and administratively complex issues that arise between the Registry and the
Registrar.
Technical Help Systems
NeuStar will provide the Registrars with the following types of technical support:
| • | Web-based self-help services, including: |
| o | Frequently asked questions | ||
| o | Downloads of EPP client software | ||
| o | Support for email messaging |
| • | Telephone support from our central Help Desk | ||
| • | Fee-based consulting services. |
Web Portal
Registry Operator will implement a secure Web-based portal to help support registrar operations. To
obtain access to our Web-based services, a registrar must register his registrants with us, and
must have implemented our security features, including SSL encryption, log in with user ID and
password, and digital certificates for authentication. The home page of the web portal will include
a notice to registrars of planned outages for database maintenance or installation of software
upgrades. This notification will be posted 30 days prior to the event in addition to active
notification including phone calls and email. We will also record outage notifications in the help
desk database to facilitate compliance with the service-level agreement. Finally, seven days and
again two days prior to the scheduled event, we will use both an email and a Web-based notification
to remind registrars of the outage.
Non-affiliated registrars and the general Internet community may obtain generic information from
NeuStar’s public Web site, which will describe our TLD service offerings and list ICANN-certified
registrars providing domain-name services.
Central Help Desk
In addition to implementing the Web site, we will provide telephone support to our registrars
through our central Help Desk. Access to the help desk telephone support is through an automatic
call distributor that routes each call to the next available customer support specialist. We will
authenticate callers by using caller ID and by requesting a pre-established pass phrase that is
different for each registrar. Requests for assistance may also come to the Help Desk via email,
either directly or via the secure Web site. The Help Desk’s three tiers of support are:
Tier-1 Support. Telephone support to registrars who normally are calling for help with customer
domain-name problems and such other issues such as EPP implementation or billing and collection.
Problems that can’t be resolved at Tier 1 are escalated to Tier 2.
Tier-2 Support. Support provided by members of the technical support team, who are functional
experts in all aspects of domain-name registration. In addition to resolving escalated Tier 1
problems with EPP implementation and billing and collection, Tier 2 staff provides technical
support in system tuning and workload processing.
Tier 3 Support. Complex problem resolution provided by on-site maintenance technicians, third party
systems and software experts, and vendors, depending on the nature of the problem.
In turn, the Help Desk uses an automated software package to collect call statistics and record
service requests and trouble tickets in a help desk database. The help desk database documents the
status of requests and tickets, and notifies the Help Desk when an SLA threshold is close to being
breached. Each customer-support and technical support specialist uses our problem management
process to respond to trouble tickets with a troubleshooting, diagnosis, and resolution procedure
and a root-cause analysis.
Escalation Policy
Our escalation policy defines procedures and timelines for elevating problems either to functional
experts or to management for resolution if they not resolved
within the escalation-policy time limits. The following table is an overview of our escalation
policy.
| Level | Description | Escalation Policy | Notification | |||
I
|
Catastrophic outage affecting overall registry operations |
Data-center manager escalates to NeuStar management and Disaster-Recovery Team if not resolved in 15 minutes | Web portal and e-mail notifications to all Registrars within 15 minutes; updates every 30 minutes | |||
II
|
Systems outage affecting one or two registrar sessions but not the entire system |
Systems engineer escalates to data-center manager if not resolved in one hour | Web-portal notification to all registrars; hourly updates | |||
III
|
Technical questions | Help Desk customer-support specialist escalates to the systems engineer if not resolved in two hours | Hourly updates to registrar via e-mail | |||
IV
|
Basic questions | Help Desk customer-support specialist escalates to the systems engineer if not resolved within four hours | Hourly updates to registrar via e-mail |
Staffing
Registry Operator will staff its Help Desk with a complement of customer service specialists. We
will add staff as necessary to respond to incoming requests within the service-level agreement.
Customer-service specialists will obtain assistance from Registry Operator’s technical staff for
any problems that cannot be resolved in one phone call.
Test and Evaluation Facility
Registry Operator will establish an operational test-and-evaluation facility that will be available
for Registrars to test their client EPP system. Our technical-support team, which consists of
functional experts in the processes and technologies for domain-name registration, supports the
registrars’ testing.
Once each new Registrar is satisfied that its system is compatible with the registry system, it
will schedule a formal acceptance test that will be monitored by our system engineer. After a
registrar has passed the acceptance test, we will
issue its user id, passwords, and digital certificates, and the Registrar can begin operations.
Customer Satisfaction Survey
To determine Registrars’ satisfaction with Registry Services, Registry Operator will implement a
Web-based customer-satisfaction survey that will consist of a set of survey questions with
responses ranging from one to five on the Likert Scale. We will tabulate the results and publish
them on the Web site.
To further verify the quality of our customer services, Registry Operator will commission a
biannual customer-satisfaction survey by an independent third party.
Exhibit C
Registrar’s Registration Agreement
[To be supplied by Registrar]
Registrar’s Registration Agreement
[To be supplied by Registrar]
Exhibit D
Registry Operator’s Operational Standards, Policies, Procedures and Practices
Registry Operator’s Operational Standards, Policies, Procedures and Practices
I. Registration Requirements
Before the Registry Operator will accept applications for registration from Registrar, all domain
name applicants in the .biz TLD (“Applicants”) must:
1. Enter into an electronic or paper registration agreement with the Registrar (“Registrar”), in
accordance with the ICANN Registrar Accreditation Agreement (“Accreditation Agreement”) and this
Agreement. Such electronic or paper registration agreement shall include, at a minimum, the
following certifications:
a) The data provided in the domain name registration application is true, correct,
up to date and complete; and
b) The registrant will keep the information provided above up to date.
2. Certify in the Registration Agreement that to the best of its knowledge:
a) The registered domain name will be used primarily for bona fide business or
commercial purposes and not (i) exclusively for personal use; or (ii) solely for
the purposes of (1) selling, trading or leasing the domain name for compensation,
or (2) the unsolicited offering to sell, trade or lease the domain name for
compensation.
b) The domain name registrant has the authority to enter into the registration
agreement; and
c) The registered domain name is reasonably related to the registrant’s business
or intended commercial purpose at the time of registration.
For purposes of the .biz Registration Restrictions (“Restrictions”), “bona fide business or
commercial use” shall mean the bona fide use or bona fide intent to use the domain name or any
content, software, materials, graphics or other information thereon, to permit Internet users to
access one or more host computers through the DNS:
1. To exchange goods, services, or property of any kind;
2. In the ordinary course of trade or business; or
3. To facilitate (i) the exchange of goods, services, information, or property of any kind; or,
(ii) the ordinary course of trade or business.
Registering a domain name solely for the purposes of (1) selling, trading or leasing the domain
name for compensation, or (2) the unsolicited offering to sell, trade or lease the domain name for
compensation shall not constitute a “bona fide business or commercial use” of that domain name.
For illustration purposes, the following shall not constitute a “bona fide business or commercial
use” of a domain name:
1. Using or intending to use the domain name exclusively for personal, noncommercial purposes; or
2. Using or intending to use the domain name exclusively for the expression of noncommercial ideas
(i.e., registering ▇▇▇▇▇▇▇▇.▇▇▇ exclusively to criticize or otherwise express an opinion on the
products or services of ABC company, with no other intended business or commercial purpose);
3. Using the domain name for the submission of unsolicited bulk e-mail, phishing, pharming or other
abusive or fraudulent purposes.
II. Incorporation of .Biz Dispute Resolution Services
In addition, Registrar agrees to incorporate the following text (or translation of such text into
relevant language) into their Registration Agreement:
“The Registrant acknowledges having read and understood and agrees to be bound by the terms and
conditions of the following documents, as they may be amended from time to time, which are hereby
incorporated and made an integral part of this Agreement:
(i) The Uniform Domain Name Dispute Resolution Policy, available at
<URL>; and
(ii) The Restrictions Dispute Resolution Criteria and Rules, available at
<URL>.”
The UDRP sets forth the terms and conditions in connection with a dispute between a Registrant and
any party other than the Registry Operator or Registrar over the registration and use of an
Internet domain name registered by Registrant.
The RDRP sets forth the terms under which any allegation that a domain name is not used primarily
for business or commercial purposes shall be enforced on a case-by-case, fact specific basis by an
independent ICANN-accredited dispute provider. None of the violations of the Restrictions will be
enforced directly by or through Registry Operator. Registry Operator will not review, monitor, or
otherwise verify that any particular domain name is being used primarily for business or commercial
purposes or that a domain name is being used in compliance with the UDRP processes.
III. Reservation
Registry Operator reserves the right to deny, cancel, place on registry-lock or hold, or transfer
any registration that it deems necessary, in its discretion; (1) to protect the integrity and
stability of the registry; (2) to comply with any applicable laws, government rules or
requirements, requests of law enforcement, in compliance with any dispute resolution process; (3)
to avoid any liability, civil or criminal, on the part of Registry Operator, as well as its
affiliates, subsidiaries, officers, directors, employees and stockholders; (4) for violations of
this Agreement and its Exhibits; or (5) to correct mistakes made by Registry Operator or any
Registrar in connection with a domain name registration. Registry Operator also reserves the right
to lock or place on hold a domain name during resolution of a dispute.
Exhibit E
Registration Fees
Registration Fees
| • | Initial Registration. Registrar agrees to pay the non-refundable amounts as set forth below: |
| Initial Registration Fee (Per Domain Name) US $5.30 |
| • | Renewal Fees. Registrar agrees to pay the non-refundable amounts as set forth below: |
| Renewal Fee (Per Domain Name) US $5.30 |
| • | Fees for Transfers of Sponsorship of Domain-Name Registrations |
Where the sponsorship of a domain name is transferred from an ICANN-Accredited Registrar to another
ICANN-Accredited Registrar, other than an ICANN approved bulk transfer, Registry Operator may
require the registrar receiving the sponsorship to request a renewal of one year for the name. In
connection with that extension, Registry Operator may charge a Renewal Fee for the requested
extension as provided in the renewal schedule set forth above. The transfer shall result in an
extension according to the renewal request, subject to a ten-year maximum on the future term of any
domain-name registration. The Renewal Fee shall be paid in full at the time of the transfer by the
ICANN-Accredited Registrar receiving sponsorship of the domain name.
For a bulk transfer approved by ICANN, Registry Operator will charge the gaining registrar US $0
(for transfers of 50,000 names or fewer) or US$50,000 (for transfers of more than 50,000 names).
| • | Fee for Restoring Deleted Domain Name Registrations. | ||
| Registry Operator may charge registrars the following maximum price for each Registered Name that is restored pursuant to the Redemption Grace Period Policy set forth in Appendix 7 to the Registry Agreement: | |||
| • | The cost of restoring an unintentionally deleted domain name in the Redemption Grace Period must not exceed US $40.00 per domain name. | ||
| • | Registry Operator will waive the fee for restoring any Registered Name that was deleted, contrary to the wishes of the Registered Name Holder, as the result of a mistake of the Registry Operator. | ||
| • | Note: the fee for restoring deleted names is separate from, and in addition to, any Renewal Fees that may be charged as set forth above. | ||
| • | Fee for disproportionate deletes during Add Grace Period. |
Registry Operator reserves the right to increase the Fees set forth above prospectively upon six
months advance notice to Registrar.
Exhibit F
Performance Specifications
Performance Specifications
[INSERT FROM REGISTRY AGREEMENT]
|
|
.BIZ Agreement Appendix 9 Approved Services (8 December 2006) |
The Registry Agreement specifies a “Process for Consideration of Proposed Registry Services.” The
following services are specifically identified as having been approved by ICANN prior to the
effective date of the Registry Agreement. As such, notwithstanding any other provisions of the
Registry Agreement, NeuStar shall be free to deploy the following services:
| • | Internationalized Domain Names, in accordance with the Letter from ▇▇▇▇▇▇▇ ▇▇▇▇▇▇ to ▇▇▇▇ ▇▇▇▇▇▇ dated July 29, 2004; and | ||
| • | Redemption Grace Period. |
|
|
.BIZ Agreement Appendix 10 Service Level Agreement (SLA) (8 December 2006) |
Service Level Agreement
1. Definitions. Capitalized terms used herein and not otherwise defined shall have the definitions
ascribed to them in Appendix 7 to the Registry Agreement or the Registry-Registrar Agreement.
2. Credits. If Registry Operator fails to meet the Performance Specifications defined in Appendix 7
to the Registry Agreement (“Service Level Exception” or “SLE”), Registry Operator shall pay in the
aggregate to the Registrar Community a credit according to the tables provided below (“Applicable
Credit”). Each Registrar shall only be entitled to a fraction of the Applicable Credit. Such
fractions of the credit specified in the tables to be paid to any individual Registrar will be
calculated based upon the number of domain names that such Registrar added to the Registry during
the Service Level Measurement Period compared to the total number of domain names added to the
Registry by all Registrars during the Service Level Measurement Period in which the SLE occurred.
The credit due to Registrar may be paid as an offset to registrations and other fees owed to
Registry Operator by Registrar. All credits shall be paid in U.S. Dollars. The following Credit
Lookup Matrix indicates the corresponding credit table for which the credits defined in this
Appendix will be levied.
CREDIT LOOKUP MATRIX
| Performance Specification | ||||||||
| Description | SRS | Nameserver | Whois | |||||
1
|
Service Availability | Table C1a | Table C1b | Table C1a | ||||
2
|
Processing Time — Add, Modify, Delete | Table C2 | NA | NA | ||||
3
|
Processing Time — Query Domain | Table C2 | NA | NA | ||||
4
|
Processing Time — Whois | NA | NA | Table C2 | ||||
5
|
Processing Time — Nameserver Resolution | NA | Table C2 | NA | ||||
6
|
Update Frequency | NA | Table C3 | Table C3 | ||||
7
|
Planned Outage — Duration | Table C4b | NA | Table C4b | ||||
8
|
Planned Outage — Timeframe | Table C4a | NA | Table C4a | ||||
9
|
Planned Outage — Notification | Table C4a | NA | Table C4a | ||||
10
|
Extended Planned Outage — Duration | Table C4b | NA | Table C4b | ||||
11
|
Extended Planned Outage — Timeframe | Table C4a | NA | Table C4a | ||||
12
|
Extended Planned Outage — Notification | Table C4a | NA | Table C4a | ||||
13
|
Cross-Network Nameserver Performance | NA | See note. | NA |
Note: The cross-network nameserver performance requirement is a subject of Registry Operator’s
obligations under the Registry Agreement but is not a subject of this Service Level Agreement
(Appendix 10).
If one or more SLEs occurs as the direct result of a failure to meet a Performance Specification in
a single credit class, Registry Operator shall be responsible only for the credit assessed for the
credit class which is the proximate cause for all directly related failures.
The following tables identify total Registrar Community credits due for SLEs in the four credit
classes C1 — C4. Notwithstanding the credit levels contained in these tables, the total credits
owed by Registry Operator under this Agreement shall not exceed $ 30,000 USD monthly and $ 360,000
USD annually. The
credits contained in Tables C1a-C4 represent the total credits that may be assessed in a given SLR
category in one Service Level Measurement Period.
2.1 C1 Credit Class–If availability of C1 Credit Class components or systems does not meet C1
Performance Specifications in any given Service Level Measurement Period described in the
Performance Specification Matrix in Appendix 7 of the Registry Agreement, Registry Operator will
credit the Registrar Community according to the tables (which amount will be credited to the
Registrar on a proportional basis as set forth above).
Table C1a
| < 30 | 30-60 | 1-2 | 2-10 | 10-30 | ||||||||||||||||||||
| SLE | sec.’s | sec.’s | min.’s | min.’s | min.’s | over 30 min.’s | ||||||||||||||||||
Monthly Credit to Registrar Community |
$ | 750 | $ | 1,500 | $ | 2,500 | $ | 3,750 | $ | 5,000 | $ | 6,000 | ||||||||||||
C1a Availability Example: In a given measurement period, the SRS Availability is 99.87%, which
equates to 52 minutes of unplanned downtime. The Registry Operator’s Performance Specification for
SRS Availability is 99.9%, or 43 minutes of downtime. The Service Level Exception, therefore, is 9
minutes (52-43 minutes), the difference between the Performance Specification and the actual
measured performance. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C1a.
In Table C1a, the time interval (2-10 minutes) has a corresponding credit of $3,750 USD to be paid
to the Registrar Community.
Table C1b
| < ▇▇ | ▇▇-▇▇ | ▇▇-▇▇ | ||||||||||||||||||||||
| SLE | min.’s | min.’s | min.’s | 1-2 hours | 2-4 hours | over 4 hours | ||||||||||||||||||
Annual Credit to
Registrar Community |
$ | 7,500 | $ | 15,000 | $ | 25,000 | $ | 35,000 | $ | 50,000 | $ | 75,000 | ||||||||||||
C1b Availability Example: In a given Service Level Measurement Period, the measured Nameserver
Availability is 99.990% over a twelve (12) month period, which equates to 52 minutes of downtime.
The Registry Operator’s Performance Specification for Nameserver Availability is 99.999%, or
5minutes of downtime per calendar year. The Service Level Exception, therefore, is 47 minutes (52-5
minutes), the difference between the Performance Specification and the actual measured performance.
From the Credit Lookup Matrix, we see the relevant SLA is found in Table C1b. In Table C1b, the
time interval (30-60 minutes) has a corresponding credit of $25,000 USD to be paid to the Registrar
Community.
2.2 C2 Credit Class–If processing time for C2 Credit Class services does not meet C2 Service Levels
in any given Service Level Measurement Period, Registry Operator will credit the Registrar
Community according to the following table (which amount will be credited to the Registrars on a
proportional basis as set forth above).
Table C2
| < 2 | ||||||||||||||||||||||||
| SLE | sec.’s | 2-5 sec.’s | 5-10 sec.’s | 10-20 sec.’s | 20-30 sec.’s | over 30 sec.’s | ||||||||||||||||||
Monthly Credit to
Registrar Community |
$ | 375 | $ | 750 | $ | 1,500 | $ | 3,500 | $ | 4,000 | $ | 7,500 | ||||||||||||
C2 Processing Example: The Performance Specification for Processing Time for Add, Modify, and
Delete is 3 seconds or less for 95% of the transactions. In a
given Service Level Measurement Period 7% of the transactions are greater than 3 seconds. The 5% of
those transactions with the longest processing times are not subject to the SLE calculation (3
seconds for 95%). The SLE is calculated using the average processing time for the 2% of the
transactions that are subject to the SLE. If there were 1,000 transactions and they took a total of
4,000 seconds the average is 4 seconds. That generates an SLE of 1 second (4 seconds — 3 seconds).
From the Credit Lookup Matrix, we see the relevant SLA is found in Table C2. In Table C2, the SLE
time interval (< 2 seconds) has a corresponding credit of $375 USD to be paid to the Registrar
Community.
2.3 C3 Credit Class–If update frequency measurements of C3 Credit Class components or systems do
not meet C3 Service Levels in any given Service Level Measurement Period as described in the
Performance Specification Matrix in Appendix 7 of the Registry Agreement, Registry Operator will
credit the Registrar Community according to the following tables (which amount will be credited to
the Registrars on a proportional basis as set forth above).
Table C3
| SLE | < 30 sec.’s | 30-60 sec.’s | 1-2 min.’s | 2-10 min.’s | 10-30 min.’s | over 30 min.’s | ||||||||||||||||||
Monthly Credit
to Registrar Community |
$ | 188 | $ | 375 | $ | 625 | $ | 938 | $ | 1,250 | $ | 1,500 | ||||||||||||
C3 Update Frequency Example: In a given Service Level Measurement Period, 95% of the updates
to the Nameserver take 24 minutes or less to complete. The corresponding Registry Operator’s
Performance Specification is 15 minutes for 95% of the updates. The SLE, therefore, is 9 minutes.
From the Credit Lookup Matrix, we see the relevant SLA is found in Table C3. The SLE time interval
(2-10 minutes) has a corresponding credit of $938 USD to be paid to the Registrar Community.
2.4 C4 Credit Class–If Registry Operator fails to comply with C4 Credit Class category Performance
Specifications, Registry Operator will credit the Registrar Community according to the following
tables (C4a and C4b) (which amount will be credited to the Registrars on a proportional basis as
set forth above).
Table C4a
| SLE | Any | |||
Monthly Credit to
Registrar Community |
$ | 500 | ||
C4a Planned Outage Notification Example: In each instance the Registry Operator fails to meet the
Performance Specifications for Notification and Timeframe related to Planned Outages and Extended
Planned Outages, the Registry Operator is subject to the credit in Table C4a. For example, the
Registry Operator informs the Registrar Community that it will initiate a Planned Outage of the SRS
on the next calendar Sunday (five (5) days advance notice). The corresponding Registry Operator’s
Performance Specification is 28 days notice. From the Credit Lookup Matrix, we see the relevant SLA
is found in Table C4a. This results in a credit of $500 USD to be paid to the Registrar Community.
Table C4b
| < 1 | 1-2 | |||||||||||||||||||||||
| SLE | hour | hours | 2-4 hours | 4-6 hours | 6-10 hours | over 10 hours | ||||||||||||||||||
Monthly Credit to
Registrar Community |
$ | 300 | $ | 750 | $ | 1,200 | $ | 2,500 | $ | 3,500 | $ | 4,000 | ||||||||||||
C4b Planned Outage Example: In a given Service Level Measurement Period, the actual duration
of a planned outage is 11 hours and 20 minutes for the SRS. The corresponding Registry Operator’s
Performance Specification is 8 hours per
month for the SRS. The SLE, therefore, is 3 hours and 20 minutes. From the Credit Lookup Matrix the
relevant SLA is found in Table C4b. The SLE time interval (2-4 hours) has a corresponding credit of
$1,200 USD to be paid to the Registrar Community.
3. Receipt of Credits. In order for Registrars to claim credits, the following procedure must be
followed:
3.1 Registry Operator shall perform the required measurements in order to obtain the total credits
associated with the applicable Service Level Measurement Period. Such measurements and associated
documentation shall be delivered by e-mail to each of the Registrars in the Registrar Community.
Such notice shall also include the total credit (if any) to be paid to the Registrar Community as a
result of any outages.
3.2 Receipt of Credit — When the above steps have been completed, the Registry Operator shall enter
in each Registrar’s account balance the amount of credit (if applicable) that can be used
immediately toward registrations in the Registry.
4. Obligations.
4.1 Except in the case of cross-network nameserver performance (which is not a subject of this
Service Level Agreement), Registry Operator will perform monitoring from internally located systems
as a means to verify that the conditions of the SLA are being met.
4.2 Upon written request, and at the sole expense of the requesting Registrar(s), Registry Operator
will retain an independent third party to be selected by Registry Operator with the consent of the
Registrar(s). The Registrar may, under reasonable terms and conditions, audit the reconciliation
records for the purposes of verifying measurements of the Performance Specifications. The
frequency of these audits will be no more than once yearly during the term of the agreement between
Registry Operator and the Registrar.
4.3 A Registrar must report each occurrence of alleged occasion of Unavailability of Core Services
to the Registry Operator customer service help desk in the manner required by the Registry Operator
(i.e., e-mail, fax, telephone) in order for an occurrence to be treated as Unavailable for purposes
of the SLE.
4.4 In the event that the Core Services are Unavailable to an individual Registrar, Registry
Operator will use commercially reasonable efforts to re-establish the affected Core Services for
such Registrar as soon as reasonably practicable. In the event that the Unavailability of Core
Services affects all Registrars, the Registry Operator is responsible for opening a blanket trouble
ticket and immediately notifying all Registrars of the trouble ticket number and details.
4.5 Both Registrar and the Registry Operator agree to use reasonable commercial good faith efforts
to establish the cause of any alleged Core Services Unavailability. If it is mutually determined to
be a Registry Operator problem, the issue will become part of the Unplanned Outage minutes.
4.6 The Registry Operator will use commercially reasonable efforts to restore the critical systems
of the Core Services within 24 hours after the termination of a force majeure event and restore
full system functionality within 48 hours after the termination of a force majeure event. Outages
due to a force majeure will not be considered Service Unavailability.
4.7 Incident trouble tickets must be opened within a commercially reasonable period of time.
5. Miscellaneous.
5.1 This Service Level Agreement is independent of any rights, obligations or
duties set forth in the Registry Agreement. In the event of any conflict between
the terms and conditions of this Agreement and the Registry Agreement, the Registry Agreement shall
control.
|
|
.BIZ Agreement Appendix 11 ..biz Registration Restrictions (8 December 2006) |
Restrictions
Registrations in the .biz TLD will be subject to the following restrictions:
1. Registrations in the .biz TLD must be used or intended to be used primarily for bona fide
business or commercial purposes; and
2. Registrations in the .biz TLD must comply with the Uniform Dispute Resolution Policy (“UDRP”),
as adopted and as may be amended by the Internet Corporation of Assigned Names and Numbers.
For purposes of the .biz Registration Restrictions (“Restrictions”), “bona fide business or
commercial use” shall mean the bona fide use or bona fide intent to use the domain name or any
content, software, materials, graphics or other information thereon, to permit Internet users to
access one or more host computers through the DNS:
1. To exchange goods, services, or property of any kind;
2. In the ordinary course of trade or business; or
3. To facilitate (i) the exchange of goods, services, information, or property of any kind; or,
(ii) the ordinary course of trade or business.
Registering a domain name solely for the purposes of (1) selling, trading or leasing the domain
name for compensation, or (2) the unsolicited offering to sell, trade or lease the domain name for
compensation shall not constitute a “bona fide business or commercial use” of that domain name.
For illustration purposes, the following shall not constitute a “bona fide business or commercial
use” of a domain name:
1. Using or intending to use the domain name exclusively for personal, noncommercial purposes; or
2. Using or intending to use the domain name exclusively for the expression of noncommercial ideas
(i.e., registering ▇▇▇▇▇▇▇▇.▇▇▇ exclusively to criticize or otherwise express an opinion on the
products or services of ABC company, with no other intended business or commercial purpose);
3. Using the domain name for the submission of unsolicited bulk e-mail, phishing, pharming or other
abusive or fraudulent purposes.
Violations
It will be a violation of the Restrictions for an Applicant to:
1. register and use a domain name contrary to the UDRP; or
2. use the registered domain name in a manner inconsistent with the definition of “business or
commercial use” contained herein.
Violations of the Restrictions may be grounds for cancellation of a registered .biz domain name,
pursuant to the enforcement mechanism discussed below.
Enforcement
A violation of the Restrictions will be enforced on a case-by-case, fact specific basis under the
processes set forth below:
1. Any allegation that a domain name is not used primarily for business or commercial purposes
shall be enforced under the provisions of the Restrictions Dispute Resolution Process (“RDRP”) as
set forth below.
2. Any alleged violation of the UDRP shall be enforced under the provisions contained therein.
Except as set forth in the “Reservation” clause below, none of the violations of the Restrictions
will be enforced directly by or through Registry Operator. The RDRP and UDRP will be made
applicable by the ICANN-Accredited Registrars’ registration agreements with registrants.
Proceedings under the RDRP and UDRP, must be brought by interested third parties in accordance with
the policies and procedures set forth below. Registry Operator will not review, monitor, or
otherwise verify that any particular domain name is being used primarily for business or commercial
purposes or that a domain name is being used in compliance with the UDRP process.
Registration Requirements
Before the Registry Operator will accept applications for registration, all domain name applicants
in the .biz TLD (“Applicants”) must:
1. Enter into an electronic or paper registration agreement with an ICANN-Accredited Registrar
(“Registrar”), in accordance with the ICANN Registrar Accreditation Agreement (“Accreditation
Agreement”) and the Registry-Registrar Agreement. Such electronic or paper registration agreement
shall include the following certifications:
a) The data provided in the domain name registration application is true, correct, up to date and
complete; and
b) The registrant will keep the information provided above up to date.
2. As part of a domain name registration application, the Applicant must certify that to the best
of its knowledge:
a) The registered domain name will be used in a manner consistent with the Restrictions above;
b) The domain name registrant has the authority to enter into the registration agreement; and
c) The registered domain name is reasonably related to the registrant’s business or intended
commercial purpose at the time of registration.
Failure to comply with the above will result in failure of the Registry Operator to process an
Applicant’s domain name application.
Reservation
Registry Operator reserves the right to deny, cancel, place on registry-lock or hold, or transfer
any registration that it deems necessary, in its discretion, (i) to protect the integrity and
stability of the registry, (ii) to comply with any applicable laws, government rules or
requirements, requests of law enforcement, (iii) in compliance with any dispute resolution process,
(iv) to enforce, at its sole discretion, any of the Restrictions above, or (vi) to avoid any
liability, civil or criminal, on the part of Registry Operator, as well as its affiliates,
subsidiaries, officers, directors and employees. Registry Operator also reserves the right to
freeze a domain name during resolution of a dispute.