Transmittal Letter/Form/Check (RFP Instruction).............................................................................. Tab

Table of Contents...................................................................................................................... Tab

Acronyms List............................................................................................................................ Tab

Compliance/Cross Reference Matrix................................................................................................ Tab

Executive Summary.................................................................................................................... Tab

I. General Information (RFP Sections D1-D11).......................................................................... I-1

II. Business Capabilities And Plan (RFP Sections D12-13)............................................................. II-1

II.1 Registry Operator's Capabilities (RFP Section D13.1)............................................................ II.1-1

II.1.1 Company Information (RFP Section D13.1.1)..................................................................... II.1-5

II.1.2 Current Business Operations (RFP Section D13.1.2)............................................................. II.1-5

II.1.3 Past Business Operations (RFP Section D13.1.3)................................................................. II.1-6

II.1.4 Registry/Database/Internet Related Experience And Activities (RFP Section D13.1.4)............... II.1-13

II.1.5 Mission (RFP Section D13.1.5)....................................................................................... II.1-19

II.1.6 Management Team (RFP Section D13.1.6)...................................................................... II.1-26

II.1.7 Staff/Employees (RFP Section D13.1.7).......................................................................... II.1-32

II.1.8 Commercial General Liability Insurance (RFP Section D13.1.8).............................................. II.1-38

II.2. Business Plan For The Proposed Registry Operations (RFP Section D13.2)................................ II.2-1

II.2.1 Services To Be Provided (RFP Section D13.2.1)............................................................... II.2.1-1

II.2.2 Revenue Model (RFP Section D13.2.2)........................................................................... II.2.2-1

II.2.3 Market Overview (RFP Section D13.2.3)......................................................................... II.2.3-1

II.2.4 Marketing Plan (RFP Section D13.2.4)............................................................................ II.2.4-1

II.2.5 Estimated Demand For Registry Services In The New TLD (RFP Section D13.2.5)................... II.2.5-1

II.2.6 Resources Required To Meet Demand (RFP Section D13.2.6)............................................. II.2.6-1

II.2.7 Plans For Acquiring Necessary Systems And Facilities (RFP Section D13.2.7)........................... II.2.7-1

II.2.8 Staff Size/Expansion Capability (RFP Section D13.2.8)....................................................... II.2.9-2

II.2.9 Availability Of Additional Management Personnel (RFP Section D13.2.9)................................. II.2.9-3

II.2.10 Term Of Registry Agreement (RFP Section D13.2.10)..................................................... II.2.10-1

II.2.11 Expected Costs Associated With The Operation Of The Proposed Registry (RFP Section D13.2.11) II.2.11-1

II.2.12 Expected Revenue Associated With The Operation Of The Proposed Registry (RFP Section D13.2.12) II.2.12-1

II.2.13 Capital Requirements (RFP Section D13.2.13)................................................................ II.2.13-1

II.2.14 Business Risks And Opportunities (RFP Section D13.2.14)................................................. II.2.14-1

II.2.15 Registry Failure Provisions (RFP Section D13.2.15).......................................................... II.2.15-1

II.3 Pro-Forma Financial Projections (RFP Section D13.3)............................................................ II.3-1

II.4 Supporting Documentation (RFP Section D13.4).................................................................... Tab

II.4.1 Registry Operator's Organizational Documents (RFP Section D13.4.1)........................................ N/A

II.4.2 References (RFP Section D13.4.2)..................................................................................... N/A

II.4.3 Annual Report (RFP Section D13.4.3).................................................................................. N/A

II.4.4 Proof Of Capital (RFP Section D13.4.4)................................................................................ N/A

II.4.5 Proof Of Insurance (RFP Section D13.4.5)........................................................................... N/A

III TECHNICAL CAPABILITIES AND PLAN (RFP Section D14-D15)................................................ III-1

III.1 Registry Operator's Technical Capabilities (RFP Section D15.1).............................................. III.1-1

III.2 Proposed Registry Operations Technical Plan (RFP Section D15.2)......................................... III.2-1

III.2.1 Proposed Facilities and Systems (RFP Section D15.2.1)....................................................... III.2-2

III.2.2 Registry Registrar Model and Protocol (RFP Section D15.2.2).............................................. III.2-23

III.2.3 Database Capabilities (RFP Section D15.2.3)................................................................... III.2-27

III.2.4 Zone File Generation (RFP Section D15.2.4).................................................................... III.2-46

III.2.5 Zone File Distribution & Publication (RFP Section D15.2.5)................................................... III.2-49

III.2.6 Billing and Collections System (RFP Section D15.2.6)......................................................... III.2-54

III.2.7 Data Escrow & Backup (RFP Section D15.2.7)................................................................. III.2-67

III.2.8 Publicy Accessible Look Up/Whois Service (RFP Section D15.2.8) ........................................ III.2-69

III.2.9 System Security (RFP Section D15.2.9).......................................................................... III.2-77

III.2.10 Peak Capacities (RFP Section D15.2.10)......................................................................... III.2-85

III.2.11 System Reliability (RFP Section D15.2.11)....................................................................... III.2-88

III.2.12 System Outage Prevention (RFP Section D15.2.12).......................................................... III.2-91

III.2.13 System Recovery Procedures (RFP Section D15.2.13)....................................................... III.2-96

III.2.14 Technical & Other Support (RFP Section D15.2.14)......................................................... III.2-103

III.3 Subcontractors (RFP Section D15.3)............................................................................... III.3-1

IV. Implementation............................................................................................................. IV-1

IV.1 Project Management...................................................................................................... IV-1

IV.2 Project Plan.................................................................................................................. IV-5

IV.3 Sun Rise Period............................................................................................................ IV-13

IV.4 Land Rush Period......................................................................................................... IV-15

IV.5 Integration.................................................................................................................. IV-19

Appendices...................................................................................................................... Appendix 1

^{TLD POLICIES Proposal Table of Contents}

TLD Policy Proposal..................................................................................................................... Tab

I. General LTD Policies (RFP Section EI)................................................................................. Tab

I.1 In General (RFP Section E1)................................................................................................. 3

I.2 TLD String (RFP Section E2)................................................................................................. 4

I.3 Naming Conventions (RFP Section E3) ................................................................................... 4

I.4 Registrars (RFP Section E4).................................................................................................. 5

I.5 Intellectual Property Provisions (RFP Section E5 – E5.6).............................................................. 7

I.6 Dispute Resolution (RFP Section E6 – E6.2).............................................................................. 9

I.7 Data Privacy, Escrow, and Whois (RFP Section E7).................................................................... 9

I.8 Billing and Collections (RFP Section E8).................................................................................. 10

I.9 Services and Pricing (RFP Section E9).................................................................................... 10

I.10 Other (RFP Section E10).................................................................................................... 10

II. Registration Policies During Start-up (RFP Section E11 – E15)...................................................... 10

III Registration Restrictions (RFP Section E16 – E21).................................................................... 14

IV. Context of TLD Within the DNS (RFP Section E22 – E27).......................................................... 15

V. Value of Proposal as a Proof of Concept (RFP Section E28 – E32)............................................... 17

Appendix 2: Rules for Uniform Charter Domain Name Dispute Resolution Policy (UCDRP)

^{REGISTRY OPERATOR’S FITNESS DISCLOSURE}

Acronym List
ADNA	Australian Domain Name Administration
ALTS	Association for Local Telecommunications Services
API	Application Programmer Interface.
APTLD	Asia Pacific Top Level Domains Forum
ASAC	Advanced Services Application Centre
ATIS	Alliance for Telecommunications Industry Solutions
ATP	Acceptance Test Plan
ATUG	Australian Telecommunications Users Group
auDA	au Domain Administration
AUNIC	Australian Network Information Centre
B&C	billing and collection
CARE	Customer Account Record Exchange
CASE	Computer Aided Software Engineering
ccTLD	country code top-level domain
CompTel	Competitive Telecommunications
CRC	Cooperative Research Centre (Research Data Network)
CTIA	Cellular Telecommunications Industry Association
DATE	Domain Administration Tool
DBMS	Database Management System
DFP	Dynamic Feedback Protocol
DID	Digital IDentification
DNS	domain name system
DNSO	Domain Names Support Organization
ESN	Enhanced Service Node
ETSI	European Telecommunications Standards Institute
FAQ	Frequently Asked Question
FCC	(U.S.) Federal Communications Commission
FTE	full-time equivalent
ftp	file transfer protocol
gTLD	generic top-level domain
http	hyper-text transfer protocol
ICANN	Internet Corporation for Assigned Names and Numbers
ID	Identification
IETF	Internet Engineering Task Force
IN	intelligent network
INC	Industry Numbering Council
ING	Internet Gateway
IP	Internet Protocol
IP Services/Solutions	Internet Protocol Services or Solutions
IPC	Intellectual Property Constituency
IPNS	Intellectual Property Notification Service
IPv6	Internet Protocol Version 6
ISO	International Organization for Standards
ISP	Internet Service Provider
IT	information technology
ITU	International Telecommunications Union
LLC	Limited Liability Company
LNPA	Local Number Portability Administration ( or Administrator)
LSP	Local Service Provider
MINC	Multilingual Internet Names Consortium
MTTR	mean-time-to-repair
N + 1	needed number plus one for a safety factor
NANC	North American Numbering Council
NANPA	North American Numbering Plan Administration (or Administrator)
NOC	Network Operations Center
NPAC	Number Portability Administration Center
NRA	United States National Regulatory Authority
NSI	Network Solutions, Inc.
NXX	Central Office Code (where XX is a variable)
OBF	Operations and Billing Forum
OLTP	On-line Transaction Processing
OPASTCO	Organization for the Promotion and Advancement of Small Telecommunications Companies
OSS	operational support system
PA	Personal Assistant; Pooling Administration
PGP	Pretty Good Privacy
PKI	Public Key Infrastructure
PSU	Production Support Unit
RAD	Rapid Application Development
RAID	Redundant Array of Independent Disks
RAP	Registry Authentication Protocol
RFC	Request for Comment
RRP	Registry-Registrar Protocol
SDA	Session Distribution Algorithm
SLA	Service Level Agreement
SLR	Service Level Requirements
SMP	symmetric multiprocessing
SMS	Service Management System; Smart Message Services
SNMP	simple network management protocol
SOHO	small office/home office
SPIN	System for Processing Internet Names
SRS	Shared Registry System
STP	System Test Plan
SW-CMM	Software Capability Maturity Model
TCP/IP	Transmission Control Protocol/Internet Protocol
TLD	top level domain
TM Forum	Telemanagement Forum
TMIA	TeleMessaging Industry Association
TPC-C	Transaction Processing Council, Online Processing Benchmark
UCDRP	Uniform Charter Dispute Resolution Policy
UDRP	Uniform Dispute Resolution Process
US$	United States dollars, as in US$50,000
USTA	United States Telephone Association
VOIP	Voice Over Internet Protocol
VPN	Virtual Private Network
W3C	World Wide Web Consortium
WAP	Wireless Applications Protocol
www	World Wide Web
XRP	eXtensible Registry Protocol
XWP	(eXtensible Whois Protocol).

JVTeam Registry Operator’s Proposal Compliance/Cross Reference Matrix
RFP Section	ABBREVIATED Requirement/Instructions	JVTeam Response Section	JVTeam Complies
Registry Operators Proposal	[INSTRUCTION: A Registry Operator's Proposal is to be submitted as part of every new TLD application. In case of applications for unsponsored TLDs, the registry operator will be the applicant and should prepare and submit the proposal as part of the application. In the case of applications for sponsored TLDs, the sponsoring organization (or, where the sponsoring organization has not yet been formed, organization(s) or person(s) proposing to form the sponsoring organization) will be the applicant. The sponsoring organization should select the proposed registry operator, have it prepare the Registry Operator's Proposal, and submit it as part of the application. Please place the legend "CONFIDENTIAL" on any part of your description that you have listed in item F3.1 of your Statement of Requested Confidential Treatment of Materials Submitted. The Registry Operator's Proposal should be separately bound (if more than one volume, please sequentially number them) and labeled: "Registry Operator's Proposal." and must cover all topics described below. This page, signed on behalf of the registry operator, should be included at the front of the Registry Operator's Proposal.]	Registry Operators Proposal	Yes
I. GENERAL INFORMATION	D1. The first section of the Registry Operator's Proposal (after the signed copy of this page) should be a listing of the following information about the registry operator. Please key your responses to the designators (D1, D2, D3, etc.) below. D2. The full legal name, principal address, telephone and fax numbers, and e-mail address of the registry operator. D3. The addresses and telephone and fax numbers of all other business locations of the registry operator. D4. The registry operator's type of business entity (e.g., corporation, partnership, etc.) and law (e.g., Denmark) under which it is organized. D5. URL of registry operator's principal world wide web site. D6. Dun & Bradstreet D-U-N-S Number (if any) of registry operator. D7. Number of employees. D8. Registry operator's total revenue (in US dollars) in the last-ended fiscal year. D9. Full names and positions of (i) all directors, (ii) all officers, (iii) all relevant managers, and (iv) any persons or entities owning five percent or more of registry operator. D10. Name, telephone and fax number, and e-mail address of person to contact for additional information regarding this proposal. If there are multiple people, please list all their names, telephone and fax numbers, and e-mail addresses and describe the areas as to which each should be contacted. D11. The full legal name, principal address, telephone and fax numbers, e-mail address, and Dun & Bradstreet D-U-N-S Number (if any) of all subcontractors identified in item D15.3 below.	I. General Information	Yes
Yes II. BUSINESS CAPABILITIES AND PLAN (D12-D13)	D12. The second section of the Registry Operator's Proposal (after the "General Information" section) is a description of the registry operator's Business Capabilities and Plan. This section must include a comprehensive, professional-quality business plan that provides detailed, verified business and financial information about the registry operator. The topics listed below are representative of the type of subjects that will be covered in the Business Capabilities and Plan section of the Registry Operator's Proposal. [INSTRUCTION: ICANN will extensively review and analyze this section of the Registry Operator's Proposal. The content, clarity, and professionalism of this section will be important factors in ICANN's evaluation of applications. We strongly recommend securing professional assistance from financial and management consultants to aid in the formulation of your business plan, in securing the necessary sources of financing, and in preparation of this section.]	II Business Capabilities and Plan	Yes
D13.1	Detailed description of the registry operator's capabilities. This should describe general capabilities and activities. This description also offers the registry operator an opportunity to demonstrate the extent of its business and managerial expertise in activities relevant to the operation of the proposed registry. The following items should, at a bare minimum, be covered:	II.1 Registry Operator's Capabilities	Yes
D13.1.1	Company information. Date of formation, legal status, primary location, size of staff, formal alliances, references, corporate or other structure, ownership structure.	II.1.1 Company Information	Yes
D13.1.2	Current business operations. Core capabilities, services offered, products offered, duration of provision of services and products.	II.1.2 Current Business Operations	Yes
D13.1.3	Past business operations/entity history. History, date of formation, legal status/type of entity, initial services, duration of provision of services and products.	II.1.3 Past Business Operations	Yes
D13.1.4	Registry/database/Internet related experience and activities. Experience with database operation, Internet service provision.	II.1.4 Registry/Database/Internet Related Experience And Activities.	Yes
D13.1.5	Mission. The registry operator's mission and how it relates to expansion into the registry operation field.	II.1.5 Mission	Yes
D13.1.6	Management. Qualifications and experience of financial and business officers and other relevant employees. Please address/include past experience, resumes, references, biographies.	II.1.6 Management Team	Yes
D13.1.7	Staff/employees. Current staff size, demonstrated ability to expand employee base, hiring policy, employee training, space for additional staff	II.1.7 Staff/Employees	Yes
D13.1.8	Commercial general liability insurance. Address/include amount of insurance policy, provider of policy, plans for obtaining additional insurance.	II.1.8 Commercial General Liability Insurance	Yes
D13.2	Business plan for the proposed registry operations. This section should present a comprehensive business plan for the proposed registry operations. In addition to providing basic information concerning the viability of the proposed operations, this section offers the registry operator an opportunity to demonstrate that it has carefully analyzed the financial and operational aspects of the proposal. At a minimum, factors that should be addressed are:	II.2. Business Plan For The Proposed Registry Operations	Yes
D13.2.1	Services to be provided. A full description of the registry services to be provided.	II.2.1 Services To Be Provided	Yes
D13.2.2	Revenue model. A full description of the revenue model, including rates to be charged for various services	II.2.2 Revenue Model	Yes
D13.2.3	Market. Market definition, size, demand, accessibility.	II.2.3 Market Overview	Yes
D13.2.4	Marketing plan. Advertising, publicity, promotion strategy, advertisement development strategy, relationship with advertising firm. Use of registrars and other marketing channels.	II.2.4 Marketing Plan	Yes
D13.2.5	Estimated demand for registry services in the new TLD. Projected total demand for registry services in the TLD, effect of projected registration fees, competition. Please provide estimates for at least 10%, 50%, and 90% confidence levels.	II.2.5 Estimated Demand For Registry Services In The New TLD	Yes
D13.2.6	Resources required to meet demand. Provide a detailed estimate of all resources (financial, technical, staff, physical plant, customer service, etc.) required to meet the estimated demands, using at least the 10%, 50%, and 90% confidence levels.	II.2.6 Resources Required To Meet Demand	Yes
D13.2.7	Plans for acquiring necessary systems and facilities. Describe plans for acquiring all necessary systems and facilities for providing the proposed services at each estimated demand level. Provide details as to the scope, cost, and vendor for any significant planned outsourcing.	II.2.7 Plans For Acquiring Necessary Systems And Facilities	Yes
D13.2.8	Staff size/expansion capability. Plans for obtaining the necessary staff resources, capacity for expansion, hiring policy, employee training, space for additional staff, staffing levels needed for provision of expanded technical, support, escrow, and registry services	II.2.8 Staff Size/Expansion Capability	Yes
D13.2.9	Availability of additional management personnel. How will management needs be filled?	II.2.9 Availability Of Additional Management Personnel	Yes
D13.2.10	Term of registry agreement. State assumptions regarding the term of any registry agreement with ICANN or the sponsoring organization. Note that the .com/.net/.org registry agreement has a basic term of four years.	II.2.10 Term Of Registry Agreement	Yes
D13.2.11	Expected costs associated with the operation of the proposed registry. Please break down the total estimated operational costs by the sources of the costs for each estimated demand level. Be sure to consider the TLD's share of ICANN's cost recovery needs. (See <http://www.icann.org/financials/budget-fy00-01-06jun00.htm#IIIB>.)	II.2.11 Expected Costs Associated With The Operation Of The Proposed Registry	Yes
D13.2.12	Expected revenue associated with the operation of the proposed registry. Please show how expected revenue is computed at each estimated demand level.	II.2.12 Expected Revenue Associated With The Operation Of The Proposed Registry	Yes
D13.2.13	Capital requirements. Quantify capital requirements in amount and timing and describe how the capital will be obtained. Specify in detail all sources of capital and the cost of that capital (interest, etc.). Evidence of firm commitment of projected capital needs will substantially increase the credibility of the registry operator's proposal.	II.2.13 Capital Requirements	Yes
D13.2.14	Business risks and opportunities. Describe upside and downside contingencies you have considered and discuss your plans for addressing them.	II.2.14 Business Risks And Opportunities	Yes
D13.2.15	Registry failure provisions. Please describe in detail your plans for dealing with the possibility of registry failure.	II.2.15 Registry Failure Provisions	Yes
D13.3	Pro-forma financial projections. Please provide detailed pro-forma financial projections, consistent with your business plan, for the demand scenarios that you estimate under item D13.2.5. The pro-formas should show revenue and expense estimates broken down by detailed categories and should be broken down into periods no longer than quarterly.	II.3 Pro-Forma Financial Projections	Yes
D13.4	Supporting documentation. The following documentation should be provided in support of the Business Capabilities and Plan section:	II.4 Supporting Documentation	Yes
D13.4.1	Registry operator's organizational documents. Documents of incorporation (or similar documents).	II.4.1 Registry Operator's Organizational Documents	Yes
D13.4.2	References. A list of significant trade and credit references.	II.4.2 References	Yes
D13.4.3	Annual report. The registry operator's most recent annual financial report (or similar document). Audited financials are preferred	II.4.3 Annual Report	Yes
D13.4.4	Proof of capital. Provide evidence of existing capital or firm commitments of capital. Demonstrated access to necessary capital will be carefully scrutinized.	II.4.4 Proof Of Capital	Yes
D13.4.5	Proof of insurance. Please provide proof of the insurance described in item D13.1.8.	II.4.5 Proof Of Insurance	Yes
III TECHNICAL CAPABILITIES AND PLAN	D14. The third section of the Registry Operator's Proposal is a description of the registry operator's Technical Capabilities and Plan. This section must include a comprehensive, professional-quality technical plan that provides a detailed description of the registry operator's current technical capabilities as well as a full description of the operator's proposed technical solution for establishing and operating all aspects of the registry. The technical plan will require detailed, specific information regarding the technical capabilities of the proposed registry. The topics listed below are representative of the type of subjects that will be covered in the Technical Capabilities and Plan section of the Registry Operator's Proposal. [INSTRUCTION: ICANN will extensively review and analyze this section of the Registry Operator's Proposal. The content, clarity, and professionalism of this section will be important factors in ICANN's evaluation of applications. We strongly recommend that those who are planning to apply secure professional assistance from engineers and/or other technical consultants to aid in the formulation of the technical plan and the preparation of the Technical Capabilities and Plan section of the Registry Operator's Proposal.] D15. The Technical Capabilities and Plan section should consist of at least the following:	III TECHNICAL CAPABILITIES AND PLAN	Yes
D15.1	Detailed description of the registry operator's technical capabilities. This should provide a detailed description of the registry operator's technical capabilities, including information about key technical personnel (qualifications and experience), size of technical workforce, and access to systems development tools. It should also describe the registry operator's significant past achievements. This description offers the registry operator an opportunity to demonstrate the extent of its technical expertise in activities relevant to the operation of the proposed registry.	III.1 Registry Operator's Technical Capabilities	Yes
D15.2	Technical plan for the proposed registry operations. This should present a comprehensive technical plan for the proposed registry operations. In addition to providing basic information concerning the operator's proposed technical solution (with appropriate diagrams), this section offers the registry operator an opportunity to demonstrate that it has carefully analyzed the technical requirements of registry operation. Factors that should be addressed in the technical plan include:	III.2 Proposed Registry Operations Technical Plan	Yes
D15.2.1	General description of proposed facilities and systems. Address all locations of systems. Provide diagrams of all of the systems operating at each location. Address the specific types of systems being used, their capacity, and their interoperability, general availability, and level of security. Describe in detail buildings, hardware, software systems, environmental equipment, Internet connectivity, etc.	III.2.1 Proposed Facilities and Systems	Yes
D15.2.2	Registry-registrar model and protocol. Please describe in detail.	III.2.2 Registry Registrar Model and Protocol	Yes
D15.2.3	Database capabilities. Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.	III.2.3 Database Capabilities	Yes
D15.2.4	Zone file generation. Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.	III.2.4 Zone File Generation	Yes
D15.2.5	Zone file distribution and publication. Locations of nameservers, procedures for and means of distributing zone files to them.	III.2.5 Zone File Distribution & Publication	Yes
D15.2.6	Billing and collection systems. Technical characteristics, system security, accessibility.	III.2.6 Billing and Collections System	Yes
D15.2.7	Data escrow and backup. Frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of escrow agents, procedures for retrieval of data/rebuild of database, etc.	III.2.7 Data Escrow & Backup	Yes
D15.2.8	Publicly accessible look up/Whois service. Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc.	III.2.8 Publicy Accessible Look Up/Whois Service	Yes
D15.2.9	System security. Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering, and other disruptions to operations. Physical security.	III.2.9 System Security	Yes
D15.2.10	Peak capacities. Technical capability for handling a larger-than-projected demand for registration or load. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance, personnel.	III.2.10 Peak Capacities	Yes
D15.2.11	System reliability. Define, analyze, and quantify quality of service.	III.2.11 System Reliability	Yes
D15.2.12	System outage prevention. Procedures for problem detection, redundancy of all systems, back up power supply, facility security, technical security, availability of back up software, operating system, and hardware, system monitoring, technical maintenance staff, server locations.	III.2.12 System Outage Prevention	Yes
D15.2.13	System recovery procedures. Procedures for restoring the system to operation in the event of a system outage, both expected and unexpected. Identify redundant/diverse systems for providing service in the event of an outage and describe the process for recovery from various types of failures, the training of technical staff who will perform these tasks, the availability and backup of software and operating systems needed to restore the system to operation, the availability of the hardware needed to restore and run the system, backup electrical power systems, the projected time for restoring the system, the procedures for testing the process of restoring the system to operation in the event of an outage, the documentation kept on system outages and on potential system problems that could result in outages.	III.2.13 System Recovery Procedures	Yes
D15.2.14	Technical and other support. Support for registrars and for Internet users and registrants. Describe technical help systems, personnel accessibility, web-based, telephone and other support, support services to be offered, time availability of support, and language-availability of support.	III.2.14 Technical & Other Support	Yes
D15.3	Subcontractors. If you intend to subcontract any the following: · all of the registry operation function; · any portion of the registry function accounting for 10% or more of overall costs of the registry function; or · any portion of any of the following parts of the registry function accounting for 25% or more of overall costs of the part: database operation, zone file generation, zone file distribution and publication, billing and collection, data escrow and backup, and Whois service please (a) identify the subcontractor; (b) state the scope and terms of the subcontract; and (c) attach a comprehensive technical proposal from the subcontractor that describes its technical plans and capabilities in a manner similar to that of the Technical Capabilities and Plan section of the Registry Operator's Proposal. In addition, subcontractor proposals should include full information on the subcontractor's technical, financial, and management capabilities and resources.	III.3 Subcontractors	Yes

JVTeam Policy Proposal Compliance/Cross Reference Matrix
RFP Section		ABBREVIATED Requirement/Instructions		JVTeam Response Section		JVTeam Complies
	TLD Policies		[INSTRUCTION: For sponsored TLDs, this part of the application is to be completed by the sponsoring organization. For unsponsored TLDs, the registry operator should complete this part of the application. Please refer to the Detailed Application Instructions for more information on the requirements for new TLD applications. The operation of a TLD involves the implementation of policies on a very large number of topics. Applicants are urged to use their response to this part of the application to demonstrate their detailed knowledge of what topics are involved and their careful analysis and clear articulation of the policies they propose on these topics. Please place the legend "CONFIDENTIAL" on any part of your description that you have listed in item F3.1 of your Statement of Requested Confidential Treatment of Materials Submitted. Section III of this application applies only to applicants for restricted TLDs. Ordinarily, restricted TLDs should be sponsored.]		TLD POLICIES		Yes
	I		GENERAL TLD POLICIES (Required for all TLDs. Note that two special policy areas--policies during the start-up period and restrictions on who may register within the TLD and for what purpose--are covered in sections II and III below.)		I. General LTD Policies		Yes
	E1		In General. Please provide a full and detailed description of all policies to be followed in the TLD (other than those covered in response to items E11-E21). If the TLD's policy on a particular topic is proposed to be identical to that reflected by a particular version of any of the following documents, it is sufficient for your response to identify the topic, to give a brief summary of the policy, and for the details to reference the document and section: · ICANN Registrar Accreditation Agreement · NSI Registrar License and Agreement · ICANN-NSI Registry Agreement · Uniform Dispute Resolution Policy Your response should comprehensively describe policies on all topics to be followed in connection with the proposed TLD. The following items (E2-E10) are examples only and should not limit your description.		I.1 In General		Yes
	E2		TLD String. Please identify the TLD string(s) you are proposing. For format requirements for TLD strings, see the answer to FAQ #5.		I.2 TLD String		Yes
	E3		Naming conventions. Describe the naming conventions and structure within the TLD. E.g., will registrants have names registered at the second level (directly under the TLD, as in registered-name.com), or will the TLD be organized with sub-domains so that registered domain names are created at a lower level (as in registered-name.travel.com)?		I.3 Naming Conventions		Yes
	E4.		Registrars. Describe in detail the policies for selection of, and competition among, registrars. Will domain-name holders deal through registrars, directly with the registry operator, or some combination of the two? What are the respective roles, functions, and responsibilities for the registry operator and registrars? If registrars are to be employed, how and by whom will they be selected or accredited? If the number of registrars will be restricted, what number of registrars will be selected? Have the qualifying registrars already been selected? On what basis will selections among those seeking to be registrars be made, and who will make them? If registrars are to be used, what mechanisms will be used to ensure that TLD policies are implemented?		I.4 Registrars		Yes
	E5.		Intellectual Property Provisions. Describe the policies for protection of intellectual property. Your response should address at least the following questions, as appropriate to the TLD: E5.1. What measures will be taken to discourage registration of domain names that infringe intellectual property rights? E5.2. If you are proposing pre-screening for potentially infringing registrations, how will the pre-screening be performed? E5.3. What registration practices will be employed to minimize abusive registrations? E5.4. What measures do you propose to comply with applicable trademark and anti-cybersquatting legislation? E5.5. Are you proposing any special protections (other than during the start-up period) for famous trademarks? E5.6. How will complete, up-to-date, reliable, and conveniently provided Whois data be maintained, updated, and accessed concerning registrations in the TLD?		I.5 Intellectual Property Provisions		Yes
	E6.		Dispute Resolution. Describe the policies for domain name and other dispute resolution. If you are proposing variations to the policies followed in .com, .net, and .org, consider the following questions: E6.1. To what extent are you proposing to implement the Uniform Dispute Resolution Policy? E6.2. Please describe any additional, alternative, or supplemental dispute resolution procedures you are proposing.		I.6 Dispute Resolution		Yes
	E7.		Data Privacy, Escrow, and Whois. Describe the proposed policies on data privacy, escrow and Whois service.		I.7 Data Privacy, Escrow, and Whois		Yes
	E8		Billing and Collection. Describe variations in or additions to the policies for billing and collection.		I.8 Billing and Collections		Yes
	E9		Services and Pricing. What registration services do you propose to establish charges for and, for each such service, how much do you propose to charge?		I.9 Services and Pricing		Yes
	E10		Other. Please describe any policies concerning topics not covered by the above questions.		I.10 Other		Yes
	II		REGISTRATION POLICIES DURING THE START-UP PERIOD (Required for all TLDs)		II. Registration Policies During Start-up		Yes
	E11		In this section, you should thoroughly describe all policies (including implementation details) that you propose to follow during the start-up phase of registrations in the TLD, to the extent they differ from the General TLD Policies covered in items E1-E9. The following questions highlight some of the areas that should be considered for start-up policies:		II. Registration Policies During Start-up		Yes
	E12		How do you propose to address the potential rush for registration at the initial opening of the TLD? How many requested registrations do you project will be received by the registry operator within the first day, week, month, and quarter? What period do you believe should be considered the TLD's "start-up period," during which special procedures should apply?		II. Registration Policies During Start-up		Yes
	E13		Do you propose to place limits on the number of registrations per registrant? Per registrar? If so, how will these limits be implemented?		II. Registration Policies During Start-up		Yes
	E14		Will pricing mechanisms be used to dampen a rush for registration at the initial opening of the TLD? If so, please describe these mechanisms in detail.		II. Registration Policies During Start-up		Yes
	E15		Will you offer any "sunrise period" in which certain potential registrants are offered the opportunity to register before registration is open to the general public? If so, to whom will this opportunity be offered (those with famous marks, registered trademarks, second-level domains in other TLDs, pre-registrations of some sort, etc.)? How will you implement this?		II. Registration Policies During Start-up		Yes
	. III		REGISTRATION RESTRICTIONS (Required for restricted TLDs only) E16. As noted in the New TLD Application Process Overview, a restricted TLD is one with enforced restrictions on (1) who may apply for a registration within the domain, (2) what uses may be made of those registrations, or (3) both. In this section, please describe in detail the restrictions you propose to apply to the TLD. Your description should should define the criteria to be employed, the manner in which you propose they be enforced, and the consequences of violation of the restrictions. Examples of matters that should be addressed are:		III Registration Restrictions		Yes
	E17		Describe in detail the criteria for registration in the TLD. Provide a full explanation of the reasoning behind the specific policies chosen.		III Registration Restrictions		Yes
	E18		Describe the application process for potential registrants in the TLD.		III Registration Restrictions		Yes
	E19		Describe the enforcement procedures and mechanisms for ensuring registrants meet the registration requirements.		III Registration Restrictions		Yes
	E20		Describe any appeal process from denial of registration.		III Registration Restrictions		Yes
	E21		Describe any procedure that permits third parties to seek cancellation of a TLD registration for failure to comply with restrictions.		III Registration Restrictions		Yes
	IV		CONTEXT OF THE TLD WITHIN THE DNS (Required for all TLDs) E22. This section is intended to allow you to describe the benefits of the TLD and the reasons why it would benefit the global Internet community or some segment of that community. Issues you might consider addressing include:		IV. Context of TLD Within the DNS		Yes
	E23		What will distinguish the TLD from existing or other proposed TLDs? How will this distinction be beneficial?		IV. Context of TLD Within the DNS		Yes
	E24		What community and/or market will be served or targeted by this TLD? To what extent is that community or market already served by the DNS?		IV. Context of TLD Within the DNS		Yes
	E25		Please describe in detail how your proposal would enable the DNS to meet presently unmet needs.		IV. Context of TLD Within the DNS		Yes
	E26		How would the introduction of the TLD enhance the utility of the DNS for Internet users? For the community served by the TLD?		IV. Context of TLD Within the DNS		Yes
	E27		How would the proposed TLD enhance competition in domain-name registration services, including competition with existing TLD registries?		IV. Context of TLD Within the DNS		Yes
	V		VALUE OF PROPOSAL AS A PROOF OF CONCEPT (Required for all TLDs)		V. Value of Proposal as a Proof of Concept		Yes
	E28		Recent experience in the introduction of new TLDs is limited in some respects. The current program of establishing new TLDs is intended to allow evaluation of possible additions and enhancements to the DNS and possible methods of implementing them. Stated differently, the current program is intended to serve as a "proof of concept" for ways in which the DNS might evolve in the longer term. This section of the application is designed to gather information regarding what specific concept(s) could be evaluated if the proposed TLD is introduced, how you propose the evaluation should be done, and what information would be learned that might be instructive in the long-term management of the DNS. Well-considered and articulated responses to this section will be positively viewed in the selection process. Matters you should discuss in this section include:		V. Value of Proposal as a Proof of Concept		Yes
	E29		What concepts are likely to be proved/disproved by evaluation of the introduction of this TLD in the manner you propose?		V. Value of Proposal as a Proof of Concept		Yes
	E30		How do you propose that the results of the introduction should be evaluated? By what criteria should the success or lack of success of the TLD be evaluated?		V. Value of Proposal as a Proof of Concept		Yes
	E31		In what way would the results of the evaluation assist in the long-range management of the DNS?		V. Value of Proposal as a Proof of Concept		Yes
	E32		Are there any reasons other than evaluation of the introduction process that this particular TLD should be included in the initial introduction?		V. Value of Proposal as a Proof of Concept		Yes
			Statement of Requested Confidential Treatment of Materials Submitted		STATEMENT OF CONFIDENTIALITY—Tab		Yes
			Registry Operator's Fitness Disclosure		REGISTRY OPERATOR’S FITNESS DISCLOSURE—Tab		Yes

^{Executive summary}

Ten years ago it would have been extremely difficult to foresee the exponential growth and sweeping impact that the Internet has had on every aspect of our lives. If we look forward another ten years we have to accept that the Internet will continue to grow and change in ways that we cannot even imagine. However, when we look at the past, at how it has shaped the present, we begin to identify clear patterns that can instruct our understanding of the future, and we can use these patterns to anticipate and prepare. The most vivid of these patterns is the notion that technology is driven by the needs of people. The domain name system is a perfect example of this: people need and want a simple and secure way to interact with the world around them. The Internet makes this possible and the domain name system makes it accessible.

Up to this point, the domain name system has played a crucial role in the growth of the World Wide Web and will continue to facilitate the convergence of telecommunications and the Internet. If we indulge ourselves for a moment and overlay what we have seen over the past ten years onto what we are likely to see in the next ten, there are several scenarios that seem imminent.

a. Every individual will want an online personal identity that they will use from cradle to grave

b. Businesses will use authentication and verification in all of their day-to-day transactions

c. Internet Protocol devices will be prolific and will be referenced and accessed by name rather than by a number

e. A plethora of new products and services will be invented to service the specific needs of the on line community

In every one of these scenarios, the DNS is a core element. The DNS as it stands, mapping IP addresses to names, is rudimentary and yet it has served the community well. We can conceive of a time when the DNS will be enhanced and expanded to map many different types of objects to each other. It is this future, potential expansion of the DNS’ capabilities and services that is at the heart of the JVTeam approach and proposal.

JVTeam Understands the Issues

The current program to introduce new top level domains into a competitive, multiple registry environment represents a critical and exciting next step for the online community. We arrived at this point through the tireless efforts of many dedicated organizations and individuals who have strived to build a stable and useful domain name system-- one that can meet the needs of individuals and businesses. JVTeam wishes to build on the strengths of these efforts by contributing responsibly and by providing the next generation domain name registry.

Effective and responsible management of a new registry requires an operator who understands the fluid, innovative environment of the Internet and has substantial DNS experience. The registry operator must have proven expertise and eminent credentials in managing a vital public resource and the ability to facilitate discussion about standards development and technical issues between competing parties. In order to cultivate the ongoing development of the domain name system environment, the registry operator must also be capable of and committed to providing a robust and scalable network infrastructure.

While the technical component is critical, successful management of a TLD registry requires much more. The registry must also have the trust of its customers and the larger community. Therefore, the registry operator must have a commitment to the security and privacy of customer information and must be capable of operating as a neutral entity within a highly competitive environment. In addition, the registry operator must have proven, even-handed policy expertise to facilitate mechanisms for the resolution of issues relating to disputes, intellectual property, standards and privacy.

The critical factors for success: Maintaining Stability and paving the way for the future introduction of new TLDs.

JVTeam understands the critical nature of a stable domain name system. It is essential that the DNS continues to grow as a globally unique, consistent structure to maximize the utility and effectiveness of domain names for the community. A registry operator must have the ability and experience to provide a substantial, trans-continental network infrastructure which can guarantee maximum performance and reliability as well as scale seamlessly to meet volatile variations in demand. But stability encompasses much more. It is also critical that the registry operator’s integrity remains unquestioned in maintaining an environment of open and fair competition, in providing a solution to the initial rush for domain names and in facilitating even-handed, workable policy administration.

The introduction of new TLDs is without precedent and because of the world’s increasing dependence on the DNS, it is imperative that ICANN and the Internet community generally learn as much as possible from this first round. It is just as important for the ongoing development of this program that this first round is successful and in no way undermines the stability of the DNS. In this context, the registry operator must be capable of understanding the implications of all of its choices both in terms of ensuring success and in understanding the instructional benefit of the results. The registry operator must be committed not just to providing registration services, but also to capturing information and sharing it unconditionally for the benefit of the future release of top level domains.

The JVTeam Solution

JVTeam is a new company formed by NeuStar and Melbourne IT to provide domain name registry services driven by customer focus, technological innovation and proven channel management expertise. The JVTeam registry will deliver the world’s most advanced domain name services in a manner that reflects the character of its parent companies through a resolute commitment to neutrality and integrity.

JVTeam fuses the DNS management expertise, registry operations experience, and technical database management capabilities of its parent companies to provide only the highest quality registry services. The scope of these services goes beyond the current boundaries and incorporates new features and abilities that will benefit end users and will enable the participation and creativity of the online community in further evolving the function and utility of the domain name system.

We have a demonstrated commitment to working cooperatively and positively within the Internet community as a team player focused on responsible management of a vital public resource. We have the technical and registry expertise to develop and deploy a first-of-its-kind solution in a fully open, non-proprietary environment. Our team has designed a technical and operational plan that will satisfy and exceed all of the requirements stipulated in the Request For Proposal (RFP). More importantly we have a team of eminently qualified, skilled and talented individuals who are not only capable of delivering the solution but are passionate about its success.

But JVTeam’s commitment to success is much more than words. Throughout this proposal you will find explicit detail as demonstrating that JVTeam has the resources, the people and the will to ensure the success of the new TLD.

XRP and the Fat Registry Model

JVTeam has an intimate knowledge of the current registry-registrar model and has identified several existing problems and opportunities. JVTeam considered several approaches including modifying the current RRP and maintaining a thin registry. After intensive exploration of these issues our technical, business and policy teams agreed that the solution which would most benefit the Internet community and meet the requirements identified by ICANN would be the adoption of a new registry-registrar protocol, eXtensible Registry Protocol (XRP) and migration to a fat registry. The benefits of this solution cannot be overstated. The proposed XRP will enable enhanced diversity and functionality for any TLD for which the registry provides services, remove the need for each registrar to provide ICANN with escrow capability, provide registrants with access to better, faster and more secure domain name services and significantly reduce the technical barrier to entry for new registrars enabling increased competition.

JVTeam is convinced that from all perspectives, the XRP and the fat registry model will ensure the stability of the Internet, provide higher standards of service and functionality for registrants, enhance the utility of the DNS, maximize the potential for competition and provide the way forward for the future introduction of new top level domains.

Pricing

JVTeam expended significant effort in finding the right balance between the cost of our proposed solution and maintaining a competitive price point for the new TLD. We believe that our proposal represents the best and only solution in balancing a considerable investment in infrastructure and development with the commercial viability of the registry.

We believe that there are key elements in the proposed technical solution that cannot and should not be compromised. For JVTeam, the ability to deliver new functionality and superior service to anyone, anywhere and anytime has become an article of faith.

JVTeam was cognizant of the fact that the very significant investment for this venture could only be recovered if it participated as an operator/subcontractor over a number of TLD strings to ensure it had the volume to match its cost structure. It was aware of the precedent that currently exists with Network Solutions operating three TLD strings .com, .net and .org.

Businesses frequently struggle to find a balance between the cost of producing a high quality service and the desire to deliver the lowest possible price to the market. JVTeam has been able to achieve a solution for the next generation domain name registry with enhanced functionality, stability, security and reliability at a price point that is lower than existing TLDs. Compromising the quality of the technical solution was simply not an option as it has become abundantly clear that the future needs of the Internet community can only be served through provision of a new registry platform that incorporates the fat registry model.

Business Capabilities and Plan

JVTeam has developed a registry solution which incorporates realistic business goals, thorough market analysis as well as comprehensive financial and operational planning. The “Business Capabilities and Plan” section of this proposal provides a detailed description of the business decisions we have made and the reasoning behind those decisions.

To ensure global awareness of and participation in the new top level domain, JVTeam is committed to a significant allocation of funds and dedicated personnel for a pre-emptive marketing campaign. Several months prior to the official launch of the new TLD, JVTeam will commission an extensive product awareness exercise including strategic mass media buys and public relations activities.

The business section of our proposal provides full details of services to be provided by the registry. JVTeam’s suite of registry services will provide the global community with access to the highest standards of support, security and administration at a very competitive price. In addition, these services will be provided in an entirely neutral and even-handed manner. The JVTeam registry will maintain a tight customer focus in all of its operations and will cultivate effective two-way communication between registrars and the registry.

JVTeam recognizes the complexities raised by intellectual property issues and will provide an Intellectual Property Notification Service whereby interested parties are able to monitor registration of domains which may infringe on their intellectual property concerns.

While the JVTeam registry is committed to success, we are also cognizant of the fact that any successful business plan must take into account both current and future risks. In this section the details of our approach to risk management incorporating proven techniques for identifying, analyzing and mitigating risks on an ongoing basis.

Technical Capabilities and Plan

JVTeam can offer comprehensive technical capabilities in the areas of registry operation, software development, database management, and standards development. These abilities are founded on extensive experience in all areas related to technical service provision for a critical public resource. JVTeam is the best choice to design, deliver and maintain the next generation domain name registry.

JVTeam provides details of the our proposal for an eXtensible Registry Protocol (XRP) and a fat registry model. Under this model, the business relationships remain unchanged: registrants will still deal with the registrar, and the registrars with the registry. The value of the proposed change in registry protocol lies in its ability to solve many of the problems currently experienced on a daily basis by both registrants and registrars and to facilitate the expansion of applications and utilities for domain names at all levels.

Our technical solution also includes operation of diverse, redundant, 24x7x365 data centers to ensure highest security and availability. In addition, standard operating practice will involve meeting monthly service level agreements (SLA) with associated penalties for non-performance. Our trans-continental network infrastructure will ensure that exactly the same levels of service and performance can be provided to end users regardless of their geographic location.

Implementation

JVTeam is prepared through experience and commitment to meet and exceed the requirements and objectives of the RFP and to deliver our proposed solution on time and within budget. In Section IV, “Implementation”, we demonstrate our extensive project management capability and experience. Through our strong project leadership and experienced staff, JVTeam will ensure project success.

The land rush component of this section describes our plans for effectively managing the issues raised by the initial rush for domain names. JVTeam is proposing a solution that ensures the moderated and impartial allocation of names during this period.

As JVTeam was born from a strong heritage of quality assurance, our approach to implementation encompasses the critical components of quality management to ensure the highest level of performance is achieved.

Policy

JVTeam is conscious that the first round introduction of new TLDs will provide vital information for the ongoing development of the DNS. JVTeam also is aware that the existing mechanisms and policies implemented by ICANN have, on the whole, been very successful in maintaining the stability of the Internet. As such, the policies and concepts being proposed by JVTeam have been developed with a view to extending and enhancing the existing DNS environment in a measured, even-handed manner. This approach does not preclude innovation but rather it promotes the carefully considered, responsible evolution of the DNS. With this in mind JVTeam’s proposal includes introduction of the Uniform Charter Dispute Resolution Policy (UCDRP). This incorporates some additions to the UDRP to incorporate a charter for intended purpose domain name spaces.

The concepts being evaluated represent substantial, incremental enhancements to the domain name system as well as solutions to several pre-existing issues. The JVTeam proposal is premised on paving the way for the stable growth of the domain name system.

Conclusion

JVTeam shares ICANN’s mission to foster the measured development of the DNS, to maintain its stability and to cultivate competition in the marketplace. Competition is good for everyone. It makes us all stronger, more innovative, and more creative.

JVTeam’s proposal is based on a rich understanding of the needs of the global community. While our solution encompasses technological innovation and comprehensive business planning, it is ultimately about giving people more freedom and choice. We believe that we are building a registry platform which will enable the domain name system to grow and to deliver the services, products and information that are wanted and needed by the global community.

For the domain name system, the next ten years of evolution will be exhilarating, challenging and surprising. The information in this proposal is a demonstration of how JVTeam will contribute positively to that evolution by using all of the resources and knowledge at our disposal to provide the next generation domain name registry.

^{I General Information (RFP Sections D1-D11)}

All Other Business Locations: * See Registry Operator’s Proposal Section II.1.3, Past Business Operations, Entity History

Type of Business Entity: Limited Liability Company organized under laws of State of Delaware, USA.

Number of Employees: See Registry Operator’s Proposal Section II.1.6, Management and Section
II.1.7, Staff/Employees

All Relevant Managers See Registry Operator’s Proposal Section II.1.6, Management

* JVTeam is a newly formed, limited liability company created to function as a registry. Therefore, it is necessary to look to the history of our parent companies, which are fully committed to the success of JVTeam and it’s objectives. A detailed description of NeuStar, Inc. and Melbourne IT is provided in Section II.1.3 of this document.

Answers to questions posed in Registry Operator’s Proposal Sections I.1 through I.11 are provided for both parent companies.

D2 – D11 — NeuStar, Inc.

Type of Business Entity: Corporation organized under laws of the State of Delaware, USA

Total Revenue in last-ended fiscal year: NeuStar is currently preparing audited financial statements for 1999

All Directors Jeffrey E. Ganek; Joseph P. Landry; Dr. Henry Kressel; Dr. Kenneth Pickar; Henry Geller

D2 – D11 — Melbourne IT Ltd.

All Other Business Locations: INWW (a division of Melbourne IT) – Virginia, USA

Type of Business Entity: Melbourne IT is incorporated in Australia as a public company limited by shares.

Total Revenue in last-ended fiscal year: AUD$14.8m in 1999 (AUD$23m for the first half of 2000).

All Officers and Relevant Managers Adrian Kloeden, Chief Executive and Operating Officer

REGISTRY OPERATORS PROPOSAL Table of Contents

TLD POLICIES Proposal Table of Contents

REGISTRY OPERATOR’S FITNESS DISCLOSURE

TLD POLICIES

Registry Operator's Fitness Disclosure

Executive summary