2013 Registrar Accreditation Agreement

Note: The English language version of this Agreement (and all referenced specifications) is the official and controlling version and translations are provided for reference only. This version was updated with minor corrections to conform to the version signed by registrars. Please see here for the redline document showing changes made on 7 January 2019.

PDF Download

NOTE: Section 3.10 of this agreement, regarding registrar insurance was waived by the ICANN Board of Directors, effective 28 September 2015. For additional information about this waiver, see the ICANN blog (https://www.icann.org/news/blog/icann-waives-registrar-insurance-requirement-levels-playing-field-for-registrars-globally) and the RAA Insurance Waiver FAQs [https://www.icann.org/resources/pages/raa-insurance-faqs-2015-09-30-en].

This REGISTRAR ACCREDITATION
AGREEMENT (this “Agreement”) is by and between the Internet Corporation for
Assigned Names and Numbers, a California non-profit, public benefit corporation
(“ICANN”), and [Registrar Name], a [Organization type and jurisdiction]
(“Registrar”), and shall be deemed made on ________________, at Los Angeles,
California, USA.

DEFINITIONS. For purposes of this
Agreement, the following definitions shall apply:

1.1 “Account Holder” means the person or entity that is paying for the
Registered Name or otherwise controls the management of the registered name,
when that person or entity is not the Registered Name Holder.

1.2 “Accredited” or “Accreditation” means to identify and set minimum
standards for the performance of registration functions, to recognize persons
or entities meeting those standards, and to enter into an accreditation
agreement that sets forth the rules and procedures applicable to the provision
of Registrar Services.

1.3 “Affiliate” means a person or entity that, directly or indirectly,
through one or more intermediaries, Controls, is controlled by, or is under
common control with, the person or entity specified.

1.4 “Affiliated Registrar” is another Accredited registrar that is an
Affiliate of Registrar.

1.5 “Applicable Registrar Family” means, with respect to Affiliated
Registrars, such Affiliated Registrar as a group.

1.6 “Consensus Policy” has the meaning set forth in the Consensus Policies
and Temporary Policies Specification attached hereto.

1.7 “Control” (including the terms “controlled by” and “under common control
with”) means the possession, directly or indirectly, of the power to direct or
cause the direction of the management or policies of a person or entity,
whether through the ownership of securities, as trustee or executor, by serving
as an employee or a member of a board of directors or equivalent governing body,
by contract, by credit arrangement or otherwise.

1.8 “DNS” refers to the Internet domain-name system.

1.9 The “Effective Date” is ________________.

1.10 The “Expiration
Date” is ________________.

1.11 “gTLD” or
“gTLDs” refers to the top-level domain(s) of the DNS delegated by ICANN
pursuant to a registry agreement that is in full force and effect, other than
any country code TLD (ccTLD) or internationalized domain name (IDN) country
code TLD.

1.12 “gTLD Zone-File
Data” means all data contained in a DNS zone file for the registry, or for any
subdomain for which Registry Services are provided and that contains Registered
Names, as provided to nameservers on the Internet.

1.13 “Illegal
Activity” means conduct involving use of a Registered Name sponsored by
Registrar that is prohibited by applicable law and/or exploitation of
Registrar’s domain name resolution or registration services in furtherance of
conduct involving the use of a Registered Name sponsored by Registrar that is
prohibited by applicable law.

1.14 “Personal Data”
refers to data about any identified or identifiable natural person.

1.15 “Registered
Name” refers to a domain name within the domain of a gTLD, whether consisting
of two (2) or more (e.g., john.smith.name) levels, about which a gTLD Registry
Operator (or an Affiliate or subcontractor thereof 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 zone file
(e.g., a registered but inactive name).

1.16 “Registered Name
Holder” means the holder of a Registered Name.

1.17 The word
“registrar,” when appearing without an initial capital letter, refers to a
person or entity that contracts with Registered Name Holders and with a
Registry Operator and collects registration data about the Registered Name
Holders and submits registration information for entry in the Registry
Database.

1.18 “Registrar
Approval” means the receipt of either of the following approvals:

1.18.1 The affirmative approval of Applicable Registrars accounting for 90% of
the Total Registered Names Under Management by the Applicable Registrars;
provided that, for purposes of calculating the Total Registered Names Under
Management by Applicable Registrars, the Total Registered Names Under
Management by each Applicable Registrar Family shall not exceed the Total
Registered Names Under Management of the Applicable Registrar Family that is
the fifth largest Applicable Registrar Family (measured by number of Registered
Names Under Management), both for purposes of the numerator and the
denominator; or

1.18.2 The affirmative approval of 50% plus one of the Applicable Registrars
that participate in the process to approve or disapprove (i.e. vote for or
against, but not abstain or otherwise fail to vote) a proposed amendment under
Section 6, and the affirmative approval of Applicable Registrars
accounting for 66.67% of the Total Registered Names Under Management by all
Applicable Registrars; provided that, for purposes of calculating the Total
Registered Names Under Management by Applicable Registrars, the Total
Registered Names Under Management by each Applicable Registrar Family shall not
exceed the total Registered Names Under Management of the Applicable Registrar
Family that is the fifth largest Applicable Registrar Family (measured by
number of Registered Names Under Management), both for purposes of the
numerator and the denominator. An example of these calculations is set forth
in Appendix 1 attached hereto.

1.19 “Registrar
Services” means the services subject to this Agreement provided by a registrar
in connection with a gTLD, and includes contracting with Registered Name
Holders, collecting registration data about the Registered Name Holders, and
submitting registration information for entry in the Registry Database.

1.20 “Registry Data”
means all Registry Database data maintained in electronic form, and shall
include gTLD Zone-File Data, all data used to provide Registry Services and
submitted by registrars in electronic form, and all other data used to provide
Registry Services concerning particular domain name registrations or
nameservers maintained in electronic form in a Registry Database.

1.21 “Registry
Database” means a database comprised of data about one or more DNS domain names
within the domain of a registry 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.22 A “Registry
Operator” is the person or entity then responsible, in accordance with an
agreement between ICANN (or its assignee) and that person or entity (those
persons or entities) or, if that agreement is terminated or expires, in
accordance with an agreement between the US Government and that person or
entity (those persons or entities), for providing Registry Services for a
specific gTLD.

1.23 “Registry
Services,” with respect to a particular gTLD, shall have the meaning defined in
the agreement between ICANN and the Registry Operator for that gTLD.

1.24 A “Reseller” is
a person or entity that participates in Registrar’s distribution channel for
domain name registrations (a) pursuant to an agreement, arrangement or
understanding with Registrar or (b) with Registrar’s actual knowledge, provides
some or all Registrar Services, including collecting registration data about
Registered Name Holders, submitting that data to Registrar, or facilitating the
entry of the registration agreement between the Registrar and the Registered
Name Holder.

1.25 “Restricted
Amendment” means (i) an amendment of the Consensus Policies and Temporary
Policies Specification or (ii) the term of this Agreement as specified in
Section 5.1, as such term may be extended pursuant to Section 5.2.

1.26 A Registered
Name is “sponsored” by the registrar that placed the record associated with
that registration into the registry. Sponsorship of a registration may be
changed at the express direction of the Registered Name Holder or, in the event
a registrar loses Accreditation, in accordance with then-current ICANN
Specifications and Policies.

1.27 “Specifications
and/or Policies” include Consensus Policies, Specifications (such as the Whois
Accuracy Program Specification) referenced in this Agreement, and any
amendments, policies, procedures, or programs specifically contemplated by this
Agreement or authorized by ICANN’s Bylaws.

1.28 “Term of this
Agreement” begins on the Effective Date and continues to the earlier of (a) the
Expiration Date, or (b) termination of this Agreement.

1.29 “Total
Registered Names Under Management” means the total number of Registered Names
sponsored by all Applicable Registrars as reflected in the latest monthly
reports submitted to ICANN by Registrars.

1.30 “Whois Accuracy
Program Specification” means the Whois Accuracy Program Specification attached
hereto, as updated from time to time in accordance with this Agreement.

1.31 “Whois
Specification” means the Registration Data Directory Service (Whois)
Specification attached hereto, as updated from time to time in accordance with
this Agreement.

1.32 “Working Group”
means representatives of the Applicable Registrars and other members of the
community that the Registrar Stakeholder Group appoints, from time to time, to
serve as a working group to consult on amendments to the Applicable Registrar
Agreements (excluding bilateral amendments pursuant to Section 6.9).

ICANN OBLIGATIONS.

2.1 Accreditation. During the Term of this Agreement and
subject to the terms and conditions of this Agreement, Registrar is hereby
Accredited by ICANN to act as a registrar (including to insert and renew
registration of Registered Names in the Registry Database) for gTLDs.

2.2 Registrar Use of ICANN Name, Website and Trademarks. ICANN
hereby grants to Registrar a non-exclusive, worldwide, royalty-free license
during the Term of this Agreement (a) to state that it is Accredited by ICANN
as a registrar for gTLDs, and (b) to link to pages and documents within the
ICANN website. Subject to the terms and conditions set forth in the Logo
License Specification attached hereto, ICANN hereby grants to Registrar a
non-exclusive, worldwide right and license to use the Trademarks (as defined in
the Logo License Specification). No other use of ICANN’s name, website or
Trademarks is licensed hereby. This license may not be assigned or sublicensed
by Registrar to any other party, including, without limitation, any Affiliate
of Registrar or any Reseller.

2.3 General Obligations of ICANN. With respect to all matters
that impact the rights, obligations, or role of Registrar, ICANN shall during
the Term of this Agreement:

2.3.1 exercise its responsibilities in an open and transparent manner;

2.3.2 not unreasonably restrain competition and, to the extent feasible,
promote and encourage robust competition;

2.3.3 not apply standards, policies, procedures or practices arbitrarily,
unjustifiably, or inequitably and not single out Registrar for disparate
treatment unless justified by substantial and reasonable cause; and

2.3.4 ensure, through its reconsideration and independent review policies,
adequate appeal procedures for Registrar, to the extent it is adversely
affected by ICANN standards, policies, procedures or practices.

2.4 Use of ICANN Accredited Registrars. In order to promote
competition in the registration of domain names, and in recognition of the
value that ICANN-Accredited registrars bring to the Internet community, ICANN
has ordinarily required gTLD registries under contract with ICANN to use
ICANN-Accredited registrars, and ICANN will during the course of this agreement
abide by any ICANN adopted Specifications or Policies requiring the use of
ICANN-Accredited registrars by gTLD registries.

REGISTRAR OBLIGATIONS.

3.1 Obligations to Provide Registrar Services. During the Term
of this Agreement, Registrar agrees that it will operate as a registrar for one
or more gTLDs in accordance with this Agreement.

3.2 Submission of Registered Name Holder Data to Registry.
During the Term of this Agreement:

3.2.1 As part of its registration of Registered Names in a gTLD, Registrar
shall submit to, or shall place in the Registry Database operated by, the
Registry Operator for the gTLD the following data elements:

3.2.1.1 The name of the Registered Name being registered;

3.2.1.2 The IP addresses of the primary nameserver and secondary nameserver(s)
for the Registered Name;

3.2.1.3 The corresponding names of those nameservers;

3.2.1.4 Unless automatically generated by the registry system, the identity of
the Registrar;

3.2.1.5 Unless automatically generated by the registry system, the expiration
date of the registration; and

3.2.1.6 Any other data the Registry Operator requires be submitted to it.

The agreement between the Registry
Operator of a gTLD and Registrar may, if approved by ICANN in writing, state
alternative required data elements applicable to that gTLD, in which event, the
alternative required data elements shall replace and supersede Subsections
3.2.1.1 through 3.2.1.6 stated above for all purposes under this Agreement but
only with respect to that particular gTLD. When seeking approval for
alternative required data elements, the data elements set forth in Subsections
3.2.1.1 through 3.2.1.6 should be considered suggested minimum requirements.

3.2.2 Within seven (7) days after receiving any updates from the Registered
Name Holder to the data elements listed in Subsections 3.2.1.2, 3.1.2.3, and
3.2.1.6 for any Registered Name that Registrar sponsors, Registrar shall submit
the updated data elements to, or shall place those elements in the Registry
Database operated by, the relevant Registry Operator.

3.2.3 In order to allow reconstitution of the Registry Database in the event
of an otherwise unrecoverable technical failure or a change in the designated
Registry Operator, within ten (10) days of any such request by ICANN, Registrar
shall submit an electronic database containing the data elements listed in
Subsections 3.2.1.1 through 3.2.1.6 for all active records in the registry
sponsored by Registrar, in a format specified by ICANN, to the Registry
Operator for the appropriate gTLD.

3.3 Public Access to Data on Registered Names. During the Term
of this Agreement:

3.3.1 At its expense, Registrar shall provide an interactive web page and,
with respect to any gTLD operating a “thin” registry, a port 43 Whois service
(each accessible via both IPv4 and IPv6) providing free public query-based
access to up-to-date (i.e., updated at least daily) data concerning all active
Registered Names sponsored by Registrar in any gTLD. Until otherwise specified
by a Consensus Policy, such data shall consist of the following elements as
contained in Registrar’s database:

3.3.1.1 The name of the Registered Name;

3.3.1.2 The names of the primary nameserver and secondary nameserver(s) for the
Registered Name;

3.3.1.3 The identity of Registrar (which may be provided through Registrar’s
website);

3.3.1.4 The original creation date of the registration;

3.3.1.5 The expiration date of the registration;

3.3.1.6 The name and postal address of the Registered Name Holder;

3.3.1.7 The name, postal address, e-mail address, voice telephone number, and
(where available) fax number of the technical contact for the Registered Name;
and

3.3.1.8 The name, postal address, e-mail address, voice telephone number, and
(where available) fax number of the administrative contact for the Registered
Name.

The agreement between the Registry Operator of a gTLD and
Registrar may, if approved by ICANN in writing, state alternative required data
elements applicable to that gTLD, in which event, the alternative required data
elements shall replace and supersede Subsections 3.3.1.1 through 3.3.1.8 stated
above for all purposes under this Agreement but only with respect to that
particular gTLD.

3.3.2 Upon receiving any updates to the data elements listed in Subsections
3.3.1.2, 3.3.1.3, and 3.3.1.5 through 3.3.1.8 from the Registered Name Holder,
Registrar shall promptly update its database used to provide the public access
described in Subsection 3.3.1.

3.3.3 Registrar may subcontract its obligation to provide the public access
described in Subsection 3.3.1 and the updating described in Subsection 3.3.2,
provided that Registrar shall remain fully responsible for the proper provision
of the access and updating.

3.3.4 Registrar shall abide by any Consensus Policy that requires registrars
to cooperatively implement a distributed capability that provides query-based
Whois search functionality across all registrars. If the Whois service
implemented by registrars does not in a reasonable time provide reasonably
robust, reliable, and convenient access to accurate and up-to-date data, the
Registrar shall abide by any Consensus Policy requiring Registrar, if
reasonably determined by ICANN to be necessary (considering such possibilities
as remedial action by specific registrars), to supply data from Registrar’s
database to facilitate the development of a centralized Whois database for the
purpose of providing comprehensive Registrar Whois search capability.

3.3.5 In providing query-based public access to registration data as required
by Subsections 3.3.1 and 3.3.4, Registrar shall not impose terms and conditions
on use of the data provided, except as permitted by any Specification or Policy
established by ICANN. Unless and until ICANN establishes a different Consensus
Policy, Registrar shall permit use of data it provides in response to queries
for any lawful purposes except to: (a) allow, enable, or otherwise support the
transmission by e-mail, telephone, postal mail, facsimile or other means of
mass unsolicited, commercial advertising or solicitations to entities other
than the data recipient’s own existing customers; or (b) enable high volume,
automated, electronic processes that send queries or data to the systems of any
Registry Operator or ICANN-Accredited registrar, except as reasonably necessary
to register domain names or modify existing registrations.

3.3.6 In the event that ICANN determines, following analysis of economic data
by an economist(s) retained by ICANN (which data has been made available to
Registrar), that an individual or entity is able to exercise market power with
respect to registrations or with respect to registration data used for
development of value-added products and services by third parties, Registrar
shall provide third-party bulk access to the data subject to public access
under Subsection 3.3.1 under the following terms and conditions:

3.3.6.1 Registrar
shall make a complete electronic copy of the data available at least one (1)
time per week for download by third parties who have entered into a bulk access
agreement with Registrar.

3.3.6.2 Registrar
may charge an annual fee, not to exceed US$10,000, for such bulk access to the
data.

3.3.6.3 Registrar’s
access agreement shall require the third party to agree not to use the data to
allow, enable, or otherwise support any marketing activities, regardless of the
medium used. Such media include but are not limited to e-mail, telephone,
facsimile, postal mail, SMS, and wireless alerts.

3.3.6.4 Registrar’s
access agreement shall require the third party to agree not to use the data to
enable high-volume, automated, electronic processes that send queries or data
to the systems of any Registry Operator or ICANN-Accredited registrar, except
as reasonably necessary to register domain names or modify existing registrations.

3.3.6.5 Registrar’s
access agreement must require the third party to agree not to sell or
redistribute the data except insofar as it has been incorporated by the third
party into a value-added product or service that does not permit the extraction
of a substantial portion of the bulk data from the value-added product or
service for use by other parties.

3.3.7 To comply with applicable statutes and regulations and for other
reasons, ICANN may adopt a Consensus Policy establishing limits (a) on the
Personal Data concerning Registered Names that Registrar may make available to
the public through a public-access service described in this Subsection 3.3 and
(b) on the manner in which Registrar may make such data available. Registrar
shall comply with any such Consensus Policy.

3.3.8 Registrar shall meet or exceed the requirements set forth in the Whois
Specification.

3.4 Retention of Registered Name Holder and Registration Data.

3.4.1 For each Registered Name sponsored by Registrar within a gTLD, Registrar
shall collect and securely maintain, in its own electronic database, as updated
from time to time:

3.4.1.1 the data specified in the Data Retention Specification attached hereto
for the period specified therein;

3.4.1.2 The data elements listed in Subsections 3.3.1.1 through 3.3.1.8;

3.4.1.3 the name and (where available) postal address, e-mail address, voice
telephone number, and fax number of the billing contact;

3.4.1.4 any other Registry Data that Registrar has submitted to the Registry
Operator or placed in the Registry Database under Subsection 3.2; and

3.4.1.5 the name, postal address, e-mail address, and voice telephone number
provided by the customer of any privacy service or licensee of any proxy
registration service, in each case, offered or made available by Registrar or
its Affiliates in connection with each registration. Effective on the date that ICANN fully implements a Proxy Accreditation Program
established in accordance with Section 3.14, the obligations under this Section
3.4.1.5 will cease to apply as to any specific category of data (such as postal
address) that is expressly required to be retained by another party in
accordance with such Proxy Accreditation Program.

3.4.2 During the Term of this Agreement and for two (2) years thereafter,
Registrar (itself or by its agent(s)) shall maintain the following records
relating to its dealings with the Registry Operator(s) and Registered Name
Holders:

3.4.2.1 In
electronic form, the submission date and time, and the content, of all
registration data (including updates) submitted in electronic form to the Registry
Operator(s);

3.4.2.2 In
electronic, paper, or microfilm form, all written communications constituting
registration applications, confirmations, modifications, or terminations and
related correspondence with Registered Name Holders, including registration contracts;
and

3.4.2.3 In
electronic form, records of the accounts of all Registered Name Holders with
Registrar.

3.4.3 During the Term of this Agreement and for two (2) years thereafter,
Registrar shall make the data, information and records specified in this
Section 3.4 available for inspection and copying by ICANN upon reasonable
notice. In addition, upon reasonable notice and request from ICANN, Registrar
shall deliver copies of such data, information and records to ICANN in respect
to limited transactions or circumstances that may be the subject of a
compliance-related inquiry; provided, however, that such obligation shall not
apply to requests for copies of the Registrar’s entire database or transaction
history. Such copies are to be provided at Registrar’s expense. In responding
to ICANN’s request for delivery of electronic data, information and records,
Registrar may submit such information in a format reasonably convenient to
Registrar and acceptable to ICANN so as to minimize disruption to the
Registrar’s business. In the event Registrar believes that the provision of
any such data, information or records to ICANN would violate applicable law or
any legal proceedings, ICANN and Registrar agree to discuss in good faith
whether appropriate limitations, protections, or alternative solutions can be
identified to allow the production of such data, information or records in
complete or redacted form, as appropriate. ICANN shall not disclose the
content of such data, information or records except as expressly required by
applicable law, any legal proceeding or Specification or Policy.

3.4.4 Notwithstanding any other requirement in this Agreement or the Data
Retention Specification, Registrar shall not be obligated to maintain records
relating to a domain registration beginning on the date two (2) years following
the domain registration’s deletion or transfer away to a different registrar.

3.5 Rights in Data. Registrar disclaims all rights to
exclusive ownership or use of the data elements listed in Subsections 3.2.1.1
through 3.2.1.3 for all Registered Names submitted by Registrar to the Registry
Database for, or sponsored by Registrar in, each gTLD for which it is
Accredited. Registrar does not disclaim rights in the data elements listed in
Subsections 3.2.1.4 through 3.2.1.6 and Subsections 3.3.1.3 through 3.3.1.8
concerning active Registered Names sponsored by it in each gTLD for which it is
Accredited, and agrees to grant non-exclusive, irrevocable, royalty-free
licenses to make use of and disclose the data elements listed in Subsections
3.2.1.4 through 3.2.1.6 and 3.3.1.3 through 3.3.1.8 for the purpose of
providing a service or services (such as a Whois service under Subsection
3.3.4) providing interactive, query-based public access. Upon a change in
sponsorship from Registrar of any Registered Name in each gTLD for which it is
Accredited, Registrar acknowledges that the registrar gaining sponsorship shall
have the rights of an owner to the data elements listed in Subsections 3.2.1.4
through 3.2.1.6 and 3.3.1.3 through 3.3.1.8 concerning that Registered Name,
with Registrar also retaining the rights of an owner in that data. Nothing in
this Subsection prohibits Registrar from (1) restricting bulk public access to
data elements in a manner consistent with this Agreement and any Specifications
or Policies or (2) transferring rights it claims in data elements subject to
the provisions of this Subsection 3.5.

3.6 Data Escrow. During the Term of this Agreement, on a
schedule, under the terms, and in the format specified by ICANN, Registrar
shall submit an electronic copy of the data described in Subsections 3.4.1.2
through 3.4.1.5 to ICANN or, at Registrar’s election and at its expense, to a
reputable escrow agent mutually approved by Registrar and ICANN, such approval
also not to be unreasonably withheld by either party. The data shall be held
under an agreement among Registrar, ICANN, and the escrow agent (if any)
providing that (1) the data shall be received and held in escrow, with no use
other than verification that the deposited data is complete, consistent, and in
proper format, until released to ICANN; (2) the data shall be released from
escrow upon expiration without renewal or termination of this Agreement; and
(3) ICANN’s rights under the escrow agreement shall be assigned with any
assignment of this Agreement. The escrow shall provide that in the event the
escrow is released under this Subsection, ICANN (or its assignee) shall have a
non-exclusive, irrevocable, royalty-free license to exercise (only for
transitional purposes) or have exercised all rights necessary to provide
Registrar Services.

3.7 Business Dealings, Including with Registered Name Holders.

3.7.1 In the event ICANN adopts a Specification or Policy that is supported by
a consensus of ICANN-Accredited registrars as reflected in the Registrar
Stakeholder Group (or any successor group), establishing or approving a Code of
Conduct for ICANN-Accredited registrars, Registrar shall abide by that Code of
Conduct.

3.7.2 Registrar shall abide by applicable laws and governmental regulations.

3.7.3 Registrar shall not represent to any actual or potential Registered Name
Holder that Registrar enjoys access to a registry for which Registrar is
Accredited that is superior to that of any other registrar Accredited for that
registry.

3.7.4 Registrar shall not activate any Registered Name unless and until it is
satisfied that it has received a reasonable assurance of payment of its
registration fee. For this purpose, a charge to a credit card, general
commercial terms extended to creditworthy customers, or other mechanism
providing a similar level of assurance of payment shall be sufficient, provided
that the obligation to pay becomes final and non-revocable by the Registered
Name Holder upon activation of the registration.

3.7.5 At the conclusion of the registration period, failure by or on behalf of
the Registered Name Holder to consent that the registration be renewed within
the time specified in a second notice or reminder shall, in the absence of
extenuating circumstances, result in cancellation of the registration by the
end of the auto-renew grace period (although Registrar may choose to cancel the
name earlier).

3.7.5.1 Extenuating
circumstances are defined as: UDRP action, valid court order, failure of a
Registrar’s renewal process (which does not include failure of a registrant to
respond), the domain name is used by a nameserver that provides DNS service to
third-parties (additional time may be required to migrate the records managed
by the nameserver), the registrant is subject to bankruptcy proceedings,
payment dispute (where a registrant claims to have paid for a renewal, or a
discrepancy in the amount paid), billing dispute (where a registrant disputes
the amount on a bill), domain name subject to litigation in a court of
competent jurisdiction, or other circumstance as approved specifically by
ICANN.

3.7.5.2 Where
Registrar chooses, under extenuating circumstances, to renew a domain name
without the explicit consent of the registrant, the registrar must maintain a
record of the extenuating circumstances associated with renewing that specific
domain name for inspection by ICANN consistent with clauses 3.4.2 and 3.4.3 of
this registrar accreditation agreement.

3.7.5.3 In
the absence of extenuating circumstances (as defined in Section 3.7.5.1 above),
a domain name must be deleted within 45 days of either the registrar or the
registrant terminating a registration agreement.

3.7.5.4 Registrar
shall provide notice to each new registrant describing the details of their
deletion and auto-renewal policy including the expected time at which a non-renewed
domain name would be deleted relative to the domain’s expiration date, or a
date range not to exceed ten (10) days in length. If a registrar makes any
material changes to its deletion policy during the period of the registration
agreement, it must make at least the same effort to inform the registrant of
the changes as it would to inform the registrant of other material changes to
the registration agreement (as defined in clause 3.7.7 of the registrars
accreditation agreement).

3.7.5.5 If
Registrar operates a website for domain name registration or renewal, details
of Registrar’s deletion and auto-renewal policies must be clearly displayed on
the website.

3.7.5.6 If
Registrar operates a website for domain registration or renewal, it should
state, both at the time of registration and in a clear place on its website,
any fee charged for the recovery of a domain name during the Redemption Grace
Period.

3.7.5.7 In
the event that a domain which is the subject of a UDRP dispute is deleted or
expires during the course of the dispute, the complainant in the UDRP dispute
will have the option to renew or restore the name under the same commercial
terms as the registrant. If the complainant renews or restores the name, the
name will be placed in Registrar HOLD and Registrar LOCK status, the WHOIS
contact information for the registrant will be removed, and the WHOIS entry
will indicate that the name is subject to dispute. If the complaint is
terminated, or the UDRP dispute finds against the complainant, the name will be
deleted within 45 days. The registrant retains the right under the existing
redemption grace period provisions to recover the name at any time during the
Redemption Grace Period, and retains the right to renew the name before it is
deleted.

3.7.6 Registrar shall not insert or renew any Registered Name in any gTLD
registry in a manner contrary to (i) any Consensus Policy stating a list or
specification of excluded Registered Names that is in effect at the time of
insertion or renewal, or (ii) any list of names to be reserved from registration
as required by the specific Registry Operator for which the Registrar is
providing Registrar Services.

3.7.7 Registrar shall require all Registered Name Holders to enter into an
electronic or paper registration agreement with Registrar including at least
the provisions set forth in Subsections 3.7.7.1 through 3.7.7.12, and which
agreement shall otherwise set forth the terms and conditions applicable to the
registration of a domain name sponsored by Registrar. The Registered Name
Holder with whom Registrar enters into a registration agreement must be a
person or legal entity other than the Registrar, provided that Registrar may be
the Registered Name Holder for domains registered for the purpose of conducting
its Registrar Services, in which case the Registrar shall submit to the
provisions set forth in Subsections 3.7.7.1 through 3.7.7.12 and shall be
responsible to ICANN for compliance with all obligations of the Registered Name
Holder as set forth in this Agreement and Specifications and Policies. Registrar
shall use commercially reasonable efforts to enforce compliance with the
provisions of the registration agreement between Registrar and any Registered
Name Holder that relate to implementing the requirements of Subsections 3.7.7.1
through 3.7.7.12 or any Consensus Policy.

3.7.7.1 The
Registered Name Holder shall provide to Registrar accurate and reliable contact
details and correct and update them within seven (7) days of any change during
the term of the Registered Name registration, including: the full name, postal
address, e-mail address, voice telephone number, and fax number if available of
the Registered Name Holder; name of authorized person for contact purposes in
the case of an Registered Name Holder that is an organization, association, or
corporation; and the data elements listed in Subsections 3.3.1.2, 3.3.1.7 and
3.3.1.8.

3.7.7.2 A
Registered Name Holder’s willful provision of inaccurate or unreliable
information, its willful failure to update information provided to Registrar
within seven (7) days of any change, or its failure to respond for over fifteen
(15) days to inquiries by Registrar concerning the accuracy of contact details
associated with the Registered Name Holder’s registration shall constitute a
material breach of the Registered Name Holder-registrar contract and be a basis
for suspension and/or cancellation of the Registered Name registration.

3.7.7.3 Any
Registered Name Holder that intends to license use of a domain name to a third
party is nonetheless the Registered Name Holder of record and is responsible
for providing its own full contact information and for providing and updating
accurate technical and administrative contact information adequate to
facilitate timely resolution of any problems that arise in connection with the
Registered Name. A Registered Name Holder licensing use of a Registered Name
according to this provision shall accept liability for harm caused by wrongful
use of the Registered Name, unless it discloses the current contact information
provided by the licensee and the identity of the licensee within seven (7) days
to a party providing the Registered Name Holder reasonable evidence of
actionable harm.

3.7.7.4 Registrar
shall provide notice to each new or renewed Registered Name Holder stating:

3.7.7.4.1 The
purposes for which any Personal Data collected from the applicant are intended;

3.7.7.4.2 The
intended recipients or categories of recipients of the data (including the
Registry Operator and others who will receive the data from Registry Operator);

3.7.7.4.3 Which data
are obligatory and which data, if any, are voluntary; and

3.7.7.4.4 How the
Registered Name Holder or data subject can access and, if necessary, rectify
the data held about them.

3.7.7.5 The
Registered Name Holder shall consent to the data processing referred to in
Subsection 3.7.7.4.

3.7.7.6 The
Registered Name Holder shall represent that notice has been provided equivalent
to that described in Subsection 3.7.7.4 to any third-party individuals whose
Personal Data are supplied to Registrar by the Registered Name Holder, and that
the Registered Name Holder has obtained consent equivalent to that referred to
in Subsection 3.7.7.5 of any such third-party individuals.

3.7.7.7 Registrar
shall agree that it will not process the Personal Data collected from the
Registered Name Holder in a way incompatible with the purposes and other
limitations about which it has provided notice to the Registered Name Holder in
accordance with Subsection 3.7.7.4 above.

3.7.7.8 Registrar
shall agree that it will take reasonable precautions to protect Personal Data
from loss, misuse, unauthorized access or disclosure, alteration, or
destruction.

3.7.7.9 The
Registered Name Holder shall represent that, to the best of the Registered Name
Holder’s knowledge and belief, neither the registration of the Registered Name
nor the manner in which it is directly or indirectly used infringes the legal
rights of any third party.

3.7.7.10 For the adjudication of
disputes concerning or arising from use of the Registered Name, the Registered
Name Holder shall submit, without prejudice to other potentially applicable
jurisdictions, to the jurisdiction of the courts (1) of the Registered Name
Holder’s domicile and (2) where Registrar is located.

3.7.7.11 The Registered Name Holder
shall agree that its registration of the Registered Name shall be subject to
suspension, cancellation, or transfer pursuant to any Specification or Policy,
or pursuant to any registrar or registry procedure not inconsistent with any
Specification or Policy, (1) to correct mistakes by Registrar or the Registry
Operator in registering the name or (2) for the resolution of disputes concerning
the Registered Name.

3.7.7.12 The Registered Name Holder
shall indemnify and hold harmless the 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 related to the Registered Name Holder’s domain name
registration.

3.7.8 Registrar shall comply with the obligations specified in the Whois
Accuracy Program Specification. In addition, notwithstanding anything in the Whois
Accuracy Program Specification to the contrary, Registrar shall abide by any
Consensus Policy requiring reasonable and commercially practicable (a)
verification, at the time of registration, of contact information associated
with a Registered Name sponsored by Registrar or (b) periodic re-verification
of such information. Registrar shall, upon notification by any person of an
inaccuracy in the contact information associated with a Registered Name
sponsored by Registrar, take reasonable steps to investigate that claimed
inaccuracy. In the event Registrar learns of inaccurate contact information
associated with a Registered Name it sponsors, it shall take reasonable steps
to correct that inaccuracy.

3.7.9 Registrar shall abide by any Consensus Policy prohibiting or restricting
warehousing of or speculation in domain names by registrars.

3.7.10 Registrar shall publish on its website(s) and/or provide a link to the
Registrants’ Benefits and Responsibilities Specification attached hereto and
shall not take any action inconsistent with the corresponding provisions of
this Agreement or applicable law.

3.7.11 Registrar shall make available a description of the customer service
handling processes available to Registered Name Holders regarding Registrar
Services, including a description of the processes for submitting complaints
and resolving disputes regarding the Registrar Services.

3.7.12 Nothing in this Agreement prescribes or limits the amount Registrar may
charge Registered Name Holders for registration of Registered Names.

3.8 Domain-Name Dispute Resolution. During the Term of this
Agreement, Registrar shall have in place a policy and procedures for resolution
of disputes concerning Registered Names. Until ICANN adopts an alternative
Consensus Policy or other Specification or Policy with respect to the
resolution of disputes concerning Registered Names, Registrar shall comply with
the Uniform Domain Name Dispute Resolution Policy (“UDRP”) identified on
ICANN’s website (www.icann.org/general/consensus-policies.htm), as may be
modified from time to time. Registrar shall also comply with the Uniform Rapid
Suspension (“URS”) procedure or its replacement, as well as with any other
applicable dispute resolution procedure as required by a Registry Operator for
which Registrar is providing Registrar Services.

3.9 Accreditation Fees. As a condition of Accreditation, Registrar
shall pay Accreditation fees to ICANN. These fees consist of yearly and
variable fees.

3.9.1 Registrar shall pay ICANN a yearly Accreditation fee in an amount
established by the ICANN Board of Directors, in conformity with ICANN’s bylaws
and articles of incorporation. This yearly Accreditation fee shall not exceed
US$4,000. Payment of the yearly fee shall be due within thirty (30) days after
invoice from ICANN, provided that Registrar may elect to pay the yearly fee in
four (4) equal quarterly installments.

3.9.2 Registrar shall pay the variable Accreditation fees established by
the ICANN Board of Directors, in conformity with ICANN’s bylaws and articles of
incorporation, provided that in each case such fees are reasonably allocated
among all registrars that contract with ICANN and that any such fees must be
expressly approved by registrars accounting, in the aggregate, for payment of
two-thirds of all registrar-level fees. Registrar shall pay such fees in a
timely manner for so long as all material terms of this Agreement remain in
full force and effect, and notwithstanding the pendency of any dispute between
Registrar and ICANN.

3.9.3 For any payments thirty (30) days or more overdue, Registrar shall pay
interest on late payments at the rate of 1.5% per month or, if less, the
maximum rate permitted by applicable law from later of the date of the invoice
or the date the invoice is sent pursuant to Section 7.6 of this Agreement. On
reasonable notice given by ICANN to Registrar, accountings submitted by
Registrar shall be subject to verification by an audit of Registrar’s books and
records by an independent third-party designated by ICANN that shall preserve
the confidentiality of such books and records (other than its findings as to
the accuracy of, and any necessary corrections to, the accountings).

3.9.4 The Accreditation fees due under this Agreement are exclusive of tax.
All taxes, duties, fees and other governmental charges of any kind (including
sales, turnover, services, use and value-added taxes) that are imposed by or
under the authority of any government or any political subdivision thereof on
the Accreditation fees for any services, software and/or hardware shall be
borne by Registrar and shall not be considered a part of, a deduction from, or
an offset against such Accreditation fees. All payments due to ICANN shall be
made without any deduction or withholding on account of any tax, duty, charge,
or penalty except as required by applicable law, in which case, the sum payable
by Registrar from which such deduction or withholding is to be made shall be
increased to the extent necessary to ensure that, after making such deduction
or withholding, ICANN receives (free from any liability with respect thereof) a
net sum equal to the sum it would have received but for such deduction or
withholding being required.

3.10 Insurance.
Registrar shall maintain in force commercial general liability insurance or
similar liability insurance as specified by ICANN with policy limits of at
least US$500,000 covering liabilities arising from Registrar’s registrar
business during the Term of this Agreement.

3.11 Obligations
of Registrars under common controlling interest. Registrar shall be in
breach of this Agreement if:

3.11.1 ICANN terminates an
Affiliated Registrar’s accreditation agreement with ICANN (an “Affiliate
Termination”);

3.11.2 Affiliated Registrar
has not initiated arbitration challenging ICANN’s right to terminate the
Affiliated Registrar’s accreditation agreement under Section 5.8 of this
Agreement, or has initiated such arbitration and has not prevailed;

3.11.3 the Affiliate
Termination was the result of misconduct that materially harmed consumers or
the public interest;

3.11.4 a second Affiliated
Registrar has pursued, after the Affiliate Termination, the same course of
conduct that resulted in the Affiliate Termination; and

3.11.5 ICANN has provided
Registrar with written notice that it intends to assert the provisions of this
Section 3.11 with respect to Registrar, which notice shall identify in
reasonable detail the factual basis for such assertion, and Registrar has
failed to cure the impugned conduct within fifteen (15) days of such notice.

3.12 Obligations
Related to Provision of Registrar Services by Third Parties. Registrar is
responsible for the provision of Registrar Services for all Registered Names
that Registrar sponsors being performed in compliance with this Agreement,
regardless of whether the Registrar Services are provided by Registrar or a
third party, including a Reseller. Registrar must enter into written
agreements with all of its Resellers that enable Registrar to comply with and
perform all of its obligations under this Agreement. In addition, Registrar
must ensure that:

3.12.1 Its Resellers do not
display the ICANN or ICANN-Accredited Registrar logo, or otherwise represent
themselves as Accredited by ICANN, unless they have written permission from
ICANN to do so.

3.12.2 Any registration
agreement used by reseller shall include all registration agreement provisions
and notices required by the ICANN Registrar Accreditation Agreement
and any ICANN Consensus Policies, and shall identify the sponsoring
registrar or provide a means for identifying the sponsoring registrar, such as
a link to the InterNIC Whois lookup service.

3.12.3 Its Resellers identify
the sponsoring registrar upon inquiry from the customer.

3.12.4 Its Resellers comply
with any ICANN-adopted Specification or Policy that establishes a program for
accreditation of individuals or entities who provide proxy and privacy
registration services (a “Proxy Accreditation Program”). Among other features,
the Proxy Accreditation Program may require that: (i) proxy and privacy
registration services may only be provided in respect of domain name
registrations by individuals or entities Accredited by ICANN pursuant to such
Proxy Accreditation Program; and (ii) Registrar shall prohibit Resellers from
knowingly accepting registrations from any provider of proxy and privacy
registration services that is not Accredited by ICANN pursuant the Proxy
Accreditation Program. Until such time as the Proxy Accreditation Program is
established, Registrar shall require Resellers to comply with the Specification
on Privacy and Proxy Registrations attached hereto.

3.12.5 Its Resellers’
customers are provided with a link to an ICANN webpage detailing registrant
educational information, as detailed in subsection 3.16 below.

3.12.6 In the event Registrar
learns that a Reseller is causing Registrar to be in breach of any of the
provisions of this Agreement, Registrar shall take reasonable steps to enforce
its agreement with such Reseller so as to cure and prevent further instances of
non-compliance.

3.12.7 Its Resellers shall publish on their website(s) and/or provide a link to
the Registrants’ Benefits and Responsibilities Specification attached hereto
and shall not take any action inconsistent with the corresponding provisions of
this Agreement or applicable law.

Registrar shall use commercially reasonable efforts to
enforce compliance with the provisions of the agreement between Registrar and
any Reseller that relate to the provisions of Registrar Services.

3.13 Registrar
Training. Registrar’s primary contact as identified in Subsection 7.6
below or designee (so long as the designee is employed by Registrar or an
Affiliated Registrar) shall complete a training course covering registrar
obligations under ICANN policies and agreements. The course will be provided by
ICANN at no expense to Registrar, and shall be available in an online
format.

3.14 Obligations
Related to Proxy and Privacy Services. Registrar agrees to comply with any
ICANN-adopted Specification or Policy that establishes a Proxy Accreditation
Program. Registrar also agrees to reasonably cooperate with ICANN in the
development of such program. Until such time as the Proxy Accreditation Program
is established, Registrar agrees to comply with the Specification on Privacy
and Proxy Registrations attached hereto.

3.15 Registrar
Self-Assessment and Audits. Registrar shall complete and deliver to ICANN
on a schedule and in the form specified by ICANN from time to time in
consultation with registrars a Registrar self-assessment. Registrar shall
complete and deliver to ICANN within twenty (20) days following the end of each
calendar year, in a form specified by ICANN a certificate executed by the president,
chief executive officer, chief financial officer or chief operating officer (or
their equivalents) of Registrar certifying compliance with the terms and
conditions of this Agreement. ICANN may from time to time (not to exceed twice
per calendar year) conduct, or engage a third party to conduct on its behalf,
contractual compliance audits to assess compliance by Registrar with the terms
and conditions of this Agreement. Any audits pursuant to this Section 3.15
shall be tailored to achieve the purpose of assessing compliance, and ICANN
will (a) give reasonable advance notice of any such audit, which notice shall
specify in reasonable detail the categories of documents, data and other
information requested by ICANN, and (b) use commercially reasonable efforts to
conduct such audit in such a manner as to not unreasonably disrupt the
operations of Registrar. As part of such audit and upon request by ICANN,
Registrar shall timely provide all responsive documents, data and any other
information necessary to demonstrate Registrar’s compliance with this
Agreement. Upon no less than ten (10) days notice (unless otherwise agreed to
by Registrar), ICANN may, as part of any contractual compliance audit, conduct
site visits during regular business hours to assess compliance by Registrar
with the terms and conditions of this Agreement. ICANN shall not disclose
Registrar confidential information gathered through such audits except as
required by applicable law, legal proceedings, or as expressly permitted by any
Specification or Policy (including ICANN’s Documentary Information Disclosure
Policy, as such policy may be amended from time to time); provided, however,
that, except as required by applicable law or legal proceedings, ICANN shall
not release any information that Registrar has marked as, or has otherwise
designated in writing to ICANN as, a “confidential trade secret,” “confidential
commercial information” or “confidential financial information” of Registrar.
If any applicable law, legal proceeding or Specification or Policy permits such
disclosure, ICANN will provide Registrar no less than fifteen (15) days notice
of its intent to disclose such information, unless such notice is prohibited by
law or legal proceeding. Such notice shall include to whom and in what manner
ICANN plans to disclose such information.

3.16 Link to
Registrant Educational Information. ICANN has published an educational
webpage summarizing the terms of the Registrar Accreditation Agreement and
related Consensus Policies (as of the date of this Agreement,
located at: http://www.icann.org/en/registrars/registrant-rights-responsibilities-en.htm).
Registrar shall provide a link to such webpage on any website it may operate
for domain name registration or renewal clearly displayed to its Registered
Name Holders at least as clearly as its links to policies or notifications
required to be displayed under ICANN Consensus Policies. ICANN may, in
consultation with registrars, update the content and/or URL for this website.

3.17 Registrar
Contact, Business Organization and Officer Information. Registrar shall
provide to ICANN and maintain accurate and current information as specified in
the Registrar Information Specification to this Agreement. In addition,
Registrar shall publish on each website through which Registrar provides or
offers Registrar Services the information specified as requiring such
publication in the Registrar Information Specification. Registrar shall notify
ICANN within five (5) days of any changes to such information and update
Registrar’s website(s) within twenty (20) days of any such changes.

3.18 Registrar’s
Abuse Contact and Duty to Investigate Reports of Abuse.

3.18.1 Registrar shall maintain an abuse contact to receive reports of abuse
involving Registered Names sponsored by Registrar, including reports of Illegal
Activity. Registrar shall publish an email address to receive such reports on
the home page of Registrar’s website (or in another standardized place that may
be designated by ICANN from time to time). Registrar shall take reasonable and
prompt steps to investigate and respond appropriately to any reports of abuse.

3.18.2 Registrar shall establish and maintain a dedicated abuse point of
contact, including a dedicated email address and telephone number that is
monitored 24 hours a day, seven days a week, to receive reports of Illegal
Activity by law enforcement, consumer protection, quasi-governmental or other
similar authorities designated from time to time by the national or territorial
government of the jurisdiction in which the Registrar is established or
maintains a physical office. Well-founded reports of Illegal Activity
submitted to these contacts must be reviewed within 24 hours by an individual
who is empowered by Registrar to take necessary and appropriate actions in
response to the report. In responding to any such reports, Registrar will not
be required to take any action in contravention of applicable law.

3.18.3 Registrar shall publish on its website a description of its procedures
for the receipt, handling, and tracking of abuse reports. Registrar shall
document its receipt of and response to all such reports. Registrar shall
maintain the records related to such reports for the shorter of two (2) years
or the longest period permitted by applicable law, and during such period,
shall provide such records to ICANN upon reasonable notice.

3.19 Additional
Technical Specifications to Implement IPV6, DNSSEC and IDNs. Registrar
shall comply with the Additional Registrar Operations Specification attached
hereto.

3.20 Notice of
Bankruptcy, Convictions and Security Breaches. Registrar will give ICANN
notice within seven (7) days of (i) the commencement of any of the proceedings
referenced in Section 5.5.8. (ii) the occurrence of any of the matters
specified in Section 5.5.2 or Section 5.5.3 or (iii) any unauthorized access to
or disclosure of registrant account information or registration data. The
notice required pursuant to Subsection (iii) shall include a detailed
description of the type of unauthorized access, how it occurred, the number of
registrants affected, and any action taken by Registrar in response.

3.21 Obligations
of Registrars Affiliated with Registry Operators. In the event
Registrar is Affiliated with any Registry Operator or back-end registry
operator (an “Affiliated Relationship”) during the Term of this Agreement,
Registrar shall comply with all ICANN Specifications and Policies that may be
developed from time to time with respect to such Affiliated Relationships, and
will notify ICANN within thirty (30) days of the occurrence of the event that
created the Affiliate relationship (e.g., the closing of any merger,
acquisition or other transaction, or the execution of any agreement, in each
case, giving rise to such Affiliated Relationship).

3.22 Cooperation
with Emergency Registry Service Providers. In the event that ICANN
transitions the operation of a registry for a gTLD in which Registrar sponsors
Registered Names to an emergency registry service provider, Registrar shall
cooperate in all reasonable respects with such emergency registry service
provider, including by entering into a registry-registrar agreement with such
provider necessary to effect the transition and by providing all Registered Name
Holder data reasonably requested by such emergency operator for the purpose of
facilitating an efficient transition of the registry for the gTLD.

PROCEDURES FOR ESTABLISHMENT OR REVISION OF SPECIFICATIONS AND POLICIES.

4.1 Compliance with Consensus Policies and Temporary Policies.
During the Term of this Agreement, Registrar shall comply with and implement
all Consensus Policies and Temporary Policies in existence as of the Effective
Date found at http://www.icann.org/general/consensus-policies.htm,
and as may in the future be developed and adopted in accordance with the ICANN
Bylaws, provided such future Consensus Policies and Temporary Policies are
adopted in accordance with the procedures and relate to those topics and
subject to those limitations set forth in the Consensus Policies and Temporary
Policies Specification to this Agreement.

TERM, TERMINATION AND DISPUTE RESOLUTION.

5.1 Term of Agreement. This Agreement shall be effective on the Effective
Date and shall have an initial term running until the Expiration Date, unless
sooner terminated.

5.2 Renewal. This Agreement and Registrar’s Accreditation will be
renewed for successive periods of five (5) years upon the Expiration Date and
the expiration of each successive five-year term thereafter under the terms and
conditions of this Agreement, unless:

5.2.1 at the time of such renewal, Registrar no longer meets the ICANN
registrar Accreditation criteria then in effect;

5.2.2 Registrar is not in compliance with its obligations under this Agreement
at the time of the Expiration Date or at the expiration of any successive five
(5) year term thereafter;

5.2.3 Registrar has been given notice by ICANN of three (3) or more material
breaches of this Agreement within the two (2) years preceding the Expiration
Date or the date of expiration of any successive five (5) year term thereafter;
or

5.2.4 this Agreement has terminated prior to the Expiration Date or the
expiration date of any successive five (5) year term thereafter.

In the event Registrar intends to
renew this Agreement pursuant to this Section 5.2, Registrar shall provide
ICANN written notice thereof during the period that is no more than ninety (90)
days and no less than sixty (60) days prior to the Expiration Date and each
successive five (5) year term thereafter. The provision of such notice shall
not be a condition to renewal hereunder. Pursuant to its customary practices
(as may be modified by ICANN), ICANN will provide notice to Registrar of the
Expiration Date and the date of expiration of any subsequent term hereunder.

5.3 Right to Substitute Updated Agreement. In the event that, during
the Term of this Agreement, ICANN adopts a revised form Registrar accreditation
agreement (the “Updated RAA”), Registrar (provided it has not received (i) a
notice of breach that it has not cured or (ii) a notice of termination or
suspension of this Agreement under this Section 5) may elect, by giving ICANN
written notice, to enter into the Updated RAA. In the event of such election,
Registrar and ICANN shall as soon as practicable enter into the Updated RAA for
the term specified in the Updated RAA, and this Agreement will be deemed
terminated.

5.4 Termination of Agreement by Registrar. This Agreement may be
terminated before its expiration by Registrar by giving ICANN thirty (30) days
written notice. Upon such termination by Registrar, Registrar shall not be
entitled to any refund of fees paid to ICANN pursuant to this Agreement.

5.5 Termination of Agreement by ICANN. This Agreement may be
terminated before its expiration by ICANN in any of the following
circumstances:

5.5.1 There was a material misrepresentation, material inaccuracy, or
materially misleading statement in Registrar’s application for Accreditation or
renewal of Accreditation or any material accompanying the application.

5.5.2 Registrar:

5.5.2.1 is
convicted by a court of competent jurisdiction of a felony or other serious
offense related to financial activities, or is judged by a court of competent
jurisdiction to have:

5.5.2.1.1 committed fraud,

5.5.2.1.2 committed a breach of fiduciary duty, or

5.5.2.1.3 with actual knowledge (or through gross negligence) permitted Illegal
Activity in the registration or use of domain names or in the provision to
Registrar by any Registered Name Holder of inaccurate Whois information; or

5.5.2.1.4 failed to comply with the terms of an order issued by a court of
competent jurisdiction relating to the use of domain names sponsored by the
Registrar;

or is the subject of a judicial
determination that ICANN reasonably deems as the substantive equivalent of any
of the foregoing; or

5.5.2.2 is
disciplined by the government of its domicile for conduct involving dishonesty
or misuse of funds of others; or

5.5.2.3 is the subject of a non-interlocutory order issued by a court or
arbitral tribunal, in each case of competent jurisdiction, finding that
Registrar has, directly or through an Affiliate, committed a specific
violation(s) of applicable national law or governmental regulation relating to
cybersquatting or its equivalent; or

5.5.2.4 is found by ICANN, based on its review of the findings of arbitral
tribunals, to have been engaged, either directly or through its Affiliate, in a
pattern and practice of trafficking in or use of domain names identical or
confusingly similar to a trademark or service mark of a third party in which
the Registered Name Holder has no rights or legitimate interest, which
trademarks have been registered and are being used in bad faith.

5.5.3 Registrar knowingly employs any officer that is convicted of a
misdemeanor related to financial activities or of any felony, or is judged by a
court of competent jurisdiction to have committed fraud or breach of fiduciary
duty, or is the subject of a judicial determination that ICANN reasonably deems
as the substantive equivalent of any of the foregoing and such officer is not
terminated within thirty (30) days of Registrar’s knowledge of the foregoing;
or any member of Registrar’s board of directors or similar governing body is
convicted of a misdemeanor related to financial activities or of any felony, or
is judged by a court of competent jurisdiction to have committed fraud or
breach of fiduciary duty, or is the subject of a judicial determination that
ICANN reasonably deems as the substantive equivalent of any of the foregoing
and such member is not removed from Registrar’s board of directors or similar
governing body within thirty (30) days of Registrar’s knowledge of the
foregoing.

5.5.4 Registrar fails to cure any breach of this Agreement within twenty-one
(21) days after ICANN gives Registrar notice of the breach.

5.5.5 Registrar fails to comply with a ruling granting specific performance
under Sections 5.7 or 7.1.

5.5.6 Registrar has been in fundamental and material breach of its obligations
under this Agreement at least three (3) times within a twelve (12) month
period.

5.5.7 Registrar continues acting in a manner that ICANN has reasonably
determined endangers the stability or operational integrity of the Internet
after receiving three (3) days notice of that determination.

5.5.8 (i) Registrar makes an assignment for the benefit of creditors or
similar act; (ii) attachment, garnishment or similar proceedings are commenced
against Registrar, which proceedings are a material threat to Registrar’s
ability to provide Registrar Services for gTLDs, and are not dismissed within
sixty (60) days of their commencement; (iii) a trustee, receiver, liquidator or
equivalent is appointed in place of Registrar or maintains control over any of
Registrar’s property; (iv) execution is levied upon any property of Registrar,
(v) proceedings are instituted by or against Registrar under any bankruptcy,
insolvency, reorganization or other laws relating to the relief of debtors and
such proceedings are not dismissed within thirty (30) days of their
commencement, or (vi) Registrar files for protection under the United States
Bankruptcy Code, 11 U.S.C. Section 101 et seq., or a foreign equivalent or
liquidates, dissolves or otherwise discontinues its operations.

5.6 Termination Procedures. This Agreement may be terminated in
circumstances described in Subsections 5.5.1 though 5.5.6 above only upon
fifteen (15) days written notice to Registrar (in the case of Subsection 5.5.4
occurring after Registrar’s failure to cure), with Registrar being given an
opportunity during that time to initiate arbitration under Subsection 5.8 to
determine the appropriateness of termination under this Agreement. This
Agreement may be terminated immediately upon notice to Registrar in
circumstances described in Subsections 5.5.7 and 5.5.8.

5.7 Suspension.

5.7.1 Upon the occurrence of any of the circumstances set forth in Section
5.5, ICANN may, in ICANN’s sole discretion, upon delivery of a notice pursuant
to Subsection 5.7.2, elect to suspend Registrar’s ability to create or sponsor
new Registered Names or initiate inbound transfers of Registered Names for any
or all gTLDs for a period of up to a twelve (12) months following the
effectiveness of such suspension. Suspension of a Registrar does not preclude
ICANN’s ability to issue a notice of termination in accordance with the notice
requirements of Section 5.6.

5.7.2 Any suspension under Subsections 5.7.1 will be effective upon fifteen
(15) days written notice to Registrar, with Registrar being given an
opportunity during that time to initiate arbitration under Subsection 5.8 to
determine the appropriateness of suspension under this Agreement.

5.7.3 Upon suspension, Registrar shall notify users, by posting a prominent
notice on its web site, that it is unable to create or sponsor new gTLD domain
name registrations or initiate inbound transfers of Registered Names. Registrar’s
notice shall include a link to the notice of suspension from ICANN.

5.7.4 If Registrar acts in a manner that ICANN reasonably determines endangers
the stability or operational integrity of the Internet and upon notice does not
immediately cure, ICANN may suspend this Agreement for five (5) working days
pending ICANN’s application for more extended specific performance or
injunctive relief under Subsection 7.1. Suspension of the Agreement under
this Subsection may, at ICANN’s sole discretion, preclude the Registrar from
(i) providing Registration Services for gTLDs delegated by ICANN on or after
the date of delivery of such notice to Registrar and (ii) creating or
sponsoring new Registered Names or initiating inbound transfers of Registered
Names for any gTLDs. Registrar must also post the statement specified in
Subsection 5.7.3.

5.8 Resolution of Disputes Under this Agreement. Subject to
the limitations set forth in Section 6 and Section 7.4, disputes arising under
or in connection with this Agreement, including (1) disputes arising from
ICANN’s failure to renew Registrar’s Accreditation and (2) requests for
specific performance, shall be resolved in a court of competent jurisdiction
or, at the election of either party, by an arbitration conducted as provided in
this Subsection 5.8 pursuant to the International Arbitration Rules of the
American Arbitration Association (“AAA”). The arbitration shall be conducted in
English and shall occur in Los Angeles County, California, USA. Except as set
forth in Section 7.4.5, there shall be one (1) arbitrator agreed by the parties
from a list of AAA arbitrators, or if parties do not agree on an arbitrator
within fifteen (15) days of the AAA request that the parties designate an
arbitrator, the AAA shall choose and appoint an arbitrator, paying due regard
to the arbitrator’s knowledge of the DNS. The parties shall bear the costs of
the arbitration in equal shares, subject to the right of the arbitrator to
reallocate the costs in their award as provided in the AAA rules. The parties
shall bear their own attorneys’ fees in connection with the arbitration, and
the arbitrator may not reallocate the attorneys’ fees in conjunction with their
award. The arbitrator shall render its decision within ninety (90) days of the
conclusion of the arbitration hearing. In the event Registrar initiates
arbitration to contest the appropriateness of termination of this Agreement by
ICANN pursuant to Section 5.5 or suspension of Registrar by ICANN pursuant to
Section 5.7.1, Registrar may at the same time request that the arbitration
panel stay the termination or suspension until the arbitration decision is
rendered. The arbitration panel shall order a stay: (i) upon showing by
Registrar that continued operations would not be harmful to consumers or the
public interest, or (ii) upon appointment by the arbitration panel of a
qualified third party to manage the operations of the Registrar until the
arbitration decision is rendered. In furtherance of sub-clause (ii) above, the
arbitration panel is hereby granted all necessary authority to appoint a
qualified third-party to manage the operations of the Registrar upon the
Registrar’s request and if the panel deems it appropriate. In selecting the
third-party manager, the arbitration panel shall take into consideration, but
shall not be bound by, any expressed preferences of Registrar. Any order granting a request for a stay must be issued within fourteen (14) days after
the filing of the arbitration. If an order granting a request for a stay is not
issued within fourteen (14) days, ICANN has the right to proceed with the
termination of this Agreement pursuant to Section 5.5 or suspension of the
Registrar pursuant to Section 5.7.1. In the event Registrar initiates
arbitration to contest an Independent Review Panel’s decision under Subsection
4.3.3 sustaining the ICANN Board of Director’s determination that a
specification or policy is supported by consensus, Registrar may at the same
time request that the arbitration panel stay the requirement that it comply
with the policy until the arbitration decision is rendered, and that request
shall have the effect of staying the requirement until the decision or until
the arbitration panel has granted an ICANN request for lifting of the stay. In
all litigation involving ICANN concerning this Agreement (whether in a case
where arbitration has not been elected or to enforce an arbitration award),
jurisdiction and exclusive venue for such litigation shall be in a court
located in Los Angeles, 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 an arbitration, the parties shall
have the right to seek temporary or preliminary injunctive relief from the
arbitration panel or in a court located in Los Angeles, California, USA, which
shall not be a waiver of this arbitration agreement.

5.9 Limitations on Monetary Remedies for Violations of this
Agreement. ICANN’s aggregate monetary liability for violations of this
Agreement shall not exceed an amount equal to the Accreditation fees paid by
Registrar to ICANN under Subsection 3.9 of this Agreement during the preceding
twelve-month period. Registrar’s monetary liability to ICANN for violations of
this Agreement shall be limited to Accreditation fees owing to ICANN under this
Agreement and, except in the case of a good faith disagreement concerning the
interpretation of this agreement, reasonable payment to ICANN for the
reasonable and direct costs including attorney fees, staff time, and other
related expenses associated with legitimate efforts to enforce Registrar
compliance with this agreement and costs incurred by ICANN to respond to or
mitigate the negative consequences of such behavior for Registered Name Holders
and the Internet community. In the event of repeated willful material breaches
of the agreement, Registrar shall be liable for sanctions of up to five (5)
times ICANN’s enforcement costs, but otherwise in no event shall either party
be liable for special, indirect, incidental, punitive, exemplary, or
consequential damages for any violation of this Agreement.

AMENDMENT AND WAIVER.

6.1 If the ICANN Board of Directors determines that an amendment to this
Agreement (including to the Specifications referred to herein, unless such
Specifications expressly do not permit amendment thereto) and all other
registrar agreements between ICANN and the Applicable Registrars (the
“Applicable Registrar Agreements”) is desirable (each, a “Special Amendment”),
ICANN may adopt a Special Amendment pursuant to the requirements of and process
set forth in this Section 6; provided that a Special Amendment may not be a
Restricted Amendment.

6.2 Prior to submitting a Special Amendment for Registrar Approval, ICANN
shall first consult in good faith with the Working Group regarding the form and
substance of such Special Amendment. The duration of such consultation shall
be reasonably determined by ICANN based on the substance of the Special
Amendment. Following such consultation, ICANN may propose the adoption of a
Special Amendment by publicly posting such amendment on its website for no less
than thirty (30) calendar days (the “Posting Period”) and providing notice of
such proposed amendment to the Applicable Registrars in accordance with Section
7.6. ICANN will consider the public comments submitted on a Special Amendment
during the Posting Period (including comments submitted by the Applicable
Registrars).

6.3 If, within one hundred eighty (180) calendar days following the
expiration of the Posting Period (the “Approval Period”), the ICANN Board of
Directors approves a Special Amendment (which may be in a form different than
submitted for public comment, but must address the subject matter of the
Special Amendment posted for public comment, as modified to reflect and/or
address input from the Working Group and public comments), ICANN shall provide
notice of, and submit, such Special Amendment for approval or disapproval by
the Applicable Registrars. If, during the sixty (60) calendar day period
following the date ICANN provides such notice to the Applicable Registrars,
such Special Amendment receives Registrar Approval, such Special Amendment
shall be deemed approved (an “Approved Amendment”) by the Applicable
Registrars, and shall be effective and deemed an amendment to this Agreement on
the date that is sixty (60) calendar days following the date ICANN provided
notice of the approval of such Approved Amendment to Registrar (the “Amendment
Effective Date”). In the event that a Special Amendment does not receive
Registrar Approval, the Special Amendment shall be deemed not approved by the
Applicable Registrars (a “Rejected Amendment”). A Rejected Amendment will have
no effect on the terms and conditions of this Agreement, except as set forth
below.

6.4 If the ICANN Board of Directors reasonably determines that a Rejected
Amendment falls within the subject matter categories set forth in Section 1.2
of the Consensus Policies and Temporary Policies Specification, the ICANN Board
of Directors may adopt a resolution (the date such resolution is adopted is
referred to herein as the “Resolution Adoption Date”) requesting an Issue
Report (as such term is defined in ICANN’s Bylaws) by the Generic Names
Supporting Organization (the “GNSO”) regarding the substance of such Rejected
Amendment. The policy development process undertaken by the GNSO pursuant to
such requested Issue Report is referred to herein as a “PDP.” If such PDP
results in a Final Report supported by a GNSO Supermajority (as defined in
ICANN’s Bylaws) that either (i) recommends adoption of the Rejected Amendment
as Consensus Policy or (ii) recommends against adoption of the Rejected
Amendment as Consensus Policy, and, in the case of (i) above, the Board adopts
such Consensus Policy, Registrar shall comply with its obligations pursuant to
Section 4 of this Agreement. In either case, ICANN will abandon the Rejected
Amendment and it will have no effect on the terms and conditions of this
Agreement. Notwithstanding the foregoing provisions of this Section 6.4, the
ICANN Board of Directors shall not be required to initiate a PDP with respect
to a Rejected Amendment if, at any time in the twelve (12) month period preceding
the submission of such Rejected Amendment for Registrar Approval pursuant to
Section 6.3, the subject matter of such Rejected Amendment was the subject of a
concluded or otherwise abandoned or terminated PDP that did not result in a
GNSO Supermajority recommendation.

6.5 If (i) a Rejected Amendment does not fall within the subject matter
categories set forth in Section 1.2 of the Consensus Policies and Temporary
Policies Specification, (ii) the subject matter of a Rejected Amendment was, at
any time in the twelve (12) month period preceding the submission of such
Rejected Amendment for Registrar Approval pursuant to Section 6.3, the subject
of a concluded or otherwise abandoned or terminated PDP that did not result in
a GNSO Supermajority recommendation, or (iii) a PDP does not result in a Final
Report supported by a GNSO Supermajority that either (a) recommends adoption of
the Rejected Amendment as Consensus Policy or (b) recommends against adoption
of the Rejected Amendment as Consensus Policy (or such PDP has otherwise been
abandoned or terminated for any reason), then, in any such case, such Rejected
Amendment may still be adopted and become effective in the manner described
below. In order for the Rejected Amendment to be adopted, the following requirements
must be satisfied:

6.5.1 the subject matter of the Rejected Amendment must be within the scope of
ICANN’s mission and consistent with a balanced application of its core values
(as described in ICANN’s Bylaws);

6.5.2 the Rejected Amendment must be justified by a Substantial and Compelling
Reason in the Public Interest, must be likely to promote such interest, taking
into account competing public and private interests that are likely to be
affected by the Rejected Amendment, and must be narrowly tailored and no broader
than reasonably necessary to address such Substantial and Compelling Reason in
the Public Interest;

6.5.3 to the extent the Rejected Amendment prohibits or requires conduct or
activities, imposes material costs on the Applicable Registrars, and/or
materially reduces public access to domain name services, the Rejected
Amendment must be the least restrictive means reasonably available to address
the Substantial and Compelling Reason in the Public Interest;

6.5.4 the ICANN Board of Directors must submit the Rejected Amendment, along
with a written explanation of the reasoning related to its determination that
the Rejected Amendment meets the requirements set out in subclauses (i) through
(iii) above, for public comment for a period of no less than thirty (30) calendar
days; and

6.5.5 following such public comment period, the ICANN Board of Directors must
(i) engage in consultation (or direct ICANN management to engage in
consultation) with the Working Group, subject matter experts, members of the
GNSO, relevant advisory committees and other interested stakeholders with
respect to such Rejected Amendment for a period of no less than sixty (60)
calendar days; and (ii) following such consultation, reapprove the Rejected
Amendment (which may be in a form different than submitted for Registrar
Approval, but must address the subject matter of the Rejected Amendment, as
modified to reflect and/or address input from the Working Group and public
comments) by the affirmative vote of at least two-thirds of the members of the
ICANN Board of Directors eligible to vote on such matter, taking into account
any ICANN policy affecting such eligibility, including ICANN’s Conflict of
Interest Policy (a “Board Amendment”).

Such Board Amendment shall, subject to Section 6.6, be
deemed an Approved Amendment, and shall be effective and deemed an amendment to
this Agreement on the date that is sixty (60) calendar days following the date
ICANN provided notice of the approval of such Board Amendment to Registrar
(which effective date shall be deemed the Amendment Effective Date hereunder).
Notwithstanding the foregoing, a Board Amendment may not amend the registrar
fees charged by ICANN hereunder, or amend this Section 6.

6.6 Notwithstanding the provisions of Section 6.5, a Board Amendment shall
not be deemed an Approved Amendment if, during the thirty (30) calendar day
period following the approval by the ICANN Board of Directors of the Board
Amendment, the Working Group, on the behalf of the Applicable Registrars,
submits to the ICANN Board of Directors an alternative to the Board Amendment
(an “Alternative Amendment”) that meets the following requirements:

6.6.1 sets forth the precise text proposed by the Working Group to amend this
Agreement in lieu of the Board Amendment;

6.6.2 addresses the Substantial and Compelling Reason in the Public Interest
identified by the ICANN Board of Directors as the justification for the Board
Amendment; and

6.6.3 compared to the Board Amendment is: (a) more narrowly tailored to
address such Substantial and Compelling Reason in the Public Interest, and (b)
to the extent the Alternative Amendment prohibits or requires conduct or
activities, imposes material costs on Affected Registrars, or materially
reduces access to domain name services, is a less restrictive means to address
the Substantial and Compelling Reason in the Public Interest.

Any proposed amendment that does not meet the requirements
of subclauses 6.6.1 through 6.6.3 in the immediately preceding sentence shall
not be considered an Alternative Amendment hereunder and therefore shall not
supersede or delay the effectiveness of the Board Amendment. If, following the
submission of the Alternative Amendment to the ICANN Board of Directors, the
Alternative Amendment receives Registrar Approval, the Alternative Amendment
shall supersede the Board Amendment and shall be deemed an Approved Amendment
hereunder (and shall be effective and deemed an amendment to this Agreement on
the date that is sixty (60) calendar days following the date ICANN provided
notice of the approval of such Alternative Amendment to Registrar, which
effective date shall deemed the Amendment Effective Date hereunder), unless,
within a period of sixty (60) calendar days following the date that the Working
Group notifies the ICANN Board of Directors of Registrar Approval of such
Alternative Amendment (during which time ICANN shall engage with the Working
Group with respect to the Alternative Amendment), the ICANN Board of Directors
by the affirmative vote of at least two-thirds of the members of the ICANN
Board of Directors eligible to vote on such matter, taking into account any
ICANN policy affecting such eligibility, including ICANN’s Conflict of Interest
Policy, rejects the Alternative Amendment. If (A) the Alternative Amendment
does not receive Registrar Approval within thirty (30) days of submission of
such Alternative Amendment to the Applicable Registrars (and the Working Group
shall notify ICANN of the date of such submission), or (B) the ICANN Board of
Directors rejects the Alternative Amendment by such two-thirds vote, the Board
Amendment (and not the Alternative Amendment) shall be effective and deemed an
amendment to this Agreement on the date that is sixty (60) calendar days
following the date ICANN provided notice to Registrar (which effective date
shall deemed the Amendment Effective Date hereunder). If the ICANN Board of
Directors rejects an Alternative Amendment, the board shall publish a written
rationale setting forth its analysis of the criteria set forth in Sections
6.6.1 through 6.6.3. The ability of the ICANN Board of Directors to reject an
Alternative Amendment hereunder does not relieve the Board of the obligation to
ensure that any Board Amendment meets the criteria set forth in Section 6.5.1
through 6.5.5.

6.7 In the event that Registrar believes an Approved Amendment does not meet
the substantive requirements set out in this Section 6 or has been adopted in
contravention of any of the procedural provisions of this Section 6, Registrar
may challenge the adoption of such Special Amendment pursuant to the dispute
resolution provisions set forth in Section 5.8, except that such arbitration
shall be conducted by a three-person arbitration panel. Any such challenge
must be brought within sixty (60) calendar days following the date ICANN
provided notice to Registrar of the Approved Amendment, and ICANN may
consolidate all challenges brought by registrars (including Registrar) into a
single proceeding. The Approved Amendment will be deemed not to have amended
this Agreement during the pendency of the dispute resolution process.

6.8 Registrar may apply in writing to ICANN for an exemption from the
Approved Amendment (each such request submitted by Registrar hereunder, an
“Exemption Request”) during the thirty (30) calendar day period following the
date ICANN provided notice to Registrar of such Approved Amendment.

6.8.1 Each Exemption Request will set forth the basis for such request and
provide detailed support for an exemption from the Approved Amendment. An
Exemption Request may also include a detailed description and support for any
alternatives to, or a variation of, the Approved Amendment proposed by such
Registrar.

6.8.2 An Exemption Request may only be granted upon a clear and convincing
showing by Registrar that compliance with the Approved Amendment conflicts with
applicable laws or would have a material adverse effect on the long-term
financial condition or results of operations of Registrar. No Exemption Request
will be granted if ICANN determines, in its reasonable discretion, that
granting such Exemption Request would be materially harmful to registrants or
result in the denial of a direct benefit to registrants.

6.8.3 Within ninety (90) calendar days of ICANN’s receipt of an Exemption
Request, ICANN shall either approve (which approval may be conditioned or
consist of alternatives to or a variation of the Approved Amendment) or deny
the Exemption Request in writing, during which time the Approved Amendment will
not amend this Agreement.

6.8.4 If the Exemption Request is approved by ICANN, the Approved Amendment
will not amend this Agreement; provided, that any conditions, alternatives or
variations of the Approved Amendment required by ICANN shall be effective and,
to the extent applicable, will amend this Agreement as of the Amendment
Effective Date. If such Exemption Request is denied by ICANN, the Approved
Amendment will amend this Agreement as of the Amendment Effective Date (or, if
such date has passed, such Approved Amendment shall be deemed effective
immediately on the date of such denial), provided that Registrar may, within
thirty (30) calendar days following receipt of ICANN’s determination, appeal
ICANN’s decision to deny the Exemption Request pursuant to the dispute
resolution procedures set forth in Section 5.8.

6.8.5 The Approved Amendment will be deemed not to have amended this Agreement
during the pendency of the dispute resolution process. For avoidance of doubt,
only Exemption Requests submitted by Registrar that are approved by ICANN
pursuant to this Article 6 or through an arbitration decision pursuant to Section
5.8 shall exempt Registrar from any Approved Amendment, and no Exemption
Request granted to any other Applicable Registrar (whether by ICANN or through
arbitration), shall have any effect under this Agreement or exempt Registrar
from any Approved Amendment.

6.9 Except as set forth in Section 4, Subsection 5.3, this Section 6,
Section 7.4 and as otherwise set forth in this Agreement and the Specifications
hereto, no amendment, supplement or modification of this Agreement or any
provision hereof shall be binding unless executed in writing by both parties,
and nothing in this Section 6 or Section 7.4 shall restrict ICANN and Registrar
from entering into bilateral amendments and modifications to this Agreement
negotiated solely between the two 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. For
the avoidance of doubt, nothing in this Section 6 or Section 7.4 shall be
deemed to limit Registrar’s obligation to comply with Section 4.

6.10 Notwithstanding
anything in this Section 6 to the contrary, (a) if Registrar provides evidence
to ICANN’s reasonable satisfaction that the Approved Amendment would materially
increase the cost of providing Registrar Services, then ICANN will allow up to
one-hundred eighty (180) calendar days for the Approved Amendment to become
effective with respect to Registrar, and (b) no Approved Amendment adopted
pursuant to Section 6 shall become effective with respect to Registrar if
Registrar provides ICANN with an irrevocable notice of termination pursuant to
Section 5.4.

MISCELLANEOUS PROVISIONS.

7.1 Specific Performance. While this Agreement is in effect, either
party may seek specific performance of any provision of this Agreement in the
manner provided in Section 5.8, provided the party seeking such performance is
not in material breach of its obligations.

7.2 Handling by ICANN of Registrar-Supplied Data. Before receiving
any Personal Data from Registrar, ICANN shall specify to Registrar in writing
the purposes for and conditions under which ICANN intends to use the Personal
Data. ICANN may from time to time provide Registrar with a revised
specification of such purposes and conditions, which specification shall become
effective no fewer than thirty (30) days after it is provided to Registrar.
ICANN shall not use Personal Data provided by Registrar for a purpose or under
conditions inconsistent with the specification in effect when the Personal Data
was provided. ICANN shall take reasonable steps to avoid uses of the Personal
Data by third parties inconsistent with the specification.

7.3 Assignment; Change of Ownership or Management.

7.3.1 Except as set forth in this Section 7.3.1, either party may assign or
transfer this Agreement only with the prior written consent of the other party,
which shall not be unreasonably withheld. If ICANN fails to expressly provide
or withhold its consent to any requested assignment (an “Assignment Request”)
of this Agreement by Registrar within thirty (30) calendar days of ICANN’s
receipt of notice of such Assignment Request (or, if ICANN has requested
additional information from Registrar in connection with its review of such
request, sixty (60) calendar days of the receipt of all requested written information
regarding such request) from Registrar, ICANN shall be deemed to have consented
to such requested assignment. Notwithstanding the foregoing, (i) ICANN may
assign this Agreement without the consent of Registrar upon approval of the
ICANN Board of Directors in conjunction with a reorganization, reconstitution
or re-incorporation of ICANN upon such assignee’s express assumption of the
terms and conditions of this Agreement, (ii) Registrar may assign this
Agreement without the consent of ICANN to a wholly-owned subsidiary of
Registrar upon such subsidiary’s express assumption of the terms and conditions
of this Agreement, and (iii) ICANN shall be deemed to have consented to an
Assignment Request in which the assignee associated with such Assignment Request
is a party to a Registrar Accreditation Agreement with ICANN on the terms set
forth in this Agreement (provided that such assignee is then in compliance with
the terms and conditions of such Registrar Accreditation Agreement in all
material respects), unless ICANN provides to Registrar a written objection to
such Assignment Request within ten (10) calendar days of ICANN’s receipt of
notice of such Assignment Request pursuant to this Section 7.3.1.

7.3.2 To the extent that an entity acquires a Controlling interest in
Registrar’s stock, assets or business, Registrar shall provide ICANN notice
within seven (7) days of such an acquisition. Such notification shall include a
statement that affirms that Registrar meets the Specification or Policy on
Accreditation criteria then in effect, and is in compliance with its
obligations under this Agreement. Within thirty (30) days of such notification,
ICANN may request additional information from the Registrar establishing
compliance with this Agreement, in which case Registrar must supply the
requested information within fifteen (15) days. Any disputes concerning
Registrar’s continued Accreditation shall be resolved pursuant to Section 5.8.

7.4 Negotiation Process.

7.4.1 If either the Chief Executive Officer of ICANN (“CEO”) or the
Chairperson of the Registrar Stakeholder Group (“Chair”) desires to discuss any
revision(s) to this Agreement, the CEO or Chair, as applicable, shall provide
written notice to the other person, which shall set forth in reasonable detail
the proposed revisions to this Agreement (a “Negotiation Notice”).
Notwithstanding the foregoing, neither the CEO nor the Chair may (i) propose
revisions to this Agreement that modify any Consensus Policy then existing,
(ii) propose revisions to this Agreement pursuant to this Section 7.4 on or
before June 30, 2014, or (iii) propose revisions or submit a Negotiation Notice
more than once during any twelve month period beginning on July 1, 2014.

7.4.2 Following receipt of the Negotiation Notice by either the CEO or the
Chair, ICANN and the Working Group shall consult in good faith negotiations
regarding the form and substance of the proposed revisions to this Agreement,
which shall be in the form of a proposed amendment to this Agreement (the
“Proposed Revisions”), for a period of at least ninety (90) calendar days
(unless a resolution is earlier reached) and attempt to reach a mutually
acceptable agreement relating to the Proposed Revisions (the “Discussion
Period”).

7.4.3 If, following the conclusion of the Discussion Period, an agreement is
reached on the Proposed Revisions, ICANN shall post the mutually agreed
Proposed Revisions on its website for public comment for no less than thirty
(30) calendar days (the “Posting Period”) and provide notice of such revisions
to all Applicable Registrars in accordance with Section 7.6. ICANN and the
Working Group will consider the public comments submitted on the Proposed
Revisions during the Posting Period (including comments submitted by the
Applicable Registrars). Following the conclusion of the Posting Period, the
Proposed Revisions shall be submitted for Registrar Approval and approval by
the ICANN Board of Directors. If such approvals are obtained, the Proposed
Revisions shall be deemed an Approved Amendment by the Applicable Registrars and
ICANN, and shall be effective and deemed an amendment to this Agreement upon
sixty (60) calendar days notice from ICANN to Registrar.

7.4.4 If, following the conclusion of the Discussion Period, an agreement is
not reached between ICANN and the Working Group on the Proposed Revisions,
either the CEO or the Chair may provide the other person written notice (the
“Mediation Notice”) requiring each party to attempt to resolve the
disagreements related to the Proposed Revisions through impartial, facilitative
(non-evaluative) mediation in accordance with the terms and conditions set
forth below. In the event that a Mediation Notice is provided, ICANN and the
Working Group shall, within fifteen (15) calendar days thereof, simultaneously
post the text of their desired version of the Proposed Revisions and a position
paper with respect thereto on ICANN’s website.

7.4.4.1 The mediation shall be conducted by a single mediator selected by the
parties. If the parties cannot agree on a mediator within fifteen (15)
calendar days following receipt by the CEO or Chair, as applicable, of the
Mediation Notice, the parties will promptly select a mutually acceptable
mediation provider entity, which entity shall, as soon as practicable following
such entity’s selection, designate a mediator, who is a licensed attorney with
general knowledge of contract law and, to the extent necessary to mediate the
particular dispute, general knowledge of the domain name system. Any mediator
must confirm in writing that he or she is not, and will not become during the
term of the mediation, an employee, partner, executive officer, director, or
security holder of ICANN or an Applicable Registrar. If such confirmation is
not provided by the appointed mediator, then a replacement mediator shall be
appointed pursuant to this Section 7.4.4.1.

7.4.4.2 The mediator shall conduct the mediation in accordance with the rules
and procedures for facilitative mediation that he or she determines following
consultation with the parties. The parties shall discuss the dispute in good
faith and attempt, with the mediator’s assistance, to reach an amicable
resolution of the dispute.

7.4.4.3 Each party shall bear its own costs in the mediation. The parties shall
share equally the fees and expenses of the mediator.

7.4.4.4 If an agreement is reached during the mediation, ICANN shall post the
mutually agreed Proposed Revisions on its website for the Posting Period and
provide notice to all Applicable Registrars in accordance with Section 7.6.
ICANN and the Working Group will consider the public comments submitted on the
agreed Proposed Revisions during the Posting Period (including comments
submitted by the Applicable Registrars). Following the conclusion of the
Posting Period, the Proposed Revisions shall be submitted for Registrar
Approval and approval by the ICANN Board of Directors. If such approvals are
obtained, the Proposed Revisions shall be deemed an Approved Amendment by the
Applicable Registrars and ICANN, and shall be effective and deemed an amendment
to this Agreement upon sixty (60) days notice from ICANN to Registrar.

7.4.4.5 If the parties have not resolved the dispute for any reason by the date
that is ninety (90) calendar days following receipt by the CEO or Chair, as
applicable, of the Mediation Notice, the mediation shall automatically
terminate (unless extended by agreement of the parties). The mediator shall
deliver to the parties a definition of the issues that could be considered in
future arbitration, if invoked. Those issues are subject to the limitations
set forth in Section 7.4.5.2 below.

7.4.5 If, following mediation, ICANN and the Working Group have not reached an
agreement on the Proposed Revisions, either the CEO or the Chair may provide
the other person written notice (an “Arbitration Notice”) requiring ICANN and
the Applicable Registry Operators to resolve the dispute through binding
arbitration in accordance with the arbitration provisions of Section 5.8,
subject to the requirements and limitations of this Section 7.4.5.

7.4.5.1 If an Arbitration Notice is sent, the mediator’s definition of issues,
along with the Proposed Revisions (be those from ICANN, Registrars or both)
shall be posted for public comment on ICANN’s website for a period of no less
than thirty (30) calendar days. ICANN and the Working Group will consider the
public comments submitted on the Proposed Revisions during the Posting Period
(including comments submitted by the Applicable Registrars), and information
regarding such comments and consideration shall be provided to the a three (3)
person arbitrator panel. Each party may modify its Proposed Revisions before
and after the Posting Period. The arbitration proceeding may not commence
prior to the closing of such public comment period, and ICANN may consolidate
all challenges brought by registrars (including Registrar) into a single
proceeding. Except as set forth in this Section 7.4.5.1, the arbitration shall
be conducted pursuant to Section 5.8.

7.4.5.2 No dispute regarding the Proposed Revisions may be submitted for
arbitration to the extent the subject matter of the Proposed Revisions (i)
relates to Consensus Policy, (ii) falls within the subject matter categories
set forth in Section 1.2 of the Consensus Policies and Temporary Policies
Specification , or (iii) seeks to amend any of the following provisions or
Specifications of this Agreement: Sections 2, 4 and 6; subsections 3.1, 3.2,
3.3, 3.4, 3.5, 3.7, 3.8, 3.9, 3.14, 3.19, 3.21, 5.1, 5.2 or 5.3; and the
Consensus Policies and Temporary Policies Specification, Data Retention
Specification, WHOIS Accuracy Program Specification, Registration Data
Directory Service (WHOIS) Specification or the Additional Registrar Operation
Specification.

7.4.5.3 The mediator will brief the arbitrator panel regarding ICANN and the
Working Group’s respective proposals relating to the Proposed Revisions.

7.4.5.4 No amendment to this Agreement relating to the Proposed Revisions may be
submitted for arbitration by either the Working Group or ICANN, unless, in the
case of the Working Group, the proposed amendment has received Registrar
Approval and, in the case of ICANN, the proposed amendment has been approved by
the ICANN Board of Directors.

7.4.5.5 In order for the arbitrator panel to approve either ICANN or the Working
Group’s proposed amendment relating to the Proposed Revisions, the arbitrator
panel must conclude that such proposed amendment is consistent with a balanced
application of ICANN’s core values (as described in ICANN’s Bylaws) and
reasonable in light of the balancing of the costs and benefits to the business
interests of the Applicable Registrars and ICANN (as applicable), and the
public benefit sought to be achieved by the Proposed Revisions as set forth in
such amendment. If the arbitrator panel concludes that either ICANN or the
Working Group’s proposed amendment relating to the Proposed Revisions meets the
foregoing standard, such amendment shall be effective and deemed an amendment
to this Agreement upon sixty (60) calendar days notice from ICANN to Registrar
and deemed an Approved Amendment hereunder.

7.4.6 With respect to an Approved Amendment relating to an amendment proposed
by ICANN, Registrar may apply in writing to ICANN for an exemption from such
amendment pursuant to the provisions of Section 6.8.

7.4.7 Notwithstanding anything in this Section 7.4 to the contrary, (a) if
Registrar provides evidence to ICANN’s reasonable satisfaction that the
Approved Amendment would materially increase the cost of providing Registrar
Services, then ICANN will allow up to one-hundred eighty (180) calendar days
for the Approved Amendment to become effective with respect to Registrar, and
(b) no Approved Amendment adopted pursuant to Section 7.4 shall become
effective with respect to Registrar if Registrar provides ICANN with an
irrevocable notice of termination pursuant to Section 5.4.

7.5 No Third-Party Beneficiaries. This Agreement shall not be
construed to create any obligation by either ICANN or Registrar to any
non-party to this Agreement, including any Registered Name Holder.

7.6 Notices and Designations. Except as provided in Section
4.4 and Section 6, all notices to be given under this Agreement shall be given
in writing at the address of the appropriate party as set forth below, unless
that party has given a notice of change of address in writing. Each party shall
notify the other party within thirty (30) days of any change to its contact
information. Any written notice required by this Agreement shall be deemed to
have been properly given when delivered in person, when sent by electronic
facsimile with receipt of confirmation of delivery, when scheduled for delivery
by internationally recognized courier service, or when delivered by electronic
means followed by an affirmative confirmation of receipt by the recipient’s
facsimile machine or email server. For any notice of a new Specification or
Policy established in accordance with this Agreement, Registrar shall be
afforded a reasonable period of time after notice of the establishment of such
Specification or Policy is e-mailed to Registrar and posted on the ICANN
website in which to comply with that specification, policy or program, taking
into account any urgency involved. Notices and designations by ICANN under
this Agreement shall be effective when written notice of them is deemed given
to Registrar.

If to
ICANN, addressed to:

Attention: Registrar
Accreditation Notices
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, California 90094-2536 USA
Telephone: +1 310 823-9358
Facsimile: + 1 310 823-8649

If to Registrar, addressed to:

Attention: [contact person]
[Registrar Name]
[Courier Address]
[Mailing Address]
Registrar Website URL: [URL]
Telephone: [telephone number]
Facsimile: [fax number]
e-mail: [e-mail address]

7.7 Dates and Times. All dates and times relevant to this
Agreement or its performance shall be computed based on the date and time
observed in Los Angeles, California, USA.

7.8 Language. All notices, designations, and Specifications or
Policies made under this Agreement shall be in the English language.

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

7.10 Entire
Agreement. Except to the extent (a) expressly provided in a written
agreement executed by both parties concurrently herewith or (b) of written
assurances provided by Registrar to ICANN in connection with its Accreditation,
this Agreement (including the specifications, which form part of it)
constitutes the entire agreement of the parties pertaining to the Accreditation
of Registrar and supersedes all prior agreements, understandings, negotiations
and discussions, whether oral or written, between the parties on that subject.

7.11 Severability.
If one or more provisions of this Agreement are held to be unenforceable under
applicable law, the parties agree to renegotiate such provision in good faith.
In the event that the parties cannot reach a mutually agreeable and enforceable
replacement for such provision, then (a) such provision shall be excluded from
this Agreement; (b) the balance of this Agreement shall be interpreted as if
such provision were so excluded; and (c) the balance of this Agreement shall be
enforceable in accordance with its terms.

[signature
page follows]

IN WITNESS WHEREOF, the parties
hereto have caused this Agreement to be executed in duplicate by their duly
authorized representatives.

ICANN

By: ___________________________________

Name: ________________________________

Title: __________________________________

[Registrar]

By: ___________________________________

Name: ________________________________

Title: __________________________________

Registrar
shall implement and comply with the requirements set forth in this
Specification, as well as any commercially practical updates to this
Specification that are developed by ICANN and the Registrar Stakeholder Group
during the Term of the Registrar Accreditation Agreement.

Except as provided for in Section 3
below, within fifteen (15) days of (1) the registration of a Registered Name
sponsored by Registrar, (2) the transfer of the sponsorship of a Registered
Name to Registrar, or (3) any change in the Registered Name Holder with respect
to any Registered Name sponsored by Registrar, Registrar will, with respect to
both Whois information and the corresponding customer account holder contact
information related to such Registered Name:

Validate the presence of data for all
fields required under Subsection 3.3.1 of the Agreement in a proper format for
the applicable country or territory.

Validate that all email addresses are in
the proper format according to RFC 5322 (or its successors).

Validate that telephone numbers are in
the proper format according to the ITU-T
E.164 notation for
international telephone numbers (or its equivalents or successors).

Validate that postal addresses are in a
proper format for the applicable country or territory as defined in UPU Postal
addressing format templates, the S42 address templates (as they may be updated)
or other standard formats.

Validate that all postal address fields
are consistent across fields (for example: street exists in city, city exists
in state/province, city matches postal code) where such information is
technically and commercially feasible for the applicable country or territory.

Verify:

the email address of the Registered Name Holder (and, if
different, the Account Holder) by sending an email requiring an affirmative
response through a tool-based authentication method such as providing a unique code that must be
returned in a manner designated by the Registrar, or

the telephone number of the Registered
Name Holder (and, if different, the Account Holder) by either (A) calling or sending an SMS to the
Registered Name Holder’s telephone number providing a unique code that must be
returned in a manner designated by the Registrar, or (B) calling the Registered
Name Holder’s telephone number and requiring the Registered Name Holder to
provide a unique code that was sent to the Registered Name Holder via web,
email or postal mail.

In
either case, if Registrar does not receive an affirmative response from the
Registered Name Holder, Registrar shall either verify the applicable contact
information manually or suspend the registration, until such time as Registrar
has verified the applicable contact information. If Registrar does not receive
an affirmative response from the Account Holder, Registrar shall verify the
applicable contact information manually, but is not required to suspend any
registration.

Except as provided in Section 3 below,
within fifteen (15) calendar days after receiving any changes to contact
information in Whois or the corresponding customer account contact information
related to any Registered Name sponsored by Registrar (whether or not Registrar was previously
required to perform the validation and verification requirements set forth in
this Specification in respect of such Registered Name), Registrar will validate and, to the
extent required by Section 1, verify the changed fields in the manner specified
in Section 1 above. If Registrar does not receive an affirmative response from
the Registered Name Holder providing the required verification, Registrar shall
either verify the applicable contact information manually or suspend the
registration, until such time as Registrar has verified the applicable contact
information. If Registrar does not receive an affirmative response from the
Account Holder, Registrar shall verify the applicable contact information
manually, but is not required to suspend any registration.

Except as set forth in paragraph 4 below,
Registrar is not required to perform the above validation and verification procedures
in Section 1(a) through 1(f) above, if Registrar has already successfully
completed the validation and verification procedures on the identical contact
information and is not in possession of facts or knowledge of circumstances
that suggest that the information is no longer valid.

If Registrar has any information
suggesting that the contact information specified in Section 1(a) through 1(f)
above is incorrect (such as Registrar receiving a bounced email notification or
non-delivery notification message in connection with compliance with ICANN’s
Whois Data Reminder Policy or otherwise) for any Registered Name sponsored by
Registrar (whether or not Registrar was previously required to perform the
validation and verification requirements set forth in this Specification in
respect of such Registered Name), Registrar must verify or re-verify, as
applicable, the email address(es) as described in Section 1.f (for example by
requiring an affirmative response to a Whois Data Reminder Policy notice). If, within fifteen (15)
calendar days after receiving any such information, Registrar does not receive
an affirmative response from the Registered Name Holder providing the required
verification, Registrar shall either verify the applicable contact information
manually or suspend the registration, until such time as Registrar has verified
the applicable contact information. If, within fifteen (15) calendar days
after receiving any such information, Registrar does not receive an affirmative
response from the customer paying for the Registered Name, if applicable,
providing the required verification, Registrar shall verify the applicable
contact information manually, but is not required to suspend any registration.

Upon the occurrence of a Registered
Name Holder’s willful provision of inaccurate or unreliable WHOIS information,
its willful failure promptly to update information provided to Registrar, or
its failure to respond for over fifteen (15) calendar days to inquiries by
Registrar concerning the accuracy of contact details associated with the
Registered Name Holder’s registration, Registrar shall either terminate or
suspend the Registered Name Holder’s Registered Name or place such registration
on clientHold and clientTransferProhibited, until such time as Registrar has
validated the information provided by the Registered Name Holder.

The terms and conditions of this
Specification shall be reviewed by ICANN in consultation with the Registrar
Stakeholder Group on or about the first anniversary of the date that the form
of this Agreement is first executed by a registrar.

Nothing within this Specification shall
be deemed to require Registrar to perform verification or validation of any
customer account holder information where the customer account holder does not

have any Registered Names under sponsorship of Registrar.

Registration Data
Directory Services. Until
ICANN requires a different protocol, Registrar will operate a WHOIS service available
via port 43 in accordance with RFC 3912, and a web-based Directory Service
providing free public query-based access to at least the elements set forth in
Section 3.3.1.1 through 3.3.1.8 of the Registrar Accreditation Agreement in the
format set forth in Section 1.4 of this Specification. ICANN reserves the right
to specify alternative formats and protocols, and upon such specification, the
Registrar will implement such alternative specification as soon as reasonably
practicable.

Following the
publication by the IETF of a Proposed Standard, Draft Standard or Internet
Standard and any revisions thereto (as specified in RFC 2026) relating to the
web-based directory service as specified in the IETF Web Extensible Internet
Registration Data Service working group, Registrar shall implement the
directory service specified in any such standard (or any revision thereto) no
later than 135 days after such implementation is requested by ICANN. Registrar
shall implement internationalized registration data publication guidelines
according to the specification published by ICANN following the work of the
ICANN Internationalized Registration Data Working Group (IRD-WG) and its
subsequent efforts, no later than 135 days after it is approved by the ICANN
Board.

1.1. The format of
responses shall follow a semi-free text format outline below, followed by a
blank line and a legal disclaimer specifying the rights of Registrar, and of
the user querying the database.

1.2. Each data object
shall be represented as a set of key/value pairs, with lines beginning with
keys, followed by a colon and a space as delimiters, followed by the value.

1.3. For fields where more
than one value exists, multiple numbered key/value pairs with the same key
shall be allowed (for example to list multiple name servers). The first
key/value pair after a blank line should be considered the start of a new
record, and should be considered as identifying that record, and is used to
group data, such as hostnames and IP addresses, or a domain name and registrant
information, together.

1.4. Domain Name Data:

1.4.1. Query format: whois –h whois.example-registrar.tld
EXAMPLE.TLD

1.4.2. Response format:

The format of responses shall contain all
the elements and follow a semi-free text format outline below. Additional data
elements can be added at the end of the text format outlined below. The data
element may, at the option of Registrar, be followed by a blank line and a
legal disclaimer specifying the rights of Registrar, and of the user querying
the database (provided that any such legal disclaimer must be preceded by such
blank line).

Domain Name: EXAMPLE.TLD
Registry Domain ID: D1234567-TLD
Registrar WHOIS Server: whois.example-registrar.tld
Registrar URL: http://www.example-registrar.tld
Updated Date: 2009-05-29T20:13:00Z
Creation Date: 2000-10-08T00:45:00Z
Registrar Registration Expiration Date: 2010-10-08T00:44:59Z
Registrar: EXAMPLE REGISTRAR LLC
Registrar IANA ID: 5555555
Registrar Abuse Contact Email: email@registrar.tld
Registrar Abuse Contact Phone: +1.1235551234
Reseller: EXAMPLE RESELLER¹
Domain Status: clientDeleteProhibited²
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Registry Registrant ID: 5372808-ERL³
Registrant Name: EXAMPLE REGISTRANT⁴
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State/Province: AP⁵
Registrant Postal Code: A1A1A1⁶
Registrant Country: AA
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234⁷
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.TLD
Registry Admin ID: 5372809-ERL⁸
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State/Province: AP
Admin Postal Code: A1A1A1
Admin Country: AA
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext: 1234
Admin Email: EMAIL@EXAMPLE.TLD
Registry Tech ID: 5372811-ERL⁹
Tech Name: EXAMPLE REGISTRANT TECHNICAL
Tech Organization: EXAMPLE REGISTRANT LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State/Province: AP
Tech Postal Code: A1A1A1
Tech Country: AA
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.TLD
Name Server: NS01.EXAMPLE-REGISTRAR.TLD¹⁰
Name Server: NS02.EXAMPLE-REGISTRAR.TLD
DNSSEC: signedDelegation
URL of the ICANN WHOIS Data Problem Reporting System: http://wdprs.internic.net/
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

1.5. The format of the
following data fields: domain status, individual and organizational names,
address, street, city, state/province, postal code, country, telephone and fax
numbers, email addresses, date and times must conform to the mappings specified
in EPP RFCs 5730-5734 (or its successors), and IPv6 addresses format should
conform to RFC 5952 (or its successor), so that the display of this information
(or values returned in WHOIS responses) can be uniformly processed and understood.

Service Level
Agreement for Registration Data Directory Services (RDDS)

2.1 Definitions

2.2 Service Level Agreement Matrix

Registrar
is encouraged to do maintenance for the different services at the times and

dates of statistically lower traffic for each service. Since substantial
downtime is already incorporated in the availability metric, planned outages or
similar; any downtime, be it for maintenance or due to system failures, will be
noted simply as downtime and counted for SLA purposes.

2.2.1 RDDS availability. Refers to the ability of
all the RDDS services for the Registrar to respond to queries from an Internet
user with appropriate data from the relevant registrar system. If 51% or more
of the RDDS testing probes see any of the RDDS services as unavailable during a
given time, the RDDS will be considered unavailable.

2.2.2 WHOIS query RTT. Refers to the RTT of the sequence
of packets from the start of the TCP connection to its end, including the
reception of the WHOIS response. If the RTT is 5-times or more the
corresponding SLR, the RTT will be considered undefined.

2.2.3 Web-based-WHOIS
query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to
its end, including the reception of the HTTP response for only one HTTP
request. If Registrar implements a multiple-step process to get to the
information, only the last step shall be measured. If the RTT is 5-times
or more the corresponding SLR, the RTT will be considered undefined.

2.2.4 RDDS query RTT. Refers to the collective of “WHOIS
query RTT” and “Web-based- WHOIS query RTT“.

2.2.5 RDDS update time. Refers to the time measured from the receipt
of an EPP confirmation to a transform command on a domain name, host or
contact, up until the servers of the RDDS services reflect the changes made.

2.2.6 RDDS test. Means one query sent to a particular “IP
address” of one of the servers of one of the RDDS services. Queries shall
be about existing objects in the registrar system and the responses must
contain the corresponding information otherwise the query will be considered
unanswered. Queries with an RTT 5 times higher than the corresponding
SLR will be considered as unanswered. The possible results to an RDDS test are:
a number in milliseconds corresponding to the RTT or
undefined/unanswered.

2.2.7 Measuring RDDS
parameters. Every 5
minutes, RDDS probes will select one IP address from all the public-DNS registered
“IP addresses” of the servers for each RDDS service of the Registrar
being monitored and make an “RDDS test” to each one. If an “RDDS test”
result is undefined/unanswered, the corresponding RDDS service will be
considered as unavailable from that probe until it is time to make a new test.

2.2.8 Collating the
results from RDDS probes. The
minimum number of active testing probes to consider a measurement valid is 10
at any given measurement period, otherwise the measurements will be discarded
and will be considered inconclusive; during this situation no fault will be
flagged against the SLRs.

2.2.9 Placement of RDDS
probes. Probes for
measuring RDDS parameters shall be placed inside the networks with the most
users across the different geographic regions; care shall be taken not to
deploy probes behind high propagation-delay links, such as satellite links.

2.3 Covenants of Performance Measurement

Registrar
shall not interfere with measurement Probes, including any form of
preferential treatment of the requests for the monitored services. Registrar
shall respond to the measurement tests described in this Specification as it
would do with any other request from Internet users (for RDDS).

Consensus Policies.

1.1. “Consensus Policies” are
those policies established (1) pursuant to the procedure set forth in ICANN’s
Bylaws and due process, and (2) covering those topics listed in Section 1.2 of
this document. The Consensus Policy development process and procedure set forth
in ICANN’s Bylaws may be revised from time to time in accordance with the
process set forth therein.

1.2. 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 registrars. Consensus Policies
shall relate to one or more of the following:

1.2.1. issues for which uniform
or coordinated resolution is reasonably necessary to facilitate
interoperability, security and/or stability of the Internet, Registrar Services,
Registry Services, or the Domain Name System (“DNS”);

1.2.2. functional and
performance specifications for the provision of Registrar Services;

1.2.3. registrar policies
reasonably necessary to implement Consensus Policies relating to a gTLD
registry;

1.2.4. resolution of disputes
regarding the registration of domain names (as opposed to the use of such
domain names, but including where such policies take into account use of the
domain names); or

1.2.5. restrictions on
cross-ownership of registry operators and registrars or Resellers and
regulations and restrictions with respect to registrar and registry operations
and the use of registry and registrar data in the event that a registry
operator and a registrar or Reseller are affiliated.

1.3. Such categories of issues referred to in
Section 1.2 shall include, without limitation:

1.3.1. principles for
allocation of registered names in a TLD (e.g., first-come/first-served, timely
renewal, holding period after expiration);

1.3.2. prohibitions on
warehousing of or speculation in domain names by registries or registrars;

1.3.3. reservation of
registered names in a TLD that may not be registered initially or that may not
be renewed due to reasons reasonably related to (i) avoidance of confusion
among or misleading of users, (ii) intellectual property, or (iii) the
technical management of the DNS or the Internet (e.g., establishment of
reservations of names from registration);

1.3.4. maintenance of and
access to accurate and up-to-date information concerning Registered Names and
name servers;

1.3.5. procedures to avoid
disruptions of domain name registrations due to suspension or termination of
operations by a registry operator or a registrar, including procedures for
allocation of responsibility among continuing registrars of the Registered
Names sponsored in a TLD by a registrar losing accreditation;
and

1.3.6. the transfer of
registration data upon a change in registrar sponsoring one or more Registered
Names.

1.4. In addition to the other limitations on
Consensus Policies, they shall not:

1.4.1. prescribe or limit the
price of Registrar Services;

1.4.2. modify
the limitations on Temporary Policies (defined below) or Consensus Policies;

1.4.3. modify
the provisions in the Registrar Accreditation Agreement regarding terms or
conditions for the renewal, termination or amendment of the Registrar
Accreditation Agreement or fees paid by Registrar to ICANN; or

1.4.4. modify ICANN’s
obligations to not apply standards, policies, procedures or practices
arbitrarily, unjustifiably, or inequitably and to not single out Registrar for
disparate treatment unless justified by substantial and reasonable cause, and
exercise its responsibilities in an open and transparent manner.

Temporary Policies. Registrar shall comply with and
implement all specifications or policies established by the ICANN Board of
Directors (the “Board“) on a temporary basis, if adopted by the
Board by a vote of at least two-thirds of its members, so long as the Board
reasonably determines that such modifications or amendments are justified and
that immediate temporary establishment of a specification or policy on the
subject is necessary to maintain the stability or security of Registrar
Services, Registry Services or the DNS or the Internet (“Temporary
Policies“).

2.1. Such proposed specification or policy
shall be as narrowly tailored as feasible to achieve those objectives. In
establishing any Temporary Policy, the Board shall state the period of time for
which the Temporary Policy is adopted and shall immediately implement the
Consensus Policy development process set forth in ICANN’s Bylaws.

2.1.1. ICANN shall also issue
an advisory statement containing a detailed explanation of its reasons for
adopting the Temporary Policy and why the Board believes such Temporary Policy
should receive the consensus support of Internet stakeholders.

2.1.2. If the period of time
for which the Temporary Policy is adopted exceeds 90 days, the Board shall
reaffirm its temporary adoption every 90 days for a total period not to exceed
one year, in order to maintain such Temporary Policy in effect until such time
as it becomes a Consensus Policy. If the one year period expires or, if during
such one year period, the Temporary Policy does not become a Consensus Policy
and is not reaffirmed by the Board, Registrar shall no longer be required to
comply with or implement such Temporary Policy.

Notice and Conflicts. Registrar
shall be afforded a reasonable period of time following notice of the
establishment of a Consensus Policy or Temporary Policy in which to comply with
such policy or specification, taking into account any urgency involved. In the
event of a conflict between Registrar Services and Consensus Policies or any
Temporary Policy, the Consensus Polices or Temporary Policy shall control, but
only with respect to subject matter in conflict. For the avoidance of doubt,
Consensus Policies that meet the requirements of this Specification may
supplement or supersede provisions of the agreements between Registrar and
ICANN, but only to the extent that such Consensus Policies relate to the
matters set forth in Section 1.2 and 1.3 of this Specification.

The expiration date of the 2013 Registrar Accreditation Agreement Specification on Privacy and Proxy Registrations has been extended to 31 January 2021, pursuant to an agreement between ICANN and a working group appointed by the Registrar Stakeholder Group.

Until the earlier to occur of (i) January
1, 2017, and (ii) the date ICANN establishes and implements a Privacy and Proxy
Accreditation Program as referenced in Section 3.14 of the Registrar
Accreditation Agreement, Registrar agrees to comply, and to require its
Affiliates and Resellers to comply, with the terms of this Specification,
provided that ICANN and the Working Group may mutually agree to extend the term
of this Specification. This Specification may not be modified by ICANN or
Registrar.

1.1 “P/P Customer” means, regardless
of the terminology used by the P/P Provider, the licensee, customer, beneficial
user, beneficiary, or other recipient of Privacy Services and Proxy Services.

1.2 “Privacy Service” is a service by
which a Registered Name is registered to its beneficial user as the Registered
Name Holder, but for which alternative, reliable contact information is
provided by the P/P Provider for display of the Registered Name Holder’s
contact information in the Registration Data Service (Whois) or equivalent
services.

1.3 “Proxy Service” is a service
through which a Registered Name Holder licenses use of a Registered Name to the
P/P Customer in order to provide the P/P Customer use of the domain name, and
the Registered Name Holder’s contact information is displayed in the
Registration Data Service (Whois) or equivalent services rather than the P/P
Customer’s contact information.

1.4 “P/P Provider” or “Service
Provider” is the provider of Privacy/Proxy Services, including Registrar and
its Affiliates, as applicable.

2.1 Disclosure of Service Terms.
P/P Provider shall publish the terms and conditions of its service (including
pricing), on its website and/or Registrar’s website.

2.2 Abuse/Infringement Point of
Contact. P/P Provider shall publish a point of contact for third parties
wishing to report abuse or infringement of trademarks (or other rights).

2.3 Disclosure of Identity of P/P
Provider. P/P Provider shall publish its business contact information on
its website and/or Registrar’s website.

2.4 Terms of service and
description of procedures. The P/P Provider shall publish on its website
and/or Registrar’s website a copy of the P/P Provider service agreement and
description of P/P Provider’s procedures for handling the following:

2.4.1 The process or facilities to
report abuse of a domain name registration managed by the P/P Provider;

2.4.2 The process or facilities to
report infringement of trademarks or other rights of third parties;

2.4.3 The circumstances under which the
P/P Provider will relay communications from third parties to the P/P Customer;

2.4.4 The circumstances under which the
P/P Provider will terminate service to the P/P Customer;

2.4.5 The circumstances under which the P/P Provider will reveal and/or publish in the Registration Data Service
(Whois) or equivalent service the P/P Customer’s identity and/or contact data;
and

2.4.6 A description of the support services offered by P/P Providers to P/P Customers, and how to access these
services.

2.5 Escrow of P/P Customer
Information. Registrar shall include P/P Customer contact information in
its Registration Data Escrow deposits required by Section 3.6 of the
Agreement. P/P Customer Information escrowed pursuant to this Section 2.5 of
this Specification may only be accessed by ICANN in the event of the
termination of the Agreement or in the event Registrar ceases business
operations.

3.1 Registered Name Holder employed
the services of a P/P Provider that is not provided by Registrar, or any of its
Affiliates;

3.2 Registered Name Holder licensed a
Registered Name to another party (i.e., is acting as a Proxy Service) without
Registrar’s knowledge; or

3.3 Registered Name Holder has used
P/P Provider contact data without subscribing to the service or accepting the
P/P Provider terms and conditions.

During the Term of
this Agreement, for each Registered Name sponsored by Registrar within a gTLD,
Registrar shall collect and securely maintain in its own electronic database
(as updated from time to time) the data specified below:

1.1. Registrar
shall collect the following information from registrants at the time of
registration of a domain name (a “Registration”) and shall maintain that
information for the duration of Registrar’s sponsorship of the Registration and
for a period of two additional years thereafter:

1.1.1. First and
last name or full legal name of registrant;

1.1.2. First and
last name or, in the event registrant is a legal person, the title of the
registrant’s administrative contact, technical contact, and billing contact;

1.1.3. Postal
address of registrant, administrative contact, technical contact, and billing
contact;

1.1.4. Email address
of registrant, administrative contact, technical contact, and billing contact;

1.1.5. Telephone
contact for registrant, administrative contact, technical contact, and billing
contact;

1.1.6. WHOIS
information, as set forth in the WHOIS Specification;

1.1.7. Types of
domain name services purchased for use in connection with the Registration; and

1.1.8. To the extent
collected by Registrar, “card on file,” current period third party transaction
number, or other recurring payment data.

1.2. Registrar
shall collect the following information and maintain that information for no
less than one hundred and eighty (180) days following the relevant interaction:

1.2.1. Information
regarding the means and source of payment reasonably necessary for the
Registrar to process the Registration transaction, or a transaction number
provided by a third party payment processor;

1.2.2. Log files, billing
records and, to the extent collection and maintenance of such records is
commercially practicable or consistent with industry-wide generally accepted
standard practices within the industries in which Registrar operates, other
records containing communications source and destination information,
including, depending on the method of transmission and without limitation: (1)
Source IP address, HTTP headers, (2) the telephone, text, or fax number; and
(3) email address, Skype handle, or instant messaging identifier, associated
with communications between Registrar and the registrant about the
Registration; and

1.2.3. Log files and, to the
extent collection and maintenance of such records is commercially practicable
or consistent with industry-wide generally accepted standard practices within
the industries in which Registrar operates, other records associated with the
Registration containing dates, times, and time zones of communications and
sessions, including
initial registration.

If, based on the receipt of
either (i) a written legal opinion from a nationally recognized law firm in the
applicable jurisdiction that states that the collection and/or retention of any
data element specified herein by Registrar is reasonably likely to violate
applicable law (the “Opinion”) or (ii) a ruling of, or written guidance from,
a governmental body of competent jurisdiction providing that compliance with
the data collection and/or retention requirements of this Specification
violates applicable law, Registrar determines in good faith that the collection
and/or retention of any data element specified in this Specification violates
applicable law, Registrar may provide written notice of such determination to
ICANN and request a waiver from compliance with specific terms and conditions
of this Specification (a “Waiver Request”). Such written notice shall: (i)
specify the relevant applicable law, the allegedly offending data collection
and retention elements, the manner in which the collection and/or retention of
such data violates applicable law, and a reasonable description of such
determination and any other facts and circumstances related thereto, (ii) be
accompanied by a copy of the Opinion and governmental ruling or guidance, as
applicable, and (iii) be accompanied by any documentation received by Registrar
from any governmental authority, in each case, related to such determination,
and such other documentation reasonably requested by ICANN. Following receipt
of such notice, ICANN and Registrar shall discuss the matter in good faith in
an effort to reach a mutually acceptable resolution of the matter. Until such
time as ICANN’s Procedure for Handling Whois Conflicts with Privacy Law is
modified to include conflicts relating to the requirements of this
Specification and if ICANN agrees with Registrar’s determination, ICANN’s
office of general counsel may temporarily or permanently suspend compliance and
enforcement of the affected provisions of this Specification and grant the
Waiver Request. Prior to granting any exemption hereunder, ICANN will post its
determination on its website for a period of thirty (30) calendar days.
Following such modification of ICANN’s Procedure for Handling Whois Conflicts
with Privacy Law, all Waiver Requests (whether granted or denied) shall be
resolved pursuant to such modified procedures.

Registrar shall provide to ICANN the
information specified below, which shall be maintained in accordance with
Section 3.17 of the Agreement. With regard to information identified below,
ICANN will hold such information pursuant to the disclosure requirements set
forth in Section 3.15 of the Agreement.

General Information

Full legal name of Registrar.

Legal form of the Registrar
(e.g., LLC, Corporation, Government Body, Intergovernmental Organization,
etc.).

The jurisdiction in which the
Registrar’s business is registered for legal and financial purposes.

The Registrar’s business
registration number and the name of the authority that issued this number.

Every business name and/or trade
name used by the Registrar.

Provide current documentation
demonstrating that the Registrar entity is legally established and in good
standing. For proof of establishment, provide charter documents or other
equivalent document (e.g., membership agreement) of the entity. If the
Registrar is a government body or organization, provide a certified copy of the
relevant statute, governmental decision or other instrument under which the
government body or organization has been established. With respect to an entity
other than a government body or organization, where no such certificates or
documents are available in the Registrar’s jurisdiction, an affidavit drafted
and signed by a notary public or a legal practitioner duly qualified in the
courts of the Registrar’s jurisdiction, declaring that the organization is
established and in good standing, must be provided.

Correspondence address for the
Registrar.* This address will be used for contractual purposes, and the
Registrar must be able to accept notices and service of legal process at this
address. No Post Office boxes are allowed.

Primary phone number where the
Registrar can be reached for contractual purposes.

Primary Fax number where the
Registrar can be reached for contractual purposes.

Primary Email address where the
Registrar can be reached for contractual purposes.

If the location or address of
Registrar’s principal place of business is different from the address provided
in 7, provide details including address, phone number, fax number and email
address.* Provide ICANN with current documentation demonstrating that the
Registrar is legally entitled to do business in the principal place of
business.

Any other addresses where the
Registrar will be operated or managed, if different from either its principal
place of business or correspondence address provided above. (If so, please
explain.) Provide ICANN with current documentation demonstrating that the
Registrar is legally entitled to do business in each location identified.

Primary contact name:

Title
Address
Phone number
Fax number
Email address

URL and Location of Port 43 WHOIS
server.

Ownership, Directors and Officers
Information

Full name, contact information,
and position of any persons or entities owning at least 5% of the ownership
interest in Registrar’s current business entity. For each person listed, please
specify such person’s percentage ownership.

Full name, contact information,
and position of all directors of the Registrar.

Full name, contact information,
and position of all officers of the Registrar.* (Officer names and positions
must be publicly displayed.)

Full name, contact information,
and position of all senior management and other key personnel overseeing the
provision of Registrar Services.

For every person or entity
mentioned in the answers to questions 15 to 18, indicate if that person or
entity:

within the past ten years, has been
convicted of a felony or of a misdemeanor related to financial activities, or
has been judged by a court to have committed fraud or breach of fiduciary duty,
or has been the subject of a judicial determination that is similar or related
to any of these;

within the past ten years, has been
disciplined by any government or industry regulatory body for conduct involving
dishonesty or misuse of funds of others;

is currently involved in any judicial
or regulatory proceeding that could result in a conviction, judgment,
determination, or discipline of the type specified in items 19(a) or 19(b); or

is the subject of a disqualification
imposed by ICANN.

Provide details if any of the above
events in (a)-(d) have occurred.

List all Affiliated Registrars, if
any, and briefly describe the Affiliation.

For any entities listed in item
20, must provide information required in items 1-14 above.

List the ultimate parent entity of
the Registrar, if applicable.*

Other

Does the Registrar or any of its
Affiliates offer any Privacy Service or Proxy Service (as such terms on defined
in the Specification on Privacy and Proxy Registrations)? If yes, list the
entities or individuals providing the Privacy Service or Proxy Service.

For any entities listed in item
23, provide information required in 1-14 above.

Does the Registrar utilize or
benefit from the services of Resellers?

If yes, provide a list of all such
Resellers known to Registrar. The information specified in this item 26 shall
be made available to ICANN upon request. At such time as ICANN develops a
secure method for the receipt and retention of such information, such
information shall thereafter be provided to ICANN in accordance with Section
3.17 of the Agreement.

* Items marked with “*” must
also be published on Registrar’s website.

This Specification may be modified by
ICANN from time to time after consultation with the Registrar Stakeholder Group
(or its successor), provided that such updates are commercially practical with
respect to the registrar industry, taken as a whole.

DNSSEC

Registrar must allow its customers to use DNSSEC upon request by relaying orders to add, remove or change public key material (e.g., DNSKEY or DS resource records) on
behalf of customers to the Registries that support DNSSEC. Such requests shall
be accepted and processed in a secure manner and according to industry best
practices. Registrars shall accept any public key algorithm and digest type
that is supported by the TLD of interest and appears in the registries posted
at: <http://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xml>
and <http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xml>.
All such requests shall be transmitted to registries using the EPP extensions
specified in RFC 5910 or its successors.

IPv6

To the extent that Registrar offers registrants the ability
to register nameserver addresses, Registrar must allow both IPv4 addresses and
IPv6 addresses to be specified.

IDN

If the Registrar offers Internationalized Domain Name (“IDN”)
registrations, all new registrations must comply with RFCs 5890, 5891, 5892,
5893 and their successors. Registrar shall also comply with the IDN Guidelines
at http://www.icann.org/en/topics/idn/implementation-guidelines.htm which may be amended, modified, or superseded from time to time. Registrar must
use the IDN tables published by the relevant registry.

Domain
Name Registrants’ Rights:

Your domain name
registration and any privacy/proxy services you may use in conjunction with it
must be subject to a Registration Agreement with an ICANN Accredited Registrar.

You are entitled to
review this Registration Agreement at any time, and download a copy for your
records.

You are entitled to accurate and accessible information about:

The identity of your
ICANN Accredited Registrar;

The identity of any
proxy or privacy service provider affiliated with your Registrar;

The terms and
conditions, including pricing information, applicable to any privacy services
offered by your Registrar;

The customer support
services offered by your Registrar and the privacy services provider, and how
to access them;

How to raise concerns
and resolve disputes with your Registrar and any privacy services offered by
them; and

Instructions that
explain your Registrar’s processes for registering, managing, transferring,
renewing, and restoring your domain name registrations, including through any
proxy or privacy services made available by your Registrar.

You shall not be subject to false
advertising or deceptive practices by your Registrar or though any proxy or
privacy services made available by your Registrar. This includes deceptive
notices, hidden fees, and any practices that are illegal under the consumer
protection law of your residence.

Domain Name Registrants’
Responsibilities:

You must comply with
the terms and conditions posted by your Registrar, including applicable
policies from your Registrar, the Registry and ICANN.

You must review your
Registrar’s current Registration Agreement, along with any updates.

You will assume sole
responsibility for the registration and use of your domain name.

You must provide
accurate information for publication in directories such as WHOIS, and promptly
update this to reflect any changes.

You must respond to
inquiries from your Registrar within fifteen (15) days, and keep your Registrar
account data current. If you choose to have your domain name registration renew
automatically, you must also keep your payment information current

The Internet Corporation for Assigned
Names and Numbers, a California non-profit, public benefit corporation
(“ICANN”), and [Registrar Name], a [organization type and jurisdiction]
(“Registrar”) have entered into a Registrar Accreditation Agreement (“Registrar
Accreditation Agreement”), of which this appendix (“Logo License
Specification”) is a part. Definitions in the Registrar Accreditation Agreement
apply in this Logo License Specification.

Registrar wishes to acquire from ICANN,
and ICANN wishes to grant to Registrar, a license to use the trademarks listed
below the signature block of this Logo License Specification (“Trademarks”) in
connection with Registrar’s role as an ICANN-accredited registrar. Pursuant to
and subject to the Registrar Accreditation Agreement, Registrar and ICANN
hereby agree as follows:

LICENSE

Grant of License. ICANN grants to
Registrar a non-exclusive, worldwide right and license to use the Trademarks,
during the term of this specification and solely in connection with the
provision and marketing of Registrar Services in order to indicate that
Registrar is accredited as a registrar of domain names by ICANN. Except as
provided in this subsection and Subsection 2.2 of the Registrar Accreditation
Agreement, Registrar shall not use the Trademarks, any term, phrase, or design
which is confusingly similar to the Trademarks or any portion of the Trademarks
in any manner whatsoever.

Ownership of Trademarks. Any and all
rights in the Trademarks that may be acquired by Registrar shall inure to the
benefit of, and are hereby assigned to, ICANN. Registrar shall not assert
ownership of the Trademarks or any associated goodwill.

No Sublicense. Registrar shall not
sublicense any of its rights under this specification to any other person or
entity (including any of Registrar’s resellers) without the prior written
approval of ICANN.

REGISTRATION AND ENFORCEMENT

Registration. Registration and any
other form of protection for the Trademarks shall only be obtained by ICANN in
its name and at its expense.

Enforcement. Registrar shall promptly
notify ICANN of any actual or suspected infringement of the Trademarks by third
parties, including Registrar’s resellers or affiliates. ICANN shall have the
sole discretion to initiate and maintain any legal proceedings against such
third parties; Registrar shall not take any such actions without the prior
written approval of ICANN; and ICANN shall retain any and all recoveries from
such actions.

Further Assurances. Registrar agrees
to execute such other documents and to take all such actions as ICANN may
request to effect the terms of this specification, including providing such
materials (for example URLs and samples of any promotional materials bearing
the Trademarks), cooperation, and assistance as may be reasonably required to
assist ICANN in obtaining, maintaining, and enforcing trademark registration(s)
and any other form of protection for the Trademarks.

TERM AND TERMINATION

This Logo License Specification shall be
effective from the date it is signed below by both parties until the Expiration
Date, unless this specification or the Registrar Accreditation Agreement is
earlier terminated. Each party shall have the right to terminate this specification
at any time by giving the other party written notice. Upon expiration or
termination of this specification, Registrar shall immediately discontinue all
use of the Trademarks.

IN WITNESS WHEREOF, the parties have
caused this Logo License Specification to be executed by their duly authorized
representatives.

ICANN

By: ___________________________________

[Registrar Name]

By: ___________________________________

Name:

Title:

Dated: __________________________________

TRADEMARKS:

1. ICANN Accredited Registrar

2.

_____________, 20____

Pursuant to Section 3.15 of Registrar Accreditation
Agreement (the “Agreement”), dated __________, 20____, by and between the
Internet Corporation for Assigned Names and Numbers, a California non-profit,
public benefit corporation (“ICANN”), and [Registrar Name], a [Organization
type and jurisdiction] (“Registrar”), the undersigned certifies, in his/her
capacity as an officer of the Registrar and not in his/her individual capacity,
on behalf of Registrar as follows:

The undersigned is the
____________________________________________ (must be one of the following:
Chief Executive Officer, President, Chief Operating Officer, Chief Financial
Officer, or the functional equivalent thereof) of Registrar.

Registrar has in place processes and procedures intended to
establish, maintain, review, test, and modify registrar policies and procedures
reasonably designed to achieve compliance with the Agreement.

To the best of the undersigned’s knowledge and belief, Registrar has performed and complied with
all covenants, agreements, obligations and conditions contained in the
Agreement that are required to be performed or complied with by it for the
calendar year 20___.

The undersigned signs this certificate as of the date
indicated under the title.

[REGISTRAR]

By: ___________________________________

Name:

Title:

This Transition Addendum (this
“Addendum”) to the Registrar Accreditation Agreement (the “Agreement”) by and
between the Internet Corporation for Assigned Names and Numbers, a California
non-profit, public benefit corporation (“ICANN”), and [Registrar Name], a
[Organization type and jurisdiction] (“Registrar”), is dated as of
_____________, 2013.

WHEREAS, ICANN and Registrar entered into the Agreement as of the
date hereof; and

WHEREAS, ICANN acknowledges that implementation by Registrar of
certain operational provisions of the Agreement is not possible on the date
hereof and will require a reasonable grace period.

NOW THEREFORE, the parties agree as follows:

ICANN will not enforce the following
provisions and specifications of the Agreement until January 1, 2014: Sections
3.4.1.1, 3.4.1.5, 3.7.10, 3.7.11, 3.12.4, 3.12.7, 3.14, 3.18 and 3.19 of the
Agreement; the first sentence of Section 3.7.8 of the Agreement; the WHOIS
Accuracy Specification; the Data Retention Specification; and the service level
agreements set forth in Section 2.2 of the Registration Data Directory Service
(WHOIS) Specification (collectively, the “Transition Provisions”).

In addition, if immediately prior to
the execution of this Addendum Registrar was party to the form registrar
accreditation agreement adopted by ICANN in 2009 (the “2009 RAA”), Registrar
may use its existing form of registrant registration agreement until January 1,
2014, provided that such agreement complies with Section 3.7.7 of the 2009
RAA.

For the calendar year ended December
31, 2013, any certification required pursuant to Section 3.15 shall not require
certification as to compliance with the Transition Provisions and may
acknowledge the permissible use of the registrant registration agreement under
Section 2 hereof.

Notwithstanding the foregoing,
Registrar agrees to use commercially reasonable efforts to comply with the
obligations set forth in the Transition Provisions and transition to a
registrant registration agreement that complies with the terms of the Agreement
prior to January 1, 2014.

Registrar must be fully compliant
with the Transition Provisions and Section 3.7.7 of the Agreement as of January
1, 2014, at which date this Addendum shall automatically terminate without
action by any party, except as it relates to Section 4 hereof.

ICANN
and the Registrar Whois Validation Working Group (as defined below) will work
together to identify and specify an appropriate set of tools to enable
Registrar to complete the across field validation specified in Section 1(e) of
the Whois Accuracy Program Specification to the Agreement (the “Across Field
Validation”). When such tools are mutually agreed between ICANN and the
Registrar Whois Validation Working Group, ICANN shall provide Registrar
written notice of such agreement (which notice shall specify and describe the
agreed upon tools). Effective on the one hundred eightieth (180th) calendar
day following delivery of such notice by ICANN, Registrar shall comply with the
obligations specified in Section 1(e) of the Whois Accuracy Program. Until
such time, ICANN will not enforce compliance with such obligations.

For purposes of this Section 6, the
Registrar Whois Validation Working Group shall be deemed to have agreed to such
Across Field Validation tools when Approval (as defined below) of the then
serving members of the group is obtained through a vote of the group (which
vote may be conducted through any verifiable means determined by the group,
including through electronic means).

The “Registrar Whois Validation Working
Group” means that existing working group whose membership has been tasked with
identifying and specifying a set of tools to enable registrars to complete the
Across Field Validation. The membership of the Registrar Whois Validation
Working Group shall be made up of volunteering representatives of
ICANN-accredited registrars, and shall initially consist of the members
currently serving on the existing working group.

“Approval” is obtained following a vote
of the Registrar Whois Validation Working Group, if the votes cast in favor of
adoption of the proposed Across Field Validations tools by the then serving members
of the group are at least two-thirds of the votes cast by such members, with
abstentions or non-votes not being counted as either votes in favor or against
adoption of such tools. For purposes of the vote of the group as referenced
above, (i) only persons appointed by an ICANN-accredited registrar shall be
deemed members of the group and eligible to cast a vote as described above and
(ii) no ICANN-accredited registrar nor group of Affiliated Registrars
represented in the Registrar Whois Validation Working Group shall have more
than one vote.

Except as set forth in this Addendum,
the Agreement shall be in full force and effect, enforceable by the parties in
accordance with its terms.

[signature page follows]

IN WITNESS WHEREOF, the parties hereto
have caused this Addendum to be executed in duplicate by their duly authorized
representatives.

ICANN

By: ___________________________________

Name: ________________________________

Title: __________________________________

[Registrar]

By: ___________________________________

Name: ________________________________

Title: __________________________________

¹ Data element may be deleted, provided that if the data element is used, it must appear at this location.

² Note: all applicable statuses must be displayed in the Whois output.

³ May be left blank if not available from Registry.

⁴ For the Registrant, Admin and Tech contact fields requiring a “Name” or “Organization”, the output must include either the name or organization (or both, if available).

⁵ All “State/Province” fields may be left blank if not available.

⁶ All “Postal Code” fields may be left blank if not available.

⁷ All “Phone Ext”, “Fax” and “Fax Ext” fields may be left blank if not available.

⁸ May be left blank if not available from Registry.

⁹ May be left blank if not available from Registry.

¹⁰ All associated nameservers must be listed.

© 2020 Internet Corporation for Assigned Names and Numbers.Privacy PolicyTerms of ServiceCookies Policy

We have updated our electronic terms of service to provide greater transparency and align with laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

2013 Registrar Accreditation Agreement

Research & References of 2013 Registrar Accreditation Agreement|A&C Accounting And Tax Services
Source

Share on Facebook

Tweet

Follow us