SEC Info℠ | Home | Search | My Interests | Help | Sign In | Please Sign In | ||||||||||||||||||||
As Of Filer Filing For·On·As Docs:Size Issuer Agent 6/28/05 Neustar Inc S-1/A 14:31M Merrill Corp/New/FA |
Document/Exhibit Description Pages Size 1: S-1/A Pre-Effective Amendment to Registration Statement HTML 1.47M (General Form) 2: EX-1.1 Underwriting Agreement HTML 163K 3: EX-3.1 Articles of Incorporation/Organization or By-Laws HTML 92K 4: EX-3.2 Articles of Incorporation/Organization or By-Laws HTML 70K 5: EX-4.1 Instrument Defining the Rights of Security Holders HTML 15K 6: EX-4.2 Instrument Defining the Rights of Security Holders HTML 15K 7: EX-5.1 Opinion re: Legality HTML 13K 8: EX-9.1 Voting Trust Agreement HTML 110K 9: EX-10.1 Material Contract HTML 12.06M 10: EX-10.4 Material Contract HTML 4.97M 11: EX-10.5 Material Contract HTML 2.37M 12: EX-10.7 Material Contract HTML 260K 13: EX-21.1 Subsidiaries of the Registrant HTML 9K 14: EX-23.1 Consent of Experts or Counsel HTML 10K
Exhibit 10.5
ORDER FOR SUPPLIES OR SERVICES
1. | DATE OF ORDER | 26 Oct. 2001 | ||
2. |
CONTRACT NO. (if any) |
|||
3. |
ORDER NO. |
SB1335-02-W-0175 |
||
4. |
REQUISITION/REFERENCE NO. |
01-909-0066 |
||
5. |
ISSUING OFFICE (address correspondence to: 000SB |
NIST 100 BUREAU DRIVE STOP 3571 BUILDING 301 ROOM B129 GAITHERSBURG, MD 20899-3571 WIDDUP, JOSEPH (301-975-6324 |
||
6. |
SHIP TO: |
SCHED |
||
a. Name of Consignee |
SEE SCHEDULE BELOW |
|||
b. Street Address |
||||
c. City |
||||
d. State |
||||
e. Zip Code |
||||
f. Ship VIA |
||||
7. |
TO: |
0007158 |
||
TIN: |
522141938 |
|||
a. Name of Contractor |
NEUSTAR |
|||
b. Company Name |
||||
c. Street Address |
1120 VERMONT AVENUE NW Suite 400 |
|||
d. City |
Washington |
|||
e. State |
DC |
|||
f. Zip |
20005 |
|||
8. |
TYPE OF ORDER |
|||
a. /x/ Purchase |
REFERENCE YOUR: Quotation Dated July 27, 2001 Please furnish the following terms and conditions specified on both sides of this order and on the attached sheet, if any, including delivery as indicated. |
|||
b. / / Delivery |
Except for billing instructions on the reverse, this delivery order is subject to instructions contained on this side only of this form and is issued subject to the terms and conditions of the above-referenced contract. |
|||
9. |
ACCOUNTING AND APPROPRIATION |
See Attached Schedule |
||
BOC: |
$0.00 |
|||
OBLIGATED AMT: |
||||
10. |
REQUISITIONING OFFICE |
NTIA 909.00 |
||
11. |
ACCOUNTING CLASSIFICATION |
/ / a. Small |
||
(check appropriate box(es)) |
/x/ b. Other Than Small |
|||
/ / c. Disadvantaged |
||||
/ / d. Women-Owned |
||||
12. |
F.O.B. POINT |
See Schedule |
||
13. |
PLACE OF |
|||
a. Inspection |
Destination |
|||
b. Acceptance |
Destination |
|||
14. |
GOVERNMENT B/L/ NO. |
|||
15. |
DELIVER TO F.O.B. POINT ON OR BEFORE |
25 Oct 2005 |
||
16. |
DISCOUNT TERMS |
00.00% 0 Days |
||
Net 0 |
||||
17. |
SCHEDULE (seer reverse for Projections) |
2
Item No. (a) |
Supplies or Services (b) |
Quantity Ordered (c) |
Unit (d) |
Unit Price (e) |
Amount (f) |
Qty Accept. (g) |
||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
The Contractor's quotation dated July 27, 2001 is hereby incorporated by reference into this purchase order as though it were included in full text. In the event of an inconsistency between the provisions of this Purchase Order and the Contractor's quotation, the inconsistency shall be resolved by giving precedence in the following order: i) the Purchase Order (excluding the Contractor's | ||||||||||||
Account and Appropriation Data: 00.00.00.0000000000.0000000000. 000.00000000000000.0000000000 |
||||||||||||
BOC: 27800 |
||||||||||||
002 |
Option Period One The Contractor must perform the services required by the SOW Period of Performance: 365 days, beginning the day after the Base Period expires |
|||||||||||
Account and Appropriation Data: 00.00.00.0000000000.0000000000. 000.00000000000000.0000000000 |
||||||||||||
BOC: 27800 |
3
Attn:
Joseph L. Widdup
National Institute of Standards and Technology
100 Bureau Dr. Stop 3571
Bldg. 301 Room B129
Gaithersburg, MD 20899-3571
M/F Solicitation SB1335-01-Q-0740
Dear Mr. Widdup:
We are pleased to submit the attached proposal in response to the National Institute of Standards and Technology's Request for Quotation (RFQ) (Solicitation Number SB1335-01-Q-0740) on behalf of the U. S. Department of Commerce's National Telecommunications and Information Administration for Centralized Management and Coordination of Registry, Registrar, Database, and Information Services for the usTLD.
As our proposal demonstrates, we offer the Department of Commerce a truly neutral vendor who is qualified to perform the required roles and responsibilities set forth in the Statement of Work in the Request for Quotation.
The solution we propose will demonstrate that NeuStar has:
As requested, we have provided an original version and two copies of our response to the RFQ. The proposal is organized in accordance with the Instructions for Submitting Quotations, and Amendment 1, Question 15. Following this letter of transmittal is the RFQ Transmittal Form, NeuStar's signed Acknowledgment of Amendment 0001 (June 16, 2001), Amendment 0002 (June 17, 2001), and Amendment 0003 (July 23, 2001). NeuStar submits this response as "Confidential and Proprietary Information" and has indicated so in the left hand corner of each page. NeuStar understands this to mean, all information received in response to this solicitation will be considered confidential and proprietary information and will be treated as such, as cited in SB1335-01-Q-0740 Amendment 0001, Question 5.
While I am the negotiator for this proposal and am authorized to bind the Corporation to any contract resulting herefrom, should you have any questions regarding our proposal, please contact Ken Hansen at 202.533.2685, via fax at 202.533.2975, or via e-mail at Ken.hansen@neustar.com.
We look forward to working with the DOC and NTIA to ensure the successful enhancement and expansion of the usTLD.
Sincerely,
Robert
Poulin
Vice President, Corporate Development
NeuStar, Inc.
Enclosures
4
REQUEST FOR QUOTATION (THIS IS NOT AN ORDER) |
This RFQ o is ý is not a small Business set-aside |
||||||||||
1. REQUEST NO SB1335-01-Q-0740 |
2. DATE ISSUED Jun 12, 2001 |
3. REQUISITION/PURCHASE REQ NO. 01-909-0066 |
4. CERT FOR NAT. DEF. UNDER BDSA REG 2 AND/OR DMS REQ. 1 |
RATING |
|||||||
5a. ISSUED BY |
6. DELIVERY BY (Date) |
||||||||||
NATIONAL INST OF STDS AND TECHNOLOGY 100 BUREAU DRIVE STOP 3572 CONTRACTS BUILDING 301 ROOM B117 GAITHERSBURG MD 20899-3572 |
7. DELIVERY o FOB Destination ý Other (See Schedule) |
||||||||||
5b. FOR MORE INFORMATION CALL (No Collect Calls) |
9. DESTINATION SCHED |
||||||||||
NAME |
Area Code |
Telephone |
a. NAME OF CONSIGNEE |
||||||||
WIDDUP, JOSEPH | 061 | 301 | 975-6324 | SEE SCHEDULE BELOW | |||||||
8. TO |
b. STREET ADDRESS |
||||||||||
a. NAME |
b. COMPANY |
||||||||||
Robert Poulin | NeuStar, Inc. | ||||||||||
c. STREET ADDRESS |
|||||||||||
1120 Vermont Avenue, NW Suite 400 |
|||||||||||
d. CITY |
e. STATE |
f. ZIP CODE |
d. STATE |
e. ZIP CODE |
|||||||
Washington | DC | 20005 | |||||||||
10. PLEASE FURNISH QUOTATIONS TO THE ISSUING OFFICE IN BLOCK 5A ON OR BEFORE CLOSE OF BUSINESS (DATE) Jul 27, 2001 |
IMPORTANT: This is a request for information and quotations furnished are not offers. If you are unable to quote, please so indicate on this form and return it to the address in Block 5A. This request does not commit the Government to pay any costs incurred in the the submission of this quotation or to contract for supplies or services. Supplies are of domestic origin unless otherwise indicated by Any representations and/or certifications to this Request for Quotations must be completed by the quoter. |
||||||||||
11. SCHEDULE (Indicate applicable Federal, State and local taxes) |
|||||||||||
ITEM NO. (a) |
SUPPLIES/SERVICES (b) |
QUANTITY (c) |
UNIT (d) |
UNIT PRICE (f) |
AMOUNT (f) |
|||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
0001 | The Contractor must perform the services required by the SOW Period of Performance: Base Period (4 years, beginning on the date of purchase order award) | 4 | YR | $ | 0.00 | $ | 0.00 | |||||
0002 | The Contractor must perform the services required by the SOW Period of Performance: Option Period One (365 days, beginning the day after the Base Year expires) | 1 | YR | $ | 0.00 | $ | 0.00 | |||||
0003 | The Contractor must perform the services required by the SOW Period of Performance: Option Period Two (365 days, beginning the day after the Base Year expires) | 1 | YR | $ | 0.00 | $ | 0.00 |
12. DISCOUNT FOR PROMPT PAYMENT |
a. 10 Calendar Days (%) |
b. 20 Calendar Days (%) |
c. 30 Calendar Days (%) |
D. CALENDAR DAYS |
||||||
NUMBER |
PERCENTAGE |
|||||||||
NOTE: Additional provisions and representations ý are o are not attached. |
||||||||||
13. NAME AND ADDRESS OF QUOTER |
14. SIGNATURE OF PERSON AUTHORIZED TO SIGN QUOTATION |
15. DATE OF QUOTATION |
||||||||
a. NAME OF QUOTER |
||||||||||
NeuStar, Inc. | DUNS-11-240-3295 | |||||||||
b. STREET ADDRESS |
16. SIGNER |
|||||||||
1120 Vermont Avenue, NW, Suite 400 | a. NAME (Type or print) | b. TELEPHONE | ||||||||
c. COUNTY |
Robert Poulin |
AREA CODE 202 |
||||||||
d. CITY |
e. STATE |
f. ZIP CODE |
c. TITLE (Type or print) |
NUMBER |
||||||
Washington | DC | 20005 | Vice President | 533.2680 | ||||||
AUTHORIZED FOR LOCAL REPRODUCTION |
STANDARD FORM 18 (Rev. 6/95) |
5
The Contractor must furnish the necessary personnel, material, equipment, services, and facilities (except as otherwise specified) to perform the requirements stated in this SOW.
A. INTRODUCTION
The.us domain ("usTLD") is the country code top level domain ("ccTLD") of the Internet domain name system ("DNS") that corresponds to the United States. Currently, second-level domain space in.us is designated for states and U.S. territories and special purposes as described in the Internet Engineering Task Force's ("IETF") RFC 1480 (titled The US Domainhttp://www.ietf.org/rfc/rfc1480.txt?number=1480) ("RFC 1480"), and is further subdivided into localities and other functional designations.
Individuals and organizations may currently request a delegation from the usTLD Administrator to provide registry and registrar services for a particular locality or localities. Local governments and community-based organizations typically use the usTLD, although some commercial names have been assigned. Where registration for a locality has not been delegated, the usTLD Administrator itself provides necessary registry and registrar services. Information on the locality-based usTLD structure and registration policies is available for review at: http://www.nic.us
The usTLD is a widely distributed registry, currently with over 8000 sub-domain delegations to over 800 individuals and entities, who maintain a registry and provide registration services for commercial, educational, and governmental entities. This distributed registration model affords scalable registration services and opportunities for organizations and commercial entities to provide name registration services. For purposes of this acquisition, we will refer to the current.us name space and structure, including its non-locality, functional elements, as the "locality-based usTLD structure."
While the locality-based usTLD structure has not attracted high levels of registration and utilization in comparison to other ccTLD's, it is popular with its current base of users. During consultations with the public on the administration of the usTLD, a considerable number of parties expressed a desire for the continued operation and support of the locality-based usTLD structure. The Contractor will be required to maintain and improve the management of the current usTLD space.
Because of its deeply hierarchical and somewhat cumbersome structure, the usTLD has not been used on a wide scale. The general absence of less hierarchical registration opportunities in the usTLD has limited the domain's attractiveness to users. It has been suggested that this more "generic" space would greatly increase the utility of the usTLD. Therefore, this acquisition also encompasses functions that will allow, on a competitive basis, for the registration of second level domains directly under usTLD (such as example.us).
A number of technical enhancements to the usTLD system functions are required to make the system more robust and reliable. Because the usTLD has operated for the most part on a delegated basis for a number of years, the availability of centralized contact information for the usTLD has proven difficult to maintain. For example, RFC 1480 advises but does not require that the administrator of a delegated sub-domain operate a database of accurate and up-to-date registration information ("WHOIS") service. As described in section above, "locality-based usTLD structure" in this acquisition refers to the current usTLD space (as described in RFC 1480), including those limited non-locality, functional designations.
Notwithstanding the fact that some of the administrative responsibilities for the locality-based usTLD structure require the registry to act as a registrar in certain limited circumstances, in order to encourage competition in domain name registration services, the Contractor will not be permitted to act as both the registry and a registrar in the expanded usTLD space. Further, the Contractor will be
6
required to perform a core set of usTLD registry functions, as described in the Contractor Requirements section below.
On August 4, 1998, the United States Department of Commerce ("DOC"), through DOC's National Telecommunications and Information Administration ("NTIA"), solicited comments addressing the future expansion and administration of the usTLD space. On March 9, 1999, NTIA hosted a public meeting regarding the future management and administration of the.us domain with approximately sixty participants, including the current usTLD Administrator, current.us registrars, educators, representatives of the technical, public interest and business communities, and federal, state and foreign government officials. NTIA also established an open electronic mailing list to facilitate further public discussions of the issues. On August 17, 2000, NTIA requested comments on a draft SOW for this acquisition. Comments received by NTIA were reviewed and considered by NTIA in connection with preparation of this SOW.
This acquisition is being conducted in accordance with Federal Acquisition Regulation (FAR) Part 13, Simplified Acquisition Procedures.
B. CONTRACTOR REQUIREMENTS
The Contractor must perform the required services for this acquisition as a prime Contractor, not as an agent or subcontractor. (The provision of the required services may be accomplished through coordinating the resources and services provided by entities other than the prime Contractor.) The Contractor must be (a) incorporated within one of the fifty states of the United States of America or the District of Columbia or (b) organized under a law of a state of the United States of America or the District of Columbia. The Contractor must possess and maintain through the performance of this acquisition a physical address within the United States and must be able to demonstrate that all primary registry services will remain within the United States of America (including the District of Columbia).
The Contractor may not charge the United States Government for performance of the requirements of this purchase order (the unit price and amount for Line Items 0001, 0002 and 0003 must each be $0.00). However, the Contractor may establish and collect fees from third parties for performance of the requirements of this purchase order, provided that the fee levels are approved by the Contracting Officer before going into effect, which approval will not be withheld unreasonably, provided that the fee levels are fair and reasonable.
B.1 Statement of Purpose
The Department of Commerce seeks to acquire centralized management and coordination of registry, registrar (where specified), database, and information services for the usTLD. In broadest terms, the usTLD was created to provide a locus for registration of domain names to serve the Internet community of the United States, and is intended to be available to a wide range of registrants. Given the foregoing, the Department seeks quotations that will achieve the following objectives:
7
B.2 Core Registry Functions
The Contractor must provide, at a minimum, the services that are outlined below. This list should not be viewed as exhaustive. The Contractor must provide all systems, software, hardware, facilities, infrastructure, and operation for the following functions:
8
B.3 Core Policy Requirements
The Contractor must:
B.4 Locality-based usTLD Structure Functions
The Contractor must:
9
10
B.5 Expanded usTLD Space Functions
The Contractor must not act as a registrar in the expanded usTLD space. Presented below is a non-exhaustive list of elements that the Contractor must incorporate into its procedures and policies for the expanded usTLD structure:
11
C. REPORTING REQUIREMENTS AND DELIVERABLES
The Contractor must post the following reports on their Internet site in order to facilitate transparency and public access.
C.1 Investigational Study (One-Time Report Due Six Months After Purchase Order Award)
The Contractor must conduct an investigation and submit a written report to the COTR, within six months after purchase order award, evaluating the compliance of existing sub-domain managers with the requirements of RFC 1480 and other documented usTLD policies. Such report must recommend structural, procedural, or policy changes designed to enhance such compliance and increase the value of the locality-based structure to local communities. During this evaluation period, the Contractor must make no additional locality delegations unless otherwise directed by the Contracting Officer.
C.2 Progress Reports
For the first two years of the purchase order, the Contractor must submit monthly progress reports to the COTR, in writing, detailing the Contractor's progress towards meeting the purchase order SOW requirements. Thereafter, such reports must be provided to the COTR on a quarterly basis.
These reports must indicate the status of all major events, as well as major work performed during the month, including technical status, accomplishments, and complications experienced in fulfilling the SOW requirements, and must be submitted in such detail and form as required by the COTR. Such reports must also provide performance data related to operation of the usTLD including, but not limited to, the following: the total number of registry transactions; the number of new, transferred or deleted registrations in the usTLD (including cumulative registrations over time); the number of delegated managers and changes in delegated managers in the locality-based usTLD space; the number of registrars accredited to register names in the expanded usTLD space, including the operational status of those registrars; and any updates or modifications to the shared registration system made by the Contractor.
12
1. 52.203-12 DEV 52.203-12 LIMITATION ON PAYMENTS TO INFLUENCE CERTAIN FEDERAL TRANSACTIONS (DEVIATION NOV 1990) (JUN 1997)
(a) Definitions.
"Agency," as used in this clause, means executive agency as defined in 2.101.
"Covered Federal action," as used in this clause, means any of the following Federal actions:
(1) The awarding of any Federal contract;
(2) The making of any Federal grant;
(3) The making of any Federal loan;
(4) The entering into of any cooperative agreement; and,
(5) The extension, continuation, renewal, amendment, or modification of any Federal contract, grant, loan, or cooperative agreement.
"Indian tribe" and "tribal organization," as used in this clause, have the meaning provided in section 4 of the Indian Self-Determination and Education Assistance Act (25 U.S.C. 450B) and include Alaskan Natives.
"Influencing or attempting to influence," as used in this clause, means making, with the intent to influence, any communication to or appearance before an officer or employee of any agency, a Member of Congress, an officer or employee of Congress, or an employee of a Member of Congress in connection with any covered Federal action.
"Local government," as used in this clause, means a unit of government in a State and, if chartered, established, or otherwise recognized by a State for the performance of a governmental duty, including a local public authority, a special district, an intrastate district, a council of governments, a sponsor group representative organization, and any other instrumentality of a local government.
"Officer or employee of an agency," as used in this clause, includes the following individuals who are employed by an agency:
(1) An individual who is appointed to a position in the Government under title 5, United States Code, including a position under a temporary appointment.
(2) A member of the uniformed services as defined in subsection 101(3), title 37, United States Code.
(3) A special Government employee, as defined in section 202, title 18, United States Code.
(4) An individual who is a member of a Federal advisory committee, as defined by the Federal Advisory Committee Act, title 5, United States Code, appendix 2.
"Person," as used in this clause, means an individual, corporation, company, association, authority, firm, partnership, society, State, and local government, regardless of whether such entity is operated for profit or not for profit. This term excludes an Indian tribe, tribal organization, or any other Indian organization with respect to expenditures specifically permitted by other Federal law.
"Reasonable compensation," as used this clause, means, with respect to a regularly employed officer or employee of any person, compensation that is consistent with the normal compensation for such officer or employee for work that is not furnished to, not funded by, or not furnished in cooperation with the Federal Government.
13
"Reasonable payment," as used this clause, means, with respect to professional and other technical services, a payment in an amount that is consistent with the amount normally paid for such services in the private sector.
"Recipient," as used in this clause, includes the Contractor and all subcontractors. This term excludes an Indian tribe, tribal organization, or any other Indian organization with respect to expenditures specifically permitted by other Federal law.
"Regularly employed," as used in this clause, means, with respect to an officer or employee of a person requesting or receiving a Federal contract, an officer or employee who is employed by such person for at least 130 working days within 1 year immediately preceding the date of the submission that initiates agency consideration of such person for receipt of such contract. An officer or employee who is employed by such person for less than 130 working days within 1 year immediately preceding the date of the submission that initiates agency consideration of such person must be considered to be regularly employed as soon as he or she is employed by such person for 130 working days.
"State," as used in this clause, means a State of the United States, the District of Columbia, the Commonwealth of Puerto Rico, a territory or possession of the United States, an agency or instrumentality of a State, and multi-State, regional, or interstate entity having governmental duties and powers.
(b) Prohibitions.
(1) Section 1352 of title 31, United States Code, among other things, prohibits a recipient of a Federal contract, grant, loan, or cooperative agreement from using appropriated funds to pay any person for influencing or attempting to influence an officer or employee of any agency, a Member of Congress, an officer or employee of Congress, or an employee of a Member of Congress in connection with any of the following covered Federal actions: the awarding of any Federal contract; the making of any Federal grant; the making of any Federal loan; the entering into of any cooperative agreement; or the modification of any Federal contract, grant, loan, or cooperative agreement.
(2) The Act also requires Contractors to furnish a disclosure if any funds other than Federal appropriated funds (including profit or fee received under a covered Federal transaction) have been paid, or will be paid, to any person for influencing or attempting to influence an officer or employee of any agency, a Member of Congress, an officer or employee of Congress, or an employee of a Member of Congress in connection with a Federal contract, grant, loan, or cooperative agreement.
(3) The prohibitions of the Act do not apply under the following conditions:
(i) Agency and legislative liaison by own employees.
14
(1) Discussing with an agency the qualities and characteristics (including individual demonstrations) of the person's products or services, conditions or terms of sale, and service capabilities.
(2) Technical discussions and other activities regarding the application or adaptation of the person's products or services for an agency's use.
(1) Providing any information not specifically requested but necessary for an agency to make an informed decision about initiation of a covered Federal action;
(2) Technical discussions regarding the preparation of an unsolicited proposal prior to its official submission; and
(3) Capability presentations by persons seeking awards from an agency pursuant to the provisions of the Small Business Act, as amended by Pub. L. 95-507, and subsequent amendments.
(ii) Professional and technical services.
(1) A payment of reasonable compensation made to an officer or employee of a person requesting or receiving a covered Federal action or an extension, continuation, renewal, amendment, or modification of a covered Federal action, if payment is for professional or technical services rendered directly in the preparation, submission, or negotiation of any bid, proposal, or application for that Federal action or for meeting requirements imposed by or pursuant to law as a condition for receiving that Federal action.
(2) Any reasonable payment to a person, other than an officer or employee of a person requesting or receiving a covered Federal action or any extension, continuation, renewal, amendment, or modification of a covered Federal action if the payment is for professional or technical services rendered directly in the preparation, submission, or negotiation of any bid, proposal, or application for that Federal action or for meeting requirements imposed by or pursuant to law as a condition for receiving that Federal action. Persons other than officers or employees of a person requesting or receiving a covered Federal action include consultants and trade associations.
15
unless they provide advice and analysis directly applying their professional or technical expertise and unless the advice or analysis is rendered directly and solely in the preparation, submission or negotiation of a covered Federal action. Thus, for example, communications with the intent to influence made by a lawyer that do not provide legal advice or analysis directly and solely related to the legal aspects of his or her client's proposal, but generally advocate one proposal over another are not allowable under this section because the lawyer is not providing professional legal services. Similarly, communications with the intent to influence made by an engineer providing an engineering analysis prior to the preparation or submission of a bid or proposal are not allowable under this section since the engineer is providing technical services but not directly in the preparation, submission or negotiation of a covered Federal action.
(iii) Selling activities by independent sales representatives. The prohibition on the use of appropriated funds, in subparagraph (b)(1) of this clause, does not apply to the following sales activities before an agency by independent sales representatives, provided such activities are prior to formal solicitation by an agency and are specifically limited to the merits of the matter;
(c) Disclosure.
(1) The Contractor who requests or receives from an agency a Federal contract must file with that agency a disclosure form, OMB standard form LLL, Disclosure of Lobbying Activities, if such person has made or has agreed to make any payment using nonappropriated funds (to include profits from any covered Federal action), which would be prohibited under subparagraph (b)(1) of this clause, if paid for with appropriated funds.
(2) The Contractor must file a disclosure form at the end of each calendar quarter in which there occurs any event that materially affects the accuracy of the information contained in any disclosure form previously filed by such person under subparagraph (c)(1) of this clause. An event that materially affects the accuracy of the information reported includes—
(i) A cumulative increase of $25,000 or more in the amount paid or expected to be paid for influencing or attempting to influence a covered Federal action; or
(ii) A change in the person(s) or individual(s) influencing or attempting to influence a covered Federal action; or
16
(iii) A change in the officer(s), employee(s), or Member(s) contacted to influence or attempt to influence a covered Federal action.
(3) The Contractor must require the submittal of a certification, and if required, a disclosure form by any person who requests or received any subcontract exceeding $100,000 under the Federal contract.
(4) All subcontractor disclosure forms (but not certifications) must be forwarded from tier to tier until received by the prime Contractor. The prime Contractor must submit all disclosures to the Contracting Officer at the end of the calendar quarter in which the disclosure form is submitted by the subcontractor. Each subcontractor certification must be retained in the subcontract file of the awarding Contractor.
(d) Agreement. The Contractor agrees not to make any payment prohibited by this clause.
(e) Penalties.
(1) Any person who makes an expenditure prohibited under paragraph (a) of this clause or who fails to file or amend the disclosure form to be filed or amended by paragraph (b) of this clause must be subject to civil penalties as provided for by 31 U.S.C. 1352. An imposition of a civil penalty does not prevent the Government from seeking any other remedy that may be applicable.
(2) Contractors may rely without liability on the representation made by their subcontractors in the certification and disclosure form.
(f) Cost allowability. Nothing in this clause makes allowable or reasonable any costs which would otherwise be unallowable or unreasonable. Conversely, costs made specifically unallowable by the requirements in this clause will not be made allowable under any other provision.
2. 52.204-6 DATA UNIVERSAL NUMBERING SYSTEM (DUNS) NUMBER (JUNE 1999)
(a) The offeror shall enter, in the block with its name and address on the cover page of its offer, the annotation "DUNS" followed by the DUNS number that identifies the offeror's name and address exactly as stated in the offer. The DUNS number is a nine-digit number assigned by Dun and Bradstreet Information Services.
(b) If the offeror does not have a DUNS number, it should contact Dun and Bradstreet directly to obtain one. A DUNS number will be provided immediately by telephone at no charge to the offeror. For information on obtaining a DUNS number, the offeror, if located within the United States, should call Dun and Bradstreet at 1-800-333-0505. The offeror should be prepared to provide the following information:
(1) Company name.
(2) Company address.
(3) Company telephone number.
(4) Line of business.
(5) Chief executive officer/key manager.
(6) Date the company was started.
(7) Number of people employed by the company.
(8) Company affiliation.
17
(c) Offerors located outside the United States may obtain the location and phone number of the local Dun and Bradstreet Information Services office from the Internet Home Page at http://www.customerservice@dnb.com
If an offeror is unable to locate a local service center, it may send an e-mail to Dun and Bradstreet at globalinfo@mail.dnb.com
(End of provision)
3. 52.213-4 TERMS AND CONDITIONS—SIMPLIFIED ACQUISITIONS (OTHER THAN COMMERCIAL ITEMS) (MAR 2001)
(a) The Contractor shall comply with the following Federal Acquisition Regulation (FAR) clauses that are incorporated by reference:
(1) The clauses listed below implement provisions of law or Executive order:
(i) 52.222-3, Convict Labor (AUG 1996) (E.O. 11755).
(ii) 52.225-13, Restrictions on Certain Foreign Purchases (July 2000)(E.O.'s 12722, 12724, 13059, 13067, 13121, and 13129).
(iii) 52.233-3, Protest After Award (AUG 1996) (31 U.S.C. 3553).
(2) Listed below are additional clauses that apply:
(i) 52.232-1, Payments (APR 1984).
(ii) 52.232-8, Discounts for Prompt Payment (MAY 1997).
(iii) 52.232-11, Extras (APR 1984).
(iv) 52.232-25, Prompt Payment (JUN 1997).
(v) 52.233-1, Disputes (DEC 1998).
(vi) 52.244-6, Subcontracts for Commercial Items and Commercial Components (MAR 2001).
(viii) 52.253-1, Computer Generated Forms (JAN 1991).
(b) The Contractor shall comply with the following FAR clauses, incorporated by reference, unless the circumstances do not apply:
(1) The clauses listed below implement provisions of law or Executive order:
(i) 52.222-20, Walsh-Healey Public Contracts Act (DEC 1996) (41 U.S.C. 35-45) (Applies to supply contracts over $10,000 in the United States).
(ii) 52.222-26, Equal Opportunity (FEB 1999) (E.O. 11246) (Applies to contracts over $10,000).
(iii) 52.222-35, Affirmative Action for Disabled Veterans and Veterans of the Vietnam Era (APR 1998) (38 U.S.C. 4212) (Applies to contracts over $10,000).
(iv) 52.222-36, Affirmative Action for Workers with Disabilities (JUN 1998) (29 U.S.C. 793) (Applies to contracts over $10,000).
(v) 52.222-37, Employment Reports on Disabled Veterans and Veterans of the Vietnam Era (JAN 1999) (38 U.S.C. 4212) (Applies to contracts over $10,000).
18
(vi) 52.222-41, Service Contract Act of 1965, As Amended (MAY 1989) (41 U.S.C. 351, et seq.) (Applies to service contracts over $2,500).
(vii) 52.222-19, Child Labor—Cooperation with Authorities and Remedies (JAN 2001) (E.O. 13126). (Applies to contracts for supplies exceeding the micro-purchase threshold.)
(viii) 52.223-5, Pollution Prevention and Right-to-Know Information (APR 1998) (E.O. 12856) (Applies to services performed on Federal facilities).
(ix) 52.225-1, Buy American Act—Balance of Payments Program—Supplies (FEB 2000) (41 U.S.C. 10a - 10d) (Applies to contracts for supplies, and to contracts for services involving the furnishing of supplies, for use within the United States if the value of the supply contract or supply portion of a service contract exceeds the micro-purchase threshold and the acquisition—
(x) 52.232-33, Payment by Electronic Funds Transfer—Central Contractor Registration (May 1999). (Applies when the payment will be made by electronic funds transfer (EFT) and the payment office uses the Central Contractor Registration (CCR) database as its source of EFT information.)
(xi) 52.232-34, Payment by Electronic Funds Transfer—Other than Central Contractor Registration (May 1999). (Applies when the payment will be made by EFT and the payment office does not use the CCR database as its source of EFT information.)
(xii) 52.247-64, Preference for Privately Owned U.S.-Flag Commercial Vessels (June 2000) (46 U.S.C. 1241). (Applies to supplies transported by ocean vessels.)
(2) Listed below are additional clauses that may apply:
(i) 52.209-6, Protecting the Government's Interest When Subcontracting with Contractors Debarred, Suspended, or Proposed for Debarment (JULY 1995) (Applies to contracts over $25,000).
(ii) 52.211-17, Delivery of Excess Quantities (SEPT 1989) (Applies to fixed-price supplies).
(iii) 52.247-29, F.o.b. Origin (JUN 1988) (Applies to supplies if delivery is f.o.b. origin).
(iv) 52.247-34, F.o.b. Destination (NOV 1991) (Applies to supplies if delivery is f.o.b. destination).
(c) FAR 52.252-2, Clauses Incorporated by Reference (FEB 1998). This contract incorporates one or more clauses by reference, with the same force and effect as if they were taken in full text. Upon request, the Contracting Officer will make their full text available. Also, the full text of a clause may be accessed electronically at this/these address(es): http://www.arnet.gov/far
(d) Inspection/Acceptance. The Contractor shall tender for acceptance only those items that conform to the requirements of this contract. The Government reserves the right to inspect or test any supplies or services that have been tendered for acceptance. The Government may require repair or replacement of nonconforming supplies or reperformance of nonconforming services at no increase in contract price. The Government must exercise its postacceptance rights—
(1) Within a reasonable period of time after the defect was discovered or should have been discovered; and
19
(2) Before any substantial change occurs in the condition of the item, unless the change is due to the defect in the item.
(e) Excusable delays. The Contractor shall be liable for default unless nonperformance is caused by an occurrence beyond the reasonable control of the Contractor and without its fault or negligence, such as acts of God or the public enemy, acts of the Government in either its sovereign or contractual capacity, fires, floods, epidemics, quarantine restrictions, strikes, unusually severe weather, and delays of common carriers. The Contractor shall notify the Contracting Officer in writing as soon as it is reasonably possible after the commencement of any excusable delay, setting forth the full particulars in connection therewith, shall remedy such occurrence with all reasonable dispatch, and shall promptly give written notice to the Contracting Officer of the cessation of such occurrence.
(f) Termination for the Government's convenience. The Government reserves the right to terminate this contract, or any part hereof, for its sole convenience. In the event of such termination, the Contractor shall immediately stop all work hereunder and shall immediately cause any and all of its suppliers and subcontractors to cease work. Subject to the terms of this contract, the Contractor shall be paid a percentage of the contract price reflecting the percentage of the work performed prior to the notice of termination, plus reasonable charges that the Contractor can demonstrate to the satisfaction of the Government, using its standard record keeping system, have resulted from the termination. The Contractor shall not be required to comply with the cost accounting standards or contract cost principles for this purpose. This paragraph does not give the Government any right to audit the Contractor's records. The Contractor shall not be paid for any work performed or costs incurred that reasonably could have been avoided.
(g) Termination for cause. The Government may terminate this contract, or any part hereof, for cause in the event of any default by the Contractor, or if the Contractor fails to comply with any contract terms and conditions, or fails to provide the Government, upon request, with adequate assurances of future performance. In the event of termination for cause, the Government shall not be liable to the Contractor for any amount for supplies or services not accepted, and the Contractor shall be liable to the Government for any and all rights and remedies provided by law. If it is determined that the Government improperly terminated this contract for default, such termination shall be deemed a termination for convenience.
(h) Warranty. The Contractor warrants and implies that the items delivered hereunder are merchantable and fit for use for the particular purpose described in this contract.
(End of clause)
4. 52.217-9 OPTION TO EXTEND THE TERM OF THE CONTRACT (MAR 2000)
(a) The Government may extend the term of this contract by written notice to the Contractor within sixty (60) days of expiration of the then-current contract period, provided that the Government gives the Contractor a preliminary written notice of its intent to extend at least sixty (60) days before the contract expires. The preliminary notice does not commit the Government to an extension.
(b) If the Government exercises this option, the extended contract shall be considered to include this option clause.
20
(c) The total duration of this contract, including the exercise of any options under this clause, shall not exceed six (6) years.
(End of clause)
5. 52.227-17 RIGHTS IN DATA—SPECIAL WORKS (JUN 1987)
(a) Definitions.
"Data," as used in this clause, means recorded information regardless of form or the medium on which it may be recorded. The term includes technical data and computer software. The term does not include information incidental to contract administration, such as financial, administrative, cost or pricing or management information.
"Unlimited rights," as used in this clause, means the right of the Government to use, disclose, reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, in any manner and for any purpose whatsoever, and to have or permit others to do so.
(b) Allocation of Rights. (1) The Government shall have—
(i) Unlimited rights in all data delivered under this contract, and in all data first produced in the performance of this contract, except as provided in paragraph (c) of this clause for copyright.
(ii) The right to limit exercise of claim to copyright in data first produced in the performance of this contract, and to obtain assignment of copyright in such data, in accordance with subparagraph (c)(1) of this clause.
(iii) The right to limit the release and use of certain data in accordance with paragraph (d) of this clause.
(2) The Contractor shall have, to the extent permission is granted in accordance with subparagraph (c)(1) of this clause, the right to establish claim to copyright subsisting in data first produced in the performance of this contract.
(c) Copyright—(1) Data first produced in the performance of this contract. (i) The Contractor agrees not to assert, establish, or authorize others to assert or establish, any claim to copyright subsisting in any data first produced in the performance of this contract without prior written permission of the Contracting Officer. When claim to copyright is made, the Contractor shall affix the appropriate copyright notice of 17 U.S.C. 401 or 402 and acknowledgment of Government sponsorship (including contract number) to such data when delivered to the Government, as well as when the data are published or deposited for registration as a published work in the U.S. Copyright Office. The Contractor grants to the Government, and others acting on its behalf, a paid-up nonexclusive, irrevocable, worldwide license for all such data to reproduce, prepare derivative works, distribute copies to the public, and perform publicly and display publicly, by or on behalf of the Government.
(ii) If the Government desires to obtain copyright in data first produced in the performance of this contract and permission has not been granted as set forth in subdivision (c)(1)(i) of this clause, the Contracting Officer may direct the Contractor to establish, or authorize the establishment of, claim to copyright in such data and to assign, or obtain the assignment of, such copyright to the Government or its designated assignee.
(2) Data not first produced in the performance of this contract. The Contractor shall not, without prior written permission of the Contracting Officer, incorporate in data delivered under this contract any data not first produced in the performance of this contract and which contain the copyright notice of 17 U.S.C. 401 or 402, unless the Contractor identifies such data and grants to the Government, or acquires on its behalf, a license of the same scope as set forth in subparagraph (c)(1) of this clause.
21
(d) Release and use restrictions. Except as otherwise specifically provided for in this contract, the Contractor shall not use for purposes other than the performance of this contract, nor shall the Contractor release, reproduce, distribute, or publish any data first produced in the performance of this contract, nor authorize others to do so, without written permission of the Contracting Officer.
(e) Indemnity. The Contractor shall indemnify the Government and its officers, agents, and employees acting for the Government against any liability, including costs and expenses, incurred as the result of the violation of trade secrets, copyrights, or right of privacy or publicity, arising out of the creation, delivery, publication, or use of any data furnished under this contract; or any libelous or other unlawful matter contained in such data. The provisions of this paragraph do not apply unless the Government provides notice to the Contractor as soon as practicable of any claim or suit, affords the Contractor an opportunity under applicable laws, rules, or regulations to participate in the defense thereof, and obtains the Contractor's consent to the settlement of any suit or claim other than as required by final decree of a court of competent jurisdiction; nor do these provisions apply to material furnished to the Contractor by the Government and incorporated in data to which this clause applies.
(End of clause)
6. 1352.233-70 HARMLESS FROM LIABILITY (MARCH 2000)
The Contractor shall hold and save the Government, its officers, agents, and employees harmless from liability of any nature or kind, including costs and expenses to which they may be subject, for or on account of any or all suits or damages of any character whatsoever resulting from injuries or damages sustained by any person or persons or property by virtue of performance of this contract, arising or resulting in whole or in part from the fault, negligence, wrongful act or wrongful omission of the contractor, or any subcontractor, their employees, and agents.
7. 1352.233-71 SERVICE OF PROTESTS (MARCH 2000)
An agency protest may be filed with either (1) the Contracting Officer, or (2) at a level above the Contracting Officer, with the agency Protest Decision Authority. See 64 Fed. Reg. 16,651 (April 6, 1999) (Internet site: http://oamweb.osec.doc.gov/conops/reflib/alp1296.htm) for the procedures for filing agency protests at the level above the Contracting Officer (with the Protest Decision Authority). Agency protests filed with the Contracting Officer shall be sent to the following address:
ATTN JOSEPH L. WIDDUP, CONTRACTING OFFICER
U
S DEPT OF COMMERCE
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY
100 BUREAU DRIVE STOP 3571
BUILDING 301 ROOM B129
GAITHERSBURG MD 20899-3571
PHONE: (301) 975-6324
FAX: (301) 975-8884
EMAIL: Joseph.Widdup@nist.gov
If a protest is filed with either the Protest Decision Authority, or with the General Accounting Office (GAO), a complete copy of the protest (including all attachments) shall be served upon both the Contracting Officer and Contract Law Division of the Office of the General Counsel within one day of
22
filing with the Protest Decision Authority or with GAO. Service upon the Contract Law Division shall be made, as follows:
8. 1352.252-71 REGULATORY NOTICE (MARCH 2000)
Offerors are advised that certain provisions and clauses identified with a Commerce Acquisition Regulation (CAR) notation for identification purposes, have not yet been incorporated into the CAR. However, all of these items are binding for this acquisition and will eventually be contained in the CAR at Part 13 of Title 48 of the Code of Federal Regulations.
9. 52.233-1 I DISPUTES (DEC 1998)—ALTERNATE I (DEC 1991)
(Reference 33.215)
10. 52.239-1 PRIVACY OR SECURITY SAFEGUARDS (AUG 1996)
(Reference 39.107)
11. 1352.201-70 CONTRACTING OFFICER'S AUTHORITY (MARCH 2000)
The Contracting Officer is the only person authorized to make or approve any changes in any of the requirements of this contract and notwithstanding any provisions contained elsewhere in this contract, the said authority remains solely in the Contracting Officer. In the event the Contractor makes any changes at the direction of any person other then the Contracting Officer, the change will be considered to have been made without authority and no adjustment will be made in the contract terms and conditions, including price.
12. 1352.201-71 CONTRACTING OFFICER'S TECHNICAL REPRESENTATIVE (COTR) (MARCH 2000)
a. (To be completed at time of award) is hereby designated as the Contracting Officer's Technical Representative (COTR). The COTR may be changed at any time by the Government without prior notice to the Contractor by a unilateral modification to the Contract. The COTR is located at:
To be completed at time of award
b. The responsibilities and limitations of the COTR are as follows:
(1) The COTR is responsible for the technical aspects of the project and serves as technical liaison with the Contractor. The COTR is also responsible for the final inspection and acceptance of all reports, and such other responsibilities as may be specified in the contract.
(2) The COTR is not authorized to make any commitments or otherwise obligate the Government or authorize any changes, which affect the Contract price, terms or conditions. Any Contractor request for changes shall be referred to the Contracting Officer directly or through the COTR. No such changes shall be made without the expressed prior authorization of the Contracting Officer. The COTR may designate assistant COTR(s) to act for the COTR by naming such assistant(s)
23
in writing and transmitting a copy of such designation through the Contracting Officer to the Contractor.
13. ANSWERS TO ANTICIPATED OFFEROR QUESTIONS
A. What procedure is the Government using to conduct this acquisition? The Government is using Federal Acquisition Regulation (FAR) Part 13, Simplified Acquisition Procedures, to conduct this acquisition. The entire FAR (including Part 13) may be accessed on the Internet at: http://www.arnet.gov/far. The competitive solicitation, solicitation amendments, and all questions and answers related to this procurement will only be made available via the Internet at http://www.fedbizops.gov.
B. Is the solicitation available in hard copy? No. The solicitation will only be released and made available in Microsoft Word 97 format via the Internet at the above web site. Potential offerors are responsible for accessing the web site. Interested parties must respond to the solicitation in order to be considered for award of any resultant contract. There is no written solicitation document available, telephone requests will not be honored, and no bidders list will be maintained.
C. What organization is currently administering the .us domain space? Under what authority? Network Solutions, Inc., 21345 Ridgetop Circle, Dulles, VA 20166-6503, a wholly owned subsidiary of VeriSign, Inc., is administering the .us domain space under the authority of Cooperative Agreement No. NCR 92-18724 originally issued by the National Science Foundation in 1992. The cooperative agreement was transferred to DOC in September of 1998 through a memorandum of understanding between the two agencies.
D. What organizations (by name, address, and phone number) currently have .us addresses? Is there a web site for this, or a database from which a report could be extracted? (If there is a database from which a report could be extracted, then please extract such a report and send the report to me in Microsoft Word or other windows-based format.) Because of the hierarchical nature of registrations in the .us domain, there is at present no compiled list or database that includes all registrations in the .us space. A description of the information that is available can be found on the Official US Domain Registry web site at: http://www.nic.us/register/whois.html. A list of delegated subdomains and related contacts is provided at: http://www.nic.us/register/register.html.
E. Over the next five years, how many current .us registrants does DOC expect to not renew their registration (at some point during the next five years) for their .us web site? Because of the hierarchal structure of the usTLD, this information is not directly available. Further, with the introduction of an expanded usTLD space, it is expected that a considerable number of new registrations will occur. Prospective Contractors should include estimated registration projections in their proposals.
F. Historically, how many registrants, per year, have not renewed their registration for their .us web site? Because of the hierarchal structure of the usTLD, this information is not directly available. Further, with the introduction of an expanded usTLD space, it is expected that a considerable number of new registrations will occur. Prospective Contractors should include estimated registration projections in their proposals.
G. Over the next five years, how many new organizations, per year, does DOC expect to register for a new .us web site? Prospective contractors should include estimated registration projections in their proposals.
H. What is the fee structure that is currently being charged, per registrant, for registration in the .us space? Network Solutions, Inc., does not charge a fee for registration in the .us space. Organizations approved to register .us domain names by the US Domain Registry may charge a fee,
24
which is generally nominal in nature. For a fuller description of charges, see the Official US Domain Registry web site at http://www.nic.us/register/cost.html
I. What data will have to be transitioned from the incumbent contractor to the contractor from the new procurement? What format is the data in? When will that data be transitioned? How will that data be transitioned? Does the Government own that data, or does the incumbent contractor own that data? Pursuant to Amendment 21 to the Cooperative Agreement between the Department of Commerce and Network Solutions, Inc., Network Solutions has agreed, upon designation of a successor registry for .us by the Department, to use commercially reasonable efforts to cooperate with the Department to facilitate the smooth transition of operation of the .us domain. That cooperation will include timely transfer to the successor registry of an electronic copy of the then-current top-level domain registration data and, to the extent such information is available, specification of the format of the data. Network Solutions has also agreed to provide, upon the Department's request, any information or documentation regarding administration of the .us domain that the Department reasonably deems necessary to secure a successor registry. After the transition period, any rights held by Network Solutions, Inc., as registry in the registry data shall terminate. DOC will license the data on a non-exclusive, transferable, irrevocable, royalty-free, paid-up basis to the successor registry.
J. Are there minimum facilities requirements (i.e., space, equipment) will companies be expected to meet in order to be considered technically acceptable from that standpoint? If so, then please specify what those requirements are. There are no minimum facilities requirements per se. Rather, quotations will be evaluated, in part, on the basis of Offerors demonstrating the quality and adequacy of their technical facilities, equipment, software, hardware, and related technology to meet these requirements.
** Any additional Offeror questions shall be sent by email only to Joseph.Widdup@nist.gov no later than 12:00 noon Eastern Time on June 29, 2001. Answers to all questions received by then will be posted as amendment(s) to the solicitation. Questions received regarding this solicitation after June 29, 2001 may not be answered by the Government. **
25
REPRESENTATIONS AND CERTIFICATIONS OF OFFERORS
1. 52.219-1 SMALL BUSINESS PROGRAM REPRESENTATIONS (MAR 2001)
(a) (1) The North American Industry Classification System (NAICS) code for this acquisition is 541519
(2) The small business size standard is $18.0 million.
(3) The small business size standard for a concern which submits an offer in its own name, other than on a construction or service contract, but which proposes to furnish a product which it did not itself manufacture, is 500 employees.
(b) Representations. (1) The offeror represents as part of its offer that it o is, ý is not a small business concern.
(2) [Complete only if the offeror represented itself as a small business concern in paragraph (b)(1) of this provision.] The offeror represents, for general statistical purposes, that it o is, o is not, a small disadvantaged business concern as defined in 13 CFR 124.1002.
(3) [Complete only if the offeror represented itself as a small business concern in paragraph (b)(1) of this provision.] The offeror represents as part of its offer that it o is, o is not a women-owned small business concern.
(4) [Complete only if the offeror represented itself as a small business concern in paragraph (b)(1) of this provision.] The offeror represents as part of its offer that it o is, o is not a veteran-owned small business concern.
(5) [Complete only if the offeror represented itself as a veteran-owned small business concern in paragraph (b)(4) of this provision.] The offeror represents as part of its offer that it o is, o is not a service-disabled veteran-owned small business concern.
(c) Definitions. As used in this provision—
"Service-disabled veteran-owned small business concern"—
(1) Means a small business concern—
(i) Not less than 51 percent of which is owned by one or more service-disabled veterans or, in the case of any publicly owned business, not less than 51 percent of the stock of which is owned by one or more service-disabled veterans; and
(ii) The management and daily business operations of which are controlled by one or more service-disabled veterans or, in the case of a veteran with permanent and severe disability, the spouse or permanent caregiver of such veteran.
(2) Service-disabled veteran means a veteran, as defined in 38 U.S.C. 101(2), with a disability that is service-connected, as defined in 38 U.S.C. 101(16).
"Small business concern," means a concern, including its affiliates, that is independently owned and operated, not dominant in the field of operation in which it is bidding on Government contracts, and qualified as a small business under the criteria in 13 CFR Part 121 and the size standard in paragraph (a) of this provision.
"Veteran-owned small business concern" means a small business concern—
(1) That is at least 51 percent owned by one or more women; or, in the case of any publicly owned business, at least 51 percent of the stock of which is owned by one or more women; and
26
(2) The management and daily business operations of which are controlled by one or more veterans.
"Women-owned small business concern," means a small business concern-
(1) Which is at least 51 percent owned by one or more women or, in the case of any publicly owned business, at least 51 percent of the stock of which is owned by one or more women; and
(2) Whose management and daily business operations are controlled by one or more women.
(d) Notice. (1) If this solicitation is for supplies and has been set aside, in whole or in part, for small business concerns, then the clause in this solicitation providing notice of the set-aside contains restrictions on the source of the end items to be furnished.
(2) Under 15 U.S.C. 645(d), any person who misrepresents a firm's status as a small, HUBZone small, small disadvantaged, or women-owned small business concern in order to obtain a contract to be awarded under the preference programs established pursuant to section 8(a), 8(d), 9, or 15 of the Small Business Act or any other provision of Federal law that specifically references section 8(d) for a definition of program eligibility, shall—
(i) Be punished by imposition of fine, imprisonment, or both;
(ii) Be subject to administrative remedies, including suspension and debarment; and
(iii) Be ineligible for participation in programs conducted under the authority of the Act.
(End of provision)
2. 52.203-11 DEV 52.203-11 CERTIFICATION AND DISCLOSURE REGARDING PAYMENTS TO INFLUENCE CERTAIN FEDERAL TRANSACTIONS DEVIATION (JAN 1990)
(a) The definitions and prohibitions contained in the clause, at FAR 52.203-12, Limitation on Payments to Influence Certain Federal Transactions, included in this solicitation, are hereby incorporated by reference in paragraph (b) of this certification.
(b) The offeror, by signing its offer, hereby certifies to the best of his or her knowledge and belief as of December 23, 1989 that—
(1) No Federal appropriated funds have been paid or will be paid to any person for influencing or attempting to influence an officer or employee of any agency, a Member of Congress, an officer or employee of Congress, or an employee of a Member of Congress on his or her behalf in connection with the awarding of a contract resulting from this solicitation;
(2) If any funds other than Federal appropriated funds (including profit or fee received under a covered Federal transaction) have been paid, or will be paid, to any person for influencing or attempting to influence an officer or employee of any agency, a Member of Congress, an officer or employee of Congress, or an employee of a Member of Congress on his or her behalf in connection with this solicitation, the offeror must complete and submit with its offer, OMB standard form LLL, Disclosure of Lobbying Activities, to the Contracting Officer, and
(3) He or she will include the language of this certification in all subcontract awards at any tier and require that all recipients of subcontract awards in excess of $100,000 must certify and disclose accordingly.
(c) Submission of this certification and disclosure is a prerequisite for making or entering into this contract imposed by section 1352, title 31, United States Code. Any person who makes an expenditure prohibited under this provision or who fails to file or amend this disclosure form to be filed or amended by this provision, must be subject to a civil penalty of not less than $10,000, and not more than $100,000, for each such failure.
[End of Clause]
27
INSTRUCTIONS FOR SUBMITTING QUOTATIONS
Before submitting a quotation, Offerors are encouraged to review the information on the locality-based usTLD structure and registration policies at: http://www.nic.us
The Offeror must submit the ORIGINAL VERSION and TWO COPIES of the Quotation to the following address:
ATTN
JOSEPH L WIDDUP
NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY
100 BUREAU DR STOP 3571
BLDG 301 RM B129
GAITHERSBURG MD 20899-3571
M/F SOLICITATION SB1335-01-Q-0740
Each quotation (original and copies) submitted in response to this solicitation must:
28
Offerors should also describe additional procedures that address other considerations than those listed above that they consider relevant to their quotation.
29
At the discretion of the Contracting Officer, a site visit to the Offeror's facility(ies) may also be requested and conducted by DOC personnel involved in this acquisition. The purpose of this visit would be to gather information relevant to the Offeror's submitted quotation. The Contracting Officer would arrange such a visit at least seven days in advance with the Offeror.
30
A quotation will only be considered if it is submitted by an organization that is (a) incorporated within one of the fifty states of the United States of America or the District of Columbia or (b) organized under a law of a state of the United States of America. The Contractor must have a physical address within the United States of America or the District of Columbia and must be able to demonstrate that all primary registry services will remain within the United States of America (including the District of Columbia).
The Government will evaluate quotations submitted in response to this acquisition for services and will award a purchase order to the technically acceptable, responsible Offeror whose quotation represents the best value. Technical excellence and comprehensiveness of the overall service for usTLD operation is significantly more important than proposed price(s) to .us registrants. The evaluated price for all quotations, in terms of the price paid by the Government, will be $0.00. This acquisition is being conducted under FAR Part 13, Simplified Acquisition Procedures. Under FAR Part 13, solicitations are not required to state the relative order of importance assigned to each evaluation factor and subfactor, nor are they required to include subfactors. The evaluation factors are listed below.
For the purposes of this solicitation, "best value" means the expected outcome of an acquisition that, in the Government's estimation, provides the greatest overall benefit in response to the requirement. In this solicitation, the term "best value" is not meant to imply that a specific tradeoff process (as described in FAR Part 15, Contracting by Negotiation) will be used by the Government. This acquisition is being conducted under FAR Part 13, Simplified Acquisition Procedures.
31
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
00001 |
||||
3. |
Effective Date |
|||||
4. |
Requisition/Purchase Req. No. |
|||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
National Inst of Stds and Technology 100 Bureau Drive Stop 3571 Building 301 Room B129 Gaithersbur MD 20899-3571 Widdup, Joseph 301-975-6324 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NUESTAR 1120 Vermont Avenue NW Suite 400 Washington DC 20005 Vendor ID: 00007158 DUNS: 112403295 |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
61010001020400009091900000 9000090900000000000000$US0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
32
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
|||||
(X) |
C. |
This supplemental agreement is entered into pursuant to authority of: FAR Subpart 43.103(a) |
||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
A. |
The purpose of this modification is to modify Section J, Registration Process: Land Rush Implementation, An Overview of the Land Rush Solution, The Benefits of NeuStar's Land Rush Implementation Approach in the Contractor's quotation, which is incorporated by reference into this Purchase Order, as follows: |
|||||
—Delete the batch-based Landrush process originally proposed by the Contractor. |
||||||
—The Contractor must implement increased monitoring of the system loads to ensure equality among its customers and that the Contractor's systems do not become overloaded. |
||||||
—The Contractor must proceed with a first-come-first-served ("FCFS") registration approach following Sunrise. |
||||||
B. |
The adoption of the FCFS approach must not affect the overall timeline for the usTLD startup phases described on page I-2 of the Contractor's quotation. The Sunrise process will remain unchanged. |
|||||
END OF MODIFICATION |
||||||
15A. |
Name and Title of Signer (Type or Print) |
James A. Casey |
||||
15B. |
Contractor/Offeror |
/s/ James A. Casey |
||||
15C. |
Date Signed |
02-04-2002 |
||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Widdup, Joseph Contracting Officer 301-975-6324 jwiddup@nist.gov |
||||
16B. |
United States of America |
/s/ Joseph Widdup |
||||
16C. |
Date Signed |
02-04-2002 |
||||
33
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. |
Contract Id Code |
|||||
2. |
Amendment/Modification No. |
0002 |
||||
3. |
Effective Date |
June 14, 2002 |
||||
4. |
Requisition/Purchase Req. No. |
|||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code 000SB National Inst. Of Stds. And Technology 100 Bureau Drivestop 3571 Building 301 Room B129 Gaithersburg, MD 20899-3571 Widdup, Joseph 301-975-6324 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NEUSTAR 1120 Vermont Avenue NW Suite 400 Washington, DC 20005 Vendor ID: 00007158 DUNS: 112403295 CAGE: |
||||
9A |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
61010001020400009091900000 9000090900000000000000$US0.00 |
||||
34
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
|||||
(X) |
C. |
This supplemental agreement is entered into pursuant to authority of: FAR Subpart 43.103(a) |
||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
A. |
The purpose of this modification is to incorporate the Government-approved version of the Contractor's usTLD Undelegated Name Policy (Interim) into this purchase order in full text. That policy is stated verbatim in the continuation pages of this modification. |
|||||
B. |
The parties agree that the usTLD Undelegated Name Policy (Interim) in no way affects the Contractor's obligation to produce a report within six months of Purchase Order award, as required by Section C.1 of the Purchase Order. |
|||||
15A. |
Name and Title of Signer (Type or Print) |
Robert Poulin Senior Vice President |
||||
15B. |
Contractor/Offeror |
/s/ Robert Poulin |
||||
15C. |
Date Signed |
June 14, 2004 |
||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Widdup, Joseph Contracting Officer 301-975-6324 jwiddup@nist.gov |
||||
16B. |
United States of America |
/s/ Joseph Widdup |
||||
16C. |
Date Signed |
June 14, 2002 |
usTLD Undelegated Name Policy (Interim)
I. Background
One of NeuStar's primary responsibilities for the usTLD is the enhancement of the locality-based space in .us. The distributed nature of this space has led, despite the good efforts of many existing delegated managers, to an often poorly coordinated and sometimes "broken" top-level domain. NeuStar is committed, in partnership with existing delegated managers and users, to improving the coordination, management and operation of the locality space. This policy provides an interim solution for registration of locality-based names, in formerly undelegated domains, by state and local governments to ensure smooth operation of the existing locality space during this undertaking.
This diagram shows the current basic structure of the usTLD locality space.
35
Since its inception, the locality space has operated through "delegated managers". Delegated managers take responsibility for the operation of specified zones within the usTLD structure. These delegations are based upon "localities," such as cities and counties, and have been third-level delegations in the form <locality>.<state>.us. For example, an entity might operate as the delegated manager of the domainburke.va.us. As the delegated manager, that entity would be fully responsible for the operation and maintenance of the delegated domain—the usTLD Administrator maintains no records or information for the zone created by the delegation beyond the actual delegation to the delegated manager.
Under the government contract between NeuStar and the Department of Commerce ("DoC"), the existing delegated managers maintain their delegations and will operate them in the normal fashion, but NeuStar is not permitted to make any new delegations until it has completed a report on the status of the locality space and made recommendations on its future operation. In order to allow the continued operation of the space for local and state governments during this process. NeuStar has developed this interim policy relating to names that were never delegated to a delegated manager prior to NeuStar's acceptance of the usTLD Administrator role.
II. Interim Policy
Until completion of the "Compliance Report Process," NeuStar will assume responsibility for the operation of all of the currently undelegated name spaces identified in RFC 1480 and/or created by the prior usTLD Administrator.NeuStar will become the interim delegated manager for all such names and run the nameservers for those names.NeuStar's role as the delegated manager for these spaces and its operation of the corresponding nameservers will be an interim role until completion of the usTLD locality space compliance report process. Upon completion of that process, NeuStar will implement necessary changes, if any, to this policy to realize the goals and requirements set out in the report. Recognizing that this process could result in a change to the manner in which the undelegated locality-based names are managed, NeuStar has designed the policy below to allow the greatest degree of flexibility while maintaining the integrity of the hierarchical locality-based domain space.
III. Domain Delegations for Undelegated Domains
In keeping with the goal of centralizing the technical function of the usTLD, all of the currently undelegated names in the identified usTLD structure will, in the interim, be delegated(1) to NeuStar.Specifically, NeuStar will be the delegated manager for the following domains to the extent that they were not delegated prior to NeuStar's acceptance of the administrator role: us.(2)
<state>.us
<locality>.<state>.us
lib.<state>.us
k12.<state>.us
pvt.k12.<state>.us
cc.<state>.us
tec.<state>.us
36
isa.us
nsn.us
dni.us
This approach will allow NeuStar to maintain control of the listed zone while permitted additional records to be registered at higher delegation levels. For example, an entity would not be permitted to be the delegated manager of some locality.<state>.us. That domain already would be delegated to NeuStar. However, the city or county government for that locality would be permitted to register its corresponding city or county government name at a level higher (e.g., ci.somelocality.<state>.us or co.somelocality.<state>.us).
IV. Registration of Names
NeuStar will serve as the registrar for all currently undelegated domains. Adds, modifies, deletes and renewals will be ordered through an Internet GUI or other process.(3) However, during the time in which this interim policy applies, only state and local government agencies and their designated representatives will be eligible to register new names in formerly undelegated.US domains.(4) In order to register a name, the registrant must complete the online form (including the provision of all requested information) and agree to the NeuStar.US Domain Name Registration Terms and Conditions. The data required from registrants in the locality space is the same as in the expanded space.
Upon completion submission of the registration information, the entity registering the name will be required to provide the following along with the registration information:
V. Future Policies and Processes
Any registration made under this interim policy will remain subject to the results of the compliance report process. Policies and procedures described in the compliance report and approved by the DoC will apply to all registered names, including names registered under this interim policy.
37
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0003 |
||||
3. |
Effective Date |
August 17, 2002 |
||||
4. |
Requisition/Purchase Req. No. |
|||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code AJF60012 National Inst. Of Stds. And Technology 100 Bureau Drivestop 3571 Building 301 Room B129 Gaithersburg, MD 20899-3571 Widdup, Joseph 301-975-6324 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NEUSTAR 1120 Vermont Avenue NW Suite 400 Washington, DC 20005 Vendor ID: 00007158 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers is o extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
38
12. |
Accounting and Appropriation Data (if required) |
610100010020400009091900009000009090000000000000$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
(X) |
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
||||
C. |
This supplemental agreement is entered into pursuant to authority of: |
|||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor ý is not, o is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
39
THIS PAGE IS INTENTIONALLY LEFT BLANK
40
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
a. Ms. Sallianne Schagrin is hereby designated as the Contracting Officer's Technical Representative (COTR). The Government may change the COTR at any time without prior notice to the Contractor by a unilateral modification to the Contract. The COTR is located at:
U.
S. Department of Commerce
National Telecommunications and Information Administration (NTIA)
Office of Policy Analysis and Development
1401 Constitution Ave., N.W., Room 4725
Washington, D.C. 20230
Phone:
(202) 482-1885
Email: SSchagrin@ntia.doc.gov
b. The responsibilities and limitations of the COTR are as follows:
(1) The COTR is responsible for the technical aspects of the project and serves as technical liaison with the Contractor. The COTR is the only Government person other than the Contracting Officer from whom the Contractor may rely for information or guidance related to performance under this purchase order. The COTR is also responsible for the final inspection and acceptance of all reports, and such other responsibilities as may be specified in the contract.
(2) The COTR is not authorized to make any commitments or otherwise obligate the Government or authorize any changes that affect the purchase order terms or conditions. Any Contractor request for changes shall be referred to the Contracting Officer directly or through the COTR. No such changes shall be made without the expressed prior authorization of the Contracting Officer. The COTR may designate assistant COTR(s) to act for the COTR by naming such assistant(s) in writing and transmitting a copy of such designation through the Contracting Officer to the Contractor.
END OF MODIFICATION
41
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0004 |
||||
3. |
Effective Date |
|||||
4. |
Requisition/Purchase Req. No. |
|||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code 000SB National Inst. Of Stds. And Technology 100 Bureau Drive Stop 3571 Building 301 Room B129 Gaithersburg, MD 20899-3571 Widdup, Joseph 301-975-6324 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NEUSTAR 1120 Vermont Avenue NW Suite 400 Washington, DC 20005 Vendor ID: 00007158 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
42
12. |
Accounting and Appropriation Data (if required) |
610100010020400009091900009000009090000000000000$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) |
|||||
Set forth item 14, pursuant to the authority of FAR 43.103(a). |
||||||
(X) |
C. |
This supplemental agreement is entered into pursuant to authority of: FAR 43.103(a) |
||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
The purpose of this modification is to incorporate the Government-approved version of the usTLD Reserved Name Registration Process and the.US Validated Domain Registration Process, along with associated appendices. Those documents are found in the continuation pages of this modification. |
||||||
END OF TEXT |
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
USTLD RESERVED NAME REGISTRATION PROCESS
The U. S. Department of Commerce awarded Purchase Order No. SB1335-02-W-0175 ("the contract") to NeuStar, Inc. ("the Contractor") for management of the.us domain, the country-code toplevel domain uniquely associated with the United States. On April 24, 2002, the.us domain was opened to the general public for registration. To preserve the U.S. Government presence in the new expanded.us space, the Department of Commerce, working through the Federal CIO Council among others, reserved second-level domain names that correspond to the names used by the U.S. Government in the.gov space, as well as the names of states and local governments. The reservation list currently appears on the Contractor's website at http://www.neustar.us.
This document describes the process that the Contractor will use for registration of these names by the appropriate entities. This process is intended to provide a streamlined method for Federal, State and Local government entities to obtain access to the reserved names.
Proposed Federal Reserved Name Registration Process
The Contractor will serve as the registrar for all reserved name registrations. Registrations, modifications to registrations, deletions and registration renewals all will be ordered through a formbased registration and certification process. The Contractor will implement the following process:
Step 1: A pre-populated form will be sent by electronic mail to each Federal government Central Information Officer (CIO). This form will contain only those names that correspond to the recipient's agency or department. State and local government contacts will receive either email, or direct mail notifications and a web address, which they can go to for viewing their reserved names.
43
Step 2: In the case of the Federal Government, the CIO will complete the electronic form, selecting the available reserved names they wish to register along with the term of the registration (yearly or lifetime) and method of payment (credit card). State and local government points of contact will fill out a web form and then mail it to a PO Box that the Contractor set up.
Step 3: The CIO will return the completed form by e-mail within 90 days. State and local government points of contact will have 120 days.
Step 4: Once the Contractor has received the completed form and the appropriate payment, the names will be loaded into the Contractor's Registry system and the registration point of contact will be notified by email of the name registration(s).
The reserved names will be released for general availability on the date to be identified in the mailing described in Step 1.
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
VALIDATED DOMAIN REGISTRATION PROCESS
The .US Validated Domain Registration Process is detailed in the sections that follow. The documents provided break down the steps by type. Specifically, what parts are handled by the systems that the Contractor built for standard .BIZ and .US registrations as well as the manual processes required to complete validation and order entry.
The documents also detail the level of effort required to complete each step in the registration process. In order to give one an understanding of how the level of effort impacts the Contractor's costs, the incremental time by functional area are categorized for these out of manual processes. This information was used to derive the pricing that is provided in Appendix 3.
Appendix 1 contains two process flows. The first process flow details the steps required to process a validated domain registration. The second process flow details the steps required to process a fully automated domain registration. In the first process flow the incremental level of effort to perform a validated registration are listed.
Appendix 2 is the process flow description document. This documents provides the details of each step in the registration process as well as the functional areas that are impacted.
Appendix 3 contains the pricing options for a validated registration. The Contractor factored into its standard registration business case all of the incremental costs associated with the Validated Domain Registration Process. After capturing the incremental costs and applying a reasonable margin, the Contractor arrived at what the cost per unit needs to be for a Validated registration.
44
AMENDMENT OF SOLICITATION OF CONTRACT
APPENDIX 1
VALIDATED DOMAIN REGISTRATION PROCESS
45
APPENDIX 2
USTLD FEDERAL RESERVE NAME ALLOCATION PROCESS
STEP |
OWNER |
ACTIVITY & DESCRIPTION |
TRIGGER |
SUPPORT TOOL(S)/ SYSTEMS |
|||||||
---|---|---|---|---|---|---|---|---|---|---|---|
1 |
Customer Service |
Send Request Packet to Agency Email full Request Packet with instructions and "terms & conditions" to Federal Agency points of contact. The Request Packet will minimally include; |
DoC Pricing Approval |
1. |
Dol provided Agency email list |
||||||
— |
Reserved names for each agency |
2. |
Agency Master List—excel spreadsheet w/Agency, domain name, and authorized email cross-ref |
||||||||
— |
Request instructions |
3. |
Contractor email text, email generator, and receipt email box |
||||||||
— |
Terms & Conditions |
4. |
Request packet with; |
||||||||
— |
Domain request forms with fields for all domain contacts |
• Reserved name list |
|||||||||
— |
Credit card authorization form |
• Instructions |
|||||||||
— |
Pricing and billing sheet |
• Terms & Conditions |
|||||||||
• Payment authorization |
|||||||||||
2 |
Customer Service |
Receive Completed Request Packet |
Email with Request Packet attachment |
1. |
Contractor email address |
||||||
Email with completed Request Packets received via defined and unique Federal Gov't Contractor email address |
2. |
Talisma |
|||||||||
3. |
Request Packet |
||||||||||
3 |
Customer Service |
Confirm Authorization |
Email with Request Packet attachment |
1. |
Agency Master List |
||||||
Compare "from" email address and "Agency Name" to Agency Master List content. If the email address and Agency name do not match that contained in the excel spreadsheet a "non confirmed" email response must be sent. |
2. |
Soft -copy pre-written "non- email |
|||||||||
3. |
Request Packet |
||||||||||
46
4 |
Customer Service |
Review Completeness |
Email with Request Packet attachment |
1. |
Request Packet Requirements Checklist |
||||||
Review Request Packet completeness ensuring that all forms and fields are included paying special attention to ensure minimally that each domain name has all contact information and that Credit Card authorization is included |
2. |
Pre-written common error response emails |
|||||||||
3. |
Request Packet |
||||||||||
5 |
Customer Service |
Review Accuracy |
Email with Request Packet attachment |
1. |
Common Error Checklist |
||||||
Review each form and field to identify incorrect data, data that does not synch from form to form and instances where multiple credit cards are not associated with domain names. |
2. |
Pre-written common error response emails |
|||||||||
3. |
Request Packet |
||||||||||
6 |
Customer Service |
Assess Charge & Assign Order Number |
Email with Request Packet attachment |
1. |
Pricing sheet |
||||||
Audit pricing/billing sheet to ensure numbers tie with domain order forms and pricing calculations are correct. |
2. |
Calculator |
|||||||||
Assign an order number and record such in Talisma and on the paperwork for translation to billing data. |
3. |
Order number tracking sheet |
|||||||||
4. |
Talisma |
||||||||||
5. |
Request Packet |
||||||||||
7 |
Customer Service |
Determine if Request Packet Complete |
Completion of Steps 3,4,5, and 6. |
1. |
Agency Master List Updated |
||||||
Record results of preliminary review steps (steps 3-6) in Talisma and on paperwork. |
2. |
Talisma |
|||||||||
3. |
Request Packet |
||||||||||
47
7a |
Customer Service |
Request Packet Incomplete |
Completion of Step 7. |
1. |
Talisma |
||||||
If Request Packet appears to be complete, does not have common/known errors, and is confirmed as being received from an authorized Agency email account then date/time/rep stamp the packet and forward to Finance. |
2. |
Request Packet |
|||||||||
7b |
Customer Service |
Request Packet Complete |
Completion of Step 7. |
3. |
Email text editor |
||||||
If any error is identified in Steps 3, 4, 5, or 6 such should be record in Talisma and on the paperwork. An email must be crafted with all error details and next steps and then returned to the submitting email address. |
4. |
Talisma Request Packet |
|||||||||
5. |
Request Packet |
||||||||||
8 |
Finance |
Enter Credit Card Transaction |
Credit Card Authorization form sent by Customer Service |
1. |
Fed Gov't SurePay account |
||||||
Enter each Credit card transaction into the Federal Gov't Reserve Name SurePay account via the web interface. The SurePay order number should be the Customer Service assigned order number to support later reconciliation and research. |
2. |
SurePay interface |
|||||||||
3. |
Customer Service assigned order number |
||||||||||
9 |
Finance |
Receive Credit Response |
Entered SurePay transaction |
1. |
|||||||
SurePay shall respond with approval or denial within 5 minutes. The response shall be printed and attached to original credit card authorization noting any pertinent denial information for use by Customer Service. Finance personnel should go to step 14 after sending approvals to Customer Service entry temp or denials to Customer Service lead. |
2. |
Printer |
|||||||||
48
10 |
Customer Service Temp |
Update Contacts |
Credit card approval response from Finance |
1. |
SRS GUI |
||||||
Using the "Modify Domain" transaction command in the CSR GUI change all domain contacts per information contained in the Request Packet. Domain contacts include; |
2. |
"Modify Domain" transaction instructions/job aid |
|||||||||
— |
Registrant |
3. |
Request Packet |
||||||||
— |
Billing |
||||||||||
— |
Administrative |
||||||||||
— |
Billing |
||||||||||
Note the registrant password should be entered into the "name- value pair" field to verify authorization of later changes |
|||||||||||
11 |
Customer Service Temp |
Update Registration Period |
Credit card approval response from Finance |
1. |
SRS GUI |
||||||
Using the "renew domain" transaction command in the CSR GUI update the registration period for each domain as indicated in the Request Packet. |
2. |
"Renew Domain" transaction instruction/job aid |
|||||||||
12 |
Customer Service Temp |
Send Confirmation |
Completion of Steps 10 and 11 |
1. |
Pre-written confirmation email text |
||||||
Draft confirmation email (utilizing pre-written template) listing all completed/updated domain names, their registration period, and the total credit card charge. |
2. |
List of entered domain names |
|||||||||
3. |
Credit card charge details |
||||||||||
49
13 |
Customer Service Temp |
Review & File |
1. |
Full Request Packet with activity not es and date/time stamps |
|||||||
Ensure that all necessary activities have been completed and properly noted on paperwork and in Talisma with order number cross- reference. Check Whois and Speed of Light to confirm DNS and Whois propogation. |
2. |
SRS GUI |
|||||||||
All paperwork to include at least the following must be filed for later retrieval. |
3. |
usTLD Whois |
|||||||||
— |
Initial Request |
4. |
Speed of Light |
||||||||
— |
Order Number |
||||||||||
— |
Date/time/rep stamps for each activity and disposition |
||||||||||
— |
SurePay approval/denial response |
||||||||||
14 |
Finance |
Record Billing Transaction |
Step 9 |
1. |
Peoplesoft |
||||||
Create a daily Peoplesoft (billing system) transaction tracking all SurePay submissions. |
2. |
SurePay |
|||||||||
15 |
Finance |
Reconcile w/Daily |
1. |
List of prior credit card submissions |
|||||||
Reconcile daily SurePay bank clearance list with prior SurePay transaction submissions to ensure accuracy and completeness. Upon accurate reconciliation clear/close Peoplesoft transaction for posting. |
|||||||||||
50
16 |
Customer Service |
Audit Review SRS Inventory and Activity reports comparing such to Billing and Talisma activity reports to ensure full reconciliation. Audit approach must confirm that no domain orders have been lost or added and that no financial transactions have been lost or duplicated. |
1. |
SRS Reserve Name Activity Report |
|||||||
2. |
SRS Reserve Name Inventory List |
||||||||||
3. |
Agency Master List with disposition notes |
||||||||||
4. |
SurePay Activity List |
||||||||||
5. |
Peoplesoft Activity List |
Note: This process only represents Federal reserve name allocation activities conducted after system and tool development, training, and SurePay account set-up and does not fully represent the error correction process for submissions that are denied payment authorization or otherwise do not meet the Contractor's full information requirements.
51
Option
1
Permanent Reservation: $152
Option
2
Three-year registration: $168 ($56 per year)
Option
3
Five-year registration: $180 ($36 per year)
Option
4
Lifetime registration: $395
Note: all prices listed above represent up front fees that must be paid at the time the registration is processed. For example, for a three-year registration, the Contractor will charge the registrant $168.
52
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0005 |
||||
3. |
Effective Date |
December 23, 2002 |
||||
4. |
Requisition/Purchase Req. No. |
|||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code 000SB National Inst. Of Stds. And Technology 100 Bureau Drive Stop 3571 Building 301 Room B129 Gaithersburg, MD 20899-3571 Widdup, Joseph 301-975-6324 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NEUSTAR 1120 Vermont Avenue NW Suite 400 Washington, DC 20005 Vendor ID: 00007158 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
610100010204000090919000090000090900000000000000$US 0.00 |
||||
53
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) |
|||||
Set forth item 14, pursuant to the authority of FAR 43.103(a). |
||||||
(X) |
C. |
This supplemental agreement is entered into pursuant to authority of: FAR 43.103(a) |
||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
A. |
The purpose of this modification is to incorporate the usTLD Federal, State and Local Name Request Registration Process that is found on the continuation pages of this modification. |
|||||
END OF TEXT |
usTLD Federal, State and Local Name Request Registration Process
Introduction
Prior to the launch of the second-level us domain space, the Contractor, in consultation with the National Telecommunications and Information Administration (NTIA) within the U. S. Department of Commerce, reserved certain Federal, State, and Local names from open registration to ensure their availability to Federal, State and Local governments.The process for registering these reserved names was incorporated into this purchase order via Modification No. 0004.
Additional Governmental Name Requests
Recently, representatives from Federal, State and Local government agencies have requested that additional names be registered under the Reserved Name Process. Consistent with the Contractor's obligations under this purchase order to serve the needs and interests of these users of the usTLD, the Contractor must accommodate such requests following the process described below.There is no deadline or limited time period for requests for additional names under the Reserved Name Process, as modified.
Additional Governmental Name Registration Process
In order to register additional names, a Federal, State, or Local governmental agency, department or bona fide representative must follow these steps:
Step One
54
Step Two
Step Three
Requests by a Governmental Agency for Names Currently Registered by the General Public
The Contractor must maintain a list of those names, presently registered by members of the general public, for which representatives of Federal, State or Local government request a reservation in the event that such general public registrations expire. Upon expiration of such registrations, the Contractor must remove the requested name(s) from the general pool of names available for public registration and place them on the Reserved Name List.The Contractor must inform the Federal, State or Local governmental representative who requested the reservation that the requested name(s) is now available for registration under the Reserved Name Process, and process the Federal, State or Local governmental entity's request pursuant to the requirements set forth in this modification to the purchase order.
55
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0006 |
||||
3. |
Effective Date |
January 13, 2003 |
||||
4. |
Requisition/Purchase Req. No. |
|||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code 000SB National Inst. Of Stds. And Technology 100 Bureau Drive Stop 3571 Building 301 Room B129 Gaithersburg, MD 20899-3571 Widdup, Joseph 301-975-6324 |
||||
7. |
Administered By (if other than item 6) |
Code 0000013 DOC/NOAA/OFA External Customer Acq. OFA66 1305 East West Highway Suite 7604 Silver Spring, Maryland 20910 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NEUSTAR 1120 Vermont Avenue NW Suite 400 Washington, DC 20005 Vendor ID: 00007158 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
56
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
610100010020400009091900009000009090000000000000$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
(X) |
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) |
||||
Set forth item 14, pursuant to the authority of FAR 43.103(b). |
||||||
C. |
This supplemental agreement is entered into pursuant to authority of: |
|||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor ý is not, o is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
A. |
The purpose of this modification is to assign administration of all functions listed in Federal Acquisition Regulation (FAR) Subparts 42.302(a) and 42.302(b) to the agency listed in Block 7 of this modification. |
|||||
B. |
This assignment is effective on the date that appears in Block 3 of this modification. |
|||||
END OF TEXT |
57
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0007 |
||||
3. |
Effective Date |
February 13, 2003 |
||||
4. |
Requisition/Purchase Req. No. |
NTIA907-3-0055SS |
||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code AMD00065 DOC/NOAA/OFA/ External Customers c/o CAMS Support Center 209 Perry Parkway, Suite 5 Gaithersburg, MD 20877-2171 Joel L. Perloth 301-258-4505 x258 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NEUSTAR 1120 Vermont Avenue NW Suite 400 Washington, DC 20005 Vendor ID: 00007158 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
58
12. |
Accounting and Appropriation Data (if required) |
$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
|||||
(X) |
C. |
This supplemental agreement is entered into pursuant to authority of: FAR 52.243-1 "Changes", FAR 43, and MUTUAL AGREEMENT OF BOTH PARTIES |
||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
Modification no.: 0007 under Purchase Order No. SB1335-02-W-0175 ("the Contract") for management of the.us domain by NeuStar, Inc. ("the Contractor") sets forth the implementation and operation of a second level domain in .us domain pursuant to the "DotKids Implementation and Efficiency Act of 2002," Public Law No. 107-317. On December 4, 2002, President George W. Bush signed this law requiring NTIA to establish a second level domain within the.us domain to provide access to material that is suitable for and not harmful to minors. |
||||||
15.A |
Name and Title of Signer (Type or Print) |
|||||
15B. |
Contractor/Offeror |
|||||
15C. |
Date Signed |
|||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Joel L. Perlroth Contracting Officer Joel.L.PerlrothAnoaa.gove 301-258-4505 x258 |
||||
16B. |
United States of America |
/s/ Joel L. Perlroth |
||||
16C. |
Date Signed |
59
Implementation and Operation of "Kids" Second Level Domain
This document describes the Contractor requirements to establish, operate and maintain a second level domain within the United States country code top level domain as required by Section 4 of Pub. Law No. 107-317. Each of the following tasks shall be completed in accordance with the requirements of Pub. Law No. 107-317.
60
i. usTLD Dispute Resolution Policy and Rules;
ii. The usTLD Nexus Requirements;
iii. Nexus Dispute Policy and Rules; and
iv. Registration Review Policy (April 22, 2002)
All requirements, rules, processes, procedures, mechanisms, fees, agreements and subcontracts required to implement the kids.us domain shall be subject to the Contracting Officer's approval.
61
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0008 |
||||
3. |
Effective Date |
May 1, 2003 |
||||
4. |
Requisition/Purchase Req. No. |
AJF60000-3-01088 |
||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code AMD00065 DOC/NOAA/OFA/ External Customers. c/o CAMS Support Center 209 Perry Parkway, Suite 5 Gaithersburg, MD 20877 Joel L. Perloth 301-258-4505 x258 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NeuStar, Inc. 46000 Center Oak Plaza Building 10 Sterling VA 20166 Vendor Id: 00001032 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
62
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
|||||
(X) |
C. |
This supplemental agreement is entered into pursuant to authority of: FAR 52.243-1 "CHANGES", FAR 43 and Mutual Agreement of the Parties |
||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
Modification No.: 0007 under Purchase order No.: SB1335-02-W-0175 set forth the implementation and operation of a second level domain in.us domain pursuant to the "Dot Kids Implementation and Efficiency Act of 2002" Public Law No. 107-317 |
||||||
This Modification No.: 0008 is being issued to add a new subsection (e) under paragraph 10. Accordingly, paragraph 10 is being deleted and replaced in its entirety. |
||||||
15A. |
Name and Title of Signer (Type or Print) |
Jeffrey J. Neuman Director, Law & Policy, NeuStar, Inc. Jeff.Neuman@NeuStar.US |
||||
15B. |
Contractor/Offeror |
/s/ Jeffrey J. Neuman |
||||
15C. |
Date Signed |
May 1, 2003 |
||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Joel L. Perlroth Contracting Officer Joel.L.Perlroth@noaa.gov 301-258-4505 x258 |
||||
16B. |
United States of America |
/s/ Joel L. Perlroth |
||||
16C. |
Date Signed |
May 1, 2003 |
||||
63
Schedule |
||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Item No. |
Supplies/Services |
Quantity |
Unit |
Unit Price |
Amount |
|||||
0001 |
BASE PERIOD |
4 |
YR |
0.00 |
0.00 |
|||||
The Contractor must perform the services required by the SOW. |
||||||||||
Period of Performance: 4 years, beginning on the date of purchase order award |
64
Implementation and Operation of "Kids" Second Level Domain
This document describes the Contractor requirements to establish, operate and maintain a second level domain within the United States country code top level domain as required by Section 4 of Pub. Law No. 107-317. Each of the following tasks shall be completed in accordance with the requirements of Pub. Law No. 107-317.
65
All requirements, rules, processes, procedures, mechanisms, fees, agreements and subcontracts required to implement the kids.us domain shall be subject to the Contracting Officer's approval.
66
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0009 |
||||
3. |
Effective Date |
August 19, 2003 |
||||
4. |
Requisition/Purchase Req. No. |
AJF60000-3-01423 |
||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code AMD00065 DOC/NOAA/OFA/ External Customers c/o CAMS Support Center 209 Perry Parkway, Suite 5 Gaithersburg, MD 20877-2171 Joel L. Perloth 301-258-4505 x258 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NeuStar, Inc. 46000 Center Oak Plaza Building 10 Sterling VA 20166 Vendor Id: 00001032 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14, the hour and date specified for receipt of offers is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
67
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
|||||
(X) |
C. |
This supplemental agreement is entered into pursuant to authority of: FAR 52.243-1 "CHANGES", FAR 43 and Mutual Agreement of the Parties |
||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
Modification No.: 0009 under Purchase order No.: SB1335-02-W-0175 is being issued to accomplish the following: |
||||||
1. |
To extend the date for the usTLD Reserved Name Registration Process until September 30, 2003. |
|||||
15A. |
Name and Title of Signer (Type or Print) |
Jeffrey J. Neuman Director, Law & Policy, NeuStar, Inc. Jeff.Neuman@NeuStar.US |
||||
15B. |
Contractor/Offeror |
/s/ Jeffrey J. Neuman |
||||
15C. |
Date Signed |
|||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Joel L. Perlroth Contracting Officer Joel.L.Perlroth@noaa.gov 301-258-4505 x258 |
||||
16B. |
United States of America |
/s/ Joel L. Perlroth |
||||
16C. |
Date Signed |
68
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
U.
S. Department of Commerce
National Telecommunications and Information Administration (NTIA)
1401 Constitution Ave., Room 4720
Washington, D.C. 20230
Phone: (202) 482-0775
E-mail: BKFulton(untia.doc.gov
0001 | BASE PERIOD | 4 | YR | 0.00 | 0.00 | |||||
The Contractor must perform the services required by the SOW. Period of Performance: 4 years, beginning on the date of purchase order award |
69
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0010 |
||||
3. |
Effective Date |
September 30, 2003 |
||||
4. |
Requisition/Purchase Req. No. |
AJF60000-4-00024 |
||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code AMD00065 DOC/NOAA/OFA/ External Customers c/o CAMS Support Center 209 Perry Parkway, Suite 5 Gaithersburg, MD 20877-2171 Joel L. Perloth 301-258-4505 x258 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NeuStar, Inc. 46000 Center Oak Plaza Building 10 Sterling VA 20166 Vendor Id: 00001032 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
70
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
|||||
(X) |
C. |
This supplemental agreement is entered into pursuant to authority of: FAR 52.243-1 "Changes", FAR 43, and Mutual Agreement of the Parties |
||||
D. |
Other (specify type of modification and authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
|||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
Modification No: 0010 under Purchase Order No. SB1335-02-W-0175 is being issued to accomplish the following: |
||||||
1. |
To extend the date for the Coordination and Management of the.us Top Level Domain (usTLD) Reserved Name Registration Process until December 31, 2003. |
|||||
2. |
To implement interim content monitoring procedures as follows: |
|||||
15.A |
Name and Title of Signer (Type or Print) |
James A. Casey Director, Policy and Bus. Development |
||||
15B. |
Contractor/Offeror |
/s/ James A. Casey |
||||
15C. |
Date Signed |
10/20/03 |
||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Joel L. Perlroth Contracting Officer Joel.L.Perlroth@noaa.gov 301-258-4505 x258 |
||||
16B. |
United States of America |
/s/ Joel L. Perlroth |
||||
16C. |
Date Signed |
10-29-03 |
SF 30 Continuation of Block Narrative
Consistent with Section 10 Paragraph (e) of Modification 8 to the.us requirements, the Contractor shall serve as Content Manager and is therefore responsible for the content review at the initial stage and through ongoing monitoring. The Contractor may perform these duties directly or subcontract a portion or all of these duties to a third party(ies).
71
Item No. |
Supplies/Services |
Quantity |
Unit |
Unit Price |
Amount |
|||||
---|---|---|---|---|---|---|---|---|---|---|
0001 |
BASE PERIOD |
4 |
YR |
0.00 |
0.00 |
|||||
The Contractor must perform the services required by the SOW. |
72
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0011 |
||||
3. |
Effective Date |
December 31, 2003 |
||||
4. |
Requisition/Purchase Req. No. |
|||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code AMD00065 DOC/NOAA/OFA/ External Customers c/o CAMS Support Center 209 Perry Parkway, Suite 5 Gaithersburg, MD 20877-2171 Carol A. Silverman 301-258-4506 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NeuStar, Inc. 46000 Center Oak Plaza Building 10 Sterling VA 20166 Vendor Id: 00001032 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
73
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
|||||
C. |
This supplemental agreement is entered into pursuant to authority of: |
|||||
(X) |
D. |
Other (specify type of modification and authority). Mutual agreement of the parties. (Ref: Contractor Request dated 12/23/03) |
||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
The purpose of this modification is to extend the date for the coordination and management of the .us Top Level Domain (usTLD) Reserved Name Registration Process until March 31, 2004. |
||||||
All other terms and conditions of Order No. DG1335-02-W-0175 remain the same. |
||||||
15A. |
Name and Title of Signer (Type or Print) |
|||||
15B. |
Contractor/Offeror |
|||||
15C. |
Date Signed |
|||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Carol A. Silverman Contracting Officer csilverman@doc.gov 301-258-4506 |
||||
16B. |
United States of America |
/s/ Carol A. Silverman |
||||
16C. |
Date Signed |
December 31, 2003 |
Item No. |
Supplies/Services |
Quantity |
Unit |
Unit Price |
Amount |
|||||
---|---|---|---|---|---|---|---|---|---|---|
74
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. |
Contract Id Code |
|||||
2. |
Amendment/Modification No. 0012 |
|||||
3. |
Effective Date |
March 31, 2004 |
||||
4. |
Requisition/Purchase Req. No. |
AJF60000-4-00560 |
||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code AJF60012 DOC/NOAA/OFA/ External Customers Acq. OFA66 1305 East West Hwy, Suite 7604 Silver Spring, MD 20910 Joel L. Perloth 301-713-0838 x205 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NeuStar, Inc. 46000 Center Oak Plaza Building 10 Sterling VA 20166 Vendor Id: 00001032 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOUR ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
75
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
(X) |
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
||||
C. |
This supplemental agreement is entered into pursuant to authority of: |
|||||
D. |
Other (specify type of modification and authority). |
|||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
The purpose of this Modification No. 0012 under Purchase Order No. SB1335-02-W-0175 is being issued to accomplish the following: |
||||||
1. |
To extend the date for the coordination and management of the .us Top Level Domain (usTLD) Reserved Name Registration Process until June 30, 2004. |
|||||
15A. |
Name and Title of Signer (Type or Print) |
|||||
15B. |
Contractor/Offeror |
|||||
15C. |
Date Signed |
|||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Joel L. Perlroth Contracting Officer Joel.L.Perlroth@noaa.gov 301-713-0838 x205 |
||||
16B. |
United States of America |
/s/ Joel L. Perlroth |
||||
16C. |
Date Signed |
March 31, 2004 |
SF 30 Continuation of Block Narrative
2. To accept the contractors proposed fee of $65.00 per domain name for the direct registration of the reservation list for kids.us
All other terms and conditions remain unchanged.
Schedule |
||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Item No. |
Supplies/Services |
Quantity |
Unit |
Unit Price |
Amount |
|||||
0001 |
BASE PERIOD |
4 |
YR |
0.00 |
0.00 |
|||||
The Contractor must perform the services required by the SOW. |
||||||||||
Period of Performance: 4 years, beginning on the date of purchase order award |
76
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0013 |
||||
3. |
Effective Date |
June 1, 2004 |
||||
4. |
Requisition/Purchase Req. No. |
AJF60000-4-01203 |
||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code AJF60012 DOC/NOAA/OFA/ External Customers Acq. OFA66 1305 East West Hwy, Suite 7604 Silver Spring, MD 20910 Joel L. Perloth 301-713-0838 x205 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NeuStar, Inc. 46000 Center Oak Plaza Building 10 Sterling VA 20166 Vendor Id: 00001032 DUNS: 112403295 CAGE: |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
77
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
|||||
C. |
This supplemental agreement is entered into pursuant to authority of: |
|||||
(X) |
D. |
Other (specify type of modification and authority) Mutual agreement of the Parties. |
||||
E. |
IMPORTANT: Contractor o is not, ý is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
Modification No. 0013 under Purchase Order No. SB1335-02-W-0175 is being issued to implement the EPP-complaint Redemption Grace Period (RGP) for ".US" domain names in accordance with the attached proposal. |
||||||
15A. |
Name and Title of Signer (Type or Print) |
Jeffrey J. Neuman Director, Law & Policy, NeuStar, Inc. Jeff.Neuman@NeuStar.US |
||||
15B. |
Contractor/Offeror |
/s/ Jeffrey J. Neuman |
||||
15C. |
Date Signed |
June 6, 2004 |
||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Joel L. Perlroth Contracting Officer Joel.L.Perlroth@noaa.gov 301-713-0838 x205 |
||||
16B. |
United States of America |
|||||
16C. |
Date Signed |
OVERVIEW
NeuStar proposed the implementation of a fully automated, EPP-compliant Redemption Grace Period (RGP) for .US domain names. The NeuStar RGP will enable Registrars to restore registered.US domain names that have been inadvertently deleted through registrant or Registrar error, but which are still within a designated 30-day Redemption Period.
STATUSES
In order to remain EPP-complaint, NeuStar will only use domain statuses defined in the current EPP specifications. As such, all domains slated for deletion will remain in PendingDelete status for 35 days or until they are restored.
78
RESTORE COMMAND
NeuStar will use the existing EPP Renew command as the basis for the Restore command. In addition, EPP extensions will be used to capture additional required information as set forth below in the section entitled "Registrar Reporting Requirements."
REPORTS
Registrars may only restore domains in order to correct unintentional deletions caused by the registrant or Registrar. Restoring registered domains in order to assume the rights to use or sell them will be considered a violation of the Registry-Registrar Agreement.
Registrar Reporting Requirements
Registrars must verify their compliance with the intention of the RGP service by submitting a Registrar Restore Report to the Registry. The primary purpose of the report is to identify the circumstance that led to the Restore request. NeuStar will take advantage of its "thick" registry to collect the reporting data at the time the Restore command is submitted. The following data is already collected and stored by the Registry, and as such will not need to be provided separately by the Registrar:
In addition, the following information must be submitted by the Registrar to the Registry as part of the Restore command. Failure to provide all of the follow data at the time the command is submitted will result in a failure to restore the domain name.
NeuStar will retain copies of all Registrar Restore and will provide the United States Department of Commerce with such reports as requested.
79
Registry Reporting Requirements
To facilitate the recirculation of unredeemed domain names back into the publicly available pool of names, NeuStar will provide comprehensive, regularly updated lists of names with a PendingDelete status to all Registrars via an FTP or SCP mechanism; these lists will include corresponding dates of deletion. Other than as set forth in these paragraphs, no Registrars will be able to modify or restore names with a PendingDelete status.
FEES
NeuStar proposed a tiered fee structure as follows:
Please also note that fees associated with the restoration of a domain name through the RGP are separate and apart from the fees that are due and payable to NeuStar for the registration or renewal of a domain name. Thus, if a domain name is deleted within five (5) days of the expiration of a domain name registration and a domain name registrant would like to restore the name through the RGP, the registry would charge the registrar the $6 for the restoration plus $5.50 for the renewal of the domain name. If the restoration occurs more than five (5) days after the expiration of the domain name, the registry would charge the registrar $40 for the restoration of the domain plus $5.50 for the one (1) year renewal of the domain name registration.
80
AMENDMENT OF SOLICITATION/MODIFICATION OF CONTRACT
1. | Contract Id Code | |||||
2. |
Amendment/Modification No. |
0014 |
||||
3. |
Effective Date |
September 21, 2004 |
||||
4. |
Requisition/Purchase Req. No. |
NTIA911-4-0111BF |
||||
5. |
Project No. (If Applicable) |
|||||
6. |
Issued By |
Code AJF60012 DOC/NOAA/OFA/ External Customers,AMD OFA66 1305 East West Hwy, Suite 7604 Silver Spring, MD 20910 Joel L. Perloth 301-713-0838 x205 |
||||
7. |
Administered By (if other than item 6) |
See Block 6 |
||||
8. |
Name And Address Of Contractor (No. Street, County, And Zip Code) |
NeuStar, Inc. 46000 Center Oak Plaza Building 10 Sterling VA 20166-6593 Vendor Id: 00001032 DUNS: 112403295 CAGE: 3DXC3 |
||||
9A. |
ý Amendment Of Solicitation No. |
|||||
9B. |
Date (See Item 11) |
|||||
10A. |
ý Modification Of Contractor/Order No. |
SB1335-02-W-0175 |
||||
10B. |
Date (See Item 13) |
October 26, 2001 |
||||
11 |
THIS ITEM ONLY APPLIES TO AMENDMENTS OF SOLICITATIONS |
|||||
o The above numbered solicitation is amended as set forth in item 14. the hour and date specified for receipt of offers o is extended o is not extended. Offers must acknowledge receipt of this amendment prior to the hour and date specified in the solicitation or as amended, by one of the following methods: (a) By completing item 8 and 15, and returning copies of the amendment; (b) By acknowledging receipt of this amendment on each copy of the offer submitted; or (c) By separate letter or telegram which includes a reference to the solicitation and amendment numbers. FAILURE OF YOU ACKNOWLEDGEMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER. If by virtue of this amendment you desire to change an offer already submitted, such change may be made by telegram or letter, provided each telegram or letter makes reference to the solicitation and this amendment, and is received prior to the opening hour and date specified. |
||||||
12. |
Accounting and Appropriation Data (if required) |
$US 0.00 |
||||
13. |
THIS ITEM APPLIES ONLY TO MODIFICATIONS OF CONTRACT/ORDERS. IT MODIFIES THE CONTRACT/ORDER NO. AS DESIRED IN ITEM 14 |
|||||
81
(X) |
A. |
This change order is issued pursuant to: (Specify authority). The changes set forth in item 14 are made in the Contract Order No. In Item 10A. |
||||
B. |
The above numbered Contract/Order is modified to reflect the administrative charges (such as changes in paying office, appropriation date, etc.) Set forth item 14, pursuant to the authority of FAR 43.103(b). |
|||||
(X) |
C. |
This supplemental agreement is entered into pursuant to authority of: FAR 52.243-1 "Changes", and Mutual Agreement of the Parties |
||||
D. |
Other (specify type of modification and authority) |
|||||
E. |
IMPORTANT: Contractor o is not o, is required to sign this document and return 3 copies to the issuing office. |
|||||
14. |
Description of Amendment/Modification (Organized by UCF section headings, including solicitation/contract subject matter where feasible.) |
|||||
Modification No. 0014 under Purchase Order No. SB1335-02-W-0175, Coordination and Management of the.us Top Level Domain (usTLD) is being issued to end the usTLD Reserved Name Registration Process (RNRP) in a phased manner by December 31, 2004 in accordance with the plan and schedule set forth below: |
||||||
15A. |
Name and Title of Signer (Type or Print) |
Jeffrey J. Newman, Esq. Director, Law & Policy, NeuStar, Inc. Jeff.Neuman@NeuStar.US |
||||
15B. |
Contractor/Offeror |
/s/ Jeffrey J. Neuman |
||||
15C. |
Date Signed |
September 21, 2004 |
||||
16A. |
Name and title of Contracting Officer (Type or Print) |
Joel L. Perlroth Contracting Officer Joel.L.Perlroth@noaa.gov 301-713-0838 x205 |
||||
16B. |
United States of America |
/s/ Joel L. Perlroth |
||||
16C. |
Date Signed |
September 24, 2004 |
PHASES:
Phase 1—Review and Cleansing of Reserve List
NeuStar will undertake a thorough review of all registration applications received to date. Shared Registration System (SRS) registration data will be crosschecked with any payments received. At the conclusion of this process, a definitive list of non-registered/non-reserved domain names will be created. This list will be used to complete the remaining phases. A keyword scan will be performed against the entire set of names will be created. This list will be used to complete the remaining phases. A keyword scan will be performed against the entire set of non-registered reserved names to identify any potentially sensitive domain names. These domain names will be set aside for further manual review at a later stage. During this period, NeuStar will work, with the Department of Commerce to make every reasonable effort to reach out to the various affinity groups to notify them of the conclusion of the reserved name program. NeuStar will publish a press release, send letters, send e-mail, make direct telephone calls, and where possible create articles to be published in relevant affinity group and stakeholder newsletters. In addition, NeuStar will provide an announcement on the official.us website.
82
Phase 2—Release of Local Names
This phase will involve the release of all unregistered or unreserved local names. This includes any city, town, village, borough, rancheria, community, or county name. This list will contain approximately 51,000 domain names. The names will be released in bulk, however due to the large number of names, the release will occur over a period of several hours.
Phase 3—Release of all State and Indian Reservation Names
All unregistered or unreserved State and Indian Reservation domain names will be released. This will include the various on each name, and state mottos. This list will contain approximately 600 domain names.
Phase 4—Interim Review
With prior approval of the NTIA, NeuStar will develop a permanent reservation list from the federal government domain names.
Phase 5—Release of Remaining Names
All remaining names not placed in the permanently reserved state during Phase 4 will be released at this point.
SCHEDULE
December 15,
2004
Phase 5 completed (Release remaining names)
83
Transmittal Letter/Forms | Tab | |||
Acronyms/ Clarification of Terms | Tab | |||
Compliance Matrix | Tab | |||
Solution Summary | Tab | |||
A. usTLD Team | A-1 | |||
B. Contractor Requirements | B.1 | |||
B.1 | Statement of Purpose | B.1-1 | ||
B.2 | Core Registry Functions | B.2-1 | ||
B.2.1 | Primary usTLD Server | B.2-2 | ||
B.2.1.1 | NeuStar's Multiple Primary Nameservers | B.2-3 | ||
B.2.1.2 | General Description of Proposed Facilities and Systems | B.2-3 | ||
B.2.1.3 | Description of System Functions | B.2-6 | ||
B.2.2 | Secondary usTLD Servers | B.2-8 | ||
B.2.3 | usTLD Zone Files | B.2-9 | ||
B.2.3.1 | Current Zone File Generation—Problems and Solution | B.2-9 | ||
B.2.3.2 | Secure Access to Update Zone File Data | B.2-10 | ||
B.2.3.3 | Frequency of Zone File Generation | B.2-11 | ||
B.2.3.4 | Zone File Generation Architecture | B.2-11 | ||
B.2.3.5 | Zone File Distribution and Publication | B.2-11 | ||
B.2.3.6 | Locations and Architecture | B.2-12 | ||
B.2.3.7 | Frequency of Zone File Publication/Update | B.2-13 | ||
B.2.4 | Whois Database | B.2-13 | ||
B.2.5 | usTLD Delegated Manager Database Administration | B.2-15 | ||
B.2.6 | Data Escrow | B.2-16 | ||
B.2.7 | Industry Representation/Compliance | B.2-17 | ||
B.2.8 | usTLD Public Awareness Initiatives | B.2-18 | ||
B.2.8.1 | Executive Summary | B.2-18 | ||
B.2.8.2 | Background | B.2-19 | ||
B.2.8.3 | Strategic Goal | B.2-20 | ||
B.2.8.4 | Customer Base | B.2-20 | ||
B.2.8.5 | Marketing Objectives | B.2-24 | ||
B.2.8.6 | Market Definition | B.2-24 | ||
B.2.8.7 | Market Opportunity | B.2-28 | ||
B.2.8.8 | Value Proposition | B.2-28 | ||
B.2.8.9 | Channel | B.2-31 | ||
B.2.8.10 | Marketing Plan | B.2-32 | ||
B.2.9 | Integration Assistance | B.2-34 | ||
B.2.10 | Compliance Monitoring | B.2-35 | ||
B.2.11 | Web Site | B.2-36 |
84
B.2.12 | Documentation and Training | B.2-37 | ||
B.2.13 | Customer Relationship Management | B.2-39 | ||
B.2.14 | Reporting | B.2-40 | ||
B.2.15 | Progress and Quarterly Reporting | B.2-41 | ||
B.2.16 | Help Desk | B.2-41 | ||
B.3 | Core Policy Requirements | B.3-1 | ||
B.3.1 | US Nexus Requirement Implementation | B.3-3 | ||
B.3.2 | Open ccTLD Policies Adoption | B.3-5 | ||
B.3.3 | usTLD Dispute Policies and Sunrise Policy/Implementation | B.3-6 | ||
B.3.3.1 | usTLD Dispute Resolution Policy | B.3-6 | ||
B.3.3.2 | Sunrise Policy and Implementation | B.3-8 | ||
B.3.4 | GAC Principles | B.3-10 | ||
B.3.5 | Additional, Alternative, or Supplemental Policies | B.3-10 | ||
B.4 | Locality-Based usTLD Structure Functions | B.4-1 | ||
B.4.1 | Existing Delegees and Registrants Service Provision | B.4-2 | ||
B.4.1.1 | Needs of Existing Users | B.4-2 | ||
B.4.1.2 | Implementing Services for Delegees | B.4-3 | ||
B.4.1.3 | Providing Support for Registrants | B.4-3 | ||
B.4.2 | Undelegated Third Level SuB.domains Service Provision | B.4-4 | ||
B.4.2.1 | Additional Needs of Undelegated Domains | B.4-6 | ||
B.4.2.2 | Implementing Registrar Services | B.4-6 | ||
B.4.2.3 | Providing Registry Services | B.4-7 | ||
B.4.3 | Locality-Based Process Modernization | B.4-7 | ||
B.4.4 | Current Locality-Based usTLD Users Coordination | B.4-8 | ||
B.4.5 | Compliance with Current Locality-Based usTLD Polices Investigation and Report | B.4-8 | ||
B.4.6 | usTLD Delegated Manager Database Development | B.4-12 | ||
B.4.7 | Whois Database Development | B.4-14 | ||
B.5 | Expanded usTLD Space Functions | B.5-1 | ||
B.5.1 | usTLD Shared Registration System | B.5-2 | ||
B.5.2 | Accreditation Process for usTLD Registrars | B.5-3 | ||
B.5.3 | Technical Certification of usTLD Registrars | B.5-4 | ||
B.5.4 | Whois Database Development | B.5-7 | ||
B.5.5 | Community Outreach Plan | B.5-9 | ||
C. NeuStar's Vision of the usTLD | C-1 | |||
D. Enhancing the Utility of the usTLD | D-1 | |||
E. Current State of the usTLD Domain Space | E-1 | |||
F. Centralized usTLD Database and Enhanced Shared Registration System | F-1 | |||
F.1 | Enhanced Shared Registration System | F-2 | ||
F.2 | Centralized usTLD Database | F-3 | ||
G. Draft Delegated Managers/Administrator Contract | G-1 |
85
H. Draft Registrar/Registry Contract | H-1 | |||
I. Start-up Phase Policies | I-1 | |||
J. Registration Process | J-1 | |||
K. Outreach to Current Locality-based usTLD Users | K-1 | |||
L. Funding for the usTLD | L-1 | |||
M. Description of Cost Elements | M-1 | |||
N. Pro Forma Projections | N-1 | |||
O. Proposed Technical Plan | O-1 | |||
O.1 | Proposed Technical Facilities and Systems | O-2 | ||
O.1.1 | Registry Facilities Site Description | O-2 | ||
O.1.1.1 | Enhanced Shared Registration System (SRS) Data Center Functional Description | O-2 | ||
O.1.1.2 | Nameserver Sites Functional Description | O-5 | ||
O.1.1.3 | Enhanced SRS Data Center and Nameserver Buildings | O-6 | ||
O.1.2 | Enhanced Shared Registration System Descriptions | O-8 | ||
O.1.2.1 | Enhanced SRS Data Center System Descriptions | O-10 | ||
O.1.2.2 | Nameserver Description | O-14 | ||
O.1.3 | Registry Network System Description | O-15 | ||
O.1.3.1 | Internet Connectivity | O-15 | ||
O.1.3.2 | VPN Registry Management Network | O-16 | ||
O.1.4 | Registry System Application Software | O-16 | ||
O.1.4.1 | Application Components | O-16 | ||
O.1.4.2 | Registry Software Development Methodology | O-19 | ||
O.2 | Registry-Registrar Model and XRP Protocol | O-22 | ||
O.3 | NeuStar's Database Capabilities | O-23 | ||
O.3.1 | Functional Overview | O-23 | ||
O.3.2 | Database System Description | O-26 | ||
O.3.3 | Database Security and Access Privileges | O-32 | ||
O.4 | Zone File Generation | O-33 | ||
O.4.1 | Secure Access to Update Zone File Data | O-33 | ||
O.4.2 | Zone File Generation Architecture | O-34 | ||
O.5 | Zone File Distribution and Publication | O-35 | ||
O.5.1 | Locations of Data Centers Housing Zone File Nameservers | O-35 | ||
O.5.2 | Zone File Publication/Update Architecture | O-35 | ||
O.6 | Billing and Collection System | O-37 | ||
O.6.1 | Technical Capabilities and Characteristics | O-37 | ||
O.6.2 | Security | O-43 | ||
O.6.3 | Access Privileges | O-44 | ||
O.6.4 | Backup and Recovery | O-45 | ||
O.6.5 | Billing and Collection Audits | O-46 | ||
O.7 | Data Escrow and Backup | O-47 |
86
O.7.1 | Frequency and Procedures for Backup of Data | O-47 | ||
O.7.2 | Backup Hardware and Software Systems | O-48 | ||
O.7.3 | Procedures for Retrieval of Data and Rebuild of the Database | O-48 | ||
O.8 | Whois Databases for Both Registrars and Delegated Managers | O-49 | ||
O.8.1 | Whois Service Functional Description | O-50 | ||
O.8.2 | Whois System Architecture | O-52 | ||
O.8.3 | Network Speed and Proposed Service Levels | O-52 | ||
O.9 | System Security | O-54 | ||
O.9.1 | System Security | O-54 | ||
O.9.1.1 | Enhanced Shared Registration System Data Center Security | O-55 | ||
O.9.1.2 | Nameserver Data Center Security | O-58 | ||
O.9.2 | Physical Security | O-59 | ||
O.10 | Peak Capacities | O-61 | ||
O.10.1 | Enhanced SRS Peak Capacity | O-61 | ||
O.10.2 | Whois Peak Capacity | O-62 | ||
O.10.3 | DNS Query Peak Capacity | O-63 | ||
O.11 | System Reliability | O-64 | ||
O.11.1 | Quality of Service and Performance Measurements | O-64 | ||
O.12 | System Outage Prevention | O-65 | ||
O.13 | System Recovery Procedures | O-71 | ||
O.13.1 | Restoring Enhanced SRS Operations in the Event of a System Outage | O-71 | ||
O.13.2 | Redundant/Diverse Systems for Providing Service in the Event of an Outage | O-73 | ||
O.13.3 | Process for Recovery From Various Types of Failures | O-74 | ||
O.13.4 | Training of Technical Staff Who Will Perform Recovery Procedures | O-76 | ||
O.13.5 | Software and Operating Systems for Restoring System Operations | O-76 | ||
O.13.6 | Hardware Needed To Restore and Run the System | O-76 | ||
O.13.7 | Backup Electrical Power Systems | O-76 | ||
O.13.8 | Projected Time for Restoring the System | O-77 | ||
O.13.9 | Testing the System Restoration Process | O-77 | ||
O.13.10 | Documenting System Outages | O-77 | ||
O.13.11 | Documenting System Problems That Could Result in Outages | O-77 | ||
O.14 | Technical and Other Support | O-78 | ||
O.14.1 | Technical Help Systems | O-78 | ||
O.14.2 | Staffing | O-80 | ||
O.14.3 | Test and Evaluation Facility | O-80 | ||
O.14.4 | Customer Satisfaction Survey | O-80 | ||
P. Past Performance | P-1 | |||
P.1 | Registry, Database, and Internet Experience | P-7 | ||
P.2 | Technical Capabilities | P-9 | ||
P.3 | Past Performance References | P-11 | ||
Q. Performance Measurements | Q-1 |
87
R. Offerors Representations and Certifications | R-1 | |||
S. NeuStar's DUNs Number | S-1 | |||
T. Transition and Project Plan | T-1 | |||
T.1 | Transition to New usTLD Administrator | T-2 | ||
T.1.1 | Requirements for Successful Transition | T-2 | ||
T.1.2 | Time Line for Transition | T-4 | ||
T.1.3 | Implementation | T-5 | ||
T.1.4 | Resources | T-5 | ||
T.2 | Project Plan | T-5 | ||
T.2.1 | High-level Task Descriptions | T-7 | ||
T.2.2 | Staffing and Organization | T-8 | ||
T.2.3 | Monitoring, Control, and Change Management | T-8 | ||
T.2.4 | Quality Assurance | T-8 |
88
AAA |
American Arbitration Association |
|
ACD |
Automatic Call Distributor |
|
AFNOG |
African Network Operators Group |
|
API |
Application Program Interface |
|
APRICOT |
Asia Pacific Regional Internet Conference on Operational Technologies |
|
ARIN |
American Registry for Internet Numbers |
|
B&C |
Billing and Collections |
|
BEEP |
Blocks Extensible Exchange Protocol |
|
CASE |
Computer-Aided Software Engineering |
|
ccTLD |
Country Code Top-Level Domain |
|
COTR |
Contracting Officer's Technical Representative |
|
CRM |
Customer Relationship Management |
|
DBMS |
Database Management System |
|
DFP |
Dynamic Feedback Protocol |
|
DNS |
Domain Name System |
|
DOC |
Department of Commerce |
|
DUNS |
Data Universal Numbering System |
|
FAQ |
Frequently Asked Questions |
|
FCC |
Federal Communications Commission |
|
ftp |
File Transfer Protocol |
|
GDP |
Gross Domestic Product |
|
gTLD |
Generic Top-Level Domain |
|
http |
Hypertext Transfer Protocol |
|
ICANN |
Internet Corporation for Assigned Names and Numbers |
|
ICC |
International Chamber of Commerce |
|
ID |
Identification |
|
IDL |
Interface Domain Language |
|
IETF |
Internet Engineering Task Force |
|
IP |
Internet Protocol |
|
IPC |
Intellectual Property Constituency |
|
IPNS |
Internet Property Notification Service |
|
89
IPv6 |
Internet Protocol Version 6 |
|
IP Services/Solutions |
Internet Protocol Services or Solutions |
|
ISA |
Inter-State authority |
|
ISO |
International Organization for Standards |
|
ISP |
Internet Service Provider |
|
IT |
Information Technology |
|
IVR |
Interactive Voice Response |
|
LOB |
Line of business |
|
M & P |
Methods and Procedures |
|
MORs |
Monthly Operation Reviews |
|
MTTR |
Mean Time To Repair |
|
N + 1 |
Needed Number Plus One for A Safety Factor |
|
NANPA |
North American Numbering Plan Administrator |
|
NANOG |
North American Network Operators Group |
|
NDP |
Nexus Dispute Policy |
|
NIST |
National Institute of Standards and Technology |
|
NOC |
Network Operations Center |
|
NPAC |
Number Portability Administration Center |
|
NSI |
Network Solutions, Inc. |
|
NTIA |
National Telecommunications and Information Administration |
|
NXX |
Central Office Code (where N is a number greater than 1 and X is a number greater than 0) |
|
OLTP |
Online Transaction Processing |
|
OT&E |
Operational Test & Evaluation |
|
PGP |
Pretty Good Privacy |
|
PKI |
Public Key Infrastructure |
|
POC |
Point of Contact |
|
PSU |
Production Support Unit |
|
QA |
Quality Assurance |
|
RAD |
Rapid Application Development |
|
RAID |
Redundant Array of Independent Disks |
|
RAP |
Registry Authentication Period |
|
RFC |
Request for Comment |
|
RFQ |
Request for Quotation |
|
90
RRP |
Registry-Registrar Protocol |
|
RTK |
Registrar Tool Kit |
|
Rwhois |
Referral Whois protocol |
|
SDA |
Session Distribution Algorithm |
|
SDK |
Software Development Kit |
|
SIPNS |
Start-up Intellectual Property Notification Service |
|
SLA |
Service Level Agreement |
|
SLD |
Second-Level Domain |
|
SMP |
Symmetric Multiprocessing |
|
SMS |
Service Management System |
|
SNMP |
Simple Network Management Protocol |
|
SOW |
Statement of Work |
|
SRS |
Shared Registration System |
|
SSL |
Secure Socket Layer |
|
SW-CMM |
Software Capability Maturity Model |
|
SUDRP |
Start-Up Dispute Resolution Policy |
|
TCP |
Transmission Control Protocol |
|
TLD |
Top-Level Domain |
|
TPC |
Transaction Processing Council |
|
tpsC |
Transactions per second |
|
UAT |
User Acceptance Test |
|
UDRP |
Uniform Dispute Resolution Policy |
|
US$ |
United States dollars |
|
usDRP |
United States Dispute Resolution Policy |
|
usTLD |
us Top-Level Domain |
|
VoIP |
Voice over IP |
|
VPN |
Virtual Private Network |
|
WAP |
Wireless Application Protocol |
|
WIPO |
World Intellectual Property Organization |
|
www |
World Wide Web |
|
XML |
eXtensible Markup Language |
|
XRP |
eXtensible Registry Protocol |
91
Clarification of Terms
Delegee | An entity designated by the past usTLD administrator to be responsible for registering names within the third and fourth levels of the locality-based namespace. | |
Subdelegee |
An entity designated by a delegee to operate a subdomain within the delegee's namespace. The term "delegee" as used in this proposal always includes both delegees and subdelegees. |
|
Delegated Manager |
The term "delegated managers" refers collectively to delegees and subdelegees. |
92
Highlights
Solution Summary
NeuStar, the leading neutral third party administrator of critical public resources, possesses the experience, technical expertise, service capabilities, and integrity to ensure all the DOC's objectives for managing and enhancing the usTLD namespace are met.
The current United States top-level domain (usTLD) is greatly underutilized. The existing hierarchical structure, operational challenges, limited awareness, service level issues, and infrastructure needs have resulted in limited adoption and use by the U.S. community. A great opportunity exists to unlock the potential of the usTLD to the benefit of the American people. Widespread use of the usTLD for e-Gov, consumer, business, and public service applications has the potential to improve the ability of the American people to find information, access services, to communicate, and to transact business.
The new administrator must meet the critical needs identified by the Department of Commerce (DOC) in order for the U.S. Internet community to realize the full benefit of the usTLD. The administrator must:
Develop a more robust, certain, and reliable system.
Promote increased use of the usTLD.
Create a centrally administered and efficiently managed structure that ensures confidence and infrastructure stability.
Create a stable, flexible, and balanced environment within the usTLD that is conducive to innovation and that will meet the future demands of potential registrants.
Ensure continued stability of the domain name system as a whole and the usTLD in particular especially through the transition period from the current to the new management structure.
Manage the usTLD so it is consistent with the Internet Corporation for Assigned Names and Numbers' (ICANN) technical management of the domain name space (DNS).
Allow for the adequate protection of intellectual property in the usTLD.
Establish and maintain consistent communication between the Contracting Officer's Technical Representative (COTR), the Contractor, and ICANN.
Promote robust competition within the usTLD.
In order to meet its objectives, the DOC should seek an administrator that can meet the significant challenges outlined below:
93
resource, including the usTLD, means taking on an obligation to operate in a fair and even-handed manner, providing equal access and service levels to all.
NeuStar is amply qualified to meet these challenges and execute the solution highlighted in the following paragraphs. A chart describing NeuStar's capabilities, qualifications, and experience is attached to the end of this section.
The NeuStar Solution
Integrity is the cornerstone of NeuStar's solution for the usTLD namespace. Our long-term vision of the usTLD is to see it regarded as the world's premier country code top-level domain (ccTLD), and that goal can only be achieved by ensuring that every aspect of its administration is managed with integrity. Integrity permeates every element of our solution and is fundamental to our corporate mission to lead and serve the industry as a neutral third party. We understand that this space is a ccTLD not a generic top-level domain (gTLD) and is exclusively available to serve the needs of U.S. constituents. Therefore, our solution for administering and enhancing the space is structured with that awareness. NeuStar will reach out to the industry and the U.S. public to ensure that the interests of all participants will be incorporated into the administration of the usTLD, and this important public resource will be managed in a manner designed to serve the public interest. Our active, ongoing involvement with the industry provides us with a perspective only experience can impart. We understand the needs and concerns of the industry for the usTLD namespace and this understanding clarifies our responsibility to develop operations and systems that address those needs while conducting ourselves in strict adherence to the principles of a neutral third party. If NeuStar did not firmly believe it could meet and exceed the DOC's objectives for the usTLD, through innovation, dedication, excellence, and integrity, we would not be submitting this proposal. We are committed to managing extremely sensitive proprietary data in an atmosphere of high security and confidentiality and our goal is the equitable treatment of all participating industry players and stakeholders.
94
Our solution can be broken down into four primary components, each of which will be defined below.
NeuStar Service Administration
Every aspect of service administration for the usTLD space must be managed with integrity. NeuStar will do this by ensuring equal access of all industry players and stakeholders to our locality-based and expanded registry services through a thick registry architecture that operates at the highest levels of availability and security. We will coordinate disparate user communities under a stable, centralized umbrella and conduct a phased, customer-focused outreach program through public awareness campaigns, marketing initiatives, and defined, accessible public mechanisms to promote the space as a place for the U.S. and its citizens.
Integrity requires that the usTLD space be operated in a responsible manner. This includes ensuring there is open communication between the administrator and the DOC, seeking on-going feedback from users, and introducing various applications and services. In addition, NeuStar will establish an advisory council made up of parties representative of the multiple constituency interests involved in the space to provide guidance regarding the addition of new features and enhancements. Finally, integrity means ensuring that policies are being applied and followed appropriately. Our approach is a collaborative one through which we will work with industry players and stakeholders to conduct compliance investigations and develop reports. As the usTLD vendor, NeuStar understands that it has several roles to play including administrator, registry, and registrar for unallocated localities. Integrity requires that each of these positions be clearly defined and appropriately managed. NeuStar understands the definitions as well as the distinctions between the three and will serve each role in an independent and neutral manner. A brief summary of some features of our Service Administration follows. More details may be found in Proposal Section B and Sections B.1 through B.5.
Policy Framework
Integrity is essential when we establish policies to ensure they are created to serve the needs of the entire U.S. population, are applied in an even-handed fashion, protect intellectual property and the privacy of individuals, and yet, are not so restrictive as to discourage registrations. NeuStar will ensure, through its policies and processes, that the space is used appropriately as a ccTLD to serve the public interest. This is a unique opportunity to redefine the space, and it is essential that it be done properly.
95
Some highlights of our proposed policy are below and more details about them may be found in Proposal Section B.3 Core Policy Requirements and Proposal Section J Registration Process.
Next Generation Technical Infrastructure
Integrity of our Technical Infrastructure implies several fundamental requirements. The system must work; the name must resolve. It must be robust, secure, dependable, and available on a consistent basis. In addition, it must enable enhanced services thereby enhancing the utility of the usTLD to service all U.S. constituencies. As with our approach for Service Administration, NeuStar will follow an inclusive and responsible process to introduce new uses and will set up mechanisms for feedback. In addition, we will provide documented, disciplined, systematic, quality processes for transition. As the space is operational, we will be introducing new functionality while commercially live and will ensure existing industry players and stakeholders experience a seamless transition. Below we describe some features of our technical infrastructure; detailed descriptions can be found in Proposal Section O.
96
Business Plan
Business Plan integrity implies that an administrator is financially stable and therefore dependable. NeuStar is financially stable. We are not a start-up company. We have a reputation for dependability and integrity. We have been in operation for over five years, have a fully funded business plan, and our original line of business is cash flow and net income positive. Furthermore, with respect to the usTLD space, NeuStar will allocate significant marketing funds to promote it. Another aspect of Business Plan integrity is developing consistent and equitable pricing strategies. In compliance with the RFQ, NeuStar will not charge the government, nor will we charge those who have existing usTLD name registries. For new players, we have highly competitive market rates for registry funding. Our for profit commercial enterprise is the right business model for providing stability and utilization to the namespace. Without profit as a motivator, there is no incentive to be creative or adhere to performance measurements. Risk and reward is an effective vehicle for delivering innovation into a competitive market. Detailed information about our Business Plan can be found in Proposal Sections L, M, and N. A summary of some of its features follows:
NeuStar—Corporate Overview
NeuStar is particularly suited to be the administrator responsible for further developing and improving the usTLD. As the leading provider of mission critical infrastructure and services in North America, NeuStar has as its central purpose, the neutral provisioning of mission critical systems in support of important public resources.
Since its founding in 1996, NeuStar has been selected time and again by the industry in open competitive procurements to provide first-of-a-kind mission critical services. In this capacity, NeuStar
97
designed, built, and manages the Number Portability Administration Center (NPAC), one of the largest databases in the world, and is the North American Numbering Plan Administrator (NANPA) whose duties include operating the public telephone numbering database for North America. Integrity and accuracy are the underpinnings of these services which affects virtually every telephone call placed within the United States and 18 other countries, including Canada. In addition, in a highly competitive bid for expansion of the Internet's Top Level Domains, NeuLevel, a subsidiary of NeuStar, was selected to serve as the registry operator for dot-biz.
The "Neu" in NeuStar refers to its trusted, neutral, third party role. All of its services are available to all service providers on non-discriminatory terms. Its entire staff is sworn to a corporate Code of Conduct and voluntarily subjects itself to independent quarterly audits, reported publicly, verifying its compliance to this Code. The critical nature of the industry functions with which NeuStar has been entrusted leads it to serve all stakeholders: regulators, standards bodies, industry and public interest groups, as well as all segments of the communications industry itself. It does so in a policy-neutral manner, providing important technical and operational subject matter expertise. Its mission is to remain the trusted, neutral third party that all these stakeholders have come to rely upon. The "Star" in NeuStar refers to its central role as a trusted clearinghouse, the hub to which communications networks connect. As the administrator, NeuStar will ensure the usTLD namespace is available to users on a neutral and equitable basis.
For all vendors, past performance is indicative of future accomplishment and NeuStar's serious, corporate commitment to the neutral, even-handed administration of communications resources is peerless. The following descriptions demonstrate our varied and rich experience in providing communications services. For each of our services, NeuStar created the necessary systems from scratch with the long-term interests of the industry in mind. We worked closely with the industry while developing these to ensure we met its initial and ongoing needs. We hope to enjoy that same productive working relationship with the DOC to ensure its evolving priorities and requirements to enhance the operation and utilization of the usTLD are also met.
NeuStar offers a diverse range of products and services for the communications industry that can be broken down into three main categories:
IP Services
"Next-Gen" Registry for dot-biz—NeuStar, through its majority owned NeuLevel joint venture, was recently selected in November, 2000, to operate the new top-level domain registry for dot-biz. The dot-biz registry will be successful because of the combined skill sets of both NeuLevel and NeuStar. NeuLevel is the ICANN accredited registry for dot-biz and provides the marketing, sales, and service delivery of dot-biz registrations. NeuStar, the majority owner of NeuLevel, has designed, is developing, and will implement, operate, and manage the technical infrastructure of the dot-biz "thick" registry platform. NeuStar also provides standards development, external affairs, and additional corporate support services to ensure the success of dot-biz. NeuLevel was selected by the Internet Corporation for Assigned Names and Numbers (ICANN) from over 40 respondents as the result of a worldwide, competitive procurement to develop the only top-level Internet domain created exclusively for business activity. This new TLD will be the place for businesses to establish their presence on the Internet. In addition, dot-biz will open the Internet to more businesses and support the introduction of new products and functionality that will provide increased services for the business community.
98
Convergence Directories—NeuStar is leading the development and introduction of a suite of Global Directory Services that include national and international ENUM administration, as well as next generation signaling standards that will bring intelligent network capabilities to IP based networks. Collectively, NeuStar's Global Directory Services will facilitate the convergence and interoperability of the Public Switched Telephone Network (PSTN) and IP based networks. As co-chair of the Internet Engineering Task Force Working Group (IETF WG) that has finalized the ENUM standard, NeuStar is a recognized leader in the development of technologies required for the introduction of next generation network services. NeuStar continues its leadership role by working closely with the communications industry, regulators, and standards bodies to leverage the ENUM standard to efficiently connect networks and to enable a broad range of converged services.
Numbering Services
North American Numbering Plan Administration (NANPA)—NeuStar operates the telephone numbering registry for the North American Numbering Plan as a public resource, serving customers throughout the United States, Canada, Bermuda, and many of the Caribbean Islands. It is the centralized source for assigning all Number Plan Area (NPA) codes and central office codes, and coordinating NPA code relief as the demand for numbers increases. NeuStar became the NANPA on October 9, 1997 for a five-year period that began formally on February 21, 1998. The Federal Communications Commission (FCC) and the North American Numbering Council (NANC), an industry group advising the FCC on numbering issues, selected NeuStar through a competitive bidding process. NeuStar transitioned this responsibility from the original Regional Bell Operating Companies and the former Bellcore in a highly responsible manner, transparent to the public. As designated in NeuStar's agreement with the FCC and the NANC, NeuStar ensures timely, equitable, and efficient administration of the rapidly growing number of requests for NPA codes and central office codes by working with all industry stakeholders.
Number Portability Administration Center (NPAC)—In April 1996, NeuStar was chosen to serve as the Local Number Portability Administrator (LNPA) through 2003. The contract was recently extended until 2006. In that role, NeuStar operates the routing registry for North America that allows customers to keep their existing phone numbers when changing local service providers. NeuStar's development and operation of the NPAC in Chicago, Illinois, provides a master registry of routing information that interfaces with local carriers. Virtually all calls in North America query a copy of NeuStar's database to be properly routed. Through this center, NeuStar coordinates the porting of local telephone numbers between carriers in North America, serving more than 250 service providers daily and porting more than one million numbers each month.
Number Pooling Administration—As proven by NeuStar, number pooling has the potential to extend the North American Numbering Plan's (NANP) life well into the next century. NeuStar has been the Pooling Administrator for over two years for U.S. pooling trials in several states and number planning areas, and in June, 2001, NeuStar was selected as the National Number Pooling Administer by the FCC. Number pooling, also known as thousands-block pooling, allows for the disbursement of numbers to service providers in 1,000 number parcels. NeuStar worked with the telecommunications industry to develop the initial Pooling Administration guidelines in New York and Illinois in 1997-1998. The current guidelines are based upon those findings and have spurred the demand for pooling implementation in several other states. NeuStar continues to work with the Industry Numbering Council (INC) to suggest and modify changes to current pooling guidelines based upon NeuStar's actual experiences with pooling trials.
ETNS—In March 2001 the European Radiocommunications Office (ERO)—a permanent office of the European Committee on Telecommunications Regulatory Affairs of CEPT (European Conference of Postal and Telecommunications Administrations) and a center of expertise in the fields of licensing, numbering, and radiocommunications—selected NeuStar in a competitive bidding process to manage
99
the establishment of the European Telephony Numbering Space (ETNS) to establish a single country code for all of Europe and assist in enhancing the availability of pan-European telecommunications services. A pan-European service is an international service that can be invoked from at least two European countries. The designation of a new European country code—388—allows European international companies, services, and individuals to obtain a single European Number for accessing their services. In this role, NeuStar will manage a pan-European numbering registry for the provisioning of critical public resources.
OSS Commercial Services
NeuStar's commercial services build on the company's strength as a neutral third-party in developing and managing complex database systems and network elements. New commercial services are designed to help the industry improve operational efficiencies while saving time and money.
CARE Clearinghouse—An industry solution for Customer Account Record Exchange (CARE), the CARE Clearinghouse simplifies the mechanized exchange of customer information between long distance and competitive local exchange carriers. NeuStar's CARE Clearinghouse service supports CARE industry standards. CARE Clearinghouse participants benefit from expedited CARE processing and reduced costs.
IdentiBaseSM—A solution to number registry problems resulting from deregulation, number portability, pooling, and local competition. With IdentiBaseSM, the Local Service Provider of any telephone number—ported, pooled, or not—can be identified whenever it is needed, in whatever format is desired. Information from IdentiBaseSM can help improve billing, provisioning, order entry, trouble management and universal emergency services. IdentiBaseSM's flexible, easy-to-query, timely data allows each department to better serve the customer base, increase revenue, decrease costs, and reduce customer churn.
NeuStar has rich experience in successfully building databases and establishing clearinghouse services that benefit the communications industry and has been widely recognized for this. Yet our expertise is not limited to systems development, and we are not merely a systems developer. We actually operate and support the systems we develop. We manage a complete start-to-finish solution. Working closely with our clients we design, develop, and create systems. We then implement and support them which allows us to understand first-hand any issues that arise and to address them quickly and intelligently. It also enables us to recognize and mitigate problems we encounter and readily adapt appropriate methods and procedures. We will assume direct accountability for the administration of the usTLD from beginning to end, because we provide services, not just systems or software.
In addition, NeuStar's corporate mission is to lead and serve the industry as a neutral third party. Neutrality for us is not a platitude; it is our identity, embodying the impeccable, high-quality, even-handed service essential to the central role we play in the industry. We are committed to impartiality and fairness, and our staff has a history of recognizing the importance of understanding and working successfully with the various industry participants and respecting their differing perspectives within the confines of regulatory environments. Our adherence to the tenets of neutrality does not come from a desire to please nor is it considered an obligation. Rather, it is what we were established to do. Neutrality is a belief we embrace and have embodied in the Code of Conduct available on NeuStar's Web site. We satisfy the strict criteria established for neutrality by the FCC and have been certified as a neutral third party in FCC order 99-346. To ensure our impartiality, we undergo a quarterly neutrality audit. We are committed to managing extremely sensitive proprietary data in an atmosphere of high security and confidentiality and our goal is the equitable treatment of all participating industry players.
100
Conclusion
NeuStar's believes that it is uniquely qualified to ensure the success of the usTLD. Our plan builds on our legacy of managing public resources in a responsible and neutral manner. Neu-Star's proven experience in implementing advanced technologies to meet the needs of the public and private sectors will deliver a high level of service to usTLD registrants and enable the introduction of enhanced services. We are confident that we can transition the administration of the usTLD with zero impact to the current users of the usTLD and begin to enhance the services they currently receive. Widespread adoption and use within the new expanded space will be ensured by the execution of our comprehensive marketing program and through the introduction of a competitive registrar model. NeuStar is committed to working collaboratively with the usTLD stakeholders to facilitate the development of policy that reflects the needs of the community. NeuStar's registries are designed and administered to ensure all industry participants have equal access, its services are provided equitably to all service providers, and its corporate focus is on the industry as a whole. This, in combination with its reputation for integrity, experience, neutrality, and industry expertise makes NeuStar the ideal vendor to administer the usTLD.
The following table provides a detailed display of NeuStar's capabilities, as evidenced by our current projects and past performance.
NeuStar's Capabilities and Qualifications
Vendor Qualification |
NeuStar's Experience |
|||
---|---|---|---|---|
Administration of complex, mission-critical U.S. public resources | • | NeuStar established processes working with the FCC and state commissions for reclamation of central office codes that have not been activated by service providers. | ||
• |
NeuStar developed databases for the tracking of central office code activity for the U.S. |
|||
• |
In conjunction with the industry and FCC, NeuStar developed a new method for reporting utilization and forecasting of numbering resources (NRUF) |
|||
Successfully transitioning administration of mission-critical public resources |
• |
Transitioned Telephone number administration from 10 companies with more than 100 local administrators across all 50 states to one central administrator |
||
• |
Transitioned telephone number inventory from more than 200 local databases to one central database |
|||
• |
Have been contracted to transition telephone number inventory from thousands of local databases across all 50 states to one local database |
|||
Proven neutrality in all business operations |
• |
In CC Docket No. 92-237, FCC 99-346, NeuStar was found to be in compliance with the neutrality requirements put forth in the NANP Administration Third Report and Order. |
||
101
• |
NeuStar undergoes a quarterly Neutrality audit performed by Ernst and Young, with a report forwarded to the FCC, NANC, and NAPM LLC. This report covers the findings of the audit regarding compliance with the NeuStar Code of Conduct and Neutrality Compliance Procedures. NeuStar asserts that it is neutral, and Ernst and Young has agreed in all audit reports. |
|||
Facilitation of controlled, systematic evolution, enhancement, and expansion of the space. |
• |
NeuStar performs the change management administration function for the NPAC SMS on behalf of the telecommunications industry. This includes over 200 change orders resulting in 7 major software releases in 4 years. |
||
• |
NeuStar hosts quarterly NPAC operations forums, known as NPAC Cross regional meetings, where issues pertinent to the operation of the NPAC and its downstream systems are discussed and resolved. |
|||
• |
NeuStar facilitated the transition of state number pooling trials to a national database focusing on a systematic evolution allowing for growth and future enhancements. |
|||
• |
NeuStar works closely with industry and the FCC to develop enhancements to the existing NANPA process, including expansion of current functions. |
|||
Experience designing, building, and supporting robust databases |
• |
NeuStar designed, built, and expanded the NPAC database from inception to its current support of 17 million ported telephone numbers in the database. The growth rate of the database is currently increasing, having surpassed 1 million additional records per month earlier this year. |
||
• |
NeuStar designed and built the pooling administration system to leverage the existing portability infrastructure. An existing NPAC database was adapted and scaled to support number pooling. |
|||
• |
NeuStar developed various NANPA-related databases to enhance functionality and streamline work efforts associated with number administration. This allows for real-time tracking of number assignment, utilization, and forecasting data. |
|||
102
• |
Leveraging its experience with high-availability, mission critical system in the telecommunications industry, NeuStar is developing the next generation DNS architecture for the.biz registry. |
|||
Experience that ensures real-time access to multiple users with a minimum of system outages and downtime |
• |
NPAC offers a Low Tech Interface (LTI) dialup access. This capability currently supports over 700 clients, allowing for simultaneous access by over 200 users. This access method is also fully scalable. |
||
• |
While fully scalable, the NPAC currently supports over 500 dedicated accesses by various service providers. |
|||
Manage a high availability system to contractual service levels |
• |
The NPAC SMS has 29 contractual service level requirements, developed jointly with the industry, which are reported on monthly. |
||
• |
The.biz registry has SLAs with several major Channel Partners covering limited system downtime and system performance measures. |
|||
Comprehensive understanding of the usTLD's evolution |
• |
NeuStar has monitored proceedings on the usTLD and associated DOC activities. |
||
• |
NeuStar has subject matter experts on staff who were involved with the original development of the usTLD. |
|||
• |
NeuStar is an active participant in various Internet-related forums such as the IETF and ICANN |
|||
Strong working relationships with stakeholders |
• |
NeuStar holds quarterly cross-regional meetings with LNPA stakeholders. |
||
• |
NeuStar holds weekly conference calls with LNP LLCs, the NPAC contracting parties, in addition to holding monthly face-to-face meetings to discuss operational issues. |
|||
• |
NeuStar actively participates in various industry forums, including LNPA WG, NOWG, IETF, ICANN, and ITU. |
|||
• |
NeuStar provides assistance to both the telecommunications industry and regulators in an effort to resolve difficulties in the area of number assignment, reporting, etc. |
|||
Facilitation of progress in a political and competitive environment |
• |
NeuStar acted as interim pooling administrator in several states prior to being selected as National Pooling Administrator. |
||
103
• |
NeuStar facilitates NPA relief planning meetings, resulting in a relief plan which meets the needs of the industry and the regulators. |
|||
• |
NeuStar provided objective information and assistance to the LNPA WG in an effort to resolve issues facing the entire telecommunications industry. |
|||
Ability to address long-term management issues |
• |
Developed Number Resource Utilization Forecasting tool, ensuring that appropriate detailed carrier information is collected, stored, analyzed, and properly distributed to appropriate regulatory authorities |
||
• |
Work closely with INC, NANC, and LNPA WGs to ensure that long term Number Resource Optimization needs are and will continue to be achieved |
|||
• |
Developed long term strategic view of the needs of telecommunication service providers and regulators |
|||
Experience in building scalable databases that ensure security of personal data |
• |
NeuStar developed, deployed, and supports the Customer Account Management Exchange database, which contains highly proprietary service provider information. |
||
• |
NeuStar developed, deployed, and maintains the Number Portability Administration Center, which contains routing information for all calls placed in the US and Canada. |
|||
• |
NeuStar maintains physical biometric facility security, with fulltime monitoring, strong physical security, and token authentication for dial-up access. |
|||
Ability to understand, develop, and manage all associated policy issues |
• |
NeuStar has an in-depth understanding all federal and state policy issues regarding number administration, in addition to meeting requirements developed by the industry which are seen to be the guidelines under which NANPA operates |
||
• |
NeuStar's experience in the policy rich telecommunications regulatory environment provides it with significant insight into the proper means for policy identification and coordination for the Internet. |
|||
104
• |
NeuStar is active in ICANN, the IETF and other Internet-related policy and standards bodies. NeuStar has a staff of experts on Internet policy and technical matters. NeuStar policy and legal experts participate heavily in ICANN constituencies' activities. |
|||
• |
NeuStar has an in-depth understanding of federal and state regulatory processes that are likely to be of prominent importance to Internet policy in the future. |
|||
Support and drive important technology standards |
• |
NeuStar is an active participant at the IETF where important internet technology protocols are developed. We are currently co-chairs of two IETF WGs including the Whois WG. |
||
• |
NeuStar has authored important IETF draft standards documents including one for a registry-registrar protocol. |
|||
• |
NeuStar developed and patented the call processing technology used to enable telephone number portability. We patented the technology and made it freely available. |
|||
Proven reputation for fair, impartial policy management |
• |
NeuStar has extended its LNPA contract for an additional 3 years over its existing 5-year contract without going through the competitive bid process, with approval by the FCC. |
||
• |
NeuStar was selected by various service providers to provide Customer Account Record Exchange service via an in-house-developed database system. |
|||
• |
Through its audit activities regarding NeuStar, Ernst & Young has consistently reported positive compliance to the Code of Conduct and Neutrality Compliance Procedures as approved by the FCC. |
|||
Strong financial performance and stability |
• |
NeuStar's existing lines of business are net income and cash flow positive |
||
• |
NeuStar's recent round of equity financing fully funded our business plan; if additional capital is required, our investment partner, Warburg Pincus, stands prepared to fund all NeuStar initiatives. |
|||
• |
[***]. |
105
NeuStar's cross-functional team organization, combined with its strong corporate focus and oversight, ensures the successful achievement of the DOC's objectives for managing and enhancing the usTLD.
HIGHLIGHTS
NeuStar is organized around a principle of leveraging a centralized group of functional organizations that support market-specific business initiatives. The line of business (LOB) teams are staffed with subject matter experts from specific markets that provide requisite knowledge to meet their LOB constituency's needs and have responsibility for business development, marketing and sales, and service delivery. By contrast, the corporate support organization is composed of information technology, operations, corporate development, administration, legal, external affairs (including media relations), finance, and neutrality functions. These functional teams are staffed with highly qualified and experienced staff who are tasked with administering various facets of our services. The Executive Oversight Committee provides direction and management to both the functional organization and the LOBs. Because the organizational structure is broad, this group is readily accessible to all teams for guidance and approval. The cohesive nature of the organization optimizes communication and fosters a collaborative work environment, whereby all of NeuStar's customer's benefit from a shared knowledge base. Additionally, this organization can quickly respond to change and reevaluate and deploy resources for critical operation.
For the usTLD Administration Program, NeuStar is proposing a dedicated cross-functional team reporting to the usTLD Director who will report to our Vice President of Internet Protocol (IP) Services. The usTLD management positions will be staffed with individuals who possess many years of relevant management and technical experience. These positions will be supplemented with personnel from our Corporate Support Team and our Technology and Operations division who will be dedicated to ensuring the success of the usTLD. The management staff will be supported by our corporate executives, who also have a strong commitment to the success of the usTLD program and will provide the requisite oversight and resources to ensure the usTLD program objectives are met.
usTLD Team
NeuStar's usTLD team will consist of an Executive Oversight Committee and an Implementation and Ongoing Operations Team. These teams are described below.
Executive Oversight
Our executive oversight committee, shown in Exhibit A-1 and introduced below, is composed of senior-level staff with vast experience covering Internet expertise, operations, systems development and deployment, financial planning, communications, and resource management. This group will provide the requisite direction and resources to ensure that the usTLD program objectives are met.
[Exhibit A-1. NeuStar's Executive Oversight Committee will ensure the requisite resources are provided for successful service delivery. Graphic Omitted: Organization chart for NeuStar Executive Oversight Committee.]
A-1
Jeffrey Ganek, President and Chief Executive Officer
Jeffrey Ganek is responsible for overall management of NeuStar, Inc. Jeff has nearly 25 years of experience in the telecommunications industry. Before heading the Communication Industry Services division within Lockheed Martin IMS, Jeff served as Vice President of Asian Operations for Global TeleSystems Group, where he developed and managed competitive telecommunications services com-panies in fast-growing Asian markets. He was also Vice President of Marketing at GTE Spacenet, Director of Global Communications Services at MCI, and Division Manager of Corporate Development at AT&T. He holds bachelor's and master's degrees from Carnegie Mellon University in Pittsburgh.
Matthew D. Wald, Vice President, IP Services
Matthew D. Wald is responsible for the commercial development and management of NeuStar's emerging IP business. He has more than 12 years of experience in the telecommunications industry, including identifying, developing, and operationalizing new business opportunities in advanced intelligent networking, IP, and Web hosting. He has held positions with LCI/Qwest Communications and Global TeleSystems Group. Most recently, as the leader of the Global Alliance and Partnership Group at GTS, he oversaw the development of several key Web hosting, Voice over IP (VoIP), and content delivery partnerships that formed the cornerstone of the GTS IP business strategy.
Mark D. Foster, Chief Technology Officer
Mark Foster is responsible for strategic technology initiatives, standards, and program management, and the design, development, and operation of NeuStar's complex network and systems infrastructure. A widely recognized subject matter expert, Mr. Foster pioneered number portability in the industry in 1994-1995 and subsequently led the development of NeuStar's Number Portability Administration Center in 1996. He has more than 20 years of entrepreneurial experience in developing innovative solutions to industry problems with inventions such as a voice-controlled intelligent network service node platform, a new computer language for developing telephone switching systems software, and the first SS7-to-IP signaling gateway (1990).
Joseph F. Franlin, Senior Vice President of Operations
Joseph Franlin is responsible for NeuStar operations and customer satisfaction for clearinghouse and numbering products and services. Joseph's organization managed the successful introduction of Local Number Portability in the United States and Canada and assumed the role of North American Numbering Plan Administrator in the United States, Canada, and many of the Caribbean Islands. Joseph has more than 30 years of experience in telecommunications and systems engineering, most notably with NYNEX, AT&T, and Lockheed Martin.
Robert Dowski, Chief Financial Officer
Robert Dowski joined NeuStar in 2000, assuming the role of Chief Financial Officer. Prior to joining NeuStar, he held similar positions with Gilat/GE Spacenet, PCS, Telecorp, and Hughes Network Systems. He has worked in the telecommunications and Information Technology industry sectors for more than 10 years, concentrating on managing large, full-scale accounting, financial planning, and strategic planning departments. In addition, he has managed the development of a series of financial systems.
Edward Frietag, General Counsel
Edward Freitag, General Counsel, is responsible for oversight of legal matters for NeuStar. Prior to joining NeuStar, he was with MCI Communications Corporation and MCI WorldCom from 1975 to 1999, last serving as Chief Corporate Counsel. During his career at MCI, he was responsible for
A-2
supporting mergers and acquisitions, financing, SEC reporting, international ventures, and other corporate matters. Prior to joining MCI, he was an associate with Donovan, Leisure, Newton & Irvine and Pro Se Law Clerk for the United States Court of Appeals for the Second Circuit. He also has served as Chairman of the Corporate and Securities Law Section of the American Corporate Counsel Association. Mr. Freitag is a graduate of Princeton University and the Columbia University School of Law.
Jerry Kovach, Senior Vice President, External Affairs
Jerry Kovach is responsible for the corporate communications, government relations, regulatory law, public policy, and public relations activities of NeuStar. Prior to joining NeuStar, Mr. Kovach was a Senior Vice President at MCI Communications Corporation from 1985 to 2000. From 1975 to 1984, he was on the staff of the United States Senate, last serving as the Chief Counsel and Chief of Staff of the Committee on Commerce, Science, and Transportation. Mr. Kovach's professional background also includes senior management positions with Chrysler Corporation and the National Academy of Sciences. Mr. Kovach is a member of Phi Beta Kappa and holds a bachelor of arts degree (cum laude) in economics from Wayne State University, a doctor of law degree (cum laude) from Wayne State University Law School, and a master of law degree from the University of Washington School of Law.
Robert Poulin, Vice President, Corporate Development
Robert R. Poulin is responsible for early-stage development of new business initiatives as well as alliance and acquisition opportunities. He actively pursues opportunities where NeuStar's proven capabilities as a trusted provider of registry and clearinghouse services can facilitate the interoperability of networks. He has 12 years of experience in the communications industry. Prior to joining NeuStar, he was Director of Business Development at Global TeleSystems Group, where he was responsible for early-stage development of new ventures in Asia. He also has held a variety of business development and finance positions with GTE Spacenet, GTE Mobilnet, and GTE Telephone Operations. He has a bachelor's degree from the Haas School of Business at the University of California at Berkeley.
Jerome Haynesworth, Vice President of Human Resources and Administration
Jerome Haynesworth is responsible for organizational development, compensation planning, facilities management, human resources development, employee relations, and equal employment programs. Jerome manages the human resources function for the technical and nontechnical components of NeuStar, with more than 400 employees internationally. He has more than 20 years of experience in managing human resources and administration, including positions with KPMG, Hughes Aircraft Company, The Interface Group/Mass., and IBM.
David H. Crocker, Senior Advisor, Consultant
David H. Crocker has been a principal with Brandenburg InternetWorking since 1991. He has been developing internetworking technologies for 30 years, including standards for e-mail, EDI, facsimile, security, and e-commerce. He was an IETF Area Director for four years, providing oversight of DNS technical development, and he initiated public interest enhancement to BIND, the DNS reference software. During the 1980s, Mr. Crocker led TCP/IP, OSI, and network management product development efforts. Mr. Crocker's current efforts focus on the creation of Internet-based businesses built on a solid foundation of customer benefit and revenue potential.
William Manning, Senior Advisor, Consultant
Bill Manning is a contributing scientist on CenterGate's UltraDNS and serves on the research staff at USC's Information Sciences Institute. At Texas Instruments, Bill was responsible for the deployment
A-3
of IP networking, initially in the semiconductor division, and then throughout the corporation. He joined Rice University to become the lead engineer for the NSFnet's SESQUINET regional network. Following the successful migration of SESQUINET and MIDnet from the NSFnet to commercial networks, Bill assumed a role in the NSF's Routing Arbiter project at NSI. Bill is active in the IETF and has been active in the DNS and Routing working groups as a participant, working group chair, and code developer. He was responsible for specifying the method for adding NSAP support to the DNS, and then he developed and implemented a plan to expand the Internet root server system to add four new nodes. Bill is also on the program committees for the North American Network Operators Group (NANOG), the Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT), and the African Network Operators Group (AFNOG). He is also a member of the Advisory Council of ARIN (American Registry for Internet Numbers). Bill continues to work on enhancing DNS code to track the growth of IP networks and is currently working with the IPv6 developers and implementers by managing the IP6.INT domain, which is the functional equivalent of the in-addr.arpa zone.
Implementation and Ongoing Operations Team
NeuStar's experience in forming successful implementation teams for such services as NPAC and NANPA will be used in staffing the usTLD operation. Leveraging these skills ensures that the usTLD will be implemented on time and that effective ongoing operations will be established. The usTLD team will include the use of experienced, highly qualified, proven individuals skilled in registry operation, database development and administration, data center operation, and transition and customer service. The usTLD team members were individually selected for their respective expertise and in-depth knowledge of technical, policy, and operational requirements. Collectively, their unique qualifications and experience, when dedicated to the coordination, expansion, and enhancement of the usTLD, will ensure success.
As can be seen in Exhibits A-2 and A-3, NeuStar is proposing two functional organizations—an implementation team and an ongoing operations team. NeuStar is committed to the delivery of high levels of quality service; therefore, most key team members participating in the implementation phase will eventually transition from the implementation team to full-time, ongoing usTLD operations support. However, this separation provides a distinct focus on the critical implementation phase. Our experience has proven that transitioning individuals participating in the implementation of an operation ensures an effective ongoing operation. As required, résumés for key team members (arranged in alphabetical order) can be found at the end of this section.
[Exhibit A-2. NeuStar's Implementation Team is comprised of dedicated subject matter experts with a depth of experience successfully meeting program objectives. Graphic Omitted: Organization chart for usTLD Implementation Team.]
[Exhibit A-3. NeuStar's usTLD Ongoing Operations Team will ensure all DOC program objectives are met. Graphic Omitted: Organization chart for usTLD Ongoing Operations Team.]
A-4
The following table contains the job titles, descriptions, and skills of key NeuStar usTLD team members.
usTLD Organization Roles and Responsibilities/Skills Matrix
Title |
Job Description |
Skills |
||
---|---|---|---|---|
Director, usTLD |
Responsible for defining the usTLD product and business requirements. Has ultimate responsibility for day-to-day management of operations to support the usTLD project and will serve as the primary point of contact (POC) to the industry. Will ensure that the necessary resources are made available to address any deviation from expectations and will be the primary decision-maker on program-related issues. Will report status to the Contracting Officer at the DOC and to NeuStar Senior Management. |
• Extensive industry experience • Excellent verbal and written communications skills • Excellent organizational and time management skills • Problem resolution skills • Excellent facilitation skills • Strong decision-making skills |
||
Program Manager |
Has overall responsibility for the successful completion of implementation, development, deployment, and upgrade of the usTLD service. Will provide overall leadership for the entire implementation team; determine project scope; develop the project plan, milestones, and risk mitigation plan; and act as the front-line contact with the client representatives on project-related issues. |
• Excellent customer service, decision-making, and communications skills • Detail-oriented, creative, and analytical • Industry experience • Experience with managing large, complex, multi-phase technical projects • Strong leadership skills |
||
A-5
Director, Systems Engineering |
Will be responsible for overall system delivery and will manage the design and development processes of all usTLD systems. |
• Well-developed and highly effective verbal and written communications skills • Demonstrated ability to manage the design and development of complex applications using development standards • Expertise in one or more technical areas as well as experience in relational database development and design |
||
Director, Information Technology and Services |
Manages the technical operations group and the network support group in a 24x7 real-time mission-critical production environment. Supports, monitors, tests, and troubleshoots hardware and software problems; recommends and schedules repairs; and provides Tier 2 support for all LAN/WAN-based applications. Maintains security and disaster recovery procedures and participates in database architecture strategy development, database design and engineering, and reliability and performance enhancement. |
• Experience in LAN operating systems • Extensive knowledge of LAN infrastructure setups, including hubs, routers, and firewalls • Strong written and communications skills • Strong analytical and problem-solving skills • Familiar with standard concepts, practices, and procedures within particular field |
||
Senior Manager, Channel Management |
Is responsible for the registrar, delegee, and resellers outreach programs. This person and his or her team are responsible for channel communications for the usTLD product. |
• Experience with various Industry forums • Excellent verbal and written communications skills • Excellent organizational and time management skills • Problem resolution skills • Excellent facilitation skills • Ability to run efficient meetings • Supervisory skills |
||
A-6
Senior Manager, Product Marketing |
Is responsible for the definition of enhanced services for the usTLD locality-based and expanded products. Will create marketing materials and review any training materials or other documentation about the product. Is responsible for public relations, branding, advertising, and Web content look and feel and will also attend industry forums. |
• Extensive Industry experience • Excellent verbal and written communications skills • Excellent organizational and time management skills • Problem resolution skills • Excellent facilitation skills |
||
Senior Manager, Customer Service |
Is responsible for all day-to-day usTLD service operations. Hires and supervises the Help Desk, Quality Assurance group, and the Training and Documentation group. Ensures that the staff have the adequate tools and facilities to properly perform their functions and develops and implements escalation procedures. |
• Extensive Industry experience • Extensive data center operations experience • Excellent verbal and written communications skills • Excellent organizational and time management skills • Problem resolution skills • Excellent facilitation skills |
||
Quality Assurance Group |
Evaluates our conformance to the standards mandated by industry guidelines. Performs operational and business audit reviews, evaluates results, and makes recommendations for the improvement of internal operational and management control systems and performance. Will send out surveys to the usTLD user base, soliciting comments about our service and incorporating their suggestions for improving the process. |
• Internal business auditing or related experience • Experience with commonly used auditing concepts and practices • Strong analytical and problem-solving skills • Strong written and verbal communications skills |
||
A-7
Help Desk Group |
Plays a critical role in the implementation of usTLD, working closely with the industry to establish policies, procedures, and processes that facilitate usTLD operations. Ongoing activities will include resolution of all user problems and inquiries associated with usTLD. |
• Excellent customer service, decision-making, and communications skills • Detail-oriented, creative, and analytical • Industry experience • Experience with troubleshooting computer hardware and software |
||
Transition Team |
Is responsible for managing the transition from the current administrator to NeuStar, which includes working closely with the delegees to understand and improve the existing locality-based space. |
• Excellent customer service, decision-making, and communications skills • Detail-oriented, creative, and analytical • Industry experience • Strong written and verbal communications skills. |
||
Technical Industry Liaison |
Is NeuStar's technical representative with the ICANN, IETF, and other industry standards bodies. Is responsible for ensuring that NeuStar is compliant with all industry standards and provides technical direction to the Systems Engineering organization. |
• Well-developed and highly effective spoken and written communications skills • Understands the usTLD space, both technically and operationally • Expertise in ccTLD technology and standards. • Detail-oriented, creative, and analytical • Registry administration experience. |
||
HR/Administration |
Responsible for Human Resources including recruiting and hiring staff. Responsible for facilities management. Responsible for ensuring program is meeting financial budget, defining AP, AR, and credit processes. Also is responsible for neutrality supervision and for ensuring that all program activities meet neutrality requirements. |
• Excellent customer service, decision-making, and communications skills • Detail-oriented, creative, and analytical • Industry experience • Strong written and verbal communications skills. |
||
A-8
Legal, Policy, and ICANN Relations |
Responsible for usTLD contract negotiation and management. Also responsible for registrar, delegated manager, and delegee contracts. Responsible for US Nexus requirements, locality-based usTLD policy enforcement, domain name dispute resolution procedure/policy, Sunrise and Land Rush Policy, ICANN Policy, Government Advisory Committee Principles, Registrar Agreement Development, and Policy compliance audit. |
• Extensive experience in ccTLD and ICANN policy • Excellent negotiation skills • Excellent contract management skills • Excellent decision-making and communication skills. |
||
Billing and Collections |
Responsible for defining Billing and Collections interface requirements, invoice design and development, methods and procedures, and credit card processing. |
• Extensive experience in registry billing and collections • Excellent customer service skills • Excellent decision-making and communications skills |
Staffing Approach
NeuStar's philosophy is that the company achieves its business goals through its people. We promote the philosophy among our employees that they are individually and collectively critical to the company's success and share in its rewards. A sense of ownership is encouraged among employees—ownership of their own work as well as responsibility for the overall performance of the company. NeuStar consistently maximizes its business goals by hiring staff who are highly productive and of high caliber, ensuring the highest levels of service.
Staffing allocations may need to be adjusted as demand for service increases. Adjustments may include the staff size or refinements to required technical skills. The mechanisms for such reviews and procedures will be consistent with NeuStar's policies. In addition, NeuStar can and will draw upon a reserve of managerial and technical skills within the corporation. Cross training is used in all positions to promote job interest and esprit de corps.
A-9
|
|
|
---|---|---|
Ken Hansen, Director, usTLD Administration | ||
Qualifications |
More that 18 years of management experience in information technology for the Internet, IT and telecommunications industries. His expertise includes managing global operations for a multi-nations telecommunications company; supporting multiple call centers; managing and supporting large data centers; and customer and data center migrations. Accomplishments include managing and staffing network and infrastructure development and support organizations; meeting and exceeding Service Level Requirements (SLRs) for availability in order provisioning environments; and working with IXCs and LECs to automate electronic information exchange to support service provisioning. |
|
Experience |
Director, Corporate Development, NeuStar, Inc. (2000-Present) |
|
I.Responsibilities include the development of corporate strategy; growing NeuStar's service portfolio of communications infrastructure services; and identification and pursuit of new business opportunities including partnerships, joint ventures, mergers and acquisitions. Led the business development effort associated with ".BIZ". | ||
Director, Marketing, Net2000 Communications (1999-2000) |
||
II.Led a team responsible for all aspects of the Net2000 product portfolio including Internet, e-commerce, Frame Relay, Private Line, Access, Local Service, Long Distance and vertical markets. Responsible for product strategy, product definition, pricing, development, launch, and ongoing product management. | ||
Senior Manager, Local Service Product Management, Business Markets, MCI Communications Corporation (1989-1999) |
||
III.Complete product life cycle responsibility for the services associated with MCI's Local Service initiative. Areas of responsibility included product strategy, identification of product requirements, oversight of development, product launch, and ongoing product related activities. | ||
Senior Manager, Access & Advanced Product Development, MCImetro (1995-1996) |
||
IV.Led the development of Carrier Access and Advanced Services for MCI's Local Service subsidiary. Primary responsibility included capability development, assessment of proposed services, and program management of new service implementation. Products included SONET based Dedicated Access, Switched Access, ISDN, AIN, and Voice. | ||
Senior Manager, Global Accounts, Complex Bids / Customer Network Design (1992-1995) |
||
V.Directed an organization that developed network based solutions and provided third level technical support in pursuit of large complex revenue opportunities. This included; direct interface with customers, Global Account teams, Engineering, Operations, Finance, and Product Marketing. | ||
Senior Manager Product Development, Global Communication Service (1991-1992) |
||
VI.Manage the development of MCI's global outsourcing offering targeted at U.S. based multinationals. This required development of short and long-term strategy; and interface with PTTs, Corporate Development and overseas offices. Successfully completed large outsourcing contracts with several large Fortune 500 companies. | ||
A-10
Education |
New York Institute of Technology, Islip, NY |
|
B.S. Program, Telecommunications Management |
||
Dianne Black, Program Manager |
||
Qualifications |
More than 12 years experience in Program Management, Product Management, Software Engineering Management and Telecommunications. Have successfully managed the implementation of over 50 large cross-functional programs with costs over 150 million. |
|
Experience |
Director, Program Management Office, NeuStar, Inc. (1999-Present) |
|
VII.Implemented and manage the Program Management Office at NeuStar. The PMO serves as an enterprise cross-functional program management team responsible for implementation of all corporate strategic projects including.biz systems, CARE OSS Clearinghouse, Code Administration System, NPAC Releases 1 through 4, and 10 other systems worth approx. 50 million in revenue within 2 years. Manage a staff of 15 people. | ||
VIII.Implemented and manage the Project Support Office, part of the Program Management Office responsible for definition and implementation of the Project Management methodology. Created the NeuStar Project Management Handbook and created a library of processes to include software development processes. Also responsible for defining and delivering monthly project management training to all employees, coaching and mentoring. Produces a monthly project management newsletter to entire company, which highlights major project milestones, project successes, processes, best practices, and lessons learned. Participates in monthly operations reviews presented to executives. Program Management team participates in the PMI (Project Management Institute) approved Project Management Certification program. |
||
Senior Manager, Local Systems Operations, MCI Communications, Inc. (1997-1999) |
||
IX.Managed 5 functions: Local Systems Project Management, Local Systems Training, Process Improvement (Business Process Reengineering), User Communications, and Web Development. | ||
X.Responsible for end-to-end project management of 60+ Local systems development projects. Served as interface between Local Systems Development and Local User groups (Product Marketing, Provisioning, OE, Customer Service, Sales, etc.). Project Management including prioritization, budgeting, scheduling, requirements definition, life-cycle development coordination including integration and UAT testing. Matrix management of approx. 50 Local Systems Organizations and 30 Systems User Groups. Systems included Order Entry, Order Processing, Provisioning, Translations, Work Flow Manager, Traffic, Access and Subscriber Billing, Customer Service. |
||
XI.Managed the Local Systems Training group. Train on approx. 30 Local Systems for approx. 1500 users. Training was mostly hands on technical training, but also support web-based training, web-based self-paced courses (CBT), and interactive video training. |
||
A-11
XII.Managed a Process Improvement group (or Business Process Reengineering group). Projects included revamping systems audit processes, systems Help Desk processes, Billing Systems Operational Support Plan, Mass Markets Systems End User Support Plan and others. Group will assess, recommend, and assist with implementation for each project. Appropriate process standards and methodology are applied for each project. |
||
XIII.Provided all user communications on all Local Systems Releases. Work with development to package release contents into user friendly material to be presented to the user community. |
||
XIV.Managed web development group responsible for design, creation, and maintenance of internal Local Systems Operations web pages. |
||
Senior Manager, Wireless Program Management, MCI Communications, Inc. (1995-1997) |
||
XV.Responsible for end-to-end project management of new city implementation. Successfully implemented 60+ wireless cities in approx. 1 year. Responsibilities include matrix management of approx 50 organizations including Legal/Regulatory, Carrier Relations, Marketing, Engineering, Fulfillment, Customer Service, Systems Development, and Sales. Developed and managed new city project plan containing approximately 150 tasks. | ||
XVI.Responsible for Customer Care and Billing software selection. Included managing software vendor RFP and selection process. Through in depth analysis and due-diligence, developed "buy vs. build" business case and presented to Wireless Executives. |
||
XVII.Responsible for systems requirements and implementation for the integration of Nationwide Cellular, a national cellular reseller acquired by MCI. |
||
XVIII.Project Managed successful implementation of cellular fulfillment systems and operations. Tasks included review of external vendor candidates. Managed RFP process and vendor selection. |
||
XIX.Project Managed successful implementation of Wireless Customer Service Systems and Operations. Tasks included operations planning, staffing, selecting and installing ACD, service processes/procedures, and system requirements and systems implementation. |
||
XX.Successfully planned and implemented National Technical Service Vendor program to support cellular customer on-site servicing needs. Established program processes and procedures and system requirements. |
||
XXI.Member of Wireless Strategy Team focused on Digital, PCS Resale, and Interconnect strategies. Included thorough research and analysis of CDMA, TDMA, and GSM technologies. |
||
XXII.Managed a staff of 3 Managers and 18 staff. |
||
Manager, New Technologies Marketing, MCI Communications, Inc. (1993-1995) |
||
XXIII.Responsible for project management of systems development, provisioning, order entry, customer service, fulfillment, and all operations for analog video phone product. | ||
A-12
XXIV.Responsible for selection and then implementation of a product fulfillment vendor. Included developing all systems requirements and then managing development project through implementation. Entailed heavy vendor coordination. |
||
XXV.Member of a team responsible for product management of set-top-box video phone, including product design, technology definition, manufacturing. Entailed heavy vendor management for both technology and manufacturing. |
||
XXVI.Responsible for multimedia services development accessed via set-top-box video product. |
||
Project Manager, MCI Communications, Corp. (1992-1993) |
||
XXVII.Responsible for successful implementation of Customer Marketing Database, a national marketing and lead generation system. Managed Consumer Exception Processing projects. | ||
XXVIII.Responsible for Business Markets Customer Service Automation. |
||
XXIX.Developed and facilitated Business Markets Systems Training. |
||
Systems Analyst, MCI Communications, Corp. (1990-1992) |
||
XXX.Full life-cycle development of National LEC Interface System. | ||
XXXI.Served as primary user interface contact. |
||
XXXII.Represented MCI on OBF Subscription Committee to define order processing standards. Also stood on committee to define cellular interface standards. |
||
Education |
B.S., Industrial Engineering and Operations Research (IEOR) (1989) |
|
Virginia Tech, Blacksburg, VA | ||
M.S., Telecommunications (1995) |
||
University of Denver, Denver, CO | ||
M.S., Information Systems Management |
||
George Washington University, Washington, DC, 75% complete | ||
Barbara Blackwell, Media Relations |
||
Qualifications |
Seasoned communications professional with over 10 years of experience in the Internet domain registry, telecommunications, government relations and legal arenas. Skilled in media relations; corporate positioning; brand building; crisis communications; event planning; issues management; public affairs and grassroots lobbying efforts. |
|
Experience |
Manager, Public Relations, NeuStar, Inc. (2000-Present) |
|
XXXIII.Creates and manages overall communications strategy and corporate positioning. | ||
XXXIV.Managed nationwide outreach during spin off of parent company and initial launch and implementation phases of registry services. |
||
XXXV.Responsible for the planning, coordination, and execution of all national and international media relations efforts. |
||
XXXVI.Write and distribute press releases and develop tactical strategies for driving all existing and new business agendas. |
||
A-13
XXXVII.Provide public relations counsel to executive management and other senior staff. |
||
Sr. Public Relations Specialist, NeuStar, Inc. (1999-2000) |
||
XXXVIII.Serve as a central point of contact for local, national and international media. Research and develop responses on a broad range of issues, arrange interviews, and pitch global and targeted issue-oriented stories to reporters and producers. | ||
XXXIX.Manage and coordinate registry/registrar public relations efforts with marketing team. |
||
Sr. Public Affairs Specialist, American Bar Assoc. (1994-1999) |
||
XL.Plan and oversee media projects relating to program activities covering a wide range of legal issues, including international law, legal problems of the elderly, taxation, administrative law and regulatory practice. | ||
XLI.Write and edit press releases, news advisories, pitch letters, op-eds. |
||
XLII.Develop and implement public relations strategies to increase association visibility in targeted media markets. |
||
XLIII.Formulate opportunities for press conferences and media events surrounding issues, meetings and product and service launches. |
||
XLIV.Managed public relations budget operations for the Public Affairs Office. |
||
Legislative Assistant, Senator Charles S. Robb (1992-1994) |
||
XLV.Drafted legislation and constituency responses for Senator approval. | ||
XLVI.Tracked legislation and in the areas of housing, banking, telecommunications and gun control; coordinated legislative efforts with other congressional offices. |
||
XLVII.Served as liaison to state constituency on behalf of Senator; monitored statewide issues and activity. |
||
XLVIII.During successful re-election year, served around the state as press assistant. |
||
Education |
M.A. Candidate, Public Communication, George Mason University |
|
B.A., Pre-Legal Studies, Virginia Commonwealth University |
||
Member, Public Relations Society of America; Association of Black Women in Journalism. As active member of National Press Club, participate in regular Club activities and events. |
||
A-14
James A. Casey, usTLD Policy |
||
Qualifications |
Mr. Casey has over seven years of experience with legal and policy matters relating to the Internet, advanced technologies and telecommunications. In this capacity Mr. Casey has assisted numerous companies in the identification and development of new technology business ventures and the development and execution of strategic policy initiatives supporting business activities. Mr. Casey's legal practice has focused on telecommunications and technology law, telecommunications ventures, energy projects, regulatory and transactional matters. And native American tribal affairs. Mr. Casey also has been involved with ongoing tribal telecommunications legislative and administrative efforts and has assisted the Federal Communications Commission as an expert on tribal telecommunications matters. In addition, Mr. Casey participates in international proceedings at the ITU and in other standards bodies, as well as on indigenous knowledge rights and biodiversity and has served as an expert witness with regard to indigenous treaty rights. |
|
Experience |
Director, Policy and Business Development, NeuStar, Inc. (2000-Present) |
|
XLIX.Develop and implement strategic policy initiatives. | ||
L.Monitor policy activities for consistency with NeuStar neutrality principles. |
||
LI.Monitor international standards and treaty body activities. |
||
LII.Assess and develop new business opportunities. |
||
LIII.Conduct governmental relations activities. |
||
Associate, Greenberg Traurig (2000-2001) |
||
LIV.Assist in the development of a tribal telecommunications, technology and economic development practice. | ||
Associate, Morrison & Foerster (1995-2000) |
||
LV.Practice focused on representation of common carrier clients (wireline and wireless) before the Federal Communications Commission | ||
LVI.Assisted tribal governments in telecommunications, utility, legislative and other matters, including development of tribal telephone and communications companies. |
||
LVII.Mass media (radio, television), contract negotiation and drafting, rulemaking proceedings, administrative and federal litigation, satellite, common carrier matters, personal communications services, emergent technologies, and infrastructure issues. Practice also included representation of Internet access companies on matters relating to computer, intellectual property and Internet law. |
||
Associate, Fletcher, Heald & Hildreth, P.L.C. (1994-1995) |
||
A-15
LVIII.Represented communications clients before the Federal Communications Commission. Experience includes mass media (radio, television), contract negotiation and drafting, rulemaking proceedings, administrative and federal litigation, satellite, common carrier matters, personal communications services, and infrastructure issues. Assisted Native tribal governments in the development of telecommunications infrastructure and provide guidance in regulatory matters and the intersection of Federal Indian Law and Telecommunications law. Other practice areas included intellectual property, computer law, and entertainment law. | ||
Summer Associate, Birch, Horton, Bittner & Cherot (1993) |
||
LIX.Conducted legal research in various areas including federal and state litigation and administrative law. Prepared legal memoranda, briefs, executive employment contracts, comments on proposed rule-makings and administrative action response letters and assisted in lobbying efforts. Experience includes: tax status of non-profit organizations, sovereign immunity, FCC comparative hearings, intellectual property liability of spin-off companies, executive contract preparation, good faith appeal to the Mineral Management Service (Department of the Interior). | ||
Research Assistant, Cornell Law School (1992-1992) |
||
LX.Researched and wrote on the historical development of the Fourth Amendment to the United States Constitution and the United States Supreme court's use of that history in search and seizure cases. Assisted in other research and materials collection as needed. | ||
Litigation Assistant, Brown and Bain (1989-1991) |
||
LXI.Researched and organized case materials for high technology litigation. Experience includes: video game and video special effects patents, trade secret theft, unfair competition, antitrust and class action litigation. Duties included discovery, and factual research and analysis. Assisted in the preparation of summary judgment motions, pre-trial briefs and other filings. | ||
Education |
J.D., Cornell Law School (1994), specialization in international legal affairs |
|
B.A., History (1988), extensive coursework in electrical engineering and computer science |
||
David H. Crocker, Technical Industry Liaison |
||
Qualifications |
Management, design and development for all aspects of Internet and distributed systems, emphasizing innovate opportunities and aggressive delivery schedules. |
|
Experience |
Principal, Brandenburg InternetWorking (1991-Present) |
|
LXII.Consultancy with focus on use of intranets and the Internet. Participate in startup business planning and funding | ||
LXIII.Assist in development of intellectual property, founded trade associations |
||
LXIV.Recent projects included standard for facsimile over the Internet; specifications of extensions to Internet email and information services; design of transport-independent deferred-attachment API; and IP network design for contention-access ATM-based interactive cable television service. |
||
Manager (Internet tech transfer), Net Systems Lab, DEC (1989-1991) |
||
A-16
LXV.Created TCP/IP technology-transfer corporate resource. Delivered early firewall and router products and network management administration tool. | ||
VP Engineer, The Wollongong Group (1987-1989) |
||
LXVI.Led product development, guiding end-user and OEM open systems software products, including TCP/IP and ISO-OSI stacks, SNMP-based network management station and TCP/OSI transition products along 9 separate sets of product lines. | ||
LXVII.Responsible for staff of 50, providing software engineering, configuration management and project support, and corporate network and computing services. |
||
Development Manager, Undermann-Bass (1985-1987) |
||
LXVIII.Delivered company's initial suite of TCP/IP software products, for PCs, terminal concentrators and internetwork routers. | ||
Director, Sys. Development, MCI Digital Info Svcs Corp. (1983-1985) |
||
LXIX.Met aggressive development schedule, creating application, directory and data processing components for MCI Mail, a unique, $50 million, distributed national electronic mail service. | ||
LXX.Developed interactive and remove batch access for 140,000 users, including delivery for Telex inbound and outbound, as well as hardcopy with letterhead and signature graphics, and access for communicating word processors. |
||
Principal Investigator, Electrical Engineering, University of Delaware (1978-1982) |
||
LXXI.Developed Unix-based email relay for heterogeneous networks. System was an exemplar for "UA/MTA" architecture of CCITT X.400 email standards. | ||
LXXII.Operated national mail relay service for the Army and for NSF's CSNet, precursor to NSFNet. |
||
LXXIII.Authored various Internet protocol specifications, especially for electronic mail. |
||
Education |
Doctoral Program, Computer Science, University of Delaware (1992) |
|
M.A., Communication, Annenberg School, USC (1977) |
||
B.A., Psychology, UCLA (1975) |
||
Thomas G. McGarry, Transition Team |
||
Qualifications |
Eighteen years experience in network engineering, network and technology planning, and telecommunications management. Significant experience in the internet and registry related technology. Represent NeuStar as SME on internet and domain name space. |
|
Experience |
Chief Technical Strategic Technical Initiatives, NeuStar, (1998-Present) |
|
LXXIV.Manage a group of subject matter experts (SME) who provide technical representation for NeuStar at various industry meetings and forums. | ||
LXXV.Drive the development of industry standards for voice over IP technologies. This work is primarily performed at the Internet Engineering Task Force (IETF) and European Telecommunication Standards Institute (ETSI). |
||
A-17
LXXVI.Interface directly with the federal and state regulators in North America as well as international regulators regarding numbering policy decisions. This is NeuStar's responsibility as the North American Numbering Plan Administrator (NANPA). |
||
LXXVII.Provide technical support with regard to telecommunications numbering issues for the North American and international communications industry. |
||
LXXVIII.Support the development and advancement of DNS, BIND, and registry related technologies at the IETF. |
||
LXXIX.Manage the process of developing new requirements in an open forum for future software releases to NeuStar's Number Portability Administration Center (NPAC). The NPAC is a registry service for ported telephone number information NeuStar has been contracted to provide to the North American communications industry. |
||
LXXX.Evaluate new business opportunities through representation at industry meetings and forums. |
||
LXXXI.Manage the introduction of new business opportunities into NeuStar business development processes. |
||
LXXXII.Acted as Director of Network Engineering for two data centers and six office locations for eight months prior to filling the vacancy. |
||
Director-Network Engineering, Geotek, Inc. (1997-1998) |
||
LXXXIII.Manage a group of engineers and administrators in the deployment of network and switching equipment and software, and communications facilities. | ||
LXXXIV.Interface with facility providers for timely deployment of cell site T1s. |
||
LXXXV.Plan and deploy interconnection with the public switched telecom network. |
||
LXXXVI.Manage the deployment and selection of a Frame Relay network for internal communications. |
||
LXXXVII.Develop hardware and software requirements and configurations for network equipment; DACS, router, alarm, modem, terminal server, synchronization. |
||
LXXXVIII.Coordinate the purchase and deployment of network and switching equipment. |
||
LXXXIX.Provide network equipment documentation and support to Geotek field technicians. |
||
Staff Director—Number Portability Project Management 7, NYNEX Corp. (1996-1999) |
||
XC.Provide company wide project management for the implementation of number portability capabilities in the NYNEX network. | ||
XCI.Provide a requirements document to address number portability's impact on NYNEX's signaling and switching network, and related systems. |
||
XCII.Develop and gain approval for three-year funding requirements for number portability. |
||
A-18
XCIII.Determine 5ESS, 4ESS, DMS10, DMS100, DMS200 TOPS and remote switch software requirements. |
||
XCIV.Participated in the selection of hardware and software for the deployment of an overlaid intelligent network to provide number portability. |
||
XCV.Participated in the network design and routing for the overlaid intelligent network. |
||
XCVI.Represent NYNEX to state and federal regulators, industry committees, and competitors with regard to network and systems requirements for number portability. |
||
Staff Director—Network & Technology Planning (1995-1996) |
||
XCVII.Act as Subject Matter Expert with regard to numbering related issues for NYNEX. | ||
XCVIII.Evaluate the impact to NYNEX of numbering related issues. Develop the NYNEX position, and drive industry direction towards that position at the Industry Numbering Committee (INC). |
||
XCIX.Provide the NYNEX interface to the North American Numbering Plan Administrator for multiple issues including NPA exhaust planning and reservations. |
||
C.Successfully lead an effort within the INC to reserve 200 carrier identification codes (CIC) for intranetwork use, available to all carriers. |
||
CI.Solely responsible for network related number portability issues within NYNEX. |
||
CII.Lead NYNEX's participation in the NY number portability trial, an effort driven by the NY State Public Service Commission (PSC). Successfully drove decisions involving cost and network reliability to NYNEX's favor. |
||
CIII.Actively participate in NY PSC effort with regard to deploying number portability. Participate on multiple subcommittees responsible for planning the deployment of new AIN technology and number portability databases. |
||
CIV.Provide input to Lucent and Nortel with regard to their methods of deploying number portability solutions in end office switches, operator service switches, tandem switches, STPs, SCPs, and operations support systems. |
||
Manager Strategic Planning—Switch and Network Technology, NYNEX Mobile Communications Company (1993-1995) |
||
CV.Provide evaluation, recommendation, and development of new products, services, and technologies on a company wide basis. |
||
CVI.Provided network requirements to equipment vendors and interconnected carriers for new products and services based on Marketing's product definition. |
||
CVII.Project managed the implementation of new products and service with the line engineering organizations, equipment vendors, and interconnected carriers across multiple markets. |
||
CVIII.Researched and evaluated new hardware and software developments and designs for cellular applications. |
||
A-19
CIX.Participated on digital deployment core team, which developed NMCC's digital deployment strategy. |
||
CX.Analyzed and evaluated AT&T digital hardware developments. |
||
Network Services Director, MobiLink (1992-1993) |
||
CXI.Chosen by NMCC upper management for a temporary assignment on a multifunctional task force (7 members) responsible for starting-up MobiLink, an international brand name for cellular service supported by 17 major cellular carriers. | ||
CXII.Developed network requirements; including performance engineering, automatic roaming, roamer validation, and dialing plans; for member companies. |
||
CXIII.Participated in Board of Directors Meetings (consisting of 7 cellular carrier Presidents) providing definitions of requirements and status of member company's progress. |
||
CXIV.Worked individually with member companies to advise on methods in which to meet network requirements. |
||
Manager, Network Engineer (1989-1992) |
||
CXV.Provide traffic engineering, equipment engineering, and implementation engineering for switch, cell, and network equipment and trunks for the NY Metro cellular network. | ||
CXVI.Developed and managed the organizational structure to provide equipment engineering, traffic engineering, and network planning for NY Metro cellular network. |
||
CXVII.Supervised four Engineers and three support personnel. |
||
CXVIII.Planned, engineered, and procured all switch, cell site, and network equipment utilized in the NY Metro cellular network. |
||
CXIX.Planned, engineered, and procured the NY Metro voice and data facilities network. |
||
CXX.Coordinated the implementation of equipment with various internal organizations and vendors. |
||
CXXI.Responsible for the implementation of proper contract approval, accounting, and purchasing processes and procedures. |
||
Manager, Network Planning (1987-1989) |
||
CXXII.Plan and implement network interconnection facilities and equipment for NY Metro cellular network. | ||
CXXIII.Defined and developed the Network Planning role in the NY Metro cellular network. |
||
CXXIV.Instituted cost savings methods and procedures for network interconnection and growth. |
||
CXXV.Planned and implemented the first cutover of a cellular switch to a remote location in the NY Metro cellular network. |
||
CXXVI.Supervised one Engineer. |
||
A-20
CXXVII.Total responsibility for planning voice network for the NY Metro cellular network. |
||
CXXVIII.Solely responsible for equal access implementation and coordination from the 1988 to 1992 in the NY Metro cellular network. |
||
Education |
1983-Present, Advanced Technical Training; Numerous advanced engineering courses in communication system design, digital, communications systems, cellular systems, telephone technology, spread spectrum theory and design, Motorola and AT&T cellular systems, and advanced intelligent network technology. |
|
May 1983, B.S., Business Administration, University of Buffalo, Buffalo, NY |
||
Jeffrey J. Neuman, ICANN Relations |
||
Qualifications |
Mr. Neuman is the Director of Law and Policy at NeuStar, Inc. He is responsible for the oversight of intellectual property law and policy matters, as well as information technology licensing. He is the external liaison for both NeuStar and NeuLevel, Inc. with the Internet Corporation of Assigned Names and Numbers (ICANN) and the Domain Name Supporting Organization. |
|
He has testified before the Subcommittee on Courts, the Internet and Intellectual Property of the Committee on the Judiciary, U.S. House of Representatives Oversight committee regarding "ICANN, New gTLDs and the Protection of Intellectual Property." |
||
Prior to joining NeuStar, his practice focused on representing telecommunication providers and e-commerce companies in matters involving technology licensing, intellectual property, and domain name disputes. Mr. Neuman is a frequent speaker on issues involving intellectual property, domain names, online dispute resolution and the introduction of new generic top-level domain names. He has been featured in articles all over the globe, including the New York Times, Wired Magazine, and the June edition of IP Asia, one of the leading intellectual property trade magazines for intellectual property practitioners in Asia, discussing the introduction of the new dot-biz top-level domain. |
||
Experience |
Director, Law and Policy NeuStar, Inc. (2001-Present) |
|
CXXIX.Serves as Director of Policy and Intellectual Property and is responsible for policy development for dot-biz. | ||
CXXX.Performs public relations functions for dot-biz registry and the introduction of top-level domains. |
||
CXXXI.External liaison with the Internet Corporation for Assigned Names and Numbers (ICANN), the Domain Name Supporting Organization of ICANN, the gTLD Registry Constituency of ICANN and the Intellectual Property Constituency. |
||
CXXXII.Responsible for the protection of NeuStar's intellectual property assets, domain name disputes, and Internet-related matters. |
||
CXXXIII.Preparation and negotiation of agreements for technology and software licensing, hardware and software system development, and joint venture/marketing relationships. |
||
Information Technology Associate, Greenberg Traurig, LLP/Akn, Gump, Strauss, Hauer & Feld, LLP (1999-2001) |
||
A-21
CXXXIV.Representation of domain name registry in intellectual property and policy-related matters before the Internet Corporation for Assigned Names and Numbers (ICANN), the United States House of Representatives and the European Commission. | ||
CXXXV.Counsel and representation of clients in the protection of intellectual property assets, trademark infringement, copyright infringement, unfair competition, domain name disputes, and Internet-related matters; Representation of clients in trademark matters before the United States Patent and Trademark Office and domain name disputes before the World Intellectual Property Organization (WIPO). |
||
CXXXVI.Preparation of agreements for technology and software licensing, hardware and software system development, telecommunication system acquisitions, and joint marketing and value added reseller relationships. |
||
CXXXVII.Preparation of Internet agreements for web site development and hosting, electronic commerce, terms of service, spamming and privacy policies. |
||
CXXXVIII.Advice and counseling of clients in the export of encryption technology; Representation of clients before the United States Department of Commerce's Bureau of Export Administration. |
||
CXXXIX.Participation in the formation of ICANN as well as WIPO's hearings on alternative dispute resolution mechanisms for domain name disputes. |
||
Associate, Arter & Hadden, LLP (1997-1999) |
||
Representation of clients in trademark infringement, copyright infringement, and unfair competition, as well as in Internet law issues. Published several articles on the creation, development and new management of the domain name system. Participated in the formation process of ICANN as well as WIPO's hearings on alternative dispute resolution mechanisms for domain name disputes. Advice and counseling in matters involving Internet issues including the protection of clients' intellectual property rights on the Internet, domain name registration, dispute resolution mechanisms, spamming, website development agreements, Internet privacy policies, and web hosting agreements. |
||
Education |
J.D., The George Washington University Law School, Washington, DC, 1997, cum laude |
|
B.A., Political Science, Pennsylvania State University, University Park, PA, 1994 |
||
B.A., Labor and Industrial Relations, 1994, summa cum laude |
||
Phi Beta Kappa |
||
Robert S. Nichols, Product Development |
||
Qualifications |
More than 14 years of experience in telecommunications and high-tech industries where he has played significant roles in launching new products and businesses. |
|
Experience |
Director, IP Services Business Development, NeuStar, Inc. (2000-Present) |
|
CXL.Manages marketing and product related activities in pursuit of commercializing a suite of Global Directory Services, which includes national and international ENUM administration as well as next generation signaling services that bring intelligent network capabilities to IP based networks. | ||
A-22
Director, Product Management, USinternetworking, (1999-2000) |
||
CXLI.USi's Product Management lead for the Enterprise Messaging and Collaboration Business Unit. Primary responsibilities include strategic development of the product roadmap, product and system development, marketing rollout and ongoing product management. | ||
CXLII.Developed market rollout strategy and launched the Enterprise Messaging and Collaboration Business Unit in September 1999. Product introduction responsibilities included press and analyst briefings, product packaging, positioning, pricing and promotion. |
||
CXLIII.Managed a team of product managers and developers for ongoing management of the core messaging service based on Microsoft Exchange, as well as enhanced features including document management, unified messaging, real time voice and data collaboration, and wireless access integration. |
||
CXLIV.Directed a team of developers in defining, building and launching a Customer Extranet, designed to allow USi Clients online access to performance and billing reports, implementation tracking, contracts, as well as initiate service changes. |
||
CXLV.Directed corporate marketing teams in development of marketing collateral, press releases, sales training documents, advertising, direct mail, case studies and white papers, TCO tools, and the corporate web site. |
||
CXLVI.Led business development activities with Microsoft Independent Software Vendors (ISVs), including evaluation, negotiation, service development and implementation of advanced service features that integrate with the Microsoft Exchange platform. |
||
Sr. Manager, New Business Development, Iridium LLC (1997-1999) |
||
CXLVII.Iridium's Service Development lead regarding new business initiatives involving external network integration and commercial reselling opportunities. Primary activities included initial development, product and market rollout, as well as the ongoing product management and evolution of the Iridium World Calling Card Service, and the Iridium High Speed Data Service. | ||
CXLVIII.Launch and ongoing service management responsibilities for the Iridium World Calling Card Service. Responsibilities included evaluating global business partners, negotiating partner agreements, developing global distribution and marketing rollout, as well as pricing, positioning and worldwide promotion. |
||
CXLIX.Service development of the Iridium High Speed Data Service (Integrated Inmarsat High Speed Data). Responsibilities included business plan development, external network integration, operation and customer service development, billing integration, global product distribution and market launch. |
||
CL.Service development of the Iridium/(Inmarsat) Aeronautical Service. Responsibilities included business plan development, external network and billing integration, global card distribution, and market launch. |
||
Manager, Satellite Telephone Products, Motient, Inc. (Formerly American Mobile Satellite Corp.(AMSC) (1994-1997) |
||
CLI.AMSC's product management lead and among the principal architects for marketing and operational related issues, including all SKYCELL service and product development projects. | ||
A-23
CLII.Managed a team of product managers with responsibility for development, implementation and ongoing support of AMSC's SKYCELL services, including voice, data and fax. |
||
CLIII.Managed systemic and configuration specific development programs to ensure system level functional performance, including network enhancements, subscriber equipment and ancillary switching platforms. |
||
CLIV.Managed product development life cycles for SKYCELL product lines including vendor management, operational and customer service support, pricing and market launch. |
||
Business Analyst, Dun & Bradstreet (1987-1993) |
||
CLV.Developed comprehensive marketing and credit reports, resulting in the assignment of composite credit appraisals. Assigned ratings based upon financial strength, industry norms, management experience, tend of entity, and payment record. | ||
Education |
B.S. in Business Administration, concentration in Marketing Management; Minor degree in philosophy, University of Delaware, Newark, DE. June 1987 |
|
M.B.A. University of Colorado, Colorado Springs, CO. July 1999 |
||
John Spengler, Customer Service |
||
Qualifications |
Twenty-five years management responsibility in the areas of communications, information systems and customer service. |
|
Experience |
Director Business Operations, NeuStar, Inc. (2001-present) |
|
CLVI.Directs and Operates the Customer Support Center for the.biz Registry. Responsible for developing new service processes and procedures. Responsible for delivery of service within Service Level Objectives. | ||
Project Manager, Integrion Financial Network (1997-2000) |
||
CLVII.Overall project management responsibility for the transition of all the Visa Interactive systems to the Interactive Financial Services platform for Integrion. The transition of all back office services to CheckFree platforms. Primary vendor coordination responsibility for IBM, an annual contract of $9.0 million. | ||
Manager Global Operations Support, Visa Interactive Inc. (1994-1997) |
||
CLVIII.Management responsible for a software maintenance team of nine programmers. Team was responsible for the quick resolution of system problems and changes. Managed assigned projects, controlled ad hoc system reports and their distribution. Negotiated maintenance contract with Logica, a software house, for the CSMS system and managed the resulting team of eight consultants. | ||
International Project Manager, Visa Interactive Inc. |
||
CLIX.Responsible for coordination and implementation of Visa Interactive Electronic Home Banking Services in the European Market. Implemented the first international electronic home banking for Barclays Bank in the UK. The pilot was a significant success and the service went into full production in April,1997. | ||
Administrative Manager,Visa International Inc. (1981-1994) |
||
A-24
CLX.Prepare and track the Business Resumption and Administration departmental budget. On-site representative for Business Resumption and Site Emergency requirements. Provide support to the Department Senior Vice President by preparing internal management presentations, analyzing and writing reports. Project manage the establishment of physical security standards for the worldwide data centers, completed site evaluations, recommend improvements and track each center for completion. | ||
Senior Project Manager |
||
CLXI.Responsible for the construction of a fully redundant 65,000 sq. ft. data center and ancillary structures, from the design phase through operational occupancy. The $32.6 million dollar budget included a negotiated ten-year lease. The project completed on time and under budget, with less than 4% in change orders. The environmental systems included three 1250 KVA generators, two 600 Ton cooling towers. | ||
Supervisor, Project Implementation and Facilities |
||
CLXII.Responsible for coordinating new services to be implemented at the McLean Computer Operations Center. Participate in the projects at an early stage and function as central coordinator during implementation. Supervised four hourly employees in the day-to-day activities of maintaining and servicing of office facility. | ||
Department Head Technical Support |
||
CLXIII.Administrative responsibility for six senior technical support analysts. Assigned personnel to hardware and software projects and directed their activities. Prepared operational cost estimates for current and proposed projects; evaluated vendor proposals for purchase of hardware. Coordinated the Operations Center Budget for three years. | ||
Department Head Customer Service |
||
CLXIV.Directed personnel and resources to provide, maintain, and operate a $3.2 million international credit authorization center. Responsible for productivity, growth, morale and job satisfaction for 70 employees. Established programs, plans and budgets for an efficiently run center. Results: A 100% improvement in morale with a 50% improvement in productivity and a substantial reduction of overtime expenses. | ||
Head Telecommunication/Data Processing Analyst |
||
CLXV.Supervised four senior analysts in the design, implementation and maintenance of a $15. million worldwide data network. Monitored and analyzed the performance of a 100 line WATS network on an Automatic Call Distributor. | ||
Education |
Center for Creative Leadership |
|
Electronic Computer Programming Institute |
||
Certificate computer programming. |
||
A-25
Frankie Russell, Product Marketing |
||
Qualifications |
More than 16 years experience in telecommunications, including business development, strategic planning, quality assurance, product management, brand management, and life cycle management for products and services in telecommunications industry. Expertise includes working with IXCs, ILECs, and CLECs to launch new products and services; media and public relations; and marketing communications. |
|
Experience |
Director, Product Marketing, NeuStar, Inc. (2001-Present) |
|
CLXVI.Directs and coordinates activities concerned with research and development of new concepts, ideas, basic data on and applications for, organization's products and services. | ||
CLXVII.Reviews and analyzes proposals submitted to determine if benefits derived and possible applications justify expenditures. |
||
CLXVIII.Develops plan for Industry outreach for OSS services. |
||
CLXIX.Develops and review marketing materials for new and existing products and services. |
||
Group Manager, Identity Services, Network Solutions, Inc. (1999-2000) |
||
CLXX.Launched five enhanced services resulting in over $10 million in new revenues. | ||
CLXXI.Negotiated deals with vendor companies to secure technology for enhanced services; programs included multiple-year registrations which established the company's renewal processes; dot com essentials, the company's first bundled product; Expedited Transfer Service, resulting in over $4 million in its first year; Internet Keywords, a partnership with Real Names Corporation; and 800 number domain names, a "Call or Click" program concept that promotes purchasing a domain name to match an existing 800 number. |
||
Independent Consultant, McKinley Marketing Partners (1998-1999) |
||
CLXXII.Senior-level Independent Consultant leading strategic product development projects for Bell Atlantic (now Verizon), Network Solutions, and Cable and Wireless. | ||
CLXXIII.Founder of consulting firm, Out-of-the-Box Marketing, Inc. Executed consulting contracts with WinStar Communications, Inc., City First Bank, and Kalidescope Kollections. First year billings exceeded $250,000. |
||
CLXXIV.Group Manager, Quality Assurance, TELE-TV Systems (joint venture between Bell Atlantic, NYNEX and Pacific Telesis) (1995-1997) |
||
CLXXV.38% improvement in productivity achieved in first six months. Led six QA analysts in support of software metrics, defect tracking/resolution, and documentation for video services product being developed for the company and a major international client. Recruited to this position by exemplifying senior and technical team leadership abilities necessary to represent the company internationally. |
||
Marketing & Communications Manager (1995-1996) |
||
A-26
CLXXVI.Selected for this high-profile PR position to work closely with executive team in launching the company's introduction into highly competitive digital TV market. Served as spokesperson interfacing with TV, computer, and telecommunications media and the company's key international partners. | ||
Marketing and Media Relations Manager, Video Services, Bell Atlantic (1995) |
||
CLXXVII.Chosen as spokesperson for leader in video services. Conceptualized first health and fitness channel for TELE-TV. | ||
Marketing Manager, FeatureFAX (1991-1994) |
||
CLXXVIII.Spearheaded primary and secondary research for first-of-its-kind enhanced facsimile product. Developed specialized marketing concepts to direct initial marketing strategies. Resolved regulatory constraints through partnership with Cable & Wireless. | ||
Marketing Manager, Thinx Software—Information Services (1990-1991) |
||
CLXXIX.Conducted initial market analysis for company's first venture into computer software. Served as primary Microsoft contact as Independent Software Vendor representative. Interpreted market readings and recommended product withdraw strategy. Successfully identified buyer and sold product. | ||
Product Manager, Operator Transfer Service, Carrier Marketing and Operator Services (1987-1990) |
||
CLXXX.Added $4 million to the bottom line by launching innovative operator transfer service; significantly improved relations with top long-distance carrier customers, including AT&T, MCI, and Sprint. | ||
Assistant Product Manager, Bell Atlantic Calling Card (1984-1987) |
||
CLXXXI.Championed proactive sales/marketing cultures (100 reps with Fortune 500 clients) to support initial launch of company's first calling card. Developed marketing campaigns targeting strategic market segments. | ||
Education |
MS Candidate, Engineering Management, George Washington University |
|
BA, Business Management & Marketing, National Louis University |
||
Member, Association of Business and Professional Women; Association of Black Women Entrepreneurs. Serves as Vice Chairman, College Partnership Program, Fairfax County, Virginia. |
||
Spencer Stefansic, Systems Engineering |
||
Qualifications |
Over nine years of experience in the telecommunications and technology industries developing client/server database systems; Internet/intranet/extranet applications and managing project implementations and large systems/IT organizations. His expertise includes implementation and management of middleware billing systems; program management of disaster recovery operations for a national wireless operator's data warehouse environments. As a manager, his responsibilities include staffing and managing over 75 employees located in four different regions; contract negotiations and vendor management; and process control. |
|
Experience |
Director, Systems Engineering, NeuStar, Inc. (2001-Present) |
|
A-27
CLXXXII.Director of a 45-person group responsible for implementing cutting edge systems at the enterprise level. Systems include the.BIZ Top Level Domain registry system; and systems providing telco-specific services such as the CARE Clearinghouse, Code Administration System. | ||
CLXXXIII.Management responsibilities include contract negotiation/vendor management, budget management and process control, invoice reconciliation, and monthly expense/capital report reconciliation |
||
Director, Billing/Middleware Development, Nextel Communications (2000-2001) |
||
CLXXXIV.Responsible for the middleware development group, and after internal reorganizations, management and support of the Nextel billing systems group, to include production support, and reporting development organizations. This expanded group has also been tasked with design and implementation of an Enterprise Application Integration system, based on IBM's MQSeries products, with a goal of replacing the current "spider web" of point-to-point system interfaces. | ||
CLXXXV.Management/budgetary responsibilities expanded to include responsibility of a 75-person group in four cities, with a $25 million+ budget. |
||
Director, Advanced Communications, Nextel Communications (1999-2000) |
||
CLXXXVI.Director of a 40-person group (with locations in Atlanta, Denver and Reston) responsible for implementing cutting edge middleware systems at the enterprise level. Systems include an EDI/XML based B to B infrastructure for transmitting bills to large corporate customers electronically; architecture and implementation of an enterprise wide database replication backbone; call detail Traffic Management systems; and development of an EJB-based API platform/system to the NEXTEL billing system, a proprietary product with no native API access. | ||
CLXXXVII. |
||
CLXXXVIII.Management responsibilities include contract negotiation/vendor management, budget management ($12 million budget) and process control (assurance and adherence to Nextel policies), invoice reconciliation, and monthly expense/capital report reconciliation. |
||
Senior Manager, Web Architecture and Infrastructure, Nextel Communications (1997-1999) |
||
CLXXXIX.Responsible for program management of the design, development and deployment of Nextel intranet and Internet applications, using Netscape web and Oracle web/database technology. Systems include an Oracle Application Server based rate plan workflow application, MapInfo-MapXtreme web based Internet cellular coverage application, and the Nextel Online Web Sales systems. | ||
CXC.Additional responsibilities included the program management of the National Activity Report (NAR) disaster recovery operation. Coordinated all system stabilization, data and software recovery/repair operations. Responsible for complete project management of all technical resources needed to stabilize the data warehouse environment, establish process control, develop/implement disaster recovery plans and create a 7x24 rapid response process. |
||
A-28
CXCI.Operated in a dual capacity providing special assistance to executive leadership (CIO, VP Development) by leading/supporting special projects research (Electronic billing payment/presentment), application gateway architecture development, and business systems integration support. |
||
Senior Systems Manager, OAO Corporation (1997-1997) |
||
CXCII.Technical Manager, providing technical expertise and program management in the architecture, development and deployment of intranet applications, using Netscape web and Oracle database technology. Projects include a classified scientific data warehouse (the Virtual Data Center, or VDC) for the Ballistic Missile Defense Organization (BMDO), accessed via a geographically distributed intranet web infrastructure, utilizing Java and CORBA technologies. Responsible for coordinating the development efforts of four separate BMDO technical groups, each group with a different mission and location within the organization. | ||
Principal Consultant, Netscape Communications (1996-1997) |
||
CXCIII.Technical/Project Manager, providing consulting expertise in the development, installation and deployment of intranet/Internet applications, using Netscape web technology. Projects include an electronic document management system, messaging solutions, Internet content publishing systems, and web based executive information systems, in the healthcare and telecommunications verticals. Responsible for engagement management, as well as exploiting new consulting opportunities in conjunction with the product sales force. | ||
Senior Principal Consultant, Oracle Corporation (1993-1996) |
||
CXCIV.Technical Manager, providing consulting expertise in the installation and deployment of the Oracle Transparent Gateway for M. Applications developed include an interactive voice response system, accessing legacy data through the gateway. Management responsibilities include engagement and project management of on-site consultants; placement of consultants at customer sites; and customer relations. |
||
CXCV.Technical Team Leader, provided database/application design review and CASE expertise, using Designer/2000, for a data warehouse environment consisting of an Oracle7 v7.2 database, storing 300 million records and requiring 500 Gigabytes of storage. |
||
Project Manager, Suncoast Scientific, Inc. (1991-1993) |
||
CXCVI.Lead eight programmers/analysts through analysis, logical and physical database design activities, using Oracle™ CASE, for a state government agency client/server application. Provided development expertise building eight applications of over 130 forms using Oracle Forms and Reports applications, with an Oracle v6.0 database. | ||
U.S. Air Force (1983-1991) |
||
CXCVII.Aircrew member, operations and systems design. | ||
Education |
B.S., Physics, University of West Florida |
|
Richard J. Tindal, Channel Management |
||
Qualifications |
Over 15 years experience in business development and sales with a recent focus on domain names and internet identity products. Responsible for operations management of the gTLD product suite. |
|
A-29
Experience |
Vice President, Sales and Business Development NeuStar, Inc. (1999-Present) |
|
Establish strong technical, operational, contractual, and billing relationships with all ICANN accredited Registrars to promote, sell and support.BIZ domain names. Work with strategic partners to enhance the functionality and utility of the.BIZ space. |
||
Vice President, International Operations Melbourne IT. (1999-2001) |
||
Manage Melbourne IT registrar operations in North America, Europe, Asia and Latin America. Plan and execute the functions of business development, sales, marketing and account management. Oversee all technical, operational, financial and marketing issues associated with major distribution channels. Grow revenues through these wholesale channels. Identify and introduce new product offerings to complement the existing, gTLD product suite. Ensure channel retention and sales growth by maintaining strong relationships with distribution channels. Identify and respond to market trends and emerging technologies that impact the product line. |
||
Director of Business Development, Network Solutions (1998-1999) |
||
Developed and executed a global marketing strategy for domain names and associated internet identity products. Performed competitive analysis, forecast demand, identified distribution channels, established alliances, programmed and managed a marketing budget, created promotional materials, mounted product presentations, prepared proposals and negotiated sales closings. Established distribution relationships with major hosting, design, access and portal companies. Substantially grew business with these companies and solidified business relationships through co-marketing programs and the establishment of high quality account management. |
||
Manager, International Sales, Texas Instruments (1996-1998) |
||
Managed the worldwide sales of wireless communications products (systems comprising TV, digital and thermal cameras, handheld computers, data compression and transmission software, radios and data link modems). Introduced the product line to government and commercial customers in the international market. Established long-term business relationships throughout Asia-Pacific, Europe and the Middle East. Trained and led a network of sales agents in 19 countries. Fostered key teaming relationships with manufacturers of complementary technology to sell joint applications. Identified and exploited synergies in distribution channels and promotional activities with these technology partners. Designed and produced audio-visual and interactive CD presentations. Trained foreign customers in proper operation and maintenance of systems they had purchased. |
||
Contract Negotiator, Marine Spill Response Corp. (1994-1995) |
||
Negotiated high cost/high complexity contracts with vendors in the US, Norway and the UK. The contracts were typically for system integration services, equipment test and evaluation, software/technology licensing, equipment purchase, and training services. Secured improvements in price, terms and conditions while retaining positive, long-term relationships with these business partners. Settled disputes over technical, contractual or financial matters. Redefined Statements of Work (SOW) and managed Change Order Processes. |
||
A-30
Deputy Director: International Programs, Australian Defense Force, Systems Command, Melbourne, Australia (1990-1993) |
||
Led a team of 36 persons responsible for cooperation programs with government agencies in Malaysia, Singapore, Japan, Israel, New Zealand, Italy, the UK, France, Canada and the USA. These programs involved logistics and engineering services, acquisition support services, training, technology sharing and equipment sales. Planned, organized and managed the performance of this team. Cultivated excellent relationships with counterparts in foreign countries, and used these personal relationships to maximum effect —accelerating agreements and innovating beneficial provisions. Developed an outstanding team spirit and productivity within the department, and mentored high performers into management positions. |
||
Defense Attaché Staff, Embassy of Australia (1986-1990) |
||
Responsible for financial, contractual and technical management of major equipment and technology acquisition programs. Liaised with multiple government departments in the US and in other countries. |
||
Education |
Honors Degree in Business Administration, University of Southern Queensland, Australia |
|
Spanish Language Certification-in progress. |
||
Ahita Vessali, Billing & Collections |
||
Qualifications |
Senior Professional with over 16 years of experience in increasingly responsible positions in the field of Accounting/Finance (eleven of those years being in the telecommunications industry). She has experience in several financial systems including G/L, A/P, A/R, Billing and Inventory with broad experience in banking operations, business acquisitions/mergers and systems integration. She exhibits outstanding organizational and management skills, as well as, extensive financial analysis expertise. |
|
Experience |
Director, Billing & Collections, NeuStar, Inc. (2000-Present) |
|
CXCVIII.Responsible for the accuracy and timeliness of all invoices, as well as, cash applications for all lines of businesses at NeuStar. | ||
CXCIX.Responsible for cash management support, billing system implementation and revenue to A/R cycle reconciliation. |
||
Controller, Program Control Operations, Spacenet, Inc. (1998-2000) |
||
CC.Directed accounting staff of 10 in Program Control Operations including billing and collections, capital lease accounting and program profitability analysis. | ||
CCI.Provided support for cash management, risk management and budget functions. |
||
CCII.Improved accuracy and timeliness of invoices, as a result of SAP invoicing and Order-To-Cash processes. |
||
CCIII.Reconciled revenue to A/R cycle and coordinated internal and external audits. |
||
Manager, Financial Analysis & Contract Revenue, GE Capital Spacenet Services, Inc. (1994-1998) |
||
CCIV.Managed a group of six billing and collections accountants. | ||
A-31
CCV.Ensured accuracy of monthly customer invoices and provided high quality customer service for key accounts including MCI/USPS, Hollywood Video, Shell Oil, Rite Aid, JC Penney, and Kmart. |
||
CCVI.Monitored A/R effectively and pursued aggressive collections on aged receivables. |
||
CCVII.Automated and streamlined billing processes (annual labor savings-2000 hours). |
||
CCVIII.Coordinated systems integration of the new subsidiaries that included 24% international and domestic travel (completed Germany's systems integration in April 1997 and achieved a Recognition of Excellence award). |
||
Senior Cost Accountant, GTE Spacenet Corporation (1989-1994) |
||
CCIX.Performed profitability analysis for both domestic and international contracts. | ||
CCX.Evaluated risk of carrying inventory to forecast and developed a new cost-of-goods sold recognition process by enhancing our inventory system to provide accurate equipment cost (cost accuracy-100%). |
||
CCXI.Approved domestic A/P invoices and improved A/P processes to alleviate possible duplication of payments to vendors (1996 savings-$200 thousand). |
||
CCXII.Audited and reconciled various physical inventories including our Manassas warehouse, which consisted of equipment in excess of $30 million and ensured existence of tight inventory controls. |
||
CCXIII.Coordinated the development of a new enhanced fixed asset system (annual labor savings-500 hours). |
||
Branch Manager/Assistant Vice President, Trustbank Savings & Loan Association (1983-1989) |
||
CCXIV.Increased growth of accounts and deposits by 15% on an annual basis by cross-selling new accounts and developing clientele through telemarketing, mail contacts and Chamber of Commerce. | ||
CCXV.Supervised the operations of a full service branch and ensured compliance with regulatory policies. |
||
CCXVI.Recruited, motivated, trained and supervised staff of 20 employees. |
||
Education |
Certified Public Accountant, 1997 |
|
MBA, Finance, George Mason University |
||
BBA, Accounting, Marymount University |
||
A-32
Peggy Wenneman, Information Technology and Services |
||
Qualifications |
More that 18 years of management experience in information technology for the Internet, IT and telecommunications industries. Her expertise includes managing global operations for a multi-nations telecommunications company; supporting multiple call centers; managing and supporting large data centers; and customer and data center migrations. Accomplishments include managing and staffing network and infrastructure development and support organizations; meeting and exceeding Service Level Requirements (SLRs) for availability in order provisioning environments; and working with IXCs and LECs to automate electronic information exchange to support service provisioning. |
|
Experience |
Director, Information Technology and Services, NeuStar, Inc. (2001-Present) |
|
CCXVII.Manages the technical operations group and the network support group in a 7x24 real-time mission critical production environment. | ||
CCXVIII.Responsible for supporting, monitoring, testing and troubleshooting hardware and software problems. |
||
CCXIX.Manages all Tier 2 support for all LAN/WAN based applications. |
||
CCXX.Participates in database architecture strategy development, database design and engineering, and reliability and performance enhancements. |
||
Vice President, Global Standards, Cable & Wireless Global (2000-2001) |
||
CCXXI.Created a multi-cultural organization to establish standards across 15 business units spanning the United States, Europe, and Japan. | ||
CCXXII.Directed organization to define, communicate, integrate and enforce standards globally. |
||
CCXXIII.Participated on Executive eGO Board (e Buisness initiatives) and Global Information Management Steering Board. |
||
CCXXIV.Saved over $2M in operating costs within first five months |
||
CCXXV.Developed fast-path (1-4 week) business process to select standard technology utilizing key stakeholder participation, and supporting 90-day product launch life cycle. |
||
CCXXVI.Implemented Web-based knowledge management system reducing e-mail congestion and dependency on subject-matter experts. |
||
CCXXVII.Improved knowledge transfer and project startup efficiency. |
||
CCXXVIII.Initiated development of enterprise interface architecture enabling faster product launch. |
||
Senior Director, Internet IT (1998-2000) |
||
CCXXIX.Directed all activities to support C&W Internet network and IT systems, including migration of Internet network and customer base to C&W purchased from MCI, customization and support of Internet Operational Support Systems, support of multiple customer call centers, and transition of Internet customer base upon sale to Prodigy. | ||
CCXXX.Enabled C&W to launch first Internet business by migrating consumer base of 350,000+ dial customers within a four-month window. |
||
CCXXXI.Migrated live network with no customer down time. |
||
A-33
CCXXXII.Implemented Customer Care, Order Entry, Security, Provisioning, and Financial systems within four months for Internet dial business. |
||
CCXXXIII.Reduced operating cost structure from $350,000 per month to $90,000 within six months. |
||
Senior Director, IT Systems (1996-1998) |
||
CCXXXIV.Directed all IT development and maintenance activities for Sales, Marketing, Commissions, and Network Provisioning systems with a staff of up to 100 employees. | ||
CCXXXV.Implemented flow-through Circuit Order through Circuit Completion system and established automation agreements with 28 LECs, to fully automate electronic information exchange. |
||
CCXXXVI.Improved Service Delivery intervals by 10 to 12 days by identifying and implementing performance enhancements to the Switched Network Provisioning system. |
||
CCXXXVII.Provided 99.95% system availability of Circuit Order Provisioning, up from less than 80%, in six months during a 400% circuit transaction increase. |
||
CCXXXVIII.Provided C&W with positive ROI within three months through consolidation of five legacy systems into a single Network Trouble Management system. |
||
CCXXXIX.Developed a Consolidated Commissions System that enabled flexible changes to compensation plans and delivered company's first on time compensation program. |
||
Senior Manager, IT, MCI (1983-1996) |
||
CCXL.Managed all life-cycle system development and implementation activities and utilized "bleeding-edge" technologies. | ||
CCXLI.Managed development and delivery of client-server rate quotation system. |
||
CCXLII.Enabled product launch (1-800-COLLECT) within eight-week period. |
||
CCXLIII.Implemented first production DB2 application within Baltimore/Washington region in 1987; supported traffic alarming system that ran 24x7; and received 1987 Achievement & Commitment to Excellence (ACE) Award. |
||
CCXLIV.Managed software migration of all mainframe software across four data centers, supporting over 200 application groups; received Flexible Flier Award (Manager of Year) 1986. |
||
CCXLV.Managed the migration of two data centers over a weekend, including all operational systems and data; closed one data center; and realized significant reduction in operating costs. |
||
CCXLVI.Implemented various technical improvements to Accounts Receivable System which reduced batch processing from 48 hours to 8 hours, while increasing volume of throughput by 250%. |
||
Education |
MBA, George Mason University |
|
International Economy, Technology & Industry studies, Oxford University |
||
Beta Gamma Sigma National Honor Society |
||
Board Member and Secretary of George Mason Alumni, 1997-1998 |
A-34
B. Contractor Requirements
NeuStar will execute our vision for the usTLD by significantly increasing and maintaining the utility and integrity of the space. We will meet the objectives laid out in the Statement of Purpose through implementing our service and policy administration throughout the usTLD namespace.
HIGHLIGHTS
The usTLD administrator must be more than just a registry operator. Because of the complexity of the usTLD space, its administrator must act as a registry, a registrar for undelegated third-level localities, and a service and policy administrator. To perform all of these functions, there must also be an understanding of the many kinds of customers being served. To successfully administrate the usTLD registry, there must be a demonstrated understanding of the needs of registrars, registrants, and delegated managers, including both delegees and subdelegees in the locality space, as well as of the stated needs of the DOC. The policy and service solutions described in this section were developed with these needs in mind.
The DOC has established a clear need for the provisioning of high-quality core functions and locality-based and expanded functions, as well as the implementation of and adherence to usTLD policies. Our provisioning of these services works to meet the objectives laid out in Sections B.1 through B.5 of the RFQ.
In accordance with RFQ requirements, NeuStar will perform the functions of usTLD administrator as a prime contractor, incorporated within the state of Delaware. NeuStar's corporate offices are in Washington, D.C., and all of our usTLD registry servers will be located within the United States. NeuStar will not charge the U.S. Government for performance of these functions.
Executing our vision through serving as the usTLD administrator, we will offer the best value for the most accurate, up-to-date, and available registry services.
Our policy and service solutions are highlighted below and in Sections B.1 through B.5 of this proposal.
Statement of Purpose—NeuStar's solution will support competition and promote use of the usTLD, by encouraging communication, ensuring equitable application of policies and procedures, and cultivating an environment conducive to innovation. We will ensure the stability of the DNS and inspire consumer confidence with a secure, robust, and reliable technical infrastructure.
Core Registry Functions—NeuStar will provide a comprehensive suite of core registry functions that take into account the needs of all of our customers—delegated managers, registrars, and registrants. We will leverage our Centralized usTLD Database and Enhanced SRS, and implement automated registration processes, updates, and zone file generation, to provide accurate, up-to-date information on demand.
Core Policy Requirements—NeuStar's policies and processes will be designed for collaborative partnerships between the usTLD administrator and the usTLD community. As the trustee of a valuable public resource, we will develop our policies to ensure that our operations serve the public interest.
Locality-Based usTLD Structure Functions—NeuStar will modernize the usTLD locality space by working with delegated managers to centralize all data currently managed by locality delegees and subdelegees. Our collaborative approach to modernizing this space will ensure that the needs of both delegated managers and registrants are met.
B-1
Expanded usTLD Space Functions—NeuStar's expanded usTLD registry will promote registrar competition and encourage registrations in the usTLD namespace. We will work closely with registrars in both our accreditation and certification processes.
NeuStar's role in communications industries, part of our very identity, has been as an administrator of U.S.-based, mission-critical public resources. We understand the difference between acting simply as a registry operator and acting as an administrator. Our goal is to serve every customer—registrars, delegated managers, registrants, and the DOC itself—to provide to those customers with the best value, highest quality registry possible.
B-2
NeuStar's solution for managing the usTLD namespace amply meets the objectives defined by the DOC and will both enhance its utility and drive its widespread adoption.
HIGHLIGHTS
The usTLD was created to provide a locus for registration of domain names to serve the Internet community of the United States, and is available to a wide range of registrants. However, it has not attracted high levels of registration and utilization when compared with other ccTLDs in part because of its hierarchical nature. Because the usTLD has been underutilized and underdeveloped, the DOC now seeks proposals to centralize management and coordination of the existing usTLD space while expanding and enhancing it to encourage use and innovation. NeuStar's solution, discussed below and in the subsections to follow, has been carefully designed to meet all the DOC's objectives for the space.
NeuStar will develop a more robust, certain, and reliable system as a framework of accountability for the delegation and the administration of the usTLD.
NeuStar believes that the importance of expanding the scope and quality of core registry functions for the usTLD cannot be stressed enough and that the expanded usTLD services should follow, in large part, the registry/registrar model that has become commonplace in the industry. Not only will this approach allow the development of a feature rich domain space, it also will establish a level of consumer familiarity that will help ensure a successful roll-out of an enhanced usTLD. Therefore, the administrator must develop a robust shared registry system (SRS) comparable to those being built for the new generic TLDs that have been established by ICANN.
The development of a secure, functional and robust SRS is not a trivial task. In developing such an SRS, NeuStar believes that a number of key elements must be implemented to handle delegation based TLD registration. In particular, Whois functionality should be centralized in the registry operator following the "thick registry" model. A "thick registry" centralizes registration data with the TLD registry, rather than placing most of the storage burden on each registrar (or delegee). This centralization increases security, functionality, and stability. NeuStar submits that existing usTLD delegation operators should be required to transition to a "thick registry" model. Other important aspects of a robust, trusted infrastructure will include:
For example, currently the usTLD does not provide a comprehensive Whois service. This has a serious, negative impact on resolving some network operations problems. NeuStar will address this and
B.1-1
other issues in the required compliance report on the usTLD space and will implement such a service with enhanced privacy protections.
Please see Proposal Sections B.3, Core Policy Requirements and O, Proposed Technical Plan, for more detailed information.
NeuStar will promote increased use of the usTLD by the Internet community of the United States by:
NeuStar's mission is to enhance the operation and utilization of the usTLD by bringing to bear the strengths and innovation of the next generation registry systems currently being deployed in the generic TLD space. As the usTLD Administrator, NeuStar will work with the Internet Community, the DOC, and ICANN to expand significantly the use and value of the current usTLD space by permitting direct registration of non-hierarchical names while centralizing and coordinating the management of the current usTLD delegations. This community-based, expanded approach will allow NeuStar to develop effective policies and procedures to ensure that current uses of the usTLD not only are protected and enhanced but also that this important public resource is managed in a manner designed to serve the public interest. To accomplish this goal, NeuStar proposes to analyze concerns with existing usTLD delegations as contemplated by the RFQ. NeuStar will then develop policies and procedures to ensure maximum utility of the existing delegations and registrations.
The complexity of the usTLD hierarchical namespace may discourage some Internet users from registering a name under the TLD. NeuStar, therefore, supports the expansion of the usTLD to allow direct second-level registrations and potentially new, concept-based hierarchies targeted to specific communities or for specific purposes. Moreover, NeuStar believes that by developing additional services to enhance the utility of the usTLD for its registrants, the usTLD's popularity and utility can be made to rival the existing generic TLDs.
In developing services, NeuStar's approach will be to work collaboratively with registrars and end users. Registrars and domain name registrants be encouraged to provide constant feedback and will have access to discussion lists and feedback forms. This feedback will be compiled and carefully considered in determining the ongoing development of the registry's systems, procedures, and services.
By improving the level of service and degree of coordination of the existing delegated space, NeuStar believes that there will be increased use of that space. For many functions, there is an inherent value in the kind of geographic categorization developed in RFC 1480. Administered properly, the delegated space in the usTLD could become as valuable and highly used as the expanded space is assumed to be.
Please see Proposal Section B.4, Locality-Based usTLD Structure Functions; Section D, Enhanced Services; and Section L, Funding for usTLD for more detailed information.
NeuStar will create a centrally administered and efficiently managed structure that ensures registrant/consumer confidence as well as infrastructure stability.
NeuStar expects to tighten significantly the operation of the delegated usTLD space. It will achieve this as discussed above, by centralizing administration and operation of the usTLD, except where decentralization is required. For all delegees there will be operational and technical standards. The centralized service will be offered for those delegees primarily interested in addressing the "policy" function of the delegation. In addition, the usTLD will follow the "thick registry" model for the
B.1-2
enhanced space, whereby primary registrant data are kept with the registry, rather than the registrar. These measures will increase dramatically the usTLD Administrator's ability to ensure that the promise of the usTLD is realized.
Please see Proposal Sections B.2, Core Registry Functions and F, usTLD Centralized Database and Enhanced SRS, for more detailed information.
NeuStar's solution will ensure continued stability of the usTLD and of the domain name system as a whole.
Citizens, businesses, consumers, and even governments depend on the Internet for communication and commerce. Key to this dependence is the domain name system (DNS). The Internet community simply cannot afford a DNS that shows any type of unreliability. An unstable DNS has disastrous effects. It prevents communication among many thousands of organizations, hinders trade between businesses and customers, and prohibits individuals from communicating with each other or contacting their government. NeuStar is acutely aware of the immense responsibility attached to the administration of such a significant public resource and will undertake all measures required to ensure its success, reliability, and security. NeuStar will utilize existing DNS infrastructure developed for the dot-biz TLD to ensure the enhanced operation and stability of the usTLD. We will do so in several ways:
By providing a stable and secure zone file distribution network—NeuStar's usTLD registry will not impact operation of the existing DNS root. Publication and distribution of usTLD zone files will be entirely compatible with existing DNS standards and procedures. Our zone file distribution network will operate in parallel with the existing root server network and will employ accepted, modern, strong, encryption-based procedures. The root servers for the network will be protected by special software and hardware mechanisms. NeuStar's system will be developed and tested to scale seamlessly into the future for TLD name service.
By preserving the unique global domain name system—The NeuStar design has been developed on the principle of maintaining consistency and interoperability through existing standards such as RFC 1034, RFC 1123, RFC 1480, and their successors. In addition, NeuStar is committed to working closely with the Internet Engineering Task Force (IETF) and other relevant organizations to ensure the stable evolution of the domain name service technologies. NeuStar is supportive of implementing policy restrictions where necessary to protect important Internet and ICANN policies and, thus, is committed to the administration of the usTLD in a manner that preserves the current system's strengths and acknowledges it as a critical public resource.
By acting in accordance with sound business practices and operational management—NeuStar is founded on principles of strong management, a tight user-oriented focus, and a clear vision. Market analysis and an understanding of the usTLD community is at all times the driver for NeuStar solutions. The NeuStar executive team brings an abundance of experience in designing, implementing, and maintaining technology-based services especially in an Internet environment.
The NeuStar usTLD registry solution will provide exceptional services. We are acutely conscious that support for domain names extends far beyond the initial registration or delegation for the entire life of the domain name. By providing effective, long term operational solutions, the domain space will thrive ensuring its own stability and encouraging the improvement of service levels within existing domain spaces.
By providing dedicated and responsive channel management—The NeuStar usTLD registry will deliver its solutions in the enhanced space via the registrar community. In this context, NeuStar understands the importance of providing an absolutely neutral third party registry service to facilitate the advancement of effective relationships in an extremely competitive environment. In this way, customer needs will drive the registry.
B.1-3
By developing an enhanced, community-based mechanism for maintaining and developing the existing usTLD space—The existing usTLD space has suffered from a lack of coordination and technical innovation since its inception. NeuStar will develop a strong community-based mechanism for managing existing delegations. Steps to improve the space will include analysis of delegee compliance with usTLD policies, quality of service improvement, establishment of a comprehensive centralized Whois service, development of minimum technical standards, and provision of outsourced technical services for delegees. These and other measures will ensure the continued viability and improvement of existing usTLD services.
Please see Proposal Section A, usTLD Organiztion; Section B.2, Core Registry Functions; Section B.3, Core Policy Requirements; Section F, usTLD Centralized Database and Enhanced SRS; and Section O, Proposed Technical Plan for more detailed information.
NeuStar's management of the usTLD will be consistent with the Internet Corporation for Assigned Names and Number's (ICANN) technical management of the DNS.
Since the DOC, through the National Telecommunications and Information Administration (NTIA), issued the statement of policy on the management of Internet names and addresses, the Internet community has expended significant effort in the development of policies and mechanisms for the governance of the Internet DNS, as well as enhancement of existing TLDs and the introduction of new TLDs. These efforts have resulted in development of a workable shared registry model that encourages competition and Internet stability, as well as protects the rights of individual Internet users. NeuStar has, where appropriate, modeled its solutions to be entirely consistent with ICANN policies and DNS management principles.
Please see Proposal Sections F, usTLD Centralized Database and Enhanced SRS, and O, Proposed Technical Plan, for more detailed information.
NeuStar will allow for the adequate protection of intellectual property in the usTLD.
NeuStar recognizes and supports the need for appropriate protection of intellectual property. NeuStar will implement a "sunrise" trademark program patterned after the "daybreak" proposal of the ICANN Intellectual Property Constituency. This program will allow registered US trademark holders and applicants a priority opportunity to register their marks within the usTLD. NeuStar also will implement appropriate dispute resolution mechanisms designed specifically for the usTLD but consistent and compatible with the ICANN Universal Dispute Resolution Policy (UDRP). Finally, NeuStar will explore additional policy and mechanisms as needed to address all manners of intellectual property issues in the usTLD.
Please see Proposal Sections B.3, Core Policy Requirements and I, Start-up Phase Policies, for more detailed information.
NeuStar will establish and maintain consistent communication between the Contracting Officer's Technical Representative (COTR), the Contracting Officer, and ICANN.
As part of its role as a neutral provider of mission critical infrastructure and services for important public resources, NeuStar has a history of coordinating and working with numerous agencies and industry participants in performing its functions. For example, as the NANPA, NeuStar works with the FCC, the North American Numbering Council, and industry forums as well as with individual telecommunications carriers. NeuStar has been highly successful in these endeavors and will bring these same communications abilities to the management of the usTLD. In particular, NeuStar will identify dedicated liaison officers with the organization to ensure consistent communication between it and the Contracting Officer, the COTR, and ICANN. Moreover, NeuStar will develop outreach programs for
B.1-4
the usTLD community including registrants and delegees, to ensure that the developing TLD meets the needs of its users.
Please see Proposal Sections B.2.7, Industry Representation/Compliance, and B.3.5, Additional, Alternative, or Supplemental Policies, for more detailed information.
NeuStar's solutions will address each of the DOC concerns. Indeed, because NeuStar's experience in the provision of mission critical public interest functions to US industry is unmatched, the proposed solution significantly exceeds these requirements and will result in a usTLD that will serve as the model for the ccTLD community.
B.1-5
B.2 Core Registry Functions
NeuStar's proven experience in delivering high-quality public resource administration services will ensure that registrars, delegated managers, and registrants receive a total service package delivered in a neutral, even-handed manner.
HIGHLIGHTS
Any administrator of the usTLD must understand the complexity of functions and services that need to be offered. In addition to understanding the needs of registrars and their registrants, this administrator must also appreciate the needs of delegated managers and registrants in the hierarchical locality space, whether they register through the registry or through a delegated manager. The ability to administer a system with three distinct types of end-users, all with their own needs and issues, requires support services that can respond to all of these needs.
As depicted in Exhibit B.2-1, usTLD registry services, zone file generation, and Whois services are the central components of our registry service offering. These components on their own make up a simple registry; however, there are equally important support functions that make up a truly successful usTLD registry. Our total service package, highlighted below and in Sections B.2.1 through B.2.16, includes all of the requirements listed in RFQ Section B.2 as well as the additional services and functions that we believe are necessary to serve all of our customers and to turn the usTLD registry into the model country-code top-level domain. As required, NeuStar will provide all systems, software, hardware, facilities, infrastructure, and operations to support these functions.
usTLD Nameserver and usTLD Zone File Administration—NeuStar's usTLD architecture is designed to be flexible, scalable and high-available to virtually eliminate downtime while providing for smooth growth. Redundant data centers in Virginia and Illinois ensure high service availability, while dynamic, near-real-time transfers of zone file data provides up-to-date, authoritative responses from the usTLD nameserver constellation.
Whois Database Administration—NeuStar will centralize the usTLD Whois database in both the expanded space and the locality space by developing and implementing two accurate and up-to-date, logical databases, one for registrants and registrars, and one for delegated managers. NeuStar's Web-based and port 43 interfaces to this enhanced Whois database will allow multiple field and string searches, freely available to the public.
usTLD Delegated Manager Database Administration—NeuStar will reach out to all delegated managers in the locality space in order to develop and implement a centralized database of delegated managers. This centralized information will serve registrants in the locality space while enabling us to contact those managers quickly to resolve issues effectively.
[Exhibit B-2.1. NeuStar will provide usTLD services with the best value and highest degree of quality and responsiveness. Graphic Omitted: highlight of various categories of usTLD services.]
Data Escrow—NeuStar will arrange frequently for data escrow of the usTLD registry, to maintain continued operations and availability in the unlikely case of a catastrophic loss of data.
B.2-1
Industry Representation/Compliance—NeuStar's involvement with Internet standards and policy organizations will contribute to our operation of the usTLD as the model for a country code top-level domain.
Integration Assistance—NeuStar will implement an operational test-and-evaluation facility and provide registrars with Registrar Tool Kit software in order to familiarize them with our thick registry and assist them in passing our technical certification process.
Compliance Monitoring—NeuStar will monitor delegated managers for technical compliance, not only as part of our initial compliance investigation and report, but also throughout the life of their delegations. This will ensure that NeuStar's database remains up to date, that delegated managers remain compliant with usTLD technical requirements, and that the usTLD retains a U.S. Nexus. This compliance monitoring will maintain the improved integrity of the usTLD.
Web Site—NeuStar will develop and implement a usTLD Web site for the Internet community as well as for private members, including delegated managers and registrars. This Web site will provide access to registry functions, information to the Internet community, and the ability to register domain names in the undelegated locality space.
Documentation and Training—At NeuStar, we believe that clear, concise documentation and training for our staff and our customers is essential to provide the best service to those customers. NeuStar's external documentation, from our Programmer's Guide to our information on marketing the usTLD, are intended to give our customers the highest level of comfort when working with the usTLD registry.
Customer Relationship Management—NeuStar's enterprise-wide CRM program assists with channel management and outreach for the usTLD. We use CRM in combination with our extensive market and customer knowledge to ensure that we meet our commitment to timely, responsive, and high-quality customer service.
Reporting—NeuStar's Web-based reporting system will have built-in functionality to provide reporting information to registrars on all aspects of their interaction with the registry.
Progress and Quarterly Reporting—As required, NeuStar will submit progress reports to the DOC that will indicate the status of all major events and all major work performed during the reporting period.
Help Desk—NeuStar will provide Help Desk services through our IP Customer Service Center, and will provide assistance to registrars, delegated managers, and registrants in the undelegated locality space.
NeuStar's experience in providing mission-critical services to the telecommunications industry has given us an understanding of what functions constitute the best service packages. The functions and services outlined in this section represent what NeuStar has come to believe are essential for a total package solution, and our flexibility will allow us to incorporate additional services as changes in the industry require them. A registry is more than servers and databases; it must serve its customers not just as a set of servers, but also as an administrator providing services to support those customers.
B.2.1 Primary usTLD Server
The essential core function of the usTLD Registry is providing authoritative name service for its domains.
Failure of a usTLD administrator to provide a reliable, secure, and robust nameserver function represents a fatal flaw in its system and ensures an unsuccessful administration of the usTLD. NeuStar will implement a nameserver architecture that is highly superior to the traditional architecture that likely will be adopted by other bidders.
B.2-2
The traditional implementation begins with one nameserver acting as the primary ("master") for zone data, which would then be transferred to secondary ("slave") servers. Located in physically separate locations, these multiple authoritative servers provide robust and reliable responses to DNS queries.
The primary nameserver holds the most current authoritative data for its zone. Secondary nameservers are also authoritative, but their data must be brought up to date by zone data transfers from the primary nameserver. The same requirement for at least two authoritative servers, one primary nameserver along with one or more secondary nameservers, applies to all registrants seeking to provide name service for their delegated domains.
NeuStar's architecture and dynamic services exceed the capabilities of the traditional approach. Our proposed technical solution provides two co-active data centers in Virginia and Illinois plus one nameserver data center in California—each of which is independently capable of processing the full data center workload. Multiple nameserver sites dispersed across the United States protect against natural or man-made disasters. Moreover, the architecture scales to support future growth of the usTLD.
Essentially, each NeuStar nameserver for the usTLD is a primary, authoritative nameserver. With near-real-time updates of zone data being handled by NeuStar's redundant, high-availability database servers, each usTLD nameserver is targeted to its primary function—providing authoritative responses to DNS queries of the usTLD.
Registry data are replicated on redundant, high-availability database servers at the data centers. Zone data are dynamically updated from these databases and propagated to all the nameservers. Zone file data on the nameservers are updated in near real time. This timely distribution of updates is a significant improvement over the traditional implementation of zone data deployment.
The benefit to the United States and the Internet community of NeuStar's enhanced approach is a solid architecture with dynamic services designed to maintain maximum stability of the usTLD and the Internet and promote user confidence.
The following sections describe the operation and maintenance of authoritative nameservers for the us TLD. NeuStar's Technical Plan is described in detail in Section O of this document.
B.2.1.1 NeuStar's Multiple Primary Nameservers
A nameserver handles resolution of usTLD domain names to their associated nameserver names and to the IP addresses of those nameservers. NeuStar's nameservers will be dynamically updated from NeuStar's usTLD Zone Update Database over secure VPN links.
Each of NeuStar's nameservers for the usTLD is a primary, authoritative nameserver because each one acquires the same authoritative zone data, in near-real-time, directly from the authoritative database of usTLD registry data. This implementation provides high availability and scalability, along with significant operational benefits compared with the more traditional approach based on primary and secondary nameservers.
B.2.1.2 General Description of Proposed Facilities and Systems
NeuStar submits that its redundant, high-availability architectures, including redundant facility implementation, high-availability cluster server architectures, redundant high-availability database technology, and redundant alternate routed network connectivity, provide significant support for mission-critical service availability. The Internet community must be able to depend on the Internet as a stable, highly available infrastructure for worldwide collaboration and commerce.
B.2-3
B.2.1.2.1 Facilities Sites and Availability
NeuStar's architecture, consisting of redundant data centers and multiple nameserver sites, provides a seamless, responsive, and reliable registry service. Our data center sites are geographically dispersed and interconnected with Virtual Private Network (VPN) capability to provide access to countrywide coverage and protect against natural and man-made disasters and other contingencies. The facility locations are provided in the following table:
Facility Site Locations
Data Center Sites |
Site Location |
|
---|---|---|
NeuStar Data Center and Nameserver Site | Illinois | |
NeuStar Data Center and Nameserver Site |
Virginia |
|
Third Nameserver Site |
California |
NeuStar's proposed usTLD Registry Service Level Agreement (SLA) provides service levels commensurate with mission-critical services for availability, outages, response time, and disaster recovery. Highlights of the SLA include:
B.2.1.2.2 Data Center Functional Description
High-availability registry services can be provided only from facilities that have been designed and built specifically for such a critical operation. NeuStar's data centers incorporate redundant uninterruptible power supplies; high-capacity ventilation and climate control; fire suppression; physical security; information system security; firewalls with intrusion detection; redundant, high-availability cluster technology; and redundant network and telecommunications architectures. When selecting the sites, we also considered their inherent resistance to natural and man-made disasters. The functional block diagram of our enhanced SRS data center is depicted in Exhibit B.2-2. As can be seen from the referenced exhibit, the data center is highly redundant and designed to eliminate any single point of failure.
Each data center facility provides the functions listed in the system function table below:
Data Center System Functions
Web Server | Delegee Distribution Database | Systems/Network Management Console | ||
Protocol (XRP) Servers |
Delegee Distribution Clusters |
Applications Administration Workstations |
||
Application Servers |
Delegee Servers |
Building LAN |
||
Central usTLD Database Servers |
Zone Distribution Database |
Firewall |
||
Whois Distribution Database |
Billing and Collection |
Load Balancers |
||
Whois Database Clusters |
Authentication Services |
Telecommunications Access |
||
Whois Servers |
Backup Server |
Central Help Desk |
B.2-4
[Exhibit B.2-2: Redundant network connectivity, high availability clusters, redundant, and replication to a second data center provide 99.9% availability and scalability. Graphic Omitted: diagram of Enhanced SRS Data Center architecture.]
B.2.1.2.3 Nameserver Site Functional Description
NeuStar's usTLD nameservers will be colocated with the data center sites described above, with an additional nameserver in California, and their architectures are consistent with NeuStar's redundant, high-availability approach. Additional nameserver sites will be added as demand warrants.
The functional block diagram of NeuStar's nameserver sites is depicted in Exhibit B.2-3. As can be seen from the exhibit, the nameserver sites are configured to be remotely managed and operated "lights out." The hardware configuration is highly redundant and designed to eliminate any single point of failure.
[Exhibit B.2-3: Redundant network components and high availability nameserver cluster provide scalable high availability. Graphic Omitted: diagram of Nameserver Data Center architecture.]
The following function table lists the nameserver functions.
Nameserver System Functions
Zone Update Database | Firewall | |
Nameserver |
Load Balancers |
|
Building LAN |
Telecommunications Access |
B.2.1.2.4 Building Environment and Security Description
Each NeuStar data center facility is located in a modern, fire-resistant building that offers inherent structural protection from such natural and man-made disasters as hurricanes, earthquakes, and civil disorder. Sites are not located within a 100-year flood plain. Facilities are protected by a public fire department and have their internal fire-detection systems connected directly to the fire department. Data centers are protected from fire by the sprinkler systems of the buildings that house them. Furthermore, each equipment room is protected by a pre-action fire-suppression system that uses Inergen gas as an extinguishing agent.
Provisions have been made for the following environmental factors:
Environmental Factors
Ventilation and climate control | Primary electrical power | |
Lighting |
Backup power supply |
|
Control of static electricity |
Grounding |
In addition to providing physical security by protecting buildings with security guards, closed-circuit TV video surveillance cameras, and intrusion detection systems, NeuStar vigilantly controls physical access to our facilities. Employees must present badges to gain entrance and must wear their badges at all times while in the facility. Visitors must sign in to gain entrance, must display their badges, and must be escorted by a NeuStar employee.
On-site security personnel are on duty 24 hours a day, 7 days a week to monitor the images from closed-circuit television cameras placed strategically throughout the facilities. Security personnel are
B.2-5
stationed at building access points throughout normal working hours; at all other times, individuals must use the proper key cards to gain access to the buildings. Further, access to rooms housing sensitive data or equipment is additionally secured with palm-print readers. Senior facility managers establish the rights of employees to access individual rooms, and the palm readers compile and record access logs.
B.2.1.3 Description of System Functions
This section provides descriptions of systems functions at NeuStar data center and nameserver Sites that underlie the fundamental operations of the usTLD primary nameserver(s). Key features of these sites include the following:
B.2.1.3.1 Server Platforms
NeuStar is proposing cluster server platforms for installation at each site. The servers are selected for applications depending on the requirements, storage capacity, throughput, interoperability, availability, and level of security. These server platform characteristics are summarized as follows:
Rack-mounted Intel 700-Mhz, 32-bit, 2- to 6-way SMP CPUs with 8 GB of ECC memory; CD-ROM; four hot-swap disk drives (9-36 MB each); redundant hot swappable power supplies; dual attach 100 BaseT Ethernet Adapter; clustering and event management software for remote management; Red Hat Linux 6.1; and controlled access protection security.
RISC 550-MHz CPU; 64-bit 2- to 32-way cross-bar SMP with 8x8 non-blocking multi-ported crossbar; 32 GB ECC RAM; 240 MB/sec channel bandwidth; 288 GB Internal mass storage; 50 TB external RAID storage; redundant hot swappable power supplies; dual attach 1,000 BaseTX/FX Ethernet adapter; clustering and event management software for remote management; and a Unix 64-bit operating system with controlled access protection security.
B.2-6
B.2.1.3.2 Data Center Systems
The data centers provide co-active fully redundant system configurations with two-way replication over a high-speed VPN network, a colocated complete nameserver, and dual-homed connectivity to Internet Service Providers (ISPs).
Complete nameserver implementations for DNS queries are colocated in each data center site and at a stand-alone site in California. Their connectivity includes redundant ISP and VPN local access links to provide alternate routed connectivity to Internet users and internal networks. Redundant Internet firewalls provide policy-based Internet Protocol (IP) filtering to protect our internal building LAN from intruders and hackers.
The redundant, high-availability database servers consist of two identical redundant, high-availability RISC systems that are designed for high-volume, online transaction processing (OLTP) database applications. The database management software is based on a parallel database architecture with a redundant, high-availability server option capable of maintaining 24 × 7 availability. The redundant, high-availability server supports high-availability operations by implementing synchronous replication. The database enables transparent database failover without any changes to application code or the operating system. Clients connecting to a replicated database are automatically and transparently connected to the replicated pair of databases. The database replication feature enables maintaining geographically separated data services for multiple sites over a WAN to provide disaster recovery.
B.2.1.3.3 Nameserver Description
Two nameserver sites are colocated at our data centers, with a third stand-alone site located in California. The nameservers are geographically dispersed with dual-homed Internet and VPN local access telecommunications links to provide resilience and disaster recovery. Nameserver sites are configured to operate "lights out." The hardware configuration is highly redundant, is designed to eliminate any single point of failure, and has exceptionally high throughput. Nameserver subsystem functions that are critical components for operating a primary, authoritative nameserver include the following:
In effect, nameservers are freed of the loading for handling zone transfers, just as the zone update functions are freed of the loading for handling DNS queries and responses. The capability to insulate systems by separating processing loads is a key feature of NeuStar's systems architecture.
The nameserver cluster is based on a high-availability, rack-mounted, multiple computer cluster. A TCP/IP server load balancer switch with a dynamic feedback protocol is used to distribute the load from Internet users to ensure that traffic is not routed to overutilized servers.
B.2-7
DNS-query-response
operation are located on other platforms that are external to the nameserver platforms.
Whois servers, for example, facilitate rapid response to Whois queries without putting any load on the nameservers and without any impact on name service functionality. As mentioned above, the traditional functions of DNS query/response handling and zone transfer processing are also performed on separate platforms.
B.2.1.3.4 Data Center Networking
Networking at the data centers provides both Internet connectivity and VPN capabilities. Nameserver and data center connectivity support fundamental operational functions for name service and zone data.
Internet connectivity is provided by multiple T-class local access telecommunications links at each of our data centers, enabling each to provide usTLD services independently of the other. The bandwidth and capacity available are provisioned to handle current loads and expected growth for at least two years.
Connectivity to each data center is via redundant routers, with load balancing that distributes the query load among the nameservers in that site's cluster, and with alternate routing to provide resilience against cable faults and loss of local access telecommunications links. Telecommunications access links for VPN capabilities are dual homed and also use redundant routers and alternate routing.
The Nameserver site is connected to each data center via VPN, and the two data centers are connected by a pair of ATM links. The VPN capability provides secure networking for internal exchange of registry data. Important operational functions supported by these networking capabilities include the following:
B.2.1.3.5 Nameserver Software Platform
For the DNS software platform, NeuStar will deploy an enhanced version of BIND. The DNS software will comply with the latest IETF standards [RFC 1035, RFC 2181].
B.2.1.3.6 Related Operational Requirements
For NeuStar's nameservers for the usTLD, there are operational requirements related to their roles as essential parts of the technical infrastructure of the Internet. In RFC2870, "Root Name Server Operational Requirements" (R. Bush et al, June 2000), the guidelines provided for the operation of the root nameservers are also provided as guidelines for the operation of ccTLD nameservers. The usTLD nameservers will comply with all relevant portions of the latest applicable standards for the proper, safe, and secure operation of such nameservers.
B.2.2 Secondary usTLD Servers
NeuStar proposes an architecture in which registry data are maintained on synchronized, redundant, high-availability database servers and in which zone updates are made to the usTLD nameservers in near real time. In effect, all such nameservers would be primary nameservers, and a DNS query would receive the same authoritative response, irrespective of which particular nameserver had received the query. This is desirable DNS behavior.
B.2-8
As described in Section B.2.1 above, secondary nameservers are components of the traditional implementation of name service.
A secondary nameserver would obtain authoritative zone data from the primary nameserver for a zone. The primary nameserver would have the responsibility for maintaining the authoritative zone data, generating the zone data file, and supporting zone data transfers. The "current" zone data would be propagated from the primary to secondary nameserver(s). Until all secondary nameservers were updated, the response to a DNS query might depend on which particular nameserver generated the response. Getting possibly different responses to the same query is not a desirable result.
In fact, if a secondary nameserver received its zone data updates from another secondary nameserver, rather than from the primary nameserver for the zone, the overall propagation delays for updates would be doubled. This is even less desirable.
Section B.2.1 above describes the proposed operation and maintenance of primary authoritative nameservers for the usTLD. Since all of the proposed usTLD nameservers would be primary, that Section therefore describes the operation and/or administration of the constellation of authoritative servers for the usTLD.
B.2.3 usTLD Zone Files
NeuStar proposes generating zone files in near real time, a major improvement that will eliminate some serious deficiencies in the current TLD system. This capability ensures that the usTLD nameservers will respond to DNS queries with the most timely, accurate, authoritative, and consistent responses possible.
A zone file is a flat database file consisting of the technical information that the DNS requires to function correctly: the domain name, nameserver host name, and IP address are the primary data elements.
Zone file generation is the term traditionally used to describe the process of generating a zone file from the registry database, deploying it to the primary root server, and then propagating it out to the secondary servers. However, this process traditionally is batch-oriented: there are delays incurred before updates to authoritative data are actually available for use in all the authoritative nameservers.
NeuStar proposes a significant improvement over traditional zone file generation and propagation (i.e., updating the zone file data in near real time within defined service levels). Just as the current TLD system does, our proposed registry TLD would store the usual DNS resource records in the zone file database.
Unlike the current system, however, NeuStar's model does not periodically generate a zone file and then publish that new file to a set of nameservers. This proposal describes our process for creating updates for the nameserver files, including information about distributing and publishing the updates. NeuStar's Technical Plan is described in detail in Section O of this document.
B.2.3.1 Current Zone File Generation—Problems and Solution
The current zone file creation process has caused many problems for both registrars and registrants. The process is based on the traditional approach of using a single primary nameserver, which maintains the authoritative data locally, and one or more secondary nameservers, which receive transfers of the primary's data. These nameservers ultimately contain authoritative data for their zones, meaning that they can respond to queries about their zones based on their locally held data, without the need to further query other nameservers before responding. However, the traditional process incurs delays and may, at times, return inconsistent responses to queries.
B.2-9
Registrants, in particular, have been troubled by the long delay before their registered domain names go live (or are redelegated). The following are common issues with the current process:
To solve the problems inherent in the traditionally based implementation of zone file generation, NeuStar proposes to introduce a significant improvement to zone file generation and propagation processes. We will update the zone files in near real time within defined service levels. Near-real-time updates provide the following significant advantages:
The proposed approach enhances the value of the usTLD by providing the most timely, accurate, authoritative, and consistent responses possible to DNS queries of the usTLD.
B.2.3.2 Secure Access to Update Zone File Data
Under NeuStar's proposed solution, the Centralized usTLD database in the data centers stores all data used to generate and distribute the zone file updates. For security reasons, neither delegees nor internal data center staff can access this database directly; the application server tier controls all database access. Registrars/delegees access the database (through the application servers) using the XRP protocol via the protocol servers. The following procedures govern creating and modifying database information:
B.2-10
Other proposal sections provide additional security related information, including information about deployment security, system and network security, and access-control authentication and authorization.
B.2.3.3 Frequency of Zone File Generation
NeuStar will generate zone file updates (diffs) at regular intervals within defined service levels. Our solution enables us to meet any reasonable service level merely by adding incremental hardware items and reconfiguring system software settings.
Any real-time zone file update procedure must not degrade the performance of the core registration system. NeuStar's solution will enable us to agree to service levels that guarantee the zone file distribution database is updated within defined intervals—initially 15 minutes—without adversely affecting core registration operations.
In addition, NeuStar will provide a Zone File Access Program, which will enable registrars and delegees to access the zone file in bulk. Our proposed query program will:
Finally, NeuStar will provide for the essential functions for logging and data backup. All zone files and updates are generated using information from the registry database. All updates are recorded as database transaction logs. Information about the primary database backup and escrow systems, data center replication, and data recovery procedures is contained in other sections of this proposal.
B.2.3.4 Zone File Generation Architecture
Zone file information is stored in the registry database (along with all other registry data) and replicated to a zone distribution server. The database stored on the zone distribution server is in turn replicated out to a database at the nameserver data centers.
B.2.3.4.1 Zone File Replication
Each time the zone distribution database is modified and before the zone file update is replicated out to the nameserver data centers, the system performs a series of quality assurance checks. If any quality assurance checks raise an alert, operations staff must approve the deployment before the update is sent to the nameservers. The quality assurance checks include:
B.2.3.4.2 Standards Compliance
Each nameserver will run software that correctly implements the IETF standards for the DNS (RFC1035, RFC2181).
NeuStar will implement all applicable best-practice recommendations contained in RFC2870 (Root Nameserver Operational Requirements).
B.2-11
B.2.3.5 Zone File Distribution and Publication
NeuStar is proposing a significant improvement over traditional zone file generation and distribution by providing near-real-time updates of the zone file data.
The process of updating zone file information at the various nameserver data centers uses information from the zone distribution servers at the two co-active data centers, which are updated as described in Sections O.4 and O.5.
The databases on the zone distribution servers will be constantly replicated over a Virtual Private Network (VPN) to the zone update database at each nameserver data center. Each nameserver data center will, in turn, use its zone update database to update its zone file databases.
To ensure availability and provide scalability and redundancy, each nameserver data center will have a cluster of two or more nameservers behind a load balancer. This configuration enables NeuStar to rapidly accommodate increases in query load by simply adding servers to the cluster at the affected nameserver data centers.
The current zone file creation process has caused many problems—long delays before registered domain names go live or are redelegated—which can also confuse registrants, disable access to Web sites, and provide inconsistent responses to queries. Currently, zone file update (and propagation) is not real-time (the delay may exceed 12 hours), and zone file information may not match Whois information (updates often take place at different times).
These problems have consequences. Registrants are clearly affected when their domain names are not live. Registrars face additional costs for operations and customer support. Even the stability of the Internet is adversely affected when delayed zone file updates result in information mismatches and cause unnecessary additional loading.
NeuStar's improvement to zone file generation and propagation—updating the zone files in real time within defined service levels—is designed to eliminate synchronization problems that occur when information is modified, facilitate the deployment of innovative new technologies such as dynamic update, and enable definition and monitoring of service levels for zone file updates.
B.2.3.6 Locations and Architecture
The usTLD nameservers that NeuStar will deploy are located in Virginia, Illinois, and California. At the nameserver data centers, a zone update database constantly receives replication update packages from the zone distribution database server at the registry data centers. This zone update database is not "hit' when the nameservers process requests; the nameservers use it only to update their zone file databases. NeuStar will deploy, for DNS software, a modified version of BIND. BIND has been modified to delete functions that are unnecessary for TLD root server operation and enhance functions that are critical to root server operations. The DNS software will comply with the latest IETF standards [RFC1035, RFC2181].
Near-real-time update of the zone file data (a significant improvement over traditional zone file generation and propagation) takes the zone file information stored in the registry master database and replicates it to a zone distribution server database.
The following two Exhibits B.2-4 and B.2-5, illustrate the zone file distribution and nameserver update processes.
The database on the zone distribution server at the registry data center is constantly replicated over our VPN to the zone update database at each nameserver data center. The update packages are compressed, encrypted, and sent with an appended checksum.
B.2-12
Every update package includes a checksum key, which is a generated checksum of the entire database up to and including modifications in that package. Each time a package updates a nameserver, the checksum is compared to the final state of the zone file data to ensure that the nameserver zone file corresponds to the zone file in the data center's database. If the checksums indicate an error, the nameserver asks the data center to replicate a full zone file to the nameserver. The update package replication process means that the full zone file should never need to be redeployed; however, NeuStar will provide this capability to recover from an unforeseen event. Should this capability be needed, propagating zone file updates may result in a 60-minute delay. We will include this as an exception in the Service Level Agreements (SLAs).
In the nameserver update process, each nameserver updates its zone file databases from its zone update database within defined service levels.
B.2.3.7 Frequency of Zone File Publication/Update
Any technical solution that includes real-time DNS updates must recognize that the most important function of the nameservers is responding to DNS queries. This requirement outweighs real-time updating of the zone file. NeuStar's solution is based on this reality. Although our real-time update process includes establishing and monitoring key parameters that measure compliance with agreed service levels, this process is subordinate to resolving DNS requests. Within this limitation, we are confident in recommending that no more than 15 minutes elapse before processing an update package. We will be willing to negotiate these or other SLAs to meet performance requirements in a way that safeguards the integrity of the Internet under heavy DNS load.
B.2.3.7.1 Monitoring and Logging
Our central network management system will log all modifications to the registry database, all zone file update actions, and all attempts at intrusion or other security-related events.
B.2.3.7.2 Standards Compliance
Each nameserver will run software that correctly implements the IETF standards for the DNS (RFC1035, RFC2181).
[Exhibit B.2-4: NeuStar's process for near real-time updating of the nameserver zone file databases ensures that consistent and timely data are always available. Graphic Omitted: flow diagram depicting zone file distribution flow.]
[Exhibit B.2-5: Maintaining a zone file database at each nameserver data center allows zone file servers to respond to DNS inquiries by accessing their own local zone file database. This maximizes efficiency and increases redundancy. Graphic Omitted: diagram depicting nameserver update process.]
B.2.4 Whois Database
NeuStar's centralized Whois database will ensure quality, consistent implementation and data, with all information available through publicly accessible means.
As part of our efforts to centralize all of the usTLD registration information and to make it available for Web-based queries, NeuStar will create and maintain an accurate and up-to-date centralized Whois database. In fact, NeuStar will actually administer two logical databases—one for registrants (in both the locality-based space and the expanded space) and registrars and one for delegated managers, that is, delegees and subdelegees. It is important to manage these entities separately because delegated managers are held to a higher level of accountability for the management of their namespace. NeuStar will maintain a Web site that will provide access to the Whois databases, and we will also provide a standard port 43 interface to the Whois data. In accordance with the RFQ, access to the Whois data via the Web site and to port 43 will be free of charge and available to the public, and the databases will allow for multiple field and string searches. Responses to Whois queries will indicate whether the record is in the registrant Whois or a delegated manager's Whois. NeuStar will reach out to the existing delegees and subdelegees to populate their information and their registrant's information in the databases.
Populating the Whois information in the expanded space will be done through the registrar at the time of registration. Registrations will not be considered complete without all of the appropriate information being provided. We will populate the data pertaining to the existing assignments by reaching out to the delegated managers, as well as by retrieving contact information contained in existing zone files of the usTLD administrator and of the delegated managers.
B.2-13
NeuStar will collect and update, at a minimum, the information listed below for each type of Whois record.
Whois Information Under the usTLD
Registrants in Locality Space |
Delegated Managers in Locality Space |
|||||
---|---|---|---|---|---|---|
1. | Name of the domain registered | 1. | Name of the delegated manager | |||
2. | Internet Protocol (IP) address of the primary nameserver and secondary nameserver(s) for the registered domain name | 2. | Delegated Manager ID | |||
3. | Corresponding names of those nameservers | 3. | IP address of the primary nameserver and secondary nameserver(s) for the delegation | |||
4. | Identity of the delegated manager under which the name is registered | 4. | Corresponding names of those nameservers | |||
5. | Creation date of the registration | 5. | Date of delegation | |||
6. | Name and postal address of the domain name holder | 6. | Name and postal address of the delegated manager | |||
7. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the domain name holder | 7. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the delegated manager | |||
8. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the domain name holder | 8. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the delegated manager | |||
9. | Web site or other contact information through which registrations can be accepted under the delegation |
B.2-14
Registrants in Expanded Space |
Registrars in Expanded Space |
|||||
---|---|---|---|---|---|---|
10. | Name of the domain registered | 17. | Name of the registrar | |||
11. | IP address of the primary nameserver and secondary nameserver(s) for the registered domain name | 18. | Registrar ID | |||
12. | Corresponding names of those nameservers | 19. | Registrar status (e.g., active, pending) | |||
13. | Creation date of the registration | 20. | Name and postal address of the registrar | |||
14. | Name and postal address of the domain name holder | 21. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the registrar | |||
15. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the domain name holder | 22. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the registrar | |||
16. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the domain name holder | 23. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the billing contact for the registrar |
Further, to ensure the integrity and highest levels of service for Whois administration, redundant databases will be located at the geographically diverse, redundant Enhanced SRS Data Centers located in Illinois and Virginia. In accordance with the U.S. Nexus requirement, no registry databases will be located outside of the United States. Both databases will be updated in near real time (intervals no greater than 15 minutes) and will be synchronized to ensure consistency of the response.
Detailed descriptions of how the databases will be populated, how they are kept up to date and accurate, and the structure of the Whois responses are provided in Section F, Central usTLD Database and Enhanced Shared Registration System. A detailed description of our Whois policy is provided in Section B.3.5.
A detailed description of the database infrastructure and design is provided in Sections O.3 and O.8 of this proposal.
B.2.5 usTLD Delegated Manager Database Administration
NeuStar's centralized database of delegated managers will enable us to contact those managers quickly and resolve issues effectively.
In order to manage a critical public resource like the usTLD, its administrator needs to maintain an accurate database for all entities that have a role in administering the space. The usTLD's delegated managers—the locality delegees and subdelegees—play an important role in the communities they serve. The usTLD Administrator may need to contact a delegated manager because of an outage or a question from one of their registrants. Out-of-date information prevents the administrator from resolving issues in a timely manner. To avoid this problem and to ensure that all delegated managers can be contacted, an integral element of the Centralized usTLD Database that NeuStar will deploy as the usTLD Administrator will be an accurate and up-to-date database of delegated managers.
B.2-15
The most critical function with regard to creating the database is obtaining information from the existing delegated managers. NeuStar has, in the past, provided just this service to the telecommunications industry. As the North American Numbering Plan Administrator, NeuStar was required to create a central database of telephone number assignments. This required us to work with multiple telecommunications companies across the country, most of which had many telephone number administrators. Not only were databases across companies inconsistent, but databases within companies were often inconsistent as well. NeuStar was nonetheless able to collect and standardize all of the data, and completed the transition ahead of schedule.
As the usTLD Administrator, NeuStar will reach out to all of the delegated managers. We will provide them with a list of the data elements required in our database, and we will provide them with multiple methods of provisioning that data with us. Our usTLD Transition Team will be tasked with the responsibility of contacting the delegated managers to collect this information. On an ongoing basis, we will provide delegated managers with an easy-to-use web interface to provision new registrations into the Centralized usTLD Database. Alternatively, should they have high volumes of registrations and would prefer a mechanized interface, delegated managers will have the option of using NeuStar's extensible Registry Protocol (XRP) to interface with the registry.
Information in the Delegated Manager Database will include at least the following:
Detailed descriptions of how the databases will be populated and how they will be kept up to date and accurate are provided in Section F, Centralized usTLD Database and Enhanced Shared Registration System.
Redundant Delegated Manager databases will be located at the geographically diverse, redundant Enhanced SRS Data Centers located in Illinois and Virginia. In accordance with the U.S. Nexus requirement, no usTLD databases will be located outside of the United States. Each database site will be updated in near real time (intervals of no more than 15 minutes) and will be synchronized. This will ensure the requisite level of availability and stability for the usTLD.
A detailed description of the operations of the databases is provided in Sections O.3 and O.9 of this proposal.
B.2.6 Data Escrow
In addition to arranging for frequent escrowing of the data contained in the usTLD registry, the very design of NeuStar's registry protects it from catastrophic failure.
B.2-16
The overall security and integrity of the usTLD requires that there be multiple mechanisms in place to ensure the continued operation of the usTLD in the event of a disaster, technical or business failure, or any other unforeseen event affecting usTLD operations. Therefore, NeuStar will establish an agreement with an outside escrow agent to develop a process and schedule for frequent escrowing of the usTLD zone file, Whois database, delegated manager Whois database, and delegated manager database, as well as necessary domain name registration data, including chain of registration data.
Although a usTLD administrator could choose simply to rely upon an escrow service to ensure data integrity and recovery capabilities, NeuStar believes that additional steps must be taken to protect such an important public resource. NeuStar's heritage as an operator of mission critical, zero-downtime infrastructure makes it uniquely qualified to address such concerns. Therefore, the design of NeuStar's registry systems virtually ensures that no single event likely will result in a catastrophic loss of data. Specifically, the NeuStar architecture will utilize redundant, coactive data centers in Illinois and Virginia, combined with a robust, and redundant nameserver architecture.
These measures by NeuStar will ensure that all data necessary for operation of the usTLD registry will be available in the unlikely event of a catastrophic failure of the registry or following the selection of an alternate usTLD Administrator by the COTR. Such information will ensure that NeuStar, or any subsequent usTLD administrator, could recover operations quickly and easily, or in the case of a transition of administrators, such transmission would occur with minimal, if any, interruptions in service.
B.2.7 Industry Representation/Compliance
NeuStar's continued participation with Internet standards and policy organizations will contribute to its operation of the usTLD as the model for a country code top-level domain.
As is discussed throughout this proposal, one of NeuStar's primary goals is to make the usTLD an important part of the global Internet infrastructure. In order to successfully assume such a role, however, the usTLD Administrator must be prepared to coordinate with the various members of the Internet community. In particular, the Administrator must be prepared to comply with applicable policies and standards of the IETF and ICANN. Such policies form the basis for effective functioning of the global Internet and are followed by all reasonable Internet operators. NeuStar will comply with all such applicable policies and standards in its operation of the usTLD. NeuStar's efforts will not stop, however, at simple compliance.
NeuStar will continue to work with the NTIA, ICANN, IETF, and the Internet community to further develop and enhance not only the usTLD, but also the Internet and the DNS. Such efforts include participation in development of privacy, security, encryption, multilingual domains, and other important policies and technologies for DNS operations. NeuStar will maintain staff dedicated to such efforts. Indeed, NeuStar employees currently chair important IETF working groups such as the Whois Working Group. NeuStar intends, therefore, to operate as the model ccTLD in the international ccTLD community and, through its technical and policy efforts, NeuStar will work to establish the usTLD as the leading example of, and staging platform for, the most advanced DNS registry services on the Internet.
An important example of NeuStar's efforts in this area will be the revision of RFC 1480 upon completion of the six-month compliance report. NeuStar believes that the learning from this analysis of the locality-based usTLD will provide an important opportunity for significant improvement of the basic structure and underlying policy of the usTLD.
B.2-17
B.2.8 usTLD Public Awareness Initiatives
NeuStar's primary research indicates that a strong demand for dot-us domain names exists within the U.S. public. NeuStar evaluated this market analysis and performed further secondary research to produce a marketing plan that will maximize brand awareness and drive market adoption.
In its commitment to the promotion and marketing of the usTLD, NeuStar has crafted the following Marketing Plan to create public awareness, expand brand identity, and drive registrations. A key component of the Marketing Plan is the maintenance of a Web site with current policy and registration information. Additional information regarding the usTLD Web site follows in Section B.2.11. The following section outlines the target markets, potential positioning, and phased awareness initiatives for the usTLD. This approach is one potential strategy to market the usTLD.
B.2.8.1 Executive Summary
NeuStar will actively market the usTLD making it the most widely available, diverse, competitive option for both consumers and small businesses in the United States. Sixty percent of the world's domain names originate in the United States. The usTLD, however, has not attracted registrations and remains underutilized compared to other country code domains. This underutilization reflects poorly on the United States as a technological leader. The problem is due, in part, to lack of promotion and awareness. To address this lack of awareness and ensure the success of public awareness initiatives, NeuStar conducted primary research uncovering the following empirical evidence to understand customers' needs, motivations, and attitudes:
These findings present opportunities for the usTLD. These opportunities, when combined with appropriate public awareness initiatives supported by a dynamic channel strategy, create an environment for success. NeuStar will execute a phased marketing program to create a "snowball effect."
B.2-18
NeuStar is confident that this phased approach will succeed for the following reasons:
NeuStar is committed to the success of the usTLD and submits the following documentation providing additional background, market environment analysis, complete research findings, and a more comprehensive outline of the marketing programs as supporting credentials.
B.2.8.2 Background
NeuStar is uniquely qualified to seize this challenge. As the leading provider of mission critical clearinghouse services, NeuStar has been entrusted to manage competitively sensitive public resources. It brings distinctive strengths to these efforts:
Market Environment
The usTLD will be introduced to a market already served by the very popular dot-com, as well as others such as dot-net and dot-org. The usTLD will need to be positioned against these competitors, and heightened awareness levels will be required to attract consumers, businesses, and public sector entities. Creating marketing programs to address these entrenched users will be of primary importance, though recognizing the need to retain current usTLD holders is not forgotten. In a recent NeuStar survey, both consumers and businesses in the United States had a 99% awareness level of the domain
B.2-19
extensions dot-com (22.7M registered) and dot-net (4.4M registered).(1) Unfortunately, current awareness levels of the usTLD are not nearly as high. Both consumers and businesses demonstrated a 3% unaided awareness level of the usTLD. (Unaided awareness tests ask respondents to answer a question without prompting or using precoded categories. For example, an unaided question might be "Which brands of soda do you drink?") Aided awareness figures are much higher (70% to 74%), indicating general acceptance of the usTLD. (Aided awareness tests ask respondents to answer a question while providing answer categories. For example, an aided question might be "Below is a list of sodas. Please mark on the answer sheet which brands you drink.") Americans have used the abbreviation "us" for 200 years, are comfortable with its use, and recognize it in this context.
B.2.8.3 Strategic Goal
The DOC "Statement of Purpose" seeks to achieve the following objectives:
NeuStar is guided by these objectives and is committed to increasing the utility and overall value of the usTLD space to drive registrations. To achieve these objectives, it is important to understand the community of customers and what motivates them to purchase.
B.2.8.4 Customer Base
Delegees
There are currently 8,000 subdomain delegations to more than 800 individual and entities who maintain a registry and provide registration services for commercial, educational, and government entities. They span the United States and are primarily composed of businesses, individuals, federal government agencies, schools, libraries, museums, and state and local governments. All K12 schools, community colleges/technical schools, and state and local government agencies are encouraged to register under the US Domain.
Public Sector
The public sector represents a broad market that includes the sizeable government bodies as well as the many non-profit organizations, all of which function in a way that suggests prime marketing opportunities for acquisition and promotion of the usTLD. Government bodies alone make up a sizeable group. There are currently more than 500 federal government acronyms that identify agencies with Web sites.(2) While the opportunities represented by the federal government, the 50 states, and localities are extensive, the opportunity represented by organizations, charities, foundations, churches, and associations is vast. These organizations, by their nature, are invested in the betterment of the United States and its people. Their numbers are sizeable. Time Almanac lists 30 U.S. religious bodies with more than 500,000 members. GuideStar's current list of U.S. nonprofit organizations numbers more than 700,000. Time Almanac 2001, Encyclopedia of Associations, lists approximately 23,000 organizations. These organizations will benefit greatly by expanding their reach via the Internet as they attempt, in a competitive environment, to reach their members and donors.
B.2-20
Business
There are approximately 12 million businesses(3) in the United States with a labor force of 139.4 million employees.(4) They support an economy with a gross domestic product (GDP) of $9.3 trillion in purchasing power parity.(5) As the U.S. economy continues to expand and globalization occurs, commercial enterprises are recognizing the need to utilize the Internet in the growth of their business. In a report by Jupiter Research, the evolution of business and the Internet was explored:
Today, virtually all companies that participate in business-to-business (B-to-B) commerce are being forced to develop new strategies to keep up with the reengineering of the economy as a whole.
Jupiter estimates that between 2000 and 2005, online B-to-B commerce will swell from 3% to 42% of total B-to-B trade in the United States. The five largest B-to-B online vertical segments today include:
Much of today's research predicts that Internet growth will continue in the business sector as businesses look to the Internet as a tool to improve traditional and expensive business processes.
Small Business
There are approximately 9.8 million small businesses(6) in the United States, and they continue to be the fastest growing business segment. Defined as having between 1 and 99 employees, small businesses employ roughly 40% of the private workforce in America.(7) Small businesses have recently created the vast majority of new jobs in the country. For example, in a study conducted by Cognetics for the U.S. Small Business Administration, companies with 1-99 employees created 85% of the 11.2 million new jobs generated in the country from 1992 to 1996. The top spots in the country for small business growth include Phoenix, Salt Lake City, Atlanta, Raleigh-Durham, Indianapolis, Washington DC, Orlando, Nashville, and Charlotte.(7)
B.2-21
Small businesses affect every sector of the economy: 37% are in the service sector, 21% in retail, 11% in financial and investment-related, and 9% in manufacturing.(8) Computer use among small businesses is quite high—estimated at 75% to 97%.(9) A recent study conducted by Dun and Bradstreet indicated online use was also substantial:
Small Business Use of the Internet
Use |
1999 |
||
---|---|---|---|
71 | % | ||
Business research | 58 | % | |
Personal research | 50 | % | |
Purchase goods/services (business use) | 43 | % | |
Purchase goods/sServices (personal use) | 31 | % | |
Sell/market products | 26 | % |
Medium and Large Business
Large businesses are defined as having more than 1,000 employees. There are approximately 7,000 firms(10) that fall into this category, and they represent .05% of U.S. businesses. Medium-size businesses are characterized as having between 100 and 999 employees. There are approximately 2 million medium-size enterprises.(11)
Consumers
When compared to other countries, the United States has the highest penetration of online consumers.(12) More and more consumers are utilizing the Internet to gather information, research products, communicate via e-mail and meet their lifestyle needs. About 164 million (59%) of consumers are online today.(13) The online population is predominantly located in large cities and the suburbs when compared with U.S. population density:
Online Population
|
U.S. Population |
Online Population |
|||
---|---|---|---|---|---|
Large city | 20 | % | 22 | % | |
Suburbs | 23 | % | 31 | % | |
Small city/town | 36 | % | 32 | % | |
Rural | 21 | % | 14 | % |
Geographically, the online population is concentrated in the Pacific West, South Atlantic, and East North Central regions, but it continues to expand beyond the technology regions (U.S. Census). Low-cost computers and reduced Internet access costs have contributed to the rise in overall household
B.2-22
penetration. San Francisco (66%), Seattle (64%), San Diego (62%), and Portland (60%) led the way with the highest household penetration rates as of September 2000.(14)
The consumer online population is characterized by several distinct factors that play a significant role in a marketing effort. They are almost evenly split by gender (51% female and 49% male), and 30% are between the ages of 35 and 49. They are overwhelmingly white and well educated when compared with the national average. The percentage of adult Internet users who have graduated from college is 41%, nearly double the national average of 22%. Given that the Internet is primarily an information source, the more educated people are, the more likely it is that they will be motivated to use the Internet. The typical online household has an annual income nearly 36% higher than that of the average American household; 30% of those online have incomes of $50,000-$75,000 although online use by those in lower and middle income groups is growing.(15) Although Internet users have higher income levels than the average American, a comparison with 1999 data reveals a widening trend that includes lower levels of affluence. This expansion of income levels is attributed to lower costs for PCs and Internet access, as well as greater acceptance of the Internet as a safe and convenient way to shop. Correlations can be drawn when examining occupation and online usage: 32.5% of the U.S. online population is in executive, managerial, or professional occupations. Most of these workers use a computer and/or access the Internet as part of their work. On average, more time is spent online at work than at home. June 2001 data show that the number of online sessions at work is twice the number of sessions at home.(16)
In a study conducted by The Media Audit (a syndicated survey of both online and traditional media in more than 80 markets over a three-year period—1998, 1999, and 2000), online usage is diversifying. African American online usage has increased 41% during the past three years to 44% online usage today. The U.S. Census estimates that Hispanics represent the fastest growing segment of the U.S. population with more than 30 million Spanish-speaking residents. Moreover, in a report published by The Economist, the buying power of Hispanics in the United States has increased by 65% since 1990 to $348 billion. Tapping into this buying power can be done online: 42% of Hispanics now have access to the Web, according to The Media Audit—an increase of 45%. Sixty-three percent of Asians were online in 1998. In 2000, that figure had risen 7% to more than 70%. Seventy percent exceeds the comparable figure for white households, whose online usage is about 58%.
E-mail ranks as the most popular online activity for consumers. It is expected that there will be 140 million active e-mail users in the United States by 2003. While many consumers have between two and five accounts, 51% check only one e-mail account daily. It is estimated that online adults will spend between 9 and 10 months of a typical lifetime writing and responding to e-mails. Research shows that e-mail has created a greater connection among family members with 26 million Americans regularly sending e-mail to a family member with whom they had not previously had much contact.(17) Instant Messaging is another communications activity that is frequently used by online Americans. Instant Messaging continues to grow because it is free and easy to use. In addition, approximately 30 million Americans are members of families in which someone has created a family Web site.(18) It is evident that the internet has introduced a fundamental shift in the way people communicate. As this communication medium becomes widely accepted, more citizens will want to own domain names to increase their online interactions. According to NeuStar research, less than 10% of Americans currently own a domain name.
B.2-23
B.2.8.5 Marketing Objectives
The single marketing objective of this plan is to ensure that every consumer, business, and public sector entity of the United States is aware of the usTLD, understands its value, and knows how they can acquire a dot-us domain name.
B.2.8.6 Market Definition
Successful launch of the usTLD will rely on marketing initiatives aimed at the appropriate audience with the appropriate message. Clearly understanding the size of the target, their demographic makeup, and their motivations and attitudes toward the Internet and domain names in particular will provide the foundation to drive usTLD penetration quickly. A research study was conducted to obtain empirical data for both U.S. businesses and consumers.
Research
NeuStar commissioned primary research to ensure a solid foundation from which to create a marketing strategy for the usTLD. The resulting information serves as the basis for all aspects of the marketing plan and will enable NeuStar to establish a presence and firmly position the usTLD quickly.
Objectives
Research was conducted in the form of a survey to a general audience of consumers and businesses regarding their attitudes and perceptions of the usTLD. The survey objectives were to:
Methodology
B.2-24
Research Participants
Target Audience
Research Highlights
The major findings of the research can be found below. A complete report detailing the research findings is located at the end of this document.
General Highlights
Consumer Research Findings
B.2-25
Business Research Findings
Research Conclusions
The results from this survey show that Americans strongly feel that creating additional domain name extensions is a good idea. Clearly the market recognizes the need for additional open space on the Internet. Whether we will see a rush to acquire additional domain names remains an open question. What is known, however, is that the usTLD is well-positioned vis-à-vis other major TLDs. The primary reason is that both business and consumer purchasers appear to prefer multipurpose
B.2-26
TLDs over single-use TLDs. The likely cause is the widespread use of dot-com in the U.S.—the ultimate generic multipurpose TLD. Over the years, research has shown that people tend to gravitate toward the familiar, hence the preference for other generic multipurpose TLDs. We believe that, with an intelligent brand awareness and advertising campaign, the usTLD can gain significant market share in the coming years.
Many natural uses for the usTLD already exist. In particular, Americans feel that dot-us is particularly well suited for e-government initiatives. For example, Americans overwhelmingly think the use of the usTLD would work for programs such as creating a Web site called voting.us which lists local polling places and information about political candidates or a Web site called parks.us which lists local, state, and national parks.
[Graphic Design]
While e-government initiatives could help drive the growth of the usTLD, it would be a mistake to limit its utilization to that market, since both consumers and businesses show interest in using the usTLD. In fact, overemphasis of e-government initiatives could persuade consumers and businesses that the usTLD is solely for government and public sector Web sites—a scenario that is clearly avoidable. There appears to be strong demand on the consumer side of the equation. Our survey found that 27% of American consumers plan to register a domain name in the next year. Additionally, survey respondents acknowledge that their first choice domain name with the dot-com suffix might be taken. As a result, they are looking at secondary options. When we asked likely domain name consumer purchasers "If you had to select a new domain name and dot-com was already taken but dot-us and dot-name were available, which would you choose?" a plurality (38%) selected the usTLD, 30% chose another name with the dot-com extension, and only 10% selected nameTLD. This speaks both to the power of the usTLD and the interest in multipurpose generic use TLDs.
[Graphic Design]
On the business side of the equation, we also see a preference for the usTLD. When we asked likely domain name business purchasers "If you had to select a new domain name and dot-com was already taken but dot-us and dot-biz were available, which would you choose?" a plurality (42%) selected the usTLD, 17% chose another name with the dot-com extension, and only 25% selected bizTLD.
To reiterate: We believe that latent demand exists for the usTLD and that a strong marketing campaign will create the requisite interest in and eventual use of the usTLD.
Key Survey Tables and Projections
Plan To Purchase Domain Within Next 12 Months / 3 Years
|
Percentage |
Pop. Projection |
||
---|---|---|---|---|
Business—12 months | 8 | % | 0.7 M | |
Business—3 years | 5 | % | 0.4 M | |
Consumer—12 months | 27 | % | 35.8 M | |
Consumer—3 years | 11 | % | 15.2 M | |
Total | — | 52.1 M |
B.2-27
Likely To Purchase usTLD One Day
|
Percentage |
Pop. Projection |
||
---|---|---|---|---|
Business | 4 | % | 1.6 M | |
Consumer | 23 | % | 31.5 M | |
Total | — | 33.1 M |
Likely To Consider Purchasing.usTLD After Being Informed of New System
|
Percentage |
Pop. Projection |
||
---|---|---|---|---|
Business | 39 | % | 3.0 M | |
Consumer | 40 | % | 24.0 M | |
Total | — | 27.0 M |
B.2.8.7 Market Opportunity
The research indicates that there are several opportunities to market and position the usTLD to address the needs of American consumers, businesses, and public sector entities with regard to domain names:
B.2.8.8 Value Proposition
Establishing a value proposition for a product provides the foundation around which a marketing campaign can be built. Value propositions define the most important benefits or facts the target group of customers should know and readily understand about the product being marketed. They clearly establish why the product is important, defining each product feature specifically and translating those features into customer benefits. Marketing programs are designed around communicating those benefits
B.2-28
to target groups. The research indicates that customers are interested in receiving the following benefits from the features of a domain name product:
Domain Name Features and Benefits Identified Through NeuStar's Research
Feature |
Benefit |
|
---|---|---|
U.S.-centric | Identifies owner as a U.S. citizen, organization, nonprofit organization, government, charity, or church | |
New |
Name they want is available |
|
Competitive price proposition |
Affordable, good value |
|
Generic TLDs with flatter hierarchical structure |
Wider use/wider popularity |
|
Direct registration |
Simplicity, ease of acquisition |
|
Available through a wide distribution network |
Simplicity, ease of acquisition |
Positioning
Product positioning is helpful in identifying the specific position or definition that is desired when promoting the product. It defines how a product should be known, described, or characterized in the
B.2-29
customer's mind. Based on the research outlined above, the following are examples of how the usTLD could be positioned:
usTLD Positioning
Market |
Responding to what emotion or attribute |
Product Feature Targeted |
Positioning Statement |
|||
---|---|---|---|---|---|---|
Consumers and businesses | Trust and security | U.S.-centric | usTLDs are trusted Web sites managed by individuals and businesses located in the United States | |||
Consumers and businesses |
Ease |
Generic TLDs with flatter hierarchical structure |
A new, easy-to-remember Web site that is owned and operated in America |
|||
Consumers and businesses |
Uniqueness and urgency |
New |
A newly introduced domain name extension that allows me to get the name I want |
|||
Consumer singles, students, young families, self-employed |
Cool factor, few people have this new cool thing |
Personalization |
usTLDs give you a piece of the Web that is as individual as you are by letting you name your own Web site. |
|||
5) Self-employed, SOHO |
Multipurpose |
Generic |
usTLDs allow my Web site to be used for multiple purposes |
Logos and Taglines
Logos and taglines are developed to provide customers an easily identifiable company symbol. These images or symbols help to brand a company or product by offering a brief, easily recognizable description. Both consumers and businesses agreed that dot-us was easy to remember. In addition, they felt the extension was a clear indication that the owner of the Web site was an American citizen. They also had favorable reactions to words like "trustworthy" and "descriptive" when asked to describe the usTLD. Given these findings, the logos, as shown in Exhibit B.2-6, are examples of the types of symbols that could be used to brand or characterize the usTLD with the American public.
[Exhibit B.2-6: There are numerous markets and positioning options for the usTLD as demonstrated in this illustrative sample of logos. Graphic Omitted: sample usTLD logos.]
B.2-30
Surprisingly, many consumers and businesses do not know how to purchase a domain name today. NeuStar's survey revealed that 3 in 5 consumers and 1 in 5 businesses do not know how or where to purchase domain names. This indicates a need for both education and a widely distributed network of sales channels to provide ease of acquisition for U.S. citizens. NeuStar's channel strategy is to create the widest distribution network possible to enable every citizen a speedy and simplified registration process. Educating citizens on where and how to acquire a usTLD will be covered within the Marketing Plan below. NeuStar would accomplish the channel objective in two phases:
Phase 1
|
|
|
||
---|---|---|---|---|
Objectives | • | Achieve 100% participation from ICANN-accredited registrars | ||
• |
Create a sense of urgency and excitement around the usTLD to encourage the registrars to assist in public awareness and promotional campaigns |
|||
Market |
Accredited registrars |
|||
Programs |
• |
Seminars |
||
• |
Letters of usTLD introduction to all appropriate registrars |
|||
• |
Creation of sales materials |
|||
• |
Sample graphics for use on resellers' Web sites |
|||
• |
Fact sheet outlining the usTLD opportunity and benefits of the structure and application platform |
|||
• |
Tool kit |
|||
• |
Online Web site |
|||
• |
Work with search engines to ensure dot-us is recognized |
|||
Timing |
1-4 months prior to launch |
B.2-31
Phase 2
|
|
|
||
---|---|---|---|---|
Objectives | • | Expand the network beyond current registrars to ensure that every American citizen, business, and public sector can easily acquire a usTLD | ||
• |
Simplify the accreditation process to encourage wide participation of commercial organizations, nonprofit organizations, foundations, government, charities, churches, and associations |
|||
Market |
• |
Entities that offer channels beyond the online environment |
||
• |
Benefits to these organizations as they expand service offerings and end-user benefits |
|||
Programs |
• |
Creation of accreditation process (Registrar in a box) |
||
• |
Letters of introduction to wide selection of entities |
|||
• |
Direct sales to targeted businesses and public service groups |
|||
• |
Creation of sales materials |
|||
• |
Educational seminars—benefits of the proposition and ease of implementation |
|||
• |
Fact Sheet outlining features and benefits, sales potential, or member reach for use in collateral |
|||
• |
Tool kit |
|||
• |
Sample graphics for use in information material/collateral |
|||
• |
Online Web site |
|||
Timing |
Launch + 1 year |
B.2.8.10 Marketing Plan
In order to promote the increased use of the space, expanding awareness levels is essential to a successful strategy. To be successful, branding requires a consistent message, delivered frequently to the target group. A phased approach is recommended, based on the levels of immediate interest and the purchase intent of target groups. The programs are designed to increase brand awareness and penetration across the United States to businesses, consumers, and the public sector.
Phase 1 objectives are to reach two specific target groups prior to launch.
These initiatives are critical and will be successful because they reach both current owners and those targeted consumers and business owners who have already expressed interest and purchase intent. Capturing this group first is essential, as they become the foundation for the public awareness and word of mouth advertising on the Web.
B.2-32
Phase 2 builds on the awareness objectives as marketing and promotional efforts are launched to reach a wider audience. The major objectives of this phase are to:
Phase 2 efforts are designed to address both the timing related to purchase intent as well as the educational challenges that were uncovered within the research. Ensuring that the population is knowledgeable of the product benefits and is aware of how and where to purchase is critical to driving registrations. This effort will be supported by the channel strategy. As more and more businesses, groups, and organizations recognize the value of providing and promoting usTLDs to their customers, associates, and members, registrations will increase. In addition, both businesses and consumers were overwhelmingly positive toward e-Government initiatives. These initiatives should be launched in Phase 2 as an increased benefit and in response to customer needs.
Phase 3 reaches across the country to all citizens to ensure they have the knowledge and the opportunity to acquire a usTLD. The major initiatives are planned to:
Phase 3 leverages the momentum established in the early stages. The usTLD message is spread to a greater audience with increased frequency. As the third phase progresses, Americans will know that a new generic TLD is available, the value of owning one, how applications can improve their utility, and how and where to acquire one. Phase 3 continues to build and rely upon partnership and affinity marketing strategies that take advantage of the greatly expanded distribution network. NeuStar is confident in this strategy because it:
B.2-33
What follows is an outline of the types of campaigns and the coverage that would be launched within each of the program phases. Each phase builds upon the one prior to capture the widest possible audience with as many impressions as possible.
Conclusion
This plan conclusively demonstrates NeuStar's ability to successfully achieve expansion of the space and drive registrations of the usTLD to every corner of the country. NeuStar has reviewed and addressed the key factors for success. It has conducted research to understand what American consumers and businesses think about domain names and the usTLD in particular. With this understanding of the market, NeuStar has developed a plan to reach the U.S. audience. NeuStar recommends getting started on this plan immediately to ensure that usTLDs will be available to more American consumers, businesses, and public sector entities without delay.
Complete Research Findings
Summary of Results and Conclusions—Consumers
Domain Name Registration Purchasing Habits | Domain name penetration (in percentage terms) is very low in the online consumer sector, with less than 1 in 10 people (6.6%) currently owning a domain name. | ||
However, latent interest in purchasing a domain name exists, with more than one-quarter of consumers indicating that they plan to purchase one in the next 12 months. An additional 15% report that they plan to purchase a domain name in the next three years. |
|||
Online consumers who access the Web from school are the population subgroup most likely to say they don't currently own a domain name but they plan to purchase one in the next year. |
|||
Not surprisingly, current domain name owners tend to be early adopters, while those planning future purchases self identify as less savvy in their use of the Internet. |
|||
Consumers say they primarily want a domain name to start/maintain home-based businesses and/or for a hobby. |
|||
A clear majority of consumer domain name owners say their personal Web site is very important to them. |
|||
Awareness and Purchasing Likelihood of usTLDs |
In an unaided test, very few consumers were able to recall that dot-us exists. In fact, general awareness of country code TLDs is low. |
||
In an aided test, approximately three-quarters report that they know that dot-us exists. This aided figure is very close to TLDs other than dot-com and dot-net (such as dot-biz and dot-pro). This suggests that even though the generic use of dot-us has been released after some others, it does not start at a brand equity or intent to purchase disadvantage vis-à-vis newer TLDs. |
|||
B.2-34
Our initial estimates are that approximately one-quarter of online consumers state an initial interest in purchasing a usTLD. This is an elastic figure, however, as many more are willing to consider a usTLD if a dot-com option is taken and/or dot-us can compete with dot-com on price. |
|||
Size and Demographics of Likely Purchasers |
Slightly less than one-quarter of online consumers state any interest in one day purchasing a domain name with a dot-us extension, and 5% say they are "very likely" to one day purchase a domain name with a dot-us extension. In round numbers, this 5% roughly equates to 6.2 million Americans. |
||
The target market is made up of a disproportionate number of people in upper socioeconomic groups. |
|||
Target purchasers have been online for over 5 years, read technology-oriented magazines, and self-identify as "Internet experts." |
|||
A disproportionate number of target users currently own a domain name. |
|||
The self-employed and those who are in technical fields also make strong targets. |
|||
Finally, online consumers who have a family member with a domain name are strongly interested in purchasing a domain name. |
|||
Attitudes About Existing TLD Options |
Slightly more than three-quarters of consumers want to use the same domain name extension that they have used in the past when they make their next purchase. Given that the overwhelming majority used dot-com in the past, we can assume that this is the preferred choice going forward. |
||
dot-com remains the most universal TLD—many other TLDs have specifically assigned categories in the minds of consumers. |
|||
However, domain name extensions appear to be less important to consumers than choosing a descriptive name for a Web site (e.g., by a 3-to-1 margin, consumers would rather select a first choice name with a dot-us extension than a less desirable name with a dot-com extension. |
|||
Consumers would rather have a dot-us extension for their own Web site over dot-name, even though they acknowledge that dot-name is more descriptive of a personal Web site. |
|||
Assess branding and product benefits for the usTLD |
A key differentiator for dot-us (like most non-dot-com suffixes) is that consumers can receive the name that they want. |
||
Other branding efforts should focus on the patriotic aspects of the usTLD. This focus particularly resonates with older online consumers. |
|||
Consumers assume that a dot-us Web site would be more trustworthy than a dot-web or dot-biz. site. |
|||
B.2-35
Finally, while many feel that a usTLD is easy to remember, there is some concern that a person using a dot-us extension would be difficult to locate on a search engine. |
|||
Receptivity for locality and hierarchical based structures |
About 4 in 10 consumers are generally receptive to locality-based name structures. |
||
However, when we ask consumers if they would personally prefer a long locality-based name (such as yourname.dallas.tx.us) or a shorter structure (yourname.us), the overwhelming preference is for the shorter name. |
|||
Consumers overwhelmingly believe that public service second-level domains (i.e., parks.us) are a good idea. |
|||
Preferred strings for different types of Web sites |
dot-com tested most favorably among all the options presented. |
||
dot-us tested very favorably versus the options presented, particularly when the sought-after name in dot-com was unavailable. |
|||
dot-us is seen as most relevant for government, education, political, and military Web sites. Users were also receptive toward personal, business, family, and community Web sites with usTLDs. |
|||
dot-net is seen as primarily for networks and alliances. Other potential uses are for any corporate Web site and, to a lesser extent, for personal Web sites. |
|||
dot-name is seen as relevant only for personal or family Web sites. |
|||
dot-biz is seen as strictly a corporate Web site TLD. |
|||
Consumers believe dot-org has multiple applications outside personal use. |
|||
Consumers clearly prefer TLDs that: |
|||
• |
Are flat rather than hierarchical |
||
• |
Are generic (like dot-us) rather than specific (like dot-name) |
||
• |
Encourage shorter rather than longer names |
||
Price elasticity and channel strategies |
dot-us needs to be priced competitively in the marketplace. While most expect dot-com and dot-us to be priced equally, a plurality of consumers expects dot-us to be cheaper than dot-com. |
||
For likely domain name purchasers, dot-us purchase intent remains low until the $15 per year price point; at $15 per year, 64% say they would be "very likely" to purchase a usTLD. |
|||
Not surprisingly, online is the preferred channel for TLDs. Among other avenues tested, about 1 in 10 are very interested in a tele-channel and 1 in 7 are very interested in purchasing domain names at retail outlets. |
|||
Barriers to TLD Purchases |
Three in five online consumers do not know how to purchase a domain name. |
||
B.2-36
Two-thirds of online consumers believe that they do not need their own domain name right now. |
|||
Approximately 1 in 4 survey respondents believe that owning a Web site is too expensive and 1 in 5 believe the creation and maintenance of a Web site is too difficult. |
Summary of Results and Conclusions—Businesses
Domain Name Registration Purchasing Habits | Domain name penetration (in percentage terms) is relatively high in the business Internet population, with 55% currently owning a domain name. | ||
However, we do not anticipate a great deal of business activity in the next year, since only 7% of businesses say they plan to purchase a domain name within the next year. An additional 4% report that they plan to purchase a domain name in the next three years. |
|||
Small businesses are more likely than large businesses to say they plan to purchase a domain name in the next year. |
|||
A majority of online businesses say their Web site is important to them. |
|||
Approximately 2 in 5 businesses say customers purchase goods or services through their current Web site. |
|||
Awareness and Purchasing Likelihood of usTLDs |
In an unaided test, very few businesses were able to recall that dot-us exists. In fact, general awareness of ccTLDs is low. |
||
One in twenty business survey respondents work for a company that currently has a country code associated with its domain name. Virtually all of these businesses have more than 1,000 employees. |
|||
In an aided test, approximately 7 in 10 report that they know that dot-us exists. This aided figure is very close to TLDs other than dot-com and dot-net (such as dot-pro). This suggests that even though the generic use of dot-us has been released after some others, it does not start at a brand equity or intent to purchase disadvantage vis-à-vis newer TLDs. |
|||
Our initial estimates are that approximately 1 in 5 businesses state some interest in eventually purchasing a usTLD. This is an elastic figure, however, as many more are willing to consider a usTLD if |
|||
• |
Their dot-com option is taken |
||
• |
dot-us can competitively compete with dot-com on price |
||
• |
They realize the necessity in purchasing dot-us in order to prevent cybersquatting. |
||
Size and Demographics of Likely Purchasers |
Slightly more than one-fifth of online businesses state an interest in one day purchasing a domain name with a dot-us extension. This means that approximately 1.5 million businesses are potential purchasers of the usTLD. |
||
B.2-37
While small and large businesses demonstrate strong interest in purchasing domain names going forward, midsize businesses appear less interested. |
|||
SOHO is an excellent target. |
|||
Target business purchasers have been online for over 5 years, and self-identify as "Internet experts." |
|||
Most business purchasers currently own a domain name. |
|||
Very few target business purchasers are over the age of 55. |
|||
Businesses that do not currently own a domain name or know how to purchase a domain name, and whose employees do not use the Internet on a daily basis are disinclined to purchase a domain name. |
|||
Attitudes about existing TLD options |
Slightly more than 3 in 5 businesses want to use the same domain name extension that they have used in the past when they make their next purchase. Given that the overwhelming majority used dot-com in the past, we can assume that this is the preferred choice going forward. |
||
dot-com remains the most universal TLD—many other TLDs have specifically assigned categories in the minds of businesses. |
|||
However, domain name extensions appear to be slightly less important to businesses than choosing a descriptive name for a Web site. For example, by a six-point margin, businesses would rather select a first choice name with a dot-us extension than a less desirable name with a dot-com extension. |
|||
Businesses would rather have a dot-us extension for their corporate Web site over dot-biz even though they acknowledge that dot-biz is more descriptive of a business Web site. |
|||
Assess branding and product benefits for the usTLD |
A key differentiator for dot-us (like most non-dot-com suffixes) is that businesses can receive the name that they want. |
||
Seven in ten businesses believe the dot-us extension means that the company is based in the United States. |
|||
While many businesses feel that a usTLD is easy to remember, there is some concern that a company using a dot-us extension could be difficult to locate on a search engine. |
|||
About one-third of businesses feel that dot-us connotes that a Web site is secure and trustworthy. |
|||
Businesses say that just because a Web site has a dot-us extension, this does not necessarily mean that it is new. |
|||
Among the businesses interested in purchasing a usTLD, one-third cited the prevention of cybersquatting and one-third believes that usTLD adds value; the remainder were unsure. |
|||
Receptivity for locality and hierarchical based structures |
About 4 in 10 online businesses are generally receptive to locality-based name structures. |
||
B.2-38
However, when we ask businesses if they would personally prefer a long locality-based name (such as your.company.dallas.tx.us) or a shorter structure (your.company.us), the overwhelming preference is for the shorter name. |
|||
Preferred strings for different types of Web sites |
dot-com tested most favorably among all the options presented. |
||
dot-us tested very favorably versus the options presented, particularly when the sought-after name in dot-com was unavailable. |
|||
dot-us is seen as most relevant for government, education, political, and military Web sites. Businesses were also receptive toward personal, business, family, and community Web sites with usTLDs. |
|||
dot-net is seen as primarily for networks and alliances. Other potential uses are for any corporate Web site and, to a lesser extent, for personal Web sites. |
|||
dot-biz is seen as strictly a corporate Web site TLD. |
|||
Businesses believe dot-org has multiple applications outside personal use. |
|||
Businesses (just like consumers) clearly prefer TLDs that: |
|||
• |
Are flat rather than hierarchical |
||
• |
Are generic (like dot-us) rather than specific (like dot-name) |
||
• |
Encourage shorter rather than longer names |
||
Price elasticity and channel strategies |
dot-us needs to be priced competitively in the marketplace. While most expect dot-com and dot-us to be priced equally, a plurality of businesses expect dot-us to be cheaper than dot-com. |
||
For likely domain name purchasers, dot-us purchase intent remains low until the $15 per year price point; at $15 per year, 63% of business say they would be very likely to purchase a usTLD. |
|||
Businesses prefer purchasing domain names in longer intervals (well over 50% would like the intervals to be three years or more) without having to renew. |
|||
Not surprisingly, online is the preferred channel for TLDs. Among other avenues tested, 15% are very interested in a tele-channel and 1 in 10 are very interested in purchasing domain names at retail outlets. |
|||
Barriers to TLD Purchases |
Slightly less than 1 in 5 businesses say that they do not know how to purchase a domain name and that this has been a very important barrier that has stopped them from creating a Web site. |
||
One-third of businesses believe that they do not need their own domain name right now. |
|||
About 1 in 4 business respondents believe purchasing a domain name is too expensive and 13% believe the creation and maintenance of a Web site is too difficult. |
B.2-39
B.2.9 Integration Assistance
NeuStar's Registrar Tool Kit software and operational test-and-evaluation facility will ensure that registries rapidly become familiar with our thick registry system, allowing them to begin operations efficiently, as soon as possible after accreditation.
NeuStar will operate a thick registry for the usTLD; although this thick registry allows us to enable new and enhanced services, it will also require registrars to follow new procedures when working with the usTLD registry. NeuStar will make every effort to give our registrars the support they need for a smooth transition to integrating with the usTLD registry.
Once a registrar is accredited, NeuStar will provide the XRP Registrar Tool Kit (RTK) software, along with documentation and training materials, to enable that registrar to learn the procedures and to obtain the technical knowledge necessary to interface with the usTLD registry.
NeuStar will establish an operational test-and-evaluation facility that will be available 24 × 7 × 365 for registrars to test their client systems. Our technical support team, which consists of functional experts in the processes and technologies for domain-name registration, will support this testing.
Once each new registrar is satisfied that its system is compatible with the registry system, it will schedule a formal acceptance test that will be monitored by our system engineers. After a registrar has passed the acceptance test, we will issue a user ID, passwords, and digital certificates, so that the registrar can begin operations.
B.2.10 Compliance Monitoring
Monitoring of delegees for technical compliance to the most current usTLD policies will ensure that NeuStar's database remains up to date, that delegees remain compliant with usTLD technical requirements, and that the usTLD retains a U.S. Nexus.
As discussed in Section B.4.5, NeuStar will conduct an initial compliance investigation in the first six months after contract award. This investigation is a requirement of the RFQ, and is intended to allow NeuStar to suggest policy changes, as well as to identify non-responsive delegees (including subdelegees), delegees who do not meet policy and technical compliance requirements, and "locality squatters." As part of this investigation, we will work collaboratively with delegees to help them achieve both policy and technical compliance, if they are found lacking in any way.
Information garnered from this investigation should also serve to confirm information received from the current administrator regarding server names and physical locations of the delegee servers. This will allow NeuStar to ensure that all delegee nameservers are physically located in the United States.
It is also important, however, that delegees continue to remain compliant with usTLD technical requirements for the lifetime of their delegations, and a level of oversight by NeuStar will help to guarantee this. Since NeuStar will not necessarily be hosting the resource records associated with names registered to delegated managers, it is possible for the delegee to register a name and forget to update NeuStar. NeuStar will "walk the tree" (see Section F for a description) on a continuous basis and compare the results with information in the Centralized usTLD Database. If there is a difference, we will contact the delegated manager to correct the discrepancy. Additionally, NeuStar will perform yearly monitoring for technical compliance of locality delegees.
B.2-40
During this yearly audit, NeuStar will check that delegees continue to meet the technical and other requirements set out in RFC 1480 and other documents, and will include the following:
In order to perform this monitoring function, NeuStar will compare delegee information in the Centralized usTLD Database with information in the zone files. NeuStar will also prepare a technical survey to send to delegees, requesting information to confirm the names and physical locations of delegee nameservers, as well as delegee contact information.
In continuing with our cooperative approach to our initial compliance investigation, NeuStar will be monitoring compliance to ensure that all delegees meet the technical and U.S. Nexus requirements necessary to run a usTLD delegation and protect the integrity of the usTLD and of the Internet. As with the original report, we will work with any deficient delegees to help them achieve technical compliance.
B.2.11 Web Site
NeuStar's usTLD Web site will provide comprehensive information and communications methods to registrars and delegees while also displaying, informative essential pages to the general public.
NeuStar recognizes how critical information flow is for a registry to interact with its registrars. We also understand that, as the administrator responsible for the integrity of the usTLD, we must provide information that can be easily accessed by the Internet community. Although these are two very distinct requirements, they can easily be incorporated into a single, easy-to-navigate, content-based Web site. NeuStar will implement such a Web site divided into a public section for potential new registrars and the Internet community and a private section for existing registrars and locality delegees (including subdelegees).
The public section of this Web site will provide information to potential new registrars as well as to the Internet community. It is vital that this section of the Web site be easy to use and easy to navigate; we will make every effort to prevent confusion, especially among the newest visitors to the Web site.
This public portion of the Web site will allow users to do the following:
B.2-41
Our efforts to maintain the best possible communications with usTLD registrars will be reflected in the private members section of the usTLD Web site. This section will allow registrars to access information about all areas of the registry's operation. Some of the key components of the site will be:
NeuStar's Web development team is experienced in providing Web sites that allow both public and private access. We will leverage our Web development experience and design an easy-to-navigate, content-based Web site that will provide fast and easy access to services, help, and information to all of our customers.
B.2.12 Documentation and Training
Readily available, clear and concise procedures and documentation ensure a stable system, informed customers, and knowledgeable Help Desk account representatives. These are fundamental to NeuStar's customer service philosophy.
Accurate, detailed documentation is vital to the implementation of any successful TLD registry, particularly when transitioning the administration of and enhancing the registry. System documentation in particular will contribute to the stability of the registry and improve service enhancements.
Two distinct types of documentation are required in order to provide a complete understanding of the usTLD and the services being provided—internal and external. Internal documentation includes both system documents and methods and procedures (M&P) documents. External documentation includes all user documents, such as online help and user's manuals and training materials for new registrars. Training of the usTLD staff ensures the highest quality of customer service that NeuStar can offer, and training materials provided to registrars allow those registrars to quickly become familiar with usTLD registry operations.
System documentation allows developers to relay the details of the usTLD registry specifications, design, and interfaces. These documents assist not only in the initial implementation of the system but also in repairing the system and scaling the system, should the need arise. M&P documentation will
B.2-42
provide the usTLD support staff with policies and procedures for support of the usTLD. These documents will provide clear instructions for responding to requests for help, procedures for handling service interruptions, and workflow processes for all functional areas. M&P documentation, while invisible to our customers, is a vital step in providing the best possible services to them. User documentation provides registrars with detailed instructions for using the Registrar Tool Kit and interfacing with the usTLD registry. These documents are vital to successful implementation of the usTLD expanded space.
Internal Documentation
As part of our internal documentation initiative, NeuStar will develop both system documents and M&P documents. In addition, a Quality Assurance (QA) Plan will be prepared and used throughout the development, test, implementation, and maintenance life cycles to ensure the quality and success of the usTLD registry. The QA Plan will specify all system and user documents to be produced for the usTLD registry.
The full suite of internal documentation will be prepared and maintained by NeuStar through the project life cycle and will be made available to the DOC or to a designated third party for audit purposes. Compliance matrices will be prepared to map system requirements to system design and to individual test scenarios. At a minimum, system documentation will include the following:
M&P documents will be developed and maintained to guide NeuStar personnel in the day-to-day operation of the usTLD. These documents will contain all of the usTLD business rules and workflow processes for all functional areas, as well as internal and external reporting requirements. At a minimum, M&P Documentation will include the following:
All M&P documentation will also include contact information for escalation of issues.
B.2-43
As part of our external documentation initiative, NeuStar will develop guides for use by registrars in the usTLD expanded space, as well as guidelines for locality-space delegees. These documents will be available on the usTLD Web site.
At a minimum, user documentation will include the following:
Training
In order to provide the best value in service to registrars, delegees, and registrants, the IP Customer Support Team will develop and distribute extensive training materials to ensure that all staff have a well-rounded knowledge and understanding of registry and registrar operations and procedures. Although staff will be chosen on the basis of domain name management experience, it is vital that all members of the usTLD team are trained on usTLD-specific methods and procedures. In this way, NeuStar will ensure extremely high levels of quality, consistent support services.
At NeuStar, we want our customers to feel comfortable working within our systems; a registrar that does not fully comprehend our procedures and functions may feel uncomfortable working with us. To avoid these problems and ensure fuller participation in the usTLD registry, training materials will be provided to registrars via the usTLD Web site. These materials will include presentations and walk-throughs that instruct registrars on use of the RTK software and inform them on how to interface with the usTLD registry. Any questions from registrars not covered in these training materials and in the user documentation and FAQs will be answered, either by our Integration Assistance team or the Help Desk staff.
B.2.13 Customer Relationship Management
NeuStar will leverage an enterprise-wide CRM program to assist in channel management and outreach for the usTLD.
NeuStar recognizes that the most important element in any service is the customer—whether that customer is the Department of Commerce, a registrar, or an individual registrant. To this end, NeuStar has codified and implemented throughout its lines of business a thoughtful, thorough, and down-to-earth approach to Customer Relationship Management (CRM). NeuStar's goal is to ensure customer satisfaction and provide superb service levels to all of the customers with whom we have a relationship.
B.2-44
Our CRM vision is to exceed customer satisfaction levels by managing all communications channels, regardless of how customer interactions are initiated, and by observing the needs and wants of our customers to better understand them. CRM allows us to seamlessly blend multiple technologies and applications with processes and resources while managing all areas and types of customer interactions, including sales, marketing, customer service, billing, and technical support. Our CRM program will optimize the value of every customer interaction and experience with usTLD points of contact and service. NeuStar's commitment to provide this down-to-earth customer support is at the heart of our CRM business practices and procedures. We understand the high expectations of our customer base for providing usTLD services to the Internet community in the United States—and NeuStar will deliver.
Our CRM program comprises scalable infrastructure, solid processes, and a technological foundation. We will use CRM in combination with our extensive market and customer knowledge to ensure that we meet our commitment to timely, responsive, and high-quality customer service.
B.2.14 Reporting
NeuStar's Web-based usTLD reporting system will be rich in functionality and have built-in flexibility to provide reporting information to registrars in numerous ways.
NeuStar's usTLD registry will include an automated reporting service that will provide a regular, high-level description of information about the registrar's interaction with the registry. This report will be e-mailed to designated registry contacts and will be available via the private section of the usTLD Web site. It is important to note that a registrar will have access only to its own data; a registrar will not have access to any other registrar's private information. The specific information included in these reports will be developed in consultation with registrars to ensure that they have access to information they deem critical for their business, and different sets of information will be available for different time periods. The reports will include data such as:
It is anticipated that registrars may require additional, specific information from time to time. To make this information available to registrars, NeuStar will develop a Web-based report query function. This function will allow registrars to obtain information on registration and maintenance activity such as:
These reports will be developed on an ongoing basis in consultation with registrars and the DOC.
B.2-45
B.2.15 Progress and Quarterly Reporting
In order to provide assurances to the COTR of the level of work and progress toward goals of the usTLD, NeuStar will submit progress reports and quarterly reports, as required by the RFQ.
Routine communications with our customer is the best way to ensure that we are making progress toward our goals for the usTLD. In accordance with RFQ Section C.2, NeuStar will submit monthly progress reports to the COTR and post them on our web site for the first two years of the purchase order, as well as quarterly reports thereafter. These reports will indicate the status of all major events as well as major work performed during the reporting period, including technical status, accomplishments, and complications experienced in fulfilling SOW requirements. These reports will also provide performance data related to the operation of the usTLD registry. This data will include, for each reporting period:
B.2.16 Help Desk
Our unparalleled experience in providing data administration solutions and services makes NeuStar the only entity truly capable of providing the technical support and administration services necessary for the successful operation of the usTLD registry.
Because of the complex nature of the usTLD space, a high level of Help Desk services will be necessary to support our customers—registrars, delegees (which includes subdelegees), and locality-based registrants. NeuStar will ensure that these communities have access to the right support from the right people.
During implementation, the usTLD staff will work to establish policies, processes, and procedures that facilitate efficient usTLD operations, including verifying and understanding registrar interfaces, problem resolution and escalation procedures, service and administration guidelines, and customer record security. Registrars who call the Help Desk will be identified by caller ID and by a pre-established pass phrase that is different for each registrar.
NeuStar's usTLD Help Desk within the Internet Protocol (IP) Customer Service Center will be the first point of contact for registrars, delegees, and direct registrants for Tier 1 technical and account questions as well as for billing questions. Tier 2 technical support will be available on a 24 × 7 × 365 basis. We will leverage NeuStar employees trained in Internet Help Desk operations; these employees will be familiar will all usTLD policies, standards, and practices. In order to accommodate multiple U.S. time zones, the Help Desk will be available from 8:00 a.m. to 8:00 p.m. (EST), Monday through Friday.
Help Desk personnel and other assistance will be available to our customers through a variety of means, including:
B.2-46
The IP Customer Service Center's phone system will use an Interactive Voice Response (IVR) system and Automatic Call Distributor (ACD) to route registrar and direct registrant calls to the appropriate Help Desk personnel. Customers who call the toll-free number after 8:00 p.m. will have their calls routed to the on-call Second Tier technical support specialist. NeuStar's highly skilled, customer-oriented Help Desk staff will be responsive to customer needs and will provide the following support services:
Customer support queries received by phone, by e-mail, or from the usTLD Web site will be logged and tracked through assignment of a trouble ticket. It is the goal of NeuStar's IP Customer Support Center to close as many trouble tickets as possible on the first call. In the event that an issue cannot be resolved during the initial call, it will be escalated to the appropriate Second Tier support service.
NeuStar's Second Tier Customer Support staff will act as a second level of escalation in resolving registrars' technical issues. This team will be responsible for providing complex problem identification and resolution, in-depth system integration assistance, and system troubleshooting. Some of the key functions supported by this team include:
The Billing and Collections team will provide support for account statements, reconciliation, and other billing issues. Although the primary point of contact for registrars on these issues will be the account manager, the Billing and Collections team will be responsible for understanding and meeting the day-to-day billing needs of registrars. The core responsibilities of the Billing and Collections team will be to:
B.2-47
Help Desk Escalation
Help Desk escalation procedures are intended to resolve issues as quickly as possible. An escalated Help Desk call will use the following procedure:
B.2-48
resolution if they are not resolved within the escalation policy time limits. The following table is an overview of our escalation policy.
NeuStar usTLD Help Desk Escalation Policy
Level |
Description |
Escalation Policy |
Notification |
|||
---|---|---|---|---|---|---|
I | Catastrophic outage affecting overall registry operations | Service center manager escalates to usTLD management and Disaster Recovery Team if not resolved in 15 minutes | Web portal and e-mail notifications to all registrars and locality delegees within 15 minutes; updates every 30 minutes | |||
II |
Systems outage affecting one or two registrar sessions but not the entire system |
Systems engineer escalates to service center manager if not resolved in one hour. |
Web-portal notification to all registrars and locality delegees, including subdelegees; hourly updates |
|||
III |
Technical questions |
Help Desk account representative escalates to the systems engineer if not resolved in two hours |
Hourly updates to registrar, locality delegee, or registrant via e-mail |
|||
IV |
Basic questions |
Help Desk account representative escalates to the systems engineer if not resolved within four hours |
Hourly updates to registrar, locality delegee, or registrant via e-mail |
The NeuStar Difference
Throughout our operations, in both telephony and IP services, NeuStar has demonstrated its ability to deliver and manage complex database services such as those needed to run a successful top-level domain. More than that, NeuStar has first-hand experience in learning what difficulties can arise from registry services like the usTLD registry and has proven its capability not only to handle problems efficiently when they arise but also to prevent them from occurring.
B.2-49
B.3 Core Policy Requirements
NeuStar will establish sound policies and processes designed to create a collaborative partnership between the usTLD Administrator and the usTLD community.
NeuStar believes that the role of the usTLD Administrator is similar to that of a trustee of an important public resource. Indeed, NeuStar submits that this should be the role of the administrator for any ccTLD. Given this role, the usTLD Administrator is responsible for the development of sound policies and procedures designed to ensure that the Administrator's operations serve the public interest.
To properly serve the public interest in the usTLD context, the usTLD Administrator must:
In its development and implementation of policies and procedures for the usTLD, the new usTLD administrator must avoid (i) taking a minimalist approach by describing certain public interest aspirations and guidelines without establishing sufficient processes to back them up, or (ii) adopting very heavy-handed regulation designed to force users and services providers of the space into a single vision of the usTLD. The first approach fails to establish a sufficient framework to promote certainty and value for users of the space, and the second approach establishes rigid structures lacking the flexibility to deal with changing business, social and policy environments. Thus, both approaches will fail, causing the ultimate failure of the enhanced usTLD. NeuStar's approach will avoid the pitfalls of under- or over-structuring the TLD space.
NeuStar will establish a number of core policies designed to address certain issues specified in the RFQ, as well as issues generally required for the transition and start-up of an enhanced usTLD. The basic polices that NeuStar will implement include:
B.3-1
The majority of NeuStar's policy activity will not be prescriptive in nature. Rather, NeuStar submits that the most effective policy structure for the usTLD will be one of collaborative partnership. NeuStar will establish effective and flexible processes responsive to the usTLD community and the public interest. In particular, NeuStar will develop a usTLD Policy Council (Council) as an advisory body for usTLD policy operations. This body will interface with the public and provide an independent forum and mechanism for future development of the usTLD.
Initially, the Council will be responsible for the modernization and enhancement of the locality-based usTLD space. In the future, however, the Council may be called upon to address such issues as new hierarchical space within the TLD to address recognized public needs, the enhancement of privacy protections for domain registrants, or the enforcement of the accreditation agreement with registrars. In any event, the Council will be designed to work effectively with the various usTLD constituencies, federal, state and local governments, and ICANN, to ensure that the usTLD Administrator's role as a trustee is fulfilled.
NeuStar is uniquely qualified to assume the complex policy role needed to properly serve the usTLD community. Indeed, the kinds of goals described are entirely consistent with NeuStar's proven record in its roles as the North American Numbering Plan Administrator and the Local Number Portability Administrator. Much more is needed in the administration of the usTLD than a strong technical solution. Absent the skills developed through the administration of public resources, it is unlikely that an entity will have the expertise to properly manage the usTLD envisioned in the RFQ and the capability to support the principles established for ccTLDs by the Governmental Advisory Committee of ICANN.
As demonstrated through the proposed development of the Council, a key aspect of NeuStar's plan to meet the goals discussed above is its commitment to ensuring that the usTLD Administrator operates as a trusted neutral third-party in the provision of secure, stable and fair administration services for the critical public resource, the usTLD space. As is clearly outlined above, despite the views of many that a ccTLD is simply another commercial venture, the usTLD Administrator cannot act simply as a commercially motivated operator. Therefore, in performing its duties for the usTLD the Administrator must hold itself to a code of conduct exceeding traditional commercial standards.
Access to DNS services is critical to entities wishing to participate in the DNS industry specifically and in Internet business generally. Domain names are the means by which governments, businesses, and consumers gain access to, navigate, and reap the benefits of the worldwide web. These benefits cannot be fully realized, however, unless policies are in place to ensure that DNS resources in the usTLD are administered in a fair, equitable and efficient manner that makes them available to all parties desiring to provide DNS services. In order to meet this goal, NeuStar submits that the services of the Administrator must be administered to meet the following objectives:
B.3-2
To ensure that NeuStar meets these objectives, it commits to strict adherence to the following usTLD Administrator Code of Conduct:
usTLD ADMINISTRATOR CODE OF CONDUCT
To ensure the provision of neutral usTLD administrative services, NeuStar will comply with this Code of Conduct.
B.3.1 US Nexus Requirement Implementation
As an important public resource, the usTLD must be managed in a manner designed to serve the United States Internet community. Therefore NeuStar will implement a US Nexus Requirement.
Recognizing that the usTLD is an important public resource that must be managed for the benefit of the United States, its citizens, and its residents, NeuStar will implement, in addition to the requirement set forth in RFC 1480 that usTLD domain name registrations be hosted on computers located within the United States, the following Nexus Requirement in both locality-based usTLD structure and the expanded usTLD space: Registrants in the usTLD must be either:
B.3-3
Whether a prospective registrant has a "bona fide presence in the United States" will be determined on a case-by-case basis in light of all relevant facts and circumstances at the time of application for a usTLD domain name. This requirement is intended to ensure that only those individuals or organizations that have a substantive connection to the United States are permitted to register for usTLD domain names.
Factors that should be considered in determining whether an entity or organization has a bona fide presence in the United States shall include, without limitation, whether such prospective usTLD domain name registrant:
For purposes of this definition, the terms United States and United States of America shall include all U.S. territories and possessions.
It shall be a continuing requirement that all usTLD domain name registrants maintain the US Nexus Requirement.
The Nexus Requirement will be enforced through an initial screening of the contact information provided by the registrant, as well as a challenge process permitted through the Nexus Dispute Policy discussed below. The screening by NeuStar will verify that selected fields, within the contact information provided, on their face, meet the Nexus Requirement and that the registrant has certified compliance with the requirement, as well as certified that the nameservers identified are located within the United States. In the event that the contact information provided does not meet the above requirement, the name requested will be placed on hold within the registry and the registrant will be given an opportunity to correct any mistake or demonstrate compliance with the Nexus requirement. If no action is taken by the registrant within the 30-day period, the registration will be cancelled and the name will be returned to available status. If, on the other hand, the registrant is able to demonstrate compliance with the requirement, the name will be registered.
Nexus Dispute Policy
Although the Nexus Requirement will initially be enforced through a usTLD Registrar's screening of the contact information provided by the registrant, and the registrant will certify that it meets at least one of the Nexus Requirements set forth above, NeuStar understands that disputes may arise as to the authenticity, veracity, or accuracy of the registrant's Nexus certification. Therefore, NeuStar, as administrator of the usTLD has devised a Nexus Dispute Policy (NDP) which will be administered
B.3-4
solely by the usTLD Administrator, or its designated representative. The NDP will provide interested parties with an opportunity to challenge a registration not complying with the Nexus Requirement.
In the event that a third party wishes to challenge the authenticity or veracity of a usTLD registrant's United States Nexus, that party may submit a "Nexus Challenge" to the usTLD Administrator or its authorized representative. The challenger must submit a written statement to the usTLD Administrator via first class mail alleging in specificity evidence to support its allegation that the registrant fails to meet any of the Nexus Requirements set forth above.
Once a challenge is received by the usTLD Administrator the domain name shall be "locked" by the usTLD Administrator until the matter is resolved. While in a "locked" position, the registrant may not (i) change any of the contact information for that particular domain name or (ii) transfer the domain name to any third party.
In the event that the usTLD Administrator finds that the challenger has established a prima facie case that the registrant has not met any of the Nexus Requirements, the usTLD Administrator shall issue a letter to the registrant to submit evidence of compliance with the Nexus Requirements ("Letter"). The registrant shall have a period of thirty (30) days from the date of the Letter to submit evidence of compliance. If, within the thirty (30) days, the registrant submits evidence establishing any of the Nexus Requirements, the registrant shall be permitted to keep the domain name.
If, however, the registrant either (i) does not respond within the thirty days, or (ii) is unable to demonstrate through documentary evidence that it met any of the Nexus Requirements prior to the date the NDP was invoked, the usTLD Administrator shall issue a finding that the registrant has failed to meet the Nexus Requirements. Upon such a finding, the registrant shall be given a total of thirty (30) days to cure the US Nexus deficiency. If the registrant is able to demonstrate within (30) days that it has cured such deficiency, the registrant shall be allowed to keep the domain name. If the registrant either (i) does not respond within the thirty (30) days, or (ii) is unable to proffer evidence demonstrating compliance with the Nexus Requirements, the domain name registration shall be deleted from the registry database and the domain name will be placed into the list of available domain names. This process represents the exclusive remedy for an NDP challenger.
NeuStar reserves the right to modify this NDP at any time with the permission of COTR. NeuStar will post its revised NDP on its Website at least thirty (30) calendar days before it becomes effective.
B.3.2 Open ccTLD Policies Adoption
NeuStar intends to establish the usTLD as a model ccTLD in the global Internet community. NeuStar fully supports, and will abide by, the open ccTLD policies established by ICANN.
NeuStar believes that the usTLD should be developed to serve as the model ccTLD in the global Internet community. In particular, it supports the significant work done by ICANN and the Internet community in developing and enhancing the Internet in the public interest. Therefore, in accordance with the DOC's requirements, from both a technical and a policy standpoint, NeuStar will develop the usTLD pursuant to developing "best practices" for open ccTLDs, as established by ICANN. Further, we will work with ICANN in the development and enhancement of new policies as they relate to the usTLD and the Internet at large.
An example of the types of open ccTLD policies supported by NeuStar is the ccTLD Constituency of the ICANN DNSO's document "Best Practice Guidelines for ccTLD Managers." Open, consensus- based policies such as these provide a sound basis for operating public resource services. Indeed, many of the principles contained in the "Best Practices" document reflect the basic themes discussed in this
B.3-5
proposal. For example, the document establishes, among other things, the following obligations of ccTLD Managers:
The primary duty of the ccTLD Manager is one of public service—to manage and operate the ccTLD Registry in the interest of and in consultation with the local Internet community, mindful of the interests of the global Internet community.
A ccTLD Manager is a trustee for the delegated domain and has a duty to serve the community it represents as well as the global Internet community. Concerns about "rights" and "ownership" of top-level domains are inappropriate. It is appropriate to be concerned about "responsibilities" and "service" to the community. The ccTLD manager should be judged on his or her performance and the extent to which it satisfies the needs of the local and global Internet communities.
NeuStar considers it a basic principle of usTLD administration that the administrator is a trustee of a valuable and important public resource. Thus, NeuStar agrees with and will abide by ICANN's open ccTLD policies, subject to any requirements of United States law and unless otherwise directed by the Contracting Officer.
B.3.3 usTLD Dispute Policies and Sunrise Policy/ Implementation
NeuStar understands that the success of an expanded and enhanced usTLD requires the development of a set of policies and dispute resolution processes that are simple and effective and provide a level of accountability for the users of the usTLD. Therefore, NeuStar has established (i) the usTLD Dispute Resolution Policy (usDRP) that is modeled after ICANN's Uniform Dispute Resolution Policy, and (ii) a Nexus Dispute Policy; a dispute mechanism to handle disputes relating to the usTLD Nexus Requirements set forth in Section B.3.1 above.
B.3.3.1 usTLD Dispute Resolution Policy
The usDRP combines the globally accepted Uniform Dispute Resolution Policy ("UDRP") for the gTLDs with improvements developed in conjunction with the World Intellectual Property Organization ("WIPO") for the administration of domain name disputes in the .BIZ top-level domain. Through its ongoing relationship with WIPO in its development of the .BIZ dispute resolution services, NeuStar is uniquely qualified to apply its knowledge and expertise in the development of domain name dispute resolution policies for the usTLD.
Although an applicant for the usTLD administrator might simply adopt the UDRP as in its current form, NeuStar believes that this would be unwise given the number of flaws that two years of experience with the policy has demonstrated.
The UDRP was adopted in late-1999 by ICANN as its first, and to date, its only global consensus-based policy, in response to the WIPO's recommendation to establish a uniform dispute resolution policy for "cases of bad faith, abusive registration of domain names that violate trademark rights ("cybersquatting' in popular terminology)." The Management of Internet Names and Addresses: Intellectual Property Issues, Final Report of the WIPO Internet Domain Name Process, See http://wipo2.wipo.int/process1/report/finalreport.html.
Through its numerous consultations with WIPO during the formulation of the .BIZ dispute resolution policies, NeuStar uncovered several flaws in the UDRP process that not only led to the issuance of inconsistent determinations by panelists but also unnecessary administrative burdens on the UDRP dispute providers. For example, the current UDRP requires that a trademark owner demonstrate that a domain name registrant both registered and used the domain name in bad faith. This requirement of both "registration and use" of domain names in bad faith has led UDRP panelists to find in favor of cybersquatters who have warehoused domain names that are identical or confusingly similar to famous trademarks, but have not "used" the domain names in bad faith (i.e., the domain
B.3-6
names do not resolve to actual web pages). In other words, panelists have found that although a trademark owner has demonstrated that a cybersquatter has registered a number of domain names that correspond to famous trademarks, because the domain name in question did not actually resolve to a web site, there was no "use" in bad faith. This result was clearly not intended by the original drafters of the UDRP.
In order to address this problem, NeuStar had modified this specific language in its usDRP to allow panelists to find in favor of the trademark owner if the trademark owner can establish that the domain name was either registered or used in bad faith. This change was met with high praise by both WIPO and the Intellectual Property Constituency of ICANN when it was adopted in .BIZ's Start-up Trademark Opposition Policy.
A second example of a flaw in the UDRP which has led to inconsistent decisions is a paragraph dealing with "evidence of registration or use in bad faith" (Section 4(b) of the Policy). This paragraph states that bad faith can be established if a Panel finds that a registrant registered the domain name in order to prevent the owner of the trademark or service mark from reflecting the mark in a corresponding name, provided that the registrant has engaged in a pattern of such conduct. This has led to several decisions which have been in favor of cybersquatters who although it was shown that they registered the one domain name in question to intentionally prevent the trademark owner from registering the domain name, it could not be shown that there was a "pattern of such conduct." In other words, under the UDRP, the explicit wording implies that unless the cybersquatter has prevented other trademark owners from registering their corresponding domain names, one instance of such activity does not amount to bad faith. This too is clearly inconsistent with the original drafters intent behind that particular paragraph. In order to address this problem, NeuStar adopted WIPO's suggestion to modify this specific language in its usDRP to allow panelists to find in favor of the trademark owner if the trademark owner can establish that the registrant registered the domain name in question in order to prevent the trademark owner from reflecting its trademark in a corresponding domain name, without showing a "pattern of such conduct."
A draft of both the usDRP and the Rules for the usDRP are provided at the end of this section.
Implementation
In order to ensure that NeuStar's improved dispute resolution mechanism, the usDRP, is enforced by only the most qualified dispute panelists familiar with all facets United States law, NeuStar has entered into an agreement with the American Arbitration Association ("AAA"). The AAA, the premier alternative dispute resolution provider in the United Sates, has flourished for nearly 75 years by demonstrating an unparalleled commitment to progressive leadership in alternative dispute resolution.
While many of the more than 140,000 cases administered by the American Arbitration Association in 1999 were resolved through mediation or arbitration, less formal methods of dispute resolution—such as fact-finding, mini-trial, and partnering—are clearly coming into wider use. To serve dispute resolution needs, the AAA provides a forum for the hearing of disputes through 37 offices nationwide, tested rules and procedures that have broad acceptance, and a roster of nearly 12,000 impartial experts to hear and resolve cases. Moreover, in addition to its significant dispute resolution experience, the AAA brings a fresh perspective to the Internet dispute resolution process.
In addition, if awarded the usTLD registry, NeuStar will solicit the expertise of other dispute resolution providers based in the United States in order to provide usTLD domain name registrants and intellectual property owners around the United States with the most qualified and knowledgeable usDRP panelists.
B.3-7
B.3.3.2 Sunrise Policy and Implementation
NeuStar will implement a Sunrise policy for owners of United States trademark applications and registrations which validates whether the claimed applications or registrations actually exist within the United States Patent and Trademark Office database, thus eliminating any need for costly and time-consuming Sunrise dispute resolution mechanism.
Since well before the formation of ICANN, intellectual property owners have debated how best to protect their trademarks and service marks ("Trademarks") on the Internet. NeuStar proposes to implement an enhanced "Sunrise" policy that not only balances the intellectual property rights of registered trademark owners, but also provides the same level of protection to those Trademark owners who have submitted trademark applications to the United States Patent and Trademark Office (PTO). In addition, unlike any other "Sunrise" plan implemented or even proposed, NeuStar will validate the authenticity of Trademark applications and registrations with the PTO through a unique and proprietary technological interface developed to ensure the integrity of the "Sunrise" process. Following is an overview of the process proposed for the implementation of the Sunrise period as in Shown in Exhibit B.3-1.
The Sunrise period will commence thirty (30) days prior to the general activation of the expanded usTLD space. During the Sunrise period, owners of trademarks and service marks (Trademarks), as well as applicants for such marks, will be able to register their marks as domain names in the new expanded usTLD space.
Any owner of an existing live Trademark registered on the Principal Register of the PTO, or an existing live application filed for registration with the PTO, will be eligible to seek to register the mark as a domain name during the Sunrise period provided that (i) the Trademark registration for that mark was issued prior to the commencement date of the Sunrise Period, or (ii) the application was filed with the PTO no later than July 27, 2001. In addition:
The registration form for the Sunrise period will include all normal registrant information along with additional details of the registered mark under which the registration is being made. The information required will include:
B.3-8
Along with these fields, the normal registration agreement will also contain a provision to the effect that:
The registrar and the usTLD Administrator shall have no liability for administering the Sunrise program so long as the registrar acts in accordance with the policies set forth in the Sunrise proposal.
[Exhibit B.3-1: NeuStar's enhanced "Sunrise" Policy not only balances the IP rights of registered trademark owners, it also provides the same level of protection for applicants to the PTD. Graphic Omitted: flow chart depicting sunrise policy implementation.]
Phase 1—Announcement
Information regarding the enhanced Sunrise program will be broadly communicated to the general public at least sixty (60) days prior to the activation date of the expanded usTLD space. The communication will be in the form of an announcement on the NeuStar web site as well as a general press release. During the announcement period, a list of all accredited registrars participating in the Sunrise program will be posted on the NeuStar web site along with a link to the registrars' web sites.
Phase 2—Sunrise Registration
In seeking to create the most neutral and impartial allocation of domain names during the Sunrise Period, NeuStar will use the same basic procedure as set forth for the Land Rush Period, Section J with a few important modifications specific to the Sunrise process.
Step 1: Submission of registration lists—Each accredited registrar will provide a list of domain names and Sunrise registration details. There will be no minimum or maximum limit for the lists. The registration files will be submitted via a secure transport mechanism before a specified closing time for first submissions. Registration lists cannot be modified until the first batch is processed and completed.
Step 2: Randomization of registrar submitted lists—The lists submitted by each registrar will be individually randomized and processed to eliminate duplicate Sunrise domain name registration requests (e.g., four different parties request unclesam.us; one of the requests will be selected and the others deleted from the list).
Step 3: Combination and randomization of registrar lists—After initial processing, the entire set of registrar lists will be combined into a single processing file and randomized.
Step 4: Processing of randomized list—Once the registration system is activated, a domain name will be randomly selected from the processing list.
Step 5: Validation of Trademark—NeuStar will not finalize the registration of a domain name under the Sunrise policy until the Trademark registration or application has been verified by the registry or its designated partner or agent. In order to verify the Trademark Registration or Application after the domain name is selected in Step 4 above, NeuStar will use its unique proprietary technology to query the PTO database to ensure that (1) the SLD portion of the domain name selected is an exact match of the claimed Trademark, (2) the Trademark has actually in fact been either applied for or registered with the PTO, and (3) the domain name applicant is in fact recognized in the PTO trademark database as the current owner or assignee of the Trademark. If a domain name meets all these qualifications, it is registered and entered into the domain name database.
B.3-9
If a domain name is either (i) unavailable, or (2) is rejected as not qualifying under the Sunrise policy, then another name is chosen at random from the list until one of the following occurs:
This process repeats until the entire list has been processed. When applicants submit registrations during the Sunrise period, they will be required to enter all relevant details for their mark's registration. The interface will support these extra fields and details will be published via the Whois database. If parties other than the registrant wish to challenge the validity of an application, they will then be able to use the trademark details to verify authenticity with the US Patent and Trademark Office.
Step 6: Results—At the end of the list processing, the results of Sunrise registrations are returned to the registrar.
Step 7: At the conclusion of the Sunrise period, no further Sunrise registrations will be accepted and the registry will commence the Land Rush registration process described in Section J.
NOTE: Sunrise registrations will only be accepted for terms of at least five (5) years and will be processed after registration fees are paid in full.
Sunrise Dispute Resolution
Because of NeuStar's unique and innovative approach to the Sunrise Policy coupled with actual validation of Trademarks with the PTO, NeuStar is proud to state that there is no need for a specific dispute resolution mechanism related to Sunrise registrations other than what is provided under the Nexus Dispute Policy and the usDRP.
B.3.4 GAC Principles
NeuStar fully supports and will abide by the principles established by the Government Advisory Council.
As previously stated, NeuStar believes that the usTLD should be developed to serve as the model ccTLD in the global Internet community. From both a technical and a policy standpoint, therefore, NeuStar will develop the usTLD pursuant to developing "best practices" for ccTLDs. One such set of principles is set forth in the ICANN Government Advisory Council's "Principles for the Delegation and Management of Country Code Top Level Domains." The document's preamble states that:
[T]he manager of a ccTLD performs a public service on behalf of the relevant local community and as such the designated manager has a duty to serve this community. The designated manager also has a responsibility to the global Internet community. By 'global Internet community' we do not mean any specific legal or international entity, but rather we interpret the term to refer to all of those who are affected by, now or in the future, the operation of the relevant TLD, because such operation may impinge on more than one jurisdiction and affect the interests of individuals and entities from both within the relevant country or territory and elsewhere.
This statement describes very clearly the basic premise pursuant to which NeuStar approaches the administration of the usTLD. Thus, NeuStar will abide by these principles, unless inconsistent with U.S. law or regulation.
B.3.5 Additional, Alternative or Supplemental Policies
NeuStar will develop and implement fair, flexible, and effective policies and procedures designed to ensure operation of the usTLD in the public interest.
NeuStar believes that the usTLD Administrator, while establishing sound and fair initial policies for the usTLD, should limit the number and scope of policies established without the benefit of usTLD
B.3-10
community participation. Therefore, the additional policies included in this section are those additional matters that must be addressed prior to launch to ensure a proper framework for enhancing and improving the usTLD in the manner set forth in the RFQ.
The additional policies needed for the transition to a new usTLD Administrator are:
Each of these policies is discussed in turn below.
Outreach Plan and Policy Council
As is stated throughout this proposal, NeuStar considers the usTLD an important public resource that must be administered to serve the public interest. It cannot be allowed to become captured by any single industry, constituency, or interest group, but instead, must carefully balance the needs of all community stakeholders. Thus, the usTLD Administrator must act as a trustee and facilitate consensus to ensure that all policy and development efforts are not only conducted in an open manner, but are effective.
In developing an appropriate and effective outreach plan, the new usTLD Administrator will have to address a number of important issues. Some of the tasks that the administrator must complete:
NeuStar believes that an administrator must conduct some level of outreach in order properly to develop its outreach plan. NeuStar already has started its outreach in preparation for this plan. In addition to the Public Awareness Plan work discussed in Section B.2.8, NeuStar has contacted a number of identified representatives of various constituencies in the usTLD community. Entities with which NeuStar has discussed the usTLD include the Media Access Project, the American Library Association, the Benton Foundation, the US Chamber of Commerce, the Center for Democracy and Technology, the National Indian Telecommunications Institute, education representatives, existing delegated managers, governmental representatives, and commercial entities. From these activities we have identified a number of principal concerns to consider, including:
B.3-11
In addition to concerns and issues regarding the administration of the usTLD generally, a number of parties discussed possible structures for the operation of the usTLD and/or the related policy function.
The first of the proposed structures was that the registry operator should be a not-for-profit company. This approach was driven by the concern that a corporation would be incented entirely by profit and not adequately serve the public interest. NeuStar submits, however, that a not-for-profit corporation would not be in the position to ensure ongoing stability of the usTLD, nor would it have sufficient resources to allow it to be sufficiently innovative and enabling of innovation in the space. As a result, the use of the usTLD likely would remain limited in comparison with the gTLDs and many other ccTLDs in the world. A commercial business, on the other hand, will commit the necessary resources to make the usTLD highly successful. Moreover, the usTLD Administrator will be subject to the oversight of the DOC, and to the possibility of losing the contract if its services do not properly address public concerns. Therefore, a for-profit model offers a superior approach for a successful usTLD.
Another model proposed posits a separate not-for-profit corporation that would serve as the binding policy arm of the usTLD Administrator, and would require definitive subcontract agreement as a condition of the DOC award. The administrator would fully fund the operations of the policy corporation and could reject proposed policy measures only through a binding arbitration. This approach raises numerous concerns including:
NeuStar will implement a policy structure that will address the concerns raised above and ensure independent, open, and unbiased policymaking for the usTLD, but will avoid the concerns raised by these structures. Of course, to the extent that the groups behind these other proposal seek to work with NeuStar after award, or if the DOC determines that one of these approaches to be preferable, NeuStar will explore effective ways of incorporating structure and concepts and addressing policy issues with participation of these important public entities.
B.3-12
The usTLD Policy Council
The centerpiece of NeuStar's outreach and policy plan will be the usTLD Policy Council. The Council will be an advisory body facilitated by NeuStar to ensure representative and unbiased policymaking. The Council's initial primary duties will include:
The functions listed above will be facilitated by the usTLD Administrator as part of its public interest duties to the usTLD community. The Council will operate in a fashion independent of the usTLD Administrator to ensure open and unbiased decision-making. The usTLD must, however, fully execute its DOC delegated obligations and, therefore, will participate on the council as a voting member, as well as work with the Council members to develop an annual Council operating budget.
Drawing on the significant progress that has been made within the ICANN in developing open and transparent consensus policy procedures, NeuStar, has modeled the aforementioned Council procedures after those of ICANN. We believe that not only does this approach provide the usTLD Administrator with a solid process for policy development, it provides significant comfort to the DOC in selecting such a structure given that it has already approved this procedural structure for ICANN, thus all parties interested in the development of usTLD policy will have a familiar mechanism to which to turn.
Thus, NeuStar will accept the policy recommendations of the usTLD Policy Council if NeuStar finds that the recommended policy (1) furthers the purposes of, and is in the best interest of the usTLD; and (2) was arrived at through fair and open processes. If NeuStar declines to accept any recommendation of the Council, it shall return the recommendation to the Council for further consideration, along with a statement of the reasons it declines to accept the recommendation. If, after reasonable efforts, NeuStar does not receive a recommendation from the Council that it finds meets the standards above, NeuStar may initiate, amend or modify and then approve a specific policy recommendation. Nothing in this paragraph, however, is intended to limit the powers of the NeuStar to act on matters not within the scope of primary responsibility of the Council or to take actions that the NeuStar finds are necessary or appropriate to further the purposes of the usTLD.
B.3-13
A critical aspect of ensuring the effectiveness and representativeness of the Council will be its selection. To facilitate its early start of operations, NeuStar will select, in consultation with appropriate stakeholders, an initial set of council members. The first obligation of the initial council will be the implementation of a mechanism for nomination and election of the entire board. They also will be responsible for determining the details of board appointment, such as term and constituencies represented (the initial council members receive one-year terms). This approach will result in a neutral, expert board to address the ongoing policy development for the usTLD.
NeuStar expects that the Council will consist of 9 to 12 members each representing a different constituency or group of stakeholders in the usTLD community. The size of the Council could be expanded in the future as necessary. Although the initial board will establish the process for determining the complete list of constituencies, NeuStar believes that a first list must include:
Some or all of the potential representation issues can be dealt with by reserving places for organizations that themselves are broadly representative of user and public interests (e.g., National Governors Association, the National League of Cities, the American Library Association, consumer advocacy groups, to name only a few).
Outreach Activities
As discussed above, the Council will be a focal point for many of the outreach activities of the usTLD. In that role, the Council will be responsible for developing and enhancing the primary policy outreach activities of the usTLD Administrator. However, a number of activities already are planned by NeuStar should it be awarded administration of the usTLD.
In addition to these activities, during the first six months of NeuStar's operation of the usTLD, it will be in constant contact with the delegated manager and locality-based user community in developing the required report to the DOC. NeuStar also will continue its public awareness activities as discussed in Section B.2.8.
B.3-14
Data Rights and Use Policy
NeuStar, as a trusted neutral third-party registry, must maintain the trust of the registrars and delegated managers, as well as the end users of the usTLD. Therefore, NeuStar recognizes that the data provided by usTLD Registrars and delegated managers belong exclusively to the usTLD Registrars and delegated managers, respectively. NeuStar will not use the data obtained from registrars and delegated managers, other than for purposes of providing usTLD services and as set forth in the Registry-Registrar Agreement.
Whois Policy
According to the Intellectual Property Constituency of the Domain Name Supporting Organization of ICANN, "Reliable, current, and multi-faceted Whois sites that allow accurate and full-featured searching across all registries and registrars will help ensure the protection of copyrights and trademarks in cyberspace, as well as simultaneously protect the interests of consumers who use the Internet to make important purchasing decisions." See Matters Related to Whois, http://ipc.songbird.com/whois_paper.html. A Whois search allows copyright owners to identify the site operator and/or the Internet service provider that is hosting potentially infringing materials or transmitting the infringing activities in order to identify online infringers for enforcement or licensing purposes. Trademark owners undertake Whois searches in an attempt to avoid possible conflicts, as well as to cure unauthorized and confusing uses of their mark.
In addition, Whois is a useful tool for consumers seeking to identify online merchants, the source of unsolicited e-mail, and so forth. Finally, many law enforcement agencies, including the Federal Bureau of Investigations, state and local police departments, and public safety watch groups including the Center for Missing Children also rely heavily on the publicly-available Whois database to prevent and apprehend criminal behavior.
NeuStar recognizes, however, that unfettered access to public Whois information also raises a number of significant privacy concerns, not the least of which is the ease with which this often-personal information can be obtained. In addition, some believe that the current state of privacy protections with respect to the Whois database essentially eliminates the ability of Internet users to anonymously register domain names. Finally, many people who register domain names, especially those who register domain names for noncommercial or personal purposes, are unaware that their home address and phone number will immediately become available to any Internet user in the world.
NeuStar understands that ICANN and the Domain Name Supporting Organization are currently addressing issues surrounding the Whois database and its use by the Internet Community. NeuStar will closely monitor the activities of the DNSO and ICANN as well as initiate its own analysis of the issues through the Council, as set forth above.
NeuStar's Whois Service
NeuStar's Whois service, modeled in part after a Whois solution that has been adopted by ICANN and has gained acceptance with the Internet community, will provide a central, openly accessible system for information regarding a particular domain name registration in the usTLD. This centralized "thick" Whois repository for the Whois information will be designed for robustness, availability, and performance.
In designing the Whois service for the usTLD, NeuStar reviewed current approaches to the service offered by other ccTLD administrators as well as by the various gTLD operators. NeuStar believes that aspects of the current approach offered by the.name gTLD balances both the need for easy access to the Whois database by legitimate users, including intellectual property owners, law enforcement, and
B.3-15
consumer organizations, but also takes into consideration relevant privacy concerns of those whose information is contained within the Whois database.
The usTLD Administrator will make available both a web-based and Port 43 Whois interface on its web site which can also be linked to by each usTLD Registrar that is a party to a Registry-Registrar Agreement with NeuStar. The information available in the Whois database will be returned as a result of a query.
As required in the RFQ, NeuStar's Whois database will allow for multiple string and field searching through a free, public, web-based interface. Although NeuStar's system will be engineered to handle high transaction loads, unreasonable levels of traffic resulting from "data mining" activities common on the Internet could hamper public availability and quality of Whois services. Therefore, this interface will provide up to seventy-five (75) responses to any given query. Recognizing that many users, including law enforcement and intellectual property owners, have a legitimate need for more robust searching capabilities, NeuStar also will provide a Whois-like directory service that will provide responses to queries in excess of seventy-five and will permit sub-string (wildcard) and more advanced Boolean searching.
The Whois Report
The Whois report shall contain the following information:
Whois service will be subject to certain terms and conditions. The additional terms and conditions are intended to prevent the unauthorized use of Whois information for purposes such as unsolicited marketing, e-mail (spamming), and other unlawful purposes.
When requesting the Whois report, the requestor must provide the following information:
B.3-16
Data collected from or about requestors will be used only to document the request and will not be used for any commercial purpose whatsoever.
NeuStar will reserve the right to prevent access to the Whois service to any individual, entity, or organization that it has reason to believe has violated the above terms and conditions of the Whois service.
Enforcement of Accurate Contact and Whois Information
Section 3.7.7 of the draft Registrar Accreditation Agreement provides in pertinent part that a Registrar shall require all registrants to enter into a registration agreement with a registrar including at least the following provisions:
3.7.7.1 [Registrant] shall provide to Registrar accurate and reliable contact details and promptly correct and update them during the term of the [Registrant] registration, including: the full name, postal address, e-mail address, voice telephone number, and fax number if available of the [Registrant]; name of authorized person for contact purposes in the case of an [Registrant] that is an organization, association, or corporation; and the data elements listed in Subsections 3.3.1.2, 3.3.1.7 and 3.3.1.8.
3.7.7.2 A [Registrant]'s willful or grossly negligent provision of inaccurate or unreliable information, its willful or grossly negligent failure promptly to update information provided to Registrar, or its failure to respond for over fifteen (15) calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the [Registrant]'s registration shall constitute a material breach of the [Registrant]'s Registration Agreement with the registrar and be a basis for cancellation of the [Registrant] registration.
Although this requirement has been in ICANN's Accreditation Agreement for Registrars in the .com, .net and .org TLDs since 1998, historically, the registrar community has largely ignored these provisions. As a result, this has led to an increase in inaccurate, false or out of date information in the Whois database.
NeuStar, as the administrator for the usTLD, will adopt additional provisions in both the Accreditation Agreement, the Registry-Registrar Agreement, and the Delegated Manager Agreement that would ensure that registrars and delegated managers take affirmative steps to enforce its agreements with its own registrants. For Example, NeuStar will require that registrars accept written complaints from third parties regarding false and/or inaccurate Whois data of domain name registrants. No later than thirty (30) days after receipt of a written complaint, the registrar shall be required to conduct an initial investigation into the accuracy of the Whois contact information. If the registrar determines that the information is either false, inaccurate or not up to date, the registrar will be required to issue a notice to the registrant stating that it believes that the information contained in the registrant's Whois record may be false, inaccurate or not up to date. The registrant shall be required to update its contact information no later than thirty (30) calendar days of the date of such notice. If, within thirty (30) days, the registrant can either (i) show that it has not provided false or inaccurate contact information or (ii) provide the updated Whois information, then the registrant will be allowed to maintain its usTLD domain name registration. If, however, after thirty (30) days, the registrant either does not respond to the registrar's notice or is unable to provide true and accurate contact
B.3-17
information, the registrant shall be deemed to have breached its registration agreement and the registrar shall be required to delete the registration. The registrar shall not be required to refund any fees paid by the registrant if the registrar terminates a registrant's registration agreement due to its enforcement of this provision.
Reserved Names Policy
Consistent with existing policies and subject to approval by the DOC, NeuStar, as the usTLD Administrator proposes to reserve from registration by the general public certain second level domain names. The reservation of such names will be made to prevent their improper use in the marketplace and/or to permit the usTLD Administrator to introduce important new services and enhancements to the usTLD. Moreover, responsible management of some of the listed names will maximize utility of these second level domains and can uniquely serve the public interest if administered by a responsible party.
The draft list that follows is intended to be illustrative rather than definitive. NeuStar will work collaboratively with DOC and the Council to finalize a list that will responsively preserve second level names in order to: prevent confusion; serve a public need; prevent theft of phone numbers, social security numbers and zip codes, and/or represent possible future enhancement of the usTLD space. Once a proposed definitive list is developed, it will be submitted to the DOC for approval.
All single-character labels
All two-character ISO 3166 country codes or United States Postal codes in addition to the state codes already reserved, shall be initially reserved to avoid conflict with the other country codes and the states.
Names and abbreviations for federal government agencies and divisions (e.g., Department of Commerce, army, navy, air force, DOC, DOD, NTIA).
All numbers five digits or greater and all numbers in the form, five digits-four digits
iana | ||
dnso |
iana-servers |
|
Icann |
iesg |
|
internic |
ietf |
|
pso |
irtf |
|
afrinic |
istf |
|
Apnic |
lacnic |
|
arin |
latnic |
|
example |
rfc-editor |
|
gtld-servers |
ripe |
|
Iab |
root servers |
|
Pro |
nic |
|
aero |
whois |
|
arpa |
www |
|
biz |
kids |
|
B.3-18
com |
xxx |
|
coop |
park |
|
edu |
zip |
|
gov |
geo |
|
info |
locate |
|
int |
scholarship |
|
mil |
whitehouse |
|
museum |
veterans |
|
name |
library |
|
net |
school |
|
org |
911 |
usTLD Dispute-Resolution Policies
General Information
All usTLD Accredited Registrars in the usTLD shall follow the usTLD Dispute Resolution Policy (referred to as the "USDRP"). The USDRP, is incorporated by reference into all usTLD Registration Agreements, and sets forth the terms and conditions in connection with a dispute relating to alleged bad faith domain name registrations as well as violations of the United States Nexus Requirement.
To invoke the policy, a trademark owner should either (a) file a complaint in a court of proper jurisdiction against the domain name holder (or where appropriate an in-rem action concerning the domain name) or (b) in cases of abusive registration submit a complaint to an approved dispute-resolution service provider (see below for a list and links).
Principal Documents
The following documents provide details:
B.3-19
NOTE: This policy is between the usTLD Registrar and its customer (the domain name holder or registrant). Thus, the policy uses "we" and "our" to refer to the registrar and it uses "you" and "your" to refer to the domain name holder.
usTLD Dispute Resolution Policy
(As Approved by the United States Department of Commerce on , 2001)
We may also cancel, transfer or otherwise make changes to a domain name registration in accordance with the terms of your Registration Agreement or other legal requirements.
B.3-20
In the administrative proceeding, the complainant must prove that each of these three elements is present.
B.3-21
B.3-22
as a party in any such proceeding, we reserve the right to raise any and all defenses deemed appropriate, and to take any other action necessary to defend ourselves.
8. Transfers During a Dispute
B.3-23
Rules for Uniform Domain Name
Dispute Resolution Policy
(the "Rules")
(As Approved by DOC on , 2001)
Administrative proceedings for the resolution of disputes under the Uniform Dispute Resolution Policy adopted by DOC shall be governed by these Rules and also the Supplemental Rules of the Provider administering the proceedings, as posted on its web site.
1. Definitions
In these Rules:
Complainant means the party initiating a complaint concerning a domain name registration.
DOC refers to the United States Department of Commerce.
Mutual Jurisdiction means a court jurisdiction at the location of either (a) the principal office of the Registrar of the domain name in question, or (b) the domain name holder's address as shown for the registration of the domain name in Registrar's Whois database at the time a complaint is submitted to a Provider.
Panel means an administrative panel appointed by a Provider to decide a complaint concerning a domain name registration.
Panelist means an individual appointed by a Provider to be a member of a Panel.
Party means a Complainant or a Respondent.
Policy means the usTLD Dispute Resolution Policy that is incorporated by reference and made a part of the Registration Agreement.
Provider means a dispute-resolution service provider approved by DOC. A list of such Providers appears at .
Registrar means the entity with which the Respondent has registered a domain name that is the subject of a complaint.
Registration Agreement means the agreement between a Registrar and a domain name holder.
Respondent means the holder of a domain name registration against which a complaint is initiated.
Reverse Domain Name Hijacking means using the Policy in bad faith to attempt to deprive a registered domain name holder of a domain name.
Supplemental Rules means the rules adopted by the Provider administering a proceeding to supplement these Rules. Supplemental Rules shall not be inconsistent with the Policy or these Rules and shall cover such topics as fees, word and page limits and guidelines, the means for communicating with the Provider and the Panel, and the form of cover sheets.
2. Communications
B.3-24
3. The Complaint
B.3-25
(The description should, for elements (2) and (3), discuss any aspects of Paragraphs 4(b) and 4(c) of the Policy that are applicable. The description shall comply with any word or page limit set forth in the Provider's Supplemental Rules.);
B.3-26
"Complainant agrees that its claims and remedies concerning the registration of the domain name, the dispute, or the dispute's resolution shall be solely against the domain name holder and waives all such claims and remedies against (a) the dispute-resolution provider and panelists, except in the case of deliberate wrongdoing, (b) the registrar, (c) the registry administrator, and (d) the Department of Commerce, as well as their directors, officers, employees, and agents."
"Complainant certifies that the information contained in this Complaint is to the best of Complainant's knowledge complete and accurate, that this Complaint is not being presented for any improper purpose, such as to harass, and that the assertions in this Complaint are warranted under these Rules and under applicable law, as it now exists or as it may be extended by a good-faith and reasonable argument."; and
4. Notification of Complaint
5. The Response
B.3-27
"Respondent certifies that the information contained in this Response is to the best of Respondent's knowledge complete and accurate, that this Response is not being presented for any improper purpose, such as to harass, and that the assertions in this Response are warranted under these Rules and under applicable law, as it now exists or as it may be extended by a good-faith and reasonable argument."; and
B.3-28
6. Appointment of the Panel and Timing of Decision
10. General Powers of the Panel
B.3-29
11. Language of Proceedings
14. Default
15. Panel Decisions
B.3-30
Paragraph 4(a) of the Policy, it shall so state. If after considering the submissions the Panel finds that the complaint was brought in bad faith, for example in an attempt at Reverse Domain Name Hijacking or was brought primarily to harass the domain name holder, the Panel shall declare in its decision that the complaint was brought in bad faith and constitutes an abuse of the administrative proceeding.
16. Communication of Decision to Parties
17. Settlement or Other Grounds for Termination
18. Effect of Court Proceedings
19. Fees
B.3-31
B.3-32
B.4 Locality-Based usTLD Structure Functions
NeuStar's modernized functions for the locality-based usTLD namespace will support the current delegated managers and registrants, and encourage new registrations in the namespace.
Although the usTLD locality space is currently underutilized and undervalued, it remains a valuable space, with existing delegated managers and registrants who appreciate its hierarchical structure. A goal of modernizing the usTLD infrastructure cannot lie only in plans to allow registrations in an expanded space; it must also accommodate the existing locality space. Similarly, simply keeping the locality space as is, without modernizing its infrastructure or examining policies for improvements, is a disservice to the users of that space.
NeuStar's approach to developing and implementing a usTLD infrastructure is inclusive. Our current understanding of the locality space will be augmented when we reach out to delegated managers and to registrants for their input. Our services provided in the locality space, to registrants and to delegated managers, will be equal to those services offered in the expanded space. Our customers are important to us, and our diminishing those services for any subset of our customers would be contrary to our philosophy of equitable treatment and integrity.
The locality-based usTLD structure functions highlighted below and in Sections B.4.1 through B.4.7 include all of the requirements listed in RFQ Section B.4. In each case, although the specific needs of customers in the locality space have been kept in mind, our solution is as rich in functionality as the comparable function in the expanded space.
Existing Delegees and Registrants Service Provision—NeuStar will provide an implementation of the usTLD consistent with the policies and philosophy embodied in RFC 1480 and the other usTLD policy documents. This implementation will be supplemented by our Centralized usTLD Database, a centralized Whois, Delegee Whois and automatic registration services to replace the current manual process.
Undelegated Third Level Subdomains Service Provision—NeuStar will provide registrar services for undelegated third-level subdomains in the locality space through the use of our Enhanced Shared Registry System (SRS), the same system that will be used by registrars in the expanded space.
Locality-Based Process Modernization—NeuStar will modernize the processes used in the locality space by leveraging our Enhanced SRS and Centralized usTLD Database, by automating registrations, and by implementing an automated update process and a modernized zone file update process.
Current Locality-Based usTLD Users Coordination—NeuStar will establish target communications mechanisms, including e-mail listservs, chat services, and other Internet-based services, as well as traditional customer outreach mechanisms, such as user group meetings, user support representatives, and other support services to maintain close relationships with usTLD stakeholders.
Compliance with Current Locality-Based usTLD Policies Investigation and Report—NeuStar will approach our compliance investigation as a means of forming partnerships with the Delegated Managers, i.e., delegees and subdelegees in the locality space. We view this report as a means of not only discovering problems in the locality space, but also of collaborating with Delegated Managers to improve the overall utility of the namespace.
B.4-1
usTLD Delegated Manager Database Development—NeuStar's database of Delegated Manager information will ensure that all delegee and subdelegee contact information and delegation information is kept up to date, so that both the registry can contact these Delegated Managers to resolve issues, and so that registrants can contact these Delegated Managers to register in the locality space.
Whois Database Development—NeuStar's centralized enhanced Whois database will accommodate Web-based, free, public searches for registrant and delegated manager contact information and will ensure the accuracy of data throughout the locality space.
The functions presented in this section will enhance the utility of the locality space and make the namespace more attractive to registrants who wish to register a domain name based in the geographic hierarchy. By centralizing our services and automating the registration process, we will provide our customers with a stable registry environment and easy-to-use services as good as or better than those offered by any other top-level domain registry.
B.4.1 Existing Delegees and Registrants Service Provision
Existing delegees and registrants in the usTLD rely on the services that the usTLD infrastructure provides. However, that current infrastructure has not evolved along with other leading Internet registries. Currently, the registration process currently is manual, the zone data update process is batch oriented, and the basic usTLD policies are not even available in a single coherent document.
It is unfortunate that the current implementations are now outdated. The lag behind modern implementations causes potential users to question the value of acquiring or maintaining names in the US domain name space. NeuStar proposes significant improvements that will benefit the existing users of the usTLD. We intend to make the usTLD a world renown ccTLD. We intend to provide services and support that improves on current practice and complies with existing policies (including RFC 1480 and Web pages on www.nic.us that take precedence). We intend to enhance the value of domain names held by existing delegees and registrants.
As proposed by NeuStar, the usTLD will have a robust, secure, and reliable infrastructure equal to or better than any Internet registry. The registration process will be streamlined so that users can check, add, modify, or delete names over an easy to access, simple to use web interface. All pertinent data related to name registrations will be maintained in a centralized data base at the registry. NeuStar will provide tools to delegees and subdelegees to simplify the process of inputting data into the Centralized usTLD Database. Zone file data will be updated from the database and propagated to nameservers in near real time. Whois data for all name holders (name holder refers collectively to delegees, subdelegees and registrants) will be available free through a public, web-based interface, and the Whois DB will allow for multiple string and field searches.
The existing delegees and registrants in the US domain will then be provided the service and support that they are entitled to expect. NeuStar will provide these services using robust and reliable systems designed to support the use of the usTLD by the Internet community of the United States.
B.4.1.1 Needs of Existing Users
The continued operation and support of the locality based usTLD is a fundamental concern to its users and an essential set of functions for the Internet community of the United States. For existing delegees and registrants, NeuStar proposes to provide service and support that will enhance the value of the names they hold in the US domain.
Current name holders want the capability to check, add, modify, or delete their data. They want DNS nameservers to have current zone file data, and they want their Whois data to be accurate and timely. In addition, users need to rely on a robust, reliable, and secure infrastructure that will be able to satisfy their expected future needs as well as their current ones.
B.4-2
NeuStar plans to implement an infrastructure designed to meet users' needs. This will include the following:
In addition, as described elsewhere in this proposal, NeuStar's facilities will be based on high availability, reliable platforms, and users (Section O.1) will have access to a range of technical and customer support services (Section B.2). NeuStar will provide clear and current guidance on the applicable policies (Section B.3). The needs of the existing delegees and registrants will be met by this approach.
B.4.1.2 Implementing Services for Delegees
In the existing locality-based name space, delegees support the fabric of the US domain. These delegees are responsible for the technical operation of nameservers for the zone names they hold, and they are responsible for administering the names in that branch of the name space. RFC 1480 speaks clearly to the degree of responsibility and commitment involved. In addition to the technical and operational aspects, as indicated by the following:
The designated manager must do a satisfactory job of operating the DNS service for the domain. That is, the actual management of the assigning of domain names, delegating subdomains and operating name servers must be done with technical competence. This includes keeping the US Domain Administrator or other higher-level domain managers advised of the status of the domain, responding to requests in a timely manner, and operating the database with accuracy, robustness, and resilience.
That RFC also conveys the administrative context of delegation:
The major concern in selecting a designated manager for a domain is that it be able to carry out the necessary responsibilities, and have the ability to do an equitable, just, honest, and competent job. The key requirement is that for each domain there be a designated manager for supervising that domain's name space. These designated authorities are trustees for the delegated domain, and have a duty to serve the community. The designated manager is the trustee of the domain for the domain itself and the global Internet community.
In that spirit, NeuStar plans to provide an implementation of the usTLD consistent with the policies and philosophy embodied in RFC 1480 and the other usTLD policy documents (e.g., as posted on www.nic.us). The major features that will provide service and support are described in Sections B, F, and O in this proposal, and include:
B.4.1.3 Providing Support for Registrants
In the existing locality-based name space, registrants are offered an alternative to running their own name servers, since delegation entails its own burdens of responsibility and costs. Instead, registrants' data is directly entered in the US domain, meaning that the zone data files on the usTLD name servers themselves have the name holders' information.
B.4-3
Direct registration provides name service support to a wider population of users by relieving them of administrative and technical requirements that come with delegation. As described later in this proposal, the usTLD registry will be able to perform registry and registrar functions on behalf of such registrants.
Registrants, too, will enjoy the benefit from the same services and support indicated above for delegees in the existing locality-based space, including secure website, centralized database, near real time updates, and other features provided for name holders in the usTLD.
B.4.2 Undelegated Third Level Sub-domains Service Provision
Undelegated sub-domains have been situated as a middle ground that offers name registration without requiring name server operation. The name servers for names in undelegated sub-domains are in fact the usTLD's name servers, and the name holders' data is kept in the main usTLD database and zone files.
The Statement of Work (SOW) requires that the usTLD Administrator provide registry and registrar services for name holders in undelegated third level locality sub-domains and others.
B.4-4
According to the official US Domain Registry's Web site (www.nic.us), that set of undelegated domains has the following structure:
Name Structures—usTLD Locality-Based
City Government: | <dept-name> | . | CI | . | <locality> | . | <state-code> | . | US | |||||||||
County Government: |
<dept-name> |
.. |
CO |
.. |
<locality> |
.. |
<state-code> |
.. |
US |
|||||||||
Parish Government: |
<dept-name> |
.. |
PARISH |
.. |
<locality> |
.. |
<state-code> |
.. |
US |
|||||||||
Town Government: |
<dept-name> |
.. |
TOWN |
.. |
<locality> |
.. |
<state-code> |
.. |
US |
|||||||||
Township: |
<dept-name> |
.. |
TOWNSHIP |
.. |
<locality> |
.. |
<state-code> |
.. |
US |
|||||||||
Township (option): |
<dept-name> |
.. |
TWP |
.. |
<locality> |
.. |
<state-code> |
.. |
US |
|||||||||
Borough Government: |
<dept-name> |
.. |
BOROUGH |
.. |
<locality> |
.. |
<state-code> |
.. |
US |
|||||||||
Village Government: |
<dept-name> |
.. |
VILLAGE |
.. |
<locality> |
.. |
<state-code> |
.. |
US |
|||||||||
Village (option): |
<dept-name> |
.. |
VIL |
.. |
<locality> |
.. |
<state-code> |
.. |
US |
|||||||||
Schools K12 District: |
<school-district> |
.. |
K12 |
.. |
<state-code> |
.. |
US |
|||||||||||
K12 School: |
<school> |
.. |
<school-district> |
.. |
K12 |
.. |
<state-code> |
.. |
US |
|||||||||
Private School: |
<school> |
.. |
PVT |
.. |
K12 |
.. |
<state-code> |
.. |
US |
|||||||||
Community College: |
<school> |
.. |
CC |
.. |
<state-code> |
.. |
US |
|||||||||||
Technical School: |
<school> |
.. |
TEC |
.. |
<state-code> |
.. |
US |
|||||||||||
Councils of Government: |
<org-name> |
.. |
COG |
.. |
<state-code> |
.. |
US |
|||||||||||
District: |
<org-name> |
.. |
DST |
.. |
<state-code> |
.. |
US |
|||||||||||
Library: |
<library-name> |
.. |
LIB |
.. |
<state-code> |
.. |
US |
|||||||||||
Museum: |
<org-name> |
.. |
MUS |
.. |
<state-code> |
.. |
US |
|||||||||||
State Government: |
<state-agency> |
.. |
STATE |
.. |
<state-code> |
.. |
US |
|||||||||||
Statewide Non-Profit: |
<org-name> |
.. |
GEN |
.. |
<state-code> |
.. |
US |
In order to satisfy these requirements, the needs of the name holders in these domains include not only those of direct registrants, but also those analogous to certain capabilities available to delegees and subdelegees. The problem is that there is no delegee for the undelegated domains. The solution is to provide the functions of registry and registrar, on behalf of those domains, for name holders who are direct registrants of undelegated domains.
The usTLD functions will already include those of usTLD Administrator, for all users, and as name server operators and name space administrators for the undelegated third level sub-domains. In addition to those, NeuStar proposes to provide the functions of registrar, on behalf of an undelegated sub-domain and its direct registrants, and of registry, to include that registrar in the Enhanced SRS.
The direct registrants in undelegated sub-domains of the US domain will then be provided the service and support that they are entitled to expect. NeuStar will provide these services using robust and reliable systems designed to support the use of the usTLD by the Internet community of the United States.
B.4-5
B.4.2.1 Additional Needs of Undelegated Domains
Undelegated domains, by definition, have no official delegee to whom the domain is delegated. Registrants in such a domain must rely on the usTLD itself to operate name servers, store data for the zone files, and administer that portion of the name space. There are two different roles for the usTLD Registry to perform, depending on the particular domain, namely:
but also including:
As described elsewhere in this proposal, NeuStar's facilities will be based on high availability, reliable platforms (Section O), and users will have access to a range of technical and customer support services (Section B.2). NeuStar will provide clear and current guidance on the applicable policies. The needs of the name holders in requisite undelegated sub-domains will be met by this approach.
B.4.2.2 Implementing Registrar Services
NeuStar will provide registrar services on behalf of undelegated sub-domains through a process analogous to that for competitive registrars wishing to interconnect with the Enhanced Shared Registry System (SRS) for the usTLD. NeuStar is developing this Enhanced SRS as part of its planned modernized registry infrastructure. Registrar functions will be developed to support NeuStar's capability to act as a registrar on behalf of an undelegated sub-domain in the locality-based name space. The term SRS refers to a system that has a mechanized interface to multiple registrars, which provides the same service to all of the interconnected registrars.
The process of acting as a registrar requires that the registrar functions, along with the relevant terms and conditions, satisfy all appropriate requirements for competitive registrars who wish to interconnect with the SRS for the usTLD domain. This formal approach will provide both the services and the safeguards that are needed for NeuStar to act as a registrar.
In NeuStar's role as registrar for an undelegated sub-domain, it acts on behalf of the name holders who are direct registrants in the locality-based name space and who wish to have NeuStar perform the registrar function. In this role, registrants will register names at a website provided by NeuStar. This will be very similar to the way registrants register names with registrars in gTLDs such as.biz. NeuStar will provide each registrant with authenticating information that will need to be submitted for future changes and updates. This will ensure that it is the appropriate registrant modifying the name.
Just like in the expanded space, NeuStar will gather information about the registrant to populate the Central usTLD Database, create a Whois record, and update the zone file. In addition NeuStar needs to clear the payment and register the registrant in NeuStar's Registrant Database. There is a clear difference between managing a name for a registrar and managing a name for a registrant. NeuStar understands the importance of treating these two types of registrations differently.
B.4-6
B.4.2.3 Providing Registry Services
NeuStar will provide registry services on behalf of undelegated sub-domains through the use of our Enhanced SRS that is being developed to include NeuStar's capability to act as a registrar on behalf of an undelegated sub-domain in the locality-based name space.
The following briefly describes some of the registry functionality and support proposed by NeuStar. Details are contained in Sections F and O this proposal.
NeuStar understands the range of roles, the services and the safeguards, that are required to satisfy the needs of name holders in the usTLD. Our implementation and operation will enhance the value of the names of name holders who actually are the usTLD.
B.4.3 Locality-Based Process Modernization
NeuStar's automated registration process, Centralized Database, and Enhanced Shared Registration System (SRS) will modernize the usTLD registry and encourage new registrations in the locality space.
Under the current usTLD administration, all registration and update processes within the registry are done manually. Although requests for registrations are received over a Web interface, this interface does not interact with a registration system. It simply sends a message to a person who then checks to see if the name is available, if the forms are filled out correctly, and if the registrant has met the appropriate requirements. The information is then manually added to a list of names and to the zone file, and a new zone file is created and sent to the nameservers, where it writes over the old zone file.
This process was implemented for registrations from delegated managers, that is, delegees and subdelegees, and for direct registrations with the registry. If a registrant wants to register with a delegated manager, the registration process depends on the specific delegated manager. There are no standard requirements for how or where delegated managers store information or how they update zone files, and there are very few requirements for how they maintain and manage their nameservers.
NeuStar will make vast improvements in the operations of the registry itself. NeuStar will implement an automated registration process, a Centralized usTLD Database, a Centralized Whois, an automated update process, and a modernized zone file update process. All system software and databases will be backed up daily, and the tapes will be stored off-site. As required, historical files and data will be escrowed with an escrow agent.
NeuStar's Enhanced SRS will be available to all delegated managers via secure web access. Under this new system, changes made by the delegated manager will be implemented directly into the registry systems, eliminating all manual processes associated with a registration. Changes to the Centralized usTLD Database will be made in real-time, and updates to the Whois and the zone file (if necessary) will be done in near-real time, that is, in intervals of no more than 15 minutes. A name will go from registration to live in 15 minutes or less, whereas today it can take weeks.
NeuStar will utilize its state-of-the-art Network Operation Center (NOC) to monitor the Enhanced SRS and its subsystems, including the Centralized usTLD Database and Whois, as well as the constellation of nameservers, on a 24-hour basis 365 days per year. The NOC will not only monitor for
B.4-7
failures but also will monitor the systems and network for degraded service that may indicate that a failure is about to happen.
NeuStar will implement billing systems to accommodate both debit accounts and credit cards. This will allow instantaneous registrations. In addition, we will utilize our customer resource management system that allows for trouble ticket management and customer contact tracking, among other capabilities.
A more detailed description of the ancilliary services provided by NeuStar to the locality space, e.g., customer service, tech support, software, is provided in Sections B.2.9 to B.2.16.
A more detailed description of the Enhanced SRS and the Centralized usTLD Database is provided in Section F of this proposal.
Section O of this proposal provides a detailed description of the systems, software, and functional capabilities that NeuStar will deploy to modernize the usTLD registry for the locality name space.
B.4.4 Current Locality-Based usTLD Users Coordination
NeuStar will develop user-friendly, effective mechanisms to encourage and coordinate the contributions of the current locality-based usTLD stakeholders.
NeuStar is acutely aware that as a result of the comparative complexity of the namespace and the lack of coordination and marketing for the usTLD, the locality-based usTLD has not attracted a high level of domain name registration activity and remains underpopulated in comparison with other ccTLDs. Although the existing administrator has established basic policies and procedures for the TLD, little has been done to enforce such policies and procedures nor has any effort been made to analyze compliance by delegated managers or the value of the namespace to its users. Moreover, virtually no effort has been made to reach out to users and stakeholders to further develop and improve the space.
NeuStar has a strong legacy of coordinating complex groups of users in the industries that it serves. Successful administration of public resources, whether they are telephone numbers or domain names, requires strong awareness of constituencies and their needs. NeuStar intends to establish target communications mechanisms, including e-mail listservs, chat services, and other Internet-based services. In addition, NeuStar will utilize traditional customer outreach, such as user group meetings, user support representatives, and other support services to maintain close relationships with usTLD stakeholders. These forums will be tailored to allow stakeholders to discuss usTLD administrative, technical, and policy issues related to the operation and management of the locality-based usTLD structure. This will ensure that, going forward with improvements in the overall space, the current users have a "voice" and stake in the future success and increased utility of the usTLD.
To begin this process, NeuStar will leverage the six-month compliance report process, discussed in detail below in Section B.4.5, to develop a strong understanding of stakeholder desires and concerns and to identify the best way to communicate with each constituency group.
Coordination of all usTLD outreach will ultimately be coordinated and developed under the auspices of the usTLD Policy Council. This council will be very important to the ongoing development of usTLD policy and public outreach. The structure and duties of this council, as well as the detailed outline of our basic outreach plan, are discussed in detail in Section B.3.5.
B.4.5 Compliance with Current Locality-Based usTLD Policies Investigation and Report
NeuStar's approach to the Compliance Investigation and Report will forge good relations with locality delegees while solving many of the problems that plague the current locality space.
B.4-8
In its request for an immediate investigation of policy compliance in the usTLD locality space, the DOC is sending a strong message about the current state of this space. Delegating portions of localities within the usTLD hierarchy began as a logical method of maintaining the space and encouraging individuals within those physical localities to register domain names. However, noncompliance by some delegees and specifically the problem of "locality squatting," have caused stagnation in registrations and have done little to promote the public interest aspect of the usTLD.
The problem of locality squatting is prevalent across current locality delegations. According to current policy, for delegations or redelegations made after July 1, 1997, it is assumed that every applicant for the delegation of a locality name has received written authorization from the locality's legitimate government to manage the domain name of that locality. Yet, according to the current list of delegated subdomains and their contacts (available on the current usTLD Web site), approximately 40 percent of the delegated subdomains are held by five individuals. Although a number of delegees who hold multiple locality delegations may be legitimate, that legitimacy is questioned when an individual delegee manages registries for localities in more than 30 states.
This compliance investigation effort is an excellent and necessary first step in improving usTLD operation and use. It will serve as more than just a report on compliance; it will also aid efforts to create a partnership among the usTLD community for achieving stable, consistent service and for pursuing enhancements in the usTLD locality space. Because of the history of usTLD administration, there is little information about current administration and operations. It is essential that a thorough investigation be performed to obtain a baseline for current information about the status of usTLD operations, assess points of satisfaction and dissatisfaction among current delegees and current registrants, and enable NeuStar to provide recommendations to the DOC for improvements by surveying current delegees and current registrants.
Without this report, it will not be possible to ensure consistent and correct administration or operation of locality-based registrations within the usTLD. The existing problems in the space will persist from an unclear, unresolved history with existing usTLD delegees.
Finally, the stated goal for the Compliance activity is to establish a basis for moving to consistent quality of service for usTLD administration. However, investigation would be appropriate even with a flawless history because it permits NeuStar to develop initial channels of communication with the existing usTLD community and to learn what changes and enhancements the community desires. NeuStar anticipates that this investigation and report will be the first step toward codifying new technical and administrative policies and proposing a successor document to RFC 1480.
The Importance of Compliance
The usTLD portion of the DNS is as essential to the infrastructure of the Internet as any other portion of the DNS. Serious use of the Internet requires highly reliable, highly stable, and highly efficient performance of the usTLD domain. Further, registrants and potential registrants in the usTLD must have assurances that they can register within their own localities without encountering resistance or nonresponsiveness from the assigned delegee. To these ends, concerns for locality-space operations divide among:
B.4-9
Ultimately there are four simple and direct needs that require assessment:
NeuStar's Approach
The new administrator of the usTLD domain will have a dual role. Although its main function will be to operate a registry for the usTLD root, it will also be charged with continuing, expanding, and enhancing the usTLD domain. This latter role entails oversight, not just operations and administration.
There are two approaches that a registry can take for oversight of the usTLD. One is top-down and authority-based, primarily entailing issuance of directives and checking for conformance. The alternative is to treat the entire usTLD domain as an activity among partners, all seeking success for the stakeholders and satisfaction among the customers. NeuStar strongly believes that an approach based on partnership will be easier to pursue and much more productive. Ultimately, a service is always collaborative, especially when the effort comprises multiple organizations.
An approach based on partnership would be essential even with a flawless history. The "social" lesson of the Internet is that large-scale, multi-organization efforts must be based on strong, consensus-based collaboration. Use of "authority" must be carefully limited, even to the extent of choosing not to use that authority if it is likely to cause ill will among participants. However, the problematic history of usTLD makes this effort more sensitive and more difficult. We realize that there may be cases where a partnership approach may be unsuccessful, and we stand ready to use a more authoritative approach, only if it becomes necessary.
NeuStar's Investigation Process
In order to conduct this compliance investigation, NeuStar will follow steps that are typical for survey research.
Planning Phase
In order to successfully conduct a compliance investigation and to ensure fairness to all parties, NeuStar will begin by reviewing all relevant documentation, including RFC 1480, the post-1997
B.4-10
agreement with delegees, and any documentation provided to us by delegees. At the same time, NeuStar will request from the current usTLD registry all contact information for current delegees and information on which delegees have signed the post-1997 agreement. This information is of vital importance to conducting a compliance investigation, because delegations or redelegations made beginning in July 1997 follow different guidelines from those delegated before that date.
Once this information is obtained from the current usTLD registry, a letter introducing NeuStar as the new usTLD registry will be sent to all delegees. This letter will be a formal request for registrant and subdelegee data from the delegees and will include a request for a copy of the written authorization to manage the domain for each locality, for delegations or for redelegations made since July 1997. The same letter will be sent to subdelegees to request registrant data under those suddelegations.
From this effort, NeuStar will compile aggregate requirements for delegees, including subdelegees, and registrants and will begin our effort to find legitimate delegees. During this time, we will also select an agency to conduct a compliance survey.
This phase of activity will ensure that the investigation is based on existing history and, to the extent possible, based on the expectations of delegees and registrants.
Design Phase
During the design phase, investigation questionnaires will be formulated for delegees, including subdelegees, and for registrants. The questionnaires will cover the full range of administration and operations topics. Use of professional survey experts will ensure that the research tools employ proper wording to elicit helpful responses and otherwise avoid the serious pitfalls often encountered with surveys developed by nonprofessionals. The surveys produced must be sufficiently open to permit participants to offer unexpected information and suggestions. However, they will also be partially based on information that is already available, so that participants can be assisted with intelligent, directed questions and plausible solutions.
NeuStar expects the survey to produce several types of useful information, including but not limited to:
This feedback will permit NeuStar to pursue a constructive, iterative process for obtaining a cure to problems, while maintaining stable operations.
As noted earlier, it is essential that NeuStar approach the design of this survey as a means of finding ways to help delegees and serve them as customers of the usTLD registry. This approach is in marked contrast to one that could be heavy-handed and oriented towards establishing authority and strictness. Such a heavy-handed approach would be likely to produce poor information and strong resentment. It is expected that delegees will have concerns, and even fears, about the new administrator. NeuStar views it as appropriate and essential to allay those fears through a constructive tone and process.
B.4-11
Execution Phase
This phase is dominated by the mechanics of distributing surveys to delegees and registrants, ensuring they complete the forms, and then obtaining the completed forms for processing. In cases where a delegee is nonresponsive, we will send a second request, followed by an attempt to contact the delegee by another method.
Analysis
Structured portions of the surveys will be straightforward and will produce simple statistics. Open-ended portions of the survey will require the skills of a professional survey researcher to ensure that answers are compiled in an appropriate and useful manner.
Recommendations and Report
Beyond basic data analysis is the step of reducing the analysis to practical suggestions to remedy problems and pursue enhancements of the usTLD locality-space policies. These may include recommendations on:
In addition to presenting recommendations for changes in locality delegations, this report will, as required in RFQ Section B4, present a full evaluation of locality squatting issues. Delegees who have proven their legitimacy by producing the requested letter of authorization will be listed, and carefully recorded information will be presented listing those delegees who contributed to the investigation, as well as those who were nonresponsive to our requests. We believe that our partnership approach to this investigation will encourage participation in our survey, and it is our hope that the vast majority of delegees will be responsive. We further believe that this investigation will serve as an excellent introduction of NeuStar's usTLD operations to current delegees, aid efforts to create partnerships between the TLD and the delegees, and allow NeuStar to discover ways to improve the services offered in the usTLD locality space. Within six months of contract award, we will file our report and recommendations with the DOC and post the report on the usTLD Web site, as required.
B.4.6 usTLD Delegated Manager Database Development
NeuStar's Delegated Manager Database will ensure the accuracy and validity of all data for delegees and subdelegees.
Because of the administrative structure of the usTLD, that is, because there are a vast number of locality delegees and subdelegees (collectively known as delegated managers), NeuStar will develop a database of delegated managers that will be kept accurate and up to date. This will be an integral element of the Centralized usTLD Database that NeuStar will deploy as the usTLD Administrator. To manage a critical public resource like the usTLD, the Administrator needs an accurate database for all entities that have a role in administering the space, and delegated managers play an important role in the functioning of the usTLD localities. Because the usTLD Administrator may need to contact a delegated manager for reasons ranging from network outages to questions from a registrant, it is not
B.4-12
acceptable to have out-of-date contact information that prevents issues from being addressed in a timely manner.
The most critical function with regard to creating the database is obtaining relevant information from the existing delegated managers—NeuStar has performed a similar function before. The task at hand is analogous to NeuStar's undertaking in the transitioning of the North American Numbering Plan to centralized administration. In order to fulfill our duties, NeuStar was required to create a centralized database of telephone number assignments by working with multiple phone companies across the country, most having multiple telephone number administrators. The databases across companies were inconsistent, as were those within companies. NeuStar was able to collect and standardize all of the data, and completed the transition ahead of schedule.
In order to ensure the accuracy and validity of the delegated manager data, NeuStar's Transition Team will reach out to all of the delegees and subdelegees. We will provide them with a list of the data elements we wish to populate, and will provide them with multiple methods of provisioning this data with us. On an ongoing basis, we will provide the delegated managers an easy-to-use web interface to provision new registrations into the Centralized usTLD Database. Alternatively, should they have high volumes of registrations and would prefer a mechanized interface, they may opt to use NeuStar's eXtensible Registry Protocol, or XRP, to interface to the registry.
Information in the Delegated Manager Database will, at a minimum, include the following:
As required the information in NeuStar's usTLD Delegated Manager Database will allow for multiple string and field searches though a free, publicly accessible, Web-based interface.
Detailed descriptions of how the databases will be populated and how they will be kept up to date and accurate are provided in Section F, Centralized usTLD Database and Enhanced Shared Registration System.
Redundant Delegated Manager databases will be located at the geographically diverse, redundant Enhanced SRS Data Centers located in Illinois and Virginia. In accordance with U.S. Nexus requirements, no databases will be located outside of the United States. Both databases will be updated in near real time (intervals of no more than 15 minutes) and will be synchronized.
A detailed description of the technology and operations of the Delegated Manager Database is provided in Sections O.3 and O.9.
B.4-13
B.4.7 Whois Database Development
NeuStar's centralized Whois database will accommodate public searches for registrant and delegated manager contact information and will ensure the accuracy of data throughout the locality space.
The locality-based usTLD space has traditionally had no centralized Whois which makes it difficult to look up contact information for domain name holders, and even for delegees. NeuStar will remedy the current deficiency by developing an enhanced, searchable, accurate, and up-to-date Whois database containing locality-based usTLD registrant information. In fact, this Whois database will be common with the Whois database for the expanded usTLD space.
NeuStar will maintain a Web site that will allow free public, searches of the Whois database, and will also provide a standard port 43 interface. As required by the COTR, the database will allow for multiple string and field searches. These searches will return Whois records that will show a differentiation between a registrant's Whois record and a delegated manager's Whois record. NeuStar will reach out to the existing delegees and subdelegees to populate information on their registrants in the databases.
NeuStar will populate the data pertaining to the existing assignments by reaching out to each of the delegated managers through information provided by the current usTLD Administrator, as well as with contact information contained in existing zone files of the usTLD Administrator and of the delegated managers. At a minimum, NeuStar will collect and update the information described below for each Whois record:
More detailed descriptions of how the databases will be populated, how they will be kept up to date and accurate, and the structure of the Whois responses are provided in Section F, Centralized usTLD Database and Enhanced Shared Registration System. A detailed description of Whois policy is provided in Section B.3.5.
Redundant databases will be located at the geographically diverse, co-active Enhanced SRS Data Centers located in Illinois and Virginia. In accordance with the U.S. Nexus requirement, no registry databases will be located outside of the United States. All databases will be updated in near real time (intervals no greater than 15 minutes) and will be synchronized to ensure consistency of responses.
A more detailed, technical description of the usTLD database is provided in Sections O.3 and O.8.
B.4-14
B.5 Expanded usTLD Space Functions
NeuStar's functions for the expanded usTLD namespace will support an unlimited number of competitive registrars and encourage second-level registrations in the namespace.
Although many users find the current usTLD hierarchical locality space to be valuable, or even essential to their presence on the Internet, the naming structure is generally considered to be cumbersome. Expanding the usTLD space to allow registrations in the second level will encourage more registrations in the namespace, and open the usTLD to registrar competition.
By introducing this new namespace, we also introduce the need for functions related to a registrar community, including a shared registration system and registrar accreditation and certification. Just as we have proposed in the locality namespace, we will leverage our Enhanced Shared Registration System (SRS) and Centralized usTLD Database, and implement an automated update process and a modernized zone file update process for use in the expanded space.
The expanded usTLD functions highlighted below and in Sections B.5.1 through B.5.5 include all of the requirements listed in RFQ Section B.5. In these sections, we emphasize our desire to work with registrars throughout the accreditation and certification process, and our understanding of the need to develop a registry that the Internet community will consider to be valuable and useful.
usTLD Enhanced Shared Registration System—NeuStar will leverage our eXtensible Registry Protocol (XRP) for interfacing registrars to our Enhanced Shared Registration System (SRS). This Enhanced SRS will support an unlimited number of competitive registrars for the expanded name space, and will provide equivalent access to the system for all registrars to register, transfer, and update domain registrations.
Accreditation Process for usTLD Registrars—NeuStar's registrar accreditation process will ensure consistency in quality and service within the usTLD, while at the same time promoting stability and competition for domain name registration services.
usTLD Technical Certification Process—NeuStar's Operational Test and Evaluation (OT&E) process will verify the correct operation and performance of a registrar's client system before access to the live Enhanced SRS is granted. This OT&E Certification will allow NeuStar to maintain the integrity of the usTLD and of the DNS as a whole.
Whois Database Development—NeuStar's centralized Whois database will accommodate Web-based, free, public searches for registrant and registrar contact information and will ensure the accuracy of data in the expanded space, beginning with the very first Whois entry in that space.
Community Outreach Plan—NeuStar will coordinate usTLD public outreach under the auspices of the usTLD Policy Council, which will be very important to the ongoing development of usTLD policy and public outreach.
Expanding the usTLD namespace will be one of the biggest steps in achieving the goal of increasing registrations and promoting competition in the space. Furthermore, the expansion of the
B.5-1
usTLD space affords NeuStar the unique opportunity to centralize all data and information from the inception of the new space. Whereas centralizing this information in the locality space must be done by reaching out to existing delegated managers, all information in the expanded space will be centralized from the beginning, ensuring that all Whois and zone file information has the highest possible levels of accuracy and integrity.
B.5.1 usTLD Enhanced Shared Registration System
NeuStar will develop and implement an Enhanced Shared Registration System (SRS) that will support an unlimited number of competitive registrars for the expanded name space. As required, this enhanced SRS will provide equivalent access to the system for all registrars to register, transfer, and update domain registrations.
NeuStar's Enhanced SRS will be developed according to a three-level architecture: protocol servers, application servers, and database servers (the Centralized usTLD Database). Exhibit B.5-1 displays a high-level view of this Enhanced SRS architecture. Registrars will interface to the registry over the Internet to the protocol servers located at redundant data centers in Illinois and Virginia. Registrars will be able to interface with either data center, and in the unlikely event of an outage to one data center, registrars will still be able to interface to the other. This redundancy ensures that the Centralized usTLD Database will always be available for handling queries, registrations, and modifications.
Protocol servers will authenticate registrars based on authentication information provided by the registry. For each registrar, a profile will dictate the access rights that will be provided. This ensures that one registrar will not be allowed to view customer-sensitive information for any other registrar or to modify registration data for another registrar's registrant.
NeuStar's protocol for interfacing registrars to a registry, called XRP (eXtensible Registry Protocol) has been developed and is currently being deployed for the .biz registry. XRP is based on two very important Internet protocols, eXtensible Markup Language (XML) and Blocks Extensible Exchange Prototcol (BEEP). Both of these protocols, XML for the data schema and BEEP for the transport layer, make it extremely easy to expand the functionality of XRP to include registrar and registry capabilities for the usTLD.
It should be noted that the IETF Provreg Working Group, in which NeuStar is an active participant, is developing an industry standard interface between registrars and registries. XRP will be functionally compatible with the standard developed at the IETF.
NeuStar has already developed the tool kits for registrars interfacing with the.biz registry. Registrars that have been tested with XRP for .biz will need to go through only simple testing to be certified for the additional functionality required for the usTLD. Assistance will be provided to registrars through an operational test-and-evaluation facility, described in Section B.2.9, and technical support will be available for usTLD accredited registrars, by phone or via the usTLD Web site, on a 24 × 7 × 365 basis.
[Exhibit B.5-1: High-level architecture illustrates a high-level view of the Enhanced SRS and the interactions with external systems. Graphic Omitted: high-level diagram of registry architecture.]
NeuStar's application servers contain the business rules that manage the registration data between the registrar and the registry. Simply stated, it acts as the interface between the protocol server, which interfaces to the registrars, and the Centralized usTLD Database. It is the most complex element of the registry because of the complex business rules and the need for real-time efficiency. NeuStar has a great deal of experience in building high-availability, complex systems to support critical public resources. Examples of these systems include the Number Portability Administration Center, the National Number Pooling Administration Center, and the.biz registry.
B.5-2
A detailed description of the functions of the Enhanced SRS is provided in Section F, Centralized usTLD Database and Enhanced Shared Registration System.
A detailed description of the technical operations and facilities of the Enhanced SRS, including XRP and the Centralized usTLD Database, is provided in Sections O.1, O.2, and O.3 of this proposal.
B.5.2 Accreditation Process for usTLD Registrars
NeuStar will implement a simple registrar accreditation process to ensure consistency in quality and service within the usTLD, while at the same time promoting stability and competition for domain name registration services.
In order to encourage the rapid implementation of the enhanced usTLD space, promote strong competition among registrars, and ensure the continued neutrality of the registry, while at the same time promoting competition and stability for domain name registration services, NeuStar will use a straightforward, fair and efficient accreditation process for all usTLD registrars. Eligibility to access the registry will be subject only to an accreditation application process and technical testing and approval by NeuStar technical staff, payment of a registrar accreditation fee, and the execution of a usTLD Registrar Accreditation and usTLD Registry-Registrar Agreements.
All registrars or potential registrars, including those who are already ICANN-Accredited Registrars, must become accredited to register domain names in the usTLD. A registrar need not be an ICANN-accredited registrar to become a usTLD registrar. The usTLD Registrar Accreditation Process is illustrated in Exhibit B.5-2. The following bullets outline the basic process:
[Exhibit B.5-2: The usTLD Registrar Accreditation Process will be followed to ensure all usTLD Registrars meet the requisite standards of integrity. Graphic Omitted: flow chart depicting usTLD registrar accreditation process.]
Because NeuStar proposes an open, shared registry for the expanded usTLD space, there will be no restrictions on the number of registrars permitted to register names in the system.
B.5-3
Copies of the usTLD Registrar Accreditation Agreement and the Accreditation Application are attached at the end of this section. NOTE: The Application refers to Application Instructions which will be developed by NeuStar and approved by the Department of Commerce prior to the commencement of the accreditation process.
B.5.3 usTLD Technical Certification Process
NeuStar's process for Operational Test and Evaluation certification will test the capabilities of registrar systems before access to the live Enhanced Shared Registry System is granted.
In order to maintain the integrity of the usTLD and of the DNS as a whole, it is necessary to ensure that registrars are technically competent and that their systems, which will interface with the usTLD Enhanced Shared Registration System (SRS), are capable of operating and performing the required functions. To fill this need, NeuStar will develop and implement a process for technical certification of registrars in the expanded usTLD space.
Before a registrar would be given permissions to access the live usTLD Enhanced SRS, it will first need to pass NeuStar's usTLD Technical Certification Process, called Operational Test and Evaluation (OT&E) certification. The purpose of this OT&E certification will be to verify the correct operation and performance of a registrar's client system.
Preparations for OT&E Certification
The OT&E certification process will begin when a registrar becomes accredited by NeuStar to register names in the usTLD, at which point the registrar will enter the usTLD registry provisioning process. This process begins when the registrar fills out a registration form. NeuStar will then send a usTLD welcome package to the registrar that will include information to help implement its eXtensible Registry Protocol (XRP) client application for the Enhanced SRS. This package will also include the following:
The registrar will be responsible for installing the XRP client application that will interface to the registry using the XRP. The registrar will interface the XRP client to the back-office systems via the XRP common APIs.
B.5-4
Because the registry-registrar communication channel will be encrypted, an SSL certificate from an approved Certificate Authority will be required to establish an SSL encrypted channel. The username/password and subnet list will provide additional security; only a valid combination of an SSL certificate, username/password, and subnet will be allowed to access the live Enhanced SRS.
During XRP client implementation, the registrar will have access to the Registry OT&E test bed environment. In the OT&E test bed, the registrar may test the operation of its software to verify the correct handling of XRP commands, their responses, and notification messages. Operations performed in the OT&E environment will not be charged and will not have any impact on the live Enhanced SRS. Registrars/Delegees will continue to have access to the OT&E test bed after certification, so that they may continue to test their back-office software systems.
When a registrar has completed the testing of its XRP client and back-office systems and would like to proceed with OT&E certification, it will then contact the usTLD Customer Service Center to schedule a time slot for an acceptance test. Time slots will be scheduled on a first-come-first-served basis. At the scheduled time, the registrar will contact the usTLD OT&E Technical Support Team to initiate the certification.
The XRP Registrar Tool Kit
The XRP Registrar Tool Kit is a software development kit (SDK) that will support the development of a registrar software system for registering Internet domain names in the usTLD registry using the XRP registry-registrar protocol and the XRP common APIs. The SDK will consist of software and documentation as described below.
The SDK will be used by the registrar as a basis for connecting to the usTLD registry test bed environment during OT&E and can also be used to develop a system for interfacing with the live usTLD registry once the registrar has been certified.
The software will consist of a working Java XRP common API and samples of interfaces to back-office systems that implement the XRP core functions and XRP extensions used to communicate between the registry and registrar. The SDK will illustrate how XML requests (registration events) can be assembled and forwarded to the registry for processing. The software will provide the registrar with the basis for a reference implementation that conforms to the XRP registry-registrar protocol. The software component of the SDK will also include XML schema definition files for all Registry XRP objects and XRP object extensions.
The documentation will also describe the XRP software package hierarchy, the object data model, and the defined objects and methods (including calling parameter lists and expected response behavior). New versions of the SDK will be made available from time to time to provide support for additional features as they become available and support for other platforms and languages.
OT&E Certification Test Cases
During OT&E certification, a registrar's client application will be required to demonstrate the proper execution of the following operations:
B.5-5
- Create domain without nameservers and without contacts (XRP Transform <create>)
- Create domain with nameservers
- Create domain with contacts
- Create domain with maximum registration period
- Create domain with maximum number of nameservers
- Create domain with maximum number of contacts
- Create domain with maximum length domain name (63 characters +.US)
- Create domain with invalid name
- Check domain (XRP Query <check>)—domain not available
- Check domain (XRP Query <check>)—domain available
- Check domain—maximum length domain name (63 characters +.US) not available
- Query domain (XRP Query <info>)
- Query domain transfer status (XRP Query <transfer>)
- Delete domain (XRP Transform <delete>)
- Renew domain (XRP Transform <renew>)
- Transfer domain (XRP Transform <transfer>)
- Change domain (XRP Transform <update>)—nameservers
- Change domain (XRP Transform <update>)—contact
- Change domain (XRP Transform <update>)—status
- Create nameserver (XRP Transform <create>)
- Create nameserver with maximum length host name (80 characters)
- Check nameserver (XRP Query <check>)—nameserver known
- Check nameserver (XRP Query <check>)—nameserver unknown
- Query nameserver (XRP Query <info>)
- Delete nameserver (XRP Transform <delete>)
- Change nameserver (XRP Transform <update>)—add IP address
- Change nameserver (XRP Transform <update>)—remove IP address
- Create contact (XRP Transform <create>)
- Check contact (XRP Query <check>)—contact known
- Check contact (XRP Query <check>)—contact unknown
- Query contact (XRP Query <info>)
- Query contact transfer status (XRP Query <transfer>)
B.5-6
- Delete contact (XRP Transform <delete>)
- Transfer contact (XRP Transform <transfer>)
- Change contact (XRP Transform <update>)—change element
- Change contact (XRP Transform <update>)—remove element
- Create registrant account (XRP Transform <create>)
- Check registrant account (XRP Query <check>)—contact known
- Check registrant account (XRP Query <check>)—contact unknown
- Query registrant account (XRP Query <info>)
- Query registrant account transfer status (XRP Query <transfer>)
- Delete registrant account (XRP Transform <delete>)
- Transfer registrant account (XRP Transform <transfer>)
- Change registrant account (XRP Transform <update>)—change element
- Change registrant account (XRP Transform <update>)—remove element
NOTE: The Registry will reserve the right to change the OT&E certification requirements as necessary to ensure compliance with the evolving XRP protocol and XRP common APIs.
Post OT&E Certification
All tests performed during OT&E certification must be completed without errors. The registry will provide the certification results in a timely manner and provide feedback for those registrars that failed to successfully complete the tests. Those registrars may correct their systems and reschedule for certification. Registrars will not be limited in the number of attempts at OT&E certification.
Upon successful OT&E certification, the registrar will become eligible for operation in the live Enhanced SRS. A new username and password will be assigned, and the NeuStar will configure the live system to recognize the SSL certificate, username, password, and subnet blocks for the registrar.
B.5.4 Whois Database Development
NeuStar's centralized Whois database will accommodate public searches for registrant and registrar contact information and will ensure the accuracy of data throughout the usTLD namespace.
The locality-based usTLD space has traditionally had no centralized Whois, which made it difficult to look up contact information for domain name holders. But the usTLD expanded space is new, and we have the chance to implement an enhanced Whois database for that space that will be accurate and up to date from the very first registration in that space. NeuStar will develop and implement an enhanced Whois database that will contain information about all usTLD registrations, registrants, and registrars active in the usTLD namespace. NeuStar's usTLD Web site will provide access to both the locality and expanded Whois databases; Whois will also be available through a standard port 43 interface.
B.5-7
In accordance with the RFQ, the Whois database will allow for multiple string and field searches through a publicly available, Web-based interface. Query returns will indicate the Whois database being accessed, and whether the record is for a registrant or a registrar. Access to the database through the Web site and through port 43 will be free of charge and available to the public.
Populating the Whois information in the expanded space will be done through the registrar at the time of registration. Registrations will not be considered complete without all of the appropriate information being provided.
At a minimum, NeuStar will collect and update the information provided below for each type of Whois record in the expanded space:
Registrant Whois information in the expanded namespace will include the following information:
Registrar Whois information in the expanded space will include the following information:
Detailed descriptions of how the database will be populated, how it will be kept up to date and accurate, and the structure of the Whois responses are provided in Section F, Central usTLD Database and Enhanced Shared Registration System. A detailed description of Whois policy is provided in Section B.3.5.
Further, to ensure the integrity and highest levels of service for Whois administration, redundant databases will be located at the geographically diverse, redundant Enhanced SRS Data Centers located in Illinois and Virginia. In accordance with the U.S. Nexus requirement, no usTLD registry databases will be located outside of the United States. Both databases will be updated in near real time (intervals no greater than 15 minutes) and will be synchronized to ensure consistency of the response.
B.5-8
A more detailed technical description of the database is provided in Sections O.3 and O.8 of this proposal.
B.5.5 Community Outreach Plan
NeuStar has a strong history of facilitating discussion among stakeholders while ensuring it does not become a barrier to progress in the public interest. NeuStar will bring this experience to bear in the usTLD.
Administration of public resources, whether they are telephone numbers or domain names, requires strong awareness of constituencies and their needs. Thus, community outreach is a critical element in such administration. In addition, however, an administrator also must have the experience and resources to ensure that public outreach, discussion and input do not becomes barriers to meeting project objectives. An inexperienced administrator might not recognize this important distinction. The distinction is, however, critical to the success of the usTLD, for without strong coordination of the outreach process itself, enhancement and development efforts for the usTLD will stagnate.
NeuStar has a strong legacy of coordinating complex groups of users in the industries that it serves. NeuStar intends to establish targeted communications mechanisms, including e-mail listservs, chat services, and other Internet-based services whereby the public can suggest or recommend either additional policies and procedures or modifications to existing ones. In addition, NeuStar will utilize traditional customer outreach, such as users group meetings, user support representatives, and other support services to maintain close relationships with usTLD users and the public.
NeuStar proposes the creation of a usTLD Policy Council to assist in the development and implementation of usTLD outreach, among other functions. This council will be very important to the ongoing development of usTLD policy and public outreach. The structure and duties of this council, as well as the detailed outline of our basic outreach plan, are discussed in detail in Section B.3.5 herein.
B.5-9
C. NeuStar's Vision of the usTLD
NeuStar will elevate the usTLD to be as widely relied upon and responsive to demand as all other US public resources.
By its very nature, a ccTLD denotes a sense of nationalism, generates a mental image in ones mind of that country, and establishes an impression about that country's relative position in technological advancement. A ccTLD can only do this, however, if it is managed and developed to benefit the needs of its user community—the citizens and government bodies of that country. This takes more than a nexus requirement, more than random newspaper advertisements, more than a commonplace central administrator. It requires a comprehensive business plan that will fulfill the vision of elevating that ccTLD into the next generation of the Internet—a place where people communicate with one another, with their government, with their local businesses, in a stable, secure and readily accessible environment. NeuStar has such a vision for the usTLD.
The body of NeuStar's response enumerates the tools we will use to fulfill this vision—a thick registry architecture that operates at the highest levels of availability and security, the coordination of disparate user communities under a stable, centralized umbrella, a phased and customer-focused outreach program to propagate the need for dot-us domain names, the introduction of enhanced services and the enablement of new advanced applications. The response also illustrates NeuStar's commitment to operate the usTLD in a responsible manner—open communication between the administrator and the DOC, willingness to seek user feedback, the formation of a representative policy council to act as a check point in the development of policy and introduction of various applications and services, an advisory team representative of multiple constituency interests and consisting of pioneers in Internet technology and user constituencies.
NeuStar's ability to perform each of the prescribed mission critical public resource functions is reinforced time and again—experience transitioning the North American Numbering Plan and coordinating over 3,000 carriers, creation of the Number Portability Administration Center and integration of hundreds of users, and the design for a next generation Internet registry.
This section of NeuStar's response is dedicated to describing our vision for the usTLD and illustrating how our infrastructure, our position as a neutral third party, and our experience will execute that vision. This section describes the image of the usTLD today, tomorrow and years from now. It is a roadmap for successful evolution of the usTLD into a revered domain name space.
Representation of the usTLD
The repurposing of ccTLDs has become almost commonplace—efforts that ignore the needs of a country citizenry in order to take a name space into the realm of the gTLDs. The reasons behind the moves are purely commercial, and serve only the economic interests of the participants. Promoting the utility of the usTLD in an effort to drive registrations should not be confused with administering the space like a gTLD, something akin to repurposing. While a ccTLD deserves to have the technical and operational functionality of a gTLD, it has a very different purpose. A ccTLD must have fulfilling the needs of its user community, its citizens, as its top priority.
NeuStar will implement a US nexus requirement to encourage all registrations be made by registrants with a valid US address or bona fide presence in the U.S. Additionally, by requiring proof of delegation in the current locality-based structure, we can promote the use of locality hierarchies by
C-1
their rightful community. This is the first step in representing the usTLD as truly being the name space of its citizens.
Once the user community is defined, the next phase of proper representation of the usTLD is enabling applications and services that benefit those constituencies. These services can serve a subset, a superset, or the entire user base. There should be no limitation on the application areas, no limit on the benefit from the usTLD. (Examples of services and applications can be found in Section D of NeuStar's response.) By enabling applications that serve the public interest within a ccTLD, the space inherently becomes citizen-centered. NeuStar's proposed enhancements reflect a commitment to enhance the usTLD to serve its unique user community.
NeuStar's vision for the representation of the usTLD has a strong constituency focus; a name space with the needs of the user community at the core of its design and operational philosophies. The usTLD should be revered as the most innovative ccTLDs and a vital U.S. public resource.
Integrity of the Infrastructure
NeuStar's response highlights our commitment to providing a next generation registry architecture. Simply, what this means, is that NeuStar has actively reviewed the current legacy systems, the similar registry work we perform as a part our existing businesses and balanced that with the needs of registrars and the end-user community to scope a platform that is more stable and more flexible than what is known today. This sort of evolution is natural in every industry, and the Internet is at a migration point; the usTLD must utilize a next generation design and lead the progression.
There are many technical facets of the NeuStar design that qualify it as 'next gen', but it is how these facets will enable advancement in the space that is truly visionary. One feature represents the shard dimension of our registry—a 'thick' registry model that utilizes an extensible protocol based on XML, standardizes and centralizes Whois information and requirements, supports numerous data fields 'objects', and provides near real-time DNS and Whois updates. A second technical feature is that NeuStar is using a database structure that treats data fields not as independent, stationary pieces of information, but as 'objects', dynamic components that can be integrated at any point of the database lifecycle, that demonstrate ever-changing relationships between data and maximize scalability.
To the end-user, the technical design of the registry is not as relevant as the way they can utilize it. The benefits to the end-user include:
NeuStar's Internet registry architecture is flexible and scalable by design, and based on an open protocol standard available to developers across the US. The usTLD should be open to any applications that will benefit the user community, as long as they maintain the integrity of the overall infrastructure. The responsible introduction of enhanced applications is facilitated by utilizing standards created by subject matter experts. The usTLD should become a space for continued evolution of
C-2
Internet technology, further strengthening the U.S. perception in the world as Internet pioneers. The NeuStar design enables this evolution.
NeuStar's vision of the usTLD infrastructure is that of a platform renown for its high standards of technological excellence. The security, stability, and reliability of the architecture will foster the introduction of numerous applications and services on the open protocol platform.
Integrity of the usTLD Administrator
Selection of an administrator is a multi-faceted analysis of technical and operational capabilities, as determined by past performance and the specifications defined for the usTLD, the commitment to protecting IP and personal information, as well as the standard the administrator will set for the usTLD in general. The usTLD administrator must be a trusted entity that is known for coordinating numerous interests with proprietary systems into single platform, protecting confidential data, taking efforts to promote competition—effectively, being a trusted neutral third party.
The reputation of the usTLD administrator will have a role in shaping the overall image of the usTLD, and therefore the selected administrator must be a responsible member of the Internet community. NeuStar is uniquely qualified to fit this role through our past and present performance:
These are more than a list of random guidelines; they represent a commitment to being a neutral, trusted third party. This represents a starting framework that the administrator of the usTLD should live by. An administrator must be a respected member of its community to effectively, coordinate and manage the usTLD in such a way as to create a valuable public asset for the United States.
To alleviate administrative burdens on the DOC, NeuStar do proposes the formation of an advisory council that can make recommendations on issues and new enhancements that have a material impact on the policy of the usTLD. Part of this group's function is to offer an additional level of checks and balances to ensure the administrator is abiding by its code of conduct in the introduction of policies and changes to the usTLD.
NeuStar's vision of itself as administrator of the usTLD is as an enabler, that is, the facilitator for introducing applications and services all the while monitoring the needs of its constituencies. The administrator must perform many roles, and each must be carried out in a responsible and even-handed manner.
Anticipated Demand for the usTLD
Like the many models of ccTLDs that have opened before it, the usTLD is expected to generate a national interest and create a desire among public and private bodies to secure usTLD domain names. Our vision for the usTLD will promote similar market adoption. NeuStar has reviewed our primary research (as presented in Section B2.8 of NeuStar's response) and numerous points of secondary research to develop a forecast of demand for the usTLD. We assume there are many needs and user groups of the usTLD, and apply varying penetration factors against those addressable markets.
Thus, NeuStar anticipates the following demand (in millions) for the usTLD:
|
Contract Year 1 |
Contract Year 2 |
Contract Year 3 |
Contract Year 4 |
||||
---|---|---|---|---|---|---|---|---|
Names Under Management | 1.39 | 4.20 | 6.81 | 9.63 |
These projections are considered a moderate estimation; we recognize the names under management in the registry could be lower or higher. Given growth rates in other ccTLDs that have been migrated to a more open space and have easier registration process, we feel these projections outline a scenario where the usTLD has gained broad market acceptance.
C-3
D. Enhancing the Utility of the usTLD
The phased introduction of new applications and innovations in a responsible manner to further the enhancement and utilization of the usTLD will be a core function of NeuStar's administration of the space.
Introduction
NeuStar has actively followed the domain name space for over three years—both the generic TLDs and the usTLD. Our involvement in the Internet community and active participation at ICANN, IETF, and other standards-making bodies provide the requisite understanding of Industry needs in the near and long-term. Subsequently, our Internet Registry architecture was shaped by the Industry desire to have a highly reliable, secure, scalable, open-protocol platform that will allow for the seamless introduction of enhancements.
NeuStar will leverage the following technical advancements and business commitments to enable a variety of enhanced services.
NeuStar will dedicate resources to enable the numerous applications that the U.S. public and private sectors can utilize through a responsibly managed addressing scheme within the usTLD. The new service enablers would be optional and made available for use both in the new expanded space and the existing hierarchical space. We present below a brief summary of enhanced applications that could be enabled by integrating the combined strengths of a U.S.-centric addressing space and NeuStar's next-generation thick registry platform. NeuStar has gauged market demand and has actively been developing the ability of its thick registry to uniquely enable these application areas. To this end, NeuStar also proposes a fair and responsible process for enabling these enhanced services while maintaining the integrity of the usTLD.
Enabling Enhanced Services
Thick Registry—NeuStar's industry-leading, next-generation thick-registry architecture provides the flexibility required to introduce innovative private and public services that meet the needs of the U.S. Internet community. An extensible "thick" structure means that an unlimited number of fields of information can be maintained in the registry database in order to enhance utility and facilitate the delivery of enhanced services. These extensible information fields are a key enabler for the delivery of opt-in services to end users by registrars, resellers, delegees, and service providers.
High Reliability—NeuStar has a proven record of managing mission-critical public resources. NeuStar has developed highly reliable infrastructure that is well suited to the consistent delivery of enhanced services within the usTLD.
Highly Secure—NeuStar's experience in securing mission-critical infrastructure, such as the Local Number Portability database, is reflected in the registry platform. NeuStar will implement a trust infrastructure, comprising both security technology and business processes, to ensure the integrity, accuracy, and privacy of the data in the registry. These attributes are critical for the delivery of enhanced services.
D-1
Open Standards—NeuStar's registry infrastructure makes use of approved open protocol standards. This approach is optimal in terms of the ability of registrars, resellers, and delegees to interface with the registry and also facilitates the development of new services. A standards-based approach will maximize the number of sales channels guaranteeing greater public awareness, access to the usTLD domain, and development of innovative services.
Marketing Investment—NeuStar has the financial resources and is committed to making the necessary investment in marketing and promotional activities to ensure widespread awareness of enhanced service enablers. This approach will tap into the entrepreneurial energy and public-service spirit of the American people and will lead to innovative services that are responsive to the needs of the U.S. community.
Neutrality—Consistent with NeuStar's trusted neutral third party status and Code of Conduct (See Section B.3 for details), NeuStar will make all of the enhanced service enablers available on an equal and fair basis to all members of the U.S. Internet community.
NeuStar has been validating the potential utility of these service enablers from a technical and market perspective. These "enablers" are intended to facilitate applications that are provided to businesses, organizations, and citizens via registrars, resellers, delegees, and service providers. We will provide an overview of the following Enhanced Services for which there is market demand and that our Internet Registry can uniquely enable.
NeuStar anticipates working with a broad base of representative organizations and government agencies to identify additional services that unlock the utility of the usTLD to serve the American Internet community.
Process for Enabling Enhanced Applications and Services
NeuStar has a history of managing shared public resources while simultaneously introducing enhanced features and functionality in a responsible and even-handed manner. These neutral and responsible practices will be mirrored in the introduction of enhancements in the usTLD.
NeuStar will manage the introduction of new enhanced services and applications in an open, neutral, and responsible manner. The usTLD will be well suited to serving the interests of the public—the way the government, citizens, business, and organizations communicate and interact. In many instances, NeuStar simply will enable enhanced services offered by others that leverage the combined benefits of the usTLD address space and NeuStar's technically advanced registry. In these instances, no change in policy will be warranted. Nevertheless, NeuStar will follow a strict process for the introduction of any new services. All new services will be analyzed for their technical and operational feasibility, and receptiveness to the usTLD existing or potential user base, and will be openly discussed within a proposed usTLD Policy Council. The Council will provide policy comments and recommendations concerning the proposed new enhanced services. A detailed discussion of the Council is found in Section B.3.5.
The technical evaluation criteria will include, but is not limited to, ensuring that service level agreements will continue to be met or exceeded, that interested parties needs are met, and that intellectual property rights and registrant privacy is protected.
D-2
After NeuStar affirms the feasibility of a new service, it will seek approval by the DOC for implementation. NeuStar will develop a document to assist in the approval process; this proposal will include a description and price of the enhancement. As shown in Exhibit D-1, NeuStar will comply with the request to have all new services approved by the DOC.
Public Resource Domains
Public Need
The current locality structure generates lengthy names that are difficult to remember, but this is most notably because the requisite contextual information is typically beyond the fourth level. While we will be taking direct second-level registrations as the administrator of the usTLD, we propose to explore the management of "public resource" domains that serve as a common naming scheme to allow for convenient and consistent naming of various public interests and services. These condensed hierarchies afford Internet users the opportunity to easily locate the information they seek without complicated trial-and-error searching. They will cross many district or state lines and be relevant to all citizens of the United States.
The usTLD is quite naturally the proper TLD for establishing such a condensed hierarchy, since the purpose would be to serve the American public.
Enhanced Services
Numerous second-level domain names could be reserved to create unique and content-specific spaces on the Internet to serve a variety of citizen-centric public interest needs. NeuStar can responsibly manage the third-level registries for each of these name spaces, through a sponsor approved by the usTLD Policy Council and the DOC, to maximize the overall utility of the second-level name.
The domain names could be registered through the sponsoring, name-specific channel that has an interest in the preservation of the name for a specific use. An example of a public resource hierarchy NeuStar could manage for the benefit of the U.S. public includes:
[Exhibit D-1: NeuStar's process for introducing enhanced services and applications is approached in an open and responsible manner, with full involvement of the DOC and the usTLD Policy Council. Graphic Omitted: flow chart of process for introducing usTLD enhancements.]
Other examples of second-level domain names NeuStar could manage (i.e., NeuStar would take third level registrations for the sponsored second level):
D-3
By having a single administrator for these public service domains, the user community will better associate the domain name space with the high standards and reliability of the NeuStar registry. This will further the notion of the usTLD as a trustworthy space managed for the benefit of the U.S. public, a ccTLD that propagates the U.S. image as the pioneers of the Internet.
NeuStar's Enabling Role
The NeuStar registry is uniquely positioned to manage these public resource hierarchies through the design of our Internet registry. The registry will manage domain names at any level with equal standards for reliability and security, for the same competitive price. NeuStar will extend its infrastructure to the third and fourth level domains to ensure highly reliable and secure namespaces. Additionally, because these hierarchies will be centrally managed, NeuStar can provide directory services to facilitate user searching.
Recommended Process
NeuStar has proposed a draft list of names for reservation by the usTLD Administrator (see Section B.3.5) and would work with the proposed Council and DOC to introduce enhanced services for these namespaces in a fair and responsible manner. We will also conduct additional outreach activities to identify other namespaces that would serve the public interest and to identify potential sponsors where appropriate. NeuStar will actively seek comment and input from delegated managers and organizations currently utilizing the existing hierarchical space or with a public interest in the space prior to the introduction of Public Resource Domains.
NeuStar will develop a document to assist in the approval process. NeuStar will comply with the request to have all new services approved by the DOC.
E-government
Public Need
The usTLD should be utilized to support the directive from the White House to "use the Internet to create a citizen-centric government." As more government agencies move critical components of their operations online, the need for a secure space increases. Moreover, an addressing infrastructure is a key enabler for a capability that allows citizens to find and access government informational resources, services and e-Gov applications.
In tandem to initiatives to provide a more secure platform for e-government initiatives, attempts are being made to streamline government processes and increase government efficiency. Our Internet registry architecture, our unique position as a trusted neutral third party, and our commitment to fulfillment of the US Nexus requirement uniquely positions NeuStar to meet this need. NeuStar will work very closely with the U.S. federal, state, and local governments to enable their requisite e-government initiatives.
Enhanced Services
Several e-government applications and services can be responsibly enabled through NeuStar's coordination and management of the usTLD. The primary objective of these online application areas is
D-4
to allow citizens to interact with the government in a direct, secure forum. According to a study by the Council for Excellence in Government, the majority of Americans feel that e-Gov would have a positive effect on government. Many such initiatives are underway today: motor vehicle administrators allow for license and registration renewals, public safety organizations take payment for fees and services, the Internal Revenue Service accepts tax forms via their secure site. Future e-government applications enabled by the usTLD addressing mechanism could include:
Because of the critical nature of e-Government applications, it is crucial that the usTLD administrator have demonstrated technical expertise, real-world operating experience, an established position as a trusted neutral third party, and the ability to provide a highly reliable and secure environment.
NeuStar's Enabling Role
Because the NeuStar platform is being developed to perform at high levels of service availability and will employ encryption technology, it is a logical domain space for all U.S. governmental bodies—national, state or local—to develop their critical online initiatives. NeuStar currently manages a mission-critical public resource for the communications industry (e.g. the public switched network relies on NeuStar numbering databases), and is prepared to do the same for the public sector through administration of the usTLD.
Recommended Process
NeuStar proposes to work with the usTLD Policy Council and the DOC to conduct an outreach program, which will include current e-Government service providers, to identify ways in which the usTLD addressing scheme can be leveraged to enable e-Gov services that reduce government cost, improve accessibility and productivity, and serve the American people.
NeuStar will develop a document to assist in the approval process. NeuStar will comply with the request to have all new services approved by the DOC.
Directory Services
Public Need
One of the primary enhanced services NeuStar proposes for increased ease of use of the usTLD is directory services. We propose to evaluate, trial, and implement a series of sophisticated directory search capabilities for services and sites on the usTLD. The primary reason the existing locality-based hierarchical structure is awkward to use is the absence of a comprehensive search capability for users to locate the service of interest without having to know the exact fully-qualified domain name. While numerous search engines exist in the Internet, none of them allow the user to pre-select U.S.-based services, specifically ones meeting the Nexus requirement or that are named using the usTLD. Consequently, prospective users must wade through long and confusing lists of services across the entire Internet to find the specific one of interest. The presentation order and content is dictated by the search sites' commercial policies, not necessarily the public interest.
D-5
Enhanced Services
A directory service for the usTLD would provide not only a separate navigational schema for the TLD while retaining the existing locality-based name structure, but would provide a usTLD-specific search capability that doesn't currently exist elsewhere, and provide for consistency and uniformity in the listings of usTLD entries. This is extremely important for government services accessed through the locality structure, as there is no pervasive user-friendly government-service-specific directory today. Commercial search sites intermix listings for government and commercial sites, obscuring which services are official government services versus similarly listed commercial services, thus confusing potential users and causing potential security and fraud problems.
One of the first objectives would be to establish a keyword schema for categorization and characterization of the existing usTLD entries, and the primary service associated with each entry (URL using the usTLD). The keyword to URL mapping forms the core of the directory, along with appropriate fields from the Whois data. This data can then be searched from the web, using any number of attributes (service name, offering entity name, associated locality info, e.g. state or county), at a site to be established, e.g. http://www.search.nic.us/. In addition, it is possible to re-direct web inquires to non-existent (incorrect) usTLD names to the search site to solicit the user to navigate to the site of interest through the directory instead. This type of mechanism makes the directory an automatic help capability and significantly aids in usTLD usage. Users would be encouraged to add a site to their bookmarks to streamline navigation in the future.
In addition to a web-based search capability, NeuStar would propose to also provide directory listings online accessible via standard (IETF) directory protocols such as LDAP, and newly emerging so-called fuzzy search protocols such as CNRP (common name resolution protocol). Lastly, NeuStar could also make the directory database available to commercial search sites to increase accuracy and usability of usTLD data they have.
Lastly, a comprehensive directory search capability makes it possible to facilitate foreign language navigation to these same sites. In some areas of the U.S. foreign language (e.g., Spanish) access is important and even mandated. Keywords and directory listings in other languages in addition to English of the same usTLD sites will facilitate these important local policies.
NeuStar's Enabling Role
The enablement of directory services by the NeuStar thick registry within the usTLD would provide an important mechanism by which both the private and public sector users could easily find information, products, and services provided by companies within the United States. Furthermore, this capability would allow citizens to easily find public services and interact with local, state, and Federal government agencies.
Recommended Process
NeuStar proposes to work with the proposed usTLD Policy Council and the DOC to fairly and responsibly implement Directory Service enablers within the usTLD addressing structure. Both public and private sector directory needs will be pursued.
NeuStar will develop a document to assist in the approval process. NeuStar will comply with the request to have all new services approved by the DOC.
D-6
Personal Identification Applications
Public Need
Over 116 million Americans are online, and each could utilize a unique personal identifier in their browsing, purchasing, or other use of the Internet. Effective use of the usTLD, in the interest of the American people, should include protection mechanisms so any American citizen could elect to register a unique personal domain name tied to any information they wish to associate with themselves for use on the Internet. These names could be the key for streamlining access to information, reducing the need to re-enter identification information to sites that are not secure, or for dynamic assignment between sites or platforms.
Enhanced Service
The need and market for various forms of globally unique, administered namespaces is well understood within the Industry. The use of "distinguished keys" is a well-known concept that we all use in various contexts. The most obvious one is the use of Social Security numbers as a "distinguished key" that links data about us in various contexts. The overuse of the SSN in various industries has created substantial concerns about privacy, formalizing the need for other forms of nationally unique identifiers. As we move online, an addressing system such as the DNS, which provides a one-to-one unique resolution, is a logical mechanism, and the usTLD a logical extension for U.S. citizens.
The core value proposition is the creation of namespaces directly under the control of consumers that can be "dynamic," in the manner in which they are accessible across a variety of applications. The product offered to the consumer will be the opportunity to obtain a domain name during the registration process that could be used for:
The name, coupled with digital security and encryption technology, could be a single online identifier for U.S. citizens. This identity could be used in a variety of applications and sites, at home or in the office, with the assurance of confidentiality.
An important element of this service would be the ability of an end user to determine what information is accessible by whom ("permissioning"), and also to decide what organization stores the data. As a neutral third party, NeuStar is a viable alternative repository for personal information or pointers that would redirect queries to other repositories selected by the end user.
NeuStar's Enabling Role
We believe that optional user-controlled digital identifiers would accelerate the adoption of electronic services in both the private and public sectors. Given that the usTLD is a public resource utilizing this capability within the usTLD to improve access to public services and to facilitate e-Gov applications including Business to Government (B2G) is particularly appropriate.
NeuStar, as a part of its existing core businesses, is in possession of confidential and competitive information and follows strict rules to ensure protection of confidential data. A Code of Conduct that restricts the resale of our data for marketing purposes, and a Whois database design that calls for a two-step process to elicit registrant information, are examples of our commitment to privacy. From a technology perspective, the extensible fields of the NeuStar Internet registry are fully capable of securely storing (registrant granted) personal data and its permissioning rights.
D-7
Recommended Process
As with any innovation, it is difficult to predict with certainty the degree of acceptance and use; however, in this case, the potential benefits appear to be compelling. NeuStar is therefore prepared to make the investment required to enable this enhanced utility within the usTLD. We propose to work with the usTLD Policy Council ("the Council") and the DOC to introduce Personal Identification Services within the usTLD in a fair and responsible manner.
NeuStar will develop a document to assist in the approval process. NeuStar will comply with the request to have all new services approved by the DOC.
Location-Based Services
Public Need
Today the Internet is indexed and navigated based primarily on domain name via the URL line of browsers and key word via search engines. Although this has served the user community well, many users seek information, resources, products, and services that by their very nature would be more conveniently organized by geographic location. Such an enabler could be applied to, for example:
The need to organize information based on geography is most readily apparent in mobile applications. Knowing where a user is located is not enough to provide useful services. End users, networks, and applications need a simple way to identify what products, services, and resources are located within the surrounding area.
Other than registering in geographically-oriented hierarchical namespaces (e.g., www.aservice.centreville.va.us), which has proven to be unattractive from a marketing perspective and impractical for multiple locations, there is there is no agreed upon globally resolvable mechanism for registering a location or multiple locations against a domain name. The location-based service capability described below provides a practical solution that satisfies an identified user need.
Enhanced Service
In order to facilitate this capability, NeuStar proposes to reserve all of the longitude and latitude coordinates that make up the United States and its territories under the usTLD. One or more locations would be associated with a domain name, and each location would in turn be associated with its geographic coordinates, which would be stored in the thick registry database.
Location registration would take place through registrars, resellers, delegees, and other service providers. Registered locations would be automatically geographically coded for longitude and latitude by the Registry based on physical address. The longitude and latitudes associated with a domain name and relevant key words will be stored in the "thick registry" database. Resolution by location will take place via API interfaces provided by NeuStar to search engines, geographically oriented portal providers, wireless operators, and other enhanced-applications providers or through direct query to the registry via client-based software. This would allow an end user to search on a particular key word for a given geographical location (e.g., search on key word "bicycle" to find all bike shops within 10 miles of
D-8
a given address). The same location-based service enabler could allow an individual to locate government offices or public services in a particular geography.
NeuStar's Enabling Role
The NeuStar thick registry architecture has the ability to support enhanced applications that require transactional resolution of queries based on parameters other than domain name. Given the geographic nature of any ccTLD, enabling location-based services within a country code would seem to make perfect sense. NeuStar seeks to enable this enhanced utility within the usTLD so that usTLD registrars, resellers, delegees, and service providers may offer domain name registrants the ability to register their locations against their domain name at an additional nominal fee and so the usTLD can be the first to offer this useful and innovative capability.
Recommended Process
As with any innovation it is difficult to predict with certainty the degree of acceptance and use; however, in this case the potential benefits appear to be compelling. NeuStar is therefore prepared to make the investment required to enable this enhanced utility within the usTLD. We propose to work with the usTLD Policy Council and DOC to introduce location-based services within the usTLD in a fair and responsible manner.
NeuStar will develop a document to assist in the approval process. NeuStar will comply with the request to have all new services approved by the DOC.
Each of the enhancements described represents a brief sample of the innovations possible within the usTLD. All enhancements will be closely evaluated to ensure that the stability of the Internet is maintained and that the usTLD is balanced with the goal of increasing utility.
D-9
E. Current State of the usTLD Domain Space
NeuStar's thorough understanding of the current state of the usTLD strengthens our ability to effectively manage and enhance the space.
NeuStar's understanding of the current usTLD space provides the foundation for solution development that ensures:
It is often said that hindsight is 20/20. This means that with time and experience, we come to understand, in context, the implications of previous decisions. Had anyone been able to predict the developmental course of the Internet and the effect it would have on people's lives, many issues that currently complicate its use would have been addressed and clarified. The same holds true for the dot-us top-level domain (usTLD). When the original structure and administrative mechanisms for the usTLD were established, there was nothing to compare it with and no way to predict its evolution. With the advantage of time, however, it is clear that the complexities of the current structure, combined with the lack of coordination and marketing of the namespace, have resulted in a space that has not attracted a high level of domain name registration activity and that remains underpopulated and underutilized in comparison with other ccTLDs.
Without an in-depth comprehension of the current usTLD space—its successes and its shortcomings—no administrator could successfully meet the challenge of improving the integrity of the usTLD. This comprehension must include a thorough understanding of the naming structure, current administration, technical and operational conditions, and other factors relating to the usTLD, as well as a general understanding of what makes a ccTLD successful. Policy issues in the usTLD run throughout these issues and are discussed throughout this section and this proposal.
The usTLD was established in 1985 as the country code top-level domain (ccTLD) for the United States. ccTLDs are based on the two-letter country codes from the list of countries in ISO-3166. A number of these ccTLDs have been repurposed—used not to serve the individuals, governments, and businesses of the country that they represent but instead as a globally available alternative to the generic top-level domains. For example, the registry for the dot-cc domain, which began as the ccTLD for Cocos Island, now advertises dot-cc as the newest alternative to the gTLDs. This type of rebranding may create user confusion and can cause a situation where the ccTLD is not managed in the best interest of the country that it should represent, thereby significantly diminishing the integrity.
This kind of repurposing has not occurred in the usTLD. Today there are approximately 8,000 subdomain delegations under the usTLD to entities providing services for commercial, educational, and governmental purposes to registrants physically located in the United States. Individuals, federal government agencies, schools, libraries, museums, and state and local governments are all registered in the usTLD locality-based hierarchy.
Naming Structure of the usTLD
The original hierarchical structure of the usTLD was defined by Dr. Jon Postel in IETF RFC 1480, "The US Domain." This structure is based upon the geography of the United States. Second-level domain space is designated for states and U.S. territories and consists of two-letter state abbreviations. For example, the state of Pennsylvania is designated by pa.us. Within the state name space, there is a further subdivision for locality names—counties, cities, or local names. Further structure is available for each of the various registering entities listed above, and additional structures not based in national geography (e.g., .fed.us, .isa.us, and .nsn.us), which represent special organizations not contained within
E-1
a specific locality, have also been established. Some of the designated structures in the usTLD include, but are not limited to:
usTLD Designated Structures
Structure |
Description |
|
---|---|---|
<state>.us | No direct registrations currently allowed. | |
state.<state>.us |
Used for state governments (e.g., state.va.us). State agencies may register under this structure. |
|
<locality>.<state>.us |
Used for city and county names (e.g., arlington.va.us). Businesses, individuals, and private schools may register under this structure. |
|
ci.<locality>.<state>.us |
Used for city governments. Agencies that make up those governments may register under this structure. |
|
co.<locality>.<state>.us |
Same as above, for county governments. |
|
k12.<state>.us |
Used for public schools. Public school districts may register under this structure. |
|
<district>.k12.<state>.us |
Used for public school districts. Public schools may register under this structure. |
|
cc.<state>.us |
Used to designate community colleges. |
|
tec.<state>.us |
Used to designate technical schools. |
|
lib.<state>.us |
Used to designate libraries. |
|
fed.us |
Used for federal agencies. Only federal agencies may register under this structure. |
|
isa.us |
Used to designate inter-state authorities (ISAs), for joint governmental authorities that are inter-state. |
|
nsn.us |
Used to designate Native Sovereign Nations, for example Indian tribes, villages, colonies, and other communities that may span state, regional, and national boundaries. |
Additional nongeographical domains are also included as part of this structure, as defined either in RFC 1480 or by previous administrators.
The locality-based hierarchy provides structure, name uniqueness, and a geographic reference point for registrants and, although it is regarded by some as unwieldy, there are enterprises that do value the specificity of the system. Exhibit E-1 demonstrates the basic structure of this hierarchy and shows the number of levels possible in the locality structure. The second-level domain names shown are a subset of all possible second-level domains, and additional "special" domains, as noted above, exist in this
E-2
space. Registrations must be made within the hierarchical structure, and no registrations are allowed in the second level.
[Exhibit E-1: The usTLD hierarchy provides structure, name uniqueness, and geographic reference points but is often considered to be unwieldy. Graphic Omitted: diagram depicting usTLD legacy naming hierarchy.]
Designations for schools provide a good example of this hierarchy. Because many schools share the same name, it is important to distinguish by locality the specific school being referenced. There might be several Washington High Schools in the United States, but there is likely only one Washington High School in any given school district in the United States. The locality structure for schools was designed in RFC 1480 to permit distinction between such schools. The k12 designation was created to allow registrations of public and private elementary schools, and the basic structure for these is k12.<state>.us. Beyond the k12 designation is a designation for a school district, and beyond that, schools may register individual names so that the final structure becomes <school name>.<district>.k12.<state>.us. Private schools register as <school name>.pvt.k12.<state>.us, but they may also register under a locality as <school name>.<locality>.<state>.us
To add further complexity, although RFC 1480 defines this structure for registration of schools, the current usTLD administrator has allowed registrations outside of this hierarchy, so that a school might register directly under the k12 branch (for example, <school name>.k12.<state>.us). Additionally, entities designated as "special service units," which are discussed but not definitively structured in RFC 1480, may register directly under k12. Similar discrepancies exist under other areas of the hierarchy. For example, a city government would generally be designated as ci.<city name>.<state>.<us>, and a county government would be co.<city name>.<state>.<us>. In general, these guidelines have been followed, but not consistently. As a real example, the following table lists some city and county government domains within the Commonwealth of Virginia.
Hierarchical Structure of Government Domains Under.va.us
City or County Name |
Fully Qualified Domain Name |
Follows Hierarchical Structure |
||
---|---|---|---|---|
Arlington County | co.arlington.va.us | Yes | ||
City of Alexandria |
ci.alexandria.va.us |
Yes |
||
City of Chesapeake |
chesapeake.va.us |
No |
||
City of Covington |
covington.va.us |
No |
||
City of Falls Church |
ci.falls-church.va.us |
Yes |
||
City of Norfolk |
norfolk.va.us |
No |
||
Richmond County |
co.richmond.va.us |
Yes |
Although the existing structures for Chesapeake, Covington, and Norfolk would have existed had these cities used the "ci" structure, it creates public confusion when cities and counties in the same state follow different naming conventions for their domains.
Administration of the usTLD
Most branches of the usTLD are delegated to a delegated manager, also known as a delegee, or locality delegee. RFC 1480, written in 1993, maintained that a single registry operator would not be able to assign all of the DNS names under dot-us and, under the administrative guidelines established for the usTLD, included guidelines for selection of delegated managers. Although some of these
E-3
guidelines have changed since 1993, the current administrator has continued the practice of delegating subdomains, and the basic requirements have been maintained.
Delegation Guidelines
Delegated managers are typically commercial or public institutions with a presence or interest in the location designated. Individuals and organizations may request an exclusive delegation from the usTLD administrator to provide a registry and registrar services for a particular subdomain under dot-us. For example, one individual with an interest in Virginia libraries might request delegation of lib.va.us, and become responsible as the delegated manager for all Virginia library names. Delegees are responsible for providing physical DNS services and maintaining technical support for registrants. A delegee may also assign further subdelegations to a subdelegee, and that subdelegee is then responsible for providing DNS services and technical support for registrants under that subdelegation. For example, a delegee who is responsible for k12.va.us might subdelegate the Wilson district to a subdelegee. That subdelegee would then be responsible for all registrations under wilson.k12.va.us.
Where registration for a locality has not been delegated, the usTLD administrator itself provides necessary registry and registrar services. Additionally, no delegations are made in the second level, so that all cases of <state>.us remain under the control of the main registry operator.
"Locality Squatting"
From the beginning, the concern in selecting a delegee for a subdomain has been assessing their ability to carry out the necessary technical and operational responsibilities in a neutral manner, that is, applying the same set of rules to all requests for a domain name. Although RFC 2916 maintained that delegees have a duty to serve the community, no requirements were established regarding the physical location of the delegee, and no limits were made on the number of delegations that could be held by a single subdomain registry operator.
Because there is no such restriction, a small number of delegees became responsible for a very large portion of the delegated namespace. In fact, according to the current contact list of locality delegees, approximately 40% of the delegations are held by 5 delegees, and 54% of the delegations are held by 10 delegees. Additionally, registry operators who have no interest in the localities themselves, except for a commercial interest, run many of the delegations. The act of running a registry in which the delegee has no legitimate interest, or of refusing to provide services to legitimate registrants, has come to be known as "locality squatting."
In response, additional guidelines were established in 1997 to ensure that delegations were made to entities with a legitimate interest in the delegated locality. Beginning in July 1997, it is assumed that for any new delegations or redelegations, the delegee has the written authorization of the legitimate government for that locality to manage the domain name for that locality. Although this written authorization does not have to be presented at the time of delegation, the delegee might be asked to produce it if the delegation is later contested. Additionally, the administrative contact on the delegation application must be a government representative. Finally, guidelines have also been added stating that no delegee may be responsible for more than 50 localities in one state or 500 localities in total.
Although these guidelines are meant to promote diversity and ensure that legitimate governments are able to choose their own delegated registry operator, analysis of the zone file suggests that problems with "locality squatting" persist in the dot-us subdomains.
Pricing of Registrations
Another important administrative issue in the usTLD is that of cost. The current administrator does not charge customers for registration of a domain name, but they do state that delegees may
E-4
charge a fee for their services, as long as the fee is small, fair, and applied equally to all customers. The definition of "small" is determined by the delegee. In many cases, the "small" fee determined by the delegee is larger than fees most registrars charge for a domain name under dot-com, dot-net, or dot-org. Whereas many registrars now charge under $15 per year to register a domain name under a gTLD, some dot-us delegees charge $25—$30 per year, with additional one-time registration fees. Paired with the long string that constitutes a dot-us domain name, this additional cost is even more likely to deter individuals and businesses from registering under dot-us.
Technical Aspects of the usTLD
Both RFC 1480 and information available through the current usTLD administrator specify the technical requirements for delegees who are responsible for a delegated subdomain. Delegees must provide at least two independent, robust, and reliable nameservers in physically separate locations on the Internet, and any changes to these nameservers must be reported to the domain registry so that they can be reflected in the usTLD zone files. Delegee host computers must also be set up to accept zone transfers from the usTLD registry. All of these technical requirements are essential for the usTLD to remain a viable registry, and any delegee not following these requirements risks having the delegation revoked.
Registration Process
Another important technical issue is that of ease of registration. That is, the registration process is currently a manual one, with no consistent, automatic registration process for registrants. Although registrants can fill out and submit an application online, there is no automatic verification of registration. Registrants have no guarantee that their requested domain name is available and whether that name has been entered into the zone file. Moreover, registration applications can often take several weeks to be processed, and some customers have stated that their applications have not been processed at all. As compared to registration in a gTLD, this process is unreliable and cumbersome.
Whois Service
Today, another essential component of a successful TLD registry is a central, accurate Whois service. RFC 1480 provided for a Whois database only through the third level, intending that delegees and subdelegees would eventually run their own Whois databases for their individual branches. Under current administrative practices, the usTLD not only has no central database that can in turn create a central Whois, there is also no mechanism in place for delegees to provision database information to the central registry. Even if delegees wished to provide new Whois information to the usTLD administrator, that capability is currently nonexistent.
In order to remedy the lack of Whois information under the usTLD, the current registry operator installed a client/server Rwhois, (referral Whois) protocol and requested that delegees also operate an Rwhois server for their delegated subdomains. The Rwhois protocol, presented in RFC 1714 in 1994, defines a method for maintaining Whois information on multiple servers while having the ability to answer queries from any of those servers. If a query were made to the usTLD registry's Rwhois server, that server would either respond with its own data or refer to the delegated subdomain's server to return the Whois information.
Although the Rwhois solution appears to be a logical one, three problems prevent it from being successful. First, a central Whois is currently the industry standard for Whois services; Rwhois is generally not considered to be a robust and secure technical solution. Second, the current registry operator has merely requested that delegees install an Rwhois server. Without mandating installation of Rwhois servers, there is no way to build a complete Whois database. Third, there is no easy-to-use,
E-5
Web-based method for Rwhois lookups in the namespace, so any Whois information that is available is difficult to find.
Other Factors
The use of the usTLD has only one restriction—it is intended for entities that have a physical presence in the United States. Yet many Internet users in the United States have little or no knowledge about this namespace. Aside from the individual advertising done by locality delegees, the space is generally not promoted and not advertised. That an individual or company can register in the usTLD space is not widely known; in fact, there are no widely held perceptions regarding the types of entities registered under the usTLD.
For those individuals who do have knowledge of and wish to register in the dot-us space, inconsistent policies among delegees, the lack of a central Whois, and even the need to locate a delegee for individual subdomains creates a degree of difficulty that many registrants would rather not encounter.
Because of the comparative complexity of the namespace and the lack of coordination and marketing, the usTLD has not attracted a high level of domain name registration activity and remains underpopulated in comparison with gTLDs and even other ccTLDs. However, many schools, libraries, state and local governments, and even individuals do retain a domain name within the dot-us namespace. Those current users of the usTLD find the space to be valuable; in fact, many of them depend on it.
The ccTLD Environment
Many countries have already been successful in building awareness and increasing the use of registrations for their country code, while others have had less success. The following page displays data collected on relative successes across three other ccTLDs—dot-de (Germany), dot-uk (United Kingdom), and dot-ca (Canada). These three countries represent differing levels of development in the evolution of their ccTLD space. Based on ccTLD domain name registrations, both Germany and the United Kingdom are characteristic of countries that have created environments that encourage growth. Both countries have experienced thriving markets and have developed mature organizations with extensive distribution networks. Canada has recently converted from a hierarchical structure that was loosely managed, to a flatter, less complex hierarchy with a newly formed administrative organization.
E-6
Success Factors in Administration of other Country Code TLDs
Factors |
Germany (.de) |
United Kingdom (.uk) |
Canada (.ca) |
|||
---|---|---|---|---|---|---|
Administrative Organization | DENIC eG Cooperative | Nominet | CIRA (Canadian Internet Registration Authority) | |||
Policies | Either the domain name owner or the designated administrator of the site must reside in Germany Self identification Can purchase registrations from member organizations only |
No residency restrictions Second-level domain (SLD) structure requires self identification Can purchase registrations from member organizations only | Must meet Canadian presence requirements Citizen Residency Various entities Documentation required Can purchase registrations from member organizations only |
|||
Structure |
Direct registration Can register any name except another TLD name (.arpa, .com, .edu, .gov, .int, .net, .nato, .mil, .org and all country-related TLDs) Cannot register German automobile identification numbers as domain names |
SLD hierarchical structure Commercial—.co.uk Non.commercial—.org.uk Registered.companies only —.plc.uk &.ltd.uk Network Providers—.net.uk Schools—.sch.uk |
Direct Registration Can still register under a geographic hierarchy that was the ccTLD structure until December 1, 2000 |
|||
Price—Wholesale |
US$5—US$10 |
US$5—US$10 |
US$5—US$10 |
|||
Price—Retail |
Generally ccTLDs are considered to be more expensive than gTLDs |
Generally ccTLDs are considered to be more expensive than gTLDs |
US$25—US$40 for one year |
|||
Awareness levels and cultural aspects |
Very well known Available and promoted since 1997 Previous campaigns include organizations giving away .de domain names with additional purchase Nationalistic |
..uk stands for United Kingdom—Abbreviation has meaningful brand acceptance General awareness is high |
CIRA recently became the administrative organization 12.01.00 |
|||
Country Code Domain |
4M names as of 2/2001 |
Growing at 28,000/month |
Growing at 20,000/month |
|||
Name Growth |
Growing at 167,000/month |
|||||
Total population |
83M |
60M |
31M |
|||
Online population |
20.1M |
20M |
13.3M |
|||
Population % online |
24% |
33% |
43% |
E-7
When analyzing the ccTLD administration for these three countries in comparison to the current administration of the usTLD, it becomes apparent that five factors have played an important role in the expansion of the ccTLD space:
In each case, an administrative organization has been assigned to maintain the registry database, and the registry manages a centralized database of information on registered domain names for that country code, assists with administration of the Internet, and provides information about domain name registrations. Neither Germany, the United Kingdom, nor Canada act as registrars. Based on the high number of domain name registrations, clearly DENIC, the German administrative organization, has created one of the most successful environments for TLD expansion. DENIC has managed the deTLD since September of 1997 and has established a wide distribution network that provides extensive opportunities for users to register names with ease.
The policies created to register, administer, and maintain each ccTLD are another contributing factor to the speed of ccTLD growth. Policies that are easily understood and require minimal enforcement establish an environment that simplifies transactions. Both DENIC and Nominet have established registration policies requiring self-selection or self-identification and no documentation for registration; in contrast, the Canadian Internet Registration Authority, CIRA, requires documentation of compliance before domain names can be registered.
The cost of registration plays a significant role in the growth of domain name registrations. gTLDs became competitive in late 1999, and until then, there was no wholesale market opportunity for gTLDs. This has not been true for many ccTLDs. Wholesale prices for ccTLDs in Germany, the United Kingdom, and Canada are relatively consistent in the US$5—US$10 range. With gTLDs fixed at $35 per year, this created a margin opportunity for the members or registrars promoting ccTLDs. With a US$20—US$30 margin opportunity, it was in the best interests of the registrars to heavily promote ccTLDs. With heavy promotion by the registrars, ccTLDs gained a significant increase in awareness and registrations.
Finally, awareness of the ccTLD, coupled with certain cultural aspects impact user acceptance. The United Kingdom has the helpful advantage of having a meaningful TLD. "uk" resonates with the user base of customers within the United Kingdom. This contributes to the overall awareness and general acceptance of the country code. "us" has a similar advantage, with clear recognition of "us" being synonymous with United States. Coupled with strong nationalistic pride, the usTLD should resonate favorably with the citizens of the United States.
Conclusion
The usTLD namespace is underutilized and under-recognized, but it remains a valuable public space. There is room for improvement in any large undertaking, and the usTLD is no exception. We have presented this extensive analysis of the current state of the usTLD and an analysis of ccTLDs in general, because we believe that the only way to make improvements—to expand and enhance the space—is to understand its current successes as well as its shortcomings. Throughout every section of this RFQ response, we have addressed our understanding of the current space along with our plans for its improvement.
The United States is the world's technological leader, and the current state of the usTLD namespace does not positively represent that. By thoroughly studying the current space, and through our careful plan for improvements, we believe that we can make the usTLD space the model for a widely used, visible, and successful country code top-level domain.
E-8
F. Centralized usTLD Database and Enhanced Shared Registration System
NeuStar's Centralized usTLD Database and Enhanced Shared Registration System will modernize the usTLD registry and promote registration in the space.
The infrastructure of the usTLD has not evolved along with other leading Internet registries. DNS standards and policies created at the IETF and ICANN have advanced significantly since the inception of the usTLD and the introduction of RFC 1480, and the usTLD has not kept pace with these advances. Yet it is reasonable for the user community to expect that the registry will be consistent with appropriate industry standards and policies. An outdated infrastructure causes potential users to question the value of acquiring a name in the usTLD name space, and most members of the user community have chosen to register names in other TLDs.
HIGHLIGHTS
There are four specific areas where the usTLD infrastructure is lacking.
If it is to become the model for the world's country code TLDs, the usTLD must have a robust, secure, and reliable infrastructure equal to or better than any other Internet registry. In order to modernize the usTLD infrastructure and provide the services and functions outlined in Section B of this proposal, NeuStar will leverage an enhanced shared registration system as shown in Exhibit F-1, Enhanced SRS, and a centralized usTLD database. This Enhanced SRS and Centralized usTLD database are the central components of NeuStar's usTLD registry, and, in turn, they create the necessary zone files and Whois service required to round out the usTLD infrastructure.
[Exhibit F-1: Enhanced SRS Data Flow illustrates the data flow for processing requests and the data distribution to external systems. Graphic omitted: diagram depicting SRS data flow.]
F-1
F.1 Enhanced Shared Registration System
As stated above, the manual registration process currently used by the usTLD administrator introduces difficulties into the processes of updating zone files, creating a centralized database, tracking changes, and providing a centralized Whois service. Currently, registrants have no guarantee that their registrations have been entered into a database or into the zone file. NeuStar's solution modernizes the registration, so that all of these functions will become automated.
There are a number of methods that could be used to modernize the infrastructure of the usTLD, and nearly all of them are likely to include a Web-based user interface. In fact, an interface that would allow registrations over the Web would be expected, if not demanded by the user community. However, a Web interface that looks better to users but that has no associated capability to update the usTLD database or zone files would not solve the timeliness and reliability problems associated with the manual process. This would be unacceptable to registrars in the expanded name space. They need immediate access to accurate and up-to-date information, and they need to have a machine interface to the registry due to the high volumes of registrations that they would expect.
NeuStar's Solution—Modernizing the Registration Process
NeuStar's modernization of the usTLD registry infrastructure begins with the implementation of an Enhanced shared registration system (Enhanced SRS). The Enhanced SRS is enhanced in that it can accommodate competitive registrars in the expanded space as well as delegated managers and registrants on the locality-based space. The term Enhanced SRS refers to a system that has a mechanized interface to multiple registrars that provides the same service to all of the interconnected registrars. In addition to supporting competitive registrars, NeuStar's Enhanced Enhanced SRS will support delegated managers that are the only entity allowed to register names in their name space. The Enhanced Enhanced SRS will automate the registration process for all name holders.
Due to the nature of the usTLD name space, it is necessary to define the three different registration processes, as shown in Exhibit F-2: (1) registrations in the expanded name space, (2) registrations in the locality-based space where NeuStar is the registrar, and (3) registrations in the locality-based space with existing delegees or subdelegees.
Expanded Name Space
Registrations in the expanded name space will be very similar to registrations in a generic TLD such as.biz, as shown in Exhibit F-3. Registrars will be responsible for the registration of names in the expanded name space, and NeuStar will not act as a registrar for that space. In order for registrars to interface over a mechanized interface with the usTLD registry, NeuStar has developed a protocol called XRP (eXtensible Registry Protocol). This protocol has been developed and is undergoing implementation for the .biz registry. NeuStar is also an active participant at the IETF Provreg Working Group, which is developing an industry standard protocol for an interface between registrars and a registry. NeuStar will ensure that XRP is functionally compatible with the standard developed by the IETF Provreg WG. All usTLD-accredited registrars will be provided with an XRP software toolkit, free of charge.
[Exhibit F-2: NeuStar's Enhanced SRS provides automated registration service to both competitive registrars, in the expanded space and delegated managers in the locality-based space. Profile-based business rules ensure security and integrity for each of the registrars and delegated managers. Graphic Omitted: diagram depicting provisioning interfaces for access to SRS.]
NeuStar will deploy a thick registry, which means that registrars will submit name, registration, and contact information about registrants to the registry, and the registry will store that information in the
F-2
central usTLD database. This information will allow the registry to create a centralized Whois and populate the zone file with the appropriate resource record.
Locality-Based Name Space Where NeuStar is the Registrar
NeuStar will be required to act as a registrar in the locality-based name space in cases of undelegated third-level names. To fulfill this role, NeuStar will implement a Web-based interface for registrants to register names in that space. This interface will be very similar to the way registrants register names with registrars today in generic top level domains (gTLD), such as.com. Upon initial registration registrants will be provided with authenticating information that will need to be submitted for future changes and updates to the registration. This will permit an extra level of security and ensure that the appropriate registrant is modifying the name.
[Exhibit F-3: All Registrars are provided the same level of access to NeuStar's high availability Enhanced SRS. Graphic Omitted: diagram of registrar access to enhanced SRS.]
Just like in the expanded space NeuStar will gather information about the registrant to populate the central usTLD database, create a Whois record, and update the zone file. In addition, NeuStar needs to clear the payment and enter the registrant in NeuStar's Registrant database. There is a clear difference between managing a name for a registrar and managing a name for a registrant. NeuStar understands the importance of treating these two types of registrations differently.
Locality-Based Name Space for Existing Delegees and Subdelegees
Existing delegees and subdelegees will continue to provide registration services to registrants within their designated localities. However, their functions will be expanded so that NeuStar can store information for all of the registrants in the usTLD name space. Delegees and subdelegees will be responsible for providing NeuStar with registration information for each name that they register, as well as contact information for each registrant so that NeuStar can update the central usTLD database and create a Whois record for the registrant. If the delegee or subdelegee chooses to host the registered names on their own name servers then they do not need to provide resource record information to NeuStar. As an additional service, NeuStar will host resource records in the usTLD zone file created at the registry. In cases where delegees and subdelegees choose to take advantage of this option, they will need to provide NeuStar with the appropriate resource record information.
NeuStar will provide a secure Web site where delegees and subdelegees will provision this information with the registry. Each delegee and subdelegee will be provided with authenticating information to ensure that they are modifying records within their name space. However, if a delegee or subdelegee would prefer to interface with the registry over a mechanized interface, they can choose to implement the XRP interface by downloading the tool kit from the usTLD web site.
F.2 Centralized usTLD Database
As noted earlier in this section, RFC 1480 made no provision for a centralized database and Whois in the usTLD space, in the hopes that delegees and subdelegees would maintain their own database and Whois. As the domain name system evolved, it became obvious that this was not the best way to maintain and administer such an important public resource. It is important that the domain name community can easily determine the entities responsible for a domain name. This is important for the proper functioning of the system and the names as well as for ensuring that the entity responsible for the name is complying with appropriate policies and practices. If that information is not centralized, it is difficult to ensure consistency and accuracy.
Additionally, there is little evidence of a publicly available or privately held database of all delegees and subdelegees. While there is a simple contact list which provides delegated names and
F-3
email addresses this is not sufficient for the purposes of ensuring the proper operations of an important public resource. Delegees and subdelegees are clearly held to a higher standard of operations since they are responsible for managing other names. It is critical that the usTLD administrator and the public have very specific and up-to-date information regarding these entities.
In an attempt to provide Whois services, the current administrator implemented a Referral Whois (Rwhois) service, in which delegees and subdelegees were asked to install Rwhois, so that Whois requests could be referred, through the main Rwhois server, down to the individual delegees. This is a solution that could be implemented in both the expanded space as well as the existing locality space. Registrars would maintain the database and Whois data for their customers in the expanded space and delegees and subdelegees would maintain their customer's data and Whois in the locality-based space.
However, Rwhois is generally considered by the technical community to be an inferior and unreliable protocol. Rwhois is not widely deployed and therefore not well understood. This is particularly a problem when the administrator would be relying on potentially thousands of entities (i.e., delegees, subdelegees, and registrars) to deploy and maintain it. A distributed Whois also creates the likelihood of there being inconsistent policies and treatment of name holders. Furthermore, it would be extremely difficult to monitor the compliance of delegees, subdelegees, and registrars if the database and Whois were distributed.
Since the database itself is not publicly accessible (only the Whois data is), a distributed architecture would virtually ensure a lack of consistency to the data that is stored and the manner that it is stored. For example one entity could store data on an Excel spreadsheet where another entity could store data in an Oracle database. One entity could store different data than another entity. This would make the process of transferring registrants from one entity to another much more difficult.
But the most convincing evidence that a distributed database and Whois approach does not work is the fact that this is the current solution deployed in the usTLD, and it is well understood that it is not sufficient.
NeuStar's Solution—A Centralized usTLD Database
In an effort to create a centralized Whois, and in order to be able to provide complete information about nameholders, NeuStar will centralize all pertinent information regarding all names registered in the usTLD name space. There are two broad categories of name holders: (1) registrants and (2) delegated managers, including all delegees, subdelegees. Registrants will register names through a delegated manager in the locality-based name space, and they will register through competitive registrars in the expanded name space. All name holders and registrars will be included in the central usTLD database and the central Whois database.
The Centralized usTLD database will be escrowed on a regular basis with an escrow agent that is acceptable to both NeuStar and the Contracting Officer's Technical Representative (COTR). The Centralized usTLD database is the heart of the usTLD registry; the publicly accessible Whois, the delegated manager Whois and the zone file will all be created from this database. Centralizing and escrowing the registration information will ensure the integrity, security, and reliability of the entire name space.
All Whois information will be free and publicly available over a Web-based interface that will allow for multiple string and field searches. NeuStar will provide a Web site for this purpose as well as providing access over the IANA-approved port 43.
The following table provides details on the Whois information that will be available through the usTLD Web interface and port 43.
F-4
Whois Information Under the usTLD
Registrants in Locality Space |
|
Delegated Managers in Locality Space |
||||
---|---|---|---|---|---|---|
24 | Name of the domain registered | |||||
25 | Internet Protocol (IP) address of the primary nameserver and secondary nameserver(s) for the registered domain name | 32. 33. |
Name of the delegated manager Delegated Manager ID |
|||
26 | Corresponding names of those nameservers | 34. | IP address of the primary nameserver and secondary nameserver(s) for the delegation | |||
27 | Identity of the delegated manager under which the name is registered | 35. | Corresponding names of those nameservers | |||
28 | Creation date of the registration manager | 36. | Date of delegation | |||
29 | Name and postal address of the domain name holder | 37. | Name and postal address of the delegated manager | |||
30 | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the domain name holder | 38. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the delegated manager | |||
31 | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the domain name holder | 39. | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the delegated manager | |||
40. | Web site or other contact information through which registrations can be accepted under the delegation |
Registrants in Expanded Space |
Registrars in Expanded Space |
|||||
---|---|---|---|---|---|---|
41. | Name of the domain registered | 48. | Name of the registrar | |||
42 | IP address of the primary nameserver and secondary nameserver(s) for the registered domain name | 49. 50. |
Registrar ID Registrar status (e.g., active, pending) |
|||
43 | Corresponding names of those nameservers | 51 | Name and postal address of the registrar | |||
44 | Creation date of the registration | 52 | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the registrar | |||
45 | Name and postal address of the domain name holder | 53 | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the registrar | |||
46 | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the domain name holder | 54 | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the billing contact for the registrar | |||
47 | Name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the domain name holder |
F-5
It is necessary to divide the methods for provisioning this information into two categories, existing information and new information. The technical and functional interfaces and methods for provisioning new information are defined earlier in this section.
Provisioning existing information will require an outreach effort to the current delegated managers. The first step is to contact the delegated managers through contact information provided by the current usTLD Administrator, we will request this information as outlined in our Transition Plan, discussed in Section T. This name and contact information can be supplemented by writing a script to "walk the tree." Walking the tree refers to the process of performing a recursive search of the usTLD, which gathers zone file information from delegees and subdelegees and includes all delegations and direct registrations. The zone files of delegated managers include contact information for the delegated manager, and they also include all registrations under the delegated manager's name space. NeuStar has already starting walking the tree and analyzing the results to develop a database of delegated manager contact information and a database of all of the names in the usTLD name space, so that NeuStar will be able to initiate our outreach effort beginning on the day of contract award.
Once the delegated managers have been contacted, they will be provided with a list of the information we would expect to receive from them including a list of names for which we believe they are responsible. We will offer them options as to how they provide us this information. They will be able to provision it on a secure website or they will be able to send us a file in a format provided by NeuStar. It may be necessary for the delegated manager to contact their registrants for some of the information we will be requesting. This will be an iterative process with regular contact between NeuStar and the delegated manager until the information is verified.
Because NeuStar will not necessarily be hosting the resource records associated with names registered to delegated managers, it is possible for the delegated manager to register a name and forget to update NeuStar. In order to ensure that our Centralized usTLD database is accurate and up to date, NeuStar will "walk the tree" continuously and compare the results with information in that database. If there is a difference, we will contact the delegated manager to correct the discrepancy.
Conclusion
If the usTLD is to be considered on par with or better than the rest of the available top-level domains, its registry must contain accurate and up-to-date information pertaining to name registrations and name holders. To accumulate this information on an ongoing basis, NeuStar will use standard practices now common in the domain name registry community. We will provide easy-to-access and easy-to-use tools by which registrants, delegated managers, and registrars can provide this information to us. Accumulating existing information is simply a matter of using data and tools at our disposal to reach out to the existing name holders. While this will be a time consuming task, NeuStar welcomes this as a good opportunity to develop a relationship with the existing user community.
F-6
G. Draft Delegated Managers/Administrator Contract
The delegated Managers/Administrators contract will establish clear and comprehensive parameters for the management of the delegated subdomains
As an important part of its work to centralize and enhance the usTLD delegated space, NeuStar intends to establish comprehensive contractual arrangements with all of the usTLD Delegated Managers. The agreements will establish clear and comprehensive parameters for the management of the delegated subdomains, as well as basic requirements and obligations binding on NeuStar as the usTLD Administrator and the Delegated Manager. In addition, because the usTLD Administrator will not have a direct contractual arrangement with the registrants, these contracts will include "flow through obligations", such as the Nexus requirement or the obligation to provide accurate WHOIS data, that the Delegated Managers will be required to enforce in its contracts with its registrants. These legal relationships will help provide the accountability and administrative certainty necessary to maintain the stable operation of the usTLD.
Recognizing the significant and useful effort that has gone into the development of similar agreements in the ICANN context, these agreements will be patterned after the Registry-Registrar agreement developed for the new gTLDs by ICANN. These agreements contain certain modifications necessary to address the dynamics and specific requirements of the usTLD. Such changes have, however, been kept to a minimum. Use of the existing ICANN agreements as templates will establish a sense of consistency between the usTLD and the DNS at large, as well as providing usTLD users, delegated managers, and registrars a familiar and effective system under which to operate. A template for the Delegated Manager Agreement is attached hereto. This document will be a standard document signed by all usTLD Delegated Managers and will be finalized upon completion of the compliance report described in Section B.4.5 of this Proposal.
WORKING DRAFT DATED JULY 27, 2001
THIS AGREEMENT IS A TEMPLATE TO SHOW THE BASIC STRUCTURE UNDER WHICH NEUSTAR EXPECTS THAT THE DELEGATED MANAGERS MIGHT OPERATE. THIS AGREEMENT WILL BE FINALIZED UPON COMPLETION OF THE COMPLIANCE REPORT DISCUSSED IN SECTION B.4.5 BASED UPON INFORMATION GATHERED IN THAT PROCESS.
usTLD ADMINISTRATOR-DELEGATED MANAGER AGREEMENT
This usTLD Administrator-Delegated Manager Agreement is made and effective as of , 200 , by and between NeuStar, Inc., a Delaware corporation, with its principal place of business located at 1120 Vermont Avenue, Suite 400, Washington, D.C. 20005 ("usTLD Administrator"), and [Delegated Manager's name], a [jurisdiction and type of organization], with its principal place of business located at [Delegated Manager's location] ("Delegated Manager").
WHEREAS, usTLD Administrator has been appointed to be the administrator of the usTLD by the U.S. Department of Commerce, National Institute of Standards and Technology to operate a shared registration system, TLD nameservers, and other equipment for the ".us" top-level domain;
WHEREAS, the usTLD Administrator has entered a usTLD Agreement with the U.S. Department of Commerce, National Institute of Standards and Technology to administer the .us top-level domain
G-1
name and to operate a shared registration system, TLD nameservers, and other equipment for the ".us" top-level domain
WHEREAS, historically the second, third, and in certain cases fourth level sub-domains of the usTLD were geographically and politically defined pursuant to the Internet Engineering Task Force's RFC 1480 (titled The US Domain at www.ietf.or/rfc/rfc1480.txt?number+1480) ("RFC 1480");
WHEREAS, pursuant to the provisions of RFC 1480 and RFC 1591 (titled Domain Name System Structure and Delegation at http://www.isi.edu/in-notes/rfc1591.txt) ("RFC 1591"), in each case as supplemented by the rules and procedures on the.us domain website (http://www.nic.us), as they may be amended from time to time (".US Domain Policies"), Registrar, along with other registrars, currently acts as a registry and registrar for certain third level and fourth-level sub-domain names within the.us top-level domain for a particular locality or localities.
WHEREAS, pursuant to this Agreement, Delegated Manager wishes to continue to provide services pursuant to RFC 1480 and RFC 1591, as supplemented by the policies created and administered by the usTLD Administrator.
NOW, THEREFORE, for and in consideration of the mutual promises, benefits and covenants contained herein and for other good and valuable consideration, the receipt, adequacy and sufficiency of which are hereby acknowledged, usTLD Administrator and Delegated Manager, intending to be legally bound, hereby agree as follows:
1. DEFINITIONS
G-2
Other terms used in this Agreement as defined terms shall have the meanings ascribed to them in the context in which they are defined.
2. OBLIGATIONS OF USTLD ADMINISTRATOR
G-3
G-4
the mechanism for access to and correction of such Personal Data. usTLD Administrator shall take commercially reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction.
3. OBLIGATIONS OF DELEGATED MANAGER
G-5
usTLD System, Delegated Manager hereby grants usTLD Administrator a non-exclusive, non-transferable, limited license to such data for propagation of and the provision of authorized access to the TLD zone files and as otherwise required in usTLD Administrator's operation of the usTLD.
G-6
4. FEES
G-7
5. CONFIDENTIALITY AND INTELLECTUAL PROPERTY
G-8
6. INDEMNITIES AND LIMITATION OF LIABILITY
G-9
ARISING FROM, THIS AGREEMENT, EVEN IF SUCH PARTY HAS BEEN INFORMED OF THE POSSIBILITY OF SUCH DAMAGES.
7. DISPUTE RESOLUTION
8. TERM AND TERMINATION
G-10
non-breaching party may, by giving written notice thereof to the other party, terminate this Agreement as of the date specified in such notice of termination.
9 MISCELLANEOUS
G-11
provided that the subsequent usTLD Administrator assumes all or substantially all of the duties of usTLD Administrator under this Agreement.
If to Delegated Manager:
|
|
|
|
|
|
with copy to:
|
|
|
|
|
|
G-12
If to usTLD Administrator:
NeuStar, Inc. 1120 Vermont Avenue, N.W. Suite 400 Washington, D.C. 20005 Attn: VP of Policy and Industry Relations phone: fax: |
with a copy to:
NeuStar, Inc. 1120 Vermont Avenue, N.W. Suite 400 Washington, D.C. 20005 Attn: General Counsel phone: fax: |
9.3 Representations and Warranties.
G-13
TOOLKIT, usTLD SYSTEM OR ANY COMPONENT THEREOF WILL BE CORRECTED. FURTHERMORE, usTLD OPERATOR DOES NOT WARRANT NOR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE XRP, APIs, DELEGATED MANAGER TOOLKITS, usTLD SYSTEM OR ANY COMPONENT THEREOF OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. SHOULD THE XRP, APIs, DELEGATED MANAGER TOOLKIT, THE usTLD SYSTEM OR ANY COMPONENT THEREOF PROVE DEFECTIVE, DELEGATED MANAGER ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION OF DELEGATED MANAGER'S OWN SYSTEMS AND SOFTWARE.
In the event of any conflict in this Agreement between this Subsection 9.3.3 and any other provision, this Subsection 9.3.3 will govern and control.
G-14
G-15
IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the date first set forth above.
NeuStar, Inc. | [Name of Delegated Manager] | |||||
By: |
By: |
|||||
Name: | |
Name: | |
|||
Title: | |
Title: | |
G-16
Exhibit A
Delegated Manager Tool Kit
usTLD Administrator-Delegated Manager Software Development Kit includes, but is not limited to the following:
G-17
Exhibit B
Engineering and Customer Service Support
During the Term of this Agreement, usTLD Administrator will provide reasonable telephone and electronic customer support to Delegated Manager, not Registrants or prospective customers of Delegated Manager, for non-technical issues solely relating to the usTLD System and its operation. usTLD Administrator will provide Delegated Manager with a telephone number and e-mail address for such support during implementation of the XRP, APIs and any reference client software included in the Delegated Manager Tool Kit. While e-mail and FAQs are the primary method of help, usTLD Administrator will provide support on a 7-day/24-hour basis. usTLD Administrator will provide a web-based customer service capability in the future and such web-based support will become the primary method of customer service support to Delegated Manager at such time.
The usTLD Administrator provides a clear, concise and efficient deliberation of customer support responsibilities. Delegated Managers provide support to registrants (i.e., Registrants) and registries (like usTLD Administrator) provide support for Delegated Managers. This structure allows the usTLD Administrator to focus its support on the highly technical and administratively complex issues that arise between the usTLD Administrator and the Delegated Manager and to focus on the system operations supporting the usTLD.
Technical Help Systems
usTLD Administrator will provide its Delegated Managers with the following types of technical support:
Web Portal
usTLD Administrator will implement a secure Web-based multimedia portal to help support Delegated Manager operations. To obtain access to these Web-based services, a Delegated Manager must register its registrants usTLD Administrator, and must have implemented our security features, including SSL encryption, log in with user ID and password, and digital certificates for authentication. The home page of the web portal will include a notice to Delegated Managers of planned outages for database maintenance or installation of software upgrades. usTLD Administrator will use commercially reasonable effort to post this notification at least thirty (30) days prior to the event in addition to active notification including phone calls and email. Finally, seven (7) days and again two (2) days prior to the scheduled event, usTLD Administrator will use both an email and a Web-based notification to remind Delegated Managers of the outage.
Non-affiliated Delegated Managers and the general Internet community may obtain generic information from usTLD Administrator's public website, which will describe the TLD service offerings and list of Delegated Managers, including Delegated Manager, providing domain-name services.
G-18
Central Help Desk
In addition to implementing the website, usTLD Administrator will provide telephone support to Delegated Managers through a central Help Desk. Access to the help desk telephone support is through an automatic call distributor that routes each call to the next available customer support specialist. usTLD Administrator will authenticate callers by using caller ID and by requesting a pre-established pass phrase that is different for each Delegated Manager. Requests for assistance may also come to the Help Desk via email, either directly or via the secure website. The Help Desk's three tiers of support are:
Tier-1 Support. Telephone support to Delegated Managers who normally are calling for help with customer domain-name problems and such other issues such as XRP implementation or billing and collection. Problems that can't be resolved at Tier 1 are escalated to Tier 2.
Tier-2 Support. Support provided by members of the technical support team, who are functional experts in all aspects of domain-name registration. In addition to resolving escalated Tier 1 problems with XRP implementation and billing and collection, Tier 2 staff provides technical support in system tuning and workload processing.
Tier 3 Support. Complex problem resolution provided by on-site maintenance technicians, third party systems and software experts, and vendors, depending on the nature of the problem.
In turn, the Help Desk uses an automated software package to collect call statistics and record service requests and trouble tickets in a help desk database. The help desk database documents the status of requests and tickets. Each customer-support and technical support specialist uses this problem management process to respond to trouble tickets with a troubleshooting, diagnosis, and resolution procedure and a root-cause analysis.
Escalation Policy
usTLD Administrator's escalation policy defines procedures and timelines for elevating problems either to functional experts or to management for resolution if they are not resolved within the escalation-policy time limits. The following table is an overview of the escalation policy.
Level |
Description |
Escalation Policy |
Notification |
|||
---|---|---|---|---|---|---|
I | Catastrophic outage affecting overall registry operations | Data-center manager escalates to usTLD Administrator management and Disaster-Recovery Team if not resolved in 15 minutes | Web portal and e-mail notifications to all Delegated Managers within 15 minutes; updates every 30 minutes | |||
II | Systems outage affecting one or two Delegated Manager sessions but not the entire system | Systems engineer escalates to data-center manager if not resolved in one hour | Web-portal notification to all Delegated Managers; hourly updates | |||
III | Technical questions | Help Desk customer-support specialist escalates to the systems engineer if not resolved in two hours | Hourly updates to Delegated Manager via e-mail | |||
IV | Basic questions | Help Desk customer-support specialist escalates to the systems engineer if not resolved within four hours | Hourly updates to Delegated Manager via e-mail |
G-19
Staffing
Initially, usTLD Administrator will staff its Help Desk with a complement of customer service specialists. usTLD Administrator will add staff as necessary to respond to incoming requests within the performance specification guidelines. Customer-service specialists will obtain assistance from usTLD Administrator's technical staff for any problems that cannot be resolved in one (1) phone call.
Test and Evaluation Facility
usTLD Administrator will establish an operational test-and-evaluation facility that will be available for Delegated Managers to test their client XRP system. usTLD Administrator's technical-support team, which consists of functional experts in the processes and technologies for domain-name registration, will support the Delegated Managers' testing.
Once each new Delegated Manager is satisfied that its system is compatible with the usTLD System, it will schedule a formal acceptance test that will be monitored by usTLD Administrator's system engineer. After a Delegated Manager has passed the acceptance test, usTLD Administrator will issue its user id, passwords, and digital certificates, and the Delegated Manager can then begin operations.
Customer Satisfaction Survey
To determine the satisfaction of Delegated Managers with usTLD Services, usTLD Administrator will implement a Web-based customer-satisfaction survey that will consist of a set of survey questions with responses ranging from one to five on the Likert Scale. usTLD Administrator will tabulate the results and plans to publish them on the website periodically.
To further verify the quality of usTLD Administrator's customer services, usTLD Administrator anticipates commissioning a bi-annual customer-satisfaction survey by an independent third party.
G-20
Exhibit C
usTLD Administrator's Operational Standards,
Policies, Procedures, and Practices
I. Registration Requirements
Before the usTLD Administrator will accept applications for registration from a Delegated Manager, all domain name applicants in the.us TLD must:
II. US Nexus Requirement
Registrants in the usTLD must be either:
Whether a prospective registrant has a "bona fide presence in the United States" will be determined on a case-by-case basis in light of all relevant facts and circumstances at the time of application for a usTLD domain name. This requirement is intended to ensure that only those individuals or organizations that have a substantive connection to the United States are permitted to register for usTLD domain names.
Factors that should be considered in determining whether an entity or organization has a bona fide presence in the United States shall include, without limitation, whether such prospective usTLD domain name registrant:
G-21
For purposes of this definition, the terms United States and United States of America shall include all U.S. territories and possessions.
It shall be a continuing requirement that all usTLD domain name registrants maintain the US Nexus Requirement.
The Nexus Requirement will be enforced through an initial screening of the contact information provided by the registrant, as well as a challenge process permitted through the Nexus Dispute Policy discussed below. The screening by usTLD Administrator will verify that selected field, within the contact information provided, on its face, meets the Nexus Requirement and that the registrant has certified compliance with the requirement, as well as certified that the nameservers identified are located within the United States. In the event that the contact information provided does not meet the above requirement, the name requested will be placed on hold within the registry and the registrant will be given an opportunity to correct any mistake or demonstrate compliance with the Nexus requirement. If no action is taken by the registrant within the 30-day period, the registration will be cancelled and the name will be returned to available status. If, on the other hand, the registrant is able to demonstrate compliance with the requirement, the name will be registered.
III. Nexus Dispute Policy
Although the Nexus Requirement will initially be enforced through a usTLD Delegated Manager's screening of the contact information provided by the registrant, and the registrant will certify that it meets at least one of the Nexus requirements set forth above, usTLD Administrator understands that disputes may arise as to the authenticity, veracity or accuracy of the registrant's Nexus certification. Therefore, usTLD Administrator, as administrator of the usTLD has devised a Nexus Dispute Policy ("NDP") which will be administered solely by the usTLD Administrator, or its designated representative. The NDP will provide interested parties with an opportunity to challenge a registration not complying with the Nexus Requirement.
In the event that a third party wishes to challenge the authenticity or veracity of a .US registrant's United States Nexus, that party may submit a "Nexus Challenge" to the usTLD Administrator or its authorized representative. The challenger must submit a written statement to the usTLD Administrator via first class mail alleging in specificity evidence to support its allegation that the registrant fails to meet any of the Nexus Requirements set forth above.
Once a challenge is received by the usTLD Administrator the domain name shall be "locked" by the usTLD Administrator until the matter is resolved. While in a "locked" position, the registrant may not (i) change any of the contact information for that particular domain name or (ii) transfer the domain name to any third party.
In the event that the usTLD Administrator finds that the challenger has established a prima facie case that the registrant has not met any of the Nexus Requirements, the usTLD Administrator shall issue a letter to the registrant to submit evidence of compliance with the Nexus Requirements ("Letter"). The registrant shall have a period of thirty (30) days from the date of the Letter to submit evidence of compliance. If, within the thirty (30) days, the registrant submits evidence establishing any of the Nexus Requirements, the registrant shall be permitted to keep the domain name.
If, however, the registrant either (i) does not respond within the thirty days, or (ii) is unable to demonstrate through documentary evidence that it met any of the Nexus Requirements prior to the
G-22
date the NDP was invoked, the usTLD Administrator shall issue a finding that the registrant has failed to meet the Nexus Requirements. Upon such a finding, the registrant shall be given a total of thirty (30) days to cure the US Nexus deficiency. If the registrant is able to demonstrate within (30) days that it has cured such deficiency, the registrant shall be allowed to keep the domain name. If the registrant either (i) does not respond within the thirty (30) days, or (ii) is unable to proffer evidence demonstrating compliance with the Nexus Requirements, the domain name registration shall be deleted from the registry database and the domain name will be placed into the list of available domain names. This process represents the exclusive remedy for an NDP challenger.
usTLD Administrator reserves the right to modify this NDP at any time with the permission of COTR. usTLD Administrator will post its revised NDP on its Website at least thirty (30) calendar days before it becomes effective.
IV. Reservation
usTLD Administrator reserves the right to deny, cancel or transfer any registration that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, in compliance with any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of usTLD Administrator, as well as its affiliates, subsidiaries, officers, directors, representatives, employees, and stockholders; (4) for violations of this Agreement (including its Exhibits); or (5) to correct mistakes made by usTLD Administrator or any Delegated Manager in connection with a domain name registration. usTLD Administrator also reserves the right to freeze a domain name during resolution of a dispute.
G-23
To be provided with at least 30 days advance notice: Yearly Subscription Fee Rate, One time Usage Fee
NOTE: usTLD Administrator reserves the right to revise the Fees prospectively upon thirty (30) days notice to Delegated Manager, provided that such adjustments are consistent with the usTLD Agreement.
G-24
H. Draft Registrar/Registry Contract
NeuStar will establish appropriate legal relationship's with usTLD Accredited Registrars to provide the accountability and administrative certainty required to maintain the integrity and stability of the usTLD.
As previously noted in Section G, an important part of its work to centralize and enhance the usTLD delegated space, NeuStar intends to establish comprehensive contractual arrangements with all of the usTLD Registrar Delegated Managers. The agreements will establish clear and comprehensive parameters for the management of the enhanced usTLD Registrars, as well as set basic requirements and obligations binding on NeuStar as the usTLD Administrator and the Registrars. In addition, because the usTLD Administrator will not have a direct contractual arrangement with the registrants, these contracts will include "flow through obligations", such as the Nexus requirement or the obligation to provide accurate Whois data, that the Registrar will be required to enforce in its contracts with its registrants. These legal relationships will help provide the accountability and administrative certainty necessary to maintain the stable operation of the usTLD.
Recognizing the significant and useful effort that has gone into the development of similar agreements in the ICANN context, these agreements will be patterned after the Registry-Registrar agreement developed for the new gTLDs by ICANN. As with the agreement with delegated managers, these agreements contain certain modifications necessary to address the dynamics and specific requirements of the usTLD. Such changes have, however, been kept to a minimum. Because the shared registry business model developed for the gTLD space has proven successful and given the similarity of the expanded usTLD to the gTLDs operated under the purview of ICANN, even fewer modifications are warranted The Registry-Registrar Agreement is attached hereto. This document will be a standard document signed by all usTLD registrars and is subject to further revision and final approval by the Contracting Officer.
H-1
WORKING DRAFT DATED JULY 27, 2001
(EXPANDED .US SPACE)
usTLD ADMINISTRATOR-REGISTRAR AGREEMENT
This usTLD Administrator-Registrar Agreement is made and effective as of , 200 , by and between NeuStar, Inc., a Delaware corporation, with its principal place of business located at 1120 Vermont Avenue, Suite 400, Washington, D.C. 20005 ("usTLD Administrator"), and [Registrar's name], a [jurisdiction and type of organization], with its principal place of business located at [Registrar's location] ("Registrar").
WHEREAS, usTLD Administrator has been appointed to be the administrator of the usTLD by the U.S. Department of Commerce, National Institute of Standards and Technology to operate a shared registration system, TLD nameservers, and other equipment for the ".us" top-level domain;
WHEREAS, multiple registrars will provide Internet domain name registration services within the.us top-level domain pursuant to usTLD Administrator-Registrar Agreements substantially similar to this Agreement;
WHEREAS, Registrar wishes to act as a registrar for domain names within the.us top-level domain.
NOW, THEREFORE, for and in consideration of the mutual promises, benefits and covenants contained herein and for other good and valuable consideration, the receipt, adequacy and sufficiency of which are hereby acknowledged, usTLD Administrator and Registrar, intending to be legally bound, hereby agree as follows:
1. DEFINITIONS
H-2
Other terms used in this Agreement as defined terms shall have the meanings ascribed to them in the context in which they are defined.
2. OBLIGATIONS OF USTLD ADMINISTRATOR
H-3
NIST, and Registrar shall not be deemed to be a third-party beneficiary under the usTLD Agreement.
H-4
3. OBLIGATIONS OF REGISTRAR
H-5
a non-exclusive, non-transferable, limited license to such data for propagation of and the provision of authorized access to the TLD zone files and as otherwise required in usTLD Administrator's operation of the usTLD.
H-6
4. FEES
H-7
5. CONFIDENTIALITY AND INTELLECTUAL PROPERTY
H-8
H-9
6. INDEMNITIES AND LIMITATION OF LIABILITY
7. DISPUTE RESOLUTION
H-10
own attorneys' fees in connection with the arbitration, and the arbitrators may not reallocate the attorneys' fees in conjunction with their award. The arbitrators shall render their decision within ninety (90) calendar days of the selection of the third arbitrator. Any litigation brought to enforce an arbitration award shall be brought in a Commonwealth or federal court in the Eastern District of the Commonwealth of Virginia, USA; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of a party during the pendency of an arbitration, each party shall have the right to seek temporary or preliminary injunctive relief from the arbitration panel or any court of competent jurisdiction located in the Eastern District of the Commonwealth of Virginia, USA, which shall not be a waiver of this arbitration agreement. This Agreement shall be construed in accordance with and governed by the laws of the Commonwealth of Virginia (without regard to any rules or principles of conflicts of law that might look to any jurisdiction outside Virginia).
8. TERM AND TERMINATION
H-11
proceedings are instituted by or against Registrar seeking relief, reorganization or arrangement under any laws relating to insolvency or bankruptcy, or seeking any assignment for the benefit of creditors, or seeking the appointment of a receiver, liquidator or trustee of Registrar's property or assets or the liquidation, dissolution or winding up of Registrar's business.
9. MISCELLANEOUS
H-12
If to Registrar:
|
|
|
|
|
|
with copy to:
|
|
|
|
|
|
If to usTLD Administrator:
NeuStar, Inc. 1120 Vermont Avenue, N.W. Suite 400 Washington, D.C. 20005 Attn: VP of Policy and Industry Relations phone: fax: |
with a copy to:
NeuStar, Inc. 1120 Vermont Avenue, N.W. Suite 400 Washington, D.C. 20005 Attn: General Counsel phone: fax: |
H-13
In the event of any conflict in this Agreement between this Subsection 9.3.3 and any other provision, this Subsection 9.3.3 will govern and control.
H-14
representatives, agents, affiliates, and stokholders from all costs and damages (including without limitation reasonable attorneys' fees) which it may suffer by reason of Registrar's failure to indemnify usTLD Administrator as provided above; provided, however, that Registrar's indemnity obligations under this Agreement shall not deemed to be limited by the amount of such insurance. Registrar shall provide a copy of the insurance policy to usTLD Administrator upon usTLD Administrator's request and shall name usTLD Administrator and the other Indemnified Persons as additional insureds under that policy.
H-15
hereto, the prevailing party shall be entitled to recover reasonable attorneys' fees, costs and disbursements (in addition to any other relief to which the prevailing party may be entitled).
H-16
IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the date first set forth above.
NeuStar, Inc. | [Name of Registrar] | |||||
By: |
By: |
|||||
Name: | |
Name: | |
|||
Title: | |
Title: | |
H-17
usTLD Administrator-Registrar Software Development Kit includes, but is not limited to the following:
H-18
Exhibit B
ENGINEERING AND CUSTOMER SERVICE SUPPORT
During the Term of this Agreement, usTLD Administrator will provide reasonable telephone and electronic customer support to Registrar, not Registrants or prospective customers of Registrar, for non-technical issues solely relating to the usTLD System and its operation. usTLD Administrator will provide Registrar with a telephone number and e-mail address for such support during implementation of the XRP, APIs and any reference client software included in the Registrar Tool Kit. While e-mail and FAQs are the primary method of help, usTLD Administrator will provide support on a 7-day/24-hour basis. usTLD Administrator will provide a web-based customer service capability in the future and such web-based support will become the primary method of customer service support to Registrar at such time.
The usTLD Administrator provides a clear, concise and efficient deliberation of customer support responsibilities. Registrars provide support to registrants (i.e., Registrants) and registries (like usTLD Administrator) provide support for registrars. This structure allows the usTLD Administrator to focus its support on the highly technical and administratively complex issues that arise between the usTLD Administrator and the Registrar and to focus on the system operations supporting the usTLD.
Technical Help Systems
usTLD Administrator will provide its registrars with the following types of technical support:
Web Portal
usTLD Administrator will implement a secure Web-based multimedia portal to help support registrar operations. To obtain access to these Web-based services, a registrar must register its registrants usTLD Administrator, and must have implemented our security features, including SSL encryption, log in with user ID and password, and digital certificates for authentication. The home page of the web portal will include a notice to registrars of planned outages for database maintenance or installation of software upgrades. usTLD Administrator will use commercially reasonable effort to post this notification at least thirty (30) days prior to the event in addition to active notification including phone calls and email. usTLD Administrator will also record outage notifications in the help desk database to facilitate compliance with the performance specifications (Exhibit B-2). Finally, seven (7) days and again two (2) days prior to the scheduled event, usTLD Administrator will use both an email and a Web-based notification to remind registrars of the outage.
Non-affiliated registrars and the general Internet community may obtain generic information from usTLD Administrator's public website, which will describe the TLD service offerings and list of registrars, including Registrar, providing domain-name services.
H-19
Central Help Desk
In addition to implementing the website, usTLD Administrator will provide telephone support to registrars through a central Help Desk. Access to the help desk telephone support is through an automatic call distributor that routes each call to the next available customer support specialist. usTLD Administrator will authenticate callers by using caller ID and by requesting a pre-established pass phrase that is different for each registrar. Requests for assistance may also come to the Help Desk via email, either directly or via the secure website. The Help Desk's three tiers of support are:
Tier-1 Support. Telephone support to registrars who normally are calling for help with customer domain-name problems and such other issues such as XRP implementation or billing and collection. Problems that can't be resolved at Tier 1 are escalated to Tier 2.
Tier-2 Support. Support provided by members of the technical support team, who are functional experts in all aspects of domain-name registration. In addition to resolving escalated Tier 1 problems with XRP implementation and billing and collection, Tier 2 staff provides technical support in system tuning and workload processing.
Tier 3 Support. Complex problem resolution provided by on-site maintenance technicians, third party systems and software experts, and vendors, depending on the nature of the problem.
In turn, the Help Desk uses an automated software package to collect call statistics and record service requests and trouble tickets in a help desk database. The help desk database documents the status of requests and tickets. Each customer-support and technical support specialist uses this problem management process to respond to trouble tickets with a troubleshooting, diagnosis, and resolution procedure and a root-cause analysis.
Escalation Policy
usTLD Administrator's escalation policy defines procedures and timelines for elevating problems either to functional experts or to management for resolution if they are not resolved within the escalation-policy time limits. The following table is an overview of the escalation policy.
Level |
Description |
Escalation Policy |
Notification |
|||
---|---|---|---|---|---|---|
I | Catastrophic outage affecting overall registry operations | Data-center manager escalates to usTLD Administrator management and Disaster-Recovery Team if not resolved in 15 minutes | Web portal and e-mail notifications to all Registrars within 15 minutes; updates every 30 minutes | |||
II | Systems outage affecting one or two registrar sessions but not the entire system | Systems engineer escalates to data-center manager if not resolved in one hour | Web-portal notification to all registrars; hourly updates | |||
III | Technical questions | Help Desk customer-support specialist escalates to the systems engineer if not resolved in two hours | Hourly updates to registrar via e-mail | |||
IV | Basic questions | Help Desk customer-support specialist escalates to the systems engineer if not resolved within four hours | Hourly updates to registrar via e-mail |
H-20
Staffing
Initially, usTLD Administrator will staff its Help Desk with a complement of customer service specialists. usTLD Administrator will add staff as necessary to respond to incoming requests within the performance specification guidelines. Customer-service specialists will obtain assistance from usTLD Administrator's technical staff for any problems that cannot be resolved in one (1) phone call.
Test and Evaluation Facility
usTLD Administrator will establish an operational test-and-evaluation facility that will be available for Registrars to test their client XRP system. usTLD Administrator's technical-support team, which consists of functional experts in the processes and technologies for domain-name registration, will support the registrars' testing.
Once each new registrar is satisfied that its system is compatible with the usTLD System, it will schedule a formal acceptance test that will be monitored by usTLD Administrator's system engineer. After a registrar has passed the acceptance test, usTLD Administrator will issue its user id, passwords, and digital certificates, and the registrar can then begin operations.
Customer Satisfaction Survey
To determine the satisfaction of registrars with usTLD Services, usTLD Administrator will implement a Web-based customer-satisfaction survey that will consist of a set of survey questions with responses ranging from one to five on the Likert Scale. usTLD Administrator will tabulate the results and plans to publish them on the website periodically.
To further verify the quality of usTLD Administrator's customer services, usTLD Administrator anticipates commissioning a bi-annual customer-satisfaction survey by an independent third party.
H-21
Exhibit C
ACCREDITATION AGREEMENT
Initial Working Draft Dated July 27, 2001
Registrar Accreditation Agreement
This REGISTRAR ACCREDITATION AGREEMENT ("Accreditation Agreement") is by and between NeuStar, Inc., a Delaware corporation, and [Registrar Name], a [Organization type and jurisdiction] ("Registrar"), and shall be deemed made on [DATE], at Washington, D.C., USA.
H-22
2. NeuStar OBLIGATIONS.
3. REGISTRAR OBLIGATIONS.
H-23
database containing the data elements listed in Subsections 3.2.1.1 through 3.2.1.6 for all active records in the registry sponsored by Registrar, in a format specified by NeuStar.
H-24
H-25
provided that the obligation to pay becomes final and non-revocable by the Registrant upon activation of the registration.
H-26
H-27
against any and all claims, suits, actions, other proceedings, damages, liabilities, costs and expenses of any kind, including without limitation reasonable legal fees and expenses, arising out of or relating to the Registrant's (i) domain name registration and (ii) use of any Registered Name.
H-28
4. PROCEDURES FOR ESTABLISHMENT OR REVISION OF SPECIFICATIONS AND POLICIES.
5. MISCELLANEOUS PROVISIONS.
H-29
H-30
5.3 above) may elect, by giving NeuStar written notice, to enter an agreement in the updated form in place of this Accreditation Agreement. In the event of such election, Registrar and NeuStar shall promptly sign a new accreditation agreement that contains the provisions of the updated form posted on the web site, with the length of the term of the substituted agreement as stated in the updated form posted on the web site, calculated as if it commenced on the date this Accreditation Agreement was made, and this Accreditation Agreement will be deemed terminated.
H-31
NeuStar may, with the written approval of the U.S. Department of Commerce, assign this agreement by giving Registrar written notice of the assignment.
If to Registrar:
with copy to:
If to Registry:
NeuStar, Inc. 1120 Vermont Avenue Suite 400 Washington, DC 20005 Attn: VP of phone: fax: |
H-32
with a copy to:
NeuStar, Inc. 1120 Vermont Avenue Suite 400 Washington, DC 20005 Attn: General Counsel phone: fax: |
H-33
IN WITNESS WHEREOF, the parties hereto have caused this Accreditation Agreement to be executed in duplicate by their duly authorized representatives.
NeuStar, INC. | ||||||
By: |
||||||
Name: | |
|||||
Title: | |
|||||
[Registrar Name] |
||||||
By: |
||||||
Name: | |
|||||
Title: | |
H-34
Working Draft Dated 07-19-01 v1.0
Registrar Accreditation: Application
HOW TO APPLY:
For your application to be considered, you must send hard copies of the following items to NeuStar:
Completed application. A completed application consists of your responses to the questions set forth in this document, typed or printed out on separate paper and attached to a signed copy of this application form.
All supporting documents as indicated below and in the Application Instructions. These will generally include an insurance certificate and an independently verified financial statement, along with any other supporting documents needed to provide complete answers to the questions below. NOTE: Application Instructions will be made available prior to the commencement of the accreditation process.
Application Fee. US $750 (non-refundable). Application fees may be submitted by wire transfer, money order, or bank check, and must be denominated in United States currency. If you want to pay by wire transfer, please send an email to < @NeuStar.com> so we can track your payment. The following is the bank account information you will need to send a wire transfer:
Account number | |
||||
Routing indicator | |
||||
[Name of Bank] Branch # | |
||||
[insert address] | |||||
Telephone [insert telephone number of Bank] |
Completed applications should be sent by mail or courier directly to NeuStar at the following address:
NeuStar, Inc.
Registrar Accreditation
1120 Vermont Avenue, Suite 400
Washington, DC 20005
Phone: (310) 823-9358
NeuStar accepts applications for registrar accreditation on a rolling basis. There is no deadline for receipt of applications for registrar accreditation.
Please provide the following information on separate paper, answering each request in a numbered paragraph corresponding to the number of the question. If there is no answer available for a particular question, please indicate that fact next to the number corresponding to the question. In answering the questions set forth below, please give the most complete answer possible, explaining all capabilities in detail, and attaching, labeling, and referencing all necessary supporting documents at the back of the application. See the Application Instructions for additional guidance.
After reviewing your answers and supporting materials, we reserve the right, in our sole discretion, to request additional information in order to assess your capabilities to serve as an accredited registrar. Submission of any such supplemental information shall be subject to the "ATTESTATION OF TRUTHFUL DISCLOSURE" set forth below.
H-35
Registrar Accreditation Application
GENERAL INFORMATION:
BUSINESS CAPABILITIES:
H-36
If any of the above events have occurred, please provide details.
PAST ICANN ACCREDITATION
H-37
ATTESTATION OF TRUTHFUL DISCLOSURE:
By signing this application, the undersigned Applicant attests that the information contained in this application, and all supporting documents included with this application, are true and accurate to the best of Applicant's knowledge. By signing this application, the undersigned Applicant gives NeuStar permission to contact third parties, investigate, request and obtain additional information and documentation, and otherwise verify the information contained in this application. Applicant waives liability on the part of NeuStar for its actions in verifying the information provided in this application. Applicant further waives liability on the part of any third parties who provide truthful, material, relevant information about Applicant as requested in this application.
Signature |
||
Name (please print) |
||
Title |
||
Name of Applicant Entity |
||
Date |
Please attach all answers and supporting documents to a signed copy of this application form. Please include the application fee and send directly or by courier to NeuStar at the address indicated above.
H-38
EXHIBIT D
POLICY ON TRANSFER OF SPONSORSHIP OF
REGISTRATIONS BETWEEN NON-SPONSORING REGISTRARS
A. Holder-Authorized Transfers.
Registrar Requirements.
The Registration Agreement between each registrar and its Registrant shall include a provision explaining that a Registrant will be prohibited from changing its registrar during the first 60 days after initial registration of the domain name with the registrar. Beginning on the 61st day after the initial registration with the registrar, the procedures for change in sponsoring registrar set forth in this policy shall apply. Enforcement shall be the responsibility of the registrar sponsoring the domain name registration.
For each instance where a Registrant wants to change its registrar for an existing domain name (i.e., a domain name that appears in a particular top-level domain zone file), the gaining registrar shall:
In those instances when the registrar of record denies the requested change of prospective gaining registrar, the registrar of record shall notify the prospective gaining Registrar that the request was denied and the reason for the denial.
Instances when the requested change of prospective gaining registrar may be denied include, but are not limited to:
H-39
In all cases, the losing registrar shall respond to the e-mail notice regarding the transfer request within five (5) days. Failure to respond will result in a default "approval" of the transfer.
usTLD Administrator Requirements.
Upon receipt of the "transfer" command from the gaining registrar, usTLD Administrator will transmit an e-mail notification to both registrars.
usTLD Administrator shall complete the "transfer" if either:
When the usTLD Database has been updated to reflect the change to the gaining registrar, usTLD Administrator will transmit an email notification to both registrars.
Records of Registration.
Each Registrant shall maintain his, her or its own records appropriate to document and prove the initial domain name registration date, regardless of the number of registrars with which the Registrant enters into a contract for registration services.
Effect on Term of Registration.
The completion by usTLD Administrator of a holder-authorized transfer under this Part A shall result in a one-year extension of the existing registration, provided that in no event shall the total unexpired term of a registration exceed ten (10) years.
B. Approved Transfers.
Transfer of the sponsorship of all the registrations sponsored by one registrar as the result of acquisition of that registrar or its assets by another registrar may be made according to the following procedure:
Upon satisfaction of these two conditions, usTLD Administrator will make the necessary one-time changes in the registry database for no charge for transfers involving 50,000 name registrations or fewer; provided that the data to be transferred to usTLD Administrator is in the form specified by usTLD Administrator ("Approved Format"). If the transfer involves registrations of more than 50,000 names, and the data to be transferred to usTLD Administrator is in the Approved format, usTLD Administrator will charge the acquiring registrar a one-time flat fee of US $50,000. If the data to be transferred is not in the Approved Format, the usTLD Administrator may charge a reasonable fee, as determined by the usTLD Administrator, in connection with the cost associated with reformatting such data.
Notwithstanding anything in the Exhibit E above to the contrary, no transfers will be permitted from a registrar, including Registrar, to a Sponsoring Registrar.
H-40
Exhibit E
USTLD ADMINISTRATOR'S OPERATIONAL STANDARDS,
POLICIES, PROCEDURES, AND PRACTICES
I. Registration Requirements
Before the usTLD Administrator will accept applications for registration from an registrar, all domain name applicants in the .us TLD must:
II. US Nexus Requirement
Registrants in the usTLD must be either:
Whether a prospective registrant has a "bona fide presence in the United States" will be determined on a case-by-case basis in light of all relevant facts and circumstances at the time of application for a usTLD domain name. This requirement is intended to ensure that only those individuals or organizations that have a substantive connection to the United States are permitted to register for usTLD domain names.
Factors that should be considered in determining whether an entity or organization has a bona fide presence in the United States shall include, without limitation, whether such prospective usTLD domain name registrant:
H-41
For purposes of this definition, the terms United States and United States of America shall include all U.S. territories and possessions.
It shall be a continuing requirement that all usTLD domain name registrants maintain the US Nexus Requirement.
The Nexus Requirement will be enforced through an initial screening of the contact information provided by the registrant, as well as a challenge process permitted through the Nexus Dispute Policy discussed below. The screening by usTLD Administrator will verify that selected field, within the contact information provided, on its face, meets the Nexus Requirement and that the registrant has certified compliance with the requirement, as well as certified that the nameservers identified are located within the United States. In the event that the contact information provided does not meet the above requirement, the name requested will be placed on hold within the registry and the registrant will be given an opportunity to correct any mistake or demonstrate compliance with the Nexus requirement. If no action is taken by the registrant within the 30-day period, the registration will be cancelled and the name will be returned to available status. If, on the other hand, the registrant is able to demonstrate compliance with the requirement, the name will be registered.
III. Nexus Dispute Policy
Although the Nexus Requirement will initially be enforced through a usTLD Registrar's screening of the contact information provided by the registrant, and the registrant will certify that it meets at least one of the Nexus requirements set forth above, usTLD Administrator understands that disputes may arise as to the authenticity, veracity or accuracy of the registrant's Nexus certification. Therefore, usTLD Administrator, as administrator of the usTLD has devised a Nexus Dispute Policy ("NDP") which will be administered solely by the usTLD Administrator, or its designated representative. The NDP will provide interested parties with an opportunity to challenge a registration not complying with the Nexus Requirement.
In the event that a third party wishes to challenge the authenticity or veracity of a.US registrant's United States Nexus, that party may submit a "Nexus Challenge" to the usTLD Administrator or its authorized representative. The challenger must submit a written statement to the usTLD Administrator via first class mail alleging in specificity evidence to support its allegation that the registrant fails to meet any of the Nexus Requirements set forth above.
Once a challenge is received by the usTLD Administrator the domain name shall be "locked" by the usTLD Administrator until the matter is resolved. While in a "locked" position, the registrant may not (i) change any of the contact information for that particular domain name or (ii) transfer the domain name to any third party.
In the event that the usTLD Administrator finds that the challenger has established a prima facie case that the registrant has not met any of the Nexus Requirements, the usTLD Administrator shall issue a letter to the registrant to submit evidence of compliance with the Nexus Requirements ("Letter"). The registrant shall have a period of thirty (30) days from the date of the Letter to submit evidence of compliance. If, within the thirty (30) days, the registrant submits evidence establishing any of the Nexus Requirements, the registrant shall be permitted to keep the domain name.
If, however, the registrant either (i) does not respond within the thirty days, or (ii) is unable to demonstrate through documentary evidence that it met any of the Nexus Requirements prior to the
H-42
date the NDP was invoked, the usTLD Administrator shall issue a finding that the registrant has failed to meet the Nexus Requirements. Upon such a finding, the registrant shall be given a total of thirty (30) days to cure the US Nexus deficiency. If the registrant is able to demonstrate within (30) days that it has cured such deficiency, the registrant shall be allowed to keep the domain name. If the registrant either (i) does not respond within the thirty (30) days, or (ii) is unable to proffer evidence demonstrating compliance with the Nexus Requirements, the domain name registration shall be deleted from the registry database and the domain name will be placed into the list of available domain names. This process represents the exclusive remedy for an NDP challenger.
usTLD Administrator reserves the right to modify this NDP at any time with the permission of COTR. usTLD Administrator will post its revised NDP on its Website at least thirty (30) calendar days before it becomes effective.
IV. Reservation
usTLD Administrator reserves the right to deny, cancel or transfer any registration that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, in compliance with any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of usTLD Administrator, as well as its affiliates, subsidiaries, officers, directors, representatives, employees, and stockholders; (4) for violations of this Agreement (including its Exhibits); or (5) to correct mistakes made by usTLD Administrator or any registrar in connection with a domain name registration. usTLD Administrator also reserves the right to freeze a domain name during resolution of a dispute.
H-43
To be provided with at least 30 days advance notice: Yearly Subscription Fee Rate, One time Usage Fee
NOTE: usTLD Administrator reserves the right to revise the Fees prospectively upon thirty (30) days notice to Registrar, provided that such adjustments are consistent with the usTLD Agreement.
H-44
Exhibit G
PERFORMANCE SPECIFICATIONS
H-45
receive a response from the usTLD System ("Unavailability"). Service Availability is a C1 priority level.
Service Availability % = {[(TM - POM) - UOM] / (TM - POM)}*100 where:
TM = Total Minutes in the Service Level Measurement Period (#days*24 hours*60 minutes).
POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages during the Service Level Measurement Period).
UOM = Unplanned Outage Minutes (Difference between the total number of minutes of Unavailability during the Service Level Measurement Period minus POM).
Upon written request, and at the sole expense of the requesting registrar(s), usTLD Administrator will retain an independent third party (to be selected by usTLD Administrator to perform an independent calculation of the UOM). The frequency of this audit will be no more than once yearly during the term of the Agreement between usTLD Administrator and the Registrar.
[This calculation is performed and the results reported for each calendar month for SRS and Whois availability and for each calendar year for Nameserver availability. Results will be reported periodically to the Registrar Community via e-mail.]
H-46
H-47
Processing Time refers to the time that the usTLD Administrator receives a request and sends a response to that request. Since each of the usTLD Services has a unique function the Performance Specifications for Processing Time are unique to each of the usTLD Services. For example, a Performance Specification for the Nameserver is not applicable to the SRS and Whois, etc. Processing Time Performance Specifications are a C2 priority level.
Processing Time Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. The usTLD Administrator will log the processing time for all of the related transactions, measured from the time it receives the request to the time that it returns a response.
H-48
The committed Performance Specification with regard to Update Frequency for both the Nameserver and the Whois is 15 minutes for 95% of the transactions. That is, 95% of the updates to the Nameserver and Whois will be effectuated within 15 minutes. This is measured from the time that the registry confirms the update to the registrar to the time the update appears in the Nameserver and Whois. Update Frequency Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis.
H-49
|
Performance Specification Description |
SRS |
Nameserver |
Whois |
||||
---|---|---|---|---|---|---|---|---|
1 | Service Availability | 99.9% per calendar month | 99.999% per calendar year | 99.95% per calendar month | ||||
2 | Processing Time—Add, Modify, Delete | 3 sec for 95% | NA | NA | ||||
3 | Processing Time—Query Domain | 1.5 sec for 95% | NA | NA | ||||
4 | Processing Time—Whois | NA | NA | 1.5 sec for 95% | ||||
5 | Processing Time—Nameserver Resolution | NA | 1.5 sec for 95% | NA | ||||
6 | Update Frequency | NA | 15 min for 95% | 15 min for 95% | ||||
7 | Planned Outage—Duration | 8 hrs per calendar month | not allowed | 8 hrs per calendar month | ||||
8 | Planned Outage—Timeframe | 1201 - 0800 EST Sun | not allowed | 1201 - 0800 EST Sun | ||||
9 | Planned Outage—Notification | 3 days | not allowed | 3 days | ||||
10 | Extended Planned Outage—Duration | 18 hrs per calendar quarter | not allowed | 18 hrs per calendar quarter | ||||
11 | Extended Planned Outage—Timeframe | 1201 - 0800 ETC Sat or Sun | not allowed | 1201 - 0800 ETC Sat or Sun | ||||
12 | Extended Planned Outage—Notification | 28 days | not allowed | 28 days |
H-50
Exhibit H
SERVICE LEVEL AGREEMENT
|
Performance Specification Description |
SRS |
Nameserver |
Whois |
||||
---|---|---|---|---|---|---|---|---|
1 | Service Availability | Table C1a | Table C1b | Table C1a | ||||
2 | Processing Time—Add, Modify, Delete | Table C2 | NA | NA | ||||
3 | Processing Time—Query Domain | Table C2 | NA | NA | ||||
4 | Processing Time—Whois | NA | NA | Table C2 | ||||
5 | Processing Time—Nameserver Resolution | NA | Table C2 | NA | ||||
6 | Update Frequency | NA | Table C3 | Table C3 | ||||
7 | Planned Outage—Duration | Table C4b | NA | Table C4b | ||||
8 | Planned Outage—Timeframe | Table C4a | NA | Table C4a | ||||
9 | Planned Outage—Notification | Table C4a | NA | Table C4a | ||||
10 | Extended Planned Outage—Duration | Table C4b | NA | Table C4b | ||||
11 | Extended Planned Outage—Timeframe | Table C4a | NA | Table C4a | ||||
12 | Extended Planned Outage—Notification | Table C4a | NA | Table C4a |
If one or more SLEs occurs as the direct result of a failure to meet a Performance Specification in a single credit class, usTLD Administrator shall be responsible only for the credit assessed for the credit class which is the proximate cause for all directly related failures.
The following tables identify total Registrar Community credits due for SLEs in the four credit classes C1-C4. Notwithstanding the credit levels contained in these tables, the total credits owed by usTLD Administrator under this Agreement shall not exceed $30,000 USD monthly and $360,000 USD annually. The credits contained in Tables C1a-C4 represent the total credits that may be assessed in a given SLR category in one Service Level Measurement Period.
H-51
Performance Specification Matrix in Exhibit G, usTLD Administrator will credit the Registrar Community according to the tables (which amount will be credited to the Registrar on a proportional basis as set forth above).
SLE |
< 30 sec.'s |
30-60 sec.'s |
1-2 min.'s |
2-10 min.'s |
10-30 min.'s |
over 30 min.'s |
||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Monthly Credit to Registrar Community | $ | 750 | $ | 1,500 | $ | 2,500 | $ | 3,750 | $ | 5,000 | $ | 6,000 |
C1a Availability Example: In a given measurement period, the SRS Availability is 99.87%, which equates to 52 minutes of unplanned downtime. The usTLD Administrator's Performance Specification for SRS Availability is 99.9%, or 43 minutes of downtime. The Service Level Exception, therefore, is 9 minutes (52-43 minutes), the difference between the Performance Specification and the actual measured performance. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C1a. In Table C1a, the time interval (2-10 minutes) has a corresponding credit of $3,750 USD to be paid to the Registrar Community.
SLE |
< 10 min.'s |
10-30 min.'s |
30-60 min.'s |
1-2 hours |
2-4 hours |
over 4 hours |
||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Annual Credit to Registrar Community | $ | 7,500 | $ | 15,000 | $ | 25,000 | $ | 35,000 | $ | 50,000 | $ | 75,000 |
C1b Availability Example: In a given Service Level Measurement Period, the measured Nameserver Availability is 99.990% over a twelve (12) month period, which equates to 52 minutes of downtime. The usTLD Administrator's Performance Specification for Nameserver Availability is 99.999%, or 5 minutes of downtime per calendar year. The Service Level Exception, therefore, is 47 minutes (52-5 minutes), the difference between the Performance Specification and the actual measured performance. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C1b. In Table C1b, the time interval (30-60 minutes) has a corresponding credit of $25,000 USD to be paid to the Registrar Community.
SLE |
< 2 sec.'s |
2-5 sec.'s |
5-10 sec.'s |
10-20 sec.'s |
20-30 sec.'s |
over 30 sec.'s |
||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Monthly Credit to Registrar Community | $ | 375 | $ | 750 | $ | 1,500 | $ | 3,500 | $ | 4,000 | $ | 7,500 |
C2 Processing Example: The Performance Specification for Processing Time for Add, Modify, and Delete is 3 seconds or less for 95% of the transactions. In a given Service Level Measurement Period 7% of the transactions are greater than 3 seconds. The 5% of those transactions with the longest processing times are not subject to the SLE calculation
H-52
(3 seconds for 95%). The SLE is calculated using the average processing time for the 2% of the transactions that are subject to the SLE. If there were 1,000 transactions and they took a total of 4,000 seconds the average is 4 seconds. That generates an SLE of 1 second (4 seconds-3 seconds). From the Credit Lookup Matrix, we see the relevant SLA is found in Table C2. In Table C2, the SLE time interval (< 2 seconds) has a corresponding credit $375 USD to be paid to the Registrar Community.
SLE |
< 30 sec.'s |
30-60 sec.'s |
1-2 min.'s |
2-10 min.'s |
10-30 min.'s |
over 30 min.'s |
||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Monthly Credit to Registrar Community | $ | 188 | $ | 375 | $ | 625 | $ | 938 | $ | 1,250 | $ | 1,500 |
C3 Update Frequency Example: In a given Service Level Measurement Period, 95% of the updates to the Nameserver take 24 minutes or less to complete. The corresponding usTLD Administrator's Performance Specification is 15 minutes for 95% of the updates. The SLE, therefore, is 9 minutes. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C3. The SLE time interval (2-10 minutes) has a corresponding credit of $938 USD to be paid to the Registrar Community.
SLE |
Any |
||
---|---|---|---|
Monthly Credit to Registrar Community | $ | 500 |
C4a Planned Outage Notification Example: In each instance the usTLD Administrator fails to meet the Performance Specifications for Notification and Timeframe related to Planned Outages and Extended Planned Outages, the usTLD Administrator is subject to the credit in Table C4a. For example, the usTLD Administrator informs the Registrar Community that it will initiate a Planned Outage of the SRS on the next calendar Sunday (five (5) days advance notice). The corresponding usTLD Administrator's Performance Specification is 28 days
H-53
notice. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C4a. This results in a credit of $500 USD to be paid to the Registrar Community.
SLE |
< 1 hour |
1-2 hours |
2-4 hours |
4-6 hours |
6-10 hours |
over 10 hours |
||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Monthly Credit to Registrar Community | $ | 300 | $ | 750 | $ | 1,200 | $ | 2,500 | $ | 3,500 | $ | 4,000 |
C4b Planned Outage Example: In a given Service Level Measurement Period, the actual duration of a planned outage is 11 hours and 20 minutes for the SRS. The corresponding usTLD Administrator's Performance Specification is 8 hours per month for the SRS. The SLE, therefore, is 3 hours and 20 minutes. From the Credit Lookup Matrix the relevant SLA is found in Table C4b. The SLE time interval (2-4 hours) has a corresponding credit of $1,200 USD to be paid to the Registrar Community.
4. Obligations.
H-54
Unavailability of Core Services affects all Registrars, the usTLD Administrator is responsible for opening a blanket trouble ticket and immediately notifying all Registrars of the trouble ticket number and details.
5. Miscellaneous.
H-55
During the start-up phase of the expanded usTLD, NeuStar will establish a set of important policies designed to improve and maintain the integrity of the usTLD by protecting important intellectual property rights and ensuring that the usTLD serves the U.S. Internet community.
HIGHLIGHTS
During the expansion of the usTLD, the new administrator will face a number of serious issues similar to those encountered by new gTLDs. These issues include, for example, concerns regarding cybersquatting, the expected "rush" of registrations at the opening of the expanded TLD space, and the need to enforce registration restrictions such as the requirement in the usTLD that registrants be residents of the US. The absence of well structured plans to address such issues indicates a likely inability of the would be administrator to handle the complex process of opening to the public a new TLD space such as the expanded usTLD, and threatens the integrity and ultimately the success of the usTLD. NeuStar has a strong understanding of these issues and has designed start-up policies and procedures to ensure that the integrity of the usTLD is maintained and improved during the critical start-up phases of the expanded usTLD.
NeuStar will implement the following policies and procedures relevant to the start-up phases of the expanded usTLD:
Exhibit I-1 illustrates NeuStar's carefully phased and controlled start-up process.
NeuStar's policy approach is thorough and fair, yet is not heavy-handed. The start-up policies outlined herein are the minimum policies required for a secure and stable start-up of the expanded
I-1
usTLD. In major part, policy in the usTLD will be developed in collaboration with the usTLD community at large.
[Exhibit I-1: The NeuStar start-up process comprises a carefully phased and controlled introduction of the expanded usTLD to ensure the integrity and stability of the usTLD and the Internet. Graphic Omitted: timeline for usTLD startup.]
I-2
J. Registration Process
To ensure rapid acceptance and vigorous marketing of the usTLD by existing and future registrars, as well as to introduce strong competition and innovation, NeuStar will implement a stable, straightforward, and familiar initial registration process for the usTLD domain name based upon the proven business model supported by ICANN.
In many ways, the expansion and enhancement of the usTLD is not unlike the introduction of a new top level domain. Therefore, a new usTLD administrator must take into account the same sets of issues and potential problems relevant to the introduction of a new gTLD. To address these issues and concerns, the chosen usTLD administrator will need a high level of experience in the DNS space, as well as significant resources to ensure stability, integrity, and accuracy of operations in a very dynamic start-up and transition process. NeuStar meets these requirements and has developed strong solutions for the usTLD expansion.
Drawing on the experience and successes of the shared registry business model developed in the context of the gTLDs, NeuStar will implement for the usTLD a clear and familiar process for domain name registration.
NeuStar's expansion of the usTLD will comprise a measured, controlled development of the usTLD consistent with the growth and development of the DNS as a whole. Thus, the expanded usTLD registration processes will be broken into three stages:
Sunrise Program
The Sunrise program will address the important issue of intellectual property rights in names that will become available in an expanded usTLD space. NeuStar agrees that it is critical to have a mechanism for dealing with the problem of "cybersquatting." NeuStar's Sunrise Program is described in detail in Section I of this proposal.
Land Rush Implementation
Subsequent to the Sunrise program for intellectual property holders, the next issue to address is the "Land Rush" phenomenon during a TLD's initial start-up period. This phenomenon, at its most basic level, describes an expected rush of registration requests as potential registrants attempt to capture the most valuable, from their perspective, names in the usTLD space. The expanded usTLD must be introduced in a manner that manages the technical system issues associated with extremely high traffic volumes. In addition, domain names must be allocated in an entirely impartial manner so that no party or parties may claim special privileges in registering a domain name in the expanded
J-1
usTLD space. The principle of neutrality should be the cornerstone of the registry's operation, and it is even more critical during the start-up period. While it is a given that this principle should underpin the registry's operation in general, this is especially true during the start-up period.
It is extremely difficult to accurately predict the initial volume of registration requests. While some basic assumptions will assist in defining boundaries, any solution to the start-up issues must take into account a degree of uncertainty and be able to provide contingencies if demand greatly exceeds predictions. Thus, Land Rush represents a significant issue that the new administrator must deal with immediately upon award by DOC. Indeed, NeuStar submits that the absence of a well-reasoned and comprehensive Land Rush solution in a party's quotation is an indicator of probable failure of transition and implementation after award.
There are several possible ways to approach the issues raised by the Land Rush phenomenon:
An Overview of the Land Rush Solution
As demonstrated in Exhibit J-1, the Land Rush process will provide an effective and fair method for ensuring the stability of the new TLD and the Internet during the initial registration period.
Phase 1: Communication of the Process—To ensure the smooth implementation of the start-up procedures, NeuStar will undertake a proactive educational campaign with registrars. This will involve distribution of information kits by e-mail as well as personal contact from the registry customer support staff and account managers. In this way, registrars will have the opportunity to completely understand the procedures and processes involved in the Land Rush solution. Fortunately, many registrars already are familiar with this process from the introduction of the new ICANN-sponsored gTLDs.
Phase 2: Submission of Registration Lists—Each accredited registrar will provide a list of domain names and registration details. There will be no minimum or maximum limit for the lists. The registration files will be submitted via a secure transport mechanism before a specified closing time for first submissions. Registration lists cannot be modified until the first batch is processed and completed.
J-2
[Exhibit J-1: The NeuStar Land Rush Process ensures complete impartiality in domain name allocation at the registry level—critical to maintaining the integrity of the usTLD. Graphic Omitted: flow chart of land rush process.]
Phase 3: Randomization of Registrar Submitted Lists—The lists submitted by each registrar will be individually randomized and processed to eliminate duplicate domain name registration requests (e.g., four different parties request unclesam.us; one of the requests will be selected, and the others will be deleted from the list).
Phase 4: Compilation and Randomization of Registrar Lists—After initial processing, the entire set of registrar lists will be combined into a single processing file and randomized.
Phase 5: Processing of Randomized List—Once the registration system is activated, a domain name will be randomly selected from the processing list. This domain name will be entered into the registry database. This process repeats until the entire list has been processed. If a chosen domain name is unavailable, then another name is chosen at random from the list until one of the following occurs:
Phase 6: Results—At the end of the list processing, the results of registrations are returned to the registrar.
Phase 7: Commencing Normal Registration Procedures—After returning the results of the Land Rush process to the registrars, the registrars and the public will be advised that the registry will be activated on April 1, 2002 to accept new registrations directly into the registry.
The Benefits of NeuStar's Land Rush Implementation Approach
Incorporating the Land Rush solution into our overall solution provides the following benefits:
The Land Rush solution will moderate the anticipated volume of registration requests without having any significant impact on fairness, stability, or system resources. The NeuStar solution is fully scalable so that stability is ensured, even if registration volumes greatly exceed predictions.
Registrant Post Start-up Registration Process and Requirements
NeuStar's plan to introduce changes in the usTLD that are designed to bring the usTLD into the global Internet infrastructure mandates that such changes be consistent wherever possible with the structures already in place in the global Internet community. Such consistency is required to encourage rapid acceptance of the expanded usTLD space by the Internet community, especially the registrar industry. Strong competition and the rapid uptake of the usTLD will drive the kind of use and innovation of the usTLD desired by the DOC and NeuStar as an applicant for administrating the space.
J-3
Therefore, following the Land Rush period of name registration, NeuStar intends to implement the ICANN registry/registrar business model for the expanded usTLD. This model has proven to be highly successful yet sufficiently flexible to support any modifications necessary to address specific usTLD requirements. This process will apply also to direct registrations performed by NeuStar in the locality-based usTLD.
In this model, the application requires the registrants to provide the necessary registration information through registrars who will have a functional interface with the registry. Registrants will be asked to provide the owner's contact information along with contact information from the administrative, technical, and billing contacts. They will be asked to provide the name and IP address for a primary and secondary nameserver and to certify that these nameservers are located within the United States to ensure compliance with the usTLD Nexus Requirement.
In addition to these items (which are already required for registrations in the existing generic TLDs, with the exception of the nameserver Nexus certification), the registrant will be asked to represent, warrant, and acknowledge that it meets the Nexus Requirement. The Nexus Requirement is set forth in Section B.3.1. Prior to acceptance of a registration, the information provided will be checked to verify that the contact addresses and nameserver addresses meet the Nexus Requirement. If they do not, the registration will be held for a period of 30 days and the potential registrant will be given an opportunity to prove compliance with the Nexus Requirement. Failure to demonstrate compliance will result in cancellation of the registration.
Nexus Requirement Enforcement
NeuStar will require that registrars obtain from the registrant certification that it meets the Nexus Requirement and the manner in which the requirement is met (i.e., citizenship, residence, or bona fide presence). In addition, NeuStar will check selected data provided by the potential registrant to ensure that the contact information establishes the proper US Nexus (e.g., a valid U.S. ZIP code is provided). NeuStar will also check the information provided for the primary and secondary nameservers identified by the potential registrant. The required certification will form the basis for the deletion of a registered name through a usTLD dispute resolution process if the information provided is false. A registration will not be made without a completed certification. The dispute resolution process is discussed in Section B.3.1
Appeal Process
To ensure fairness and neutrality in operations, any individual who is denied a registration will be given an opportunity to ask the usTLD Administrator to review its decision and also to demonstrate that the requested name meets usTLD domain registration requirements. Upon an adequate showing, the individual will be permitted to register the requested name. As a general matter, however, NeuStar does not intend to deny initial registrations unless a given registration does not meet the Nexus Requirement as discussed above.
Registration Cancellation
As discussed above, third parties will have the opportunity to challenge registrations, for example for lack of proper US Nexus, through the usTLD Dispute resolution process discussed in Section B.3.3
J-4
K. Outreach to Current Locality-based usTLD Users
NeuStar believes that community involvement must be the core of any public service operation. Therefore, NeuStar will develop user-friendly, flexible, and effective mechanisms for ensuring input and coordination of the current locality-based usTLD users.
HIGHLIGHTS
As is noted in Section B.4.4, NeuStar is aware that as a result of the comparative complexity of the namespace and the lack of coordination and marketing for the usTLD, the locality-based usTLD has not attracted a high level of domain name registration activity and remains underpopulated in comparison with other ccTLDs. In particular, almost no effort has been made to reach out to locality-based users and stakeholders to further develop and improve the space.
NeuStar has a strong legacy of coordinating complex groups of users in the industries that it serves. Successful administration of public resources, whether they are telephone numbers or domain names, requires strong awareness of constituencies and their needs. NeuStar intends to establish target communication mechanisms, including e-mail listservs, chat services, and other Internet-based services. In addition, NeuStar will utilize traditional customer outreach, such as user group meetings, user support representatives, and other support services to maintain close relationships with usTLD stakeholders. These forums will be tailored to allow users and the public to suggest or recommend additional policies or procedures for the usTLD.
To begin this process, NeuStar will leverage the six-month compliance report process, discussed in detail in Section B.4.5, to develop a strong understanding of stakeholder desires and concerns and to identify the best way to communicate with each constituency group.
Coordination of all usTLD outreach efforts will ultimately be implemented and developed under the auspices of the usTLD Policy Advisory Council. This council will be very important to the ongoing development of usTLD policy and public outreach. The structure and duties of this council, as well as the detailed outline of our basic outreach plan, are discussed in detail in Section B.3.5.
K-1
Past financial performance, the ability to secure capital, and current financial commitment to the development of a next generation Internet registry architecture position NeuStar to fully fund the usTLD at no cost to the US government and position it for a low cost to facilitate registrant adoption by the US public.
HIGHLIGHTS
All stakeholders receive best value as a result of:
The administration of the usTLD is a commercial service offering to the United States at large and should therefore be at no cost to the US government. NeuStar complies with the request in the RFQ that the value of the purchase order related to the coordination and management of the usTLD is $0.00 [cost] to the Department of Commerce, or any other U.S. government body that would assume control of the contract, as shown in NeuStar's Request For Quotation Standard Form 18 (Rev. 6/95) in the first section of this proposal.
NeuStar's Financial Stability
NeuStar, a privately held corporation, has sufficient capital to fully fund the efforts to coordinate and manage the usTLD outlined herein. As demonstrated in the attached financial statements, NeuStar was net income positive for the financial year 2000. The original lines of business are net income and cash flow positive going forward, and have seen substantial growth—revenue has grown from $6 million in 1997 to $67 million in 2000, a CAGR of 126%. These statements illustrate the maturity of the existing registry businesses we have been operating for over 5 years.
NeuStar recently closed on approximately $50 million in equity capital. This capital will fund the design, implementation, and operation of a next generation Internet registry. In addition, NeuStar has a very strong balance sheet and is in the process of securing over $50 million of debt financing, the majority of which will be secured by long-term receivables (a high quality form of security).
In addition to its own fund raising capabilities, NeuStar continues to receive the on-going financial support of its world-class investment partners. NeuStar's majority owner, Warburg Pincus, is one of the largest private equity firms in the United States. Please refer to the letter immediately following this section from Warburg Pincus that outlines its commitment to the success of NeuStar's business.
Registry Fees
To ensure that the usTLD is promoted, successful, and that the best value is received for all constituencies, NeuStar proposes competitive market rates for its next generation registry services related to the coordination and management of the usTLD. Because NeuStar is able to leverage the current Internet registry architecture, many development costs are effectively shared, and offset the incremental spend required for the usTLD, enabling NeuStar to offer a competitive market price for registrations.
Delegee and Registrar Fees
In its role as administrator of the usTLD, NeuStar will be responsible for accreditation and management of commercial registrars. Currently, no ICANN-accredited registrars are eligible for selling second-level registrations for the usTLD. The administrator will have the responsibility of establishing
L-1
criteria, reviewing applications, and integrating accredited registrars to the registry, and managing on-going relations.
NeuStar will follow a similar model to ICANN for selecting registrars and establishing fees to cover administrative expenses. The fees will not exceed those enumerated in the table in the first year; in the subsequent years, the fees will not increase by more than 10% annually. NeuStar will not charge for the registry interface or the operational testing and evaluation (OT&E). All fees are presented in the table below:
Registrar Fees
Application Fee | $1,000 (one time) | |
XRP License | $0 | |
OT&E | $0 | |
Annual Fixed Fee | $1,250 (per year) | |
Variable Fee | $0.05 (per registration) |
Moreover, these fees are designed to cover administrative expenses that are directly attributed to usTLD registrar activity, and are not intended to provide an additional revenue stream for the registry. These fees are implemented to keep the registrant price at a competitive level, further promoting the enhanced utility of the space and driving market adoption.
Registration Fees (Undelegated Localities)
As instructed, the usTLD administrator will act as the registrar for undelegated localities in the locality-based space. In this capacity, and in this space only, NeuStar will provide direct registration services to the registrant. NeuStar will have a discrete registrar function, one that utilizes standard protocols and interfaces with the registry as all other registrars. Were NeuStar to offer these domains at the same price per registration as those charged to delegees and usTLD accredited registrars, it would place NeuStar in a position of under cutting the registrar market rate for domain names.
Based on the incremental work as a registrar and the core principle of enabling adoption, NeuStar proposes the following competitive market rates:
Registration Price
Locality-based Domain Name Registration | $ | 15.00 |
This price could also be interpreted as our recommended retail rate for registrars and delegees. While NeuStar will place no enforcement mechanisms that restrict pricing at the registrar or delegee level, it presents this as a guide.
Registration Fees (to Registrars)
NeuStar will levy domain name registrations fees in a neutral and even-handed manner to all delegees and usTLD-accredited registrars. The domain name registration fee is applicable to all new registrations in NeuStar's usTLD registry.
The usTLD has a legacy, and that legacy comes with an existing base of domain names entered into the registry under varying terms and conditions. NeuStar recognizes that the existing delegations and domain names, though they may have been handled in a different manner than what we propose herein, have nonetheless created a name space and implied rights that must be protected. Those parties with legitimate usTLD domain names today, should continue to hold those names, and NeuStar has no
L-2
desire to remove names from legitimate holders or to levy additional fees from them for what was incurred prior to transition.
Thus, NeuStar recognizes a distinction between the past and the present, and will not charge domain name registration fees for those names in the zone file or applications submitted prior to the submission of this proposal. The distinction will hold only for existing registrations in the locality structure, and all new additions to that structure will be subject to the registry fee structure presented below. This solution is deemed the best value for the usTLD community as it does not rely on the new, expanded space to subsidize all of the locality space, provides a starting point for enactment of new policy, and provides a competitive delegee and registrar environment.
To provide the registry service in a neutral and even-handed fashion on an on-going basis, the domain name registration fees must be comparable for all registrations. By their very nature, domains at any level of hierarchy under the first level require identical levels of technical and operational support. This is NeuStar's rationale behind consistent pricing for new additions in the locality structure and the expanded space.
All fees will be charged to the Registrars and delegees at the time of registration, based on the term length of the registration. The registration applies to all new or renewed names in the registry database (i.e., names under management). The total fee in each instance is equal to the term of the new or renewed registration multiplied by the annual registration. All fees will be debited from the appropriate registrars account with the registry at the time the registration is entered into the registry database, as discussed in NeuStar's proposal Section J. The registration fee for the expanded usTLD will be as follows:
Price
Domain Name Registration | $ | 5.50 |
NeuStar will offer domain name registrations for term lengths, consistent with those available in the gTLD market. Delegees and registrars can offer and select any of the offered registration terms to registrants during our live operation of the usTLD registry. During the Sunrise period, that period which allows legitimate trade and service mark owners to obtain names corresponding to their marks, will have a minimum term of registration of 5 years. This will aid in the on-going protection of those trade and service marks. After this period, all term lengths will be available for registrations.
During the start-up phase of the usTLD, NeuStar will provide enhanced service offerings to further the protection of intellectual property. As discussed in Section B3.3 of NeuStar's response, we will validate trade and service mark requests against an authoritative database during Sunrise to ensure the validity of those requests. Fees for this enhanced Sunrise phase are as follows:
Price
Enhanced Sunrise Fee | $ | 4.50 |
This is a one-time fee, in addition to the standard registration fee, to secure a dot-us domain name during the sunrise phase. The structure is designed to strengthen the Sunrise process, and further serves to illustrate NeuStar's understanding and willingness to protect intellectual property. NeuStar will not charge any other incremental fees during the land rush, batch processing phase of start-up.
Service fees for enhanced applications and service offerings are not included in the domain name registration fee, but will be developed in the course of implementation. All will be competitively priced to suit market needs.
L-3
Optional Hosting Service Fee
To minimize administrative burdens on delegated managers, optional hosting relationships can be offered. It is proposed that the usTLD Administrator host resource records for delegated managers. The price for this hosting service is equivalent to that of a domain name registration, as it is a comparable service to that performed by the Administrator.
NeuStar feels the fees outlined in this section are extremely competitive to the registration prices in the current ccTLD and gTLD markets. These prices are possible because NeuStar is leveraging existing infrastructure and able to compensate for the increased responsibilities with the coordination and management of the usTLD. NeuStar is investing substantial capital into the development of a next generation Internet registry that despite having no comparable market, provides competitive pricing to ensure market adoption and use.
L-4
M. Description of Cost Elements
With over five years of experience designing, implementing, and managing mission-critical public resources, NeuStar confidently presents an illustrative analysis of the costs associated with administration of the usTLD.
HIGHLIGHTS
The development of a next-generation, thick Internet Registry architecture is a high-priority, fully funded, NeuStar initiative. NeuStar has developed an Internet registry business plan with the goal of providing a state-of-the-art, innovative, world-class solution that is reliable and scalable and exceeds customer expectations. NeuStar has analyzed and enumerated the resources required to design, implement, and operate the usTLD registry and has evaluated the market research and general demand for TLDs to develop a registration forecast. Factors such as economies of scope and scale, interoperability, and feasibility were considered in each of the required operational aspects of the registry as well as for the innovations NeuStar is proposing.
In the following section, we provide a qualitative review of the various cost elements associated with operating the registry, managing the existing locality structure, establishing and administering policies, communicating and working with the Department of Commerce's Contracting Officer and other Internet stakeholders, and developing enhanced service offerings and applications to increase the demand and utility of the space.
Expense Estimation
NeuStar's technical solution has been designed to meet or exceed the requirements of the RFQ; the costs associated with delivering this service are discussed in this section. We feel that our past and current experience providing registry services gives us a solid base for generating a resource plan that is realistic and covers all aspects of Registry operation. NeuStar's strong efforts balance the infrastructure, security, and IP issues with providing the best value for coordination and management of the usTLD.
The costs associated with coordination and management of the usTLD registry are variable with respect to registration volume, SRS queries, Whois queries, innovative designs of the registry, the number of accredited registrars, modernization of the locality structure, policy formulation, marketing and outreach, and the ability to provide the highest levels of service. NeuStar has considered each of these determinations when analyzing the costs for each of the resources required to operate a world-class registry. These costs refer to the implementation and transition phases as well as to the continuing operation of the registry business after launch. The resources required to support the development, operation, and ongoing enhancement of the usTLD were derived by weighing technical specifications against market demand in the form of anticipated volumes.
NeuStar is currently developing and implementing this registry architecture through its subsidiary, NeuLevel, and will leverage that development design. When analyzing the usTLD opportunity, proportional allocations are made to develop the stand-alone financial plan (presented in Section N). While there is technical infrastructure to be shared, there are incremental costs associated with an additional TLD, as well as costs unique to the usTLD. All costs associated with coordination and management of the usTLD are presented below, distinguished by capital investment and operational spending.
M-1
Capital Investment
Hardware estimates are inclusive of all incremental hardware components required for ongoing development and operation of the Registry. Software estimates include custom software development to support all registry services described throughout this proposal, as well as third-party software purchases.
As discussed in Section O, Proposed Technical Plan, the physical infrastructure for the registry is a highly scalable design built to operate at high performance and availability levels. The Enhanced Shared Registry System (SRS) data centers are responsible for the core registry functions of adding, modifying, and deleting domain names to the registry. Nameservers that manage the resolution of domain names to IP addresses are colocated. The quantity of application, name, Web and Whois servers; routers; load balancers; and relevant networking equipment is driven by the zone root query volume and size, anticipated demand for usTLD registrations, and the thick registry design.
The software design is an equally large-scale and important facet of the development of a next-generation Internet registry. The custom thick registry architecture that is being developed will provide enhanced service offerings and applications to be seamlessly integrated into the usTLD space. Additionally, this open architecture will allow for ease in scaling the registry hardware as query and registration volumes increase. Currently, as active members in the IETF, we are developing an open interface registry-registrar protocol that will be available at no charge to all usTLD-accredited registrars. In addition to this custom development, NeuStar, as a part of its design, will purchase various third-party software packages.
The capital investment NeuStar is currently making in an Internet registry architecture will not only surpass existing performance and security standards but will serve as a means to promote competition and increase the number of applications available for the usTLD.
Operating Expenses
The management of the usTLD includes developing policy, coordinating the current delegated managers in the locality space, fulfilling the function of registrar for undelegated names in the locality-based space, accrediting registrars, managing operational and technical aspects of the registry, maintaining high levels of security, maintaining facilities for infrastructure and registry employees, providing communication between and within all facets of the registry, enhancing the utility of the space through business development, implementing marketing and outreach programs, and acting as a representative to the ccTLD constituency within ICANN. Each of these items and the cost drivers are explained in the following paragraphs.
Functional Areas
The coordination and management of the usTLD comprises several roles and functions for NeuStar, including transition and integration of new customers, acting as a registrar for undelegated names in the locality structure, and operating a near-real-time registry, as well as a product development role. As a part of its corporate philosophy, NeuStar leverages all corporate functions (i.e., finance and accounting, human resources, legal, media relations, and procurement) across all lines of business.
The generation of the compliance report and recommendations will require unique, individual efforts and external subject matter experts. The scope of this effort includes making direct contact with existing delegees and subdelegees to determine their current technical and operational capabilities, generating an up-to-date database with their contact information, and determining how a central administrator can share some of their responsibilities. NeuStar will leverage knowledge of large outreach programs gained in its experience of transitioning the North American Numbering Plan
M-2
Administration (NANPA) and will solicit the assistance of subject matter experts on the U.S. domain name structure.
Formulation of and monitoring acceptance of policy is another important function that NeuStar will manage as administrator of the usTLD. The policy staff is responsible for coordinating with the usTLD Policy Council on formation of new policies or modification of existing policy. They will communicate with the requisite parties at ICANN, that is, the ccTLD constituency, the GAC, and the Intellectual Property Constituency. This group will also be responsible for accreditation of new usTLD registrars.
Because of their sensitive nature, the registry and registrar functions will be handled separately. NeuStar will have dedicated staff that fulfills the function of registrar for undelegated domains in the locality-based structure of the usTLD; they will not have any responsibilities within the registry operations. This function will act like current registrars with an XRP-like interface into the registry with which they register domains under that delegation.
In its role as central registry, NeuStar has experience managing technical and operational responsibilities. Experienced staff will manage all networks, systems, databases, and hardware to meet the service level requirements of the registry.
Additionally, NeuStar will focus a team of individuals on the increased enhancement of the usTLD through the facilitation of new applications and value-added services to increase the utility of the usTLD. This product development group will coordinate with various public interest groups as well as commercial entities to promote new and innovative extensions to the usTLD.
Expense Categories
New and incremental staffing is required for each functional area of the coordination and management of the usTLD. Through our existing contract with the Federal Communications Commission, NeuStar has government-approved labor burden rates that are factored to all staff rates to cover all employee-related benefits; that rate is 33.3%. For each of the staff members, we have modeled to account for all expenses that are applicable for each function.
The Enhanced SRS and two of the nameserver sites will be housed in NeuStar facilities in Virginia and Illinois. A proportional amount of the space in those data centers is allocated for the Internet registry. In addition to these technical facilities, NeuStar will contract with qualified third parties to host nameservers in geographically disbursed facilities. All usTLD-related staff will occupy space in one of our U.S.-based facilities.
Communications expense is calculated on a cost-per-Megabit rate and is projected to decline on cost at an annual rate of 15%. This includes all bandwidth and capacity requirements at the SRS data centers and the nameserver sites. NeuStar contracts with multiple communications providers to share its communication lines rather than being reliant on a single provider. This protects each phase of the system from outage due to a communication provider's backbone outage.
Significant funds are allocated to the marketing and outreach programs for the usTLD, in conjunction with the marketing plan presented in Section B.2.8 and the outreach programs in Sections B.3.5 This category of expense includes the public relations efforts, the execution of a brand awareness campaign, and any media or collateral related to the usTLD.
In its role as administrator of the usTLD, NeuStar will be an active member of the ccTLD constituency and abide by all policies and best practices established by ICANN. NeuStar will participate in meetings and working groups wherever appropriate to protect the value and autonomy of the usTLD. As a member, NeuStar would be responsible for all funding requirements set forth by ICANN. Currently, there is a formula, composed of a fixed fee and a variable component based on registry
M-3
volume, to determine quarterly "dues" to ICANN. Additionally, NeuStar will be responsible for a membership fee to the ccTLD constituency. NeuStar has included this funding requirement in the financial plan.
As a part of normal operations, NeuStar budgets for ongoing hardware and software maintenance. This provides additional support for all capital expenditures discussed above.
As with the approved labor burden, NeuStar has a government-approved general and administrative rate allocated to all direct expenses that is used in forecasting expenses and generating a competitive price. That rate is 25%.
Each of the enumerated expenses is critical to the efficient coordination and management of the usTLD. NeuStar's extensive experience operating a mission-critical public resource uniquely qualifies us to identify and account for each aspect of our responsibilities. Quantitative analysis for these expenses can be found in the financial statement presented in Section N.
M-4
N. Pro Forma Projections
NeuStar's financial plan for the usTLD reflects the variability of the domain name management of an Internet registry and a pricing option that will pass on economies of scale to registrars and registrants, but that also provides a reasonable profit.
NeuStar recognizes the need of the DOC to determine the fairness and reasonableness of registry prices and assess that the users, citizens of the United States, are receiving the best value. To assist in that assessment, we submit revenue and operating expenses associated with the coordination and management of the usTLD for each of the years in the base term of the DOC's purchase order.
As a part of our proposal for the coordination and management of the usTLD, NeuStar has developed a comprehensive business plan around the anticipated demand for its next-generation, thick Internet registry. Additionally, we have introduced creative pricing structures to pass back economies of scale that we realize. The projections presented below are consistent with the demand enumerated in Section C of NeuStar's response, as well as the technical, operating, and policy functions outlined in Section M.
The expense, both capital and operational, is variable in nature; therefore, the financials presented are a snapshot for a volume range (domain names under management). The incremental expenses increase as volume increases in the registry; thus, if the volume exceeds that presented in this analysis, the expense will also increase.
The financial statements are prepared in accordance with US GAAP. Revenue is calculated on a straight-line basis over the duration of the registration term. Likewise, depreciation and amortization are calculated on a straight-line basis, whereby hardware is depreciated over three (3) years and software amortized over five (5) years. All other expenses are wholly recognized in the period in which they occur. All figures are presented in thousands.
|
Contract Year 1 |
Contract Year 2 |
Contract Year 3 |
Contract Year 4 |
||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Revenue | $ | 2,799.9 | $ | 18,959.1 | $ | 38,840.2 | $ | 49,692.3 | ||||||
Operating |
||||||||||||||
Staffing | 5,151.4 | 6,598.2 | 8,077.4 | 9,269.0 | ||||||||||
Marketing/Outreach | 10,542.7 | 6,442.1 | 7,066.1 | 7,980.0 | ||||||||||
Communication | 239.2 | 777.6 | 1,200.8 | 1,559.2 | ||||||||||
Maintenance | 1,276.7 | 1,377.0 | 1,427.5 | 1,465.1 | ||||||||||
ICANN | 69.5 | 142.4 | 132.2 | 142.7 | ||||||||||
Depreciation and Amortization | 1,268.7 | 1,380.2 | 1,436.3 | 1,391.0 | ||||||||||
Other Direct | 2,259.8 | 2,370.7 | 2,514.7 | 2,640.6 | ||||||||||
Total Operating | 20,808.0 | 19,088.0 | 21,855.0 | 24,447.6 | ||||||||||
G&A |
5,202.0 |
4,772.0 |
5,463.7 |
6,111.9 |
||||||||||
Total |
26,010.0 |
23,860.0 |
27,318.7 |
30,559.5 |
||||||||||
EBIT | (23,210.1 | ) | (4,901.0 | ) | 11,521.5 | 19,132.8 | ||||||||
NeuStar is committed to the financial success of administering the usTLD. The returns NeuStar forecasts here confirm that registry customers are receiving best value for the service provided. This forecast assumes we will be on a strong trajectory as of year four of the contract to receive an adequate return on our investment. We are confident we will meet or exceed the objectives of the DOC, to be eligible for the optional renewals that afford this opportunity.
N-1
NeuStar believes that the financial plan associated with the usTLD is a key evaluation criterion for determining the feasibility of a project. The usTLD administrator must have:
NeuStar fully satisfies all of the aforementioned criteria.
N-2
HIGHLIGHTS
NeuStar's proposed technical solution for usTLD operations meets all of the U.S. Department of Commerce's (DOC's) requirements for the existing and expanded usTLD, in addition to providing numerous improvements and enhancements:
Full Existing and Expanded usTLD Space Support—NeuStar will provide support for the existing usTLD space, which will include support for existing delegees, as well as providing registrar service for new and existing registrants. In addition, NeuStar will provide full registry support to all eligible registrars for the expanded usTLD space.
Database Centralization—NeuStar proposes to implement a Centralized usTLD Database including a Delegated Manager Database and a centralized Whois. This approach will offer improved consistency and accuracy of data.
Improved Reliability—In support of registry, registrar, database, and information services for the usTLD, NeuStar will implement co-active data centers and a number of nameserver data centers to create a resilient infrastructure protected against outages through redundancy, fault tolerance, and geographic dispersion. The benefits to the U.S Internet community are improved availability and better access to DNS services.
Providing Real-Time Responsiveness—NeuStar will implement near-real-time updates to the zone files and the Whois database. The benefit to the U.S Internet community is the elimination of delay-caused confusion over domain name registrations.
Eliminating Bottlenecks—NeuStar's high-availability cluster architecture provides scalable processing throughput, dynamic load balancing between the two data centers, and multiple high-speed Internet connections. The benefit to the Internet user and registrar communities is the elimination of registry bottlenecks.
Encouraging Competition—NeuStar will develop and deploy a new, streamlined registry-registrar protocol for the expanded usTLD space: the eXtensible registry protocol (XRP). The XRP provides more features and functionality than the existing registry/registrar interface and far greater security. The benefits to the Internet community are greatly improved Internet stability and increased public confidence. NeuStar will work with the Internet Engineering Task Force (IETF) to bring the protocol to standard status.
NeuStar's proposed usTLD technical solution is based on our experience with the Number Portability Administration Center (NPAC) and with the.biz registry operations. As requested, Section O.1 provides an overview of our proposed facilities and systems; subsequent sections expand this overview into a comprehensive technical plan for registry operations detailing the equipment software, hardware, and related technology NeuStar will use to meet the usTLD program objectives and needs.
O-1
O.1 Proposed Technical Facilities and Systems
NeuStar proposes world-class redundant Enhanced Shared Registration System (SRS) Data Centers in Virginia and Illinois and initially three Nameserver Data Centers, co-located with the Enhanced SRS Data Centers and a standalone in California, that will provide the facilities and infrastructure to host the usTLD Registry. Our facility locations were selected to give wide geographic separation and provide resilience against natural and man-made disasters. The benefit to the DOC and the Internet community is reliable, non-stop usTLD registry, registrar, database, and information services operation.
NeuStar has developed a redundant facility implementation, high availability cluster server architectures, redundant database technology, and redundant alternate routed network connectivity that successfully supports mission-critical services today. The Internet community needs to be able to depend on the Internet as a stable, highly available infrastructure for worldwide collaboration and commerce.
In the subsection that follows, we describe where the NeuStar facilities are located and provide a functional description and physical description of the Enhanced Shared Registration System (SRS) data center and the nameserver sites. In subsequent subsections, we provide a more detailed system description of each of the systems residing within these facilities.
O.1.1 Registry Facilities Site Description
This section describes NeuStar's proposed usTLD Registry architecture consisting of redundant Enhanced SRS data centers and multiple nameserver sites to provide a seamless, responsive, and reliable registry service to registrars and Internet users. As shown in Exhibit O-1, our TLD registry redundant Enhanced SRS and nameserver data center sites are geographically dispersed and interconnected with a Virtual Private Network (VPN) to provide nationwide coverage and protect against natural and man-made disasters and other contingencies.
O.1.1.1 Enhanced Shared Registration System (SRS) Data Center Functional Description
High availability registry services can be provided only from facilities that have been designed and built specifically for such a critical operation. The NeuStar Enhanced SRS data centers incorporate redundant uninterruptible power supplies; high-capacity ventilation and climate control; fire suppression; physical security; firewalls with intrusion detection; redundant, high availability cluster technology; and redundant network and telecommunications architectures. When selecting the sites, we considered their inherent resistance to natural and man-made disasters. The functional block diagram of our Enhanced SRS data center is depicted in Exhibit O-2. As can be seen from this exhibit, the Enhanced SRS data center is highly redundant and designed for no single point of failure.
Each Enhanced SRS data center facility provides the functions listed in the system function directory table below. Descriptions of the Enhanced SRS systems providing these functions are provided in the next subsection.
[Exhibit O-1: To enhance service availability and reduce the possibility of catastrophic failure, NeuStar will initially deploy three nameservers at sites in CA, VA, and IL. Two of the namserver sites will be co-located with the co-active pair of Enhanced SRS Data Centers. Graphic Omitted: map depicting data center locations.]
[Exhibit O-2: NeuStar's Enhanced SRS data centers feature redundant network connectivity, high availability clusters, and replication to a second data center engineered to provide 99.95% availability and scalability. Graphic Omitted: architectural diagram of the enhanced SRS data center.]
O-2
Enhanced Shared Registration System (SRS) Function Directory
System Function |
Functional Description |
|
---|---|---|
Web Server | High capacity Web Servers provide secure Web services and information dissemination. It contains a registry home page to enable registrars to sign in and inquire about account status, get downloads and whitepapers, access frequently asked questions, obtain self help support, or submit a trouble ticket to the TLD Registry Help Desk. | |
Secure Web Provisioning Interface |
High capacity web servers provide a secure interface for the delegated managers and registrants in the locality space to provision registration data. Delegated managers will be provided with authenticity information that they will need to input to access their account information. Registrants that utilize NeuStar as a registrar will be provided with similar authenticity information for their registrations. This is to ensure that only that registrant can modify the registration. |
|
Protocol (XRP) Servers |
XRP transactions received from registrars undergo front-end processing by the XRP server that manages the XRP session level dialog, performs session level security processing, and strips out transaction records. These XRP transaction records are sent to the Enhanced SRS data center application server cluster for security authentication and business logic processing. |
|
Application Servers |
Processing of the XRP applications business logic, user authentication, posting of inserts, deletes, updates to the master database, and interfaces to authentication, billing and collections, backup, and system/network administration. |
|
Centralized usTLD |
The Centralized usTLD database maintains registry data in a multi-threaded, multi-session database |
|
Database Servers |
for building data-driven publish and subscribe event notifications and replication to downstream data marts such as the Whois, Delegee, Zone, and Billing and Collection services. |
|
Whois Distribution Database |
The Whois Distribution Database is dynamically updated from the Centralized usTLD database and propagates the information to the Whois Database clusters. |
|
Whois Database Clusters |
The Whois Database is dynamically updated from the Whois Distribution Database and sits behind the Whois Server clusters. The Whois Database clusters are used to look up records that are not cached by the Whois Servers. |
|
Whois Servers |
The Load Balanced Whois Server Clusters receive a high volume of queries from Registrants and Internet users. The Whois service returns information about Registrars, domain names, nameservers, IP addresses, and the associated contacts. |
|
O-3
Delegee Whois |
The Delegee Distribution Database is dynamically updated from the Centralized usTLD database and |
|
Distribution Database |
propagates the information to the Delegee Database clusters. |
|
Delegee Whois Database |
The Delegee Database is dynamically updated from the Delegee Distribution Database and sits behind |
|
Clusters |
the Delegee Server clusters. The Delegee Database clusters are used to look up records that are not cached by the Delegee Servers. |
|
Delegee Whois Servers |
The Load Balanced Delegee Server Clusters receive a high volume of queries from Registrants and Internet users. The Delegee service returns information about Registrars, domain names, nameservers, IP addresses, and the associated contacts. |
|
Zone Distribution |
The Zone Distribution Database is dynamically updated from the registry Centralized usTLD database |
|
Database |
and propagated to the nameserver sites located worldwide. It contains domain names, their associated nameserver names, and the IP addresses for those nameservers. |
|
Billing and Collection |
A commercial off-the-shelf system is customized for registry specific eCommerce billing and collection functions that are integrated with XRP transaction processing, the master database and a secure Web server. The system maintains each registrar's account information by domain name and provides status reports on demand. |
|
Authentication Services |
Authentication Service uses commercial X.509 certificates and is used to authenticate the identity of entities interacting with the Enhanced SRS. |
|
Backup Server |
Provides backup and restore of each of the various cluster servers and database servers files and provides a shared robotic tape library facility for central backup and recovery. |
|
Systems/Network |
Provides system administration and simple network management protocol (SNMP) monitoring of the |
|
Management Console |
network, LAN-based servers, cluster servers, network components, and key enterprise applications including the XRP, Web, Whois, Zone, Billing and Collections, Backup/Restore, and database application. Provides threshold and fault event notification and collects performance statistics. |
|
Applications Administration Workstations |
Provides client/server GUI for configuration of Enhanced SRS applications including XRP, Web, Billing and Collection, Database, Authentication, Whois, Zone, etc. |
|
Building LAN |
Provides dual redundant switched Gigabit Ethernet LAN-based connectivity for all network devices in the data center |
|
O-4
Firewall |
Protects the building LAN from the insecure Internet via a Firewall that provides policy-based IP filtering and network-based intrusion detection services to protect the system from Internet hacking and denial of service attacks. |
|
Load Balancers |
Dynamic Feedback Protocol (DFP)—based load balancing of TCP/IP traffic in a server cluster including common protocols such as least connections, weighted least connections, round robin, and weighted round robin. |
|
Telecommunications Access |
Dual-homed access links to Internet Service Providers (ISPs) and Virtual Private Network (VPN) services are used for connectivity to the Internet and the NeuStar Registry Management Network. |
|
Central Help Desk |
A single point of contact telephone and Internet-Web help desk provides multi-tier technical support to registrars on technical issues surrounding the Enhanced SRS. |
O.1.1.2 Nameserver Sites Functional Description
As discussed above, two nameserver sites are co-located at our Enhanced SRS Data Centers and a third nameserver System site is geographically separated with dual-homed Internet and VPN local access telecommunications links to provide resilience and disaster recovery. The additional nameserver site will be installed in a Data Center in California. Additional nameserver sites will be introduced as demand warrants. Additional nameserver sites will be introduced as demand warrants. The functional block diagram of our nameserver sites is depicted in Exhibit O-3. As can be seen from the exhibit, the nameserver sites are configured to be remotely managed and operated "lights out." The hardware configuration is highly redundant and designed for no single point of failure.
[Exhibit O-3: Redundant network components and high availability nameserver cluster provide scalable high availability. Graphic Omitted: architectural diagram of nameserver data center.]
The following function directory table lists the nameserver functions. Descriptions of the systems providing these functions are provided in the next subsection.
O-5
Nameserver Function Directory
System Function |
Functional Description |
|
---|---|---|
Zone Update Database | The Enhanced SRS Zone Distribution Database is propagated to the Zone Update Database Servers at the nameserver sites. Information propagated includes domain names, their associated nameserver names, and the IP addresses for those nameservers. | |
Nameserver |
The nameserver handles resolution of usTLD domain names to their associated nameserver names and to the IP addresses of those nameservers. The nameservers are dynamically updated from the Zone Update Database. Updates are sent over the VPN Registry Management Network. |
|
Building LAN |
Provides dual redundant switched Gigabit Ethernet LAN-based connectivity for all network devices in the data center |
|
Firewall |
Protects the building LAN from the insecure Internet via a Firewall that provides policy-based IP filtering and network-based intrusion detection services to protect the system from Internet hacking and denial of service attacks. |
|
Load Balancers |
Dynamic Feedback Protocol (DFP)—based load balancing of TCP/IP traffic in a server cluster including common protocols such as least connections, weighted least connections, round robin, and weighted round robin. |
|
Telecommunications Access |
Dual-homed access links to Internet Service Providers (ISPs) and Virtual Private Network (VPN) services are used for connectivity to the Internet and the NeuStar Registry Management Network. |
O.1.1.3 Enhanced SRS Data Center and Nameserver Buildings
Each NeuStar data center facility is located in a modern, fire-resistant building that offers inherent structural protection from such natural and man-made disasters as hurricanes, earthquakes, and civil disorder. Sites are not located within a 100-year flood plain. Facilities are protected by a public fire department and have their internal fire-detection systems connected directly to the fire department.
O-6
Data centers are protected from fire by the sprinkler systems of the buildings that house them. Furthermore, each equipment room is protected by a pre-action fire-suppression system that uses Inergen gas as an extinguishing agent.
The environmental factors at the Enhanced SRS Data Center and nameserver sites are listed in the following table.
Environmental Factors at Enhanced SRS Data Center and Nameserver Sites
Ventilation and Climate Control | Dual redundant HVAC units control temperature and humidity. Either unit will maintain the required environment. | |
Lighting |
2x2-foot ceiling-mounted fluorescent fixtures |
|
Control of static electricity |
All equipment-mounting racks are grounded to the building's system, and are equipped with grounding straps that employees wear whenever they work on the equipment. |
|
Primary electrical power |
208-volt, 700-amp service distributed through four power panels |
|
Backup power supply |
30 minutes of 130-KVA UPS power 1000-KVA generator (Enhanced SRS data center) 250-KVA generator (nameserver data center) |
|
Grounding |
All machines are powered by grounded electrical service A 12-gauge cable under the equipment-room floor connects all equipment racks to the building's electrical-grounding network |
Building Security
In addition to providing physical security by protecting buildings with security guards, closed circuit TV surveillance video cameras, and intrusion detection systems, NeuStar vigilantly controls physical access to our facilities. Employees must present badges to gain entrance and must wear their badges at all times while in the facility. Visitors must sign in to gain entrance. If the purpose of their visit is found to be valid, they are issued a temporary badge; otherwise, they are denied entrance. At all times while they are in the facility, visitors must display their badges and must be escorted by a NeuStar employee. Sign-in books are maintained for a period of one year.
Security Personnel
On-site security personnel are on duty 24 hours a day, 7 days a week to monitor the images from closed-circuit television cameras placed strategically throughout the facilities. Security personnel are stationed at each building-access point throughout normal working hours; at all other times (6:30 p.m. to 6:30 a.m. and all day on weekends and major holidays), individuals must use the proper key cards to
O-7
gain access to the buildings. Further, any room housing sensitive data or equipment is equipped with a self-closing door that can be opened only by individuals who activate a palm-print reader. Senior facility managers establish the rights of employees to access individual rooms and ensure that each reader is programmed to pass only authorized individuals. The palm readers compile and maintain a record of individuals who enter controlled rooms.
O.1.2 Enhanced Shared Registration System Descriptions
This section provides system descriptions of the NeuStar Enhanced SRS Data Center sites and the Nameserver Data Center. We provide brief system descriptions and block diagrams of each functional system within the two sites and their network connectivity. The NeuStar usTLD system architecture's central features are as follows:
NeuStar is proposing standard, mid-level, and high-end cluster server platforms for installation at each site. The servers are selected for applications depending on the requirements, storage capacity, throughput, interoperability, availability, and level of security. The generic server platform characteristics are summarized in the following table.
O-8
Server Platform Description
Platform |
Features |
Application |
||
---|---|---|---|---|
Standard Intel Server Clusters |
Rack-mounted Intel 700 Mhz, 32-bit, 2- to 6-way SMP CPUs with 8 GB of ECC memory, CD ROM, four hot-swap disk drives (9-36 MB each), redundant hot swappable power supplies, dual attach 100 BaseT Ethernet Adapter, clustering and event management software for remote management. Red Hat Linux 6.1 |
• Nameserver Cluster • Whois Server Cluster • Backup Server • Network Management Server • Update Servers (Zone/Whois) • XRP Server • Web Server |
||
Mid-level RISC Server Clusters |
RISC 550 Mhz 2- to 8-way SMP, 64-bit CPUs, 32 GB ECC RAM, 72 GB internal disk capacity, 71 TB external RAID, redundant hot swappable power supplies, dual attach Gigabit Ethernet Adapter, clustering and event management software for remote management. Unix 64-bit operating system |
• Application Server Cluster • Billing & Collection Server • Authentication Server • Whois Database Server |
||
High-end RISC Server Cluster |
RISC 550 MHz CPU, 64-bit 2- to 32-way cross-bar SMP with 8x8 non-blocking multi-ported crossbar, 32 GB ECC RAM, 240 MB/sec channel bandwidth, 288 GB Internal mass storage, up to 50 TB external RAID storage, redundant hot swappable power supplies, dual attach Gigabit Ethernet Adapter, clustering and event management software for remote management. Unix 64-bit operating system |
Redundant Server for database system |
O-9
O.1.2.1 Enhanced SRS Data Center System Descriptions
As previously shown in Exhibit O-2, the Enhanced SRS data centers provide co-active fully redundant system configurations with two-way replication over the high-speed VPN Registry Management Network, a co-located complete nameserver cluster, and dual-homed connectivity to the Internet Service Providers (ISPs). Descriptions of each of the systems in the Enhanced SRS Data Center site are as follows.
XRP Server Cluster
XRP transactions received from registrars over the Internet undergo front-end processing by the XRP Server which manages the XRP session level dialog, performs session level security processing, and strips out the transaction records. These XRP transaction records are sent to the Enhanced SRS data center application server cluster for security authentication and business logic processing. The XRP server is a rack-mounted Intel machine with local disk storage. It off-loads the front end processing of the XRP protocol and off-loads the extensive communication protocol processing, session management, and SSL security encryption/decryption from the applications servers. The XRP server strips the fields out of the XML document transaction and builds XRP binary transaction packets that are sent to the application server for initial security authentication and log-on with user ID and password. Once the user is authenticated, the session is active and the XRP application server performs all business logic processing, billing, collection, and database operations.
Nameserver
A complete nameserver cluster for DNS queries is co-located in each Enhanced SRS data center site. As previously shown in Exhibit O-3, the nameserver cluster consists of redundant ISP and Virtual Private Network (VPN) local access links to provide alternate routed connectivity to Internet users and NeuStar's Registry Management Network. Redundant Internet firewalls provide policy-based IP filtering to protect our internal building LAN from intruders and hackers.
Application Server Cluster
The application server cluster is a high availability multiple computer cluster. Each computer within the cluster is a mid-level processor with its own CPU, RAID disk drives, and dual LAN connections. Processor nodes used in the clusters are RISC symmetric multiprocessor (SMP) architectures scalable in configurations from 2- to 8-way with the processing and storage capacity for very large applications. As depicted in Exhibit O-4, the application server cluster is designed to handle the registrar transaction workload and provides the business logic processing applications and interfaces to the authentication server, Centralized usTLD database, and billing and collection system. The application server cluster is front-ended with a TCP/IP load balancer to equitably distribute the processing load across the cluster processors. The cluster manager software monitors hardware and software components, detects failures, and responds by reallocating resources to support applications processing. The process of detecting a failure and restoring the application service is completely automatic—no operator intervention is needed.
Database Server
The database server consists of two identical redundant RISC systems that are designed for high-volume, online transaction-processing (OLTP) database applications. Each server contains high-end RISC processors scalable in configurations from 2-to 32-way SMP. A crossbar-based SMP memory subsystem is capable of supporting up to 32 GB of memory needed to maintain high OLTP transaction workloads. The storage subsystem supports up to 288 GB of internal RAID storage and up to 50 TB of external RAID storage. The database management software is based on a parallel database
O-10
architecture with a redundant server option capable of maintaining 24 × 7 availability. The server supports high availability operations by implementing synchronous replication. The database enables transparent database failover without any changes to application code or the operating system. Clients connecting to a replicated database are automatically and transparently connected to the replicated pair of databases. The database replication feature makes it possible to maintain geographically separated data services for multiple sites over a WAN to provide disaster recovery.
A multi-session, multi-threaded server and dual cache architecture (client/server) provides exceptionally high throughput and fast access to stored objects. A powerful database-driven publish and subscribe event notification system enables applications such as Whois or Zone Distribution to subscribe to a specific Centralized usTLD database activity (e.g., a domain name insert). When the domain name insert occurs, an event is generated by the database to be handled as a dynamic update to the Whois and Zone distribution servers.
[Exhibit O-4: High availability cluster provides scalable throughput to handle projected registrar, delegated manager, and registrant transaction workload. Graphic Omitted: architectural diagram of application server cluster.]
Whois Distribution Database
Certain Centralized usTLD Database events such as a domain name insert, domain name delete, or domain name change, generate a notification to subscriber databases such as the Whois Distribution Database. Modifications to the Whois Distribution Database are replicated to the Whois Database Clusters.
Whois Database
The Whois architecture gives the flexibility to deploy a Whois database to any number of NeuStar Data Centers. In the initial phase, the Whois infrastructure will be deployed to the two Enhanced SRS Data Centers. However, in the future, and based on load placed on the initial two Data Centers, additional infrastructure can be deployed to any of the nameserver Data Centers managed by NeuStar.
Each Whois Database receives replicated updates from the Whois Distribution Database. The initial Whois Database will consist of two mid-level RISC database servers configured in a high availability cluster with RAID storage and from 2- to 8-way SMP processors. Since data is cached in the Whois Servers, the Whois Database is hit only when a Whois Server has not cached a request in memory.
Whois Server Cluster
The Whois service is available to anyone and is engineered to handle large volumes of transactions per day. The cluster is a rack-mount Intel Pentium-based high availability multiple computer cluster that maintains a separate database for domain name registrations and caches commonly requested records. Processor nodes used in the Whois cluster are standard Intel Pentium SMP machines scalable in configurations from 2- to 6-way SMP with local disk storage.
The Whois database contains information about registrants, associated registrars/delegated manager, domain names, nameservers, IP addresses, and the contacts associated with them. This is an improvement over the current registry that provides no end-user contact information. The Whois server cluster is front-ended with a load balancer designed to distribute the load equitably to the servers in the cluster and handle extremely high volumes of queries. The load balancer tracks processor availability and maintains high query processing throughput.
O-11
Delegee Whois Distribution Database
Certain Centralized usTLD database events such as a delegation/sub-delegation insert, delegation/sub-delegation delete, or delegation/sub-delegation change, generate a notification to subscriber databases such as the Delegee Whois Distribution Database. Modifications to the Delegee Whois Distribution Database are replicated to the Delegee Whois Database Clusters.
Delegee Whois Database
The Delegee architecture gives the flexibility to deploy a Delegee Whois database to any number of NeuStar Data Centers. Initially, the Delegee infrastructure will be deployed to the two Enhanced SRS Data Centers. However, in the future, and based on load placed on the initial two Data Centers, additional infrastructure can be deployed to any of the nameserver Data Centers managed by NeuStar.
Each Delegee Whois Database receives replicated updates from the Delegee Whois Distribution Database. The initial Delegee Whois Database will consist of two mid-level RISC database servers configured in a high availability cluster with RAID storage and from 2- to 8-way SMP processors. Since data are cached in the Delegee Whois Servers, the Delegee Whois Database is hit only when a Delegee Whois Server has not cached a request in memory.
Delegee Whois Server Cluster
The Delegee Whois service is available to anyone. The cluster consists of rack-mount Intel Pentium-based high availability multiple computer cluster that maintains a separate database for domain name delegations and caches commonly requested records. Processor nodes used in the Delegee cluster are standard Intel Pentium SMP machines scalable in configurations from 2- to 6-way SMP with local disk storage.
The Delegee Whois database contains information about delegated managers, domain names, nameservers, IP addresses, and the contacts associated with them. The Delegee Whois server cluster is front-ended with a load balancer designed to distribute the load equitably to the servers in the cluster and handle extremely high volumes of queries. The load balancer tracks processor availability and maintains high query processing throughput.
Zone Distribution Database
The Zone Distribution Database is dynamically updated from the Centralized usTLD database using the same technique used for the Whois Distribution Database. The Zone Distribution Database is propagated to Zone Update Database at the nameserver sites using replication. This approach is far better than the current approach of TLD Zone File updates for.com,.net, and.org that occur two times per day.
Billing and Collection Server
The Billing and Collection server is a LAN-based mid-level RISC machine in configurations scalable from 2-to 8-way SMP with the processing and storage capacity for very large enterprise applications. This server runs a commercial off-the-shelf customer relationship management and billing and collection system that interfaces with the Centralized usTLD database.
Secure Web Server Cluster
A high-capacity secure Web Server cluster is provided to enable secure Web services and information dissemination. It contains a registry home page to enable registrars to sign in and inquire about account status, get downloads and white papers, access frequently asked questions, obtain
O-12
self-help support, or submit a trouble ticket to the TLD Registry Help Desk. The Web Server is a rack-mounted Intel machine with local disk storage.
Authentication Server
The authentication server is a LAN-based mid-level RISC machine scalable in configurations from 2- to 8-way SMP with local RAID storage. This server runs commercial X.509 certificate-based authentication services and is used to authenticate the identity of registrars, delegated managers, and registrants, as well as NeuStar personnel. In addition, the authentication server supports our secure Web server portal for customer service functions.
Backup Server
The backup server is an Intel Pentium-based SMP server that runs the backup and restore software to backup or restore each of the various cluster servers and database servers and provide a shared robotic tape library facility. It interfaces to the Intel server clusters and RISC server clusters over a high-speed fiber channel bridge. It interfaces with the high-end redundant database servers via a disk array and the fiber channel bridge that interconnects to the robotic tape library. It is capable of performing remote system backup/restore of the nameservers over the VPN-based Registry Management Network.
System/Network Management Console
The system/network management console provides simple network management protocol (SNMP) monitoring of the network, LAN-based servers, cluster servers, and key enterprise applications including the XRP, Web, Whois, Zone, Billing and Collections, and database applications. The server is a LAN-based standard Intel Pentium-based SMP machine with local RAID disk storage and dual attached LAN interconnections.
Building LAN Backbone
The redundant switched Gigabit Ethernet building LAN backbone gives unprecedented network availability via redundant Gigabit Ethernet switches. Devices are dual attached to each of the gigabit switches to provide a redundant LAN architecture. The building LAN is protected from the insecure Internet via a firewall that provides IP filtering and network-based intrusion detection services to protect the system from Internet hacking and denial of service attacks.
Dual-Homed Telecommunications Access
We are using dual-homed high-speed Internet local access telecommunications links to two separate ISP providers. These links will be alternately routed to provide resilience against cable faults and loss of local access telecommunications links. Similarly, the telecommunications access links to our VPN provider for the Registry management network will be dual-homed and alternate routed.
O-13
O.1.2.2 Nameserver Description
Two nameserver sites are co-located at our Enhanced SRS Data Centers and the third nameserver cluster site is geographically separated, with dual-homed Internet and VPN local access telecommunications links to provide resilience and disaster recovery. The additional zone server clusters will be installed in California, Additional nameserver sites will be installed as demand warrants. The functional block diagram of our nameserver cluster is previously depicted in Exhibit O-3. As can be seen from the exhibit, the nameserver sites are configured to operate "lights out." The hardware configuration is highly redundant and designed for no single point of failure and exceptionally high throughput. The following are the nameserver subsystem functions:
Zone Update Database
The Zone Distribution Database at the Enhanced SRS Data Center is propagated to the Zone Update Database using replication. Replication takes place over the VPN Registry Management Network. The Zone Update Database is not hit when resolving DNS queries; instead, the nameservers update their in-memory database from the Zone Update Database, within defined service levels.
Nameserver Cluster
The nameserver cluster handles resolution of usTLD domain names to their associated nameserver names and to the IP addresses of those nameservers. The resolution service can handle in excess of 500 million queries per day, and our load-balanced architecture allows additional servers to be added to any nameserver cluster to allow on-demand scalability.
The nameserver Cluster is a high availability rack-mounted multiple computer cluster consisting of standard Intel Pentium-based SMP machines configurable from 2- to 6-way SMP with local disk storage and dual attachment to the LAN. A TCP/IP server load balancer switch is used to distribute the load from Internet users. The server load balancer uses dynamic feedback protocol to enable servers to provide intelligent feedback to the load balancer to ensure that traffic is not routed to overutilized servers. The load balancer supports algorithms including least connections, weighted least connections, round-robin, and weighted round-robin.
Building LAN Backbone
A redundant switched Ethernet building LAN backbone maintains high network availability via redundant Ethernet switches. Devices are dual attached to each of the Ethernet switches to provide a redundant LAN architecture. The building LAN is protected from the insecure Internet via a firewall that provides IP filtering and network-based intrusion detection services to protect the system from Internet hacking and denial of service attacks.
O-14
A summary of the features and benefits of our usTLD system architecture is provided in the following table.
usTLD Registry
Feature |
Benefit |
|
---|---|---|
Three classes of scalable processor configuration—standard, mid-level, and high-end | Provides flexible processing power and scalability to the applications | |
Direct Access Storage up to 50 Terabytes for database applications |
Unmatched storage scalability of the database |
|
Switched Gigabit Ethernet Redundant building LAN architecture |
High capacity LAN infrastructure with no bottlenecks |
|
Full Redundancy of all critical components with no single point of failure |
Zero downtime and zero impact to users |
|
Dual-homed, alternate routed local access links to two separate Internet Service Providers |
Maintains connectivity if one of the ISP's services should experience and outage |
|
Dual-homed, VPN connections to the VPN service provider |
Protects against digging accidents that could damage local access cables |
|
Redundant parallel database architecture configured for high |
Non-stop database services and throughput scaled to handle |
|
OLTP transaction throughput |
all registry operations out of one data center. |
|
Load balancing session distribution algorithm (SDA) to intelligently and transparently distribute traffic across servers |
Maximize the number of Transmission Control Protocol/Internet Protocol (TCP/IP) connections managed by a server farm. |
|
Separate Whois Server cluster and datamart to process Whois transactions |
Facilitates rapid response to Whois queries. |
O.1.3 Registry Network System Description
NeuStar is using the Internet to provide connectivity to the Registrars, Delegated Managers, and Registrants (where applicable) and a VPN to provide a secure Registry Management Network for communications between the Enhanced SRS data centers and the nameserver sites.
O.1.3.1 Internet Connectivity
NeuStar will deploy two 45-MB T-3 local access telecommunications links at each of our data centers, enabling each to provide TLD services independently of the other. We will provision 5 MBs of capacity on each of the T-3 links. Therefore, we will provision 10 MB into each nameserver site and have up to 90 MB (2 × 45 MB) of capacity for growth. This should be sufficient growth for at least two years.
Connectivity to each data center will be via redundant routers. For security purposes, the router will be configured to allow only DNS UDP/TCP and BGP4 packets. Each router is connected to a load
O-15
balancer that distributes the query load among the nameservers in that site's cluster. These links will be alternately routed to provide resilience against cable faults and loss of local access telecommunications links. Similarly the telecommunications access links to our VPN provider for the Registry Management Network will be dual-homed and alternate routed. Redundant routers are used for both Internet and VPN access.
O.1.3.2 VPN Registry Management Network
Each Enhanced SRS Data Center is connected to each of the nameserver sites over a VPN. In addition there are two ATM links that connect the two Enhanced SRS Data Centers. Like the Internet access, the ATM links will be delivered over a T-3 local access link. Each link will be configured with some fraction of the full 45 MB of bandwidth. At the nameservers, the two VPN connections will be delivered over a 1.5 MB T-1 local access link. The bandwidth on each of the VPN circuits will be some fraction of the full 1.5 MB. The VPN Registry Management Network is a secure network used for NeuStar internal registry information exchange. It handles:
O.1.4 Registry System Application Software
Supporting existing delegees and registrants, as well as planning for the growth associated with domain registration and administration in the expanded usTLD space, requires vision and a flexible design. NeuStar's vision is to successfully conduct leading-edge software engineering and product development that will address the needs of each of the usTLD registry's sets of customers. NeuStar's proven record of successful development and implementation of large projects benefits the COTR by reducing technical and schedule risk.
NeuStar software components are developed using open system and software standards to facilitate cost-effective application expansion and upgrade. The functional design consists of a number of components representing a blend of:
O.1.4.1 Application Components
The following components, illustrated in Exhibit O-5, deliver the Registry application functionality:
O-16
Further information regarding these components is presented in the following paragraphs.
Protocol Adapter Component
The protocol adapter component is the software module running on the XRP protocol servers. This component provides the standards based interface between the Registry and the Registrar or Delegee systems. The XRP protocol will be based on open industry standards such as:
The protocol adapters will receive secure, encrypted data from Registrar/Delegee systems. They will convert the verbose external XML message into a compact binary internal message format, which is delivered to the application server's process manager for processing. When processing is complete, the process manager will send the binary internal message back to the protocol adapters for conversion to the protocol appropriate for communicating with the external system (i.e., XRP).
The protocol adaptor architecture allows NeuStar to support a simple but powerful XML-based protocol supporting a comprehensive security policy, while eliminating additional load that would otherwise be placed on the core Enhanced SRS system.
[Exhibit O-5: High-level architecture illustrates a high level view of the Enhanced SRS and the interactions with external systems. Graphic Omitted: architectural diagram of the registry system.]
Application Server Component
The design of the application server component is modular and flexible to support the requirements and scalable to meet demands placed on the system. The application server utilizes a stateless architecture that allows scalability simply by adding additional machines to the tier. The core business logic is built into the application server component. This component manages all back-end resources and performs services such as connection pooling and monitoring.
The process engines defined in this section are some of the major functional components of the system. Process engines will be added and configured to meet the functional requirements.
Process Manager—is used to manage the different processes supported by the application, including starting processes in a specific order at initialization time, monitoring the health of executing processes, restarting failed processes, and starting new processes to address application load requirements. The process manager mediates processing and information requests from external systems by forwarding requests to the respective process engines.
Process Engines—will perform the underlying processing steps or primitives that are involved in performing the operation. The process engines receive data and parameters from other application
O-17
components, including the process manager. The process engines access data from databases and update the databases while processing a transaction. The primary process engines are:
The functionality of the primary process engines is explained in detail in Sections O.3 and O.6.
Whois Component
Whois-related modifications to the Centralized usTLD database cause equivalent changes to the subscribing Whois Distribution Database. Updates to the Distribution Database are replicated to the Whois Database Cluster at each Enhanced SRS Data Center. Machines in the Whois Server Cluster cache common requests in-memory, taking load off the Whois Database Cluster. Cached items expire after a defined time interval to ensure that Whois data can be guaranteed correct within defined service levels (see Section O.8 for a detailed description of the Whois capabilities). Exhibit O-6 provides a more detailed application architecture overview.
[Exhibit O-6: The application architecture overview provides a high-level view of the registry processes necessary to support registry functionality and interactions with external systems and the Centralized usTLD database. Graphic Omitted: application architecture overview diagram.]
Delegee Component
Delegee-related modifications to the Centralized usTLD database cause equivalent changes to the subscribing Delegee Whois Distribution Database. Updates to the Distribution Database are replicated to the Delegee Database Cluster at each Enhanced SRS Data Center. Machines in the Delegee Whois Server Cluster cache common requests in-memory, taking load off the Delegee Whois Database Cluster. Cached items expire after a defined time interval to ensure that Delegee data can be guaranteed correct within defined service levels (see Section O.9 for a detailed description of the Delegee capabilities). Exhibit O-6 provides a more detailed application architecture overview.
Datastore
The Enhanced SRS architecture includes a co-active databases supporting high availability operations by implementing synchronous replication. This enables transparent database failover without any changes to application code or the operating system. Clients connecting to a co-active database are automatically and transparently connected to the co-active pair of databases.
The architecture utilizes a powerful database-driven publish and subscribe event notification system that enables components such as Whois or Zone Distribution to subscribe to specific Enhanced SRS events. Subscribed events cause dynamic updates to the Whois and Zone distribution servers (see Section O.3 for a detailed description of the Database capabilities).
O-18
Web Server Component
NeuStar will provide usTLD Registry functionality via a Web-based, Internet-accessible interface. Expanded usTLD space registrars, as well as existing usTLD space delegees and registrants will all have the ability to access various registry/registrar functionality via a Web interface.
The guiding principles for the design of the proposed Web Server component are flexibility and security. The Web interface will be accessible over the Internet, using a client Web browser and will be served up by the Registry Web server clusters at the Enhanced SRS Data Centers. The secure Web servers provide front-end HTTPS (secure Web) protocol handling with client browsers accessible over the Internet.
Some of the key features of the Registry Web interface architecture include:
Billing and Collection System
NeuStar will combine our customized B&C methodology that has proved successful in the past with an accounts receivable product to provide comprehensive, secured, high-quality, scalable, and Web-accessible B&C service. The major components of the system will include:
See Section O.6 for a detailed description of the Billing and Collection system along with the interfaces, security, and access privileges.
Nameserver Component
Zone-related modifications to the Centralized usTLD database cause equivalent changes to the subscribing Zone Distribution Database. Updates to the Zone Distribution Database are replicated out to the Zone Update Databases at each nameserver Data Center. Machines in the nameserver cluster reconcile their in-memory database with the Zone Update Database at regular intervals defined in the service level agreement. The entirety of zone data is held memory resident.
Section O.5 explains nameserver architecture in detail, along with the process, software, and advantages.
O.1.4.2 Registry Software Development Methodology
The quick-time-to-market and software technologies required to design and implement the registry software applications dictate software development methodologies that minimize software development
O-19
and reduce development time without sacrificing software quality. NeuStar's technical personnel are experts in software applications development of registry and clearinghouse protocols and software applications used in Internet domain names and phone number registry systems. NeuStar's experience will benefit the COTR by providing software products that meet the functional requirements and operate reliably.
On the basis of our experience, NeuStar is using Rapid Application Development (RAD) methodology and Computer-Aided Software Engineering (CASE) tools for registry software applications development. RAD methodology enables large applications systems to be developed and tested incrementally in planned releases consisting of alpha, beta, and full production versions. We have found that incremental development of software applications is a key success factor in fielding feature-rich software applications that meet business needs. This is because each incremental build provides a testable software product that can be demonstrated to users and stakeholders. Changes can be easily incorporated in the next build cycle, and each successive build provides increased functionality until the full production release is completed, tested, and accepted. NeuStar feels that this approach is ideally suited for allowing new software projects to quickly and fully benefit from our previously developed software applications.
RAD Methodology
In the RAD methodology there are five phases:
Development Tools and Languages
NeuStar is using object-oriented analysis and object-oriented design CASE tools for requirements analysis and detailed software design. We use object-oriented programming, database development tools, and fourth-generation programming languages for software development. The following table gives examples of tools NeuStar has used in the past and will use on the usTLD project.
O-20
usTLD Software Development Tools
Development Tool/Language |
Purpose |
|
---|---|---|
CASE Tools | NeuStar will utilize CASE tools such as Oracle CASE and Rational Rose. These tools provide full feature object-oriented analysis and design. | |
Java, C++, Delphi, SQL |
NeuStar has extensive experience with, and will utilize, these development languages where appropriate to implement all business logic. |
|
CORBA, RMI |
NeuStar has extensive experience with, and will utilize, these Remote object protocols. |
|
Java Servlets, Java Server Pages, Cold Fusion, |
NeuStar has extensive experience with, and will utilize, these Web |
|
CGI-script, XML, and XSL |
development technologies for building Web sites and thin client applications for distribution to a wide range of users. |
O-21
O.2 Registry-Registrar Model and XRP Protocol
In the past, registry/registrar model and their associated protocol is a "thin" (limited amount of data) registry serving a "thick" (more data) registrar. NeuStar will deploy a "thick registry" model, with contact and authentication details stored centrally at the Registry. Under this model, the business relationships would be unchanged: registrants would still deal with the registrar, and the registrars would deal with the registry.
As part of its thick-registry proposal, NeuStar will deploy, the eXtensible Registry Protocol (XRP). The XRP protocol will accommodate both thin and thick registry models. We do not anticipate introducing the XRP protocol until after the initial "land rush" period has ended.
The XRP Protocol provides the following benefits:
O-22
O.3 NeuStar's Database Capabilities
NeuStar will provide, redundant database system capable of managing large databases and high transaction processing loads reliably, with scalable growth to accommodate change.
The database system supports asynchronous replication of data between two co-active Enhanced SRS data centers geographically dispersed. The benefit to the Internet community is reliable, stable operations and scalable transaction processing throughput to accommodate Internet growth.
The heart of the Enhanced SRS is its database systems, which provide not only simple data storage and retrieval capabilities but also the following capabilities:
As applications architectures such as Enhanced SRS become increasingly dependent on distributed client/server communications and processing, system designers must carefully plan where the bulk of the data processing occurs: on the database server, applications server, or client. Our final design will distribute the processing workload in a way that maximizes scalability and minimizes downtime.
This proposal section (O.3) is divided into three major subsections:
O.3.1 Functional Overview—describes the characteristics of the three primary Centralized usTLD databases (i.e., size, throughput, and scalability); database procedures and functions for object creation, editing, and deleting; change notifications; transfer procedures; grace-period functions; and reporting.
O.3.2 Database System Description—describes the database system components, server platforms, and scalability for the three primary databases.
O.3.3 Security and Access Privileges—describes the access controls for granting and denying users and administrators access to the databases.
O.3.1 Functional Overview
As shown in Exhibit O-7, NeuStar's registry will include four major databases:
O-23
database administrators. Customers can view billing data through a secure Web portal with a B&C Applications Programmer Interface (API).
In addition to these databases, the registry will maintain various internal databases to support operations such as authorizing login user ids and passwords, authenticating digital certificates, and maintaining access control lists.
In implementing the Centralized usTLD Database systems, our system designers will carefully analyze the differing requirements for the three major databases and select the optimum solution for each. Design techniques and considerations will include:
[Exhibit O-7: Enhanced SRS Data Flow illustrates the data flow for processing requests and the data distribution to external systems. Graphic Omitted: flow chart of enhanced SRS data flow.]
Database Size, Throughput, and Scalability
The following table lists design parameters for the initial design of the three major databases. The term scalability in the table refers to the database's ultimate capacity expressed as a multiple of the initial design capacity in terms of size and transaction processing power. NeuStar will closely monitor the overall performance and capacity of the database and will pro-actively make adjustments as
O-24
required to keep the database performing at optimal levels. Given technological advances, there really is no practical limit to the overall capacity of the database.
Database Design Parameters
Centralized usTLD Database |
Initial Design Parameter |
|
---|---|---|
Domain registrations | 5 million | |
Registrars | 500 | |
Size of registration object | 10 K | |
Total data | 50 G | |
Database Management System (DBMS) and logs | 3 G | |
Database indexing | 200 G | |
Total size | 250 G | |
Database throughput | TpsC = 1050 | |
Database scalability | 100 times in size, 8 times in processing power |
Billing Database |
Design Parameter |
|
---|---|---|
Billable events per month | 1 million | |
Transaction size | 1 K | |
Transactions per month | 1 G | |
Historical data for 3 months | 3 G | |
Registrars | 200 | |
Registrar billing profile | 30 K | |
Total billing-data | 3 M | |
Total data | 3 G | |
DBMS and logs | 3 G | |
Database indexing | 6 G | |
Total size | 12 G | |
Database throughput | TpsC = 353 | |
Database scalability | From 2-way to 8-way |
Whois Database |
Design Parameter |
|
---|---|---|
Domain registrations | 5 million | |
Registrars | 200 | |
Size of registration object | 4 K | |
Total data | 20 G | |
DBMS and logs | 2 G | |
Database indexing | 100 G | |
Total size | 120 G | |
Database throughput | TpsC = 353 | |
Database scalability | 2-way to 8-way |
Delegee Database |
Design Parameter |
|
---|---|---|
Delegated subdomains | 50,000 | |
Delegated managers | 50,000 | |
Size of subdomain object | 4 K | |
Total data | 40 M | |
DBMS and logs | 2 G | |
Database indexing | 200 M | |
Total size | 240 M | |
Database throughput | TpsC = 353 | |
Database scalability | 2-way to 8-way |
O-25
Past Performance References Information
Required Information |
NeuStar Response |
||
---|---|---|---|
Type of Work | Local Number Portability Administration | ||
Contract Number or Purchase Order Number |
Master Agreements with seven regional LLCs |
||
Duration of the Contract or Purchase Order |
1996-2006 |
||
Dollar value of the Contract or Purchase Order |
Transaction Based with Minimums |
||
Type of Contract or Purchase Order |
Transaction Based with Minimum |
||
Name and Address of Customer Organization |
NAPM LLC, see below for addresses |
||
Technical Point of Contact at Customer Organization for the Contract or Purchase Order |
Michael O'Connor NAPM Co-Chair 1095 Avenue of the Americas Room 3429 New York, NY 10036 TN: 212-395-2976 Fax: 212-575-1157 e-mail: michael.o'connor.iii@verizon.com |
||
Pamela Connell NAPM Co-Chair 1200 Peachtree St., Promenade I, Suite 22E23 Atlanta, GA 30309 TN: 404-810-4762 Fax: 404-810-6422 e-mail: phconnell@att.com |
|||
Information for an Alternative Customer Organization Point of Contact |
Same as above |
||
Detailed Description of the Effort Performed by the Contractor/Subcontractor under the Contract or Purchase Order |
• |
NeuStar operates the master database that contains the call and signaling/routing registry for North America allowing customers to keep their existing phone numbers when changing local service providers. |
|
• |
NeuStar coordinates the porting of local telephone numbers between carriers in North America serving more than 250 service providers daily and porting more than 700,000 numbers each month. |
||
• |
NeuStar provides, directly or indirectly, secure host-to-host administration transaction interfaces to the registry for 5,000 service providers. |
||
• |
NeuStar operates the service to 29 monthly service level agreements including availability (99.99%), transaction response time, throughput, and help desk telephone call answer times. We pay financial penalties for missing any of these levels. |
O-26
Database Procedures and Functions
The database system is critical to the processing of Enhanced SRS business transactions. The Centralized usTLD database and B&C databases are accessed during many registry transactions. If a transaction is completed successfully, the system not only updates these two databases but also the Whois distribution, Delegee distribution and Zone distribution databases (as necessary). Below is a list of some of the functions performed by the Centralized usTLD Database and the Registry:
A typical mass update is a global change of a registrar's name, which may occur when one registrar purchases another. NeuStar will design procedures for mass database changes initiated by registrars, delegees, or other authorized entities.
O.3.2 Database System Description
Although the four primary Centralized usTLD databases—Enhanced SRS, Whois, Delegee, and Billing—will differ, depending upon the services they support, the Enhanced SRS on the whole, will be structured to:
NeuStar forecasts that, as with most OLTP applications, the anticipated volume of Enhanced SRS transactions will have a high ratio of "reads" to "writes." We will design the databases and applications by partitioning the workload to improve response times and scalability.
O-27
Centralized usTLD Database
The Centralized usTLD Database will support and provide information for primary domain registration services. The following table lists the data stored in the Centralized usTLD Database.
Centralized usTLD Database Data
Primary Element |
Details |
|||
---|---|---|---|---|
Domain Names | • | Domain Name Attributes (Status) | ||
• |
Associated Name Servers |
|||
• |
Associated Registrar |
|||
• |
Associated Delegated Manager |
|||
• |
Associated Registrant Data |
|||
Nameserver |
• |
Nameserver Attributes (Status) |
||
• |
Associated IP Addresses |
|||
• |
Associated Registrar |
|||
• |
Associated Delegated Manager |
|||
• |
Associated Registrant Data |
|||
IP Address |
• |
IP Address Attributes (Status) |
||
• |
Associated Nameservers |
|||
• |
Associated Registrar |
|||
• |
Associated Delegated Manager |
|||
• |
Associated Registrant Data |
|||
Registrar List |
Registrar Names |
|||
Registrars |
• |
Registrar Name |
||
• |
Registrar Contact Details |
|||
• |
Registrar URL (Home page) |
|||
• |
Registrar Whois URL (Web Port 80) |
|||
• |
Registrar Whois URL (Port 43, if applicable) |
|||
• |
Registrar Attributes (Status) |
|||
Delegated Manager List |
Delegated Manager Names |
|||
Delegated Managers |
• |
Delegated Manager Name |
||
• |
Delegated Manager Contact Details |
|||
• |
Delegated Manager URL (Home page) |
|||
• |
Delegated Manager Attributes (Status) |
O-28
NeuStar will configure the database system to provide appropriate response times. We will plan capacity to ensure that as business requirements increase and demand for domain names grows, the system will be able to handle the workload within the agreed upon response times.
Centralized usTLD Database Platform
For the Centralized usTLD Database platform, NeuStar will use a business-critical-proven, high-performance, data center computing platform with the following characteristics:
The Centralized usTLD Database server will use the Unix 64-bit operating system with controlled-access security.
NeuStar will have vendor support agreements to keep the systems running and to repair or replace components immediately if problems occur.
Scalability
In planning for growth, NeuStar will design a database system with the ability to add resources on an as-needed basis without interrupting processing. Because database growth can occur in several areas, we will monitor each of the following parameters and plan for growth accordingly:
Billing Database
The Billing database provides information for Billing and Collections services, including:
O-29
Billing Database Platform
The Billing database platform will have the following characteristics:
The database server's operating system will be Unix 64-bit.
NeuStar will have vendor support agreements to keep the systems running and to repair or replace components immediately if problems occur.
Scalability
In planning for growth, NeuStar will design a database system with the ability to add resources on an as-needed basis without interrupting processing. Because database growth can occur in several areas, we will monitor each of the following parameters and plan for growth accordingly:
Whois Database
Anyone can query the Whois database. Each database entity includes information on the following items for all Internet domain names registered in the usTLD:
O-30
Whois Database Platform
Each Whois server cluster will be supported by a clustered pair of database servers. The Whois database platform will have the following characteristics:
The database server will use the Unix 64-bit operating system with.
Scalability
NeuStar will design the Whois database to grow with increasing demand over time. Because database growth can occur in several areas, we will monitor each of the following parameters and plan for growth accordingly:
Delegee Database
Anyone can query the Delegee database. Each database entity includes the following information for all delegated subdomains registered in the usTLD:
O-31
Delegee Database Platform
Each Whois server cluster will be supported by a clustered pair of database servers. The Whois database platform will have the following characteristics:
The database server will use the Unix 64-bit operating system.
Scalability
NeuStar will design the Whois database to grow with increasing demand over time. Because database growth can occur in several areas, we will monitor each of the following parameters and plan for growth accordingly:
Database Administration
NeuStar personnel who administer and maintain the database will perform their tasks at times and intervals scheduled to ensure maximum system availability. Typical database-administration tasks include the following:
O-32
Database Backup/Restore
Proposal Paragraphs O.7 (Data Escrow and Backup) and O.14 (System Recovery Procedures) describe our proven backup/restore processes, which we will employ for the Enhanced SRS operation. Backup frequency and logging processes will minimize data loss in case of system outage.
Disaster Recovery
Each Centralized usTLD database component will asynchronously replicate its database in the other co-active Enhanced SRS Data Center. As Proposal Paragraphs O.7 (Data Escrow and Backup) and O.14 (System Recovery Procedures) explain, in the unlikely event of a catastrophic outage at one data center, the Enhanced SRS operations will failover to the replicate database.
O.3.3 Database Security and Access Privileges
Proposal Paragraph O.10 explains NeuStar's security measures in detail. The major technical security-related controls to ensure data integrity and security on the database platforms include the following:
O-33
NeuStar proposes generating zone files in near-real-time, thus ensuring timely synchronization of nameservers.
The zone file is a flat database file consisting of the technical information that the DNS requires to function correctly: the domain name, nameserver host name, and IP address.
Zone file generation is the term traditionally used to describe the process of generating a zone file from the registry database, deploying it to the primary root server, and then propagating it out to the secondary servers.
However, NeuStar's model does not periodically generate a zone file and then publish the new file to a set of nameservers. This Proposal describes our process for creating updates for the nameserver files; Section O.5 contains information about distributing and publishing the updates. To make the two sections complete and self-sufficient, each contains certain information that is also found in the other.
Benefits of the Proposed Solution
NeuStar's zone file generation and propagation processes will update zone files in near-real time within defined service levels. Near-real-time updates provide the following significant advantages:
O.4.1 Secure Access to Update Zone File Data
Under our proposed solution, the Centralized usTLD Database in the Enhanced SRS data centers store all data used to generate and distribute the zone file updates. For security reasons, neither registrars nor internal data center staff can access this database directly; the application server tier controls all database access. Registrars/Delegees access the database (through the application servers) using the XRP protocol via the protocol servers. The following procedures govern creating and modifying database information:
Other proposal sections provide additional security-related information:
O-34
Frequency of Zone File Generation
NeuStar will generate zone file updates (diffs) at regular intervals within defined service levels. Our solution enables us to meet any reasonable service level merely by adding incremental hardware items and reconfiguring system software settings.
Any zone file update procedure must not degrade the performance of the core registration system. NeuStar's solution will enable us to agree to service levels that guarantee the zone file distribution database is updated within defined intervals (initially set to 15 minutes) without adversely affecting core registration operations.
Logging and Data Backup
All zone files and updates are generated using information from the Centralized usTLD database. All updates are recorded as database transaction logs. Proposal Sections O.7, O.13, and O.14 contain information about the primary database backup and escrow systems, data center replication, and data recovery procedures.
O.4.2 Zone File Generation Architecture
Zone file information is stored in the Centralized usTLD Database (along with all other registry data) and replicated to a zone distribution server. The database stored on the zone distribution server is in turn replicated out to a database at the nameserver data centers.
Zone File Replication
Each time the zone distribution database is modified, and before the zone file update is replicated out to the nameserver data centers, the system performs a series of quality assurance checks. If any quality assurance checks raise an alert, operations staff must approve the deployment before the update is sent to the nameservers. The quality assurance checks include:
Standards Compliance
Each nameserver will run software that correctly implements the IETF standards for the DNS (RFC1035, RFC2181).
NeuStar expects to implement all applicable best-practice recommendations contained in RFC2870 (Root Nameserver Operational Requirements).
O-35
O.5 Zone File Distribution and Publication
NeuStar proposes near-real-time updates of the zone file data, which will facilitate synchronization of the nameservers as well as the monitoring of service levels.
This proposal section (O.5) describes the process of updating zone file information at the various nameserver data centers using information from the zone distribution servers at the two co-active Enhanced SRS data centers. The preceding proposal section (O.4) describes how the databases on those zone distribution servers are updated. To make the two sections complete and self-sufficient, each contains certain information that is also found in the other.
The databases on the zone distribution servers will be constantly replicated over a VPN to the zone update database at each nameserver data center. Each nameserver data center will, in turn, use its zone update database to update its zone file databases. Updating will comply with defined service levels.
To ensure availability and provide scalability and redundancy, each nameserver data center will have a cluster of two or more nameservers behind a load balancer. This configuration enables NeuStar to rapidly accommodate increases in query load by simply adding servers to the cluster at the affected nameserver data centers.
Benefits of the Proposed Solution
NeuStar's zone file generation and propagation processes will update the zone files in near real time within defined service levels. Near real-time updates provide the following significant advantages:
O.5.1 Locations of Data Centers Housing Zone File Nameservers
Exhibit O-1 (shown previously) provides the locations of the three nameservers. We will monitor network utilization and geographic traffic flows and will deploy new nameservers in additional geographic locations when appropriate.
At the nameserver data centers, a zone update database constantly receives replication update packages from the zone distribution database server at the Enhanced SRS data centers. This zone update database is not "hit' when the nameservers process requests; the nameservers use it only to update their zone file databases.
NeuStar will deploy a modified version of BIND. It has been modified to remove capabilities not required for TLD root server operations and to speed up the remaining functions. The DNS software will comply with the latest IETF standards [RFC1035, RFC2181].
O.5.2 Zone File Publication/Update Architecture
As we introduced in Proposal Paragraph O.4, NeuStar proposes near-real-time update of the zone file. That paragraph discusses how the zone file information is stored in the Enhanced SRS master database and then replicated to a zone distribution server database.
Exhibit O-8 illustrates the zone file distribution process. The database on the zone distribution server at the Enhanced SRS data center is constantly replicated over our VPN to the zone update database at each nameserver data center. The update packages are compressed, encrypted, and sent with an appended checksum.
O-36
Every update package includes a checksum key, which is a generated checksum of the entire database up to and including modifications in that package. Each time a package updates a nameserver, the checksum is compared to the final state of the zone file data to ensure that the nameserver zone file corresponds to the zone file in the Enhanced SRS data center's database. If the checksums indicate an error, the nameserver asks the Enhanced SRS data center to replicate a full zone file to the nameserver. The update package replication process means that the full zone file should never need to be redeployed; however, NeuStar will provide this capability to recover from an unforeseen event. Should this capability be needed, propagating zone file updates may result in a 60-minute delay.
Exhibit O-9 depicts how each nameserver updates its zone file databases from its zone update database.
Frequency of Zone File Publication/Update
Any technical solution that includes real-time DNS updates must recognize that the most important function of the nameservers is responding to DNS queries. This requirement outweighs real-time updating of the zone file. NeuStar's solution is based on this reality. Our real-time update process includes establishing and monitoring key parameters.
[Exhibit O-8: NeuStar's process for near real-time updating of the nameserver zone file databases ensures that consistent and timely data are always available. Graphic Omitted: flow chart of zone file distribution process.]
[Exhibit O-9: Maintaining a zone file database at each nameserver data center allows zone file servers to respond to DNS inquiries by accessing their own local zone file database. This maximizes efficiency and increases redundancy. Graphic Omitted: diagram depicting nameserver update process.]
Monitoring and Logging
Our central network management system will log all modifications to the Centralized usTLD database, all zone file update actions, and all attempts at intrusion or other security-related events.
Standards Compliance
Each nameserver will run software that correctly implements the IETF standards for the DNS (RFC1035, RFC2181).
NeuStar expects to implement all applicable best-practice recommendations contained in RFC2870 (Root Nameserver Operational Requirements).
O-37
O.6 Billing and Collection System
NeuStar's proven experience in successfully selecting, implementing, and operating complex Billing and Collection (B&C) systems for communications and domain name registry services ensures that our usTLD registry billing services will be feature rich, accurate, secure, and accessible to the entire customer base.
The B&C system will maintain customers' accounts, create account statements, and audit and track information for both customers and the industry.
The fundamental goal of the system is to maintain the B&C data and create reports that are accurate, accessible, secured, and scalable. B&C will enable detailed transaction-based charging to the customers, based on extensive resource accounting and usage data recording performed in the Registry System. The B&C system must produce timely and accurate account statements and billing reports that are accurate, easy to understand, and contain only clearly defined charges from the Catalog of services and prices. Such account statements are ultimately more economical because they are less likely to provoke costly billing disputes.
NeuStar offers a simple B&C process as depicted in Exhibit O-10. It is based on debit and/or credit card accounts established by each of our clients. We will withdraw all domain registration service payments from the incurring customer's debit or credit card account on a per-transaction basis. We will provide fee-incurring services (e.g., domain registrations, registrar transfers, and domain renewals) for customers only so long as their accounts are in good standing. NeuStar's B&C system will be sufficiently flexible to adapt to different billable events, grace-period implementations, and pricing structures.
NeuStar's B&C system will be located at the two redundant Enhanced SRS data centers in Virginia and Illinois. These systems will handle the key B&C functions, including:
[Exhibit O-10: NeuStar's billing and collection solution will ensure that all usTLD billing and collection requirements are met with the highest level of service. Graphic Omitted: flow diagram for billing and collection process.]
O.6.1 Technical Capabilities and Characteristics
NeuStar will customize an off-the-shelf product to ensure data processing accuracy, accessibility, flexibility, and scalability to accommodate increasing transaction volumes and additional billable events. Our finance and technical experts are experienced in customizing systems to evolve smoothly from performing simple to more complex tasks, and from small-scale to large-scale operations. We selected this solution after conducting a detailed analysis of the options for administering the registry's B&C system. Our proposed system will:
O-38
Billing and Collection System Description
Exhibit O-11 illustrates the major components of the B&C system and its interfaces with other Enhanced SRS subsystems.
B&C database—This database, which is separate from the Registry's Centralized usTLD Database, contains the data shown in the following table. Proposal Paragraph O.3 discusses the capabilities, management, administration, and backup of all databases, including the B&C database. This subsection discusses only the design aspects of the B&C database.
Transaction Processor—This processor, which responds to inputs from the external application server and from the B&C operations GUI, is the only component that has access to update the B&C database. The transaction processor will process transactions in real time, responding to API calls from application servers, and also will process transaction log files obtained from external servers. The transaction processor has two main subcomponents:
O-39
B&C Database Contents
Primary Element |
Details |
Primary Element |
Details |
|||||||
---|---|---|---|---|---|---|---|---|---|---|
Catalog | • | Transaction type | Transaction data | • | Transaction ID | |||||
• |
Amount charged |
• |
Customer ID |
|||||||
• |
Start date |
• |
Transaction type |
|||||||
• |
End date |
• |
Start date |
|||||||
• |
Additional information |
• |
End date |
|||||||
• |
Domain name |
|||||||||
• |
Registrant contact information |
|||||||||
Customer Information |
• |
Customer name |
Account history |
• |
Customer ID |
|||||
• |
Customer ID |
• |
Amount received |
|||||||
• |
Customer e-mail address |
• |
Date of amount received |
|||||||
• |
Customer address |
• |
Transaction type |
|||||||
• |
Preferred payment method |
Account Information |
• |
Customer ID |
||||||
• |
Credit card information |
• |
Current Amount |
|||||||
• |
Account setup date |
User Administration |
• |
User ID |
||||||
• |
Operational date |
• |
User role |
|||||||
• |
End date |
[Exhibit O-11: The application architectural overview provides a high-level view of the billing and collection system necessary to support registry functionality and its interactions with external systems. Graphic Omitted: architectural diagram of billing and collection processes.]
Monitor and Notifier—This component monitors the registrars' accounts for sufficient funds and monitors domain name expirations and renewals. When it detects actionable items, it notifies the transaction processor and the registry's Customer Service organization.
Report Generator—This component will generate monthly account statements and various reports, including annual reports. This is also the component that Customer Service will use to generate custom reports requested by a customer. After generating custom reports in a batch process, the report generator sends them to the FTP directory, where they are stored for the customer to download.
O-40
Billing and Collection System Interfaces
As Exhibit O-11 above indicates, the B&C system will have four types of interfaces:
Application Programmer Interfaces (APIs)—That connect billing functionality with selected non-B&C functions of the registry (e.g., registrar administration, domain registration, accounting system entries, and e-mail processes). The APIs, which connect to the application server, will provide good query capabilities, triggers for billable events, and a means for customizing or extending B&C functionality. The APIs will enable the B&C system to perform B&C functions in near real time (i.e., at the same time that the registry system is processing the request). The APIs will be well defined, including parameters used and resultant status codes. All error codes will be well documented, and B&C activities will be logged for tracking and audit purposes. API functions include the following:
GUI Client—For the B&C system's registry operations personnel, who will use this interface for system administration and reporting functions, including:
Secure Web-based Portal—That enables customers to use readily available Web browsers (Netscape Navigator 4.0 or above, or Microsoft Internet Explorer 4.0 or above) to monitor their account balances and view reports over the Internet. Using this interface, customers can view the balance in their debit accounts, their credit card transactions, and their domain registration records in detail. Customers are granted permissions via the database security features to access data pertaining to their own accounts, but they cannot access data from other customers' accounts. Customers also are able to select the interface by which the query or report will be delivered; depending upon the type of report or query, the available interfaces can include on-screen, FTP, or e-mail. The interface will be by way of a secure network using the Enhanced SRS Web server, HTML, and an off-the-shelf reporting tool. Features of the Web GUI include:
O-41
Transaction Log Files—Are automatically created by and transferred from external systems such as the application server and database systems.
Billing and Collection Procedures
The B&C system processes data that are generated during the following three types of procedures:
O-42
The following tables provide details of each type of process flow. Where they state that the B&C system sends a special notification to a customer, it also sends a copy to the usTLD Customer Service organization.
Registrar Administration
Function |
Billing and Collection Process Flow |
|
---|---|---|
Initial Account Setup | Registry receives the registrar's Registry Service Agreement and the license fee. | |
Registry establishes an account in the B&C system, enters all contact information, but account status is non-operational. |
||
Operational Account Setup |
Registry verifies registrar's acceptability and invoices for the annual maintenance fee. |
|
Registry receives maintenance fee payment and changes account status to operational. |
||
Registry notifies registrar to prepay the established debit account or collects credit card information |
||
Debit Account Prepayment |
Registry receives customer's payment, opens debit account, and credits received amount to that account. |
|
Change in B&C Profile |
Registry receives the request. If registry approves, it updates customer's B&C profile in B&C system. |
|
Credit Extension |
Registry receives the request. If registry approves, B&C system extends the credit. |
|
Change in Payment Methods |
Registry receives the request. If registry approves request, B&C system records the change. |
The following are the transactional services recognized by the B&C system:
O-43
The following are the non-transactional services recognized by the B&C system:
O.6.2 Security
Proposal Paragraph O.10 provides extensive details about security issues, such as system, network, and physical security and specific issues, such as access control, authentication, and authorization. This subsection discusses only security provisions that are specific to B&C. Like the overall registry system, the B&C system will implement security at the Network, System, and User levels, as follows:
Network-level Security—The primary network-level communications technology underlying the B&C system is the IP protocol. The only interfaces that have access to the B&C system are the secure Web GUI to monitor account status and the FTP server to download reports. A firewall forms the secure interface between our secure internal network and the untrusted Internet. Firewalls use filters to permit or deny packet flow on the basis of the origin and/or destination of the packet's addresses and ports.
Users who want to obtain access to the secure Web portal that we provide to the registrars must first obtain access to the secure Web server within the Enhanced SRS. When the user's Web browser attempts to establish an https (secure Web application protocol) session with the registry, our system initiates the SSL (secure sockets layer). Part of the initialization sequence is a public key exchange or identification. Once the SSL initialization is complete, it establishes a secure, encrypted channel between the user's Web browser and the registry's Web server, and exchanges digital certificates to ensure the integrity and authenticity of the session. The use of a secure Web browser/server ensures that no clear text, including passwords, is sent over the public or shared data network.
System-level Security—Secure user login facilities ensure that secure Web server users are fully authorized and authenticated. The Enhanced SRS secure Web server presents a login menu on the user's Web browser. The login menu includes 20 lines of warning message stating that this is a private computer system and authorization is required for access. The default warning message will be: "NOTICE: This is a private computer system. Unauthorized access or use may lead to prosecution!"
When users attempt to log in to the secure Web server, they must enter their user ID and their password. The login/password information forwarded back to NeuStar's usTLD Web server is encrypted through the SSL channel previously established.
User-level Security—Every B&C system user (individual and application, external and internal) has a unique user login account on the system, with unique user identification codes (user IDs) and passwords to authenticate users and an access control list to control their access to system resources and applications. User profiles are set up and maintained in the database system so that users' access to the B&C system is controlled by their user profile and the access privileges granted therein. NeuStar
O-44
will establish and maintain well-defined security procedures for adding and deleting users and modifying their logon account, access control lists, and user profile access privileges, depending on the user's functional role. The following subsection contains additional information about user roles and privileges.
O.6.3 Access Privileges
The B&C system and network employ multi-tiered access control to ensure that all B&C resources—such as transactions and data—can be accessed and used only by authorized users. As previously discussed, access to the proposed B&C system via the network is fully secured behind a perimeter firewall and user ID and password system, while physical access is controlled using electronic keys and palm readers. Once authorized users gain access to the system, their privileges are controled by the operating system access control lists and the database system user profile that determines what functions, system resources, and data the users are allowed to access and use. Access privileges are broadly defined and controlled for the following user groups:
The following subparagraphs discuss the access privileges of each group.
Registry Employees
Only internal usTLD registry staff members using cardkeys can gain access to the registry facility. Registry employees who are authorized to access the B&C system do so using workstations connected through the registry LAN. Except for the system administrators, these employees access the system using the B&C client interface, which will be established specifically for staff members to perform billing adjustments, maintenance, and related functions.
Each internal user of the B&C system is also associated with a user role that will permit or deny access to different functions in the B&C system. The System Administrator will create the roles that allow users to access certain functionality. Initially, we expect to define user roles within NeuStar's B&C-operations organization as follows:
O-45
Customers
Customers have only view access to their B&C account status, account statements, and reports. They have to contact B&C personnel within the registry's Customer Support organization for any billing adjustments, custom reports, or special arrangements.
Query Capabilities—The Web GUI will provide authorized registrars with the ability to query the B&C database for information. As previously described, to access the Web GUI, the registrar must obtain network access to the registry Web server and then proceed through the identification and authentication process using a valid logon ID and password. A registrar's access to the B&C information is limited to his own accounts; the registrar is denied access to the information about any other registrar's account. The Web GUI supports the following standard queries and reports:
Customers can submit nonstandard queries or requests for special reports by contacting NeuStar's Customer Service organization via e-mail, phone, or fax. Customer Service will place any custom reports on a secure FTP server from which the requesting customer can download them.
Adjustments—For billing issues or adjustments in profile or account statements, customers must contact NeuStar's Customer Service organization via e-mail, phone call, or fax. The B&C Manager has the capability to perform any billing adjustments or similar services requested by a customer.
Notifications and Statements—The registry will e-mail to each customer a detailed monthly transaction statement, an account summary, and a detailed list of all fee-incurring charges. In addition, the B&C system will automatically e-mail "Low Account Balance," "Insufficient Funds," and "Credit Card Transaction Refusal" notifications to any customer when needed.
O.6.4 Backup and Recovery
We will employ the same backup and recovery procedures for the B&C system that we use for the overall registry system. Proposal Paragraph O.7 provides detail on the following procedures:
O-46
If the B&C system fails (i.e., the API interface to the application returns an "Error status"), a built-in recovery mechanism will ensure that transactions and data are not lost. The application server will log all undeliverable B&C transactions, with transaction identifiers, to an internal file. After the problem is corrected, the file will be transferred to the B&C system for processing.
O.6.5 Billing and Collection Audits
NeuStar will provide the infrastructure to collect all data needed for accounting and auditing reports that meet commercially accepted standards and will provide this data, as appropriate, to COTR-designated auditors. Data will be available for the current fiscal year and for an agreed number of preceding years. NeuStar will assist COTR-designated auditors by providing all required statements and reports. Annually, NeuStar's internal auditors will audit the registry's B&C system, records, and supporting documentation to verify the accuracy of billing for usTLD services.
O-47
O.7 Data Escrow and Backup
NeuStar will back up the databases in our data centers in Virginia and Illinois and will regularly place escrow copies of the backups in secure off-site locations. These procedures are essential elements of our realistic plans for continuity of operations in the event of system failures and natural or man-made disasters.
The goal of any data backup/recovery procedure is full recovery from failures without any loss of data. Data backup strategies handle system hardware failures (e.g., loss of a processor or one or more disk drives) by reinstalling the data from daily backups, supplemented by the information on the "before" and "after" image-journal backup files that the database creates.
The conventional strategy for guarding against loss of the entire facility because of fire, flood, or other natural or man-made disaster is to provide off-site escrow of the usTLD data in a secure storage facility. Even when successful, this recovery strategy does not prevent the loss of a certain volume of transactions between the time the data were backed up and the occurrence of the disaster. Users are subject to denial of service during the time required to recover the data center database and/or reestablish operations at an alternate disaster recovery site. Relocating the data center normally requires at least 24 hours, and the escrowing of backups often is done only weekly, meaning that a disaster could result in substantial loss of both services and data.
NeuStar's backup solution goes a step further. We propose two co-active Enhanced SRS data centers, each capable of handling the entire workload should a major system failure or natural or man-made disaster occur at the other. The transactions from each data center are replicated in real time to the other over redundant high-speed Virtual Private Network (VPN) telecommunications links. Each Enhanced SRS data center also conducts independent backups, as described in the following paragraph. Since the two Enhanced SRS data centers are co-active, our backup strategy maintains continuity of operations and enables full recovery of all transactions, even in the event of multiple hardware failures.
O.7.1 Frequency and Procedures for Backup of Data
Each co-active data center independently implements a zero-downtime/zero-impact incremental data backup each day and a full data backup weekly. We place escrow copies of the backup tapes in a secure off-site storage facility operated by a third party whose business is data escrow. We copy static data (e.g., the operating systems, DNS software, and applications software) to CD-ROMs for quick reload, should that become necessary. We back up to DLT tape any dynamically changing files (e.g., log files vital to system maintenance and operation, database files, database-journal files, and software configurations). Weekly, we perform full-system backups to DLT tape of all databases identified in Section O.3 (Enhanced SRS Database, Whois, Billing).
Each data center uses online zero-downtime/zero-impact backup procedures that include the following four steps:
O-48
O.7.2 Backup Hardware and Software Systems
Exhibit O-12 depicts the backup/recovery hardware and software of the Enhanced SRS data centers. Each data center's system includes two backup servers with DLT robotic tape libraries. The data backup system uses the DLT IV data cartridge and the DLT 5 data format. To achieve zero-downtime/zero-impact backup, we use a RAID disk array and a high-speed fiber channel bridge interconnect to the robotic tape libraries. The backup server copies not only the database server's backup files to the disk array, as discussed in the four-step process already described, but also the backup files of the cluster servers. During the few minutes this process requires, applications still have access to the cluster servers and database server. Then the backup server copies the files to the DLT robotic tape device.
Because of the criticality of the database, NeuStar proposes a fully redundant database management system. We will configure the database system as two independent database servers—primary and backup—with synchronous replication using two-way commits to maintain database synchronization. If one database server fails, the database system is sized so that the second server can process the entire load without degradation while the primary server is restored to service.
We will transport both daily incremental backups of dynamically changing data and the weekly full backup to a secure escrow agent to be selected with the concurrence of the COTR.
[Exhibit O-12: Snapshots of NeuStar's Centralized usTLD Database are written to a disk array and then copied to tape library to enable seamless application processing and continuous database access. Graphic Omitted: flow diagram depicting data center backup system.]
O.7.3 Procedures for Retrieval of Data and Rebuild of the Database
We maintain copies of the DLT tapes holding incremental data backups in a three-tape rotation:
The full backup tapes are maintained in a two-tape rotation, with one tape at the secure escrow facility and one at the data center for reuse. Copies of the static data CD-ROMs for the operating systems and applications are also maintained at the escrow facility.
Should the primary database server experience a catastrophic crash that necessitates a lengthy recovery process, data center operations continue seamlessly on the backup database server that replicates all the data in the primary server. After the failed database server is repaired, we recover its data using the full backup tape and incremental backup tape that is retrieved from the escrow facility. We first restore the full backup files, and then we restore the incremental files. We then synchronize the recovered database to the primary database. This procedure recovers the database to the last complete transaction processed by the primary database.
This backup procedure enables NeuStar to meet the service level agreements required for continuous availability and near-zero unplanned downtime, thereby improving the stability of the Internet, enhancing public confidence, and improving customer satisfaction.
O-49
O.8 Whois Databases for Both Registrars and Delegated Managers
NeuStar proposes a central, authoritative Whois service that will provide the Internet community with consistent, timely, and accurate information about Registrants and delegated Managers.
Whois is a database of information about Internet domain names. NeuStar's proposed registry will maintain a state-of-the-art, near real-time Whois service that will make this information available to registrars and delegees on the common Whois port (Port 43) as well as through a NeuStar public website. With a simple wrapper around NeuStar's Whois service, these registrars and delegees will have the ability to control their own Whois offering, complete with its own look and feel and branding. Our registry will store all information relating to Whois data entities, including contact and authentication data. This section covers both the Whois Database (Registrants) and the Delegee Whois database. The term Whois implies both services
The Whois service is intended as a directory service for registrants, as well as for any other individuals and businesses that want to query details of domain names or related data stored in the registry. Our Whois data will be available in both conventional and machine-readable format, facilitating automation.
In addition to providing the Whois directory service to registrars and delegees, NeuStar will also have the ability to provide the service directly to the Internet community via our Web site.
Benefits of Proposed Solution
NeuStar's proposed solution, which centralizes the Whois data and provides its own access, as well as access via registrars and delegees, provides the following benefits:
O-50
O.8.1 Whois Service Functional Description
The Whois service will accommodate queries regarding the data entities listed in the following table.
Whois Data Entities
Entities |
Fields |
|
---|---|---|
Domain names | Attributes (Status) | |
Associated nameservers |
||
Associated registrar Associated Delegated Manager |
||
Associated registrant data |
||
Nameserver |
Attributes (Status) |
|
Associated IP addresses |
||
Associated registrar Associated |
||
Delegated Manager |
||
Associated registrant data |
||
IP Address |
Attributes (Status) |
|
Associated nameserver |
||
Associated registrar |
||
Associated Delegated Manager |
||
Associated registrant data |
||
Registrar List |
Registrar name |
|
Registrars |
Registrar name |
|
Registrar contact details |
||
Registrar URL (Home page) |
||
Registrar Whois URL (Web Port 80) |
||
Registrar Whois URL (Web Port 43, if applicable) |
||
Attributes (Status) |
Machine-Readable Format
NeuStar's standardized Whois format will facilitate automated parsing of Whois information.
Because the viewable data could be modified over time (e.g., new fields could be added), a robust and formalized encoding mechanism is needed to provide the non-Registrar/Delegee community with reliable automated access to Whois data.
For example, an organization tracking trademark infringement might want to acquire the Whois data, automatically parse it, and store it in a tracking system. To accommodate such organizations, the
O-51
Whois information must be presented in a formal, way that is compatible with automated processing. To accomplish this, we will present the Whois data in a readable format.
Advanced Search Capabilities
Per COTR requirements, the Whois database will support using multiple string and field searching. Boolean searches based on any combination of Whois fields will be accommodated.
Data Filtering
In order to accommodate any data access restrictions that may arise, either immediately or in the future, NeuStar will implement the capability to filter viewed data based either on the capabilities/profile of the requestor or the query type. This will allow NeuStar to conform to any data privacy requirements imposed on the Whois data.
Bulk-Access Program
NeuStar proposes to provide a data mart that will give users the ability to download the Whois database, while limiting the recipient's conditions of use.
The proposed data mart bulk-access program would:
Both the registry and the registrars/delegees will have the ability to conduct the actual bulk-access program. Data will be exposed only within the privacy restrictions imposed by the usTLD Administrator, or by law.
Each full and incremental data set will consist of an XML document meeting the content and format requirements, as agreed by the Registry and the accessing customers. Once the XML document is generated, the following preparation steps will be performed:
Once prepared, data sets will be provided either by Internet File Transfer Protocol (FTP) or, at the option of either the Registry Operator or the Designated Recipient, by writing the full data set to DAT tape (or other media mutually agreed by Registry Operator and the Designated Recipient) and sending it to the Designated Recipient by expedited delivery service (such as FedEx or DHL).
O-52
O.8.2 Whois System Architecture
NeuStar will deliver a Whois service that incorporates near-real-time update, scalable infrastructure, and multiple layers of redundancy. We will initially deploy the Whois servers at the two co-active Enhanced SRS data centers shown previously in Exhibit O-1. The software architecture will enable us to deploy Whois infrastructure to any number of additional NeuStar data centers. As the registry grows, we will have the ability to deploy additional Whois infrastructure as appropriate to increase geographic dispersion, enhance the level of service in particular geographic regions, and reduce the load on the Enhanced SRS data centers.
Exhibit O-13 illustrates the Whois architecture. At each Whois site, incoming queries are distributed by a load balancer to a cluster of Whois servers that are, in turn, connected to a backend database cluster. This configuration will provide both redundancy and scalability through the addition of servers to either cluster.
Each Whois server will cache common requests in memory and query the back-end database cluster only on a cache miss. We can configure the duration that Whois information is cached before being deleted (e.g., 10 minutes); after deletion, the server must query the database for the information. Each Whois server will be configured with at least 2 GB of high-speed memory, sufficient to hold at least one million of the most commonly queried Whois records.
Exhibit O-14 depicts the update of the Whois databases. As the Central usTLD database is updated, the system will also update the Whois distribution database server in near real time. This database will be replicated to the Whois databases. Replication between data centers always occurs over a VPN or a dedicated link, and the registry will digitally sign update packages.
The proposed Whois service offers the following benefits:
[Exhibit O-13: As with other Enhanced SRS configurations, NeuStar will provide fault tolerance and easy scalability of the Whois system through redundant architecture and clustered servers. Graphic Omitted: architectural diagram of Whois server system.]
[Exhibit O-14: The Centralized usTLD Database updates the Whois and Delegee Whois distribution databases in near real-time, and the information is distributed within a configurable period to the Whois/Delegee database, where it is available for query. Graphic Omitted: flow diagram for Whois update process.]
O.8.3 Network Speed and Proposed Service Levels
The potentially large volume of Whois queries places a significant network connectivity burden on the registry. Based on the assumption that each Whois query will generate approximately 10 Kbits of network traffic, we will use the following engineering guidelines for provisioning bandwidth:
O-53
These guidelines will be compared with actual usage data and adjusted accordingly.
We will engineer the Whois service to provide the following average service levels:
We will configure the Whois service to limit connections based on the following criteria:
We will scale the exact number of Whois and database servers deployed in each cluster and at each data center to maintain the specified service levels.
O-54
O.9 System Security
NeuStar is currently operating successful data centers for various telecommunications and domain name registry services. This experience has familiarized us with security risks, as well as with the most current and effective means of thwarting such risks. The COTR can be assured that our comprehensive security provisions will protect the usTLD infrastructure, operations, and data.
Enhanced Shared Registration System (Enhanced SRS) and nameserver data centers are subject to a wide range of security threats, including hacking, break-ins, data tampering, denial of service, and physical attacks against the facility. The recent denial-of-service attacks against important government and dot-com sites point to the technical capabilities of some hackers and the lengths to which they will go to attack the Internet community. Further, because the Registry will contain proprietary data from competing registrars, security procedures must incorporate user authentication procedures that ensure that each registrar's files are available only to its own personnel.
Failure to address these security threats creates the risks of unscheduled down time and the disruption or denial of services.
This section describes system security features that we will implement in our networks, servers, and applications for the Enhanced SRS data centers and nameserver data centers.
O.9.1 System Security
NeuStar offers the COTR comprehensive system security for our networks, servers, applications, and customer support services. Our security architecture is a policy-based, multi-tiered structure based on industry standards and on evolving new IEFT standards for registry-to-registrar security and secure DNS. Our solution integrates the following security features to provide assurance that multiple security threats or attacks will be unsuccessful:
O-55
O.9.1.1 Enhanced Shared Registration System Data Center Security
The Enhanced SRS provides three layers of security to protect the registry subsystems: (1) network security, (2) server security, and (3) application security. Each security layer addresses a specific security threat as discussed below.
Network Security
Edge routers, firewalls, and load balancers provide perimeter protection for the data center network and applications systems, guarding against unauthorized access from the Internet.
Server Security
The Enhanced SRS operating systems provide access protection through a user login procedure and through file-level access control lists. These access control mechanisms perform the following functions:
The Enhanced SRS operating systems will perform security-relevant logging functions, including:
O-56
The following provisions apply to passwords:
Application Security
Each Enhanced SRS application will have its own set of security processes and technical controls. The Enhanced SRS applications that interface with the registrars/delegees/registrants (e.g., the XRP and the secure Web customer service portal) employ the SSL (secure sockets layer) protocol element that uses public-key exchange and RC4 encryption. Public services (e.g., Whois, delegee, DNS queries, and the public Internet Web portal) rely on the previously discussed network perimeter security devices—edge routers, firewalls, and load balancers—to protect the internal LAN and applications servers.
O-57
The following table summarizes the benefits of each security mechanism that we employ at the data centers to prevent system hacking, break-ins, and denial-of-service attacks.
Security Summary
Security System Element |
Features and Benefits |
|
---|---|---|
Server Operating System Security | ||
User ID and password; file-level access control lists |
Ensures that the user can access authorized functions, but no others, and can perform only authorized operations within these functions. |
|
Database Security |
||
User ID and password; user profiles |
Limits database access to preauthorized users with a familiar, easy-to-use method for user authentication. Retains the last two passwords and disallows their usage, complicating the task of password guessing and cracking. Rejects simultaneous sessions by an individual user, helping ensure that user IDs and passwords are not shared. Limits access rights to database objects and functions to a specified user or user group, simplifying the job of user administration. Rejects unauthorized access attempts and automatically disables identification codes after a preestablished number of unsuccessful attempts, preventing trial-and-error hacking attempts. |
|
O-58
Application Security |
||
Data encryption (SSL) |
HTTPS encryption ensures that only the intended receiver can read messages between users and the NDR. |
|
Digital signatures |
Issued by an authentication server, digital signatures ensure that the incoming data actually have come from the purported sender. This provides nonrepudiation, avoiding disputes over data origin. |
|
User ID and password |
Ensures that the user can access authorized functions, but no others, and can perform only authorized operations within these functions |
|
Network Security |
||
Router |
Permits only UDP/TCP packets to enter the application servers, thus isolating the system from most potentially damaging messages. |
|
Firewall |
Guards the secure LAN from the nonsecure Internet by permitting the passage of only packet flows whose origins and destinations comply with preestablished rules. |
|
Intrusion detection |
Detects intrusion at the LAN level. Displays an alert at the network operations center workstation and creates a log entry. |
|
Load balancer |
Implements security policies to prevent denial of service attacks (e.g., SYN floods, ping floods, and "smurfs"). |
O.9.1.2 Nameserver Data Center Security
NeuStar's approach to nameserver security is a subset of the security mechanisms we employ at the Enhanced SRS data centers. The nameserver data center also relies on multi-layer perimeter protection, controlled access, enforcement of applications security features, and strong physical security protection.
Network Security
The same mechanisms used for the Enhanced SRS data center are employed at the zone nameserver data centers. Edge routers and firewalls provide perimeter protection for the data center network and applications systems, guarding against unauthorized access from the Internet.
O-59
sites in a "lights out" (unmanned) mode. VPN technology achieves secure data transfer through encrypted data communications links.
Server Security
The zone nameserver operating systems provide access protection for remote system administration through a user login procedure and through file-level access control lists. These access control mechanisms perform the following functions:
The zone nameserver operating systems will perform security-relevant logging functions, including:
Application Security
The zone nameserver essentially enables the public to make DNS queries via the Internet. Public services, such DNS queries, rely on the previously discussed network perimeter security devices—edge routers, firewalls, and load balancers—to protect the internal LAN and applications servers.
O.9.2 Physical Security
NeuStar vigorously enforces physical security measures, controlling all access to our facilities. Throughout normal working hours, security personnel stationed at each building entrance verify that employees are displaying proper identification badges, and they control access by nonemployees, who must sign in to gain entrance. The sign-in books are stored for a period of one year. If the purpose of their visit is found to be valid, nonemployees are issued a temporary badge; otherwise, they are denied entrance.
At all times while they are in the facility, visitors must display their badges and must be escorted by a NeuStar employee. We also strictly enforce the policy that employees must wear their badges prominently displayed at all times while in the facility.
In addition to providing physical security by protecting buildings with security guards, NeuStar uses a Cassi-Russco security system with Secure Perfect software to manage access control. The system utilizes proximity card readers with PIN codes for access to the buildings nonpublic areas and biometric
O-60
readers recognition equipment to control access to the data center. Cameras monitor access points to the building and data center and provide digital recording for archives. All exterior doors are monitored for status. A panic button has been installed for summoning aid, if it is required.
The following table lists salient facts about our physical security mechanisms.
NeuStar Physical Security Mechanisms
Mechanism |
Remarks |
|
---|---|---|
Security guards |
Physically prevent intruder access; verify employee badges |
|
Closed-circuit video surveillance cameras |
Extend capabilities of security guards; maintain access records |
|
Intrusion detection systems |
Provide audible and visual alarms to notify security personnel in the event of unauthorized entry |
|
Identity badges |
Permanent badges for employees; easily recognizable temporary badges for visitors |
|
Sign-in registers |
Maintained as permanent records for at least one year |
|
Electronic key badges |
Control physical access during off hours; maintain access records |
|
Palm readers |
Restrict physical access to mission-critical rooms within our facilities; maintain access records |
|
Self-closing doors |
Restrict physical access to mission-critical rooms within our facilities |
O-61
O.10 Peak Capacities
NeuStar proposes a highly scalable Enhanced Shared Registration System (SRS) and nameserver systems that are initially sized for a peak load of three times the average projected workload. The peak load capacity and built-in scalability of the registry system architecture ensures the COTR that adequate capacity is available during initial peak usage periods, and that as usage grows over the life of the registry operations, the Enhanced SRS system infrastructure can scale up smoothly without service disruption.
To avoid creating bottlenecks for Enhanced SRS, Whois, and nameserver services, NeuStar will engineer for peak usage volumes. In addition, NeuStar will deploy redundant co-active Enhanced SRS data centers—a network of nameserver sites that are sized to handle the projected initial peak volumes. Subsequently, we will add additional zone nameservers to handle the anticipated growth. Our Enhanced SRS, Whois, and nameserver architectures are designed with highly scalable server clusters and connected through networks that can be smoothly scaled up without disrupting the system. Expansion provisions include the following:
This subsection describes the peak capacities of the Enhanced SRS, Whois, and nameserver subsystems in terms of the network, server, and database platforms' initial sizing and scalability. NeuStar central backup/recovery, escrow, system/network management, and system administration systems are enterprise-strength hardware and software platforms that can easily handle these management and administrative functions throughout the entire registry operations lifespan. Additional desktop computers and workstations can be added to accommodate growth in staff and workload as usage increases and the registry infrastructure grows. Our maintenance support, help desk, and technical support functions are staffed for the initial peak usage period, and staff can be increased to handle workload surges caused by registry marketing and promotional events.
It should be noted that Delegee database capacity requirements are assumed to be low. For this reason, they have been factored into the Whois database capacity numbers.
O.10.1 Enhanced SRS Peak Capacity
The Enhanced SRS provides the core subsystems that handle registrar transaction-based services, including XRP processing, billing and collection, secure Web portal, and back-end database system services. This subsection describes the Enhanced SRS subsystems peak capacity in terms of the initial sizing and scalability of the network, server, and database platforms.
O-62
Network
The XRP average steady-state transaction load is projected to be 150 transactions per second (tps), or approximately 13 million transactions per day. Since peak transactions are six times the average, we designed for a peak transaction load of 900 tps. The average transaction size is 5,000 bits, which translates to a required telecommunication capacity of 4.5 MBPS. The external communication network connectivity to the Internet is initially sized at two fractional T-3 ISP 20-MBPS local access links, for a total of 40 MBPS to handle XRP transactions and Whois queries. The registry's VPN between the sites is two T-1 1.544 MBPS. The VPN handles zone database updates, server backup and restore, system/network management, and system administration functions.
Server Clusters
The XRP server cluster and the associated applications server clusters are front-ended with load balancers that distribute the transaction processing workload across the servers in each cluster. Distribution algorithms include least connections, weighted least connections, round robin, and weighted round robin.
The XRP server and applications server clusters are initially sized to handle six times the projected steady-state workload, or 900 peak transactions per second. The processing capacity can grow linearly by adding additional servers to the cluster. The total system capacity is a cluster size of 32 SMP 8-way RISC servers.
The Billing and Collection system is sized to handle 200 peak transactions per second, because not every XRP transaction results in a billable service.
Database System
The database system consists of dual high-end RISC machines, each with 2- to 32-way SMP scalability. The initial processing capacity of the database system is 4-way SMP, sized in terms of the Transaction Processing Council Online Transaction Processing (OLTP) benchmark of 2500 transactions per second (tpsC).
The database system can grow to handle eight times the initial projected volume of transaction loads. NeuStar will closely monitor system usage and will scale the database capacity correspondingly.
O.10.2 Whois Peak Capacity
A large percentage of the load on the current registry's Whois server is caused by data mining. NeuStar will increase network bandwidth and add high-performance database capabilities to the Whois service infrastructure. Our proposed bulk-access services will reduce the Whois load by as much as two-thirds. This subsection describes the Whois subsystems peak capacity in terms of initial sizing and scalability of the network, server, and database platforms.
Network
The peak Whois transaction rate is estimated to be 2,000 queries per second, with an estimated packet size of 10,000 bits. This produces a maximum load of 20 MBPS. Initially, we will provide communication network connectivity for Whois queries between the Internet and each data center as two fractional T-3 ISP local-access links. Although these links initially will not be used at full capacity, they ultimately can carry up to 90 MBPS per data center before we upgrade to larger links.
O-63
Whois Server Cluster
Our Whois server cluster is front-ended with load balancers to distribute the transaction processing workload across the servers in each cluster. Distribution algorithms include least connections, weighted least connections, round robin, and weighted round robin.
The Whois server cluster is initially sized to handle 2,000 peak transactions per second. To improve query response time and lighten the load on the database, the Whois servers cache frequently accessed domain names.
The processing capacity can grow linearly by adding additional servers to the cluster. The total system capacity is a cluster size of 32 SMP 6-way Intel servers. NeuStar will closely monitor Whois usage and will increase the system's capacity to accommodate increasing demand.
Database System
Behind the Whois/Delegee servers are dual mid-range RISC machines, each with 2- to 8-way SMP scalability. Initial processing capacity will be 4-way SMP at 500 tpsC, scalable to 1,000 tpsC. (tpsC is Transaction Processing Council (TPC) Online Transaction Processing (OLTP) benchmark C workload.)
NeuStar is implementing a Whois bulk-load data mart service that will enable the registrars to provide their customers with OLTP bulk query services for data mining of domain names.
O.10.3 DNS Query Peak Capacity
During the initial land rush period when registrars are marketing the expanded usTLD domain name extensions, DNS query traffic is expected to be moderate because of less caching further down the DNS hierarchy. Moreover, the query load will not approach current dot-com/dot-net/dot-org levels until more than five million names are registered. Although NeuStar is proposing three nameserver sites at roll-out, we will closely monitor the load to project the need to add another site
NeuStar's registry handles DNS queries at the nameservers. This subsection describes the nameservers' peak capacity in terms of the network, server, and database platforms' initial sizing and scalability. NeuStar's design will easily scale as load increases.
Network
NeuStar anticipates a peak load of 5,000 DNS queries per second at each nameserver data center and estimates the average query package size to be 1,600 bits. This load produces a required telecommunications network bandwidth for DNS queries of 8 MBPS. To provide this bandwidth, we will provision two fractional T-3 access links to the Internet at each zone nameserver site. The nameserver data centers will easily process a peak load of 40,000 queries per second with more than 100 percent reserve capacity.
Zone Nameservers
Our DNS nameserver cluster will be front-ended with load balancers to distribute the transaction processing workload across the nameservers in the cluster. Distribution algorithms include least connections, weighted least connections, round robin, and weighted round robin.
The nameserver cluster is initially sized to handle three times the projected steady-state workload, or 5,000 queries per second. To improve query response, the entire zone will be held memory resident.
Processing power can grow linearly by adding additional servers to the cluster up to its total system capacity: a cluster size of 32 SMP 6-way Intel servers. NeuStar will closely monitor system usage and will scale up as required.
Database System
The nameserver database update systems use Intel machines with up to 6-way SMP scalability to perform snapshot replication of updates to the nameserver database. Since the snapshot replication is triggered at regular intervals, the initial nameserver database update system is sized as a 2-way SMP database server, which is more than adequate to distribute the zone file updates.
O-64
To provide continuous access to usTLD registry data and applications, NeuStar proposes the use of two co-active data centers, geographically separated and continuously online. Each data center incorporates redundancy and nonstop, high-availability features in its hardware and software configurations.
Today, business lives in an environment of global economies, increasing competition, ever-changing technologies and markets, population mobility, and other uncertainties. It becomes increasingly evident that the ability of a business to quickly and intelligently respond to these changing conditions depends directly on the availability, timeliness, and integrity of its information resources. The Information Technology industry has responded to this need with a variety of high-availability systems whose costs depend on the size of the necessary databases and on service-level agreements covering system availability. Thus, a TLD registry's selection of a high-availability solution is not only a significant investment but also a crucial decision that can determine the registry's success or failure.
usTLD applicants must realize that few businesses can afford to be without access to mission critical applications, nor can they tolerate system failures that lead to excessive downtime and denial of service. Furthermore, few end users would consider a system to be "available" if system performance drops below some acceptable level or if the system is only available to some subset of the user community. How useful is the fact that a system can perform a zillion tpm or execute a query in milliseconds without knowing its availability and the cost of achieving its performance and availability?
NeuStar is proposing two co-active data centers for usTLD registry operations and a network of nameservers. These facilities are geographically dispersed to minimize the possibility of outages caused by natural or man-made disasters. The nameservers are dual-homed to each data center via a VPN backhaul link. As Exhibit O-15 indicates, the two data centers are interconnected by high-speed, alternate-routed VPN links. The VPN network management system includes a "heartbeat" signal from each data center. If it detects a failed heartbeat at one data center, it automatically routes all traffic to the other.
Each data center will have redundant network components, high-availability server clusters, and redundant database servers to eliminate single points of failure. All critical telecommunications access links and network components—routers, firewalls, LAN switches, and server NIC cards—will be redundant. Anything less would be inadequate to provide the service levels that the COTR and the industry deserve.
[Exhibit O-15: In the event of a disaster at one of NeuStar's two co-active data centers, the other is sized to manage all registry operations with little or no service degradation, thereby safeguarding the integrity of the Internet. Graphic Omitted: diagram depicting connectivity of co-active data centers.]
O.11.1 Quality of Service and Performance Measurements
Neustar understands the importance of quality of service as it pertains to the usTLD. The systems and operations used to be reliable and have a high level of performance. But quality of service is only a subjective opinion unless one provides objective measures of performance and reliability. For example the Enhanced SRS must have a high level of availability for the registrars and provide response times. Both of these functions can be measured, monitored and reported.
NeuStar believes Performance Measurements are so important to the proper functioning of the usTLD Administrator we have integrated detailed performance measurements into our usTLD Administrator Registrar Agreements. Not only have we integrated the measurements into the agreement, but we have included credits to be paid to the registrars if we fail to meet any one of them.
For a detailed description of the performance measurements please see Exhibit G of the usTLD Registrar Contract in Section H of this proposal. For a detailed description of the Perfomance Credits please see Exhibit H of the same contract in Section H of this Proposal. Section Q of this proposal provides an overview of NeuStar's capabilities and commitments with regard to Performance Measurements.
O-65
O.12 System Outage Prevention
The NeuStar's co-active redundant data centers and high-availability server cluster architecture will maintain continuous operations with no disruptions in service. The benefit is improved system availability, minimum downtime, and high confidence in the Internet registry services.
The Internet community requires outage prevention measures specifically designed to minimize system downtime. Downtime can be categorized as either unplanned or planned:
In addition to employing the above measures for minimizing planned downtime, system designers may use redundancy and high-availability system architectures designed to minimize unplanned outages. Many data management operations will also have disaster recovery agreements with a business continuity provider who provides a disaster recovery site geographically separated from the operational data center. The intent is to maintain continuity of operations in the event of a natural or man-made disaster.
NeuStar believes these approaches alone, although commendable, are insufficient to meet the high service levels expected by the DOC and the Internet community. For example, the registry services are so specialized and component intensive that no business continuity provider is likely to be capable of resuming services without a lengthy outage period. We contend that the only way to provide satisfactory service levels is through a combination of approaches, including:
Procedures for Problem Detection and Resolution
To best meet data center requirements for availability, flexibility, and scalability, NeuStar has designed a high-availability architecture that will combine multiple computers into a cluster. Nodes in the cluster will be loosely coupled, with each node maintaining its own processor, memory, operating system, and network connectivity. Our system/network management and cluster management tools will automatically detect and compensate for system and network faults and notify system operators.
At five-minute intervals the network management system will "ping" network devices with Simple Network Management Protocol (SNMP) for availability and poll them for performance statistics. Event threshold violations or error conditions will initiate a sequence of alerting events, including visual notifications via a topology map, an entry into a trap log of event records, e-mails to a bulletin board, and notices to technical support staff. The goal is to detect and repair potential problems before services are disrupted.
O-66
An SNMP daemon will be configured to periodically check the status and health of vital server processes. In the event of a critical process failure, the SNMP agent will send a trap to the network management system, initiating an alert to the technical support staff. Our network management software will include remote monitoring and management of operations, so technical support staff can easily diagnose and troubleshoot network faults, either from the Network Operations Center or remotely. Once a problem is detected, it will be resolved using our proven problem management process. In conjunction with this problem management process, we will employ proactive performance management and trend analysis processes to do root cause analysis and discover performance and utilization trends that could lead to potential problems.
The cluster management software will organize multiple nodes (up to 16) into a high-availability cluster that delivers application processing support to LAN-/WAN-attached clients. The cluster software, which will monitor the health of each node and quickly respond to failures to eliminate application downtime, will automatically detect and respond to failures in the following components:
Since high availability is a primary design goal, a cluster cannot have a single point of failure; accordingly, we will employ RAID mirrored disk drives and multiple LAN connections. The cluster software will monitor these hardware and software components and respond by allocating new resources when necessary to support applications processing. The process of detecting failures and restoring the applications service will be completely automated—no operator intervention will be required.
Redundancy of Data Centers and Systems
NeuStar is proposing redundant co-active data centers: one in Virginia and one in Illinois. These data centers will be interconnected by redundant, high-speed, secure VPN telecommunications links to provide two-way replication of all registry database transactions. A heartbeat monitor will determine the online status of each data center and enable the services to be provided entirely from the second data center if one is lost.
Within each data center, the system will be redundantly configured so that failure of any system component will leave a configuration of surviving system components capable of executing the entire workload within 95 percent of the previous performance for at least 90 percent of users. To achieve no-single-point-of-failure architecture, NeuStar will replicate all components and configure the system for automatic failover.
The following table describes the system architecture redundancy we will employ at each Enhanced SRS data center to meet 99.9+ percent service availability levels.
O-67
System Redundancy Elements
Issue |
Redundancy Solution |
Benefit |
||
---|---|---|---|---|
Single failure of a system component | Replicate all critical components to eliminate single point of failures | The system is capable of executing the entire workload. | ||
Maintaining availability of applications |
Stateless N+1 node high-availability processor clusters |
In event of a processor failure, service is not degraded. |
||
LAN Interface or cable failure |
Multi-path LAN I/O |
Automatic switchover from one LAN switch to another to restore connectivity |
||
Disk controller or cable failure |
Multi-path disk I/O |
Applications take alternate routes |
||
Disk storage module failure |
Redundant Array of Independent Disks (RAID, levels 1, 3, and 5) |
Applications still have access to data in the event of a single disk failure |
||
Hardware/software upgrades and additions or changes to the configuration |
N+1 redundancy allows hot repair/upgrade of system components. |
Eliminate downtime due to administrative and maintenance tasks |
||
Dynamic processor de-allocation |
Dynamically take a processor out of service to modify the physical and logical configuration of the system. |
Eliminate downtime due to maintenance tasks and component replacement |
||
Replace disks |
RAID drives and controllers allow hot plug-in of disk modules |
Eliminate downtime due to maintenance tasks |
Hot Repair of System Components
Another advantage of system redundancy is that it will enable our maintenance staff to use hot repair or replacement of system components. Keeping the system in full operation while we perform such common system administration tasks as upgrading the hardware or software or adding to or changing components will eliminate the MTTR (Mean-Time-To-Repair) factor and will minimize downtime. Hot repair is possible only when major system components are redundant, as in the NeuStar solution.
Backup Power Supply
Each Enhanced SRS and nameserver data center will be provided with UPSs to ride through brief electrical transients and outages. For more than brief outages, each Enhanced SRS data center will have a 1,000 KVA generator and the nameserver data center will have a 250 KVA generator capable of running the entire data center in the event of a lengthy electrical blackout.
Facility Security
As discussed in Registry Operator's Proposal Section O.10, NeuStar will vigorously enforce physical security measures that control all access to our facilities. Throughout normal working hours, security personnel stationed at each building entrance will verify that employees are displaying proper identification badges and will control access by nonemployees, who must sign in to gain entrance. The
O-68
sign-in books will be stored for a period of one year. If the purpose of a nonemployee's visit is found to be valid, he or she will be issued a temporary badge; otherwise, entrance will be denied. At all times while they are in the facility, visitors must display their badges and must be escorted by a NeuStar employee. We will also strictly enforce the policy that employees wear their badges prominently displayed at all times while in the facility. During off hours (6:30 p.m. to 6:30 a.m. and all day on weekends and major holidays), individuals must use the proper electronic key cards to gain access to the building. We will issue electronic key cards only to employees who need access for business purposes.
In addition to being stationed at building entrances during normal working hours, on-site security personnel will be on duty 24 hours a day and 7 days a week to monitor the images from closed-circuit television cameras placed strategically throughout the facilities. Further, any room housing sensitive data or equipment will be equipped with a self-closing door that can be opened only by individuals who activate a palm print reader. Senior managers will establish the rights of employees to access individual rooms and ensure that each reader is programmed to admit only those authorized individuals. We will grant access rights only to individuals whose duties require them to have hands-on contact with the equipment housed in the controlled space; administrative and customer service staff normally do not require such access. The palm readers will compile and maintain a record of individuals who enter controlled rooms. The following table lists our physical security mechanisms.
Physical Security Provisions
Mechanism |
Purpose |
|
---|---|---|
Security guards | Physically prevent intruder access; verify employee badges | |
Closed-circuit video surveillance cameras |
Extend capabilities of security guards; maintain access records |
|
Intrusion detection systems |
Extend capabilities of security guards to building perimeter |
|
Identity badges |
Permanent badges for employees; easily recognizable temporary badges for visitors |
|
Sign-in registers |
Maintained as permanent records for at least one year |
|
Electronic key badges |
Control physical access during off hours; maintain access records |
|
Palm readers |
Restrict physical access to mission-critical rooms within our facilities; maintain access records |
|
Self-closing doors |
Restrict physical access to mission-critical rooms within our facilities |
Technical Security
Registry Operator's Proposal Section O.10 also describes the technical security measures that NeuStar proposes. We will use the underlying user ID and password security features of the XRP, supplemented by system-based Public Key Infrastructure (PKI) services to provide additional security. The following table lists the systems, protocols, and devices to prevent system hacks, break-ins, data tampering, and denial-of-service attacks.
O-69
Database and Operating System Security
Technical Security System Element |
Features and Benefits |
||
---|---|---|---|
Access control system: user ID and password, file level access control lists | Ensures that the user can access authorized functions, but no others, and can perform only authorized operations within these functions. For example, the registrar of a registered domain name is authorized to query it and then renew or cancel it or change its nameservers but cannot query domain names held by other registrars. | ||
Database: user ID and password, user profiles |
• |
Limits database access to pre-authorized users. |
|
• |
Retains the last two passwords and disallows their usage. |
||
• |
Rejects simultaneous sessions by an individual user. |
||
• |
Stores user profiles. |
||
• |
Limits access rights to database objects and functions to a specified user or user group. |
||
• |
Rejects unauthorized access attempts. Automatically revokes identification codes after a preestablished number of unsuccessful attempts. |
||
• |
Provides an interface to facilitate the online administration of user privileges. |
||
E-commerce Security Features |
|||
SSL v3.0 protocol |
HTTPS encryption ensures that messages between the registry and registrars/delegees can be read only by the intended receiver. |
||
Digital signatures |
Issued by an X.509 authentication server, digital signatures ensure that the incoming data actually has come from the purported sender; provides nonrepudiation. |
||
Boundary Security Features |
|||
Router |
Permits only DNS UDP/TCP packets to enter the data center LAN, thus isolating the TLD system from most potentially damaging messages. |
||
Firewall |
Guards the secure TLD LAN from the nonsecure Internet by permitting the passage of only packet flows whose origins and destinations comply with preestablished rules. |
||
Intrusion detection |
Detects intrusion at the LAN level. Displays an alert at the usTLD network operations workstation and creates a log entry. |
Availability of Backup Software, Operating System, and Hardware
Registry Operator's Proposal Section O.7 describes our zero-downtime/zero-impact backup process, which will use backup servers, disk array, and a DLT robotic tape library. The dedicated backup system will be independent of the registry server clusters that run the applications.
O-70
System Monitoring
The subsection entitled "Procedures for Problem Detection and Resolution" describes system monitoring capabilities and procedures. Our Network Management System and specialized element managers will monitor specific routers, LAN switches, server clusters, firewalls, applications, and the backup servers. In addition, the cluster management software will monitor the status and health of processor, memory, disk, and LAN components in the high-availability cluster.
Technical Maintenance Staff
The NeuStar three-tier customer service approach will ensure that all problems are resolved by the appropriate party in a timely manner.
The Technical Support Group will operate from the Help Desk Network Operations Center (NOC) within the data centers. The group will comprise system administrators, network administrators, database administrators, security managers, and functional experts in the TLD registry IT systems and applications infrastructure. usTLD registry customers access the Technical Support Group through the Tier-1 Help Desk. This group will resolve trouble tickets and technical problems that have been escalated to them by the Help Desk Customer Service Agents. If the problem involves a hardware failure, the Technical Support Group will escalate the problem to our Tier-3 on-site maintenance technicians, third-party maintenance providers, or our hardware vendors, depending on the nature of the problem.
Server Locations
NeuStar's registry servers will be located in the Enhanced SRS data centers in Virginia and Illinois. Two zone nameserver centers will be collocated with the registry data centers; the remaining nameserver center will be California, with dual-homed telecommunications links and redundant high-availability servers to provide resilience and disaster recovery.
O-71
O.13 System Recovery Procedures
NeuStar is proposing two co-active Enhanced SRS data centers and a network of nameserver data centers geographically dispersed to provide redundancy and to enable us to responsibly recover from unplanned system outages, natural disasters, and disruptions caused by human error or interference. The COTR and the Internet community can be confident that we will respond to unplanned system outages quickly with little or no loss of services.
To maintain public confidence in the Internet, the COTR surely desires a high level of system recovery capabilities. Proven industry solutions to the problems of outages and disaster recovery incorporate high-availability system architectures and fast failover from the primary data center to a mirrored backup. High-availability solutions minimize downtime with availability of 99.9 percent or greater. Continuously available solutions go a step further with virtually zero downtime, creating an availability of approximately 99.999 percent (five nines).
System recovery architectures include:
NeuStar's system recovery solution is based on running mission-critical Enhanced SRS applications at two co-active data centers (separated by nearly 700 miles) with database replication technology that maintains database synchronization between the two centers. To provide backup for DNS queries, we are implementing multiple nameserver data centers, also physically separated by long distances. We recognize that system management and recovery are more difficult when the system is spread over a large geographical area; however, two-way replication between the co-active Enhanced SRS data centers will keep the registry master databases identical.
O.13.1 Restoring Enhanced SRS Operations in the Event of a System Outage
Believing that prevention of failure is better than restoring after failure, and to maximize availability and eliminate the possibility that a single-point failure could shut down operations, we implemented each of the co-active Enhanced SRS data centers and three nameservers with:
O-72
The recovery mechanisms we will implement include:
The remainder of this subsection describes how we would recover from a system-wide disaster, that is, one that disables an entire data center. Subsection O.14.3 discusses recovery from various types of component failures.
O-73
Each of the co-active data centers is sized to take over the entire load of the Enhanced SRS operations, and each zone nameserver is dual-homed to each data center. With this architecture, recovery in the event of a disaster is nearly instantaneous. Sessions that were dropped by the data center that suffered the disaster are simply restarted on the remaining data center within seconds. The following are the main issues that our disaster recovery strategy solves:
The use of co-active data centers with two-way replication between them provides fast, simple disaster recovery that maintains continuity of operations—even in the event of a major disaster. The resulting zero-downtime/zero-impact system not only solves system recovery problems, it also sustains confidence in the Internet. The following are the procedures that are followed to restore operations if an Enhanced SRS or nameserver data center experiences a natural or man-made disaster:
Once the disaster recovery team has stabilized and tested the Enhanced SRS or nameserver equipment, it retrieves the system and application software CD-ROMs and the database backup tapes from the secure escrow. It then rebuilds the data center using the same recovery procedures that are used for restoring components lost in a more limited failure. (Subsection O.14.3 describes these procedures.)
O.13.2 Redundant/Diverse Systems for Providing Service in the Event of an Outage
NeuStar is proposing two co-active Enhanced SRS data centers and multiple zone nameserver data centers with high availability clusters and cluster management software that enables multiple node processors, in conjunction with RAID storage arrays, to quickly recover from failures. The server load
O-74
balancer and the cluster manager software monitor the health of system processors, system memory, RAID disk arrays, LAN media and adapters, system processes, and application processes. They detect failures and promptly respond by reallocating resources.
Dual database servers are coupled to a primary and a backup database and RAID configuration to ensure data integrity and access to the database. The database system uses synchronous replication, with two-way commits to replicate every transaction to the backup database. The process of detecting failures and restoring service is completely automated and occurs within 30 seconds with no operator intervention required.
O.13.3 Process for Recovery From Various Types of Failures
The following table lists the possible types of failures and describes the process for recovery.
Failures Affecting the Nameserver Sites
Failure Type |
Recovery Process |
---|---|
Nameserver cluster processor fails | Cluster management software logs out the failed processor and processing continues on the remaining nodes in the cluster. |
Internet or VPN link fails |
Ongoing sessions are dropped and restarted on the other redundant ISP or VPN access link Ongoing sessions are dropped and restarted on one of the other nameserver sites |
Edge router, firewall, or load balancer fails |
Ongoing sessions are dropped and restarted on the redundant components. |
Failures Affecting the Data Center Applications and Database Server
Failure type |
Recovery process |
---|---|
Applications cluster processor fails | Cluster management software logs out the failed processor and processing continues on the remaining processors in the cluster. |
XRP server processor fails |
Registrar session is dropped from the failed server and restarted on the other XRP server |
Web server processor fails |
Cluster management software logs out the failed processor and processing continues on the remaining processors in the cluster. |
Database server processor fails |
The operating system automatically distributes load to the remaining SMP processors |
Database disk drive fails |
Processing automatically continues on the RAID with no data loss |
Database crashes |
The applications processing continues seamlessly on the backup replicate database |
Authentication server fails |
Processing automatically continues on the redundant authentication server |
Whois cluster processor fails |
Cluster management software logs out the failed processor and processing continues on the remaining processors in the cluster |
O-75
A Billing server fails |
Processing automatically continues on the redundant B&C server |
Internet or VPN link fails |
Ongoing sessions are dropped and restarted on the other redundant ISP or VPN access link |
Router or firewall fails |
Ongoing sessions are dropped and restarted on the remaining redundant router or firewall. |
In all cases of component failure, system recovery is automatic, with zero downtime and zero impact on system users. The remainder of this subsection (O.14.3) provides additional information about failure recovery considerations for individual components.
Recovery From a Cluster Processor Failure
If one processor in a cluster fails, the cluster manager software logically disconnects that processor. While technicians repair or replace it, applications and user sessions continue on the remaining cluster processors. After the failed processor is off line, the following procedures are used to recover it:
Database System Recovery
Our database management system supports continuous operation, including online backup and management utilities, schema evolution, and disk space management. All routine database maintenance is performed while the database is online.
NeuStar's database server software solution will provide distributed redundancy by implementing synchronous replication from a primary database server to a backup database server. This solution includes automatic and transparent database failover to the replicated database without any changes to application code or the operating system.
If a database system node experiences a hardware failure or database corruption, NeuStar technicians use the following recovery procedures:
O-76
O.13.4 Training of Technical Staff Who Will Perform Recovery Procedures
NeuStar technical personnel have an average of five years of data center operations experience, encompassing the high-availability cluster technology, distributed database management systems, and LAN/WAN network management systems that are employed in the recovery process. New hires and transfers to NeuStar's usTLD registry operations will be given the following training:
O.13.5 Software and Operating Systems for Restoring System Operations
NeuStar will use commercially available Unix operating systems, cluster management software, and backup/recovery software to restore the Enhanced SRS and nameserver systems to operation. In addition to providing synchronous replication of registry transactions to the backup server, our database management system will provide data recovery services using the DLT tape backup system. Backup/recovery hardware and software at the Enhanced SRS data center will remotely back up and restore the nameservers over the VPN.
All static applications software and operating systems are backed up to DLT tape volumes and converted to CD-ROM for quick restoration in the event of operating system or application software failures. Backup copies are maintained in the data center for quick access, with additional copies in the secure escrow facility.
O.13.6 Hardware Needed To Restore and Run the System
The two co-active data centers will house the commercial off-the-shelf, redundant cluster servers and dedicated backup/recovery servers that are needed to restore the system to operation.
O.13.7 Backup Electrical Power Systems
Each of the two data centers is configured with a UPS battery backup system that provides sufficient power for 30 minutes of operation. Each one also has a transfer switch connected to 1,000-KVA motor generators that are capable of powering the entire data center for many days without commercial power.
O-77
O.13.8 Projected Time for Restoring the System
Two co-active data centers, each with high-availability clusters sized to handle the full projected registry load, provide the Enhanced SRS services.
O.13.9 Testing the System Restoration Process
NeuStar will test disaster recovery plans and outage restoration procedures annually to ensure that they can effectively restore system operations.
O.13.10 Documenting System Outages
System problem documentation includes the following:
O.13.11 Documenting System Problems That Could Result in Outages
NeuStar's proactive systems management processes include performance management, trend analysis, and capacity planning. These processes analyze system performance and utilization data to detect bottlenecks and resource utilization issues that could develop into outages. Monthly reports on the three processes keep the data center manager apprised of our performance against service level agreements and raise awareness of potential problems that could result in outages.
In addition, NeuStar performs root cause analysis of hardware and software failures to determine and analyze the reason for any failure. On the basis of our findings, we work with vendors to generate hardware service bulletins and software maintenance releases to prevent reoccurrence of these failures.
O-78
O.14 Technical and Other Support
In addition to maintaining our central Help Desk and Technical Support Team, NeuStar will offer Web-based self-help support via a Web-accessible portal, which will enable registrars to access our domain name application process, a knowledge base, and frequently asked questions.
NeuStar's technical support will satisfy several criteria:
For the expanded usTLD space, NeuStar will conform to the ICANN registry model, which provides a clear, concise, and efficient deliberation of customer support responsibilities. Registrars provide support to registrants, and registries provide support for registrars. This allows the registry to focus its support on the highly technical and administratively complex issues that arise between the registry and the registrar.
For the existing locality-based space, NeuStar will continue to support usTLD delegated managers and registrants in a manner consistent with the way they are currently supported.
O.14.1 Technical Help Systems
NeuStar will provide the following types of technical support, all available on a 24 × 7 × 365 basis:
Web Portal
NeuStar will implement a secure Web-based multimedia portal to help support usTLD customer operations. To obtain access to our Web-based services, customers must have implemented our security features, including SSL encryption, log in with user ID and password, and digital certificates for authentication.
The home page of the Web portal will include a notice to customers of planned outages for database maintenance or installation of software upgrades. This notification will be posted 30 days prior to the event in addition to active notification including phone calls and e-mail. We will also record outage notifications in the help desk database to facilitate compliance with the service-level agreement.
O-79
Finally, seven days and again two days prior to the scheduled event, we will use both an e-mail and a Web-based notification to remind registrars of the outage.
The general Internet community may obtain generic information from NeuStar's public Web site, which will describe our usTLD service offerings and list certified registrars and delegated managers providing domain name services.
Central Help Desk
In addition to implementing the Web site, we will provide telephone support to our registrars through our central Help Desk. Access to the help desk telephone support is through an automatic call distributor that routes each call to the next available customer support specialist. We will authenticate callers by using caller ID and by requesting a preestablished pass phrase that is different for each registrar. Requests for assistance may also come to the Help Desk via e-mail, either directly or via the secure Web site.
The Help Desk's three tiers of support are:
Tier-1 Support—Telephone support to usTLD Registry customers who normally are calling for help with domain name problems and other issues such as XRP implementation or billing and collection. Problems that cannot be resolved at Tier 1 are escalated to Tier 2.
Tier-2 Support—Support provided by members of the Technical Support Team, who are functional experts in all aspects of domain name registration. In addition to resolving escalated Tier 1 problems with XRP implementation and billing and collection, Tier 2 staff provide technical support in system tuning and workload processing.
Tier-3 Support—Complex problem resolution provided by on-site maintenance technicians, third-party systems and software experts, and vendors, depending on the nature of the problem.
In turn, the Help Desk uses an automated software package to collect call statistics and record service requests and trouble tickets in a help desk database. The help desk database documents the status of requests and tickets, and notifies the Help Desk when an SLA threshold is close to being breached. Each customer support and technical support specialist uses our problem management process to respond to trouble tickets with a troubleshooting, diagnosis, and resolution procedure and a root-cause analysis.
Escalation Policy
Our escalation policy defines procedures and timelines for elevating problems either to functional experts or to management for resolution if they are not resolved within the escalation policy time limits. The following table is an overview of our escalation policy.
O-80
Escalation Policy
Level |
Description |
Escalation Policy |
Notification |
|||
---|---|---|---|---|---|---|
I | Catastrophic outage affecting overall registry operations | Data center manager escalates to NeuStar management and Disaster Recovery Team if not resolved in 15 minutes | Web portal and e-mail notifications to all Registrars within 15 minutes; updates every 30 minutes | |||
II |
Systems outage affecting one or two XRP sessions but not the entire system |
Systems engineer escalates to data center manager if not resolved in one hour |
Web portal notification to all customers; hourly updates |
|||
III |
Technical questions |
Help Desk customer support specialist escalates to the systems engineer if not resolved in two hours |
Hourly updates to customer via e-mail |
|||
IV |
Basic questions |
Help Desk customer support specialist escalates to the systems engineer if not resolved within four hours |
Hourly updates to customer via e-mail |
O.14.2 Staffing
Initially, NeuStar will staff its Help Desk with a complement of customer service specialists, enabling us to operate three shifts providing 24 × 7 × 365 coverage. We will add staff as necessary to respond to incoming requests within the service level agreement. Customer service specialists will obtain assistance from NeuStar's technical staff for any problems that cannot be resolved in one phone call.
O.14.3 Test and Evaluation Facility
NeuStar will establish an operational test-and-evaluation facility that will be available 24 × 7 × 365 for registrars and delegees to test their client XRP system. Our Technical Support Team, which consists of functional experts in the processes and technologies for domain name registration, will support the registrars and delegees.
Once each new registrar/delegee is satisfied that its system is compatible with the registry system, it will schedule a formal acceptance test that will be monitored by our system engineer. After a registrar/delegee has passed the acceptance test, we will issue its user ID, passwords, and digital certificates, and the registrar/delegee can begin operations.
O.14.4 Customer Satisfaction Survey
To determine customer satisfaction with registry services, NeuStar will implement a Web-based customer satisfaction survey that will consist of a set of survey questions with responses ranging from one to five on the Likert Scale. We will tabulate the results and publish them on the Web site.
To further verify the quality of our customer services, NeuStar will commission a biannual customer satisfaction survey by an independent third party.
O-81
NeuStar has the requisite and proven capability, administrative and technical experience, and professional integrity to responsibly administer the usTLD to best serve the public interest while simultaneously enhancing its operation and usage.
HIGHLIGHTS
• | Leading neutral third-party provider of mission-critical, U.S. public resource administration services for the communications industry since 1996 |
• |
Proven experience developing innovative solutions beneficial to the industry as a whole in a highly competitive environment |
• |
A unique combination of world-class DNS registry and critical infrastructure operations expertise |
• |
Strong corporate commitment and sound financial position |
• |
Recipient of Supercomm Award for excellence in OSSs for the design and delivery of the NPAC SMS database |
The usTLD is a critical public resource that is seriously underutilized under its current administration. The United States is one of the world's technological leaders, and its namespace should be positively perceived by the Internet community and highly regarded among Americans and the rest of the world. In fact, it should be the model of a successful, widely used ccTLD. Instead, it is regarded as cumbersome and overly hierarchical. In releasing the previous RFCs and this RFQ, the Department of Commerce has shown its desire to significantly improve the usTLD by bringing it into the global Internet infrastructure while dramatically improving the awareness, utility, and value of the usTLD for its users. The DOC needs to select a responsible administrator who will meet these objectives while maintaining and promoting the integrity of the usTLD and the Internet as a whole. All of these objectives can be met only by a vendor that has a proven ability to neutrally administer complex, mission-critical systems while facilitating competition and progress in a competitive environment. Specifically, the DOC must select a vendor that has, among others, the following technical and administrative qualifications:
P-1
NeuStar is that vendor. Since 1996, NeuStar has successfully provided such mission-critical services to the U.S. communications industry. NeuStar possesses the strong management, technical capabilities, strong financial performance, and depth of experience vital for the successful administration of the usTLD.
The following table provides a detailed display of NeuStar's capabilities, as evidenced by our current projects and past performance.
NeuStar's Capabilities and Qualifications
Vendor Qualification |
|
NeuStar's Experience |
||
---|---|---|---|---|
Administration of complex, mission-critical U.S. public resources | • | NeuStar established processes working with the FCC and state commissions for reclamation of central office codes that have not been activated by service providers. | ||
• |
NeuStar developed databases for the tracking of central office code activity for the U.S. |
|||
• |
In conjunction with the industry and FCC, NeuStar developed a new method for reporting utilization and forecasting of numbering resources (NRUF) |
|||
Successfully transitioning administration of mission-critical public resources |
• |
Transitioned Telephone number administration from 10 companies with more than 100 local administrators across all 50 states to one central administrator |
||
• |
Transitioned telephone number inventory from more than 200 local databases to one central database |
|||
• |
Have been contracted to transition telephone number inventory from thousands of local databases across all 50 states to one local database |
|||
Proven neutrality in all business operations |
• |
In CC Docket No. 92-237, FCC 99-346, NeuStar was found to be in compliance with the neutrality requirements put forth in the NANP Administration Third Report and Order. |
||
P-2
• |
NeuStar undergoes a quarterly Neutrality audit performed by Ernst and Young, with a report forwarded to the FCC, NANC, and NAPM LLC. This report covers the findings of the audit regarding compliance with the NeuStar Code of Conduct and Neutrality Compliance Procedures. NeuStar asserts that it is neutral, and Ernst and Young has agreed in all audit reports. |
|||
Facilitation of controlled, systematic evolution, enhancement, and expansion of the space. |
• |
NeuStar performs the change management administration function for the NPAC SMS on behalf of the telecommunications industry. This includes over 200 change orders resulting in 7 major software releases in 4 years. |
||
• |
NeuStar hosts quarterly NPAC operations forums, known as NPAC Cross regional meetings, where issues pertinent to the operation of the NPAC and its downstream systems are discussed and resolved. |
|||
• |
NeuStar facilitated the transition of state number pooling trials to a national database focusing on a systematic evolution allowing for growth and future enhancements. |
|||
• |
NeuStar works closely with industry and the FCC to develop enhancements to the existing NANPA process, including expansion of current functions. |
|||
Experience designing, building, and supporting robust databases |
• |
NeuStar designed, built, and expanded the NPAC database from inception to its current support of 17 million ported telephone numbers in the database. The growth rate of the database is currently increasing, having surpassed 1 million additional records per month earlier this year. |
||
• |
NeuStar designed and built the pooling administration system to leverage the existing portability infrastructure. An existing NPAC database was adapted and scaled to support number pooling. |
|||
• |
NeuStar developed various NANPA-related databases to enhance functionality and streamline work efforts associated with number administration. This allows for real-time tracking of number assignment, utilization, and forecasting data. |
|||
P-3
• |
Leveraging its experience with high-availability, mission critical system in the telecommunications industry, NeuStar is developing the next generation DNS architecture for the.biz registry. |
|||
Experience that ensures real-time access to multiple users with a minimum of system outages and downtime |
• |
NPAC offers a Low Tech Interface (LTI) dialup access. This capability currently supports over 700 clients, allowing for simultaneous access by over 200 users. This access method is also fully scalable. |
||
• |
While fully scalable, the NPAC currently supports over 500 dedicated accesses by various service providers. |
|||
Manage a high availability system to contractual service levels |
• |
The NPAC SMS has 29 contractual service level requirements, developed jointly with the industry, which are reported on monthly. |
||
• |
The.biz registry has SLAs with several major Channel Partners covering limited system downtime and system performance measures. |
|||
Comprehensive understanding of the usTLD's evolution |
• |
NeuStar has monitored proceedings on the usTLD and associated DOC activities. |
||
• |
NeuStar has subject matter experts on staff who were involved with the original development of the usTLD. |
|||
• |
NeuStar is an active participant in various Internet-related forums such as the IETF and ICANN |
|||
Strong working relationships with stakeholders |
• |
NeuStar holds quarterly cross-regional meetings with LNPA stakeholders. |
||
• |
NeuStar holds weekly conference calls with LNP LLCs, the NPAC contracting parties, in addition to holding monthly face-to-face meetings to discuss operational issues. |
|||
• |
NeuStar actively participates in various industry forums, including LNPA WG, NOWG, IETF, ICANN, and ITU. |
|||
• |
NeuStar provides assistance to both the telecommunications industry and regulators in an effort to resolve difficulties in the area of number assignment, reporting, etc. |
|||
Facilitation of progress in a political and competitive environment |
• |
NeuStar acted as interim pooling administrator in several states prior to being selected as National Pooling Administrator. |
||
P-4
• |
NeuStar facilitates NPA relief planning meetings, resulting in a relief plan which meets the needs of the industry and the regulators. |
|||
• |
NeuStar provided objective information and assistance to the LNPA WG in an effort to resolve issues facing the entire telecommunications industry. |
|||
Ability to address long-term management issues |
• |
Developed Number Resource Utilization Forecasting tool, ensuring that appropriate detailed carrier information is collected, stored, analyzed, and properly distributed to appropriate regulatory authorities |
||
• |
Work closely with INC, NANC, and LNPA WGs to ensure that long term Number Resource Optimization needs are and will continue to be achieved |
|||
• |
Developed long term strategic view of the needs of telecommunication service providers and regulators |
|||
Experience in building scalable databases that ensure security of personal data |
• |
NeuStar developed, deployed, and supports the Customer Account Management Exchange database, which contains highly proprietary service provider information. |
||
• |
NeuStar developed, deployed, and maintains the Number Portability Administration Center, which contains routing information for all calls placed in the US and Canada. |
|||
• |
NeuStar maintains physical biometric facility security, with fulltime monitoring, strong physical security, and token authentication for dial-up access. |
|||
Ability to understand, develop, and manage all associated policy issues |
• |
NeuStar has an in-depth understanding all federal and state policy issues regarding number administration, in addition to meeting requirements developed by the industry which are seen to be the guidelines under which NANPA operates |
||
• |
NeuStar's experience in the policy rich telecommunications regulatory environment provides it with significant insight into the proper means for policy identification and coordination for the Internet. |
|||
P-5
• |
NeuStar is active in ICANN, the IETF and other Internet-related policy and standards bodies. NeuStar has a staff of experts on Internet policy and technical matters. NeuStar policy and legal experts participate heavily in ICANN constituencies' activities. |
|||
• |
NeuStar has an in-depth understanding of federal and state regulatory processes that are likely to be of prominent importance to Internet policy in the future. |
|||
Support and drive important technology standards |
• |
NeuStar is an active participant at the IETF where important internet technology protocols are developed. We are currently co-chairs of two IETF WGs including the Whois WG. |
||
• |
NeuStar has authored important IETF draft standards documents including one for a registry-registrar protocol. |
|||
• |
NeuStar developed and patented the call processing technology used to enable telephone number portability. We patented the technology and made it freely available. |
|||
Proven reputation for fair, impartial policy management |
• |
NeuStar has extended its LNPA contract for an additional 3 years over its existing 5-year contract without going through the competitive bid process, with approval by the FCC. |
||
• |
NeuStar was selected by various service providers to provide Customer Account Record Exchange service via an in-house-developed database system. |
|||
• |
Through its audit activities regarding NeuStar, Ernst & Young has consistently reported positive compliance to the Code of Conduct and Neutrality Compliance Procedures as approved by the FCC. |
|||
Strong financial performance and stability |
• |
NeuStar's existing lines of business are net income and cash flow positive |
||
• |
NeuStar's recent round of equity financing fully funded our business plan; if additional capital is required, our investment partner, Warburg Pincus, stands prepared to fund all NeuStar initiatives. |
|||
• |
NeuStar has experienced strong revenue growth, from $6M in 1997 to $67M in 2000. |
P-6
P.1 Registry, Database, and Internet Experience
NeuStar combines comprehensive registry operations experience with extensive DNS knowledge to effectively administer the usTLD.
Effective, responsible administration of the usTLD requires that its operator understand the fluid, innovative environment of the Internet and demonstrate proven ability to build and manage a registry. The usTLD registry operator must have substantial experience and proven credentials in managing a significant public database, the ability to facilitate discussions about standards development and technical issues between competing parties, and a commitment to the security of proprietary data to ensure competition. In addition, the registry operator must have demonstrable evidence of its ability to design, build, and maintain a robust, responsive, scalable, and secure database to ensure the highest levels of quality and flexibility in the changing world of global communications. As an administrator, that operator must also have the ability to develop and manage policy issues, maintain strong working relationships with stakeholders, and control the systematic evolution, enhancement, and expansion of the usTLD space.
NeuStar is a leader and innovator in these areas and has been instrumental in the effective management, solution development, and policy guidelines for managing critical public resources. Our administrative roles, as the North American Numbering Plan Administrator, Local Number Portability Administrator, and Pooling Administrator, directly qualify us for a similar role as the usTLD Administrator. In all of these roles, we provide mission-critical resources to U.S.-based public resources. Furthermore, in all of these roles, we designed a transition plan that allowed us to smoothly transition and begin operations, either on time or ahead of schedule.
NeuStar has extensive experience in transitioning the administration of mission-critical public resources from multiple geographically dispersed entities to one central administrator. Our transition of the North American Numbering Plan Administration (NANPA) from the legacy operators to NeuStar is a particularly relevant example. In 1997, NeuStar was awarded the responsibility of administrating telephone numbers for the North American Numbering Plan. Prior to NeuStar's administration, ten large phone companies administered phone numbers across all fifty states. Each company had multiple local number administrators in each state. Part of NeuStar's responsibility was to transition the administration from over a hundred local administrators. This required an intensely coordinated effort involving site visits, coordination meetings, and progress reports. It was not uncommon to have to sift through file cabinets to find current and historical inventories. In many cases, the existing administrators could provide little support because they were new to the job or did not have historical data. Despite the difficulty involved, NeuStar was able to transition the administration well ahead of schedule. The NANPA registry of telephone number assignments is now a critical element of the U.S. telecommunications infrastructure.
A second example involves the transition of telephone number inventory from hundreds of telephone companies with hundreds of different databases to one central database. NeuStar has won number pooling administration contracts in over 12 different states. Number pooling involves transitioning unused telephone numbers from multiple telephone companies to one central administrator. The unused numbers can then be redistributed to other telephone companies. This is a very difficult process, because it involves hundreds of phone companies with multiple administrators and different databases. There is also a public outreach effort that involves assisting the phone companies in taking inventory, and evaluating the inventory for usable numbers. NeuStar has to advise the individual companies on the format of the data and the process they need to undertake to transition the numbers to us. Once NeuStar has transitioned the inventory, we are responsible for redistributing it in a neutral, even-handed, yet conservative manner. Recently, NeuStar was awarded the
P-7
contract to take on this responsibility on a federal level for all 50 states. This will involve over 3,000 different entities.
One of the most significant benefits of a domain name is its portability and free movement between Internet Service Providers. The registry systems developed by NeuStar to administer telephone numbering are directly analogous to a domain name registry, and parallels exist between the DNS and telephone number portability. For example, the telephone numbering system in North America is broken down by area codes and a second set of three digits referred to as the NXX or prefix component of a telephone number. It is a hierarchical delegation system similar to the DNS. Prior to 1996, consumers were unable to enjoy the benefits of telephone number portability because of the monopoly environment at the Local Service Provider (LSP) level. In April 1996, NeuStar was selected by the Illinois Commerce Commission SMS/RFP Subcommittee to develop a Number Portability Administration Center (NPAC) and provide turnkey and operational NPAC services initially within Chicago. The Number Portability Administration Center (NPAC) Service Management System (SMS) is a master registry of routing information that interfaces with the local carrier's administration systems. The NPAC SMS interfaces directly to Local Exchange Carriers' key operational systems and operation processes. The NPAC SMS developed and maintained by NeuStar coordinates the porting of telephone numbers between carriers and downloads routing information to carriers' local systems, which in turn update local databases.
Since the introduction of the NPAC, Local Number Portability has revolutionized the U.S. telecommunications industry. Through competitive procurement processes, NeuStar was selected to provide telephone number registry services for a five-year term in four regions of the United States. The competing vendor was selected in the three remaining U.S. regions and Canada. In early March 1998, the other three regions—Southeast, Western, and West Coast—terminated their vendor contracts due to poor performance and executed contracts with NeuStar for NPAC SMS services, with Canada following soon after. Consequently, NeuStar now provides telephone number portability services to all of the United States and Canada, processing in excess of tens of millions of transactions per day, and serving more than 4,000 service providers across North America. As the operator of the NPAC master telephone registry, NeuStar:
All of these qualifications are directly applicable to the administration of the usTLD. While the NPAC registry perhaps most clearly demonstrates NeuStar's experience in developing and administering a registry, we have developed similar systems for the management of the North American Numbering Plan, European Telephony Numbering Space, Number Pooling, and the.biz TLD. In short, NeuStar provides a level of skill and experience in registry operations in the United States that simply cannot be matched.
P-8
P.2 Technical Capabilities
NeuStar offers comprehensive technical capabilities in the areas of registry operation, software development, database management, and standards development. These abilities are founded on expansive experience in all areas related to technical service provision for a critical public resource. NeuStar is the best choice to design, deliver, and maintain the next-generation domain name registry for the usTLD.
Any top-level domain registry operator must be capable of improving the reliability and effectiveness of domain name registration, contribute responsibly to a competitive environment, and preserve the Internet's continuing stability. In addition, the registry operator must bring the technical know-how to specify and design a solution that ensures the continuing evolution of the domain name system.
There are many complexities within the DNS and registry environment that require a detailed understanding of the issues and their implications on the technical solution. For instance, a minor change in policy can have far-reaching implications on how a database needs to behave in order to ensure the integrity and efficiency of domain name registration and administration. But the usTLD space presents even more complexity because it must accommodate both the current hierarchical locality structure while allowing second-level registrations in the new, expanded space. Management of the usTLD registry also brings with it an immense responsibility in the secure administration of personal and business contact information. The public sees a country code domain as having the highest level of integrity, and it is essential that the registry operator understands this and stores all registry data with the highest levels of security. It is vital for the success of the usTLD that the registry operator understands the entire operating environment and has the experience and ability to deliver a solution that benefits all relevant stakeholders. NeuStar has the technical capabilities to deliver that solution.
NeuStar specializes in developing and operating unique support services for the Internet and communications industries by using innovative solutions employing the highest standards and practices and by providing services in an impeccably evenhanded fashion as a trusted third party.
As the North American Numbering Plan Administrator, NeuStar operates the telephone numbering registry for the North American Numbering Plan as a public numbering resource. NeuStar is also the Local Number Portability Administrator for the United States and Canada, operating the telephone number routing registry for North America. The integrity and accuracy of these services are essential for virtually every call placed in North America.
The Number Portability Administration Center Service Management System hosts the routing registry that is used to track network and call routing, SS7 signaling, and billing information for all telephone numbers in North America. We provide, directly or indirectly, highly secure host-to-host administrative transaction interfaces to this registry for all 5,000 service providers in North America. The service providers' operational support systems (OSSs) require the highest availability standards of our service to manage and operate their networks.
Consequently, we operate this service to 29 monthly service level requirements (SLRs), including availability (99.99%), transaction response time, throughput, and help desk telephone call answer times, and we pay financial penalties for missing any of these levels. Between our data centers, we provide real-time database replication and server failover/recovery functions and fully redundant enterprise networking facilities. Our data centers are owned and operated by NeuStar, are staffed 24 × 7 by our own network operations center personnel, are physically located in the United States, and are secured by both card key and palm print readers.
NeuStar operates its services, including the NPAC SMS, from a unique world-class Internet Protocal network and server infrastructure housed in our own diverse, redundant data centers. We
P-9
operate highly secure, quad redundant enterprise IP network application servers and support servers (e.g., DNS, NNTP, and RADIUS/SecurID) that provide dedicated access directly to more than 300 communication service providers and indirectly to all 5,000 service providers in North America. At approximately 900 Mbps of aggregate capacity, our IP network provides diverse BGP-4 routed links to external service provider OSSs and network elements. In addition, we support more than 1,000 dial-up or secured Internet users from our customers to access our services via Web-based interfaces. In case of failure of a service provider's OSS, they may log directly into our Web-based NPAC GUI to provide critical network management functions. All dial-up users (internal or external) must use a NeuStar-issued SecurID for strong authentication.
Each data center has a completely redundant, hardened, switched VLAN backbone and a redundant set of network access servers and firewalls. All critical application and database servers are dual-homed to each of these site-based backbones, using a virtual-IP address assigned to each host that is reachable through either NIC port on that host through either backbone. Each NIC port and backbone link is assigned a 4-IP address subnet to ensure quick detection of NIC/link/port failures and maintain full reachability of that server without impacting established internal or external communication associations. Certain key services (such as NPAC SMS application and database servers) are implemented using approximately 64 Lucent (Stratus) hardware fault tolerant HP-UX servers.
The NeuStar network is structured into a series of security rings to provide firewall isolation of traffic from various sources and applications. All Internet-reachable systems are placed onto one of a series of bastion subnets (bracketed by firewalls) to ensure security of the core network in the unlikely case of a server breach on the bastion network. All external data network links employ extensive BGP-4 route filtering to ensure that only appropriate internal routes are advertised and that routes to other service providers' networks are not advertised or reachable.
While extensively using standard, well-known, protocols (e.g., BGP-4), we also employ certain relatively unusual protocols, such as CMIP over IP, which are common in OSS applications. The NPAC service employs this protocol to provide a distributed, bi-directional, object-oriented application framework for interacting with the registry. Strong authentication is employed for accepting CMIP associations from service providers' OSSs, with an extensive administrative key management infrastructure to support. Each service provider system is assigned a list of keys, each at least 660 bits in length. Each and every CMIP provisioning transaction is individually signed to provide the highest in authentication and non-repudiation, given the potential operational and financial impacts one service provider could cause another. Given the millions of transactions we process every day, we have employed extensive hardware-based crypto accelerators to ensure the highest performance levels without sacrificing security. Given the industry critical nature of the NPAC service, standardizing access to it from service providers' OSSs was essential. In 1996 we developed the CMIP interface standards for the NPAC and subsequently placed them in the public domain. They are now managed under the auspices of a specific industry standards body (the NANC LNPA WG) to whom we provide ongoing secretarial and change management support for maintenance of the standards.
These levels of standards are highly relevant and appropriate for a DNS registry provider, given the importance of the DOC's usTLD initiatives and the vital need to do so while enhancing the value of the usTLD and maintaining the stability of the Internet. They exemplify our fluency with both the technical operational security and overall business standards with which industry-critical services of this kind must be provided in the interest of all industry stakeholders.
NeuStar's technical capabilities have extended even further since taking on the role of.biz registry operator. NeuStar's advanced TLD registration system uses a high-performance and highly scalable 3-tier architecture. The tiers include a Web/protocol server tier, an application server tier, and a back-end server tier (e.g., database, billing, credit card payments, and registry server). The registration
P-10
system has been developed with a custom-built application server and associated infrastructure. Security has been a priority throughout both the software architecture and network design.
The infrastructure has built-in redundancy with multiple servers in the Web/protocol, application, and database tiers and has been engineered for high fault tolerance. In addition, network devices such as routers, firewalls, and load-balancers have been deployed in a fully redundant configuration. Each tier is configured as a cluster, with failed servers being automatically removed from the cluster. Capacity planning has been done to scale throughout the environment so that there is plenty of room for future growth.
Because we operate through a channel partner network, we have experience providing integration protocols including http Post, XML, and e-mail templates and using security mechanisms such as SSL and PGP. NeuStar's research group was an active leader in the development of new industry standards and has participated in the development of an XML-based domain name registration protocol which has been deployed in our.biz operation.
The scope of NeuStar's experience includes design and development of secure, real-time resource management systems; implementation of high-transaction, high-availability database solutions; design and management of transcontinental IP networks; and the effective and timely delivery of technical solutions within highly regulated environments. For all of these reasons, NeuStar is the best choice for developing and delivering a responsible and stable solution for the usTLD registry.
P.3 Past Performance References
NeuStar's solid customer contact references are a reflection of the high regard in which NeuStar is held and are directly attributable to our commitment to integrity.
Some vendors without extensive experience in developing and administering large-scale registry operations might not have the customer contact references needed to successfully meet the DOC's requirements for the usTLD. Other vendors may have all the necessary references but will lack the neutral third-party component necessary to ensure that all users are dealt with in an equitable manner and that a broad industry-wide approach to resolving the issues is taken. NeuStar has both. We are proud of our work and the relationships we have with our current customers and respectfully submit the following past performance references for you to contact at your discretion. Further, we would welcome a site visit by the DOC Contracting Officer and COTR.
P-11
Past Performance References Information
Required Information |
NeuStar Response |
||
---|---|---|---|
Type of Work | North American Numbering Plan Administration | ||
Contract Number or Purchase Order Number |
FCC 97-372, FCC 99-346 |
||
Duration of the Contract or Purchase Order |
November 1997-November 2002 |
||
Dollar value of the Contract or Purchase Order |
$24.9M |
||
Type of Contract or Purchase Order |
Fixed Price |
||
Name and Address of Customer Organization |
FCC 445 12th St., SW Washington, DC 20005 |
||
Technical Point of Contact at Customer Organization for the Contract or Purchase Order |
Cheryl Callahan Common Carrier Bureau FCC 445 12th Street, SW Washington, DC 20045 TN: 202-418-1806 Fax: 202-418-2345 e-mail: ccallaha@fcc.gov |
||
Information for an Alternative Customer Organization Point of Contact |
Same as above |
||
Detailed Description of the Effort Performed by the Contractor/Subcontractor under the Contract or Purchase Order |
• |
NeuStar operates the telephone numbering registry for the North American Numbering Plan as a vital national public numbering resource. |
|
• |
Primary functions include the assignment and administration of Numbering Plan Area (NPA) codes, central office codes, Carrier Identification Codes (CIC), and other numbering resources. In addition, NANPA provides area relief planning services and collects utilization and forecast data for projecting the exhaust of NPAs and the NANP. |
P-12
Past Performance References Information
Required Information |
NeuStar Response |
||
---|---|---|---|
Type of Work | .biz Registry Operations | ||
Contract Number or Purchase Order Number |
Registry Agreement between NeuLevel, a majority owned subsidiary of NeuStar and ICANN |
||
Duration of the Contract or Purchase Order |
Base: 5 years from commencement of operation (expected 4Q01) |
||
Dollar value of the Contract or Purchase Order |
Transaction Based: Base Registrations $5.30/year |
||
Type of Contract or Purchase Order |
Transaction Based |
||
Name and Address of Customer Organization |
ICANN 4676 Admiralty Way, Suite 330 Marina del Ray, CA 90292 TN: 310-823-9358 Fax: 310-823-8649 e-mail: icann@icann.org |
||
Technical Point of Contact at Customer Organization for the Contract or Purchase Order |
Louis Touton TN: 310-823-9358 |
||
Information for an Alternative Customer Organization Point of Contact |
N/A |
||
Detailed Description of the Effort Performed by the Contractor/Subcontractor under the Contract or Purchase Order |
• |
..biz gTLD ICANN registry operator. |
|
• |
Process registrations for domain names. |
||
• |
Manages registry databases that facilitate navigation to.biz addresses. |
||
• |
Creates centralized zone files. |
||
• |
Manages Sunrise and Landrush policies. |
||
• |
Addresses intellectual property disputes through mediation. |
||
• |
Manages.biz space in accordance with ICANN policies. |
||
• |
Works closely with all industry participants. |
P-13
Past Performance References Information
Required Information |
NeuStar Response |
||
---|---|---|---|
Type of Work | National Pooling Administration | ||
Contract Number or Purchase Order Number |
CON 01000016 |
||
Duration of the Contract or Purchase Order |
6/15/01-6/15/02, with four additional one-year options |
||
Dollar value of the Contract or Purchase Order |
$17,902,666 exclusive of award fee |
||
Type of Contract or Purchase Order |
Cost-plus-award-fee |
||
Name and Address of Customer Organization |
FCC/Contracts and Purchasing Center 445 12th St., SW Washington, DC 20005 |
||
Technical Point of Contact at Customer Organization for the Purchase Order |
Mr. Mark Oakey, (202) 418-0933 Fax: N/A, moakey@fcc.gov |
||
Information for an Alternative Customer Organization Point of Contact |
N/A |
||
Detailed Description of the Effort Performed by the Contractor/Subcontractor under the Contract or Purchase Order |
• |
Pooling Administrator manages the number administration and assignment processes that allocate numbering resources to a shared industry inventory associated with a designated geographic area. |
|
• |
Allocates telephone numbers in 1000 number parcels. |
||
• |
NeuStar works with the industry to suggest changes and modifications to pooling guidelines and administers number pooling in accordance with industry guidelines. |
||
• |
Actively participates in industry forums. |
||
• |
Provides help desk support to users. |
P-14
Past Performance References Information
Required Information |
NeuStar Response |
||
---|---|---|---|
Type of Work | European Telephony Numbering Space (ETNS) Administration | ||
Contract Number or Purchase Order Number |
Private contract with ERO |
||
Duration of the Contract or Purchase Order |
5 years from first Turnup date 3-1-01 |
||
Dollar value of the Contract or Purchase Order |
Transaction Based |
||
Type of Contract or Purchase Order |
Transaction Based |
||
Name and Address of Customer Organization |
European RadioCommunication Office (ERO) Midtermolen 1 DK 2100 Copenhagen |
||
Technical Point of Contact at Customer Organization for the Contract or Purchase Order |
European RadioCommunication Office (ERO) Vince Humphries Midtermolen 1 DK 2100 Copenhagen TN: +45 35250300 e-mail: ero@ero.dk |
||
Information for an Alternative Customer Organization Point of Contact |
Same as above |
||
Detailed Description of the Effort Performed by the Contractor/Subcontractor under the Contract or Purchase Order |
• |
Administrator for European Telephony Numbering Space Service for 43 European Conference of Postal and Telecommunications Administrations (CEPT) countries. |
|
• |
Maintains a registry of all ETNS numbers. |
||
• |
Provides help desk support to users. |
||
• |
Tracks and coordinates service providers and serving networks. |
P-15
NeuStar is committed to providing the highest level of quality and performance to ensure the overall integrity of this mission-critical service.
HIGHLIGHTS
Performance Measurements are designed to ensure:
When the Department of Commerce selects a vendor, it must consider not only the vendor's cost components and ability to design and develop a system but also the overall quality of the vendor's products and services. Because NeuStar is in the business of providing mission-critical services, quality is of utmost importance to us. We do not provide systems, we provide service. Our staff recognizes quality and performance as an ongoing and evolving process that facilitates our commitment to continuous improvement by meeting the demands of our customers and the ever-changing marketplace. Through education and training opportunities, we promote teamwork, empowerment, leadership, strategic planning, and personnel development. The quality performance measurement system attributes managed by our staff include reliability, interoperability, availability, responsiveness, effective communication, accuracy, security, and one of our strongest value-added trademarks—neutrality.
NeuStar's Quality Management Program drives the delivery of all our services. Our performance measurement system, the heart of our Quality Management Program, is managed through strategic Monthly Operational Reviews (MORs)—meetings of senior and executive management during which progress and results are discussed—as well as through various additional operational and tactical reviews. In conjunction with our Quality Management Program, NeuStar is committed to constantly improving our services while ensuring high levels of responsiveness to customer requests. NeuStar continues to work with its customers to identify the key processes required for problem resolution and delivery of quality services, including measures to assess database performance, accessibility, and staff responsiveness to customer issues. Our Customer Relationship Management (CRM) practices capture aspects of our performance relevant to our customers to ensure increased competitiveness, greater customer value, and delivery of world-class products and services. In addition, NeuStar's upper management commitment to provide world-class products and services to our customers on a consistent, timely, and accurate basis is central.
NeuStar's Quality Management Program ensures effective business account management, compliance with standards and applicable Service Level Agreements, and cost-effective operations analysis while maintaining our competitive business edge within the communications industry. Our program is well administered and supported within NeuStar across all functional groups including:
Q-1
NeuStar is committed to providing a high level of performance to the usTLD community. To that end, NeuStar proposes Performance Measurements related to the operation of the usTLD registry. The purpose of these Performance Measurements is to ensure that the registry consistently performs at high levels to meet the needs of the industry, to ensure the reliability of this mission-critical infrastructure, and to ensure stability of the usTLD. Comparable benchmarks for service level agreements are typical for public resources, and the usTLD should be no exception.
NeuStar believes that Performance Measurements are so important to the proper functioning of the usTLD Administrator that we have integrated detailed Performance Measurements into our usTLD Draft Registry-Registrar Agreements. Not only have we integrated the measurements into the agreements, but we have included credits to be paid to the registrars if we fail to meet any of them.
For a detailed description of the Performance Measurements, please see Exhibit G of the usTLD Registry-Registrar Agreement in Section H of this proposal. For a detailed description of the Performance Credits, please see Exhibit H of the same agreement.
We believe these measures will provide accurate indicators of NeuStar's progress under the project and assessment of services offered. Further, as required, for the first two years of the purchase order, we will submit monthly progress reports to the COTR, in writing, detailing the Contractor's progress toward meeting the purchase order SOW requirements. These reports are described in Section B.2.15, Progress and Quarterly Reporting.
Q-2
R. Representations and Certifications of Offerors
REPRESENTATIONS AND CERTIFICATIONS OF OFFERORS
1. 52.219-1 SMALL BUSINESS PROGRAM REPRESENTATIONS (MAR 2001)
(a)(1) The North American Industry Classification System (NAICS) code for this acquisition is 541519
(2) The small business size standard is $18.0 million.
(3) The small business size standard for a concern which submits an offer in its own name, other than on a construction or service contract, but which proposes to furnish a product which it did not itself manufacture, is 500 employees.
(b) Representations. (1) The offeror represents as part of its offer that it o is, ý is not a small business concern.
(2) [Complete only if the offeror represented itself as a small business concern in paragraph (b)(1) of this provision.] The offeror represents, for general statistical purposes, that it o is, o is not, a small disadvantaged business concern as defined in 13 CFR 124.1002.
(3) [Complete only if the offeror represented itself as a small business concern in paragraph (b)(1) of this provision.] The offeror represents as part of its offer that it o is, o is not a women-owned small business concern.
(4) [Complete only if the offeror represented itself as a small business concern in paragraph (b)(1) of this provision.] The offeror represents as part of its offer that it o is, o is not a veteran-owned small business concern.
(5) [Complete only if the offeror represented itself as a veteran-owned small business concern in paragraph (b)(4) of this provision.] The offeror represents as part of its offer that it o is, o is not a service-disabled veteran-owned small business concern.
(c) Definitions. As used in this provision—
"Service-disabled veteran-owned small business concern"—
(1) Means a small business concern—
(i) Not less than 51 percent of which is owned by one or more service-disabled veterans or, in the case of any publicly owned business, not less than 51 percent of the stock of which is owned by one or more service-disabled veterans; and
(ii) The management and daily business operations of which are controlled by one or more service-disabled veterans or, in the case of a veteran with permanent and severe disability, the spouse or permanent caregiver of such veteran.
(2) Service-disabled veteran means a veteran, as defined in 38 U.S.C. 101(2), with a disability that is service-connected, as defined in 38 U.S.C. 101(16).
"Small business concern," means a concern, including its affiliates, that is independently owned and operated, not dominant in the field of operation in which it is bidding on Government contracts, and qualified as a small business under the criteria in 13 CFR Part 121 and the size standard in paragraph (a) of this provision.
"Veteran-owned small business concern" means a small business concern—
(1) That is at least 51 percent owned by one or more women; or, in the case of any publicly owned business, at least 51 percent of the stock of which is owned by one or more women; and
R-1
(2) The management and daily business operations of which are controlled by one or more veterans.
"Women-owned small business concern," means a small business concern—
(1) Which is at least 51 percent owned by one or more women or, in the case of any publicly owned business, at least 51 percent of the stock of which is owned by one or more women; and
(2) Whose management and daily business operations are controlled by one or more women.
(d) Notice. (1) If this solicitation is for supplies and has been set aside, in whole or in part, for small business concerns, then the clause in this solicitation providing notice of the set-aside contains restrictions on the source of the end items to be furnished.
(2) Under 15 U.S.C. 645(d), any person who misrepresents a firm's status as a small, HUBZone small, small disadvantaged, or women-owned small business concern in order to obtain a contract to be awarded under the preference programs established pursuant to section 8(a), 8(d), 9, or 15 of the Small Business Act or any other provision of Federal law that specifically references section 8(d) for a definition of program eligibility, shall—
(i) Be punished by imposition of fine, imprisonment, or both;
(ii) Be subject to administrative remedies, including suspension and debarment; and
(iii) Be ineligible for participation in programs conducted under the authority of the Act.
(End of provision)
(a) The definitions and prohibitions contained in the clause, at FAR 52.203-12, Limitation on Payments to Influence Certain Federal Transactions, included in this solicitation, are hereby incorporated by reference in paragraph (b) of this certification.
(b) The offeror, by signing its offer, hereby certifies to the best of his or her knowledge and belief as of December 23, 1989 that—
(1) No Federal appropriated funds have been paid or will be paid to any person for influencing or attempting to influence an officer or employee of any agency, a Member of Congress, an officer or employee of Congress, or an employee of a Member of Congress on his or her behalf in connection with the awarding of a contract resulting from this solicitation;
(2) If any funds other than Federal appropriated funds (including profit or fee received under a covered Federal transaction) have been paid, or will be paid, to any person for influencing or attempting to influence an officer or employee of any agency, a Member of Congress, an officer or employee of Congress, or an employee of a Member of Congress on his or her behalf in connection with this solicitation, the offeror must complete and submit with its offer, OMB standard form LLL, Disclosure of Lobbying Activities, to the Contracting Officer, and
(3) He or she will include the language of this certification in all subcontract awards at any tier and require that all recipients of subcontract awards in excess of $100,000 must certify and disclose accordingly.
(c) Submission of this certification and disclosure is a prerequisite for making or entering into this contract imposed by section 1352, title 31, United States Code. Any person who makes an expenditure prohibited under this provision or who fails to file or amend this disclosure form to be filed or amended by this provision, must be subject to a civil penalty of not less than $10,000, and not more than $100,000, for each such failure.
R-2
[End of Clause]
R-3
NeuStar's Data Universal Numbering System (DUNS) number, presented below, is also provided on the bottom left-hand corner of the transmittal form.
11-240-3295
S-1
T. Transition and Project Plan
NeuStar's proven program management method-ology ensures the successful implementation of robust, high-availability mission-critical systems and operations. NeuStar has a long legacy of transitioning administration of public resources to next-generation, open-interface platforms and will effect a seamless, transparent, and low-risk transition through a thoughtful, deliberate transition plan.
HIGHLIGHTS
A well-thought-out, proven program management methodology is a critical factor for implementing and running a successful TLD registry. Absent this critical component, the project could easily fail. At NeuStar, we believe, of course, that such easily avoided failure is unacceptable.
Another critical element for the successful implementation of the usTLD, is the need for a smooth, seamless transition from the legacy administrator to the new administrator. Indeed, from NeuStar's perspective, a successful transition is the most important aspect of this project for maintaining stability and integrity of the usTLD and the Internet and ensuring the highest degree of service to the United States Internet community. NeuStar has proven our capabilities in transitioning data and services from legacy systems to next-generation, open-interface platforms numerous times.
NeuStar has extensive experience in transitioning the administration of mission-critical public resources from multiple geographically dispersed entities to one central administrator. Our transition of the North American Numbering Plan Administration (NANPA) from the legacy operators to NeuStar is a particularly relevant example. In 1997, NeuStar was awarded the responsibility of administrating telephone numbers for the North American Numbering Plan. Prior to NeuStar's administration, ten large phone companies administered phone numbers across all fifty states. Each company had multiple local number administrators in each state. Part of NeuStar's responsibility was to transition the administration from over a hundred local administrators. This required an intensely coordinated effort involving site visits, coordination meetings, and progress reports. It was not uncommon to have to sift through file cabinets to find current and historical inventories. In many cases, the existing administrators could provide little support because they were new to the job or did not have historical data. Despite the difficulty involved, NeuStar was able to transition the administration well ahead of schedule. The NANPA registry of telephone number assignments is now a critical element of the U.S. telecommunications infrastructure.
A second example involves the transition of telephone number inventory from hundreds of telephone companies with hundreds of different databases to one central database. NeuStar has won number pooling administration contracts in over 12 different states. Number pooling involves transitioning unused telephone numbers from multiple telephone companies to one central administrator. The unused numbers can then be redistributed to other telephone companies. This is a very difficult process, because it involves hundreds of phone companies with multiple administrators and different databases. There is also a public outreach effort that involves assisting the phone companies in taking inventory, and evaluating the inventory for usable numbers. NeuStar has to advise the individual companies on the format of the data and the process they need to undertake to
T-1
transition the numbers to us. Once NeuStar has transitioned the inventory, we are responsible for redistributing it in a neutral, even-handed, yet conservative manner. Recently, NeuStar was awarded the contract to take on this responsibility on a federal level for all 50 states. This will involve over 3,000 different entities.
Because of our firm belief that effective transition is an indispensable part of our overall project plan for the usTLD, we are presenting a detailed Transition Plan and explanation of our comprehensive Project Plan. We are proud of our demonstrated ability to effect timely successful transitions of complex systems and are eager to apply our expertise to the usTLD.
T.1 Transition to New usTLD Administrator
NeuStar will leverage our experience in successfully transitioning other mission-critical resources to ensure a smooth and seamless transition of the usTLD administration.
The DOC faces a challenge in selecting a vendor that not only is qualified to build a robust registry system, but also is qualified to transition mission-critical operations and resources, such as the existing locality-based usTLD. The usTLD domain structure is part of the Internet critical infrastructure, and many U.S. citizens rely upon its being a zero-downtime operation. NeuStar has faced the challenge of transitioning these kinds of resources and has succeeded in all of our transition and implementation operations. NeuStar submits that no other potential respondent to the RFQ has the kind of critical transition experience required by this RFQ.
The key requirements for safe transition are careful planning; phased incremental transition stages, and the allocation of sufficient resources to oversee the process, achieve necessary changes, and recover promptly from any difficulties that may arise. Absolutely crucial is the cooperation of the previous administrator. Our experience as the NANPA and LNPA have proven that nonresponsiveness from legacy operators hinders progress and is detrimental to both the system and its customers.
The DOC must ensure that it does not select a vendor for the usTLD that underestimates the importance of potential complexity of the transition process. The transition process that we present here is comprehensive and sufficiently detailed in its incremental approach to transition of an operation involving critical infrastructure, to ensure a seamless and stable transition.
T.1.1 Requirements for Successful Transition
Transition for the usTLD entails a number of different processes.
Because the first two steps form the framework for the third step, this section focuses on these formative processes. The expansion and further enhancement of the usTLD is addressed elsewhere in this proposal. Changes to the existing usTLD administration first require the compliance investigation and report that is correctly mandated by the DOC. This is because enhancements cannot be intelligently specified without having much detail as possible about the current base of delegees and users, and changes need to be pursued as a collaborative effort with the existing usTLD community.
To initiate the transition process immediately upon award, certain information will be required:
T-2
The specific information items required to initiate the transition process are:
Requirements for a Successful Transition
NeuStar Needs From Current Administrator |
Why/Benefits |
||
---|---|---|---|
All contact information for current delegees | This information is needed to begin the required compliance investigation and report. | ||
Historical information including delegations and re-delegations made after July 1, 1997 |
Historical data can put current situation in context. Delegation and re-delegation done after July 1, 1999 requires written proof. |
||
Copy of zone file as of award date |
Needed as a development tool to permit production testing prior to operational commitment. |
||
All registration data, including but not limited to: |
|||
• • • • • • • • |
Up-to-date list of all delegees including dates of delegation Agreements with delegees Agreements with registrants Registration information for direct registrants Policies and understandings, written or otherwise (generally understood) Previous contracts, understandings, and agreements Whois information DNS zone snapshot at transition event |
The complete set of registration data is needed in two phases. The first allows awardees to gain familiarity with the registrations and to prepare registration software. The second permits the awardees' operations databases to be current at the time of handoff. Information about delegees and agreements with them are essential for permitting awardees to make contact and understand existing arrangements with delegees. Information about direct registrants and agreements with them is essential for the same reason. Copies of existing policies allow NeuStar to continue operations and then introduce changes incrementally. The same is true for obtaining copies of existing databases. |
|
Current, internal operational policies and procedures |
Familiarity with existing practices is necessary to continue them and ensure that changes are incremental |
||
Data formats |
Essential for automated incorporation of existing data |
||
Database administration and query volumes history |
Historical operations data establish the scale of systems and operations to be provided by NeuStar. |
||
T-3
Final change requests for existing registrations |
New registrations will not occur during transition, but changes to existing registrations may occur |
||
Transition assistance from the current administrator |
Assistance from the current contractor is at the core of all transition requirements, since it holds operational data, procedures, and registration agreements. |
||
Transition of the www.us Web site from the current administrator to NeuStar |
NeuStar will publish our own Web site for the usTLD, and needs Web site users to be able to easily find the new registry information. |
||
Transition Assistance from IANA |
Root server changes will be required to delegate.us to NeuStar |
We believe that the above required information is reasonable and necessary for a seamless transition that is transparent to registrants and delegees and that will ensure the overall stability of the usTLD, it operations, and the DNS and the Internet as a whole.
T.1.2 Time Line for Transition
The schedule listed below gives a synopsis of the transition tasks and expected timing of these tasks starting from the award date. Although a quicker process is possible, the timeline provided is ideal for the proposed transition.
Transition Timeline
Schedule |
|
Tasks |
||
---|---|---|---|---|
Award Date | NeuStar requests: | |||
• | Current DNS TLD zone file | |||
• | Whois contact information file | |||
• | usTLD registration database | |||
• | Outreach to delegated managers begins | |||
• | All information regarding delegees | |||
• | Notify IANA of award | |||
2 days post-award |
NeuStar receives copies of existing: |
|||
• | Zone file | |||
• | Whois file | |||
7 days post-award |
NeuStar receives copies of existing usTLD registration database NeuStar receives contact information for all delegees, and information as to which delegees have signed a post-1997 delegee agreement Development begins |
|||
21 days post-award |
Development complete Testing begins |
|||
28 days post-award |
Testing complete Begin live operations transition |
|||
35 days post-award |
Complete live operations transition IANA Delegates .us to NeuStar |
T-4
T.1.3 Implementation
As shown in Exhibit T-1, NeuStar will follow these phases for the successful transition of administration and operations of the usTLD registry:
T.1.4 Resources
NeuStar's implementation team, discussed in-depth in Section A, will include an dedicated transition team as an integral part of its operations. This team will have significant experience in transitioning services and will work with the current administrator, delegees, and registrants to ensure that the transition is transparent to all users and that the stability and integrity of the registry and the Internet is maintained.
T.2 Project Plan
NeuStar's project plan explicitly addresses critical tasks to ensure successful implementation of the usTLD systems and operation.
A well designed project plan will ensure that the usTLD project stays on schedule, management will anticipate necessary changes, strong team communications will be maintained, and delivery will be on time. NeuStar's usTLD Project Plan outlines all phases and associated tasks required to successfully implement the usTLD systems and operations.
Exhibit T-1 provides a high-level Transition and Implementation Timeline.
We will work to a detailed project plan to ensure all objectives are met. This project plan will include all major tasks/subtasks, duration, resources, and dependencies.
T-5
[Exhibit T-1: NeuStar will leverage a proven program management approach and detailed project plan to ensure a seamless transition and implementation of the expanded and enhanced usTLD. Graphic Omitted: high-level usTLD transition and implementation timeline.]
T-6
T.2.1 High-level Task Descriptions
The following table provides overview descriptions of the major program responsibilities that NeuStar must successfully perform to meet the usTLD objectives.
NeuStar Program Responsibilities
High-Level Tasks |
|
Subtasks |
||
---|---|---|---|---|
Project Management Project Initiation | • | Create project charter | ||
• | Create project notebook | |||
• | Assign project sponsor | |||
• | Obtain budget approval | |||
• | Create staffing plan | |||
• | Define roles and responsibilities | |||
• | Conduct initial team and project kickoff meetings | |||
• | Determine metrics for testing and production environments | |||
Project Management Project Planning |
• |
Define scope |
||
• | Develop Work Breakdown Structure (WBS) and initial project schedule | |||
• | Create communications plan, risk management plan, stakeholder plan, quality plan, procurement plan, resource management plan, and change management plan | |||
• | Define usTLD product marketing plan | |||
• | Define usTLD business requirements | |||
• | Define usTLD outreach program | |||
• | Attend industry forums | |||
• | Define legal and policy requirements | |||
• | Define finance and budget plan | |||
• | Define administrative and facilities plan | |||
Project Management Execution and Control |
• |
Implement locality-based usTLD operation and transition from the current administrator |
||
• | Modernize locality-based usTLD | |||
• | Implement expanded usTLD space functions | |||
• | Registrar accreditation and certification | |||
• | Sunrise | |||
• | Landrush | |||
• | Live expanded usTLD | |||
• | Deliver Monthly Progress Reports to COTR (For the 1st 2 years and quarterly thereafter) | |||
• | Deliver six-month Compliance Report | |||
Project Management Closing |
• |
Customer acceptance |
||
• | Project turnover | |||
System Development |
• |
Develop and finalize functional specifications |
||
• | Develop and finalize high-level design | |||
• | Develop and finalize detail design | |||
• | Conduct coding and unit test | |||
• | Data Migration/Population | |||
Testing |
• |
Develop system and user test plans |
||
• | Establish test bed | |||
• | Develop integration test plan |
T-7
High-Level Tasks |
|
Subtasks |
||
---|---|---|---|---|
• |
Perform system test |
|||
• | Conduct interface testing | |||
• | Perform connectivity testing | |||
• | Perform volume/load testing | |||
• | Perform end-to-end testing | |||
• | Perform User Acceptance Test (UAT) | |||
Training |
• |
Develop training materials |
||
• | Conduct internal training sessions | |||
• | Conduct external training sessions | |||
Production and Rollout |
||||
• | Conduct production readiness review (go/no go) | |||
• | Roll out April 1, 2002 |
T.2.2 Staffing and Organization
The usTLD management team will ensure that its experienced, motivated team and knowledgeable staff are available for successful implementation. It will utilize work breakdown structures, historical information, and understanding of scope and resource descriptions in determining resource needs. Appropriate staffing for implementation will ensure that personnel resources are used effectively and efficiently. Periodically, NeuStar Program Management will evaluate the staffing levels and augment resources as necessary to meet the usTLD project objectives.
NeuStar Program Management will assist with the identification, documentation, and assignment of project roles and reporting relationships. The usTLD project team will provide status updates on deliverables and resource changes to the Program Management Office.
T.2.3 Monitoring, Control, and Change Management
NeuStar's project monitoring and control processes will be established to ensure that high performance standards are met at both participant and project levels and to rapidly identify and address any issues or concerns that may arise during the usTLD project. Through strong schedule performance monitoring and control, unnecessary schedule slippage and cost overrun will be mitigated. In addition, recognizing the occasional need for changes in project parameters, NeuStar will follow a strict change control process to ensure that necessary change does not undermine project progress. NeuStar's monitoring and control objective will be to ensure that the activities of all participants are focused on achieving the usTLD project goals and requirements.
NeuStar's change control process follows the major steps in submitting, analyzing, approving, and completing a change control request. All change requests are documented and logged into a tracking system. Appropriate parties will be notified of the impact analysis and NeuStar's recommendation for action.
T.2.4 Quality Assurance
NeuStar recognizes quality as an ongoing and evolving process that facilitates our commitment to continuous improvement by meeting the demands of our customers and the ever-changing marketplace. Through education and training opportunities, we promote teamwork, empowerment, leadership, strategic planning, and personnel development. The quality performance measurement system attributes managed by our staff include reliability, interoperability, availability, responsiveness, effective communication, accuracy, security, and one of our strongest value-added trademarks—neutrality. Please see Section Q for more details on NeuStar's Quality and Performance Management process.
T-8
usTLD Request for Quotation Response Compliance Matrix
RFQ Section |
|
Requirement |
NeuStar Will Comply |
Response Section |
|||
---|---|---|---|---|---|---|---|
B. Contractor Requirements |
The Contractor must perform the required services for this acquisition as a prime Contractor, not as an agent or subcontractor. (The provision of the required services may be accomplished through coordinating the resources and services provided by entities other than the prime Contractor.) The Contractor must be (a) incorporated within one of the fifty states of the United States of America or the District of Columbia or (b) organized under a law of a state of the United States of America or the District of Columbia. The Contractor must possess and maintain through the performance of this acquisition a physical address within the United States and must be able to demonstrate that all primary registry services will remain within the United States of America (including the District of Columbia). |
B |
|||||
The Contractor may not charge the United States Government for performance of the requirements of this purchase order (the unit price and amount for Line Items 0001, 0002 and 0003 must each be $0.00). However, the Contractor may establish and collect fees from third parties for performance of the requirements of this purchase order, provided that the fee levels are approved by the Contracting Officer before going into effect, which approval will not be withheld unreasonably, provided that the fee levels are fair and reasonable. |
|||||||
B.1 Statement of Purpose |
The Department of Commerce seeks to acquire centralized management and coordination of registry, registrar (where specified), database, and information services for the usTLD. In broadest terms, the usTLD was created to provide a locus for registration of domain names to serve the Internet community of the United States, and is intended to be available to a wide range of registrants. Given the foregoing, the Department seeks quotations that will achieve the following objectives: |
N/A |
Information Only |
||||
B.1 |
55. |
Ensure that procedures and a framework of accountability for the delegation and the administration of usTLD evolve into a more robust, certain, and reliable system. |
B.1 |
||||
B.1 |
56. |
Promote increased use of the usTLD by the Internet community of the United States (including small businesses, consumers, Internet users, not-for-profit organizations, and local governments (i.e., state, city, and county), among others), with residence or a bona fide presence in the United States) through introduction of enhanced services, dissemination of information through advertising and/or other appropriate mechanisms, and simplification of registration services including direct registration. |
B.1 |
||||
B.1 |
57. |
Create a centrally administered and efficiently managed structure that ensures both registrant/consumer confidence and infrastructure stability through coordination of delegations as well as other appropriate functions. |
B.1 |
||||
B.1 |
58. |
Create a stable, flexible, and balanced environment within the usTLD that is conducive to innovation and that will meet the future demands of potential registrants. |
B.1 |
||||
B.1 |
59. |
Ensure continued stability of the domain name system as a whole and the usTLD, particularly throughout the transition period from the current management structure into the new structure developed and maintained under the Contractor. |
B.1 |
||||
B.1 |
60. |
Manage the usTLD consistent with the Internet Corporation for Assigned Names and Numbers' (ICANN) technical management of the DNS. |
B.1 |
||||
B.1 |
61. |
Allow for the adequate protection of intellectual property in the usTLD. This includes, in particular, the implementation of a "sunrise period" that permits qualified trademark owners to pre-register their trademarks as domain names in the expanded usTLD space prior to the opening of the expanded usTLD space to wider registration, and a dispute resolution procedure to address conflicts between trademarks and domain names arising from "cybersquatting" in the usTLD. |
B.1 |
||||
B.1 |
62. |
Establish and maintain consistent communication between the COTR, the Contractor and ICANN. This includes representation of the usTLD in the ICANN ccTLD constituency and contribution to ICANN's operating costs as apportioned to the usTLD through the ICANN budget process. |
B.1 |
||||
B.1 |
63. |
Promote robust competition within the usTLD and in particular registration services that will lead to greater choice, new, and better services for users. |
B.1 |
||||
B.2 Core Registry Functions |
The Contractor must provide, at a minimum, the services that are outlined below. This list should not be viewed as exhaustive. The Contractor must provide all systems, software, hardware, facilities, infrastructure, and operation for the following functions: |
B.2, B.2.1 - B.2.16 |
|||||
B.2 |
64. |
Operation and maintenance of the primary, authoritative server for the usTLD; |
B.2.1, O.1, O.4, O.5 |
||||
B.2 |
65. |
Operation and/or administration of a constellation of secondary servers for the usTLD; |
B.2.2, O.1, O.4, O.5 |
||||
B.2 |
66. |
Compilation, generation, and propagation of the usTLD zone file(s); |
B.2.3, F, O.1, O.4, O.5 |
||||
B.2 |
67. |
Maintenance of an accurate and up-to-date registration (WHOIS) database for all usTLD registrations; |
B.2.4, F, O.1, O.3 |
||||
B.2 |
68. |
Maintenance of an accurate and up-to-date database of usTLD subdelegation managers; |
B.2.5, F, O.1, O.3 |
||||
B.2 |
69. |
Establishment of a data escrow for usTLD zone file and domain name registration information, including chain of registration data; |
B.2.6, F, O |
||||
B.2 |
70. |
Compliance with applicable Internet Engineering Task Force (IETF) and applicable ICANN policies for the functions outlined above; and |
B.2.7, F, O.2 |
||||
B.2 |
71. |
Promotion of awareness and registration in the usTLD including maintaining website with up-to-date policy and registration information for the usTLD. |
B.2.8 |
||||
B.3 Core Policy Requirements |
The Contractor must: |
N/A |
Information Only |
||||
B.3 |
72. |
Implement United States Nexus Requirement: The Contractor must run the usTLD as a country code top level domain intended to serve the community of Internet users (including end users, business, government, and not-for-profit organizations, among others) resident or located with a bona fide presence in the United States, and is not intended to attract or otherwise encourage registrations from outside the United States. In addition to the current policy set forth in RFC 1480 requiring that usTLD domain name registrations be hosted on computers located within the United States, the Contractor must implement a United States Nexus Requirement in both the locality-based usTLD structure and the expanded usTLD space. |
B.3.1 |
||||
B.3 |
73. |
Adopt ICANN Policies Pertaining to Open ccTLD's: Although the usTLD is intended to serve the Internet community of the United States, and is not intended to encourage registrations from entities or individuals resident outside the United States, the Contractor must follow the ICANN policies pertaining to open ccTLD's unless otherwise directed by the Contracting Officer. |
B.3.2 |
||||
B.3 |
74. |
Implement a Uniform Domain Name Dispute Resolution Procedure and Sunrise Policy. The Contractor must implement a uniform domain name dispute resolution procedure intended to resolve disputes arising from "cybersquatting" applicable to the usTLD (such policy is intended to be modeled upon the ICANN Uniform Domain Name Dispute Resolution Procedure, consistent with modifications necessary for such policy to be applicable to the usTLD specifically). The Contractor must also implement a "Sunrise Policy" that permits qualified trademark owners to pre-register their trademarks as domain names in the expanded usTLD space prior to the opening of the expanded usTLD space to wider registration. |
B.3.3 |
||||
B.3 |
75. |
Abide by Government Advisory Committee Principles: The Contractor must abide by the principles and procedures set forth in the Government Advisory Committee document "Principles for the Delegation and Management of Country-Code Top Level Domains," unless inconsistent with U.S. law or regulation. |
B.3.4 |
||||
B.4 Locality-based usTLD Structure Functions |
The Contractor must: |
N/A |
Information Only |
||||
B.4 |
76. |
Provide Service for Existing Delegees and Registrants: Provide service and support for existing delegees and registrants in the existing, locality-based usTLD structure under current practice, including policies set forth in RFC 1480 and other documented usTLD policies. |
B.4.1, F, O |
||||
B.4 |
77. |
Provide Services for Undelegated Third Level Sub-Domains: Provide direct registry and registrar services for all other undelegated third level locality sub-domains, including services for CO and CI, and undelegated special purpose domains (K12, CC, TEC, LIB, MUS, STATE, DST, COG and GEN). |
|||||
B.4 |
78. |
Modernize Locality-Based usTLD processes: The Contractor must modernize and automate the locality-based usTLD delegation and registration process under the control of the usTLD administrator, including the creation of an electronic database to store historical usTLD registration data. |
B.4.2, F, O |
||||
B.4 |
79. |
Coordinate Current Locality-Based usTLD Users: The Contractor must create a mechanism or mechanisms whereby delegated managers of the usTLD, users of the locality-based usTLD, traditional usTLD user groups (such as state and local governments, the library community and educational institutions, among others), and other interested parties, can coordinate to discuss usTLD administrative, technical, and policy issues related to the operation and management of locality-based usTLD structure. |
B.4.4, B.3.5 |
||||
B.4 |
80. |
Investigate Compliance with Current Locality-Based usTLD Policies: The Contractor must conduct an investigation (or commission such an investigation) and submit a report to the COTR, within six months after purchase order award, evaluating the compliance of existing sub-domain managers with the requirements of RFC 1480 and other documented usTLD policies. Further, the study should include an evaluation of "locality-squatting" issues, or the practice of registering a locality name without providing a responsive level of service to such locality. Such report must recommend structural, procedural, and policy changes designed to enhance such compliance or improve usTLD registration services and increase the value of the locality-based usTLD structure to local communities. During this evaluation period, the Contractor must not make any additional locality delegations or transfers unless otherwise directed by the Contracting Officer. |
B.4.5 |
||||
B.4 |
81. |
Develop Database of usTLD Delegated Managers: The Contractor must develop a single database for up-to-date and verified contact information for all delegated managers in the usTLD, including to locality-level and functional second level (where delegated) administrators and, where applicable, for all sub-delegations made by such locality-level or second level administrators. Such databases should allow for multiple string and field searching through a free, public, web-based interface, and consist of at least the following elements: |
B.4.6, F, O |
||||
• |
The name of the delegated manager; |
||||||
• |
The IP address of the primary nameserver and secondary nameserver(s) for the delegation; |
||||||
• |
The corresponding names of those nameservers; |
||||||
• |
The date of delegation; |
||||||
• |
The name and postal address of the delegated manager; |
||||||
• |
The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the delegated manager; |
||||||
• |
The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the delegated manager; and |
||||||
• |
The website or other contact information through which registrations can be accepted under that delegation. |
||||||
B.4 |
82. |
Develop Registrant WHOIS Database: The Contractor must develop an enhanced searchable WHOIS database that contains, or provides reliable access to, all locality-based usTLD registrants including the registrants of delegated usTLD managers and, where applicable, registrants located under delegated managers' sub-delegations. Such WHOIS database must allow for multiple string and field searching through a free, public, web-based interface, and consist of at least the following elements: |
B.4.7, F, O |
||||
• |
The name of the domain registered; |
||||||
• |
The Internet Protocol (IP) address of the primary nameserver and secondary nameserver(s) for the registered domain name; |
||||||
• |
The corresponding names of those nameservers; |
||||||
• |
The identity of the delegated manager under which the name is registered; |
||||||
• |
The creation date of the registration; |
||||||
• |
The name and postal address of the domain name holder; |
||||||
• |
The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the domain name holder; and |
||||||
• |
The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the domain name holder. |
||||||
B.5 Expanded usTLD Space Functions |
The Contractor must not act as a registrar in the expanded usTLD space. Presented below is a non-exhaustive list of elements that the Contractor must incorporate into its procedures and policies for the expanded usTLD structure: |
B.5 |
|||||
B.5 |
83 |
Develop and Implement Shared Registration System: The Contractor must develop and implement a shared registration system whereby qualified competing registrars may register domain names for their customers in the expanded usTLD space (i.e., example.us). At a minimum, this proposed shared registration system must allow an unlimited number of accredited/licensed registrars to register domain names in the expanded usTLD; provide equivalent access to the system for all accredited/licensed registrars to register domains and transfer domain name registrations among competing accredited/licensed registrars; update domain name registrations; and provide technical support for accredited/licensed registrars. |
B.5.1, F, O |
||||
B.5 |
84. |
Accreditation of usTLD Registrars: The Contractor must develop and implement a process describing the manner in which registrars in the expanded usTLD space will be accredited to register names in the expanded usTLD. |
B.5.2 |
||||
B.5 |
85. |
Technical Certification of usTLD Registrars: The Contractor must develop and implement a process for technical certification of registrars in the expanded usTLD space. |
B.5.3, O |
||||
B.5 |
86. |
Develop WHOIS Database: The Contractor must develop an enhanced searchable WHOIS database that contains, or provides reliable access to, all expanded usTLD registrations. Such WHOIS database must be operated at the registry level (as opposed to at the level of individual accredited registrars) and allow for multiple string and field searching through a free, public, web-based interface, and consist of at least the following elements: |
B.5.4, F, O |
||||
• |
The name of the second level domain registered; |
||||||
• |
The IP address of the primary nameserver and secondary nameserver(s) for the registered domain name; |
||||||
• |
The corresponding names of those nameservers; |
||||||
• |
The creation date of the registration; |
||||||
• |
The name and postal address of the domain name holder; |
||||||
• |
The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the technical contact for the domain name holder; and |
||||||
• |
The name, postal address, e-mail address, voice telephone number, and (where available) fax number of the administrative contact for the domain name holder. |
||||||
B.5 |
87. |
Community Outreach Plan: The Contractor must develop a public outreach mechanism whereby the public space can suggest or recommend additional policies or procedures for the usTLD that may be developed or suggest how existing policy should be modified or updated. |
B.5.5, B.3.5 |
usTLD Request for Quotation Response Compliance Matrix
RFQ Section |
|
Requirement |
NeuStar Will Comply |
Response Section |
|||
---|---|---|---|---|---|---|---|
C. Reporting Requirements and Deliverables | The Contractor must post the following reports on their Internet site in order to facilitate transparency and public access. | X | B.2.15, B.4.5 | ||||
C.1 Investigational Study (One-Time Report Due Six Months After Purchase Order Award) |
The Contractor must conduct an investigation and submit a written report to the COTR, within six months after purchase order award, evaluating the compliance of existing sub-domain managers with the requirements of RFC 1480 and other documented usTLD policies. Such report must recommend structural, procedural, or policy changes designed to enhance such compliance and increase the value of the locality-based structure to local communities. During this evaluation period, the Contractor must make no additional locality delegations unless otherwise directed by the Contracting Officer. |
X |
B.4.5 |
||||
C.2 Progress Reports |
For the first two years of the purchase order, the Contractor must submit monthly progress reports to the COTR, in writing, detailing the Contractor's progress towards meeting the purchase order SOW requirements. Thereafter, such reports must be provided to the COTR on a quarterly basis. |
These reports must indicate the status of all major events, as well as major work performed during the month, including technical status, accomplishments, and complications experienced in fulfilling the SOW requirements, and must be submitted in such detail and form as required by the COTR. Such reports must also provide performance data related to operation of the usTLD including, but not limited to, the following: the total number of registry transactions; the number of new, transferred or deleted registrations in the usTLD (including cumulative registrations over time); the number of delegated managers and changes in delegated managers in the locality-based usTLD space; the number of registrars accredited to register names in the expanded usTLD space, including the operational status of those registrars; and any updates or modifications to the shared registration system made by the Contractor. |
X |
B.2.15 |
|||||
88. |
52.203-12 DEV 52.203-12 LIMITATION ON PAYMENTS TO INFLUENCE CERTAIN FEDERAL TRANSACTIONS (DEVIATION NOV 1990) (JUN 1997) |
N/A |
Information Only |
||||
89. |
52.204-6 DATA UNIVERSAL NUMBERING SYSTEM (DUNS) NUMBER (JUNE 1999) |
X |
S |
||||
90. |
52.213-4 TERMS AND CONDITIONS—SIMPLIFIED ACQUISITIONS (OTHER THAN COMMERCIAL ITEMS) (MAR 2001) |
N/A |
Information Only |
||||
91. |
52.217-9 OPTION TO EXTEND THE TERM OF THE CONTRACT (MAR 2000) |
N/A |
Information Only |
||||
92. |
52.227-17 RIGHTS IN DATA—SPECIAL WORKS (JUN 1987) |
N/A |
Information Only |
||||
93. |
1352.233-70 HARMLESS FROM LIABILITY (MARCH 2000) |
N/A |
Information Only |
||||
94. |
1352.233-71 SERVICE OF PROTESTS (MARCH 2000) |
N/A |
Information Only |
||||
95. |
1352.252-71 REGULATORY NOTICE (MARCH 2000) |
N/A |
Information Only |
||||
96. |
52.233-1 I DISPUTES (DEC 1998)—ALTERNATE I (DEC 1991) |
N/A |
Information Only |
||||
97. |
52.239-1 PRIVACY OR SECURITY SAFEGUARDS (AUG 1996) |
N/A |
Information Only |
||||
98. |
1352.201-70 CONTRACTING OFFICER'S AUTHORITY (MARCH 2000) |
N/A |
Information Only |
||||
99. |
1352.201-71 CONTRACTING OFFICER'S TECHNICAL REPRESENTATIVE (COTR) (MARCH 2000) |
N/A |
Information Only |
||||
100. |
ANSWERS TO ANTICIPATED OFFEROR QUESTIONS |
N/A |
Information Only |
||||
Representations and Certifications of Offerors |
|||||||
101. 52.219-1 SMALL BUSINESS PROGRAM REPRESENTATIONS (MAR 2001) |
X |
R |
|||||
102. 52.203-11 DEV 52.203-11 CERTIFICATION AND DISCLOSURE REGARDING PAYMENTS TO INFLUENCE CERTAIN FEDERAL TRANSACTIONS DEVIATION (JAN 1990) |
X |
R |
|||||
Instructions for Submitting Quotations |
|||||||
Before submitting a quotation, Offerors are encouraged to review the information on the locality-based usTLD structure and registration policies at: http://www.nic.us |
N/A |
Information Only |
|||||
The Offeror must submit the ORIGINAL VERSION and TWO COPIES of the Quotation to the following address: ATTN JOSEPH L WIDDUP NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY 100 BUREAU DR STOP 3571 BLDG 301 RM B129 GAITHERSBURG MD 20899-3571 M/F SOLICITATION SB1335-01-Q-0740 Each quotation (original and copies) submitted in response to this solicitation must: |
N/A |
Information Only |
|||||
ATTN JOSEPH L WIDDUP NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY 100 BUREAU DR STOP 3571 BLDG 301 RM B 129 GAITHERSBURG MD 20899-3571 M/F SOLICITATION SB1335-01-q-0740 |
N/A |
Information Only |
|||||
Each quotation (original and copies)submitted in response to this solicitation must |
N/A |
Information Only |
|||||
A. |
Include resume(s) of key personnel (including education and experience credentials) that would perform and/or manage the requirements of this acquisition. |
X |
A |
||||
B. |
Describe how the Offeror would satisfy each of the individual requirements described in the "Contractor Requirements" section of the SOW. (In the event that the provision of the required services would be accomplished through coordinating the resources and services provided by entities other than the prime Contractor, the quotation must explicitly indicate how the Contractor will ensure that the "Contractor Requirements" will be fulfilled.) |
X |
B, B.1—B.16 |
||||
C. |
In light of the "Statement of Purpose" in the SOW, present a detailed narrative describing the Offeror's overall vision for future management of the usTLD, including how the Offeror proposes to make the usTLD more attractive and useful to United States Internet users and the Offeror's expectations for the number of potential usTLD registrants. |
X |
C |
||||
D. |
Describe any services or functions, if any, the Offeror proposes to perform as part of usTLD management in addition to those listed in the SOW. |
X |
D |
||||
E. |
Demonstrate clearly, concisely and accurately, in written narrative form, the Offeror's understanding of the current state of the usTLD domain space. |
X |
E |
||||
F. |
Describe, for the SOW requirement related to the development of a database of usTLD delegated managers, and the development of registrant WHOIS databases (both for the locality-based usTLD structure and the expanded usTLD space) how the Offeror would collect the necessary information and the technical and operational specifications of the databases. |
X |
F, B.2.4,B.2.5 |
||||
G. |
Include a proposed draft of any contract(s) that the Offeror proposes to use between itself, as Contractor, and usTLD delegated managers (which may include "flow through" registration agreements to be used by locality-based usTLD registrants) considered necessary to ensure the stable operation of the locality-based usTLD structure and implement necessary policies. Note: The content of the final version of all such contract(s) must be approved by the Contracting Officer before use by the Contractor in performance of the resultant purchase order. |
X |
G |
||||
H. |
Include a proposed draft of any contract(s) that the Offeror proposes to use between itself, as Contractor, and expanded usTLD registrars to ensure the stable operation of the expanded usTLD and implement the necessary policies (which may include shared registration system license agreements, registrar accreditation agreements, and registrant agreements). Note: The content of the final version of all such contract(s) must be approved by the Contracting Officer before those contract(s) may be used by the Contractor in performance of the resultant purchase order; |
X |
H |
||||
I. |
Include written policies (including implementation details) that the Offeror proposes to follow, as Contractor, during the start-up phase of registrations in the usTLD. Such description must include the following considerations: |
X |
I, B.3.1,B.3.3, B.3.5 |
||||
1. |
How the Offeror would design and implement the "Sunrise Policy" that permits qualified trademark owners to pre-register their trademarks as domain names in the expanded usTLD space prior to the opening of the expanded usTLD space to wider registration. |
||||||
2. |
How the Offeror would implement a uniform domain name dispute resolution procedure intended to resolve disputes arising from "cybersquatting" applicable to the usTLD (such policy is intended to be modeled upon the ICANN Uniform Domain Name Dispute Resolution Procedure, consistent with modifications necessary for such a policy to be applicable to the usTLD specifically. Offeror should propose necessary modifications). |
X |
I, B.3.1, B.3.3, B.3.5 |
||||
3. |
How the Offeror proposes to implement and enforce the United States nexus requirement intended to preserve the usTLD for use by the community of United States Internet users. |
||||||
4. |
Describe any proposed additional, alternative, or supplemental policies or programs the Offeror considers relevant and essential towards the locality-based usTLD space or the expanded usTLD space. |
Offerors should also describe additional procedures that address other considerations than those listed above that they consider relevant to their quotation. |
|||||||
J. |
Address the following considerations in the description of the registration process: |
X |
J |
||||
1. |
How the Offeror proposes to address the potential initial "rush" for registrations at the opening of the expanded usTLD space. |
||||||
2. |
Describe the proposed application process for potential registrants; |
||||||
3. |
Describe the proposed mechanisms for ensuring that registrants meet registration requirements; |
X |
J |
||||
4. |
Describe any proposed appeal process that could be used by the applicant as a result of Contractor denial of registration. |
||||||
5. |
Describe any proposed procedure that would permit third parties to seek cancellation of a registration for failure to comply with restrictions imposed by the Contractor. |
||||||
K. Describe in detail the proposed mechanisms and community outreach plans for coordinating the current locality-based usTLD users and the mechanism by which the public can suggest or recommend additional policys or procedures for the usTLD. |
X |
K, B.3.5 |
|||||
L. |
Describe, in detail, how the Contractor would fund the requirements of this acquisition at no cost to the United States Government. |
X |
L |
||||
M. |
Project/estimate and explain annual Contractor costs for this acquisition in such a way to permit the Government to match those costs to specific SOW Contractor Requirements. |
X |
M |
||||
N. |
Include detailed proposed financial plans, including, if appropriate, the manner in which fees levied for services rendered by the Contractor would be derived, considering cost plus a fair and reasonable profit. |
X |
N |
||||
O. |
Describe, in detail, the technical facilities, equipment, software, hardware, and related technology that the Offeror would use to meet the requirements of this acquisition. |
X |
O |
||||
P. |
Include no more than five past performance references for other efforts similar in scope to this acquisition that were either (a) completed by the Offeror (either as a prime Contractor or as a first-tier subcontractor) in the past five years or (b) currently in process. For each past performance reference, include the following information: |
X |
P |
||||
1. |
Contract Number/Purchase Order Number; |
||||||
2. |
Duration of the Contract/Purchase Order; |
||||||
3. |
Dollar Value of Contract/Purchase Order (Broken Down on a Per-Year Basis, if Applicable); |
||||||
4. |
Contract type of Contract/Purchase Order (e.g., firm-fixed-price, cost-plus-fixed-fee, cost-plus-award-fee, fixed-price with economic price adjustment); |
||||||
5. |
Name and Mailing Address of Customer Organization; |
||||||
6. |
Technical Point of Contact at Customer Organization for the Contract/Purchase Order, including Phone Number, Fax Number and Email Address; |
||||||
7. |
Information Noted in I.4 above for an Alternate Customer Organization Point of Contact; and |
||||||
8. |
Detailed Description of the Effort Performed by the Contractor/Subcontractor under the Contract/Purchase Order. At the discretion of the Contracting Officer, a site visit to the Offeror's facility(ies) may also be requested and conducted by DOC personnel involved in this acquisition. The purpose of this visit would be to gather information relevant to the Offeror's submitted quotation. The Contracting Officer would arrange such a visit at least seven days in advance with the Offeror. |
||||||
Q. |
Describe, in detail, proposed performance measures that will provide accurate indicators of the Contractors progress under the project and assessment of services offered |
X |
Q |
||||
R. |
Include a completed copy of "Offeror Representations and Certifications" from this solicitation. |
X |
R |
||||
S. |
The Offeror's Data Universal Numbering System (DUNS) Number. (See FAR 52.204-6 on page 16 of this solicitation.) |
X |
S |
||||
Evaluation Criteria for Award |
|||||||
A quotation will only be considered if it is submitted by an organization that is (a) incorporated within one of the fifty states of the United States of America or the District of Columbia or (b) organized under a law of a state of the United States of America. The Contractor must have a physical address within the United States of America or the District of Columbia and must be able to demonstrate that all primary registry services will remain within the United States of America (including the District of Columbia). |
|||||||
The Government will evaluate quotations submitted in response to this acquisition for services and will award a purchase order to the technically acceptable, responsible Offeror whose quotation represents the best value. Technical excellence and comprehensiveness of the overall service for usTLD operation is significantly more important than proposed price(s) to.us registrants. The evaluated price for all quotations, in terms of the price paid by the Government, will be $0.00. This acquisition is being conducted under FAR Part 13, Simplified Acquisition Procedures. Under FAR Part 13, solicitations are not required to state the relative order of importance assigned to each evaluation factor and subfactor, nor are they required to include subfactors. The evaluation factors are listed below. |
|||||||
• |
Technical excellence and comprehensiveness of the offered service—For this factor, the Government will evaluate responses to items A through O and item Q in the "INSTRUCTIONS FOR SUBMITTING QUOTATIONS." |
N/A |
Information Only |
||||
• |
Past performance information—For this factor, the Government will evaluate information obtained from past performance references provided by the Offeror in their quotation in response to item "P" in the "INSTRUCTIONS FOR SUBMITTING QUOTATIONS" section of the solicitation, as well as any other relevant past performance information that the Government obtains about the Offeror from other sources; |
||||||
• |
Reasonableness of proposed price(s) to.us registrants. For this factor, the Government will determine whether the proposed price(s) to the registrants are fair and reasonable considering the level of service(s) to be provided to the.us registrants. |
||||||
For the purposes of this solicitation, "best value" means the expected outcome of an acquisition that, in the Government's estimation, provides the greatest overall benefit in response to the requirement. In this solicitation, the term "best value" is not meant to imply that a specific tradeoff process (as described in FAR Part 15, Contracting by Negotiation) will be used by the Government. This acquisition is being conducted under FAR Part 13, Simplified Acquisition Procedures. |
This ‘S-1/A’ Filing | Date | Other Filings | ||
---|---|---|---|---|
Filed on: | 6/28/05 | 3, S-1/A | ||
12/31/04 | ||||
12/15/04 | ||||
11/15/04 | ||||
11/1/04 | ||||
10/15/04 | ||||
9/30/04 | ||||
9/24/04 | ||||
9/21/04 | ||||
6/30/04 | ||||
6/14/04 | ||||
6/6/04 | ||||
6/1/04 | ||||
3/31/04 | ||||
12/31/03 | ||||
12/3/03 | ||||
9/30/03 | ||||
8/19/03 | ||||
5/1/03 | ||||
2/13/03 | ||||
1/13/03 | ||||
12/23/02 | ||||
12/4/02 | ||||
8/17/02 | ||||
6/14/02 | ||||
4/24/02 | ||||
4/22/02 | ||||
4/1/02 | ||||
10/26/01 | ||||
7/27/01 | ||||
7/23/01 | ||||
6/29/01 | ||||
6/17/01 | ||||
6/16/01 | ||||
12/1/00 | ||||
8/17/00 | ||||
7/1/99 | ||||
4/6/99 | ||||
3/9/99 | ||||
8/4/98 | ||||
2/21/98 | ||||
10/9/97 | ||||
7/1/97 | ||||
List all Filings |