QuickLinks
 -- Click here to rapidly navigate through this document

Exhibit 10.6  


 
  Registry Agreement  
  


This
REGISTRY AGREEMENT ("Agreement") is by and between the Internet Corporation for Assigned Names and Numbers, a not-for-profit corporation, and NeuLevel, Inc., a
Delaware, USA Corporation. 


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



1.1.
The "Authoritative Root-Server System" means the constellation of DNS root-nameservers specified, from time to time, in the file
<ftp://ftp.internic.net/domain/named.root>. 


1.2.
The "Base Period," in the case of a TLD delegated within the Authoritative Root-Server System on the Effective Date, means a period beginning on the
Commencement-of-Service Date and extending until the Expiration Date. In the case of a TLD not delegated within the Authoritative Root-Server System, the "Base
Period" means a period beginning at the conclusion of the Ramp-Up Period and extending until the Expiration Date. 


1.3.
The "Commencement-of-Service Date" means the Effective Date, except that, in the case of a TLD not delegated within the Authoritative Root-Server System on the
Effective Date, the Commencement-of-Service Date shall be the date on which the Registry TLD is first delegated within the Authoritative Root-Server System to
nameservers designated by Registry Operator. 


1.4.
The "DNS" refers to the Internet domain-name system. 


1.5.
The "Effective Date" is the date on which this Agreement is first signed on behalf of both parties. 


1.6.
The "Expiration Date" is the date specified in Subsection 5.1.1, as it may be extended according to Subsection 5.1.2. 


1.7.
"ICANN" refers to the Internet Corporation for Assigned Names and Numbers, a party to this Agreement. 



1.8.
An "ICANN-Accredited Registrar" is an entity or person accredited by ICANN to act as a registrar for domain names within the domain of the Registry TLD. 


1.9.
"Personal Data" refers to data about any identified or identifiable natural person. 


1.10.
The "Ramp-Up Period," in the case of a TLD not delegated within the Authoritative Root-Server System on the Effective Date, is the period beginning on the
Commencement-of-Service Date and extending for one year. 


1.11.
"Registered Name" refers to a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels, about which Registry Operator (or an affiliate
engaged in providing Registry Services) maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. A name in a Registry Database may be a
Registered Name even though it does not appear in a zone file (e.g., a registered but inactive name). 


1.12.
"Registry Data" means all Registry Database data maintained in electronic form, and shall include TLD Zone-File Data, all data used to provide Registry Services 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 the Registry
Database. 


1.13.
"Registry Database" means a database comprised of data about one or more DNS domain names within the domain of the Registry TLD that is used to generate either DNS resource records that are
published authoritatively or responses to domain-name availability lookup requests or Whois queries, for some or all of those names. 












1.14.
"Registry Operator" refers to NeuLevel, Inc., a party to this Agreement, or any assignee of it under Subsection 5.11. 


1.15.
"Registry-Registrar Agreement" means an agreement between Registry Operator and an ICANN-Accredited Registrar with the provisions specified by Subsection 3.4. 



1.16.
"Registry Services" means services provided as an integral part of the operation of the Registry TLD, including all subdomains in which Registered Names are registered. In determining whether a
service is integral to the operation of the Registry TLD, consideration will be given to the extent to which the Registry Operator has been materially advantaged in providing the service by its
designation as such under this Agreement. The development of technology, expertise, systems, efficient operations, reputation (including identification as Registry Operator), financial strength, or
relationships with registrars and third parties shall not be deemed an advantage arising from the designation. Registry Services include: receipt of data concerning registration of domain names and
nameservers from registrars, provision to registrars of status information relating to the Registry TLD, dissemination of TLD zone files, operation of the Registry TLD zone servers, dissemination of
contact and other information concerning domain-name and nameserver registrations in the Registry TLD, and such other services required by ICANN in the manner provided in Subsections 4.3
through 4.6. Registry Services shall not include the provision of nameservice for a domain used by a single entity under a Registered Name registered through an ICANN-Accredited Registrar. 


1.17.
"Registry TLD" refers to the.biz TLD. 


1.18.
"Service Term" means that portion of the Term of this Agreement commencing on the Commencement-of-Service Date. 


1.19.
"Term of this Agreement" begins on the Effective Date and continues until the earlier of (a) the Expiration Date, or (b) termination of this Agreement. 



1.20.
"TLD" refers to a top-level domain in the DNS. 


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




2.     ICANN OBLIGATIONS.  



2.1.  General Obligations of ICANN. With respect to all matters that affect the rights, obligations, or role of Registry Operator, ICANN shall during the
Term of this Agreement: 



2.1.1.
exercise its responsibilities in an open and transparent manner; 


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


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


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




2.2.
Designation of Registry Operator. ICANN hereby designates Registry Operator as the sole operator for the Registry TLD during the Term of this
Agreement. 


2.3.
Recognition in Authoritative Root-Server System. During the Term of this Agreement, Registry Operator may, by notifying ICANN, request
(a) delegation of the Registry TLD to specified DNS nameservers and (b) changes in that delegation. Any such request must be made in a format, and 












otherwise
meet technical requirements, specified from time to time by ICANN. The initial format and technical requirements are set forth in Appendix A. Changes to the format and technical
requirements may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall withhold without reason) or in the manner provided in Subsections 4.3 through
4.6. ICANN will use commercially reasonable efforts to have such requests implemented in the Authoritative Root-Server System within five business days of the submission. 



2.4.  Recognition in the Root-Zone Contact Database. To the extent ICANN publishes contact data regarding TLDs, during the Term of this
Agreement it will show the Registry TLD's operator as Registry Operator and the Registry TLD's administrative and technical contacts as requested from time to time by Registry Operator. Any such
request must be made in a format, include the elements of contact data, and otherwise meet technical requirements, specified from time to time by ICANN. The initial requirements for these requests are
set forth in Appendix B. Changes to the requirements for requests may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall withhold without
reason) or in the manner provided in Subsections 4.3 through 4.6. 


2.5.  Other Obligations of ICANN. During the Term of this Agreement, ICANN shall use commercially reasonable efforts to: 



2.5.1.
maintain, or cause to be maintained, a stable, secure, authoritative and publicly available database of relevant information regarding the delegation of the Registry TLD; 


2.5.2.
generate, or cause to be generated, authoritative and accurate root zone information from such database and operate, or cause to be operated, the Authoritative Root-Server System in
a stable and secure manner; 


2.5.3.
maintain, or cause to be maintained, authoritative records and an audit trail regarding delegations of the Registry TLD and records related to these delegations; and 


2.5.4.
inform Registry Operator in a timely manner of any changes to ICANN's contact information. 




2.6.
Use of ICANN Name, Logo, and Website. ICANN hereby grants to Registry Operator a non-exclusive, worldwide, royalty-free
license during the Term of this Agreement (a) to state that it is designated by ICANN as the registry operator for the Registry TLD, (b) to use a logo specified by ICANN to signify that
Registry Operator is an ICANN-designated registry operator, and (c) to link to pages and documents within the ICANN web site. No other use of ICANN's name or logo is licensed hereby. This
license may not be assigned or sublicensed by Registry Operator. 




3.     REGISTRY OPERATOR OBLIGATIONS.  



3.1.
Obligation to Provide Registry Services. During the Service Term, Registry Operator shall operate, or cause to be operated, a registry of
Registered Names that meets the functional specifications described by Subsection 3.2 and the performance specifications described by Subsection 3.3. Throughout the Term of this Agreement, Registry
Operator shall be obligated to enter into a Registry-Registrar Agreement with any ICANN-Accredited Registrar seeking such an agreement on the terms specified by Subsection 3.4. Registry Operator shall
commence providing Registry Services in the Registry TLD according to the registry start-up plan specified in Subsection 3.7 and, on the conclusion of that plan and throughout the
remainder of the Term of this Agreement, shall continue providing Registry Services. Throughout the Service Term, Registry Operator shall provide Registry Services in compliance with any
Registry-Registrar Agreement as provided in Subsection 3.4 that is then in effect. 


3.2.  Functional Specifications for Registry Services. All Registry Services provided by Registry Operator shall be provided under this Agreement and
shall meet the functional specifications established by ICANN. The initial functional specifications are set forth in Appendix C. Non-material changes and additions to the
functional specifications may be made by Registry 












Operator
with prior written notice to ICANN and any affected ICANN-Accredited Registrars. All other changes and additions to the functional specifications may be made only with the mutual written
consent of ICANN and Registry Operator (which neither party shall withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 


3.3.
Performance Specifications for Registry Services. All Registry Services provided by Registry Operator shall meet the performance specifications and
comply with the registrar service level agreement established by ICANN. The initial performance specifications are set forth in Appendix D and the initial service level agreement is set forth
in Appendix E. Changes to the performance specifications or service level agreement may be made only with the mutual written consent of ICANN and Registry Operator
(which neither party shall withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 


3.4.  Registry-Registrar Agreements. During the Term of this Agreement, Registry Operator shall enter a Registry-Registrar Agreement with any
ICANN-Accredited Registrar desiring to enter such an agreement. All Registry Services provided by Registry Operator for the Registry TLD shall be provided strictly in accordance with that
Registry-Registrar Agreement: 



3.4.1.
Initially, the form of the Registry-Registrar Agreement shall be that attached as Appendix F. 


3.4.2.
The form of the Registry-Registrar Agreement may be revised (a) by Registry Operator with the written consent of ICANN, (b) by ICANN in the manner provided in Subsections 4.3
through 4.6, provided that any additional terms are within the topics set forth in Subsection 4.2, or, (c) with respect to the price charged registrars by Registry Operator for Registry
Services, according to Subsection 3.4.3. 


3.4.3.
Registry Operator may, at its option and with thirty days written notice to ICANN and to all ICANN-Accredited Registrars, revise the prices charged to registrars under the Registry-Registrar
Agreement, provided that (a) the same price shall be charged for services charged to all ICANN-Accredited Registrars (provided that volume adjustments may be made if the same opportunity to
qualify for those adjustments is available to all ICANN-Accredited Registrars) and (b) the prices shall not exceed those set forth in Appendix G, as adjusted according to Subsections
3.14.5 and 4.4. Registry Operator shall charge no fee to anyone for Registry Services if such fee is not listed on Appendix G. For Registry Services (a) listed on Appendix G
without a stated price or (b) introduced more than six months after the Commencement-of-Service Date, Registry Operator may propose to ICANN, no later than thirty days
before the commencement of that service, the inclusion in Appendix G of an offering price for the Registry Service. The offering price for the Registry Service shall be included in
Appendix G only upon the written consent of ICANN, which shall not be unreasonably withheld or delayed (ordinarily 30 days or less). 




3.5.
Fair Treatment of ICANN-Accredited Registrars. 



3.5.1.
Registry Operator shall provide all ICANN-Accredited Registrars that have Registry-Registrar Agreements in effect, and that are in compliance with the terms of such agreements, equivalent
access to Registry Operator's Registry Services, including to its shared registration system. 


3.5.2.
Registry Operator shall certify to ICANN every six months, using the objective criteria set forth in Appendix H, that Registry Operator is providing all such ICANN-Accredited Registrars
with equivalent access to its Registry Services, including to its shared registration system. 



3.5.3.
Registry Operator shall not act as a registrar with respect to the Registry TLD. This shall not preclude Registry Operator from registering names within the domain of the Registry TLD in
compliance with Subsection 3.6. This also shall not preclude an affiliate of Registry 











Operator
from acting as a registrar with respect to the Registry TLD, provided that Registry Operator complies with the provisions of Subsections 3.5.4 and 3.5.5. 


3.5.4.
Registry Operator shall comply with its Code of Conduct attached as Appendix I. Any changes to that Code of Conduct will require ICANN's written approval. 



3.5.5.
Registry Operator will ensure, in a form and through ways described in Appendix H, that the revenues and assets of Registry Operator are not utilized to advantage registrars that are
affiliated with Registry Operator to the detriment of other ICANN-Accredited Registrars. The distribution of funds by Registry Operator to its debt or equity participants in accordance with their debt
or equity participation shall not violate this Subsection 3.5.5. 


3.5.6.
With respect to its obligations under Subsections 3.5.1 through 3.5.5 and Appendices H and I, Registry Operator agrees to participate in and comply with the sanctions program described in
Appendix Y, provided that all other registry operators having registry agreements with ICANN for the operation of unsponsored top-level domains (i.e. top-level domains,
other than country-code and infrastructure domains, not having a sponsoring organization) are obligated to participate in and comply with a sanctions program with substantially the same
provisions as Appendix Y. Registry Operator agrees that the sanctions program described in Appendix Y shall be a non-exclusive and additional option for ICANN to promote
compliance with Subsections 3.5.1 through 3.5.5 and Appendices H and I, and that the availability of that option does not limit or affect in any way ICANN's ability to employ any other compliance
measures or remedies available under this Agreement. In the event that the gTLD Constituency of the Domain Name Supporting Organization proposes a substitute Appendix Y at any time prior to 1
May 2002, and ICANN determines (following an appropriate process of public notice and comment) that substitution by that Appendix Y would serve the interests of the Internet community,
the substitution shall be made. 




3.6.
Registrations Not Sponsored by Registrars Under Registry-Registrar Agreements. Registry Operator shall register domain names within the domain of
the Registry TLD, other than on a request submitted by a registrar pursuant to that registrar's Registry-Registrar Agreement, only as follows: 



3.6.1.
Registry Operator may register the domain names listed on Appendix X (Part A) for its own use in operating the registry and providing Registry Services under this Agreement,
provided the total number of domain names listed on Appendix X at any time does not exceed 5000. At the conclusion of its designation by ICANN as the operator for the Registry TLD, Registry
Operator shall transfer all such
domain-name registrations to the entity or person specified by ICANN. Appendix X may be revised upon the written notice by Registry Operator to ICANN and written consent by ICANN,
which shall not be unreasonably withheld. 


3.6.2.
Registry Operator may register the domain names listed on Appendix X (Part B) for its own use, provided that the total number of domain names listed on Appendix X at any
time does not exceed 5,000. Registry Operator may retain registration of those names at the conclusion of its designation by ICANN as the operator for the Registry TLD, provided registration fees are
paid and all other requirements for registration by third parties are met. Appendix X may be revised upon written notice by Registry Operator to ICANN and written consent by ICANN, which shall
not be unreasonably withheld. 


3.6.3.
As instructed from time to time by ICANN, Registry Operator shall maintain the registration of up to 5000 domain names within the domain of the Registry TLD for use by ICANN and other
organizations responsible for coordination of the Internet's infrastructure. 


3.6.4.
Subsection 3.6 shall not preclude Registry Operator from registering domain names within the domain of the Registry TLD through an ICANN-Accredited Registrar pursuant to that registrar's
Registry-Registrar Agreement. 















3.7.
Registration Start-Up Plan. Registry Operator shall commence provision of Registry Services for the Registry TLD, including the
provision of nameservice for the Registry TLD, according to the schedule and procedures set forth in the registration start-up plan in Appendix J to this Agreement. 


3.8.
Registration Restrictions Within Registry TLD. 



3.8.1.
Except to the extent that ICANN otherwise expressly authorizes in writing, Registry Operator shall reserve from registration the domain names specified by a schedule established by ICANN. The
initial schedule is attached as Appendix K. Changes to the schedule may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall withhold without
reason) or in the manner provided in Subsections 4.3 through 4.6. 


3.8.2.
Registry Operator shall apply, monitor, and enforce the restrictions on registration in the Registry TLD established by ICANN in the manner established by ICANN. Appendix L sets forth
the
restrictions to be applied initially and Appendix M sets forth the manner by which these restrictions shall be applied, monitored, and enforced. Changes to the restrictions and the manner of
their application, monitoring, and enforcement may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall withhold without reason) or in the manner
provided in Subsections 4.3 through 4.6. 




3.9.
Bulk Access to TLD Zone Files. Registry Operator shall provide bulk access to the zone files for the Registry TLD as follows: 



3.9.1.
to third parties—on the terms set forth in the TLD zone file access agreement established by ICANN. The initial terms of the agreement are set forth as Appendix N to this
Agreement. Changes to the terms of the TLD zone file access agreement may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall withhold without
reason) or in the manner provided in Subsections 4.3 through 4.6. 


3.9.2.
to ICANN—on a continuous basis in the manner which ICANN may from time to time specify. 




3.10.
Publication by Registry Operator of Registry Data. 



3.10.1.
At its expense, Registry Operator shall provide free public query-based access to up-to-date data concerning domain-name and nameserver registrations
maintained by Registry Operator in connection with the Registry TLD. The data elements reported, format of responses to queries, data update frequency, query types supported, and protocols through
which access is provided shall be as established by ICANN. The initial specification of the data elements reported, format of responses to queries, minimum data update frequency, query types
supported, and protocols through which access is provided are set forth in Appendix O. Registry Operator may request supplementation of the specification to include additional data elements
reported or query types supported, in which event ICANN shall act to supplement the specification in a reasonable manner within a reasonable time. Other changes to the specification may be made only
with the mutual written consent of ICANN and Registry Operator (which neither party shall withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 


3.10.2.
To ensure operational stability of the registry, Registry Operator may temporarily limit access under Subsection 3.10.1 in which case Registry Operator shall immediately notify ICANN of the
nature of and reason for the limitation. Registry Operator shall not continue the limitation longer than a period established by ICANN if ICANN objects in writing, which objection shall not be
unreasonably made. The period shall initially be five business days; changes to that period may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall
withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. Such temporary limitations shall be applied in a non-arbitrary manner and shall apply fairly to all
ICANN-Accredited Registrars. 














3.10.3.
In providing query-based public access to registration data as required by this Subsection 3.10, Registry Operator shall not impose terms and conditions on the use of the data provided, except
as permitted by policy established by ICANN. Unless and until ICANN establishes a different policy, Registry Operator 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, or facsimile 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 Registry Operator or any
ICANN-Accredited Registrar, except as reasonably necessary to register domain names or modify existing registrations. Changes to that policy may be made only with the mutual written consent of ICANN
and Registry Operator (which neither party shall withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 


3.10.4.
To comply with applicable statutes and regulations and for other reasons, ICANN may from time to time establish policies in the manner described by Subsections 4.3 through 4.6 establishing
limits on the data concerning registrations that Registry Operator may make available to the public through a public-access service described in this Subsection 3.10 and on the manner in which
Registry Operator may make them available. In the event ICANN establishes any such policy, Registry Operator shall abide by it within the time allowed by Subsection 4.5. 



3.10.5.
At its expense, Registry Operator shall provide bulk access to up-to-date data concerning domain-name and nameserver registrations maintained by Registry
Operator in connection with the Registry TLD in the following two ways: 



3.10.5.1.
on a daily schedule, only for purposes of providing free public query-based access to up-to-date data concerning domain-name and nameserver registrations
in multiple TLDs, to a party designated from time to time in writing by ICANN. The content and format of this data, and the procedures for providing access, shall be as established by ICANN. The
initial content, format, and procedures are set forth in Appendix P. Changes to that content and format and those procedures may be made only with the mutual written consent of
ICANN and Registry Operator (which neither party shall withhold without reason) or in the manner provided in Subsections 4.3 through 4.6. 


3.10.5.2.
on a continuous basis, to ICANN in the manner which ICANN may from time to time reasonably specify, only for purposes of verifying and ensuring the operational stability of Registry
Services, the DNS, and the Internet. The content and format of this data, and the procedures for providing access, shall be as established by ICANN. The initial content, format, and procedures are set
forth in Appendix Q. Changes to that content and format and those procedures may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall withhold
without reason) or in the manner provided in Subsections 4.3 through 4.6. 
















3.11.
Data Escrow. Registry Operator shall periodically deposit into escrow all Registry Data in an electronic format. The escrow shall be maintained,
at Registry Operator's expense, by a reputable escrow agent mutually approved by Registry Operator and ICANN, such approval also not to be unreasonably withheld by either party. The schedule, content,
format, and procedure for escrow deposits shall be as established by ICANN from time to time. The initial schedule, content, format, and procedure shall be as set forth in Appendix R. Changes
to the schedule, content, format, and procedure may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall withhold without reason) or in the manner
provided in Subsections 4.3 through 4.6. The escrow shall be held under an agreement, substantially in the form of Appendix S, among ICANN, Registry Operator, and the escrow agent. In the event
that, after a good-faith search by ICANN and Registry Operator, no mutually approved escrow agent agrees to the terms of Appendix S, ICANN and Registry Operator shall, in
conjunction with a mutually approved escrow agent, negotiate in good faith for a substitute escrow agreement. 


3.12.
Registry Operator's Handling of Personal Data. Registry Operator shall notify registrars sponsoring registrations in the registry for the Registry
TLD of the purposes for which Personal Data submitted to Registry Operator by registrars is collected, the intended recipients (or categories of recipients) of such Personal Data, and the mechanism
for access to and correction of such Personal Data. Registry Operator shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction.
Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. 


3.13.
Rights in Data. Except as permitted by the Registry-Registrar Agreement, Registry Operator shall not be entitled to claim any intellectual
property rights in data supplied by or through registrars. In the event that Registry Data is released from escrow under Subsection 3.11, any rights held by Registry Operator in the data shall
automatically be transferred on a non-exclusive, irrevocable, royalty-free, paid-up basis to ICANN or to a party designated in writing by ICANN. 


3.14.
Registry-Level Financial Support of ICANN. During the Term of this Agreement, Registry Operator shall pay to ICANN the following fees: 



3.14.1.
Fixed Registry-Level Fee. Registry Operator shall pay ICANN a quarterly Fixed Registry-Level Fee in an amount established by the ICANN Board of
Directors, in conformity with the ICANN bylaws and articles of incorporation, not to exceed one quarter of the annual Fixed Registry-Level Fee Cap described in Subsection 3.14.4. 



3.14.2.  Variable Registry-Level Fee. Registry Operator shall pay ICANN a quarterly Variable Registry-Level Fee in an amount calculated according to a
formula and method established from time to time by the ICANN Board of Directors, in conformity with the ICANN bylaws and articles of incorporation. The formula and method shall allocate the total
variable fee among all TLDs sponsored or operated under a sponsorship or registry agreement with ICANN (whether the fee is collected at the registry or registrar level) based on the relative size of
the registries for those TLDs. It shall be permissible for the formula and method so established to do any of the following: (a) to measure the size of a TLD's registry, at least once per year
where feasible, by the number of names under administration within the TLD by the registry's operator, (b) to deem the number of domain names under administration within the Registry TLD to be
the number of Registered Names, (c) to provide for a deduction in computing a sponsor's or operator's Variable Registry-Level Fee of some or all of that sponsor's or registry operator's Fixed
Registry-Level Fee, and (d) to provide that the number of domain names under administration for the.com,.net, and.org TLDs is the number of second-level domains within those TLDs. It shall also
be permissible for the formula and method to consider accreditation fees collected from registrars as a credit applied to the Variable Registry-Level Fee for the TLD to which the fees pertain. Groups
of registries for two or more TLDs may, with the agreement of their sponsors or operators and ICANN, agree to allocate the variable fee collected from them in a manner not based on the relative size
of 














the
registries within the group, provided that the combined variable fees collected for all TLDs within the group is based on the combined size of the registries in the group. 


3.14.3.
Payments Must Be Timely. Registry Operator shall pay the quarterly Fixed and Variable Registry-Level Fees within thirty days after the date of
ICANN's invoice for those fees. These payments shall be made in a timely manner throughout the Term of this Agreement and notwithstanding the pendency of any dispute between Registry Operator and
ICANN. Registry Operator shall pay interest on payments not timely made at the rate of 1% per month or, if less, the maximum rate permitted by California law. 



3.14.4.  Fee Caps. The Fixed Registry-Level Fee Cap shall be US$80,000 per year until and including 30 June 2002; shall automatically increase by
15% on July 1 of each year beginning in 2002; and may be increased by a greater amount in the manner provided by Subsection 4.3 The sum of the Fixed Registry-Level Fees and the Variable
Registry-Level Fees due to be paid in any year ending on any 30 June during or within one year after the Term of this Agreement by all TLD sponsors and registry operators having sponsorship or
registry agreements with ICANN shall not exceed the Total Registry-Level Fee Cap described in the following sentence. The Total Registry-Level Fee Cap shall be US$5,500,000 for the fiscal year ending
30 June 2002; shall increase by 15% each fiscal year thereafter; and may be increased by a greater amount in the manner provided by Subsection 4.3. 



3.14.5.  Adjustments to Price. The maximum pricing for initial and renewal registrations set forth in Appendix G shall be adjusted at the
beginning of each calendar quarter by adding, to the amount specified in that Appendix (after adjustment according to Subsection 4.4) as the applicable annual charge for initial or renewal
registration of a domain name, an amount calculated according to the following three sentences. For calendar quarters in which the variable fee is collected at the registrar level, the amount shall be
US$0.00. For the first two calendar quarters during the Term of this
Agreement in which the variable fee is collected at the registry level, the amount shall be four times the per-name variable accreditation fee charged to registrars for the quarter
beginning six months earlier. For subsequent calendar quarters, the amount shall be four times the quarterly Variable Registry-Level Fee reflected in the invoice to Registry Operator for such a fee
for the quarter beginning six months earlier divided by the number of Registered Names that the invoice shows was used to calculate that quarterly Variable Registry-Level Fee. 




3.15.
Reports Provided to ICANN. Registry Operator shall provide the following periodic written reports to ICANN regarding the following: 



3.15.1.
Monthly Reports on Registry Operations. Within twenty days after the end of each month during the Term of this Agreement, Registry Operator
shall provide ICANN a written report, giving information specified by ICANN, on operation of the registry during the month. The initial specification of information is set forth in Appendix T.
Changes to that specification may be made only with the mutual written consent of ICANN and Registry Operator (which neither party shall withhold without reason) or in the manner provided in
Subsections 4.3 through 4.6. 


3.15.2.
Data Related to Proof of Concept. Registry Operator shall, for the purpose of providing data concerning concepts to be proven by establishment
of the Registry TLD, provide reports concerning the Registry TLD's operation on a schedule and with content specified in Appendix U. 





4. PROCEDURES FOR ESTABLISHMENT OR REVISION OF SPECIFICATIONS AND POLICIES.



4.1.
Registry Operator's Ongoing Obligation to Comply With New or Revised Specifications and Policies. During the Term of this Agreement, Registry
Operator shall comply, in its provision of Registry Services, on the schedule provided in Subsection 4.5, with 










4.1.1.
new or revised specifications (including forms of agreement to which Registry Operator is a party) and policies established by ICANN as Consensus Policies in the manner described in Subsection
4.3, 


4.1.2.
in cases where: 



4.1.2.1.
this Agreement expressly provides for compliance with revised specifications or policies established in the manner set forth in one or more subsections of this Section 4; or 


4.1.2.2.
the specification or policy concerns one or more topics described in Subsection 4.2. 





4.2.  Topics for New and Revised Specifications and Policies. New and revised specifications and policies may be established on the following topics: 



4.2.1.
issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registry Services, the DNS, or
the Internet; 


4.2.2.
functional and performance specifications for the provision of Registry Services; 


4.2.3.
safety and integrity of the Registry Database; 



4.2.4.
procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for
serving Registered Names affected by such a suspension or termination; 


4.2.5.
resolution of disputes regarding whether particular parties may register or maintain registration of particular domain names; 


4.2.6.
principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration); 


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


4.2.8.
maintenance of and access to accurate and up-to-date contact information for domain-name registrants; 



4.2.9.
reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of
users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); and 


4.2.10.
registry policies reasonably necessary to implement Consensus Policies relating to registrars. 




4.3.
Manner of Establishment of New and Revised Specifications and Policies. 



4.3.1.
"Consensus Policies" are those specifications or policies established based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (a) action of
the ICANN Board of Directors establishing the specification or policy, (b) a recommendation, adopted by at least a two-thirds vote of the council of the ICANN Supporting
Organization to which the matter is delegated, that the specification or policy should be established, and (c) a written report and supporting materials (which must include all substantive
submissions to the Supporting Organization relating to the proposal) that (i) documents the extent of agreement and disagreement among impacted groups, (ii) documents the outreach
process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and (iii) documents the nature and intensity of reasoned support and opposition to
the proposed policy. 











4.3.2.
In the event that Registry Operator disputes the presence of such a consensus, it shall seek review of that issue from an Independent Review Panel established under ICANN's bylaws. Such review
must be sought within fifteen working days of the publication of the Board's action establishing the policy. The decision of the panel shall be based on the report and supporting materials required by
Subsection 4.3.1. In the event that Registry Operator seeks review and the Independent Review Panel sustains the Board's determination that the policy is based on a consensus among Internet
stakeholders represented in the ICANN process, then Registry Operator must implement such policy unless it promptly seeks and obtains a stay or injunctive relief under Subsection 5.9. 


4.3.3.
If, following a decision by the Independent Review Panel convened under Subsection 4.3.2, Registry Operator still disputes the presence of such a consensus, it may seek further review of that
issue within fifteen working days of publication of the decision in accordance with the dispute resolution procedures set forth in Subsection 5.9; provided, however, that Registry Operator must
continue to implement the policy unless it has obtained a stay or injunctive relief under Subsection 5.9 or a final decision is rendered in accordance with the provisions of Subsection 5.9 that
relieves Registry Operator of such obligation. The decision in any such further review shall be based on the report and supporting materials required by Subsection 4.3.1. 



4.3.4.
A specification or policy established by the ICANN Board of Directors on a temporary basis, without a prior recommendation by the council of an ICANN Supporting Organization, shall also be
considered to be a Consensus Policy if adopted by the ICANN Board of Directors by a vote of at least two-thirds of its members, so long as the Board reasonably determines that immediate
temporary establishment of a specification or policy on the subject is necessary to maintain the operational stability of Registry Services, the DNS, or the Internet, and that the proposed
specification or policy is as narrowly tailored as feasible to achieve those objectives. In establishing any specification or policy under this provision, the ICANN Board of Directors shall state the
period of time for which the specification or policy is temporarily adopted and shall immediately refer the matter to the appropriate Supporting Organization for its evaluation and review with a
detailed explanation of its reasons for establishing the temporary specification or policy and why the Board believes the policy should receive the consensus support of Internet stakeholders. If the
period of time for which the specification or policy is adopted exceeds ninety days, the Board shall reaffirm its temporary establishment every ninety days for a total period not to exceed one year,
in order to maintain such specification or policy in effect until such time as it meets the standard set forth in Subsection 4.3.1. If the standard set forth in Subsection 4.3.1 is not met within the
temporary period set by the Board, or the council of the Supporting Organization to which it has been referred votes to reject the temporary specification or policy, it will no longer be a "Consensus
Policy." 


4.3.5.
For all purposes under this Agreement, the policies identified in Appendix V shall be treated in the same manner and have the same effect as "Consensus Policies." 


4.3.6.
In the event that, at the time the ICANN Board of Directors establishes a specification or policy under Subsection 4.3.1 during the Term of this Agreement, ICANN does not have in place an
Independent Review Panel established under ICANN's bylaws, the fifteen-working-day period allowed under Subsection 4.3.2 to seek review shall be extended until fifteen working days after
ICANN does have such an Independent Review Panel in place and Registry Operator shall not be obligated to comply ICANN with the specification or policy in the interim. 




4.4.  Pricing Adjustments Arising from New or Revised Specifications or Policies. The maximum prices stated in Appendix G shall be increased
through an amendment to this Agreement as approved by ICANN and Registry Operator, such approval not to be unreasonably withheld, to reflect demonstrated increases in the net costs of providing
Registry Services arising from (A) new or 









revised
ICANN specifications or policies adopted after the Effective Date, or (B) legislation specifically applicable to the provision of Registry Services adopted after the Effective Date, to
ensure that Registry Operator recovers such costs and a reasonable profit thereon; provided that such increases exceed any reductions in costs arising from (A) or (B) above. 


4.5.
Time Allowed for Compliance. Registry Operator shall be afforded a reasonable period of time (not to exceed four months unless the nature of the
specification or policy established under Subsection 4.3
reasonably requires, as agreed to by ICANN and Registry Operator, a longer period) after receiving notice of the establishment of a specification or policy under Subsection 4.3 in which to comply with
that specification or policy, taking into account any urgency involved. 


4.6.
Indemnification of Registry Operator. ICANN shall indemnify, defend, and hold harmless Registry Operator (including 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 solely from Registry Operator's compliance
as required by this Agreement with an ICANN specification or policy (including, without limitation, a Consensus Policy) established after the Effective Date; except that Registry Operator shall not be
indemnified or held harmless hereunder to the extent that the claims, damages or liabilities arise from the particular manner in which Registry Operator has chosen to comply with the specification or
policy, where it was possible for Registry Operator to comply in a manner by which the claims, damages, or liabilities would not arise. As an alternative to providing the indemnity stated in this
Subsection 4.6, ICANN may, at the time it establishes a specification or policy after the Effective Date giving rise to an indemnity obligation under this Subsection 4.6, state ICANN's election that
the Registry Operator shall bear the cost of insuring the claims, damages, liabilities, costs, and expenses that would otherwise be indemnified by ICANN under this Subsection 4.6, in which case the
reasonable cost to Registry Operator of such insurance shall be treated under Subsection 4.4 as a cost of providing Registry Services arising from the newly established ICANN specification or policy. 




5. MISCELLANEOUS PROVISIONS.  



5.1.  Expiration of this Agreement. 



5.1.1.
The initial Expiration Date shall be five years after the Commencement-of-Service Date, except that, in the case of a TLD not delegated within the Authoritative
Root-Server System on the Effective Date, the initial Expiration Date shall be five years after the end of the Ramp-Up Period. The Expiration Date may be extended as provided
in Section 5.1.2. 


5.1.2.
The initial Expiration Date shall be extended by one year in the event that, on the date one year before the initial Expiration Date, Registry Operator has under management within the Registry
TLD at least 19,827,980 Registered Names. 


5.1.3.
Registry Operator acknowledges and agrees that upon the earlier of (i) the Expiration Date or (ii) termination of this Agreement by ICANN pursuant to Subsection 5.4, it will cease
to be the operator of the Registry TLD unless ICANN and Registry Operator enter a new registry agreement continuing Registry Operator's status as operator of the Registry TLD. 


5.1.4.
Upon conclusion of its status as operator of the Registry TLD, Registry Operator shall make all commercially reasonable efforts to cooperate with ICANN, and with any party designated by ICANN
as successor operator, to facilitate prompt and smooth transition of the operation of the Registry TLD. 



5.1.5.
Registry Operator acknowledges and agrees that, except as expressly provided by this Agreement, it shall not acquire any right in the Registry TLD by virtue of its operation of the Registry TLD
or its provision of Registry Services hereunder. 




5.2.
Procedure for Subsequent Agreement. 



5.2.1.
Registry Operator may, no later than eighteen months prior to the initial Expiration Date, submit a written proposal to ICANN for the extension of this Agreement for an 











additional
term (the "Renewal Proposal"). The Renewal Proposal shall contain a detailed report of the Registry Operator's operation of the Registry TLD and include a description of any additional
Registry Services, proposed improvements to Registry Services, or changes in price or other terms of service. ICANN shall provide an initial response to the Renewal Proposal within thirty days of
receiving it and, during a period of at least six months after receiving the Renewal Proposal, ICANN shall consider the Renewal Proposal and meet with Registry Operator to discuss the Renewal
Proposal, but the decision whether to accept the Renewal Proposal shall be in ICANN's sole discretion. 


5.2.2.
Only after the six-month period described in Subsection 5.2.1 may ICANN call for competing proposals from potential successor registry operators for the Registry TLD. Registry
Operator shall be eligible, to the same extent as similarly situated entities, to submit a proposal to such a call. To the extent that the Renewal Proposal demonstrates (i) substantial service
in the interests of the Internet community, (ii) enhancement of competition for registration services, and (iii) enhancement of the utility of the DNS, such demonstration shall be among
the specific factors considered in ICANN's evaluation of any competing proposals, but the choice from among competing proposals shall be in ICANN's sole discretion. 


5.2.3.
In the event a party other than the Registry Operator is selected as the successor registry operator for the Registry TLD upon the expiration of this Agreement, ICANN shall require the
successor registry operator to pay to Registry Operator a Registry Operator Transfer Fee equal to the difference of: 



5.2.3.1
the present value, at the Expiration Date (as extended, if applicable), computed using a discount rate equal to the London Inter-Bank Offer Rate ("LIBOR") (based on the term of
renewal of the successor registry operator) plus three percent per annum, of the revenue stream that
would be achieved by the successor registry operator from renewal fees during the term (not taking into account any extensions) of the successor registry operator's registry agreement for Registered
Names on the Expiration Date that have not been continuously under registration during the entire Base Period, assuming that the domain-name registrations are renewed at the time of their
expiration for a renewal term and at annual renewal fees and rates described in the next four sentences. The assumed renewal term, fees, and rates shall be based on actual experience within the
Registry TLD during a period (the "Benchmark Period") consisting of the eighteen months immediately prior to the Expiration Date. The assumed renewal term shall be the average total term by which
registrations of Registered Names scheduled for expiration during the Benchmark Period are extended by renewal during the Benchmark Period. The assumed renewal rate shall be the percentage of names
scheduled for expiration during the Benchmark Period that are extended by renewal at least once during the Benchmark Period. The assumed annual renewal fee shall be the lesser of (i) the
maximum annual renewal fee that the successor registry operator may charge under its registration agreement and (ii) the average of the annual renewal fees charged by Registry Operator during
the Benchmark Period; less 


5.2.3.2
the present value, at the Expiration Date, computed using a discount rate equal to the LIBOR (based on the term of renewal of the successor registry operator) plus three percent per annum, of
the expense stream that would result during the term (not taking into account any extensions) of the successor registry operator's registry agreement from continued registration of the registrations
at the Expiration Date, with the same assumptions regarding renewal rates and terms set forth in Subsection 5.2.3.1 above. For purposes of this calculation, the annual expense of continued
registration shall be assumed to be 45% of the assumed annual renewal fee stated in Subsection 5.2.3.1 above. 



5.2.3.3
The calculation of present value shall be on a monthly basis with all renewals and expenses occurring in a given month assumed to occur at the end of the month. The Registry Operator Transfer
Fee shall be paid, with interest per annum equal to the 
















LIBOR
plus three percent, from the Expiration Date, within nine months after the Expiration Date. 





5.3.
Condition to Performance. In the event that ICANN is unable, through use of commercially reasonable efforts, to have the Registry TLD delegated
within the Authoritative Root-Server System to nameservers designated by Registry Operator within two years after the Effective Date, then this Agreement shall be automatically terminated
without liability of either party to the other party and neither party shall have any further obligation hereunder. Thirty days in advance of such an automatic termination, either party may propose an
extension of the time in which delegation must occur, and in that event the other party shall consult in good faith (but without obligation to agree) concerning the proposal. No extension of the time
in which delegation must occur shall be effective unless embodied in a written amendment signed by authorized agents of both parties to this Agreement. 



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



5.4.1.
There was a material misrepresentation, material inaccuracy, or materially misleading statement, made with knowledge of its falsity, inaccuracy, or misleading nature or without reasonable cause
to believe it was true, accurate, and not misleading, of then-existing fact or of Registry Operator's intention in its application for the Registry TLD or any written material provided to
or disclosed to ICANN by the Registry Operator in connection with the application. The foregoing shall not apply to projections or forward-looking statements (other than statements, not made in good
faith, about Registry Operator's intentions) in the application or materials. 


5.4.2.
Registry Operator: 



5.4.2.1.
is convicted by a court of competent jurisdiction of a felony or other serious offense related to financial activities, or is the subject of a determination by a court of competent
jurisdiction that ICANN reasonably deems as the substantive equivalent of those offenses; or 


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




5.4.3.
Any officer or director of Registry Operator is convicted of a felony or of a misdemeanor related to financial activities, or is judged by a court to have committed fraud or breach of fiduciary
duty, or is the subject of a judicial determination that ICANN deems as the substantive equivalent of any of these, and such officer or director is not immediately removed in such circumstances. 


5.4.4.
Registry Operator fails to cure any material breach of this Agreement (other than a failure to comply with a Consensus Policy adopted by ICANN during the Term of this Agreement as to which
Registry Operator has obtained a stay under Subsection 5.9) within fifteen business days (or such longer reasonable period as may be necessary using best efforts to cure such breach) after ICANN gives
Registry Operator written notice of the breach. 


5.4.5.
Registry Operator's action or failure to act has been determined by arbitration under Subsection 5.9 to be in violation of this Agreement and Registry Operator continues to act or fail to act
in the manner that was determined to violate this Agreement for a period stated in the arbitration decision, or if no period is stated, fifteen business days. 


5.4.6.
Registry Operator acts or continues acting in a manner that ICANN has reasonably determined endangers the operational stability of Registry Services, the DNS, or the Internet after receiving
three days notice of that determination. 














5.4.7.
Registry Operator fails to pay to ICANN the final amount of sanctions determined to be appropriate under the sanctions program described in Appendix Y within thirty days after the amount
of sanctions is deemed final. 


5.4.8.
Registry Operator becomes bankrupt or insolvent. 





This
Agreement may be terminated in the circumstances described in Subsections 5.4.1 through 5.4.7 above only upon thirty calendar days written notice to Registry Operator (in the case of the
circumstances described in Subsections 5.4.4, 5.4.5, and 5.4.6 occurring after Registry Operator's failure to cure), with Registry Operator being given an opportunity during that time to initiate
arbitration under Subsection 5.9 to determine the appropriateness of termination under this Agreement. In the event Registry Operator initiates arbitration concerning the appropriateness of
termination by ICANN, Registry Operator may at the same time request that the arbitration panel stay the termination until the arbitration decision is rendered, and that request shall have the effect
of staying the termination until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay. If Registry Operator acts in a manner that ICANN reasonably
determines endangers the operational stability of Registry Services, the DNS, or the Internet and upon notice does not immediately cure, ICANN may suspend this Agreement for five calendar days pending
ICANN's application for more extended injunctive relief under Subsection 5.9. This Agreement may be terminated immediately upon notice to Registry Operator in the circumstance described in Subsection
5.4.8. 



5.5.  Representations and Warranties of Registry Operator. Registry Operator represents and warrants to ICANN that: 



5.5.1.
it is a corporation duly organized, validly existing, and in good standing under the laws of Delaware, USA; 


5.5.2.
it has all requisite organizational power and authority to execute, deliver and perform its obligations under this Agreement; 


5.5.3.
the execution, performance and delivery of this Agreement has been duly authorized by Registry Operator; and 



5.5.4.
subject to Subsection 5.3, no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by Registry Operator in order for it to
enter into and perform its obligations under this Agreement. 




5.6.
Additional Covenants of Registry Operator. Throughout the Term of the Agreement, Registry Operator shall comply, in all material respects, with the
covenants contained in Appendix W. 


5.7.
Indemnification of ICANN. Registry Operator shall indemnify, defend, and hold harmless ICANN (including its directors, officers, employees, and
agents) from and against any and all claims, damages, liabilities, costs, and expenses, including reasonable legal fees and expenses, arising out of or relating to: (a) the selection of
Registry Operator to operate the Registry TLD; (b) the entry of this Agreement; (c) establishment or operation of the Registry TLD; (d) Registry Services; (e) collection or
handling of Personal Data by Registry Operator; (f) any dispute concerning registration of a domain name within the domain of the Registry TLD; and (g) duties and obligations of Registry
Operator in operating the Registry TLD; provided that, with respect to items (b) through (g) only, Registry Operator shall not be obligated to indemnify, defend, or hold harmless ICANN
to the extent of ICANN's indemnification of Registry Operator under Subsection 4.6 and provided further that, with respect to item (g) only, Registry Operator shall not be obligated to
indemnify, defend, or hold harmless ICANN to the extent the claim, damage, liability, cost, or expense arose due to a breach by ICANN of any obligation contained in this Agreement. For avoidance of
doubt, nothing in this Subsection 5.7 shall be deemed to require Registry Operator to reimburse or otherwise indemnify ICANN for the costs associated with the negotiation or execution of this
Agreement, or with the monitoring or management of the parties' respective obligations under this Agreement. 












5.8.
Indemnification Procedures. If any third-party claim is commenced that is indemnified under Subsections 4.6 or 5.7, notice thereof shall be given
to the indemnifying party as promptly as practicable. If, after such notice, the indemnifying party acknowledges its obligation to indemnify with respect to such claim, then the indemnifying party
shall be entitled, if it so elects, in a notice promptly delivered to the indemnified party, to immediately take control of the defense and investigation of such claim and to employ and engage
attorneys reasonably acceptable to the indemnified party to handle and defend the same, at the indemnifying party's sole cost and expense, provided that in all events ICANN shall be entitled to
control at its sole cost and expense the litigation of issues concerning the validity or interpretation of ICANN policies or conduct. The indemnified party shall cooperate, at the cost of the
indemnifying party, in all reasonable respects with the indemnifying party and its attorneys in the investigation, trial, and defense of such claim and any appeal arising therefrom; provided, however,
that the indemnified party may, at its own cost and expense, participate, through its attorneys or otherwise, in such investigation, trial and defense of such claim and any appeal arising therefrom.
No settlement of a claim that involves a remedy affecting the indemnifying party other than the
payment of money in an amount that is indemnified shall be entered into without the consent of the indemnified party. If the indemnifying party does not assume full control over the defense of a claim
subject to such defense in accordance with this Subsection, the indemnifying party may participate in such defense, at its sole cost and expense, and the indemnified party shall have the right to
defend the claim in such manner as it may deem appropriate, at the cost and expense of the indemnifying party. 


5.9.  Resolution of Disputes Under This Agreement. Disputes arising under or in connection with this Agreement, including requests for specific
performance, shall be resolved through binding arbitration conducted as provided in this Subsection 5.9 pursuant to the rules of the International Court of Arbitration of the International Chamber of
Commerce ("ICC"). The arbitration shall be conducted in the English language and shall occur in Los Angeles County, California, USA. There shall be three arbitrators: each party shall choose one
arbitrator and, if the two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The parties shall bear the costs of the arbitration in equal shares, subject
to the right of the arbitrators to reallocate the costs in their award as provided in the ICC rules. The parties shall bear their own attorneys' fees in connection with the arbitration, and the
arbitrators may not reallocate the attorneys' fees in conjunction with their award. The arbitrators shall render their decision within ninety days of the initiation of arbitration. In all litigation
involving ICANN concerning this Agreement (as provided in the remainder of this Subsection), 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 a temporary stay or injunctive relief from the arbitration panel or a court located
in Los Angeles, California, USA, which shall not be a waiver of this arbitration agreement. 


5.10.
Limitation of Liability. ICANN's aggregate monetary liability for violations of this Agreement shall not exceed the amount of Fixed or Variable
Registry-Level Fees paid by Registry Operator to ICANN within the preceding twelve-month period under Subsection 3.14. Registry Operator's aggregate monetary liability to ICANN for violations of this
Agreement shall be limited to fees and monetary sanctions due and owing to ICANN under this Agreement. In no event shall either party be liable for special, indirect, incidental, punitive, exemplary,
or consequential damages arising out of or in connection with this Agreement or the performance or nonperformance of obligations undertaken in this Agreement. EXCEPT AS OTHERWISE PROVIDED IN THIS
AGREEMENT, REGISTRY OPERATOR DOES NOT MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES RENDERED BY ITSELF, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR WORK,
INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE. 












5.11.
Assignment. Any assignment of this Agreement shall be effective only upon written agreement by the assignee with the other party to assume the
assigning party's obligations under this Agreement. Moreover, neither party may assign this Agreement without the prior written approval of the other party. Notwithstanding the foregoing, a party may
assign this Agreement by giving written notice to the
other party in the following circumstances: (a) Registry Operator may assign this Agreement as part of the transfer of its registry business if such transfer and assignment are approved in
advance by ICANN pursuant to its procedures, and (b) ICANN may assign this Agreement (i) in conjunction with a reorganization or re-incorporation of ICANN, to another
non-profit corporation organized for the same or substantially the same purposes as ICANN or (ii) as required by Section 5 of Amendment 1 (dated 10 November 1999) to
the 25 November 1998 Memorandum of Understanding between ICANN and the United States Department of Commerce. 



5.12.  Subcontracting. Registry Operator shall not subcontract portions of the technical operations of the Registry TLD accounting for more than 80% of
the value of all Registry TLD operations without ICANN's written consent. When ICANN's consent to subcontracting is requested, ICANN shall respond within fifteen business days, and the consent shall
not be unreasonably withheld. In any subcontracting of the technical operations of the Registry TLD, the subcontract shall state that the subcontractor shall not acquire any right in the Registry TLD
by virtue of its performance under the subcontract. 


5.13.
Force Majeure. Neither party shall be liable to the other for any loss or damage resulting from any cause beyond its reasonable control (a "Force
Majeure Event") including, but not limited to, insurrection or civil disorder, war or military operations, national or local emergency, acts or omissions of government or other competent authority,
compliance with any statutory obligation or executive order, industrial disputes of any kind (whether or not involving either party's employees), fire, lightning, explosion, flood, subsidence, weather
of exceptional severity, and acts or omissions of persons for whom neither party is responsible. Upon occurrence of a Force Majeure Event and to the extent such occurrence interferes with either
party's performance of this Agreement, such party shall be excused from performance of its obligations (other than payment obligations) during the first six months of such interference, provided that
such party uses best efforts to avoid or remove such causes of nonperformance as soon as possible. 


5.14.  No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by either ICANN or Registry Operator to any
non-party to this Agreement, including any registrar or Registered Name holder. 


5.15.
Notices, Designations, and Specifications. All notices (including determinations, designations, and specifications) 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. Any notice required by this
Agreement shall be deemed to have been properly given when delivered in person, when sent by electronic facsimile, or when scheduled for delivery by an internationally recognized courier service.
Designations and specifications by ICANN under this Agreement shall be effective when written notice of them is deemed given to Registry. 



If
to ICANN, addressed to: 


Internet
Corporation for Assigned Names

and Numbers

]4676 Admiralty Way, Suite 330

Marina Del Rey, California 90292

Telephone: 1/310/823-9358

Facsimile: 1/310/823-8649

Attention: Chief Executive Officer 














If
to Registry Operator, addressed to: 


NeuLevel, Inc.

Loudoun Tech center

45980 Center Oak Plaza

Sterling, Virginia 20166

Telephone: 1/571/434-5450

Facsimile: 1/571/434-5786

Attention: VP of Policy and Industry Relations 


With
a copy addressed to: 


NeuLevel, Inc.

Loudoun Tech center

45980 Center Oak Plaza

Sterling, Virginia 20166

Telephone: 1/571/434-5450

Facsimile: 1/571/434-5786

Attention: General Counsel 




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


5.17.
Language. All notices, designations, determinations, and specifications made under this Agreement shall be in the English language. 


5.18.
Amendments and Waivers. No amendment, supplement, or modification of this Agreement or any provision hereof shall be binding unless executed in
writing by both parties. No waiver of any provision of this Agreement shall be binding unless evidenced by a writing signed by the party waiving compliance with such provision. No waiver of any of the
provisions of this Agreement 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. 


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


5.20.
Entire Agreement. This Agreement (including its Appendices, which form a part of it) constitutes the entire agreement of the parties hereto
pertaining to the operation of the Registry TLD and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, between the parties on that subject. In the
event of a conflict between the provisions in the body of this Agreement (Section 1 to Subsection 5.20) and any provision in its Appendices, the provisions in the body of the Agreement shall
control. 









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


INTERNET
CORPORATION FOR ASSIGNED NAMES AND NUMBERS 



	By:	
 M. Stuart Lynn

President and CEO	 
	

Date:	

May 11, 2001	

 
	

NeuLevel, Inc.	

 
	

By:	

 Doug Armentrout

Chief Executive Officer	

 
	

Date:	

May 11, 2001	

 











APPENDIX A  


 
  Internet Assigned Numbers Authority
  Format and Technical Requirements for Requests to Change
  TLD Nameservers in the Root Zone


(This
document applies only to TLDs as to which a written agreement is in effect between ICANN and the TLD delegee, sponsor, or operator.) 


1.
Requests for changes in TLD nameserver delegations to be reflected in the root zone are to be submitted by e-mail to root-mgmt@iana.org. 



2.
Requests should be submitted by filling out the template available at http://www.iana.org/tld/cctld-template.txt (for ccTLDs) or  http://www.iana.org/tld/tld-template.txt (for other TLDs). 


3.
Nameserver change requests are subject to verification of authenticity and authorization. Both the listed technical contact and the listed administrative contact should be available to verify that
the request is authentic and they authorize the requested change. Except where a written agreement between ICANN and the TLD delegee, sponsor, or operator expressly states to the contrary, the IANA
shall be entitled to rely on authorization of either the administrative or technical contact as constituting a request for nameserver change by the TLD delegee, sponsor, or operator. 



4.
Requests for changes to nameservice for ccTLDs (i.e. TLDs having two-letter labels) must result in delegation to at least two nameservers, preferably on different network segments.
Requests for changes to nameservice for other TLDs must result in delegation to nameservers on at least five different network segments. 


5.
Delegations of a TLD to more than thirteen nameservers are not supported. 


6.
Prior to submitting the request, nameservice should be set up at all the nameservers to which delegation is to be made. Lame delegations (i.e. delegations to servers without operating nameservice
for the delegated zone) will not ordinarily be made. 



7.
The IANA must have zone file access. Except where other arrangements are made (such as for TLDs with large zones), this means that zone file transfers must be enabled at all nameservers for
transfers to at least 128.9.0.0/16 and 192.0.32.0/20. 


(9
May 2001) 









APPENDIX B  


 
  Internet Assigned Numbers Authority
  Format, Content, and Technical Requirements for Requests to
  Change TLD Contact Information


(This
document applies only to TLDs as to which a written agreement is in effect between ICANN and the TLD delegee, sponsor, or operator.) 


1.
Requests for changes in TLD contact data are to be submitted by e-mail to root-mgmt@iana.org. 



2.
Requests should be submitted by filling out the template available at at http://www.iana.org/tld/cctld-template.txt (for ccTLDs) or  http://www.iana.org/tld/tld-template.txt (for other TLDs). 


3.
Requests for changes to TLD contact data must include all applicable elements of data requested in items 3-5 of the template. All information submitted must be accurate. 


4.
Contact change requests are subject to verification of authenticity and authorization. Both the listed technical contact and the listed administrative contact should be available to verify that the
request is authentic and they authorize the requested change. Except where a contract between ICANN and the TLD delegee, sponsor, or operator expressly states to the contrary, the IANA shall be
entitled to rely on authorization of either the administrative or technical contact as constituting a request for a contact change by the TLD delegee, sponsor, or operator, except that any change of
the identity of the sponsoring organization, administrative contact, or technical contact must comply with notice requirements stated in the agreement. 


(9
May 2001) 









APPENDIX C  


 
  Functional Specifications  
  


C.1 Registry Overview  


This
section will provide an overview of the registry. Specifically it will describe the registry facilities, the SRS systems and functions, and the nameserver systems and functions. 



C.1.1 Registry Facilities Site Description  


This
section describes NeuLevel's proposed TLD Registry architecture consisting of redundant SRS data centers and multiple nameserver sites to provide a seamless, responsive, and reliable registry
service to registrars and Internet users. The NeuLevel TLD registry consists of redundant SRS and multiple nameserver data center sites geographically dispersed. All of these sites are interconnected
with a secure Virtual Private Network (VPN) to provide worldwide coverage and protect against natural and man-made disasters and other contingencies. 



SRS Data Center and Nameserver Buildings  


Each
NeuLevel data center facility is located in a modern, fire-resistant building that offers inherent structural protection from such natural and man-made disasters as
hurricanes, earthquakes, and civil disorder. Facilities are protected by a public fire department, and have their internal fire-detection systems connected directly to the fire department. 


Data
centers are protected from fire by the sprinkler systems of the buildings that house them. Furthermore, each equipment room is protected by a pre-action fire-suppression
system that uses an extinguishing agent. 


The
environmental factors at the SRS Data Center and nameserver sites are listed in the following table. 



	

	SRS DATA CENTER ENVIRONMENTAL FACTORS
	

	Heating, ventilation, and air conditioning	 	Redundant HVAC units control temperature and humidity, able to maintain the required environment under failure of any one unit.
	

	Control of static electricity	 	All equipment-mounting racks are grounded to the building's system, and are equipped with grounding straps that employees wear whenever they work on the equipment.
	

	Power supply	 	Modular UPS with battery backup and diesel generator.
	

	Grounding	 	•	All machines are powered by grounded electrical service.
	 	 	•	A heavy-gage cable under the equipment-room floor connects all equipment racks to the building's electrical-grounding network.
	






Building Security  


In
addition to providing physical security by protecting buildings with security guards, closed circuit TV surveillance video cameras, and intrusion detection systems, physical access to our
facilities is vigilantly controlled. Employees must present badges to gain entrance, and must wear their badges at all times while in the facility. Visitors must sign in to gain entrance. If the
purpose of their visit is found to be valid, they are issued a temporary badge; otherwise, they are denied entrance. At all times while they are in the facility, visitors must display their badges and
must be escorted by an authorized employee. Sign-in books are maintained for a period of one year. 


C.1.2 Shared Registration System (SRS) Data Center Functional Description  


The
SRS data centers incorporate redundant uninterruptible power supplies; high-capacity heating, ventilation, and air conditioning; fire suppression; physical security; system security;
firewalls with intrusion detection; redundant, high availability cluster technology; and redundant network and 








telecommunications
architectures. The sites have been engineered to be resistant to natural and man-made disasters. The functional block diagram of our SRS data center is depicted in
Exhibit 1. This diagram is shown for illustrative purposes and is a target architecture. Details within the diagram are subject to change as we progress through development and deployment. 



        Each
SRS data center facility provides the functions listed in the system function directory table below. 



	

	SHARED REGISTRATION SYSTEM (SRS) FUNCTION DIRECTORY
	

	System Function	 	Functional Description
	

	Web Server	 	High capacity Web Servers provide secure web services and information dissemination that is outside the scope of the XRP protocol. It contains a registry home page to enable registrars to sign in and inquire about account
status, get downloads and whitepapers, access frequently asked questions, obtain self help support, or submit a trouble ticket to the TLD Registry Help Desk.
	

	Protocol (XRP) Servers	 	XRP transactions received from registrars undergo front-end processing by the XRP server that manages the XRP session level dialog, performs session level security processing, and strips out transaction records. These XRP
transaction records are sent to the SRS data center application server cluster for security authentication and business logic processing.
	

	Application Servers	 	Processing of the XRP applications business logic, user authentication, posting of inserts, deletes, updates to the master database, and interfaces to authentication, billing and collections, backup, and system/network
administration.
	

	SRS Database Servers	 	The SRS database maintains registry data in a multi-threaded, multi-session database for building data-driven publish and subscribe event notifications and replication to downstream data marts such as the Whois, Zone, and
Billing and Collection services.
	

	Whois Distribution Database	 	The Whois Distribution Database is dynamically updated from the SRS database and propagates the information to the Whois Database clusters.
	

	Whois Database Clusters	 	The Whois Database is dynamically updated from the Whois Distribution Database and sits behind the Whois Server clusters. The Whois Database clusters are used to lookup records that are not cached by the Whois
Servers.
	

	Whois Servers	 	The Load Balanced Whois Server Clusters receive a high volume of queries from Registrants and Internet users. The Whois service returns information about Registrars, domain names, nameservers, IP addresses, and the
associated contacts.
	

	Zone Distribution Database	 	The Zone Distribution Database is dynamically updated from the registry SRS database and propagated to the nameserver sites located worldwide. It contains domain names, their associated nameserver names, and the IP
addresses for those nameservers.
	

	Billing and Collection	 	A commercial off the shelf system is customized for registry specific eCommerce billing and collection functions that are integrated with XRP transaction processing, the master database and a secure web server. The system
maintains each registrar's account information by domain name and provides status reports on demand.
	

	Authentication Services	 	Authentication Service uses X.509 digital certificates and is used to authenticate the identity of entities interacting with the SRS.
	

	Backup Server	 	Provides backup and restore of each of the various cluster servers and database servers files and provides a shared robotic tape library facility for central backup and recovery.
	

	 	 	 









	Systems/Network Management Console	 	Provides system administration and simple network management protocol (SNMP) monitoring of the network, LAN-based servers, cluster servers, network components, and key enterprise applications including the XRP, Web, Whois,
 Zone, Billing and Collections, Backup/Restore, and database application. Provide threshold and fault event notification and collects performance statistics.
	

	Applications Administration Workstations	 	Provides client/server GUI for configuration of SRS applications including XRP, Web, Billing and Collection, Database, Authentication, Whois, Zone, etc.
	

	Building LAN	 	Provides dual redundant switched 100BaseT Ethernet LAN-based connectivity for all network devices in the data center.
	

	Firewall	 	Protects the building LAN from the insecure Internet via a Firewall that provides policy-based IP filtering and network-based intrusion detection services to protect the system from the Internet hacking and denial of
service attacks.
	

	Load Balancers	 	Dynamic Feedback Protocol (DFP) — based load balancing of TCP/IP traffic in a server cluster including common protocols such as least connections, weighted least connections, round robin, and weighted round
robin.
	






C.1.3 Nameserver Sites Functional Description  


Two
of the five initial nameserver sites are co-located at our SRS Data Centers. One of the remaining nameserver sites will be located in Europe, another of the remaining nameservers will
be located in Asia. The location of the fifth nameserver site has not yet been determined. Additional geographically dispersed nameserver sites will be deployed as load and geographic diversity needs
dictate and will be served with dual homed Internet and VPN local access telecommunications links to provide resilience and disaster recovery. The functional block diagram of our nameserver sites is
depicted in Exhibit 2. As can be seen from the exhibit the nameserver sites are configured to be remotely managed and operated "lights out". This diagram is shown for illustrative purposes and
is a target architecture. Details within the diagram are subject to change as we progress through development and deployment. 


        The
following function directory table lists the nameserver functions. 



	

	NAMESERVER FUNCTION DIRECTORY
	

	System Function	 	Functional Description
	

	Zone Update Database	 	The SRS Zone Distribution Database is propagated to the Zone Update Database Servers at the nameserver sites. Information propagated includes domain names, their associated nameserver names, and the IP addresses for those
nameservers.
	

	Nameserver	 	The nameserver handles resolution of TLD domain names to their associated nameserver names and to the IP addresses of those nameservers. The nameservers are dynamically updated from the Zone Update Database. Updates are
sent over the VPN Registry Management Network.
	

	Building LAN	 	Provides dual redundant switched 100BaseT Ethernet LAN-based connectivity for all network devices in the data center.
	

	Firewall hacking	 	Protects the building LAN from the insecure Internet via a Firewall that provides policy-based IP filtering and network-based intrusion detection services to protect the system from the Internet and denial of service
attacks.
	

	Load Balancers	 	Dynamic Feedback Protocol (DFP)—based load balancing of TCP/IP traffic in a server cluster including common protocols such as least connections, weighted least connections, round robin, and weighted round
robin.
	

	Telecommunications Access	 	Dual-homed access links to Internet Service Providers (ISPs) and Virtual Private Network (VPN) services are used for connectivity to the Internet and the NeuLevel Registry Management Network.
	












C.2 Registry-Registrar Model and Protocol  


The
document linked below has been submitted to the PROVREG Working Group of the Internet Engineering Task Force (IETF) for consideration for development of an IETF standard regarding a
Registry-Registrar Protocol. It describes in great detail the NeuLevel proposal for the registrar interface to the registry. It includes all of the commands and capabilities that exist between the
registry and the registrar. This document is subject to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. However, the
following provides the target architecture and initial functionality. 


Neulevel
will implement support for the IETF PROVREG working group's protocol specification no later than 135 days after it is adopted as a Proposed Standard [RFC 2026, section
4.1.1]. 


E.  Brunner-Williams,
A. Damaraju & N. Zhang: "Extensible Registry Protocol (XRP)", draft-brunner-xrp-00.txt, work in progress. 



C.3 Zone File generation, Distribution, and Publication  


NeuLevel
will generate and propagate DNS zone file updates to the DNS server array incrementally as transactional updates initiated by the SRS resulting from new domain name registrations. Updates
will be initiated from the SRS, and queued and propagated to the DNS server array in near real-time consistent with the applicable service level requirements. 


The
NeuLevel registry would store only the following resource records in the zone file database: 



	•
	A
single SOA record



	•
	A
number of NS and A records, up to a maximum of 13 of each, for the TLD DNS servers for .biz



	•
	Domain
name and delegated nameservers (NS Records)



	•
	Name-server
host names and their associated IP addresses (A Records) 




NeuLevel
will implement, on a reasonable schedule, glue-generation and pruning criteria specified by ICANN from time to time. 



Zone File Access Program  


NeuLevel
will provide a data mart to enable registrars to access the zone file in bulk. Our proposed query program will: 



	•
	Reduce
the load placed on the nameservers by data mining programs. (For example, some ISPs use data mining to accelerate domain name availability checking.)



	•
	Bind
subscribers to limiting conditions as to how they can use the data, according to the terms set forth in Appendix N.



	•
	Provide
the entire database in a BIND format that will facilitate such services as suggesting alternate names, accelerating DNS queries, and compiling industry statistics. 






Logging and Data Back-up  


All
zone files and updates are generated using information from the SRS database. All updates are recorded as database transaction logs. 



Zone File-Generation Architecture  


Zone
file information is stored in the SRS database (along with all other registry data) and replicated to a zone distribution server within defined service levels. See Appendix D, item 3.5.1. The
database stored on the zone distribution server is in turn replicated out to a database at the nameserver data centers. 









Standards Compliance  


The
DNS name server array will comply with the IETF standards for the DNS (RFC1035, RFC2181, RFC 2182). In addition, DNS extensions (security, transactional updates, internationalization, etc.)
adopted or proposed by IETF will be assessed and supported consistent with industry acceptance and prudent operational considerations as part of the release requirements definition for the initial
registry release and each subsequent one. 



NeuLevel
expects to implement all applicable best-practice recommendations contained in RFC2870 (Root Nameserver Operational Requirements), as they become practicable. 


C.4 Whois Service  


Please
see Appendix O. 


C.5 Customer Support Services and Capabilities  


The
registry provides a clear, concise and efficient deliberation of customer support responsibilities. Registrars provide support to registrants and registries provide support for registrars. This
allows the registry to focus its support on the highly technical and administratively complex issues that arise between the registry and the registrar. 


C.5.1 Technical Help Systems  


NeuLevel
will provide the registrars with the following types of technical support: 



	•
	Web-based
self-help services, including:



	•
	Knowledge
bases



	•
	Frequently
asked questions



	•
	White
papers



	•
	Downloads
of XRP client software



	•
	Support
for email messaging






	•
	Telephone
support from our central Help Desk



	•
	Fee-based
consulting services 




Web Portal  


NeuLevel
will implement a secure Web-based multimedia portal to help support registrar operations. To obtain access to our Web-based services, a registrar must register his registrants with us, and
must have implemented our security features, including SSL encryption, log in with user ID and password, and digital certificates for authentication. 


The
home page of the web portal will include a notice to registrars of planned outages for database maintenance or installation of software upgrades. This notification will be posted 30 days prior to
the event in addition to active notification including phone calls and email. We will also record outage notifications in the help desk database to facilitate compliance with the service-level
agreement. Finally, seven days and again two days prior to the scheduled event, we will use both an email and a Web-based notification to remind registrars of the outage. 


Non-affiliated
registrars and the general Internet community may obtain generic information from NeuLevel's public Web site, which will describe our TLD service offerings and list ICANN-certified
registrars providing domain-name services. 










Central Help Desk  


In
addition to implementing the Web site, we will provide telephone support to our registrars through our central Help Desk. Access to the help desk telephone support is through an automatic call
distributor that routes each call to the next available customer support specialist. We will authenticate callers by using caller ID and by requesting a pre-established pass phrase that is different
for each registrar. Requests for assistance may also come to the Help Desk via email, either directly or via the secure Web site. 


The
Help Desk's three tiers of support are: 



Tier-1 Support—Telephone support to registrars who normally are calling for help with customer domain-name problems and such other issues
such as XRP implementation or billing and collection. Problems that can't be resolved at Tier 1 are escalated to Tier 2. 


Tier-2 Support—Support provided by members of the technical support team, who are functional experts in all aspects of domain-name
registration. In addition to resolving escalated Tier 1 problems with XRP implementation and billing and collection, Tier 2 staff provides technical support in system tuning and workload processing. 



Tier-3 Support—Complex problem resolution provided by on-site maintenance technicians, third party systems and software experts, and
vendors, depending on the nature of the problem. 




In
turn, the Help Desk uses an automated software package to collect call statistics and record service requests and trouble tickets in a help desk database. The help desk database documents the
status of requests and tickets, and notifies the Help Desk when an SLA threshold is close to being breached.
Each customer-support and technical support specialist uses our problem management process to respond trouble tickets with a troubleshooting, diagnosis, and resolution procedure and a root-cause
analysis. 


Escalation Policy  


Our
escalation policy defines procedures and timelines for elevating problems either to functional experts or to management for resolution if they not resolved within the escalation-policy time
limits. The following table is an overview of our escalation policy. 



	 
	 	 
	 	 
	 	 

	Level
 
	 	Description
	 	Escalation Policy
	 	Notification

	I	 	Catastrophic outage affecting overall registry operations	 	Data-center manager escalates to NeuLevel management and Disaster-Recovery Team if not resolved in 15 minutes	 	Web portal and e-mail notifications to all Registrars within 15 minutes; updates every 30 minutes
	

II	
 	

Systems outage affecting one or two registrar sessions but not the entire system	
 	

Systems engineer escalates to data-center manager if not resolved in one hour	
 	

Web-portal notification to all registrars; hourly updates
	

III	
 	

Technical questions	
 	

Help Desk customer-support specialist escalates to the systems engineer if not resolved in two hours	
 	

Hourly updates to registrar via e-mail
	

IV	
 	

Basic questions	
 	

Help Desk customer-support specialist escalates to the systems engineer if not resolved within four hours	
 	

Hourly updates to registrar via e-mail











Staffing  


Initially,
NeuLevel will staff its Help Desk with a complement of customer service specialists. We will add staff as necessary to respond to incoming requests within the service-level agreement.
Customer-service specialists will obtain assistance from NeuLevel's technical staff for any problems that cannot be resolved in one phone call. 


Test and Evaluation Facility  


NeuLevel
will establish an operational test-and-evaluation facility that will be available for registrars to test their client XRP system. Our technical-support team, which consists of functional
experts in the processes and technologies for domain-name registration, will support the registrars' testing. 


Once
each new registrar is satisfied that its system is compatible with the registry system, it will schedule a formal acceptance test that will be monitored by our system engineer. After a registrar
has passed the acceptance test, we will issue its user id, passwords, and digital certificates, and the registrar can begin operations. 


Customer Satisfaction Survey  


To
determine registrars' satisfaction with registry services, NeuLevel will implement a Web-based customer-satisfaction survey that will consist of a set of survey questions with responses ranging
from one to five on the Likert Scale. We will tabulate the results and publish them on the Web site. 


To
further verify the quality of our customer services, NeuLevel will commission a biannual customer-satisfaction survey by an independent third party. 


C.6 Operational Test and Evaluation  


Before
a Registrar is allowed to join the live.biz Open Architecture Registry System (OARS) it must first pass Operational Test and Evaluation (OT&E) certification. The purpose of OT&E certification
is to verify the correct operation and performance of a Registrar's client system. 


Preparations for OT&E Certification  


The
OT&E certification process begins when a Registrar becomes accredited by ICANN to register names in the.biz TLD, at which point the Registrar enters the.biz Registry provisioning process. The
Registrar fills out a registration form and a.biz welcome package is provided to the Registrar. This package includes information that will assist the Registrar in implementing its Extensible Registry
Protocol (XRP) client application for OARS. This package will include the following: 



1.  Username
and password to access the Registrar Channel Partner only area of the.biz web site. 


2.  The
OT&E Testbed server information and username/password for two accounts to access the.biz OT&E Testbed for Registrar client testing. 


3.  Instructions
on where to download the XRP Registrar Tool Kit. 


4.  Instructions
on where to download the documentation for the XRP Registrar Tool Kit. 


5.  Instructions
on where to download the XRP specifications and XRP Common Application Programmer Interfaces (APIs). 



6.  Instructions
on how to proceed with the OT&E certification process. 


7.  Instructions
on how to obtain an SSL certificate from an approved Certificate Authority. 


8.  Instructions
on how to provide.biz with the list of subnets that will be used to access the OARS. 


9.  Test
Plans and Procedures that will explain the test cases, test metrics, data collection, test data analysis, and reporting to be performed during OT&E verification. 













The
Registrar is responsible for installing the XRP client application that will interface to the Registry using the XRP protocol. The Registrar will interface the XRP client to the back office
systems via the XRP common APIs. The.biz Registrar Tool Kit is available to any interested party that would like to implement Registrar client applications. 


The
Registry-Registrar communication channel will be encrypted. A SSL certificate from an approved Certificate Authority is required to establish a SSL Version 3.0 encrypted channel. The
username/password and subnet list provides additional security as only a valid combination of a SSL Version 3.0 certificate; username/password and subnet will be allowed to access the live Shared
Registry System. 


During
XRP client implementation, the Registrar has access to the Registry OT&E Testbed environment. In the OT&E Testbed, the Registrar may test the operation of its software to verify the correct
handling of XRP commands, their responses, and notification messages. Operations performed in the OT&E environment will not be charged and will not have any impacts on the live OARS. Registrars will
continue to have access to the OT&E Testbed after certification, so that they may continue to test their back office software systems. 


When
a Registrar has completed the testing of its XRP client and back office systems and would like to proceed with OT&E certification, it should contact.biz Customer Care to schedule a time
slot. Time slots will be scheduled on a first-come-first-serve basis. 


At
the scheduled time, the Registrar should contact the.biz OT&E Technical Support Team to initiate the certification. 


The Registrar Tool Kit  


The
Registrar Toolkit Kit is a software development kit (SDK) that will support the development of a Registrar software system for registering Internet domain names in the Registry using the XRP
Registry-Registrar Protocol and the XRP common APIs. The SDK will consist of software and documentation as described below. 



The
SDK can be used by the Registrar as a basis for connecting to the.biz Registry Testbed environment during OT&E, and can also be used to develop a system for interfacing with the live.biz Registry
once the Registrar has been certified. 


The
software will consist of a working Java XRP common API and samples of interfaces to back office systems that implement the XRP protocol core functions and XRP extensions that are used to
communicate between the Registry and Registrar. The SDK will illustrate how XML requests (Registration Events) can be assembled and forwarded to the Registry for processing. The software will provide
the Registrar with the basis for a reference implementation that conforms to the XRP Registry-Registrar Protocol. The software component of the SDK will also include XML Schema definition files for
all Registry XRP objects and XRP Object extentions. 


The
documentation will also describe the XRP software package hierarchy, the object data model, and an description of the defined objects and methods (including calling parameter lists, and expected
response behavior). New versions of the SDK will be made available from time to time to provide support additional features as they become available as well as other platform and language support. 



OT&E Certification Test Cases  


During
OT&E certification, a Registrar's client application will be required to demonstrate the proper execution of the following operations. 



1.  SSL
Version 3.0 connection establishment 


2.  XRP
<login> command 


3.  Change
of <login> password 


4.  XRP
<logout> command 













5.  Domain
Name Operations 



a.  Create
domain without nameservers and without contacts (XRP Transform <create>) 


b.  Create
domain with nameservers 


c.  Create
domain with contacts 


d.  Create
domain with maximum registration period 


e.  Create
domain with maximum number of nameservers 



f.  Create
domain with maximum number of contacts 


g.  Create
domain with maximum length domain name (63 characters +.BIZ) 


h.  Create
domain with invalid name 


i.  Check
domain (XRP Query <check>)—domain not available 


j.  Check
domain (XRP Query <check>)—domain available 


k.  Check
domain—maximum length domain name (63 characters +.BIZ) not available 


l.  Query
domain (XRP Query <INFO>) 


m.  Query
domain transfer status (XRP Query <transfer>) 


n.  Delete
domain (XRP Transform <delete>) 


o.  Renew
domain (XRP Transform <renew>) 


p.  Transfer
domain (XRP Transform <transfer>) 


q.  Change
domain (XRP Transform <update>)—nameservers 


r.  Change
domain (XRP Transform <update>)—contact 



s.  Change
domain (XRP Transform <update>)—status 




5.  Nameserver
Operations 



a.  Create
nameserver (XRP Transform <create>) 


b.  Create
nameserver with maximum length host name (80 characters) 


c.  Check
nameserver (XRP Query <check>)—nameserver known 


d.  Check
nameserver (XRP Query <check>)—nameserver unknown 


e.  Query
nameserver (XRP Query <INFO>) 



f.  Delete
nameserver (XRP Transform <delete>) 


g.  Change
nameserver (XRP Transform <update>)—add IP address 


h.  Change
nameserver (XRP Transform <update>)—remove IP address 




6.  Contact
Operations 



a.  Create
contact (XRP Transform <create>) 


b.  Check
contact (XRP Query <check>)—contact known 



c.  Check
contact (XRP Query <check>)—contact unknown 


d.  Query
contact (XRP Query <INFO>) 


e.  Query
contact transfer status (XRP Query <transfer>) 


f.  Delete
contact (XRP Transform <delete>) 


g.  Transfer
contact (XRP Transform <transfer>) 


h.  Change
contact (XRP Transform <update>)—change element 


i.  Change
contact (XRP Transform <update>)—remove element 















7.  Registrant
Account Operations 



j.  Create
Registrant Account (XRP Transform <create>) 


k.  Check
Registrant Account (XRP Query <check>)—contact known 



l.  Check
Registrant Account (XRP Query <check>)—contact unknown 


m.  Query
Registrant Account (XRP Query <INFO>) 


n.  Query
Registrant Account transfer status (XRP Query <transfer>) 


o.  Delete
Registrant Account (XRP Transform <delete>) 


p.  Transfer
Registrant Account (XRP Transform <transfer>) 


q.  Change
Registrant Account (XRP Transform <update>)—change element 


r.  Change
Registrant Account (XRP Transform <update>)—remove element 




8.  Effectiveness
and Utility of client session management and information exchange. 


9.  Performance
of client session management and information exchange throughput. 




NOTE:
The Registry reserves the right to change the OT&E certification requirements as necessary to ensure compliance with the evolving XRP IEFT standard and XRP common APIs. 


Post OT&E Certification  


All
tests performed during OT&E certification must be completed without errors. The Registry will provide the certification results in a timely manner and provide feedback for those Registrars that
failed to successfully complete the tests. Registrars may correct their systems and re-schedule for certification. Registrars will not be limited in the number of attempts at OT&E
certification. 


Upon
successful OT&E certification, the Registrar becomes eligible for operation in the live OARS. A new username/password is assigned and the Registry will configure the live system to recognize the
SSL certificate, username, password, and subnet blocks for the Registrar. The Registrar may start operation when it has satisfied the financial requirements for going live. 



C.7 Registrar Reports  


NeuLevel
will provide a reporting service allowing Registrars to retrieve reports on their customer base. These reports will be posted to a secure site (i.e. FTP) that can be accessed by the
individual Registrar by entering username and passcode. The format for reports will be easily machine-readable by registrars (i.e. XML, CSV). Naming convention of reports will identify the registrar,
the date the report was created and indicate subject of the report. The Registry will archive copies of all reports created. 


These
reports are: 



1.  Daily
Reconciliation Reports created from credit/debit and debit account transaction logs 


2.  Daily
and Monthly Registrar Cumulative Report for domain-names registrations 


3.  Transaction
logs 


4.  Complete
database export file of all data entities they own 




The
Registrar Cumulative Reports include: 



	•
	Total.biz
domain-names strings processed



	•
	Total.biz
domain-names "registered"



	•
	Total.biz
domain-name strings "unavailable"



	•
	Total.biz
domain-name strings "invalid" 











	•
	Total
Credit/Debit Card account transactions and amount



	•
	Total
Debit account debits and amount



	•
	Total
Wire Transfers and amount 




Custom
Reporting is an optional feature that would allow registrars to specify report criteria and have a report available for download upon completion. 



	•
	Numbers
and names of domain-names registered within any period



	•
	Domain-names
transferred to/away from registrar within a specified period



	•
	Change
of ownership activity, time/date request were processed



	•
	Re-delegation
activity 



Comments
concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org. 


Page
Updated 27-April-2001

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


C.8 Database Services  


The
following grammer representation of XML syntax uses the Augmented Backus-Naur Form (ABNF), defined in rfc2234: 



	octet	=	<any 8-bit sequence of data>
	

hextet	

=	

<any 16-bit sequence of data>
	

char	

=	

<any US-ASCII character (octets 0—127)>; see ANSI X3.4-1986
	

upalpha	

=	

"A" -- "B" -- "C" -- "D" -- "E" -- "F" -- "G" -- "H" -- "I" -- "J" -- "K" -- "L" -- "M" -- "N" -- "O" -- "P" -- "Q" -- "R" -- "S" -- "T" -- "U" -- "V" -- "W" -- "X" -- "Y" -- "Z"
	

lowalpha	

=	

"a" -- "b" -- "c" -- "d" -- "e" -- "f" -- "g" -- "h" -- "i" -- "j" -- "k" -- "l" -- "m" -- "n" -- "o" -- "p" -- "q" -- "r" -- "s" -- "t" -- "u" -- "v" -- "w" -- "x" -- "y" -- "z"
	

alpha	

=	

lowalpha -- upalpha; also called "letter"
	

digit	

=	

"0" -- "1" -- "2" -- "3" -- "4" -- "5" -- "6" -- "7" -- "8" -- "9"; also called "number"
	

alphanum	

=	

alpha -- digit; also called "letnum"
	

plus	

=	

0x2b
	

hyphen	

=	

0x2d; also called "dash"
	

dot	

=	

0x2e
	

underscore	

=	

0x5F
	

ldh	

=	

alpha -- digit -- hyphen; also (abuse of notation) called "dns-char"
	

id-prefix	

=	

alphanum
	

ldh-label	

=	

[61* ldh id-prefix]
	

label	

=	

id-prefix ldh-label
	

sldn	

=	

label dot label
	

hostname	

=	

*(label dot) sldn
	

ipv4-addr	

=	

1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
	 	 	 









	

ipv6-addr	

=	

hexpart [":" IPv4address]
	

hexpart	

=	

hexseq -- hexseq "::" [hexseq] -- "::" [hexseq]
	

hexseq	

=	

hex4 *(":" hex4)
	

hex4	

=	

1*4HEXDIG
	

e164a-addr	

=	

plus 1*3 digit dot 1*12 digit





Every
resource record in the.biz zone will have one of the following as its owner: 



	•
	xbiz
(for the SOA record and ns records for the.biz zone itself)



	•
	An
sldn, where the right-hand label is "biz" (for NS records)



	•
	A
hostname, where the right-hand label is "biz" (for A records) 




C.9 Transfers  


The
system will provide a function to TRANSFER ownership of an entity to a new parent entity. Examples of this are transferring a domain-name to a new registrant (Transfer of
registrant/registrar) and transferring a registrant to a new registrar (Transfer of registrar). 


The
TRANSFER function will operate on the registrant, domain-name, and contact entities. 


The
TRANSFER function will take a source entity type and identifier as well as a new sponsorship entity type and identifier as input. If the source entity type is a domain-name the new
owner entity type must be a registrant. If the source entity type is a registrant, the new owner entity type must be a registrar. 



The
TRANSFER function will return a response code indicating success or failure. 


Registrars
will only be able to TRANSFER a registrant entity to themselves, and to do so they must supply the registrant authentication. 


Registrars
will only be able to TRANSFER domain-name entities to registrants that they sponsor. 


Registry
supervisors will be able to TRANSFER any domain-name entity to any registrant. 



Registry
supervisors will be able to TRANSFER any registrant to any registrar. 


Transfer
of domain-name entities creates billing transactions. 


C.10 Grace Period  


Add Grace Period  


The
Add Grace Period is a specified number of calendar days following the initial registration of a domain. The current value of the Add Grace Period for all registrars is five calendar days. If a
Delete, Renew, or Transfer operation occurs within the five calendar days, the following rules apply: 



Delete.    If a domain is deleted within the Add Grace Period, the sponsoring Registrar at the time of the deletion is credited for the amount
of the registration. The domain is deleted from the Registry database and is immediately available for registration by any Registrar. See below for a description of overlapping grace period
exceptions. 


Renew.    If a domain is extended within the Add Grace Period, there is no credit for the add. The account of the sponsoring Registrar at the
time of the extension will be charged for the initial add plus the number of years the registration is extended. The expiration date of the domain is extended by the number of years, up to a total of
ten years, as specified by the registrar's requested Renew operation. 












Transfer (other than ICANN—approved bulk transfer).    Transfers under Part A of Exhibit B to the Registry—Registrar
Agreement may not occur during the Add Grace Period or at any other time within the first 60 days after the initial registration. Enforcement is the responsibility of the Registrar sponsoring the
domain name registration and is currently enforced by the SRS. 


Bulk Transfer (with ICANN approval).    Bulk transfers with ICANN approval may be made during the Add Grace Period according to the procedures
in Part B of Exhibit B to the Registry—Registrar Agreement. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the initial
add. 




Renew Grace Period  


The
Renew Grace Period is a specified number of calendar days following the renewal of a domain name registration period through an XRP Command Renew. The current value of the Renew Grace Period is
five calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the following rules apply: 



Delete.    If a domain is deleted within the Renew Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of the
renew fee. The deleted domain is moved to the Redemption Grace Period (that is, to the PendingDelete status) as described in Appendix C.11. See below for a description of overlapping grace period
exceptions. 


Renew.    A domain can be extended within the Renew Grace Period for up to a total of ten years. The account of the sponsoring Registrar at
the time of the additional extension will be charged for the additional number of years the registration is extended. 


Transfer (other than ICANN—approved bulk transfer).    If a domain is transferred within the Renew Grace Period, there is no
credit. The expiration date of the domain is extended by one year and the years added as a result of the Extend remain on the domain name up to a total of 10 years. 


Bulk Transfer (with ICANN approval).    Bulk transfers with ICANN approval may be made during the Renew Grace Period according to the
procedures in Part B of Exhibit B to the Registry—Registrar Agreement. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the
Renew operation. 




Auto-Renew Grace Period  


The
Auto-Renew Grace Period is a specified number of calendar days following an auto-renewal. An auto-renewal occurs if a domain name registration is not renewed by the expiration date; in this
circumstance the registration will be automatically renewed by the system the first day after the expiration date. The current value of the Auto-Renew Grace Period is 45 calendar days. If a Delete,
Renew, or Transfer occurs within the Auto-Renew Grace Period, the following rules apply: 



Delete.    If a domain is deleted within the Auto-Renew Grace Period the deleted domain is moved to the Redemption Grace Period (that is, to
the PendingDelete status) as described in Appendix C.11. See below for a description of overlapping grace period exceptions. 



Renew.    A domain can be Renewed within the Auto-Renew Grace Period for up to a total of ten years. The account of the sponsoring Registrar
at the time of the additional extension will be charged for the additional number of years the registration is extended. 


Transfer (other than ICANN—approved bulk transfer).    If a domain is transferred under Part A of Exhibit B to the
Registry—Registrar Agreement within the Auto-Renew Grace Period, the losing Registrar is credited with the Auto-Renew charge and the year added by the Auto-Renew operation is cancelled.
The expiration date of the domain is extended by one year up to a total maximum of ten by virtue of the transfer and the gaining Registrar is charged for that additional year, even in cases where a
full year is not added because of the 10-year maximum limitation. 












Bulk Transfer (with ICANN approval).    Bulk transfers with ICANN approval may be made during the Auto-Renew Grace Period according to the
procedures in Part B of Exhibit B to the Registry—Registrar Agreement. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the
Auto-Renew. 




Transfer Grace Period  


The
Transfer Grace Period is a specified number of calendar days following the transfer of a domain according to Part A of Exhibit B to the Registry—Registrar Agreement. The current value
of the Transfer Grace Period is five calendar days. If a Delete, Extend, or Transfer occurs within that five calendar days, the following rules apply: 



Delete.    If a domain is deleted within the Transfer Grace Period, the sponsoring Registrar at the time of the deletion receives a credit of
the transfer fee. The deleted domain is moved to the Redemption Grace Period (that is, to the PendingDelete status) as described in Appendix C.11. See below for a description of overlapping grace
period exceptions. 


Renew.    If a domain is extended within the Transfer Grace Period, there is no credit for the transfer. The Registrar's account will be
charged for the number of years the registration is extended. The expiration date of the domain is extended by the number of years, up to a maximum of ten years, as specified by the registrar's
requested Extend operation. 


Transfer (other than ICANN—approved bulk transfer).    If a domain is transferred within the Transfer Grace Period, there is no
credit. The expiration date of the domain is extended by one year up to a maximum term of ten years. 


Bulk Transfer (with ICANN approval).    Bulk transfers with ICANN approval may be made during the Transfer Grace Period according to the
procedures in Part B of Exhibit B to the Registry—Registrar Agreement. The expiration dates of transferred registrations are not affected. The losing Registrar's account is charged for the
Transfer operation that occurred prior to the Bulk Transfer. 




Bulk Transfer Grace Period  


There
is no grace period associated with Bulk Transfer operations according to Part B of Exhibit B to the Registry—Registrar Agreement. Upon completion of the Bulk Transfer, any associated
fee is not refundable. 


Overlapping Grace Periods  


If
an operation is performed that falls into more that one grace period, the actions appropriate for each grace period apply (with some exceptions as noted below). 



	•
	If
a domain is deleted within the Add Grace Period and the Renew Grace Period, then the Registrar is credited the registration and renew amounts, taking into account the
number of years for which the registration and renew were done. The domain is deleted from the Registry database and is immediately available for registration by any Registrar.



	•
	If
a domain is auto-renewed, then extended, and then deleted within the Renew Grace Period, the registrar will be credited for the Auto-Renew and the number of years for the
extension. The years that were added to the Registered Name's expiration as a result of the auto-renewal and extension are removed.The deleted Registered Name is moved to the Redemption Grace Period
(that is, to the PendingDelete status) as described in Appendix C.11. 




Overlap Exception  



	•
	If
a domain is deleted within one or several Transfer Grace Periods, then only the current sponsoring Registrar is credited for the transfer amount. For example if a domain
is transferred from Registrar A to Registrar B and then to Registrar C and finally deleted by Registrar C 










within
the Transfer Grace Period of the first, second and third transfers, then only the last transfer is credited to Registrar C. 



	•
	If
a domain is extended (through the XRP command "Renew") within the Transfer Grace Period, then the current Registrar's account is charged for the number of years the
registration is extended. 




Note:  If several billable operations, including transfers, are performed on a domain and the domain is deleted within the grace periods of
each of those operations, only those operations that were performed after the latest transfer, including the latest transfer, are credited to the current Registrar. 


Earlier
Drafts: 


18 June 2003

11 May 2001

27 April 2001  


C.11 Additional Services  



Redemption Grace Period  


Overview  


The
Redemption Grace Period Service allows registrars to restore Registered Names that were unintentionally deleted and are still within a thirty-day Redemption Grace Period (RGP). The RGP
Service cover all names deleted by registrars, with the exception of those names deleted in the Add Grace Period. 


The
RGP Service may be implemented in two stages. Stage 1 is as described in the following. In the future, ICANN and Registry Operator will discuss implementation of Stage 2, with the goal, if
feasible, of allowing registrants to choose which registrar will restore their deleted name(s). 



Implementation  


The.biz
Registry RGP is a fully automated and EPP-compliant implementation. Only statuses defined in the current EPP specifications will be used. As such all domains slated for deletion
will remain in PendingDelete status for 35 days or until they are restored. 


PendingDelete Status:  


All
domains deleted outside the Add Grace Period will be placed on PendingDelete status for a total of 35 days, after which time the names will be purged from the Registry database and made
available again for registration. 


During
this PendingDelete timeframe, domain names can only be restored during the first 30 days, and cannot be otherwise modified. The only action allowed by the Registrar is the restoration of
the domain name. 


Note:
BULK TRANSFER operations are allowed within the 30-day RGP provided that such transfer is in accordance with Exhibit D to Appendix F. The gaining registrar in any
ICANN-approved bulk transfer assumes the role of the deleting registrar with regards to any name in the PendingDelete status sponsored by the losing registrar at the time of transfer. 



Note:
TRANSFER or modification requests shall not be allowed during the RGP. 


Upon
being placed in PendingDelete status, domain names will be immediately removed from the DNS, but will remain in the Whois with a notation about their availability of being restored. (See
Appendix O for further details). 


At
the conclusion of the 30-day RGP, the domain will remain on PendingDelete for an additional five days. During this time, the domain cannot be restored, modified, deleted, or
transferred. At the 










conclusion
of this five-day period, the domain will be purged from the Registry database and hence available for re-registration. 


Restore Command:  


The
implementation of the Redemption Grace Period Service involves one command. 


RESTORE
Command: Registrars may restore names by using the existing EPP Renew command. In addition, EPP extensions will be used to capture the additional required reporting information, see below. A
successful restore command will terminate the PendingDelete status, remove the deleted
status attribute from the registration and return the registered name to the same state it was in immediately prior to the delete request. 


If
the registered name is past its expiration date at the time it is restored, then, following the restore, its registration term will be extended by the minimum term of years necessary to bring it
current. The registrar will first be debited for the restoration and following for the renewal term. 


There
is no Restore Grace Period. 


Appropriate Use of the Restore Capability  


Registrars
may only RESTORE Registered Names in order to correct unintentional deletions caused by registrant, registrar, or registry mistake (or as required by operation of the UDRP or other
applicable dispute resolution policy in order to implement a court, arbitral tribunal or Administrative Panel decision). Restoring Registered Names in order to assume the rights to use or sell them
will be considered an abuse of the system and will give Registry Operator the ability to delete those impacted domain names or terminate the Registry-Registrar Agreement. 



Registrar Reporting Requirement  


In
order to facilitate verification of registrar compliance with the intended purpose of the Redemption Grace Period Service, Registrars are required to submit a "Registrar Restore Report" to the
Registry Operator. 


The
reports will be generated as set forth by the Registry Operator through the restore command (EPP extensions) and in accordance with the below: 


The
following data shall be provided by the Registry Operator: 



	•
	WHOIS
data for deleted name, as it existed prior to deletion



	•
	WHOIS
data for deleted name, as it existed at the time of report submission



	•
	Exact
date and time of deletion



	•
	Exact
date and time of restore 




The
following data shall be submitted by the registrar as part of the restore command. Failure to provide all of the following data at the time the restore command is submitted will result in a
failure to restore the domain name. 



	•
	Written
explanation and corresponding reason code as to why registered name was restored (e.g., registrant mistake, registrar mistake, registry mistake, dispute resolution,
etc.)



	•
	Written
statement affirming that Registrar has not restored the.BIZ domain name in question in order to assume the rights to use or sell the name for itself or for any third
party (unless the name was restored as required to give effect to an order or decision from a court, arbitral tribunal or Administrative Panel—in such cases a copy of the order should be
provided separately to the Registry Operator by no later than five (5) business days following the restore).



	•
	Written
statement affirming that information in report is factually accurate to the best of the Registrar's knowledge, and that the registrar acknowledges that intentionally
supplying false 










information
in the Restore Report shall constitute an incurable material breach of the Registry-Registrar Agreement and may result in the deletion of the impacted domain name(s). 




The
registry will maintain (for two years) copies of all Restore commands, as well as provide ICANN with copies of such reports. Further, the registry will include in its monthly report to ICANN the
number of Restore Reports received (see Appendix T). 





Registry Transparency Requirement—Registry Reports  


The
Registry will provide comprehensive, regularly updated lists of names with a PendingDelete status to all Registrars via an FTP or SCP mechanism; these lists will include corresponding dates of
deletion. These reports will only include names in the last five days of the PendingDelete status. 


Registry Transparency—Public Whois  


See
Appendix O. 


Registry Fees for Restoring Deleted Names  


The
maximum registry fee for restoring a deleted name is set forth in Appendix G to the Registry Agreement. The Redemption Grace Period Service
fee is separate from, and in addition to, the ordinary charges for registration term extensions. 


Comments
concerning the layout, construction and functionality of this site. should be sent to webmaster@icann.org. 


Page
Updated: 28-Jun-2003

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


Appendix C
is divided into eleven sections: 



	C.1	Registry Overview
	

C.2	

Registry-Registrar Model and Protocol
	

C.3	

Zone File Generation, Distribution, and Publication
	

C.4	

Whois Service
	

C.5	

Customer Support Services and Capabilities
	

C.6	

Operational Test and Evaluation
	

C.7	

Registrar Reports
	

C.8	

DataBase Services
	

C.9	

Transfers
	

C.10	

Grace Period
	

C.11	

Additional Services












APPENDIX D  


 
  Performance Specifications  
  


1. Introduction. The attached Performance Specification Matrix ("Matrix") provides a list of performance specifications as they apply to the three Core
Services provided by the Registry—SRS, Nameserver, and Whois services. 


2. Definition. Capitalized terms used herein and not otherwise defined shall have the meaning ascribed to them in the Registry Agreement. 



2.1
"Core Internet Service Failure" refers to an extraordinary and identifiable event beyond the control of Registry Operator affecting the Internet services to be measured pursuant to
Section 3.6 of this Appendix D. Such events include but are not limited to congestion collapse, partitioning, power grid failures, and routing failures. 


2.2
"Core Services" refers to the three core services provided by the Registry—SRS, Nameserver, and Whois Services. 


2.3
"Performance Specification" refers to the specific committed performance service levels as specified herein. 


2.4
"Performance Specification Priority" refers to the Registry's rating system for Performance Specifications. Some Performance Specifications are more critical to the operations of the Registry than
others. Each of the Performance Specifications is rated as C1—mission critical, C2—mission important, C3—mission beneficial, or C4—mission maintenance. 


2.5
"Registrar Community" refers to all of the ICANN-Accredited Registrars who have executed Registry-Registrar Agreements with Registry Operator for the Registry TLD. 


2.6
"SRS" refers to the Shared Registration System; the service that the Registry provides to the Registrar Community. Specifically, it refers to the ability of Registrars to add, modify, and delete
information associated with domain names, nameserver, contacts, and registrar profile information. This service is provided by systems and software maintained in coactive redundant data centers. The
service is available to approved Registrars via an Internet connection. 


2.7
"Nameserver" refers to the nameserver function of the Registry and the nameservers that resolve DNS queries from Internet users. This service is performed by multiple nameserver sites that host
DNS resource records. The customers of the nameserver service are users of the Internet. The nameservers receive a DNS query, resolve it to the appropriate address, and provide a response. 


2.8
"Service Level Measurement Period" refers to the period of time for which a Performance Specification is measured. Monthly periods are based on calendar months, quarterly periods are based on
calendar quarters, and annual periods are based on calendar years. 


2.9
"Whois" refers to the Registry's Whois service. The Registry will provide contact information related to registered domain names and nameserver through a Whois service. Any person with access to
the Internet can query the Registry's Whois service directly (via the Registry website) or through a Registrar. 




3. Performance Specifications. Registry Operator shall use commercially reasonable efforts to provide Registry Services for the Registry TLD. The
Performance Specifications defined below establish the basis for the Service Level Exception Credits ("SLE Credits") provided for in Appendix E to this Registry Agreement. These Performance
Specifications also set forth Registry Operator's obligations directly to ICANN under Subsection 3.3 of the Registry Agreement. 



3.1 Service Availability. Service Availability is defined as the time, in minutes, that the Registry's Core Services are responding to its users.
Service is unavailable when a service listed in the Matrix is unavailable to all users, that is, when no user can initiate a session with or receive a response from the Registry ("Unavailability").
Service Availability is a C1 priority level. 










3.1.1 Service Availability is measured as follows: 



Service
Availability % = {[(TM—POM)—UOM] / (TM—POM)}*100 where: 


TM =
Total Minutes in the Service Level Measurement Period (#days*24 hours*60 minutes) 


POM =
Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages during the Service Level Measurement Period) 



UOM =
Unplanned Outage Minutes (Difference between the total number of minutes of Unavailability during the Service Level Measurement Period minus POM). 




Upon
written request, and at the sole expense of the requesting Registrar(s), Registry Operator will retain an independent third party (to be selected by Registry Operator with the consent of the
Registrar(s) to perform an independent calculation of the UOM). The frequency of this audit will be no more than once yearly during the term of the agreement between Registry Operator and the
Registrar. 


This
calculation is performed and the results reported for each calendar month for SRS and Whois availability and for each calendar year for Nameserver availability. Results will be reported to the
Registrar Community via e-mail and to ICANN according to Appendix T. 


3.1.2 Service Availability—SRS = 99.9% per calendar month. Service Availability as it applies to the SRS refers to the ability of the
SRS to respond to Registrars that access and use the SRS through the XRP protocol defined in Appendix C. SRS Unavailability will be logged with the Registry Operator as Unplanned Outage
Minutes. The committed Service Availability for SRS is 99.9% and the Service Level Measurement Period is monthly. 


3.1.3 Service Availability—Nameserver = 99.999% per calendar year. Service Availability as it applies to the Nameserver refers to the
ability of the Nameserver to resolve a DNS query from an Internet user. Nameserver Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service
Availability for Nameserver is 99.999% and the Service Level Measurement Period is annually. 


3.1.4 Service Availability—Whois = 99.95% per calendar month. Service Availability as it applies to Whois refers to the ability of
all users to access and use the Registry's Whois service. Whois Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for Whois is
99.95% and the Service Level Measurement Period is monthly. 




3.2 Planned Outage. High volume data centers like the Registry require downtime for regular maintenance. Allowing for regular maintenance ("Planned
Outage") ensures a high level of service for the Registry. Planned Outage Performance Specifications are a C4 priority level. 



3.2.1 Planned Outage Duration. The Planned Outage Duration defines the maximum allowable time, in hours and minutes, that the Registry Operator is
allowed to take the Registry Services out of service for regular maintenance. Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. This Performance
Specification, where applicable, has a monthly Service Level Measurement Period. The Planned Outage Duration for the Core Services is as follows: 



(i)
Planned Outage Duration—SRS = 8 hours (480 minutes) per month; 


(ii)
Planned Outage Duration—Nameserver = (no planned outages allowed); and 


(iii)
Planned Outage Duration—Whois = 8 hours (480 minutes) per month. 

















3.2.2 Planned Outage Timeframe. The Planned Outage Timeframe defines the hours and days in which the Planned Outage can occur. The Planned Outage
Timeframe for the Core Services is as follows: 



(i)
Planned Outage Timeframe—SRS = 0600-1400 UTC Sunday; 


(ii)
Planned Outage Timeframe—Nameserver = (no planned outages allowed); and 


(iii)
Planned Outage Timeframe—Whois = 0600-1400 UTC Sunday. 




3.2.3 Planned Outage Notification. The Registry Operator must notify all of its Registrars of any Planned Outage. The Planned Outage Notification
Performance Specification defines the number of days prior to a Planned Outage that the Registry Operator must notify its Registrars. The Planned Outage Notification for the Core Services is as
follows: 



(i)
Planned Outage Timeframe—SRS = 3 days; 


(ii)
Planned Outage Timeframe—Nameserver = (no planned outages allowed); and 


(iii)
Planned Outage Timeframe—Whois = 3 days. 





3.3 Extended Planned Outage. In some cases such as software upgrades and platform replacements an extended maintenance timeframe is required. Extended
Planned Outages will be less frequent than regular Planned Outages but their duration will be longer. Extended Planned Outage Performance Specifications are a C4 priority level. 



3.3.1 Extended Planned Outage Duration. The Extended Planned Outage Duration defines the maximum allowable time, in hours and minutes, that the Registry
Operator is allowed to take the Registry Services out of service for extended maintenance. Extended Planned Outages are planned in advance and the Registrar Community is provided warning ahead of
time. Extended Planned Outage periods are in addition to any Planned Outages during any Service Level Measurement Period. This Performance Specification, where applicable, has a Service Level
Measurement Period based on a calendar quarter. The Extended Planned Outage Duration for the Core Services is as follows: 



(i)
Extended Planned Outage Duration—SRS = 18 hours (1080 minutes) per calendar quarter; 


(ii)
Extended Planned Outage Duration—Nameserver = (no planned outages allowed); and 


(iii)
Extended Planned Outage Duration—Whois = 18 hours (1080 minutes) per calendar quarter. 




3.3.2 Extended Planned Outage Timeframe. The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned Outage can
occur. The Extended Planned Outage Timeframe for the Core Services is as follows: 



(i)
Extended Planned Outage Timeframe—SRS = 0600 - 1400 UTC Saturday or Sunday; 


(ii)
Extended Planned Outage Timeframe—Nameserver = (no planned outages allowed); and 


(iii)
Extended Planned Outage Timeframe—Whois = 0600 - 1400 UTC Saturday or Sunday. 




3.3.3 Extended Planned Outage Notification. The Registry Operator must notify all of its Registrars of any Extended Planned Outage. The Extended Planned
Outage Notification Performance Specification defines the number of days prior to an Extended Planned Outage that the Registry Operator must notify its Registrars. The Extended Planned Outage
Notification for the Core Services is as follows: 



(i)
Extended Planned Outage Timeframe—SRS = 4 weeks; 













(ii)
Extended Planned Outage Timeframe—Nameserver =(no planned outages allowed); and 



(iii)
Extended Planned Outage Timeframe—Whois = 4 weeks. 





3.4 Processing Time. Processing Time is an important measurement of transaction-based services like the Registry. The first three Performance
Specifications, Service Availability, Planned Outages and Extended Planned Outages, measure the amount of time that the service is available to its users. Processing Time measures the quality of that
service. 


Processing
Time refers to the time that the Registry Operator receives a request and sends a response to that request. Since each of the Registry Services has a unique function the Performance
Specifications for Processing Time are unique to each of the Registry Services. For example, a Performance Specification for the Nameserver is not applicable to the SRS and Whois, etc. Processing Time
Performance Specifications are a C2 priority level. 


Processing
Time Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. The Registry Operator will log the processing time for all of the
related transactions, measured from the time it receives the request to the time that it returns a response. 



3.4.1 Processing Time—Add, Modify, Delete = 3 seconds for 95%.



(i)
Processing Time—Add, Modify, and Delete is applicable to the SRS as accessed through the XRP protocol defined in Appendix C. It measures the processing time for add, modify, and
delete transactions associated with domain names, nameservers, contacts, and registrar profile information. 


(ii)
The Performance Specification is 3 seconds for 95% of the transactions processed. That is, 95% of the transactions will take 3 seconds or less from the time the Registry Operator receives the
request to the time it provides a response. 






3.4.2 Processing Time—Query Domain = 1.5 seconds for 95%.




(i)
Processing Time—Query Domain is applicable to the SRS as accessed through the XRP protocol defined in Appendix C. It measures the processing time for an availability query of a
specific domain name. 


(ii)
The performance specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Registry Operator receives the query to
the time it provides a response as to the domain name's availability. 





3.4.3 Processing Time—Whois Query = 1.5 seconds for 95%.




(i)
Processing Time—Whois Query is only applicable to the Whois. It measures the processing time for a Whois Query. 


(ii)
The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Whois receives a query to the time it
responds. 




3.4.4 Processing Time—Nameserver Resolution = 1.5 seconds for 95%.



(i)
Processing Time—Nameserver Resolution is only applicable to the Nameserver. It measures the processing time for a DNS query. 



(ii)
The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time Nameserver receives the DNS query to the
time it provides a response. 





3.5 Update Frequency. There are two important elements of the Registry that are updated frequently and are used by the general public; Nameserver and
Whois. Registrars generate these 









updates
through the SRS. The SRS then updates the Nameserver and the Whois. These will be done on a batch basis. Update Frequency Performance Specifications are a C3 priority level. 



The
committed Performance Specification with regard to Update Frequency for both the Nameserver and the Whois is 15 minutes for 95% of the transactions. That is, 95% of the updates to the Nameserver
and Whois will be effectuated within 15 minutes. This is measured from the time that the registry confirms the update to the registrar to the time the update appears in the Nameserver and Whois.
Update Frequency Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. 



3.5.1 Update Frequency—Nameserver = 15 minutes for 95%.



3.5.2 Update Frequency—Whois = 15 minutes for 95%.




3.6 Cross-Network Nameserver Performance Requirements. Nameserver round-trip-time and packet loss from the Internet are
important elements
of the quality of service provided by the Registry Operator. These characteristics, however, are affected by Internet performance and therefore cannot be closely controlled by Registry Operator.
Accordingly, these requirements are not matters subject to Service Level Exceptions and credits under the Service Level Agreement (Appendix E), but they are Registry Operator obligations under
Section 3.3 of the Registry Agreement. 



The
committed Performance Specification for cross-network nameserver performance is a measured round-trip time of under 300 ms and measured packet loss of under 10%. Cross-network
nameserver performance measurements will be conducted by ICANN at times of its choosing, in the following manner: 



3.6.1
The measurements will be conducted by sending strings of DNS request packets from each of four measuring locations to each of the.biz nameservers and observing the responses from the.biz
nameservers. (These strings of requests and responses are referred to as a "CNNP Test".) The measuring locations will be four root nameserver locations (on the US East Coast, US West Coast, Asia, and
Europe). 


3.6.2
Each string of request packets will consist of 100 UDP packets at 10 second intervals requesting ns records for arbitrarily selected.biz second-level domains, preselected to ensure that the
names exist in the Registry TLD and are resolvable. The packet loss (i.e. the percentage of response packets not received) and the average round-trip time for response packets received
will be noted. 


3.6.3
To meet the packet loss and round-trip-time requirements for a particular CNNP Test, all three of the following must be true: 



3.6.3.1
The round-trip time and packet loss from each measurement location to at least one.biz nameserver must not exceed the required values. 


3.6.3.2
The round-trip time to each of 75% of the.biz nameservers from at least one of the measurement locations must not exceed the required value. 


3.6.3.3
The packet loss to each of the.biz nameservers from at least one of the measurement locations must not exceed the required value. 




3.6.4
Any failing CNNP Test result obtained during an identified Core Internet Service Failure shall not be considered. 


3.6.5
To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests at varying times (i.e. at different times of the day, as well as on different days of the week). Registry Operator
will be deemed to have failed to meet the cross-network nameserver performance requirement only if the.biz nameservers persistently fail (see Section 3.6.3 above) the CNNP Tests with no less
than three consecutive failed CNNP Tests to be considered to have persistently failed. 











3.6.6
In the event of persistent failure of the CNNP Tests, ICANN will give Registry Operator written notice of the failures (with backup data) and Registry Operator will have sixty days to cure the
failure. 


3.6.7
If, following that opportunity to cure, the.biz nameservers continue to persistently fail CNNP Tests and Registry Operator fails to resolve the problem after thirty days notice of the continuing
failures, Registry Operator will be deemed not to have met its obligations under Subsection 3.3 of the Registry Agreement. 


3.6.8
Sixty days prior to the commencement of testing under this provision, ICANN will provide Registry Operator with the opportunity to evaluate the testing tools and procedures to be used by ICANN.
In the event that Registry Operator does not approve of such tools and procedures, ICANN will work directly with Registry Operator to make necessary modifications. 





4. Responsibilities of the Parties.



4.1
Except in the case of nameserver performance measurements, Registry Operator will perform monitoring from internally located systems as a means to verify that the availability and performance
measurements in this document are being met. 


4.2
Beginning no later than 120 days post Commencement-of-Service Date, the Registry Operator will publish preliminary weekly system performance and availability
reports. Registry Operator will use best efforts to finalize these reports no later than 30 days after the preliminary reports are provided. 


4.3
The Registry Operator will provide the Whois Service as specified in Appendices C and O. 


4.4
The Registry Operator will use commercially reasonable efforts to restore the critical systems of the Core Services within 24 hours after the termination of a force majeure event and
restore full system functionality within 48 hours after the termination of a force majeure event. Outages due to a force majeure will not be considered Service Unavailability. 




5. Miscellaneous.



5.1
This Appendix is not intended to replace any term or condition in the Registry Agreement. 


5.2
Dispute Resolution will be handled pursuant to the terms of Subsection 5.9 of the Registry Agreement. 












 
 

PERFORMANCE SPECIFICATION MATRIX    
    



	 
	 	Performance

Specification Description
	 	SRS
	 	Nameserver
	 	Whois

	1	 	Service Availability	 	99.9% per calendar month	 	99.999% per calendar year	 	99.95% per calendar month
	2	 	Processing Time—Add, Modify, Delete	 	3 sec for 95%	 	NA	 	NA
	3	 	Processing Time—Query Domain	 	1.5 sec for 95%	 	NA	 	NA
	4	 	Processing Time—Whois	 	NA	 	NA	 	1.5 sec for 95%
	5	 	Processing Time—Nameserver Resolution	 	NA	 	1.5 sec for 95%	 	NA
	6	 	Update Frequency	 	NA	 	15 min for 95%	 	15 min for 95%
	7	 	Planned Outage—Duration	 	8 hrs per calendar month	 	not allowed	 	8 hrs per calendar month
	8	 	Planned Outage—Timeframe	 	0600—1400 UTC Sun	 	not allowed	 	0600—1400 UTC Sun
	9	 	Planned Outage—Notification	 	3 days	 	not allowed	 	3 days
	10	 	Extended Planned Outage—Duration	 	18 hrs per calendar quarter	 	not allowed	 	18 hrs per calendar quarter
	11	 	Extended Planned Outage—Timeframe	 	0600—1400 UTC Sat or Sun	 	not allowed	 	0600—1400 UTC Sat or Sun
	12	 	Extended Planned Outage—Notification	 	28 days	 	not allowed	 	28 days
	13	 	Cross-Network Nameserver Performance	 	NA	 	300 ms RTT and 10% packet loss	 	NA











APPENDIX E  


 
 

Service Level Agreement  
  



1.  Definitions. Capitalized terms used herein and not otherwise defined shall have the definitions ascribed to them in Appendix D to
the Registry Agreement or the Registry-Registrar Agreement. 


2.  Credits. If Registry Operator fails to meet the Performance Specifications defined in Appendix D to the Registry Agreement
("Service Level Exception" or "SLE"), Registry Operator shall pay in the aggregate to the Registrar Community a credit according to the tables provided below ("Applicable Credit"). Each Registrar
shall only be entitled to a fraction of the Applicable Credit. Such fractions of the credit specified in the tables to be paid to any individual Registrar will be calculated based upon the number of
domain names that such Registrar added to the Registry during the Service Level Measurement Period compared to the total number of domain names added to the Registry by all Registrars during the
Service Level Measurement Period in which the SLE occurred. The credit due to Registrar may be paid as an offset to registrations and other fees owed to Registry Operator by Registrar. All credits
shall be paid in U.S. Dollars. The following Credit Lookup Matrix indicates the corresponding credit table for which the credits defined in this Appendix will be levied. 


 
 

CREDIT LOOKUP MATRIX    
    



	 
	 	Performance Specification

Description
	 	SRS
	 	Nameserver
	 	Whois

	1	 	Service Availability	 	Table C1a	 	Table C1b	 	Table C1a
	2	 	Processing Time—Add, Modify, Delete	 	Table C2	 	NA	 	NA
	3	 	Processing Time—Query Domain	 	Table C2	 	NA	 	NA
	4	 	Processing Time—Whois	 	NA	 	NA	 	Table C2
	5	 	Processing Time—Nameserver Resolution	 	NA	 	Table C2	 	NA
	6	 	Update Frequency	 	NA	 	Table C3	 	Table C3
	7	 	Planned Outage—Duration	 	Table C4b	 	NA	 	Table C4b
	8	 	Planned Outage—Timeframe	 	Table C4a	 	NA	 	Table C4a
	9	 	Planned Outage—Notification	 	Table C4a	 	NA	 	Table C4a
	10	 	Extended Planned Outage—Duration	 	Table C4b	 	NA	 	Table C4b
	11	 	Extended Planned Outage—Timeframe	 	Table C4a	 	NA	 	Table C4a
	12	 	Extended Planned Outage—Notification	 	Table C4a	 	NA	 	Table C4a
	13	 	Cross-Network Nameserver Performance	 	NA	 	See note.	 	NA





Note:
The cross-network nameserver performance requirement is a subject of Registry Operator's obligations under Subsection 3.3 of the Registry Agreement but is not a subject of this Service Level
Agreement (Appendix E). 


If
one or more SLEs occurs as the direct result of a failure to meet a Performance Specification in a single credit class, Registry Operator shall be responsible only for the credit assessed for the
credit class which is the proximate cause for all directly related failures. 


The
following tables identify total Registrar Community credits due for SLEs in the four credit classes C1—C4. Notwithstanding the credit levels contained in these tables, the total
credits owed by Registry Operator under this Agreement shall not exceed $30,000 USD monthly and $360,000 USD annually. 










The
credits contained in Tables C1a-C4 represent the total credits that may be assessed in a given SLR category in one Service Level Measurement Period. 


2.1 C1 Credit Class—If availability of C1 Credit Class components or systems does not meet C1 Performance Specifications in any given
Service Level Measurement Period described in the
Performance Specification Matrix in Appendix D of the Registry Agreement, Registry Operator will credit the Registrar Community according to the tables (which amount will be credited to the
Registrar on a proportional basis as set forth above). 


 
 

Table C1a    
    



	SLE
 
	 	< 30

sec.'s
	 	30-60

sec.'s
	 	1-2

min.'s
	 	2-10

min.'s
	 	10-30

min.'s
	 	over 30

min.'s

	Monthly Credit to Registrar Community	 	$	750	 	$	1,500	 	$	2,500	 	$	3,750	 	$	5,000	 	$	6,000





C1a Availability Example: In a given measurement period, the SRS Availability is 99.87%, which equates to 52 minutes of unplanned downtime. The Registry
Operator's Performance Specification for SRS Availability is 99.9%, or 43 minutes of downtime. The Service Level Exception, therefore, is 9 minutes (52-43 minutes), the difference between
the Performance Specification and the actual measured performance. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C1a. In Table C1a, the time interval (2-10
minutes) has a corresponding credit of $3,750 USD to be paid to the Registrar Community. 



 
 

Table C1b    
    



	SLE
 
	 	< 10

min.'s
	 	10-30

min.'s
	 	30-60

min.'s
	 	1-2

hours
	 	2-4

hours
	 	over 4

hours

	Annual Credit to Registrar Community	 	$	7,500	 	$	15,000	 	$	25,000	 	$	35,000	 	$	50,000	 	$	75,000





C1b Availability Example: In a given Service Level Measurement Period, the measured Nameserver Availability is 99.990% over a twelve (12) month
period, which equates to 52 minutes of downtime. The Registry Operator's Performance Specification for Nameserver Availability is 99.999%, or 5minutes of downtime per calendar year. The Service Level
Exception, therefore, is 47 minutes (52-5 minutes), the difference between the Performance Specification and the actual measured performance. From the Credit Lookup Matrix, we see the
relevant SLA is found in Table C1b. In Table C1b, the time interval (30-60 minutes) has a corresponding credit of $25,000 USD to be paid to the Registrar Community. 




2.2 C2 Credit Class—If processing time for C2 Credit Class services does not meet C2 Service Levels in any given Service Level Measurement
Period, Registry Operator will credit the Registrar Community according to the following table (which amount will be credited to the Registrars on a proportional basis as set forth above). 


 
 

Table C2    
    



	SLE
 
	 	< 2 sec.'s
	 	2-5

sec.'s
	 	5-10

sec.'s
	 	10-20

sec.'s
	 	20-30

sec.'s
	 	over 30

sec.'s

	Monthly Credit to Registrar Community	 	$	375	 	$	750	 	$	1,500	 	$	3,500	 	$	4,000	 	$	7,500





C2 Processing Example: The Performance Specification for Processing Time for Add, Modify, and Delete is 3 seconds or less for 95% of the transactions.
In a given Service Level Measurement Period 7% of the transactions are greater than 3 seconds. The 5% of those transactions with the longest processing times are not subject to the SLE calculation (3
seconds for 95%). The SLE is calculated using the average processing time for the 2% of the transactions that are subject to the SLE. If there were 1,000 transactions and they took a total of 4,000
seconds the average is 4 









seconds.
That generates an SLE of 1 second (4 seconds—3 seconds). From the Credit Lookup Matrix, we see the relevant SLA is found in Table C2. In Table C2, the SLE time interval
(< 2 seconds) has a corresponding credit of $375 USD to be paid to the Registrar Community. 




2.3 C3 Credit Class—If update frequency measurements of C3 Credit Class components or systems do not meet C3 Service Levels in any given
Service Level Measurement Period as described in the Performance Specification Matrix in Appendix D of the Registry Agreement, Registry Operator will credit the Registrar Community according to
the following tables (which amount will be credited to the Registrars on a proportional basis as set forth above). 


 
 

Table C3    
    



	SLE
 
	 	< 30

sec.'s
	 	30-60

sec.'s
	 	1-2

min.'s
	 	2-10

min.'s
	 	10-30

min.'s
	 	over 30

min.'s

	Monthly Credit to Registrar Community	 	$	188	 	$	375	 	$	625	 	$	938	 	$	1,250	 	$	1,500





C3 Update Frequency Example: In a given Service Level Measurement Period, 95% of the updates to the Nameserver take 24 minutes or less to complete. The
corresponding Registry Operator's Performance Specification is 15 minutes for 95% of the updates. The SLE, therefore, is 9 minutes. From the Credit Lookup Matrix, we see the relevant SLA is found in
Table C3. The SLE time interval (2-10 minutes) has a corresponding credit of $938 USD to be paid to the Registrar Community. 




2.4 C4 Credit Class—If Registry Operator fails to comply with C4 Credit Class category Performance Specifications, Registry Operator will
credit the Registrar Community according to the following tables (C4a and C4b) (which amount will be credited to the Registrars on a proportional basis as set forth above). 


 
 

Table C4a    
    



	SLE
 
	 	Any

	Monthly Credit to Registrar Community	 	$	500






C4a Planned Outage Notification Example: In each instance the Registry Operator fails to meet the Performance Specifications for Notification and
Timeframe related to Planned Outages and Extended Planned Outages, the Registry Operator is subject to the credit in Table C4a. For example, the Registry Operator informs the Registrar Community that
it will initiate a Planned Outage of the SRS on the next calendar Sunday (five (5) days advance notice). The corresponding Registry Operator's Performance Specification is 28 days
notice. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C4a. This results in a credit of $500 USD to be paid to the Registrar Community. 



 
 

Table C4b    
    



	SLE
 
	 	< 1 hour
	 	1-2 hours
	 	2-4 hours
	 	4-6 hours
	 	6-10 hours
	 	over 10 hours

	Monthly Credit to Registrar Community	 	$	300	 	$	750	 	$	1,200	 	$	2,500	 	$	3,500	 	$	4,000





C4b Planned Outage Example: In a given Service Level Measurement Period, the actual duration of a planned outage is 11 hours and 20 minutes for
the SRS. The corresponding Registry Operator's Performance Specification is 8 hours per month for the SRS. The SLE, therefore, is 3 hours and 20 minutes. From the Credit Lookup Matrix
the relevant SLA is found in Table C4b. The SLE time interval (2-4 hours) has a corresponding credit of $1,200 USD to be paid to the Registrar Community. 









3. Receipt of Credits. In order for Registrars to claim credits, the following procedure must be followed: 



3.1
Registry Operator shall perform the required measurements in order to obtain the total credits associated with the applicable Service Level Measurement Period. Such measurements and associated
documentation shall be delivered by e-mail to each of the Registrars in the Registrar Community. Such notice shall also include the total credit (if any) to be paid to the Registrar
Community as a result of any outages. 


3.2
Receipt of Credit—When the above steps have been completed, the Registry Operator shall enter in each Registrar's account balance the amount of credit (if applicable) that can be used
immediately toward registrations in the Registry. 




4.     Obligations.  



4.1
Except in the case of cross-network nameserver performance (which is not a subject of this Service Level Agreement), Registry Operator will perform monitoring from internally located systems as a
means to verify that the conditions of the SLA are being met. 


4.2
Upon written request, and at the sole expense of the requesting Registrar(s), Registry Operator will retain an independent third party to be selected by Registry Operator with the consent of the
Registrar(s). The Registrar may, under reasonable terms and conditions, audit the reconciliation records for the purposes of verifying measurements of the Performance Specifications. The frequency of
these audits will be no more than once yearly during the term of the agreement between Registry Operator and the Registrar. 


4.3
Registry Operator's obligations under this SLA (Appendix E) are waived during the first 120 days after the Commencement-of-Service Date. 



4.4
A Registrar must report each occurrence of alleged occasion of Unavailability of Core Services to the Registry Operator customer service help desk in the manner required by the Registry Operator
(i.e., e-mail, fax, telephone) in order for an occurrence to be treated as Unavailable for purposes of the SLE. 


4.5
In the event that the Core Services are Unavailable to an individual Registrar, Registry Operator will use commercially reasonable efforts to re-establish the affected Core Services
for such Registrar as soon as reasonably practicable. In the event that the Unavailability of Core Services affects all Registrars, the Registry Operator is responsible for opening a blanket trouble
ticket and immediately notifying all Registrars of the trouble ticket number and details. 


4.6
Both Registrar and the Registry Operator agree to use reasonable commercial good faith efforts to establish the cause of any alleged Core Services Unavailability. If it is mutually determined to
be a Registry Operator problem, the issue will become part of the Unplanned Outage minutes. 


4.7
Beginning no later than 120 days post Commencement-of-Service Date, the Registry Operator will publish preliminary weekly system performance and availability
reports. Registry Operator will use best efforts to finalize these reports no later than 30 days after the preliminary reports are provided. 


4.8
The Registry Operator will use commercially reasonable efforts to restore the critical systems of the Core Services within 24 hours after the termination of a force majeure event and
restore full system functionality within 48 hours after the termination of a force majeure event. Outages due to a force majeure will not be considered Service Unavailability. 


4.9
Incident trouble tickets must be opened within a commercially reasonable period of time. 




5.     Miscellaneous.  



5.1
This Service Level Agreement is independent of any rights, obligations or duties set forth in the Registry Agreement. In the event of any conflict between the terms and conditions of this
Agreement and the Registry Agreement, the Registry Agreement shall control. 










APPENDIX F  


 
 

Registry-Registrar Agreement  
  


This
Registry-Registrar Agreement (the "Agreement") is between NeuLevel, Inc., a Delaware corporation, with its principal place of business located at Loudoun Tech Center, 45980 Center Oak
Plaza, Sterling, VA 20166 ("Registry Operator"), and [Registrar's name], a [jurisdiction and type of organization], with its principal place of business
located at [Registrar's location] ("Registrar"). 


WHEREAS,
Registry Operator has entered a Registry Agreement with the Internet Corporation for Assigned Names and Numbers to operate a shared registration system, TLD nameservers, and other equipment
for the.biz top-level domain; 


WHEREAS,
multiple registrars will provide Internet domain name registration services within the.biz top-level domain; 


WHEREAS,
Registrar wishes to act as a registrar for domain names within the.biz top-level domain. 


NOW,
THEREFORE, for and in consideration of the mutual promises, benefits and covenants contained herein and for other good and valuable consideration, the receipt, adequacy and sufficiency of which
are hereby acknowledged, Registry Operator and Registrar, intending to be legally bound, hereby agree as follows: 



1.     DEFINITIONS  



1.1.  The
"APIs" are the application program interfaces by which Registrar may interact, through the XRP, with the Registry System. 


1.2.  "Confidential
Information" means all information and materials, including, without limitation, computer software, data, information, databases, protocols, reference implementation
and documentation, and functional and interface specifications, provided by the Disclosing Party to the Receiving Party under this Agreement and marked or otherwise identified as Confidential,
provided that if a communication is oral, the Disclosing Party will notify the Receiving Party in writing within 15 days of the disclosure. 



1.3.  "DNS"
means the Internet domain name system. 


1.4.  The
"Effective Date" shall be the date on which it is first executed by both parties. 


1.5.  "ICANN"
means the Internet Corporation for Assigned Names and Numbers. 


1.6.  "Personal
Data" refers to data about any identified or identifiable natural person. 


1.7.  "Registered
Name" refers to a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels, about which Registry Operator or an
affiliate engaged in providing Registry Services maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. A name in a Registry Database may be a
Registered Name even though it does not appear in a TLD zone file (e.g., a registered but inactive name). 


1.8.  "Registered
Name Holder" means the holder of a Registered Name. 


1.9.  The
"Registrar Tool Kits" shall mean the Tool Kits set forth in Exhibit A. The Registrar Tool Kits shall be comprised of the Domain Name Application Service and the Registry
Live Tool Kits. 



1.10.  "Registry
Agreement" means the Registry Agreement between Registry Operator and ICANN dated [date of Registry Agreement] for the operation of the Registry
TLD. 


1.11.  "Registry
TLD" means the.biz TLD. 












1.12.  "Registry
Database" means a database comprised of data about one or more DNS domain names within the domain of the Registry TLD that is used to generate either DNS resource records
that are published authoritatively or responses to domain-name availability lookup requests or Whois queries, for some or all of those names. 



1.13.  "Registry
Services" means services provided as an integral part of the operation of the Registry TLD, including all subdomains in which Registered Names are registered. In
determining whether a service is integral to the operation of the Registry TLD, consideration will be given to the extent to which the Registry Operator has been materially advantaged in providing the
service by its designation as such under this Agreement. The development of technology, expertise, systems, efficient operations, reputation (including identification as Registry Operator), financial
strength, or relationships with registrars and third parties shall not be deemed an advantage arising from the designation. Registry Services include: receipt of data concerning registration of domain
names and nameservers from registrars, provision to registrars of status information relating to the Registry TLD, dissemination of TLD zone files, operation of the Registry TLD zone servers,
dissemination of contact and other information concerning domain-name and nameserver registrations in the Registry TLD. 


1.14.  The
"Registry System" means the registry system operated by Registry Operator for Registered Names in the Registry TLD. 


1.15.  "Term"
means the term of this Agreement, as set forth in Subsection 8.1. 


1.16.  "XRP"
means the extensible registry-registrar protocol used by the Registry System. 



1.17.  A
"TLD" means a top-level domain of the DNS. 


Other
terms used in this Agreement as defined terms shall have the meanings ascribed to them in the context in which they are defined. 




2.     OBLIGATIONS OF REGISTRY OPERATOR  



2.1.  Access to Registry System. Throughout the term of this Agreement, Registry Operator shall provide Registrar with access as a registrar
to the Registry System that Registry Operator operates according to its arrangements with ICANN. Nothing in this Agreement entitles Registrar to enforce any agreement between Registry Operator and
ICANN. 


2.2.  Maintenance of Registrations Sponsored by Registrar. Subject to the provisions of this Agreement, ICANN requirements, and Registry
requirements authorized by ICANN, Registry Operator shall maintain the registrations of Registered Names sponsored by Registrar in the Registry System during the term for which Registrar has paid the
fees required by Subsection 4.1. 



2.3.  Provision of Tool Kits; License.  



2.3.1.  Domain
Name Application Service Tool Kit. Until the expiration of the Domain Name Application Service (as set forth in Appendix J to the Registry Agreement), Registry
Operator shall provide to Registrar a copy of the Domain Name Application Service Tool Kit no later than five business days after the Effective Date. Such Domain Name Application Service Tool Kit
shall provide sufficient technical specifications to allow Registrar to interface with the Domain Name Application Service portion of the Registry System and employ its features that are available to
Registrars; provided that if the Effective Date occurs prior to the date that Registry Operator has made the Domain Name Application Service Tool Kit available to.biz accredited Registrars generally
("DNAS Availability Data"), and such date is prior to the expiration of the Domain Name Application Service, Registry Operator shall provide to Registrar a copy of the Domain Name Application Service
Tool Kit, no later than five (5) business days after the DNAS Availability Date. 


2.3.2.  Registry
Live Tool Kit. No later than five business days after the Effective Date, Registry Operator shall provide to Registrar a copy of the Registry Live Tool Kit, which shall 














provide
sufficient technical specifications to allow Registrar to interface with the Registry Live portion of the Registry System and employ its features that are available to Registrars; provided
that if the Effective Date occurs prior to the date that Registry Operator has made the Registry Live Tool Kit available to.biz accredited Registrars generally ("Live Availability Data"), Registry
Operator shall provide to Registrar a copy of the Registry Live Tool Kit, no later than five (5) business days after the Live Availability Date. 


2.3.3.  License.
Subject to the terms and conditions of this Agreement, Registry Operator hereby grants Registrar and Registrar accepts a non-exclusive,
non-transferable, worldwide limited license to use for the term and purposes of this Agreement the XRP, APIs and any reference client software included in the Registrar Tool Kits, as well
as updates and redesigns thereof, for providing domain name registration services in the Registry TLD only and for no other purpose. 




2.4.  Changes to System. Registry Operator may from time to time make modifications to the XRP, APIs, or other software licensed hereunder
that will revise or augment the features of the Registry System. Registry Operator will provide Registrar with at least ninety days notice prior to the implementation of any material changes to the
XRP, APIs or software licensed hereunder. 


2.5.  Engineering and Customer Service Support. Registry Operator shall provide Registrar with engineering and customer service support as
set forth in Exhibit B. 


2.6.  Handling of Personal Data. Registry Operator shall notify Registrar of the purposes for which Personal Data submitted to Registry
Operator by Registrars is collected, the intended recipients (or categories of recipients) of such Personal Data, the mechanism for access to and correction of such Personal Data, and the retention
policy of Registry Operator for such Personal Data. Registry Operator shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction.
Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars. 


2.7.  ICANN Requirements. Registry Operator's obligations hereunder are subject to modification at any time as a result of ICANN-mandated
requirements and consensus policies. Notwithstanding anything in this Agreement to the contrary, Registrar shall comply with any such ICANN requirements in accordance with the timeline defined by
ICANN. 




3.     OBLIGATIONS OF REGISTRAR  



3.1.  Accredited Registrar. During the term of this Agreement, Registrar shall maintain in full force and effect its accreditation by ICANN
as a registrar for the Registry TLD, by either, at the sole discretion of ICANN, amending its existing ICANN Accreditation Agreement with ICANN ("Accreditation Agreement") to apply to Registry
Operator, or by signing a new Accreditation Agreement with ICANN that applies to Registry Operator. 


3.2.  Registrar Responsibility for Customer Support. Registrar shall provide (i) support to accept orders for Registered Names and
(ii) customer service (including domain name record support) and billing and technical support to Registered Name Holders. 


3.3.  Registrar's Registration Agreement. At all times while it is sponsoring the registration of any Registered Name within the Registry
System, Registrar shall have in effect an electronic or paper registration agreement with the Registered Name Holder. The initial form of Registrar's registration agreement is attached as
Exhibit C (which may contain multiple alternative forms of the registration agreement). Registrar may from time to time amend those forms of registration agreement or add alternative forms of
registration agreement, provided a copy of the amended or alternative registration agreement is furnished to the Registry Operator three business days in advance of the use of such amended
registration agreement. Registrar shall include in its registration agreement those terms required by this Agreement and other terms that are consistent with Registrar's obligations to Registry
Operator under this Agreement. 












3.4.  Indemnification Required of Registered Name Holders. In its registration agreement with each Registered Name Holder, Registrar shall
require such Registered Name Holder to indemnify, defend and hold harmless Registry Operator, and its directors, officers, employees and agents from and against any and all claims, damages,
liabilities, costs and expenses, including reasonable legal fees and expenses, arising out of or relating to the Registered Name Holder's domain name registration. The registration agreement shall
further require this indemnification obligation survive the termination or expiration of the registration agreement. 


3.5.  Data Submission Requirements. As part of its registration and sponsorship of Registered Names in the Registry TLD, Registrar shall
submit complete data as required by technical specifications of the Registry System that are made available to Registrar from time to time. Registrar hereby grants
Registry Operator a non-exclusive, non-transferable, limited license to such data for propagation of and the provision of authorized access to the TLD zone files and as
otherwise required in Registry Operator's operation of the Registry TLD. 


3.6.  Security. Registrar agrees to develop and employ in its domain name registration business all necessary technology and restrictions to
ensure that its connection to the Registry System is secure. All data exchanged between Registrar's system and the Registry System shall be protected to avoid unintended disclosure of information.
Registrar agrees to employ the necessary measures to prevent its access to the Registry System granted hereunder from being used to (1) allow, enable, or otherwise support the transmission by
e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than its own existing customers; or (2) enable high volume, automated,
electronic processes that send queries or data to the systems of Registry Operator, any other registry operated under an agreement with ICANN, or any ICANN-accredited registrar, except as reasonably
necessary to register domain names or modify existing registrations. In addition, Registry Operator may require other reasonable security provisions to ensure that the Registry System is secure. 



3.7.  Resolution of Technical Problems. Registrar agrees to employ necessary employees, contractors, or agents with sufficient technical
training and experience to respond to and fix all technical problems concerning the use of the XRP and the APIs in conjunction with Registrar's systems. Registrar agrees that in the event of
significant degradation of the System or other emergency, Registry Operator may, in its sole discretion, temporarily suspend access to the System. Such temporary suspensions shall be applied in a
non-arbitrary manner and shall apply fairly to any registrar similarly situated, including affiliates of Registry Operator. 



3.8.  Time. Registrar agrees that in the event of any dispute concerning the time of the entry of a domain name registration into the
Registry Database, the time shown in the Registry records shall control. 


3.9.  Change in Registrar Sponsoring Domain Name. Registrar may assume sponsorship of a Registered Name Holder's existing domain name
registration from another registrar by following the policy set forth in Exhibit D. When transferring sponsorship of a Registered Name to or from another registrar, Registrar shall comply with
the requirements of Exhibit D. 


3.10.  Compliance with Terms and Conditions. Registrar shall comply with, and shall include in its registration agreement with each
Registered Name Holder as appropriate, all of the following: 



3.10.1.  ICANN
standards, policies, procedures, and practices for which Registry Operator has monitoring responsibility in accordance with the Registry Agreement or other arrangement with
ICANN. 


3.10.2.  Operational
standards, policies, procedures, and practices for the Registry TLD as set forth in the Registry Agreement and as established from time to time by Registry Operator in
a non-arbitrary manner and applicable to all registrars, including affiliates of Registry Operator, and consistent with ICANN's standards, policies, procedures, and practices and Registry
Operator's Registry Agreement with ICANN. Among Registry Operator's operational standards, policies, procedures, and practices are those set forth in Exhibit E. Additional or 











revised
Registry Operator operational standards, policies, procedures, and practices for the Registry TLD shall be effective upon thirty days notice by Registry Operator to Registrar. 


3.10.3  Operational
standards, policies, procedures, and practices for the IP Claim Service are set forth in Exhibit I. 




3.11.  Restrictions on Registered Names. In addition to complying with ICANN standards, policies, procedures, and practices limiting domain
names that may be registered, Registrar agrees to comply with applicable statutes and regulations limiting the domain names that may be registered. 




4.     FEES  



4.1.  Amount of Registry Operator Fees. Registrar agrees to pay Registry Operator the fees set forth in Exhibit F for initial and
renewal registrations and other services provided by Registry Operator to Registrar (collectively, "Fees"). Registry Operator reserves the right to revise the Fees prospectively upon thirty days
notice to Registrar, provided that such adjustments are consistent with Registry Operator's Registry Agreement with ICANN. As one element of the Fees, Registrar agrees to pay Registry Operator the
applicable variable fees assessed to Registry Operator by ICANN, as permitted by Subsection 3.14.5 of the Registry Agreement. 


4.2.  Payment of Registry Operator Fees. In advance of incurring Fees, Registrar shall establish a letter of credit, deposit account, or
other credit facility accepted by Registry Operator, which acceptance will not be unreasonably withheld so long as payment is assured. All Fees are due immediately upon receipt of applications for
initial and renewal registrations, or upon provision of other services provided by Registry Operator to Registrar. Payment shall be made via debit or draw down of the deposit account, letter of credit
or other credit facility. Registry Operator shall provide monthly invoices to the Registrar. 


4.3.  Non-Payment of Fees. In the event Registrar has insufficient funds deposited or available through the letter of credit or
credit facility with Registry Operator, Registry Operator may do any or all of the following: (a) stop accepting new initial or renewal registrations from Registrar; (b) delete the
domain names associated with any negative balance incurred from the Registry database; and (c) pursue any other remedy under this Agreement. 



4.4.  Parity of ICANN Support Fees. Registry Operator may pay Variable Registry-Level Fees to ICANN under Subsection 3.14.2 of its Registry
Agreement with ICANN. In consideration of Registry-Operator's payment of these fees, Registrar provides the following assurance of parity of support of ICANN among TLDs: For any period in which
(a) Registry Operator pays ICANN Variable Registry-Level Fees for the Registry TLD; (b) Registrar is not required to pay ICANN an on-going component of registrar
accreditation fees for accreditation as a registrar in the Registry TLD; (c) the Registry Operator for the.com,.net, and.org is not obligated by its Registry Agreement with ICANN to pay ICANN
Variable Registry-Level Fees; and (d) Registrar is accredited by ICANN as a registrar in the.com,.net, and.org TLDs, Registrar hereby gives its express approval of an on-going
component of its Registrar accreditation fees for.com,.net, and.org TLDs that is equivalent, on a per-name basis, to the Variable Registry-Level Fee paid by Registry Operator to ICANN with
respect to the Registry TLD. 




5.     CONFIDENTIALITY AND INTELLECTUAL PROPERTY  



5.1.  Use of Confidential Information. During the Term of this Agreement, each party (the "Disclosing Party") may be required to disclose
its Confidential Information to the other Party (the "Receiving Party"). Each party's use and disclosure of the Confidential Information of the other party shall be subject to the following terms and
conditions: 



5.1.1.  The
Receiving Party shall treat as strictly confidential, and use all reasonable efforts to preserve the secrecy and confidentiality of, all Confidential Information of the
Disclosing Party, including implementing reasonable physical security measures and operating procedures. 

















5.1.2.  The
Receiving Party agrees that it will use any Confidential Information of the Disclosing Party solely for the purpose of exercising its right or performing its obligations under
this Agreement and for no other purposes whatsoever. 


5.1.3.  The
Receiving Party shall make no disclosures whatsoever of any Confidential Information of the Disclosing Party to others; provided, however, that if the Receiving Party is a
corporation, partnership, or similar entity, disclosure is permitted to the Receiving Party's officers, employees, contractors and agents who have a demonstrable need to know such Confidential
Information, provided the Receiving Party shall advise such personnel of the confidential nature of the Confidential Information and of the procedures required to maintain the confidentiality thereof,
and shall require them to acknowledge in writing that they have read, understand, and agree to be individually bound by the confidentiality terms of this Agreement. 



5.1.4.  The
Receiving Party shall not modify or remove any confidentiality legends and/or copyright notices appearing on any Confidential Information of the Disclosing Party. 


5.1.5.  The
Receiving Party agrees not to prepare any derivative works based on the Confidential Information. 


5.1.6.  Notwithstanding
the foregoing, this Subsection 5.1 imposes no obligation upon the parties with respect to information that (a) is disclosed with the Disclosing Party's prior
written approval; or (b) is or has entered the public domain through no fault of the Receiving Party; or (c) is known by the Receiving Party prior to the time of disclosure; or
(d) is independently developed by the Receiving Party without use of the Confidential Information; or (e) is made generally available by the Disclosing Party without restriction on
disclosure. 


5.1.7.  In
the event the Receiving Party is required by law, regulation or court order to disclose any of Disclosing Party's Confidential Information, Receiving Party will promptly notify
Disclosing Party in writing prior to making any such disclosure in order to facilitate Disclosing Party seeking a protective order or other appropriate remedy from the proper authority, at the
Disclosing Party's expense. Receiving Party agrees to cooperate with Disclosing Party in seeking such order or other remedy. Receiving Party further agrees that if Disclosing Party is not successful
in precluding the requesting legal body from requiring the disclosure of the Confidential Information, it will furnish only that portion of the Confidential Information which is legally required. 


5.1.8.  The
Receiving Party's duties under this Subsection 5.1 shall expire five (5) years after the information is received or earlier, upon written agreement of the parties. 




5.2.  Intellectual Property.  



5.2.1.  Subject
to Subsection 3.5, each party will continue to independently own its intellectual property, including all patents, trademarks, trade names, service marks, copyrights, trade
secrets, proprietary processes and all other forms of intellectual property. In addition, Registry Operator, or its suppliers and/or licensees, shall own all right, title and interest in and to the
XRP, APIs, Registrar Tool Kits, and any software incorporated into the Registry System, as well as all intellectual property appurtenant thereto. 


5.2.2.  Without
limiting the generality of the foregoing, no commercial use rights or any licenses under any patent, patent application, copyright, trademark, know-how, trade
secret, or any other intellectual proprietary rights are granted by the Disclosing Party to the Receiving Party by this Agreement, or by any disclosure of any Confidential Information to the Receiving
Party under this Agreement. 
















6.     INDEMNITIES AND LIMITATION OF LIABILITY  



6.1.  Indemnification. Registrar, at its own expense and within thirty days after presentation of a demand by Registry Operator under this
Section, will indemnify, defend and hold harmless Registry Operator and its employees, directors, officers, representatives, agents and affiliates, against any claim, suit, action, or other proceeding
brought against Registry Operator or any affiliate of Registry Operator based on or arising from any claim or alleged claim: (i) relating to any product or service of Registrar;
(ii) relating to any agreement, including Registrar's dispute policy, with any Registered Name Holder of Registrar; or (iii) relating to Registrar's domain name registration business,
including, but not limited to, Registrar's advertising, domain name application process, systems and other processes, fees charged, billing practices and customer service; provided, however, that in
any such case: (a) Registry Operator provides Registrar with prompt notice of any such claim, and (b) upon Registrar's written request, Registry Operator will provide to Registrar all
available information and assistance reasonably necessary for Registrar to defend such claim, provided that Registrar reimburses Registry Operator for its actual and reasonable costs incurred in
connection with providing such information and assistance. Registrar will not enter into any settlement or compromise of any such indemnifiable claim without Registry Operator's prior written consent,
which consent shall not be unreasonably withheld. Registrar will pay any and all costs, damages, and expenses, including, but not limited to, reasonable attorneys' fees and costs awarded against or
otherwise incurred by Registry Operator in connection with or arising from any such indemnifiable claim, suit, action or proceeding. 


6.2.  Limitation of Liability. EXCEPT AS PROVIDED IN SUBSECTION 6.3 BELOW, IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR ANY SPECIAL,
INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES FOR ANY VIOLATIONS OF THIS AGREEMENT. 


6.3.  Performance Credits. In the event Registry Operator fails to meet the performance specifications set forth in Exhibit G of this
Agreement, Registry Operator shall provide a credit to Registrar in an amount equal to its proportionate share of applicable performance credits set forth in Exhibit H to this Agreement. Such
performance credits shall constitute the sole and exclusive remedy available to Registrar with regard to Registry Operator's failure to meet the performance specifications. 




7.     DISPUTE RESOLUTION  



7.1.  Dispute Resolution. Disputes arising under or in connection with this Agreement, including requests for specific performance, shall be
resolved through binding arbitration conducted as provided in this Section pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce ("ICC"). The
arbitration shall be conducted in the English language and shall occur in the Commonwealth of Virginia, USA. There shall be three arbitrators: each party shall choose one arbitrator and, if the two
arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The parties shall bear the costs of the arbitration in equal shares, subject to the right of the
arbitrators to reallocate the costs in their award as provided in the ICC rules. The parties shall bear their own attorneys' fees in connection with the arbitration, and the arbitrators may not
reallocate the attorneys' fees in conjunction with their award. The arbitrators shall render their decision within ninety days of the initiation of arbitration. Any litigation brought to enforce an
arbitration award shall be brought in a Commonwealth or federal court in the eastern district of the Commonwealth of Virginia, USA; however, the parties shall also have the right to enforce a judgment
of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of a Party during the pendency of an arbitration, each Party shall have
the right to seek temporary or preliminary injunctive relief from the arbitration panel or a court located in the Eastern District of the Commonwealth of Virginia, USA, which shall not be a waiver of
this arbitration agreement. 









8.     TERM AND TERMINATION  



8.1.  Term of the Agreement; Revisions. The Term of this Agreement shall commence on the Effective Date and, unless earlier terminated in
accordance with the provisions of this Agreement, shall expire on the expiration of the Registry Agreement. In the event that revisions to Registry Operator's approved form of Registry-Registrar
Agreement are approved or adopted by ICANN, Registrar will either execute an amendment substituting the revised agreement in place of this Agreement or, at its option exercised within fifteen days
after receiving notice of such amendment, terminate this Agreement immediately by giving written notice to Registry Operator. In the event that Registry Operator does not receive such executed
amendment or notice of termination from Registrar within such fifteen day period, Registrar shall be deemed to have terminated this Agreement effective immediately. 


8.2.  Termination. This Agreement may be terminated as follows: 



8.2.1.  Termination
For Cause. In the event that either party materially breaches any of its obligations under this Agreement and such breach is not substantially cured within thirty
calendar days after written notice thereof is given by the other party, then the non-breaching party may, by giving written notice thereof to the other party, terminate this Agreement as
of the date specified in such notice of termination. 


8.2.2.  Termination
at Option of Registrar. Registrar may terminate this Agreement at any time by giving Registry Operator thirty days notice of termination. 


8.2.3.  Termination
Upon Loss of Registrar's Accreditation. This Agreement shall terminate in the event Registrar's accreditation by ICANN is terminated or expires without renewal. 



8.2.4.  Termination
in the Event of Termination of Registry Agreement. This Agreement shall terminate in the event that Registry Operator's Registry Agreement with ICANN is terminated or
expires without entry of a subsequent Registry Agreement with ICANN and this Agreement is not assigned under Subsection 9.1.1. 


8.2.5.  Termination
in the Event of Insolvency or Bankruptcy. Either party may terminate this Agreement if the other party is adjudged insolvent or bankrupt, or if proceedings are
instituted by or against a party seeking relief, reorganization or arrangement under any laws relating to insolvency, or seeking
any assignment for the benefit of creditors, or seeking the appointment of a receiver, liquidator or trustee of a party's property or assets or the liquidation, dissolution or winding up of a party's
business. 




8.3.  Effect of Termination. Upon the expiration or termination of this Agreement for any reason: 



8.3.1.  Registry
Operator will complete the registration of all domain names processed by Registrar prior to the effective date of such expiration or termination, provided that Registrar's
payments to Registry Operator for Fees are current and timely. 


8.3.2.  Registrar
shall immediately transfer its sponsorship of Registered Names to another ICANN-accredited registrar in compliance with any procedures established or approved by ICANN. 



8.3.3.  All
Confidential Information of the Disclosing Party in the possession of the Receiving Party shall be immediately returned to the Disclosing Party. 


8.3.4.  All
fees owing to Registry Operator shall become immediately due and payable. 




8.4.  Survival. In the event of termination of this Agreement, the following shall survive: (i) Subsections 2.6, 3.5, 5.1, 5.2, 6.1,
6.2, 7.1, 8.3.3, 8.3.4, 8.4, 9.2, 9.3.3, 9.5, 9.6, 9.8, 9.9, 9.10, 9.11 and 9.13 and (ii) the Registered Name Holder's indemnification obligation under Subsection 3.4. Neither party shall be
liable to the other for damages of any sort resulting solely from terminating this Agreement in accordance with its terms. 









9.     MISCELLANEOUS  



9.1.  Assignments.  



9.1.1.  Assignment to Successor Registry Operator. In the event the Registry Operator's Registry Agreement is terminated (and such
termination is deemed final under the Registry Agreement) or expires without entry by Registry Operator and ICANN of a subsequent registry agreement, Registry Operator's rights under this Agreement
may be assigned to a company with a subsequent registry agreement covering the Registry TLD upon ICANN's giving Registrar written notice within sixty days of the termination or expiration, provided
that the subsequent registry operator assumes the duties of Registry Operator under this Agreement. 


9.1.2.  Assignment in Connection with Assignment of Agreement with ICANN. In the event that Registry Operator's Registry Agreement with
ICANN for the Registry TLD is validly assigned, Registry Operator's rights under this Agreement shall be automatically assigned to the assignee of the Registry Agreement, provided that the assignee
assumes the duties of Registry Operator under this Agreement. In the event that Registrar's accreditation agreement with ICANN for the Registry TLD is validly assigned, Registrar's rights under this
Agreement shall be automatically assigned to the assignee of the accreditation agreement, provided that the subsequent registrar assumes the duties of Registrar under this Agreement. 


9.1.3.  Other Assignments. Except as otherwise expressly provided in this Agreement, the provisions of this Agreement shall inure to the
benefit of and be binding upon, the successors and permitted assigns of the parties. Neither party shall assign or transfer its rights or obligations under this Agreement without the prior written
consent of the other party, which shall not be unreasonably withheld. 




9.2.  Notices. Any notice or other communication required or permitted to be delivered to any party under this Agreement shall be in writing
and shall be deemed properly delivered, given and received when delivered (by hand, by registered mail, by courier or express delivery service, by e-mail or by telecopier during business
hours) to the address or telecopier number set forth beneath the name of such party below, unless party has given a notice of a change of address in writing: 



If
to Registrar: 


with
copy to: 


If
to Registry Operator: 



NeuLevel, Inc.

Loundoun Tech Center

45980 Center Oak Plaza

Sterling, VA 20166

Attn: VP of Policy and Industry Relations 




with
a copy to: 



NeuLevel, Inc.

Loundoun Tech Center

45980 Center Oak Plaza

Sterling, VA 20166

Attn: General Counsel 





9.3.  Representations and Warranties.  



9.3.1.  Registrar. Registrar represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good
standing under the law of the                        , (2) it has all requisite corporate power and authority to execute,
deliver and perform its obligations 











under
this Agreement, (3) it is, and during the Term of this Agreement will continue to be, accredited by ICANN or its successor, (4) the execution, performance and delivery of this
Agreement has been duly authorized by Registrar, (5) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by Registrar in
order for it to enter into and perform its obligations under this Agreement. 


9.3.2.  Registry Operator. Registry Operator represents and warrants that: (1) it is a corporation duly incorporated, validly
existing and in good standing under the laws of the State of Delaware, (2) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this
Agreement, (3) the execution, performance and delivery of this Agreement has been duly authorized by Registry Operator, and (4) no further approval, authorization or consent of any
governmental or regulatory authority is required to be obtained or made by Registry Operator in order for it to enter into and perform its obligations under this Agreement. 


9.3.3.  Disclaimer of Warranties. THE XRP, APIs, REGISTRAR TOOLKITS, REGISTRY SYSTEM AND ANY COMPONENT THEREOF ARE PROVIDED
"AS-IS" AND WITHOUT ANY WARRANTY OF ANY KIND. REGISTRY OPERATOR EXPRESSLY DISCLAIMS ALL
WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY OR SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE
AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. REGISTRY OPERATOR DOES NOT WARRANT THAT THE XRP, APIs, REGISTRAR TOOLKITS, REGISTRY SYSTEM OR ANY COMPONENT THEREOF WILL MEET REGISTRAR'S REQUIREMENTS, OR
THAT THE OPERATION OF XRP, APIs, REGISTRAR TOOLKITS, THE REGISTRY SYSTEM OR ANY COMPONENT THEREOF WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE XRP, APIs, REGISTRAR TOOLKITS,
REGISTRY SYSTEM OR ANY COMPONENT THEREOF WILL BE CORRECTED. FURTHERMORE, REGISTRY OPERATOR DOES NOT WARRANT NOR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE XRP, APIs, REGISTRAR
TOOLKITS, REGISTRY SYSTEM OR ANY COMPONENT THEREOF OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. SHOULD THE XRP, APIs, REGISTRAR TOOLKITS, THE REGISTRY
SYSTEM OR ANY COMPONENT THEREOF PROVE DEFECTIVE, REGISTRAR ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION OF REGISTRAR'S OWN SYSTEMS AND SOFTWARE. 




9.4.  Insurance. During the Term of this Agreement, and any renewal Terms, Registrar shall have in place US $1,000,000 in comprehensive
legal liability insurance from a reputable insurance provider with an A.M. Best rating of "A" or better. Such Insurance shall be used to indemnify and hold harmless Registry Operator and its
employees, directors, officers, representatives, agents and affiliates from all costs and damages (including reasonable attorneys' fees) which it may suffer by reason of Registrar's failure to
indemnify Registry Operator as provided above. Registrar shall provide a copy of the insurance policy to Registry Operator upon Registry Operator's reasonable request. 


9.5.  Third-Party Beneficiaries. The Parties expressly agree that ICANN is an intended third-party beneficiary of this Agreement. Otherwise,
this Agreement shall not be construed to create any obligation by either party to any non-party to this Agreement, including any holder of a Registered Name. Registrar acknowledges that
nothing in this Agreement shall confer upon Registrar the status of an intended third-party beneficiary to the Registry Agreement. 


9.6.  Relationship of the Parties. Nothing in this Agreement shall be construed as creating an employer-employee or agency relationship, a
partnership or a joint venture between the parties. 












9.7.  Force Majeure. Neither party shall be liable to the other for any loss or damage resulting from any cause beyond its reasonable
control (a "Force Majeure Event") including, but not limited to, insurrection or civil disorder, war or military operations, national or local emergency, acts or omissions of government or other
competent authority, compliance with any statutory obligation or executive order, industrial disputes of any kind (whether or not involving either party's employees), fire, lightning, explosion,
flood, subsidence, weather of exceptional severity, equipment or facilities shortages which are
being experienced by providers of telecommunications services generally, or other similar force beyond such Party's reasonable control, and acts or omissions of persons for whom neither party is
responsible. Upon occurrence of a Force Majeure Event and to the extent such occurrence interferes with either party's performance of this Agreement, such party shall be excused from performance of
its obligations (other than payment obligations) during the first six months of such interference, provided that such party uses best efforts to avoid or remove such causes of nonperformance as soon
as possible. 


9.8.  Amendments. Except as otherwise provided herein, no amendment, supplement, or modification of this Agreement or any provision hereof
shall be binding unless executed in writing by both parties. 


9.9.  Waivers. No failure on the part of either party to exercise any power, right, privilege or remedy under this Agreement, and no delay
on the part of either party in exercising any power, right, privilege or remedy under this Agreement, shall operate as a waiver of such power, right, privilege or remedy; and no single or partial
exercise or waiver of any such power, right, privilege or remedy shall preclude any other or further exercise thereof or of any other power, right, privilege or remedy. Neither party shall be deemed
to have waived any claim arising out of this Agreement, or any power, right, privilege or remedy under this Agreement, unless the waiver of such claim, power, right, privilege or remedy is expressly
set forth in a written instrument duly executed and delivered on behalf of such party; and any such waiver shall not be applicable or have any effect except in the specific instance in which it is
given. 


9.10.  Attorneys' Fees. If any legal action or other legal proceeding (including arbitration) relating to the performance under this
Agreement or the enforcement of any provision of this Agreement is brought against either Party hereto, the prevailing Party shall be entitled to recover reasonable attorneys' fees, costs and
disbursements (in addition to any other relief to which the prevailing Party may be entitled). 


9.11.  Construction. The Parties agree that any rule of construction to the effect that ambiguities are to be resolved against the drafting
party shall not be applied in the construction or interpretation of this Agreement. 


9.12.  Further Assurances. Each party hereto shall execute and/or cause to be delivered to each other Party hereto such instruments and
other documents, and shall take such other actions, as such other Party may reasonably request for the purpose of carrying out or evidencing any of the transactions contemplated by this Agreement. 


9.13.  Entire Agreement. This Agreement (including its exhibits, which form a part of it) constitutes the entire agreement between
the parties concerning the subject matter of this Agreement and supersedes any prior agreements, representations, statements, negotiations, understandings, proposals or undertakings, oral or written,
with respect to the subject matter expressly set forth herein. 


9.14.  Counterparts. This Agreement may be executed in one or more counterparts, each of which shall be deemed an original, but all of which
together shall constitute one and the same instrument. 













IN
WITNESS WHEREOF, the parties hereto have executed this Agreement as of the date set forth in the first paragraph hereof. 



	NeuLevel, Inc.	 	[Registrar]
	 	 	 	 	 
	 	 	 	 	 
	By:	 	 	By:	 
	Name:	 	 	Name:	 
	Title:	 	 	Title:	 









 
 

Exhibit A
  Registrar Tool Kits    
    



Registry-Registrar
Software Development Kit includes: 


1.     Software Development Kit for Domain Name Application Service  



	•
	Secure
ftp client



	•
	Reference
client implementation:



	•
	TCL



	•
	Interface
definition:



	•
	ABNF



	•
	XML
schema



	•
	Registry
Operational Profile (our extensions)



	•
	Authentication
and Encryption guidelines 




2.     Software Development Kit for Registry Live  



	•
	Reference
client implementations:



	•
	Java



	•
	Language
bindings



	•
	Interface
Definition Language (IDL)






	•
	Interface
definition:



	•
	ABNF



	•
	XML
schema






	•
	Registry
Operational Profile (our extensions)



	•
	Authentication
and Encryption guidelines



	•
	Epp
"feature freeze" drafts



	•
	Epp
test plan and coverage matrix



	•
	Java,
API documentation 












 
 

Exhibit B
  Engineering and Customer Service Support    
    


During
the Term of this Agreement, Registry Operator will provide reasonable telephone and electronic customer support to Registrar, not Registered Name holders or prospective customers of Registrar,
for non-technical issues solely relating to the Registry System and its operation. Registry Operator will provide Registrar with a telephone number and e-mail address for such
support during implementation of the XRP, APIs and Software. While e-mail and FAQs are the primary method of help, Registry Operator will provide support on a
7-day/24-hour basis. Registry Operator will provide a web-based customer service capability in the future and such web-based support will become the
primary method of customer service support to Registrar at such time. 


The
Registry Operator provides a clear, concise and efficient deliberation of customer support responsibilities. Registrars provide support to registrants and registries provide support for
Registrars. This allows the Registry to focus its support on the highly technical and administratively complex issues that arise between the Registry and the Registrar. 


Technical Help Systems  


NeuLevel
will provide the Registrars with the following types of technical support: 



	•
	Web-based
self-help services, including:



	•
	Knowledge
bases



	•
	Frequently
asked questions



	•
	White
papers



	•
	Downloads
of XRP client software



	•
	Support
for email messaging






	•
	Telephone
support from our central Help Desk



	•
	Fee-based
consulting services. 




Web Portal  


Registry
Operator will implement a secure Web-based multimedia portal to help support registrar operations. To obtain access to our Web-based services, a registrar must
register his registrants with us, and must have implemented our security features, including SSL encryption, log in with user ID and password, and digital certificates for authentication. The home
page of the web portal will include a notice to registrars of planned outages for database maintenance or installation of software upgrades. This notification will be posted 30 days prior to
the event in addition to active notification including phone calls and email. We will also record outage notifications in the help desk database to facilitate compliance with the service-level
agreement. Finally, seven days and again two days prior to the scheduled event, we will use both an email and a Web-based notification to remind registrars of the outage. 


Non-affiliated
registrars and the general Internet community may obtain generic information from NeuLevel's public Web site, which will describe our TLD service offerings and list
ICANN-certified registrars providing domain-name services. 










Central Help Desk  


In
addition to implementing the Web site, we will provide telephone support to our registrars through our central Help Desk. Access to the help desk telephone support is through an automatic call
distributor that routes each call to the next available customer support specialist. We will authenticate callers by using caller ID and by requesting a pre-established pass phrase that is
different for each registrar. Requests for assistance may also come to the Help Desk via email, either directly or via the secure Web site. The Help Desk's three tiers of support are: 



Tier-1
Support. Telephone support to registrars who normally are calling for help with customer domain-name problems and such other issues such as XRP implementation or billing
and collection. Problems that can't be resolved at Tier 1 are escalated to Tier 2. 


Tier-2
Support. Support provided by members of the technical support team, who are functional experts in all aspects of domain-name registration. In addition to resolving
escalated Tier 1 problems with XRP implementation and billing and collection, Tier 2 staff provides technical support in system tuning and workload processing. 



Tier
3 Support. Complex problem resolution provided by on-site maintenance technicians, third party systems and software experts, and vendors, depending on the nature of the problem. 




In
turn, the Help Desk uses an automated software package to collect call statistics and record service requests and trouble tickets in a help desk database. The help desk database documents the
status of requests and tickets, and notifies the Help Desk when an SLA threshold is close to being breached. Each customer-support and technical support specialist uses our problem management process
to respond to trouble tickets with a troubleshooting, diagnosis, and resolution procedure and a root-cause analysis. 


Escalation Policy  


Our
escalation policy defines procedures and timelines for elevating problems either to functional experts or to management for resolution if they not resolved within the escalation-policy time
limits. The following table is an overview of our escalation policy. 



	Level
	 	Description
	 	Escalation Policy
	 	Notification

	I	 	Catastrophic outage affecting overall registry operations	 	Data-center manager escalates to NeuLevel management and Disaster-Recovery Team if not resolved in 15 minutes	 	Web portal and e-mail notifications to all Registrars within 15 minutes; updates every 30 minutes
	

II	
 	

Systems outage affecting one or two registrar sessions but not the entire system	
 	

Systems engineer escalates to data-center manager if not resolved in one hour	
 	

Web-portal notification to all registrars; hourly updates
	

III	
 	

Technical questions	
 	

Help Desk customer-support specialist escalates to the systems engineer if not resolved in two hours	
 	

Hourly updates to registrar via e-mail
	

IV	
 	

Basic questions	
 	

Help Desk customer-support specialist escalates to the systems engineer if not resolved within four hours	
 	

Hourly updates to registrar via e-mail










Staffing  


Initially,
Registry Operator will staff its Help Desk with a complement of customer service specialists. We will add staff as necessary to respond to incoming requests within the service-level
agreement.
Customer-service specialists will obtain assistance from Registry Operator's technical staff for any problems that cannot be resolved in one phone call. 


Test and Evaluation Facility  


Registry
Operator will establish an operational test-and-evaluation facility that will be available for Registrars to test their client XRP system. Our technical-support team,
which consists of functional experts in the processes and technologies for domain-name registration, will support the registrars' testing. 


Once
each new Registrar is satisfied that its system is compatible with the registry system, it will schedule a formal acceptance test that will be monitored by our system engineer. After a
registrar has passed the acceptance test, we will issue its user id, passwords, and digital certificates, and the Registrar can begin operations. 


Customer Satisfaction Survey  


To
determine Registrars' satisfaction with Registry Services, Registry Operator will implement a Web-based customer-satisfaction survey that will consist of a set of survey questions with
responses ranging from one to five on the Likert Scale. We will tabulate the results and publish them on the Web site. 



To
further verify the quality of our customer services, Registry Operator will commission a biannual customer-satisfaction survey by an independent third party. 


 
 

Exhibit C
  Registrar's Registration Agreement
  [To be supplied by Registrar]    



 
 

Exhibit D
  Policy on Transfer of Sponsorship of
  Registrations Between Registrars    
    


A. Holder-Authorized Transfers.  


Registrar Requirements.  


The
registration agreement between each Registrar and its Registered Name Holder shall include a provision explaining that a Registered Name Holder will be prohibited from changing its Registrar
during the first 60 days after initial registration of the domain name with the Registrar. Beginning on the 61st day after the initial registration with the Registrar, the procedures for change
in sponsoring registrar set forth in this policy shall apply. Enforcement shall be the responsibility of the Registrar sponsoring the domain name registration. 


For
each instance where a Registered Name Holder wants to change its Registrar for an existing domain name (i.e., a domain name that appears in a particular top-level domain zone file),
the gaining Registrar shall: 



1)  Obtain
express authorization from an individual who has the apparent authority to legally bind the Registered Name Holder (as reflected in the database of the losing Registrar). 



a)  The
form of the authorization is at the discretion of each gaining Registrar. 


b)  The
gaining Registrar shall retain a record of reliable evidence of the authorization. 















2)  In
those instances when the Registrar of record is being changed simultaneously with a transfer of a domain name from one party to another, the gaining Registrar shall also obtain
appropriate authorization for the transfer. Such authorization shall include, but not be limited to, one of the following: 



a)  A
bilateral agreement between the parties. 


b)  The
final determination of a binding dispute resolution body. 


c)  A
court order. 




3)  Request,
by the transmission of a "transfer" command as specified in the XRP, that the Registry database be changed to reflect the new Registrar. 



a)  Transmission
of a "transfer" command constitutes a representation on the part of the gaining Registrar that: 



(1)  the
requisite authorization has been obtained from the Registered Name Holder listed in the database of the losing Registrar, and 


(2)  the
losing Registrar will be provided with a copy of the authorization if and when requested. 






In
those instances when the Registrar of record denies the requested change of Registrar, the Registrar of record shall notify the prospective gaining Registrar that the request was denied and the
reason for the denial. 


Instances
when the requested change of sponsoring Registrar may be denied include, but are not limited to: 



1)  Situations
described in the Domain Name Dispute Resolution Policy 


2)  A
pending bankruptcy of the Registered Name Holder 


3)  Dispute
over the identity of the Registered Name Holder 


4)  Request
to transfer sponsorship occurs within the first 60 days after the initial registration with the Registrar 




In
all cases, the losing Registrar shall respond to the electronic notice regarding the "transfer" request within five (5) days. Failure to respond will result in a default "approval" of the
"transfer." 


Registry Requirements.  


Upon
receipt of the "transfer" command from the gaining Registrar, Registry Operator will transmit an electronic notification to both Registrars. 



Registry
Operator shall complete the "transfer" if either: 



1)  the
losing Registrar expressly "approves" the request, or 


2)  Registry
Operator does not receive a response from the losing Registrar within five (5) days. 




When
the Registry's database has been updated to reflect the change to the gaining Registrar, Registry Operator will transmit an electronic notification to both Registrars. 



Records of Registration.  


Each
Registered Name Holder shall maintain its own records appropriate to document and prove the initial domain name registration date, regardless of the number of Registrars with which the Registered
Name Holder enters into a contract for registration services. 


Effect
on Term of Registration. 










The
completion by Registry Operator of a holder-authorized transfer under this Part A shall result in a one-year extension of the existing registration, provided that in no event
shall the total unexpired term of a registration exceed ten (10) years. 


B.    ICANN-Approved Transfers.  


Transfer
of the sponsorship of all the registrations sponsored by one registrar as the result of acquisition of that Registrar or its assets by another Registrar may be made according to the following
procedure: 




(a)  The
gaining Registrar must be accredited by ICANN for the Registry TLD and must have in effect a Registry-Registrar Agreement with Registry Operator for the Registry TLD. 



(b)  ICANN
must certify in writing to Registry Operator that the transfer would promote the community interest, such as the interest in stability that may be threatened by the actual or
imminent business failure of a Registrar. 





Upon
satisfaction of these two conditions, Registry Operator will make the necessary one-time changes in the registry database for no charge, for transfers involving 50,000 name
registrations or fewer; provided that the data to be transferred to Registry Operator is in the form specified by Registry Operator as may be reasonably approved by ICANN ("Approved Format"). If the
transfer involves registrations of more than 50,000 names, and the data to be transferred to Registry Operator is in the Approved Format, Registry Operator will charge the gaining registrar a
one-time flat fee of US$ 50,000. If the data to be transferred is not in the Approved Format, the Registry Operator may charge a reasonable fee in connection with the costs associated with
reformatting such data. 


 
 

Exhibit E
  Registry Operator's Operational Standards, Policies, Procedures and Practices    
    



I.     Registration Requirements  


Before
the Registry Operator will accept applications for registration from Registrar, all domain name applicants in the.biz TLD ("Applicants") must: 



1.  Enter
into an electronic or paper registration agreement with the Registrar ("Registrar"), in accordance with the ICANN Registrar Accreditation Agreement ("Accreditation Agreement")
and this Agreement. Such electronic or paper registration agreement shall include, at a minimum, the following certifications: 



a)  The
data provided in the domain name registration application is true, correct, up to date and complete; and 


b)  The
registrant will keep the information provided above up to date. 




2.  Certify
in the Registration Agreement that to the best of its knowledge: 



a)  The
registered domain name will be used primarily for bona fide business or commercial purposes and not (i) exclusively for personal use; or (ii) solely for the purposes
of (1) selling, trading or leasing the domain name for compensation, or (2) the unsolicited offering to sell, trade or lease the domain name for compensation. 



b)  The
domain name registrant has the authority to enter into the registration agreement; and 


c)  The
registered domain name is reasonably related to the registrant's business or intended commercial purpose at the time of registration. 
















II.    Incorporation of.Biz Dispute Resolution Services  


In
addition, Registrar agrees to incorporate the following text (or translation of such text into relevant language) into their Registration Agreement: 


"The
Registrant acknowledges having read and understood and agrees to be bound by the terms and conditions of the following documents, as they may be amended from time to time, which are hereby
incorporated and made an integral part of this Agreement: 



(i)  The
Uniform Domain Name Dispute Resolution Policy, available at <URL>; 



(ii)  The
Start-up Dispute Resolution Policy ("SUDRP"), available at <URL>; and 


(iii)  The
Restrictions Dispute Resolution Criteria and Rules, available at <URL>." 




The
SUDRP sets forth the terms and conditions in connection with a dispute between a registrant of a.biz domain name ("Registrant") with any third party (other than Registry Operator or Registrar)
over the registration or use of a.biz domain name registered by Registrant that is subject to the Start-up Intellectual Property Notification Service ("SIPNS"). SIPNS is a service
introduced by Registry Operator to notify a trademark or service mark holder ("Claimant") that a second-level domain name has been registered in which that Claimant claims intellectual property
rights. In accordance with the SUDRP and its associated Rules, those Claimants will have the right to challenge registrations through independent ICANN-accredited dispute resolution providers. 


The
UDRP sets forth the terms and conditions in connection with a dispute between a Registrant and any party other than the Registry Operator or Registrar over the registration and use of an Internet
domain name registered by Registrant. 


The
RDRP sets forth the terms under which any allegation that a domain name is not used primarily for business or commercial purposes shall be enforced on a case-by-case, fact
specific basis by an independent ICANN-accredited dispute provider. None of the violations of the Restrictions will be enforced directly by or through Registry Operator. Registry Operator will not
review, monitor, or otherwise verify that any particular domain name is being used primarily for business or commercial purposes or that a domain name is being used in compliance with the SUDRP or
UDRP processes. 


III.  Reservation  


        Registry Operator reserves the right to deny, cancel or transfer any registration that it deems necessary, in its discretion; (1) to protect the integrity
and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, in compliance with any dispute resolution process;
(3) to avoid any liability, civil or criminal, on the part of Registry Operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) for violations of this
Agreement and its Exhibits; or (5) to correct mistakes made by Registry Operator or any Registrar in connection with a domain name registration. Registry Operator also reserves the right to
freeze a domain name during resolution of a dispute. 


 
 

Exhibit F
  Registration Fees    
    



	•
	Domain
Name Application Fees (Phase 1). Registrar agrees to pay the non-refundable amounts as set forth below: 



US
$2.00 Per Domain Name Application Submission 












	•
	Initial
Registration. Registrar agrees to pay the non-refundable amounts as set forth below: 







	Initial Registration Fee

(Per Domain Name)
	 	Volume Range

(Number of Registered Names)

	US $5.30	 	0 to 4,999,999
	US $5.00	 	5,000,000 to 9,999,999
	US $4.75	 	10,000,000 +






	•
	Renewal
Fees. Registrar agrees to pay the non-refundable amounts as set forth below: 







	Renewal Fee

(Per Domain Name)
	 	Volume Range

(Number of Registered Names)

	US $5.30	 	0 to 4,999,999
	US $5.00	 	5,000,000 to 9,999,999
	US $4.75	 	10,000,000 +






	•
	Secure
Domain Name Registration Service. Registrar agrees to pay the non-refundable amounts as set forth below: 





US
$500.00 Per Secure Domain Name Registration 



	•
	Fees
for Transfers of Sponsorship of Domain-Name Registrations 





Where
the sponsorship of a domain name is transferred from an ICANN-Accredited Registrar to another ICANN-Accredited Registrar, other than an ICANN approved bulk transfer, Registry Operator may
require the registrar receiving the sponsorship to request a renewal of one year for the name. In connection with that extension, Registry Operator may charge a Renewal Fee for the requested extension
as provided in the renewal schedule set forth above. The transfer shall result in an extension according to the renewal request, subject to a ten-year maximum on the future term of any
domain-name registration. The Renewal Fee shall be paid in full at the time of the transfer by the ICANN-Accredited Registrar receiving sponsorship of the domain name. 


For
a bulk transfer approved by ICANN under Part B of Exhibit D to the Registry-Registrar Agreement, Registry Operator will charge the gaining registrar US $0 (for transfers of 50,000
names or fewer) or US$50,000 (for transfers of more than 50,000 names). 



	•
	Enhanced
Whois Service. Registrar agrees to pay the non-refundable amounts as set forth below: 





To
be provided with at least 30 days advance notice: Yearly Subscription Fee Rate, One time Usage Fee 





Registry
Operator reserves the right to revise the Fees prospectively upon thirty days notice to Registrar, provided that such adjustments are consistent with Registry Operator's Registry Agreement
with ICANN. 


 
 

Exhibit G
  Performance Specifications    
    


1.  Introduction. The attached Performance Specification Matrix ("Matrix") provides a list of performance specifications as they apply to
the three Core Services provided by the Registry—SRS, Nameserver, and Whois services. 


2.  Definitions. Capitalized terms used herein and not otherwise defined shall have the meaning ascribed to them in the Registry-Registrar
Agreement. 



2.1  "Core
Services" refers to the three core services provided by the Registry—SRS, Nameserver, and Whois Services. 









2.2  "Performance
Specification" refers to the specific committed performance service levels as specified herein. 


2.3  "Performance
Specification Priority" refers to the Registry's rating system for Performance Specifications. Some Performance Specifications are more critical to the operations of the
Registry than
others. Each of the Performance Specifications is rated as C1-mission critical, C2-mission important, C3-mission beneficial, or C4-mission maintenance. 


2.4  "Registrar
Community" refers to all the ICANN-Accredited Registrars accredited by ICANN who have executed Registry-Registrar Agreements with Registry Operator for the Registry TLD. 


2.5  "SRS"
refers to the Shared Registration System; the service that the Registry provides to the Registrar Community. Specifically, it refers to the ability of Registrars to add, modify,
and delete information associated with domain names, nameserver, contacts, and registrar profile information. This service is provided by systems and software maintained in coactive redundant data
centers. The service is available to approved Registrars via an Internet connection. 


2.6  "Nameserver"
refers to the nameserver function of the Registry and the nameservers that resolve DNS queries from Internet users. This service is performed by multiple nameserver sites
that host DNS resource records. The customers of the nameserver service are users of the Internet. The nameservers receive a DNS query, resolve it to the appropriate address, and provide a response. 



2.7  "Service
Level Measurement Period" refers to the period of time for which a Performance Specification is measured. Monthly periods are based on calendar months, quarterly periods are
based on calendar quarters, and annual periods are based on calendar years. 


2.8  "Whois"
refers to the Registry's Whois service. The Registry will provide contact information related to registered domain names and nameserver through a Whois service. Any person
with access to the Internet can query the Registry's Whois service directly (via the Registry website) or through a Registrar. 




3.  Performance Specifications. Registry Operator shall use commercially reasonable efforts to provide Registry Services for the Registry
TLD. The Performance Specifications defined below establish the basis for the Service Level Exception Credits ("SLE Credits") provided for in Exhibit H to this Registry-Registrar Agreement. 



3.1  Service Availability. Service Availability is defined as the time, in minutes, that the Registry's Core Services are responding to its
users. Service is unavailable when a service listed in the Matrix is unavailable to all users, that is, when no user can initiate a session with or receive a response from the Registry
("Unavailability"). Service Availability is a C1 priority level. 



3.1.1  Service Availability is measured as follows: 



Service
Availability % = {[(TM—POM)—UOM] / (TM—POM)}*100 where: 


TM =
Total Minutes in the Service Level Measurement Period (#days*24 hours*60 minutes). 


POM =
Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages during the Service Level Measurement Period). 


UOM =
Unplanned Outage Minutes (Difference between the total number of minutes of Unavailability during the Service Level Measurement Period minus POM). 




Upon
written request, and at the sole expense of the requesting Registrar(s), Registry Operator will retain an independent third party (to be selected by Registry Operator with the consent of the
Registrar(s) to perform an independent calculation of the UOM). The frequency of this audit will be no more than once yearly during the term of the agreement between Registry Operator and the
Registrar. 











This
calculation is performed and the results reported for each calendar month for SRS and Whois availability and for each calendar year for Nameserver availability. Results will be reported to the
Registrar Community via e-mail. 


3.1.2  Service Availability—SRS = 99.9% per calendar month. Service
Availability as it applies to the SRS refers to the ability of the SRS to respond to Registrars that access and use the SRS through the XRP protocol defined in Appendix C of the Registry
Agreement. SRS Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for SRS is 99.9% and the Service Level Measurement Period is
monthly. 


3.1.3  Service Availability—Nameserver = 99.999% per calendar year.
Service Availability as it applies to the Nameserver refers to the ability of the Nameserver to resolve a DNS query from an Internet user. Nameserver Unavailability will be logged with the Registry
Operator as Unplanned
Outage Minutes. The committed Service Availability for Nameserver is 99.999% and the Service Level Measurement Period is annually. 


3.1.4  Service Availability—Whois = 99.95% per calendar month. Service
Availability as it applies to Whois refers to the ability of all users to access and use the Registry's Whois service. Whois Unavailability will be logged with the Registry Operator as Unplanned
Outage Minutes. The committed Service Availability for Whois is 99.95% and the Service Level Measurement Period is monthly. 




3.2  Planned Outage. High volume data centers like the Registry require downtime for regular maintenance. Allowing for regular maintenance
("Planned Outage") ensures a high level of service for the Registry. Planned Outage Performance Specifications are a C4 priority level. 



3.2.1  Planned Outage Duration. The Planned Outage Duration defines the maximum allowable time, in hours and minutes, that the Registry
Operator is allowed to take the Registry Services out of service for regular maintenance. Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. This
Performance Specification, where applicable, has a monthly Service Level Measurement Period. The Planned Outage Duration for the Core Services is as follows: 



3.2.1.1  Planned
Outage Duration—SRS = 8 hours (480 minutes) per month; 


3.2.1.2  Planned
Outage Duration—Nameserver = (no planned outages allowed); and 


3.2.1.3  Planned
Outage Duration—Whois = 8 hours (480 minutes) per month. 




3.2.2  Planned Outage Timeframe. The Planned Outage Timeframe defines the hours and days in which the Planned Outage can occur. The Planned
Outage Timeframe for the Core Services is as follows: 



3.2.2.1  Planned
Outage Timeframe—SRS = 0600-1400 UTC Sunday; 


3.2.2.2  Planned
Outage Timeframe—Nameserver =(no planned outages allowed); and 


3.2.2.3  Planned
Outage Timeframe—Whois = 0600-1400 UTC Sunday. 




3.2.3  Planned Outage Notification. The Registry Operator must notify all of its Registrars of any Planned Outage. The Planned Outage
Notification Performance Specification defines the number of days prior to a Planned Outage that the Registry Operator must notify its Registrars. The Planned Outage Notification for the Core Services
is as follows: 



3.2.3.1  Planned
Outage Timeframe—SRS = 3 days; 


3.2.3.2  Planned
Outage Timeframe—Nameserver =(no planned outages allowed); and 


3.2.3.3  Planned
Outage Timeframe—Whois = 3 days. 

















3.3  Extended Planned Outage. In some cases such as software upgrades and platform replacements an extended maintenance timeframe is
required. Extended Planned Outages will be less frequent than regular Planned Outages but their duration will be longer. Extended Planned Outage Performance Specifications are a C4 priority level. 



3.3.1  Extended Planned Outage Duration. The Extended Planned Outage Duration defines the maximum allowable time, in hours and minutes, that
the Registry is allowed to take the Registry Services out of service for extended maintenance. Extended Planned Outages are planned in advance and the Registrar Community is provided warning ahead of
time. Extended Planned Outage periods are in addition to any Planned Outages during any Service Level Measurement Period. This Performance Specification, where applicable, has a Service Level
Measurement Period based on a calendar quarter. The Extended Planned Outage Duration for the Core Services is as follows: 



3.3.1.1  Extended
Planned Outage Duration—SRS = 18 hours (1080 minutes) per calendar quarter; 


3.3.1.2  Extended
Planned Outage Duration—Nameserver =(no planned outages allowed); and 


3.3.1.3  Extended
Planned Outage Duration—Whois = 18 hours (1080 minutes) per calendar quarter. 




3.3.2  Extended Planned Outage Timeframe. The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned
Outage can occur. The Extended Planned Outage Timeframe for the Core Services is as follows: 



3.3.2.1  Extended
Planned Outage Timeframe—SRS = 0600-1400 UTC Saturday or Sunday; 


3.3.2.2  Extended
Planned Outage Timeframe—Nameserver =(no planned outages allowed); and 


3.3.2.3  Extended
Planned Outage Timeframe—Whois = 0600-1400 UTC Saturday or Sunday. 




3.3.3  Extended Planned Outage Notification. The Registry must notify all of its Registrars of any Extended Planned Outage. The Extended
Planned Outage Notification Performance Specification defines the number of days prior to an Extended Planned Outage that the Registry Operator must notify its Registrars. The Extended Planned Outage
Notification for the Core Services is as follows: 



3.3.3.1  Extended
Planned Outage Timeframe—SRS = 4 weeks; 


3.3.3.2  Extended
Planned Outage Timeframe—Nameserver =(no planned outages allowed); and 


3.3.3.3  Extended
Planned Outage Timeframe—Whois = 4 weeks. 





3.4  Processing Time. Processing Time is an important measurement of transaction-based services like the Registry. The first three
Performance Specifications, Service Availability, Planned Outages and Extended Planned Outages, measure the amount of time that the service is available to its users. Processing Time measures the
quality of that service. 


Processing
Time refers to the time that the Registry Operator receives a request and sends a response to that request. Since each of the Registry Services has a unique function the Performance
Specifications for Processing Time are unique to each of the Registry Services. For example, a Performance Specification for the Nameserver is not applicable to the SRS and Whois, etc. Processing Time
Performance Specifications are a C2 priority level. 












Processing
Time Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. The Registry Operator will log the processing time for all of the
related transactions, measured from the time it receives the request to the time that it returns a response. 



3.4.1  Processing Time—Add, Modify, Delete = 3 seconds for 95% 



3.4.1.1  Processing
Time—Add, Modify, and Delete is applicable to the SRS as accessed through the XRP protocol defined in Appendix C of the Registry Agreement. It
measures the
processing time for add, modify, and delete transactions associated with domain names, nameserver, contacts, and registrar profile information. 



3.4.1.2  The
Performance Specification is 3 seconds for 95% of the transactions processed. That is, 95% of the transactions will take 3 seconds or less from the time the Registry Operator
receives the request to the time it provides a response. 




3.4.2  Processing Time—Query Domain = 1.5 seconds for 95% 



3.4.2.1  Processing
Time—Query Domain is applicable to the SRS as accessed through the XRP protocol defined in Appendix C of the Registry Agreement. It measures the
processing time for an availability query of a specific domain name. 


3.4.2.2  The
performance specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Registry Operator
receives the query to the time it provides a response as to the domain name's availability. 




3.4.3  Processing Time—Whois Query = 1.5 seconds for 95% 



3.4.3.1  Processing
Time—Whois Query is only applicable to the Whois. It measures the processing time for a Whois Query. 



3.4.3.2  The
Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Whois receives a query
to the time it responds. 




3.4.4  Processing Time—Nameserver Resolution = 1.5 seconds for 95% 



3.4.4.1  Processing
Time—Nameserver Resolution is only applicable to the Nameserver. It measures the processing time for a DNS query. 



3.4.4.2  The
Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time Nameserver receives the DNS
query to the time it provides a response. 





3.5  Update Frequency. There are two important elements of the Registry that are updated frequently and are used by the general public;
Nameserver and Whois. Registrars generate these updates through the SRS. The SRS then updates the Nameserver and the Whois. These will be done on a batch basis. Update Frequency Performance
Specifications are a C3 priority level. 


The
committed Performance Specification with regard to Update Frequency for both the Nameserver and the Whois is 15 minutes for 95% of the transactions. That is, 95% of the updates to the Nameserver
and Whois will be effectuated within 15 minutes. This is measured from the time that the registry confirms the update to the registrar to the time the update appears in the Nameserver and Whois.
Update Frequency Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. 



3.5.1  Update Frequency—Nameserver = 15 minutes for 95%. 











3.5.2  Update Frequency—Whois = 15 minutes for 95%. 




	 
	 	Performance

Specification

Description
	 	SRS
	 	Nameserver
	 	Whois

	1	 	Service Availability	 	99.9% per calendar month	 	99.999% per calendar year	 	99.95% per calendar month
	2	 	Processing Time—Add, Modify, Delete	 	3 sec for 95%	 	NA	 	NA
	3	 	Processing Time—Query Domain	 	1.5 sec for 95%	 	NA	 	NA
	4	 	Processing Time—Whois	 	NA	 	NA	 	1.5 sec for 95%
	5	 	Processing Time—Nameserver Resolution	 	NA	 	1.5 sec for 95%	 	NA
	6	 	Update Frequency	 	NA	 	15 min for 95%	 	15 min for 95%
	7	 	Planned Outage—Duration	 	8 hrs per calendar month	 	not allowed	 	8 hrs per calendar month
	8	 	Planned Outage—Timeframe	 	0600—1400 UTC Sun	 	not allowed	 	0600—1400 UTC Sun
	9	 	Planned Outage—Notification	 	3 days	 	not allowed	 	3 days
	10	 	Extended Planned Outage—Duration	 	18 hrs per calendar quarter	 	not allowed	 	18 hrs per calendar quarter
	11	 	Extended Planned Outage—Timeframe	 	0600—1400 UTC Sat or Sun	 	not allowed	 	0600—1400 UTC Sat or Sun
	12	 	Extended Planned Outage—Notification	 	28 days	 	not allowed	 	28 days




 
 

Exhibit H
  Service Level Agreement    
    


1.  Definitions. Capitalized terms used herein and not otherwise defined shall have the definitions ascribed to them in Exhibit G to
the Registry-Registrar Agreement. 


2.  Credits. If Registry Operator fails to meet the Performance Specifications defined in Exhibit G ("Service Level Exception" or
"SLE"), Registry Operator shall pay in the aggregate to the Registrar Community a credit according to the tables provided below ("Applicable Credit"). Each Registrar shall only be entitled to a
fraction of the Applicable Credit. Such fractions of the credit specified in the tables to be paid to any individual Registrar will be calculated based upon the number of domain names that such
Registrar added to the Registry during the Service Level Measurement Period compared to the total number of domain names added to the Registry by all Registrars during the Service Level Measurement
Period in which the SLE occurred. The credit due to Registrar may be paid as an offset to registrations and other fees owed to Registry Operator by Registrar. All credits shall be paid in U.S.
Dollars. The following Credit Lookup Matrix indicates the corresponding credit table for which the credits defined in this Appendix will be levied. 









 
 

CREDIT LOOKUP MATRIX  
  



	 
	 	Performance

Specification

Description
	 	SRS
	 	Nameserver
	 	Whois

	1	 	Service Availability	 	Table C1a	 	Table C1b	 	Table C1a
	2	 	Processing Time—Add, Modify, Delete	 	Table C2	 	NA	 	NA
	3	 	Processing Time—Query Domain	 	Table C2	 	NA	 	NA
	4	 	Processing Time—Whois	 	NA	 	NA	 	Table C2
	5	 	Processing Time—Nameserver Resolution	 	NA	 	Table C2	 	NA
	6	 	Update Frequency	 	NA	 	Table C3	 	Table C3
	7	 	Planned Outage—Duration	 	Table C4b	 	NA	 	Table C4b
	8	 	Planned Outage—Timeframe	 	Table C4a	 	NA	 	Table C4a
	9	 	Planned Outage—Notification	 	Table C4a	 	NA	 	Table C4a
	10	 	Extended Planned Outage—Duration	 	Table C4b	 	NA	 	Table C4b
	11	 	Extended Planned Outage—Timeframe	 	Table C4a	 	NA	 	Table C4a
	12	 	Extended Planned Outage—Notification	 	Table C4a	 	NA	 	Table C4a





If
one or more SLEs occurs as the direct result of a failure to meet a Performance Specification in a single credit class, Registry Operator shall be responsible only for the credit assessed for the
credit class which is the proximate cause for all directly related failures. 


The
following tables identify total Registrar Community credits due for SLEs in the four credit classes C1—C4. Notwithstanding the credit levels contained in these tables, the total
credits owed by Registry Operator under this Agreement shall not exceed $30,000 USD monthly and $360,000 USD annually. The credits contained in Tables C1a-C4 represent the total credits that may be
assessed in a given SLR category in one Service Level Measurement Period. 


2.1 C1 Credit Class—If availability of C1 Credit Class components or systems does not meet C1 Performance Specifications in any given
Service Level Measurement Period described in the Performance Specification Matrix in Exhibit G, Registry Operator will credit the Registrar Community according to the tables (which amount will
be credited to the Registrar on a proportional basis as set forth above). 


 
 

Table C1a    
    



	SLE
 
	 	< 30

sec.'s
	 	30-60

sec.'s
	 	1-2

min.'s
	 	2-10

min.'s
	 	10-30

min.'s
	 	over 30

min.'s

	Monthly Credit to Registrar Community	 	$	750	 	$	1,500	 	$	2,500	 	$	3,750	 	$	5,000	 	$	6,000





C1a Availability Example: In a given measurement period, the SRS Availability is 99.87%, which equates to 52 minutes of unplanned downtime. The Registry
Operator's Performance Specification for SRS Availability is 99.9%, or 43 minutes of downtime. The Service Level Exception, therefore, is 9 minutes (52-43 minutes), the difference between
the Performance Specification and the actual measured performance. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C1a. In Table C1a, the time interval (2-10
minutes) has a corresponding credit of $3,750 USD to be paid to the Registrar Community. 








 
 

Table C1b    
    



	SLE
 
	 	< 10

min.'s
	 	10-30

min.'s
	 	30-60

min.'s
	 	1-2

hour s
	 	2-4

hours
	 	over 4

hours

	Annual Credit to Registrar Community	 	$	7,500	 	$	15,000	 	$	25,000	 	$	35,000	 	$	50,000	 	$	75,000





C1b Availability Example: In a given Service Level Measurement Period, the measured Nameserver Availability is 99.990% over a twelve (12) month
period, which equates to 52 minutes of downtime. The Registry Operator's Performance Specification for Nameserver Availability is 99.999%, or 5 minutes of downtime per calendar year. The Service Level
Exception, therefore, is 47 minutes (52-5 minutes), the difference between the Performance Specification and the actual measured performance. From the Credit Lookup Matrix, we see the
relevant SLA is found in Table C1b. In Table C1b, the time interval (30-60 minutes) has a corresponding credit of $25,000 USD to be paid to the Registrar Community. 



2.2 C2 Credit Class—If processing time for C2 Credit Class services does not meet C2 Service Levels in any given Service Level Measurement
Period, Registry Operator will credit the Registrar Community according to the following table (which amount will be credited to the Registrars on a proportional basis as set forth above). 



 
 

Table C2    
    



	SLE
 
	 	< 2

sec.'s
	 	2-5

sec.'s
	 	5-10

sec.'s
	 	10-20

sec.'s
	 	20-30

sec.'s
	 	over 30

sec.'s

	Monthly Credit to Registrar Community	 	$	375	 	$	750	 	$	1,500	 	$	3,500	 	$	4,000	 	$	7,500





C2 Processing Example: The Performance Specification for Processing Time for Add, Modify, and Delete is 3 seconds or less for 95% of the transactions.
In a given Service Level Measurement Period 7% of the transactions are greater than 3 seconds. The 5% of those transactions with the longest processing times are not subject to the SLE calculation (3
seconds for 95%). The SLE is calculated using the average processing time for the 2% of the transactions that are subject to the SLE. If there were 1,000 transactions and they took a total of 4,000
seconds the average is 4 seconds. That generates an SLE of 1 second (4 seconds—3 seconds). From the Credit Lookup Matrix, we see the relevant SLA is found in Table C2. In Table C2, the SLE
time interval (< 2 seconds) has a corresponding credit of $375 USD to be paid to the Registrar Community. 




2.3 C3 Credit Class—If update frequency measurements of C3 Credit Class components or systems do not meet C3 Service Levels in any given
Service Level Measurement Period as described in the Performance Specification Matrix in Exhibit G, Registry Operator will credit the Registrar Community according to the following tables
(which amount will be credited to the Registrars on a proportional basis as set forth above). 


 
 

Table C3    
    



	SLE
 
	 	< 30

sec.'s
	 	30-60

sec.'s
	 	1-2

min.'s
	 	2-10

min.'s
	 	10-30

min.'s
	 	over

30 min.'s

	Monthly Credit to Registrar Community	 	$	188	 	$	375	 	$	625	 	$	938	 	$	1,250	 	$	1,500





C3 Update Frequency Example: In a given Service Level Measurement Period, 95% of the updates to the Nameserver take 24 minutes or less to complete. The
corresponding Registry Operator's Performance Specification is 15 minutes for 95% of the updates. The SLE, therefore, is 9 minutes. From the Credit Lookup Matrix, we see the relevant SLA is found in
Table C3. The SLE time interval (2-10 minutes) has a corresponding credit of $938 USD to be paid to the Registrar Community. 









2.4 C4 Credit Class—If Registry Operator fails to comply with C4 Credit Class category Performance Specifications, Registry Operator will
credit the Registrar Community according to the following tables (C4a and C4b) (which amount will be credited to the Registrars on a proportional basis as set forth above). 


 
 

Table C4a    
    



	SLE
 
	 	Any

	Monthly Credit to Registrar Community	 	$	500






C4a Planned Outage Notification Example: In each instance the Registry Operator fails to meet the Performance Specifications for Notification and
Timeframe related to Planned Outages and Extended Planned Outages, the Registry Operator is subject to the credit in Table C4a. For example, the Registry Operator informs the Registrar Community that
it will initiate a Planned Outage of the SRS on the next calendar Sunday (five (5) days advance notice). The corresponding Registry Operator's Performance Specification is 28 days
notice. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C4a. This results in a credit of $500 USD to be paid to the Registrar Community. 



 
 

Table C4b    
    



	SLE
 
	 	< 1

hour
	 	1-2

hours
	 	2-4

hours
	 	4-6

hours
	 	6-10

hours
	 	over 10

hours

	Monthly Credit to Registrar Community	 	$	300	 	$	750	 	$	1,200	 	$	2,500	 	$	3,500	 	$	4,000





C4b Planned Outage Example: In a given Service Level Measurement Period, the actual duration of a planned outage is 11 hours and 20 minutes for
the SRS. The corresponding Registry Operator's Performance Specification is 8 hours per month for the SRS. The SLE, therefore, is 3 hours and 20 minutes. From the Credit Lookup Matrix
the relevant SLA is found in Table C4b. The SLE time interval (2-4 hours) has a corresponding credit of $1,200 USD to be paid to the Registrar Community. 




3.  Receipt of Credits. In order for Registrars to claim credits, the following procedure must be followed: 



3.1  Registry
Operator shall perform the required measurements in order to obtain the total credits associated with the applicable Service Level Measurement Period. Such measurements and
associated documentation shall be delivered by e-mail to each of the Registrars in the Registrar Community. Such notice shall also include the total credit (if any) to be paid to the
Registrar Community as a result of any outages. 


3.2  Receipt
of Credit—When the above steps have been completed, the Registry Operator shall enter in each Registrar's account balance the amount of credit (if applicable) that
can be used immediately toward registrations in the Registry. 




4.     Obligations.  



4.1  Except
in the case of cross-network nameserver performance (which is not a subject of this Service Level Agreement), Registry Operator will perform monitoring from internally located
systems as a means to verify that the conditions of the SLA are being met. 


4.2  Upon
written request, and at the sole expense of the requesting Registrar(s), Registry Operator will retain an independent third party to be selected by Registry Operator with the
consent of the Registrar(s). The Registrar may, under reasonable terms and conditions, audit the reconciliation records for the purposes of verifying measurements of the Performance Specifications.
The frequency of these audits will be no more than once yearly during the term of the agreement between Registry Operator and the Registrar. 











4.3  Registry
Operator's obligations under this SLA are waived during the first 120 days after the Commencement-of-Service Date. 


4.4  A
Registrar must report each occurrence of alleged occasion of Unavailability of Core Services to the Registry Operator customer service help desk in the manner required by the
Registry Operator (i.e., e-mail, fax, telephone) in order for an occurrence to be treated as Unavailable for purposes of the SLE. 


4.5  In
the event that the Core Services are Unavailable to an individual Registrar, Registry Operator will use commercially reasonable efforts to re-establish the affected
Core Services for such Registrar as soon as reasonably practicable. In the event that the Unavailability of Core Services affects all Registrars, the Registry Operator is responsible for opening a
blanket trouble ticket and immediately notifying all Registrars of the trouble ticket number and details. 


4.6  Both
Registrar and the Registry Operator agree to use reasonable commercial good faith efforts to establish the cause of any alleged Core Services Unavailability. If it is mutually
determined to be a Registry Operator problem, the issue will become part of the Unplanned Outage minutes. 


4.7  Beginning
no later than 120 days post Commencement-of-Service Date, the Registry Operator will publish preliminary weekly system performance and
availability reports. Registry Operator will use best efforts to finalize these reports no later than 30 days after the preliminary reports are provided. 



4.8  The
Registry Operator will use commercially reasonable efforts to restore the critical systems of the Core Services within 24 hours after the termination of a force majeure
event and restore full system functionality within 48 hours after the termination of a force majeure event. Outages due to a force majeure will not be considered Service Unavailability. 


4.9  Incident
trouble tickets must be opened within a commercially reasonable period of time. 




5.     Miscellaneous.  



5.1  This
Service Level Agreement is independent of any rights, obligations or duties set forth in the Registry Agreement. In the event of any conflict between the terms and conditions of
this Agreement and the Registry Agreement, the Registry Agreement shall control. 



 
 

Exhibit I
  Registry/Registrar IP Claim Service Agreement    
    


This
IP Claim Service Agreement ("Agreement") entered into this            day
of                        , 2001 ("Effective Date") is between NeuLevel, Inc., a Delaware corporation having a
principal place of business at Loudoun Tech Center, 45980 Center Oak Plaza, Building VIII, Sterling, VA 20166 ("Registry Operator")
and                        ,
a                        corporation having a
principal place of business at                        ("Registrar"). This Agreement is hereby incorporated as Exhibit I to
Appendix F ("Registry-Registrar Agreement") to the Registry Agreement
by and between the Internet Corporation for Assigned Names and Numbers ("ICANN") and Registry Operator, including all Appendices attached thereto ("Registry Agreement"). Capitalized terms not defined
herein shall have the meaning set forth in the Registry Agreement. 


 
 

Explanatory Statement    
    


Registry
Operator has been authorized by the Internet Corporation for Assigned Names and Numbers ("ICANN") to operate as the.biz top-level domain registry. 



Prior
to Registry Operator's launch of the.biz registry, Registrar desires to offer an Intellectual Property Claim Service to holders of intellectual property rights who desire to obtain a.biz domain
name. 










Registry
Operator is willing to provide such Intellectual Property Claim Service subject to the terms and conditions of this Agreement. 


NOW,
THEREFORE, the parties agree as follows: 



1.     DEFINITIONS  



1.1  "Branded Site" means the Web site that includes Registry Operator branding, which Registry Operator will make available to third
parties to obtain information regarding the IP Claim Service. 


1.2  "Batch Option" means the submission of one hundred (100) or more separate claims in a flat file (e.g., Microsoft Excel "CSV"
format or as otherwise specified by Registry Operator) to Registry Operator for syntax check and batch load for IP Claim Service processing. 


1.3  "Claim" means a claim submitted by an End User through the IP Claim Service with respect to a Trademark (as defined below). 



1.4  "End User" means any individual, company or legal entity that uses the IP Claim Service. 


1.5  "IP Claim Service" means the Intellectual Property Claim Service as described in the Terms of Use in which each domain name application
in the.biz TLD submitted through an ICANN-Accredited Registrar will be compared to a database of registered or common law trademark ("Trademark") claim forms. For each match between the domain name
for an application and a string identified on a Trademark claim form notifications will be provided by Registry Operator to the applicant that other entities have claimed intellectual property rights
over that domain name. 


1.6  "Link" (as a noun or verb) means one or more instances of the following, as the context requires: (i) the hypertext connection
between the Registrar Site and the Branded Site or White Site; or (ii) the text and graphics depicting the hypertext connection. 


1.7  "Marketing Materials" means any advertising, press releases, publicity, marketing collateral or similar materials regarding the IP
Claim Service. 


1.8  "Participating Registrars" means the ICANN-Accredited Registrars offering the IP Claim Service. 



1.9  "Registrar Site" means the Internet URL controlled and/or operated by Registrar for the provision of the IP Claim Service. 


1.10  "Terms of Use" means the terms and conditions to access and use the IP Claim Service, a copy of which is attached as
Schedule A, which Registry Operator may modify from time to time in its sole discretion. 


1.11  "White Site" shall mean the Web site that does not include Registry Operator branding, which Registry Operator will make available to
Participating Registrars. 




2.     SERVICE DESCRIPTION  



2.1  Basic IP Claim Service. Registry Operator will provide the IP Claim Service pursuant to the terms and conditions of this Agreement
during the period beginning approximately May 21, 2001 continuing through approximately July 9, 2001 ("Phase 1"). The exact dates are subject to change at Registry Operator's sole
discretion. Registry Operator will provide advance notice to Registrar in the event that the above dates change. Registry Operator shall provide the IP Claim Service on behalf of Registrar in the
following manner: 



Branded
Site. Registrar will be included on the Branded Site unless Registrar expressly opts out. Registry Operator will make information regarding the IP Claim Service generally available to third
parties through the Branded Site. If an End User desires to submit a Claim through the Branded Site, Registry Operator will provide the End User with a list of all of the Participating Registrars.
Claimant will be required to choose a Participating Registrar as its 











provider
of the IP Claim Service before submitting a Claim through the Branded Site. Upon Registry Operator's receipt of a Claim and payment for such Claim pursuant to Section 7.2 below,
Registry Operator will process such Claim on behalf of Registrar through the IP Claim Service. Registrar acknowledges that Registry Operator does not guarantee that End User(s) will elect to obtain
the IP Claim Service from Registrar. Registry Operator will randomize the order in which each Participating Registrar appears on such list. Registrar further acknowledges that an End User's selection
of a Participating Registrar will not obligate such End User to obtain any other products or services of the Participating Registrar, including the submission of an application for a domain name or
the submission of any additional Claims through the IP Claim Service. 




2.2  Additional Methods. In addition to the Branded Site, Registrar may elect one or both of the following methods, at Registrars sole
discretion: 



(a)  Batch
Option. Registrar may submit Claims to Registry Operator for processing through the Batch Option. Registrar shall be solely responsible for collecting from End Users and
submitting to Registry Operator accurate and complete data for each Claim submitted through the Batch Option. Upon receipt by Registry Operator of properly-formatted Claims submitted through the Batch
Option and payment for such Claims pursuant to Section 7.1 below, Registry Operator will process such Claims through the IP Claim Service. 



(b)  White
Site. Registrar may refer End Users to the IP Claim Service by creating a Link to the White Site or by "framing" the White Site. Upon receipt by Registry Operator of a Claim
submitted by an End User through the White Site and payment for such Claim pursuant to Section 7.2 below, Registry Operator will process such Claim on behalf of Registrar through the IP Claim
Service. Registry Operator will make the White Site available as soon as practicable, but in no event later that five (5) business days from the Effective Date. 




2.3  Terms of Use. Registrar shall execute, and cause each of its End Users to execute the Terms of Use for each Claim submitted through the
Batch Option. For Claims submitted through the White and/or Branded Sites, Registry Operator shall cause each of the End Users to execute the Terms of Use on behalf of Registrar. Registry Operator
will provide Registrar with a copy of any modifications to the Terms of Use and Registrar shall notify all End Users of such modifications. Registrar shall not create terms and conditions with respect
to the IP Claim Service that are inconsistent with the Terms of Use. In the event of any inconsistency, the Terms of Use shall control. Registrar may provide End Users with a foreign translation of
the Terms of Use, but each End User must execute the English version of the Terms of Use provided by Registry Operator, which shall be authoritative. Registrar shall diligently enforce End User
compliance with such Terms of Use. 


2.4  Data Entry Services. If Registrar submits data through the Batch Option, Registrar (i) must provide accurate data for each
Claim, (ii) must ensure that the data conforms to the required field specifications, and (iii) may not create or supply "filler" data to bypass the data field requirements. Registrar
shall not access or modify the text of any data field created or supplied by an End User or its agent during the Claim submission process. In addition, Registrar shall not replace End User or agent
data with its own contact information in a Claim. 


2.5  End User License. By submitting End User data in connection with a Claim, Registrar automatically grants, or warrants that the owner of
such data has expressly granted, Registry Operator the limited, royalty-free, non-exclusive worldwide license to use all of the data contained in a Claim solely for the
purposes of implementing the IP Claim Service, processing the Claim, notifying domain name applicants of Claims, notifying End User of changes to the IP Claim Service, for archival purposes, and
otherwise required by Registry Operator for in Registry Operator's operation of the Registry TLD. 












2.6  Misuse. Registrar shall promptly notify Registry Operator of any suspected or known misuse of the IP Claim Service and provide its best
efforts to assist in verifying the facts surrounding such suspected misuse. 


2.7  Restrictions. Except as may be expressly provided in this Agreement, Registrar may not: (i) rent, lease, lend, directly or
indirectly transfer the IP Claim Service to any third party other than Registrar's authorized resellers of registration services; (ii) create derivative products based on the IP Claim Service
(other than as may be necessary to frame the White Site and bundle the IP Claim Service with Registrar's services); or (iii) remove, modify or obscure any copyright, trademark, patent or mask
work notices that appear on the IP Claim Service, Terms of Use or Marketing Materials or that appear during the use of the IP Claim Service. 


2.8  Reports. Registry Operator may be required to provide certain information and reports to ICANN from time to time. Registrar shall
submit periodic reports to Registry Operator, which shall include such information as may be reasonably requested by Registry Operator. Any failure of Registrar to provide such reports within thirty
(30) days after request by Registry Operator shall be a material breach of this Agreement. 


2.9  Technical Contacts. Upon execution of this Agreement, Registrar shall designate at least two (2) technical contacts that
Registry Operator may contact regarding this Agreement and shall provide Registry Operator with the name, telephone number and email address of such technical contact. Registrar shall promptly notify
Registry Operator of any change of its technical contacts or such contact information. 


2.10  Return of Copy of Registrar End User Data. No later than thirty (30) days after the completion of Phase 1, Registry Operator
shall provide to Registrar a complete copy of all Registrar's End User data submitted through the IP Claim Service. In no event shall Registrar receive any End User data that did not originate from
Registrar. 




3.     MARKETING  



3.1  Promotion. Registrar shall use its commercially reasonable efforts to promote and otherwise solicit prospective End Users to use to the
IP Claim Service. Such efforts shall accurately describe the IP Claim Service as set forth in the Marketing Materials and as otherwise provided by Registry Operator. In addition, such efforts shall be
consistent with good business ethics and reflect favorably upon the IP Claim Service. 


3.2  Marketing Materials. Registry Operator will provide Registrar with Marketing Materials in electronic format or such other format as the
parties may mutually agree. ** 


3.3  Restrictions. Registrar shall refrain from engaging in any illegal, unfair, or deceptive trade practices, unethical business practices
or making any representations or warranties inconsistent with those provided hereunder with respect to the promotion of the IP Claim Service. 


3.4  Logo and Trade Name Use. Registry Operator hereby consents to Registrar's use of Registry Operator's logo and trade name, as provided
by Registry Operator to Registrar, for the limited purpose of Linking to the Branded Site or the White Site and for Marketing Materials. Any and all use of Registry Operator's logo or trade name by
Registrar shall inure to the benefit of Registry Operator. Registrar acknowledges that its utilization of Registry Operator's logo will not create in it, nor will it represent it has any right, title
or interest in or to such logo. Registrar shall not do anything contesting or impairing the trademark rights of Registry Operator. Except as expressly contemplated by this Agreement, Registrar may not
use Registry Operator's name, trademarks, service marks or other identifier in any capacity without Registry Operator's prior written consent. 



3.5  Press Release. Any news release, public announcement, advertisement or publicity proposed to be released by Registrar containing
Registry Operator's logo and/or trademark will be subject to the prior written approval of Registry Operator. 













4.     SUPPORT  



4.1  Branded Site and White Site Options. At no cost to End Users, Registry Operator shall be the exclusive provider of customer support for
the IP Claim Service for Registrars that use the Branded or White Site Options. 


4.2  Batch Option. At no cost to End Users, Registrars shall be the exclusive provider of customer support for the IP Claim Service for
Registrars that elect to use the Batch Option. 


4.3  FAQs. Registrar shall create a Link from the Registrar Site to the Frequently Asked Questions ("FAQs") on the Branded Site, which
Registry Operator may amend from time to time in its sole discretion. Registrar may provide translation(s) of the FAQs into languages other than English but shall modify any translation upon request
by Registry Operator, if Registry Operator determines in its sole discretion that the translation does not accurately convey the intent of the FAQs. Nothing herein shall obligate Registry Operator
from verifying or monitoring in any way Registrar's compliance with the above. Registry Operator may frequently modify the FAQs. It is essential that the End User have access to the most recent
version of the FAQs. Therefore, except as provided above, Registrar may not otherwise copy the Frequently Asked Questions in whole or in part. 




5.  ACCURATE DATA. Registrar shall be responsible for the adequacy and accuracy of all data and information that Registrar and End User
furnish to Registry Operator and the results obtained therefrom. Registrar shall be responsible for maintaining adequate controls over its processing and data transmissions up to but excluding
transmissions within the IP Claim Service, for monitoring the input and output of such processing and transmissions and for notifying Registry Operator of any non-conforming processing
and/or transmissions. Registrar acknowledges and agrees, and shall require End User to acknowledge and agree, that Registry Operator is not responsible for checking, verifying or editing message
content or completeness or for detecting errors or anomalies nor for recreating or re-transmitting data. Although Registrar understands and acknowledges that Registry Operator has no
obligation to check, verify or edit claim content or completeness or for detecting errors, in the event that any errors are discovered, the claims containing such errors may be returned to Registrar
for correction and/or editing prior to Registry Operator processing the claim. 


6.     TERMINATION  



6.1  Term. Unless otherwise terminated in accordance with section 6, this Agreement shall expire 6 months after the
commencement of Phase 1. 


6.2  Termination Under Registry—Registrar Agreement. This Agreement may be terminated pursuant to the terms of the
Registry-Registrar Agreement. 


6.3  Material Breach. Registry Operator may terminate this Agreement upon ten (10) days written notice of a material breach of this
Agreement if such breach is not cured within such ten (10) day period. Notwithstanding the above, Registry Operator may terminate this Agreement immediately, upon written notice, for breach of
Sections 2.3, 2.4, or 4.3. 


6.4  Suspension. Registry Operator may suspend the IP Claim Service for Registrar and/or terminate this Agreement if Registrar breaches this
Agreement, and Registrar fails to cure such breach within five (5) days after receiving notice thereof from Registry Operator; provided, however, that Registry Operator may immediately suspend
the IP Claim Service and/or terminate this Agreement without notice (i) in order to prevent damage to or degradation of its Internet network integrity which may be caused by Registrar or its
End Users, (ii) to comply with any law, regulation, court order, or other governmental request or order which requires immediate action, (iii) for anyone's violation of Registry
Operator's Terms of Use or Privacy Policy, or (iv) for other behavior that in Registry Operator's sole discretion may be deemed to be illegal or otherwise to protect Registry Operator from
legal liability. Registry Operator will endeavor to give Registrar notice regarding the reason(s) for suspension or termination as soon as reasonably practicable after such suspension or termination. 












6.5  Effect of Termination. Within thirty (30) days after the expiration or termination of this Agreement for any reason, Registrar
will destroy the original and all copies (including partial copies) of all Marketing Materials or other materials provided by Registry Operator or used by Registrar in connection with this Agreement,
including copied portions contained in derivative works. Within such time period, Registrar will certify in writing to Registry Operator its compliance with this provision. 


6.6  Survival. The provisions of Articles Section 2.5, 2.8, 8, 9 and 10 shall survive any termination or the expiration of this
Agreement. 




7.     FEES TO REGISTRY OPERATOR  



7.1  Batch Option Fee. Subject to the terms of Appendix G of the Registry Agreement, Registrar shall pay Registry Operator a fixed
fee for each Claim submitted through the Batch Option ("Batch Option Fee"). The Batch Option Fee is provided in Schedule B. Registry Operator may, at its option and within 7 days written
notice, revise the fees in Schedule B. Registrar shall pay Registry Operator the Batch Option Fee by wire transfer concurrently with submission of Claims to Registry Operator. 


7.2  Branded Site and White Site Fees. End Users shall pay Registry Operator an IP Claim Service fee of ninety dollars (US $90) for each
Claim submitted through the White Site or the Branded Site ("IP Claim Service Fee"). IP Claim Service Fees are provided in Schedule B. Registry Operator may, at its option and with
7 days written notice, revise the fees in Schedule B. Registry Operator shall deduct from each IP Claim Service Fee a fixed fee in accordance with the fees set forth below ("Site Fee").
Registry Operator shall pay Registrar the remaining amount within thirty (30) days after the official close of Phase 1. Registry Operator, in accordance with Appendix G, shall determine
the Site Fees for the Branded and White Sites along with the Batch Option Site Fees. 


7.3  Expenses. Each party shall be responsible for its own expenses incurred in connection with performing its obligations hereunder. 


7.4  Taxes. Each party shall be responsible for sales, use, transfer, excise and all other taxes and duties, whether international,
national, state or local, however designated, which are levied or imposed by reason of performance by the other party under this Agreement; excluding, however, income taxes. 




8.     OWNERSHIP/CONFIDENTIALITY  



8.1  Ownership. Registry Operator has and shall retain all right, title and interest, including intellectual property rights, in and to the
IP Claim Service, Branded Site, White Site, and Registry Operator's logos, trademarks, and service marks. 




9.     WARRANTIES; LIMITATION OF LIABILITY; INDEMNIFICATION  



9.1  Accreditation; Terms of Use. Registrar represents and warrants that it has received and will maintain accreditation by ICANN as a
registrar of top-level domains. Registrar will offer the IP Claim Service in a manner that is consistent with this Agreement, the Terms of Use and Marketing Materials provided by Registry
Operator. Registrar shall be solely responsible for any claims, warranties or representations made by Registrar or Registrar's employees or representatives that differ from the Terms of Use provided
by Registry Operator. Registrar has entered a Registry-Registrar Agreement with Registry Operator which shall remain in effect during the term of this Agreement. 


9.2  Disclaimer of Warranties. REGISTRY OPERATOR MAKES NO WARRANTY TO REGISTRAR OR TO ANY OTHER ENTITY, WHETHER EXPRESS, IMPLIED OR 












STATUTORY,
AS TO THE MERCHANTABILITY, FITNESS FOR ANY PARTICULAR PURPOSE, LACK OF VIRUSES, ACCURACY OR COMPLETENESS OF RESPONSES OR RESULTS, TITLE, NONINFRINGEMENT, QUIET ENJOYMENT OR QUIET
POSSESSION, OR CORRESPONDENCE TO DESCRIPTION WITH RESPECT TO THE IP CLAIM SERVICE, THE WHITE SITE, OR THE BRANDED SITE. THE ENTIRE RISK AS TO THE QUALITY OF OR ARISING OUT OF THE USE OR PERFORMANCE OF
THE IP CLAIM SERVICE, THE WHITE SITE AND THE BRANDED REMAINS WITH THE REGISTRAR AND END USER. 


9.3  Limitation of Liability. IN NO EVENT SHALL EITHER PARTY OR THEIR AFFILIATES, OFFICERS, DIRECTORS, EMPLOYEES, AGENTS OR ASSIGNS BE
LIABLE FOR ANY INDIRECT DAMAGES, INCLUDING BUT NOT LIMITED TO, LOST PROFITS, LOSS OF BUSINESS, LOSS OF PRIVACY, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, PUNITIVE OR CONSEQUENTIAL DAMAGES THAT RESULT
IN ANY WAY FROM REGISTRAR'S OR ITS END USERS' RELIANCE ON OR USE OF CONTENT, INFORMATION, OR SERVICES PROVIDED ON OR THROUGH THE IP CLAIM SERVICE, THE WHITE SITE, THE BRANDED SITE OR THAT RESULT FROM
OR ARE RELATED TO, MISTAKES, OMISSIONS, INTERRUPTIONS, DELETION OF FILES, ERRORS, DEFECTS, DELAYS IN OPERATION OR TRANSMISSION OR ANY FAILURE OF PERFORMANCE OF ANY KIND, EVEN IF SUCH PARTY HAS BEEN
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. REGISTRY OPERATOR'S LIABILITY TO THE OTHER WHETHER IN CONTRACT OR IN TORT (INCLUDING BREACH OF WARRANTY, NEGLIGENCE AND STRICT LIABILITY IN TORT) SHALL BE
LIMITED TO THE AMOUNTS ACTUALLY PAID (INCLUDING BOTH PRINCIPAL AND INTEREST) TO REGISTRAR BY REGISTRY OPERATOR AT THE TIME THE EVENT RESULTING IN LIABILITY OCCURS. 




10.   MISCELLANEOUS  



10.1  Governing Law. This Agreement shall be governed by and construed in accordance with the laws of the Commonwealth of Virginia without
regard to its principles of conflicts of laws. 


10.2  Independent Contractors. Except to the extent that Registry Operator processes Claims on behalf of Registrars, nothing contained in
this Agreement shall be construed as creating any agency, partnership, or other form of joint enterprise between the parties. In the course of performing the IP Claim Service, Registry Operator may
retain independent contractors or assign or subcontract to or otherwise have any third party perform any or all of the IP Claim Service at any time, provided that Registry Operator shall continue to
remain responsible for full performance of any such duties to the same extent as if it had performed the IP Claim Service itself. 


10.3  Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by Registry Operator to any
non-party to this Agreement, including any End User. Notwithstanding the above, Registry Operator shall be a third party beneficiary to the Terms of Use. 









IN
WITNESS WHEREOF, this Agreement has been executed and delivered by the undersigned officers, thereunto, duly authorized, as of the Effective Date. 



	NEULEVEL, INC.	 	REGISTRAR
	 	 	 	 	 
	

By:	

 	
 	

By:	

 
	Name:	 	 	Name:	 
	Title:	 	 	Title:	 
	Date:	 	 	Date:	 











 
 

SCHEDULE A
  IP CLAIM SERVICE
  TERMS OF USE    
    



THIS IS A LEGALLY BINDING AGREEMENT BETWEEN                        - ("REGISTRAR") AND YOU, THE OWNER OF A
REGISTERED OR COMMON LAW TRADEMARK OR SERVICE MARK ("OWNER") OR THE DULY
AUTHORIZED AGENT OF AN OWNER ("AGENT") (COLLECTIVELY, "YOU"). THESE TERMS OF USE ARE THE COMPLETE AND EXCLUSIVE STATEMENT OF THE TERMS OF USE REGARDING USE OF THE REGISTRAR'S INTELLECTUAL PROPERTY
CLAIM SERVICE (THE "SERVICE").


BY SELECTING "I AGREE," BY USING THE SERVICE OR BY SIGNIFYING ACCEPTANCE IN ANY OTHER WAY, YOU AGREE TO BE BOUND BY THESE TERMS OF USE. IF YOU DO NOT AGREE WITH ALL OF THESE
TERMS OF USE, YOU ARE NOT AUTHORIZED TO USE THE SERVICE AND YOU MUST DISCONTINUE ANY FURTHER USE.


1.  The Service. Registrar provides the Service to holders of both registered and common law trademarks or service marks (collectively
"Trademarks"). During the domain name application process, applicants for a.biz domain name ("Applicants") will be notified of an Owner's alleged intellectual property rights in a Trademark if the
domain name contained in the domain name application is an exact match of the Trademark identified in an IP Claim (as defined below) submitted by Owner. You may review frequently asked questions
regarding the Service by reviewing our FAQs. 


2.  Registration, Password and Security. To use the Service, You may be asked to first create an account and obtain a login name and
password. You must provide Registrar with accurate, complete and current registration information and must update this information promptly if it changes. 


You
represent and warrant that You are at least eighteen (18) years of age or older and are either an Owner or an Agent duly authorized to represent an Owner(s) in connection with the Service
and submitting an IP Claim on behalf of an Owner(s). Agent will indemnify and hold harmless Registrar and its officers, directors, employees, agents, affiliates and subcontractors for any claims
brought by Owner or Third Parties relating to the use of the Service. 


You
are solely responsible for maintaining the confidentiality of Your login name and password. You must immediately notify Registrar of any unauthorized use of Your login name and You are responsible
for any unauthorized activities, charges and/or liabilities made on or through Your login name until we receive such notification. You may not transfer or lend login names to any other third party. 


3.  License to Use Data / Privacy. By submitting an IP Claim, You hereby grant Registrar, as well as any of its agents or subcontractors, a
limited, royalty-free, non-exclusive worldwide license to use all of the data contained in the IP Claim solely for the purposes of implementing the Service, processing Your IP
Claim, notifying Applicants of Your IP Claim, and for notifying You of changes to the Service, for archival purposes. 








4.  The IP Claim Process. 


In
order to submit a claim with respect to a Trademark or Trademarks ("IP Claim") through the Service, You must complete an IP Claim form for each Trademark. For each IP Claim, You must submit
complete contact information, representative contact information and notification details, and the details regarding the Trademark. You may specify in the representative field that an Agent may
receive legal correspondence regarding the IP Claim. Once You have submitted an IP Claim, you will receive a confirmation email and a claim number. You must retain the claim number for each IP Claim
You submit. 


Registrar
will accept IP Claims until July 9, 2001, or such later date as it may determine in its sole discretion ("Close of Phase I") and no IP Claims will be accepted after that date. 


From
the Close of Phase I until September 25, 2001 ("Phase 2"), or such other later date as Registrar may choose, in its sole discretion, the domain name applications from ICANN-approved
registrars ("Applications") will be compared with the database of IP Claims processed through the Service ("IP Claim Database"). For each exact match between an IP Claim in the IP Claim Database and a
domain name application, the Registry Operator for.Biz ("Registry Operator") will notify the Applicant that a third party or third parties have submitted an IP Claim for the exact Trademark. The email
notification to the Applicant will include, among other things, the information provided by Owner in the IP Claim, instructions on how to proceed with the registration process, and that if selected
during the randomized name selection phase ("Name Selection Phase"), the domain name will be placed on a temporary thirty (30) day hold when the Registry goes "live." The Applicant will have
the option to proceed with the Application or cancel the Application. If the Applicant does not respond to the email notification, or elects to cancel the Application, Your domain name application
will not be processed during the Name Selection Phase. If the Applicant chooses to proceed with the registration process and the name is selected during the Name Selection Phase, that domain name
automatically will be placed on a thirty (30) day "hold period" when the name is registered. 


After
Name Selection, the Owner will be notified by Registry Operator if an Applicant has successfully registered the domain name. The Owner will then have the option of contacting the Applicant and
finding a solution or using the guidelines set forth by a special dispute resolution process called the Start-up Trademark Opposition Policy ("STOP") ("information available at
[LINK], or the Uniform Domain-Name Dispute Resolution Procedures ("UDRP") (information is available at
http://www.icann.org/udrp/udrp-policy-24oct99.htm). 


You
will not be notified if there are no Applications that exactly match an IP Claim You submitted in the IP Claim Database. 


USE OF THE SERVICE DOES NOT GUARANTEE THAT AN OWNER WILL BE AWARDED THE.BIZ EXTENSION FOR ITS TRADEMARK. AN OWNER THAT WISHES TO OBTAIN A.BIZ EXTENSION FOR ITS TRADEMARK MUST
FILE A DOMAIN NAME APPLICATION.


DOMAIN NAME APPLICANTS WILL ONLY BE NOTIFIED OF APPLICATIONS THAT ARE EXACT MATCHES WITH A TRADEMARK IDENTIFIED IN AN IP CLAIM FORM. REGISTRAR WILL NOT VERIFY WHETHER A
TRADEMARK CLAIMED ON AN IP CLAIM FORM CORRESPONDS WITH AN ACTUAL, LEGAL OR VALID TRADEMARK, NOR WILL REGISTRAR PROVIDE ANY LEGAL OVERSIGHT OR ADJUDICATION FOR ANY DISPUTED INTELLECTUAL PROPERTY
IMPLICATED BY THE SERVICE.


5.  Conduct. 


You
may access and use the Service for lawful purposes only and you are solely responsible for the knowledge and adherence to any and all laws, statutes, rules and regulations pertaining to Your use
of the Service. You agree that You will not (i) use the Service to commit a criminal offense or to encourage conduct that would constitute a criminal offense or give rise to a civil liability,
or otherwise violate any local state, Federal or international law or regulation; (ii) upload or otherwise transmit any content that You do not have a right to transmit under any law or
contractual or fiduciary duty; 










(iii) interfere
or infringe with any trademark or proprietary rights of any other party; (iv) interfere with the ability of other users to access or use the Service; (v) claim a
relationship with or to speak for any individual, business, association, institution or other organization for which You are not authorized to claim such a relationship; (vi) interfere with or
disrupt the Service or servers or networks connected to the Service, or disobey any requirements, procedures, policies or regulations of networks connected to the Service; or (vii) reproduce,
duplicate, copy, use, distribute, sell, resell or otherwise exploit for any commercial purposes any portion of the Service. 


6.  Fees. As consideration for the Service, You agree to pay Registrar, or its agents or subcontractors, as the case may be, an IP Claim fee
for each IP Claim submitted through the Service by credit card through its online payment system. Such fee shall be due immediately and is non-refundable. Registrar, or its agents or
subcontractors, may take all remedies to collect fees owed. Registrar, or its agents or subcontractors may require you to submit and pay for each IP Claim individually or it may allow you store up a
certain number of IP Claims before submitting them for processing. Once you have stored that number of IP Claims, you may not be able to store any additional IP Claims and may need to submit them for
processing and pay the applicable fee before obtaining additional storage space. No refunds are permitted. 


7.  Agents. You agree that, if Your agent (e.g., an attorney, employee, etc.) submits an IP Claim on Your behalf, You are nonetheless bound
as a principal by all Terms of Use herein. Your continued use of the Services shall ratify any unauthorized actions of Your agent. By acting on Your behalf, Your agent certifies that he or she is
authorized to use the Service on Your behalf, that he or she is authorized to bind You to these Terms of Use and that he or she has apprised You of these Terms of Use of this Agreement. In addition,
You are responsible for any errors made by Your agent. Registrar will not refund fees paid by You or Your agent on Your behalf for any reason, including, but not limited to, in the event that Your
agent fails to comply with these Terms of Use, Your agent incorrectly provides information in the IP Claim process or if Your agent changes or otherwise modifies Your IP Claim incorrectly. 


8.  Copyright. You acknowledge that the Service, any underlying technology used in connection with the Service, and all software, material,
information, communications, text, graphics, links, electronic art, animations, audio, video, photos, and other data (collectively, the "Content") available within the Service are provided by
Registrar or third-party providers and are the copyrighted works of Registrar and/or such third parties. Except as expressly authorized by Registrar or such third parties in these Terms of Use or as
may be posted on the Service, You may not copy, reproduce, publish, distribute, modify, create derivative works of, rent, lease, sell, transfer, display, transmit, compile or collect in a database, or
in any manner commercially exploit any part of the Content or the Service, in whole or in part. You may not store any significant portion of any Content or the Service owned by, or licensed to
Registrar in any form, whether archival files, computer-readable files, or any other medium. You also may not "mirror" any Content or the Service on any other server. 


Registrar
encourages you to download and print a reasonable number of copies of an IP Claim for noncommercial, internal use only; provided that (i) any permitted copies contain, in unmodified
form, any copyright or other proprietary rights notices and an original source attribution to the Service; and (ii) no modifications are made except as may be expressly provided by Registrar. 


9.  Links. Some links on the Service lead to sites posted by independent site owners. Because Registrar has no control over these sites, it
cannot be responsible for such sites' accessibility via the Internet and does not endorse products, services, or information provided by such sites. As such, Registrar shall not be responsible or
liable, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with, use or reliance on any content, goods or services available on or through any other
site. Further, the inclusion of these links does not imply that the other sites have given
permission for inclusion of these links, or that there is any relationship between Registrar and the linked sites. 


10.  Disclaimer of Warranty, Limitation of Liability. YOU AGREE THAT YOUR ACCESS TO AND USE OF THE SERVICE IS AT YOUR OWN RISK. NEITHER
REGISTRAR NOR TIS PARENTS, 










SUBSIDIARIES,
SHAREHOLDERS, MEMBERS, OFFICERS, DIRECTORS, EMPLOYEES, AFFILIATES, AGENTS OR SUBCONTRACTORS WARRANT THAT THE SERVICE WILL BE UNINTERRUPTED OR ERROR-FREE; NOR DO THEY MAKE ANY
WARRANTY AS TO THE RESULTS THAT MAY BE OBTAINED FROM THE USE OF THE SERVICE OR AS TO THE ACCURACY, RELIABILITY, OR CONTENT WITHIN THE SERVICE. THE SERVICE IS PROVIDED ON AN "AS IS, "AS AVAILABLE"
BASIS WITHOUT REPRESENTATIONS OR WARRANTIES OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSES AND
NON-INFRINGEMENT. 


IN
NO EVENT WILL REGISTRAR NOR ITS PARENTS, SUBSIDIARIES, SHAREHOLDERS, MEMBERS, OFFICERS, DIRECTORS, EMPLOYEES, AFFILIATES, AGENTS OR SUBCONTRACTORS BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY
INCIDENTAL, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES (EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES), ARISING OUT YOUR USE OF OR INABILITY TO ACCESS OR USE THE SERVICE, INCLUDING WITHOUT
LIMITATION, LOSS OF REVENUE OR ANTICIPATED PROFITS, LOSS OF GOODWILL, LOST BUSINESS, LOST DATA, COMPUTER FAILURE OR MALFUNCTION, OR ANY AND ALL OTHER DAMAGES OR LOSSES THAT RESULT FROM MISTAKES,
INACCURATELY ENTERED DATA, UNAUTHORIZED USE, OMISSIONS, INTERRUPTIONS, ERRORS, DEFECTS, DELAYS IN OPERATION, OR ANY FAILURE OF PERFORMANCE, WHETHER OR NOT LIMITED TO ACTS OF GOD, COMMUNICATIONS
FAILURE, THEFT, DESTRUCTION OR UNAUTHORIZED ACCESS TO INSTITUTIONS RECORDS, PROGRAMS OR SERVICES. YOU AGREE THAT THE FOREGOING LIMITATIONS OF LIABILITY REPRESENT A REASONABLE ALLOCATION OF RISK. 


IN
NO EVENT, SHALL REGISTRAR BE LIABLE TO YOU FOR ANY AMOUNT EXCEEDING THE AMOUNT OF FEES PAID BY YOU FOR THE APPLICABLE IP CLAIM. 


11.  Indemnification. You agree to indemnify and hold harmless Registrar and its parents, subsidiaries, shareholders, members, officers,
directors, employees, affiliates, agents and subcontractors from any claim or demand, including reasonable attorney's fees made by any third party due to or arising out of Your use of the Service,
your breach of these Terms of Use, any Content submitted to the Service, or any disputes involving the intellectual property rights of the Trademarks. 


12.  Modifications to the Service. Registrar reserves the right at any time and from time to time to modify or discontinue, temporarily or
permanently, the Service (or any part thereof) with or without notice. You agree that will not be liable to You or to any third party for any modification, suspension, or discontinuation of the
Services. 


13.  Termination. You may discontinue Your participation in and access to the Service at any time. These Terms of Use will continue to apply
to all past use of the Service by You, even if You are no longer using the Service. You acknowledge and agree that Registrar may terminate or block Your use of all or part of the Service without prior
notice for any reason, including, without limitation, if Registrar believes You have engaged in conduct prohibited by these Terms of Use. You agree that upon termination or discontinuance for any
reason, may delete all information related to You on the Service and may bar Your access to and use of the Service. 


14.  Governing Law. These Terms of Use shall be governed by and construed in accordance with the laws of the
[                        ], without regard to its principles of conflicts of law. 


15.  Changes to the Terms of Use. Registrar reserves the right to modify the Terms of Use at any time and from time to time. Any
modifications shall be effective upon the posting of the modified Terms of Use at www.                        . You agree to
review these Terms of Use periodically so that You are aware of any modifications.
Your continued use of the Service shall be deemed Your acceptance of the modified Terms of Use. 










16.  Severability. In the event that any provision of these Terms of Use shall be unenforceable or invalid under any applicable law or be so
held by applicable court decision, such unenforceability or invalidity shall not render this Agreement unenforceable or invalid as a whole, and, in such event, such provision shall be changed and
interpreted so as to best accomplish the objectives of such provision within the limits of applicable law or applicable court decision. 



17.  Third Party Beneficiary. Registry Operator ("NeuLevel") is an intended third party beneficiary of these Term and Conditions with rights
to enforce these Terms of Use. You will cooperate in good faith with NeuLevel or Registrar in investigating instances of non-compliance with these Terms of Use, if NeuLevel or Registrar
believes in good faith that you are not in compliance with these Terms of Use. 


18.  Subcontractors. In the course of providing the IP Claim Service, Registrar may retain independent contractors or assign or subcontract
to or otherwise have any third party perform any or all of the IP
Claim Service at any time, provided that Registrar shall continue to remain responsible for full performance of any such duties to the same extent as if it had performed the IP Claim Service itself. 


19.  Entire Agreement. These Terms of Use completely and exclusively state the agreement of the parties regarding the subject matter, and
supersede all prior agreements and understandings, whether written or oral, with respect to the subject matter of these Terms of Use. 



I
AGREE                        I DO NOT AGREE 









APPENDIX G  


 
 

Registry Operator Maximum Price Schedule  
  


This
schedule specifies the maximum price NeuLevel may charge for Registry Services under the Registry-Registrar Agreement. In a manner consistent with Section 3.4.3 of the Registry Agreement,
NeuLevel may charge a lower-than-specified rate for services, including not charging for a specified service. NeuLevel shall not be entitled to charge for any Registry Service
not specified in this Appendix G. 


1.     Maximum Domain-Name Initial Registration Fee  


NeuLevel
may charge the maximum fee per year at the time of registration for each domain name registered (the "Initial Registration Fee") in the Registry TLD or for each deferred domain name
registration, during the Term of the Registry Agreement as provided in the table below: 



	Maximum Fee

(Per Domain Name)
	 	Volume Range

(Number of Registered Names)

	US $5.30	 	0 to 4,999,999
	US $5.00	 	5,000,000 to 9,999,999
	US $4.75	 	10,000,000 +






The
Initial Registration Fee shall be paid in full by the ICANN-Accredited Registrar sponsoring the domain name at the time of registration. 


2.     Maximum Domain-Name Renewal Fee  


NeuLevel
may charge the maximum fee per year at the time of registration for each domain name registration renewal (the "Renewal Fee") in the Registry TLD during the Term of the Registry Agreement as
provided below: 



	Maximum Fee

(Per Domain Name)
	 	Volume Range

(Number of Registered Names)

	US $5.30	 	0 to 4,999,999
	US $5.00	 	5,000,000 to 9,999,999
	US $4.75	 	10,000,000 +






The
Renewal Fee shall be paid in full by the ICANN-Accredited Registrar sponsoring the domain name at the time of renewal. 


3.     Fees for Transfers of Sponsorship of Domain-Name Registrations  


During
the Term of the Registry Agreement, where the sponsorship of a domain name is transferred from one ICANN-Accredited Registrar to another ICANN-Accredited Registrar, NeuLevel may require the
registrar receiving the sponsorship to request a renewal of one year for the name. In connection with that extension, NeuLevel may charge a Renewal Fee for the requested extension as provided in item
2 above. The transfer shall result in an extension according to the renewal request, subject to a ten-year maximum on the future term of any domain-name registration. The
Renewal Fee shall be paid in full at the time of the transfer by the ICANN-Accredited Registrar receiving sponsorship of the domain name. 


For
a bulk transfer approved by ICANN under Part B of Exhibit D to the Registry-Registrar Agreement, Registry Operator may charge the gaining registrar US $0 (for transfers of 50,000
names or fewer) or US $50,000 (for transfers of more than 50,000 names). 










4.     Maximum Fee for Enhanced Whois Service  


During
the Term of the Registry Agreement, NeuLevel may introduce extended capabilities to its Whois service, as described in Appendix O to the Registry Agreement. 


These
extended service capabilities shall be made available on a subscription fee basis as follows: 



	To be negotiated with ICANN	 	Yearly Subscription Fee Rate
	To be negotiated with ICANN	 	One Time Usage Fee






5.  Maximum Fee for Start-Up Intellectual Property Notification and Domain Name Application Service


During
the Start-Up phase of the Registry TLD, NeuLevel will provide an Intellectual Property Notification and Domain Name Application service. This service is described in detail in
Appendix J to the Registry Agreement. This service shall be made available on a fee basis with maximum fees as follows: 



	US $90.00	 	Per Trademark Claim Form
	US $2.00	 	Per Domain Name Application Submission






6.     Maximum Fee for Secure Domain Name Registration Service  


During
the Term of the Registry Agreement, NeuLevel contemplates the introduction of an enhanced registration service, offered through ICANN-Accredited Registrars, utilizing secure processing
mechanisms for mission critical registrations to provide additional security measures with respect to modifications to domain name information and/or transfers of a domain name. This service is
described
in Appendix J to the Registry Agreement. This service will be offered as early as during the Start-Up phase of the Registry TLD with initial payments billed and due after the
Commencement-of-Service Date. The maximum fee charged will be as follows: 



	US $500.00	 	Per Secure Domain Name Registration






7.     Maximum Fee for Multi-Lingual Domain Registration Service  


During
the Term of the Registry Agreement, NeuLevel contemplates the introduction of a multi-lingual registration service, offered through ICANN-Accredited Registrars, allowing registrants to register
domain names in their native languages. This service will be introduced consistent with ICANN's plan on internationalized domains. The maximum fee charged will be as follows: 



	Maximum Fee

(Per Domain Name)
	 	Volume Range

(Number of Registered Names)

	To be negotiated with ICANN	 	0 to 4,999,999
	To be negotiated with ICANN	 	5,000,000 to 9,999,999
	To be negotiated with ICANN	 	10,000,000 +






The
Initial Registration Fee shall be paid in full by the ICANN-Accredited Registrar sponsoring the multi-lingual domain name at the time of registration. 


NeuLevel
may charge the maximum fee per year at the time of registration for each multi-lingual domain name registration renewal (the "Renewal Fee") in the Registry TLD during the Term of the Registry
Agreement as provided below: 



	Maximum Fee

(Per Domain Name)
	 	Volume Range

(Number of Registered Names)

	To be negotiated with ICANN	 	0 to 4,999,999
	To be negotiated with ICANN	 	5,000,000 to 9,999,999
	To be negotiated with ICANN	 	10,000,000 +











The
Renewal Fee shall be paid in full by the ICANN-Accredited Registrar sponsoring the multi-lingual domain name at the time of renewal. 


8.     Fee for Restoring Deleted Domain Name Registrations  



NeuLevel
may charge registrars the following maximum prices for each Registered Name that is restored pursuant to the Redemption Grace Period Policy set forth in Appendix C to the Registry
Agreement: 



	•
	The
cost of restoring an unintentionally deleted domain name in the Redemption Grace Period must not exceed US $40.00. 




NeuLevel
will waive the fee for restoring any Registered Name that was deleted, contrary to the wishes of the Registered Name Holder, as the result of a mistake of the Registry Operator. 



Note:
the fee for restoring deleted names is separate from, and in addition to, any Renewal Fees that may be charged pursuant to Section 2 of this appendix. 


9.     Fee Adjustments  


The
fees listed below are subject to adjustment according to the terms of Sections 3.14.5 and 4.4 of the Registry Agreement. 


 
 

FEE TABLE    
    



	Fee Type
	 	Maximum Amounts
	 	Fee Subject to Adjustment

	Registration Fee	 	US $5.30, $5.00, $4.75	 	Yes, §§ 3.14.5, 4.4
	

Renewal Fee	
 	

US $5.30, $5.00, $4.75	
 	

Yes, §§ 3.14.5, 4.4
	

Multi-Lingual Registration Fee	
 	

To be negotiated with ICANN	
 	

Yes, §§ 3.14.5, 4.4
	

Multi-Lingual Renewal Fee	
 	

To be negotiated with ICANN	
 	

Yes, §§ 3.14.5, 4.4
	

Enhanced Whois Fee	
 	

To be negotiated with ICANN	
 	

Yes, §§ 3.14.5, 4.4
	

Secure Domain Name Registration Fee	
 	

US $500	
 	

Yes, §§ 3.14.5, 4.4
	

Redemption Grace Period Restore Fee	
 	

US $40	
 	

Yes, §§ 3.14.5, 4.4











APPENDIX H  


 
 

NeuLevel Equal Access and Nondiscrimination Practice  
  


I. Equal Access and Nondiscriminatory Practice  


NeuLevel
shall provide registrars with the opportunity to register domain names in the.biz TLD pursuant to the terms and conditions of a Registry-Registrar Agreement ("RRA") to be executed between
NeuLevel and any such registrars accredited by ICANN to act as a registrar for domain names within the domain of the.biz TLD (hereinafter referred to as "ICANN-Accredited Registrars"). NeuLevel shall
provide all ICANN-Accredited Registrars (including individual NeuLevel members acting as a registrar) with equivalent access to the Registry-Registrar Protocol. NeuLevel will also make a certification
to ICANN at the end of the six month period immediately following the Effective Date of the Registry Agreement and at the end of each subsequent six month period for the Term of the Registry
Agreement, using the objective criteria set forth in the NeuLevel Equivalent Access Certification below, that NeuLevel, in its capacity as Registry Operator is providing all ICANN-Accredited
Registrars with such equivalent access. 


NeuLevel
will ensure, in a form and through ways described in the NeuLevel Equivalent Access Certification below, that the revenues and assets of the Registry Operator are not utilized to advantage
NeuLevel, its affiliates, any contractor to NeuLevel, or any owner of such contractor, to the detriment of other ICANN-Accredited Registrars. 


All
capitalized terms not otherwise defined herein shall have the meaning ascribed to them in the Registry Agreement. 


 
 

NEULEVEL EQUIVALENT ACCESS CERTIFICATION  
  




NeuLevel,
in its capacity as the Registry Operator, and on behalf of its contractors, makes the following certifications: 


1.  All
ICANN-Accredited Registrars (including NeuLevel affiliates acting as Registrars) connect to the Registry Shared Registration System using the same means available on the same terms
and conditions to any other ICANN-Accredited Registrar. 


2.  The
Registry Operator has made all registrar access software and any updates to that software available to all ICANN-Accredited Registrars at the same time and under the same term and
conditions. 


3.  All
ICANN-Accredited Registrars have the same level and means of access to Registry customer support personnel. 


4.  All
ICANN-Accredited Registrars have the same level and means of access to the NeuLevel Registry resources to resolve Registry/Registrar or Registrar/Registrar disputes and technical
and/or administrative customer service issues. 


5.  All
ICANN-Accredited Registrars have the same level and means of access to Registry Data to reconcile their registration activities. 


6.  All
ICANN-Accredited Registrars may perform basic automated registrar account management functions using the same registrar access software made available to all ICANN-Accredited
Registrars by the Registry Operator. 


7.  The
Registry Operator's Shared Registration System does not include any algorithms or protocols that differentiate among ICANN-Accredited Registrars with respect to functionality,
including database access, system priorities and overall performance. 


8.  All
Registry Operator officers, directors, shareholders, employees, agents, consultants, and contractors have been directed not to give preferential treatment to any individual
ICANN-Accredited Registrar. 














9.  The
Registry Operator has not provided preferential pricing structures, promotions or other economic terms to any individual ICANN-Accredited Registrar which are not available to all
ICANN-Accredited Registrars. 


10.  Registry
Operator has complied with the terms of the Registry Operator Code of Conduct and the Equal Access and Nondiscrimination Practice Plan. 


11.  I,
the undersigned, have taken reasonable steps to verify that the foregoing representations are true and correct. 


This
Certification is dated this the    day of                        ,
            . 


NeuLevel 




	By:	 	

	Name:	 	

	Title:	 	







II.    NeuLevel Equal Access and Nondiscriminatory Practice  


NeuLevel
and its contractors will comply with the following policies relating to Equal Access and Nondiscrimination Practice Plan (the "Plan"). 



	1.
	Section A—Equivalent Access Policy




It
is the goal of this policy to ensure that: 



1.1  All
ICANN-Accredited Registrars connect to the System using the same protocols and with the same limitations and security measures. 


1.2  All
ICANN-Accredited Registrars have the same access to customer support, administrative and business services. 


1.3  All
ICANN-Accredited Registrars have the same access to the tools required to access their data through the System including billing, account management and other similar services. 



1.4  With
the exception of systems designed to enforce NeuLevel's or ICANN's terms of service, contract or policy, the System does not include any features or systems designed to perform
prejudicially or favorably towards any specific ICANN-Accredited Registrar[s]. 



	2.
	Section B—Organizational Conflict of Interest Compliance Plan for NeuLevel





NeuLevel
has created the following processes and policies in order to achieve the goals outlined above. 



2.1  Organization Structure


NeuLevel
will comply with its Code of Conduct contained in Appendix I with respect to its organizational structure. NeuLevel will ensure it maintains the appropriate protections from
organizational conflicts of interest. Currently, Jeff Ganek is a member of the Board of Directors of Neustar and NeuLevel. NeuLevel will ensure that its directors, officers, employees, agents and
consultants are independent and derive their mandate and directions from NeuLevel Board of Directors. 


2.2  Financial Separation


NeuLevel
will ensure that separate financial statements for NeuLevel are prepared using United States GAAP accounting standards. NeuLevel's financial statements will account for its own costs,
revenues, cash flow, etc. as a separate entity, using distinct systems and accounting functions. Reasonable and independently auditable internal accounting controls will be in place to ensure the
adequacy of these systems and functions. The accounting and operational 














procedures
will be established in such a fashion that no detailed customer account information relating to any ICANN-Accredited Registrar will be available to any other ICANN-Accredited Registrar. 



2.3  Different Locations/Office Premises


NeuLevel
will conduct its business and technical operations from different premises than any ICANN-Accredited Registrar. There may be situations where technical systems might reside within the same
physical premises as an ICANN-Accredited Registrar, however these premises will not be owned by an ICANN-Accredited Registrar, will be operated by an entity not affiliated with any of them, and will
be physically and distinctly separated from each other. Any instance where NeuLevel has located or will locate technical systems in the same third party premises as an ICANN-Accredited Registrar will
be disclosed to ICANN within a commercially reasonable time period after NeuLevel is made aware of the situation. Only upon the written consent of ICANN, which shall not be unreasonably withheld or
delayed, may NeuLevel technical systems reside in any datacenter or network facility owned or controlled, in whole or in part, by an ICANN-Accredited Registrar. 


2.4  Physical Barriers


At
NeuLevel's facilities, only assigned personnel employed or contracted by NeuLevel will have regular badge access to the premises and any other person will be treated as a visitor to the facility
and will gain access only through established visitor sign-in and identification badge procedures. NeuLevel will create and maintain an entry/exit log for all persons who enter the
facility. 


2.5  Registry
Access 


NeuLevel
will provide access to all Registry customers through the mechanisms described above. 



	3.
	Section C—Information Control





NeuLevel
has in place various procedural safeguards to ensure that data and information of the registry business are not utilized to advantage one ICANN-Accredited Registrar over another. The Access
to Data Policy is attached as Exhibit A. 



3.1  Staff Training


All
NeuLevel Personnel and other employees who have a need to know NeuLevel business will undergo a formal Training Program, providing the staff members with a clear understanding of this Plan with
special attention paid to the Equivalent Access Policy and the staff members' responsibility under the plan. Formal training will be required before any potential staff member is given an assignment
or access to NeuLevel material. Formal refresher training will be given on an annual basis. 


3.2  Treatment of Information


Upon
completion of the training program, all NeuLevel Personnel and other employees who have a need to know NeuLevel business will be required to sign a non-disclosure agreement
(Exhibit B) and a NeuLevel Business Avoidance Certification (Exhibit C) acknowledging, among other things, his/her understanding of the requirements, and certifying that he/she will
strictly comply with the provisions of the Plan. The signed agreements will be maintained in the program files and the individual's personnel file. Each staff member acknowledges verification of the
annual refresher training required by this Plan. 


The
Compliance Officer (CO) will, in all cases, endeavor to ensure that NeuLevel and its employees do not release any information to any ICANN-Accredited Registrar, or their respective employees that
could be used by an ICANN-Accredited Registrar to the detriment of any other ICANN-Accredited Registrar regardless of the official stated sensitivity of the 














information.
Under no circumstances will Registry Sensitive Information be approved by the CO for release to any other ICANN-Accredited Registrar. 




 
 

EXHIBIT A
  ACCESS TO DATA POLICY    
    


1.  Purpose: To establish policies (i) for the protection of Proprietary Information developed by and/or in the possession of
NeuLevel, and (ii) for the protection of Registry Sensitive Information to ensure that the revenue and assets of NeuLevel are not unfairly utilized to advantage another ICANN-Accredited
Registrar to the detriment of other competing ICANN-Accredited Registrars. 


2.  Scope: This policy is applicable to all officers, directors, members, shareholders, employees, agents, consultants, and subcontractors
of NeuLevel. 


3.  Definitions:



3.1  Proprietary Information.  Financial, personnel, technical, or business information owned or possessed by NeuLevel which has
not been authorized for public release. Such information is frequently referred to as "Proprietary Information," "Confidential Information" or "Privileged Information." 


3.2  Registry Sensitive Information.  Any information, including Proprietary Information or other financial, personnel,
technical, or business information owned or possessed by NeuLevel relating to its business which could be utilized to advantage ICANN-Accredited Registrar to the detriment of other competing
ICANN-Accredited Registrars. Examples of Registry Sensitive Information are contained in Attachment 1 hereto. 


3.3  Computer Software.  Computer programs and computer databases. 


3.4  Computer Software Documentation.  Technical data, including computer listing and printouts, in human-readable form which
(i) document the design or details of computer software, (ii) explain the capabilities of the software, or (iii) provide instructions for using the software to obtain desired
results from a computer. 




4.     Procedures for Protection of Proprietary Information:  



4.1  Responsibility.  Managers are responsible for identifying Registry Sensitive Information developed, produced or possessed
by NeuLevel and for instructing employees reporting to them regarding the proper handling and safeguarding of such information. Each NeuLevel employee will exercise reasonable care to protect Registry
Sensitive Information from unauthorized or inadvertent disclosure. 


4.2  Disclosure.  It is recognized that there are occasions where it is necessary to disclose Proprietary Information to
outsiders. Such disclosure should not be made without the prior written approval of an authorized Corporate officer of NeuLevel. Advice from Corporate counsel should be obtained on all questions
relating to the identification or releasing of Proprietary Information or Registry Sensitive Information. 


4.3  Marking of Documents.  Documents containing Proprietary Information or Registry Sensitive Information will be marked with
one of the markings described below at the time the document(s) is produced. Computer tapes and other recorded material should be identified by proper labeling which is visible to the ordinary person
while the material is being stored. In addition, all such material should have a warning notice at the beginning of the material to ensure the user is forewarned about the proprietary or sensitive
nature of its contents (as soon as access is afforded to a computer tape or at the beginning of a sound recording, etc.). 



4.3.1  Internal Documents.  On internal documents (reports, memoranda, drawings, etc.) the applicable following legend shall be
put at the top or bottom of the first page or, in the case 











of
drawings, in the space provided for such legends. The "need to know" principle shall be the guideline when divulging Proprietary Information or Registry Sensitive Information internally. 




 
 

NeuLevel Proprietary Information    
    





The information on this document is proprietary to NeuLevel. It may not be used, reproduced or disclosed without the written approval of NeuLevel.





 
 

NeuLevel Registry Sensitive Information    
    





The information on this document is proprietary to NeuLevel. It may not be used, reproduced or disclosed without the written approval of the Compliance Officer of
NeuLevel.




4.3.2  Documents for External Distribution



	A.
	Reports and Similar Documents








The
following legend shall be typed or stamped on the cover and/or title page of reports or on the face of other documentation provided to others: 





 
 

NeuLevel Proprietary Information    
    





This document is the property of NeuLevel. It may be used by recipient only for the purpose for which it was transmitted and shall be returned upon request or when no longer
needed by recipient. It may not be copied or communicated without the prior written consent of NeuLevel.


	B.
	Letters






On
letters to third parties or outsiders which will contain Proprietary Information, the following statement or equivalent shall appear in the text: 


Information contained herein is NeuLevel Proprietary Information and is made available to you because of your interest in our company (or program, etc.). This information is
submitted in confidence and its disclosure to you is not intended to constitute public disclosure or authorization for disclosure to other parties.


	C.
	Proposals to Commercial Companies







1.  A
restrictive legend such as the following shall be placed on the title page of each volume of the proposal: 




NeuLevel's proposal, which follows, contains information and data that are privileged and/or confidential to NeuLevel. This information and data are not made available for
public review and are submitted voluntarily to XYZ COMPANY NAME only for purposes of review and evaluation in connection with this proposal. No other use of the information and data contained herein
is permitted without the express written permission of NeuLevel. Information and data contained herein is protected by the Uniform Trade Secrets Act, as codified, and any improper use, distribution,
or reproduction is specifically prohibited. No license of any kind whatsoever is granted to any third party to use the information and data contained herein unless a written agreement exists between
NeuLevel and the third party which desires access to the information and data. Under no condition should the information and data contained herein be provided in any manner whatsoever to any third
party without the prior written permission of NeuLevel. The data subject to this restriction is contained in pages            .














2.  Each
page of the proposal which contains Proprietary Information shall be marked as follows: 




Use or disclosure of proposal information is subject to the restriction on the title page of this proposal.


	D.
	Proprietary Information Released Pursuant to Contract







When
Proprietary Information is exchanged between NeuLevel and another company, a Confidentiality Agreement or Non-Disclosure Agreement shall be executed by the parties concerned. 


1.  The
parties will designate in writing one or more individuals within their own organization as the only person(s) authorized to receive Proprietary Information exchanged between the
parties pursuant to this Agreement (see Attachment 2 for sample agreement.). 


2.  All
information which the disclosing party claims as proprietary shall be received in writing, clearly identified as proprietary, and delivered personally or by mail addressed to
individuals designated above to receive the Proprietary Information. 







5.     Safekeeping  


When
not in use, Proprietary Information or Registry Sensitive Information will be stored in a locked desk, cabinet or file. Such material will not be left unattended during the workday and should be
turned face down in the presence of visitors or employees who have no need to know. 



6.     Destruction  


Burning,
shredding or comparable methods will be used for the destruction of Proprietary Information or Registry Sensitive Information. 


7.     Terminating Employees  


Terminating
employees will be reminded of their responsibilities and obligations in protecting Proprietary Information. All employees will execute a non-disclosure agreement specifying
that they may not retain or otherwise use such information after termination. Any deviation from this policy must be approved in writing by NeuLevel counsel and NeuLevel. 


8.     Third-Party Proprietary Information  


Proprietary
Information received from other companies through contractual or pre-contractual relationships will be afforded the same level of protection given to NeuLevel's Proprietary
Information. 


9.     Questions  


Questions
concerning implementation or interpretation of this policy will be referred to the appropriate General Manager or the General Counsel. 







 
 

ATTACHMENT 1
  Examples of Proprietary & Registry Sensitive Information    
    


Engineering Information  


Engineering
information, including schematics, code, and engineering notes will be considered Proprietary Information. 


Statistical Information  


Some
statistical information will be available for public consumption. Such information does not require any special treatment, so long as neither NeuLevel nor any ICANN-Accredited Registrar, receives
any preferential treatment (e.g., early access to such information). Other statistics, such as numbers of registrations, transfers, etc., performed by each registrar, as well as processing times,
numbers of failures or any information that is trending negative or contains negative performance factors not generally available to the public should be considered Registry Sensitive Information. 


One
area of statistical data that is deserving of special attention is Registry Information pertaining to the numbers of registrations, transfers, etc., performed by each registrar. All such
information is Registry Sensitive Information and will be treated accordingly. Unless otherwise approved, registration activity information must be protected from disclosure to any registrar other
than the registrar to which the information refers. 


Financial Information  


Financial
data related to NeuLevel is Registry Sensitive Information and will not be released without the express consent of the General Manager of NeuLevel. Monthly expenses and income shall be kept
sensitive and restricted from disclosure to any party other than the appropriate NeuLevel staff. 


 
 

ATTACHMENT 2
  NON-DISCLOSURE AGREEMENT
  Proprietary Information    
    


This
is an Agreement, effective                            , 2000 between NeuLevel, Inc., (hereinafter
referred to as "NeuLevel") and                        (hereinafter referred to as
"                        "). It is recognized that it may be necessary or desirable to exchange information between NEULEVEL
and                        for the purpose
of                                         
       . With respect
to the information exchanged between the parties subsequent to this date, the parties agree as follows: 



(1)  "Proprietary
Information" shall include, but not be limited to, performance, sales, financial, contractual and special marketing information, ideas, technical data and concepts
originated by the disclosing party, not previously published or otherwise disclosed to the general public, not previously available without restriction to the receiving party or others, nor normally
furnished to others without compensation, and which the disclosing party desires to protect against unrestricted disclosure or competitive use, and which is furnished pursuant to this Agreement and
appropriately identified as being proprietary when furnished. 


(2)  In
order for proprietary information disclosed by one party to the other to be protected in accordance with this Agreement, it must be: (a) in writing or in electronic form;
(b) clearly identified as proprietary information at the time of its disclosure by each page thereof being marked with an appropriate legend indicating that the information is deemed
proprietary by the disclosing party; and (c) delivered by letter of transmittal, hand delivery, or electronically transmitted to the individual designated in Paragraph 3 below, or his
designee. Where the proprietary information has not been or cannot be reduced to written or electronic form at the time of disclosure and such disclosure is made orally and with prior assertion of
proprietary rights therein, such orally disclosed proprietary information shall only be protected in accordance with this Non-Disclosure Agreement provided that complete written summaries
of all proprietary aspects of any such oral disclosures shall have been delivered to the individual identified in 












Paragraph 3
below, within 20 calendar days of said oral disclosures. Neither party shall identify information as proprietary which is not in good faith believed to be confidential, privileged,
a trade secret, or otherwise entitled to such markings or proprietary claims. 


(3)  In
order for either party's proprietary information to be protected as described herein, it must be submitted in written or electronic form as discussed in Paragraph 2 above
to: 



	NeuLevel, Inc.	 	

	

Name: Jeffrey J. Neuman, Esq.	
 	

Name:
	 	 	

	

Title: Director, Law & Policy	
 	

Title:
	 	 	

	

Address: 1120 Vermont Ave., NW Fourth Floor, Washington, D.C. 20005	
 	

Address:
	 	 	

	

Telephone No: (202) 533-2733	
 	

Telephone No:
	 	 	

	

FAX No: (202) 533-2970	
 	

FAX No:
	 	 	







(4)  Each
party covenants and agrees that it will keep in confidence, and prevent the disclosure to any person or persons outside its organization or to any unauthorized person or persons,
any and all information which is received from the other under this Non-Disclosure Agreement and has been protected in accordance with paragraphs 2 and 3 hereof; provided however, that a
receiving party shall not be liable for disclosure of any such information if the same: 



A.  Was
in the public domain at the time it was disclosed, 


B.  Becomes
part of the public domain without breach of this Agreement, 


C.  Is
disclosed with the written approval of the other party, 


D.  Is
disclosed after three years from receipt of the information, 


E.  Was
independently developed by the receiving party, 


F.  Is
or was disclosed by the disclosing party to a third party without restriction, or 


G.  Is
disclosed pursuant to the provisions of a court order. 




As
between the parties hereto, the provisions of this Paragraph 4 shall supersede the provisions of any inconsistent legend that may be affixed to said data by the disclosing party, and the
inconsistent provisions of any such legend shall be without any force or effect. 


Any
protected information provided by one party to the other shall be used only in furtherance of the purposes described in this Agreement, and shall be, upon request at any time, returned to the
disclosing party. If either party loses or makes unauthorized disclosure of the other party's protected information, it shall notify such other party immediately and take all steps reasonable and
necessary to retrieve the lost or improperly disclosed information. 


5)  The
standard of care for protecting Proprietary Information imposed on the party receiving such information, will be that degree of care the receiving party uses to prevent disclosure,
publication or dissemination of its own proprietary information, but in no event less than reasonable care. 


(6)  Neither
party shall be liable for the inadvertent or accidental disclosure of Proprietary Information if such disclosure occurs despite the exercise of the same degree of care as such
party normally takes to preserve its own such data or information. 



(7)  In
providing any information hereunder, each disclosing party makes no representations, either express or implied, as to the information's adequacy, sufficiency, or freedom from
defect of any kind, including freedom from any patent infringement that may result from the use of such 












information,
nor shall either party incur any liability or obligation whatsoever by reason of such information, except as provided under Paragraph 4, hereof. 


(8)  This
Non-Disclosure Agreement contains the entire agreement relative to the protection of information to be exchanged hereunder, and supersedes all prior or
contemporaneous oral or written understandings or agreements regarding this issue. This Non-Disclosure Agreement shall not be modified or amended, except in a written instrument executed
by the parties. 


(9)  Nothing
contained in this Non-Disclosure Agreement shall, by express grant, implication, estoppel or otherwise, create in either party any right, title, interest, or
license in or to the inventions, patents, technical data, computer software, or software documentation of the other party. 


(10)  Nothing
contained in this Non-Disclosure Agreement shall grant to either party the right to make commitments of any kind for or on behalf of any other party without the
prior written consent of that other party. 


(11)  The
effective date of this Non-Disclosure Agreement shall be the date upon which the last signatory below executes this Agreement. 


(12)  This
Non-Disclosure Agreement shall be governed and construed in accordance with the laws of the Commonwealth of Virginia. 


(13)  This
Non-Disclosure Agreement may not be assigned or otherwise transferred by either party in whole or in part without the express prior written consent of the other
party, which consent shall not unreasonably be withheld. This consent requirement shall not apply in the event either party shall change its corporate name or merge with another corporation. This
Non-Disclosure Agreement shall benefit and be binding upon the successors and assigns of the parties hereto. 



(14)  It
is further understood and agreed that money damages would not be a sufficient remedy for any breach of this agreement by either party or any of its representatives and that the
non-breaching party shall be entitled to equitable relief, including injunction and specific performance, as a remedy for any such breach. Such remedies shall not be deemed to be the
exclusive remedies for a breach of this agreement but shall be in addition to all other remedies available at law or equity. In the event of litigation relating to this agreement, if a court of
competent jurisdiction determines that either party or any of its representatives have breached this agreement, then the breaching party shall be liable and pay to the non-breaching party
the reasonable legal fees incurred in connection with such litigation, including an appeal therefrom. 



	NeuLevel, Inc.	 	

	

By:	
 	

	
 	

By:	
 	


	

Name:	
 	

	
 	

Name:	
 	


	

Title:	
 	

	
 	

Title:	
 	


	

Date:	
 	

	
 	

Date:	
 	












 
 

EXHIBIT B
  NON-DISCLOSURE AGREEMENT    
    


I
understand I am an employee of NeuLevel, Inc. ("NeuLevel") or another employee who has a need to know information related to NeuLevel which is proprietary, confidential or business sensitive,
belonging to NeuLevel, other companies or customers of NeuLevel. I agree not to disclose or otherwise disseminate such information to anyone other than Need to Know Employees, except as directed, in
writing, by                        of NeuLevel or his/her designee ("Compliance Officer"). I understand
that disclosure of such information to anyone other than a Need to Know
Employee or use of such information could result in personal liability for such unauthorized use or disclosure.


I
agree to use such proprietary, confidential and/or business sensitive information only in the performance of requirements necessary to carry out my duties as a Need to Know Employee, and I agree to
take suitable precautions to prevent the use or disclosure of such information to any party, other than Need to Know Employees. I will report to the Compliance Officer any potential violation of this
agreement. I further agree to surrender any and all data and information, of any type whatsoever,
to the Compliance Officer upon the termination of my employment as an employee of NeuLevel, or my assignment with NeuLevel. 


I
certify that I have read and fully understand this Non-Disclosure Agreement and agree to abide by all requirements contained herein. I understand that my strict compliance is essential
to NeuLevel, and any violation of these requirements may result in termination of my employment. 



	Agreed to:	 	Verified:
	

 Employee	
 	

 General Manager, Registry
	

Date	
 	

Date





 
 

EXHIBIT C
  REGISTRY BUSINESS ORGANIZATIONAL CONFLICT OF INTEREST AVOIDANCE CERTIFICATION    
    


I
hereby certify that I have received training in and understand the requirements of conflict of interest issues and the requirements of the Organizational Conflict of Interest Compliance Plan of the
Registry Business of NeuLevel, LLC. I certify that I will strictly comply with the provisions of this Plan. I understand my obligation to (i) refrain from any activities which could pose a
personal conflict of interest and (ii) report to the General Manager of the Registry Business, any conflict, whether personal or organizational, which is perceived or identified during the
course of my employment with the Registry Business. 



	CERTIFIED	 	 
	

 signature date	
 	

 
	

 name	
 	

 











APPENDIX I  


 
  REGISTRY CODE OF CONDUCT  
  


NeuLevel
will at all times operate as a trusted neutral third-party provider of Registry Services. NeuLevel recognizes that domain names are the means by which businesses, consumers, and individuals
gain access to, navigate, and reap the benefits of the global Internet. These benefits cannot be fully realized, however, unless DNS resources are administered in a fair, efficient, and neutral manner
that makes them available to all parties desiring to provide DNS services. Therefore, in its provision of neutral Registry Services, NeuLevel will comply with the following Registry Code of Conduct. 


1.  Other
than in connection with the distribution of dividends or other profits to NeuLevel's members and shareholders, NeuLevel will not, and will require that its subcontractors do not,
directly or indirectly, show any preference or provide any special consideration to any DNS registry operator or ICANN-Accredited Registrars in the.biz Registry versus any other DNS registry operator
or ICANN-Accredited Registrars in the.biz Registry, as those terms are defined by ICANN, including the registry or registrar owned by a member of NeuLevel. 


2.  All
ICANN-Accredited Registrars in the.biz Registry shall have equal access to Registry Services provided by NeuLevel as set forth in Appendix H. 


3.  NeuLevel
and its owners shall not in any way attempt to warehouse domain names. In addition, Registry Operator shall not attempt to register domain names in its own right, except for
names designated for operational purposes in compliance with Subsection 3.6 of the Registry Agreement. In its Monthly Report to ICANN, NeuLevel shall include a list of all names designated for
operational purposes. 


4.  Any
shareholder, subsidiary, affiliate, or other related entity of NeuLevel that also operates as a provider of registrar services shall maintain separate books of account with respect
to its registrar operations separate from those of NeuLevel. 


5.  Neither
NeuLevel, nor its shareholders, subsidiaries, affiliates, or other related entities shall have access to user data or proprietary information of an ICANN-Accredited Registrar,
except as necessary for registry management and operations. 


6.  NeuLevel
will ensure that no user data or proprietary information from any ICANN-Accredited Registrar is disclosed to its affiliates, subsidiaries, or other related entities, except as
necessary for registry management and operations. 


7.  Confidential
information about NeuLevel's business services will not be shared with employees of any DNS registry operator or ICANN-Accredited Registrars, except (i) as
necessary for registry management and operations or (ii) if such information is made available to all DNS registry operator employees and ICANN-Accredited Registrars on the same terms and
conditions. 


8.  No
member of NeuLevel's Board of Directors will simultaneously serve on the Board of Directors of an ICANN-Accredited Registrar that obtains Registry Services from NeuLevel. 


9.  No
employee of NeuLevel will hold a greater than 5% interest, financial or otherwise in a company that obtains Registry Services from NeuLevel. 


10.  No
employee of NeuLevel will also be an employee of any NeuLevel subsidiary, affiliate or other related entity that also operates as an ICANN-Accredited Registrar. 


11.  NeuLevel
will ensure that no user data from or proprietary information of any registry operated or controlled by NeuLevel is disclosed to any other registry operated or controlled by
NeuLevel. 


12.  NeuLevel
will conduct internal neutrality reviews on a regular basis. In addition, NeuLevel and ICANN may mutually agree on an independent party ("Neutrality Analyst") that ICANN may
hire, at ICANN's expense, to conduct a neutrality review of NeuLevel, ensuring that NeuLevel and its owners comply with all the provisions of this Registry Operator Code of Conduct. The neutrality
review may be conducted as often as once per year. NeuLevel will provide the Neutrality Analyst with reasonable access to information and records appropriate to complete the review. The results of the
review of the Neutrality Analyist will be provided to ICANN and shall be deemed to be confidential and proprietary information of NeuLevel and its owners. 









APPENDIX J  


 
  Registry TLD Start-Up Plan  
  


Registry
Operator will follow a multi-phased start-up procedure for.biz. These phases have been designed to ensure fairness and equity to all ICANN-Accredited Registrars, resellers,
potential registrants and registrants, and to reflect the diverse needs of these constituencies and the Internet Community. The approximate commencement date of the phases are set forth below: 



	

	PHASE
 
	 	ESTIMATED AVAILABILITY TO CUSTOMERS
 

	

	Phase 1: Start-Up Intellectual Property Notification and Domain Name Application	 	•	 	Acceptance of Trademark Claim Forms: 150 days prior to Commencement-of-Service Date.
	Service	 	•	 	Last Day to Submit Trademark Claim Forms: 110 days prior to Commencement-of-Service Date
	 	 	•	 	Acceptance of Domain Name Application submissions: 110 days prior to Commencement-of-Service Date
	 	 	•	 	Last day to submit Domain Name Applications before Landrush: 15-30 days prior to Commencement-of-Service Date
	

	Phase 2: Landrush	 	•	 	15-30 days prior to Commencement-of-Service Date
	

	Phase 3: Registry Live	 	Occurs on Commencement-of-Service Date:
	 	 	•	 	WHOIS service available
	 	 	•	 	DNS service available
	 	 	•	 	Registration of domain names on first-come, first-served basis begins
	 	 	•	 	Commencement of 30 day "Hold Period" for domain names that are subject to SIPN
	






This
Appendix describes the Start-Up Intellectual Property Notification and Domain Name Application Service, and the Landrush process. The Registry Live phase is described more fully in
Appendix C. NeuLevel will develop proprietary systems to support the first two phases of operation of the Registry. The systems for these phases are being developed specifically for the
purposes described below and are not intended to be supported after the Commencement-of-Service Date. The time frames contemplated herein are approximate and subject to change
with advance notice to ICANN and the Internet community. All final dates will be published on our website. 


Phase 1: Intellectual Property Notification and Domain Name Application Service  


The
Start-Up Intellectual Property Notification and Domain Name Application Service is designed to assist entities with intellectual property rights in trademarks and service marks
("Trademarks") in protecting their rights in the context of new TLDs and expected significant number of applications for new second level domain names. As more fully described below, each domain name
application in the.biz TLD submitted through an ICANN-Accredited Registrar will be compared to a database of Trademark claim forms operated by the Registry Operator. For each match between the domain
name for an application and a string identified on a Trademark Claim Form (as defined below) notifications will be provided that entities have claimed intellectual property rights over that domain
name. 



	A.
	Trademark Claim Form Submission






The
Start-up Intellectual Property Notification service ("SIPN") will begin approximately 150 days prior to the Commencement-of-Service Date, Registry
Operator will advise the public about the SIPN service by publishing detailed information for the general public that describes the SIPN process on its own website as well as make available to ICANN
to publish on its website. For a period of approximately thirty (30) to forty-five (45) days beginning approximately 110 days prior to the 








Commencement-of-Service
Date ("Claim Period"), Trademark owners ("Claimants") will be afforded the opportunity to fill out and submit "Trademark Claim Forms" which will set out
the following information: 



(i)  The.biz
domain name in which the Trademark owner is claiming intellectual property rights. This domain name must be identical to the alphanumeric string contained in the mark; 



(ii)  Exact
alphanumeric string contained in the trademark in which rights are claimed; 


(iii)  Trademark
holder entity contact information; 


(iv)  Trademark
holder representative's contact information and relationship to trademark holder entity (i.e., General Counsel, President, CEO, etc.); 


(v)  Description
of goods and services for which the exact Trademark is being used; 


(vi)  Date
of first use of the Trademark in commerce; and 


(vii)  If
the mark is registered with any national Trademark office, registration number, and country where registration was obtained (optional). 




There
shall be no restriction on the number of intellectual property owners that may file Trademark Claim Forms for a given domain name. Trademark owners may not submit a Trademark Claim Form after
the Claim Period. 


The
Registry Operator will not, however: 



	•
	Verify
whether a claim corresponds with an actual Trademark.



	•
	Provide
legal oversight or adjudication.



	•
	Guarantee
or represent that a Trademark owner who enrolls in the SIPN ("Claimant") will receive the actual domain name. 




Due
to the administrative requirements associated with comparing Trademark Claim Forms with domain name applications, and the limited duration of the SIPN process, the Registry Operator, and not
ICANN-Accredited Registrars will be responsible for managing and administering the SIPN service. In conjunction with the various marketing channels of Registry Operator, ICANN-Accredited Registrars
may also be afforded the opportunity to participate in the marketing of the SIPN service in accordance with Registry Operator's Equal Access Requirements and Code of Conduct, as set forth in
Appendices H and I respectively. The SIPN service will be offered on a fixed fee per Trademark Claim Form basis. The amount of the SIPN fee will be published by Registry Operator prior to the
commencement of the SIPN service, but in no event will the fee exceed the maximum amount set forth in Section 6 of Appendix G. This fee will be collected by the Registry Operator, or its
designee at the time that the Trademark Claim Form is submitted. 


Claimants
will submit a Trademark Claim Form for each separate Trademark for which they are claiming intellectual property rights via a website. This website will be accessible 24 hours per day
and will provide information about the SIPN, the Pre-registration, Landrush and SRS live phases, and a link to any relevant dispute resolution services. Claimants will receive
e-mail notification acknowledging receipt of the Trademark Claim Form. 


Submission
of a Trademark Claim Form does not create any special rights with respect to registering a particular domain name. Any Claimant wishing to register a domain name must also submit a separate
domain name application as described below. In addition to the Trademark Claim Form, the Claimant must also submit an Application (as described below) in order to be eligible to have a chance at
receiving the actual domain name. The submission of a Trademark Claim Form does not guarantee that the Claimant will receive the actual domain name. 










	B.
	Domain Name Application Submission




After
the end of the Claim period set forth above, and for a period of approximately ninety days thereafter, ICANN-Accredited Registrars will collect from those individuals or entities applying for
a.biz domain name ("Applicants") and provide to the Registry Operator the applications for domain name registrations in the Registry TLD ("Applications"). 



	•
	Prior
to the commencement of the submission of domain name Applications, the Registry Operator will have:



	•
	Agreements
with ICANN-Accredited Registrars;



	•
	Completed
testing with these ICANN-Accredited Registrars as set forth below;



	•
	Established
Customer Support processes and procedures for ICANN-Accredited Registrars as set forth in Appendix C;



	•
	Established
processes and procedures for billing, order entry, reporting and operations support;



	•
	A
website that will support secure transactions from Registrars, including posting of reports for ICANN-Accredited Registrars;



	•
	A
website that provides information to potential domain name Applicants;



	•
	Customer
Care support;



	•
	Escalation
processes and procedures for ICANN-Accredited Registrars; and



	•
	Debit
and billing capabilities. 




ICANN-Accredited
Registrars and Applicants will be advised that a minimum subscription of two (2) years will be required for domain name registrations granted during Landrush, and that a
non-refundable fixed fee for each domain name Application will be assessed. Such application fee shall not exceed the amount set forth in Appendix G. This fee is separate and in
addition to the Domain Name Initial Registration Fee set forth in Section 1 of Appendix G. 


Only
ICANN-Accredited Registrars that have completed testing with the Registry Operator will be permitted to submit Applications. The technical requirements placed on ICANN-Accredited Registrars
during Phases 1 and 2 will be significantly less than that required once the Registry enables the XRP protocol post-Landrush (as set forth below). During this start-up period,
ICANN-accredited Registrars must pass a start-up-phase technical acceptance test provided by the registry. The start-up-phase acceptance test will
involve: 



	•
	Creation
of batch files



	•
	Submission
of batch files



	•
	Validation
of submitted files against format and syntactic rules 




ICANN-Accredited
Registrars will be granted start-up-phase system access after submitting a batch file correctly conforming to the structure and syntax required by the Registry
Operator. ICANN-Accredited Registrars will be responsible for developing the necessary interface with their customers. The Registry Operator will develop an API that the ICANN-Accredited Registrars
will use to interface with the Registry Operator's systems. ICANN-Accredited Registrars will use a batch process to submit domain name applications to the Registry Operator. The file format, transport
method, and processing schedule will be provided in advance to the ICANN-Accredited Registrars. The Registry Operator will check the file format and integrity of each batch file to determine if it is
readable. If the batch file is not readable, the ICANN-Accredited Registrar will be notified and given an opportunity to resubmit the batch file. 


When
submitting its domain name application, the applicant will be given the opportunity to purchase NeuLevel's Secure Domain Name Registration Service. In the event that an applicant obtains the
domain name in question through the Landrush process described below, the service will be activated 










and
the domain name holder billed after the Commencement-of-Service Date. The Secure Domain Name Registration Service will be designed to provide a higher level of domain name
security to businesses with a mission critical domain name. Although domain names enrolled in the service will be subject to the restrictions and requirements of the.biz TLD, a secure registration
will be maintained in a "locked" status so that no changes to the information about the name may be modified absent affirmative approval obtained from the registrant by the Registry Operator. This
service will minimize the likelihood that a domain name will be hijacked or otherwise made unavailable either intentionally or through administrative error. The Secure Domain Name Service will be
offered on a 5-year term subject to the maximum fee set forth in Appendix G. 


Prior
to Landrush, each Application received by the Registry Operator will be compared to the Trademark Claim Form database. For each match between an Application and a Trademark Claim Form, the
Registry Operator will notify the applicant and the ICANN-Accredited Registrar through which the applicant filed an Application, that a third party, or parties, has submitted a claim for the exact
string requested. The notification to the Applicant will include, among other things, the information provided by Claimant in the Trademark Claim Form, instructions on how to proceed with the
registration process, notification that the domain name will automatically placed "On Hold" (as described below) if the name is registered. This notification is provided to all Applicants that apply
for the same string in the Application and does not guarantee ultimate registration by that Applicant of the domain name during Landrush. 


The
e-mail notification to the Applicant will provide a link to a secure site where the Applicant will go to confirm whether it wishes to proceed with the domain name application. The
Applicant will have the option to proceed with the application or cancel. If the Applicant does not respond to the e-mail notification from the Registry Operator, or elects to cancel the
Application, the Application will not be processed during Landrush, thus making the Applicant ineligible to register the actual domain name. If the Applicant affirmatively elects to continue the
application process after being notified of the Claimant(s) alleged trademark rights in the desired domain name, Registry Operator will provide confirmation to the Applicant as well as the ICANN-
Accredited Registrar through which the Applicant filed the Application, confirming the decision to pursue the domain name during Landrush. 


Phase 2: Landrush  


The
Landrush phase will begin approximately fifteen (15) to thirty (30) days prior to the Commencement-of-Service Date, depending on the number of Applications
received by the Registry Operator. The final date will be published on Registry Operator's website. All of the Applications from all ICANN-Accredited Registrars received by the Registry Operator will
be combined and randomized in a single batch for Landrush processing. This process will ensure fairness for each ICANN-Accredited Registrar and Applicant. In order to assure the ICANN-Accredited
Registrar community and the public that the results will be truly random, NeuLevel will apply a randomization algorithm to the batch. The requirement of the randomization algorithm is to ensure that
submitted domain names are completely randomized, without bias to any ICANN-Accredited Registrar. 


The
duration of processing during the Landrush phase will depend on the number of Applications received and placed in the processing queue. Domain name requests will be processed in the order in which
they appear in the randomized batch. After the processing of all Applications, each ICANN-Accredited Registrar will be notified of the domain names granted for that ICANN-Accredited Registrar's
customers. It will be the responsibility of the ICANN-Accredited Registrar to notify its customers whether they received the name(s) for which they submitted Applications. 


Registry
Operator will not guarantee that any individual Applicant or ICANN-Accredited Registrar will obtain a given name, nor will it accept any liability for errors, mistakes, omissions or technical
problems that arise with the Start-up Process. 


ICANN-Accredited
Registrars will be responsible for payment for each domain name that is successfully registered. This registration fee will be separate from the non-refundable fixed
application fee submitted during Phase 1 above. The Registry Operator will deduct payment from a debit account 










pre-funded
by each ICANN-Accredited Registrar. Domain names registered during the Landrush period will be registered for two (2) years. 


Phase 3: Registry Live  


Registry
Live begins on the Commencement-of-Service Date and will include the services and functionality described in Appendix C. 



	A.
	ICANN-Accredited Registrar Testing for Registry Live. 




Before
being granted access to the Registry-Live system, ICANN-Accredited Registrars will be required to pass a more extensive acceptance test than for Phases 1 and 2 described above. It
will require that ICANN-Accredited Registrars pass an XRP acceptance test which will involve: 



	•
	Connecting
to the registry and establishing a session



	•
	Passing
the authentication/authorization process



	•
	Executing
a script testing each XRP function at least once



	•
	Disconnecting
from the system 




The
Registry Operator will record a transaction log documenting the ICANN-Accredited Registrar's interaction with the Registry Operator. The ICANN-Accredited Registrar will be granted full access to
the system after successfully passing this test. 



	B.
	Commencement of Service. 




As
of the Commencement of Service Date, all domain names granted during the Landrush phase will be activated in the DNS unless such names are subject to the Hold Period described below. 



	C.
	Registration Hold Period. 




The
registration in the live registry of a domain name that is the subject of a complete Trademark Claims Form will not be immediate, but rather the subject domain name registration will automatically
enter a thirty (30) day Hold Period during which all Claimants will be advised by e-mail of the identity of the person or entity that has registered the exact Trademark claimed. The
notification e-mail will include the full WHOIS information of the registrant. In addition, the e-mail will provide a hyperlink to the Start-Up Uniform Dispute
Resolution Process ("SUDRP") as described in Appendix M to the Registry Agreement. 


During
this Hold Period, the domain name will not be activated in the DNS. Should a notified party file a contest to the registration in the formal SUDRP process, the domain name would be
"locked" until the dispute is decided. During such "locked" period, in accordance with the current Uniform Dispute Resolution Policy, modification by the registrant of the domain name information
(i.e. holder, contact information, etc.) will not be permitted, however, the domain name will resolve to the DNS after the Hold Period set forth above. 


Disclaimer of Warranties  


REGISTRY
OPERATOR DOES NOT MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES RENDERED BY ITSELF, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR WORK, INCLUDING,
WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE. 









APPENDIX K  


 
  Schedule of Reserved Names  
  


Except
to the extent that ICANN otherwise expressly authorizes in writing, the Registry Operator shall reserve names formed with the following labels from initial (i.e. other than renewal)
registration within the TLD: 


A. Labels Reserved at All Levels. The following names shall be reserved at the second level and at all other levels within the TLD at which Registry
Operator makes registrations: 




ICANN: 



	•
	aso



	•
	dnso



	•
	icann



	•
	internic



	•
	pso






IANA-related
names: 



	•
	afrinic



	•
	apnic



	•
	arin



	•
	example



	•
	gtld-servers



	•
	iab



	•
	iana



	•
	iana-servers



	•
	iesg



	•
	ietf



	•
	irtf



	•
	istf



	•
	lacnic



	•
	latnic



	•
	rfc-editor



	•
	ripe



	•
	root-servers 




B. Additional Second-Level Reservations. In addition, the following names shall be reserved at the second level: 



	•
	All
single-character labels.



	•
	All
two-character labels shall be initially reserved. The reservation of a two-character label string shall be released to the extent that the
Registry Operator reaches agreement with the government and country-code manager, or the ISO 3166 maintenance agency, whichever appropriate.The Registry Operator may also propose release
of these reservations based on its implementation of measures to avoid confusion with the corresponding country codes. 











	•
	aero



	•
	arpa



	•
	biz



	•
	com



	•
	coop



	•
	edu



	•
	gov



	•
	info



	•
	int



	•
	mil



	•
	museum



	•
	name



	•
	net



	•
	org



	•
	pro





C. Tagged Domain Names. All labels with hyphens in the third and fourth character positions (e.g., "bq—1k2n4h4b") 


D. Second-Level Reservations for Registry Operations. The following names are reserved for use in connection with the operation of the registry for the
Registry TLD. They may be used by Registry Operator under Subsection 3.6.1, but upon conclusion of Registry Operator's designation as operator of the registry for the Registry TLD they shall be
transferred as specified by ICANN: 



	•
	nic



	•
	whois



	•
	www















APPENDIX L  


 
  .biz Registration Restrictions  
  


Restrictions  


Registrations
in the.biz TLD will be subject to the following restrictions: 



1.  Registrations
in the.biz TLD must be used or intended to be used primarily for bona fide business or commercial purposes; and 


2.  Registrations
in the.biz TLD must comply with the Uniform Dispute Resolution Policy ("UDRP"), as adopted and as may be amended by the Internet Corporation of Assigned Names and
Numbers. For proceedings intitiated before the Commencement-of-Service Date, a modified version of the UDRP, known as the Start-Up Uniform Dispute Resolution Policy
("SUDRP") (which also includes corresponding modifications to the Rules for Uniform Domain Name Resolution Policy) will apply. 




For
purposes of the.biz Registration Restrictions ("Restrictions"), "bona fide business or commercial use" shall mean the bona fide use or bona fide intent to use the domain name or any content,
software, materials, graphics or other information thereon, to permit Internet users to access one or more host computers through the DNS: 



1.  To
exchange goods, services, or property of any kind; 



2.  In
the ordinary course of trade or business; or 


3.  To
facilitate (i) the exchange of goods, services, information, or property of any kind; or, (ii) the ordinary course of trade or business. 




Registering
a domain name solely for the purposes of (1) selling, trading or leasing the domain name for compensation, or (2) the unsolicited offering to sell, trade or lease the domain
name for compensation shall not constitute a "bona fide business or commercial use" of that domain name. 



For
illustration purposes, the following shall not constitute a "bona fide business or commercial use" of a domain name: 



1.  Using
or intending to use the domain name exclusively for personal, noncommercial purposes; or 


2.  Using
or intending to use the domain name exclusively for the expression of noncommercial ideas (i.e., registering abcsucks.biz exclusively to criticize or otherwise express an opinion
on the products or services of ABC company, with no other intended business or commercial purpose). 




Violations  


It
will be a violation of the Restrictions for an Applicant to: 



1.  register
or use a domain name contrary to the SUDRP; 


2.  register
and use a domain name contrary to the UDRP; or 


3.  use
the registered domain name in a manner inconsistent with the definition of "business or commercial use" contained herein. 




Violations
of the Restrictions may be grounds for cancellation of a registered.biz domain name, pursuant to the enforcement mechanism discussed below. 








Enforcement  


A
violation of the Restrictions will be enforced on a case-by-case, fact specific basis under the processes set forth below: 



1.  Any
allegation that a domain name is not used primarily for business or commercial purposes shall be enforced under the provisions of the Restrictions Dispute Resolution Process
("RDRP") as set forth in Appendix M. 


2.  Any
alleged violation of the UDRP shall be enforced under the provisions contained therein, as modified by the SUDRP for proceedings initiated no later than sixty days after the
Commencement-of-Service Date. 




None
of the violations of the Restrictions will be enforced directly by or through Registry Operator. The RDRP, UDRP, and SUDRP will be made applicable by the ICANN-Accredited Registrars' registration
agreements with registrants. Proceedings under the RDRP, UDRP, and SUDRP must be brought by interested third parties in accordance with the policies and procedures set forth in Appendix M.
Registry Operator will not review, monitor, or otherwise verify that any particular domain name is being used primarily for business or commercial purposes or that a domain name is being used in
compliance with the SUDRP or UDRP processes. 


Registration Requirements  


Before
the Registry Operator will accept applications for registration, all domain name applicants in the.biz TLD ("Applicants") must: 



1.  Enter
into an electronic or paper registration agreement with an ICANN-Accredited Registrar ("Registrar"), in accordance with the ICANN Registrar Accreditation Agreement
("Accreditation Agreement") and the Registry-Registrar Agreement. Such electronic or paper registration agreement shall include the following certifications: 



a)  The
data provided in the domain name registration application is true, correct, up to date and complete; and 


b)  The
registrant will keep the information provided above up to date. 




2.  As
part of a domain name registration application, the Applicant must certify that to the best of its knowledge: 



a)  The
registered domain name will be used in a manner consistent with the Restrictions above; 


b)  The
domain name registrant has the authority to enter into the registration agreement; and 


c)  The
registered domain name is reasonably related to the registrant's business or intended commercial purpose at the time of registration. 





Failure
to comply with the above will result in failure of the Registry Operator to process an Applicant's domain name application. 


Reservation  


Registry
Operator reserves the right to deny, cancel or transfer any registration that it deems necessary, in its discretion, to protect the integrity and stability of the registry, to comply with any
applicable laws,
government rules or requirements, requests of law enforcement, in compliance with any dispute resolution process, or to avoid any liability, civil or criminal, on the part of Registry Operator, as
well as its affiliates, subsidiaries, officers, directors and employees. Registry Operator also reserves the right to freeze a domain name during resolution of a dispute. 









APPENDIX M  


 
  Start-Up Enforcement and Enforcement of the
  Restrictions Document  
  


I. Uniform Dispute Resolution Policy  


A. General Information  


All
ICANN-Accredited Registrars in the.biz top-level domain shall follow the Uniform Domain-Name Dispute-Resolution Policy (often referred to as the "UDRP"). Under the policy,
most types of trademark-based domain-name disputes must be resolved by agreement, court action, or arbitration before a registrar will cancel, suspend, or transfer a domain name. Disputes
alleged to arise from abusive registrations of domain names (for example, cybersquatting) may be addressed by expedited administrative proceedings that the holder of trademark rights initiates by
filing a complaint with an approved dispute-resolution service provider. 


To
invoke the policy, a trademark owner should either (a) file a complaint in a court of proper jurisdiction against the domain-name holder (or where appropriate an
in-rem action concerning the domain name) or (b) in cases of abusive registration submit a complaint to an approved dispute-resolution service provider (see below for a list and
links). 


B. Principal Documents  


The
following documents provide relevant details: 



1.
Uniform Domain Name Dispute Resolution Policy—This policy is followed by all ICANN-Accredited Registrars. It can be found at:
http://www.icann.org/udrp/udrp-policy-24oct99.htm 



2.
Rules for Uniform Domain Name Dispute Resolution Policy—These rules are followed by all dispute-resolution service providers, with supplementation by each provider's supplemental rules.
This can be found at: <http://www.icann.org/udrp/udrp-rules-24oct99.htm>. 


3.
List of Approved Dispute-Resolution Service Providers. This list can be found at: <http://www.icann.org/udrp/approved-providers.htm>. 


4.
Information Concerning Approval Process for Dispute-Resolution Service Providers. This information can be found at:
<http://www.icann.org/udrp/udrp-provider-approval-process.htm>. 




II.    Start-Up Dispute Resolution Policy  


A. General Information  


All
disputes between a third party and a domain name registrant regarding the registration of an Internet domain name that is subject to the Start-Up Intellectual Property Notification
Service ("SIPNS"), set forth in Appendix J, shall be decided under the Start-Up Dispute Resolution Policy ("SUDRP"). 


To
invoke the policy, a third party may submit a complaint to an approved dispute-resolution service provider. 


B. Principal Documents  


The
following documents provide details: 



1.
Start-up Dispute Resolution Policy—This policy is followed by all ICANN-Accredited Registrars. The Policy, is attached as Exhibit 1 to this Appendix, and is made a
part of the ICANN-Accredited Registrar-registrant agreement. Registry Operator has begun the process of contacting potential dispute providers and is finalizing the procedures outlined below. 


2.
Rules for Start-Up Dispute Resolution Policy—These rules are followed by all dispute-resolution service providers, with supplementation by each provider's supplemental
rules. A preliminary draft 












of
the Rules are attached as Exhibit 2 to this Appendix. Registry Operator has begun the process of contacting potential dispute providers and is finalizing the procedures outlined below. 



3.
List of Approved Dispute-Resolution Service Providers. The then current list of approved dispute-resolution service providers will be identified on ICANN's web site at
http://www.icann.org/udrp/<FILE TO BE INSERTED>. 


4.
Information Concerning Approval Process for Dispute-Resolution Service Providers. The then current approval process will be identified on ICANN's web site at
http://www.icann.org/udrp/<FILE TO BE INSERTED>. 




III.  Restrictions Dispute Resolution Policy  



A. General Information  


All
ICANN-Accredited Registrars in the.biz top-level domain shall follow the Restrictions Dispute Resolution Policy (referred to as the "RDRP"). Under the policy, several types of disputes
alleged from a violation of the Restrictions Document (for example, from a.biz domain name used exclusively for personal noncommercial use), as set forth in Appendix L, may be addressed by
expedited administrative proceedings. These may be initiated by any party filing a complaint with an approved dispute-resolution service provider. To invoke the policy, a third party may submit a
complaint to an approved dispute-resolution service provider. 


B. Principal Documents  


The
following documents provide details: 



1.
Restrictions Dispute Resolution Policy—This policy is followed by all ICANN-Accredited Registrars. A preliminary draft of the Policy, is attached as Exhibit 3 to this Appendix,
and is made a part of the ICANN-Accredited Registrar-registrant agreement. Registry Operator has begun the process of contacting potential dispute providers and is finalizing the procedures outlined
below. 


2.
Rules for Restrictions Domain Name Dispute Resolution Policy—These rules are followed by all dispute-resolution service providers, with supplementation by each provider's supplemental
rules. A preliminary draft of the Rules are attached as Exhibit 4 to this Appendix. Registry Operator has begun the process of contacting potential dispute providers and is finalizing the
procedures outlined below. Registry Operator will coordinate with ICANN to publish the final Rules prior to the beginning of the.biz start-up procedures described in Appendix J. 


3.
List of Approved Dispute-Resolution Service Providers. The then current list of approved dispute-resolution service providers will be identified on ICANN's web site at
http://www.icann.org/udrp/<FILE TO BE INSERTED>. 


4.
Information Concerning Approval Process for Dispute-Resolution Service Providers. The then current approval process will be identified on ICANN's web site at
http://www.icann.org/udrp/<FILE TO BE INSERTED>. 



Exhibit 1

Start-up Dispute Resolution Policy for <.biz>  


1. Purpose. This Start-up Dispute Resolution Policy (the "Policy") is incorporated by reference into the <.biz>Registration
Agreement. It sets forth the terms and conditions in connection with a dispute between you (as the registrant) and any party other than us (as the registrar) or the registry administrator for the
<.biz> top-level domain (the "Registry Operator") over the registration or use of an Internet domain name registered by you that is subject to the Start-Up
Intellectual Notification Service ("SIPNS"; <URL>). 


The
SIPNS is a service introduced by the Registry Operator to notify a trademark or service mark holder ("Claimant") that a second-level domain name has been registered in which that Claimant 










claims
intellectual property rights. In order to benefit from the SIPNS, a Claimant was required to submit a Trademark Claim Form ("TCF") for the <.biz> domain name matching the exact
alphanumeric string contained in the trade or service mark in which that Claimant has rights. Neither the Registry Operator nor we verified whether the TCF information provided by a Claimant is
accurate. Neither the Registry Operator nor we provide any warranties or guarantees in respect of that information. No restriction was placed on the number of Claimants that could file a TCF
for a given domain name. Accordingly, in some cases, there are multiple Claimants for a single domain name. If your domain name identically matches a trade or service mark string specified in a TCF,
any Claimant that filed such a TCF will be notified of this fact. The notification will provide the relevant details of your registration, including your contact details. In accordance with this
Policy and the Rules, those Claimants will have the right to challenge your domain name registration, subject to the challenge priority established by the Registry Operator. 



Proceedings
under Paragraph 4 of this Policy will be conducted according to the Rules for Start-up Dispute Resolution Policy (the "Rules"), which are available at
<URL>, and the selected administrative dispute resolution service provider's supplemental rules. 


2. Your Representations. By applying to register a domain name in the start-up period, you hereby represent and warrant to us that
(a) the statements that you made in your <.biz> Registration Agreement are complete and accurate; (b) to your knowledge, the domain name will not infringe upon or otherwise
violate the rights of any third party; (c) you are not registering the domain name for an unlawful purpose; and (d) you will not knowingly use the domain name in violation of any
applicable laws or regulations. It is your responsibility to determine whether your domain name registration infringes or violates someone else's rights. 


3. Cancellations, Transfers, and Changes. We will cancel, transfer or otherwise make changes to a domain name registration that is subject to this
Policy under the following circumstances: 



a.
subject to the provisions of Paragraph 8, our receipt of written or appropriate electronic instructions from you or your authorized agent to take such action; and/or 


b.
our receipt of an order from a court or arbitral tribunal, in each case of competent jurisdiction, requiring such action; and/or 



c.
our receipt of a decision of an Administrative Panel requiring such action in any administrative proceeding to which you were a party and which was conducted under this Policy or a later version of
this Policy adopted by ICANN. 




We
may also cancel, transfer or otherwise make changes to a domain name registration in accordance with the terms of the <.biz> Registration Agreement, ICANN Policy, or other legal
requirements. 


4.     Mandatory Administrative Proceeding.  



This
Paragraph sets forth the type of disputes for which you are required to submit to a mandatory administrative proceeding. These proceedings will be conducted before one of the administrative
dispute resolution service providers listed at www.icann.org/udrp/approved-providers.htm (each, a "Provider"). 



a. Applicable Disputes. You are required to submit to a mandatory administrative proceeding in the event that a Claimant asserts to the applicable
Provider, in compliance with the Rules, that: 



(i)
your domain name is identical to a trademark or service mark in which the Claimant has rights; and 


(ii)
you have no rights or legitimate interests in respect of the domain name; and 


(iii)
your domain name has been registered or is being used in bad faith. 




In
the administrative proceeding, the Claimant must prove that each of these three elements is present. 









b. Evidence of Registration or Use in Bad Faith. For the purposes of Paragraph 4(a)(iii), the following circumstances, in particular but without
limitation, if found by the Panel to be present, shall be considered evidence of the registration or use of a domain name in bad faith: 



(i)
circumstances indicating that you have registered the domain name primarily for the purpose of selling, renting, or otherwise transferring the domain name registration to the Claimant or to a
competitor of the Claimant, for valuable consideration in excess of your documented out-of-pocket costs directly related to the domain name; or 


(ii)
you have registered the domain name in order to prevent the Claimant from reflecting the mark in a corresponding domain name; or 


(iii)
you have registered the domain name primarily for the purpose of disrupting the business of a competitor; or 


(iv)
by using the domain name, you have intentionally attempted to attract, for commercial gain, Internet users to your web site or other on-line location, by creating a likelihood of
confusion with the Claimant's mark as to the source, sponsorship, affiliation, or endorsement of your web site or location or of a product or service on your web site or location. 




c. How to Demonstrate Your Rights to and Legitimate Interests in the Domain Name in Responding to a Complaint. When you receive a complaint, you should
refer to the Rules to determine how your response should be prepared. Any of the following circumstances, in particular but without limitation, if found by the Panel to be proved based on its
evaluation of all evidence presented, shall demonstrate your rights or legitimate interests to the domain name for purposes of Paragraph 4(a)(ii): 



(i)
You are the owner or beneficiary of a trade or service mark that is identical to the domain name; or 


(ii)
Before any notice to you of the dispute, your use of, or demonstrable preparations to use, the domain name or a name corresponding to the domain name in connection with a bona fide offering of
goods or services; or 


(iii)
you (as an individual, business, or other organization) have been commonly known by the domain name, even if you have acquired no trademark or service mark rights. 




d. Selection of Provider. The Claimant shall select the Provider from among those approved by ICANN by submitting the complaint to that Provider. The
selected Provider will administer the proceeding, except in cases of consolidation as described in Paragraph 4(f). 


e. Initiation of Proceeding and Process and Appointment of Administrative Panel. All disputes will be decided by a single Panelist, who shall be
appointed by the Provider. The Rules state the process for initiating and conducting a proceeding and for appointing the Sole Panelist that will decide the dispute (the "Administrative Panel"). 


f. Consolidation. In the event of multiple disputes between you and a Claimant, either you or the Claimant may petition to consolidate the disputes
before a single Administrative Panel. This petition shall be made to the first Administrative Panel appointed to hear a pending dispute between the parties. This Administrative Panel may consolidate
before it any or all such disputes in its sole discretion, provided that the disputes being consolidated are governed by this Policy or another dispute resolution policy adopted by ICANN. 


g. Fees. All fees charged by a Provider in connection with any dispute before an Administrative Panel pursuant to this Policy shall be paid by the
Claimant. 


h. Our Involvement in Administrative Proceedings. We do not, and will not, participate in the administration or conduct of any proceeding before an
Administrative Panel. In addition, we will not be liable as a result of any decisions rendered by an Administrative Panel. 









i. Remedies. The remedies available to a Claimant pursuant to any proceeding before an Administrative Panel shall be limited to requiring the transfer
of your domain name registration to the Claimant. 


j. Notification and Publication. The Provider shall notify us and the Registry Operator of any decision made by an Administrative Panel with respect to
a domain name you have registered with us. All decisions under this Policy will be published in full over the Internet, except when an Administrative Panel determines in an exceptional case to redact
portions of its decision. 


k. Implementation of the Administrative Panel's Decision. If an Administrative Panel decides that your domain name registration should be transferred,
we will wait ten (10) business days (as observed in the location of our principal office) after we are informed by the applicable Provider of the Administrative Panel's decision before
implementing that decision. We will then implement the decision unless we have received from you during that ten (10) business day period official documentation (such as a copy of a complaint,
file-stamped by the clerk of the court) that you have commenced a lawsuit against the Claimant in a jurisdiction to which the Claimant has submitted under Paragraph 3 of the Rules.
(In general, that jurisdiction is either the location of our principal office or of your address as shown in our Whois database.) If we receive such documentation within the ten (10) business
day period, we will not implement the Administrative Panel's decision, and we will take no further action, until we receive (i) evidence satisfactory to us of a resolution between the parties;
(ii) evidence satisfactory to us that your lawsuit has been dismissed or withdrawn; or (iii) a copy of an order from such court dismissing your lawsuit or ordering that you do not have
the right to continue to use your domain name. 



l. Multiple Challenges.



(i)
Your domain name may be the subject of multiple challenges by Claimants. In such event, the Registry Operator will be responsible for establishing the challenge priority among multiple claimants
on a randomized basis. 


(ii)
In the event that there is more than one challenger, the Administrative Panel shall decide, in light of its findings in respect of each of the elements identified in Paragraph 4(a),
whether any further challenges shall be permitted in respect of your domain name under this Policy. 





5. All Other Disputes and Litigation. All other disputes between you and any party other than us or the Registry Operator regarding your domain name
registration that are not brought pursuant to the mandatory administrative proceeding provisions of Paragraph 4 shall be resolved between you and such other party through any court, arbitration
or other proceeding that may be available, or the Uniform Domain Name Dispute Resolution Policy, as supplemented by the Registration Restrictions Dispute Resolution Criteria. 


6. Our Involvement in Disputes. We will not participate in any way in any dispute between you and any party other than us regarding the registration and
use of your domain name. You shall not name us as a party or otherwise include us in any such proceeding. In the event that we are named as a party in any such proceeding, we reserve the right to
raise any and all defenses deemed appropriate, and to take any other action necessary to defend ourselves. 


7. Maintaining the Status Quo. We will not cancel, transfer, activate, disactivate, or otherwise change the status of any domain name registration
subject to this Policy, except as provided in Paragraph 3 above. 


8. Transfers During a Dispute.



a. Transfers of a Domain Name to a New Holder. You may not transfer a domain name registration that is subject to this Policy to another holder until
all pending or prospective challenges pursuant to this Policy have been resolved, except that a transfer may be made to the Claimant in a pending administrative proceeding (e.g., in the event of a
settlement of the dispute). 


b. Changing Registrars. You may not transfer a domain name registration that is subject to this Policy to another registrar until all pending or
prospective challenges pursuant to this Policy have been resolved. 











9.     Policy Modifications.  


The
Registry Operator reserves the right to modify this Policy at any time with the permission of ICANN. We will post the revised Policy at <URL> at least fifteen (15) calendar days
before it becomes effective. Unless this Policy has already been invoked by the submission of a complaint to a Provider, in which event the version of the Policy in effect at the time it was invoked
will apply to you until the dispute is over, all such changes will be binding upon you with respect to any domain name registration dispute, whether the dispute arose before, on or after the effective
date of the change. In the event that you object to a change in this Policy, your sole remedy is to cancel your domain name registration with us, provided that you will not be entitled to a refund of
any fees you paid to us. The revised Policy will apply to you until you cancel your domain name registration. 


 
 

Exhibit 2
  Rules for Start-up Dispute Resolution Policy
  (the "Rules")


Administrative
proceedings for the resolution of disputes pursuant to the Start-up Dispute Resolution Policy (<URL>) shall be governed by these Rules and any Supplemental Rules
of the dispute resolution service provider administering the proceedings, as posted at its web site. 


1.     Definitions  



In
these Rules: 


Complainant
means a party or the parties that submitted a Trademark Claim Form and which is/are challenging a domain name registration that is subject to the Start-up Intellectual Property
Notification Service. 


ICANN
refers to the Internet Corporation for Assigned Names and Numbers. 


Mutual
Jurisdiction means a court jurisdiction at the location of either (a) the principal office of the Registrar of the domain name in question, or (b) the domain name holder's
address, as shown for the registration of the domain name in the Registrar's Whois database at the time a complaint is submitted to a Provider. 


Panel
means the sole panelist appointed by a Provider to decide a complaint pursuant to the Policy. 


Party
means a Complainant or a Respondent. 


Policy
means the Start-up Dispute Resolution Policy that is incorporated by reference and made a part of the Registration Agreement. 


Provider
means a dispute resolution service provider approved by ICANN. A list of such Providers appears at http://www.icann.org/udrp/approved-providers.htm. 



Registrar
means the entity with which the Respondent has registered a domain name that is the subject of a complaint. 


Registration
Agreement means the agreement between a Registrar and a domain name holder. 


Registry
Operator means the registry operator for the <.biz> top-level domain. 


Respondent
means the holder of a domain name registration against which a complaint is initiated. 


Reverse
Domain Name Hijacking means using the Policy in bad faith to attempt to deprive a registered domain name holder of a domain name. 


Supplemental
Rules means the rules adopted by the Provider administering a proceeding to supplement these Rules. Supplemental Rules shall not be inconsistent with the Policy or these Rules. 













2.     Communications  



(a)
Any written communication to the Complainant or the Respondent required under these Rules shall be made by the means specified by the Complainant or the Respondent, respectively, or in the absence
of such specification: 



(i)
by facsimile with a confirmation of transmission; or 


(ii)
by postal or courier service, postage pre-paid and return receipt requested; or 


(iii)
electronically via the Internet, provided a record of its transmission is available. 




(b)
Any communication to the Provider or the Panel shall be made in accordance with the Provider's Supplemental Rules. 



(c)
All communications shall be made in the language prescribed in Paragraph 11. 


(d)
Either Party may update its contact details by notifying the other Party, the Provider and the Registrar. 


(e)
Except as otherwise provided in these Rules, or decided by a Panel, all communications provided for under these Rules shall be deemed to have been made: 



(i)
if delivered by facsimile transmission, on the date shown on the confirmation of transmission; or 


(ii)
if by postal or courier service, on the date marked on the receipt; or 


(iii)
if via the Internet, on the date that the communication was transmitted, provided that the date of transmission is verifiable. 




(f)
Except as otherwise provided in these Rules, all time periods calculated under these Rules shall begin to run on the earliest date that the communication is deemed to have been made in accordance
with Paragraph 2(e). 


(g)
Except as otherwise provided in these Rules, any communication by 



(i)
a Panel to any Party shall be copied to the Provider and to the other Party; 


(ii)
the Provider, following the commencement of an administrative proceeding pursuant to Paragraph 4(c), to any Party shall be copied to the other Party; and 


(iii)
a Party shall be copied to the other Party, the Panel and the Provider, as the case may be. 




(h)
It shall be the responsibility of the sender to retain records of the fact and circumstances of sending, which shall be available for inspection by affected parties and for reporting purposes. 


(i)
In the event that a Party sending a communication receives notification of non-delivery of the communication, that Party shall promptly notify the Provider of the circumstances of the
notification. 




3.     The Complaint  



(a)
A Complainant shall initiate an administrative proceeding under this Policy by: 



(i)
submitting its complaint to the Provider of its choice within twenty (20) calendar days of being notified by the Registry Operator of its challenge priority; and 


(ii)
registering the submission of its complaint with the Registry Operator. See instructions posted at (Registry Operator) <URL>. 




If
the Complainant fails to submit its complaint to a Provider or to complete its registration with the Registry Operator by the specified deadline, it shall be deemed to have forfeited its right to
challenge the domain name registration under this Policy. In any event, a Complainant shall as 









soon
as possible after receiving notification of its challenge priority advise the Registry Operator in writing of its election not to challenge the domain name registration under this Policy. 


(b)
The complaint shall be submitted in hard copy (with annexes) and in electronic form (without annexes). 


(c)
The complaint shall: 



(i)
Request that the complaint be submitted for decision in accordance with the Policy and Rules and describe why the domain name registration should be considered subject to the Policy; 



(ii)
Provide the full name, postal and e-mail addresses, and the telephone and telefax numbers of the Complainant and of any representative authorized to act for the Complainant in the
administrative proceeding; 


(iii)
Provide the Registry Account Number, the Registry Claim Number and the Challenge Priority Number provided by the Registry Operator; 


(iv)
Specify a preferred method for communications to the Complainant in the administrative proceeding (including person to be contacted, medium, and address information) for each of
(A) electronic-only material and (B) material including hard copy; 


(v)
Provide the full name of the Respondent and, if different from the contact details available in the Whois database for the domain name, provide all information known to the Complainant regarding
how to contact the Respondent or any representative of the Respondent, including contact information based on pre-complaint dealings; 


(vi)
Specify the domain name(s) that is/are the subject of the complaint; 


(vii)
Identify the Registrar(s) with whom the domain name(s) is/are registered at the time the complaint is filed; 


(viii)
Specify the trademark(s) or service mark(s) on which the complaint is based and, for each mark, describe the goods or services, if any, with which the mark is used (the Complainant may also
separately describe other goods and services for which it intends, at the time the complaint is submitted, to use the mark in the future); 



(ix)
Describe, in accordance with the Policy, the grounds on which the complaint is made including, in particular, 



(1)
the extent to which the domain name(s) is/are identical to a trademark or service mark in which the Complainant has rights; and 


(2)
why the Respondent should be considered as having no rights or legitimate interests in respect of the domain name(s) that is/are the subject of the complaint; and 


(3)
why the domain name(s) should be considered as having been registered or used in bad faith. 




(x)
Identify any other proceedings that have been commenced or terminated in connection with or relating to any of the domain name(s) that is/are the subject of the complaint, including any such
proceedings under this Policy; 


(xi)
Identify the Mutual Jurisdiction to which the Complainant(s) will submit, with respect to any challenges to a decision in the administrative proceeding to transfer the domain name, as follows: 



"The
Complainant hereby designates [identify precisely the court jurisdiction] as the Mutual Jurisdiction, for the purposes of any challenges to a decision in the
administrative proceeding to cancel or transfer the domain name." 












(xii)
Conclude with the following statement followed by the signature of the Complainant or its authorized representative: 



"Complainant
agrees that its claims and remedies concerning the registration of the domain name, the dispute, or the dispute's resolution shall be solely against the domain name holder and waives all
such claims and remedies against (a) the dispute resolution service provider and the Administrative Panelist, except in the case of deliberate wrongdoing, (b) the registrar,
(c) the Registry Operator, and (d) the Internet Corporation for Assigned Names and Numbers, as well as their directors, officers, employees, and agents." 



"Complainant
certifies that the information contained in this Complaint is to the best of Complainant's knowledge complete and accurate, that this Complaint is not being presented for any improper
purpose, such as to harass, and that the assertions in this Complaint are warranted under the Start-up Dispute Resolution Policy, the Rules for Start-up Dispute Resolution
Policy and under applicable law, as it now exists or as it may be extended by a good-faith and reasonable argument."; and 




(xiii)
Annex any documentary or other evidence, including any trademark or service mark registration upon which the complaint relies and a schedule indexing such evidence. 




(d)
The complaint may relate to more than one domain name, provided that the domain names are registered by the same domain name holder and the Complainant has an equal challenge priority in respect
of each domain name that is the subject of the complaint. 




4.     Notification of Complaint  



(a)
The Provider shall review the complaint for formal compliance with the Policy and the Rules. If the complaint is found to be in compliance, the Provider shall notify it to the Respondent, in the
manner prescribed in Paragraph 2(a). For the purposes of notifying the complaint, the Provider shall not be required to use any contact details other than those available in the Whois database
for the domain name(s) in dispute. 


(b)
If the Provider finds the complaint to be formally deficient, it shall promptly notify the Complainant of the nature of the deficiencies identified. The Complainant shall have five
(5) calendar days within which to correct any such deficiencies, after which the administrative proceeding will be deemed terminated and the Complainant shall be deemed to have forfeited its
right to challenge the domain name registration under this Policy. 


(c)
The date of commencement of the administrative proceeding shall be the date the complaint is notified by the Provider to the Respondent. 



(d)
The Provider shall immediately notify the Complainant, the Respondent, the Registry Operator and ICANN of the date of commencement of the administrative proceeding. 




5.     The Response  



(a)
Within twenty (20) calendar days of the date of commencement of the administrative proceeding the Respondent shall submit a response to the Provider. 


(b)
The response shall be submitted in hard copy (with annexes) and in electronic form (without annexes). 



(c)
The response shall: 



(i)
Specifically respond to the statements and allegations contained in the complaint and include any and all bases for the Respondent to retain registration and use of the disputed domain name(s); 











(ii)
Provide the name, postal and e-mail addresses, and the telephone and telefax numbers of the Respondent and of any representative authorized to act for the Respondent in the
administrative proceeding; 



(iii)
Specify a preferred method for communications directed to the Respondent in the administrative proceeding (including person to be contacted, medium, and address information) for each of
(A) electronic-only material and (B) material including hard copy; 


(vi)
Identify any other proceedings that have been commenced or terminated in connection with or relating to any of the domain name(s) that is/are the subject of the complaint, including any such
proceedings under the Policy; 


(vii)
Conclude with the following statement followed by the signature of the Respondent or its authorized representative: 



"Respondent
certifies that the information contained in this Response is to the best of Respondent's knowledge complete and accurate, that this Response is not being presented for any improper purpose
and that the assertions in this Response are warranted under the Start-up Dispute Resolution Policy, the Rules for Start-up Dispute Resolution Policy and under applicable law,
as it now exists or as it may be extended by a good-faith and reasonable argument."; and 




(viii)
Annex any documentary or other evidence upon which the Respondent relies, together with a schedule indexing such documents. 




(d)
At the request of the Respondent, the Provider may, in exceptional cases, extend the period of time for the filing of the response. The period may also be extended by written stipulation between
the Parties, provided the stipulation is approved by the Provider. 


(e)
If a Respondent does not submit a response, in the absence of exceptional circumstances, the Panel shall decide the dispute based upon the complaint. 


(f)
Where there are multiple Claimants in respect of a domain name registration, a Respondent that has already submitted a response, shall be entitled to rely on such response and, subject to the time
limits specified in Paragraph 5(a), to supplement any previously submitted response. 




6.     Appointment of the Panel and Timing of Decision  



(a)
Each Provider shall maintain and publish a publicly available list of panelists and their qualifications. 


(b)
The Provider shall appoint a single Panelist from its published list, taking into consideration such factors as the nationalities of the parties and the circumstances of the dispute. 


(c)
Once the Panel is appointed, the Provider shall notify the Parties of the Panelist appointed and the date by which, absent exceptional circumstances, the Panel shall forward its decision on the
complaint to the Provider. 




7.     Impartiality and Independence  


The
Panelist shall be impartial and independent and shall have, before accepting appointment, disclosed to the Provider any circumstances giving rise to justifiable doubt as to the Panelist's
impartiality or independence. If, at any stage during the administrative proceeding, new circumstances arise that could give rise to justifiable doubt as to the impartiality or independence of the
Panelist, that Panelist shall promptly disclose such circumstances to the Provider. In such event, the Provider shall have the discretion to appoint a substitute Panelist in accordance with
Paragraph 6. 


8.     Communication Between Parties and the Panel  


No
Party or anyone acting on its behalf may have any unilateral communication with the Panel. 









9.     Transmission of the File to the Panel  


The
Provider shall forward the case file as soon as the Administrative Panel is appointed. 


10.   General Powers of the Panel  



(a)
The Panel shall conduct the administrative proceeding in such manner as it considers appropriate in accordance with the Policy and the Rules. 


(b)
In all cases, the Panel shall ensure that the Parties are treated with equality and that each Party is given a fair opportunity to present its case. 



(c)
The Panel shall ensure that the administrative proceeding takes place with due expedition. It may, at the request of a Party or on its own motion, extend, in exceptional cases, a period of time
fixed by the Rules or by the Panel. 


(d)
The Panel shall determine the admissibility, relevance, materiality and weight of the evidence. 


(e)
A Panel shall decide a request by a Party to consolidate multiple domain name disputes in accordance with the Policy and the Rules. 




11.   Language of Proceedings  



(a)
Unless otherwise agreed by the Parties, or specified otherwise in the Registration Agreement, the language of the administrative proceeding shall be the language of the Registration Agreement,
subject to the authority of the Provider or the Panel, as the case may be, to determine otherwise, having regard to the circumstances of the administrative proceeding. 


(b)
The Panel may order that any documents submitted in languages other than the language of the administrative proceeding be accompanied by a translation in whole or in part into the language of the
administrative proceeding. 




12.   Further Statements  


In
addition to the complaint and the response, the Panel may request, in its sole discretion, further statements or documents from either of the Parties. 


13.   In-Person Hearings  


There
shall be no in-person hearings (including hearings by teleconference, videoconference, and web conference), unless the Panel determines, in its sole discretion and as an exceptional
matter, that such a hearing is necessary for deciding the complaint. 


14.   Default  



(a)
In the event that a Party, in the absence of exceptional circumstances, does not comply with any of the time periods established by the Rules or the Panel, the Panel shall proceed to a decision on
the complaint. 











(b)
If a Party, in the absence of exceptional circumstances, does not comply with any provision of, or requirement under, the Rules or any request from the Panel, the Panel shall draw such inferences
therefrom as it considers appropriate. 




15.   Panel Decisions  



(a)
A Panel shall decide a complaint on the basis of the statements and documents submitted and in accordance with the Policy, these Rules and any rules and principles of law that it deems applicable. 


(b)
In the absence of exceptional circumstances, the Panel shall forward its decision on the complaint to the Provider within fourteen (14) calendar days of its appointment. 



(c)
The Panel's decision shall be in writing, provide the reasons on which it is based, indicate the date on which it was rendered and identify the name of the Panelist. 


(d)
If the Panel concludes that the dispute is not within the scope of Paragraph 4(a) of the Rules, it shall so state. If after considering the submissions the Panel finds that the complaint
was brought in an attempt at Reverse Domain Name Hijacking the Panel shall state its findings to this effect in its decision. 


(e)
In the event that there are multiple Complainants, each Panel shall specify in its decision whether any subsequent challenges against the domain name(s) that is/are the subject of the Panel's
decision shall be permitted. 




16.   Communication of Decision to Parties  



(a)
Within three (3) business days (as observed at the Provider's principal place of business) after receiving the decision from the Panel, the Provider shall endeavor to communicate the full
text of the decision to each Party, the Registry Operator and ICANN. 


(b)
In the event of a determination in favor of the Complainant, the Registry Operator shall immediately communicate to each Party the date for the implementation of the decision in accordance with
the Policy and any action required by the Parties in connection therewith. 


(c)
Except if the Panel determines otherwise, the Provider shall publish the full decision and the date of its implementation on a publicly accessible web site. In any event, the portion of any
decision determining a complaint to have been brought in bad faith shall be published. 


(d)
In the event of multiple Complainants, the Registry Operator shall be responsible for communicating the Panel's decision to all Complainants, including specifying whether a further challenge has
been authorized by the Panel. 




17.   Settlement or Other Grounds for Termination  



(a)
If, the Complainant notifies the Provider or the Panel that the Parties have agreed on a settlement, the Provider or the Panel, as the case may be, shall suspend or terminate the administrative
proceeding. 


(b)
If, it becomes unnecessary or impossible to continue the administrative proceeding for any other reason, the Provider or Panel, as the case may be, shall terminate the administrative proceeding,
unless a Party raises justifiable grounds for objection within a period of time to be determined by the Provider or Panel. 




18.   Fees  



(a)
The Complainant shall pay to the Provider an initial fixed fee, in accordance with the Provider's Supplemental Rules, within the time and in the amount required. 









(b)
The Provider shall be under no obligation to take any action on a complaint until it has received from the Complainant the initial fee in accordance with Paragraph 18(a). 



(c)
If the Provider has not received the fee within ten (10) calendar days of receiving the complaint, the Provider shall have the discretion to terminate the administrative proceeding and the
Complainant shall be deemed to have forfeited its right to challenge the domain name registration pursuant to the Policy. 


(d)
In exceptional circumstances, the Provider shall be entitled to request payment of additional fees. 




19.   Exclusion of Liability  



Except
in the case of deliberate wrongdoing, neither the Provider nor a Panelist shall be liable to a Party for any act or omission in connection with any administrative proceeding under the Policy
and the Rules. 


20.   Amendments  


The
version of these Rules in effect at the time of the submission of the complaint to the Provider shall apply to the administrative proceeding commenced thereby. These Rules may not be amended
without the express written approval of ICANN. 


 
 

Exhibit 3
  Restrictions Dispute Resolution Policy    
    


1. Purpose. This Restrictions Dispute Resolution Policy (the "RDRP") is incorporated by reference into your <.biz>Registration Agreement. It
sets out the terms and conditions that will apply in the event of a dispute between you (as the registrant) and a third party other than us (as the registrar) or the registry administrator for the
<.biz> top-level domain over the registration or use of your domain name in violation of the <.biz> Registration Restrictions (available at http://<URL>).
Proceedings under Paragraph 4 of the RDRP will be conducted according to the Supplemental Rules for Restrictions Dispute Resolution Policy (the "Supplemental RDRP Rules"), which are available
at <http://www.icann.org/{filename}>, and the selected administrative dispute resolution service provider's supplemental rules. 


2. Your Representations. By applying to register a domain name, or by asking us to maintain or renew a domain name registration, you hereby represent
and warrant to us that (a) the statements that you made in your Registration Agreement are complete and accurate; (b) to your knowledge, the registration of the domain name will not
infringe upon or otherwise violate the rights of any third party; (c) you are not registering the domain name for an unlawful purpose; (d) you will not knowingly use the domain name in
violation of any applicable laws or regulations; (e) your domain name registration does not and will not violate the terms and conditions of the <.biz> Registration Restrictions. It
is your responsibility to determine whether your domain name registration infringes or violates someone else's rights. It is also your responsibility to determine whether your domain name registration
violates the <.biz> Registration Restrictions. 


3. Cancellations, Transfers and Changes. We will cancel, transfer or otherwise make changes to domain name registrations under the following
circumstances: 



(a)
subject to the provisions of Paragraph 8, our receipt of written or appropriate electronic instructions from you or your authorized agent to take such action; 


(b)
our receipt of an order from a court or arbitral tribunal, in each case of competent jurisdiction, requiring such action; and/or 


(c)
our receipt of a decision of an Administrative Panel requiring such action in any administrative proceeding to which you were a party and which was conducted under the RDRP or a later version of
the RDRP adopted by ICANN. 













We
may also cancel, transfer or otherwise make changes to a domain name registration in accordance with the terms of your <.biz> Registration Agreement, ICANN policy, or other legal
requirements. 


4.     Mandatory Administrative Proceeding.  


This
Paragraph sets forth the type of disputes for which you are required to submit to a mandatory administrative proceeding. These proceedings will be conducted before one of the administrative
dispute resolution service providers listed at www.icann.org/udrp/approved-providers.htm (each, a "Provider"). 



a. Applicable Disputes. In addition to the grounds set out in Paragraph 4(a) of the UDRP, you will also be required to submit to a mandatory
administrative proceeding in the event that a complainant asserts to a Provider that your domain is not being or will not be used primarily for a bona fide business or commercial purpose. In the
administrative proceeding, the complainant will bear the burden of proving that the above element is present. A complaint under the RDRP will not be considered valid if based exclusively on the
alleged non-use of your domain name. 


b. Bona Fide Business or Commercial Use. "Bona fide business or commercial use" shall mean the bona fide use or bona fide intent to use the domain name
or any content software, materials, graphics or other information thereon, to permit Internet users to access one or more host computers through the DNS: 



(i)
to exchange goods, services, or property of any kind; or 


(ii)
in the ordinary course of trade or business; or 


(iii)
to facilitate the exchange of goods, services, information, or property of any kind or the ordinary course of trade or business. 




c. Not a Bona Fide Business or Commercial Use. Registering a domain name solely for the purposes identified below shall not constitute a "bona fide
business or commercial use" of that domain name: 



(i)
selling, trading or leasing the domain name for compensation, or 


(ii)
the unsolicited offering to sell, trade or lease the domain name for compensation. 


(iii)
For illustration purposes, the following shall not constitute a "bona fide business or commercial use" of a domain name: 



(1)
Using or intending to use the domain name exclusively for personal, noncommercial purposes; or 


(2)
Using or intending to use the domain name exclusively for the expression of noncommercial ideas (e.g., registering <abcsucks.biz>exclusively to criticize or otherwise express an opinion
on the products or services of ABC company, with no other intended business or commercial purpose). 





d. Selection of Provider. The complainant shall select the Provider from among those approved by ICANN by submitting the complaint to that Provider. The
selected Provider will administer the proceeding, except in cases of consolidation as described in Paragraph 4(f). 



e. Initiation of Proceeding and Process and Appointment of Administrative Panel. The Supplemental RDRP Rules state the process for initiating and
conducting a proceeding and for appointing the panel that will decide the dispute (the "Administrative Panel"). 


f. Consolidation. In the event of multiple disputes between you and a complainant, either you or the complainant may petition to consolidate the
disputes before a single Administrative Panel. This petition shall be made to the first Administrative Panel appointed to hear a pending dispute between the parties. This Administrative Panel may
consolidate before it any or all such disputes in 












its
sole discretion, provided that the disputes being consolidated are governed by the RDRP or another dispute resolution policy adopted by ICANN. 


g. Fees. All fees charged by a Provider in connection with any dispute before an Administrative Panel pursuant to the RDRP shall be paid by the
complainant, except in cases where you elect to expand the Administrative Panel from one to three panelists as provided in the Supplemental RDRP Rules, in which case all fees will be split evenly by
you and the complainant. 



h. Our Involvement in Administrative Proceedings. We do not, and will not, participate in the administration or conduct of any proceeding before an
Administrative Panel. In addition, we will not be liable as a result of any decisions rendered by the Administrative Panel. 


i. Remedies. The remedies available to a complainant pursuant to any proceeding before an Administrative Panel shall be limited to requiring the
cancellation of your domain name or the transfer of your domain name registration to the complainant. 


j. Notification and Publication. The Provider shall notify us of any decision made by an Administrative Panel with respect to a domain name you have
registered with us. All decisions under the RDRP will be published in full over the Internet, except when an Administrative Panel determines in an exceptional case to redact portions of its decision. 


k. Availability of Court Proceedings. The mandatory administrative proceeding requirements set forth in Paragraph 4 shall not prevent either you
or the complainant from submitting the dispute to a court of competent jurisdiction for independent resolution before such mandatory administrative proceeding is commenced or after such proceeding is
concluded. If an Administrative Panel decides that your domain name registration should be canceled or transferred, we will wait ten (10) business days (as observed in the location of our
principal office) after we are informed by the applicable Provider of the Administrative Panel's decision before implementing that decision. We will then implement the decision unless we have received
from you during that ten (10) business day period official documentation (such as a copy of a complaint, file-stamped by the clerk of the court) that you have commenced a lawsuit
against the complainant in a jurisdiction to which the complainant has submitted under the Supplemental RDRP Rules. (In general, that jurisdiction is either the location of our principal office or of
your address as shown in our Whois database.) If we receive such documentation within the ten (10) business day period, we will not implement the Administrative Panel's decision, and we will
take no further action, until we receive (i) evidence satisfactory to us of a resolution between
the parties; (ii) evidence satisfactory to us that your lawsuit has been dismissed or withdrawn; or (iii) a copy of an order from such court dismissing your lawsuit or ordering that you
do not have the right to continue to use your domain name. 




5. All Other Disputes and Litigation. All other disputes between you and any party other than us regarding your domain name registration that are not
brought pursuant to the mandatory administrative proceeding provisions of Paragraph 4 shall be resolved between you and such other party through any court, arbitration or other proceeding that
may be available. 


6. Our Involvement in Disputes. We will not participate in any way in any dispute between you and any party other than us regarding the registration and
use of your domain name. You shall not name us as a party or otherwise include us in any such proceeding. In the event that we are named as a party in any such proceeding, we reserve the right to
raise any and all defenses deemed appropriate, and to take any other action necessary to defend ourselves. 


7. Maintaining the Status Quo. We will not cancel, transfer, activate, deactivate, or otherwise change the status of any domain name registration under
the RDRP except as provided in Paragraph 3 above. 


8.     Transfers During a Dispute.  



a. Transfers of a Domain Name to a New Holder. You may not transfer your domain name registration to another holder (i) during a pending
administrative proceeding brought pursuant to 









Paragraph 4
or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding is concluded; or (ii) during a
pending court proceeding or arbitration commenced regarding your domain name unless the party to whom the domain name registration is being transferred agrees, in writing, to be bound by the decision
of the court or arbitrator. We reserve the right to cancel any transfer of a domain name registration to another holder that is made in violation of this subparagraph. 


b. Changing Registrars. You may not transfer your domain name registration to another registrar during a pending administrative proceeding brought
pursuant to Paragraph 4 or for a period of fifteen (15) business days (as observed in the location of our principal place of business) after such proceeding
is concluded. You may transfer administration of your domain name registration to another registrar during a pending court action or arbitration, provided that the domain name you have registered with
us shall continue to be subject to the proceedings commenced against you in accordance with the terms of the RDRP. In the event that you transfer a domain name registration to us during the pendency
of a court action or arbitration, such dispute shall remain subject to the domain name dispute policy of the registrar from which the domain name registration was transferred. 




9. Policy Modifications. We reserve the right to modify the RDRP at any time with the permission of ICANN. We will post the revised RDRP at
<URL> at least thirty (30) calendar days before it becomes effective. Unless this version of the RDRP has already been invoked by the submission of a complaint to a Provider, in
which event the version of the RDRP in effect at the time it was invoked will apply to you until the dispute is over, all such changes will be binding upon you with respect to any domain name
registration dispute, whether the dispute arose before, on or after the effective date of our change. In the event that you object to a change in this version of the RDRP, your sole remedy is to
cancel your domain name registration with us, provided that you will not be entitled to a refund of any fees you paid to us. The revised RDRP will apply to you until you cancel your domain name
registration. 


 
 

Exhibit 4
  Supplemental Rules for
  Restrictions Dispute Resolution Policy    
    


1. Purpose. Administrative proceedings for the resolution of disputes under the Restrictions Dispute Resolution Policy ("RDRP"; <URL>) shall
be governed by the Rules for Uniform Domain Name Dispute Resolution Policy ("UDRP Rules"; <URL>) as supplemented or modified by these Supplemental Rules for Restrictions Dispute Resolution
Policy (the "Supplemental RDRP Rules") and any supplemental rules of the dispute resolution service provider administering the proceedings. 


2. Definitions. Defined terms in the UDRP Rules shall have the same meaning in these Supplemental RDRP Rules, subject to the following: 



(a)
Complaint based on UDRP and RDRP. If a complaint is based on the UDRP and the RDRP, the term "Policy" shall refer to the Uniform Domain Name Dispute Resolution Policy ("UDRP") and the RDRP, and
the term "Rules" shall refer to the UDRP Rules as supplemented or modified by these Supplemental RDRP Rules. 



(b)
Complaint based on the RDRP alone. If a complaint is based on the RDRP alone, the term "Policy" shall refer to the RDRP, and the term "Rules" shall refer to the UDRP Rules as supplemented or
modified by these Supplemental RDRP Rules. 




3. RDRP Grounds. A complaint pursuant to the RDRP (whether or not also based on the UDRP) shall describe, in accordance with Paragraph 4(a)-(c),
the grounds on which the complaint is made including, in particular, the extent to which the domain name is not being or will not be used primarily for a bona fide business or commercial purpose. 









APPENDIX N  


 
 

Zone File Access Agreement  
  


1.     PARTIES  


The
User named in this Agreement hereby contracts with [name of Registry Operator]
("[nickname of Registry Operator]") for a non-exclusive, non-transferable, limited right to access an
Internet host server or servers designated by [nickname of Registry Operator] from time to time, and to transfer a copy of the
described Data to the User's Internet host machine specified below, under the terms of this Agreement. Upon execution of this Agreement by [nickname of Registry
Operator], [nickname of Registry Operator] will return a copy of this Agreement to you for
your records with your UserID and Password entered in the spaces set forth below. 


2.     USER INFORMATION  



	

 	
 	

(a) User:	
 	







	

 	
 	

(b) Contact Person:	
 	







	

 	
 	

(c) Street Address:	
 	







	

 	
 	

(d) City, State or Province:	
 	







	

 	
 	

(e) Country and Postal Code:	
 	







	

 	
 	

(f) Telephone Number:	
 	


	 	 	(including area/country code)





	

 	
 	

(g) Fax Number:	
 	


	 	 	(including area/country code)





	

 	
 	

(h) E-Mail Address:	
 	


	

 	
 	

(i) Specific Internet host machine which will be used to access [nickname of Registry Operator]'s server to transfer copies of the Data:





	

 	
 	

 	
 	

 
	 	 	Name:	 	






	

 	
 	

IP Address:	
 	


	

 	
 	

(j) Purpose(s) for which the Data will be used: During the term of this Agreement, you may use the data for any legal purpose, not prohibited under Section 4 below. You may incorporate some or all of the Data in your own products or services,
and distribute those products or services for a purpose not prohibited under Section 4 below.





3.     TERM  


This
Agreement is effective for a period of three (3) months from the date of execution by [nickname of Registry
Operator] (the "Initial Term"). Upon conclusion of the Initial Term this Agreement will automatically renew for successive three-month renewal terms (each a
"Renewal Term") until terminated by either party as set forth in Section 12 of this Agreement or one party provides the other party with a written notice of termination at least seven
(7) days prior to the end of the Initial Term or the then current Renewal Term. 


NOTICE
TO USER: CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS. YOU MAY USE THE USER ID AND ASSOCIATED PASSWORD PROVIDED IN CONJUNCTION WITH THIS AGREEMENT ONLY TO OBTAIN A COPY OF
[TLD label] TOP-LEVEL DOMAIN ("TLD") ZONE FILES, AND ANY ASSOCIATED ENCRYPTED CHECKSUM FILES (COLLECTIVELY THE
"DATA"), VIA THE FILE TRANSFER PROTOCOL ("FTP") OR HYPERTEXT TRANSFER PROTOCOL ("HTTP") PURSUANT TO THESE TERMS. 










4.     GRANT OF ACCESS  



[Nickname of Registry Operator] grants to you a non-exclusive, non-transferable, limited right to access
an Internet host server or servers designated by [nickname of Registry Operator] from time to time, and to transfer a copy of
the Data to the Internet host machine identified in Section 2 of this Agreement no more than once per 24 hour period using FTP or HTTP for the purposes described in this
Section 4. You agree that you will: 


(a)  use
this Data only for lawful purposes but that under no circumstances will you use this Data to: (1) allow, enable, or otherwise support the transmission by
e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than your own existing customers; or (2) enable high volume,
automated, electronic processes that send queries or data to the systems of [nickname of Registry Operator] or any
ICANN-accredited registrar, except as reasonably necessary to register domain names or modify existing registrations. [Nickname of Registry
Operator] reserves the right, with the approval of the Internet Corporation for Assigned Names and Numbers ("ICANN"), to specify additional specific categories of
prohibited uses by giving you reasonable written notice at any time and upon receiving such notice you shall not make such prohibited use of the Data you obtain under this Agreement. 


(b)  copy
the Data you obtain under this Agreement into a machine-readable or printed form only as necessary to use it in accordance with this Agreement in support of your use of the Data. 


(c)  comply
with all applicable laws and regulations governing the use of the Data. 


(d)  not
distribute the Data you obtained under this Agreement or any copy thereof to any other party without the express prior written consent of
[nickname of Registry Operator], except that you may redistribute the Data insofar as it has been incorporated by you into a
value-added product or service that does not permit the extraction of a substantial portion of the Data from the value-added product or service, provided you prohibit the recipient of the Data from
using the Data in a manner contrary to Section 4(a). 


(e)  take
all reasonable steps to protect against unauthorized access to, use, and disclosure of the Data you obtain under this Agreement. 




5.     FEE  


You
agree to remit in advance to [nickname of Registry Operator] a quarterly fee of $0 (USD) for the right to access the files
during either the Initial Term or Renewal Term of this Agreement. [Nickname of Registry Operator] reserves the right to adjust,
with the approval of ICANN, this fee on thirty days prior notice to reflect a change in the cost of providing access to the files. 


6.     PROPRIETARY RIGHTS  


You
agree that no ownership rights in the Data are transferred to you under this Agreement. You agree that any copies of the Data that you make will contain the same notice that appears on and in the
Data obtained under this Agreement. 


7.     METHOD OF ACCESS  


[Nickname of Registry Operator] reserves the right, with the approval of ICANN, to change the method of access to the Data at
any time. You also agree that, in the event of
significant degradation of system processing or other emergency, [nickname of Registry Operator] may, in its sole discretion,
temporarily suspend access under this Agreement in order to minimize threats to the operational stability and security of the Internet. 


8.     NO WARRANTIES  


The
Data is being provided "as-is." [Nickname of Registry Operator] disclaims all warranties with respect to the Data, either expressed or implied, including but
not limited to the implied warranties of 








merchantability,
fitness for a particular purpose, and non-infringement of third party rights. Some jurisdictions do not allow the exclusion of implied warranties or the exclusion or
limitation of incidental or consequential damages, so the above limitations or exclusions may not apply to you. 


9.     SEVERABILITY  


In
the event of invalidity of any provision of this Agreement, the parties agree that such invalidity shall not affect the validity of the remaining provisions of this Agreement. 


10.   NO CONSEQUENTIAL DAMAGES  


In
no event shall [nickname of Registry Operator] be liable to you for any consequential, special, incidental or indirect
damages of any kind arising out of the use of the Data or the termination of this Agreement, even if [nickname of Registry
Operator] has been advised of the possibility of such damages. 


11.   GOVERNING LAW  


This
Agreement shall be governed and construed in accordance with the laws of [home jurisdiction of Registry Operator]. You
agree that any legal action or other legal proceeding relating to this Agreement or the enforcement of any provision of this Agreement shall be brought or otherwise commenced in the
[specify local court]. You expressly and irrevocably agree and consent to the personal jurisdiction and venue of the federal and
state courts located [home jurisdiction of Registry Operator] (and each appellate court located therein) for matters arising in
connection with this Agreement or your obtaining, use, or distribution of the Data. The United Nations Convention on Contracts for the International Sale of Goods is specifically disclaimed. 


12.   TERMINATION  


You
may terminate this Agreement at any time by erasing the Data you obtained under this Agreement from your Internet host machine together with all copies of the Data and providing written notice of
your termination to [nickname of Registry Operator] at [address of Registry
Operator]. [Nickname of Registry Operator] has the right to terminate this Agreement
immediately if you fail to comply with any term or condition of this Agreement. You agree upon receiving notice of such termination of this Agreement by [nickname
of Registry Operator] or expiration of this Agreement to erase the Data you obtained under this Agreement together with all copies of the Data. 



13.   DEFINITION  


"Data"
means all data contained in a DNS zone file for the Registry TLD as provided to TLD nameservers on the Internet. 


14.   ENTIRE AGREEMENT  


This
is the entire agreement between you and [nickname of Registry Operator] concerning access and use of the Data, and it
supersedes any prior agreements or understandings, whether written or oral, relating to access and use of the Data. 



	[Full name of Registry Operator]	 	User:
	

By:

(sign)	
 	

By:

(sign)
	

Name:

(print)	
 	

Name:

(print)
	

Title:	
 	

Title:
	

Date:	
 	

Date:





ASSIGNED USERID AND PASSWORD  


(To
be assigned by [nickname of Registry Operator] upon execution of this Agreement): 



	USERID:	 	PASSWORD:











APPENDIX O  


 
 

Whois Specification—Public Whois  
  


NeuLevel
will provide RFC954-conformant Whois service. NeuLevel will also provide an enhanced "Whois" service. This Appendix is subject to change by agreement of Registry Operator and
ICANN during the design process as well as during the IETF standards process. However, the following provides the target architecture and initial functionality. 



RFC954-Conformant Whois  


The
standard Whois service is intended as a lookup service for registries, registrars, registrants, as well as for other individuals and businesses that wish to query details of domain names or
nameservers stored in the registry. Being a fat-registry, the standard Whois service will provide a central location for all authoritative.biz TLD data. Registrars will be able to provide
a front-end web interface to the standard Whois service. In addition, the Registry provides its own front-end web interface to allow convenient user access to the Whois
service. 


Due
to the nature of the NeuLevel fat- (thick-)registry model, the RFC954-conformant Whois service will be engineered to handle high transaction load and be integral to the
standard suite of registry services. The service will return a single response per domain name or nameserver query. The RFC954-conformant Whois service will conform to established service
level agreements. 


The
RFC954-conformant service provided by the registry will have the following features: 



	•
	Standard
protocol accessible over port 43. 
	•
	Consistent
format (fields and formatting) for all registrars. 
	•
	Near
real-time updates, eliminating "timing" problems when modifying registry information. 
	•
	Extensible
field capability. 




Whois Service Data Elements  


The
RFC954-conformant service will include the following data elements: 



	•
	The
name of the domain name registered; 
	•
	The
IP addresses of the primary nameserver and secondary nameserver(s) of the name registered; 
	•
	The
corresponding names of those nameservers; 
	•
	The
identity of the registrar; 
	•
	The
original creation date and term of the registration; 
	•
	The
name, postal address, e-mail address, voice telephone number, and (where available) fax number of the domain name registrant; 
	•
	The
name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the name registered; and 
	•
	The
name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the name registered. 




Extensible-Field Capability  


NeuLevel
will introduce the ability for registrars to use XRP to add customized fields to a record in the registry database. These fields will appear in an "additional information" section of the
Whois data. The maximum number of custom fields allowed per record is yet to be determined. 


The
extensible-field capability will eliminate the need for registrars to store additional information in their own local database, then combine it with the registry Whois information when they
present it to end users. The proposed capability will also ensure that end users will view the same information no matter which registrar they use to retrieve Whois data. 










Privacy Capability  


NeuLevel
may introduce the optional ability for registrars to use XRP to associate privacy labels to a record in the registry database. These fields would appear in an "additional information" section
of the Whois data. The maximum number of custom fields allowed per record is yet to be determined. 


The
privacy label capability allows registrars to transmit data with an associated indication of any special disclosure or handling restrictions. This can allow exchange of data among entities
involved in the domain-name registration system in a manner that permits consistent adherence to applicable restrictions. 



Query Control—Object Type Control  


The
following keywords restrict a search to specific object type: 



Domain:  Search only by domain objects. The input string is searched in the Name field. 


Contact:  Search only contact objects. The input string is searched in the ID field. 


Nameserver:  Search only by nameserver objects. The input string is searched in the nameserver field or the IP address field. 



Registrar:  Search only registrar objects. The input string is searched in the Name field. 




By
default, if no object type control is specified, then the Name field of the Domain object is searched. 


Whois Output Fields  



Domain Record:  


A
Whois query that results in domain information will return the following fields from the Domain object and the associated data from host and contact objects. This set of data is also referred to as
the Domain Record. 




Domain
ID

Domain Name

Sponsoring Registrar

Domain Status

Registrant, Administrative, Technical and Billing Contact

Information including

        Contact ID

        Contact Name

        Contact Organization

        Contact Address, City, State/Province, Country

        Contact Postal Code

        Contact Phone, Fax, E-mail

Name Servers associated with this domain

Created by Registrar

Last Updated by Registrar

Last Transferred Date

Additional fields (registrar specified)

Domain Registration Date

Domain Expiration Date

Domain Last Updated Date 















Note:
For domains on PendingDelete Status, the Registry's front-end web interface will provide an additional explanation of the status as follows: 



	Up to 30 days after deletion:	 	Pending Delete (Restorable)
	

More than 30 days after deletion:	
 	

Pending Delete (Scheduled for release)





Nameserver
Record: 


Nameserver
ID

Nameserver name

Currently Associated (true/false)

Nameserver status

IP addresses associated

Sponsoring Registrar

Created by Registrar

Last Updated by Registrar

Last Transferred Date

Additional fields (registrar specified) 


Contact Record:  


A
Whois query that results in contact information will return the following. This set of information is referred to as the Contact Record. 




Contact
ID

Contact Registrar

Contact Name

Contact Organization

Contact Address, City, State/Province, Country + 3 street fields

Contact Postal Code

Contact Phone, Fax, E-mail

Contact Registration Date

Contact Last Updated Date

Currently Associated

Contact Status

Sponsoring Registrar

Created Registrar

Last Transferred Date 





Registrar Record:  



A
Whois query that results in Registrar information will return the following. This set of information is referred to as the Registrar Record. 




Registrar
ID (conforming to the IANA registrar-ids registry)

Registrar Name

Registrar Status

Registrar Address, City, State/Province, Country

Registrar Postal Code

Registrar Phone, Fax, E-mail

Registrar Administrative Contacts

Registrar Billing Contacts 














Sample Whois Output  


This
section provides sample output from the Whois server for each type of Registry Object: Domain, Contact, Nameserver, and Registrar. The output is structured as key/value pairs, which simplifies
machine-readability. 


Domain Record:  



	 	 	Input:	 	whois "domain = neulevel.biz"
	 	 	Output:	 	Domain ID: DOM-1012
	 	 	 	 	Domain Name: NEULEVEL.BIZ
	 	 	 	 	Sponsoring Registrar: SAMPLE
	 	 	 	 	Domain Status: ACTIVE
	 	 	 	 	Registrant Name: JEFFREY J. NEUMAN
	 	 	 	 	Registrant Organization: NEULEVEL, INC.
	 	 	 	 	Registrant Address: 1120 VERMONT AVE., NW
	 	 	 	 	Registrant City: WASHINGTON
	 	 	 	 	Registrant State/Province: DC
	 	 	 	 	Registrant Country: USA
	 	 	 	 	Registrant Postal Code: 20005
	 	 	 	 	Registrant Phone Number: (202) 533-2600
	 	 	 	 	Registrant Facsimile Number: (202) 533-2970
	 	 	 	 	Registrant Email: JEFF.NEUMAN@NEULEVEL.BIZ
	 	 	 	 	Admin ID: CNT-1012
	 	 	 	 	Admin Name: JEFFREY J. NEUMAN
	 	 	 	 	Admin Organization: NEULEVEL, INC.
	 	 	 	 	Admin Address: 1120 VERMONT AVE., NW
	 	 	 	 	Admin City: WASHINGTON
	 	 	 	 	Admin State/Province: DC
	 	 	 	 	Admin Country: USA
	 	 	 	 	Admin Postal Code: 20005
	 	 	 	 	Admin Phone Number: (202) 533-2600
	 	 	 	 	Admin Facsimile Number: (202) 533-2970
	 	 	 	 	Admin Email: JEFF.NEUMAN@NEULEVEL.BIZ
	 	 	 	 	Tech ID: CNT-1012
	 	 	 	 	Tech Name: JEFFREY J. NEUMAN
	 	 	 	 	Tech Organization: NEULEVEL, INC.
	 	 	 	 	Tech Address: 1120 VERMONT AVE., NW
	 	 	 	 	Tech City: WASHINGTON
	 	 	 	 	Tech State/Province: DC
	 	 	 	 	Tech Country: USA
	 	 	 	 	Tech Postal Code: 20005
	 	 	 	 	Tech Phone Number: (202) 533-2600
	 	 	 	 	Tech Facsimile Number: (202) 533-2970
	 	 	 	 	Tech Email: JEFF.NEUMAN@NEULEVEL.BIZ
	 	 	 	 	Billing ID: CNT-1012
	 	 	 	 	Billing Name: JEFFREY J. NEUMAN
	 	 	 	 	Billing Organization: NEULEVEL, INC.
	 	 	 	 	Billing Address: 1120 VERMONT AVE., NW
	 	 	 	 	Billing City: WASHINGTON
	 	 	 	 	Billing State/Province: DC
	 	 	 	 	Billing Country: USA
	 	 	 	 	Billing Postal Code: 20005
	 	 	 	 	Billing Phone Number: (202) 533-2600
	 	 	 	 	 









	 	 	 	 	Billing Facsimile Number: (202) 533-2970
	 	 	 	 	Billing Email: JEFF.NEUMAN@NEULEVEL.BIZ
	 	 	 	 	Name Server: ENTERPRISE.MELBOURNEIT.COM.AU
	 	 	 	 	Name Server: DEFIANT.MELBOURNEIT.COM.AU
	 	 	 	 	Created On: May 5, 2001
	 	 	 	 	Expires On: May 5, 2003
	 	 	 	 	Updated On: May 5, 2001





Contact Record: 



	 	 	Input:	 	whois "contact = Jeff Neuman"
	 	 	Output:	 	Contact ID: CNT-1012
	 	 	 	 	Registrar: SAMPLE
	 	 	 	 	Name: JEFFREY J. NEUMAN
	 	 	 	 	Organization: NEULEVEL, INC.
	 	 	 	 	Address: 1120 VERMONT AVE, NW
	 	 	 	 	City: WASHINGTON
	 	 	 	 	State: DC
	 	 	 	 	Country: USA
	 	 	 	 	Postal Code: 20005
	 	 	 	 	Phone Number: (202) 533-2600
	 	 	 	 	Facsimile Number (202) 533-2970
	 	 	 	 	E-mail: JEFF.NEUMAN@NEULEVEL.BIZ
	 	 	 	 	Created On: MAY 5, 2001
	 	 	 	 	Updated On: MAY 5, 2001





Nameserver Record: 



	 	 	Input:	 	whois "nameserver dns1.neulevel.biz"
	 	 	Output:	 	Nameserver ID: HST-9
	 	 	 	 	Nameserver name: dns1.NEULEVEL.BIZ
	 	 	 	 	Currently Associated (true/false):T
	 	 	 	 	Nameserver status: ACTIVE
	 	 	 	 	IP addresses associated: 24.6.0.1
	 	 	 	 	Sponsoring Registrar: SAMPLE
	 	 	 	 	Created by Registrar: SAMPLE
	 	 	 	 	Last Updated by Registrar: May 5, 2001
	 	 	 	 	Last Transferred Date: May 5, 2001
	 	 	 	 	Additional fields (registrar specified)





Registrar Record: 



	 	 	Input:	 	whois "registrar SAMPLE"
	 	 	Output:	 	Registrar ID: REG-42
	 	 	 	 	Registrar Name: SAMPLE
	 	 	 	 	Registrar Status: ACTIVE
	 	 	 	 	Registrar Address 1: 424 Fifth Street
	 	 	 	 	Registrar Address 2:
	 	 	 	 	Registrar City: FARGO
	 	 	 	 	Registrar State/Province: ND
	 	 	 	 	Registrar Country: USA
	 	 	 	 	Registrar Postal Code: 12345
	 	 	 	 	Registrar Phone: (888) 555-1212
	 	 	 	 	Registrar E-mail: jn24601@sample.biz
	 	 	 	 	Admin Contact Name: Jean Valjean
	 	 	 	 	 









	 	 	 	 	Admin Contact Phone: (888) 555-1212
	 	 	 	 	Admin Contact E-mail: jn24601@sample.biz
	 	 	 	 	Billing Contact Name: Jean Valjean
	 	 	 	 	Billing Contact Phone: (888) 555-1212
	 	 	 	 	Billing Contact E-mail: jn24601@sample.biz





Enhanced Whois Service  


NeuLevel
will also provide a Whois-like directory service intended for intellectual property owners. This service will provide multiple responses to queries and allow
sub-string and boolean searches. The registry will provide access to a subset of the enhanced Whois functionality fee exempt, and additional functionality will be provided on a for fee
basis. 


This
service is intentionally separated from the standard Whois service due to the high transaction loads that will be placed on the standard service due to the fat-registry model, and
requirement to meet service level agreements. While the RFC954-conformant Whois service will be updated in near real-time, there is no need for the enhanced service to have
this requirement due to the nature of it's users. The enhanced service will not be required to conform to service level agreements, so the registry can be more liberal enabling enhanced functionality
that places additional load on the enhanced services infrastructure. The maximum update latency of the enhanced service will be 24 hours after updates to the core registry database are
received. 


The
registry will continue consultation with the Intellectual Property Constituency of the DNSO in ICANN and similar interested groups to maximize the utility of the enhanced Whois service. However at
a minimum the enhanced service will provide the following functionality: 


Functionality exempt from fee:  



	•
	Exact-match
search on registrant name, returning first 75 matching records. 




Functionality incurring fee:  



	•
	Exact-match
search on domain name. 
	•
	Exact-match
search on registrant name. 
	•
	Sub-string
search on domain name. 
	•
	Multi-field
search involving sub-string searches on both domain name and registrant name fields. 
	•
	Boolean
searches. For example: ((xxx AND yyy) OR zzz). 














APPENDIX P  


 
 

Whois Provider Data Specification  
  


Registry
Operator will provide bulk access to up-to-date data concerning domain name and nameserver registrations maintained by Registry Operator in connection with the
Registry TLD on a daily schedule, only for purposes of providing free public query-based access to up-to-date data concerning domain name and nameserver registrations in
multiple TLDs, to a party designated from time to time in writing by ICANN (the "Designated Recipient"). 


The
procedures for providing access, and the specification of the content and format of this data, will be as stated below, until changed according to the Registry Agreement. This Appendix is subject
to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. In addition, Registry Operator agrees to implement changes to this
Appendix sepcified by ICANN to conform to the IETF provreg working group's protocol specification no later than 135 days after the IETF specification is adopted as a Proposed Standard
[RFC 2026, section 4.1.1]. Accordingly, the following provides the target architecture and initial functionality. 


A.  Procedures for Providing Access  


The
Registry Operator will prepare (i) full data sets for one day of each week (the day to be designated by ICANN) and (ii) incremental data sets for all seven days of each week. Full
and incremental data sets shall be up-to-date and coherent as of 1200 UTC on the day to which they relate. Until a different day is designated by ICANN, the full data sets will
be prepared for Sundays. (Note that on the ICANN-designated day both an incremental and a full data set are prepared.) 



1.  Preparation of Files Containing Data Sets. Each full and incremental data set consists of an XML document meeting the content and format
requirements of Parts B and C of this document. Once the XML document is generated, the following preparation steps will be performed: 



a.  The
XML document will be placed in a file named according to the following convention: 


For
full data sets: "wfYYMMDD" where "YYMMDD" is replaced with the date (YY=last two digits of year; MM=number of month; DD=day; in all cases a single-digit number should be left-padded
with a zero). 


For
incremental data sets: "wiYYMMDD" where "YYMMDD" follows the same format. 


b.  The
Registry Operator may optionally split the document using the Unix SPLIT command (or equivalent) to produce files no less than 1GB each (except the final file). If files are split,
an MD5 file (produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors in case of transfer fault. The Registry Operator may optionally compress the document using
the Unix GZIP command (or equivalent) to reduce the filesize. 


c.  The
file(s) will then be encrypted and signed using PGP, version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the escrow
file in addition to encrypting it.) The Data Recipient's public key will be used for the encryption and the Registry Operator's private key will be used for the signature. Public keys will be
exchanged between the Registry Operator and the Designated Recipient by e-mail, physical delivery of floppy diskettes, or other agreed means. 




2.  Transmission of Full Data Sets. Once prepared, full data sets will be provided either by the procedures for incremental data sets
described in item A(3) below or, at the option of either the Registry Operator or the Designated Recipient, by writing the full data set to DAT tape (or other media mutually agreed by Registry
Operator and the Designated Recipient) and sending it to the Designated Recipient by expedited delivery service (such as FedEx or DHL). If sent by expedited delivery service, the full data set will be
scheduled for arrival no later than the second calendar day following the day to which the full backup relates. 









3.  Transmission of Incremental Data Sets. To permit the transmission of incremental data sets, the Registry Operator will make them
available for download by the Designated Recipient by Internet File Transfer Protocol. Incremental data sets will be made available for download no later than 20:00 UTC on the day to which they
relate. 




B.  Content  


The
data sets (whether full or incremental) will consist of four types of objects: 



1.  Domain objects. One type of object is the domain object, which corresponds to a single Registered Name. Each domain object includes the
following data: 



Domain
ID

Domain Name

Sponsoring Registrar (IANA-assigned identifier)

Domain Status

Registrant, Administrative, Technical and Billing

Contact Information including

        Contact ID

        Contact Name

        Contact Organization

        Contact Address, City, State/Province, Country

        Contact Postal Code

        Contact Phone, Fax, E-mail

Name Servers associated with this domain

Created by Registrar (IANA-assigned identifier)

Last Updated by Registrar (IANA-assigned identifier)

Last Transferred Date

Additional fields (registrar specified)

Domain Registration Date

Domain Expiration Date

Domain Last Updated Date 




2.  Nameserver objects. A second type of object is the nameserver object, which corresponds to a single registered nameserver. The
nameserver object includes the following data: 



Nameserver
ID

Nameserver Name

IP Addresses associated

Sponsoring Registrar(IANA-assigned identifier)

Created by Registrar (IANA-assigned identifier)

Name Server Last Updated by Registrar (IANA-assigned identifier)

Last Transferred Date 




3.  Contact objects. A third type of object is the contact object, which corresponds to a single contact (whether registrant,
administrative, technical or billing contact). The contact object includes the following data: 



Contact
ID

Contact Name

Contact Organization

Contact Address, City, State/Province, Country

Contact Postal Code

Contact Phone, Fax, E-mail

Contact Registration Date

Contact Last Updated Date

Currently Associated












Contact
Status

Sponsoring Registrar (IANA-assigned identifier)

Created Registrar (IANA-assigned identifier)

Last Transferred Date 





4.  Registrar object. The final type of object corresponds to a single registrar. It includes the following data: 



Registrar
ID (conforming to the IANA registrar-ids registry)

Registrar Name

Registrar Status

Registrar Address, City, State/Province, Country

Registrar Postal Code

Registrar Phone, Fax, E-mail

Registrar Administrative Contacts

Registrar Billing Contacts 




5.  Objects Contained in Full and Incremental Data Sets. Full data sets include one domain object for each Registered Name within the
Registry TLD; and nameserver, contact, and registrar objects for each nameserver, contact, and registrar referred to in any domain object. Incremental data sets consist of (a) those of the
objects constituting a full data set that have been added or updated since the last incremental data set and (b) notations of deletion of any objects since the last incremental data set. 




C.  Format  


Full
and incremental data sets will be XML version 1.0, UTF-8 encoded documents conforming to the following document type definition: 


<?xml
version="1.0"?> 


<schema
targetNamespace="urn:neulevel:whoisdb"

    xmlns="http://www.w3.org/2000/10/XMLSchema"

    xmlns:whoisdb="urn:neulevel:whoisdb"

    xmlns:eppcom="urn:iana:xml:ns:eppcom"

    xmlns:epp="urn:iana:xml:ns:epp"

    xmlns:contact="urn:iana:xml:ns:contact"

    xmlns:domain="urn:iana:xml:ns:domain"

    xmlns:host="urn:iana:xml:ns:host"

    elementFormDefault="qualified"> 


<!—Import
EPP Element Types—>

<import namespace="urn:iana:xml:ns:eppcom" schemaLocation="eppcom.xsd"/>

<import namespace="urn:iana:xml:ns:epp" schemaLocation="epp.xsd"/>

<import namespace="urn:iana:xml:ns:contact" schemaLocation="contact.xsd"/>

<import namespace="urn:iana:xml:ns:domain" schemaLocation="domain.xsd"/>

<import namespace="urn:iana:xml:ns:host" schemaLocation="host.xsd"/> 


<annotation>

    <documentation>XML Schema for Whois Data Escrow From NeuLevel

    </documentation>

</annotation> 



<!—Child
Element—>

<element name="whois-data" type="whoisdb:whoisDbType"/> 








<complexType
name="whoisDbType">

    <choice>

        <element name="full" type="whoisdb:fullsetType"/>

        <element name="incremental" type="whoisdb:partialType"/>

    </choice>

    <attribute name="tld" type="whoisdb:tldType" use="required"/>

    <attribute name="date" type="timeInstant" use="required"/>

</complexType> 


<simpleType
name="tldType">

    <restriction base="string">

        <enumeration value="biz"/>

    </restriction>

</simpleType> 


<complexType
name="fullsetType">

    <sequence>

        <element name="contact" type="contact:infDataType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="domain" type="domain:infDataType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="host" type="host:infDataType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="registrar" type="whoisdb:registrarType" minOccurs="0" maxOccurs="unbounded"/>

    </sequence>

</complexType> 


<complexType
name="partialType">

    <sequence>

        <element name="contact" type="contact:infDataType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="domain" type="domain:infDataType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="host" type="host:infDataType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="registrar" type="whoisdb:registrarType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="del-contact" type="contact:sIDType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="del-domain" type="domain:sNameType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="del-host" type="host:sNameType" minOccurs="0" maxOccurs="unbounded"/>

        <element name="del-registrar" type="whoisdb:registrarIDType" minOccurs="0" maxOccurs="unbounded"/>

    </sequence>

</complexType> 


<complexType
name="registrarIDType">

    <sequence>

        <element name="registrar-id" type="eppcom:clIDType"/>

    </sequence>

</complexType> 


<!—Registrar
Type derived from XRP Specification—>

<complexType name="registrarType">

    <sequence>

        <element name="roid" type="eppcom:roidType"/>











        <element
name="registrar-id" type="eppcom:clIDType"/>

        <element name="name" type="whoisdb:registrarNameType"/>

        <element name="address" type="contact:addrType"/>

        <element name="web-url" type="whoisdb:registrarWebUrlType"/>

        <element name="iana-id" type="whoisdb:registrarIanaIDType"/>

        <element name="contact" type="whoisdb:registrarContactType" maxOccurs="5"/>

        <element name="status" type="whoisdb:registrarStatusType"/>

        <element name="crDate" type="timeInstant"/>

        <element name="upDate" type="timeInstant" minOccurs="0"/>

    </sequence>

</complexType> 


<simpleType
name="registrarNameType">

    <restriction base="string">

        <minLength value="1"/>

        <maxLength value="128"/>

    </restriction>

</simpleType> 


<simpleType
name="registrarWebUrlType">

    <restriction base="string"/>

</simpleType> 


<simpleType
name="registrarIanaIDType">

    <restriction base="string"/>

</simpleType> 


<complexType
name="registrarContactType">

    <simpleContent>

        <extension base="eppcom:roidType">

            <attribute name="type" use="required">

                <simpleType>

                    <restriction base="string">

                        <enumeration value="administrative"/>

                        <enumeration value="billing"/>

                        <enumeration value="technical"/>

                    </restriction>

                </simpleType>

            </attribute>

        </extension>

    </simpleContent>

</complexType> 



<simpleType
name="registrarStatusType">

    <restriction base="string">

        <enumeration value="active"/>

        <enumeration value="suspended"/>

        <enumeration value="defunct"/>

    </restriction>

</simpleType> 


</schema>










APPENDIX Q  


 
  Whois Specification—ICANN  
  


Registry
Operator will provide bulk access by ICANN to up-to-date data concerning domain name and nameserver registrations maintained by Registry Operator in connection with
the Registry TLD on a daily schedule, only for purposes of verifying and ensuring the operational stability of Registry Services, the DNS, and the Internet. 


The
procedures for providing access, and the specification of the content and format of this data, will be as stated below, until changed according to the Registry Agreement. This Appendix is subject
to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. In addition, Registry Operator agrees to implement changes to this
Appendix specified by ICANN to conform to the IETF provreg working group's protocol specification no later than 135 days after the IETF specification is adopted as a Proposed Standard
[RFC 2026, section 4.1.1]. Accordingly, the following represents the target architecture and initial functionality. 


A. Procedures for Providing Access  



The
Registry Operator will prepare a full data set once each week (the day to be designated by ICANN). Full data sets shall be up-to-date and coherent as of 1200 UTC on the day
to which they relate. Until a different day is designated by ICANN, the full data sets will be prepared for Sundays. 



1. Preparation of Files Containing Data Sets. Each full data set consists of an XML document meeting the content and format requirements of Parts B and
C of this document. Once the XML document is generated, the following preparation steps will be performed: 



a.
The XML document will be placed in a file names according to the following convention: "wfYYMMDD" where "YYMMDD" is replaced with the date (YY=last two digits of year; MM=number of month; DD=day;
in all cases a single-digit number should be left-padded with a zero). 


b.
Registry Operator may optionally split the document using the Unix SPLIT command (or equivalent) to produce files no less than 1GB each (except the final file). If files are split, an MD5 file
(produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors. The Registry Operator may optionally compress the document using the Unix GZIP command (or equivalent)
to reduce the filesize. 


c.
The file(s) will then be encrypted and signed using PGP, version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note that PGP compresses the escrow file in
addition to encrypting it.) An ICANN public key will be used for the encryption and the Registry Operator's private key will be used for the signature. Public keys will be exchanged between the
Registry Operator and ICANN by e-mail, physical delivery of floppy diskettes, or other agreed means. 




2. Transmission of Full Data Sets. Once prepared, full data sets will be provided according to paragraph a below or, at Registry Operator's
option, according to paragraph b below: 



a.
Registry Operator will make full data sets available for download by ICANN by Internet File Transfer Protocol (FTP). (FTP access will be password protected and limited to prespecified IP ranges.)
The data sets will be made available for download beginning no later than 2000 UTC on the day to which they relate and until the next full data set becomes available for download. 


b.
Registry Operator will write the full data set to DAT (DDS-4) tape (or other media specified by ICANN) and send it to ICANN by expedited delivery service (such as FedEx or DHL). The
full data set will be scheduled for arrival at ICANN no later than the fourth calendar day following the day to which the data set relates. 
















B. Content  


The
full data sets will consist of the objects and contents described for full data sets in Part B of Appendix P. 


C. Format  



Full
data sets will be XML version 1.0, UTF-8 encoded documents conforming to the schema/document type declaration set forth in Part C of Appendix P. 









APPENDIX R  


 
  Data Escrow Schedule, Content, Format, and Procedure  
  


This
Appendix R to the Registry Agreement consists of four of the five exhibits to the Service Level Agreement that constitutes Appendix S to the Registry Agreement: 



Exhibit A—Schedule
for Escrow Deposits 


Exhibit B—Escrow
Deposit Format Specification 


Exhibit C—Escrow
Transfer Process 


Exhibit D—Escrow
Verification Procedures 




The
fifth exhibit (Exhibit E) to Appendix S, which sets forth the escrow agent's fees, is subject to negotiation between Registry Operator and the escrow agent. 


 
 

Exhibit A—Schedule for Escrow Deposits


1. Procedures for Providing Access. The Registry Operator will prepare (i) full data sets for one day of each week (the day to be designated by
ICANN) and (ii) incremental data sets for all seven days of each week. Full and incremental data sets shall be up-to-date and coherent as of 1200 UTC on the day to which
they relate. Until a different day is designated by ICANN, the full data sets will be prepared for Sundays. 



2. Preparation of Files Containing Data Sets. Each full and incremental data set consists of an XML document meeting the content and format requirements
of Exhibit B of this document. Once the XML document is generated, the following preparation steps will be performed: 


The
XML document will be placed in a file named according to the following convention: 



For
full data sets: "wfYYMMDD" where "YYMMDD" is replaced with the date (YY=last two digits of year; MM=number of month; DD=day; in all cases a single-digit number should be left-padded
with a zero). 



For
incremental data sets: "wiYYMMDD" where "YYMMDD" follows the same format. 




3. Start Date for Escrow Procedures. Registry Operator and ICANN shall cooperate in resolving implementation issues, an escrow agent shall be selected,
and an escrow agreement shall be entered in time for escrow deposits to begin within ninety days after the Commencement-of-Service Date. 


 
 

Exhibit B—Escrow Deposit Format Specification


This
Appendix is subject to change by agreement of Registry Operator and ICANN during the design process as well as during the IETF standards process. In addition, Registry Operator agrees to
implement changes to this Appendix sepcified by ICANN to conform to the IETF provreg working group's protocol specification no later than 135 days after the IETF specification is adopted as a
Proposed Standard [RFC 2026, section 4.1.1]. Accordingly, the following provides the target architecture and initial functionality. 



The
escrow data sets (whether full or incremental) will consist of four types of objects: 



	•
	Domain
object



	•
	Nameserver
object



	•
	Contact
object



	•
	Registrar
object 




Additionally,
incremental data sets will contain notations of deletion of objects since the last incremental data set. 










1. The Domain Object. The domain object which corresponds to a single registered name consists of the following elements: 




Domain
ID

Domain Name

Sponsoring Registrar

Domain Status

Registrant Identifier

Contact Identifiers for Administrative, Technical and Billing

Contacts

Name Servers associated with this domain

Child Name Servers registered in this domain

Domain Created by Registrar

Domain Last Updated by Registrar

Domain Registration Date

Domain Expiration Date

Domain Last updated

Date Domain Last TransferDate

Domain Authorization Information

Additional Fields (Registrar Specified) 





2. The Name Server Object. The nameserver object which corresponds to a single registered nameserver consists of the following elements: 




Name
Server ID

Name Server Name

Name Server Status

Name Server Association Status

Name Server IP Addresses if applicable

Sponsoring Registrar

Created by Registrar

Name Server Creation Date

Name Server Last Updated Date

Name Server Last Transfer Date

Additional fields (Registrar Specified)

Name Server Authorization Information 





3. The Contact Object. The contact object, which corresponds to a single contact (whether registrant, administrative, technical or billing contact)
consists of the following elements: 




Contact
ID

Contact Name

Contact Status

Contact Association Status

Contact Organization

Contact Address, City, State/Province, Country

Contact Postal Code

Contact Phone, Fax, E-mail

Sponsoring Registrar

Created by Registrar

Contact Creation Date

Contact Last Updated Date

Contact Last Transfer Date

Contact Authorization Information

Additional fields (Registrar Specified) 














4. The Registrar Object. The registrar object, which corresponds to a single registrar consists of the following elements: 




Registrar
ID (registry specific)

Registrar Object Identifier (Unique object Identifier)

Registrar ID (conforming to the IANA registrar-ids registry)

Contact ID of Registrar

Registrar Name

Registrar Address, City, State/Province, Country

Registrar Administrative Contacts

Registrar Technical Contacts

Registrar Billing Contacts

Registrar URL

Registrar Creation Date

Registrar Last Updated Date

Registrar Authorization Information

Registrar Account Information 





Additionally,
incremental data sets will contain notations of deletion of objects since the last incremental data set. These notations of object deletion are defined as follows: 



	Name of element
 
	 	Type of element

	Del-domain	 	domain:sNameType
	Del-nameserver	 	host:sNameType
	Del-contact	 	contact:sIDType
	Del-registrar	 	whoisdb:registrarIDType






Objects Contained in Full and Incremental Data Sets. Full data sets include one domain object for each Registered Name within the Registry TLD; and
nameserver, contact, and registrar objects for each nameserver, contact, and registrar referred to in any domain object. Incremental data sets consist of:(a) those of the objects constituting a full
data set that have been added or updated since the last incremental data set and (b)notations of deletion of any objects since the last incremental data set. 


Format. Full and incremental data sets will be XML version 1.0, UTF-8 encoded documents. The XML Schema definition for the objects and their
notations of deletion will be specified after discussions between ICANN and Registry Operator. The format will be based on the Whois provider format specified in Appendix P, Section C
"Format", but will be augmented to include all data elements reasonably necessary to permit operation of the Registry Services for the Registry TLD in the event the escrow data is released. In the
event that ICANN and Registry Operator do not agree on the escrow format, ICANN shall reasonably specify that format. 


 
 

Exhibit C—Escrow Transfer Process


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



1.
The file(s) making up the Deposit will first be created according to the format specification. (See Exhibit B above, "Escrow Deposit Format Specification"). The resulting file shall be named
according to the following format: "bizSEQN", where "SEQN" is a four digit decimal number that is incremented as each report is prepared. 


2.
Next, the Deposit file will be processed by a program (provided by ICANN) that will verify that it complies with the format specification and contains reports of the same date/time (for a Full
Deposit), count the number of objects of the various types in the Deposit, and append to the file a report of the program's results. 


3.
Registry Operator may optionally split the resulting file using the Unix SPLIT command (or equivalent) to produce files no less than 1 GB each (except the final file). If Deposit files are split, 












an
MD5 file (produced with MD5SUM or equivalent) must be included with the resulting files to isolate errors. 


4.
The file(s) will then be encrypted and signed using a method mutually agreed by the Registry Operator and the Designated Data Recipient. 



5.
Transmission of Full Data Sets. Once prepared, full data sets will be provided either by the procedures for incremental data sets described in item C(6) below or, at the option of either the
Registry Operator or the Designated Recipient, by writing the full data set to DAT tape (or other media mutually agreed by Registry Operator and the Designated Recipient) and sending it to the
Designated Recipient by expedited delivery service (such as FedEx or DHL). If sent by expedited delivery service, the full data set will be scheduled for arrival no later than the second calendar day
following the day to which the full backup relates. 


6.
Transmission of Incremental Data Sets. To permit the transmission of incremental data sets, the Registry Operator will make them available for download by the Designated Recipient by Internet file
transfer protocol. Incremental data sets will be made available for download no later than 2000 UTC on the day to which they relate. 



 
 

Exhibit D—Escrow Verification Procedures


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



1.
At the conclusion of the deposit window, all Deposit files will be moved to a not-publicly-accessible directory and the existence and size of each will be noted. 


2.
The file(s) will then be decrypted using a method mutually agreed by the Registry Operator and the Escrow agent. 


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



4.
Escrow Agent will run a program on the Deposit file (without report) that will split it in to its constituent reports (including the format report prepared by the Registry Operator and appended to
the Deposit) check its format, count the number of objects of each type, and verify that the data set is
internally consistent. This program will compare its results with the results of the Registry-generated format report, and will generate a Deposit format and completeness report. 


5.
The decrypted Deposit file will be encrypted by the program using a method mutually agreed by the Registry Operator and the Escrow agent. 


6.
The decrypted Deposit file will be destroyed to reduce likelihood of data loss to intruders in case of partial security failure. 




Distribution Of Public Keys. Each of Registry Operator and Escrow Agent will distribute its public key to the other party (Registry Operator or Escrow
Agent, as the case may be), confirm receipt by a method mutually agreed by both the parties. 









APPENDIX S  


 
  Registry Data Escrow Agreement  
  


This
Registrar Data Escrow Agreement ("Agreement") is made as of this [enter date] (the "Beginning Date"), by and between
[name of Registry Operator] ("Registry Operator"), [name of Escrow
Agent] ("Escrow Agent"), and the Internet Corporation for Assigned Names and Numbers ("ICANN"). All capitalized terms not defined herein shall have the meaning set
forth in the Registry Agreement. All capitalized terms not defined in this Agreement have the meanings set forth in the Registry Agreement. 


 
 

RECITALS    
    


A.
Registry Operator and ICANN have entered into a Registry Agreement dated [insert date of Registry Agreement] ("Registry
Agreement"), which requires Registry Operator, during the term of the Registry Agreement, to submit certain domain name registration data to a reputable escrow agent to be held in escrow. 


B.
Pursuant to the Registry Agreement, Registry Operator intends to deliver periodically to Escrow Agent an electronic copy of the Registry Database, as detailed in Subsection 3.11 of the Registry
Agreement (each such delivery referred to as a "Deposit"). 


C.
Registry Operator desires Escrow Agent to hold each Deposit, and, upon certain events, release any retained Deposits (or a copy of the Deposits) to ICANN, in accordance with the terms of this
Agreement or as ordered by a court of competent jurisdiction. 


Now,
therefore, in consideration of the premises and mutual obligations contained herein and for other good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged,
the parties agree as follows: 


 
 

AGREEMENT    
    


1.
Content of Deposits. Deposits will be of two kinds: Full Deposits and Incremental Deposits. Each Full Deposit will consist of Registry Data that
reflects the current and complete Registry Database. Incremental Deposits will consist of data that reflects all transactions involving the database that are not reflected in the last previous Full
Deposit or Incremental Deposit, as the case may be. 


2.
Schedule for Deposits. Registry Operator must create and deliver to Escrow Agent a Full Deposit once each week, according to the schedule specified
in Exhibit A of Appendix R. Registry Operator must create and deliver to Escrow Agent an Incremental Deposit once each day during which a Full Deposit is not made, according to the
schedule specified in Exhibit A of Appendix R. 



3.  Format of Deposits. The data in each Full Deposit and in each Incremental Deposit shall follow the data format specified in the TLD Registry Data
Escrow: Format Specification (the "Format Specification"), attached as Exhibit B of Appendix R. 


4.
Procedure for Deposits. Each properly formatted Full Deposit and Incremental Deposit shall be processed and electronically delivered in encrypted
form to Escrow Agent according to the transfer process described in Exhibit C of Appendix R. 


5.
Notification of Deposits. Simultaneous with the delivery to Escrow Agent of any Full or Incremental Deposit, Registry Operator shall deliver to
Escrow Agent and to ICANN a written statement (which may be by authenticated e-mail) that includes a copy of the report generated upon creation of the Full or Incremental Deposit by the
ICANN-provided software (as described in Exhibit A) and states that the Full or Incremental Deposit (as the case may be) has been inspected by Registry Operator according to the procedures
described in Exhibit C of Appendix R and is complete and accurate. Escrow Agent shall notify ICANN of all Deposits received, within two business days of receipt. 


6.
Verification. Within two business days after receiving each Full or Incremental Deposit, Escrow Agent shall verify the format and completeness of
each Deposit by performing the verification procedures 










specified
in Exhibit D of Appendix R and shall deliver to ICANN a copy of the verification report generated for each Deposit (which may be by authenticated e-mail). If Escrow
Agent discovers that any Deposit fails the verification procedures, Escrow Agent shall notify, including by email, fax and phone, Registry Operator and ICANN of such nonconformity within forty-eight
hours of discovery. Upon notification of such verification failure, Registry Operator shall begin developing modifications, updates, corrections, and other fixes of the Full or Incremental Deposit
necessary for the Deposit to pass the verification procedures and shall deliver such fixes to Escrow Agent as promptly as possible. Escrow Agent shall verify the accuracy or completeness of any such
corrected Deposit pursuant to the procedures in this Section 6 and shall give ICANN notice of successful verification within twenty-four hours. The failure of any Full or
Incremental Deposit to meet verification procedures and any efforts by Registry Operator to remedy such failure shall not delay the delivery of any subsequent scheduled Full or Incremental Deposits
pursuant to the schedule in Exhibit A of Appendix R. Escrow Agent shall deliver, on the first business day of each month, (i) a written certification to ICANN that Escrow Agent
has performed such verification procedures on each Deposit received during the last month, and (ii) copies of the verification reports generated for each Deposit received during the last month. 



7.  Retention and Confidentiality. 



7.1  Retention. Escrow Agent shall hold and maintain the Deposits in a secure, locked, and environmentally safe facility which is accessible only to
authorized representatives of Escrow Agent. Escrow Agent shall use commercially reasonable efforts to protect the integrity of the Deposits. Each of ICANN and Registry Operator shall have the right to
inspect Escrow Agent's written records with respect to this Agreement upon reasonable prior notice and during normal business hours. 


7.2
Destruction of Deposits. At all times, Escrow Agent shall retain the four most recent Full Deposits and all Incremental Deposits after the earliest
of those four Full Deposits, all of which must have passed the verification procedures specified in Exhibit D of Appendix R. Registry Operator may destroy any Deposits prior to these
four most recent Full Deposits. 


7.3
Confidentiality. Escrow Agent shall use commercially reasonable efforts to protect the confidentiality of the Deposits. Except as provided in this
Agreement, Escrow Agent shall not disclose, transfer, make available, or use any Deposit (or any copies of any Deposit). Should Escrow Agent be put on notice that it is required to disclose any
Deposits by statute, rule, regulation, order, or other requirement of a governmental agency, legislative body, court of competent jurisdiction, or binding arbitral body (other than any requirement
pursuant to Sections 9.6, 11, and 13 of this Agreement), Escrow Agent shall notify ICANN and Registry Operator within seven days or as soon as practicable and reasonably cooperate with Registry
Operator and/or ICANN in any contest of the disclosure. Should any contest
prove unsuccessful, Escrow Agent shall not be held liable for any disclosure pursuant to such governmental, legislative, judicial, or arbitral order, statute, rule, regulation, or other requirement. 




8.
Duplication. Escrow Agent may duplicate any Deposit by any commercially reasonable means in order to comply with the terms and provisions of this
Agreement, provided that Registry Operator shall bear the expense of such duplication. Alternatively, Escrow Agent, by notice to Registry Operator, may reasonably require Registry Operator to promptly
duplicate any Deposit. 


9.  Release of Deposit to ICANN. Within five business days after receipt of any required documents and/or notices specified in this Section 9,
Escrow Agent shall deliver to ICANN all Deposits in Escrow Agent's possession, in the event that the Escrow Agent receives all of the following: 



9.1
One of the following notices: 



9.1.1
A written notice by the Registry Operator requesting Escrow Agent to effect such delivery to ICANN; or 











9.1.2
A written notice by ICANN that the Registry Agreement has: (i) expired without renewal, pursuant to Subsection 5.1 of the Registry Agreement, or (ii) been terminated, pursuant to
Subsection 5.4 of the Registry Agreement; or 


9.1.3
A written notice by ICANN that all of the following have occurred: 



9.1.3.1
ICANN failed, with respect to (a) any Full Deposit or (b) five Incremental Deposits within any calendar month, to receive, within five calendar days after the Deposit's scheduled
delivery date, to receive notification of receipt from Escrow Agent; and 



9.1.3.2
ICANN gave notice to Escrow Agent and Registry Operator of that failure; and 


9.1.3.3
ICANN has not, within seven calendar days after the notice under Section 9.2.3.2, received notice from Escrow Agent that the Deposit has been received; or 




9.1.4
A written notice by ICANN that all of the following have occurred: 



9.1.4.1
ICANN has received notification from Escrow Agent of failed verification of a Full Depositor of failed verification of five Incremental Deposits within any calendar month; and 



9.1.4.2
ICANN gave notice to Registry Operator of that receipt; and 


9.1.4.3
ICANN has not, within seven calendar days after the notice under Section 9.1.4.2, received notice from Escrow Agent of verification of a remediated version of the Deposit; or 




9.1.5
A written notice by ICANN that release of the Deposits is mandated by non-payment of any fees due to Escrow Agent, pursuant to Section 15 of this Agreement; or 


9.1.6
A written notice by ICANN that a court, arbitral, legislative, or government agency that ICANN finds to be of competent jurisdiction has issued an order, rule, statute, regulation, or other
requirement (a copy of which ICANN has provided to Registry Operator) that mandates the release of the Deposits to ICANN; and 




9.2
Evidence satisfactory to Escrow Agent that ICANN or Registry Operator (whichever gave the notice under Section 9.1) has previously notified the other party in writing; and 


9.3
Written instructions from ICANN that the Deposits be released and delivered to ICANN; and 


9.4
A written undertaking by ICANN that the Deposits will be used only as permitted under the terms of the Registry Agreement. Upon release of any Deposits to ICANN, Escrow Agent shall at the same
time deliver to Registry Operator a photostatic copy of the notice it received from ICANN under Sections 9.1.2 to 9.1.6, as applicable. 




10.  Release of Deposit to Registry Operator. Escrow Agent shall deliver all Deposits to Registry Operator upon termination of this Agreement in
accordance with Sections 14.1 and 14.2.1 of this Agreement. 


11.
Procedure After Release. 



11.1
Right to Use Deposits. Upon release of any Deposits to ICANN pursuant to Section 9, ICANN shall immediately have the right to exercise or
have exercised all rights in the Deposits necessary to provide registry services, as detailed in Section 3.13 of the Registry Agreement, except that ICANN shall not deliver Deposits released
pursuant to Sections 9.1.3, 9.1.4, or 9.1.5 to a third party for use so long as (a) the Registry Agreement is in effect, (b) Registry Operator is providing Registry Services in
conformity with the requirements of the Registry Agreement, and (c) Registry Operator provides Deposits directly to ICANN according to the Exhibits A, B, and C of Appendix R (modified to
make ICANN rather than Escrow Agent the recipient), and the Deposits pass the verification procedures specified in Exhibit D of Appendix R. 










11.2
Objection Notice. Upon release of any Deposits to ICANN pursuant to Sections 9.1.2 through 9.1.6, Registry Operator shall have thirty calendar days
to notify Escrow Agent and ICANN in writing (the "Objection Notice") of its objection to the release of the Deposits to ICANN and request that the issue of entitlement to the Deposits be resolved
pursuant to the dispute resolution procedures in Subsection 5.9 of the Registry Agreement (the "Dispute Resolution Procedures"). Registry Operator and ICANN agree to resolve any disputes they may have
as between themselves hereunder, including any objections to release of the Deposits pursuant to Sections 9.1.2 thru 9.1.6, solely through the Dispute Resolution Procedures. The parties agree that the
delivery of an Objection Notice and the commencement of Dispute Resolution Procedures shall not delay release of any Deposits to ICANN pursuant to Section 9. 


11.3
Dispute Resolution Procedures. The parties agree that any proceedings brought pursuant to the Dispute Resolution Procedures shall be conducted
consistently and in accordance with any prior arbitration or court orders/decisions involving the Registry Agreement. The parties further agree that any proceedings relating to this Agreement and
brought pursuant to the Dispute Resolution Procedures shall not examine, re-evaluate, reconsider, or otherwise subject to review any issues, causes of action, or other claims which were
decided, or which a party had a reasonable opportunity to raise, in proceedings which involved the Registry Agreement. 


11.4
Withdrawal of Objection Notice. Registry Operator may, at any time, notify Escrow Agent and ICANN that Registry Operator wishes to withdraw its
Objection Notice. Upon receipt of such withdrawal from Registry Operator, Escrow Agent shall promptly deliver to ICANN any Deposits that have not previously been delivered to ICANN. 



11.5  Dispute Resolution Decisions. 



11.5.1
If the release of Deposits to ICANN is determined in Dispute Resolution Procedures to have been proper, Escrow Agent shall promptly deliver to ICANN, in accordance with the instructions
specified in Section 9.3, any Deposits that have not previously been delivered. 


11.5.2
If the release of Deposits to ICANN is determined in Dispute Resolution Procedures to have been improper, ICANN shall promptly return or destroy, at Registry Operator's discretion, the Deposits
received by ICANN under Section 9. 





12.
Indemnity. Registry Operator and ICANN shall, jointly and severally, indemnify and hold harmless Escrow Agent and each of its directors, officers,
agents, employees and stockholders ("Escrow Agent Indemnitees") absolutely and forever, from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges,
and any other expenses whatsoever, including reasonable attorneys' fees and costs, that may be asserted by a third party against any Escrow Agent Indemnitees in connection with this Agreement or the
performance of Escrow Agent or any Escrow Agent
Indemnitees hereunder (with the exception of any claims based on the misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents, employees, contractors, and
stockholders). Escrow Agent shall likewise indemnify and hold harmless Registry Operator and ICANN, and each of their respective directors, officers, agents, employees and stockholders ("Indemnitees")
absolutely and forever, from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any other expenses whatsoever, including reasonable attorneys'
fees and costs, that may be asserted by a third party against any Indemnitee in connection with the misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents,
employees, contractors, and stockholders. 



13.
Interpleader. 



13.1
Escrow Agent may submit any dispute under this Agreement to any court of competent jurisdiction in an interpleader or similar action. Any and all costs incurred by Escrow Agent in connection
therewith, including reasonable attorneys' fees and costs, shall be borne 50% by each of Registry Operator and ICANN. 











13.2
Escrow Agent shall perform any acts ordered by any court of competent jurisdiction, without any liability or obligation to any party hereunder by reason of such act. 




14.
Term and Termination. 



14.1
Term. The initial term of this Agreement shall be one year, commencing on the Beginning Date (the "Initial Term"). This Agreement shall be
automatically renewed for an additional term of one year ("Additional Term") at the end of the Initial Term and each Additional Term hereunder unless, on or before ninety days prior to the end of the
Initial Term or an Additional Term, a party notifies the other parties that it wishes to terminate this Agreement at the end of such term. In the event a party gives the other parties such notice of
termination, and Registry Operator and ICANN cannot agree to resolve, by the end of the then-current term, any disputes regarding the renewal of this Agreement or the establishment of a
replacement escrow agent: (i) Registry Operator and ICANN shall resolve any such disputes through the Dispute Resolution Procedures; (ii) this Agreement shall continue to remain in
effect during the resolution of any such disputes; and (iii) Escrow Agent shall have the right to invoice either Registry Operator or ICANN for the data escrow services provided during this
dispute resolution period at the rates listed in Exhibit E. This paragraph in no way limits the Registry Operator's right under Subsection 3.11 of the Registry Agreement to change to a
different Escrow Agent mutually approved by Registry Operator and ICANN, such approval not to be unreasonably withheld by either of them, provided that such Escrow Agent will agree to substantially
similar terms as in the present document and there is no significant interruption of Deposits. 


14.2
Termination. This Agreement shall terminate the occurrence of any of the following: 



14.2.1
Termination of this Agreement by both Registry Operator and ICANN upon having delivered to Escrow Agent a written notice signed by both Registry Operator and ICANN indicating their mutual
intent to terminate this Agreement upon ninety days' notice; 


14.2.2
Termination of this Agreement by Escrow Agent pursuant to Section 15; or 


14.2.3
Release of the Deposit(s) to ICANN pursuant to Section 9 and, if an Objection Notice is made and not withdrawn, a final decision that the release of materials to ICANN was proper at the
end of the Dispute Resolution Procedures. 





15.
Fees and Payments. Registry Operator shall pay to Escrow Agent the applicable fees and charges listed in Exhibit E as compensation for Escrow
Agent's services under this Agreement. If Registry Operator fails to pay any fees or charges invoiced by Escrow Agent by the due date(s), Escrow Agent shall give written notice to Registry Operator of
non-payment of any such past-due fees hereunder and, in that event, the Registry Operator shall have the right to pay the past-due fee(s) within ten business days
after receipt of the notice from Escrow Agent. If Registry Operator fails to pay in full all such past-due fees during the ten day period, Escrow Agent shall give notice of
non-payment of any past-due fees to ICANN and, in that event, ICANN shall have the option of paying the past-due fee within ten business days of receipt of such
notice from Escrow Agent. Upon payment of the past-due fee by either Registry Operator or ICANN, this Agreement shall continue in full force and effect. If both Registry Operator and ICANN
fail to pay the past-due fee(s) within the applicable periods under this Section 15, Escrow Agent shall have the right to terminate this Agreement immediately by sending notice of
termination to all other parties, and, upon termination, Escrow Agent shall deliver to ICANN all Deposits held by Escrow Agent. 


16.
Ownership of Deposit Materials. Subject to the provisions (including Subsection 3.13) of the Registry Agreement, the parties recognize and
acknowledge that ownership of the Deposit materials during the effective term of this Agreement shall remain with the Registry Operator at all times. 












17.  Miscellaneous. 



17.1
Remedies. For the purposes of fulfilling its obligations under this Agreement, Escrow Agent may act in good faith reliance on, and shall not be
held liable for, any written notice, instruction, instrument, or other writing signed or presented by a person with apparent authority to act on behalf of Registry Operator or ICANN. 


17.2
Dispute Resolution. Registry Operator and ICANN further agree to resolve any disputes they may have as between themselves under this Agreement
pursuant to the Dispute Resolution Procedures. 


17.3  Limitation of Liability. The parties shall not be liable to each other for special, indirect, incidental, or consequential damages hereunder. As
between ICANN and Registry Operator the liability limitations of Subsection 5.10 of the Registry Agreement also apply. 


17.4
Independent Contractor. Escrow Agent is an independent contractor and is not an employee or agent of either Registry Operator or ICANN. 


17.5
No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by Registry Operator, ICANN, or Escrow Agent to any
non-party to this Agreement, including but not limited to any domain-name holder or registrar. 


17.6  Amendments. This Agreement shall not be modified or amended except in writing executed by each of the parties. 


17.7
Assignment. Neither Registry Operator nor ICANN may assign or transfer this Agreement (by merger, sale of assets, operation of law, or otherwise),
except that the rights and obligations of Registry Operator or ICANN automatically shall be transferred to the assignee of one of those parties' rights and obligations under the Registry Agreement.
Escrow Agent may not assign or transfer this Agreement without the prior written consent of both Registry Operator and ICANN. 



17.8  Entire Agreement. This Agreement, including all exhibits, supersedes all prior discussions, understandings, and agreements between Escrow Agent and
the other parties with respect to the data escrow services. The parties acknowledge and agree that, as between ICANN and Registry Operator, the Registry Agreement (including all its appendices) is
intended to co-exist with this Agreement, this Agreement is supplementary to the Registry Agreement, and the Registry Agreement shall control in the event of any conflict. 


17.9
Counterparts. This Agreement may be executed in counterparts, each of which when so executed shall be deemed to be an original and all of which
when taken together shall constitute one and the same Agreement. 


17.10  Governing Law. This Agreement shall be construed and enforced in accordance with the laws of the State of California, without regard to its
conflicts-of-laws principles. The parties consent and agree that jurisdiction and venue for any legal proceedings relating to this Agreement shall lie with the state and
federal courts of Los Angeles County in the State of California. 


17.11
Notices. All notices, requests, demands or other communications required or permitted to be given or made under this Agreement shall be in writing
and shall be delivered by hand, by commercial overnight delivery service which provides for evidence of receipt, by certified mail, return receipt requested, postage prepaid, by facsimile, or by
e-mail (e-mail to be followed promptly at receiver's request by a copy delivered by one of the other means of delivery) to the corresponding addresses listed on the signature
page of this Agreement. If delivered personally, by commercial overnight delivery service, by facsimile, or by e-mail, the date on which the notice, request, instruction or document is
delivered shall be the date on which delivery is deemed to be made, and if delivered by mail, the date on which such notice, request, instruction or document is received shall be the date on which
delivery is deemed to 














be
made. Any party may change its address for the purpose of this Agreement by notice in writing to the other parties as provided herein. 



17.12  Survival. The obligation of confidentiality in Section 7, Sections 9, 10, 11, 12, 13, and this Section 17.12 shall survive any
termination of this Agreement. 


17.13
No Waiver. No failure on the part of any party hereto to exercise, and no delay in exercising any right, power or single or partial exercise of
any right, power or remedy by any party will preclude any other or further exercise of that or any other right, power, or remedy. No express waiver or assent by any party to any breach of or default
in any term or condition of this Agreement shall constitute a waiver of or an assent to any succeeding breach of or default in the same or any other term or condition. 





IN
WITNESS WHEREOF each of the parties has caused its duly authorized officer to execute this Agreement as of the date and year first above written. 


Escrow
Agent

[name and address of Escrow Agent] 



	By:	 	
 [name of signer]

[title of signer]	 	 
	

Registry Operator

[name and address of Registry Operator]	
 	

 
	

By:	
 	

 [name of signer]

[title of signer]	
 	

 
	

ICANN



4676 Admiralty Way

Suite 330

Marina del Rey, CA 90292

E-mail:

Phone: 1-310-823-9358

Fax: 1-310-823-8649	
 	

 
	

By:	
 	

 M. Stuart Lynn

President and CEO	
 	

 











APPENDIX T  


 
  Registry Operator's Monthly Report  
  


Registry
Operator shall provide the following information in its monthly reports. Information reported in response to items 5-16 shall be kept confidential by ICANN until three months
after the end of the month to which the report relates. 


ICANN
shall use reasonable commercial efforts to preserve the confidentiality of the information reported in response to items 5-16. 



1. Accredited Registrar Status. State the number of registrars for whom the Registry Operator had received accreditation notification from ICANN at the
end of the reporting month, grouped into the following three status categories: 



1.1.
Operational registrars are those who have authorized access into the System for processing domain name registrations. It should be noted that operational registrars are not listed on the
InterNIC.net web site until they specifically request to be listed. This means that a registrar may be operational from the point of view of the Registry Operator but not listed on the InterNIC site. 



1.2.
Registrars in the ramp-up period represent those who have received a password to access the Registry operational test and evaluation (OT&E) environment. The OT&E environment is
provided to allow registrars to develop and test their systems with the System. 


1.3.
Registrars in the pre-ramp-up period are those who have been sent information regarding the Registry TLD, but have not yet entered the Ramp-up Period. 




2. Service Level Agreement Performance. Compare Service Level Agreement ("SLA") requirements with actual performance measures for the reporting month. 



3. TLD Zone File Access Activity. State the zone file access activity for the current reporting month including: 



3.1.
Total number of zone file access passwords at end of previous month 


3.2.
Number of new zone file access passwords issued during the reporting month 


3.3.
Total number of zone file access approvals at end of reporting month 




4. Completed SRS/System Software Releases. State significant releases that have occurred since the Effective Date, including: 



4.1.
Release Name 


4.2.
Features 


4.3.
Target Date 


4.4.
Complete Date 




5. Domain Names Under Sponsorship—Per Registrar. State the number of domain names sponsored by each live ICANN-Accredited Registrar in the
TLD for the current reporting month. 


6. Nameservers Under Management—Per Registrar. State the number of nameservers registered by each ICANN-Accredited Registrar in the TLD for
the current reporting month. 


7. Domain Names Registered by Registry Operator. Provide a list of all domain names registered by Registry Operator, other than on a request submitted
by a registrar pursuant to that registrar's Registry-Registrar Agreement, in the Registry TLD. The list should be broken down in accordance with Subsections 3.6.1 and 3.6.2 of the Registry Agreement. 


8. Whois Service Activity. State the number of Whois queries during the current reporting month. For registries with fee-based enhanced
Whois Service, state the number of queries for each service (i.e. basic, xWhois, etc.). 










9. Monthly Growth Trends. Tabulate the monthly growth trend in total Registry transactions. Transactions should be divided into three categories: 



9.1.
Write Domain—This category includes the following transactions: add domain, modify domain, delete domain, renew domain (including restore domain), auto-renew domain (if
any) and transfer domain. 


9.2.
Query Domain—This category includes the following transactions: query domain and query domain transfer status. 


9.3.
Check Domain—This category includes the following transaction: check domain. 



9.4.
Write Server—This category includes the following transactions: add name server, modify name server, and delete name server. 


9.5.
Query Server—This category includes the following transaction: query name server. 


9.6.
Check Server—This category includes the following transaction: check name server. 


9.7.
Write Contact (where contact information is maintained under the registry model)—This category includes the following transactions: add contact, modify contact, delete contact,
transfer contact. 


9.8.
Query Contact (where contact information is maintained under the registry model)—This category includes the following transactions: query contact and query contact transfer status. 



9.9.
Check Contact (where contact information is maintained under the registry model)—This category includes the following transaction: check contact. 




10. Total Number of Transactions by Subcategory by Month. Tabulate the monthly growth trend for each transaction in subcategories of the Write Domain,
Write Server, and Write Contact categories described in Subsection 9.1 as follows: 



10.1.
Add Domain 


10.2.
Delete Domain(divided in deletions within the Add Grace Period, and those that are moved to the Redemption Grace Period). 


10.3.
Modify Domain 


10.4.
Check Domain 


10.5.
Renew Domain 


10.6.
Transfer Domain 


10.7.
Restore Domain 




11. Total Number of Failed Transactions by Subcategory by Month. Starting 1 December 2001, tabulate the monthly growth trend for each failed
transaction in subcategories of the Write Domain, Write Server, and Write Contact categories described in Subsection 9.1 as follows: 



11.1.
Add Domain 


11.2.
Delete Domain 


11.3.
Modify Domain 


11.4.
Check Domain 


11.5.
Renew Domain 


11.6.
Transfer Domain 


11.7.
Restore Domain 













12. Daily Transaction Range. Tabulate the number of total daily transactions. The range of transaction volume should be shown for each month along with
the average daily transaction volume. 


13. TLD Geographical Registrations Distribution. Tabulate the number and percent of total and new domain name registrations in the Registry TLD broken
down by geographical location (country code) as of the end of the current reporting month. (Only applies where contact information is maintained under registry model.) 


14. Deleted Names—Per Registrar. State the number of domain names deleted by each registrar during the current reporting month. 



15. Restored Names—Per Registrar. List the number of domain names restored by each registrar during the current reporting month, and state
the total number of domain names restored by each registrar. 


16. Violations of Registrar Restore Report—Per Registrar. List the total number of such domain names for each registrar. 









APPENDIX U  


 
  Evaluation of Concepts  
  


Registry
Operator shall provide the following reports and related data to ICANN for use in its proof of concept evaluation. Such reports shall be provided according to the schedule described herein
during the Term of the Registry Agreement. 


The
reports provided by Registry Operator as described in this Appendix shall be subject to confidentiality restrictions according to categories described in Section 11. 


1. Concept: Procedures for Maintaining Registry Stability and Fairness to Customers in the Launch of a TLD Restricted to Commercial Use



1.1 Phase 1 Period Effectiveness—within 120 days after the end of the Phase 1 Period (as set forth in Appendix J), Registry
Operator shall provide the following information and reports to ICANN. 



1.1.1
Total number of Trademark Claim Form Submissions for the Intellectual Property Notification ("IPN") Service. 


1.1.2
Total number of Trademark Claim Form Submissions for the IPN Service broken down by the following global regions: 



1.1.2.1
Africa; 


1.1.2.2
Asia Pacific; 


1.1.2.3
Europe; 


1.1.2.4
Latin America/Caribbean; and 


1.1.2.5
North America. 




1.1.3
Total fees collected for the IPN Service during the Phase 1 Period. 


1.1.4
Total number "matches" between.biz strings submitted in the.biz domain name Applications and Trademark Claim Forms. 


1.1.5
Total number of domain names placed "on hold" as a result of the IPN Service. 



1.1.6
Total number of domain name requests cancelled by the applicant following IPN Service notice. 


1.1.7
Total Domain Name Application volume by day. 


1.1.8
Total Domain Name Application volume by week. 


1.1.9
Total Domain Name Application volume with holder addresses in the regions described below: 



1.1.9.1
Africa; 


1.1.9.2
Asia Pacific; 


1.1.9.3
Europe; 


1.1.9.4
Latin America/Caribbean; and 


1.1.9.5
North America. 




1.1.10
Total number of ICANN-Accredited Registrars qualified to submit Domain Name Applications on each day of the Phase 1 Period. 


1.1.11
Total number of Domain Names Applications during the Phase 1 Period under the sponsorship of each ICANN-Accredited Registrar. 


1.1.12
Total number of registrants requesting the Secure Domain Name Registration Service. 














1.1.13
Total number of registrants who requested the Secure Domain Name Registration Service and obtained their requested domain name during the Phase 2-Landrush. 


1.1.14
Total number of ICANN-Accredited Registrars permitted to sell the Secure Domain Name Registration Service. 


1.1.15
Total number of Secure Domain Name Registration Service registrations under sponsorship of each ICANN-Accredited Registrar. 


1.1.16
A summary of the complaints received from Registrars during the Phase 1 Period. 


1.1.17
A description of significant technical difficulties encountered in operating during the Phase 1 Period. 




1.2 Phase 2 (Landrush) Period Effectiveness—within 120 days after the end of the Phase 2-Landrush Period (as set forth in
Appendix J), Registry Operator shall provide the following information and reports to ICANN. 



1.2.1
A summary of the complaints received from Registrars during the Phase 2-Landrush Period. 


1.2.2
A description of significant technical difficulties in operating during the Phase 2-Landrush Period. 


1.2.3
A tabulation, by Registrar, of the terms in years of Phase 2-Landrush registration requests submitted to the random selection.biz domain name processing system. 



1.2.4
A tabulation, by registrar, of the terms in years of Phase 2-Landrush registration requests successfully filled by the random selection.biz domain name processing system. 




1.3 Dispute Resolution Mechanism—within 120 days after the last day an initial claimant may make a Start-Up Dispute
Resolution Policy ("SUDRP") challenge, Registry Operator shall provide the following information and reports to ICANN. 



1.3.1
A statement of the total number of challenges submitted under the SUDRP. 


1.3.2
A tabulation of the number of names subject to multiple SUDRP challenges (i.e. × names were subject to exactly two challenges, y names were subject to exactly three
challenges, etc.). 


1.3.3
A statement of how many names sponsored by each Registrar were subject to at least one SUDRP challenge. 


1.3.4
A breakdown by country of the registration offered by the domain-name holder of the number of successful and unsuccessful SUDRP challenges. 


1.3.5
A statement, broken down by sponsoring registrar, of the number of names involved in challenges where the holder failed to submit any materials after receiving notification of the SUDRP
challenge. 


1.3.6
A statement, broken down by the region of the holder's address as described below, of the number of names subject to successful SUDRP challenges: 



1.3.6.1
Africa; 


1.3.6.2
Asia Pacific; 


1.3.6.3
Europe; 


1.3.6.4
Latin America/Caribbean; and 


1.3.6.5
North America. 

















1.3.7
A statement, broken down by the region of the successful challenger's address as described below, of the number of names subject to successful SUDRP challenges: 



1.3.7.1
Africa; 


1.3.7.2
Asia Pacific; 


1.3.7.3
Europe; 


1.3.7.4
Latin America/Caribbean; and 


1.3.7.5
North America. 




1.3.8
A statement of the number of successful SUDRP challengers that did not register the challenged name, broken down by priority of the challenger (i.e. × first-priority
challengers chose not to register the challenged name; y second priority challengers were offered the opportunity to, but did not, register the challenged name, etc.). 


1.3.9
A summary of the complaints received from Registrars regarding the SUDRP. 


1.3.10
A description of significant technical difficulties encountered in connection with the SUDRP. 


1.3.11
Registry Operator's evaluation of the overall effectiveness of the SUDRP. 




1.4 Registry Live Effectiveness—within 180 days after the start of the Registry Live Period, Registry Operator shall provide the
following information and reports to ICANN. 



1.4.1
Total number of domain names granted during Registry Live broken down by ICANN-Accredited Registrar. 


1.4.2
Total number of domain names granted during Registry Live broken down by domain name holder having addresses in the regions described below: 


1.4.2.1
Africa; 



1.4.2.2
Asia Pacific; 


1.4.2.3
Europe; 


1.4.2.4
Latin America/Caribbean; and 


1.4.2.5
North America. 




1.4.3
Total number of domain names "on hold" at the Commencement-of-Service Date. 


1.4.4
Total initial domain name registration volume by day during Registry Live. 


1.4.5
Total initial domain name registration volume by week. 


1.4.6
Total initial domain name registration volume during Registry Live with holder addresses in the regions described below: 



1.4.6.1
Africa; 


1.4.6.2
Asia Pacific; 


1.4.6.3
Europe; 


1.4.6.4
Latin America/Caribbean; and 


1.4.6.5
North America. 




1.4.7
Total number of ICANN-Accredited Registrars qualified to submit domain name registrations on day one of the Registry Live Period. 


1.4.8
Total number of domain names registered during each month of the Registry live Period under the sponsorship of each ICANN-Accredited Registrar. 














1.4.9
A summary of the complaints received from Registrars during the Registry Live Period. 


1.4.10
A description of significant technical difficulties encountered in operating during the Registry Live Period. 




1.5 Effectiveness of Batch Processing, Random Selections System—within 90 days after the end of the Phase 2-Landrush
Period, Registry Operator shall provide the following information and reports to ICANN. 



1.5.1
Provide a written report detailing the effectiveness of the batch processing, random selection.biz domain name processing system during the Land Rush Period. Include such items as lessons
learned during the process and methods of improvement. 


1.5.2
For each round of the random selection.biz domain name processing system, as described in Appendix J: 



1.5.2.1
the date on which the merged "qualified".biz domain name list was created; 


1.5.2.2
processing time required to process the "random" domain name list and register the.biz domain name selected during Phase 2-Landrush in the Registry Database; 


1.5.2.3
the names of the Registrars from which domain name applications were received; 


1.5.2.4
the number of domain name requests received from each registrar; 



1.5.2.5
the number of domain names granted for each Registrar during Phase 2-Landrush; 


1.5.2.6
the number of domain name requests submitted by each Registrar that were not granted because the domain name was "unavailable or "reserved"; 


1.5.2.7
a tabulation showing the number of names subject to multiple requests (i.e. × names were subject to exactly two requests, y names were subject to exactly three
requests, etc.); and 


1.5.2.8
a tabulation showing the number of names subject to multiple requests in each submitted by each Registrar queue (i.e. × names were subject to exactly two requests, y
names were subject to exactly three requests, etc.). 





1.6 Miscellaneous.  



1.6.1
Within 30 days after the anniversary of the Commencement-of-Service Date, provide a tabulation of the number of Phase I Period domain name registrations
transferred to another holder during each month after the Commencement-of-Service Date. 


1.6.2
Within 30 days after the anniversary of the Commencement-of-Service Date, provide a tabulation of the number of Landrush domain name registrations transferred to
another holder during each month after the Commencement-of-Service Date. 


1.6.3
Within 30 days of receipt by Registry Operator of any lawsuit concerning the start-up activities in.biz, please identify the lawsuit and provide a copy of the complaint or
describe its allegations. 


1.6.4
Within 30 days after the anniversary of the Commencement-of-Service Date, provided a tabulation of the number of Registry Live domain name registrations
transferred to another holder during each month after the Commencement-of-Service Date. 





2. Concept: Procedures for Minimizing Abusive Domain-Name Registration Practices



No
later than 180 days after the Commencement-of-Service Date, Registry Operator shall provide to ICANN a Proof-of-Concept Report on Minimizing
Abusive Registration Practices, with the following information. 



2.1
Provide a written report detailing the effectiveness of the IPN Service in limiting abusive registration practices. Include such items as lessons learned and methods of improvement. 









2.2
Provide a written report detailing the effectiveness of the Domain Name Application Fee in limiting abusive registration practices. Include such items as lessons learned and methods of
improvement. 


2.3
Provide a written report detailing the effectiveness of the Secure Domain Name Registration Service in limiting abusive registration practices. Include such items as lessons learned and methods of
improvement. 




3. Concept: Introducing a TLD Restricted to Commercial Use as a Means of Effective Competition with a Dominant, Well-Financed TLD Such
as.com


No
later than one month after each anniversary date after the Commencement-of-Service Date, Registry Operator shall provide to ICANN an Annual
Proof-of-Concept Report on Effectiveness of Competition, with the following information: 



3.1 Marketing Efforts.



3.1.1
Total Registry Operator expenditures for marketing the.biz TLD, broken down by calendar quarter ending in the year to which the report relates and by the region where the expenditure was made: 



3.1.1.1
Africa; 


3.1.1.2
Asia Pacific; 


3.1.1.3
Europe; 


3.1.1.4
Latin America/Caribbean; and 


3.1.1.5
North America. 




3.1.2
Types of marketing media utilized by Registry Operator, broken down by calendar quarter ending in the year to which the report relates. 


3.1.3
Total expenditure for each marketing media provided above, broken down by calendar quarter ending in the year to which the report relates. 


3.1.4
(For the first annual report:) Provide a breakdown of marketing expenditures during the Phase 1 Period for the following global regions: 



3.1.4.1
Africa; 


3.1.4.2
Asia Pacific; 


3.1.4.3
Europe; 


3.1.4.4
Latin America/Caribbean; and 


3.1.4.5
North America. 




3.1.5
(For the first annual report:) Provide a breakdown of marketing expenditures during the Phase 2-Landrush Period for the following global regions: 



3.1.5.1
Africa; 



3.1.5.2
Asia Pacific; 


3.1.5.3
Europe; 


3.1.5.4
Latin America/Caribbean; and 


3.1.5.5
North America. 




3.1.6
Total annual marketing expenditure. 




3.2 Quarterly Report—Total number of ICANN-Accredited Registrars registering domain names in the TLD 











3.2.1
Total number of ICANN-Accredited Registrars authorized to register domain names in the.biz TLD broken down on a quarterly basis (include a geographic breakdown by global region). 


3.2.2
Total number of new ICANN-Accredited Registrars authorized to register domain names in the.biz TLD broken down on a quarterly basis (include a geographic breakdown by global region). 



3.2.3
Total number of ICANN-Accredited Registrars authorized to register domain names in the.biz TLD that were terminated broken down on a quarterly basis (include a geographic breakdown by global
region). 


3.2.4
Describe the reason for each termination listed above. 


3.2.5
Total number of registrations under management by each ICANN-Accredited Registrar, broken down on a quarterly basis. 




3.3
Number of initial registrations during each calendar month ending in the year to which the report relates. 


3.4
Number of renewals during each calendar month ending in the year to which the report relates. 



3.5
Number of registration transfers during each calendar month ending in the year to which the report relates. 


3.6
Provide the Geographic breakdown of registrants by global region: 



3.6.1
Africa; 


3.6.2
Asia Pacific; 


3.6.3
Europe; 


3.6.4
Latin America/Caribbean; and 


3.6.5
North America. 




3.7
Total domain name registrations expiring and not renewed during each calendar month ending in the year to which the report relates. 



3.8
Average term of new registrations during each calendar month ending in the year to which the report relates. 


3.9
Average term of renewals during each calendar month ending in the year to which the report relates. 




4. Concept: Adding a TLD Restricted to Commercial Use Will Result in an Expansion and Globalization of the Effective Namespace, Rather than Wasteful Duplication of
Registrations


Landrush Report—within 90 days after the end of the Phase 2—Landrush Period, Registry Operator shall provide to ICANN an
"Expansion of the DNS" report with the following elements: 



4.1
Total number of duplicate registrations (i.e. same name) with each of the following TLDs during Landrush Period: 



4.1.1
..com; 


4.1.2
..net; 


4.1.3
..org; 


4.1.4
..de; and 


4.1.5
..co.uk. 















4.2
An estimate of the percentage of such duplicate registrations registered to the same holder. (e.g., example.biz and example.com registered to the same holder). 


4.3
The estimated percentage of such duplicate registrations sharing at least one nameserver with respect to each of the five domains listed in 3.1.1 to 3.1.5. 


4.4
Total number of domain names under management during the Phase 2—Landrush Period with holder addresses in the regions described below: 



4.4.1
Africa; 


4.4.2
Asia Pacific; 


4.4.3
Europe; 


4.4.4
Latin America/Caribbean; and 


4.4.5
North America. 




4.5
Number of ICANN-Accredited Registrars, broken down by global region, registering domain names during the Phase 2—Landrush Period: 



4.5.1
Africa; 


4.5.2
Asia Pacific; 


4.5.3
Europe; 


4.5.4
Latin America/Caribbean; and 


4.5.5
North America. 





Annual Reports—No later than one month after each anniversary date after the Commencement-of-Service Date, Registry
Operator shall provide to ICANN an "Expansion of the DNS" report with the following elements: 



4.6
Total number of duplicate registrations (i.e. same name) with each of the following TLDs at the end of each calendar month ending in the year to which the report relates. 



4.6.1
..com; 



4.6.2
..net; 


4.6.3
..org; 


4.6.4
..de; and 


4.6.5
..co.uk. 




4.7
An estimate of the percentage of such duplicate registrations registered to the same holder. 


4.8
The percentage of such duplicate registrations sharing at least one nameserver with respect to each of the five domains listed in 3.6.1 to 3.6.5. 


4.9
Total number of domain names under management Post Landrush Period on a quarterly basis with holder addresses in the regions described below: 



4.9.1
Africa; 


4.9.2
Asia Pacific; 


4.9.3
Europe; 


4.9.4
Latin America/Caribbean; and 


4.9.5
North America. 















4.10
Number of ICANN-Accredited Registrars, broken down by global region, registering domain names during the Post Landrush Period: 



4.10.1
Africa; 


4.10.2
Asia Pacific; 


4.10.3
Europe; 


4.10.4
Latin America/Caribbean; and 


4.10.5
North America. 





5. Concept: Registry Services Can Effectively Be Provided by a Jointly Managed Registry Operator



5.1
Ability to Effectively Operate the Registry. Annual Report—No later than one month after each anniversary date after the
Commencement-of-Service Date, Registry Operator shall provide to ICANN a Joint Management Registry Report with the following elements: 



5.1.1
Total number of registrations under management during each calendar month ending in the year to which the report relates. 


5.1.2
Total number of ICANN-Accredited Registrars registering domain-names in the Registry TLD during each calendar month ending in the year to which the report relates. 


5.1.3
Total amount of SLE Credits to ICANN-Accredited Registrars during each calendar month ending in the year to which the report relates. 



5.1.4
Total SLE Credits awarded to each ICANN-Accredited during each calendar month ending in the year to which the report relates. 


5.1.5
Provide a breakdown of the SLE Credits awarded to ICANN-Accredited Registrars for the following Credit Classes: 



5.1.5.1
C1a Credit Class; 


5.1.5.2
C1b Credit Class; 


5.1.5.3
C2 Credit Class; 


5.1.5.4
C3 Credit Class; and 


5.1.5.5
C4 Credit Class. 














5.2
Ability to Attract and Maintain Registrars—within 180 days after the Commencement-of-Service Date,
Registry Operator shall provide the following information and reports to ICANN. 



5.2.1
Total number of ICANN-Accredited Registrars who participated in the Registry start-up-phase technical acceptance test. 



5.2.2
Total number of ICANN-Accredited Registrars who failed the start-up-phase technical acceptance test. 


5.2.3
Total number of ICANN-Accredited Registrars re-tested in the start-up-phase technical acceptance test. 


5.2.4
A summary of complaints received from ICANN-Accredited Registrars regarding the start-up-phase technical acceptance test. 


5.2.5
Provide a written report detailing the effectiveness of the start-up-phase technical acceptance test. Include such items as lessons learned and methods of improvement. 


5.2.6
Total number of ICANN-Accredited Registrars who participated in the XRP Acceptance Test. 


5.2.7
Total number of ICANN-Accredited Registrars who failed the XRP Acceptance Test. 


5.2.8
Total number of ICANN-Accredited Registrars re-tested for the XRP Acceptance Test. 


5.2.9
A summary of complaints received from Registrars regarding the XRP Acceptance Test. 


5.2.10
Provide a written report detailing the effectiveness of the XRP acceptance test. Include such items as lessons learned and methods of improvement. 





6. Concept: Mechanisms for Ensuring that all Registrars Are Treated Fairly


Annual Reports—No later than one month after each anniversary date after the Commencement-of-Service Date, Registry
Operator shall provide to ICANN a Fair-Treatment Report with the following elements: 



6.1
A description of every known violation or alleged violation of the Code of Conduct during each calendar month ending in the year to which the report relates. 


6.2
Total number of complaints received by Registry Operator from registrars regarding services provided by Registry Operator. 



6.2.1
Identify and categorize the types of complaints received from registrars. 


6.2.2
List corrective actions, if any, in response to the categorized complaints. 




6.3
Total number of ICANN-Accredited Registrars restricted from further registrations for non-payment of registration fees. 




7. Concept: Use of Centralized Registry-Level Whois to Enhance Transparency and Accountability in Domain-Name Registrations



Annual Reports—No later than three months after each anniversary date after the Commencement-of-Service Date,
Registry Operator shall provide to ICANN a Whois Report with the following elements: 



7.1
Total number of complaints received from registrants regarding Whois information during each calendar month ending in the year to which the report relates. 


7.2
Total number of complaints received from ICANN-Accredited Registrars regarding Whois service during each calendar month ending in the year to which the report relates. 



7.3
Total number of complaints received from third parties regarding Whois information during each calendar month ending in the year to which the report relates. 












7.4
(For the first annual report:) Total initial query volume during the Phase 2—Landrush Period. 


7.5
Total number of queries during each calendar month ending in the year to which the report relates. 



7.6
Enhanced Whois Services: 



7.6.1
Total number of subscribers (include a geographic breakdown by country and global region). 


7.6.2
Total number of queries during each calendar month ending in the year to which the report relates. 


7.6.3
Total number of queries broken down by subscriber during each calendar month ending in the year to which the report relates. 




7.7
Privacy Complaints: 



7.7.1
Total number of complaints relating to privacy issues during each calendar month ending in the year to which the report relates. 



7.7.2
Identify and categorize types of privacy complaints. 





8. Concept: Capital Requirements in Operating a TLD Restricted to Commercial Use


Annual Reports—No later than one month after each anniversary date after the Commencement-of-Service Date, Registry
Operator shall provide to ICANN a Funding Requirements Report with the following elements: 



8.1
Total expenditures during the Phase 1. 



8.2
Total expenditures during Phase 2 Land Rush Period. 


8.3
Total expenditures during Phase 3 Registry Live on a quarterly basis. 


8.4
Breakdown of expenditures for the following categories: 



8.4.1
Marketing; 


8.4.2
Software; and 


8.4.3
Hardware. 




8.5
Provide a list of the employee positions hired during the following periods: 



8.5.1
Pre-Phase 1 Period; 


8.5.2
Phase 1 Period; 


8.5.3
Phase 2 Landrush Period; and 


8.5.4
Phase 3 Registry Live on a quarterly basis. 





9. Concept: Registration Restrictions Can Be Implemented by a Registry Operator in a Cost Effective and Timely Manner



9.1
SUDRP/UDRP Proceedings—within 165 days after the Commencement-of-Service Date, Registry Operator shall
provide an initial report with the following information and reports to ICANN. Thereafter, no later than one year after the anniversary date of the initial report, Registry Operator shall provide the
following information and reports to ICANN. 



9.1.1
A statement of the total number of Start-Up Dispute Resolution Policy ("SUDRP") and/or UDRP challenges filed. 



9.1.2
A tabulation of the number of names subject to multiple SUDRP and/or UDRP challenges (i.e., × names were subject to exactly two challenges, y names were subject to
exactly three challenges, etc.). 














9.1.3
A statement of how many names sponsored by each Registrar were subject to at least one SUDRP and/or UDRP challenge. 


9.1.4
A breakdown by country of the registration offered by the domain-name holder of the number of successful and unsuccessful SUDRP and/or UDRP challenges. 



9.1.5
A statement, broken down by sponsoring Registrar, of the number of names involved in SUDRP and/or UDRP challenges where the holder failed to submit any materials after notification of challenge. 


9.1.6
A statement, broken down by the region of the holder's address as described below, of the number of names subject to successful SUDRP and/or UDRP challenges: 



9.1.6.1
Africa; 


9.1.6.2
Asia Pacific; 


9.1.6.3
Europe; 


9.1.6.4
Latin America/Caribbean; and 


9.1.6.5
North America. 




9.1.7
A statement, broken down by the region of the successful challenger's address as described below, of the number of names subject to successful SUDRP and/or UDRP challenges: 



9.1.7.1
Africa; 


9.1.7.2
Asia Pacific; 


9.1.7.3
Europe; 


9.1.7.4
Latin America/Caribbean; and 


9.1.7.5
North America. 




9.1.8
A statement of the number of successful SUDRP and/or UDRP challengers that did not register the challenged name, broken down by priority of the challenger
(i.e. × first-priority challengers chose not to register the challenged name; y second priority challengers were offered the opportunity to, but did not, register the
challenged name, etc.). 


9.1.9
A summary of the complaints received from Registrars regarding the SUDRP. 




9.2
Registrations Restrictions—within 165 days after the Commencement-of-Service Date, Registry Operator
shall provide the following information and reports to ICANN. Thereafter, no later than one year after the anniversary date of the initial report, Registry Operator shall provide the following
information and reports to ICANN. 



9.2.1
A statement of the total number of Restriction Dispute Resolution Policy ("RDRP") Challenges filed. 


9.2.2
A tabulation of the number of names subject to multiple RDRP challenges (i.e., × names were subject to exactly two challenges, y names were subject to exactly three
challenges, etc.). 


9.2.3
A statement of how many names sponsored by each Registrar were subject to at least one RDRP challenge. 


9.2.4
A breakdown by country of the registration offered by the domain-name holder of the number of successful and unsuccessful RDRP challenges. 


9.2.5
A statement, broken down by sponsoring Registrar, of the number of names involved in RDRP challenges where the holder failed to submit any materials after notification of challenge. 














9.2.6
A statement, broken down by the region of the holder's address as described below, of the number of names subject to successful RDRP challenges: 



9.2.6.1
Africa; 


9.2.6.2
Asia Pacific; 


9.2.6.3
Europe; 


9.2.6.4
Latin America/Caribbean; and 


9.2.6.5
North America. 




9.2.7
A statement, broken down by the region of the successful challenger's address as described below, of the number of names subject to successful RDRP challenges: 



9.2.7.1
Africa; 


9.2.7.2
Asia Pacific; 


9.2.7.3
Europe; 


9.2.7.4
Latin America/Caribbean; and 


9.2.7.5
North America. 




9.2.8
A statement of the number of successful RDRP challengers that did not register the challenged name, broken down by priority of the challenger (i.e. × first-priority
challengers chose not to register the challenged name; y second priority challengers were offered the opportunity to, but did not, register the challenged name, etc.). 


9.2.9
A statement, broken down by sponsoring Registrar, of the number of names forfeited on the basis that the name was registered solely for the purpose of (1) selling, trading or leasing the
domain name for compensation, or (2) the unsolicited offering to sell, trade or lease the domain name for compensation. 


9.2.10
A summary of the complaints received from Registrars regarding the RDRP. 


9.2.11
A description of significant technical difficulties encountered in connection with the RDRP resolution. 



9.2.12
Registry Operator's evaluation of the overall effectiveness of the RDRP adopted for the Registry TLD. 


9.2.13
Registry Operator's evaluation of the overall effectiveness of each dispute resolution policy adopted by the Registry TLD described below: 



9.2.13.1
SUDRP; 


9.2.13.2
RDRP; and 


9.2.13.3
UDRP. 






10. Commercially Reasonable Efforts and Review



Many
of the reports to be provided by Registry Operator require access to data to which Registry Operator may not be privy or which may not be reasonably available to Registry Operator. Recognizing
the importance of the proof of concept: 



10.1
Registry Operator shall use commercially reasonable efforts to obtain all necessary data and complete the required reports as set forth in this Appendix; and 


10.2
In the event Registry Operator is unable through commercially reasonable efforts to obtain the requisite data to complete the required reports or the compilation of a specific report proves
unreasonably costly, ICANN shall, to the fullest extent possible, assist Registry Operator and/or the Registry community in obtaining or coordinating efforts to obtain the data, or alternative data 












(including
as appropriate data of reduced scope) useful in connection with the proof of concept, in a less costly way. 




11. Confidentiality


The
reports provided by Registry Operator as described in this Appendix shall be subject to confidentiality restrictions according to categories described in the following table: 



	Category


	 	Restrictions



	1	 	May be publicly disclosed by ICANN 18 months after the information is reported to ICANN.
	

2	
 	

May be publicly disclosed by ICANN 6 months after the information is reported to ICANN.
	

3	
 	

May be publicly disclosed by ICANN 90 days after the last date to which the information relates.
	

4	
 	

No confidentiality restrictions.






ICANN
will use commercially reasonable efforts to prevent public disclosure prior to the times described in the table above. 


Registry
Operator shall clearly label all reports and information provided pursuant to this Appendix with the appropriate confidentiality category prior to submission to ICANN. 


The
following table sets forth, for each item in each report, the confidentiality category (CC) that applies to it: 



	Report

ID
 
	 	CC
	 	Report

ID
	 	CC
	 	Report

ID
	 	CC
	 	Report

ID
	 	CC

	1.1.1	 	2	 	1.4.1	 	4	 	3.8	 	3	 	7.5	 	3
	1.1.2.1-1.1.2.5	 	2	 	1.4.2.1-1.4.2.5	 	4	 	3.9	 	3	 	7.6.1	 	2
	1.1.3	 	2	 	1.4.3	 	3	 	4.1.1-4.1.5	 	4	 	7.6.2	 	2
	1.1.4	 	4	 	1.4.4	 	4	 	4.2	 	4	 	7.6.3	 	2
	1.1.5	 	4	 	1.4.5	 	4	 	4.3	 	4	 	7.7.1	 	2
	1.1.6	 	4	 	1.4.6.1-1.4.6.5	 	4	 	4.4.1-4.4.5	 	4	 	7.7.2	 	2
	1.1.7	 	4	 	1.4.7	 	4	 	4.5.1-4.5.5	 	4	 	8.1	 	3
	1.1.8	 	4	 	1.4.8	 	2	 	4.6.1-4.6.5	 	4	 	8.2	 	3
	1.1.9	 	4	 	1.4.9	 	2	 	4.7	 	4	 	8.3	 	2
	1.1.10.1-1.1.10.5	 	4	 	1.4.10	 	2	 	4.8	 	4	 	8.4.1-8.4.5	 	2
	1.1.11	 	4	 	1.5.1	 	4	 	4.9.1-4.9.5	 	4	 	8.5.1-8.5.5	 	2
	1.1.12	 	2	 	1.5.2.1-1.5.2.4	 	3	 	4.10.1-4.10.5	 	4	 	9.1.1	 	4
	1.1.13	 	4	 	1.5.2.5-1.5.2.9	 	2	 	5.1.1	 	2	 	9.1.2	 	4
	1.1.14	 	3	 	1.6.1	 	3	 	5.1.2	 	2	 	9.1.3	 	2
	1.1.15	 	4	 	1.6.2	 	4	 	5.1.3	 	2	 	9.1.4	 	4
	1.1.16	 	2	 	2.1	 	3	 	5.1.4	 	2	 	9.1.5	 	4
	1.1.17	 	2	 	2.2	 	3	 	5.2.1	 	3	 	9.1.6.1-9.1.6.5	 	4
	1.1.18	 	2	 	2.3	 	3	 	5.2.2	 	3	 	9.1.7.1-9.1.7.5	 	4
	1.2.1	 	2	 	3.1.1.1-3.1.1.5	 	1	 	5.2.3	 	3	 	9.1.8	 	4
	1.2.2	 	2	 	3.1.2	 	1	 	5.2.4	 	3	 	9.1.9	 	4
	1.2.3	 	4	 	3.1.3	 	1	 	5.2.5	 	3	 	9.2.1	 	4
	1.2.4	 	3	 	3.1.4.1-3.1.4.5	 	1	 	5.2.6	 	3	 	9.2.2	 	4
	1.2.5	 	3	 	3.1.5.1-3.1.5.5	 	1	 	5.2.7	 	3	 	9.2.3	 	2
	1.3.1	 	4	 	3.1.6	 	2	 	5.2.8	 	3	 	9.2.4	 	4
	1.3.2	 	4	 	3.2.1	 	4	 	5.2.9	 	3	 	9.2.5	 	4
	1.3.3	 	2	 	3.2.2	 	4	 	5.2.10	 	3	 	9.2.6	 	4
	 	 	 	 	 	 	 	 	 	 	 	 	 	 	 









	1.3.4	 	4	 	3.2.3	 	4	 	6.1	 	2	 	9.2.7	 	4
	1.3.5	 	4	 	3.2.4	 	2	 	6.2.1	 	2	 	9.2.8	 	4
	1.3.6.1-1.3.6.5	 	4	 	3.2.5	 	2	 	6.2.2	 	2	 	9.2.9	 	3
	1.3.7.1-1.3.7.5	 	4	 	3.3	 	3	 	6.3	 	4	 	9.2.10	 	2
	1.3.8	 	4	 	3.4	 	3	 	7.1	 	2	 	9.2.11	 	2
	1.3.9	 	2	 	3.5	 	3	 	7.2	 	2	 	9.2.12	 	3
	1.3.10	 	2	 	3.6.1-3.6.5	 	3	 	7.3	 	2	 	9.2.13.1-9.2.13.5	 	3
	1.3.11	 	4	 	3.7	 	3	 	7.4	 	3	 	 	 	 










APPENDIX V  


Consensus Policies  


The
Registry Agreement requires Registry Operators to abide by various specifically stated procedures and also Consensus Policies. Policies adopted before the date of the Registry Agreement are deemed
to be Consensus Policies. Policies adopted after the date of the Registry Agreement are applicable to Registry Operator if those policies meet certain requirements regarding the demonstration of
consensus. 


The
following policies are specifically identified as having been adopted by the ICANN Board of Directors as of the dates shown below. As such, they are deemed Consensus Policies: 



	•
	Uniform
Domain Name Dispute Resolution Policy—adopted August 26, 1999; form of implementation documents approved October 24, 1999. 














APPENDIX W  


 
  Additional Covenants of NeuLevel  
  


1.     Ownership Structure  


As
of April 23, 2001, Registry Operator is a Delaware corporation. The ownership of the LLC is divided between NeuStar, Inc., a Delaware corporation (55%) and Melbourne IT Ltd.,
an Australian company (45%). The corporate structure and ownership levels of Registry Operator are subject to change in the normal course of Registry Operator's business. Any change of the ownership
structure shall be in conformance with Section 3 below. 


2.     Insurance  


Registry
Operator, or parent of Registry Operator on behalf of Registry Operator, shall acquire, prior to the Effective Date, at least US $10,000,000 in comprehensive general liability insurance from
a reputable insurance provider with an A.M. Best rating of "A" or better and shall maintain insurance meeting these requirements throughout the Term of this Agreement. 


3.     Limitation on Merger, Consolidation or Reorganization  


During
the Term of this Agreement, Registry Operator shall not: (1) merge, consolidate or otherwise reorganize into or with a Registry Operator for a TLD which has more than 10,000,000
Registered Names under management, or any of its affiliates; or (2) sell or otherwise transfer all of its assets or stock to a Registry Operator for a TLD which has more than 10,000,000
Registered Names under management, or any of its affiliates. Registry Operator may merge, consolidate or otherwise reorganize into or with a (1) Registry Operator which has less than 10,000,000
Registered Names under management, or (2) a domain name registrar, only upon the express written consent of ICANN, which consent may not be unreasonably withheld or delayed. In considering
whether to give consent, ICANN may consider Concepts 3, 5 and 6 stated in Appendix U to this Agreement. 


4.     Funding Commitment  



Registry
Operator shall have available from either internal or external sources a minimum of US $34,000,000 in funding solely for Registry Operator's activities in establishing and operating the
Registry TLD through the date that is one year following the Commencement-of-Service Date. 


5.     Marketing Commitment  


Registry
Operator shall have available from either internal or external sources a minimum of US $15,000,000 for marketing Registry Services in the Registry TLD. Registry Operator shall use reasonable
commercial efforts to effectively market.biz Registry Services during the Term of the Agreement. 









APPENDIX X  


 
  Names Registered to Registry Operator  
  


The
domains to be reserved by NeuLevel are as follows: 


Part A: Names staying with the Registry in the event of reassignment  



	1.	advisory.biz
	2.	api.biz
	3.	autorenew.biz
	4.	billing.biz
	5.	bizdomain.biz
	6.	bizinfo.biz
	7.	bizlogin.biz
	8.	bizlock.biz
	9.	bizname.biz
	10.	bizness.biz
	11.	biznotification.biz
	12.	bizregistrar.biz
	13.	bizregistrars.biz
	14.	bizwebaddress.biz
	15.	bulkrenew.biz
	16.	business.biz
	17.	callcenter.biz
	18.	cctld.biz
	19.	claims.biz
	20.	customercare.biz
	21.	customersupport.biz
	22.	digitalcertificates.biz
	23.	directory.biz
	24.	dns.biz
	25.	domain.biz
	26.	domainname.biz
	27.	domainnames.biz
	28.	domains.biz
	29.	dotbizpromotions.biz
	30.	dotbiz.biz
	31.	dotbizaccounting.biz
	32.	dotbizbilling.biz
	33.	dotbizcallcenter.biz
	34.	dotbizcards.biz
	35.	dotbizcustomercare.biz
	36.	dotbizcustomersupport.biz
	37.	dotbizhelp.biz
	38.	dotbizhelpdesk.biz
	39.	dotbizinfo.biz
	40.	dotbizmail.biz
	41.	dotbizorder.biz
	42.	dotbizregistrar.biz
	43.	dotbizregistrarsupport.biz
	44.	dotbizsecurity.biz
	45.	dotbizsite.biz
	46.	dotbiztechnicalsupport.biz
	 	 











	47.	dotbiztroubledesk.biz
	48.	dotbizwebmaster.biz
	49.	ebiz.biz
	50.	ebizness.biz
	51.	findyour.biz
	52.	ftp.biz
	53.	getyour.biz
	54.	gopher.biz
	55.	gtld.biz
	56.	helpdesk.biz
	57.	hostmaster.biz
	58.	identify.biz
	59.	imap.biz
	60.	info.biz
	61.	ldap.biz
	62.	multilingual.biz
	63.	mybiz.biz
	64.	network.biz
	65.	nntp.biz
	66.	ntp.biz
	67.	order.biz
	68.	pop.biz
	69.	pop3.biz
	70.	questions.biz
	71.	questionsdotbiz.biz
	72.	register.biz
	73.	registry.biz
	74.	registeryour.biz
	75.	registeryourbiz.biz
	76.	registrant.biz
	77.	registrar.biz
	78.	registrarreports.biz
	79.	registrars.biz
	80.	registrarsupport.biz
	81.	registrylock.biz
	82.	renew.biz
	83.	renewnames.biz
	84.	root.biz
	85.	rootserver.biz
	86.	securedomain.biz
	87.	securename.biz
	88.	security.biz
	89.	servicemark.biz
	90.	services.biz
	91.	smtp.biz
	92.	snmp.biz
	93.	technicalsupport.biz
	94.	telnet.biz
	95.	thebizdomain.biz
	96.	thebizregistry.biz
	97.	theregistry.biz
	98.	troubledesk.biz
	99.	usergroup.biz
	100.	webmaster.biz
	 	 










	101.	whatbiz.biz
	102.	whois.biz
	103.	whoisbiz.biz
	104.	www.biz
	105.	xrp.biz
	106.	yourbiz.biz
	107.	zone.biz
	108.	zonefile.biz






Part B: Names staying with NeuLevel in the event of reassignment:  



	1.	melbourneit.biz
	2.	neulevel.biz
	3.	neu-level.biz
	4.	neulevelinc.biz
	5.	neulevelbiz.biz
	6.	neulevelllc.biz
	7.	neulevelregistrar.biz
	8.	neulevelregistrars.biz
	9.	neulevelregistry.biz
	10.	neulevel-inc.biz
	11.	neulevel-llc.biz
	12.	neulevel-biz.biz
	13.	neustar.biz
	14.	newlevel.biz
	15.	new-level.biz






If
the corporate identity of NeuLevel is changed, Appendix X will be amended to incorporate 2nd level domain variations on the new identity. 









APPENDIX Y  


 
  Sanctions Program  
  


This
document describes a program (the "Sanctions Program") under which violations of Subsections 3.5.1 through 3.5.5 and Appendix H (certification and separation requirements) and
Appendix I (Registry Operator's Code of Conduct) of the Registry Agreement may be addressed, at ICANN's option, by a separate and additional set of specific monetary sanctions. The Sanctions
Program is intended to allow ICANN flexibility to address violations of those Subsections and Appendices by means less extreme than proceedings to terminate the Registry Agreement. Registry Operator
agrees that the Sanctions Program is a non-exclusive and additional option for promoting compliance with Appendices H and I, and does not (except as stated below) limit or affect in any
way ICANN's ability to employ any other compliance measures or remedies available under the Registry Agreement. 


Registry
Operator agrees to participate in and comply with the Sanctions Program described in this document, provided that all other registry operators having registry agreements with ICANN for the
operation of unsponsored top-level domains (i.e., top-level domains, other than country-code and infrastructure domains, not having a sponsoring organization) are
obligated to participate in and comply with a sanctions program with substantially the same provisions. Failure by Registry Operator to participate in and comply with this sanctions program according
to the terms of this document constitutes a ground for ICANN to terminate the Registry Agreement. 


ICANN
and Registry Operator agree that, should the gTLD Constituency of the Domain Name Supporting Organization propose a substitute Appendix Y at any time prior to 1 May 2002, and ICANN
determines (following an appropriate process of public notice and comment) that substitution by that Appendix Y would serve the interests of the Internet community, the substitution will be
made. 


Investigation:  


ICANN
may elect to employ the Sanctions Program by sending Registry Operator a Confidential Notice of Investigation. Should ICANN choose to initiate an investigation with regard to any particular
activity or conduct, it must do so (a) within 90 days of the time that such activity or conduct is brought to the attention of the appropriate ICANN employee, and (b) in any event
no later than one year after the episode in question. The Confidential Notice of Investigation must be given in the manner described by the Registry Agreement, but shall not be publicly disclosed or
commented upon by ICANN unless Registry Operator has previously disclosed or confirmed its existence. The Confidential Notice of Investigation must include all of the following: 



1.
A statement that an investigation under the Sanctions Program is being initiated; 


2.
A statement of the possible violation of Subsections 3.5.1 through 3.5.5 and Appendices H and I being investigated and the reasons for believing such violation may have occurred; 


3.
A request to Registry Operator to provide to ICANN the information, including copies of any documentation, that ICANN believes is necessary for it to conduct the investigation, which information
must be reasonably related to the alleged violation; and 


4.
A specification of the ICANN investigator to whom a response should be made and the form in which the response should be transmitted. 




Registry
Operator shall have thirty days (or such larger period as ICANN may allow) after the date of the Confidential Notice of Investigation to send a response to the specified ICANN investigator.
The response, which shall be transmitted to the ICANN investigator in the manner stated in the Confidential Notice of Investigation, shall include: 



1.
An acknowledgement that an investigation has been initiated; 


2.
Any of the information requested in the Confidential Notice of Investigation that Registry Operator chooses to provide in accordance with clause 3 above; 












3.
If Registry Operator does not provide any or all of the information sought by the Confidential Notice of Investigation, the Registry Operator may state its reason(s) for not providing the
information, and ICANN is free to draw any reasonable inferences from the failure to provide such information; 


4.
Any request by the Registry Operator for confidential treatment of any of the information supplied, and the reason for such confidential treatment; and 


5.
A specification of the name and address of the person appointed by the Registry Operator to receive communications concerning the investigation ("Authorized Representative"). 




Any
such response shall be treated as confidential by ICANN unless disclosed or confirmed by Registry Operator. Within thirty days after transmission of the Registry Operator's response to the Notice
of Investigation, ICANN shall do one of the following: 



1.
If ICANN chooses to commence a sanctions proceeding based on the information it has received from the Registry Operator and otherwise, send the Authorized Representative a Statement of Evidence of
Violation meeting the requirements stated below; 


2.
If ICANN chooses not to proceed with the sanctions proceeding or a renewed investigation, send the Authorized Representative a notice that the Investigation is closed without further action; or 


3.
If ICANN chooses to seek additional information, send an additional Confidential Notice of Investigation to the Registry Operator meeting the requirements stated above. 




Statement of Evidence of Violation  


If
ICANN has reason to believe that a violation has occurred, it shall send the Authorized Representative a Statement of Evidence of Violation. The Statement of Evidence of Violation shall not be
publicly disclosed or commented on by ICANN unless Registry Operator has previously disclosed or confirmed its existence. The Statement of Evidence of Violation shall: 



1.
Specify the provision(s) of Subsections 3.5.1 through 3.5.5 and Appendices H and I of the Registry Agreement that ICANN has reason to believe Registry Operator has violated; 


2.
Provide a reasonably specific statement of the factual basis of the apparent violation; 


3.
Include all evidence on which ICANN has relied in concluding it has reason to believe that a violation has occurred; 


4.
Give the legal and factual basis for ICANN's conclusion that it has reason to believe that a violation has occurred, based on a discussion of the provisions of the Registry Agreement, the included
evidence, and any reasonable inferences drawn therefrom; and 


5.
State whether the alleged violation would, if established, be a major violation or a minor violation (see below) and why. 




Within
thirty days (or such longer period as ICANN may allow) after the Statement of Evidence of Violation is sent, the Registry Operator shall send a response to the ICANN investigator. 


Finding of Violation  


At
least thirty days after the Statement of Evidence of Violation is sent, and after considering any Registry Operator's response to the Statement of Evidence of Violation, ICANN may issue a Finding
of Violation. A Finding of Violation must be sent to the person appointed by the Registry Operator to receive communications concerning the investigation, and shall be posted on ICANN's website, with
appropriate redactions for material that ICANN and Registry Operator agree is confidential. If no Finding of Violation is sent within ninety days after the Registry Operator's response to the
Statement of Evidence of Violation, the sanctions proceeding shall be deemed closed without action. 









Any
Finding of Violation must: 



1.
Specify the provision(s) of Subsections 3.5.1 through 3.5.5 and Appendices H and I of the Registry Agreement that ICANN finds Registry Operator has violated; 


2.
Provide a specific detailed description of the evidence upon which ICANN relies in making the finding; 


3.
Specifically state any inferences that ICANN draws based on the evidence, upon Registry Operator's failure to provide information requested in the investigation, or otherwise; 


4.
Provide a specific detailed description of the nature of the violation found, and state whether the violation is found to be major or minor and why; and 



5.
State the amount of monetary sanctions assessed for each distinct violation found and reasons why the amount is deemed reasonable. 




In
finding a violation, ICANN may rely on information provided in response to a Confidential Notice of Investigation, on any evidence included in the Statement of Evidence of Violation, and on any
information provided in response to the Statement of Evidence. ICANN may draw inferences from any failure by the Registry Operator to provide information requested in the investigation, provided those
inferences are reasonable in the circumstances. Only one Finding of Violation may be issued with respect to any particular episode of activity or conduct. 


A
violation shall be classified as major or minor based on (a) the effects of the violation on competition and competitors, (b) the extent to which the violation appears to be
intentional by Registry Operator, considering the level of the employees or agents involved, prior notice to the Registry Operator of the circumstances, and other relevant factors, (c) the
extent to which the Registry Operator has established and effectively enforces policies that prohibit such violations (where the violation involves actions by employees or agents of Registry Operator
that have not been approved by senior management that has authority to change such policies), (d) prior findings of violations by the Registry Operator, and (e) any other relevant
circumstances. 


Sanctions
of up to US$10,000 for each violation may be assessed for each minor violation found and sanctions of up to US$100,000 for each violation may be assessed for each major violation found. The
amount of the financial sanction shall be proportionate to the violation and other relevant facts. 


In
the event ICANN makes a Finding of Violation and seeks to impose a monetary sanction, it may not thereafter issue a cure notice or seek any other remedy on the basis of the assertion that the same
specific episode on which the Finding of Violation is based constitutes a breach of this Agreement, but it may take into account the fact of the Finding and sanction in determining that another
violation should be dealt with in a particular way, including by deeming it a material breach of this Agreement. 



Review of Finding of Violation  


Findings
of Violation may be reviewed only by ICANN's Reconsideration Policy or by arbitration under Subsection 5.9 of the Registry Agreement. 


Registry
Operator may seek review of any aspect of any Finding of Violation by a request for reconsideration under ICANN's Reconsideration Policy (as it may be amended from time to time), provided
that the request is submitted within the time allowed by the policy after the sending of the Finding of Violation. The submission of a request for reconsideration shall not be a prerequisite for
seeking review of the Finding of Violation by arbitration. 


Registry
Operator may also appeal the assessment of sanctions in the Finding of Violation by giving ICANN written notice of its intention to arbitrate (the "Arbitration Notice") under Subsection 5.9
of the Registry Agreement. Registry Operator shall deliver the Arbitration Notice no later than fifteen days after the Finding of Violation is sent, except that if a timely request for reconsideration
is submitted under ICANN's Reconsideration Policy (as it may be amended from time to time) the deadline shall be fifteen calendar days after ICANN has provided contractual notice that the ICANN Board
has voted to act or not to act on the request. If Registry Operator does not deliver an Arbitration Notice within the time described above, or the Registry Operator causes the arbitration to be
discontinued before decision, the amount of the sanctions assessed in the Finding of Violation shall be deemed final. 



If
a timely Arbitration Notice is delivered, the arbitration shall determine, based on the record, whether the Finding of Violation is warranted and the amount of sanctions is reasonable. The amount
of sanctions as determined appropriate according to the arbitration decision shall be deemed final. 


Payment of Sanctions  


Registry
Operator shall pay to ICANN the final amount of sanctions within thirty days after the amount of sanctions is deemed final. Failure to do so shall be a ground for termination under Subsection
5.4.7 of the Registry Agreement. 









APPENDIX F  


 
  Amendment No. 1 to Appendix F  
  


This
Amendment to the Registry-Registrar Agreement ("Amendment") dated as of the            day
of                        , 2002 between NeuLevel, Inc., a Delaware corporation, with offices
located at 46000 Center Oak Plaza, Building X, Sterling, VA 20166 ("Registry Operator") and                        , with its
principal place of business at                        ("Registrar").
 


WHEREAS,
Registry Operator and Registrar entered into that certain Registry-Registrar Agreement ("Agreement") dated as
of                        , 2001 ("Effective Date") and the Exhibits and Schedules
thereto (the Agreement, together with such Exhibits and Schedules are collectively referred to as "Transaction Documents"), concerning the provision of domain name registration services for the.BIZ
top-level domain ("TLD"). 


WHEREAS,
Registry Operator and Registrar now desire to amend certain terms of the Transaction Documents to clarify and supplement the parties' agreement; 



WHEREAS,
Registry Operator wishes to offer new Registry Services on the terms and conditions as approved by the Internet Corporation for Assigned Names and Numbers ("ICANN"). 


NOW,
THEREFORE, in consideration of the mutual covenants contained herein and other good and valuable consideration, receipt of which is hereby acknowledged, the parties agree as follows: 



1.
Capitalized terms used in this Amendment and not otherwise defined shall have the same meaning set forth in the Transaction Documents. 


2.
Registry Services. Registry Operator shall provide Registrar no less than thirty (30) days written notice of any new Registry Service (as defined in the Agreement) that has been approved by
ICANN
according to the procedures set forth in the Registry Agreement by and between ICANN and Registry Operator dated May 11, 2001. Such notice shall include the provision of information on pricing,
starting date and any additional terms and conditions regarding the new Registry Service. Such notice shall not be a substitute for the notice required in Section 2.4 of the Agreement. 


3.
By signing this Amendment, Registrar does not have a binding obligation to provide any or all of the Registry Services offered by Registry Operator. The decision of whether to offer a Registry
Service to its end users shall be made solely by Registrar. 



4.
Except as specifically modified by this Amendment, the terms and conditions of the Transaction Documents shall remain in full force and effect. 




IN
WITNESS WHEREOF, the parties have caused this Amendment to be duly executed as of the date first written above. 



	REGISTRY OPERATOR

NEULEVEL, INC.	 	REGISTRAR
	

By:	

	
 	

By:	


	Name:	 	 	Name:	 
	Title:	 	 	Title:	 











 
 

Amendment No. 1 to Registry Agreement  
  


Amendment
No. 1 effective as of 3 June 2003 ("Amendment") to the Registry Agreement dated 11 May 2001 ("Agreement"), by and between the Internet Corporation for Assigned Names and
Numbers, a not-for-profit California corporation ("ICANN"), and NeuLevel Inc., a Delaware corporation ("Registry Operator"). Capitalized terms used but not defined
herein shall have that meaning ascribed to them in the Agreement. 


Whereas,
on 2 June 2003 the ICANN Board of Directors approved certain revisions to the Agreement to implement a redemption grace period service
in the.biz top level domain operated by Registry Operator, on such terms set forth and described to the ICANN Board of Directors at the 2 June 2003 meeting of the ICANN Board of Directors; 



Whereas,
at such 2 June 2003 meeting of the ICANN Board of Directors, the Board of Directors authorized certain revisions to Appendices C, G, O and T to the Agreement and the preparation of
this Amendment in accordance therewith; 


Now,
Therefore, in consideration of the mutual agreements contained herein and intending to be legally bound hereby, the parties hereto amend the Agreement as follows: 



1.  The
following pages of Appendix C to the Agreement are hereby replaced by the substitute pages attached hereto, as follows: Page 1 (table of contents) is replaced with the
attached page 1; pages 132-135 (C.10 Grace Period) are replaced with the attached pages 132-138 (C.10 Grace Period and  C.11 Additional Services).




2.  Appendix G
to the Agreement is hereby deleted in its entirety and replaced with a new Appendix G, in the form attached
hereto. 


3.  Appendix O
to the Agreement is hereby deleted in its entirety and replaced with a new Appendix O, in the form attached
hereto. 


4.  Appendix T
to the Agreement is hereby deleted in its entirety and replaced with a new Appendix T, in the form attached
hereto. 


5.  Except
as expressly amended hereby, the Agreement and the Appendices thereto shall remain and continue in full force and effect. This Amendment may be executed in any number of
counterparts, all of which together shall constitute one and the same instrument. 




The
parties have duly executed this Amendment as of the date first written above. 



	THE INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS	 	NEULEVEL INC.
	

By:	

	
 	

By:	


	Name:	Richard Tindal	 	Name:	Dr. Paul Twomey
	Title:	President and CEO	 	Title:	Vice President, Registry Services











 
 

Amendment No. 2 to Registry Agreement  
  


Amendment
No. 2 effective as of 30 September 2004 ("Amendment") to the Registry Agreement dated 11 May 2001 ("Agreement"), by and between the Internet Corporation for Assigned
Names and Numbers, a not-for-profit California corporation ("ICANN"), and NeuLevel Inc., a Delaware corporation ("Registry Operator"). Capitalized terms used but not
defined herein shall have that meaning ascribed to them in the Agreement. 


Whereas,
on 30 September 2004 the ICANN Board of Directors approved certain revisions to the Agreement. 



Now,
Therefore, in consideration of the mutual agreements contained herein and intending to be legally bound hereby, the parties hereto amend the Agreement as follows: 



1.  Appendix C,
Section 10, page 133-134, regarding the Auto-Renew Grace Period to the Agreement are hereby replaced by the substitute page attached
hereto 




The
parties have duly executed this Amendment as of the date first written above. 



	THE INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS	 	NEULEVEL INC.
	

By:	

	
 	

By:	


	Name:	Richard Tindal	 	Name:	Dr. Paul Twomey
	Title:	President and CEO	 	Title:	Vice President, Registry Services













QuickLinks


Registry Agreement


Internet Assigned Numbers Authority Format and Technical Requirements for Requests to Change TLD Nameservers in the Root Zone


Internet Assigned Numbers Authority Format, Content, and Technical Requirements for Requests to Change TLD Contact Information


Functional Specifications



Performance Specifications

PERFORMANCE SPECIFICATION MATRIX



Service Level Agreement

CREDIT LOOKUP MATRIX

Table C1a

Table C1b

Table C2

Table C3

Table C4a

Table C4b


Registry-Registrar Agreement



Exhibit A Registrar Tool Kits

Exhibit B Engineering and Customer Service Support


Exhibit C Registrar's Registration Agreement [To be supplied by Registrar]

Exhibit D Policy on Transfer of Sponsorship of Registrations Between Registrars

Exhibit E Registry Operator's Operational Standards, Policies, Procedures and Practices

Exhibit F Registration Fees

Exhibit G Performance Specifications


Exhibit H Service Level Agreement

CREDIT LOOKUP MATRIX

Table C1a

Table C1b

Table C2

Table C3

Table C4a

Table C4b


Exhibit I Registry/Registrar IP Claim Service Agreement

Explanatory Statement


SCHEDULE A IP CLAIM SERVICE TERMS OF USE


Registry Operator Maximum Price Schedule

FEE TABLE



NeuLevel Equal Access and Nondiscrimination Practice

NEULEVEL EQUIVALENT ACCESS CERTIFICATION

EXHIBIT A ACCESS TO DATA POLICY

NeuLevel Proprietary Information

NeuLevel Registry Sensitive Information

NeuLevel Proprietary Information

ATTACHMENT 1 Examples of Proprietary & Registry Sensitive Information

ATTACHMENT 2 NON-DISCLOSURE AGREEMENT Proprietary Information

EXHIBIT B NON-DISCLOSURE AGREEMENT

EXHIBIT C REGISTRY BUSINESS ORGANIZATIONAL CONFLICT OF INTEREST AVOIDANCE CERTIFICATION



REGISTRY CODE OF CONDUCT


Registry TLD Start-Up Plan



Schedule of Reserved Names



.biz Registration Restrictions



Start-Up Enforcement and Enforcement of the Restrictions Document


Exhibit 2 Rules for Start-up Dispute Resolution Policy (the "Rules")


Exhibit 3 Restrictions Dispute Resolution Policy

Exhibit 4 Supplemental Rules for Restrictions Dispute Resolution Policy


Zone File Access Agreement



Whois Specification—Public Whois


Whois Provider Data Specification


Whois Specification—ICANN



Data Escrow Schedule, Content, Format, and Procedure

Exhibit A—Schedule for Escrow Deposits

Exhibit B—Escrow Deposit Format Specification

Exhibit C—Escrow Transfer Process

Exhibit D—Escrow Verification Procedures


Registry Data Escrow Agreement

RECITALS

AGREEMENT



Registry Operator's Monthly Report


Evaluation of Concepts


Additional Covenants of NeuLevel



Names Registered to Registry Operator


Sanctions Program


Amendment No. 1 to Appendix F


Amendment No. 1 to Registry Agreement


Amendment No. 2 to Registry Agreement