World Health Organization TLD 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.]

[D] I. GENERAL INFORMATION

D1. Introduction

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.

A Memorandum of Understanding has been entered into between WHO and CORE, regarding CORE roles as are Registry operator for the .health domain (please see attached document). Given the specificity of the .health domain, the coverage of this proposal does not include details strongly dependant upon the policies expected to be designed by the Sponsoring Organization regarding the use of .health.

D2. Name and address

The full legal name, principal address, telephone and fax numbers, and e-mail address of the registry operator.

CORE Internet Council of Registrars
World Trade Center II
29 route de Pre-Bois
CH-1215 Geneva
Switzerland
Telephone +41 22 929 5744
Fax +41 22 929 5745

E-mail address: tldapp@corenic.org

D3. Other Business Locations

The addresses and telephone and fax numbers of all other business locations of the registry operator

N/A.

Note: CORE is an association whose members have their own marketing and customer service functions. CORE's members have offices in 20 countries on 4 continents and interact with customers in over 19 languages. (Please see attached.)

D4. Type of Entity

The registry operator's type of business entity (e.g., corporation, partnership, etc.) and law (e.g., Denmark) under which it is organized.

CORE is a non-profit association established under Swiss law.

CORE's current membership qualification criteria are the same as those currently used by ICANN for registrar accreditation

D5. URL

URL of registry operator's principal world wide web sites.

http://www.corenic.org

D6. Identifier

Dun & Bradstreet D-U-N-S Number (if any) of registry operator

N/A

D7. Number of Employees

Number of employees.

Thanks to its ability to outsource key functions to members, CORE does not currently have any employees of its own for its registrar activity. CORE's current outsourcing contracts account for ten (10) full-time positions devoted to CORE's central coordinating functions:

CORE shared registry System (Düsseldorf, Germany): 5 staff provided by CSL GmbH
CORE Secretariat (Geneva, Switzerland): 5 staff provided by Axone SA

For the sake of comparison to existing gTLD registrars with centralised business models, CORE has made an approximate count of CORE member staff concerned with domain registrations via CORE. The approximate aggregate number of number employees concerned with CORE registrations is 200.

For the CORE-Registry operations, a directly employed staff of 10 is to be built up prior to launching its first TLD. This staff will partly be newly hired and partly be seconded from members of the Association.

D8. Revenue

Registry operator's total revenue (in US dollars) in the last-ended fiscal year.

CORE Registrar Revenue

CORE's gross cash revenue during 1999 amounts to USD 2.4 million in registration fees paid by members for .com, .net and .org domain registrations performed through CORE. Net of fees paid to the .com/.net/.org registry and ICANN, the Association's cash revenue from registration amounts to USD 0.6 million. (See 1999 Financial Statements).

Membership contributions

The Association's total accrued membership contributions for 1999 amounted to USD 728,000. (See 1999 Financial Statements).

D9. Directors, Officers

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.

(i) Directors (CORE Executive Committee)

Current members of the Executive Committee are

Mr. Ken Stubbs, Chair
Dr. Jonathan Robinson, member of Executive Committee
Mr. François Luc Collignon, member of Executive Committee
Mr. Hal Lubsen, member of Executive Committe
Ms. Rosa Delgado, member of Executive Committee
Mr. Robert F. Connelly, member of Executive Committee
Mr. Werner Staub, member of Executive Committee and Head of CORE Secretariat

(ii) Officers

Werner Staub, Head of CORE Secretariat
Siegfried Langenbach, Head of Shared Registry System (SRS) Operation and Development

(iii) Managers

Uwe Ohse, SRS Operation and Development, Front-end and client systems
Christoph Schiffer, SRS Operation and Development, Back-end systems
Marc Baradez, CORE Secretariat
Radek Maturana, CORE Secretariat

(iv) (No ownership links)

As a not-for-profit Association under Swiss Law, CORE cannot be owned, all members irrespective of size stand on an equal footing and the Association is open to new members who qualify according to objective non-discriminatory membership criteria.

D10. Person for this Proposal

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.

1) CORE Secretariat:

Werner Staub
tldapp@corenic.org
Tel +41 22 929 5743
Fax +41 22 929 5745

2) Legal consultant:

María Luisa Osuna
Cuatrecasas Abogados
mluisa_osuna@cuatrecasas.com
Tel +34 93 2905548
Fax +34 93 2905588

3) Business plan consultant:
Mr. Antoine Fatio
KPMG Consulting
afatio@kpmg.com
Tel: +41 22 704 1515

D11. Subcontractors Listing

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.

[D] II. BUSINESS CAPABILITIES AND PLAN

D12. Executive Summary

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 profbessional 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.]

Resources available within CORE's Membership

CORE is an open association of companies who are fundamentally concerned with domain names and have created a co-ordinating technical framework while freely competing amongst each other. Thanks to the diversity of its membership CORE has access within its membership to the resources of

- World class telecommunications companies (Cegetel, France Telecom, Deutsche Telekom, KPN, Saritel/TelecomItalia, Telia, Colt Telecom);
- Highly specialised domain name registrars, a large number of whom are already ICANN-accredited;
- ccTLD registry operators (in particular DENIC, the largest registry after .com with over 3 million domains under .de; NIC-SE concerned with .se; DKNIC concerned with .dk);
- Internet Service providers;
and
- a standards organization (ETSI European Telecommunications Standards Institute). ETSI is the forum for key standards such as GSM and UMTS, and one of the four members of the ICANN´s PSO.

The co-operation of members through the CORE framework is limited to areas where shared resources are technically necessary. The shared resources are developed and managed by way of multi-lateral consensus building and fair sharing of costs.

Demonstrated Shared Registry Capabilities

CORE's current activity as a shared registrar is the result of US Department of Commerce "White Paper" which implicitly delayed the introduction of new TLDs but specified the transition of the .com/.net/.org registry to a shared model. The existing CORE SRS was adapted to interact with the newly created shared "light" registry operated by NSI. As the NSI registry does not record domain holders and contact information, the existing CORE shared system is a shared registry as far as domain holders and contacts are concerned. With over 800,000 domains managed in a shared environment, the CORE's current registrar system demonstrates the scalability and the validity of CORE shared "heavy" registry concept.

Separation of CORE Registry and CORE Registrar

As explained in CORE's .nom proposal, CORE points out that a registry operator should not be allowed to be a registrar in its own registry unless this takes place for a short transition time. This plan is built on the principle that the not-for-profit CORE Registry Operator will be institutionally separated from the not-for-profit CORE Registrar. There are to be two separate membership processes, separate supervisory bodies and separate staff. Both organizations will independently have the rights to use the current CORE shared registry system. It is to be expected that a number of CORE members will become members of both the CORE Registry and the CORE Registrar.

Enhancement of Existing CORE SRS and Protocol for new Registry Requirements

Learning from the .com experience

The existing CORE SRS has originally been built as a registry system. Some changes were made to match the architecture of NSI registry and the RRP (Registrar Registry Protocol) developed by NSI. A series of concepts used by the NSI registry (in particular the so-called light registry concept, the management of name servers) are at odds with the technical judgement of the CORE SRS working group. In other areas, the Registrar activity has given CORE members valuable experience on how to manage a highly distributed registration process (in particular with respect to division of work between member and resellers). The intermediate version of the CORE SRS specified in this plan (corresponding to SRS protocol version 1.1) represents a design goal compatible with CORE's time schedule and registry requirements. This design will be validated by a newly CORE Registry SRS working group, under the supervision of CORE Registry CTO.

Commitment to protocol convergence

CORE members are keenly aware of the need for convergence in registry protocols. This must be achieved through consensus-building between registries and registrars.

CORE is committed to contribute to the convergence of shared registry protocols and concepts. However, CORE does not feel that the current RRP is an appropriate working basis. CORE is looking forward to work on a common shared registry protocol with ccTLD registries and new and existing gTLD registries, within the ITEF framework.

Organizational concept

Central functions managed by CORE Staff

While CORE has relied on outsourcing contracts (principally with members), the central management of the new registry operator activities is to be entrusted to staff directly employed by the CORE Registry.

Redundancy through outsourcing and geographic distribution

CORE will continue to rely on outsourcing relationships, especially with members as its membership is particularly well-suited for most services and functions, in particular for commodity services or for functions that can and should be duplicated (WhoIs servers, Name servers …etc).

Competition between members in customer-related activities and value-added services

Interaction with customer and value-added services are areas of intense competition between members. The registry is not involved in customer interaction except for automated registry messages, where the interaction with registrar alone would not be sufficient. The customer cannot contact the registry to obtain direct interaction for normal transactions. If the registry is contacted, it directs the customer to the maintaining registrar for a given registration, or to the list of registrars, in a neutral fashion. If problems are reported, the registry informs the members involved and keeps track of the follow-up.

Value-added service by member registrars can be built upon instruments provided by the registry, such as the ability (available equally to all member registrars) to store optional information in the registry: PGP Public Keys, Personal Ids …etc.

Financial process

The registry operator funding process is based on members' parity in terms of contributions and risk sharing where an initial capital needs must be met. The history of CORE has shown that despite competition, there is enough solidarity between members to fund investments. The fee paid for registrations is equal for all members who have the freedom to set their own pricing. The registration fees are set as cost recovery and comprise the minimum reserve per domain needed to cover the duration of the registration and the contingencies that could arise over the average registration period.

Technical process

CORE's shared registration system is proven its value with over 800,000 domains shared by 30 CORE members who register .com, .net and .org domains via CORE. The current proposal is based on a variant of CORE Shared Registry System Protocol with slight modifications compared to the existing version (SRS Protocol Specification 1.1). For reasons linked to editorial work sharing and the limited time available for this proposal, some newly required procedures described in this proposal or in the registration policy documents are not yet described in this document. These are based on additional payload definitions and process specifications but analogous in architecture to the principal transactions.

As a Registrar organization, CORE is committed in contributing to converge on shared registry protocols. There is reason to expect productive dialogue between registries and registrars in this area as soon as the TLD application period ends. CORE will ensure that members can operate in compatibility mode and work with the registrar community at large to develop next generation protocols. There is a widely held view within CORE's membership that new protocols should give due consideration to recent standards such as XML and be developed on the traditional "rough consensus, running code" philosophy.

D13. Business Plan for the .health TLD

The Business Capabilities and Plan section should consist of at least the following:

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:

Note: in order to make it easier for ICANN to analyse the contents, the presentation of the business plan has been kept strictly in the format of the ICANN TLD application forms. As a result, some repetitions are inevitable.

D13.1.1. Company information.

Date of formation, legal status, primary location, size of staff, formal alliances, references, corporate or other structure, ownership structure.

Date of Formation

CORE has been founded in October 1997 pursuant to Article 60-79 of the Swiss Civil Code. As a not-for-profit organization, it stands automatically has acquired legal personality at inception. As Swiss not-for-profit organizations can voluntarily apply for registration, CORE has obtained registration in the Geneva Company Register (Registre du Commerce).

Before initiating registry operations, the association intends to split into a Registrar and a Registry. Under the current working hypothesis, this will involve the creation of a new association to which the assets and liabilities related to registry operations are transferred.

Legal Status

CORE is not-for-profit Association under Swiss Law. The current bylaws are attached.

The CORE Registry will also be a not-for-profit Association under Swiss law.

Primary Location

The Secretariat of the Association is located in Geneva, Switzerland (see D.2). Its current Shared Registration System is Located in Düsseldorf, Germany.

The CORE Registry will also have its Secretariat in Geneva, Switzerland. It is also expected that the main Registry Database will be hosted in Geneva. Additional database sites and points of presence may be located elsewhere.

Membership

At the time of writing CORE has 72 members. 11 members have joined the association in 1998, 1999 and 2000. Several CORE members are major Telecommunications or Internet infrastructure and application service providers. CORE's current membership is spread over 20 countries:

001	Nominalia	Spain
003	PSI K.K.	Japan
004	Internet Domain Registrars Corp.	Canada
005	First Identity Net	USA
008	Chungwa Telecom Co. Ltd	Taiwan
009	California Suncare, Inc.	USA
010	ETSI	France
011	CSL GmbH	Germany
012	TUCOWS International Corp. / Domain Direct	Canada
013	Melbourne IT	Australia
014	DENIC eG	Germany
016	NetBenefit (UK) LTD	United Kingdom
017	Interdomain, S.A.	Spain
018	Namebay S.A.M	Monaco
019	Pacific Communications Dev. Corp.	Taiwan
020	Aktiv GmbH	Germany
022	Global Internet Services, Inc	USA
024	Bahamas Telecommunications Corp	Bahamas
025	Corporate Domains, Inc.	USA
028	Net Wizards, Inc.	USA
030	Saritel S.p.A	Italy
033	IP Consult GmbH	Germany
035	Smartphone SA	Switzerland
038	Callisto germany.net	Germany
039	Knipp Medien und Kommunikation GmbH	Germany
040	Retevisión SA	Spain
041	Telia AB Network Services	Sweden
043	Alinet Italia Srl	Italy
045	Domain Names International, LLC	USA
046	Eurotel	Germany
048	LanMinds, Inc	USA
049	L.M. - Sitename Ltd	Israel
050	Médiafusion Inc.	Canada
051	Netlink Holdings Pty Ltd	Australia
052	Netlink Internet Services Ltd	United Kingdom
053	CASDNS, Inc.	USA
054	eNom, Inc.	USA
056	TotalNet Inc. Div. MPACT Immedia Inc	Canada
058	Internet Name Registrar	USA
059	The Edge Consultants Pte Ltd.	Singapore
060	France Telecom Transpac	France
061	Freedom Communications, Inc.	USA
063	Ji Tong Communications Co., Ltd.	China
064	SITA	Switzerland
066	Demon Internet Ltd.	United Kingdom
068	Epoch Networks	USA
071	Secunet Security Networks GmbH	Germany
072	Halo Technologies Ltd.	USA
075	Deutsche Telekom AG	Germany
076	Network Information Centre (NIC-SE)	Sweden
077	wespe.de GmbH	Germany
078	Domain Bank, Inc.	USA
079	Axone Services & Développement SA	Switzerland
080	Capital Networks Pty Ltd.	Australia
081	InterNetX GmbH	Germany
082	Grona Verket AB	Sweden
084	Tele Danmark A/S	Denmark
085	KPN Telecom BV	The Netherlands
086	Europe Online	Luxembourg
087	ARK Inc.	Japan
088	Tokyo Internet Corporation	Japan
090	InterQ	Japan
091	InterneXt	France
093	7WAYS	France
092	Cegetel S. A.	France
094	Boston Light Software Corp.	USA
095	OLM, LLC	USA
096	Global Village GmbH	Germany
097	ABC TeleMedia AG	Germany
098	COLT Telecom AG, Switzerland	Switzerland
099	3W-Media GmbH	Germany
101	Kamp Netzwerkdienste GmbH	Germany

(Formal Alliances)

Other than the relationship with its members, CORE does not entertain any formal alliances. However, it should be noted that CORE has signed MoUs with different organizations in order to serve as Registry Operator for their new TLD Proposals, including WHO's proposal.

Competition between members

CORE members operate in full competition with one another as far as CORE is concerned. While alliances can exist between individual members, they are not related to organized through CORE.

Organizational Structure

CORE current organizational structure is based on the following bodies: (a) Member plenary, (b) the Executive Committee, (c) the permanent Secretariat, (d) the SRS operations and maintenance team and (e) Working Groups.

No ownership, equal voting power of members

As a not-for-profit Association, CORE cannot be owned nor can it distribute any profits. CORE's financial resources are provided through advances from members based on a strict equal treatment concept. All members have the same voting power irrespective of size or usage of the central resources.

D13.1.2. Current business operations.

Core capabilities, services offered, products offered, duration of provision of services and products.

ICANN-accredited Registrar

CORE currently operates as an ICANN-accredited registrar enabling its members to register domains under .com. ,net and .org for their clients and resellers through CORE. In doing so, CORE stands as the contractual counter party to the domain holders, to ICANN, to the .com/.net/.org registry and to the members.

Shared Registry System Development

One of the key purposes for which CORE has been chartered is the development of a shared registry system and related standards. CORE's development activity is based on (1) the consensus-building within CORE' SRS working group and (2) compensated development work by members or third parties. The existence of CORE's SRS working group goes back to October 1997; the current group essentially composed of members using the SRS on a daily basis for domain registrations. A CORE member has developed the current implementation of the CORE SRS.

Fully distributed business model

CORE does not market any products other than the services made available to its members acting as domain registrars. Barring urgencies and problem tracking, CORE does not interact with customers other than through the member in charge of a given registration. Domain registrations can be transferred within CORE from one member to another at the request of the customer.

Shared Registration System based on Registry Model

The Shared Registration System (SRS) used by CORE is based on the model originally designed for use by a registry. Experience has shown that the same, or similar sharing mechanisms, are useful on registrar level as well.

Registrations in new generic TLD

It is expected that the CORE Registrar will act as a registrar in newly created TLDs in the same or similar fashion as it currently does for .com, .net and .org. For this reason, CORE intends to split its Registrar and Registry functions into two separate entities.

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.

History of CORE

CORE Internet Council of Registrars was established in October 1997 for the purpose of creating a shared not-for-profit domain name registry under the terms of the generic Top-Level Domains Memorandum of Understanding (gTLD-MoU; see http://www.gtld-mou.org). The gTLD-MoU had been signed in May 1997 under the auspices of the International Telecommunication Union.

The IAHC process preceding the launch of CORE

The gTLD-MoU formalised an open public consultation process launched at the initiative of the Internet Society (ISOC), the Internet Assigned Numbers Authority (IANA) and the International Telecommunication Union in response to the explosive growth of the DNS. The need for additional top-level domains was also felt in the context of the full monopoly held then by Network Solutions, Inc. on the registration of generic top-level domains. The need to specify an alternative was also felt because the contract between Network Solutions Inc. and the US National Science Foundation was due to expire in March 1998.

The consultation process leading to the gTLD-MoU and subsequently to the creation of CORE was organized through an ad-hoc multilateral committee called IAHC (International Ad Hoc Committee) composed of representative appointed by ISOC, IETF, IAB, INTA and the International Telecommunication Union.

The IAHC recommended the addition of 7 new Top-Level Domains to be managed in the public trust by a newly created shared registry to be called CORE Internet Council of Registrars. It specified the framework under which was to be set up including the gTLD-MoU, the CORE-MoU to be signed by all CORE members, the draft Articles of Association and Regulations of CORE, CORE's legal form as a Swiss not-for-profit Association, the membership criteria for CORE, the independent membership qualification approval process, the independent Policy Oversight Committee for CORE and the seven new TLDs to be managed by CORE. These specifications were published before companies could apply for membership.

It is important to point out that no member of CORE is associated with any of the members of the IAHC. All of the founding members of CORE were approved by an independent organization based on the objective qualification criteria.

Development of a scalable shared registry system

During the second half of 1997, 88 membership applications were approved. After the formal creation of CORE in October 1997, CORE started to build a shared registration system in 1997 in order to be ready for registrations by February 1998. This first version of an automated shared domain registry system based on the principle pre-payment was tested by a large number of CORE members.

Extensive participation in ICANN process

Following the publication of the US Government Green Paper on the Domain Name System, CORE and its members participated extensively in the consultation process which led to the publication of the US Government White Paper and later the creation of ICANN and the DNSO.

Second implementation of CORE SRS adapted to function as registrar system

In January 1999 CORE initiated the development of a second implementation of its registration system.

In the context of CORE's ICANN registrar accreditation and selection in 1999 as a Testbed registrar for the newly shared .com/.net/.org registry, this system was adapted to operate as a shared registrar system.

At the time of writing, CORE's shared registration system handles over 800,000 domain names. Over 30 CORE members participate as so-called reselling members in CORE's current role of ICANN-accredited registrar.

Duration of provision of services

CORE's com/net/org registrar framework has been in production mode since July 1999. Members' and outsourcing partners' involvement in domain registrations dates back to the early stages publicly available Internet services.

D13.1.4. Registry/database/Internet related experience and activities

Experience with database operation, Internet service provision.

Experience with shared registry database management

Shared databases as used in a shared registry are a relatively recent development. Even prior to developing its own system, CORE has been able to build on the experience made by CORE members who worked with two major shared registries, DENIC (.de) and Nominet (e.g. .co.uk). Several members of CORE's SRS working group held supervisory board positions in the Equally important bodies were contributions from members who worked with a large number of different domain name registries.

CORE's current shared Registrar System is a variant of the second implementation of its SRS design. Both implementations of the CORE SRS have originally been developed as a full-fledged registry system.

Experience with .com/.net/.org shared registry

At the time of writing, the CORE SRS manages over 800,000 domains under the responsibility of 30 CORE members. The SRS team manages the central Whois server (whois.corenic.net), which is updated within minutes after domain or contact information is changed.

The CORE SRS version used for .com/.net/.org is based on the second implementation of the CORE SRS developed in 1999. The interconnection with the NSI Registry took place in the framework of the NSI shared registry testbed for which CORE was selected as a "testbed registrar" by ICANN. It is important to point out that technically, a shared registrar system to be kept in synchrony with a "dorsal-spine-only" shared registry is more complex than a standalone registry. Moreover, CORE's work on the NSI interconnection could only start in June 1999 as NSI had not previously published its RRP protocol and at that time required a non-disclosure agreement and a performance bond before supplying any information.

Additional plausibility-checking, automated archiving and the SRS team and the CORE secretariat run verification tools. These systems are updated and improved continuously.

Despite its generally decentralized organizations, CORE relies on certain centralized verification mechanisms, such as those involved in domain holder changes. Experience with these mechanisms is key for CORE's proposals for distributed enforcement and verification mechanisms with a central audit electronic trail.

Internet-related experience and know-how available within membership

Most CORE members have a long-standing track record of internet related activities, either as Internet application developers, ISPs, Telecommunications companies, application hosting providers, hardware housing providers, ccTLD registries or specialized domain name registries.

D13.1.5. Mission.

The registry operator's mission and how it relates to expansion into the registry operation field.

The mission of CORE is to develop and operate standards and coordinating mechanisms for the central management of Internet domain registrations in the public trust on a not-for-profit basis. CORE's current mission as stated in the bylaws is defined on the basis of the gTLD-MoU, which nowadays is an historic reference only. After on the separation of CORE's registry and registrar activity, the missions of the two resulting organizations will be reworded based on the terminology that has evolved in the meantime.

D13.1.6. Management.

Qualifications and experience of financial and business officers and other relevant employees. Please address/include past experience, resumes, references, biographies.

CORE will set up a new management team for registry operations and initially draw on human resources in CORE's membership.

The biographies of the current executive committee members are attached. As a result of the projected separation of CORE's registrar and registry functions, the composition of the Executive Committee in charge of the registry at the start of operations may be different.

Also attached are biographies of several managers and technical experts who have already been identified as candidates who would be seconded by CORE members. CORE expects additional commitments from CORE members in the near future. For reasons of personal privacy and because the CORE membership at large has something to say in the choice of the candidates retained, the names are not for publication at this stage.

D13.1.7. Staff/employees.

Current staff size, demonstrated ability to expand employee base, hiring policy, employee training, space for additional staff.

Current resources

As a consortium of registrars, CORE currently operates with outsourcing agreements (generally to members) instead of hiring its own staff. This policy has provided CORE with the necessary flexibility in scaling its resources as required by rapidly changing needs. Thanks to the specialization of CORE's membership in Internet and domain name related activities, CORE has privileged access to technical experts and knowledgeable managers in its field.

Staff for registry activities

In the context of registry operations, CORE will build up a team of 10 staff positions by the time registry operations start. Depending on the overall workload required, the initial staffing level might be higher.

Given the immediate need for specialized managers and technical experts, CORE will primarily draw on membership resources to build the first nucleus of the Registry team. This will be based on seconding arrangements with members with a minimum duration of 1 year for senior positions and three months for junior positions.

CTO and CEO

The Registry activity will be placed under the responsibility of a chief executive officer and a chief technical officer. Both of these positions can either be filled by long-term members seconded staff or individuals firmly hired by CORE.

As pointed out under 13.1.7, the attached CVs are not for publication at this stage for privacy and due process reasons.

D13.1.8. Commercial general liability insurance.

Address/include amount of insurance policy, provider of policy, plans for obtaining additional insurance.

A confirmation letter of CORE's current company liability insurance policy from Baloise Insurance is attached.

A new policy is to be negotiated for the CORE Registry as soon as its separation from the CORE Registrar is complete.

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:

Introduction

Operational Model

The CORE Registry model is based on the principle that competing registrars share and control on the central coordinating resources on an equal footing. In the context of this application, the term registry operator applies to that central coordinating resource. The registry is operated on a cost-recovery basis and open to new members meeting objective, non-discriminatory membership criteria.

This principle in many ways implies what products and services the registry operator offers to members and indirectly to end-users.

For historic reasons, the CORE association is currently active as a registrar for .com, .net, .org registrations. Given many members' and end-users' reliance on these functions, there is a need to continue these operations as a shared registrar. The shared registrar will therefore be separated from the newly created shared registry operator and may become a member of the latter.

The membership qualification criteria currently used by CORE is in principle identical to those practiced by ICANN for accreditation except that CORE accepts supporting documentation in several additional languages. It is expected that after the split the CORE Registry would continue to relay on member qualification criteria equivalent to those used by ICANN. Indeed, as explained in the S.O Proposal, CORE favors a gTLD wide ICANN Registrar accreditation program.

Membership status needed to perform registrations, financial aspects

Membership in the CORE Registry is a necessary condition for access to registration resources. As the CORE Registry is not-for-profit membership association, it cannot rely on profit-oriented investments as a source of capital. Members are therefore required to provide financing in the form of membership fees credited for future registrations. The principle applied is equal treatment of all members in terms of the amount of funding required. As existing members have financed the current CORE association, the sum of past financial contributions is accounted for in this context. As soon as the financial situation of the association permits it, the members are allowed to use their contributions for registrations.

Possible additional requirements

Depending on the policies set for a given domain managed by the CORE Registry, there may be additional conditions for a member to be allowed to perform certain transactions and registrations. This can apply to sensitive transactions such as holder changes, registrar transfers or complaint submission, or to additional professional adequacy standards set forth by the applicable registration policy.

For registration in the .health TLD, the registrar has to sign the policy document and be approved by the Sponsoring Organization (SO). The SO approval concept and the related registry access privileges may be differentiated by type of operation.

Trust model and disciplinary framework

Presumption of trust in registrar

The registry in principle trusts its registrars and their due diligence in authenticating end-users. The registrars have the professional responsibility of submitting well-formed requests to the registry after reasonable verification as can be expected of a professional registrar in the specific circumstances. Failure to act professionally can lead to the member registrar being barred from certain transaction by decision of the registry operator or the sponsoring organization.

Certain transactions, such as registrar transfers, are placed under cross-verification, random verification or systematic screening regimes.

User authentication by registrar

The responsibility to authenticate users is placed on the registrars. Thanks to this principle, registrars can compete in terms of quality of service and the overall concept becomes scalable. This principle does not exclude designs where registrars place customers' digital certificates or other verification resources into the central registry database for additional security.

Ability to pre-screen registrations and changes

Depending on the policies of the Sponsoring Organization (SO), the CORE Registry provides mechanisms allowing registrations or changes to registrations to be performed electronically in two stages. When this method is used, a customer's instruction is executed by a registrar's request to the registry but registry keeps the request on hold. The request is completed only if a separate authority specified by the SO approves it.

If pre-screening is used and administered through the SO, the member registrar has the responsibility of submitting adequately pre-verified requests that can reasonably be expected to pass the screening hurdle. This is essential to keep the screening costs low and avoid irritation of end-users.

Relationship with ICANN accreditation concept

The current concept of ICANN registrar accreditation is specific to .com, .net and .org registrations. If ICANN creates a generic accreditation, this is expected to be a requirement for a member to register names. CORE is ready to cooperate with other registrars and ICANN in developing a generic accreditation framework.

D13.2.1. Services to be provided

A full description of the registry services to be provided.

Information registration and update services

The fundamental service provided by the registry is storage of domain and contact information. For this purpose, under normal circumstances, the registry interacts exclusively with member registrars in same fashion as securities exchange interacts with member securities firm.

The registrars in turn interact with the public and/or with resellers. Depending on the model used for chartered TLDs, additional services are provided in interaction with specific bodies designated by the Sponsoring Organization (e.g. pre-screening mechanisms).

Types of information stored by the registry

Note: the technical plan contains a detailed description of information resources managed by the registry.

Domain, name server, holder, contact, and maintenance information

The array of registration services provided is significantly larger than that of the current .com/.net/.org shared registry. CORE Registry will not only host domain and name server information, but also domain holder contact and maintenance information, or agent for contacts information.

Additional records

Moreover, additional information required by the SO could also be stored in the registry. As the registry evolves, additional value-added records (such as public key certificate IDs or key fingerprints) may be stored in the registry by the registrar at the request of the end-user.

Direct pointers

From a technical standpoint, the registry has the ability of maintaining direct pointers to hosts, eliminating if need be the delegation via additional name servers managed by third parties.

Electronic document storage

In the context of some transactions, registrars can store electronic copies of supporting documents in the registry and reference them from within the domain or contact records.

Information provision services

The registry provides information to registrars, end-user, and third parties with a legitimate interest and to the public, depending on its legal and regulatory obligations subject to the limitations specified by the contractual framework, ICANN policies and the Law.

Information to the end-user provided via the registrar

The registrar is the end-users partner for registration, but also for providing status information on the registration where the data cannot be published for privacy or other reasons. Data that is not published on the public Whois service can be checked through the maintaining registrar.

Cross-verification mechanisms

In the event that a domain holder wishes to perform a registrar change or wishes to check the data lodged in the registry without going through the maintaining registrar, a cross-verification mechanism is used. This mechanism is based on automated central procedures used to ensure that another registrar can only access a customer's information after having been specifically instructed.

An example of such a mechanism is the registry sending, at the request of Registrar B, a one-time password to the recorded customer address. The customer then can give this password to registrar B and obtain confirmation without having to go through the maintaining registrar A. This mechanism illustrates how important it is to store customer contact information centrally in order to foster competition between registrars.

Whois service

CORE will operate a unified Whois service i.e., contrary to the current concept use for .com, .net and .org, users can find all the data on the central Whois service. The Whois is run on several machines independent from the registry database. They only provide information that can be shown in line with policies, ICANN guidelines and applicable privacy legislation as set forth in the registration policy.

For performance and availability reasons, CORE will eventually operate several Whois servers on different locations providing information on all the domains registered.

As the Whois servers are separate from the registry database, updates are sent from registry back-end system to the Whois server whenever a change is made. A given domain or contact record will thus show in the registry within 30 seconds. This technology has been successfully used on the CORE registrar Whois server and has performed well for over 1,500,000 domain, contact and host records managed by the current SRS used for CORE's registrar activity.

Some specialized servers will be provided to facilitate pre-registration check queries, i.e. queries whose purpose is to verify if a domain is still available in the registry.

Third parties with legitimate interests

The SRS has the ability to administer, on a granular basis, information requests from third parties with a legitimate interest. In this context, it keeps track of the requests and the information provided. The requests are administered by the maintaining registrar whenever possible. Based on automated cross-verification and supervision by the registry, it is possible to process request involving several registrars in a single request.

The policy of providing information to third parties is subject to the registration agreement, registration policy and the applicable privacy legislation.

Registrar transfer capability

Domain portability and supervisory framework for orderly competition

The registrar competition model organized by the registry can be regarded as a service to the community at large.

The registry manages the mechanisms for transfers of domains between registrars at the request of the domain holder. This procedure is different from the one known as "change of sponsoring registrar" in the current .com/.net/.org registry in as much as the registry holds all the domain holder, contact and maintenance information. This provides additional security against accidentally or maliciously initiated transfers affecting data protection.

Registration and modification pre-screening framework available

The shared registry system has the ability to administer the pre-screening of registrations and modifications performed by third parties as mandated by the Sponsoring Organization. If pre-screening is used, customers contact registrars as they would in other cases. However, the registrations are not activated immediately. An approval request is sent to the parties identified by the SO who then can approve or reject a registration via digitally signed messages to the registry.

Complaint administration framework available (self-policing)

The registry has the ability to administer an automated complaint administration framework based on the principle that registrars register complaints on behalf of customers and the follow-up as well as automatic messages are generated by the registry.

D13.2.2. Revenue model.

A full description of the revenue model, including rates to be charged for various services.

Ability to run TLD-specific revenue models

While CORE registry will support the "traditional" revenue models used by most shared TLD registries currently, its design allows for specificities implemented for a given TLD. In particular, a given TLD managed through CORE Registry as Registry Operator may have specific financial requirements specified by the respective sponsoring organization, be it to cover the costs of the sponsoring organization or to collect fees for purposes mandated by the sponsoring organization.

Outside Sponsoring Organization

The underlying registry-level revenue model is separate from the sponsoring organization (SO) revenue model.

The registry-level revenue model is based on cost recovery whereas an outside sponsoring organization will define its own model based on its own role and process.

The outside sponsoring organization pre-finances the adjustments needed to the CORE SRS to accommodate the specific processes required. Once the registration phase begins, the financial flows are based on the pre-payment principle as follows:

customer -> registrar -> registry operator -> sponsoring organization

SO-based pre-screening model

The CORE Registry SRS is being designed to accommodate pre-screening functions performed by outside organizations or individuals appointed and funded by the Sponsoring Organization. The cost of effective formal pre-screening is normally a multiple of cost of the registry operations.

As soon as a registration is performed, the member registrar's prepayment account is debited. Unless otherwise mandated by the registration policy, no refund takes place if the Sponsoring Organization’s screening framework rejects the registration. (This principle encourages the submission of well-formed and carefully prepared applications). At regular intervals, the SO's portion of registration fees is wired to the SO.

SO-based post-screening model

The model used in this case is identical to the pre-screening model at the moment of registration, but may involve adjustments when records, deleted, put on hold, cross verified etc.

Revenue model for the .health TLD

Charge per domain-year to the registrar

The charge to the registrar would include the cost-recovery for the Registry operator and the Sponsoring Organization, including verification costs for acceptance of the application. The renewal process will further be linked to the re-verification of registration data.

Disincentive and special cost recovery charges

Disincentive charges are not designed to have a significant influence on the revenue stream. These charges may be used to manage resource bottlenecks or unexpected high demand for services that would usually be provided free of charge. This business plan does not take into account these charges. Examples of disincentive charges are fees charged to registrars for avoidable repetitive queries in excess of a set limit or ratio. Special cases are fines for accidental registrar transfers and similar problems.

Special cost recovery charges allow the registry to cover the expenses needed for special verifications and actions. They are not expected to have a significant impact on the Registry's financial results because their purpose is precisely to compensate possible perturbations. The idea behind special cost recovery charges is to be able to keep the price low and ensure that considerate customers to not have to pay for those who cause unreasonable costs. Examples of a special cost recovery charge are those applying for re-authentication, for complaint registration or for trademark protection requests (exclusion mechanism).

D13.2.3. Market.

Market definition, size, demand, and accessibility.

Market issues for .health are discussed in the Sponsoring Organization Proposal, Section E.??.

D13.2.4. Marketing plan.

Advertising, publicity, promotion strategy, advertisement development strategy, relationship with advertising firm. Use of registrars and other marketing channels.

Marketing by competing registrars

As an association of competing registrars, the CORE Registry is not involved in marketing activities directed to the public. Members compete on the basis of their marketing capabilities, their marketing channels, their quality of service and their value-added products. It is expected that the high linguistic diversity of CORE will further increase with the entry of new members.

Awareness programs and neutral information

The Registry Operator may participate in awareness programs in order to inform potential users, and the registry would support this with the provision of neutral information. In particular, the registry operator provides (a) descriptions and frequently asked questions, (b) lists of members and services by various criteria, regularly resorted by random order and (c) contractual reference information (registration policy, compulsory part of registration agreement, dispute resolution, complaint procedures.

The CORE registry operator will gradually increase the number of languages in which central information is provided. The current CORE secretariat can currently support members in 5 languages, which in turn facilitates members' outreach in their respective environments. Members will be able to contribute the creation of central multilingual information resources.

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.

It is premature to estimate the demand for .health registration, as this depends directly on the finally selection criteria to be determined by the WHO-led consensus process

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.

Resources for .health

Financial

Given the fact that CORE has an existing shared registry system and an ongoing registration operations through members, the additional requirements for financial resources can be met through existing funds and equal contributions from new members. The financial requirements for a restricted TLD such as .health are expected to be relatively low compared to high-volume TLDs.

Technical

CORE principal technical resource is its shared registration system (SRS) and the TLD servers. CORE will obtain housing and connectivity from members at market prices based on flexible contracts reflecting actual usage.

The projected physical plant is composed of a main SRS installation located at a protected co-location site with high-end hardware and network installations. A back-up site is to be hosted by a CORE member as is currently the case. The connectivity available through CORE members is virtually unlimited.

The TLD servers will be distributed and based on a staggered implementation plan. Initially, bandwidth and capacity requirements are modest as long as volume is low.

Staff

CORE expects to have 10 staff working for registry activities (including .health) in various managerial, technical and clerical capacities. This seems credible based on CORE's current operations (800,000 registrations) and the staffing levels of some ccTLD registries in CORE's membership. By way of comparison, DENIC employs 38 staff for over 3,000,000 domains and provides many services centrally that are member-based in CORE's model. Customer service is limited to member support and the provision of neutral information to the public.

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.

Starting with the second implementation of its SRS, CORE has successfully switched over to commodity type of hardware based running the Linux operating system. On the SRS, the back-end configuration involves a double processor CPU with a RAID mass storage and dual power supply. The front-end configuration is based on two separate machines, each of which can replace the other. The main SRS is hosted at a co-location site.

An identical configuration though possibly with lesser performance features is used as a test system.

TLD Name servers are based on leased or purchased type hosted at the main SRS site and initially on two, later 5 different locations world-wide. CORE will have full remote access to all TLD servers, housing is to be obtained from members or third parties at market prices.

Whois servers are based on lighter machines easy to duplicate. There will be several Whois servers so at the SRS location, later additional machines will be installed at remote locations. The concept of multiple Whois servers with incremental updating is key for the protection of SRS backend performance. Check queries from members and are directed to specialised Whois servers.

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.

As explained under D13.1.7, CORE will rely on seconded staff as well as limited outsourcing of non-central tasks. As staffing requirement rise, the registry will attempt to draw on seconded staff from members working full or part time for the registry. Certain experts can work remotely.

The operational concept of CORE is based on automated tasks on registry level and delegation of value-added tasks to member. This automatically limits the degree to which the registry requires clerical staff and support.

CORE has a tradition of working with members for development work. One-time tasks such as specific software developments and documentation projects can be entrusted to experts from within the compensated at market rates. Many CORE members are specialized application developers who make available their systems to third parties.

D13.2.9. Availability of additional management personnel.

How will management needs be filled?

At CORE, CEO, CT O and other key positions are filled either by long.-term member seconded professionals or by newly hired personnel. A formal call to the membership will be issued as and when there is sufficient certainty as to the effective launch of the TLD(s). Given the diversity of CORE's membership, the association has access to a large pool of professionals.

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.

The expected term has not yet been specified in the Memorandum of Understanding.

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

Exact breakdowns are dependant on the mechanisms retained by the Sponsoring Organization and on economies of scale possible through the management of other TLDs by the Registry operator.

While the initial costs are not expected to be a function of volume, running costs allow for adjustments based on the volume experienced.

In case of insufficient funding, the members can assess themselves monthly membership dues.

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.

While the revenue cannot be measured at this stage, in the absence of final policy, CORE will operate on a cost-recovery basis. Receipts in excess of a commission based on CORE's own cost-recovery and reasonable investments will be transferred to the Sponsoring Organization.

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.

CORE expects to be able to fund the TLD launch with existing funds and members contributions from existing and new members. The member dues mechanism is based on a minimum cumulated contribution level per member. All members are treated equally.

The members of CORE have used this mechanism since 1998. The mechanism has worked well despite the difficulties and uncertainties to which the association was subject during almost three years. It is reasonable to assume that once the launch of a new TLD is placed under the responsibility of the association, the peer funding mechanism will work even more smoothly.

The member contributions are credited for future registrations when the financial situation of the registry allows it. As soon as registry funding levels are adequate, members are allowed to run down their contribution level within the limits decided by the membership (see D13.2.12).

Once the required level of cumulated contributions per member has been reduced, the association can reduce the price per registration. All members will always pay the same price irrespective of volumes. The pricing is set in a fashion to ensure sufficient coverage of risks and future costs based on the contractual duration of registrations.

D13.2.14. Business risks and opportunities.

Describe upside and downside contingencies you have considered and discuss your plans for addressing them

The principal risks associated with TLD projects are unexpected delays at unexpected times. CORE's members can regard themselves as well placed to understand this risk. An additional risk is constituted by erratic registration volume that could be the result of unexpected regulatory issues.

As a not-for-profit membership association, the CORE registry has no special use for business opportunities in its own right. Its purpose is to discharge its duties in an orderly fashion on a cost-recovery basis. However, the current and members of the association, their customers and the public at large have everything to gain from a TLD managed in the public trust and lower registration prices as volumes grow. It is important to point out in this context that CORE is an open association based on non-discriminatory membership criteria.

An additional opportunity for members lies in their ability to co-operate in technical standards while competing in other areas. The shared registry facilitates this productive form of co-competition.

D13.2.15. Registry failure provisions.

Please describe in detail your plans for dealing with the possibility of registry failure.

CORE's plans for the registry failure scenario involve a series of safety nets related to integrity, availability and confidentiality of registration data.

(a) Contractual stipulations at all levels allow for the replacement of the registry in case of failure, but place the same obligations towards domain holders and third parties on the successor organization.

(b) Contracts with infrastructure operators (housing, connectivity providers) contain the obligation to maintain service in case of registry failure for at least 6 months or until a replacing organization can be found. This applies in particular to the TLD server housing providers.

(c) The registry data is backed up and stored at an independent escrow services provider on a daily basis. ICANN or an independent auditor of its choice is enabled to verify the data escrow at any time.

(d) A back-up system is run at a neutral CORE member's site and maintained up-to-date using data synchronization tools.

(e) The regulations of the association allow members to assess themselves contributions to be available for contingencies. Coming from members, they can be made available directly to interim service providers if need be. The amount provided per member can be computed on a "per domain maintained" basis.

(f) The registry operator keeps adequate reserves per domain. CORE is ready to work with ICANN on the concept of a financial escrow arrangement whereby a reserve covering at least 6 months of operation in an emergency is put in escrow with and independent financial institution.

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.

Financial projections will be developed in accordance with the policies and selection mechanism put forward by the Sponsoring Organization.

D13.4. Supporting documentation.

The following documentation should be provided in support of the Business Capabilities and Plan section:

D13.4.1. Registry operator's organizational documents.

Documents of incorporation (or similar documents).

The following documents are attached:

CORE Articles of Association

CORE Rules

Copy of Geneva Company Register certificate

Baloise insurance confirmation

D13.4.2. References.

A list of significant trade and credit references.

See list of CORE members and point D13.4.4.

D13.4.3. Annual report.

The registry operator's most recent annual financial report (or similar document). Audited financials are preferred.

The following document are attached:

Audit report from KPGM of CORE's 1998 Financial statements based on Internationally Accepted Accounting Principles (IAS)

Audit report from KPGM of CORE's 1999 Financial statements based on Internationally Accepted Accounting Principles (IAS)

Audit report from KPGM of CORE's June 2000 Interim Financial statements based on Internationally Accepted Accounting Principles (IAS)

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.

UBS Bank Reference Letter

(CORE is customer of UBS since 1997 and holds funds in excess of USD 3,000,000)

D13.4.5. Proof of insurance.

Please provide proof of the insurance described in item D13.1.8.

The following document is attached:

Baloise Assurances Confirmation.

[D] III. TECHNICAL CAPABILITIES AND PLAN

D14. General

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

Note: the content of this section is reflects points not already covered under D13 and in the attached CORE SRS protocol specification 1.1.

D15. Introduction

The Technical Capabilities and Plan section should consist of at least the following:

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.

Technical workforce

The planned concept of hiring personnel and members seconding key experts is discussed under D13.2.

CORE has track record of successful developments in collaborative mode, personnel from various members working together. CORE Registrar SRS operation and maintenance and secretariat have been outsourced to two separate member companies.

It is important to point out that participating members also have extensive experience in shared systems from their own developments. Many member operate shared registration system concepts on their own facilities in order to collaborate with channel partners.

While distributed organizational concept will be maintained to the extent of which projects are posted for member participation, the CORE Registry is directly responsible for the operation of the main SRS site and the Secretariat. The CEO, the CTO and key technical experts are registry staff. Other technical staff members are expected to be seconded part-time or full-time from members. Some experts and consultants employed part-time will be able to work from remote locations.

Systems development tools

CORE’s SRS development concept is based on readily available systems development tool, many of which are in open source. CORE does not rely on proprietary development tools.

Outsourcing

The management of replicable resources such as additional Whois servers (see D13.2.1) and TLD servers are outsourced to members with appropriate resources. In all cases, the ability for CORE Registry to log into the server using secure protocols such as SSH is maintained. As documented under D12, CORE’ s membership particularly well suited for the task.

Significant past achievements

Significant past achievements with the framework of CORE itself are discussed under D12. CORE’s existing CORE SRS is used for over 800,000 domains handled under the responsibility of CORE members who compete against one another.

The existing system demonstrates the ability of CORE’s members to work together (working groups, task forces) despite geographical distances and across diverse types of members companies.

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:

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.

Concepts

Facilities and systems are discussed under D13.2.7 where type of hardware and software is mentioned. CORE has obtained pro forma quote from its member COLT telecom for housing of the main SRS system and connectivity. It is expected that the main Whois server and the primary TLD server will also be hosted and that location. The quote currently provided refers to hosting in Geneva, Switzerland, but alternative options will be analysed and discussed within CORE’s membership. COLT and other CORE members with major infrastructure operations have facilities in a large number of European cities. (See attached pro forma offer from COLT Telecom). Hosting includes secure power supply, surveillance. The Geneva hosting site in walking distance from the offices where most CORE staff currently are located.

All key systems have fully redundant disk and power supply properties. A backup system can replace the production system withy are located.

Thanks to the use of incremental Whois server updates, the load on the main system is limited to actual domain update transactions. Check queries typically account for over 95 percent of transaction load; this load can thus spread over a range of machine and locations.

Summary of system components

Main SRS site

The main SRS system is composed of a back-end machine holding the data and a front-end processor used to handle transaction with the member registrars and as a proxy firewall to insulate the backend. The entire complex is installed behind a packet filtering firewall. The front-end system communicates with the back-end system over a separate network interface in a separate network. The back-end system is linked to separate back-up units. CORE currently uses Informix as a database system. The capacity of the current database and hardware design scales has been tested with several million registrations; current production usage stands at over 800,000 domains.

Backup SRS site

The backup site has an identical configuration possibly with lower performance and availability features. The backup site is feed continuously with data and designed to be able to take over in an emergency within 24 hours.

Whois sites

Several Whois sites are operated on the main SRS site and on other locations (see above). Specialised low-payload queries are available for checking purposes.

TLD Server sites

TLD servers are run on at least 3, later 5 locations. The main SRS location is expected to be a TLD server location as well. A given location may host more than one TLD server. Capacity is adjusted based on the number of registration. This implies that the TLD server concept will be revised as the number of registrations grows.

It is important to point out that the key requirement for TLD servers is access to expert knowledge in managing them. The multiple TLD servers CORE has access in this context to the experience of CORE member with large zone files such as DENIC with over 3,000,000 domain in the .de zone. The members of the DENIC team participate in the Shared Secondary System project led by CENTR.

Current ICANN Root servers operate with a sustained throughput of about 2 Mega Bits per Second (Mb/sec.) of DNS traffic. CORE TLD servers will be deployed with at least a 2 Mb/sec sustained bandwidth available with a burstable bandwidth initially up to 10 Mb/sec. Understand that the largest Burst sustained for over one minute on a ICANN Root server to date is 12 Mb/sec.

CORE TLD Servers will follow specifications outlined in RFC2010.

CORE will make statistics on availability and performance available to ICANN for periodic review.

Secretariat site

The secretariat manages a sizeable Intranet specialized email and tracking tools. Experience with .com, .net and .com registrations has shown that secretariat costs ca be kept low thanks to specialized systems developed to increase productivity with interfaces to the main SRS system. The secretariat system is comparable to the SRS client systems run by members. The secretariat tools are developed on a continuous basis by the secretariat and member participating in related projects.

Test SRS site

A test SRS site is available to members on an ongoing basis for testing purposes. The technical concept of the test sites is identical to that of the production system but it is not necessarily loaded with the same data.

D15.2.2. Registry-registrar model and protocol.

Please describe in detail.

Registry-registrar model

The registry- registrar model is described under the heading “Operational Model” in the business plan section and in the registration policy.

Shared Registry Protocol

The version of the SRS Protocol CORE plans to use for the registry is described in the attached document “CORE SRS Protocol Specification 1.1”.

The CORE SRS protocol is based on PGP-signed messages exchanged between the SRS and the member registrar. The member registrar can use a stateless interaction client kit (SRSIO), which CORE provides in source code for Unix. SRSIO transparently handles a socket connection to the SRS and as well as the signing and the signature verification on the member registrar side. An API into the CORE Messaging system is under development.

An alternative transport method is email, the use of which must be specifically authorized for a given PGP signature. Email-based submissions are practical for occasional participants such as approval officers in charge of a given area.

Discussion of CORE SRS protocol choice, protocol convergence

The CORE SRS protocol has been developed by CORE members and continues to be further enhanced. CORE member have no religious preference for a given protocol, but would like to ensure that protocol convergence be a matter of consensus building with diverse inputs.

The current version of RRP protocol has not been retained because it requires higher transaction capacity of the central system only and works with a registry that does not manage contact and domain registrant information. Although RRP now available as an RFC, it is felt that it was developed without consensus building in a secretive environment.

CORE is ready to participate in constructive standards work, which can involve concepts developed by other existing registries, in particular ccTLD registries. Core supports calls for convergence of shared registry protocols but feels that this deserves to be a technical process and that the registrar constituency is a political, not a technical forum. CORE looks forward to participating in developing IETF standards for the robust Registry Registrar Protocols that can cover all types of TLD management systems.

CORE SRS History

The CORE shared registry model and philosophy date back to designs established in 1997 which in turn were partly inspired by established shared registries such as Denic (.de) and Nominet (.co.uk). An intermediary specification was published in the context of the IETF shared registry protocol BOF (CORE-DB) in 1998.

The SRS design process has always been multilateral and was formalised within CORE’s membership in the SRS working group. The SRS protocol has been the focus of extensive consensus-building process involving dozens of competitors who were able to agree on a common approach.

The first implementation of the CORE SRS was developed based on a call for proposals and contract assigned to Emergent Corporation in November 1997. The system was tested extensively by many CORE registrars during 1998. Members' feedback regarding the first implementation was the basis for the second implementation initiated in January 1999.

CORE is currently using the second implementation of the protocol, developed for CORE by CSL GmbH of Duesseldorf, Germany. The code was rewritten from the start and significant platform changes were made. The current system has been designed with Linux as target platform but can run on other Unix version as well. This version was adapted to become a registrar system. The current CORE Registrar system has been running for over one year assisting many organizations to participate in the sail and maintenance of nearly one million domains. CORE was a critical participant in the ICANN sponsored Testbed phase. CORE has played a constructive role in the Testbed phase with overcoming technical issues during the initial phase of implementing a Shared Registry in accordance with NSI/DoC and ICANN.

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.

Back End Database Concept

Philosophy

The database concept has been developed with the following requirements in mind:

Simplicity - the underlying database structure must be easy to understand.

Unencumbered portability - the database does not depend on proprietary technology and be ported from a given "commodity" type of database system to another.

Clear documentation of responsibilities - the registry database must show who is in charge of what.

Summary Database Schema

The database schema described here covers the tables used to store permanent data, i.e. the current domain, name host, holder and contact information, as well as the respective historic information. Additional tables not described here are used for processing and verification purposes and depend on the specific implementation of the SRS protocol.

Domain table

Used to hold information on the domain itself along with pointers to related tables. Key data elements are the domain name, the registrar in charge of administering the domain, the record creation and last modification date, the domain status (active, lock, hold) and the expiration date of the domain, as well as pointers to the associated contact record for admin contact, technical contact, zone contact, agent for contact and maintenance service provider (maintainer). The purpose of the maintainer pointer is to document the assignment of handling responsibility to resellers or registry members.

Holder table (Registrant)

For each domain there is a domain holder record. The holder data is kept on a separate table because the domain may change while the holder data is not modified; as a result, the holder record last modification date is only affected if indeed there were change to the holder record. (For instance, the change of a name host would affect the domain record, but it would not affect the holder record). The holder table has the same structure as the contact table, but contrary to the latter stands in a strict one-to-one relationship with the domain table. The holder of a given domain is the Registrant.

Contacts table

The contact table is separate from domain table because a given contact can be associated with many domains. For instance, a technical contact is often an employee or role of a service provider and therefore presents in a large number of domain registrations. This is also true for personal domains where an “agent for contact” is specified who may be a different from the domain holder. The contacts are linked to the domain records based on the respective role or quality of the contact. A given contact may be liked to many domains in several qualities at the same time.

Name server or hosts table

A given domain name can be linked to several name server host records. The link between a domain and a name host is based on the name host record identifier, so that it is possible to change the name or the IP number of all domains attached to the same name host record.

There will not be any GLUE generated for hosts not under a SLD with in the zone as specified in RFC2181.

Historic data tables

Historic tables for all the above maintain earlier states of the respective records.

Size, throughput, scalability

The SRS has been tested with the current configuration at sustained rates of one database update transaction per second involving multiple tables. The system has a built-in queuing mechanism in all internal stages where bottlenecks can appear. As a result, the system can take accept burst load of up to 5 transactions per second in its input queue and process them as capacity becomes available.

It is important to note in this context that the CORE Registry is a "full" or "thick" registry where the contact and registrant data is maintained with the domain and name server data. This feature eliminates the problems associated with Registrar to maintaining a separate Whois data in fracture under widely diverging standards. The advantage to the Registrar, ICANN and the public is that there will not separate Whois Escrow implications for registrars participating with the CORE Registry. Should a CORE Registrar become insolvent, there is no need to reconstitute the registrant´s data as all the data elements are contained in a single registry.

Protocol specificities and the concept of a “thick” registry skew comparative transactional capacity statistics. Transactions in the sense of the CORE SRS and the NSI RRP 1.1.0 are not comparable. The CORE system is designed to handle all data whereas the RRP currently only handles domain name strings and name servers. Current RRP volume statistics are inflated by orders of magnitude through the inclusion of check transactions, which go directly on the RRP interface. (A check transaction a request to verify if a domain is available.) CORE's uses Whois servers (which can easily be multiplied) for these verifications. Even if the Whois server is 30 or 60 seconds behind the back end database, this does not materially increase the likelihood of collisions. Experience shows that the number or requests on the CORE SRS is rather in the same order of magnitude as the number of domains and contacts registered. By contrast, current RRP statistics show for a single day a number of transactions higher than the total number of domain s registered since inception.

The current database concept is expected scale as for tens of million domain records. Additional tuning may be required as the database moves into new orders of magnitude. Since the CORE SRS is based on queuing and distributed computing based on inexpensive Intel hardware, additional equipment can be added to create clustered highly robust path to additional system resources should the need arise. As the TLDs grow in size, additional equipment can be installed to manage the load and availability requirements of increased TLD growth or additional Sponsoring Organizations.

Procedures for object creation, modification and deletion

All database records are created, modified and deleted through request issued and signed by members. Each request contains a template. Usually a given request us used to create, modify or delete a single record.

The details are described in the SRS protocol Specification 1.1 (attached)

Registrar Transfer Procedures

See Registration Policy Description and SRS Protocol Specification 1.1.

Grace Periods

Where applicable, similar grace period concepts are used as currently in the case of the .com, .net and org, except that, within the constraints of ICANN policies and prescriptions by an outside Sponsoring Organization, members can decide how they want them implemented and can obtain a change in policy. In particular, the issue of large-scale credit card fraud has been raised. In these cases, the registry will define a policy for investigation and refund if a certain amount is involved in a single case.

Change notification mechanism

Change notification mechanisms are based on the principle that key contact data is in the registry and that in some cases the registry can enhance security and confidence by sending automatic messages in case of changes or other sensitive transactions. This process does not relieve the members of their obligations to manage the interactions with customers.

Reporting capabilities

Statistical and data dump processes run automatically at regular intervals (daily, weekly, and monthly). The reporting times are based on UTC and do not change with daylight savings time.

Given their backgrounds, member registrars are in a good position to analyse their own data. To facilitate checking, the registry makes data dump files available to the members can ensure that their systems are in synchrony.

The registry provides statistical data on an equal treatment basis. The members decide jointly what data they wish to be made available to all members and to the public.

If there is an outside sponsoring organization, it has access to detailed statistical data.

The registry can generate the following reports.

Registration Reports, new domains, name servers, contacts.

Registrar Account Reports include information on account balances, money transfers, accounting and financial auditing for Sponsoring Organizations.

Domain, Host, and IP Address reports for each registrar. This report describes all objects owned by each registrar within the backend system.

Query reports for Whois servers, including what hosts submitted how many queries. Notifications of server availability, query rate and location of query origin.

Name Server statistics. Nam Server Query Rate (queries per second) Bandwidth utilization.

Server accounting statistics, system load resource utilization.

Backup and Dump reports. Date/Time of backup, records in each table or database.

Security notifications and System Denial of Service detection logs.

D15.2.4. Zone file generation.

Procedures for changes, editing by registrars, updates. Address frequency, security, process, interface, user authentication, logging, data back-up.

Frequency

CORE’s plans are to use 12-hourly batch zone file generation in the initial phase. Depending on the progress made in co-operation with other registries for incremental zone file handling, CORE may switch over to this method after a period of extensive testing.

Verification

The zone file is checked for consistency and size. Each zone file is ensured to be within a tolerance for size and correctness, beginning SOA and ending markers. A MD5 hash is generated for each zone and distributed along with the zone to the TLD Server by a secure automated process. Each TLD Server checks the transmitted file against the MD5 hash to ensure the file was transmitted correctly. Operators are notified if a transfer is not completed successfully.

Interface, User authentication

Registry Operator can access all TLD servers using a secure protocol. TLD operator can access server as well, but each machine is configured for unmanned operation. TLD Servers will follow the specifications for Operational Criteria for Root Name Servers defined in RFC2010.

Back-up

TLD server operators keep old files for 7 days plus one file per week for an extended period.

D15.2.5. Zone file distribution and publication.

Locations of name-servers, procedures for and means of distributing zone files, Zone files to them

Transfer after verification

Name servers will be located at major peering points throughout the Internet. Servers will be located on secure premises.

Name Servers will run the BIND name server as it is widely available in source and runs on many platforms. This is the most actively developed name server software.

Name Servers will have UDP checksums when generating and sending UDP datagrams.

All Name Servers will be dedicated hosts, not having any other dedicated function such as SMTP, NNTP, etc. All logins other than the console will be over encrypted channel such as SSH.

System clocks will be synchronized via the current version of NTP with authentication. At least 2 NTP peers will be used.

The Name Server will be located in a locked secure data center with restricted access. The power supply will be redundant, Network connectivity will be redundant and System power will be available via UPS.

Network administrators will make them selves aware of CERT advisories and the server will undergo periodical security audits. All name servers will use a C2 secure operating system with system auditing enabled.

Zone transfer access control will be configured so that outbound zone transfers are only permitted to destinations on the servers´ local network and to networks defined by the operators for debugging purposes.

The AXFR protocol will be used to in preference to FTP for zone file distribution. The NOTIFY and IXFR capabilities will be enabled on all Name Servers.

Recursion will be disabled for queries.

Interface, User authentication

Registry Operator can access all TLD servers using a secure protocol. TLD operator can access server as well, but each machine is configured for unmanned operation

Implicit Back-up

TLD servers automatically maintain old zone files for at least 7 days.

D15.2.6. Billing and collection systems.

Technical characteristics, system security, accessibility.

Registrar prepayment mechanism

The CORE Registry operates with a prepayment system analogous to the current cash prepayment mechanism used for .com, .net and .org. Registrars wire the funds to the registry bank account based on their expected registration volumes.

Each Registrar must maintain an account in good standing. Each Account within the back end system is debited once for each domain/year registered. A delete within the specified grace period will credit the registrars account for the number of domain years related to the registration.

The Registry Operator provides a management interface to Sponsoring Organizations for managing accounts within the backend registry database. This interface is implemented over a secure interface and is implement using the CORE SRS protocol.

All Registrars may inspect their account in real time by issuing protocol level requests or via a Secure Web interface provided by the Registry Operator.

For reliability purposes and to ease members’ cash management, CORE work with financial institutions to either offer the ability to use accounts at several locations with various financial institutions. Members are encouraged to used unique amounts to facilitate tracking of the payments (currently most CORE members wire amounts where the rightmost digits indicate the member number and serial digit used to make sure each amount is different).

The registry secretariat verifies the amounts received over its electronic banking link and credits the amount actually received on the SRS account (referred to as Registrar Credit Units account or RCU account). RCUs are currently equated to one dollar.

As and when credits are used for registrations or other charged-for transactions, the SRS automatically calculates the remaining balance of the RCU account. Conversely, deletions within grace period or the refunds cause the member RCU account to be credited. All transactions are logged.

Monthly statements and cross-verification

At the end of the month, the secretariat enters the global SRS-generated changes to the RCU account into the separate accounting system. All other transactions (bank account entries) are recorded immediately. Members receive a statement indicating their start and ending balances as well as debit and credit summaries.

The RCU balance and the balance of the Registry accounting system are cross-verified per month end. To increase transparency, all figures are based on UTC (GMT) time.

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.

Standard backup procedures

The main SRS is backed up daily on tapes kept for various duration. Once month, a tape is generated for long-term (10 year or more) conservation. As and when feasible, this mechanism will be ported to DVD or similar other high-density long-term media. These backups contain the history tables showing earlier states of modified records. Additional protocol-level audit trail log files are also kept.

The standard backup data is stored on an Rsync server where it can be accessed a encrypted SSH link. This can be used by the secretariat to crate additional backup copies.

Real-time remote logging messages

In order to cover the transactions that could be missed between two daily backup procedures, the main SRS site sends log messages to a local repository and to the back-up site. This mechanism is similar to that use to update whois servers.

Data Escrow

The Registry Whois will be escrowed with an ICANN accredited Escrow company using the XML format specified by the ICANN Escrow committee. CORE has obtained a pro-forma offer from Adhersis, a French data storage provider. The Frequency of Escrow will be one per week. The Registry will also make available, to ICANN, additional statistics about registrations so that the escrowed files can be checked for integrity.

Real-time remote logging on back-up srs site

A second Slave database is maintained off-site for real-time backup and archival purposes.

Daily backup within master site

The master database creates backups on tape. The tapes are stored in a Data-Safe style fireproof vault off site.

D15.2.8. Publicly accessible look up/Whois service.

Address software and hardware, connection speed, search capabilities, coordination with other Whois systems, etc.

As is the already the case on the CORE system, the whois service is updated at most 30 seconds after the SRS backend. This is achieved through messages send by the SRS backend via the front-end proxy to the whois server (see D13.2.7 and D15.2.1)

For registry operations, CORE Registry will use at least three Whois servers, one of which is co-located with the main SRS site, two major hosting providers who are also CORE members operate the other two.

The Whois database is implemented on a distributed database system. The service is updated continually as new registrations come in. The hardware is separated from the main registry network by a firewall.

The load on the whois servers is distributed across several systems by the use of a NAT and Firewall and Load Balancing system. The servers are located in a secure facility and adhere to operating system requirements much like those for Name Servers.

The whois service has a limiting device so that denial of service attacks and data mining operations can be defeated.

The whois database can be extended for Sponsoring Organizations, which could allow searching on additional fields such as VAT/EIN or registration number. The Whois system will be compliant with current ICANN policies and procedures.

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.

Security experts and audit

CORE will work on a regular basis with internal and external security specialists so as to ensure the system design remains in line with growing needs and newly discovered security issues in operating systems or other standard software components. The experts regularly review the SRS architecture.

Physical security

The physical access to the main site is protected through the housing service provider and camera surveillance. The systems are located in a closed rack with secure power supply and high-speed connectivity. (See pro forma quote from CORE member COLT Telecom.). Only CORE personnel have access to the closed rack.

Technical security

As discussed under D15.2.1, the SRS backend is protected through the front-end functioning as a proxy firewall, as well as a packet filtering firewall installed between the upstream connection and the entire system. The packet filtering firewall rejects all connections not specifically allowed. The front-end acts as a proxy firewall and, at the same time, takes communications-related processing load off the back-end.

Remote login into the back-end is limited to times when this feature has been activated temporarily by physical on-site intervention. It is achieved through proxies secure sessions via the front-end machine. The cryptographic keys used for such access are specific to the expert enabled to access the system.

Data integrity

The change history audit trail enables verification if changes to the database were performed through the SRS engine itself, or if data was tampered with. The verification of the data integrity can be performed on the backup site.

Confidentiality

Bulk data transfers toward the outside can be executed over secure links or in encrypted form, as the specific transaction may require. The SRS does not store any financial information such as credit card numbers. The SRS protocol technically allows for the use of PGP encryption in incoming data. The degree to which encryption is used in incoming transactions depends on the on the degree of confidentiality.

Availability

The front-end machine are can be duplicated to achieve increased performance and redundancy. The back-end has high availability and redundancy features in line with its role. The different stages of the registration process and other tasks are interconnected by queues. Failure of one component or process does not generally cause any harm, but can slow down the overall performance.

Physical environment.

All server hosts will be located in a secure space such as a locked computer room or a data canter with restricted access. The power supplies are redundant, using batteries, generators or other means to protect against utility power failures. Network connectivity is redundant, so that a single wide area line failure cannot completely isolate the equipment from the rest of the network.

Network security

The system and network administrators will educate themselves about potential threats, and stay current on CERT bulletins regarding network break-ins. The system staff will periodically audit the server host's activity logs and be able to detect attempted break-ins during and after the fact.

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.

Benchmark reference data

As discussed under D15.2.3, the system has been designed for sustained load of one complex update transaction per second. Check queries are directed to separate whois servers where load can easily be spread over several machines. Any comparison with current data shown in the context of .com, .net and .org must take into account that NSI shows check queries as part of the SRS load although it can be handled via separate servers, and that the NSI registry whois service lags 24 hours behind the database. Check queries can easily represent 99% of all transactional volume.

Moreover, CORE’s organizational model allows it to use incentive-disincentive based load management to ensure considerate and economical use of central resources by members.

To maintain high performance of Whois servers, CORE plans to use restrictions affecting repetitive queries from the same source. Volume users of the CORE whois (e.g. whois portals) need to be identified and specifically authorised. Portals exceeding a certain volume will have to indicate their requestor IP number for each query.

D15.2.11. System reliability.

Define, analyze, and quantify quality of service.

Availability targets

The target availability parameters are set in consideration of relative cost and volume and nature of service provided. Whenever possible, multiple redundant resources are used.

SRS Site

The SRS itself is not for direct use by the public. Member registrars need to be able to determine the amount of money they are willing to spend for the level of availability in time (95%, 99% or 99.9%). Members’ own systems should be designed to accommodate minor outages or slow response times.

Whois servers

The CORE registry will operate with multiple whois servers updated within seconds. While in isolated cases a given domain may be affected by synchronization problems and not show in the whois, the overall whois service can achieve almost uninterrupted availability (barring concerted, large-scale denial-of-service attacks and unexpected surges in demand). If a given whois server is down, users can normally go on another machine. Whois gateway machines run by members can perform the switch automatically if need be. See D15.2.8.

TLD servers

As there will be at least five TLD servers, zero downtime can be achieved as far as the TLD name service is concerned. While high-availability machines are used, the prime quality effort made for an individual server is data integrity and consistency. The measures to protect the integrity are discussed under D15.2.4. and D15.2.5.

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.

See D15.2.1 and subsequent paragraphs.

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.

Recovery procedures on the main site

In case of failure of a redundant system component (e.g. an individual RAID Disk), the system may made unavailable for the time needed to replace the component even if technically it could continue to operate. System managers may decide to create separate back-ups to capture to exact state of the machine before proceeding. The duration of this type of interruption would not exceed two hours.

In case of failure of a non-redundant components (e.g. a RAID controller), the recovery from backup systems and continuous logs may take up to 8 hours. The main SRS team runs regular fire drills in recovering data from the backup systems to a test system.

Backup SRS site

The SRS backup site is designed to be able to take over of operation at the latest in case the main SRS is affected. Although data is transferred continuously to SRS backup site, a decision to switch will not be taken lightly. The main priority for the SRS site management is to eliminate all and any risk of sending wrong data to the TLD servers. This objective takes precedence over mere issues of comfort, such as the ability to register a new domain immediately or change a name server for the next TLD zone file distribution.

While the technical switch over to the backup site can be performed within hours, the decision to switch will only be taken with at least a day advance notice.

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.

Support to users

Registrars who compete with respect to service level and price perform support to users. The CORE Registry Secretariat will redirect inquiries to the respective maintaining member if inquiries are received by email or by telephone. The CORE Registry web site is used to offer neutral information such as member lists and frequently asked questions.

The agreements signed by registrars define their minimum support responsibilities towards customers.

Support to members

The SRS team and the Secretariat support members via email, telephone and via SRS transactions. The Secretariat can interact with members in English, French, German and Spanish; other languages may be added in the future.

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.

It is not expected that any function accounting to more than 10% would be outsourced to a single operator.

The allocation of outsourced is based on due process within the membership. While a series of members have indicated readiness to handle functions and have provided offers therefore, no definitive assignments have been made.

[D] Signature

By signing this Registry Operator's Proposal, the undersigned certifies (a) that he or she has authority to do so on behalf of the registry operator and, on his or her own behalf and on behalf of the registry operator, (b) that all information contained in this proposal, and all documents attached to this proposal, is true and accurate to the best of his/her/its knowledge and information. The undersigned and the registry operator understand that any material misstatement or misrepresentation will reflect negatively on any application of which this proposal is a part and may cause cancellation of any delegation of a top-level domain based on such an application.

_______________________________
Signature

Werner Staub

Name (please print)

Head of CORE Secretariat

Title

CORE Internet Council of Registrars

Name of Registry Operator

September 30, 2000

Date

Table of Contents

[D] Registry Operator's Proposal

[D] I. GENERAL INFORMATION

D1. Introduction

D2. Name and address

D3. Other Business Locations

D4. Type of Entity

D5. URL

D6. Identifier

D7. Number of Employees

D8. Revenue

CORE Registrar Revenue

Membership contributions

D9. Directors, Officers

(i) Directors (CORE Executive Committee)

(ii) Officers

(iii) Managers

(iv) (No ownership links)

D10. Person for this Proposal

D11. Subcontractors Listing

[D] II. BUSINESS CAPABILITIES AND PLAN

D12. Executive Summary

Resources available within CORE's Membership

Demonstrated Shared Registry Capabilities

Separation of CORE Registry and CORE Registrar

Enhancement of Existing CORE SRS and Protocol for new Registry Requirements

Learning from the .com experience

Commitment to protocol convergence

Organizational concept

Central functions managed by CORE Staff

Redundancy through outsourcing and geographic distribution

Competition between members in customer-related activities and value-added services

Financial process

Technical process

D13. Business Plan for the .health TLD

D13.1. Detailed description of the registry operator's capabilities.

D13.1.1. Company information.

Date of Formation

Legal Status

Primary Location

Membership

(Formal Alliances)

Competition between members

Organizational Structure

No ownership, equal voting power of members

D13.1.2. Current business operations.

ICANN-accredited Registrar

Shared Registry System Development

Fully distributed business model

Shared Registration System based on Registry Model

Registrations in new generic TLD

D13.1.3. Past business operations/entity history.

History of CORE

The IAHC process preceding the launch of CORE

Development of a scalable shared registry system

Extensive participation in ICANN process

Second implementation of CORE SRS adapted to function as registrar system

Duration of provision of services

D13.1.4. Registry/database/Internet related experience and activities

Experience with shared registry database management

Experience with .com/.net/.org shared registry

Internet-related experience and know-how available within membership

D13.1.5. Mission.

D13.1.6. Management.

D13.1.7. Staff/employees.

Current resources

Staff for registry activities

CTO and CEO

D13.1.8. Commercial general liability insurance.

D13.2. Business plan for the proposed registry operations.

Introduction

Operational Model

Membership status needed to perform registrations, financial aspects

Possible additional requirements

Trust model and disciplinary framework

Presumption of trust in registrar

User authentication by registrar

Ability to pre-screen registrations and changes

Relationship with ICANN accreditation concept

D13.2.1. Services to be provided