Table of Contents 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 *

11. 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 .museum 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 * Information registration and update services * Types of information stored by the registry * Information provision services * Information to the end-user provided via the registrar *

Cross-verification mechanisms *

Whois service *

Third parties with legitimate interests *

Registrar transfer capability * Domain portability and supervisory framework for orderly competition * Registration and modification pre-screening framework available *

Complaint administration framework available (self-policing) *

D13.2.2. Revenue model. * Ability to run TLD-specific revenue models * Outside Sponsoring Organization * Revenue model for the .museum TLD * Charge per domain-year to the registrar *

Disincentive and special cost recovery charges *

D13.2.3. Market. *

D13.2.4. Marketing plan. *

Marketing by competing registrars *

Awareness programs and neutral information *

D13.2.5. Estimated demand for registry services in the new TLD. *

D13.2.6. Resources required to meet demand. *

Resources for .museum registry operations * Financial *

Technical *

Staff *

D13.2.7. Plans for acquiring necessary systems and facilities. *

D13.2.8. Staff size/expansion capability. *

D13.2.9. Availability of additional management personnel. *

D13.2.10. Term of registry agreement. *

D13.2.11. Expected costs associated with the operation of the proposed registry. *

D13.2.12. Expected revenue associated with the operation of the proposed registry. *

D13.2.13. Capital requirements. *

D13.2.14. Business risks and opportunities. *

D13.2.15. Registry failure provisions. *

D13.3. Pro-forma financial projections. *

D13.4. Supporting documentation. *

D13.4.1. Registry operator's organizational documents. *

D13.4.2. References. *

D13.4.3. Annual report. *

D13.4.4. Proof of capital. *

D13.4.5. Proof of insurance. *

[D] III. TECHNICAL CAPABILITIES AND PLAN * D14. General *

D15. Introduction *

D15.1. Detailed description of the registry operator's technical capabilities. *

Technical workforce *

Systems development tools *

Outsourcing *

Significant past achievements *

D15.2. Technical plan for the proposed registry operations. *

D15.2.1. General description of proposed facilities and systems. *

Concepts *

Summary of system components *

Main SRS site * Backup SRS site *

Whois sites *

TLD Server sites *

Secretariat site *

Test SRS site *

D15.2.2. Registry-registrar model and protocol. * Registry-registrar model *

Shared Registry Protocol *

Discussion of CORE SRS protocol choice, protocol convergence *

CORE SRS History *

D15.2.3. Database capabilities. * Back End Database Concept * Philosophy *

Summary Database Schema *

Size, throughput, scalability *

Procedures for object creation, modification and deletion *

Registrar Transfer Procedures *

Grace Periods *

Change notification mechanism *

Reporting capabilities *

D15.2.4. Zone file generation. * Frequency *

Verification *

Interface, User authentication *

Back-up *

D15.2.5. Zone file distribution and publication. * Transfer after verification *

Interface, User authentication *

Implicit Back-up *

D15.2.6. Billing and collection systems. * Registrar prepayment mechanism *

Monthly statements and cross-verification *

D15.2.7. Data escrow and backup. * Standard backup procedures *

Real-time remote logging messages *

Data Escrow *

Real-time remote logging on back-up srs site *

Daily backup within master site *

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

D15.2.9. System security. *

Security experts and audit *

Physical security *

Technical security *

Data integrity *

Confidentiality *

Availability *

Physical environment. *

Network security *

D15.2.10. Peak capacities. * Benchmark reference data * D15.2.11. System reliability. * Availability targets *

SRS Site *

Whois servers *

TLD servers *

D15.2.12. System outage prevention. *

D15.2.13. System recovery procedures. *

Recovery procedures on the main site *

Backup SRS site *

D15.2.14. Technical and other support. * Support to users *

Support to members *

D15.3 Subcontractors. *
[D] Signature *
 
 

[D] Registry Operator's 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. As stated in response to question C17, the Museum Domain Management Association ("MDMA"" and "Applicant") intends to secure its registry operator services for the .museum TLD from CORE Internet Council of Registrars ("CORE"). MDMA and CORE have entered into a Memorandum of Understanding ("MOU") for this purpose; a copy of the MOU that contains the material terms and conditions of the contractual relationship between the MDMA and CORE is included in response to question C18.2.

CORE is submitting an application to ICANN in this proceeding as a Sponsoring Organization for the .nom TLD and as a Registry Operator. CORE is submitting a detailed Section D as part of its .nom TLD Application. The MDMA believes that the information contained in CORE’s responses to the Section D questions in the .nom TLD Application will provide very detailed information to ICANN about its abilities to provide the registry operator services for the ..museum TLD.

MDMA’s responses contained herein may direct ICANN and interested participants in this process to additional information that may be found in CORE’s responses to questions in Section D of the .nom TLD Application, submitted to ICANN under separate cover.

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 Committee

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) International Council of Museums:

Cary Karp, Director

Department of Information Technology

Swedish Museum of Natural History

Svante Arrheniusv. 3

Box 50007

104 05 Stockholm

Sweden

Email: ck@nrm.se

Phone: +46 8 5195 4055

Fax: +46 8 5195 4235

2) J. Paul Getty Museum:

Kenneth Hamma, Assistant Director

The J. Paul Getty Museum

1200 Getty Center Drive

Suite 1000

Los Angeles, CA 90049-1687

Email: khamma@getty.edu

Phone: 310-440-7186

Fax: 310-440-7752
 
 

Please contact either or both of these individuals and they, in turn, will contact the appropriate individuals at CORE.
 
 

11. 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 professional assistance from financial and management consultants to aid in the formulation of your business plan, in securing the necessary sources of financing, and in preparation of this section.]
 
 
Resources available within CORE's Membership CORE is an open association of companies who are fundamentally concerned with domain names and have created a coordinating 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 .museum 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 COLTTelecom 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 1997for 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 wasdue 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 registrarsshare 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 .museum TLD, the registrar has to sign the policy document and be approved by the MDMA. The MDAM approval concept and the related registry access privileges may be differentiated by type of operation Additional information on MDMA’s policy on registration are found in section E of this proposal .

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

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 MDMA, 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 MDMA approves it.

If pre-screening is used and administered through the MDMA, 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 may be provided in interaction with specific bodies designated by the MDMA (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 MDMA 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 betweenregistrars 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 MDMA. 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 MDMA 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 MDMA revenue model.

The registry-level revenue model is based on cost recovery whereas the MDMA will define its own model based on its own role and process.

MDMA 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

MDMA-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 MDMA. 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 MDMA’s screening framework rejects the registration. (This principle encourages the submission of well-formed and carefully prepared applications). At regular intervals, the MDMA's portion of registration fees is wired to the MDMA.

MDMA-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 .museum TLD Charge per domain-year to the registrar

The charge to the registrar would include the cost-recovery for the Registry operator and the MDMA, 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 forre-authentication, for complaint registration or for trademark protection requests (exclusion mechanism).

D13.2.3. Market. Market definition, size, demand, and accessibility. Market issues for .museum are further discussed in other sections of this Application. 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. Demand for registration in the .museum TLD is expected to be strong, but because it is a restricted domain, no larger than the total number of the world’s museums and related professional organizations. Thus it is extremely unlikely that the eventual total number of registrations in the TLD will reach 100,000. At the same time it is likely that the number of registrations will reach a relatively steady state within five years.
In this restricted domain registration fees set within a reasonable range will almost no effect on the volume of registrations. The MDMA’s policy toward registration fees will permit free competition among registrars and will encourage the lowest possible barrier to registration even for the most financially constrained museum. 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 .museum registry operations 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 .museum 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 .museum) 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 expandedtechnical, 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 MDMA 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 MDMA. 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 responsibilityof 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 MDMA. 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 operatoran 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 systemhas 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:

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 the MDMA, 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.

MDMA has access to detailed statistical data.

The registry can generate the following reports.

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 restrictedaccess. 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 MDMA 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 useto 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 againstutility 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:

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