Table of Contents

Table of Contents 

[D] Registry Operator's Proposal                                                                            1

[D] I. GENERAL INFORMATION                                                                                                                                                 1

D1. Introduction                                                                                                                                                                           1

Relationship of .nom with CORE                                                                                                                                          1

CORE Registry operator vs CORE Registrar                                                                                                                 2

D2. Name and address                                                                                                                                                                 2

D3. Other Business Locations                                                                                                                                                   3

D4. Type of Entity                                                                                                                                                                        3

D5. URL                                                                                                                                                                                         3

D6. Identifier                                                                                                                                                                                 3

D7. Number of Employees                                                                                                                                                          3

D8. Revenue                                                                                                                                                                                  4

CORE Registrar Revenue                                                                                                                                                       4

Membership contributions                                                                                                                                                    4

D9. Directors, Officers                                                                                                                                                                 4

(i) Directors (CORE Executive Committee)                                                                                                                     4

(ii) Officers                                                                                                                                                                          5

(iii) Managers                                                                                                                                                                     5

(iv) (No ownership links)                                                                                                                                                  5

Interim Executive Committee for Registry Operator                                                                                                     5

D10. Person for this Proposal                                                                                                                                                     5

D11. Subcontractors Listing                                                                                                                                                       6

[D] II. BUSINESS CAPABILITIES AND PLAN                                                                                                                         6

D12. Executive Summary                                                                                                                                                             6

Resources available within CORE's Membership                                                                                                              6

Demonstrated Shared Registry Capabilities                                                                                                                       7

Separation of CORE Registry and CORE Registrar                                                                                                           7

Enhancement of Existing CORE SRS and Protocol for new Registry Requirements                                                    7

Learning from the .com experience                                                                                                                                 7

Commitment to protocol convergence                                                                                                                           8

Organisational concept                                                                                                                                                          8

Central functions managed by CORE Staff                                                                                                                   8

Redundancy through outsourcing and geographic distribution                                                                               8

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

Financial process                                                                                                                                                               8

Technical process                                                                                                                                                             9

D13. Business Plan for the .nom TLD                                                                                                                                       9

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

D13.1.1. Company information.                                                                                                                                             9

Date of Formation                                                                                                                                                              9

Legal Status                                                                                                                                                                      10

Primary Location                                                                                                                                                              10

Membership                                                                                                                                                                     10

(Formal Alliances)                                                                                                                                                           12

Competition between members                                                                                                                                     12

Organisational Structure                                                                                                                                                12

No ownership, equal voting power of members                                                                                                         12

D13.1.2. Current business operations.                                                                                                                               12

ICANN-accredited Registrar                                                                                                                                          12

Shared Registry System Development                                                                                                                         12

Fully distributed business model                                                                                                                                  13

Shared Registration System based on Registry Model                                                                                             13

Registrations in new generic TLD                                                                                                                                13

D13.1.3. Past business operations/entity history.                                                                                                           13

History of CORE                                                                                                                                                              13

The IAHC process preceding the launch of CORE                                                                                              13

Development of a scalable shared registry system                                                                                              14

Extensive participation in ICANN process                                                                                                                  14

Second implementation of CORE SRS adapted to function as registrar system                                                   14

Duration of provision of services                                                                                                                                 15

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

Experience with shared registry database management                                                                                            15

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

Internet-related experience and know-how available within membership                                                              16

D13.1.5. Mission.                                                                                                                                                                  16

D13.1.6. Management.                                                                                                                                                          16

D13.1.7. Staff/employees.                                                                                                                                                    17

Current resources                                                                                                                                                            17

Staff for registry activities                                                                                                                                              17

CTO and CEO                                                                                                                                                                   17

D13.1.8. Commercial general liability insurance.                                                                                                              17

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

Introduction                                                                                                                                                                           18

Operational Model                                                                                                                                                          18

Membership status needed to perform registrations, financial aspects                                                                 18

Possible additional requirements                                                                                                                                  18

Trust model and disciplinary framework                                                                                                                      19

Presumption of trust in registrar                                                                                                                              19

User authentication by registrar                                                                                                                              19

Ability to pre-screen registrations and changes                                                                                                        19

Relationship with ICANN accreditation concept                                                                                                       19

D13.2.1. Services to be provided                                                                                                                                        20

Information registration and update services                                                                                                             20

Types of information stored by the registry                                                                                                          20

Information provision services                                                                                                                                     20

Information to the end-user provided via the registrar                                                                                        21

Cross-verification mechanisms                                                                                                                                21

Whois service                                                                                                                                                             21

Third parties with legitimate interests                                                                                                                     21

Registrar transfer capability                                                                                                                                           22

Domain portability and supervisory framework for orderly competition                                                          22

Registration and modification pre-screening framework available                                                                          22

Complaint administration framework available (self-policing)                                                                                  22

D13.2.2. Revenue model.                                                                                                                                                      22

Ability to run TLD-specific revenue models                                                                                                               22

Outside Sponsoring Organisation                                                                                                                           23

Revenue model for the .nom TLD                                                                                                                                 23

Charge per domain-year to the registrar                                                                                                                 23

Maximum remaining duration                                                                                                                                   24

Disincentive and special cost recovery charges                                                                                                   24

D13.2.3. Market.                                                                                                                                                                    24

Market for .nom                                                                                                                                                               24

Potential sources of registrations                                                                                                                            24

Gradual growth of demand                                                                                                                                       25

Numbers of potentially interested users                                                                                                                25

Push by new applications and mobile telephony                                                                                                 25

D13.2.4. Marketing plan.                                                                                                                                                      25

Marketing by competing registrars                                                                                                                              26

Awareness programs and neutral information                                                                                                            26

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

Estimated demand for .nom TLD                                                                                                                                   26

D13.2.6. Resources required to meet demand.                                                                                                                  27

Resources for .nom                                                                                                                                                         27

Financial                                                                                                                                                                      27

Technical                                                                                                                                                                     27

Staff                                                                                                                                                                              28

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

D13.2.8. Staff size/expansion capability.                                                                                                                           28

D13.2.9. Availability of additional management personnel.                                                                                           29

D13.2.10. Term of registry agreement.                                                                                                                               29

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

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

D13.2.13. Capital requirements.                                                                                                                                           30

D13.2.14. Business risks and opportunities.                                                                                                                     31

D13.2.15. Registry failure provisions.                                                                                                                                31

D13.3. Pro-forma financial projections.                                                                                                                                   32

D13.4. Supporting documentation.                                                                                                                                          32

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

D13.4.2. References.                                                                                                                                                             32

D13.4.3. Annual report.                                                                                                                                                        33

D13.4.4. Proof of capital.                                                                                                                                                      33

D13.4.5. Proof of insurance.                                                                                                                                                33

[D] III. TECHNICAL CAPABILITIES AND PLAN                                                                                                                  33

D14. General                                                                                                                                                                                33

D15. Introduction                                                                                                                                                                       34

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

Technical workforce                                                                                                                                                        34

Systems development tools                                                                                                                                           34

Outsourcing                                                                                                                                                                     34

Significant past achievements                                                                                                                                       35

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

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

Concepts                                                                                                                                                                           35

Summary of system components                                                                                                                                  36

Main SRS site                                                                                                                                                             36

Backup SRS site                                                                                                                                                               36

Whois sites                                                                                                                                                                      36

TLD Server sites                                                                                                                                                              37

Secretariat site                                                                                                                                                                  37

Test SRS site                                                                                                                                                                    37

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

Registry-registrar model                                                                                                                                                 37

Shared Registry Protocol                                                                                                                                               38

Discussion of CORE SRS protocol choice, protocol convergence                                                                         38

CORE SRS History                                                                                                                                                          38

D15.2.3. Database capabilities.                                                                                                                                           39

Back End Database Concept                                                                                                                                         39

Philosophy                                                                                                                                                                  39

Summary Database Schema                                                                                                                                      39

Size, throughput, scalability                                                                                                                                     41

Procedures for object creation, modification and deletion                                                                                  41

Registrar Transfer Procedures                                                                                                                                 42

Grace Periods                                                                                                                                                              42

Change notification mechanism                                                                                                                               42

Reporting capabilities                                                                                                                                                42

D15.2.4. Zone file generation.                                                                                                                                             43

Frequency                                                                                                                                                                         43

Verification                                                                                                                                                                       43

Interface, User authentication                                                                                                                                       43

Back-up                                                                                                                                                                             43

D15.2.5. Zone file distribution and publication.                                                                                                               44

Transfer after verification                                                                                                                                               44

Interface, User authentication                                                                                                                                       44

Implicit Back-up                                                                                                                                                               44

D15.2.6. Billing and collection systems.                                                                                                                            45

Registrar prepayment mechanism                                                                                                                                 45

Monthly statements and cross-verification                                                                                                                45

D15.2.7. Data escrow and backup.                                                                                                                                     46

Standard backup procedures                                                                                                                                         46

Real-time remote logging messages                                                                                                                             46

Data Escrow                                                                                                                                                                     46

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

Daily backup within master site                                                                                                                                    46

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

D15.2.9. System security.                                                                                                                                                     47

Security experts and audit                                                                                                                                              47

Physical security                                                                                                                                                             47

Technical security                                                                                                                                                           48

Data integrity                                                                                                                                                                   48

Confidentiality                                                                                                                                                                 48

Availability                                                                                                                                                                       48

Physical environment.                                                                                                                                               48

Network security                                                                                                                                                        49

D15.2.10. Peak capacities.                                                                                                                                                    49

Benchmark reference data                                                                                                                                              49

D15.2.11. System reliability.                                                                                                                                                 49

Availability targets                                                                                                                                                    49

SRS Site                                                                                                                                                                       49

Whois servers                                                                                                                                                            50

TLD servers                                                                                                                                                                50

D15.2.12. System outage prevention.                                                                                                                                50

D15.2.13. System recovery procedures.                                                                                                                            50

Recovery procedures on the main site                                                                                                                         50

Backup SRS site                                                                                                                                                               51

D15.2.14. Technical and other support.                                                                                                                             51

Support to users                                                                                                                                                              51

Support to members                                                                                                                                                        51

D15.3 Subcontractors.                                                                                                                                                               51

[D] Signature                                                                                                                                                                                  53


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

Relationship of .nom with CORE

The idea of a .nom TLD was not originally brought forward by CORE itself: is was part of the set of seven TLDs specified by the IAHC, a multilateral committee set up in 1996 to look into the launch of new TLDs. The IAHC report was published in early 1997 [see http://www.iahc.org and the history of CORE under D13.1.3].

CORE is the result of an open and neutral process launched by the IAHC. Among other things, the IAHC report called for the creation of a ".nom" TLD for personal names. The word .nom, as it was pointed out by the IAHC at the time, was taken from French so as to extend the scope of proposed TLDs beyond English-language strings.

It is important to point out that neither the string .nom nor any other domain listed on CORE's original new domain list was chosen by CORE. The framework upon which CORE was built served the policy setting function to the independent Policy Oversight Committee (POC; the successor organisation of the IAHC) and defined the Policy Advisory Body (PAB) as policy recommendation forum. The members of these two bodies have contributed widely to the ICANN and DNSO processes which now server the purposes for which the POC and the PAB were originally created .

CORE Registry operator vs CORE Registrar

CORE's application as a registry operator is based on its original mission. However, as explained in the S.O Proposal, should CORE’s proposal be selected by ICANN, CORE’s understanding is that a mechanism shall be implemented to isolate the registrar function from the registry function. This is in CORE’s view required to ensure a fair and robust competition model, the registry being a natural monopoly and having sensible information about its customers (i.e.the registrars) should not be itself a registrar competing with registrars/customers.

For this purpose, CORE's intention is to split the current association into two separate associations (with different executive committees, secretariats, technical teams, etc.), each in charge of one of the two functions. The implementation of the split will be based on ICANN's criteria and require ratification by CORE's Plenary Meeting. This document is based on the hypothesis that the CORE Registrar function would remain under the existing contractual relationships between CORE and other parties (in particular domain name holders), whereas current members would create a new association to which registry-related assets and liabilities would be transferred. Nevertheless, it could be the other way round, or even CORE could abandon the registrar function altogether. As we have also explained in the S.O. Proposal, for the purposes of this document, the new association is referred to as CORE-II. Depending on technical, legal or other considerations it may be necessary to use a different mechanism with the same objectives.

Regarding members of CORE and CORE-II, we believe that ICANN should establish a gTLDs wide registrar accreditation program. In this case, these gTLDs accredited registrars would be the possible members of CORE-II.

Should ICANN not adopt such gTLDs wide registrar accreditation program, CORE-II initial members will be the current members of CORE wishing to join the new association. Immediately after, membership will be open to all those current .com/.org/.net ICANN accredited registrars wishing to join the new association. (The current registrar accreditation program is in many respects dependant on the so-called "NSI agreements", and contains terms, conditions and liabilities that have convinced many CORE members not to undertake the accreditation process. This is why in a situation where there is no gTLDs wide registrar accreditation process, CORE current members, even if not .com/.net/.org accredited, should be accepted as CORE-II members and registrars)

Also, in the assumption of lack of a gTLDs wide registrar accreditation program, CORE will accept in the future those third parties that meet objective, non-discriminatory criteria comparable to those currently used by CORE and by ICANN in their accreditation programs.

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. (See CORE member listing attached to this proposal).

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.

For the reasons explained under D1, CORE proposes to create a new association, which would be a split-off of CORE. This new association (CORE-Registry) would be 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 t

Interim Executive Committee for Registry Operator

If a new association is created to operate and manage the TLD “.nom”,  as explained in D1 above, the Plenary Meeting of CORE in which such decision is adopted, will also elect the interim executive committee of the CORE-II. Said interim executive committee shall be active until the Plenary Meeting of the CORE-II is held and a new executive committee is elected or the interim executive committee is confirmed.

D10. Person for this Proposal

Name, telephone and fax number, and e-mail address of person to contact for additional information regarding this proposal. If there are multiple people, please list all their names, telephone and fax numbers, and e-mail addresses and describe the areas as to which each should be contacted.

1) CORE Secretariat:

Werner Staub

tldapp@corenic.org

Tel +41 22 929 5743

Fax +41 22 929 5745

 

2) Legal consultant:

María Luisa Osuna

Cuatrecasas Abogados

mluisa_osuna@cuatrecasas.com

Tel +34 93 2905548

Fax +34 93 2905588

 

3) Business plan consultant:

Mr. Antoine Fatio

KPMG Consulting

afatio@kpmg.com

Tel: +41 22 704 1515

D11. Subcontractors Listing

The full legal name, principal address, telephone and fax numbers, e-mail address, and Dun & Bradstreet D-U-N-S Number (if any) of all subcontractors identified in item D15.3 below.

[D] II. BUSINESS CAPABILITIES AND PLAN

D12. Executive Summary

The second section of the Registry Operator's Proposal (after the "General Information" section) is a description of the registry operator's Business Capabilities and Plan. This section must include a comprehensive, professional-quality business plan that provides detailed, verified business and financial information about the registry operator. The topics listed below are representative of the type of subjects that will be covered in the Business Capabilities and Plan section of the Registry Operator's Proposal.[INSTRUCTION: ICANN will extensively review and analyze this section of the Registry Operator's Proposal. The content, clarity, and professionalism of this section will be important factors in ICANN's evaluation of applications. We strongly recommend securing profbessional assistance from financial and management consultants to aid in the formulation of your business plan, in securing the necessary sources of financing, and in preparation of this section.]

 

Resources available within CORE's Membership 

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

- World class telecommunications companies (Cegetel, France Telecom, Deutsche Telekom, KPN, Saritel/TelecomItalia, Telia, Colt Telecom);

- Highly specialised domain name registrars, a large number of whom are already ICANN-accredited;

- ccTLD registry operators (in particular DENIC, the largest registry after .com with over 3 million domains under .de; NIC-SE concerned with .se; DKNIC concerned with .dk);

- Internet Service providers;

and

- a standards organisation (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 above in the S.O. Proposal and in D.1., CORE points out once more 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 organisations 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.

Organisational 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 organisation, 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 .nom 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 organisation, it stands automatically has acquired legal personality at inception. As Swiss not-for-profit organisations can voluntarily apply for registration, CORE has obtained registration in the Geneva Company Register (Registre du Commerce).

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

Legal Status

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

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

Primary Location

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

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

Membership

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

001

Nominalia

Spain

003

PSI K.K.

Japan

004

Internet Domain Registrars Corp.

Canada

005

First Identity Net

USA

008

Chungwa Telecom Co. Ltd

Taiwan

009

California Suncare, Inc.

USA

010

ETSI

France

011

CSL GmbH

Germany

012

TUCOWS International Corp. / Domain Direct

Canada

013

Melbourne IT

Australia

014

DENIC eG

Germany

016

NetBenefit (UK) LTD

United Kingdom

017

Interdomain, S.A.

Spain

018

Namebay S.A.M

Monaco

019

Pacific Communications Dev. Corp.

Taiwan

020

Aktiv GmbH

Germany

022

Global Internet Services, Inc

USA

024

Bahamas Telecommunications Corp

Bahamas

025

Corporate Domains, Inc.

USA

028

Net Wizards, Inc.

USA

030

Saritel S.p.A

Italy

033

IP Consult GmbH

Germany

035

Smartphone SA

Switzerland

038

Callisto germany.net

Germany

039

Knipp Medien und Kommunikation GmbH

Germany

040

Retevisión SA

Spain

041

Telia AB Network Services

Sweden

043

Alinet Italia Srl

Italy

045

Domain Names International, LLC

USA

046

Eurotel

Germany

048

LanMinds, Inc

USA

049

L.M. - Sitename Ltd

Israel

050

Médiafusion Inc.

Canada

051

Netlink Holdings Pty Ltd

Australia

052

Netlink Internet Services Ltd

United Kingdom

053

CASDNS, Inc.

USA

054

eNom, Inc.

USA

056

TotalNet Inc. Div. MPACT Immedia Inc

Canada

058

Internet Name Registrar

USA

059

The Edge Consultants Pte Ltd.

Singapore

060

France Telecom Transpac

France

061

Freedom Communications, Inc.

USA

063

Ji Tong Communications Co., Ltd.

China

064

SITA

Switzerland

066

Demon Internet Ltd.

United Kingdom

068

Epoch Networks

USA

071

Secunet Security Networks GmbH

Germany

072

Halo Technologies Ltd.

USA

075

Deutsche Telekom AG

Germany

076

Network Information Centre (NIC-SE)

Sweden

077

wespe.de GmbH

Germany

078

Domain Bank, Inc.

USA

079

Axone Services & Développement SA

Switzerland

080

Capital Networks Pty Ltd.

Australia

081

InterNetX GmbH

Germany

082

Grona Verket AB

Sweden

084

Tele Danmark A/S

Denmark

085

KPN Telecom BV

The Netherlands

086

Europe Online

Luxembourg

087

ARK Inc.

Japan

088

Tokyo Internet Corporation

Japan

090

InterQ

Japan

091

InterneXt

France

093

7WAYS

France

092

Cegetel S. A.

France

094

Boston Light Software Corp.

USA

095

OLM, LLC

USA

096

Global Village GmbH

Germany

097

ABC TeleMedia AG

Germany

098

COLT Telecom AG, Switzerland

Switzerland

099

3W-Media GmbH

Germany

101

Kamp Netzwerkdienste GmbH

Germany

 

(Formal Alliances)

Other than the relationship with its members, CORE does not entertain any formal alliances. However, it should be noted that CORE has signed MoUs with different organizations in order to serve as Registry Operator for their new TLD Proposals, but none of these agreements has any impact on the .nom application.

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 organised through CORE.

Organisational Structure

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

No ownership, equal voting power of members

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

D13.1.2. Current business operations.

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

ICANN-accredited Registrar

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

Shared Registry System Development

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

Fully distributed business model

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

Shared Registration System based on Registry Model

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

Registrations in new generic TLD

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

D13.1.3. Past business operations/entity history.

History, date of formation, legal status/type of entity, initial services, duration of provision of services and products.

 

History of CORE

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

The IAHC process preceding the launch of CORE

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

The consultation process leading to the gTLD-MoU and subsequently to the creation of CORE was organised 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 organisation 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 decentralised organisations, CORE relies on certain centralised 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 specialised 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 organisations 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 specialisation 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 specialised managers and technical experts, CORE will primarily draw on membership resources to build the first nucleus of the Registry team. This will be based on seconding arrangements with members with a minimum duration of 1 year for senior positions and three months for junior positions.

CTO and CEO

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

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

D13.1.8. Commercial general liability insurance.

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

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

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

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

This section should present a comprehensive business plan for the proposed registry operations. In addition to providing basic information concerning the viability of the proposed operations, this section offers the registry operator an opportunity to demonstrate that it has carefully analyzed the financial and operational aspects of the proposal. At a minimum, factors that should be addressed are:

Introduction

Operational Model

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

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

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

The membership qualification criteria currently used by CORE is in principle identical to those practised 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.

The registrar has to sign the policy document and/or be approved by the Sponsoring Organisation (SO). The SO approval concept and the related registry access privileges may be differentiated by type of operation.

Trust model and disciplinary framework
Presumption of trust in registrar

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

Certain transactions, such as registrar transfers, are placed under cross-verification, random verification or systematic screening regimes. In this case the trust in …

User authentication by registrar

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

Ability to pre-screen registrations and changes

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

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

Relationship with ICANN accreditation concept

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

D13.2.1. Services to be provided

A full description of the registry services to be provided.

Information registration and update services

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

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

Types of information stored by the registry

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

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

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

Additional records

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

Direct pointers

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

Electronic document storage

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

Information provision services

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

Information to the end-user provided via the registrar

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

Cross-verification mechanisms

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

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

Whois service

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

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

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

Some specialised 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 organised by the registry can be regarded as a service to the community at large.

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

Registration and modification pre-screening framework available

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

Complaint administration framework available (self-policing)

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

D13.2.2. Revenue model.

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

Ability to run TLD-specific revenue models

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

Outside Sponsoring Organisation

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

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

The outside sponsoring organisation 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 organisation

SO-based pre-screening model

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

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

SO-based post-screening model

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

Revenue model for the .nom TLD
Charge per domain-year to the registrar

The .nom revenue model is traditionalist in as much as essentially the creation of new domain record and the annual renewal are charged for on a linear basis. An exception to this rule may apply to the opening process when the TLD is launched.

As it is currently the case for .com, .net and .org registrations, renewal can be performed at any time until the remaining duration of the domain registration reaches the maximum time span.

The charge by the registry to the member registrar per domain-year in the financial projections is expected to be USD 3 per domain year after a couple of months' operation. Depending on the evolution of volume and cost over time, the fee per domain year can be lowered further.

Maximum remaining duration

Given the nature of the .nom TLD as a personal TLD, its long-term nature is also reflected in the maximum remaining duration. This parameter is set fourth by the SO Registration Policy Committee. For the purpose of the projections it is expected to be in the 21 years so as to allow registrants to perform registrations for a reasonable number of years that may have a particular significance in the respective culture. However, experience with the .com, .net and .org domain has shown that this does not tend to be significant from a quantitative perspective. The vast majority of registrations tend to be for one year. The financial projections have been built upon conservative estimates in line with current experience.

Disincentive and special cost recovery charges

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

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

D13.2.3. Market.

Market definition, size, demand, and accessibility.

Market for .nom
Potential sources of registrations

The .nom TLD is restricted to individuals. Initially, most potential domain holder will be regular Internet users who wish to have their own long-term address independent of employer, service provider, professional organisation.

Given the low cost of registrations, a growing number of registrations may be performed with the help or under the sponsorship of commercial companies but - by virtue of the registration policy - strictly at the request of the individual who is registered as the domain holder. The domain holder must have the control of the domain unencumbered by any commercial sponsorship plan.

A particular class of registrants is that of minors who can hold a domain registered on their behalf by parents or relatives. Similar cases are associations, school classes or other groups of persons who jointly decide to get individual domains for all the members of the group.

Gradual growth of demand

Contrary to commercial domains and thanks to the restrictions applied by the registration policy, it is expected that there will be little speculative demand for .nom domains. As a result, the demand will grow gradually as people discover the utility of a long-term identifier. At a later stage personal domain programs and sponsorship schemes by commercial companies are expected to stimulate demand.

Numbers of potentially interested users

At the TLD launch stage, the number of potentially interested users who can easily be made aware of the existence of top-level domains is probably limited to 5 or 10 million individuals. Only a small fraction of these users will register a personal domain at the outset, most probably people who have several Internet connections. Demand is likely to be stimulated through click-and-use programs by registrars, ISPs and other partners; these resources require time to develop. At that point the number of users reachable by registrars should be equivalent to the connected population.

Push by new applications and mobile telephony

New applications, especially subscription-based products, are strongly linked to portable identifiers. Instant messaging between mobile phones enjoys growing popularity amongst young people as shown by the Japanese Docomo i-Mode and SMS messaging in countries with GSM networks. The comparison between the two clearly shows that usage increases dramatically if email addresses as opposed to telephone numbers can be used. It is therefore reasonable to expect substantial demand through mobile telephone marketing schemes where a personal domain name is part of the subscription. In this context, the market for personal domains can be equated to the future market of UMTS.

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.

Estimated demand for .nom TLD

Demand estimates have been prepared based on a low entry barrier concept.

The Financial projections are based on the hypothesis that

- there is 90% likelihood that first-year registrations will exceed 200,000 registrations per year;

- there is 50% likelihood that first-year registration volume will exceed 500,000 domain registrations

- there is only 10% likelihood that first-year registration volume will exceed 1,300,000 registrations.

A general working hypotheses is that growth of volume will average 100%. This is a conservative estimate in view of recent experience. For reasons of simplicity, the calculations have been made on the basis of a continuous growth.

 

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 .nom
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 financing requirement specific to the registry activity is estimated at USD 1,5 million from CORE's existing funds accumulated in the form of membership dues. These have the status of credits for future registrations by members and when the resources of CORE permit. The expected arrival of new members - all of whom pay the same amount of member financing as the existing members should further increase the available funding for registry activities. This approach does not affect the funds covering the operations of CORE's registrar activities.

The financial projections based on initial expenses are conservative and represent outlays for high-end infrastructure. Legal expenses have and those associated with the advisory council budget are also based on pessimistic assumptions.

Although CORE expects to spend less than the projected amounts and take in higher amounts through initial registrations, it will seek additional stand-by facilities from CORE members and other parties. Conversely, spending will be based on a risk-averse strategy. As a result, the financial projections can be regarded as pessimistic for all levels of registrations volumes considered.

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. In this context, financial projections are pessimistic as they assume expenses for near-zero usage initially. The budget for software enhancements is provided in additional to staff costs.

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 although the financial projections are based on a pessimistic evaluation of non-compressible costs. The overall TLD server costs is estimated conservatively at USD 0.60 per domain per year.

Staff

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

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

Describe plans for acquiring all necessary systems and facilities for providing the proposed services at each estimated demand level. Provide details as to the scope, cost, and vendor for any significant planned outsourcing.

 

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

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

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

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

D13.2.8. Staff size/expansion capability.

Plans for obtaining the necessary staff resources, capacity for expansion, hiring policy, employee training, space for additional staff, staffing levels needed for provision of expanded technical, support, escrow, and registry services.

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

The operational concept of CORE is based on automated tasks on registry level and delegation of value-added tasks to member. This automaticality 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 specialised application developers who make available their systems to third parties.

D13.2.9. Availability of additional management personnel.

How will management needs be filled?

As explained under D13.1.7, 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 is four (4) years.

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

The expected cost associated with the registry operations is shown on the pro forma financial projections.

While the initial costs are not expected to be a function of volume, running costs allow for adjustments based on the volume experienced. The projections reflect the hypothesis that the .nom TLD will start slowly but grow at a steady pace. Based on the expected growth, higher investments are made initially and throughout the projected period than would otherwise be the case. In case growth is slower, investments in hardware, connectivity as well as staffing levels can be revised downward.

Staff costs are assumed to grow at half the quarterly rate of growth of registration volume. TLD servers costs and other overhead are computed as if no domains were ever deleted.

In case of insufficient funding, the members can assess themselves monthly membership dues. This is shown in the projections where needed as an increase in the required cumulated contributions per member.

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.

The financial projections for the different volume levels are based on the assumption that registrations grow steadily at 19% per quarter or 100% per year.

The rate of renewal is estimated conservatively at 60% for revenue collection purposes.

As discussed earlier, the expected average duration of registrations is based on current experience and shown slowly growing from 1.2 years toward 1.4  years. While this is a conservative estimate, it is likely that registrations sponsored by companies in the context of subscription contracts will not be prepaid for many years.

As soon as the revenues reach comfortable levels, members are allowed to use their previously paid membership dues for registrations. This is formalised by lowering the required level of cumulated member dues.  As a result, the registration income diminishes over the respective period. Conversely, in case of necessity, this figure can increase as discussed under D13.2.11.

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.

As discussed under  D13.2.6, CORE expects to be able to fund the TLD launch with existing funds and members contributions from existing and new members. The member due mechanisms is based on a minimum cumulated contribution level per member. All members are treated equally (see also D13.2.11).

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

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

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

D13.2.14. Business risks and opportunities.

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

The principal risks associated with the .nom project 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 organisation.

(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 organisation 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 synchronisation 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.

The attached financial projections are based on quarterly income and expenses over the four years in a very low (90% likelihood to exceed), expected (50% likelihood to exceed) and high volume (10% likelihood to exceed) scenario.

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 1 and 2

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

Systems development tools

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

Outsourcing

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

Significant past achievements

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

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

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

This should present a comprehensive technical plan for the proposed registry operations. In addition to providing basic information concerning the operator's proposed technical solution (with appropriate diagrams), this section offers the registry operator an opportunity to demonstrate that it has carefully analyzed the technical requirements of registry operation. Factors that should be addressed in the technical plan include:

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

Address all locations of systems. Provide diagrams of all of the systems operating at each location. Address the specific types of systems being used, their capacity, and their interoperability, general availability, and level of security. Describe in detail buildings, hardware, software systems, environmental equipment, Internet connectivity, etc.

Concepts

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

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

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

Summary of system components
Main SRS site

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

Backup SRS site

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

Whois sites

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

TLD Server sites

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

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

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

CORE TLD Servers will follow specifications outlined in RFC2010.

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

Secretariat site

The secretariat manages a sizeable Intranet specialised email and tracking tools. Experience with .com, .net and .com registrations has shown that secretariat costs ca be kept low thanks to specialised 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 (D13.2) 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 authorised for a given PGP signature. Email-based submissions are practical for occasional participants such as approval officers in charge of a given area.

Discussion of CORE SRS protocol choice, protocol convergence

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

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

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

CORE SRS History

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

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

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

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

D15.2.3. Database capabilities.

Database size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation, reporting capabilities, etc.

Back End Database Concept
Philosophy

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

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

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

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

Summary Database Schema

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

Domain table

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

Holder table (Registrant)

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

Contacts table

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

Name server or hosts table

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

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

Historic data tables

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

Size, throughput, scalability

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

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

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

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

Procedures for object creation, modification and deletion

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

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

Registrar Transfer Procedures

See Registration Policy Description and SRS Protocol Specification 1.1.

Grace Periods

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

Change notification mechanism

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

Reporting capabilities

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

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

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

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

The registry can generate the following reports.

·        Registration Reports, new domains, name servers, contacts.

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

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

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

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

·        Server accounting statistics, system load resource utilization.

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

·        Security notifications and System Denial of Service detection logs.

D15.2.4. Zone file generation.

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

Frequency

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

Verification

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

Interface, User authentication

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

Back-up

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

D15.2.5. Zone file distribution and publication.

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

Transfer after verification

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

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

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

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

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

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

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

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

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

Recursion will be disabled for queries.

Interface, User authentication

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

Implicit Back-up

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

D15.2.6. Billing and collection systems.

Technical characteristics, system security, accessibility.

Registrar prepayment mechanism

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

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

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

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

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

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

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

Monthly statements and cross-verification

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

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

D15.2.7. Data escrow and backup.

Frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of escrow agents, procedures for retrieval of data/rebuild of database, etc.

Standard backup procedures

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

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

Real-time remote logging messages

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

Data Escrow

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

Real-time remote logging on back-up srs site

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

Daily backup within master site

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

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

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

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

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

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

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

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

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

 

D15.2.9. System security.

Technical and physical capabilities and procedures to prevent system hacks, break-ins, data tampering, and other disruptions to operations. Physical security.

Security experts and audit

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

Physical security

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

Technical security

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

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

Data integrity

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

Confidentiality

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

Availability

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

Physical environment.

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

Network security

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

D15.2.10. Peak capacities.

Technical capability for handling a larger-than-projected demand for registration or load. Effects on load on servers, databases, back-up systems, support systems, escrow systems, maintenance, personnel.

Benchmark reference data

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

Moreover, CORE’s organisational 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:

l         all of the registry operation function;

l         any portion of the registry function accounting for 10% or more of overall costs of the registry function; or

l         any portion of any of the following parts of the registry function accounting for 25% or more of overall costs of the part: database operation, zone file generation, zone file distribution and publication, billing and collection, data escrow and backup, and Whois service

please (a) identify the subcontractor; (b) state the scope and terms of the subcontract; and (c) attach a comprehensive technical proposal from the subcontractor that describes its technical plans and capabilities in a manner similar to that of the Technical Capabilities and Plan section of the Registry Operator's Proposal. In addition, subcontractor proposals should include full information on the subcontractor's technical, financial, and management capabilities and resources.

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

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


[D] Signature

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

 

_______________________________
Signature

Werner Staub___________________
Name (please print)

Head of CORE Secretariat_________
Title

CORE Internet Council of Registrars_
Name of Registry Operator

September 30, 2000________________
Date