|
Appendix D Registry-Registrar Agreement
Registry-Registrar Agreement
This Registry-Registrar Agreement (the "Agreement") is between
Public Interest Registry, a company organized under the laws of [jurisdiction],
with its principal place of business located at [location] ("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 .ORG
top-level domain;
WHEREAS, multiple Registrars will provide Internet domain name registration
services within the .ORG top-level domain;
WHEREAS, Registrar wishes to act as a Registrar for domain names within
the .ORG 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:
Back to top
1. DEFINITIONS
1.1. The "APIs" are the application
program interfaces by which Registrar may interact, through the RRP,
with the Registry System.
1.2. "Confidential Information"
means all information and materials, including, without limitation,
computer software, data, information, intellectual property, databases,
protocols, reference implementation and documentation, financial information,
statistics 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, including by email, within 15 days of the disclosure
that it is confidential.
1.3. "DNS" means the Internet
domain name system.
1.4. The "Effective Date" shall
be the date on which the Agreement is first executed by both parties.
1.5. "EPP" means the extensible
provisioning 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, hether consisting
of two or more (e.g., john.smith.name) 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. The "Registrar Tool Kit"
comprises the items described in Exhibit A.
1.11. "Registry Agreement" means
the Registry Agreement between Registry Operator and ICANN dated [date
of Registry Agreement] for the operation of the Registry TLD.
1.12. "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.13. "Registry TLD" means the
.ORG TLD.
1.14. "Registry Services" means
services provided as an integral part of the operation of the Registry
TLD, including all subdomains in which Registered Names are registered.
In determining whether a service is integral to the operation of the
Registry TLD, consideration will be given to the extent to which the
Registry Operator has been materially advantaged in providing the
service by its designation as such under this Agreement. The development
of technology, expertise, systems, efficient operations, reputation
(including identification as Registry Operator), financial strength,
or relationships with registrars and third parties shall not be deemed
an advantage arising from the designation. Registry Services include:
receipt of data concerning registration of domain names and nameservers
from registrars, provision to registrars of status information relating
to the Registry TLD, dissemination of TLD zone files, operation of
the Registry TLD zone servers, dissemination of contact and other
information concerning domain-name and nameserver registrations in
the Registry TLD.
1.15. The "Registry System" means
the system operated by Registry Operator for Registered Names in the
Registry TLD.
1.16. "RRP" means the registry-registrar
protocol used by the Registry System.
1.17. "Term" means the term of
this Agreement, as set forth in Subsection 9.1.
1.18. 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.
Back to top
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 Operator 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. No
later than three business days after the Effective Date, Registry
Operator shall provide to Registrar a copy of the Registrar Tool Kit,
which shall provide sufficient technical specifications to permit
registrar interface with the Registry System and employ its features
that are available to Registrars. Subject to the terms and conditions
of this Agreement, Registry Operator hereby grants Registrar and Registrar
accepts a non-exclusive, non-transferable, worldwide limited license
to use for the Term and purposes of this Agreement, all components
owned by or licensed to Registry Operator in and to the RRP, EPP,
APIs, any reference client software and any other intellectual property
included in the Registrar Tool Kit, as well as updates and redesigns
thereof, to provide 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 RRP, EPP, APIs, or
other software or materials licensed hereunder that will modify, revise
or augment the features of the Registry System. Registry Operator
will provide Registrar with at least ninety days notice prior to the
implementation of any material changes to the RRP, 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, 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.
2.7. Service Level Agreement. Registry
Operator shall issue credits to Registrar as described in Exhibit
G.
2.8. ICANN Requirements. Registry Operator's
obligations hereunder are subject to modification at any time as the
result of ICANN-mandated requirements and consensus policies. Notwithstanding
anything in this Agreement to the contrary, Registrar shall comply
with any such ICANN requirements in accordance with the timeline defined
by ICANN.
Back to top
3. Applicant's Business
Activities
3.1. Accredited Registrar. During the Term
of this Agreement, Registrar shall maintain 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, 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 holder
of the name. The initial 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 fourteen
(14) calendar 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 directors,
officers, employees and agents 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 that this indemnification obligation survive the termination
or expiration of the registration agreement.
3.5. 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.5.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; and
3.5.2. operational standards, policies,
procedures, and practices for the Registry TLD 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 E. 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.6. 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.7. 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 and that all data exchanged between Registrar's system
and the Registry System shall be protected to avoid unintended disclosure
of information. Registrar shall employ the necessary measures to prevent
its access to the Registry System granted hereunder from being used
to (i) 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 (ii) 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.
3.8. 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 RRP, EPP, the
APIs and the systems of Registry Operator in conjunction with Registrar's
systems. In the event of significant degradation of the Registry System
or other emergency, Registry Operator may, in its sole discretion,
temporarily suspend Registrar's 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.9. Time. 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.10. Change in Registrar Sponsoring Domain Name.
Registrar may assume sponsorship of a Registered Name Holder's existing
domain name registration from another registrar by following the policy
set forth in Exhibit D. When transferring sponsorship of a Registered
Name to or from another registrar, Registrar shall comply with the
requirements of Exhibit D.
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.
Back to top
4. FEES
4.1. Amount of Registry Operator Fees.
Registrar agrees to pay Registry Operator the fees set forth in Exhibit
F for initial and renewal registrations and other services provided
by Registry Operator to Registrar (collectively, "Fees").
Registry Operator reserves the right to revise the Fees prospectively
upon thirty days notice to Registrar, provided that such adjustments
are consistent with Registry Operator's Registry Agreement with ICANN.
4.2. Payment of Registry Operator Fees.
In advance of incurring Fees, Registrar shall establish a letter of
credit, deposit account, or other credit facility accepted by Registry
Operator, which acceptance will not be unreasonably withheld. Registry
Operator will invoice Registrar monthly in arrears for the Fees incurred
by Registrar in the month. All Fees are due immediately upon receipt
of Registry Operator's invoice pursuant to the letter of credit, deposit
account, or other credit facility.
4.3. Non-Payment of Fees. Registrar's timely
payment of Fees is a material condition of Registry Operator's obligations
under this Agreement. In the event that Registrar fails to pay its
Fees within five days of the date when due, Registry Operator may
do any or all of the following: (i) stop accepting new initial or
renewal registrations from Registrar; (ii) delete the domain names
associated with invoices not paid in full from the Registry database;
(iii) give written notice of termination of this Agreement pursuant
to Subsection 9.2.1; and (iv) pursue any other remedy under this Agreement.
4.4. Parity of ICANN Support Fees. Registry
Operator may pay Variable Registry-Level Fees to ICANN under Subsection
3.14.2 of its Registry Agreement with ICANN. In consideration of Registry-Operator's
payment of these fees, Registrar provides the following assurance
of parity of support of ICANN among TLDs: For any period in which
(i) Registry Operator pays ICANN Variable Registry-Level Fees for
the Registry TLD; (ii) Registrar is not required to pay ICANN an on-going
component of registrar accreditation fees for accreditation as a registrar
in the Registry TLD; (iii) the Registry Operators for the other TLDs
are not obligated by its Registry Agreement with ICANN to pay ICANN
Variable Registry-Level Fees; and (iv) Registrar is accredited by
ICANN as a registrar in the other TLDs, Registrar hereby gives its
express approval of an on-going component of its Registrar accreditation
fees for other TLDs that is equivalent, on a per-name basis, to the
Variable Registry-Level Fee paid by Registry Operator to ICANN with
respect to the Registry TLD.
Back to top
5. CONFIDENTIALITY AND
INTELLECTUAL PROPERTY
5.1. Use of Confidential Information. During
the Term of this Agreement, each party (the "Disclosing Party")
may 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 (i) is disclosed in the absence of a
confidentiality agreement and such disclosure was agreed to by the
Disclosing Party in writing prior to such disclosure; or (ii) is
or has entered the public domain through no fault of the Receiving
Party; or (iii) is known by the Receiving Party prior to the time
of disclosure; or (iv) is independently developed by the Receiving
Party without use of the Confidential Information; or (v) is made
generally available by the Disclosing Party without restriction
on disclosure.
5.1.7. The Receiving Party's duties under
this Subsection 5.1 shall expire two (2) years after the expiration
or termination of this Agreement or earlier, upon written agreement
of the parties.
5.2. Intellectual Property
5.2.1. Subject to the licenses granted
hereunder, 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.
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.
Back to top
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 or 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. Registry Operator
shall provide Registrar with prompt notice of any such claim, and
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 Registry Operator's 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. Representation and Warranty. Registrar
represents and warrants that: (i) it is a corporation duly incorporated,
validly existing and in good standing under the law of the state of
[________] (ii) it has all requisite corporate power and authority
to execute, deliver and perform its obligations under this Agreement,
(iii) the execution, performance and delivery of this Agreement has
been duly authorized by Registrar, and (iv) 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.
6.3. Limitation of Liability. IN NO EVENT
SHALL EITHER PARTY BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL,
PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES RESULTING
FROM LOSS OF PROFITS OR BUSINESS INTERRUPTION, ARISING OUT OF OR IN
CONNECTION WITH THIS AGREEMENT, EVEN IF THE OTHER PARTY HAS BEEN ADVISED
OF THE POSSIBILITY OF SUCH DAMAGES.
6.4. Disclaimer of Warranties. THE REGISTRAR
TOOL KIT IS 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 FUNCTIONS
CONTAINED IN THE REGISTRAR TOOL KIT WILL MEET REGISTRAR'S REQUIREMENTS,
OR THAT THE OPERATION OF THE REGISTRAR TOOL KIT WILL BE UNINTERRUPTED
OR ERROR-FREE, OR THAT DEFECTS IN THE REGISTRAR TOOL KIT WILL BE CORRECTED.
FURTHERMORE, REGISTRY OPERATOR DOES NOT WARRANT NOR MAKE ANY REPRESENTATIONS
REGARDING THE USE OR THE RESULTS OF THE REGISTRAR TOOL KIT OR RELATED
DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY,
OR OTHERWISE. SHOULD THE REGISTRAR TOOL KIT PROVE DEFECTIVE, REGISTRAR
ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION
OF REGISTRAR'S OWN SYSTEMS AND SOFTWARE.
Back to top
7. INSURANCE
7.1. Insurance Requirements. Registrar
shall acquire, prior to the Effective Date, at least US $1,000,000
in comprehensive general liability insurance from a reputable insurance
provider with an A.M. Best rating of "A" or better naming
Registry Operator as an additional insured and shall maintain insurance
meeting these requirements throughout the Term of this Agreement.
Registrar shall provide a copy of the insurance policy to Registry
Operator upon Registry Operator's reasonable request.
Back to top
8. DISPUTE RESOLUTION
8.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 State of Delaware, 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 the state or federal courts in the State of Delaware, 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 state or federal courts in the State
of Delaware, USA, which shall not be a waiver of this arbitration
agreement.
Back to top
9. TERM AND TERMINATION
9.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 last day of the calendar month which
is sixty months after the Effective Date. 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.
9.2. Termination. This Agreement may be
terminated as follows:
9.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.
9.2.2. Termination at Option of Registrar.
Registrar may terminate this Agreement at any time by giving Registry
Operator thirty days notice of termination.
9.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.
9.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 10.1.1.
9.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.
9.3. Effect of Termination. Upon the expiration
or termination of this Agreement for any reason:
9.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.
9.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.
9.3.3. All Confidential Information of
the Disclosing Party in the possession of the Receiving Party shall
be immediately returned to the Disclosing Party.
9.3.4. All fees owing to Registry Operator
shall become immediately due and payable.
9.4. Survival. In the event of termination
of this Agreement, the following shall survive: (i) Subsections 2.6,
3.6, 5.1, 5.2, 6.1, 6.3, 6.4, 8.1, 9.4, 10.2, 10.3, 10.4, 10.6, 10.7
and 10.8 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.
Back to top
10. MISCELLANEOUS
10.1. Assignments.
10.1.1. Assignment to Successor Registry
Operator. In the event the Registry Operator's Registry Agreement
is terminated 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.
10.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.
10.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.
10.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 such party has given a notice of a change
of address in writing:
If to Registrar:
with copy to:
If to Registry Operator:
Public Interest Registry
with a copy to:
10.3. 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 expressly
acknowledges that, notwithstanding anything in this Agreement to the
contrary, it is not an intended third-party beneficiary of the Registry
Agreement.
10.4. 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.
10.5. 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, 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.
10.6. Amendments. No amendment, supplement,
or modification of this Agreement or any provision hereof shall be
binding unless executed in writing by both parties.
10.7. 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.
10.8. 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.
10.9. Counterparts. All executed copies
of this Agreement are duplicate originals, equally admissible as evidence.
This Agreement may be executed in counterparts, and such counterparts
taken together shall be deemed the Agreement. A facsimile copy of
a signature of a party hereto shall have the same effect and validity
as an original signature.
Back to top
Exhibit A Registrar Toolkit
The Registrar Tool Kit will consist of a working Java API and samples
and C samples that can be used to implement the RRP (during the transition
period) and EPP protocol that is used to communicate between the Registry
System and Registrar. The samples will illustrate how XML requests (Registration
Events) can be assembled and forwarded to the Registry Operator for
processing. The software will provide the Registrar with the basis for
a reference implementation that conforms to the Registry-Registrar Protocol.
The software component of the Registrar Tool Kit will be based on static
XML requests.
The documentation will explain to the Registrar the details of the
protocol specification. It will describe the commands that need to be
sent to the Registry System in order to support domain registration
events, as well as the possible responses that may be returned by the
Registry Operator. The precise nature of the sequencing of commands,
as well as the payload that must be assembled and transmitted to the
Registry Operator, will be defined for each possible registration event.
The documentation will also describe the software that implements the
EPP Registry-Registrar protocol. This will consist of a description
of the software package hierarchy, and an explanation of the defined
objects and methods (including calling parameter lists, and expected
response behavior).
The Registrar Tool Kit will be licensed under the GNU Lesser General
Public License and this Agreement.
Back to top
Exhibit B Engineering and Customer
Service Support
Registrar will be provided with customer support services by the Registry
Operator of three types:
- Front line customer support
- Administrative/billing/financial support
- Technical support
Front Line Customer Support. The front
line support is the first point of contact for Registrar. Front line
support will be available on a 24/7 basis. This operation will be able
to answer general registrar questions. When the answer is not available
or Registrar is not satisfied with the answer, a service support case
is opened and a support ticket is issued. These support tickets are
escalated to either the technical support team or the administrative/financial/billing
support team depending on the nature of the problem.
Methods of contact that will be supported by customer support will
include: telephone, fax, postal mail and e-mail.
Administrative/Financial/Billing Support.
The administrative/financial/billing support team will deal with Registrar's
business, account management, financial and billing issues. Examples
that fall into these categories include:
- Registrar account balance inquiries
- Registrar low-balance warning notifications
- Crediting a Registrar's account after payment
- Legal issues related to the registry-registrar agreement
- Administrative issues for the acceptance of new registrars
The support team will have guidelines to ensure a conduit exists for
escalation to higher levels of registry management with respect to unresolved
administrative/billing/financial issues.
Technical Support. The technical support
team is responsible for dealing with Registrar's technical issues. Registry
Operator shall provide a package of support services through the Technical
Support Group (TSG). Overall, the TSG shall attempt to provide around
the clock, real time professional support to all registrars that have
entered into Registry-Registrar Agreements with Registry Operator, ranging
from basic inquiries to high-level operations critical technical support.
Registry Operator's operation staff shall be available 24/7, with required
members of the department on call. Escalation procedures shall be in
place, ensuring that management is notified of service outages in a
timely manner.
Access to Registry Data. The TSG shall
have access to Registry System data to support Registrar, to the extent
that current operating status can be determined, response to specific
Registrar queries about Registrar specific data or specific transactions
can be provided. Registry Operator employees shall be required to properly
identify the Registrar before providing any Registrar critical data,
and shall be prohibited from providing information about other Registrar
operations.
Notifications. The TSG shall be responsible
for notifying Registrar of upcoming maintenance and outages. At a minimum,
all planned outages and maintenance shall be announced at least 7 days
prior to the scheduled date. Further, the TSG shall be required to provide
immediate notice of unplanned or unscheduled outages and maintenance.
Customer Escalation Process. The TSG
will operate with a customer escalation process. Normally, support calls
or other forms of communication shall start with the lowest level of
support, and be escalated should the first level of support be insufficient.
In cases where higher levels of support are immediately apparent (all
levels of support staff will be trained in identifying these) the escalation
chain may be jumped. Also, should the time limit expire with no notice,
the support level may be escalated. The escalation levels and response
requirements are as follows:
Level 1 Technical based questions,
usually unique to the Registrar that may require support from a Registry
System operator or engineer. Requests for information or technical
support shall be provided within an hour unless is it deemed to be
a Level 2 incident.
Level 2 Registry System outages
involving non-critical operations to the registry affecting one or
more registrars only, but not the entire system. Response reports
shall be provided every 30 minutes, by no less than a qualified Registry
System engineer.
Level 3 Catastrophic outages, or
disaster recovery involving critical operations to the Registry System
overall. Response reports shall be provided every 15 minutes, by no
less than a senior Registry System engineer.
Level |
Incident Duration |
Severity |
Position |
Name |
After Hours Number |
Business Hours Number |
Level 1 |
1 hour |
Low |
Customer Support Supervisor |
TBH |
TBD
Cell Phone |
TBD |
Level 2 |
2 hours |
Med |
Operations Manager |
TBH |
TBD
Voice mail connected to pager. |
TBD |
Level 3 |
4 hours |
High |
General Manager |
TBH |
TBD
Voice mail connected to pager. |
TBD |
Security of Customer Support Service.
Registrar must supply a list of specific individuals (5 to 10 people)
that are authorized to contact the Registry Operator. Each individual
will also be assigned a pass phrase. Any phone requests made by Registrar
to Registry Operator's customer service will have to come from someone
on the authorized list, and require the pass phrase to be supplied.
In the event that an attempt is made to contact the Registry Operator's
customer service on behalf of Registrar, but appropriate authentication
is not provided, Registry Operator will make contact with Registrar
to inform it of a breach of security protocol.
Customer Satisfaction Surveys. In order
to fairly judge the quality of its customer services, Registry Operator
may hire an outside party to perform customer satisfaction surveys on
a regular basis. The result of these surveys will be used to identify
and correct problems with the customer service process. Registry Operator
will also use these results to measure improvements in customer satisfaction.
Back to top
Exhibit C Registrar's Registration
Agreement
[To be supplied by Registrar]
Back to top
Exhibit D Policy on Transfer of
Sponsorship of Registrations between Registrars
A. Holder-Authorized Transfers
Registrar Requirements
The registration agreement between each Registrar and its Registered
Name Holder shall include a provision explaining that a Registered
Name Holder will be prohibited from changing its Registrar during
the first 60 days after initial registration of the domain name with
the Registrar. Beginning on the 61st day after the initial registration
with the Registrar, the procedures for change in sponsoring registrar
set forth in this policy shall apply. Enforcement shall be the responsibility
of the Registrar sponsoring the domain name registration.
For each instance where a Registered Name Holder wants to change
its Registrar for an existing domain name (i.e., a domain name that
appears in a particular top-level domain zone file), the gaining Registrar
shall:
- Obtain express authorization from an individual who has the apparent
authority to legally bind the Registered Name Holder (as reflected
in the database of the losing Registrar).
- The form of the authorization is at the discretion of each
gaining Registrar.
- The gaining Registrar shall retain a record of reliable evidence
of the authorization.
- In those instances when the Registrar of record is being changed
simultaneously with a transfer of a domain name from one party to
another, the gaining Registrar shall also obtain appropriate authorization
for the transfer. Such authorization shall include, but not be limited
to, one of the following:
- A bilateral agreement between the parties.
- The final determination of a binding dispute resolution body.
- A court order.
- Request, by the transmission of a "transfer" command
as specified in the Registrar Tool Kit, that the Registry database
be changed to reflect the new Registrar.
- Transmission of a "transfer" command constitutes
a representation on the part of the gaining Registrar that:
- the requisite authorization has been obtained from the
Registered Name Holder listed in the database of the losing
Registrar, and
- the losing Registrar will be provided with a copy of
the authorization if and when requested.
In those instances when the Registrar of record denies the requested
change of Registrar, the Registrar of record shall notify the prospective
gaining Registrar that the request was denied and the reason for the
denial. Instances when the requested change of sponsoring Registrar
may be denied include, but are not limited to:
- Situations described in the Domain Name Dispute Resolution Policy.
- A pending bankruptcy of the Registered Name Holder.
- Dispute over the identity of the Registered Name Holder.
- Request to transfer sponsorship occurs within the first 60 days
after the initial registration with the Registrar.
In all cases, the losing Registrar shall respond to the e-mail notice
regarding the "transfer" request within five (5) days. Failure
to respond will result in a default "approval" of the "transfer."
Registry Requirements
Upon receipt of the "transfer" command from the gaining
Registrar, Registry Operator will transmit an e-mail notification
to both Registrars.
Registry Operator shall complete the "transfer" if either:
- the losing Registrar expressly "approves" the request,
or
- Registry Operator does not receive a response from the losing
Registrar within five (5) days.
When the Registry's database has been updated to reflect the change
to the gaining Registrar, Registry Operator will transmit an email
notification to both Registrars.
Records of Registration
Each Registered Name Holder shall maintain its own records appropriate
to document and prove the initial domain name registration date, regardless
of the number of Registrars with which the Registered Name Holder
enters into a contract for registration services.
Effect on Term of Registration
The completion by Registry Operator of a holder-authorized transfer
under this Part A shall result in a one-year extension of the existing
registration, provided that in no event shall the total unexpired
term of a registration exceed ten (10) years.
B. ICANN-Approved Transfers
Transfer of the sponsorship of all the registrations sponsored by one
registrar as the result of acquisition of that Registrar or its assets
by another Registrar may be made according to the following procedure:
- The gaining Registrar must be accredited by ICANN for the Registry
TLD and must have in effect a Registry-Registrar Agreement with Registry
Operator for the Registry TLD.
- ICANN must certify in writing to Registry Operator that the transfer
would promote the community interest, such as the interest in stability
that may be threatened by the actual or imminent business failure
of a Registrar.
Upon satisfaction of these two conditions, Registry Operator will make
the necessary one-time changes in the registry database for no charge,
for transfers involving 50,000 name registrations or fewer. If the transfer
involves registrations of more than 50,000 names, Registry Operator
will charge the gaining registrar a one-time flat fee of US$ 50,000.
Back to top
Exhibit E Registry Operator's Standards,
Policies, Procedures, and Practices
- Cancellation of Registered Names.
Registry Operator may transfer or cancel any Registered Name (i) for
violations of this Agreement and its Exhibits or (ii) to correct mistakes
made by Registry Operator or any Registrar in connection with a domain
name registration.
- Additional Requirements for Registration
Agreement. In addition to the provisions of Subsection 3.4,
in its registration agreement with each Registered Name Holder, Registrar
shall require such Registered Name Holder to:
- consent to the use, copying, distribution, publication, modification
and other processing of Registered Name Holder's Personal Data by
Registry Operator and its designees and agents in a manner consistent
with the purposes specified pursuant to Subsection 2.6;
- submit to proceedings commenced under ICANN's Uniform Domain
Name Dispute Resolution Policy ("UDRP")
- immediately correct and update the registration information for
the Registered Name during the registration term for the Registered
Name; and
- Additional Security. Each session
wherein Registrar accesses the Registry System shall be authenticated
and encrypted using two-way secure socket layer ("SSL")
protocol. At a minimum, Registrar shall authenticate every client
connection with the Registry System using both an X.509 server certificate
issued by a commercial certification authority identified by the Registry
Operator and its Registrar password. Registrar shall disclose only
its Registrar password to its employees with a need to know. Registrar
agrees to notify Registry Operator within four hours of learning that
its Registrar password has been compromised in any way or if its server
certificate has been revoked by the issuing certification authority
or compromised in any way.
- Updates to Registration Information.
Registrar shall submit any corrections or updates from a Registered
Name Holder relating to the registration information for a Registered
Name to Registry Operator in accordance with such timeline and specifications
as Registry Operator may develop.
- Transition Plan.
Operational Test & Evaluation
Before Registrar will be allowed to join the live registration environment,
they must first pass Operational Test and Evaluation ("OT&E")
certification.
The OT&E process has two main objectives:
- Verifying the correct operation of Registrar's client system, and
Registrar's capability to operate the interface with the Registry
System; and
- Establishing the contractual and business relationship between
Registrar and the Registry, in accordance with the Agreement.
The OT&E certification process will be available to all ICANN-accredited
registrars starting from the date described in Section 7 below.
Registrar will be required to pass certain tests to be eligible to
go live. All tests performed during OT&E certification must be completed
without errors. Registry Operator will provide the certification results
in a timely manner and provide feedback if Registrar fails to successfully
complete the tests. Registrar may correct its systems and re-schedule
for certification. Registrar will not be limited in the number of attempts
at OT&E certification. Upon successful OT&E certification, Registrar
becomes eligible for operation in the live registration environment.
Back to top
Exhibit F Registration Fees
- Domain-Name Initial Registration Fee
Registry Operator will charge US $6.00 per year for each domain name
registered (the "Initial Registration Fee") in the Registry
TLD. The Initial Registration Fee shall be paid in full by Registrar
sponsoring the domain name at the time of registration.
- Domain-Name Renewal Fee
Registry Operator will charge US $6.00 per year for each domain name
registration renewal (the "Renewal Fee") in the Registry TLD.
The Renewal Fee shall be paid in full by Registrar sponsoring the domain
name at the time of renewal.
- Fees for Transfers of Sponsorship of Domain-Name
Registrations
Where the sponsorship of a domain name is transferred from one ICANN-Accredited
Registrar to another ICANN-Accredited Registrar, Registry Operator will
require the registrar receiving the sponsorship to request a renewal
of one year for the name. In connection with that extension, Registry
Operator will charge a Renewal Fee for the requested extension as provided
in item 2 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.
- ICANN Variable Fees
The pricing for initial and renewal registrations set forth above shall
be adjusted pursuant to Section 3.14.5 of the Registry Agreement between
Registry Operator and ICANN.
- Bulk Transfer Fee
For a bulk transfer approved by ICANN under Part B of Exhibit D, Registry
Operator will charge the gaining registrar US $0 (for transfer of 50,000
names or fewer) or US $50,000 (for transfers of more than 50,000 names).
Back to top
Exhibit G Service Level Agreement
- Definitions Capitalized terms used
herein and not otherwise defined shall have the meaning ascribed to
them in the Registry-Registrar Agreement.
1.1 "Current Pricing Level" refers
to prices charged for Registry Services as provided in Appendix G
of the Registry Agreement as adjusted pursuant to Subsections 3.14.5
and 4.4 of the Registry Agreement.
1.2 "C1" means Category 1, a
mission critical service.
1.3 "C2" means Category 2, a
mission important service.
1.4 "C3" means Category 3, a
mission beneficial service.
1.5 "Degraded Performance" means
a service not meeting the performance requirement set forth in this
document. Round-trip time is used as the basis of this metric for
all services except nameservice; for nameservice packet loss and Round-trip
time are used as metrics.
1.6 "Monthly Timeframe" shall
mean each single calendar month beginning and ending at 00:00 the
Coordinated Universal Time (UTC).
1.7 "Monthly Unplanned Outage Time"
shall be the sum of minutes of all Unplanned Outage Time during the
Monthly Timeframe. Each minute of Unplanned Outage Time subtracts
from the available Monthly Planned Outage Time up to four (4) hours.
1.8 "Not Responding" means a
service will be deemed as "Not Responding" in the event
that the Network/Application Monitoring Service responds with a negative
or degraded service response.
1.9 "Planned Outage" means the
periodic pre-announced occurrences when the System will be taken out
of service for maintenance or care. Planned Outages will be scheduled
only during the following window period of time each week, 01:00 to
09:00 UTC on Sunday (the "Planned Outage Period"). This
Planned Outage Period may be changed from time to time by the Registry
Operator, in its sole discretion, upon prior notice to each Registrar.
Planned Outages will not exceed four (4) hours/per calendar week beginning
at 00:00 UTC Monday nor total more than eight (8) hours/per calendar
month. Planned Outage for a nameserver shall not coincide with or
overlap Planned Outage for any other nameserver. Notwithstanding the
foregoing, in each calendar year Registry Operator may incur one (1)
additional Planned Outage of up to eight (8) hrs in duration during
the Planned Outage Period for major systems or software upgrades ("Extended
Planned Outages"). This Extended Planned Outage represents the
total allowed Planned Outages for the month.
1.10 "Round-trip" means the amount
of measured time that it takes for a reference query to make a complete
trip from the sampling agent, to the system or process being tested
and back again. Usually measured in milliseconds.
1.11 "Service Availability" means
when the System is operational and predictably responding in a commercially
reasonable manner. By definition, this does not include Planned Outages
or Extended Planned Outages.
1.12 "Service Unavailability"
means when, as a result of a failure of systems within the Registry
Operator's control,
1.12.1 with respect to services other
than Whois Service and nameservice, Registrar is unable to establish
a session with the System gateway which shall be defined as:
1.12.1.1 successfully complete a TCP
session start,
1.12.1.2 successfully complete the
SSL authentication handshake, and
1.12.1.3 successfully complete the
Extensible Provisioning Protocol ("EPP") <login>
command.
1.12.2 With respect to all services,
system monitoring tools register three (3) consecutive monitoring
failures on any of the components listed in Section 2 - System Services.
1.13 "SLA" means this Service
Level Agreement between Registry Operator and Registrar.
1.14 "SLA Credit" means those
credits available to the Registrar pursuant to the SLA.
1.15 "System" shall mean the
list of components listed in Section 2 - System Services.
1.16 "Transaction" shall mean
chargeable Registry Services, which includes initial and renewal registrations.
1.17 "Unplanned Outage Time"
shall mean all of the following:
1.17.1 With respect to services other
than Whois Service and nameserver resolution, the amount of time
recorded between a trouble ticket first being opened by the Registry
Operator in response to a Registrar's claim of Service Unavailability
for that Registrar through the time when the Registrar and Registry
Operator agree the Service Unavailability has been resolved with
a final fix or a temporary work around, and the trouble ticket has
been closed. This will be considered Service Unavailability only
for those individual Registrars impacted by the outage;
1.17.2 With respect to services other
than Whois Service and nameserver resolution, the amount of time
recorded between a trouble ticket first being opened by the Registry
Operator in the event of Service Unavailability that affects all
Registrars through the time when the Registry Operator resolves
the problem with a final fix or a temporary work around, and the
trouble ticket has been closed;
1.17.3 With respect to all services,
the amount of time that Planned Outage time exceeds the limits established
in Section 1.10 above; or
1.17.4 With respect to all services,
the amount of time that Planned Outage time occurs outside the window
of time established in Section 1.10 above.
1.18 "Whois Service" means the
Registry Operator Whois Services described in Appendix O of the Registry
Agreement.
- System Services
The following table lists, by category (C1, C2, or C3), the Registry
System services for which availability and performance requirements
are established. Services shall meet availability requirements according
to their category, as listed in the "Cat." column below.
In addition, various services must meet the performance requirements
listed in the "Perf." column below. These availability and
performance requirements are the subject of the SLA between Registry
Operator and Registrars.
Component/Service |
Cat. |
Perf. |
DNS |
|
|
AXFR/IXFR Update
|
C3 |
P5 |
Billing |
|
|
Account balance check/modify
|
C2 |
|
Manual balance adjust
|
C3 |
|
Admin |
|
|
Update Registrar profile
|
C3 |
|
Update Registrar status
|
C3 |
|
Protocol Interface |
|
|
Add/Renew/Delete/ Update
|
C1 |
P1 |
Transfer
|
C1 |
P6 |
Check
|
C1 |
P2 |
- Service Levels (Availability and Performance)
C1
|
Total duration of Unplanned Outage Time of C1 class
services must not exceed 30 minutes per Monthly Timeframe. This
represents a Service Availability percentage of 99.93%. |
Total duration of Service Unavailability of C1 class
services must not exceed 60 minutes per Monthly Timeframe. This
represents a Service Availability percentage of 99.86%. |
C2
|
Total duration of Unplanned Outage Time of C2 class
services must not exceed 90 minutes per monthly Timeframe. This
represents a Service Availability percentage of 99.79%. |
Total duration of all Service Unavailability of
C2 class services must not exceed 180 minutes per Monthly Timeframe.
This represents a Service Availability percentage of 99.65%. |
C3
|
Total duration of Unplanned Outage Time of C3 class
services must not exceed 300 minutes per Monthly Timeframe. This
represents a Service Availability percentage of 99.30%. |
Total duration of all Service Unavailability of
C3 class services not to exceed 600 minutes per Monthly Timeframe.
This represents a Service Availability percentage of 98.61%. |
P1
|
For a single-entity payload, Round-trip time should
not exceed 800ms as measured by the system monitoring tools that
simulates a representative registrar. A request with a multiple
entity payload should materially perform consistent with the behavior
of multiple, single entity payload operation. |
P2
|
For a single-entity payload, Round-trip time should
not exceed 400ms as measured by the system monitoring tools that
simulates a representative registrar. A request with a multiple-entity
payload should materially perform consistent with the behavior
of multiple, single entity payload operation. |
P5
|
See Subsection 5.14 below. |
P6
|
For a single-entity payload, Round-trip time should
not exceed 1600 ms as measured by the system monitoring tools
that simulates a representative registrar. A request with a multiple-entity
payload should materially perform consistent with the behavior
of multiple, single entity payload operation. |
- Credits
4.1 C1 If availability of C1 class
services does not meet C1 Service Levels in any given calendar month,
Registry Operator will credit Registrar according to this calculation;
C = (amv/t)*sle
Where:
C |
=
|
number of Transactions to be credited
to Registrar for the calendar month. |
amv |
=
|
average month's volume (previous four calendar
months total Transaction volume/4 months) |
t |
=
|
time period, number of minutes per month averaged
over number of days in previous four calendar months (for example,
if previous four months had 30, 31, 30, 31 days, these time
period = (30 + 31 + 30 + 31)/4 * 24 hours * 60 minutes = 43,920
minutes) |
sle |
=
|
service level exception, the number of Unavailable
minutes minus the number of SLA acceptable Unavailable minutes |
Example:
Registry Operator records 15 minutes of service level exception
beyond the time periods contemplated by the SLA. The current amv
is 30,000 total names registered and time period was 43,920 minutes.
As such, Registry Operator will credit Registrar for 10.25 Transactions
at the then Current Pricing Level.
4.2 C2 If availability of C2 class
services does not meet C2 Service Levels in any given calendar month,
Registry Operator will credit Registrar according to this calculation;
C = (amv/t)*sle * 60%
Where:
C |
=
|
number of Transactions to be credited
to Registrar for the calendar month |
amv |
=
|
average month's volume (previous four calendar
months total Transaction volume/4 months) |
t |
=
|
time period, number of minutes per month averaged
over number of days in previous four calendar months (see example
in Subsection 4.1) |
sle |
=
|
service level exception, the number of Unavailable
minutes minus the number of SLA acceptable Unavailable minutes |
60% |
=
|
priority adjustment |
Example:
Registry Operator records 15 minutes of service level exception
beyond the time periods contemplated by the SLA. The current amv
is 30,000 total names registered and time period was 43,920 minutes.
As such, Registry Operator will credit Registrar for 6.15 Transactions
at the then Current Pricing Level.
4.3 C3 If availability of C3 services
does not meet C3 Service Levels in any given calendar month, Registry
Operator will credit Registrar according to this calculation;
C = (amv/t)*sle * 30%
Where:
C |
=
|
number of Transactions to be credited to Registrar
for the calendar month |
amv |
=
|
average month's volume (previous four calendar
months total Transaction volume/4 months) |
t |
=
|
time period, number of minutes per month averaged
over number of days in previous four calendar months (see example
in Subsection 4.1) |
sle |
=
|
service level exception, the number of Unavailable
minutes minus the number of SLA acceptable Unavailable minutes |
30% |
=
|
priority adjustment |
Example:
Registry Operator records 15 minutes of service level exception
beyond the time periods contemplated by the SLA. The current amv
is 30,000 total names registered and the time period was 43,920
minutes. As such, Registry Operator will credit Registrar for 3.07
Transactions at the then Current Pricing Level.
4.4 Degraded Performance If the
performance of the transactive systems (OpenXRS API, Whois) does
not meet the performance expectations outlined in Service Levels
over the calendar month in question, Registry Operator will credit
Registrar according to this calculation;
C = (amv/t)*sle * 7.5%
Where:
C |
=
|
number of Transactions to be credited to Registrar
for the calendar month |
amv |
=
|
average month's volume (previous four calendar
months total Transaction volume/4 months) |
t |
=
|
time period, number of minutes per month averaged
over number of days in previous four calendar months (see example
in Subsection 4.1) |
sle |
=
|
service level exception, the number of Degraded
Performance minutes |
7.5% |
=
|
priority adjustment |
Example:
Registry Operator records 15 minutes of service level exception
beyond the time periods contemplated by the SLA. The current amv
is 30,000 total names registered and time period was 43,920 minutes.
As such, Registry Operator will credit Registrar for 0.77 Transactions
at the then Current Pricing Level.
4.5 Receipt of Credits In order
for registrars to claim credits, the following procedure must be
followed:
4.5.1 Issue a Request for SLA Credits.
The claiming registrar must make a request for credits to Registry
Operator claiming that it experienced downtime or degraded performance
in excess of what is outlined in this Exhibit.
4.5.2 Provide documentation to indicate
SLA Violation.
A Registrar may provide documentation in the form of either:
4.5.2.1 Registrar initiated notification(s)
to the Registry Operator of a down time that exceeded SLA limits,
including the trouble ticket number issued by the Registry Operator.
The closing ticket(s) should be included as well in order to
determine the total downtime (unless the closing ticket includes
this); or
4.5.2.2 Notification from the Registry
Operator (with trouble ticket number attached) of down time
or Degraded Performance. The closing ticket(s) should be included
as well in order to determine the total downtime (unless the
closing ticket includes this).
4.5.3 Justification of Volume.
In order to calculate credits, the Registrar should include volume
figures for the past four (4) calendar months, and a certification
that these numbers accurately reflect the LEAST registration activity
that would be covered during the affected SLA outage.
4.5.4 Receipt of Credit.
When the above steps have been completed to the Registry Operator's
satisfaction, the Registry Operator shall provide notification
of the number of credits that will be entered in the Registrar's
account balance and that can be used immediately toward registrations
in the Registry.
- Responsibilities of the Parties
5.1 Registrar will assist Registry Operator
by reporting each occurrence of alleged Service Unavailability to
Registry Operator customer service help desk in the manner required
by Registry Operator (i.e., e-mail, fax or telephone) in order for
an occurrence to be treated as Service Unavailability for purposes
of this SLA. Registry Operator will treat all system performance problems
in order of decreasing severity and fix them within a commercially
reasonable period of time. Incidents flagged by the measurement system
will also qualify as ticketed events and will be classed as Unavailability.
5.2 Registry Operator will perform monitoring
from internally located systems as a means to verify that the conditions
of the SLA are being met.
5.3 The SLA will be reconciled on a quarterly
basis.
5.4 The Registrar will have the option
to choose which of the credit calculations described in Subsection
4 of this SLA will apply where service level credit overlaps occurs.
There can be several types of credits over the same calendar month,
but the Registrar can only claim one type of refund for each event.
5.5 Registry Operator will not attempt
to discern what discount levels were in effect at the specific time
of a service level exception, but rather use the discount level in
effect at the time the credits issue. All service level credits will
be paid out using the appropriate discounts and rate levels reflected
by the then current rate schedule.
5.6 The Registrar may, under reasonable
terms and conditions, audit the reconciliation records for the purposes
of verifying service level performance. The frequency of these audits
will be no more than once every six month period during the term of
the Registry-Registrar Agreement between Registry Operator and the
Registrar.
5.7 Registry Operator's obligations under
this SLA are waived during the first 120 days after the Commencement-of-Service
Date.
5.8 Incident trouble tickets must be opened
within a commercially reasonable period of time.
5.9 In the event that Service Unavailability
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.
5.10 Both Registrar and the Registry Operator
agree to use reasonable commercial good faith efforts to establish
the cause of any alleged Service Unavailability. If it is mutually
determined to be a Registry Operator problem, the issue will become
part of the Unplanned Outage Time.
5.11 Registrars must inform the Registry
Operator any time their estimated volume of transactions (excluding
check domain commands), will exceed their previous calendar month's
volume by more than 25%. In the event that a Registrar fails to inform
Registry Operator of a forecasted increase of volume of transactions
of 25% or more and the Registrar's volume increases 25% or more over
the previous month, and should the total volume of transactions added
by the Registry Operator for all Registrars for that month exceed
the Registry Operator's actual volume of the previous month's transactions
by more than 20%, then the Registrar(s) failing to give such notice
will not be eligible for any SLA Credits in that Monthly Timeframe.
Registrars shall provide their forecasts at least 30 days prior to
the first day of the next calendar month. In addition, the Registry
Operator agrees to provide monthly transaction summary reports starting
no later than 120 days after the Commencement-of-Service Date.
5.12 The Registry Operator will notify
Registrar of Planned Outages outside the Planned Outage Period at
least 7 days in advance of such Planned Outage. In addition, Registry
Operator will use reasonable commercial good faith efforts to maintain
an accurate 30 day advance schedule of possible upcoming Planned Outages.
5.13 The Registry Operator will update
the Whois Service on a near real-time basis. During normal operation,
all registration and information updates sent from a Registrar to
the Registry are stored in the primary database (database A). The
information in database A is replicated to a backup database (database
B) at regular intervals, normally within five (5) minutes. The Whois
service uses database B as its source of information. The time lag
in the Whois information update is determined by the database replication
interval. The Registry Operator will notify Registrars in advance
when changes to the Whois Service update schedule occur.
5.14 The Registry Operator will initiate
the addition, deletion or other modification of DNS zone information
to the master DNS server within 5 minutes of a Transaction. The Registry
Operator will notify Registrar in advance when changes to the schedule
occur. The Registry Operator will notify Registrars regarding any
scheduled maintenance and unavailability of the TLD root-servers.
5.15 The Registry Operator will use commercially
reasonable efforts to restore the critical systems of the System within
24 hours in the event of a force majeure and restore full system functionality
within 48 hours. Outages due to a force majeure will not be considered
Service Unavailability.
5.16 Beginning no later than 120 days after
the Commencement-of-Service Date, the Registry Operator will publish
preliminary weekly system performance and availability reports. Registry
Operator will use best efforts to finalize these reports no later
than 30 days after the preliminary reports are provided.
5.17 The Registry Operator will provide
Service Availability percentages during each Monthly Timeframe as
listed in Section 3 - Service Levels of this Exhibit.
- Miscellaneous
6.1 This Exhibit is not intended to replace
any term or condition in the Registry-Registrar Agreement.
6.2 Dispute Resolution will be handled
pursuant to the arbitration provisions of the Registry-Registrar
Agreement.
Back to top
|