[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.
CORE is the result of an open and
neutral process launched by the IAHC. 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 serve
the purposes for which the POC and the PAB were originally created .
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] (N/A)
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 19 countries on 3 continents. (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 site.
http://www.corenic.org
D6. [Identifier]
Dun & Bradstreet D-U-N-S Number (if any) of registry operator
Registered in Geneva. Please see
copy of Certificate attached
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 of member 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. These 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.8 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 registrations amounts to USD 550,000. (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.
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.
Werner Staub
tldapp@corenic.org
Tel +41 22 929 5743
Fax +41 22
929 5745
2) Legal
consultant:
María Luisa
Osuna
Cuatrecasas Abogados
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.
N/A
[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).
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 is demonstrates the scalability and the validity of CORE shared "heavy" registry concept.
Separation of CORE Registry and CORE Registrar
CORE has repeatedly pointed out that a registry operator should not be allowed to be a registrar in its own registry unless this takes place for a short transition time. This plan is built on the principle that the not-for-profit CORE Registry Operator will be institutionally separated from the not-for-profit CORE Registrar. There are to be two separate membership processes and separate supervisory bodies. Both organisations will have independently the rights to the current CORE shared registry system. It is to be expected that a number of CORE members will be 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.
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 working on a common shared registry protocol with ccTLD registries and new gTLD registries.
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 , in particular for commodity services or for functions that can and should be duplicated.
Competition between members in customer-related activities and value-added services
Interaction with customer and value-added services are the 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.
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 all 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 contributing to convergence 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 on recent standards such as XML and be developed on the traditional "rough consensus, running code" philosophy.
D13. Business Capabilities and Plan
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. 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 19 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.
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 and (d) the SRS operations and maintenance team and (e) Working Groups.
No ownership, equal voting power of members
As an 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. The current implementation of the CORE SRS has been developed by a CORE member.
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 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. {wst}
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 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 verification tools are run by the SRS team and the CORE secretariat. 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 co-ordinating 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 a 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 8 to 10 staff positions by the time registry operations start. Depending on the overall workload required, the initial staffing level may 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 co-ordinating 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 creates 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.
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 allows to use their contributions for registrations.
Possible additional requirements
Depending on the policies set fourth for a to a given domain managed by the CORE Registry, there may be additional conditions for a member to be allowed to per form 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.
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 verifications 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.
Additional records
Moreover, additional information required by the SO can 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, 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 offering 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 enable 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.
.post Services
For the .post TLD, the following entities and services are proposed:
1) the
.post Accreditation Service - a
section of the UPU
2) .post Operators
– Postal Administrations accredited to use .post domain names
3) .post Registrars
– Postal Administrations accredited to issue .post domain names
4) ICANN-accredited Registrars – any organisation accredited by ICANN to act as a registrar.
The .post Accreditation Service will
receive all accreditation requests from potential .post Operators. Once the necessary agreements have been signed,
the .post Operators can request
domain names from the .post
Accreditation Service. If these are approved, the .post Accreditation Service transmits the necessary domain
information to an ICANN-accredited
registrar for inclusion into the DNS and Whois.
The UPU is the only .post Accreditation Service and as a
start, the only entity which communicates domain name information to
registrars. Initially, all domain names will be registered through CORE.
A .post Operator, however, may also chose to become a .post Registrar if it wishes to
register .post domain names for its customers. In the accreditation process to
become a .post Registrar, the Postal
Administration must either:
1) be
an ICANN-accredited registrar
2) use
the services of an existing ICANN-accredited registrar.
In addition, the ‘.post Registrar’ will have to demonstrate its ability to apply all the TLD restrictions, policies and necessary guarantees.
The postal administration of every country in the world could ultimately be delegated registrar authority for SLDs, subject to conformance with UPU expectations for trust and confidentiality. This delegation can be administered by a registrar authority as determined by the postal administration. Delegation of SLD registrar authority will be subject to UPU oversight. This is to ensure that postal administrations worldwide adhere to the public expectation of trust and confidentiality for any internet entity operating under the UPU. Alternate postal administrations within a country will be delegated SLD registrar authority subject to the same expectations of trust and confidentiality as for primary postal administrations.
Registrars for SLDs for worldwide service offerings will be determined by the UPU.
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 registration is rejected by the Sponsoring Organisation's screening framework. (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 .post TLD
The UPU is a non-profit organisation. Therefore, the UPU budgeting and finances are based on cost recovery. The fee structure reflects this.
Postal Administrations who use the .post (.post Operators) will be charged :
1) An
initial non-refundable application fee of USD $1,000 to $10,000 to cover the
costs of examining the request for accreditation as a .post Operator. The fee will vary as a function of the point
contributions of its member country to the UPU. This fee will be waived for
those Postal Administrations who have contributed to the ICANN .post TLD
application.
2) An
annual fee of USD $1,000 to $10,000 to cover the costs of operating the common
components and the policy making activities.
3) A
USD $150 fee per domain name requested per 2 year period, covering the costs of
pre-screening, registration and registry. Special pricing may be granted for
Postal Administrations with limited budgets or bulk requests.
Postal Administrations who act as .post Registrars will be charged:
1) An
initial non-refundable application fee of USD $1,000 to $10,000 to cover the
costs of examining the request for accreditation as a .post Registrar. The fee will vary as a function of the point
contributions of its member country to the UPU.
2) An
annual fee of USD $500 to $5,000 to cover the costs of the policy making
activities.
3) A
royalty of USD $15 per domain name registered per 2 year period.
Fees may be adjusted annually based on the effective costs of operating the .post.
D13.2.3. Market.
Market definition, size, demand, accessibility.
Market for .post
The .post TLD will serve the community of Postal Administrations who in turn serve the community at large. Assigning an eMail address to each habitant in a region or country and providing convenient access points in post offices is one of the more ambitious projects in the internet. The Trusted Postal Services associated with these eMails will help the general public accept the internet as a more secure medium.
The Postal Administrations, their customers and the public are already served by DNS. We firmly believe that the .post TLD will help accelerate the general acceptance of the internet with the ‘have nots’ and the ‘not sure’.
The UPU does not anticipate a significant rush in the start-up period. The first wave of registrations will concern :
1) the
189 members of the UPU, with around 400 to 1000 domain names – to be registered
over a 6 month period.
2) the
generic postal domain names – less than 200.
The second wave will concern the customers of Postal Administrations, notably the geographical mapping of domain names. The volume will depend on the Postal Administration’s business plans.
Examples:
1) Postal
Administration 1 may assign domain names to all cities, communes and national
administration services. This would result in over 30’000 domain names. In all
probability, Postal Administration 1 will become a .post Registrar, using the technical services of an
ICANN-accredited Registrar. The planned time frame is 6 to 12 months for completion.
2) Postal Administration 2 would only have its own domain names – 3 to 4 at most and will not be requesting domain names for his customers.
D13.2.4. Marketing plan.
Advertising, publicity, promotion strategy, advertisement development strategy, relationship with advertising firm. Use of registrars and other marketing channels.
Marketing of the .post TLD and associated postal services that will be made available from the TLD will be performed by the individual Postal Administrations in their respective countries. This will also include any Global Postal services that the individual country is participating in.
The marketing of the .post TLD and services will be combined with existing marketing plans and strategies for postal e-business products and services and will use the existing marketing resources of the various Postal Administrations.
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 .post
The UPU does not anticipate a significant rush in the start-up period. The first wave of registrations will concern :
1) the
189 members of the UPU, with around 400 to 1000 domain names – to be registered
over a 6 month period.
2) the
generic postal domain names – less than 200.
The second wave will concern the customers of Postal Administrations, notably the geographical mapping of domain names. The volume will depend on the Postal Administration’s business plans.
Examples:
1) Postal
Administration 1 may assign domain names to all cities, communes and national
administration services. This would result in over 30’000 domain names. In all
probability, Postal Administration 1 will become a .post Registrar, using the technical services of an
ICANN-accredited Registrar. The planned time frame is 6 to 12 months for
completion.
2) Postal
Administration 2 would only have its
own domain names – 3 to 4 at most and will not be requesting domain names for
his customers.
The
confidence levels of these estimates can reasonably be expected at
approximately 90% due to the distinct number of UPU members being only 189 and
the fact that the policy restrictions ensure that UPU members will only have
the legal right to register a limited number of domains.
The UPU is a non-profit organisation. Therefore, the UPU budgeting and finances are based on cost recovery. The registration fees reflects this and therefore should have little or no effect on whether a registration will be applied for or not.
Due to the fairly low volumes involved and the heterogeneous national situations, the current intention is to allow the .post Registrar to chose its ICANN-accredited registrar – as long as the latter abides by the ‘.post Additional Restrictions for ICANN-accredited registrars’. This introduces a token amount of competition among registrars – but the financial implications are modest, at best.
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.
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 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.
Technical
CORE principal technical resource is its shared registration system (SRS) and the TLD servers. CORE's 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 automatically limits the degree to which the registry requires clerical staff and support.
CORE has a tradition of working with members for development work. One-time tasks such as specific software developments and documentation projects can be entrusted to experts from within the compensated at market rates. Many CORE members are 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, CTO 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>.)
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 .post 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.
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.
Please see Sponsoring Organisation’s Proposal.
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 from 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 .post 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 and 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 are 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 made available for contingencies. Coming from members, the 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.
Please see Sponsoring Organisation’s Proposal.
D13.4. Supporting documentation.
The following documentation should be provided in support of the Business Capabilities and Plan section:
D13.4.1. Registry operator's organizational documents.
Documents of incorporation (or similar documents).
The following documents are attached:
CORE Articles of Association
CORE Rules
Copy of Geneva Company Register certificate
Baloise
insurance confirmation
D13.4.2. References.
A list of significant trade and credit references.
See list of CORE members and point D13.4.4.
D13.4.3. Annual report.
The registry operator's most recent annual financial report (or similar document). Audited financials are preferred.
The following document are attached:
Audit report from KPGM of CORE's 1998 Financial statements based on Internationally Accepted Accounting Principles (IAS)
Audit report from KPGM of CORE's 1999 Financial statements based on Internationally Accepted Accounting Principles (IAS)
Audit report from KPGM of CORE's June 2000 Interim Financial statements based on Internationally Accepted Accounting Principles (IAS)
D13.4.4. Proof of capital.
Provide evidence of existing capital or firm commitments of capital. Demonstrated access to necessary capital will be carefully scrutinized.
UBS Bank Reference Letter
(CORE is customer of UBS since 1997 and holds funds in excess of USD 3,000,000)
D13.4.5. Proof of insurance.
Please provide proof of the insurance described in item D13.1.8.
The following document is attached:
Baloise
Assurances Confirmation.
[D] III. TECHNICAL CAPABILITIES AND PLAN
D14. General
The third section of the Registry Operator's Proposal
is a description of the registry operator's Technical Capabilities and Plan.
This section must include a comprehensive, professional-quality technical plan
that provides a detailed description of the registry operator's current
technical capabilities as well as a full description of the operator's proposed
technical solution for establishing and operating all aspects of the registry.
The technical plan will require detailed, specific information regarding the
technical capabilities of the proposed registry. The topics listed below are
representative of the type of subjects that will be covered in the Technical
Capabilities and Plan section of the Registry Operator's Proposal.
[INSTRUCTION: ICANN will extensively review and analyze this section of the
Registry Operator's Proposal. The content, clarity, and professionalism of this
section will be important factors in ICANN's evaluation of applications. We
strongly recommend that those who are planning to apply secure professional
assistance from engineers and/or other technical consultants to aid in the
formulation of the technical plan and the preparation of the Technical
Capabilities and Plan section of the Registry Operator's Proposal.]
Note: the content of this section is reflects points not already covered under D13 and in the attached CORE SRS protocol specification 1.1.
D15. Introduction
The Technical Capabilities and Plan section should consist of at least the following:
D15.1. Detailed description of the registry operator's technical capabilities.
This should provide a detailed description of the registry operator's technical capabilities, including information about key technical personnel (qualifications and experience), size of technical workforce, and access to systems development tools. It should also describe the registry operator's significant past achievements. This description offers the registry operator an opportunity to demonstrate the extent of its technical expertise in activities relevant to the operation of the proposed registry.
Technical workforce
The planned concept of hiring personnel and members seconding key experts is discussed under D13.2.
CORE has track record of successful developments in collaborative mode, personnel from various members working together. CORE Registrar SRS operation and maintenance and secretariat have been outsourced to two separate member companies.
It is important to point out that participating members also have extensive experience in shared systems from their own developments. Many member operate shared registration system concepts on their own facilities in order to collaborate with channel partners.
While distributed 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 bandwith available with a burstable bandwith 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 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 contructive 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 present 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 registrants 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, 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 Following reports can be generated by the registry.
· 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.
A management interface is provided to Sponsoring Organizations by the Registry Operator 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 causes 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 durations. 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 integraty.
Real-time remote logging on back-up srs site
A second Slave database is maintained off-site for realtime 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, the other two are operated by two major hosting providers who are also CORE members.
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 services 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 proxied 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
Support to users is performed by registrars who compete with respect to service level and price. 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 Permanent Secretariat_____
Title
CORE Internet Council of Registrars
Name of Registry Operator
_______________________________
Date