Document:

exv10w4w1

 

Exhibit
10.4.1

 

 

 

 

 

      

NANP Administration Services

Scope of Work Change Proposal # 6

INC Issue 517 — Denying NXX Assignment to a Service

Provider that has opted into Pooling

July 7, 2006

      

			
	NeuStar, Inc.
	 	46000 Center Oak Plaza
	 
	 	Sterling, VA 20166

 

 

NANPA — Scope of Work Change #6 Proposal — INC Issue 517

 

Table of Contents

	 	 	 	 	 
	1 Introduction
	 	 	1	 
	1.1 Purpose and Scope
	 	 	1	 
	1.2 Modification of Guidelines
	 	 	1	 
	2 Proposed Industry Numbering Committee (INC) Scope of Work Change
	 	 	2	 
	3 NeuStar’s Proposed Solution
	 	 	3	 
	4 Assumptions and Risks
	 	 	4	 
	5 Cost Assumptions and Summary
	 	 	5	 
	6 Conclusion
	 	 	5	 

      

			
	© NeuStar, Inc. 2006
	 	iii

 

 

NANPA — Scope of Work Change #6 Proposal — INC Issue 517

 

1    Introduction

1.1    Purpose and Scope

In accordance with NeuStar’s contract1 and our constant effort to provide the
best support and value to both the Federal Communications Commission (FCC) and the
telecommunications industry, NeuStar, as the North American Numbering Plan Administrator (NANPA),
hereby submits this scope of work change to the FCC for approval. This scope of work change is in
compliance with NANPA’s Change Management protocol and most importantly per requirements as
outlined in NANP Administrator Solicitation SOL03000001, Section H.9, Item 5, which states the
following:

“If and when a change to the NANPA system is adopted by the NANC or the INC, the
contractor’s liaison shall ensure that the proposed change is forwarded to the Contracting
Officer and the Contracting Officer’s Technical Representative (COTR). No change shall be
binding until such modification is issued, nor shall the Government be liable for any
costs associated with a system change until such modification is issued.”

1.2 Modification of Guidelines

Pursuant to NeuStar’s contact, the NANPA shall participate in the development and
modification of guidelines and procedures, which may affect the performance of the NANPA functions.
These changes may be derived from regulatory directives and/or modifications to guidelines. In
addition, new guidelines may be developed as appropriate to comply with regulatory directives. The
NANPA shall adopt and implement any changes that are consistent with regulatory directives after
they are officially adopted, recognizing that some may constitute a change in the scope of work.

When the Industry Numbering Committee (INC) places any changes to its guidelines in initial
closure, the NANPA shall submit an assessment regarding the impact of scope of work, time and costs
to the INC, the North American Numbering Council (NANC) and the FCC within 30 days.2

This document provides detailed information pertaining to the INC’s requirement submitted on June
8, 2006. This change order document covers the required subject matters such as explaining the
industry’s requirements, proposed solution, costs and risk and assumptions.

 

			
	1	 	Contract Number CON03000016 and the NANPA Technical Requirements Document, March
2003.
	 
	2	 	NANPA Technical Requirements Document, March 2003, Section 2.10, Modification of
Guidelines.

      

			
	© NeuStar, Inc. 2006
	 	1

 

 

NANPA — Scope of Work Change #6 Proposal — INC Issue 517

 

2 Proposed Industry Numbering Committee (INC) Scope of Work Change

During the June 6-8, 2006 INC meeting, INC Issue 517 was accepted. It was resolved and went
to Initial Closure on June 8, 2006. This issue affects both the NANP Administration System (NAS)
and NANPA operations.

	•	 	Issue 517: Denying NXX assignment to SP that has OPTED into Pooling

The official INC issue statement is stated below and can also be found on the ATIS website:

	A)	 	ISSUE STATEMENT

NANPA has no way of knowing whether an SP has opted into pooling in a specific rate center,
so it is possible for that SP to request CO code resources in a rate center in which they have
already opted into participation in pooling.

	B)	 	FOLLOWING RESOLUTION FROM INC

The following changes were made to the COCAG and the TBPAG to resolve this issue:

A new section 3.10 was created:

3.10     If an SP has chosen to participate in thousands-block number pooling in a voluntary rate
center outside of the top 100 MSAs, the SP cannot withdraw from pooling in a voluntary rate
center once the SP has submitted a forecast, a donation, or has been assigned a
thousands-block. Once an SP chooses to participate in thousands-block number pooling in a
voluntary rate center, all numbering requests must be submitted directly to the PA.

4.1.1 The applicant must certify a need for NANP numbers, e.g., provision of wireline or
wireless service in the Public Switched Telephone Network.

In order to obtain CO codes, an applicant must submit or have submitted a North American Numbering
Plan Numbering Resource Utilization/Forecast (NRUF) Report (See NRUF Reporting Guidelines) to the
NANPA for the NPA(s) in which the CO code(s) is being requested.3 This requirement shall
not apply in instances where an NPA has been implemented since the last NRUF Report and the Service
Provider has submitted a NRUF Report for the NPA(s) previously serving the geographic areas
involved.

The applicant must submit an NXX request form certifying that a need exists for an NXX assignment
to a point of interconnection or a switching entity due to routing, billing, regulatory, or tariff
requirements. The NXX request form must provide an Operating Company Number

 

			
	3	 	FCC 00-104, § 52.15 (f) (4) (5).

      

			
	© NeuStar, Inc. 2006
	 	2

 

 

NANPA — Scope of Work Change #6 Proposal — INC Issue 517

 

(OCN), which uniquely identifies the applicant. The NANPA will not issue numbering resources
to a carrier without an OCN.4 The OCN cannot be shared with another service provider.

If NANPA determines from the report provided by the PA that an applicant is participating in
pooling in that rate center, NANPA will deny the application. Once an applicant chooses to
participate in thousands-block number pooling in a voluntary rate center, all numbering requests
must be submitted directly to the PA.

5.2 Receive and process applications (CO Code (NXX) Assignment Request Form Part 1) for CO
codes (NXX) within the geographic NPA(s) for which the CO Code Administrator is responsible.

For rate centers transitioning to pooling:

	•	 	The CO Code Administrator will only process NXX requests received at least 33
calendar days prior to the Pool Start Date.
	 
	•	 	Within the 33 calendar days prior to Pool Start Date, applications for codes/blocks will
not be accepted. However within this 33-day interval, the NANPA will
continue to process code applications for:

	 	•	 	CO codes awarded via lottery;
	 
	 	•	 	LRN requests;
	 
	 	•	 	full CO code request for a single customer;
	 
	 	•	 	CO code expedite requests;
	 
	 	•	 	petition/safety valve requests;
	 
	 	•	 	any requests from non-pooling capable carriers; and
	 
	 	•	 	PA requests to the NANPA.

After Pool Start Date, all pooling-capable carriers will apply to the PA for numbering resources.

Once an SP chooses to participate in thousands-block number pooling in a voluntary rate center,
all numbering requests must be submitted directly to the PA. NANPA
will not assign a CO code (NXX) to an SP for a voluntary pooled rate center in which that SP has either submitted a forecast
to the PA, submitted a donation to the PA, or has been assigned a thousands-block in that rate
center.

	3	 	NeuStar’s Proposed Solution

In order to implement INC Issue 517 for the central office code application
processing, NANPA proposes modifying the NANP Administration System. We believe that our proposed
solution set forth below will enable us to properly assign and deny resources in accordance with
the INC Issue 517 in the most efficient and effective manner possible.

 

			
	4	 	FCC 01-362, § 52.15 (g)(4).

      

			
	© NeuStar, Inc. 2006
	 	3

 

 

NANPA — Scope of Work Change #6 Proposal — INC Issue 517

 

Solution:

On a daily basis, the National Pooling Administrator (PA) will provide NANPA a file containing the
following information: NPA, rate 

center(s) where pooling is voluntary (also known as optional), and
the Operating Company Number(s) (OCN) of those service providers that are participating in pooling
in the identified voluntary rate center(s). This information will be loaded into NAS.

When the applicant begins the application process and enters the NPA, rate center, OCN and
application type (i.e., initial or growth code), NAS will perform a validation check using the
information provided by the PA to determine if the submitting service provider is participating in
pooling in the identified rate center. If the service provider is participating in pooling in the
identified rate center, NAS will respond with a validation error, informing the applicant that it
must submit its application for resources to the PA. NAS will not permit the applicant to proceed
any further in the application process. If the service provider is not participating in pooling
according to the PA information, then the application will be accepted and processed.

If the service provider initiates participation in a voluntary pooling rate center (e.g., submits a
thousand block forecast to the PA) on the same day it submits an application for an initial/growth
code directly into NAS, the application would normally be accepted by the system because NANPA only
receives a daily file from the PA. To account for this situation, NAS will perform a scan of all
pending initial/growth code applications (ones in which the pooling pass-thru box is not checked)
at the time the updated PA file is loaded into the system. Any pending application matching the
information in the PA file will be highlighted in the system and denied by the Code Administrator.

	4	 	Assumptions and Risks

Part of the NANPA’s assessment of this change order is to identify the associated
assumptions and consider the risks that can have an impact on our operations.

Assumptions:

	1.	 	NANPA assumes that the PA will provide the required information on a daily basis. If there
are any problems or issues that result in updated information not
being available, NAS will use the most recent PA information made available to NANPA.
	 
	2.	 	NANPA assumes when carriers call to request information relating to a service provider’s
participation in pooling, NANPA will only be required to explain this new central office
code assignment process. Questions concerning the PA information must be directed to the
PA.
	 
	3.	 	NANPA assumes the information provided to it by the PA is true and accurate.

If the process expands beyond these assumptions, the NANPA reserves the option of filing a revised
change order proposal to address the additional expansion.

      

			
	© NeuStar, Inc. 2006
	 	4

 

 

NANPA — Scope of Work Change #6 Proposal — INC Issue 517

 

Risks

This process relies on the PA for the data identifying the NPAs, voluntary pooling rate
centers and participating service providers (as identified via an OCN). The accuracy of NAS
validations on initial and growth code applications is only as reliable as the information provided
by the PA. In addition, daily update of this data is critical for NAS to properly accept/denied
central office code assignment requests.

Impact on Operations

The proposed solution impacts NAS by requiring the system to perform additional functions not
identified in the contract. Specifically, these functions include:

	1.	 	Accessing the daily PA file containing the NPAs, voluntary pooling rate centers and the
participating service providers (OCNs);
	 
	2.	 	Updating the NAS database with the PA information;
	 
	3.	 	Checking central office assignment applications against the PA information;
	 
	4.	 	Returning a validation error for those initial/growth central office code applications in
which
the NPA, rate center and OCN correspond with information provided by the PA;
	 
	5.	 	Scanning pending assignment requests to identify applications in which the NPA, rate center
and OCN matches the data provided by the PA; and,
	 
	6.	 	Addressing additional calls and emails that result from the implementation of the new
validation.

	5	 	Cost Assumptions and Summary

The proposed solution for implementation of the INC Issue 517 requires changes in NAS in
order for the system to identify and reject applications for initial/growth codes from service
providers that participate in pooling in voluntary pooling rate centers. NANPA has determined that
the cost associated with implementing this change in NAS is $16,096.96.

	6	 	Conclusion

NeuStar, as the NANPA, hereby seek the FCC’s approval for this Scope of Work Change
in order for proper communication protocols to be executed by which the industry can be made
aware that NANPA is accommodating this Scope of Work change order.

      

			
	© NeuStar, Inc. 2006
	 	5

 

 

      

      

NANP Administration Services

Scope of Work Change Proposal # 7

INC Issue 454 — Criteria Service Providers Must Meet to

Obtain Growth 900 NXX

September 25, 2006

      

			
	NeuStar, Inc.
	 	46000 Center Oak Plaza
	 
	 	Sterling, VA 20166

 

 

NANPA — Scope of Work Change #7 Proposal — INC Issue 454

 

Table of Contents

	 	 	 	 	 
	1 Introduction
	 	 	1	 
	1.1 Purpose and Scope
	 	 	1	 
	1.2 Modification of Guidelines
	 	 	1	 
	2 Proposed Industry Numbering Committee (INC) Scope of Work Change
	 	 	2	 
	3 NeuStar’s Proposed Solution
	 	 	2	 
	4 Assumptions and Risks
	 	 	3	 
	5 Cost Assumptions and Summary
	 	 	3	 
	6 Conclusion
	 	 	3	 

      

			
	© NeuStar, Inc. 2006
	 	iii

 

 

NANPA — Scope of Work Change #7 Proposal — INC Issue 454

 

	1	 	Introduction

	1.1	 	Purpose and Scope

In
accordance with NeuStar’s contract1 and our constant effort to provide the best support
and value to both the Federal Communications Commission (FCC) and the telecommunications industry,
NeuStar, as the North American Numbering Plan Administrator (NANPA), hereby submits this scope of
work change to the FCC for approval. This scope of work change is in compliance with NANPA’s Change
Management protocol and requirements as outlined in NANP Administrator Solicitation SOL03000001,
Section H.9, Item 5, which states the following:

“If and when a change to the NANPA system is adopted by the NANC or the INC, the
contractor’s liaison shall ensure that the proposed change is forwarded to the Contracting
Officer and the Contracting Officer’s Technical Representative (COTR). No change shall be
binding until such modification is issued, nor shall the Government be liable for any costs
associated with a system change until such modification is issued.”

	1.2	 	Modification of Guidelines

Pursuant to NeuStar’s contact, the NANPA shall participate in the development and
modification of guidelines and procedures, which may affect the performance of the NANPA functions.
These changes may be derived from regulatory directives and/or modifications to guidelines. In
addition, new guidelines may be developed as appropriate to comply with regulatory directives. The
NANPA shall adopt and implement any changes that are consistent with regulatory directives after
they are officially adopted, recognizing that some may constitute a change in the scope of work.

When the Industry Numbering Committee (INC) places any changes to its guidelines in initial
closure, the NANPA shall submit an assessment regarding the impact of scope of work, time and costs
to the INC, the North American Numbering Council (NANC) and the FCC within 30 days.2

This document provides detailed information pertaining to the INC’s requirement which was moved
into initial closure on August 31,2006. This change order document explains the industry’s
requirements, describes NANPA’s proposed solution and related assumptions, risks and costs.

 

			
	1	 	Contract Number CON03000016 and the NANPA Technical Requirements Document, March
2003.
	 
	2	 	NANPA Technical Requirements Document, March 2003, Section 2.10, Modification of
Guidelines.

      

			
	© Neu Star, Inc. 2006
	 	1

 

 

NANPA — Scope of Work Change #7 Proposal — INC Issue 454

 

2 Proposed Industry Numbering Committee (INC) Scope of Work
Change

During the August 22-24, 2006 INC meeting, INC Issue 454 was resolved and went to Initial
Closure on August 31, 2006. This issue affects both the NANP Administration System (NAS) and
NANPA operations.

	•	 	Issue 454: Criteria Service Providers (SP) Must
Meet to Obtain Growth 900 NXX

The official INC issue statement is stated below and can also be found on the ATIS website:

	A)	 	ISSUE STATEMENT

The 900 NXX Assignment Guidelines do not provide adequate criteria an SP must meet in order
to obtain a growth NXX.

	B)	 	FOLLOWING RESOLUTION FROM INC

The 900 NXX Assignment Guidelines, as well as the 900 NXX Forms (Parts A, B, and C) were
amended to clarify the process and requirements for applying for and obtaining additional 900 NXX
assignments. The modified 900 NXX Forms are attached.

	3	 	NeuStar’s Proposed Solution

In order to implement INC Issue 454 for the 900 NXX Code application processing, NANPA
proposes modifying the NANP Administration System to accommodate the changes the INC made to the
900 NXX Part A — Assignment Request/Return
Notification/Information Change; the 900 NXX Part B — 900 NXX Code Disposition Form; and the 900 NXX Part C —Certification of 900 NXX Code In Service
Form.

Solution:

NANPA will incorporate the text changes the INC made to the 900 NXX Forms (Part A, B, and C) into
the NAS. The changes direct that an initial request shall be limited to no more than 5 NXX codes,
and no more than 5 NXX codes can be requested at any one time. In order for an applicant to request
additional codes, the applicant must first certify that all previously assigned codes are in
service and the code holder has submitted its Part C “Confirmation of 900 NXX Code in Service” to
the NANPA. The applicant also must certify the need for the additional codes requested and advise
of plans to activate new services requiring individual codes within six months of the date of the
request on the Part A form.

The proposed changes to the 900 NXX Assignment forms result in text changes to the Part A, B and C
forms in NAS. However, there are no new data fields on the forms that require changes to the NAS
database.

      

			
	©NeuStar, Inc. 2006
	 	2

 

 

NANPA — Scope of Work Change #7 Proposal — INC Issue 454

 

	4	 	Assumptions and Risks

Part of the NANPA’s assessment of this change order is to identify the associated
assumption and consider the risks that can have an impact on its operations.

Assumptions:

	•	 	NANPA assumes the information provided to it by the applicant is true and accurate.
	 
	•	 	If the process expands beyond these assumptions, the NANPA reserves the option of filing a
revised change order proposal to address the additional expansion.

Risks:

	•	 	Multiple text changes to the 900 NXX Parts A, B and C forms will need to be reviewed to
ensure NAS forms duplicate the changes made by the industry.

Impact on Operations:

The proposed solution impacts NAS by requiring text changes to the three 900 NXX Assignment forms.
In addition, the process relies on the NANPA to convey these changes to 900 NXX applicants.

	5	 	Cost Assumptions and Summary

The proposed solution for implementation of the INC Issue 454 requires changes in NAS in
order for the system to match the text changes the INC has made to the 900 NXX Assignment Forms.
NANPA has determined that the cost associated with implementing this change in NAS is $1,768.19.

	6	 	Conclusion

NeuStar, as the NANPA, hereby seeks the FCC’s approval for this Scope of Work Change in
order for proper communication protocols to be executed by which the industry can be made
aware that NANPA is accommodating this Scope of Work change order.

      

			
	© NeuStar, Inc. 2006
	 	3

 

 

NANPA — Scooe of Work Change #7 Proposal — INC Issue 454

 

3.1 900 NXX CODE FORMS

3.1.1 PART A

     ASSIGNMENT REQUEST/RETURN NOTIFICATION/INFORMATION CHANGE

The applicant and the code administrator acknowledge that the information other than identifying
the applicant and any code assigned to that applicant, contained on this request form is sensitive
and will be treated as confidential. The information in this form shall be treated as proprietary
and will only be shared with 900 NXX code administrator personnel and/or regulators.

	1.	 	Name of entity requesting code assignment/return notification/information change:
	 
	 	 	 

	 
	2.	 	Applicant Contact Information:

	 	 	 	 	 	 	 	 	 	 	 
	Name:
	 	 	 	 	 	 	 	 	 	 
	 	 	 	 	 	 	 
	Street Address:	 	 	 	 	 	Room:                     	 	 
	 	 	 	 	 	 	 	 	 
	City, State/Province,	 	 	 	 	 	 
	 	 	 	 	 	 	 	 	 
	Country	 	 	 	 	 	 
	 	 	 	 	 	 	 	 	 
	Zip/Postal Code	 	 	 	 	 	 
	 	 	 	 	 	 	 	 	 

Phone No.:                      Email:                      FAX No.:                     

Company Name:                                                            

Operating Company Number
(OCN):1                     

Access Customer Name Abbreviation (ACNA):                     

Carrier Identification Code (CIC):                     

 

			
	1	 	Required per FCC 00-429 Section 52.15 (g) (3) (iv).

			
	 	 	 
	 
	© NeuStar, Inc. 2006
	 	4

 

 

NANPA — Scope of Work Change #7 Proposal — INC Issue 454

 

	3.	 	900 NXX Code Request
	 
	3a.	 	Is certification or authorization required to provide 900 NXX service in the intended service area?

Yes                            No                     

If yes, does your company have such certification or authorization?

Yes                            No                     

If yes, indicate type and date of certification (e.g., letter of authorization, license,
Certification of Public Convenience, etc.):

 

 

If no or pending, explain:

 

 

	 	3b. 	 	Type of Request (check one)
	 
	 	 	 	      900 NXX Code request (also complete Sections 3c and 3d)
	 
	 	 	 	      900 NXX Code return (also complete Section 3e)

	 
	 	 	 	      900 NXX Code information change (also complete Section 3f)
	 
	 	3c.	 	 900 NXX Code Request Information (see Section 5 of the Guidelines)

There will be no maximum placed on the total number of codes assigned to each carrier. No
more then five NXX codes shall be requested per application form. No more than five NXX codes
can be requested at any one time.

An
initial request shall be limited to
five NXX codes.

To request additional
codes, the applicant will be required
to; (Issue 454)

1. Certify that all previously assigned codes are in service and the code holder has
submitted its Part C, “Confirmation of 900 NXX Code in service Form.” to the NANPA. (Issue
454)

2.
Certify the need for the additional codes requested and advise of plans to activate new
services requiring individual codes within six months of the date of the reuest on the Part A
form (Issue 454)

	 	 	 	 	 	 	 	 	 
	Assignment Preferences
	 	 	 	In Service Date	 	 
	(1)
	 	 	 	 	 	 	 	 
	 

	 	 
	 	 	 	 	 	 
	(2)
	 	 	 	 	 	 	 	 
	 

	 	 
	 	 	 	 	 	 
	(3)
	 	 	 	 	 	 	 	 
	 

	 	 
	 	 	 	 	 	 

			
	 	 	 
	 
	© NeuStar, Inc. 2006
	 	5

 

 

NANPA — Scope of Work Change #7 Proposal — INC Issue 454

 

	 	 	 	 	 	 	 	 	 
	(4)

	 	 	 	 	 	 	 	 
	 

	 	 
	 	 	 	 	 	 
	(5)
	 	 	 	 	 	 	 	 
	 

	 	 
	 	 	 	 	 	 

Expected in service date(s) (must be within 6 months of assignment) (issue 454)

	3d. 	 	Current 900 NXX Code Assignments

List current 900 NXX Code(s) already assigned:

 

 

 

Have
all the above 900 NXXs been placed in service, and has a
Part C, “Confirmation of 900
NXX Code In Service Form,” been submitted for each 900 NXX Code? (Issue 454)

Yes                            No                     

If
no, please list the 900 NXXs not placed in service and the reasons why.(Issue 454)

 

 

 

 

	3e. 	 	Code Return Notification

The following 900 NXX code(s) are being returned to the list of available NXX codes:

 

Effective date:                                         

	3f.	 	 Code Information Change

900 NXX Codes affected:

 

Reasons for change:

           Merger/Acquisition

           Company Name Change

           Contact Information Change

           Other

Explanation:                                                             

Effective date:                                                            

			
	 	 	 
	 
	© NeuStar, Inc. 2006
	 	6

 

 

     NANPA — Scope of Work Change #7 Proposal — INC Issue 454

 

These NXX code(s) were formerly administered by:

     Company Name:                                                             

     Contact Name:                                        

     Street Address:                                          Room:                     

     City, State/Province,                                                             

           Country:                                                            

     Zip/Postal Code:                                         

     Phone:                                          Email:                         
                

     FAX:                                        

     OCN:                         ACNA:                         CIC:                     

(Issue 454) I hereby certify that the above information is true and accurate to the best of my
knowledge, that the assigned 900 NXX code (s) will be used in the provisioning of 900 service as
a public telecommunications service, and that this application has been prepared in accordance with the “900 NXX Code Assignment Guidelines.” (Issue 454)

 

Signature of Authorized Representative of Code Applicant/Holder

 

Name/Title

 

Date

3.2 900 NXX FORMS

3.2.1 PARTS

900 NXX CODE APPLICATION DISPOSITION FORM

Applicant Information

     Name:                                                             

     Street Address:                                          Room:                    

     City, State/Province:                                         

     Country:                                        

     Zip/Postal Code :                                        

     Phone No.:                      Email:                     

     FAX No.:                                        

     Company Name:                                                            
              
      

     Operating Company Number (OCN):                    

     Access Customer Name Abbreviation (ACNA):                    

     Carrier Identification Code (CIC):                    

			
	 	 	 
	 
	© NeuStar, Inc. 2006
	 	7

 

 

NANPA — Scope of Work Change #7 Proposal — INC Issue 454

 

     Date of Application:                     

     Date of Receipt of Request:                     

     Date of Response to Request:                     

Disposition of Code Request

	 	 	 	 	 	 
	 	 	 	Code request approved. 900 NXX code(s) assigned:
	 	 

	 	 	 	 
	 	 

	 	 	 	 
	 	 
	 	 	 	 
	 	 

	 	 	 	 
	 	 
	 	 	 	 
	 	 	 	     Form complete, code request denied
	 	 

	 	 	 	 
	 	 

	 	Explanation:	 	 
	 	 

	 	 	 	 
	 	 
	 	 	 	 
	 	 

	 	 	 	 
	 	 
	 	 	 	 
	 	 	 	     Form incomplete. Additional information required in the following section(s):
	 	 

	 	 	 	 
	 	 

	 	Explanation:	 	 
	 	 

	 	 	 	 
	 	 
	 	 	 	 
	 	 

	 	 	 	 
	 	 
	 	 	 	 
	 	 

	 	Code(s) returned:	 	 
	 	 

	 	 	 	 
	 	 

	 	Effective:	 	 
	 	 

	 	 	 	 

	 	 	 	 	 
	 

	 	 	 	 
	Signature of Code Administrator

	 	 	 	Date
	 
	 	 	 	 
	 

	 	 	 	 
	Street Address

	 	 	 	Room

      

City, State/Province

      

Country

      

Zip/Postal Code

Phone No.:                                            Email:                       
                 

FAX No.:                                                            

			
	 	 	 
	 
	© NeuStar, Inc. 2006
	 	8

 

 

NANPA — Scope of Work Change #7 Proposal — INC Issue 454

 

3.3 900 NXX CODE FORMS

3.3.1 PART C

CONFIRMATION
OF 900 NXX CODE IN SERVICE FORM (Issue 454)

By signing below, I certify that the 900 NXX code(s) specified below are in service and that the
NXX code(s) are being used for the purpose specified in the original application (See Section 5,
“Responsibilities of Code Applicants and Holders” in the 900 NXX Code Assignment Guidelines).

 

Authorized Representative of Code Holder (Print)

Operating Company Number (OCN)                     

	 	 	 	 	 
	 

Signature

	 	 	 	 
	 
	 	 	 	 
	 

	 	 	 	 
	Title

	 	 	 	Date
	 
	 	 	 	 
	Service Trouble Reporting Contact Name:

	 	 	 	 
	

 

	 	 	 	 
	 
	 	 	 	 
	Service Trouble Reporting Number:
	 	 	 	 
	 
	 	 	 	 
	 

	 	 	 	 

	 	 	 	 	 	 	 	 	 
	900 NXX Code	 	 	 	Date of Application	 	 	 	In Service Date
	 
	 	 	 	 	 	 	 	 
	 

	 	 	 	 
	 	 	 	 
	 
	 	 	 	 	 	 	 	 
	 

	 	 	 	 
	 	 	 	 
	 
	 	 	 	 	 	 	 	 
	 

	 	 	 	 
	 	 	 	 
	 
	 	 	 	 	 	 	 	 
	 

	 	 	 	 
	 	 	 	 
	 
	 	 	 	 	 	 	 	 
	 

	 	 	 	 
	 	 	 	 

			
	 	 	 
	 
	© NeuStar, Inc. 2006
	 	9

 

 

 

 

 

 

 

 

 

 

      

      

NANP Administration Services

Scope of Work Change Proposal # 8

INC Issue 496 — Update COCAG Section 6.3.1 Information

Changes for Rate Center Changes

November 22, 2006

	 	 	 
	 
	NeuStar, Inc.

	 	46000 Center Oak Plaza
	 

	 	Sterling, VA 20166

 

 

NANPA — Scope of Work Change #8 Proposal — INC Issue 496

 

Table of Contents

	 	 	 	 	 
	1     Introduction 
	 	 	1	 
	    1.1     Purpose and Scope 
	 	 	1	 
	    1.2     Modification of Guidelines 
	 	 	1	 
	2     Proposed Industry Numbering Committee (INC) Scope of Work Change 
	 	 	2	 
	3     NeuStar’s Proposed Solution 
	 	 	3	 
	4     Assumptions and Risks 
	 	 	4	 
	5     Cost Assumptions and Summary 
	 	 	4	 
	6     Conclusion 
	 	 	5	 

      

© NeuStar, Inc. 2006

iii

 

NANPA — Scope of Work Change #8 Proposal — INC Issue 496

 

	1	 	Introduction

	1.1	 	Purpose and Scope

In
accordance with NeuStar’s
contract1 and our constant effort to provide the best support
and value to both the Federal Communications Commission (FCC) and the telecommunications industry,
NeuStar, as the North American Numbering Plan Administrator (NANPA), hereby submits this scope of
work change to the FCC for approval. This scope of work change is in compliance with NANPA’s Change
Management protocol and most importantly per requirements as outlined in NANP Administrator
Solicitation SOL03000001, Section H.9, Item 5, which states the following:

“If and when a change to the NANPA system is adopted by the NANC or the INC, the
contractor’s liaison shall ensure that the proposed change is forwarded to the Contracting
Officer and the Contracting Officer’s Technical Representative (COTR). No change shall be
binding until such modification is issued, nor shall the Government be liable for any costs
associated with a system change until such modification is issued.”

	1.2	 	Modification of Guidelines

Pursuant to NeuStar’s contact, the NANPA shall participate in the development and
modification of guidelines and procedures, which may affect the performance of the NANPA functions.
These changes may be derived from regulatory directives and/or modifications to guidelines. In
addition, new guidelines may be developed as appropriate to comply with regulatory directives. The
NANPA shall adopt and implement any changes that are consistent with regulatory directives after
they are officially adopted, recognizing that some may constitute a change in the scope of work.

When the Industry Numbering Committee (INC) places any changes to its guidelines in initial
closure, the NANPA shall submit an assessment regarding the impact of scope of work, time and costs
to the INC, the North American Numbering Council (NANC) and the FCC within 30 days.2

This document provides detailed information pertaining to the INC’s requirement submitted on
October 27, 2006. This change order document covers the required subject matters such as
explaining the industry’s requirements, proposed solution, costs and risk and assumptions.

 

			
	1	 	Contract Number CON03000016 and the NANPA Technical Requirements Document, March 2003.
	 
	2	 	NANPA Technical Requirements Document, March 2003, Section 2.10, Modification of Guidelines.

 

© NeuStar, Inc. 2006

1

 

NANPA — Scope of Work Change #8 Proposal — INC Issue 496

      

	2	 	Proposed Industry Numbering Committee (INC) Scope of Work Change

During the October 19, 2006 INC meeting, INC Issue 496 was resolved and went to Initial
Closure on October 27, 2006. This issue affects NANPA operations.

	•	 	Issue 496: Update COCAG Section 6.3.1 Information Changes for Rate Center Changes

The official INC issue statement is stated below and can also be found on the ATIS website:

	A)	 	ISSUE STATEMENT

“When a SP requests to move a code(s) from one rate center to another, Section 6.3.1
Information Changes of the COCAG requires that the SP must certify to the NANPA that there are no
ported numbers within the code(s). Section 3.9 of the COCAG states that SPs cannot change the
rate center on a code that contains ported TNs because of the impact to customer calling patterns
and associated charges, and the fourth paragraph of Section 6.3.1 states that SPs cannot change the
rate center on a pooled code if blocks have been assigned to any SP other than the LERG Assignee.

Unfortunately, experience has shown that some SPs may not understand the implications of changing
the rate center on a pooled code or a code that contains ported TNs, and the SP may simply supply
the certification to NANPA without actually checking the LNP database. Similar to the process of
NANPA’s verification that there are no ported TNs in a returned code before approving disconnect of
the code, NANPA should also verify that there are no ported TNs in a code when an SP requests a
rate center change.

NANPA could run an NPAC report to determine if there are ported numbers within a code for which the
rate center change has been requested. If the code contains ported numbers, then NANPA will deny
the request for a rate center change. If the code contains pooled blocks but no ported numbers and
the LERG Assignee is the only SP with blocks from the code, then NANPA may approve the rate center
change.”

	B)	 	FOLLOWING RESOLUTION FROM INC

The following text changes were made to the COCAG, Section 6.3.1 and Section 13 (Glossary):

	6.3.1	 	Information Changes

SPs that wish to move CO codes from one rate center to another must submit a Part 1 to the CO Code
Administrator. Upon receipt of the Part 1 for an NXX that has been activated, the CO Code
Administrator will request that the NPAC produce an ad hoc report, generated during off-peak hours,
that identifies the SPs and associated quantities of ported TNs or pending ports within the
code(s). The CO Code Administrator will not request an ad hoc report if the SP is requesting a rate
center change for a code that has not reached its LERG Routing Guide effective date.

 

© NeuStar, Inc. 2006

2

 

NANPA — Scope of Work Change #8 Proposal — INC Issue 496

 

If the report shows that there are ported TNs or pending ports, then the CO Code
Administrator will issue a Part 3 Denial to the applicant. If the report shows that there
are no ported TNs or pending ports, then the CO Code Administrator will issue a Part 3
Acceptance to the applicant with instructions to the Applicant to immediately remove the NXX
from the NPAC to ensure that no porting occurs between the time the ad hoc report was produced
and the effective date of the rate center change. On the effective date of the rate center
change, the Applicant must immediately add the NXX to the NPAC to ensure that porting can
resume.

	13.0	 	Glossary

	 	 	 
	  NPAC SMS

	 	The Number Portability Administration Center (NPAC) Service Management
	 

	 	System (SMS) is a database that contains routing
	 

	 	information on ported TNs and pooled blocks and facilitates the updating
	 

	 	of the routing databases of all subtending SPs in the portability area.

	3	 	NeuStar’s Proposed Solution

In order to implement INC Issue 496, NANPA personnel will need to request an ad hoc
report from the NPAC whenever a service provider submits an application to change the rate
center associated with an in-service central office code. Presently, NANPA relies upon the
certification of the service provider that the code in question has no active or pending
ports. INC Issue 496, which requires NANPA to obtain an ad hoc report for all service provider
requests to change the rate center for an in-service code, is a new requirement for NANPA.

For each CO code application requesting a rate center change on an in-service code, NANPA
will: 1) review the application for accuracy and completeness, 2) prepare and submit a request
to NPAC for an ad hoc report, 3) suspend the service provider application in the NANP
Administration System (NAS), 4) compile and analyze the information contained in the ad hoc
report and 5) return a Part 3 (“Administrator Confirmation”) to the service provider.

Steps 2, 3 and 4 are new requirements for NANPA when processing these types of requests.
In addition, NANPA personnel will be required to provide new standard verbiage within the
Part 3 remarks field generated by the NAS when providing the required disposition to the
applicant. Also, NANPA has learned through its experience with the return code with
ported telephone number (TN) process that additional interaction (e.g., email, phone
calls) will be required between the NANPA CO Code Administrator and the service provider
whenever a code application involves the disposition of ported TNs.

 

© NeuStar, Inc. 2006

3

 

NANPA — Scope of Work Change #8 Proposal — INC Issue 496

 

	4	 	Assumptions and Risks

As part of the NANPA’s assessment of this change order, NANPA is required to identify the
associated assumptions and risks that can have an impact on its operations.

Assumptions:

	•	 	NANPA assumes the information provided to it by the applicant is true and accurate.
	 
	•	 	NANPA assumes the NPAC ad hoc report is true and accurate.
	 
	•	 	NANPA assumes that the current process it uses to request an ad hoc report from the NPAC
will remain the same as it is today for requesting such a report for central office code
returns.
	 
	•	 	NANPA will request an ad hoc report for all applications requesting a rate center change.
(Note: Per industry guidelines, rate center consolidations and additions do not require
service providers to submit an application to NANPA).
	 
	•	 	If the process expands beyond these assumptions, the NANPA reserves the option of filing a
revised change order proposal to address the additional expansion.

Risks:

	•	 	NANPA relies upon the information in the NPAC ad hoc report to make its determination to
approve or deny a request. Any inaccuracies in NPAC data may result in the incorrect
disposition of the request.

Impact on Operations:

The proposed solution impacts NANPA operations by requiring NANPA personnel to take additional time
and effort to complete an application requiring a rate center change. Further, NANPA must now rely
on an outside entity (NPAC) to complete this transaction that is presently accomplished without
external information.

	5	 	Cost Assumptions and Summary

The proposed solution for implementation of the INC Issue 496 requires changes in NANPA
operations. NANPA personnel must verify there are not active or pending ports on all code
applications requesting a rate center change. NANPA has determined that the cost associated with
implementing this change is $4,956.00 per year or $413.00 per month.

To determine this cost, NANPA identified the quantity of applications involving a rate center
change since January 2005 and used that information to calculate an average monthly quantity of
such applications.3 NANPA then factored into this average monthly quantity the
possibility that service providers will delegate the responsibility of identifying active or
pending ports on a code

 

			
	3	 	NANPA excluded rate center changes due to consolidations and the creation of new rate centers.

 

© NeuStar, Inc. 2006

4

 

NANPA — Scope of Work Change #8 Proposal — INC Issue 496

      

to NANPA, rather than performing this work themselves, as is presently required per industry
guidelines. After identifying the additional steps required to process a rate center change
request, NANPA calculated the additional processing time required for each CO code application
requesting a change in rate center. With this information, NANPA determined a cost per application
and multiplied that result by the projected average monthly quantity of rate center change
requests.

	6	 	Conclusion

NeuStar, as the NANPA, hereby seeks the FCC’s approval for this Scope of Work Change. Upon
approval by the FCC, NANPA can notify the industry that NANPA is accommodating this Scope of Work
change order.

 

© NeuStar, Inc. 2006

5

 

      

      

NANP
Administration Services

Scope of Work Change Proposal # 9

INC Issue 522: Revisions to Procedures for Submitting the

Part 4 Form for Dedicated Non-pooled codes

November 22, 2006

	 	 	 
	 
	NeuStar, Inc.

	 	46000 Center Oak Plaza
	 

	 	Sterling, VA 20166

 

 

NANPA — Scope of Work Change #9 Proposal — INC Issue 522

      

Table of Contents

	 	 	 	 	 
	1     Introduction 
	 	 	1	 
	  1.1     Purpose and Scope 
	 	 	1	 
	  1.2     Modification of Guidelines
	 	 	1	 
	2     Proposed Industry Numbering Committee (INC) Scope of Work Change 
	 	 	2	 
	3     NeuStar’s Proposed Solution 
	 	 	2	 
	4     Assumptions and Risks 
	 	 	3	 
	5     Cost Assumptions and Summary 
	 	 	3	 
	6     Conclusion 
	 	 	3	 

 

© NeuStar, Inc. 2006

iii

 

NANPA — Scope of Work Change #9 Proposal — INC Issue 522

 

	1	 	Introduction

	1.1	 	Purpose and Scope

In
accordance with NeuStar’s
contract1 and our constant effort to provide the best support and
value to both the Federal Communications Commission (FCC) and the telecommunications industry,
NeuStar, as the North American Numbering Plan Administrator (NANPA), hereby submits this scope of
work change to the FCC for approval. This scope of work change is in compliance with NANPA’s Change
Management protocol and most importantly per requirements as outlined in NANP Administrator
Solicitation SOL03000001, Section H.9, Item 5, which states the following:

“If and when a change to the NANPA system is adopted by the NANC or the INC, the
contractor’s liaison shall ensure that the proposed change is forwarded to the Contracting
Officer and the Contracting Officer’s Technical Representative (COTR). No change shall be
binding until such modification is issued, nor shall the Government be liable for any costs
associated with a system change until such modification is issued.”

	1.2	 	Modification of Guidelines

Pursuant to NeuStar’s contact, the NANPA shall participate in the development and modification
of guidelines and procedures, which may affect the performance of the NANPA functions. These
changes may be derived from regulatory directives and/or modifications to guidelines. In addition,
new guidelines may be developed as appropriate to comply with regulatory directives. The NANPA
shall adopt and implement any changes that are consistent with regulatory directives after they are
officially adopted, recognizing that some may constitute a change in the scope of work.

When the Industry Numbering Committee (INC) places any changes to its guidelines in initial
closure, the NANPA shall submit an assessment regarding the impact of scope of work, time and costs
to the INC, the North American Numbering Council (NANC) and the FCC within 30 days.2

This document provides detailed information pertaining to the INC’s requirement submitted on
October 27, 2006. This change order document covers the required subject matters such as
explaining the industry’s requirements, proposed solution, costs and risk and assumptions.

 

			
	1	 	Contract Number CON03000016 and the NANPA Technical Requirements Document, March 2003.

			
	2	 	NANPA Technical Requirements Document, March 2003, Section 2.10, Modification of Guidelines.

 

© NeuStar, Inc. 2006

1

 

NANPA — Scope of Work Change #9 Proposal — INC Issue 522

 

	2	 	Proposed Industry Numbering Committee (INC) Scope of Work Change

During the October 19, 2006 INC meeting, INC Issue 522 was resolved and went to Initial
Closure on October 27, 2006. This issue affects the NANP Administration System (“NAS”).

	•	 	Issue 522: Revisions to Procedures for Submitting the Part 4 Form for Dedicated Non-pooled
codes

The official INC issue statement is stated below and can also be found on the ATIS website:

	A)	 	ISSUE STATEMENT

Service Providers that designate dedicated codes obtained through the Pooling Administrator
as non-pooled codes should be allowed to submit Part 4s for these codes directly to NANPA.

	B)	 	FOLLOWING RESOLUTION FROM INC

The resolution of the issue is to allow a SP that has applied to the Pooling Administrator
(“PA”) for a dedicated NPA-NXX in a pooling area, and has received that NPA-NXX, to submit the Part
4 “Confirmation of CO Code in Service” directly to the NANPA via NAS. Currently, the SP is required
to submit the Part 4 “Confirmation of CO Code in Service” directly to the PA.

	3	 	NeuStar’s Proposed Solution

INC Issue 522 requires NANPA to send the “Administrators Response — Receipt of Part 4”
(i.e., “Part 5”) to the PA if the service provider submits a “Confirmation of CO Code In-Service”
(i.e., “Part 4”) directly to the NANPA for a non-pooled, dedicated code that was originally
requested via the PA.

Solution:

A new field will be added to the Part 4 in which the service provider submitting the Part 4 can
indicate that the code is a non-pooled, dedicated code in a pooling area. If this field is
populated, NAS will automatically forward the Part 5 to the service provider and the PA. If this
field is not populated, the Part 5 will only be sent to the service provider.

In addition, NANPA will update the standard verbiage associated with the Part 4 reminder notice
that is automatically generated by NAS. Presently, if a Part 4 has not been received by NANPA
during the first five months following the original effective date as indicated on the Part 3, a
reminder notice will be sent to the code assignee. The notice is sent no later than one month prior
to the end of the 6th month and provides direction to the code assignee on submitting
the Part 4. The text of the reminder notice must be updated to reflect the option for the service
provider to submit a Part 4 directly to the NANPA if the code is a non-pooled, dedicated code.

 

© NeuStar, Inc. 2006

2

 

NANPA — Scope of Work Change #9 Proposal — INC Issue 522

 

	4	 	Assumptions and Risks

As part of the NANPA’s assessment of this change order, NANPA is required to identify
the associated assumptions and risks that can have an impact on its operations.

Assumptions:

	•	 	NANPA assumes that the service provider will properly identify the code as a non-pooled,
dedicated code and populate the non-pooled dedicated code field on the Part 4 to trigger the
automatic forwarding of NANPA’s disposition to the PA.
	 
	•	 	NANPA assumes that service providers may return the Part 4 form for a non-pooled,
dedicated code to either the PA or the NANPA. The service provider would not submit the same
Part 4 form to both administrators.

Risks:

	•	 	If the service provider fails to indicate on the Part 4 that the involved code is a
non-pooled, dedicated code, no notification will be sent by NAS to the PA. Failure to provide
such a notification to the PA may result in a code being placed on a state reclamation list. A
state regulatory commission may contact a service provider about an assigned code not being
placed in service within industry prescribed time frames when in fact the code is in service.

	5	 	Cost Assumptions and Summary

The proposed solution for implementation of the INC Issue 522 requires changes in NAS in order
for the system to automatically send a Part 5 to both the PA and the service provider when the Part
4 is associated with a non-pooled, dedicated code. NANPA has determined that the cost associated
with implementing this change in NAS is $5,028.00.

	6	 	Conclusion

NeuStar, as the NANPA, hereby seeks the FCC’s approval for this Scope of Work Change. Upon
approval by the FCC, NANPA can notify the industry that NANPA is accommodating this Scope of Work
change order.

 

© NeuStar, Inc. 2006

3exv10w6

 

Exhibit
10.6

	 	 	 
	

	 	.BIZ Registry Agreement

(8 December 2006)

 

Registry Agreement

This REGISTRY AGREEMENT (this “Agreement”) is entered into as of 18 December 2006 by and between
Internet Corporation for Assigned Names and Numbers, a California nonprofit public benefit
corporation (“ICANN”), and NeuStar, Inc. a Delaware corporation.

ARTICLE 1 INTRODUCTION

Section 1.1 Effective Date. The Effective Date for purposes of this Agreement shall be 8 December
2006.

Section 1.2 Top-Level Domain. The Top-Level Domain to which this Agreement applies is .biz (“TLD”).

Section 1.3 Designation as Registry Operator. Upon the Effective Date, until the Expiration Date as
defined in Section 4.1 hereof, ICANN shall continue to designate NeuStar, Inc. as the sole registry
operator for the TLD (“Registry Operator”).

ARTICLE 2 REPRESENTATIONS AND WARRANTIES

Section 2.1 Registry Operator’s Representations and Warranties.

2.1 (a) Organization; Due Authorization and Execution. Registry Operator is a corporation,
duly organized, validly existing and in good standing under the laws of Delaware, and
Registry Operator has all requisite power and authority to enter into this Agreement. All
corporate approvals and actions necessary for the entrance by Registry Operator into this
Agreement have been obtained and this Agreement has been duly and validly executed and
delivered by Registry Operator.

2.1 (b) Statements made During Negotiation Process. The factual statements made in writing by
both Parties in negotiating this Agreement, were true and correct in all material respects at
the time . A violation or breach of this subsection shall not be a basis for termination,
rescission or other equitable relief, and, instead shall only give rise to a claim for
damages.

Section 2.2 ICANN’s Representations and Warranties.

2.2 (a) Organization; Due Authorization and Execution. ICANN is a nonprofit public benefit
corporation duly organized, validly existing and in good standing under the laws of
California. ICANN has all requisite corporate power and authority to enter

 

 

into this Agreement. All corporate approvals and actions necessary for the entrance by ICANN
into this Agreement have been obtained and this Agreement has been duly and validly executed
and delivered by ICANN.

ARTICLE 3 COVENANTS

Section 3.1 Covenants of Registry Operator. Registry Operator covenants and agrees with ICANN as
follows:

3.1 (a) Preserve Security and Stability.

3.1 (a)(i) ICANN Temporary Specifications or Policies. Registry Operator shall comply
with and implement all specifications or policies established by the ICANN Board of
Directors on a temporary basis, if adopted by the ICANN Board of Directors by a vote
of at least two-thirds of its members, so long as the ICANN Board of Directors
reasonably determines that immediate temporary establishment of a specification or
policy on the subject is necessary to maintain the Stability or Security (as defined
in Section 3.1(d)(iv)(G)) of Registry Services or the DNS (“Temporary Specification or
Policies”). Such proposed specification or policy shall be as narrowly tailored as
feasible to achieve those objectives. In establishing any specification or policy
under this provision, the ICANN Board of Directors shall state the period of time for
which the specification or policy is temporarily adopted and shall immediately
implement the Consensus Policy development process set forth in ICANN’s Bylaws. ICANN
shall also issue an advisory statement containing a detailed explanation of its
reasons for adopting the temporary specification or policy and why the Board believes
the specification or policy should receive the consensus support of Internet
stakeholders. If the period of time for which the specification or policy is adopted
exceeds 90 days, the ICANN Board shall reaffirm its temporary adoption every 90 days
for a total period not to exceed one year, in order to maintain such policy in effect
until such time as it shall become a Consensus Policy as described in Section 3.1(b)
below. If during such one year period, the temporary policy or specification does not
become a Consensus Policy meeting the standard set forth in Section 3.1(b) below,
Registry Operator shall no longer be required to comply with or implement such
temporary policy or specification.

3.1 (b) Consensus Policies.

3.1 (b)(i) At all times during the term of this Agreement and subject to the terms
hereof, Registry Operator will fully comply with and implement all Consensus Policies
found at http://www.icann.org/general/consensus-policies.htm, as of the Effective Date
and as may in the future be developed and adopted in accordance with ICANN’s Bylaws
and as set forth below.

3.1 (b)(ii) “Consensus Policies” are those specifications or policies established (1)
pursuant to the procedure set forth in ICANN’s Bylaws and due process, and (2)
covering those topics listed in Section 3.1(b)(iv) below. The Consensus Policy
development process and procedure set forth in ICANN’s Bylaws may be revised from time
to time in accordance

 

 

with ICANN’s Bylaws, and any Consensus Policy that is adopted through such a revised process
and covering those topics listed in Section 3.1(b) (iv) below shall be considered a Consensus
Policy for purposes of this Agreement.

3.1 (b)(iii) For all purposes under this Agreement, the policies identified at
http://www.icann.org/general/consensus-policies.htm shall be treated in the same manner and have
the same effect as “Consensus Policies.”

3.1 (b)(iv) Consensus Policies and the procedures by which they are developed shall be designed to
produce, to the extent possible, a consensus of Internet stakeholders, including the operators of
gTLDs. Consensus Policies shall relate to one or more of the following: (1) issues for which
uniform or coordinated resolution is reasonably necessary to facilitate interoperability, Security
and/or Stability of the Internet or DNS; (2) functional and performance specifications for the
provision of Registry Services (as defined in Section 3.1(d)(iii) below); (3) Security and
Stability of the registry database for the TLD; (4) registry policies reasonably necessary to
implement Consensus Policies relating to registry operations or registrars; or (5) resolution of
disputes regarding the registration of domain names (as opposed to the use of such domain names).
Such categories of issues referred to in the preceding sentence shall include, without limitation:

3.1 (b)(iv)(A) principles for allocation of registered names in the TLD (e.g., first-come,
first-served, timely renewal, holding period after expiration);

3.1 (b)(iv)(B) prohibitions on warehousing of or speculation in domain names by registries or
registrars;

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

3.1 (b)(iv)(D) maintenance of and access to accurate and up-to-date information concerning
domain name registrations;

3.1 (b)(iv)(E) procedures to avoid disruptions of domain name registration due to suspension
or termination of operations by a registry operator or a registrar, including procedures for
allocation of responsibility for serving registered domain names in a TLD affected by such a
suspension or termination; and

3.1 (b)(iv)(F) resolution of disputes regarding whether particular parties may register or
maintain registration of particular domain names.

 

 

3.1 (b)(v) In addition to the other limitations on Consensus Policies,
they shall not:

3.1 (b)(v)(A) prescribe or limit the price of Registry Services;

3.1 (b)(v)(B) modify the standards for the consideration of proposed
Registry Services, including the definitions of Security and Stability
(set forth below) and the standards applied by ICANN;

3.1 (b)(v)(C) for two years following the Effective Date, modify
the procedure for the consideration of proposed Registry Services;

3.1 (b)(v)(D) modify the terms or conditions for the renewal or
termination of this Agreement;

3.1 (b)(v)(E) modify ICANN’s obligations to Registry Operator under
Section 3.2 (a), (b), and (c);

3.1 (b)(v)(F) modify the limitations on Temporary
Specifications or Consensus Policies;

3.1 (b)(v)(G) modify the definition of Registry Services;

3.1 (b)(v)(H) modify the terms of Sections 7.2 below; or

3.1 (b)(v)(I) alter services that have been implemented pursuant to
Section 3.1(d) of this Agreement (unless justified by compelling and
just cause based on Security and Stability.

3.1 (b)(vi) Registry Operator shall be afforded a reasonable period of time
following notice of the establishment of a Consensus Policy or Temporary
Specifications or Policies in which to comply with such policy or
specification, taking into account any urgency involved. In the event of a
conflict between Registry Services (as defined in Section 3.1(d)(iii) below),
on the one hand, and Consensus Policies developed in accordance with this
Section 3.1(b) or any Temporary Specifications or Policies established
pursuant to Section 3.1(a)(i) above, on the other hand, the Consensus Polices
or Temporary Specifications or Policies shall control, notwithstanding any
other provisions contained within this Agreement.

3.1 (c) Handling of Registry Data.

3.1 (c)(i) Data Escrow. Registry Operator shall establish at its expense a
data escrow or mirror site policy for the Registry Data compiled by Registry
Operator. Registry Data, as used in this Agreement, shall mean the following:
(1) data for domains sponsored by all registrars, consisting of domain name,
server name for each nameserver, registrar id, updated date, creation date,
expiration date, status information, and DNSSEC related key material (if
Registry Operator implements DNSSEC); (2) data

 

 

for nameservers sponsored by all registrars consisting of server name,
each IP address, registrar id, updated date, creation date, expiration date,
and status information; (3) data for registrars sponsoring registered domains
and nameservers, consisting of registrar id, registrar address, registrar
telephone number, registrar e-mail address, whois server, referral URL,
updated date and the name, telephone number, and e-mail address of all the
registrar’s administrative, billing, and technical contacts; (4) domain name
registrant data collected by the Registry Operator from registrars as part of
or following registration of a domain name; and (5) the DNSSEC-related
material necessary to sign the .biz zone (e.g., public and private
portions of .biz zone key-signing keys and zone-signing keys)(if Registry Operator
implements DNSSEC). The escrow agent or mirror-site manager, and the
obligations thereof, shall be mutually agreed upon by ICANN and Registry
Operator on commercially reasonable standards that are technically and
practically sufficient to allow a successor registry operator to assume
management of the TLD. To this end, Registry Operator shall periodically
deposit into escrow all Registry Data on a schedule (not more frequently than
weekly for a complete set of Registry Data, and daily for incremental updates)
and in an electronic format mutually approved from time to time by Registry
Operator and ICANN, such approval not to be unreasonably withheld by either
party. In addition, Registry Operator will deposit into escrow that data
collected from registrars as part of offering Registry Services introduced
after the Effective Date of this Agreement. The schedule, content, format, and
procedure for escrow deposits shall be as reasonably established by ICANN from
time to time, and as set forth in Appendix 1 hereto. Changes to the schedule,
content, format, and procedure may be made only with the mutual written
consent of ICANN and Registry Operator (which neither party shall unreasonably
withhold) or through the establishment of a Consensus Policy as outlined in
Section 3.1(b) above. The escrow shall be held under an agreement,
substantially in the form of Appendix 2, as the same may be revised from time
to time, among ICANN, Registry Operator, and the escrow agent.

3.1 (c)(ii) Personal Data. Registry Operator shall notify registrars
sponsoring registrations in the registry for the TLD of the purposes for which
Personal Data (as defined below) submitted to Registry Operator by registrars,
if any, is collected, the intended recipients (or categories of recipients) of
such Personal Data, and the mechanism for access to and correction of such
Personal Data. Registry Operator shall take reasonable steps to protect
Personal Data from loss, misuse, unauthorized disclosure, alteration or
destruction. Registry Operator shall not use or authorize the use of Personal
Data in a way that is incompatible with the notice provided to registrars.
“Personal Data” shall refer to all data about any identified or identifiable
natural person.

3.1 (c)(iii) Bulk Zone File Access. Registry Operator shall provide bulk
access to the zone files for the registry for the TLD to ICANN on a continuous
basis in the manner ICANN may reasonably specify from time to time. Bulk
access to the zone files shall be provided to third parties on the terms set
forth in the TLD zone file access agreement reasonably established by ICANN,
which initially shall be in the form attached as Appendix 3 hereto. Changes to
the zone file access agreement may be

 

 

made upon the mutual written consent of ICANN and Registry Operator
(which consent neither party shall unreasonably withhold).

3.1 (c)(iv) Monthly Reporting. Within 20 days following the end of each
calendar month, Registry Operator shall prepare and deliver to ICANN a report
providing such data and in the format specified in Appendix 4. ICANN may audit
Registry Operator’s books and records relating to data contained in monthly
reports from time to time upon reasonable advance written notice, provided
that such audits shall not exceed one per quarter. Any such audit shall be at
ICANN’s cost, unless such audit shall reflect a material discrepancy or
discrepancies in the data provided by Registry Operator. In the latter event,
Registry Operator shall reimburse ICANN for all reasonable costs and expenses
associated with such audit, which reimbursement shall be paid together with
the next Registry-Level Fee payment due following the date of transmittal of
the cost statement for such audit.

3.1 (c)(v) Whois Service. Registry Operator shall provide such whois data as
set forth in Appendix 5.

3.1 (d) Registry Operations.

3.1 (d)(i) Registration Restrictions.

3.1 (d)(i)(A) Registry Operator shall reserve, and not register any TLD
strings (i) appearing on the list of reserved TLD strings attached as
Appendix 6 hereto or (ii) located at
http://data.iana.org/TLD/tlds-alpha-by-domain.txt for initial (i.e.,
other than renewal) registration at the second level within the TLD.

3.1(d)(i)(B) Registry Operator shall apply, monitor, and enforce the
restrictions on registration in the Registry TLD. Appendix 11 sets
forth the restrictions to be applied and sets forth the manner by which
these restrictions shall be applied, monitored, and enforced. Changes
to the restrictions may be made only with the mutual written consent of
ICANN and Registry Operator (which neither party shall unreasonably
withhold).

3.1 (d)(ii) Functional and Performance Specifications. Functional and
Performance Specifications for operation of the TLD shall be as set forth in
Appendix 7 hereto, and shall address without limitation DNS services;
operation of the shared registration system; and nameserver operations.
Registry Operator shall keep technical and operational records sufficient to
evidence compliance with such specifications for at least one year, which
records ICANN may audit from time to time upon reasonable advance written
notice, provided that such audits shall not exceed one per quarter. Any such
audit shall be at ICANN’s cost.

3.1 (d)(iii) Registry Services. Registry Services are, for purposes of this
Agreement, defined as the following: (a) those services that are both (i)

 

 

operations of the registry critical to the following tasks: the receipt of data from
registrars concerning registrations of domain names and name servers; provision to registrars of
status information relating to the zone servers for the TLD; dissemination of TLD zone files;
operation of the registry zone servers; and dissemination of contact and other information
concerning domain name server registrations in the TLD as required by this Agreement; and (ii)
provided by the Registry Operator for the .biz registry as of the Effective Date as set forth on
Appendix 9; (b) other products or services that the Registry Operator is required to provide
because of the establishment of a Consensus Policy (as defined in Section 3.1(b) above); (c) any
other products or services that only a registry operator is capable of providing, by reason of its
designation as the registry operator; and (d) material changes to any Registry Service within the
scope of (a), (b) or (c) above.

3.1 (d)(iv) Process for Consideration of Proposed Registry Services. Following
written notification by Registry Operator to ICANN that Registry Operator may
make a change in a Registry Service within the scope of the preceding
paragraph:

3.1 (d)(iv)(A) ICANN shall have 15 calendar days to make a “preliminary
determination” whether a Registry Service requires further
consideration by ICANN because it reasonably determines such Registry
Service: (i) could raise significant Security or Stability issues or
(ii) could raise significant competition issues.

3.1 (d)(iv)(B) Registry Operator must provide sufficient information at
the time of notification to ICANN that it may implement such a proposed
Registry Service to enable ICANN to make an informed “preliminary
determination.” Information provided by Registry Operator and marked
“CONFIDENTIAL” shall be treated as confidential by ICANN. Registry
Operator will not designate “CONFIDENTIAL” information necessary to
describe the purpose of the proposed Registry Service and the effect on
users of the DNS.

3.1 (d)(iv)(C) ICANN may seek expert advice during the preliminary
determination period (from entities or persons subject to
confidentiality agreements) on the competition, Security or Stability
implications of the Registry Service in order to make its “preliminary
determination.” To the extent ICANN determines to disclose confidential
information to any such experts, it will provide notice to Registry
Operator of the identity of the expert(s) and the information it
intends to convey.

3.1 (d)(iv)(D) If ICANN determines during the 15 calendar day
“preliminary determination” period that the proposed Registry Service,
does not raise significant Security or Stability (as defined below), or
competition issues, Registry Operator shall be free to deploy it upon
such a determination.

 

 

3.1 (d)(iv)(E) In the event ICANN reasonably determines during the 15 calendar day
“preliminary determination” period that the Registry Service might raise significant competition
issues, ICANN shall refer the issue to the appropriate governmental competition authority or
authorities with jurisdiction over the matter within five business days of making its
determination, or two business days following the expiration of such 15 day period, whichever is
earlier, with notice to Registry Operator. Any such referral communication shall be posted on
ICANN’s website on the date of transmittal. Following such referral, ICANN shall have no further
responsibility, and Registry Operator shall have no further obligation to ICANN, with respect to
any competition issues relating to the Registry Service. If such a referral occurs, the Registry
Operator will not deploy the Registry Service until 45 calendar days following the referral, unless
earlier cleared by the referred governmental competition authority.

3.1 (d)(iv)(F) In the event that ICANN reasonably determines during the 15 calendar day
“preliminary determination” period that the proposed Registry Service might raise significant
Stability or Security issues (as defined below), ICANN will refer the proposal to a Standing Panel
of experts (as defined below) within five business days of making its determination, or two
business days following the expiration of such 15 day period, whichever is earlier, and
simultaneously invite public comment on the proposal. The Standing Panel shall have 45 calendar
days from the referral to prepare a written report regarding the proposed Registry Service’s effect
on Security or Stability (as defined below), which report (along with a summary of any public
comments) shall be forwarded to the ICANN Board. The report shall set forward the opinions of the
Standing Panel, including, but not limited to, a detailed statement of the analysis, reasons, and
information upon which the panel has relied in reaching their conclusions, along with the response
to any specific questions that were included in the referral from ICANN staff. Upon ICANN’s
referral to the Standing Panel, Registry Operator may submit additional information or analyses
regarding the likely effect on Security or Stability of the Registry Service.

3.1 (d)(iv)(G) Upon its evaluation of the proposed Registry Service, the Standing Panel will report
on the likelihood and materiality of the proposed Registry Service’s effects on Security or
Stability, including whether the proposed Registry Service creates a reasonable risk of a
meaningful adverse effect on Security or Stability as defined below:

Security: For purposes of this Agreement, an effect on security by the proposed Registry
Service shall mean (1) the unauthorized disclosure, alteration, insertion or destruction of
Registry Data, or (2) the unauthorized access to or

 

 

disclosure of information or resources on the Internet by systems operating in
accordance with all applicable standards.

Stability: For purposes of this Agreement, an effect on stability shall mean that the
proposed Registry Service (1) is not compliant with applicable relevant standards that are
authoritative and published by a well-established, recognized and authoritative standards
body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF or
(2) creates a condition that adversely affects the throughput, response time, consistency or
coherence of responses to Internet servers or end systems, operating in accordance with
applicable relevant standards that are authoritative and published by a well-established,
recognized and authoritative standards body, such as relevant Standards-Track or Best Current
Practice RFCs and relying on Registry Operator’s delegation information or provisioning
services.

3.1 (d)(iv)(H) Following receipt of the Standing Panel’s report, which will be posted (with
appropriate confidentiality redactions made after consultation with Registry Operator) and
available for public comment, the ICANN Board will have 30 calendar days to reach a decision. In
the event the ICANN Board reasonably determines that the proposed Registry Service creates a
reasonable risk of a meaningful adverse effect on Stability or Security, Registry Operator will not
offer the proposed Registry Service. An unredacted version of the Standing Panel’s report shall be
provided to Registry Operator upon the posting of the report. The Registry Operator may respond to
the report of the Standing Panel or otherwise submit to the ICANN Board additional information or
analyses regarding the likely effect on Security or Stability of the Registry Service.

3.1 (d)(iv)(I) The Standing Panel shall consist of a total of 20 persons expert in the design,
management and implementation of the complex systems and standards-protocols utilized in the
Internet infrastructure and DNS (the “Standing Panel”). The members of the Standing Panel will be
selected by its Chair. The Chair of the Standing Panel will be a person who is agreeable to both
ICANN and the registry constituency of the supporting organization then responsible for generic top
level domain registry policies. All members of the Standing Panel and the Chair shall execute an
agreement requiring that they shall consider the issues before the panel neutrally and according to
the definitions of Security and Stability. For each matter referred to the Standing Panel, the
Chair shall select no more than five members from the

 

 

Standing Panel to evaluate the referred matter, none of which shall
have an existing competitive, financial, or legal conflict of interest, and
with due regard to the particular technical issues raised by the referral.

3.1 (e) Fees and Payments. Registry Operator shall pay the Registry-Level Fees to ICANN on a
quarterly basis in accordance with Section 7.2 hereof.

3.1 (f) Traffic Data. Nothing in this Agreement shall preclude Registry Operator from making
commercial use of, or collecting, traffic data regarding domain names or non-existent domain
names for purposes such as, without limitation, the determination of the availability and
health of the Internet, pinpointing specific points of failure, characterizing attacks and
misconfigurations, identifying compromised networks and hosts and promoting the sale of
domain names, provided however, that such use does not permit Registry Operator to disclose
domain name registrant or end-user information or other Personal Data as defined in Section
3.1(c)(ii) that it collects through providing domain name registration services for any
purpose not otherwise authorized by this agreement. In this regard, in the event the TLD
registry is a “thick” registry model, the traffic data that may be accessible to and used by
Registry Operator shall be limited to the data that would be accessible to a registry
operated under a “thin” registry model. The process for the introduction of new Registry
Services shall not apply to such traffic data. Nothing contained in this section 3.1(f) shall
be deemed to constitute consent or acquiescence by ICANN to an introduction by Registry
Operator of a service employing a universal wildcard function. To the extent that traffic
data subject to this provision is made available, access shall be on terms that are
nondiscriminatory.

3.1 (g) Cooperation. The parties agree to cooperate with each other and share data as
necessary to accomplish the terms of this Agreement.

Section 3.2 Covenants of ICANN. ICANN covenants and agrees with Registry Operator as follows:

3.2 (a) Open and Transparent. Consistent with ICANN’s expressed mission and core values,
ICANN shall operate in an open and transparent manner.

3.2 (b) Equitable Treatment. ICANN shall not apply standards, policies, procedures or
practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry
Operator for disparate treatment unless justified by substantial and reasonable cause.

3.2 (c) TLD Zone Servers. In the event and to the extent that ICANN is authorized to set
policy with regard to an authoritative root server system, it will use best efforts to ensure
that (i) the authoritative root will point to the TLD zone servers designated by Registry
Operator for the Registry TLD throughout the Term of this Agreement; and (ii) any changes to
the TLD zone server designation submitted to ICANN by Registry Operator will be implemented
by ICANN within seven days of submission.

3.2 (d) Nameserver Changes. Registry Operator may request changes in the nameserver
delegation for the Registry TLD. Any such request must be made in a format, and otherwise
meet technical requirements, specified from time to time by ICANN. ICANN will use
commercially reasonable efforts to have such requests

 

 

implemented in the Authoritative Root-Server System within seven calendar days of the
submission.

3.2 (e) Root-zone Information Publication. ICANN’s publication of root-zone contact
information for the Registry TLD will include Registry Operator and its administrative and
technical contacts. Any request to modify the contact information for the Registry Operator
must be made in the format specified from time to time by ICANN.

ARTICLE 4 TERM OF AGREEMENT

Section 4.1 Term. The initial term of this Agreement shall expire on December 31, 2012, the
“Expiration Date,” as extended by any renewal terms.

Section 4.2 Renewal. This Agreement shall be renewed upon the expiration of the term set forth in
Section 4.1 above and each later term, unless the following has occurred: (i) following notice of
breach to Registry Operator in accordance with Section 6.1 and failure to cure such breach within
the time period prescribed in Section 6.1, an arbitrator or court has determined that Registry
Operator has been in fundamental and material breach of Registry Operator’s obligations set forth
in Sections 3.1(a), (b), (d) or (e); Section 5.2 and (ii) following the final decision of such
arbitrator or court, Registry Operator has failed to comply within ten days with the decision of
the arbitrator or court, or within such other time period as may be prescribed by the arbitrator or
court. Upon renewal, in the event that the terms of this Agreement are not similar to the terms
generally in effect in the Registry Agreements of the 5 most reasonably comparable gTLDs (provided
however that if less than five gTLDs are reasonably comparable, then comparison shall be made with
such lesser number, and .com, info, .net and .org are hereby deemed comparable), renewal shall be
upon terms reasonably necessary to render the terms of this Agreement similar to such terms in the
Registry Agreements for those other gTLDs. The preceding sentence, however, shall not apply to the
terms of this Agreement regarding the standards for the consideration of proposed Registry
Services, including the definitions of Security and Stability and the standards applied by ICANN in
the consideration process; the terms or conditions for the renewal or termination of this
Agreement; ICANN’s obligation to Registry Operator under Section 3.2(a), (b) and (c); the
limitations on Consensus Policies or Temporary Specifications or Policies; or the definition of
Registry Services. In addition, upon renewal, registry fees payable to ICANN may be reasonably
modified so long as any increase in such fees shall not exceed the average of the percentage
increase in registry fees for the five most reasonably comparable TLDs (or such lesser number as
provided above) during the prior three year period;

Section 4.3 Changes. While this Agreement is in effect, the parties agree to engage in good faith
negotiations at regular intervals (at least once every three calendar years following the Effective
Date) regarding possible changes to the terms of the Agreement, including to Section 7.2 regarding
fees and payments to ICANN. In addition, ICANN shall consider and discuss with Registry Operator
other appropriate changes to pricing and related terms under the Agreement in the event ICANN shall
obtain further independent data from professional experts providing analysis of the pricing of
domain name registrations and competitive market considerations. The failure by Registry Operator
to agree to an increase in registry fees or other terms shall not constitute a violation of this
provision.

Section 4.4 Failure to Perform in Good Faith. In the event Registry Operator shall have been
repeatedly and willfully in fundamental and material breach of Registry Operator’s obligations set
forth in Sections 3.1(a), (b), (d) or (e); Section 5.2, and arbitrators in accordance with Section
5.1(b) of this Agreement repeatedly have found Registry Operator to have been in fundamental and
material breach of this Agreement, including in at least three separate awards,

 

 

then the arbitrators shall award such punitive, exemplary or other damages as they may believe
appropriate under the circumstances.

ARTICLE 5 DISPUTE RESOLUTION

Section 5.1
Resolution of Disputes.

5.1
(a) Cooperative Engagement. In the event of a disagreement between Registry Operator and
ICANN arising under or out of this Agreement, either party may by notice to the other invoke
the dispute resolution provisions of this Article V. Provided, however, that before either
party may initiate arbitration as provided in Section 5.1(b) below, ICANN and Registry
Operator must attempt to resolve the dispute by cooperative engagement as set forth in this
Section 5.1(a). If either party provides written notice to the other demanding cooperative
engagement as set forth in this Section 5.1(a), then each party will, within seven calendar
days after such written notice is deemed received in accordance with Section 8.6 hereof,
designate a single executive officer as its representative under this Section 5.1(a) with
full authority to act on such party’s behalf to resolve the dispute. The designated
representatives shall, within 2 business days after being designated, confer by telephone or
in person to attempt to resolve the dispute. If they are not able to resolve the dispute
during such telephone conference or meeting, they shall further meet in person at a location
reasonably designated by ICANN within 7 calendar days after such initial telephone conference
or meeting, at which meeting the parties shall attempt to reach a definitive resolution. The
time schedule and process set forth in this Section 5.1(a) may be modified with respect to
any dispute, but only if both parties agree to a revised time schedule or process in writing
in advance. Settlement communications within the scope of this paragraph shall be
inadmissible in any arbitration or litigation between the parties.

5.1
(b) Arbitration. Disputes arising under or in connection with this Agreement, including
requests for specific performance, shall be resolved through binding arbitration conducted as
provided in this Section 5.1(b) pursuant to the rules of the International Court of
Arbitration of the International Chamber of Commerce (“ICC”). The arbitration shall be
conducted in the English language and shall occur in Los Angeles County, California, USA only
following the failure to resolve the dispute pursuant to cooperative engagement discussions
as set forth in Section 5.1(a) above. There shall be three arbitrators: each party shall
choose one arbitrator and, if the two arbitrators are not able to agree on a third
arbitrator, the third shall be chosen by the ICC. The prevailing party in the arbitration
shall have the right to recover its costs and reasonable attorneys’ fees, which the
arbitrators shall include in their awards. Any party that seeks to confirm or vacate an
arbitration award issued under this Section 5.1(b) may do so only pursuant to the applicable
arbitration statutes. In any litigation involving ICANN concerning this Agreement,
jurisdiction and exclusive venue for such litigation shall be in a court located in Los
Angeles County, California, USA; however, the parties shall also have the right to enforce a
judgment of such a court in any court of competent jurisdiction. For the purpose of aiding
the arbitration and/or preserving the rights of the parties during the pendency of
arbitration, the parties shall have the right to seek a temporary stay or injunctive relief
from the arbitration panel or a court, which shall not be a waiver of this agreement to
arbitrate.

Section 5.2
Specific Performance. Registry Operator and ICANN agree that irreparable damage could
occur if any of the provisions of this Agreement was not performed in accordance

 

 

with its specific terms. Accordingly, the parties agree that they each shall be entitled to
seek from the arbitrators specific performance of the terms of this Agreement (in addition to any
other remedy to which each party is entitled).

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

ARTICLE 6 TERMINATION PROVISIONS

Section 6.1
Termination by ICANN. ICANN may terminate this Agreement if and only if: (i) Registry
Operator fails to cure any fundamental and material breach of Registry Operator’s obligations set
forth in Sections 3.1(a), (b), (d) or (e); or Section 5.2 within thirty (30) calendar days after
ICANN gives Registry Operator written notice of the breach, which notice shall include with
specificity the details of the alleged breach; and (ii) (a) an arbitrator or court has finally
determined that Registry Operator is, or was, in fundamental and material breach and failed to cure
such breach within the prescribed time period and (b) following the decision of such arbitrator or
court, Registry Operator has failed to comply with the decision of the arbitrator or court.

Section 6.2
Bankruptcy. This Agreement shall automatically terminate in the event Registry Operator
shall voluntarily or involuntarily be subject to bankruptcy proceedings.

Section 6.3
Transition of Registry upon Termination of Agreement. Upon any termination of this
Agreement as provided in Sections 6.1 and 6.2, the parties agree to work cooperatively to
facilitate and implement the transition of the registry for the TLD in accordance with this Section
6.3. Registry Operator shall agree to provide ICANN or any successor registry authority that may be
designated for the TLD with any data regarding operations of the registry for the TLD necessary to
maintain operations that may be reasonably requested in addition to that data escrowed in
accordance with Section 3.1(c)(i) hereof.

Section 6.4
Rights in Data. Registry Operator shall not be entitled to claim any intellectual
property rights in Registry Data. In the event that Registry Data is released from escrow as set
forth in Section 3.1(c)(i), rights, if any, held by Registry Operator in the data shall
automatically be licensed on a non-exclusive, irrevocable, royalty-free, paid-up basis to ICANN or
to a party designated in writing by ICANN.

Section 6.5
No Reimbursement. Any and all expenditures, capital investments or other investments
made by Registry Operator in connection with this Agreement shall be at Registry Operator’s own
risk and ICANN shall have no obligation to reimburse Registry Operator for any such expense,
capital expenditure or investment. Registry Operator shall not be required to

 

 

make any payments to a successor registry operator by reason of registry fees paid to Registry
Operator prior to the effective date of (i) any termination or expiration of this Agreement or (ii)
transition of the registry, unless any delay in transition of the registry to a successor operator
shall be due to the actions of Registry Operator.

ARTICLE 7 SPECIAL PROVISIONS

Section 7.1
Registry-Registrar Agreement.

7.1
(a) Access to Registry Services. Registry Operator shall make access to Registry
Services, including the shared registration system, available to all ICANN-accredited
registrars, subject to the terms of the Registry-Registrar Agreement attached as Appendix 8
hereto. Registry Operator shall provide all ICANN-accredited registrars following execution
of the Registry-Registrar Agreement, provided registrars are in compliance with such
agreement, operational access to Registry Services, including the shared registration system
for the TLD. Such nondiscriminatory access shall include without limitation the following:

7.1 (a)(i) All registrars (including any registrar affiliated with Registry Operator,
if any) can connect to the shared registration system gateway for the TLD via the
Internet by utilizing the same maximum number of IP addresses and SSL certificate
authentication;

7.1 (a)(ii) Registry Operator has made the current version of the registrar toolkit
software accessible to all registrars and has made any updates available to all
registrars on the same schedule;

7.1 (a)(iii) All registrars have equivalent access to customer support personnel via
telephone, e-mail and Registry Operator’s website;

7.1 (a)(iv) All registrars have equivalent access to registry resources to resolve
registry/registrar or registrar/registrar disputes and technical and/or administrative
customer service issues;

7.1 (a)(v) All registrars have equivalent access to data generated by Registry
Operator to reconcile their registration activities from Registry Operator’s Web and
ftp servers;

7.1 (a)(vi) All registrars may perform basic automated registrar account management
functions using the same registrar tool made available to all registrars by Registry
Operator; and

7.1 (a)(vii) The shared registration system does not include, for purposes of
providing discriminatory access, any algorithms or protocols that differentiate among
registrars with respect to functionality, including database access, system priorities
and overall performance.

7.1 (a)(viii) Such Registry-Registrar Agreement may be revised by Registry Operator
from time to time, provided however, that any such revisions must be approved in
advance by ICANN.

7.1
(b) Registry Operator Shall Not Act as Own Registrar. Registry Operator shall

 

 

not act as a registrar with respect to the TLD. This shall not preclude Registry Operator
from registering names within the TLD to itself through a request made to an ICANN-accredited
registrar.

7.1
(c) Restrictions on Acquisition of Ownership or Controlling
Interest in Registrar.
Registry Operator shall not acquire, directly or indirectly, control of, or a greater than
fifteen percent ownership interest in, any ICANN-accredited registrar.

Section 7.2
Fees to be Paid to ICANN.

7.2
(a) Registry-Level Transaction Fee.

7.2 (a)(i) Commencing on January 1, 2007, Registry Operator shall pay ICANN a
Registry-Level Fee. Subject to Sections 7.2(a)(ii) and (iii) below, such fee shall
equal the Transaction Fee set forth in the table below multiplied by the number of
annual increments of an initial or renewal domain name registration (including
renewals associated with transfers from one ICANN-accredited registrar to another)
during the applicable calendar quarter:

	 	 	 
	YEAR	 	TRANSACTION FEE
	2007
	 	US$0.15
	 
	 	 
	2008
	 	US$0.15
	 
	 	 
	2009
	 	US$0.20
	 
	 	 
	2010
	 	US$0.20
	 
	 	 
	2011
	 	US$0.25
	 
	 	 
	2012
	 	US$0.25

7.2 (a)(ii) Commencing in 2009, for calendar quarters during the Term for which the
average annual price of registrations during the quarter is between US$3.01 and
US$4.99, the Registry-Level Fee shall be the lesser of (a) the transaction fee
provided in 7.2.a.1 or (b) US$0.15 plus US $0.01 for each increase by US$0.20 above
$3.01 in the average price of domain name registrations, multiplied by the number of
annual increments of an initial or renewal domain name registration during such
quarter (including renewals associated with transfers from one ICANN-accredited
registrar to another); and

7.2 (a)(iii) Following two consecutive calendar quarters during which the average
annual price of registrations during the quarter is US$3.00 or less (disregarding for
these purposes any registry-offered discounts or marketing incentives having the short
term effect of lowering the average annual price of domain name registrations),
Registry Operator may request the parties enter good-faith negotiations to review and
renegotiate the fee obligation considering all relevant factors including but not
limited to Registry Operator’s business needs as well as ICANN’s financial requirements.

 

 

7.2
(b) Payment Schedule. Registry Operator shall pay the Registry-Level Fees specified in
Section 7.2(a) and Section 7.2(c), if applicable, by the 20th day following the
end of each calendar quarter (i.e., on April 20, July 20, October 20 and January 20 for the
calendar quarters ending March 31, June 30, September 30 and December 31) of the year to an
account designated by ICANN.

7.2
(c) Variable Registry-Level Fee. For fiscal quarters in which ICANN does not collect a
variable accreditation fee from all registrars, upon receipt of written notice from ICANN,
Registry Operator shall pay ICANN a Variable Registry-Level Fee. The fee will be calculated
by ICANN, paid to ICANN by the Registry Operator in accordance with the Payment Schedule in
Section 7.2(b), and the Registry Operator will invoice and collect the fees from the
registrars who are party to a Registry-Registrar Agreement with Registry Operator. The fee
will consist of two components; each component will be calculated by ICANN for each
registrar:

7.2 (c)(i) The transactional component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year but shall not exceed US $0.25.

7.2 (c)(ii) The per-registrar component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year, but the sum of the per- registrar fees calculated for
all registrars shall not exceed the total Per- Registrar Variable funding established
pursuant to the approved 2004- 2005 ICANN Budget.

Provided, however, that Registry Operator shall only be required to pay the
fees set forth in paragraph (c) above, in the event that ICANN elects to
collect the Variable Registry-Level Fee from all ICANN-Accredited
Registrars. For the avoidance of doubt, Registry Operator shall not be
required to collect the per-registrar component of the Variable
Registry-Level Fee from any registrar unless it is required to do so for all
registrars.

7.2
(d) Interest on Late Payments. For any payments pursuant to Section 7.2(a) thirty days or
more overdue past the time period for payment set forth in Section 7.2 (b), Registry Operator
shall pay interest on late payments at the rate of 1.5% per month or, if less, the maximum
rate permitted by applicable law. Registry Operator shall not be required to pay interest on
late payments under Section 7.2(c), provided that Registry Operator is in good faith making
reasonably diligent efforts to collect the underlying payments from those registrars party to
a Registry-Registrar Agreement with Registry Operator.

Section 7.3.
Pricing for Domain Name Registrations and Registry Services.

(a) Pricing. From the Effective Date through six (6) months following the Effective Date, the price
to ICANN-accredited registrars for new and renewal domain name registrations and for transferring a
domain name registration from one ICANN-accredited registrar to another, shall

 

 

not exceed a total fee of US$6.00 (the “Maximum Service Fee”). Commencing on 1 January 2007, the
Maximum Service Fee charged during a calendar year for each annual increment of a new and renewal
domain name registration and for transferring a domain name registration from one ICANN-accredited
registrar to another, may not exceed the Maximum Service Fee during the preceding calendar year
multiplied by 1.10. The same Service Fee shall be charged to all ICANN-accredited registrars for
new and renewal domain name registrations. Volume discounts and marketing support and incentive
programs may be made if the same opportunities to qualify for those discounts and marketing support
and incentive programs is available to all ICANN-accredited registrars.

(b) Adjustments
to Pricing for Domain Name Registrations. Registry Operator shall provide no less
than six months prior notice in advance of any price increase for domain name registrations and
shall continue to offer domain name registrations for periods of up to ten years. Registry Operator
is not required to give notice of the imposition of the Variable Registry-Level Fee set forth in
Section 7.2(c).

ARTICLE 8 MISCELLANEOUS

Section 8.1
Indemnification of ICANN.

8.1 (a) Registry Operator shall indemnify, defend, and hold harmless ICANN (including its
directors, officers, employees, and agents) from and against any and all third-party claims,
damages, liabilities, costs, and expenses, including reasonable legal fees and expenses,
arising out of or relating to: (a) ICANN’s reliance, in connection with its decision to
delegate the TLD to Registry Operator or to enter into this Agreement, on information
provided by Registry Operator in its application for the TLD; (b) Registry Operator’s
establishment or operation of the registry for the TLD; (c) Registry Operator’s provision of
Registry Services; (d) collection or handling of Personal Data by Registry Operator; (e) any
dispute concerning registration of a domain name within the domain of the TLD for the
registry; and (f) duties and obligations of Registry Operator in operating the registry for
the TLD; provided that Registry Operator shall not be obligated to indemnify, defend, or hold
harmless ICANN to the extent the claim, damage, liability, cost, or expense arose due to a
breach by ICANN of any obligation contained in this Agreement. For avoidance of doubt,
nothing in this Section 8.1 shall be deemed to require Registry Operator to reimburse or
otherwise indemnify ICANN for the costs associated with the negotiation or execution of this
Agreement, or with the monitoring or management of the parties’ respective obligations under
this Agreement. Further, this section shall not apply to any request for attorney’s fees in
connection with any litigation or arbitration between or among the parties.

8.1 (b) For any claims by ICANN for indemnification whereby multiple registry operators
(including Registry Operator) have engaged in the actions or omissions that gave rise to the
claim, Registry Operator’s aggregate liability to indemnify ICANN with respect to such claim
shall be limited to a percentage of ICANN’s total claim, calculated by dividing the number of
total domain names under registration with Registry Operator within the TLD (which names
under registration shall be calculated consistently with Section 7.2 hereof for any
applicable quarter) by the total number of domain names under registration within all TLDs
for which the registry operators thereof that are engaging in the same acts or omissions
giving rise to such claim. For the avoidance of doubt, in the event that a registry operator
is engaged in the same acts or omissions giving rise to the claims above, but such registry
operator(s) do not have the same or similar indemnification obligations to

 

 

ICANN at set forth in 8.1(a) above, the number of domains under management by such registry
operator(s) shall nonetheless be included in the calculation in the preceding sentence.

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

Section 8.3
No Offset. All payments due under this Agreement shall be made in a timely manner
throughout the term of this Agreement and notwithstanding the pendency of any dispute (monetary or
otherwise) between Registry Operator and ICANN.

Section 8.4
Use of ICANN Name and Logo. ICANN grants to Registry Operator a non-exclusive
royalty-free license to state that it is designated by ICANN as the Registry Operator for the
Registry TLD and to use a logo specified by ICANN to signify that Registry Operator is an
ICANN-designated registry authority. This license may not be assigned or sublicensed by Registry
Operator.

Section 8.5
Assignment and Subcontracting. Any assignment of this Agreement shall be effective only
upon written agreement by the assignee with the other party to assume the assigning party’s
obligations under this Agreement. Moreover, neither party may assign this Agreement without the
prior written approval of the other party, which approval shall not be unreasonably withheld.
Notwithstanding the foregoing, ICANN may assign this Agreement (i) in conjunction with a
reorganization or re-incorporation of ICANN, to another nonprofit corporation organized for the
same or substantially the same purposes, or (ii) as may be required pursuant to the terms of that
certain Memorandum of Understanding between ICANN and the U.S. Department of Commerce, as the same
may be amended from time to time. Registry Operator must provide notice to ICANN of any
subcontracting arrangements, and any agreement to subcontract portions of the operations of the TLD
must mandate compliance with all covenants, obligations and agreements by Registry Operator
hereunder. Any subcontracting of technical operations shall provide that the subcontracted entity
become party to the data escrow agreement mandated by Section 3.1(c)(i) hereof.

Section 8.6
Amendments and Waivers. No amendment, supplement, or modification of this Agreement or
any provision hereof shall be binding unless executed in writing by both parties. No waiver of any
provision of this Agreement shall be binding unless evidenced by a writing signed by the party
waiving compliance with such provision. No waiver of any of the provisions of this Agreement or
failure to enforce any of the provisions hereof shall be deemed or shall

 

 

constitute a waiver of any other provision hereof, nor shall any such waiver constitute a
continuing waiver unless otherwise expressly provided.

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

Section 8.8
Notices, Designations, and Specifications. All notices to be given under or in relation
to this Agreement shall be given either (i) in writing at the address of the appropriate party as
set forth below or (ii) via facsimile or electronic mail as provided below, unless that party has
given a notice of change of postal or email address, or facsimile number, as provided in this
agreement. Any change in the contact information for notice below shall be given by the party
within 30 days of such change. Any notice required by this Agreement shall be deemed to have been
properly given (i) if in paper form, when delivered in person or via courier service with
confirmation of receipt or (ii) if via facsimile or by electronic mail, upon confirmation of
receipt by the recipient’s facsimile machine or email server. Whenever this Agreement shall specify
a URL address for certain information, Registry Operator shall be deemed to have been given notice
of any such information when electronically posted at the designated URL. In the event other means
of notice shall become practically achievable, such as notice via a secure website, the parties
shall work together to implement such notice means under this Agreement.

If to ICANN, addressed to:

Internet Corporation for Assigned Names and Numbers

4676 Admiralty Way, Suite 330

Marina Del Rey, California 90292

Telephone: 1-310-823-9358

Facsimile: 1-310-823-8649

Attention: President and CEO

With a Required Copy to: General Counsel

Email: (As specified from time to time.)

If to Registry Operator, addressed to:

NeuStar, Inc.

46000 Center Oak Plaza

Sterling, VA 20166

Telephone: 1-571-434-5400

Facsimile: 1-571-434-5735

Attention: Sr. Director, Law, Advanced Services and Business Development

NeuStar, Inc.

With a Required Copy to: General Counsel

Email: (As specified from time to time.)

Section 8.9
Language. Notices, designations, determinations, and specifications made under this
Agreement shall be in the English language.

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

Section 8.11
Entire Agreement. This Agreement (including its Appendices, which form a part of it)
constitutes the entire agreement of the parties hereto pertaining to the operation of the TLD and
supersedes all prior agreements, understandings, negotiations and discussions, whether oral or
written, between the parties on that subject. In the event of a conflict between the

 

 

provisions in the body of this Agreement and any provision in its Appendices, the provisions
in the body of the Agreement shall control.

[signature page follows]

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

     INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

	 	 	 	 	 
	 	 	 
	 	By:  	/s/
Dr. Paul Twomey
 	 
	 	 	Dr. Paul Twomey 	 
	 	 	President and CEO 	   
	   	Date: 

     NEUSTAR, INC.

	 	 	 	 	 
	 	 	 
	 	By:  	/s/ Richard Tindal
	 
	 	 	Richard Tindal 	 
	 	 	Vice President 	 
	   	Date: 12/19/06

Source: [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00118-of-00352.parquet"}, [{"source": "alea-institute/alea-institute/kl3m-data-edgar-agreements/train-00118-of-00352.parquet"}]]