2.1 Application Vehicle and Institutional Set-up
  ------------------------------------------------

This bid is submitted by Asociación CORE++. This entity has as its only goal to
submit the proposal and negotiate the subsequent contract with ICANN. But it
will not sign the contract itself, nor act as the .net Registry. For these
purposes, it will set up the institutional framework described below.


  2.2 The participants in the CORE++ Bid
  --------------------------------------

CORE++ is a consortium of non-profit and for-profit organizations. The bulk of
the .net-related activity is performed by functional organizations acting as
suppliers to CORE++. As a result, it is necessary to describe the key functional
organizations participating in CORE++ alongside the description of institutional
set-up of CORE++.

With regard to the Applicant's Business and Other Associated Activities, the
determinant activities are those of the key functional organizations described
below.


  2.3. CORE++ Institutional Set-up
  --------------------------------

CORE++ is based on a two-level institutional set-up. The institutional set-up is
structured in the form of

  * one coordinating organization (created as a new company)

  * several functional organizations (existing companies and institutions).


The functional organizations are the ones that perform the essential technical
tasks. They participate managerially in the coordinating organization, some of
them also financially. Economically, they act as suppliers to the coordinating
organization, but they have an obligation to continue to perform their function
even in case the institutional tier should be unable to act. Financially,
institutionally and technically, they have the highest level of solidity that
can be achieved in the respective fields, yet could be replaced in the extremely
unlikely event of failure.

This form of organizations lies in the spirit of the Internet and modern
concepts of high security and international risk management. The technical
functions are encapsulated with clear interfaces and assigned to well-qualified,
strong organizations. The coordinating organization is kept as light as
possible. This set-up is more resilient than a monolithic organization. It also
enables CORE++ to act both globally and regionally, achieving a degree of
geographical and language diversity that a monolithic organization cannot match.


  2.4. The Coordinating Organization
  ----------------------------------

The coordinating organization for the purpose of the ICANN RFP is set up as not-
for-profit association CORE++, chartered with the objective of creating a .net
registry by fostering the required cooperation of for-profit and not-for-profit
organizations. Please seepart 1, Section 4 for a detailed description of CORE++
SL.

It prepares, among other things, the institutional set-up for a for-profit
organization, to be called "CORE++ SL". If the CORE++ Association is retained
for the bid, then it will either sign the contract with ICANN in view of that
contract being assigned to the newly created CORE++ S.L.

At the time of this submission, the participants of the CORE++ are preparing the
creation of the CORE++ Limited Liability Partnership. The final financial
parameters will be determined shortly after ICANN's deadline, when the
submission is public. This enables the financial partners in the CORE++ project
to evaluate the precise context of their financial investment.

Most of the functional organizations will formallly be partners (members,
equivalent to shareholders, even if the term is not legaly correct)) of such
CORE++ SL corporation. Some of them are still going though the internal aproval
procedures for becoming formal members. Some other functional organizations will
act as subcontractors without holding a stake in CORE++ equity.


  2.5. The Functional Organizations
  ---------------------------------

The CORE++ proposal is based upon the participation of key organizations, each
of which performing for CORE++ that it already performs in the course for is
normal business. The list below addresses the organizations performing technical
functions. Other organizations with a mere financial involvement are listed
under <Section 1, point 3.vii>. The functional organizations are listed here by
time zone of their principal place of activity (from East to West).


  2.5.1. NIDA Consortium

NIDA Consortium is a joint venture between NIDA, Cydentity, and Inames.

The National Internet Development Agency of Korea (NIDA) is a non-profit
organization. It was founded in 1999 with the aim of building a stable internet
address management system. Since then, NIDA has been in charge of allocating &
managing Internet addresses in an efficient manner including R&D activities
designed to increase the use of Internet. It has established a stable framework
for managing the Internet address resources and promoting international
cooperation and comprehensive policies.

As a sub-organization of NIDA, Korea Network Information Center (KRNIC) also has
endeavored in allocation and assignment of domestic IP addresses and
registration of .KR domains. As of now, NIDA manages about 590,000 .KR domains.
In addition, NIDA has showed continuous support for international cooperation
and development in Internet through its outreach programs for developing
countries and active participation in various international organizations and
conferences. In this way, NIDA has been playing a key role in Internet
development of Korea based on Korea's world-class high-speed network
infrastructure. NIDA is located in Seoul, Republic of Korea.

CyDentity and Inames are companies specialized in Internet Address Resources.
They have prepared and materialized a global platform, R&D, and operations to
manage the necessary technologies for operating a Registry since 2001, based on
the skill and experiences in Internet Address Business. CyDentity has
participated in the .org Registry Re-delegation in March 2002. In addition to
developing technologies regarding expansion and efficient use of Internet
Address resource, CyDentity and Inames provide an e-Business Total Solution &
Service by consulting on matters such as e-Design, e-Promotion, and e-Biz.


  2.5.2 CORE Internet Council of Registrars

CORE is a not-for-profit membership association of Internet domain name
registrars and registries active since 1997 in the internet industry. CORE was
the first operable ICANN accredited registrar in 1999, and has always been
actively present in the major technical and political development that ICANN
pursued since its creation. Some of the high value services that CORE offers are
the following:

Registrar business operations With their shared registration system (SRS) CORE
provides cutting-edge developments.

  * Registry consulting services


CORE's professional expertise and their profound experience with state-of-the-
art technologies make them a valuable adviser. CORE has repeatedly submitted
successful bids to ICANN.

  * Registries back-end services


Since 2002, CORE provides sophisticated back-end registry systems for two
sponsored top level domains (sTLD), .aero and .museum.


  2.5.3.Telefónica

Telefónica Group is one of the world's leading telecommunications companies.
Telefónica is the leading operator in the Spanish and Portuguese speaking
markets and the fifth biggest operator in terms of market capitalization. Its
activities are centered mainly on the fixed and mobile telephony businesses with
broadband as the key tool for the development of both of these.

The company has a significant presence in 16 countries and has operations of
various sizes in approximately 40 countries. Telefónica has a strong presence in
Latin America, where the company acts in eight countries and where it
concentrates its growth strategy. Its costumer base amounts more than 115
million. Telefónica is a 100% public company, with almost 1.7 million direct
shareholders. Its share capital currently comprises 4,955,891,361 ordinary
shares traded on the Spanish Stock Market (Madrid, Barcelona, Bilbao and
Valencia) and on those in London, Paris, Frankfurt, Tokyo, New York, Lima,
Buenos Aires, São Paulo and the SEAQ International Exchange in London.


  2.5.4. NICBR

NICBR is the entity, coordinated by the Brazilian Internet Steering Committee -
CGIBR, with the attribution to coordinate and to integrate all internet services
in Brazil, assuring quality and efficiency in all offered services. Specially
must support the development of internet services, approve and commend policies
for the Brazilian internet, and technical and operational procedures, allocate
the internet address space and register all domain names under the ccTLD <.br>,
promote the interconnection of different backbones and collect, organize and
share information and statistics about internet services.


  2.5.5. ISC

The Redwood City based Internet Systems Consortium, Inc. (ISC) is a nonprofit
public benefit corporation dedicated to supporting the infrastructure of the
universal connected self-organizing Internet -- and the autonomy of its
participants -- by developing and maintaining core production quality software,
protocols, and operations.

ISC was originally founded to continue the work of maintaining and enhancing
BIND following in the footsteps of U. C. Berkeley, Digital Equipment Corp., and
Vixie Enterprises. ISC's operational activities include root name service,
Internet hosting facilities, secondary name service for more than 50 top-level
domains, and a DNS OARC (Operations, Analysis and Research Center) for
monitoring and reporting of the Internet's Domain Name System.

Today, ISC has employees in California, Massachusetts, Canada, Holland, and
Australia, and a global constituency.

This chapter presents the skills of the partners CORE++ comprises, information
on the key technical personnel involved and details concerning the technical
utilities and technologies at their disposal.


  Partners


  CORE

CORE was created in 1997, initially with the aim to become the registry for the
new top level domains that were about to be created at that time. The
development in the Internet society changed the role of CORE and CORE became the
initiator of the SRS principle as well as one of the five initial registrars
ICANN accredited. CORE is also the acting registry for the two sponsored top
level domains .aero and .museum. They are also meant to become the acting
registry for the Top Level Domain .cat when/if .cat gets the green light from
ICANN. CORE has extensible knowledge of the EPP and RRP protocols. All technical
personnel involved with CORE is available to CORE++.


  NIDA Consortium

NIDA (National Internet Development Agency of Korea) is the acting registry for
the country code top level domain .kr (Korea). There are currently approximately
600,000 domains in the TLD .kr. The NIDA Consortium has been involved in the
ICANN framework since the start and has also participated in the work of the
IETF for years. NIDA has taken a leadership role for developing IDNs in Asia and
is the home of Yangwoo Ko who is the co-author to RFC 3743, CJK IDN Guidelines.
NIDA is also in the forefront of the ENUM project.

NIDA is also responsible for the allocation of IP resources in the APNIC Area;
since August 2004, the allocation is focused on IPv6 address space. Another
effort conducted by NIDA is WINC (Wireless Number connection to Content). The
development of NIDA has been conducted by Dr Jae-Chul Sir, today the acting
president.


  NICBR

NICBR is the acting Registry for the Brasilian Country Code Top Level Domain
.br. At the end of December, there were approximately 710,000 domains
registered.

NICBR has been involved in the ICANN framework since the start of ICANN in
1997/1998. Since 2000, they have actively participated in the IETF work and is
represented by Fredrico Neves at SSAC.

When Internet Software Consortium (ISC) started their project on mirroring the f-
root, the .br registry was deeply involved. They made a partnership with ISC; in
this context, they run the first mirror in Latin America.

In Sao Paolo there are several Exchange Points and NICBR is today acting as a
neutral partner running the Central IX in Sao Paolo. The work to get all the
stakeholders together was conducted by Hartmut Glaser, who also is a Member of
the Address Council within the ASO (Address Supporting Organisation).


  Telefonica

Telefonica Group is one of the world's leading telecommunications companies,
with operations in Europe and the Americas, offering direct connectivity between
Latin America, the US and Europe through its international fiber optic network,
as a part of a network that spans all over the world. Telefonica owns and
operates highly secure facilities in many countries, where they run state-of-the-
art equipment and services.

Their robust IP network has an extensive coverage (complemented by domestic
networks in 10 countries with more than 1,500 PoPs), including the major hubbing
points, and over 200 peering agreements with major carriers and Tier-1 operators
around the world, ensuring direct access to foreign country users even in these
places with no local presence, through a minimum hop count path. It is fully
managed by Telefonica, offering maximum quality, flexibility and reliability.
This backbone already has fully equipped nodes to provide IPv6 international
access, integrating communication services between Europe and the Americas
through IPv6.

Within this network, Telefonica already provides domain name services and SRS
services to registry companies in the group such as Interdomain, responsible for
the management of the .es domain.


  .ZA DNA

The .za DNA was established in 2002 after a consultation process within South
Africa. The transfer from the original administrator of the .ZA ccTLD Mike
Lawrie, to the .za DNA was effected by the IANA on the 10 January 2005. The
services within .za continue to be handled according to the relevant RFCs
developed by IANA as well as by other guidelines developed within the ICANN
framework. The aim is to have .za fully incorprated in the operations one year
after start.


  Internet Systems Consortium (ISC)

Internet Systems consortium (ISC) is acting as subcontractor with the
responsibility to ccordinate DNS operations. As the original author of BIND, ISC
has an extensive knowledge of BIND and DNS. ISC is also operating the f-root-
server since more than 10 years and is providing specialist competence to the
Root Server System Advisory Committe (RSSAC).


  Tools and Engineering Methods


  Software Development Tools

The operation of the .net registry comprises many complex activities which
cannot be accomplished without a proper technical basis. CORE++ therefore uses
well-established technological frameworks and tools for software development,
revision control, issue tracking and other crucial tasks:

  * Java - the core system of the .net registry server is running on Sun's Java
    platform. Java not only provides sophisticated features that contribute to
    the quality of the developed software. Java's hardware and operating system
    independency provides CORE++ with the flexibility to respond to future
    challenges and IT developments.

  * NetBeans IDE - all Java software development, testing and debugging is done
    using the acclaimed NetBeans development environment.

  * Concurrent Versions System (CVS) - the leading open-source revision control
    system is used for source code and release management.

  * JUnit - a widely used Java unit testing framework that greatly facilitates
    regression testing.

  * Request Tracker - internal (developer) and external (registrar) issue
    tracking is provided by RT, a widely used, enterprise-grade ticketing
    system.



  Software Engineering Methods

In addition to suitable tools, the use of proven software development methods
and processes is crucial to achieve the level of software quality required for
operating the .net registry. CORE++ has been able to adopt such practices in the
course of various software projects - most notably during the implementation of
CORE's registration gateway, a system that consists of more than 500,000 lines
of Java code. Projects of such dimension cannot be managed without proper
software engineering techniques. The development team of CORE++ therefore
applies the following principles and methodologies during the typical phases of
the involved development process:

  * Analysis/Design: Initial requirement analysis and the design of the system
    components are performed using OOA/OOD methods (object-oriented
    analysis/design). In particular, the Unified Modeling Language (UML) is used
    for tasks like use case analysis, package/class design and the creation of
    collaboration and status diagrams.

  * Coding: The strict use of object-oriented programming methodology, utilizing
    Sun's Java platform, represents the basis for the implementation. Emphasis
    is especially placed on documentation, code reuse and the application of
    proven software design patterns wherever possible.

  * Testing: During and after the implementation, continuous testing is
    performed to assess all components of the system, including (but not limited
    to) extensive unit/regression testing using the JUnit framework. In
    addition, stress tests are applied to evaluate a system's behaviour under
    extreme load conditions.

  * Operation: Every deployment of a new release is carefully planned. Multiple
    internal test stages, usually followed by a prior operation on the OT+E
    system, are performed and evaluated before any new code is installed on a
    production system.



  Key Technical Personnel

This section lists the individuals that will take the lead in the technical
development and operation of the .net registry.


  Klaus Malorny

Diplom Informatiker (similar to Master of Computer Science). Senior Software
Developer at Knipp Medien und Kommunikation GmbH, Dortmund (10 1/2 years +
during study). Senior Software Developer at Siemens Rolm Communication Inc.,
Santa Clara, USA (1/2 year). Computer experience for 26 years. Skills: C, C++,
Java, SQL, Pascal, PostScript, Assembler (x86), _JavaScript, Perl and various
other (scripting) languages; Database, GUI and web design & programming, object
oriented programming, 2D/3D graphics, Internet protocols, XML/XSLT/SGML,
cryptography and related technologies. Domain related activities: designed and
implemented Knipp internal registration system, designed and implemented CORE's
second generation Shared Registry System. Participation in the IETF Provreg WG
List, which designed EPP. Member of the technical advisory committee of the
German ccTLD Registry, DENIC.


  Thomas Corte

Diplom-Informatiker (similar to Master of Computer Science). Works as a senior
software developer at Knipp Medien und Kommunikation GmbH, Dortmund, Germany
since 1992 and has 20 years of computer experience. Skills: programming in Java,
C, C++, Perl, SQL, Lisp, Modula-2; object oriented analysis and design with UML;
database administration; web design & programming; XML/SGML/TeX. Managed several
web application projects for major companies utilising Sun's J2EE platform.
Participated in the design and development of CORE's second generation SRS.


  Elmar Knipp

Elmar Knipp is managing director of Knipp Medien und Telekommunikation GmbH,
mainly responsible for technology and strategy. He co-founded the company in
1994. In 1997, Knipp entered the domain market and has since gained experience
in all areas of this business. This includes acting as a registrar, as registry
operator for sTLDs and also as software vendor for registry systems. He holds 50
% of Knipp's shares. Elmar Knipp is vice president of CORE since 2001, is member
of the Supervisory Board of DENIC eG since July 1998 and is one of the directors
of Afilias since 2003. Elmar Knipp studied Computer Science at the University of
Dortmund.


  Timur Nusserov

Diplom Mathematiker (similar to Master of Mathematics). Software Developer at
Knipp Medien und Kommunikation GmbH, Dortmund (5 years). Software Developer at
GFOS, Essen (5 years). Skills: C, C++, Java, Perl; Database, web programming
(JSP), object oriented programming, HTML, Internet protocols. Designed and
implemented CORE's second generation SRS.


  Damian Lusiewicz

Diplom Informatiker (similar to Master of Computer Science). Senior Software
Developer and System Administrator at Knipp Medien und Kommunikation GmbH,
Dortmund (7 years). Skills: Java, C, C++, Perl, Pascal, Assembler(68k), SQL,
HTML; object oriented programming, web programming, firewall, IP connectivity
and VoIP solutions.


  Markus Fischer

Diplom-Informatiker (similar to Master of Computer Science). Software Developer
at Knipp Medien und Kommunikation GmbH, Dortmund, since 2003; FernUniversität
Hagen (4 years); Multimedia Kommunikationssysteme GmbH, Hagen (4 years); Skills:
C, C++, Java, Pascal, SML, Visual Basic, SQL, HTML, XML, JavaScript, object
oriented analysis and design, databases, web design & programming, networking,
client-server applications, software testing and quality assurance, evolutionary
optimization, computer graphics, telelearning, project management.


  Michael Rumianek

Software developer. Michael has a multi-year theoretical and practical Internet
experience. He developed several mathematical and fuzzy based simulation
algorithms. Since December 2001 he is involved in the development of CORE's
registry gateway software.


  Natalie Lordick

Software developer. Natalie has a multi-year theoretical and practical Internet
experience. In that context she designed GUI's and implemented several
mathematical simulation algorithms. Since December 2001 she is involved the
development of CORE's registry gateway software.


  Marcus Faure

Internet technician. Marcus is co-founder and CTO of Global Village Germany, the
company being established in 1996. It offers services to customers like Merck,
Zuerich Aggripina and Underberg. He has been active in the development and
operation of the GV registrar gateway which is used by 1000+ registrars to
access a variety of top level domains. He is also responsible for security
installations of a number of customers and has been a project manager for the
development of e-learning portal sites that are supported by the EU commission
and the German government.

Since 2001 he is also chairman of the executive committee of CORE Internet
Council of Registrars. As such, he pursuits CORE's mission to establish new TLDs
on the Internet. He is co-author of the SITA ICANN agreement for .aero. On the
other hand, in ICANN's registrars' constituency, he gained experience in
registrars' interests and their role in the success of a domain.


  Frederico Neves

Frederico Neves has a degree on chemistry engineering and got contact with the
domain naming system during his master degree program at University of São Paulo
in 1993. CTO of ".br Registry" and Engineering Manager for LACNIC. Technical
contact for .BR since 1998. Designed and implemented the ".br registry system"
in 1997 and the "LACNIC system" in 2001. Participation in various IETF WG
related to domains and addresses. Member of the Security and Stability advisory
committee of ICANN (SSAC).


  Hartmut Glaser

Prof. Hartmut Richard Glaser, Bachelor in Physics (USP - University of São Paulo
- 1967); Assistant Professor for Physics at USP (1968 to 1970); Master in
Electrical Engineering/Microelectronics (USP - 1972); Doctorate studies at USP
(1972 to 1975); Assistant Professor in Electronics at USP (1970 to 2004); Vice-
Coordinator of Microelectronics Laboratory (Research Center) at USP (1972 to
1988); Assistant to the Dean (Director) of the Polytechnic School (Faculty) of
USP (1988 to 1993); Assistant to the Rector of University of São Paulo for
InformationTechnologies/Internet (1993 to 1996); Assistant to the CEO of FAPESP -
 The State of São Paulo Research Foundation (1996 to 2004); Executive
Coordinator of ANSP - the Academic Network of the State of São Paulo (1996 to
2002); Executive Coordinator of NICBR (1996 to 2004); Member of LACNIC´s Board
of Directors (2000 to 2006); AC/ASO/ICANN Member (2000 to 2006)


  Milton Kaoru Kashiwakura

Master of Electronic Engineering at Escola Politécnica - University of São
Paulo, in 1990. Engineering Manager at CGIBR, since September 2004; Network
Manager at iG, the main ISP in Brazil, from June 2001 to August 2004; Technical
Coordinator at ANSP, the Academic Network at São Paulo created by FAPESP (the
first brazilian network connected to Internet in November 1988), from January
1998 to May 2001; Network Director and Engineer at Electronic Computer Center -
University of São Paulo, from September 1983 to December 1997; Projected and
implemented the first NAP in Brazil; projected and implemented Advanced ANSP,
the Academic Network of the State of São Paulo - like Internet 2; projected and
implemented RedeUSP, the Network of University of São Paulo with more than 500
buildings spreaded in many cities; and hundreds networks projects for institutes
and companies.


  Dr. Jae-Chul Sir

President of KRNIC of NIDA, in charge of Internet Name Policy Section,
Statistics & Policy Research Team, International Affairs Team, and a member of
NNC (Number and Name Committee. Served as an arbitrator of the Korean Commercial
Arbitration Board, a Promotion & PR director at KADO (Korea Agency for Digital
Opportunity & Promotion), and a President of HwaShin CompuGraphic Company.
Professional Engineer (P.E.). B.S. and M.S. in Computer Science from Hanyang
University. Ph.D. in Computer Science from Soongsil University. Skills: Computer
Network Design & Implementation; Internet protocols; Wired & Wireless
Telecommunication Management; XML/SGML, C++, Delphi, Java, Pascal, Assembler,
AutoLISP and other languages; Database (Oracle); Computer Graphics & Design
(AutoCAD) ICT related activities: Took an active role in drafting the Internet
Resource Administration Act and conducted Outreach Projects. Worked on digital
divide projects at KADO as a project manager.


  Javier Achirica

Javier Achirica has been involved in the design and deployment of IP networks
and services for 12 years, in both corporations and national and international
carrier IP networks in different areas of Telefonica, setting up IP networks and
services in more than 12 countries. He has been an active developer in several
open-source projects related to IP applications and systems. Javier has also
been working in different IETF working groups for 7 years.


  Pablo Varela

Pablo Varela has been involved in the operation, deployment and design of IP
networks and services for 8 years in both national and international carrier IP
networks in different areas of Telefonica.


  TaeJae Kim

TaeJae Kim is currently a CEO of INAMES, one of the top registrar companies in
Korea. He served as a CEO and advisor of the Su-Won Cable Broadcasting, one of
the biggest cable broadcasting companies in Korea. He completed the Graduate
School of Industry & Information Studies at Kyung-Hee University in Seoul. He
awarded the 'Chief Executive of Korea' from HeraldBiz Media and the '1st
Innovative Management Company' from Seoul Economic Newspaper. Recently, he also
received 'National Customer Satisfaction Management Award'. He was given this
prestigious award in recognition of the high-quality domain registration
operation of his company and his devotion to internet service development based
on RFID and IPv6.


  Chang Hun Lee

Chang Hun Lee is a CEO of Cydentity, one of the top innovative internet solution
providers in Korea and one of the ICANN Accredited Registrars. He started his
career at Samsung Electronics (UK) and Northern Development Company in United
Kingdom. In 2000, he was appointed as ICANN Business Constituency Member. He has
been acting as ICANN Registrar Constituency Member and URI (Uniform Resource
Identifier) Forum advisor of NIDA. He holds a BA and Master degree in
International Business from Newcastle Business School in UK. Internet related
activities: He has actively participated in the wide range of international
conference such as ICANN, ITU, IETF, MINC, APRICOT, and APTLD as well as Korean
Internet organization; NC, NNC and TTA. In 2002, he led a DotOrg Re-delegation
bidding Project as Technical & Operating Backend solution provider and involved
in professional projects regarding on domain development such as DotAsia
Project, EPP application for KRNIC domain registration system, and collaborative
ccTLD Name Servers.


  Alan Levin

Futurist and development engineer. Bachelor of Science (Computer Science)
completed in 1990 and MBA in 1995. Alan spearheads a number of Internet
developments in Africa relating to domain names. Alan operates AfriDNS to
examine the competence of all African country code domains. Installed anycast
copy of various root servers. Chairman of the Internet Society South Africa
chapter. Treasurer of the .za DNA, member of the AfriNIC board and founding
treasurer of the Public Interest Registry. Operates a number of nameservers
hosted in the US, Europe and Africa.

  Overall System Design
  =====================

The registry system designated for .net as proposed by CORE++ consists of
several components distributed around the world. The main component in this
setup is the shared registry system (SRS). Its purpose is to manage the domain
repository, to process the requests from the registrars and to supply data to
name servers and the Whois servers. There are two identical, independent
instances of the SRS at different geographic locations. The so-called "main"
site is responsible for normal operation, while the "mirror" site is used as a
backup in case of a complete failure of the main site. The other components are
the name servers, the support centers, the Whois servers and the registry web
site, which are also distributed around the world. All components are
interconnected via a virtual private network. The topology of the VPN reflects
the independence of the main and mirror SRS site: each other component is
equipped with a separate VPN connection to both SRS sites.

This section does not cover data center aspects, please see sections
2.3.(b).(iii) for details concerning Internet connectivity and 2.5.(b).(xiii)
for thorough information on security precautions.


  Main/Mirror Shared Registry System Design
  =========================================

The main system is designed to allow high security, reliability and throughput.
A combined firewall, intrusion detection system and VPN represents the gateway
between the inner SRS networking and the Internet respectively the
infrastructure of the hosting data center. The servers that process the RRP and
EPP requests are connected via load balancers and the firewall to the Internet
on the one hand and to the internal network backbone on the other hand. To this
internal backbone network, the two database subsystems are connected, as well as
the backup system, the FTP/E-Mail server, OT+E system and other systems
described below.

The gateway consists of a redundant pair of Juniper NetScreen-5000 series units.
These state-of-the-art devices provide means to protect the SRS from a large
variety of denial of service attacks and other attacks (like port scans),
providing a high data throughput at the same time. They also handle the virtual
private network connections to the other sites. Externally, two redundant
connections to the Internet infrastructure (i.e. to two different
switches/routers of the data center) provide failsafe operation. Internally, the
gateway is connected to

  * the demilitarized zone 1, which is accessible by registrars only. It is
    connected to the RRP/EPP servers via the load balancers

  * the demilitarized zone 2, which allows traffic from/to the registrars and
    authorized entities (FTP) and to the whole Internet (SMTP for e-mail
    delivery, DNS for Name Server Sanity Checks and HTTP/HTTPS for the web
    servers). Also, the OT+E system is connected to this zone

  * the internal backbone network to allow traffic from/to other CORE++ sites
    that are connected via VPN


The redundant load balancers, based on F5 Networks BIG-IP systems, distribute
the RRP/EPP requests of the registrars and RPC requests of the web server to the
systems that perform the processing. Due to the ability to alter the
distribution dynamically, a failing system can quickly be removed from the
distribution. Also, this allows a gentle shutdown of a system for hardware and
software maintenance (like patching): New connections are routed to different
systems and existing connections can be shut down on the protocol level (as
defined in RFC 3734 and RFC 2832).

A set of three HP Integrity rx7620-16 servers form the so-called "EPP/RRP
Servers" group, which is responsible for processing RRP and EPP requests from
the registrars as well as RPC requests of the web server that are related to the
proposed Domain Protection Service. Instead of using fewer systems that contain
the maximum number of processors (sixteen), more systems with less-than-maximum
number (eight) of processors are used. This has the advantages that in case of
an outage of a system, the loss of overall performance is lower on the one hand,
and that it gives the opportunity to increase the computational power by adding
processors to compensate short to medium term load increases on the other hand.
Medium to long term load increases can be accomplished either by adding
additional servers to the set or by replacing the existing servers with more
powerful members of the HP Integrity family. If required, the servers may also
be extended by adding memory. Initially, the systems are equipped with 64 GByte
memory.

Two databases are designated for the SRS site. For details, see section
2.5.(b).(v).

Two dedicated backup servers (HP Integrity rx2620-2 with 2 CPUs and 16 GByte
memory) are responsible for backing up the databases (transaction logs, data
dumps) as well as the built-in hard drives of all servers. They are connected to
a RAID system (Ignite server) and to an Ultrium based tape library (Storage Data
Protector server), respectively. See section 2.5.(b).(x) for details.

Besides the mentioned components, additional HP Integrity rx2620-2 servers (also
equipped with 2 CPUs and 16 GByte memory) perform various tasks that are
described in the following. While they have dedicated responsibilities for the
normal operation, these responsibilities can be delegated to other systems to
cope with an outage of one of these systems. In addition, a sufficiently
equipped spare system is available that can replace one of these servers as well
as one of the earlier mentioned EPP/RRP servers.

One server is dedicated to the aspects of the zone generation, as well as to the
report generation. The zone generation includes the various processes described
in sections 2.5.(b).(vii) and 2.5.(b).(viii). Zone files and reports that are
produced for the registrars and other authorized entities are transferred to the
FTP server.

The billing/administration server performs various tasks regarding registrar
accounting and administration, like monitoring, configuration management and
access control.

The OT+E server is the playground for the registrars to test the
interoperability of their systems with the SRS. It not only provides RRP/EPP
functionality, but also Whois, Web, FTP and DNS servers that operate on test
data.

A server that is connected to the demilitarized zone 2 is dedicated to operate
as an FTP server and as an SMTP server for outgoing e-mails (e.g. transfer
notifications) and to perform the name server checks for the implementation of
the Name Server Sanity Check service. Both this server and the OT+E server are
not directly connected to the internal backbone network to avoid further damage
if these systems have been compromized. Instead, the traffic to the other
systems is routed through the firewall to filter attempts to gain access to
other systems.

A cluster of two HP Integrity rx7620-16 servers (8 CPUs, 64 GByte), also
connected to the demilitarized zone 2, provides web pages and web interfaces for
registrars, registrants and other interested parties. If the web interface
requires access to the SRS data repository (e.g. if a registrar requests
information about an object), it communicates with the EPP/RRP servers via RPC
mechanisms. Also, as the web interface provides a Whois service, the cluster
maintains its own copy of the Whois data in its own database. The cluster on the
mirror site is also used as a fallback solution if the designated Whois
server(s) are unavailable to provide their service for some reason. The cluster
is equipped with a RAID system.

All internal and external (i.e. to the data center) network cabling is using
copper Gigabit Ethernet technology. To avoid a single point of failure within
the networking of the SRS, a double network approach is used -- all network
components like Ethernet interfaces at the servers, cabling and switches, exist
twice. Additional interconnections between these two instances enhance the
stability and reduce the risk of an SRS service interruption due to networking
problems. The use of managed switches allows the detection of problems of the
devices themselves as well as of the cabling before they have impact on the
operation. The usage of the Spanning Tree Protocol ensures quick failover
recovery. All network components as well as the servers support both IPv4 and
IPv6 communication protocols.

The data centers hosting the main and mirror sites provide at least Gigabit
bandwith to multiple global exchange points.


  Whois Server Design
  ===================

The Whois server consists of a cluster of two HP Integrity rx7620-16 systems (8
CPUs, 64 GByte), connected to a RAID system. The systems gain access to the
Internet resp. data center infrastructure via a redundant pair of Juniper
NetScreen 500 devices, which provide firewall, IDS and VPN functionality. One
node of the cluster is designated to operate the Whois database, while the other
is designated to run the Whois server application software. In case of a failure
of one system, the remaining system performs both tasks. The design also offers
appropriate scalability: If need be, the cluster nodes can be upgraded with
additional processors and memory to compensate increased load demands.

Similar to the SRS site, the Whois server uses copper Gigabit Ethernet for
internal cabling and for the connection to the hosting data center. Also, the
data center provides at least Gigabit bandwidth to multiple global exchange
points. All network components as well as the servers support both IPv4 and IPv6
communication protocols.


  Master Domain Name Server
  =========================

The operation of the master domain name server is based on the following
foundation.

  * Providing Zone file: Master domain name server gets the zone file from the
    SRS system, and propagetes the zone file to slave domain name servers. Zone
    file has an information of .net domain names, their associated name server
    names, and the IP addresses for those name servers.

  * Name server: The name server resolves DotNet domain name queries. It will
    provide their associated name server names and the IP addresses of those
    name servers. The name servers are dynamically updated upon the changes of
    the SRS Database. Updates are sent over the VPN Registry Management Network.

  * Network redundancy: Dual redundant switched Gigabit Ethernet LAN-based
    connectivity for all network devices will be provided in the data center.

  * Firewall: Protects the network from the Internet hacking and denial of
    service attacks with a firewall that provides policy-based IP filtering and
    network-based intrusion detection services.

  * Load Balancers: The traffics into a name servers are load balanced by
    clustering the servers. The balancing policies will be one of the common
    protocols such as least connections, weighted least connections, round
    robin, weighted round robin, and etc.

  * Remote Access: Dual-homed access links to Internet Service Providers (ISPs)
    and Virtual Private Network (VPN) services are used for the connectivity to
    the Internet and the Primary DNS Management Network.



  Server Farm Components

  * Monitoring Server: monitoring name server and DB Server

  * Name Server: handles resolution of DotNet domain names, DNS Query Processing

  * Database Server: stores Zone Data and other information



  Hardware Configuration

  * Router: Cisco 10000 Series Gigabit Switch Router, High-performance IP
    services, Carrier-class high availability, Maximum scalability, Hot
    Swappable. The Cisco 10000 Series supports Parallel Express Forwarding
    (PXF), patented by Cisco. PXF offers customers the ability to turn on
    multiple IP services while maintaining line-rate performance. PXF is
    software-based; customers can add new service functions without swapping out
    hardware. The Cisco 10000 Series supports many critical edge services,
    including quality of service (QoS), Multiprotocol Label Switching (MPLS),
    Multilink Point-to-Point Protocol (MLPPP), broadband aggregation, and access
    control lists (ACLs). Full hardware redundancy, online insertion and removal
    (OIR), Cisco Route Processor Redundancy Plus (RPR+), Cisco Stateful
    Switchover (SSO), and Cisco Nonstop Forwarding (NSF) are the key features of
    the Cisco 10000 Series that make it a premier Cisco carrier-class platform.

  * Switch: Cisco Catalyst 6500 Series, Gigabit Switch The Cisco Enhanced
    FlexWAN module offers the ability to consolidate LAN, WAN, and MAN services
    into a single platform and lowers the total cost of ownership of the network
    through simplified design and ease of network management and maintenance.
    The unique value proposition of the Cisco Catalyst 6500 Series is the
    convergence supported from the physical layer to a highly scalable
    application layer. These two platforms can scale from 10 Megabit Ethernet to
    10 Gigabit Ethernet in the LAN and DS-0 to OC-48/STM-16 in the WAN.

  * Firewall: NetScreen 5000 Series Gigabit Firewall, The Juniper Networks
    NetScreen-5000 Series is a line of purpose built, high-performance security
    systems designed to deliver a new level of high-performance capabilities for
    large enterprise, carrier, and data center networks. The NetScreen-5000
    Series security systems integrate firewall, DoS and DDoS protection, VPN,
    and traffic management functionality in low profile modular chassis. The
    NetScreen-5000 Series offers excellent scalability and flexibility while
    providing high levels of security through NetScreen's custom operating
    system, NetScreen ScreenOS. The NetScreen-5000 Series employs a switch
    fabric for data exchange and separate multi-bus channel for control
    information, delivering scalable performance for the most demanding
    environments.

  * Load Balancer: Alteon Application Switch (L4~L7 Load Balancing Switch)
    enables application optimization, delivery, and high availability through
    the use of sophisticated application/device load balancing, intelligent
    traffic management, application redirection, application-layer security,
    security acceleration, and bandwidth management.

  * VPN: The Juniper Networks NetScreen-SA 1000 Series of SSL VPNs enables to
    deploy cost-effective remote access, extranet and intranet security, all
    from a single platform. The NetScreen-SA 1000 Series is based on the Instant
    Virtual Extranet (IVE) platform, which uses SSL, the security protocol found
    in all standard Web browsers, as a secure access transport mechanism. The
    use of SSL eliminates the need for client software deployment, changes to
    internal servers, and costly ongoing maintenance.

  * Name Server(8eu/1site) : IBM x335 Server, Rack-optimized 1U, Two-way Intel®
    XeonTM processor (512KB L2 cache) capable, Two PCI-X 64-bit/100MHz slots,
    Support for 2 IDE or 2 Hot-swap Ultra 320 SCSI hard disk drives, Integrated
    RAID 1 for mirroring, Integrated dual 10/100/1000 Ethernet, Memory (std/max)
    512MB or 1GB/8GB PC2100 ECC DDR1 Maximum internal storage 293.6GB2 Ultra320
    SCSI or 240GB IDE

  * Monitoring Server(2eu/1site) : IBM x335 Server

  * Database Server(2eu/1site) : IBM pSeries 650, Rack-optimized 1U , 2-way, 4-
    way, 6-way and 8-way configurations, POWER4+ microprocessors with L3 cache -
    Provide improved system performance and higher reliability in a smaller,
    more efficient dual-processor chip, Enable capacity to grow to eight
    processors. High memory and I/O bandwidth, Up to 64GB ChipkillTM ECC, bit-
    steering memory, Up to 63 hot-plug or 55 hot-plug/blind-swap PCI/PCI-X
    adapter slots, Hot-swappable disk and media bays, Redundant hot-plug power
    and cooling subsystems, IBM @server Cluster 1600, Dynamic processor and PCI
    bus slot deallocation.



  Slave Name Servers
  ==================

Under the coordination of ISC, CORE++ operates slave name servers with the help
of third-party name server providers. All systems are maintained to the same
standards as the root nameservers, including carefully controlled access,
industry standard operating systems and procedures for limiting exposure to both
compromise attacks and denial of service attacks, as well as a great deal of
experience with prevention, mitigation, and recovery from attacks. This includes
physical security according to industry standards for major network
infrastructure.

Each CORE++ .net DNS operator will control its own infrastructure, with
auditing, oversight, and final approval by CORE++. The initial hardware/software
used for .net DNS publication will be as follows:

  * EP.NET - Intel Xeon; Linux; ISC BIND9

  * Cogent - Intel Xeon; FreeBSD; ISC BIND8

  * ISC - AMD Opteron; FreeBSD; ISC BIND9

  * Autonomica - AMD Opteron; Linux; ISC BIND9

  * Speedera - Linux; Intel; AMD Opteron; ISC BIND9.


By making infrastructure a local choice for each .net operator, CORE++ plans to
maximize leverage on local expertise, and ensure architectural diversity
avoiding "single mode of failure" scenarios.

As pointed out above, CORE++'s DNS master server for .net will be located at
NIDA, and will be a redundant set, one of two master servers. Zone transfers
from these redundant servers to the public slave servers operated by CORE++'s
.net DNS Operators will be authenticated using the DNS TSIG protocol, and both
the master server and all slave servers will support the DNS IXFR protocol for
rapid updates.

Each CORE++ .NET DNS location will be served by diverse IP network transit
connectivity, including service from CORE++ subcontractor Telefonica.


  Support Center Design
  =====================

Each service center operates a server (HP Integrity rx2620-2 with 2 CPUs and 16
GByte memory) that performs various administrative tasks, like e-mail exchange
(equipped with spam and virus filters), provision of request trackers, VoIP
services, web proxy services, access control and similar. The server as well as
the workstations of the support center staff are connected to the Internet via a
redundant pair of Juniper Netscreen 200 series devices. They provide firewall
and IDS services plus VPN interconnection to the other sites.

Additional information on support center characteristics is provided in section
2.5.(b).(xix).

  Overview
  ========

The domain name service designated for .net by CORE++ is coordinated by the
Internet Systems Consortium. Being the developers of the well-known BIND name
server software as well as the operator of the f-root name server, ISC has an
outstanding reputation regarding DNS expertise. Maximum stability and
performance for the .net DNS system is thereby guaranteed. The master name
server of .net is managed by NIDA, which also has considerable experience in the
field of DNS, particularly via its operation of one of root and top level domain
name servers.

CORE++ will deploy DNSSEC in .net as soon as IETF publishes stable RFC's and all
of contracted .net DNS operators have completed implementation testing. Each
CORE++ .net DNS location will be served by diverse IP network transit
connectivity, including service from CORE++ subcontractor Telefonica.


  DNS Providers
  =============


  NIDA
  ----


  Availability

The DNS Service is the most critical service of the registry, and there should
be no downtimes at all. The hardware, software and geographic redundancy built
into the DNS service provided by NIDA will reduce down times to zero. NIDA
assures a DNS service availability of 99.9999%. See 2.5.(b).(i) for details
concerning the redundant master name server setup.


  Performance Level

The domain name server at NIDA is designed to handle load of queries for DNS
data that is three times the measured daily peak (averaged over the monthly
timeframe) of such requests on the most loaded name server. So, in case of
failure of 2/3 all domain name servers, the remaining 1/3 domain name servers
are capable of handling the load of all DNS queries.

Name server round-trip time and packet loss from the Internet are important
elements of the quality of service provided by the Registry Operator.

Each primary domain name system center scales from dual 1Gbps network
connectivity, and easily processes more than 100 percent reserve capacity. A
total packet loss of less than 5% is assured.

See also 2.5.(b).(xiv).


  ISC
  ---

The name servers managed by ISC are operated under the same general conditions
and standards as the name server providing resolution of the root zone. This
includes carefully controlled access, industry standard operating systems and
procedures for limiting exposure to both compromise attacks and denial of
service attacks, as well as a great deal of experience with prevention,
mitigation, and recovery from attacks. This setup guarantees that response times
and packet loss targets, having a level equivalent to the root name servers,
easily surpass the minimum requirements as specified in Appendix D.

The variety of experienced DNS operators engaged, along with the distribution of
their facilities around the world, provide a high degree of diversity and
redundancy, with no "no single point of failure" and "no single mode of
failure".

Initially, 26 name servers will be serving the .net zone worldwide. The use of
anycast methodology further enhances the reliability and extensibility of the
name server setup, thus providing a large number of available authoritative name
servers. Please refer to section 2.3.(b).(iii) for a list of name server
locations.

The slave name servers are using the DNS IXFR, authenticated via the DNS TSIG
protocol, for synchronization with the master name server, ensuring rapid DNS
updates and zone integrity.


  Zone Monitoring and Accuracy Checking
  =====================================

Among other things, section 2.5 Appendix D contains the performance
specifications for the .net name servers operated by CORE++ and its service
providers, especially in terms of resolution performance and allowed outages. To
ensure the designated level of service, CORE++ installs extensive DNS monitoring
facilities that continuously check DNS availability and performance and notify
the .net support staff immediately as soon as alleged problems are detected.

To further improve overall resolution stability, various kinds of zone accuracy
checks are performed. This includes a plausiblity test which uses heuristical
methods to verify the reasonability and size of a generated .net zone. In
addition, the overall .net resolution quality is enhanced by the proposed "name
server sanity check" feature, which enables registrars to be notified of common
delegation problems. Details concerning the "name server sanity check" feature
are given in section 2.3.(a).

Operational scalability is primarily achieved by the underlying architecture of
the systems comprising the .net registry. The scalability measures offered by
the various systems are described in the following.


  Shared Registry System

The software used for the processing of EPP and RRP commands is designed to run
on multiple systems simultaneously. Due to the fact that the software makes
extensive use of Java's multi-threading capabilities, it scales well with the
number of processors in each system. Therefore, long-term scalability due to
increased registry activity can be accomplished by extending the system with
additional processors and/or machines.

Based on the numbers from the .net reports, the SRS is dimensioned to run with
about 10 % load during regular operation. In section 2.5.(b).(v), it is
estimated (for database capacity purposes) that the number of .net domains
doubles within the first two years of .net operation by CORE++. It can be
assumed that the number of commands that need to be processed per time period
scales linearly with the total number of .net domains. Therefore, the initial
system is able to handle the additional load resulting from increased domain
numbers. To further cope with temporary unexpected load peaks, CORE++ ensures
that at least 100 % spare capacity is available all the time.

As the SRS itself does not process any e-mails, the system is not affected by
the spam problem.


  Database Systems

Scalability aspects of the used database systems are discussed in detail in
section 2.5.(b).(v).


  Domain Name Servers

In´general, all contracted name server operators are required to provide
suitable scalability. Increasing load is handled by

  * Adding network peers and, over time, transit providers. CORE++ starts with
    enough bandwidth to handle current and projected load for a long time;
    increasing connectivity is no complex problem for any DNS operator.

  * Adding systems to existing sites or, as needed, new sites to join anycast
    clouds. New CPU/network capacity can be easily added at almost any time.


The distribution of name server operation among several independent providers,
resulting in the usage of multiple hardware and software environments, reduces
the risk of complete DNS outages caused by new viruses or undiscovered exploits.


  Whois Server

Similar to the SRS system, the Whois server and its database are designed to run
at about 10 % load initially and to provide at least 100 % spare capacity. Like
the database used for the SRS, the Whois server database is also equipped with a
RAID system that provides the required potential for the improvement of hard
disc capacity and performance. Moreover, the cluster used for the Whois server
can be extended by adding processors and memory, which provides additional
scalability.

Half a year after the transition of .net registry operations to CORE++, a second
Whois server is established in South Africa. This second server further improves
the reliability of the Whois service, as well as its ability to cope with
increasing load demands.


  Support Centers

The support centers are receiving e-mails from registrars and are thus exposed
to virus and spam threats. They are therefore equipped with virus and spam
filters to protect themselves against these menaces.


  Security Precautions
  --------------------

The use of a firewall and an intrusion detection system at each site minimizes
the risk of distributed denial of service attacks, virus and worm infection.
Inter-site communication of system components is performed via Virtual Private
Networks (VPNs), shielding the data traffic from malicious manipulation. Refer
to section 2.5.(b).(xiii) for further details concerning security.


  Restart capabilities
  --------------------

CORE++ takes various precautions to reduce the risk of an unanticipated outage
of any system that is crucial to registry operations, see section 2.5.(b).(xvi)
for details. However, in spite of e.g. the presence of spare and backup systems
for all critical components, such an outage cannot be completely excluded. It is
therefore important that, once the problem that caused the outage is fixed, any
affected system can quickly be restarted and thus be brought back online in a
fast manner.


  SRS Software

The Shared Registry System software implemented by CORE++ manages the entire
data repository in the database, using a highly transactional scheme. This
prevents any task that was processed at the time of system shutdown from leaving
partial, potentially inconsistent results in the repository. Thus no cleanup
procedures need to be performed on restart that might delay the recovery, which
enables the application to be restarted within one minute (given the
availability of the database).


  Whois Server Software

In general, the software that implements the Whois server is restarted within
less than a minute. While an outage of the Whois server might require an
additional resynchronization with the SRS's data repository, the actual Whois
query processing is resumed immediately after the restart.


  Database

Due to the use of transaction logs, all involved database systems are able to
restore transactional integrity after a restart without significant delay. This
means that the availability of the data repositories used by e.g. the SRS and
the Whois server can quickly be restored after a problem that made a database
shutdown necessary. It is anticipated that a restart of the production database
is accomplished within two minutes. In the unexpected event that the primary
database server cannot be brought up again, the secondary database server can
immediately take over the duties.


  Servers

The HP-UX operating system used to run the various servers, including the
EPP/RRP and database servers, provides a journaling file system that allows a
fast file system check after reboot even in case of an unclean shutdown, e.g.
due to a system crash or a power supply failure. A complete reboot of such a
server is usually done within four minutes.


  Firewalls, Load Balancers, Switches

The time required for the restart of these network components is typically less
than one minute.


  Scalability of Resources
  ------------------------

CORE++ achieves a high degree of scalability thanks to its two-level structure.
The coordinating organization (CORE++ SL) outsources technical operations to the
functional organizations in charge of clearly defined tasks. All of them are
redundant, i.e. there are two or more organizations for a given task, all of
which with substantial stand-by resources. In case of higher-than-expected need
for any given resource, additional staff and physical resource can be brought in
immediately. This is particularly useful in case of a temporary drain on
resources.

The attached organigram shows the set-up for the principal functions.

  Shared Registry System

The .net registry operated by CORE++ offers a shared registry system that
accepts network connections from registrars on a 24/7 basis. Connecting
registrars may submit commands using the RRP or EPP registry-registrar
protocols. Additional information for registrars is provided by regularly
generated reports downloadable via FTP.


  Thin Registry vs. Thick Registry Model

CORE++ supports both the thin and the thick registry model for .net. Registrars
may choose to keep contact data for their domains locally (thin model) or to
upload contact information for some or all of their domains and maintain the
associated contacts at the registry henceforth (thick model). As depicted in
detail in section 2.2.(b), this may be chosen on a per-domain basis. Usage of
the thick registry model requires that the registrar switches to EPP before,
however.


  RRP

As previously described, CORE++ continues to support RRP as a registrar-registry
protocol for one year after the .net migration in July 2005. After that year of
transition, all .net registrars will have to have migrated to EPP.


  EPP

Shortly after the resumption of normal registry operation, registrars are given
the opportunity to switch from RRP to EPP for their registrar-registry
transactions. They may take their time to do so, because RRP is supported for a
full year after the .net transition. As mentioned above, switching to EPP does
not require a simultaneous switch from the thin to the thick registry model -
registrars may choose to remain within the thin registry model while using EPP
to manage their domain repository.

Please refer to section 2.2.(b) for an exhaustive description of registry-
registar protocol issues.


  Support for Localized Contact Data in EPP

The EPP implementation provided by CORE++ for .net supports the use of localized
contact information. This means that the registry evaluates and stores localized
contact information specified (in unrestricted UTF-8) by an EPP
contact:postalInfo element with its type attribute set to "loc". Refer to RFC
3733 for details. If specified by the registrar, localized contact information
is displayed in the Whois output and delivered within the results to an EPP
contact:info command.


  Reports

In addition to the realtime facilities offered by the EPP/RRP support described
above, the SRS also communicates with registrars via reports, e.g. to provide
transfer or autorenewal related information. These reports are generated by the
SRS on a regular basis and made available for registrars by a dedicated FTP
server. As mentioned above, both the contents of the reports and the directory
structure of the FTP server is chosen to match the setup of the current .net
operator to facilitate the transition for .net registrars.


  Processing Times

The processing times for standard queries are given in section 2.5 Appendix D.
Add/create, modify/update, transfer and delete operations are considered as
write operations, while check and info commands represent read operations in
this context.

For a thorough coverage of the duration of any planned and unplanned outages,
please refer to sections 2.5 Appendix D and E. Devised recovery procedures,
along with estimates concerning the time required to recover from various
failures, are described in section 2.5.(b).(xviii).

  Database Software

CORE++ uses Sybase Adaptive Server Enterprise (ASE) as the Database Management
System Software for permanent storage of all repository data managed or used by
the SRS and Whois servers, respectively. Sybase ranges among the world's top
five database vendors, offering enterprise database solutions with competitive
performance, stability and sophistication for years. Their Adaptive Server
Enterprise product supports a wide range of hardware platforms and operating
systems, which reduces the risk of being stuck to a particular platform, thus
gaining more flexibility for dealing with future .net developments. Moreover,
the product offers excellent interoperability, most notably with Hewlett-
Packard's ServiceGuard clustering technology designated to be used for .net
registry operation. Support contracts with Sybase guarantee the fast
availability of professional technical support from the software vendor if need
be. CORE++ has gained positive experience with the deployment, operation and
maintenance of Sybase database products, using them for the CORE Registry
Gateway as well as the .aero/.museum registry systems. Last but not least,
Sybase particularly delivers good results in Total Cost of Ownership (TCO)
considerations.


  Database System Layout

Both SRS sites (main site and mirror site) are equipped with two database
servers (primary and secondary server) each. The primary database server, which
is used under normal conditions, is a cluster of two HP Integrity rx7620-16
servers connected to a common RAID system. It is operated in a "hot standby"
configuration, where the machines monitor each other and take over the database
operation in case of the failure of the other system. The secondary database
server is a single (non-clustered) machine, but equally equipped and connected
to a separate RAID system. Using Sybase Replication Server, the data of the two
database servers is kept in sync. The primary database server operates as the
primary replication server in this context (allowing read and write access),
while the secondary server operates in standby mode (offering read-only access
for performing supplemental tasks like report generation and similar services,
if need be). This configuration ensures low impact of database failures on the
availability of the registry for the registrars; switchover between the cluster
nodes is performed within 30 seconds. The switchover to the secondary system is
done equally fast. As transactional database programming techniques always
require to implement the ability to repeat a transaction that has failed for
some reason, the switchover is handled gracefully by the registry software. The
secondary server is also used to host the database of the OT+E registry system.

The mirror site's primary database server is also kept in sync with the primary
database server of the main site using Sybase Replication Server. This means
that, from a data management perspective, the mirror site can instantly take
over the operation in case of a complete failure of the main site.

Both main and mirror site's primary database servers are backed up using Sybase
Backup Server software. The secondary servers may be restored using the dumps
from the respective primary servers. See section 2.5.(b).(x) for more
information on database backup procedures.


  Scalability

The used system design is able to cope with the current and future demands of
.net, based on the projected growth that is described in section 2.4. As
database servers, multi-processor systems are used which are initially equipped
with a number of processors suitable for the mid-term .net load and which can be
extended with additional processors to adapt to long-term requirements -- due to
its multi-engine support, the Sybase database software is capable of making full
use of the available processors. Similarly, the RAID systems can be equipped
with additional, faster and/or larger hard disks. These measures ensure the
scalability required for future .net developments.

For short term load peaks, the database is scaled to cope with at least 200 % of
the daily maximum load.


  Database Size

At the time of writing, the .net registry contains about 5 million domains.
While the CORE++ business plan is based on the worst case scenario of zero
growth (constant number of .net domains), the database capacity is planned
according to the assumption that the number of .net domains will double within
the first two years after the .net transition, which corresponds to a growth of
9 % per quarter. According to the Verisign reports of January up to August 2004,
the quarterly increase of .net domains is currently approximately 4 %. Hence the
estimate provides enough margin to cope with additional growth that may emerge
from the proposed new .net services and promotional campaigns.

Due to the storage of all historical data for domain, host and contact (thick
registry) objects, not only the total number of .net domains is important to
estimate the database size. Because every successful write operation creates a
new version of the affected object(s) in the database, the number of these
operations must also be considered. Calculations based on Verisign's monthly
.net reports, along with a reasonable safety margin, yield that the lifetime of
a .net domain is approximately 5 years on the average. The registry retains data
of deleted domains for one additional year. Moreover, data from PIR's monthly
reports, which are used instead of Verisign's reports here to avoid impact of
"hammering" (see section 2.3.(a), 'Auction Model'), reveal that each domain
(along with its associated host and contact objects) is, on the average,
modified 8 times a year. This results in an average of 25 versions for each
domain that exist in the database. Calculating with the aspired number of 10
million .net domains and reasonable estimates regarding the space required by a
domain within the domain, host and contact tables (and the associated indices),
the total database size amounts to about 3 Terabytes. The RAID system designated
for the database server is able to handle up to 8 Terabytes of storage space,
thus offering sufficient scalability to cope with future developments.


  Database Performance

In general, the performance of the various products of database vendors is hard
to compare. While benchmark comparisons like the ones made available by the
Transaction Processing Performance Council (TPC) may help to create a coarse
classification, it must be stated that the benefit of those benchmarks for the
design of a database system (hardware/software setup) for a concrete application
is quite low. The abstract performance values provided by e.g. the TPC-C
benchmark can hardly be transferred to the actual transaction patterns of a
given database application without making a considerable number of questionable
assumptions and estimates. The fact that database performance heavily depends on
the used hardware and the fine tuning of used components makes helpful
comparisons even more difficult.

Nevertheless, the TPC results clearly indicate that Sybase is undoubtedly able
to compete with other players in the enterprise database market. Sybase Adaptive
Server Enterprise has been used by CORE for mission critical applications for
several years, meeting the high requirements regarding throughput and response
time performance. Furthermore, the choice of database hardware designated for
the .net registry has been done in consideration of the experiences gained from
the Sybase-driven operation of the CORE Registry Gateway and the .aero/.museum
registries as well as the different magnitudes of the existing activities
compared to the .net operation.


  High-Level Database Design

As a general principle, all persistent registry data is stored in the database.
The database is used by different components of the system, like the shared
registry component or the accounting component.

The so-called core data tables hold the authoritative registry data, like the
domain names, host and contact data. For each data object, multiple versions are
retained, i.e. if a domain object is modified, the existing version is not
overwritten, but a new version is created instead. The experience has shown the
benefit of being able to review the history of domain, host and contact objects,
especially in case of disputes or for issue tracking purposes. The versions that
become "historic" are stored in separate tables to maintain a high speed access
to the current objects.

The processing of EPP and RRP commands submitted by the registrars result in the
modification of the core data tables. Along with the new object versions, the
commands (as well as the responses) that have been performed to create them (the
so-called "write" operations) are stored in the database, too. In contrast,
commands that perform read operations only, like domain info or check requests,
are not stored. As they do not modify the repository, there is no need to keep
them for auditing purposes.

Besides the command processors, other components of the registry system, like
DNS zone generator, Whois server feed, report generators or web interface
require access to the data with different usage patterns. Some of these
components require extensive "bulk" access to the data, i.e. operate on large
subsets. Due to the nature of transactional databases, this bears the risk of
blocking the database by these operations, which would have impact on the
accessibility of the registry for registrars. To avoid this, these components
work on their own copies of the core data. The special design of the core data
tables ensures a quick and non-blocking synchronization between them and their
copies. Other components have different access patterns and work directly on the
core data tables; for these components, table and index design are specially
tailored to allow efficient operation.

To allow a flexible implementation of period related policies and asynchronous
procedures, a general state machine concept is used. It provides a framework for
the stepwise, event driven execution of long-term tasks. Dedicated database
tables keep track of task progress, event consumption and objects referenced by
a specific task.

One important application of this mechanism is the implementation of inter-
registrar domain transfers. Dedicated database tables are devised to keep track
of pending transfers and the associated domains and registrars. The involved
asynchronous processes, such as the automatic acknowledge of transfers after the
5-day reply period, are handled by long-term state machines.

Grace periods, e.g. for domain addition and renewal, are dealt with by special
date columns in the domain tables that clearly identify the eligibility of the
object with respect to a specific grace period rule. If the system determines
that a grace period is applicable for an operation, the billing subsystem is
consulted to identify the book entry that is related to the refundable
operation. As a safety check, it is additionally verified that this book entry
has not already been refunded. If a refund has been approved, an additional
refunding book entry is created and the corresponding date columns in the domain
tables are cleared. As described in section 2.2.(b), CORE++ supplies registrars
with supplemental information about granted grace period refunds within EPP
responses.


  Change Notifications

If a registrar's object repository within the database is modified, the
registrar is always informed about this change by at least one of the following
means:

  * In case of changes that directly (i.e., synchronously) result from an EPP or
    RRP command, the result code delivered with the registry server's response
    to the command indicates the repository change.

  * Notifications about aynchronous changes (like outgoing or incoming transfer
    completions) are provided by poll messages which registrars can obtain by
    using the EPP poll command.

  * Asynchronous changes are additionally indicated in report files that are
    generated on a regular basis and can be downloaded by registrars via FTP.

  Overview
  --------

With respect to the importance of the toplevel domain .net and due to the fact
that it is widely used by network operators providing important services, it has
been of greatest concern in the planning process to ensure exhaustive network
coverage and geographical distribution.

One of the main ideas while outlining the structure of CORE++ was to create a
global solution with participants from all parts of the world. The same global
approach concerns the covered network topology.


  Geographic Network Coverage
  ---------------------------

Each partners runs parts of the registry system, be it the SRS itself, the name
servers, the Whois server or other facilities used for internal coordination.
The main SRS site is located in Europe (Germany), while the mirror SRS site has
its home in Asia (South Korea).

Name servers are provided in

  * the USA (8 servers),

  * Japan (2 servers),

  * Australia (1 server),

  * Belgium (1 server),

  * China (1 server),

  * France (1 server),

  * Germany (1 server),

  * Great Britain (1 server),

  * India (1 server),

  * Ireland (1 server),

  * Italy (1 server),

  * Malaysia (1 server),

  * the Netherlands (1 server),

  * New Zealand (1 server),

  * Spain (1 server),

  * Sweden (1 server),

  * Switzerland (1 server) and

  * Taiwan (1 server).


In addition to this geographical diversity, the CORE++ name servers are also
widely distributed in terms of network topology. The use of anycast methods
further enhances overall resolution availability and speed.

The Whois server in operated in Brazil. A second instance is planned in South
Africa.

The CORE++ support centers are located in Korea, Brazil and Switzerland. This
global distribution enables CORE++ to provide native language support for most
registrars.


  Support for Growing and Emerging Markets
  ----------------------------------------

The global approach of CORE++ enables the .net registry to react to upcoming
trends and economical development in a flexible way. The structure of CORE++
allows additional partners to be integrated at a later point in time to further
enhance this high degree of adaptability.

In particular, due to its extensive presence in Asia, CORE++ is well prepared to
cope with the demands that arise from the economical growth currently observed
in that area.

CORE++ implements a near-realtime update of its name server system with an
update interval of less than five minutes. With five million domain names and
increasing, this requires special precautions throughout the whole system,
starting at the management of the core data, ending at the name servers
themselves. An established way to achieve this is the principle of incremental
processing. In this model, the previous results are not discarded and the
process is not performed on the whole dataset in each iteration. Instead, old
results are retained and the subset that requires updates is determined. Taking
the numbers of the PIR registry in April 2004 as an example -- 1,33 million write
operations on domain names and hosts per month, which are about 150 write
operations per five minute interval, compared to about three million domains in
this month -- demonstrates the potential of this approach. Actually much larger
magnitudes are assumed to cope with peak loads, e.g. by bulk updates registrars
tend to perform from time to time.

The zone generation is also influenced by the emerging DNSSEC standard.
Fortunately, the zone does not need to be signed as a whole. Instead, individual
record sets are signed independently of each other. This fits nicely into the
incremental zone generation model. The current draft "DNSSEC Operational
Practices" (draft-ietf-dnsop-dnssec-operational-practices-02.txt) recommends
lifetimes for key and zone signing keys as well as for the signatures of the DS
records. This makes a periodical update of the zone entries for domain names in
DNSSEC mode necessary. While the lifetimes of key and zone signing keys are
rather long-living with 13 months and 36 days, the draft recommends a duration
of only a few days for the signatures of the DS records. With an assumed five
day duration, five million domain names and 50% use of DNSSEC, this would result
in about 3500 signing operations (two per name) per interval. This is a
magnitude the zone generation system can easily handle. Actually, a use rate of
50% is rather high for the next few years, as the adoption of the DNSSEC
standard requires a complete update of the DNS infrastructure up to the end user
systems and will likely progress at a slow pace.

It needs to be noted that of course not all zone generation steps can be
performed in an incremental way and can benefit from it.

All edits that are submitted by the registrars via EPP and RRP requests are
applied to the so-called core data tables. These tables hold the authoritative
data of the registry. They are optimized to work efficiently with the EPP and
RRP servers on the one hand, and to work as a data source for other subsystems
on the other hand. Subsystems that need to work on bulk data, like the zone file
generation, do not operate directly on the core data tables. All known database
systems, including those working with multi-version data, use locking mechanisms
to manage simultaneous access to the data and the integrity of the data (ACID
properties). By using complex queries and updates on a large data set, there is
a high risk to lock out other users (like the EPP/RRP servers) for the duration
of the probably longer lasting operation. As the zone file generation does need
such complex operations, it works on its own copy of the data. At the beginning
of each iteration, a snapshot is taken by synchronizing these tables with the
core data tables. Only data that is required for zone generation is copied.
Contact data, for example, is not required. The mechanism is designed to have
the least possible impact regarding locking of the core data tables. Since the
zone file generation subsystem is the only user of its own tables, there is no
impact by locks that may be created there by the database.

After the synchronization, it is determined for which domain names the DNS
records need to be (re-)created. As mentioned above, this depends not only on
the edited core data tables, but also on DNSSEC related factors, like the need
for refreshing signatures or doing rollovers of the registry's zone signing
keys. As the proposed DNSSEC standard requires to identify the gaps in the name
space (in the current drafts via the NSEC records, alternatives are in
discussion), it needs to be determined also whether these gaps have changed.

The next step is to create all missing DNS records and to sign them, if DNSSEC
has been enabled for the related domain name.

The final step is to determine differences to older zone files, which are still
stored in the database, in order to create the necessary data that is required
for the support of the IXFR protocol. Finally, the complete and incremental zone
files are exported to the file system in the required formats for further usage.

During the entire process, extensive information about its progress and detected
problems and anomalies is logged. In addition, various sanity checks are
performed at the end that ensure the completeness and integrity of the generated
zone files. If any suspicious conditions, problems and similar have been
detected, they are brought to immediate attention to a responsible technician.
In the worst case, the technician can delay or suspend the distribution of the
zone files, in order to avoid defective data to be propagated to and published
by the name servers.

The whole process is performed in the secure environment of the registry. Direct
access to the zone file generation and distribution process is granted only to
specially trained and trusted fraction of the maintenance staff, which also
monitors the process continuously. As described in detail in section
2.5.(b).(xiii), exhaustive user authentication procedures are applied to prevent
access by unauthorized personnel. Determined by their respective level, members
of the support staff are provided with limited, secured possibilities to alter
the data repository (and thus the zone file) in order to fulfill their duties.
The authentication of the registrars that perform edits on the core data is
handled at the EPP/RRP level, see section 2.5.(iv) also. Any support requests
sent by registrars via e-mail, fax or phone are authenticated using a previously
negotiated security pass phrase. The authentication for editing DNSSEC related
data (keys resp. their hashes) is done in the context of protected registration;
see section 2.3.(a) for details about this service.

Depending on the outcome of the negotiations with Verisign about the migration
of the name servers, it may be that during the transition phase the process of
the zone file generation differs from the way described above, especially the
interval may be considerably longer.

Being part of the database content, core data tables and tables related to the
zone file generation are backed up, replicated and escrowed, see sections
2.5.(v), 2.5.(x) and 2.5.(xi). The generated zone files are backed up in the
context of general system backup (see also 2.5.(x)).

Once the zone files have been generated and verified, they are distributed to
the name servers. For the upload of the most recent zone, the IXFR and NOTIFY
protocols, as described in RFC 1995 and RFC 1996, are used. The communication
between the registry and the master name server takes place over an encrypted
VPN connection, guarded by firewalls. This limits access to the respective
systems, preventing other systems from using the related IP addresses and ports.
To ensure the authenticity and the integrity of the communication, it is guarded
by the TSIG protocol (RFC 2845), with different keys for each name server.

Each name server operator also has access to recent zone files, formatted as
described in RFC 1035 and respective RFCs of the DNS extensions. These can be
used for new systems or systems that have been put off-line for maintenance.

As soon as a new zone file has been generated, each name server is triggered via
a NOTIFY message to pull the zone from the master. After the transfer of the
zone data, the registry tests the name server via the publicly available
interface address. The test is performed by querying the SOA record and various
random records that have been updated in the most recent zone file. When all
name servers have been updated, the iteration is declared as completed.

The master name server is connected to both the main registry system and the
mirror registry system via the VPN. In the case of a switchover from the main
registry site to the mirror registry site, the name server receives the
notifications from the mirror site and pulls the zone data from there.

  Billing Procedures
  ------------------

The registry maintains an account for each registar. All registrations,
transfers, renewals and other billable operations have to be prepaid, and
corresponding fees are deducted from the registrar's account.

Whenever a billable operation is attempted, the registrar's account is first
checked for sufficient funds. If the account is lacking the required funds, the
operation is rejected. A corresponding result code is returned if the rejection
affects a realtime EPP/RRP command, as opposed to e.g. an internal autorenew
operation that was not directly triggered by a registrar command. However, the
autorenewal of expired domains is treated differently; to avoid accidental
domain deletions, autorenewals are continued even in case of insufficient
registrar funds. Non-billable operations (like all read-only commands) and
activities that trigger refunds are always executed, regardless of the
registrar's account balance.

If sufficient funds are available, the operation is executed and the registrar's
account is charged with the corresponding fee (if the operation was completed
successfully).

Each registrar may provide an account balance threshold value. The billing
subsystem will automatically send an e-mail containing a "low account balance
warning" to the registrar whenever the registrar's funds drop below the
configured threshold value.

Some commands, like domain deletions or transfer cancellations, result in
refunds if corresponding grace periods apply. The affected registrar's account
is immediately credited for each refund.


  Billing Reports
  ---------------

For each registrar, billing report files are generated on a monthly basis and
made available for download via FTP. These reports contain detailed information
about every single billing operation that has been performed on the registrar's
account (including refunds).

To facilitate the transition for .net registrars, billing reports provided by
the current .net operator are continued to be generated and are provided in the
same manner as before (i.e. generation frequency, file format and location
within the FTP server's directory structure will be preserved for maximum
backward compatibility).


  Implementation of the Billing Subsystem
  ---------------------------------------

The billing subsystem of the SRS implemented by CORE++ uses several dedicated
database tables to manage

  * registrar accounts (including current balance and warning threshold),

  * tariffs for billable operations along with their validity periods and

  * book entries (each one representing a single credit or debit).


In addition, the tables comprising the actual object repository contain
supplemental columns to keep track of corresponding grace period deadlines. More
information concering the grace period implementation is provided in section
2.5.(b).(v).

The SRS component responsible for actual registry operation communicates with
the billing subsystem via the database. Any billable or refundable event (such
as domain creation, domain deletion within grace period, request for domain
transfer, domain renewal or autorenewal) results in the lookup of a suitable
tariff in the tariff table, the creation of a corresponding record in the book
entry table and the update of the registar's account.

The entire implementation is carefully designed to ensure billing accuracy. The
checking for sufficient funds as well as the processing of book entries
representing the billable events are always done within the same database
transaction that performs the actual billable repository change, thus ensuring
transactional integrity and account consistency.


  Registrar Web Interface
  -----------------------

Registrars may login to an SSL secured web interface within the registrar
extranet that provides extensive access to billing related issues, such as

  * information on the registrar's current account balance,

  * an overview of present book entries (including various options for sorting,
    aggregation, filtering and searching),

  * a listing of all billing events associated with a particular domain,

  * a listing of money deposits received from the registrar by the registry and

  * web forms that allow for the change of the warning threshold, e-mail
    addresses and other billing related contact information.


In addition, the registrar may retrieve the past invoices online. Two
representations are available, Adobe PDF (Portable Document Format) and an XML
format suitable for automated processing by the registrar.


  Registry Support Web Interface
  ------------------------------

The billing department within the registry's support staff has access to a web
interface that provides tools for the management of registrar accounts. This
includes the addition or removal of an account and the update of account
settings which cannot be modified by the registrar itself. In particular, the
support web interface is used to credit the balance for a registrar that has
placed a deposit, i.e. submitted money to the registry.

Special security precautions are taken to prevent the sensitive billing
subsystem and its web interface from unauthorized use. This includes the
restriction to SSL-based connections as well as IP address based access control.
Any registrar related account transaction must be confirmed by an authorized
supervisor.


  Additional services
  -------------------

As already described above, CORE++ provides additional services that facilitate
the task of keeping track of billing issues for registrars. In particular, this
includes the per-domain account statement available via the web interface (see
above) and the EPP extension that supplies registrars with operation cost/refund
and "total cost of domain ownership" information within the response to a
billable EPP command. See section 2.3.(a) for a detailed description of these
services and extensions.


  Available Payment Methods
  -------------------------

CORE++ will give the registrar the choice between two possibilities for the
mandatory prepayment.

  * The registrar can wire the money to the registry. Besides having to provide
    his address and his company name, the registrar has to identify himself on
    the remark fields of the wire with his IANA registrar id.

  * The registrar can pay by a standby letter of credit. The letter has to
    comply with the international forms of L/C.


The registrars are responsible for payment delays which could arise from bank
holidays in the involved regions. The currency always is United States Dollar.

  Overview
  ========

CORE++ uses three different types of backup systems:

  * File system backup

  * Database backup

  * General system backup


Every type meets special demands. Independent, identical installations are
present at the main site (Frankfurt) and at the mirror site (Seoul). Details on
each of the three backup systems are provided in the following sections.

It should be noted that the backup systems are not related to the possibility to
manage historic data. The history of SRS repository objects, e.g. changes of a
domain, are retrievable by other means (see 2.5.(b).(v)). Historic versions of
the registry software are retrievable via the used revision control system
(CVS).


  File system backup
  ==================


  Software
  --------

CORE++ uses a commercial backup software solution from HP (HP OpenView Storage
Data Protector, formally known as OmniBackup II). It is one of the most commonly
used backup solutions in heterogenous infrastructures with medium and large
volumes of data.

The software uses a client-server approach; it is multi-platform enabled and
clients are available for all common operating systems. On every client system
that needs to be backed up, so-called disk agents are installed that communicate
with the server. Client installation and maintenance (updates, patches) can be
done remotely. The management can be done through consoles (X-Windows, MS
Windows, CLI). The server is configurable for automatic backup; if offers
possibilities for full backup as well as different levels of incremental backup.

The software is able to backup/restore multiple systems in parallel. It takes
network bandwith and usage into consideration and is capable of distributing
data streams to multiple physical devices at the same time. Different levels of
user and group privileges exist. If so configured, a workstation user can
retrieve his own files. Sensitive data is only available to persons with the
appropriate access rights.

Although Data Protector uses a proprietary data format for storage, data
retrieval should not pose a problem as the software has a large user base. It is
unlikely that a vendor problem might render the tapes useless. The software is
cluster-aware, i.e. data accessible through different nodes of a cluster is
backed up only once.

The solution has been used to backup CORE's application and database servers for
several years.


  Hardware
  --------

Data Protector is usable with different media. A medium can be e.g. a tape or a
harddrive. CORE++ uses Ultrium type libraries (HP StorageWorks MSL6000 Tape
Library). The libraries are scalable and can be adopted to different usage
patterns. CORE++ uses one library per site, each equipped with 2 drives and 60
slots. The connection to the backup host is done via fibre channel.

Ultrium is an industry standard. One tape has a capacity of 200 GB
(uncompressed). The transfer rate is 60 MB/sec. The Ultrium drives are equipped
with on-the-fly hardware compression that causes no noticeable reduction of the
backup speed.

Supplemental to the library, an additional single drive is placed in every
location. This drive can be used as a fallback solution in case of library
unavailability.


  Usage and Configuration
  -----------------------

All systems in a location (see 2.3.(b).(i)) are backed up regularly. This
includes the SRS itself, but also the whois servers, the OT+E system and the web
server. The designated backup frequency is as follows:

  * A full backup is done every week.

  * An incremental backup is done every other day on "even" days, i.e. on the
    2nd, 4th, 6th etc. of the month. These backups depend on the full backup and
    not on the previous incremental backup.

  * Every other day on "odd" days, i.e. on the 1st, 3rd, 5th etc. of a month, an
    incremental backup is done in relation to the full or most recent "even"
    backup.


This scheme reduces the number of required tapes in the event of a restore and
therefore reduces the required time.

It should be noted that these file-based backups are not utilized to bootstrap a
crashed server. This is done with the third backup method (general system
backup, see below).

The backup tapes are never deleted. They are stored in a secure, fireproof
location within the data center. In regular intervals, the tapes are sent to the
escrow agent of CORE++, Iron Mountain, Inc., or one of its subsidiaries for
further storage.


  Database backup
  ===============

The used database software from Sybase is capable of full and incremental data
dumps. The dumps can be compressed on the database level. CORE++ uses level 4 of
compression, which is a good compromise between the achieved compression rate
(between 70% and 90%) and the increase of time for the backup/restore caused by
the compression (which is hardly noticeable for this level).

Full database dumps are done on a daily basis, with a 12-hour offset between the
Frankfurt and Seoul locations. The incremental dumps of the transaction logs are
done half-hourly.

The dumps are located in a special area of the file system of the database
server (as a matter of course, on the central RAID system). They are deleted 5
days after their creation. This mechanism ensures that the dumps are directly
available without the requirement to make use of tapes. In additon, this
filesystem area is also backed up with the means of the described backup system
above. Thus, every full backup and incremental transaction log is available on
tapes for later usage.

To restore a database from scratch, it is first checked whether all dumps from
the file system (see above) have survived the problem. If not, the required
files have to be restored from the tapes using the Data Protector solution.
Then, the most recent full database dump is loaded. Afterwards, all incremental
dumps that followed the full dump are applied to complete the restoration. With
this pattern, a restore of the database requires 48 files in the worst case (1
full, 47 increments). It is estimated that such a restore from scratch,
including retrieval of data from the tape, takes about 12 hours.


  General system backup
  =====================


  Overview
  --------

As mentioned above, the bootstrapping of a failed system is not feasible with a
filesystem backup. Another mechanism is designated for this purpose.

All servers are running with the commercial operating system HP-UX. The
operating system offers provisions for general system backups. The software is
called "Ignite" and can dump a complete system to a specified device. A device
can be a harddrive, a DVD writer, a tape or a network attached Ignite server.
Such a dump can be used to bootstrap a new system with exactly the same
parameters as the original system. In interactive mode, it can also be used to
clone one system, but change parameters like the IP addresses or reconfigure the
size of file systems etc.


  Usage and Configuration
  -----------------------

Both main and mirror sites are each equipped with a dedicated Ignite server. The
Ignite server is connected to the backbone via a Gigabit ethernet link; it is
equipped with its own RAID system, offering a data capacity of 3 Terabytes.

The Ignite server is used to store all recent operating system variants, as well
as patch bundles and other so-called software depots. The production servers use
the Ignite server as a data source for their maintenance tasks. In regular
intervals, the production servers dump their file system to the Ignite server.
It is intended to do this on a quarterly basis.

In case of need to restore a server, the following tasks have to be
accomplished:

 1. Restore the server with his latest dump from the Ignite server. This is the
    same process as installing a new system.

 2. Restore the files to the latest version, using the file system backup (see
    above).

It should be noted that this task can take some hours. However, this does not
mean that the service provided by the affected server is unavailable, since
every service consists of at least a couple of two servers that can replace each
other.


  Test run
  ========

All the above scenarios of recovering a system, individual files or databases
will be tested in regular intervals. These recovery tests will be performed on
an internal test system.


  Data Center Provisions
  ======================

The Telefonica data center provides the following services to assist the backup
tasks:

  * Manual tape operations as necessary

  * Acquisition and availability of the needed physical tape media to perform
    the service for the client

  * Tape media replacement and recycling

  * Off-site storage (In a monthly basis, Telefonica Data, takes the tapes to
    another facility)

  * Ability to scale quickly and efficiently

  Arrangements for Data Escrow
  ----------------------------

In addition to the backup measures described in section 2.5.(b).(x), CORE++
establishes an escrow account with Iron Mountain, Inc. Iron Mountain is one of
the world's leading providers for outsourced records and information management
services.

CORE++ will deposit, on a regular basis, a complete set of registry data (in a
format agreed upon by CORE++ and ICANN) at the facilities of Iron Mountain. The
used data format supplies sufficient information to permit a complete
restoration of the registry's data repository in case of data loss at both the
registry's main and mirror SRS sites.

Please refer to section 2.5 Appendix R, "Data Escrow Specification", for a
detailed description of the devised data escrow procedures, including plans for
the exact escrow schedule, the used data format, the data transfer process as
well as data verification measures.


  Backup Plans for Data Recovery
  ------------------------------

CORE++ has devised exhaustive plans for the recovery of registry data if
required, utilizing data retrieved from the escrow provider if need be.

Supplemental to these failsafe recovery plans, CORE++ will take adequate
liability insurance coverage. As a yet-to-be-formed entity, this cannot be done
at the present stage, but La Bâloise, a well-considered Swiss insurance company,
has been charged with preparing the relevant policies, and corresponding
provisions are included in the budget. Please note that the subcontractors
already have such insurance coverage for their own activities.

Please refer to section 2.5.(b).(xviii), "System Recovery Procedures", for an in-
depth discussion of all data recovery measures involving the backup and escrow
mechanisms used by CORE++.

  Overview

The .net registry system implemented by CORE++ includes a publicly accessible
Whois service that provides information on registry repository objects via the
"Whois" protocol on TCP port 43 as well as via a web interface. As already
described above, the designated Whois implementation incorporates (among other
things)

  * dedicated Sybase databases for each whois server,

  * continuous, fast data synchronization via a special "Whois feed" protocol
    capable of automatic recovery after disconnection,

  * support for both the "thin" and "thick" registry models, including a
    referral mechanism for coordination with the Whois servers of registrars and

  * CRISP/IRIS support no later that half a year after the finalization of these
    standards.


Please refer to section 2.5, Appendix O ("Whois Specification") for full details
concerning these and other features. Please refer to section 2.2.(b) for the
reasoning of the choice to support both "thin" and "thick" models.


  Hardware and Internet Connectivity

Derived from the numbers VeriSign has published in their public monthly reports
of the .com/.net registry, a peak load of about 8 million Whois requests per day
is expected at the beginning of the CORE++ registry operation. With an estimated
response size of 3 kBytes (the size of the query is typically less than 50 bytes
and negligible), a bandwidth of about 2.3 MBits/sec is required for the current
load. With an additional 100% spare capacity and a growth equal to the growth of
the number of domains, which is assumed to double within the first two years
(see also 2.5.(b).(v)), the minimum bandwidth that is considered as sufficient
is 10 MBits/sec. As the Whois server is connected via Gigabit Ethernet to the
data center/Internet, this bandwidth can easily be supplied to the Whois server.

For the designated hardware and its scalability, please refer to sections
2.5.(b).(i) and 2.5.(b).(iii).


  Support for Data Disclosure Preferences

The EPP 1.0 standard, particularly its contact mapping as described in RFC 3733,
provides means for registrars to specify their preferences concerning the
handling of contact data submitted to the registry (in contexts where the
"thick" registry model is used). Using optional contact:disclose elements when
creating or modifying contacts, the registrar is able to identify contact fields
that require special handling regarding their disclosure to third parties.

The Whois service implemented by CORE++ is designed to respect the data
disclosure preferences specified by registrars using these mechanisms. Unless
registry policy dictates otherwise, contact fields will be included in or
excluded from the Whois output according to the respective disclosure setting.

[RESPONSE IS CONFIDENTIAL]

  SRS Components
  ==============

The load of the SRS components is mainly dependent on the number of requests
sent by the registrars. For estimations, both the reports for the .com/.net
registry operated by VeriSign and the .org registry operated by PIR (formerly
also operated by VeriSign) have been taken into account. The switch from RRP to
EPP will result in an increased load: on the one hand, more requests will be
sent by the registrars due to the fact that the "thick" registrar model is
supported and contacts will be created, modified and deleted. On the other hand,
due to the use of XML, the requests are larger and need more processing time
(parsing and construction). With the introduction of the auction service (see
section 2.3.(a)), whose main purpose is to make the hammering of registrars
fruitless, a considerable reduction of the number of requests is expected.
However, for the worst-case analysis, this positive effect is not considered.

If a potential load peak can be foreseen, e.g. as a side effect of the
introduction of a new service or the start of a promotion campaign, the impact
is evaluated and it is analysed whether the systems can cope with it or whether
an upgrade of the resources (hardware, network infrastructure) is required. The
same applies to increased traffic that is announced by registrars in accordance
to the respective requirement of the service level agreement, see section 2.5
Appendix E.


  Short Term Peak Capabilities
  ----------------------------


  EPP/RRP Servers

As described in section 2.5.(b).(iii), at least 100% spare capacity above the
daily maximum will be provided. Since the number of registrars is fixed (in
respect to the short period under observation), the number of connections per
registrar is limited to a certain amount and the number of parallel requests per
connection is limited to one, there is a maximum number of parallel requests
arriving at the system. While it is likely that in such a worst case situation
the spare capacity is completely consumed and the saturation of the computing
power will cause degraded performance, it can be guaranteed that the system will
not cease operation.


  Database

The database is designed to cope with 100 % additional load. See also section
2.5.(b).(v). If it turns out that the required capacity exceeds those reserves,
as a last resort backend processes like zone and report generation can be
reconfigured to use the secondary database instead, to gain relief on the
primary database until upgrade measures designated to handle a long-term load
increase (like processor and memory upgrade) make an impact.


  Backup Systems

The backup systems are rather unaffected by a short term peak. It may result in
larger incremental backups, but as there are no special size limitations to
them, the backup system will be unaffected by this. Also, a short term peak will
only slightly increase the overall data volume that needs to be backed up.


  Network Infrastructure

The available VeriSign reports for the .com/.net registries show a maximum
number of request of about 1.75 billion requests per month. Assuming an ample
request size of 500 Bytes for the RRP requests and a ratio of 1/7 of the .net
domains, this results in a required bandwith of roughly 400 kBits/sec. The
following factors are applied to this value: factor 2 to compensate variations
during the day and on weekends, factor 3 to take the larger size of EPP requests
and the larger number of requests (for managing contacts) into account, and
another factor 3 to cover additional traffic for the incremental update of the
name servers and Whois servers resulting from the request. This results in a
bandwidth of about 7.2 MBits/sec. Assuming a peak load of 300%, this amounts to
about 22 MBits/sec. As the SRS site is connected to the Internet via a 1
GBit/sec connection, a limitation of the operation of the SRS by the network
infrastructure is quite unlikely.

The main SRS is operated within the network of Telefónica. The data center in
Frankfurt has 3 STM-16 (OC-48) going out of the location and is able to absorb
peaks of more than a gigabit per second.

The backbone is made up of STM-64/STM-16 links and is also able to absorb large
amounts of peak traffic.

Telefónica's main backbone covers the following points:

  * Europe: Madrid, London, Paris. Frankfurt, Amsterdam

  * North America: New York, Miami, Washington D.C. (Ashburn), Chicago, Dallas,
    Palo Alto, Monterrey (mx)

  * South America: Saõ Paulo, Rio de Janeiro, Buenos Aires, Santiago de Chile,
    Lima, El Salvador / Guatemala


Along with various exchange points, this network coverage provides enough
bandwith capacity to all registrars, even in case of extraordinary SRS usage.


  Other Components

Other components are considered to be unaffected by short-term peaks.


  Long Term Peak Capabilities
  ---------------------------

As described in section 2.5.(b).(iii), a steady increase of the registry size is
anticipated. If it happens that the growth is much larger, the designated paths
for an intermediate system extension provide enough time to plan further system
extensions and redesigns and to put them into practice.


  Domain Name Servers
  ===================

CORE++ will closely analyze the traffic of the domain name servers to increase
the capacity. This subsection describes initial sizing and scalability of the
domain name servers in terms of network and servers.

CORE++ anticipates a peak load of 200,000 DNS queries per second at all name
servers. Recent VeriSign reports reveal that the current average load of .net
DNS queries amounts to about 40,000 queries per second. Using a peak factor of
300%, at least 120,000 requests must be expected in total. This means that the
design parameter of 200,000 queries leaves enough space for future development
of the load.


  Master Domain Name Server
  -------------------------

The domain name server cluster will be front-ended with load balancers to
distribute workload. The name server cluster is initially sized to handle three
times the anticipated steady-state workload. The entire zone will be held memory
resident. Processing capacity grows linearly by adding additional servers to the
cluster up to its total system capacity. CORE++ will closely monitor system
usage and will scale up as required.


  Slave Domain Name Servers
  -------------------------

Each domain name server is capable of processing at least 10,000 requests per
second. Given the planned number of more that 20 instances distributed
throughout the network, enough spare capacity is provided to deal with load
peaks.


  Whois Server
  ============

Similar to other components, the Whois server is designed to provide spare
capacity, as described in section 2.5.(b).(iii). Additional capacity will be
provided by a second Whois Server that is installed 6 to 12 months after the
transition. Also, an auxilliary Whois server can be installed on the mirror SRS
site if necessary. Despite this, any occurring peaks that are in no relation to
the total number of registered domains or the registrar activity, are closely
investigated. If a data mining/harvesting attempt is detected, the existing
countermeasures are improved accordingly.

The data center at NIC.BR is equipped with 2 POS-OC3 transit connections and one
GigEth connection to the IX where it peers with all major networks in the
region.


  Support Personnel
  =================

As a part of the regular audits of the technical support, it is determined
whether the size of the support staff is sufficient to handle the requests from
the registrars and other parties (e.g. registrants in the context of the
protected registration service). The same is done for maintenance personnel.
Depending on the outcome, new employees are hired and trained for their new job.
As an intermediate and quick solution, overhours and temporary reassignment of
employees may be used to compensate bottlenecks.


  Escrow Systems
  ==============

As mentioned above, peaks in registration activity have no significant effect on
the size of the registry repository in terms of order of magnitude. Therefore,
the estimated size of the escrow data should be affected in a critical way.
However, the contracts with the escrow provider are tailored to provide suitable
support for growing volume.

As outlined in the given performance specifications and the proposed service
level agreement (see sections 2.5., Appendix D and Appendix E for details),
CORE++ is committed to offer a high level of performance and reliability in
operating the .net registry. This section summarizes the measures taken by
CORE++ to achieve this quality of service.


  Reliability by System Architecture

The registry system implemented by CORE++ and its service providers is carefully
designed to avoid any single points of failure. Redundancy and fault tolerance
are provided for all involved systems, including hardware, applications,
databases and network components. In addition, the system's scalability and peak
capabilities guarantee constant availability and quick response times even in
cases where the load imposed on the system exceeds nominal levels.

Two complete, independent SRS installations are present in separate geographic
locations (Frankfurt, Germany and Seoul, South Korea). They ensure a quick
failover and a reliable resumption of SRS operations even in the unlikely event
of a complete site failure, e.g. due to natural or man-made desaster at one
location. Due to the large geographic distance of the two sites, it is even more
unlikely that both of them might be simultaneously affected by such an incident.

The designated domain name servers are widely distributed in terms of geography
and network topology, allowing for a fast and reliable resolution of .net domain
names.

The third-party software used by CORE++ consists of proven, enterprise-grade
solutions. Components like Adaptive Server Enterprise from Sybase (for the
database servers) or Sun's Java Platform (the basis for the entire SRS) provide
a stable and reliable basis for registry operations.

Please refer to sections 2.5.(b).(i), 2.5.(b).(ii), 2.5.(b).(iii), 2.5.(b).(v),
2.5.(b).(vi), 2.5.(b).(x), 2.5.(b).(xi), 2.5.(b).(xiii), 2.5.(b).(xiv),
2.5.(b).(xvi) and 2.5.(b).(xiii) for more details regarding these topics.


  Reliability by Engineering Methods

The level of service offered by a system heavily depends on the quality of the
used software. CORE++ has gained considerable experience in software development
and deployment, most notably during the development and operation of the
registry systems for the .aero and .museum top level domains and the domain
registration gateway for CORE, the Internet Council of Registrars. CORE++ is
aware that properties like correctness, robustness, stability and performance
are crucial for every software project. Therefore, special care is not only
taken when selecting the involved third-party software (see above). During the
development of all custom software (most notably the shared registry system
itself), the experienced development team of CORE++ uses state-of-the-art
frameworks, tools and engineering methods. See section 2.5.(a) for more
information.


  Reliability by Quality Assurance

In order to provide a smooth, reliable service, and especially to protect it
against the consequences of human errors, CORE++ deploys quality assurance
procedures at all levels of the registry operation:

  * Continuous monitoring of all systems is performed for instant problem
    detection.

  * Access to sensitive systems and critical modifications of these systems are
    only granted to suitably skilled personnel.

  * Operator's manuals and step-by-step instructions are provided for all
    typical maintenance tasks.

  * Extensive staff training and assessment make sure that all members of the
    personnel (development, support, operation, maintenance) are up to their
    duties.

  * Sophisticated testing methods ensure the quality of all developed software.


Details concerning these topics are provided in sections 2.5.(a),
2.5.(b).(xiii), 2.5.(b).(xvi), 2.5.(b).(xviii) and 2.5.(b).(xix).

  Data Center Precautions
  -----------------------

The data centers hosting the system components of the registry provide various
facilities to ensure a continuous operation, such as backup power supply,
technical and facility security. Refer to section 2.5.(b).(xiii) for more
details.


  Server Locations
  ----------------

The locations of the various data centers and the respectively hosted facilities
are described in 2.3.(b).(iii).


  Availability by Design
  ----------------------

The general system design, as described in 2.5.(b).(i), includes various
precautions to reduce the risk of outages. These are described in the following.


  Shared Registry System Site

The network infrastructure of the SRS is designed to compensate a failure of one
of its components. This is achieved by doubling these components, i.e. the
firewall/IDS/VPN system, the load balancer and the switches that represent the
internal backbone. They are operated in an active-active configuration. All
servers within the system are equipped with two Ethernet interfaces for each
logical connection. Where applicable, the components themselves are equipped
with redundant power supplies. The interconnection between the servers and the
network components provides redundant paths between each two nodes without a
single point of failure.

For the database system used by the SRS, a double redundancy is provided. First,
the database is hosted by a cluster consisting of two separate servers that are
connected to a common RAID subsystem. In case of an outage of one cluster node,
the other node automatically resumes the operation (hot standby). In addition to
this so-called "primary" database server, an additional non-clustered
"secondary" database is operated as a warm standby solution. For more details,
see section 2.5.(b).(v).

To process the EPP and RRP requests of the registrars, multiple systems are
provided which run the SRS software simultaneously. A load balancer distributes
the incoming requests to these systems. An outage of one server does not
interrupt the service. Although the available computing power is reduced by such
an outage, the provisioned spare capacities ensure that the overall performance
does not violate the service level agreement.

In the unlikely event of a simultaneous outage of multiple components that makes
it impossible to provide the service, or in case of natural/man-made disaster at
the "main" site in Frankfurt, a switchover to the "mirror" site in Seoul is
performed. Thanks to continuous database replication, the mirror site is
equipped with the entire data of the repository. Depending on the nature of the
main site's failure, a limited data loss regarding transactions that were
performed in the last few minutes of main site uptime may occur. Compared to the
damage caused by a long-term outage, this is considered as negligible.

The actual switchover procedure mainly consists of the following steps:

  * Complete shutdown of the main site, if necessary. Despite the failure, some
    components still may be in an operative state. To avoid interference with
    the mirror site, these must be deactivated.

  * IP address change of the DNS address records belonging to externally visible
    servers to the corresponding servers on the mirror site. To facilitate this,
    a short TTL setting will be used, and registrars are advised to use solely
    domain names (as opposed to IP addresses) to connect.

  * Name servers and Whois servers are reconfigured to use the mirror site as
    their data source.

  * At the mirror site, software components that have been in cold standby are
    launched. This includes the actual SRS system.


In addition, the registrars are informed about the switchover, enabling them to
adapt or restart their clients if necessary.


  Whois Server

The Whois server is hosted by a cluster of two nodes. Under normal conditions,
one of the nodes runs the actual Whois server software, while the other node is
used to operate the underlying database. In case of a failure of one node, the
remaining machine is able to take over the corresponding service. This is
accomplished by the use of HP's MC/ServiceGuard clustering software.

For the case of total site failure, provisions are made to run the Whois service
at the SRS mirror site. In addition, it is planned to add a dedicated Whois
mirror site within 6-12 months after the transition from VeriSign.


  Domain Name Servers

The huge number of different name server locations used by CORE++ for the .net
zone and the involved diversity (in terms of both geography and network
topology) provide a high degree of inherent protection against DNS outages. In
particular, the use of Anycast methodology ensures that a server will be able to
respond to requests as long as at least one of the sites in its Anycast cloud is
available. In addition, reliable facilities with sufficient redundance are
provided at the individual sites hosting the .net name servers.


  Registry Web Site

Similar to the Whois server, the web server consists of a cluster of two nodes.
The services running on this system, e.g., the public web site and the database
that is used for the web Whois service, are equally distributed in terms of the
load. Again, HP's MC/ServiceGuard software is used to perform the switchover of
any services from the failing node to the remaining node. Should both nodes fail
simultaneously at the main site, the services can be hosted by the mirror SRS
site instead.


  Monitoring
  ----------

Both hardware (servers, network components) as well as application software
(database software, SRS software, Whois server software etc.) are constantly
monitored using HP OpenView, a world-class enterprise management solution. The
handling of any reported failure is performed by the technical staff. To ensure
a high level of maintenance quality and speed, the following measures are taken:

  * Typical outage scenarios for each component are documented in an operator's
    manual, providing detailed steps for analysis and remedy of the described
    situations, including (but not limited to)

      * restart of software

      * reconfiguration of network components and servers

      * reboot of servers

      * replacement of defective harddrives and reassignment of spare drives
        within a RAID system

      * activation of the spare server

      * switch from the primary to the secondary database server

  * The technical staff is trained to understand the structure of the system and
    the interdependency of the components. Apart from that, typical failure
    scenarios are exercised. The training is repeated on a regular basis.

  * Occurring failures are documented by the technical staff. These error
    reports are reviewed within the scope of regular audits, eventually leading
    to additional instructions within the operator's manual and/or improvements
    of the system's architecture.



  Backups
  -------

If need be, all systems may be recovered using the established backup and
restore mechanisms. These mechanisms and the used software are described in
detail in section 2.5.(b).(x) and 2.5.(b).(xviii).


  Hardware supplies and Software Availability
  -------------------------------------------

The data centers will keep spare parts for all critical hardware involved, which
allows fast replacement in case of hardware failures. In addition, continuous
24/7 phone and on-site support from the vendors ensures the availability of
hardware and software, including operating systems. Contracts guarantee the
delivery of components that ran out of stock within hours.

  IDN Support
  ===========

CORE++ supports Internationalized Domain Names (IDNs) in the same manner as they
are provided by the current .net operator. This applies to all components of the
system, including (but not limited to) the SRS, the Whois server and the domain
name servers. The well-established Punycode encoding is used for all systems and
protocols that are not capable of working with non-ASCII characters. Support for
IDN-related RRP extensions and conventions that are already in use for .net is
continued. The EPP implementation will also support IDNs.

IDN character variants are treated in the same way as the are currently handled
in .net. This means that all new IDN registrations are submitted in conjunction
with a language tag that denotes the language associated with the IDN
registration. For each registrar, a default language tag is maintained that is
used if the registrar doesn't specify an explicit tag value via RRP/EPP for a
particular IDN registration.

The language tag is used to look up a variant mapping table for the denoted
language. Mapping tables do not exist for all available languages. If, however,
a matching mapping table is present, it is used to look up all applicable
variants belonging to the given IDN. Along with the domain name in question,
these variants are blocked from subsequent registration. Vice versa,
registrations of domain names that are associated with an already blocked
variant in the given language are rejected. Implementation specifics concerning
variants are adapted to the current behavior of VeriSign's .net registry system,
as far as information about this behavior is publicly available,

Existing .net IDNs are taken over from the data dumps provided by VeriSign
during the transition. The same applies to the used variant mapping tables. At
the time of writing, VeriSign uses mapping tables for various languages,
including simplified and traditional Chinese and Japanese. If the tables
currently used by VeriSign are not publicly available, CORE++ requests these
tables from VeriSign as part of the data dumps provided during the transition.
CORE++ also expects to receive information about each registrar's default
language tag along with the remaining .net registrar data.


  IPv6 Support
  ============

The registry system implemented by CORE++ provides full support for IPv6. Refer
to section 2.3.(a) for details concerning the implementation.

The backbone network of Telefónica, the data center provider for the main SRS,
is IPv6 capable using 6PE to encapsulate the IPv6 on MPLS. Telefónica peers in
London and Amsterdam with the main IPv6 players. We offer IPv6 connectivity in
all the places we are present.

The CORE++ member NIDA provides IPv6 support on all levels, i.e. for the mirror
SRS, on the Internet infrastructure as well as for the master name server on
both the DNS protocol and DNS interface level.


  DNSSEC Support
  ==============

CORE++ intends to implement the DNSSEC standard within half a year after
finalization of the related RFCs. See section 2.3.(a) for detailed information
regarding this topic.

  Overview
  --------

As described in various other sections, the registry system proposed by CORE++
offers exhaustive support for both the prevention of outages as well as the fast
recovery from an outage that could not be avoided in the first place. The most
important cornerstones of the system's fault tolerance are

  * uncompromising, redundant design for all systems (including the SRS site,
    the database systems, the Whois server, the DNS systems and the web site)
    using cold, warm and hot standby solutions as well as "hot-swap" components

  * repository data replication, both locally at the "main" SRS site as well as
    to the remote ("mirror") SRS site

  * a professional backup and escrow solution protecting against data loss

  * highly secured data centers equipped with uninterruptible power supplies and
    redundant network connections

  * multi-site architecture for fast failover in case of site failure

  * geographical diversity of the involved systems

  * extensive monitoring of all facilities


to name but a few.

These topics are discussed in more detail elsewhere. Please refer to section
2.5.(b).(xvi) for more information on system outage prevention. In-depth
descriptions of the involved redundancy/diversity measures can be found in
sections 2.5.(b).(i) and 2.5.(b).(v). Section 2.5.(b).(xv) contains additional
reliability considerations. The proposed backup procedures (including the used
backup software and media) and escrow solutions are presented in sections
2.5.(b).(x) and 2.5.(b).(xi), respectively.

The remainder of this chapter will therefore focus on the description of actual
recovery procedures for various expected or unexpected failure/outage scenarios,
the documentation of such procedures and provisions concerning the involved
staff.


  Outage scenarios
  ----------------

This section presents outage scenarios of various types and how the proposed
system - and the CORE++ support/maintenance staff if necessary - will cope with
them.


  Expected Outages

In some cases, the outage of a subsystem may be foreseen. This is especially the
case for events that are actually planned by the maintenance staff, e.g. a
scheduled maintenance of one of the multiple SRS systems attached to the load
balancer. Such cases are usually treated as a part of normal registry operation.
Depending on the nature of the failure, the maintenance may not even be
noticable by registrars or Internet users seeking to resolve .net names. In
terms of dealing with them, expected outages differ from the unexpected outages
described below in the following aspects:

  * Expected outages are planned events.

  * The date and time of their occurrance can be defined by the maintenance
    staff, which means that they can be scheduled with the convenience of
    registrars and/or Internet users in mind, i.e. on weekends.

  * They can be performed in a controlled way, i.e. a previous clean shutdown of
    the affected systems is possible.

  * In case of impact on registrars, expected outages can be announced in
    advance.


Otherwise, these outages are handled in the same way as the unexpected scenarios
below.


  Unexpected Outages

Unexpected outages are caused by unplanned failures of one or more system
components. As soon as such an outage has been detected by the monitoring
facilities, the registry's redundancy provisions - if necessary - are used to
deal with the problem. Depending on the nature of the failure, registrars and/or
Internet users using .net facilities may or may not be affected. Some types of
failures may require manual intervention by the CORE++ staff, while others may
be handled by an automatic failover to a standby system.

Depending on the severity and the required countermeasures, outage scenarios can
be categorized into several classes:

  * A) Failure of a subsystem that provides automatic failover:

    In case of the failure of such a subsystem, e.g. one of the SRS servers
    behind the load balancer or a hard drive within a RAID system, the automatic
    failover facilities will detect the failure and take the subsystem out of
    service. No interruption of registry services will happen, since other
    subsystems can immediately take over the duties of the failed one without
    the need for manual intervention.

    Maintenance staff alerted about the problem can repair or replace the
    subsystem at a scheduled point in time. Thanks to "hot-swap" facilities, the
    replacement can usually be accomplished without impact on registrars or
    Internet users. Even the complete reinstallation of a server, including its
    operating system, can quickly be accomplished via backups and the used
    Ignite technology, if need be.

    Depending on the nature of the failure, a slightly degraded registry
    performance may be encountered until the subsystem is replaced; e.g. if one
    of the SRS servers fails, the load balancer will dispatch requests from
    registrars to a lower number of systems, thus slightly increasing the load
    on these remaining systems.

  * B) Failure of a subsystem which replacement requires staff interaction:

    Some of the redundant subsystems are not intended to provide an automatic
    failover. If e.g. the primary database server should crash, the switchover
    to the secondary server (which is standing by with replicated repository
    data) is decided upon and done by the maintenance staff. In such a case, a
    short interruption of the affected registry services is usually unavoidable;
    it is estimated that, depending on the actual case, such an outage could
    have a duration from 5 up to 30 minutes. Therefore, a trouble ticket is
    opened immediately and the registrars are notified about the outage, its
    impact and the estimated duration.

    Before the switchover, any necessary measures are taken to ensure data
    integrity and other important system properties; e.g., in the case above,
    the SRS servers are taken offline to prevent any further interactions, and
    any pending updates are performed on the secondary database server. After
    that, the switchover is performed and all services that had to be shut down
    are launched again. The success of the switchover is verified. As soon as
    the registry has resumed normal operation, the trouble ticket is closed and
    the registrars are notified.

    Afterwards, the maintenance staff will restore the failed systems. If need
    be, a subsequent scheduled maintenance will be used to put the restored
    subsystem back into service. In any case, the outage is documented, and the
    way it was dealt with is assessed. The operator's manual is supplemented and
    additional staff training is scheduled if necessary.

  * C) Multiple failures that require a switchover to the mirror site:

    While unlikely, it is possible that multiple or all components of a
    redundant setup are failing simultaneously. This can normally only be caused
    by e.g. a natural or man-made desaster that destroys major parts of the
    affected site. In such cases, a switchover to the provided mirror site is
    considered and - if found necessary - performed by the maintenance staff. An
    interruption of registry services until the mirror site has been brought
    online is necessary in such an event. All measures regarding trouble
    tickets, registrar notifications and data integrity are taken as described
    in B) above. Due to the continuously performed data replication, the mirror
    site has all required repository data at its disposal and can quickly resume
    operations. It is estimated that registry operation can usually be resumed
    within two hours. As the mirror site is equipped with the same computing
    power as the main site, no degraded performance is encountered by registrars
    while registry operations are performed at the mirror site.

    After the registry has restarted all services, the replacement of the
    defective subsystems is immediately addressed, and the main site is
    reconstructed. As soon as possible, a maintenance is scheduled to move
    registry operations back to the main site.

    Outage evaluation is done as performed for outages of class B).

    Additional information about the site switching procedures is given in
    section 2.5.(b)(xvi).

  * D) Failure of both main and mirror site:

    Due to the fact that main and mirror site are placed at very distant
    geographical locations (Frankfurt, Germany and Seoul, South Korea), it is
    quite unlikely that both sites will be destroyed and fail simultaneously.
    However, if this happens, it can be assumed that a global problem has
    occurred that also affects many .net registrars. In order to preserve
    equality in access, it may therefore be considered adequate to suspend
    registration activities for a limited time to give registrars the
    opportunity to repair their equipment.

    CORE++ will use this period to restore the facilities at the main and the
    mirror site. If required, repository data will be restored using the
    available backups or by retrieving data from the escrow provider. Best
    efforts will be made to incorporate all registrar transactions that were
    issued shortly before the site destruction; if feasible, data restoration
    experts will be consulted and the restoration of data from damaged hard
    drives will be attempted. As a last resort, registry operations will be
    resumed after site restoration using the repository data from the most
    recent available backup or data escrow.

    As soon as at least one site has been restored, registrars are notified and
    registry operation continues.


While the cases C) and D) above are especially focused on an outage of the SRS,
A) and B) are also applicable for outages of other components, such as the
domain name servers, the Whois server and the registry web site.

If a failure of the facility hosting the Whois server occurs, a site switch
(similar to the one planned for the SRS) is also possible, since the SRS mirror
site is prepared to take over the operation of the Whois server in that case. A
similar approach is used for the servers hosting the registry web site. Since
the web server cluster on the mirror site is in warm standby mode and no
relevant state is stored on the web server itself, a switchover from the main
site to the mirror site can easily be accomplished. See section 2.5.(b).(xvi)
for more information.

The outage of a majority of the name server provided by CORE++ is very unlikely
due to high distributed design and the use of Anycast methodology. If an of one
name server occurs, DNS resolution is usually not disrupted. The restoration can
quickly be done, as complete zone files can be transferred from the SRS site by
the name server operator fast after the facilities have been brought up again.


  Documentation, Staff Availability and Training
  ----------------------------------------------

All procedures that have to be performed by the CORE++ maintenance staff in case
of typical outage situations are described in the operator's manual, which
provides contingency plans with detailed steps for analysis and recovery. As
mentioned above, all occurred outages are documented and evaluated in order to
supplement the operator's manual if necessary. The manual also contains
information on the detection of problems that might lead to outages, such as
important warnings from the monitoring system or suspicious messages in the
system's log file.

The entire registry system is designed with the KISS principle in mind, which
means that all components and their interdependencies are constructed as simple
and clear as possible. This makes diagnostics and maintenance easy and
facilitates a quick recovery from outages. In addition, it reduces the risk of
human errors while configuring the system, thus further improving the system's
reliability.

If the monitoring facilities detects an outage, first-level technical personnel
is notified immediately. If necessary, a member of the second-level technical
staff, equipped with in-depth knowledge about the system, is contacted via a
pager or a similar mechanism and deals with the problem. Problems which cannot
be solved by second-level staff are forwarded to the development team. The
trouble ticket system is used to coordinate these efforts.

Staff training ensures that the personnel dealing with outages and their
recovery is up to their tasks. Periodically, typical outage scenarios are
exercised to verify that monitoring, redundant facilities and personnel are
working as expected. Similarly, dry-runs for the switchover from the main site
to the mirror are performed on a regular basis.

General information about the designated support facilities and procedures is
given in section 2.2.(a). This section provides additional information by
focusing on specific aspects of the supplied support facilities.


  Registrar Extranet
  ------------------

The web site of CORE++ includes a password protected registrar extranet web site
that provides registrars with convenient access to relevant tools and materials,
such as

  * announcements of recent improvements, changes, maintenances or promotional
    programs,

  * support contact information,

  * frequently asked questions (FAQs),

  * downloads of technical registrar toolkits,

  * access to report files generated by the SRS,

  * object inventory lists (domains/contact/hosts),

  * billing information (see also section 2.5.(b)(ix)),

  * marketing materials and

  * facilities for web-based SRS interaction.



  Central Help Desk
  -----------------

In addition to implementing the website, CORE++ will provide telephone support
to our registrars through our central help desk. Access to the help desk
telephone support will be through an automatic call distributor that routes each
call to the next available customer support specialist.

CORE++ will authenticate callers requesting a pre-established pass phrase that
is different for each registrar. Requests for assistance may also come to the
help desk via either fax, e-mail or the secure website.


  Three-Tier Support
  ------------------

  * Tier-1 Support: Telephone support for the registry customers who normally
    are calling for help with domain name problems and other issues such as
    evaluation test. Problems that cannot be resolved at Tier 1 are escalated to
    Tier 2.

  * Tier-2 Support: Support provided by members of the Technical Support Team,
    who are functional experts in all aspects evaluation test. Tier 2 staff will
    provide technical support in system tuning and workload processing.

  * Tier-3 Support: Complex problem resolutions will be provided by on-site
    maintenance technicians, third-party systems, software experts, and vendors
    depending on the nature of the problem.


The trouble ticket syste will document the status of requests and tickets, and
it will notify the Help Desk when an SLA threshold is close to being breached.
Each customer support and technical support specialist will use the problem
management process to respond to trouble tickets with a troubleshooting,
diagnosis, and resolution procedure and a root-cause analysis. Tier-3 will be
provided by SRS Main System Staff.


  Issue Tracking
  --------------

As already described, CORE++ intends to use the Request Tracker (RT) system from
Best Pracical Solutions for internal and external issue tracking.

Tickets maintained by a non-public portion of the installed RT system are used
within CORE++ for internal issue tracking, task management, workflow control and
other aspects of collaboration between different sections and members of the
CORE++ staff. RT will particularly contribute to the coordination of the three
support centers and to the communication between support staff, data center
maintenance personnel and software developers.

The RT system also includes a public part that may be accessed by all .net
registrars via an e-mail or a web interface, enabling them to create new
tickets, add information to existing issues, close resolved cases or monitor the
progress of their inquiries. The system can be configured to send e-mails to
involved persons if any action has been taken concerning a particular ticket,
helping to keep all interested parties informed automatically.


  Staffing
  --------

Initially, CORE++ will staff its Help Desk with a complement of customer service
specialists, enabling us to operate three shifts providing 24 x 7 x 365
coverage. CORE++ will add staff as necessary to respond to incoming requests
within the service level agreement. Customer service specialists will obtain
assistance from the technical staff of CORE++ for any problems that cannot be
resolved in one phone call.


  Test and Evaluation Facility
  ----------------------------

CORE++ will establish an operational test-and-evaluation facility that will be
available 24 x 7 x 365 for registrars and delegees to test their client system.
Our Technical Support Team, which consists of functional experts in the
processes and technologies for domain name registration, will support the
registrars and delegees.

Once each new registrar/delegee is satisfied that its system is compatible with
the registry system, it will schedule a formal acceptance test that will be
monitored by our system engineer. After a registrar/delegee has passed the
acceptance test, CORE++ will issue its user ID, passwords, and digital
certificates. And then the registrar/delegee can begin its operations.


  Customer Satisfaction Survey
  ----------------------------

To determine customer satisfaction with registry services, CORE++ will implement
a web-based customer satisfaction survey that will consist of a set of survey
questions with responses.


  Registrar Workshops
  -------------------

As deemed required, e.g. due to new registry features that are planned to be
introduced, registrar workshops, teleconferences, web conferences are performed.