Afilias is one of the leading Internet domain registry services companies in 
the world, managing nearly 7,000,000 domain names and more than 50,000,000 
records.  Founded in 2000, the Company is the ICANN-designated Registry 
Operator for .INFO, and the provider of registry services to Public Interest 
Registry (PIR), the Registry Operator for .ORG.  In addition, Afilias provides 
registry services for seven ccTLDs (.AG (Antigua and Barbuda), .GI 
(Gibralter), .HN (Honduras), .IN (India), .LA (Laos), .SC (Seychelles), 
and .VC (St. Vincent and the Grenadines)).  Afilias has offices in North 
America, Europe and Asia, from which it serves more than 150 registrars across 
the globe with state-of-the-art service. 

The current .NET Registry Agreement specifies that "ICANN shall select as the 
successor Registry Operator the eligible party that it reasonably determines 
is best qualified to perform the registry function . . . taking into account 
all factors relevant to the stability of the Internet, promotion of 
competition, and maximization of consumer choice, including without 
limitation: functional capabilities and performance specifications proposed by 
the eligible party for its operation of the registry, the price at which 
registry services are proposed to be provided by the party, the relevant 
experience of the party, and the demonstrated ability of the party to manage 
domain name or similar databases at the required scale."  

Afilias excels in all of these areas through its proven technical expertise, 
extensive knowledge of the domain market, competitive pricing, and number of 
domains it serves.  In addition, Afilias is the only applicant involved in the 
bid that has conducted a seamless transition of a domain that approximates the 
size of .NET, which was the migration of .ORG from VeriSign to PIR in 2003.

Afilias' proposal ensures the most stable, secure and reliable operation 
of .NET:  

· Stronger DNS security:  Afilias' primary DNS provider, UltraDNS, has 
developed and implemented a new mechanism that enables normal query resolution 
even while under a crushing attack.  This new process enables on-the-fly 
identification of "Trusted Recursive Servers," which answer queries for 
Afilias' zones in a fully isolated and protected environment. This process 
currently supports Afilias' other domains and will dramatically improve .NET 
resilience, thereby strengthening security.

· Leading-edge DNS Platform: Afilias' functional capabilities and 
performance specifications include a proven, stable registry system and a 
redundant, scalable DNS network.  Its architecture is capable of managing more 
than 200,000,000 domain names and can handle in excess of 2 trillion directory 
service transactions each month. The number of simultaneous queries that can 
be processed through the network is at least 1,000,000 queries per second.

· Safe and seamless transition: Only Afilias can credibly assure a safe 
and secure migration of .NET.  As with .ORG in 2003, .NET must at least be 
upgraded to the EPP protocol, and may well also be moved to a new system and 
transitioned from "thin" to "thick."  Afilias pioneered these transitions 
with .ORG, making Afilias the only applicant with the crucial experience 
needed to 1) migrate a domain from VeriSign, 2) migrate a domain of this size; 
and 3) implement the upgrades required. No other registry provider has the 
needed experience to do this safely.

· Many registrars have already built systems to implement Afilias' 
migration approach, reducing their load versus an unfamiliar process with an 
inexperienced operator. To help registrars further, Afilias will provide a 
$0.25 per domain allowance to help offset migration expenses related to the 
EPP/Thick upgrades.

· Multiple suppliers: Afilias' operation of .NET would correct an 
unacceptable single point of potential failure on the Internet, posed by 
VeriSign and its proprietary systems.  VeriSign's monthly reports to ICANN 
show that whenever .COM is down, so is .NET, and vice versa.  Afilias' 
systems, by contrast, are designed to avoid single points of failure and 
capitalize on multiple suppliers.

· Enhanced reliability: Afilias' .INFO domain has the best SRS (shared 
registry system) availability record among all of the gTLDs, 
including .COM/.NET and .BIZ, based on January-September 2004 ICANN reports 
(which are the latest publicly available).  

Afilias has the strongest record of promoting competition, as it built .INFO 
from scratch into the sixth-largest TLD in the world in three years.  It is 
time to remove .NET from the shadow of .COM, and allow its growth to 
accelerate under Afilias' leadership.  .NET has the potential to offer 
consumers more choices and more savings, but only if it is properly managed by 
an experienced registry operator.  Afilias plans to immediately implement the 
following:

· Reduced price:  Afilias will reduce the .NET price from $6.00 to 
$3.25/domain year, on an ongoing basis.  The total registry price to 
registrars (including ICANN's $.75 fee) will be $4.00, which is a $2.00 
(33.3%) savings versus the current $6.00 price.  Over the term of the 
contract, registrars, and if passed through, registrants  may save as much as 
$60 million over the next six years.

· .NET Promotion:  Afilias will promote .NET by offering new 
registrations for only $1.00 during the first year of new registrations-- an 
83% reduction versus VeriSign's price (and a 96% reduction if the fee is not 
included).  The price includes the ICANN fee and will be in effect at least 
until 2006.  Afilias has conducted similar programs for .INFO, which have been 
highly successful.  

Afilias believes in responsible innovation, and will realign the NET registry 
with the interests of the ICANN community, including registrants, registrars 
and end-users, through both new and improved services and greater innovation:

· New and Improved Services:  Afilias will immediately provide four 
improvements to existing services: 1)  Upgrade .NET to EPP v1.0 for greater 
security; 2) Faster WHOIS updates to reduce the "spammer lag" in place today 
with VeriSign's 12-24 hour update schedule; 3) compliant IDN deployment, 
sharing tables with the IANA IDN Language-Table registry; and 4) creation of a 
thick registry, also for greater security.  In addition, we will use the PDP 
to explore new concepts such as:  an emergency rollback service to address 
suspicious modifications to domains; an auction approach to deleting names; 
and an expiration date synchronization service.

· Innovation:  Two important initiatives will help spur responsible 
innovation for .NET.

   - Formation of the Technical Advisory Group (TAG): Afilias has recruited
     recognized technical experts to serve on this body, which will provide
     advice on security, services and other technical matters critical to
     operation of the .NET domain and its users.  

   - Establishment of the Infrastructure Innovation Fund (IIF): Afilias will
     establish a $1,000,000 IIF to be placed at the disposal of the
     Technical Advisory Group for research, development, and testing and
     implementation trials.

Afilias is one of only three registry operators in the world that has 
demonstrated ability to manage domain name databases at the required scale 
of .NET:  

· The other two are VeriSign, which as the incumbent lacks the critical 
boost to competition, and DENIC, which lacks the transition experience, market 
expertise and agility that Afilias has to challenge VeriSign's dominant 
position.  

· The thick registry databases managed by Afilias consist of over 
50,000,000 records, which is the only registry whose scale comparable to the 
estimated 41,000,000 names in .COM/.NET managed today by VeriSign.

Afilias has the strongest track record of adhering to all ICANN policies.  It 
has played a leadership role in the development and implementation of ICANN 
policies, ranging from reservation of country names in .INFO to the new 
transfer policy.  Our philosophy is to work cooperatively with ICANN, 
standards bodies and the broader Internet community.  We avoid, for example, 
launching unilateral changes in DNS and registry operations.

As explained in the Proposal described below, Afilias meets or exceeds all of 
the RFP absolute criteria.  Afilias also excels at all of the relative 
criteria.  Our advantages include: 1) we will provide support in ten 
languages; 2) our transition plan is the ONLY one proven by relevant 
experience;  3) we propose a responsible approach to new registry services; 4) 
our technology exceeds the technical specifications in numerous areas; 5) we 
propose a price of $4.00 that is 33.3% percent lower than the incumbent and 
can save consumers up to $60 million, as well as a bold promotional price of 
$1.00 for new registrations; 6) competition will be best enhanced by Afilias, 
as innovative pricing and marketing strategies will best help ICANN promote 
robust competition; 7) our use of multiple suppliers avoids single points of 
failure; 8) we have the clearest and most dependable record of support for 
GNSO and ICANN policies; and (9) with the experience of supporting .ORG and 7 
ccTLDs, we have more -- quantitative and qualitative -- transition experience 
than anyone else.

While many of our competitors may be competent registry operators within their 
current operations, they do not provide the combined breadth or depth of 
service we offer, and they are not nearly as well qualified to transition or 
manage .NET.  Examples from the records of three potential applicants 
illustrate this point:

VeriSign has no comparable transition experience in migrating from RRP to EPP, 
which it is required to do. Note that migrating the database -- which a 
selection of VeriSign would avoid -- is only part of a transition. Upgrades 
from RRP to EPP and from "thin" to "thick" are far more complex procedures.  
Furthermore, VeriSign touts its recently deployed ATLAS system (which 
supports .NET) as very fast.  However, VeriSign plans for the ATLAS system to 
also handle billions of RFID, VoIP , COM and other TLD transactions, which 
will likely affect .NET performance and reliability.  VeriSign has already 
affected .NET (and .COM) stability by unilaterally introducing a wildcard 
service. Verisign ins on record saying it reserves the right to re-introduce 
the wildcard at any time. 

NeuLevel/NeuStar is similarly bereft of comparable transition experience.  
Adding more risk, NeuLevel has no experience managing domain volume of .NET 
magnitude.  Between .US and .BIZ, NeuLevel only manages about 2 million 
domains -- yet .BIZ had more SRS downtime in 2004 than .INFO did.  
Neulevel/NeuStar also introduced a wildcard service with the attendant impact 
on stability.  Although .BIZ and .INFO were started at about the same 
time, .BIZ is only about 1/3 the size of.INFO. 

DENIC has never managed a gTLD, and has no experience with an EPP-based domain 
registration system.  Despite the size of .DE, over 90% of DENIC's business is 
local, giving DENIC experience that is too limited to qualify it to run a 
global brand and operation such as .NET. Operationally, DENIC's system 
faltered upon its launch of IDNs in 2004, and historically DENIC has not 
provided 24x7 support service.  Further, DENIC has no comparable transition 
experience or experience in implementing ICANN policies.  On the contrary, 
DENIC's record of cooperation with ICANN casts doubts on its ability to 
improve the implementation of GNSO policies, a key criterion in the RFP.  


In summary, Afilias' business is focused solely on global domain registry 
services.  The Company is the best-qualified applicant to support .NET during 
the transition and into the future.  Under our leadership, a properly 
managed .NET can effectively challenge .COM and contribute to a more 
competitive environment for the registration of domain names, thereby 
fulfilling an important aspect of ICANN's mission.  Only Afilias has the 
experience and resources to build .NET into a competitive, innovative TLD that 
delivers greater value to the community.

...  I. Overview

Leveraging expertise gained from operating the fifth and sixth largest gTLDs 
in the world, Afilias' registry services will meet and exceed the absolute and 
relative criterion for.NET. As detailed in the Appendices above, Afilias 
proposes to perform at a higher level of service in the following manner:

· Enhance accountability of the registry operator by adding an additional 21 
SLA metrics including reporting on DNS and Whois performance

· Improve performance of the .NET registry by increasing the requirements for 
all SRS query commands to 400 milliseconds or less and SRS write commands to 
800 milliseconds or less

· Guaranteeing 99.999% network uptime 

· Improving Whois updates from between 12-24 hours to within 5 minutes and 
enable enhanced functionality for both thin and thick Whois displays and 
privacy controls.

· Reducing monthly planned SRS outage allotments

· Improving the data available and ICANN's ability to participate in registry 
escrow procedures

Afilias has the fastest resolution time in the industry, critical for the 
speed of network communication, as well as reliability, security and stability 
of core .NET registry functions.

Afilias has an experienced technology management team leading an expert staff 
of technical support, customer service, and product management specialists who 
assist registrars and registrants 24x7x365.  This disciplined team has created 
well-defined processes that allow it to avoid emergencies and quickly address 
issues as they arise.

Afilias has clearly demonstrated industry leadership in registry operations.  
Not only has Afilias pioneered the use of EPP, it possesses the most 
experience with it and is currently running the most advanced version of EPP 
in production.  Afilias also has a history of bringing new registry systems 
online:  1) it launched .INFO as the first gTLD registry to run EPP; 2) it 
managed the largest transition of a gTLD registry when it migrated the .ORG 
domain from VeriSign on behalf of PIR; and 3) it has transitioned 7 existing 
ccTLD registries, providing customized registry solutions for each.

Afilias' registry system is also customizable to easily integrate new registry 
products that are required by industry advancement as well as those necessary 
to support the needs of the community.

Afilias already supports nearly 7,000,000 domains and has proven its 
scalability over time. Not only has Afilias' database grow to the scale of the 
current .COM/.NET registry in terms of the amout of records it supports, but 
it has been tested to handle heavy loads including processing the real-time 
launch of new services and volume registrations in excess of 1 million names 
during a 36 hour period. 

Afilias' systems and technology base are standards-compliant, flexible, fault-
tolerant, and have been proven to be reliable under challenging operational 
conditions and even to withstand natural disastersemergencies.  Afilias' 
existing systems are already powerful and robust enough to run the .NET TLD, 
enabling Afilias start-up operations to run quickly and smoothly.

Afilias' combination of proven technology, strong leadership, customer 
advocacy, and operational excellence provides a solid foundation for Afilias' 
succession as the new .NET registry operator.

...  II. Technology Highlights

Key highlights of Afilias' technology include:

· DNS service that propagates DNS changes in as fast as 120 seconds, with a 
demonstrated network uptime commitment of at least 99.999%;

· Redundant security systems and load balancing capabilities to prevent 
security breaches, system attacks, and system overload problems; 

· Strong physical security, including intrusion prevention and protection from 
man-made and natural disasters; 

· Full Customer Service and Technical Support staff, providing 24/7 service to 
registrars with complete real-time monitoring facilities, with proven, 
established escalation procedures; 

· Comprehensive mechanisms to ensure compliance with .NET and ICANN policies, 
and obligations under registry agreements; and

· Detailed review processes for the integration of new requirements, as well 
as subsequent compliance monitoring and periodic review. 

· A commitment to some of the highest levels of service of any ICANN-
accredited registry and agreement to conform similarly for the .NET domain. 

Next Generation DNS: 

Afilias will once again set the standard for the next generation of DNS.

In 2001 Afilias introduced the GTLD marketplace to rapid DNS propagation, and 
in 2002 began the exclusive use of Anycast technology in the provision of 
their DNS services.

Other industry participants first criticized and then followed.  Today rapid 
DNS propagation and the use of Anycast technology is a minimum expectation of 
the gTLD Registry provider.  In 2005 Afilias will again improve industry 
standards by servicing its registries through the use of multiple DNS 
providers, eliminating the risk of the single DNS vendor and network 
dependency.   

..  III. Key Technical Personnel/Size of Technical Workforce/Access to Systems 
Development Tools

Afilias' technology team combines many years of experience in designing, 
building and maintaining highly scalable, distributed and networked 
transaction-based systems. The team is led by Ram Mohan, the company's VP of 
Business Operations and CTO, along with Michael Young, the company's Senior 
Director of Information Technology and Howard Eland, Afilias' Senior 
Technology Architect.  Full biographies of these individuals can be found in 
Section 3.

Afilias' technical workforce numbers over 50, and includes key personnel in 
Database Administration, Systems Architecture, Quality Assurance, Technical 
Support, Documentation, Database Analysis, Financial Systems and Billing 
Support, as well as front-line Customer Support.

The .NET registry will have access to the full range of systems development 
and monitoring tools that have been acquired or developed by Afilias.  These 
tools will provide the .NET registry unparalleled ability to provide best-of-
breed services to registrars, registrants, organizations, individuals and 
other interested parties.  Afilias has implemented model engineering standards 
in each of the major components of registry management, including (but not 
limited to) software code management, quality assurance and control, software 
operations metrics, systematic testing procedures and formal development and 
operational methodologies.

In addition to the above resources, Afilias has entered into long-term 
agreements with the following vendors to provide critical functions for the 
operation of the registry:

· International Business Machines (IBM) [http://www.ibm.com] will provide data 
center, systems and technology. (See Section 5 (b)(I)Part B, I, General 
Description of Proposed Facilities and Systems, for details.) 

· UltraDNS Corporation (UltraDNS) [http://www.ultradns.com] will provide 
global DNS services on behalf of the registry operator.  (See Section 5 (b) 
(VII)Part B VII Zone File Distribution and Publication, for details.) 

· Iron Mountain, Inc. (Fort Knox) [http://www.ironmountain.com] will provide 
data escrow services. (See Section 5 (b) (X) Part  B X Backup, and Section 5
(b) (XI)XI  Escrow, for details.) 

· Autonomica AB (Autonomica) [http://www.autonomica.se/] will provide global 
DNS services on behalf of the registry operator.  (See Section 5(b) (VII)Part 
VII  Zone File Distribution and Publication, for details.) 

...  IV. Continuing Commitment to Technical and Operational Excellence

Afilias is committed to a path of continued excellence; and has an established 
history of extending funds, human resources, and time towards not just meeting 
commitments, but exceeding them.  Afilias meets new issues and events head on, 
and takes careful and responsible action required to attain a resolution.  
Below are three examples of how Afilias dealt with emergency issues in the 
past, and how we have emerged with enhanced knowledge and a more secure and 
stable system:

Example 1:

In the first quarter of 2004 Afilias experienced surges of abusive transaction 
requests to the SRS servers causing extended transaction times beyond stated 
SLA's.  Competition for released domain names (deleted domain names re-
entering into availability) in the .ORG and .INFO registries were generating 
load factors magnitudes beyond regular registry traffic conditions.  Afilias 
took several decisive and successful actions:.

1. Formed an Emergency Task Force to examine traffic patterns of the registry 
system, identify specific load points and developed software upgrades and 
hardware recommendations.

2. Worked closely with the its rate-limiter equipment vendor to adopt a new, 
more effective rate limiting policy to manage both standard registry 
operations and the competitive domain drop rate process.

3. Applied an additional software-driven rate limiting technology that 
ELIMINATED Add Storms in the .INFO and .ORG registries - this is an 
accomplishment unmatched in the .COM and .NET registry today.

4. Conducted daily meetings with engineers from all Registrars that requested 
assistance until the situation was resolved.

Afilias succeeded in re-establishing transaction response time SLA's without 
ever ceasing operation due to the extensive loading from the competitive 
Domain Drop Process.  Afilias succeeded in producing a solution that has 
scaled with the sudden influx of new added Registrars throughout 2004; not 
only maintaining transaction time SLA's, but continuing to improve them. 

Faced with a similar situation in 2001, VeriSign was forced into an emergency 
shutdown of the .COM, .NET, and .ORG Registries for over 24 hours.  VeriSign 
was not able to resolve the effect of Add Storms through normal registry 
operations, and was forced to setup a divergent batch pool access system for 
the competitive domain drop process.  While Afilias maintains transaction 
response SLA's through registrations made during the domain drop Process, 
VeriSign will not guarantee transaction response SLA's on their batch pool 
access.  Furthermore VeriSign has failed to scale their batch pool domain drop 
access with the recent registrar growth reducing the per registrar allocated 
batch pool connections from 30 to 10, and limiting the number of new 
registrars that could be added to the registry per day.    

Example 2:

In early July of 2004, Afilias experienced a short brownout as a result of BGP 
route dampening of the DNS services provided for the .ORG domain on the behalf 
of the Public Interest Registry. 

The issue resulted from an increase in speed of the operation of one of the 
core components of the UltraDNS network, which caused a cascading series of 
restarts of those components and BGP route withdrawals over a short period of 
time. This was sufficient to cause dampening of some routes to some networks, 
which exacerbated the restarts. The flaps and dampening, together with 
restarts of the components, also caused hung queries on a small number of 
nameservers.

At no time did the .ORG DNS system experience a blackout, and due to the 
structure of UltraDNS' Anycast network, the effect to end users was limited. 
The duration of the interruption at UltraDNS was less then ten minutes, while 
some effects to network operators were reported for a more lengthy period. 
Users in multiple parts of the world also reported no problems with 
accessing .ORG domains during this period. 

The SRS was not affected during this time. 

The major backbone networks were largely unaffected due to their employment of 
the Best Current Practices detailed by RIPE. The networks which implemented 
this BCP experienced effectively no failures, and benefited from the use of 
caching recursive servers by end users, who were largely insulated.

The specific issues experienced in this event were in no way caused by, nor 
affected by, UltraDNS' use of Anycast, and the use of unicast would in no way 
have mitigated the effects seen. 

Subsequent steps taken by Afilias and its DNS service provider, UltraDNS, to 
mitigate future similar occurrences include:

· the creation of a redundant network running on a different code base from 
the primary UltraDNS network (NSD based)

· the addition of new nodes to the NS system

· the creation of a DDOS Cloud infrastructure unparalleled in the industry 
(see Section 5(b) (ii)Section Five Part B subsection (ii))

· the addition of new host name/IP address routes used for the TLD 
infrastructure 

· the upgrading and over-provisioning of all related infrastructure components
(see Section 5(b) (ii), (vii) and (viii)Five Part B subsection ii, vii, and 
viii)

· the establishment of additional vendors for DNS (See sSection 5Five)

It is important to note that the current deployment of the UltraDNS system is 
unmatched in its design and implementation to withstand foreseeable conditions 
that could affect DNS availability.  In contrast, VeriSign's Atlas DNS system 
has experienced a number of availability issues throughout 2004, with no 
visible plan as to how VeriSign intends to resolve these serious DNS issues.

Example 3:

In 2002 Afilias acquired LibertyRMS a Tucows back-office Registry Services 
provider.  Related Registry hardware was acquired with the purchase that 
included a number of database layer enterprise Unix servers.

Afilias encountered repeated issues with these Database Servers inherited from 
Tucows, which resulted in a number of short unscheduled outages of the 
registry SRS services from late 2002 to early 2004.  These outages did not 
affect DNS resolution, only domain creation and update functions, nor did they 
result in any related data integrity issues.  

Afilias went to extensive efforts to see that every serviceable component was 
replaced in these servers, yet problems continued to occur.  Afilias therefore 
removed the critical database servers long before the end of their expected 
life-cycle, and replaced them with advanced IBM Unix Enterprise servers 
(RS6000) configured in HACMP clusters.  These replacements have created 
multiple layers of automated database hardware failover capacity for Afilias; 
since this initiative was undertaken - there have been no reoccurrences of 
these hardware outages.  (See Section Five Part B sub-section V. for more 
detail,).

...  I. Proposed Facilities and Systems Overview

Afilias will provide complete registry operations for the .NET TLD.  The 
technical systems involved include:

· World-class (Telco-grade) data centers and technology from IBM Research Labs 
for security, stability, and reliability, using fully diverse Internet 
connectivity

· Scale-tested registry architecture built with at least N+1 redundancy

· Configurable registry software, designed to accommodate .NET's policy 
parameters

· Comprehensive disaster recovery plans, trained staff, and scenario planning 
to provide prompt response to any failures, large or small

· Afilias' operations office in Toronto, Canada.  This office includes our 
Technical Support, software development, IT, and Network Operations Center 
(NOC) teams

A. Physical Plant

All Primary Registry systems will be located within IBM secure data centers in 
North America.,  aAll Afilias Datacenters conform to these minimum security 
standards:

· 24/7 on-site security personnel and security monitoring

· Surveillance cameras

· Controlled access to the data center

·Use of identification systems

B. Locations

Currently, Afilias utilises IBM and Q9 Network facilities to locate its 
systems and production technology infrastructure.  The .ORG and .INFO domains 
both run out of these centres currently, as do our ccTLDs.

IBM Hosting Delivery Centers are located worldwide and share modeled service 
offerings.  Afilias currently utilizes IBM facilities in St. Louis, Missouri 
USA and Secaucus, New Jersey USA; and will expand its data centers as required 
by the growth patterns of the .NET domain.  Afilias' agreement with IBM allows 
us to use IBM data centers in geographically separated locations.  For the 
purposes of vendor and geographic diversity, Afilias also maintains equivalent 
grade data center facilities with Q9 Networks in Toronto, Canada.

See 5(b)(i)-Figure 1: Extensive Worldwide Data Center Coverage, below.

...  III. IBM V3 Facility (Fully Managed Data Centers)

These facilities are fully hosted solutions in V3 telco-grade, high security 
buildings.  Only IBM staff has access to the physical environment, servers, 
network devices, etc.

Afilias' data center power fault tolerance provides:

· Dual entry on different sides of the building

· Redundant power within the building

· Four UPS systems with full battery backup

· Six 2MW diesel generators

· Automatic throw-over switches

· 30,000 gallons diesel fuel on site (minimum 50 hour fuel supply) 

IBM's data center Class "A" facility provides: 

· 138,000 sq. ft. of raised floor space capacity

· 1M sq. ft. facility

· Halon and water suppression technology

· Multiple air conditioning units are configured in a fully redundant array.  
Multiple UPS power units with battery backup provide clean and reliable 
electrical power.  Multiple diesel generators, also in a fully redundant 
array, are available should an extended power outage occur. 

Server racks, cases, network cables and components are systematically labeled 
with color-coded identifiers, minimizing human error during plant services 
work and accelerating trouble-shooting capabilities in the event of equipment 
failure.

Security guards are on duty 24/7 and enforce a sign-in process where staff 
entering the facility must be on an approved list and accompanied by a minimum 
of one other staff member. The entire facility is monitored by video 
surveillance.

... IV. Other Production and Failover Sites: V5 Facilities (Managed and Self-
Managed Data Centers) and Q9 Networks Data Centers.

All production and fail-over facilities are co-located in telco-grade, high-
security buildings and have the following characteristics:

· Security guards are on duty 24/7 and enforce a sign-in process where anyone 
entering the facility must be on an approved list.

· Visitors must show legal photo ID to be granted access to each facility and 
once inside must use a card key and palm scanner to gain access to the data 
center.

· Afilias' systems are locked within cages in the data center and must be 
unlocked by security.  The entire facility will be monitored by video 
surveillance.

· Multiple air conditioning units are configured in a fully redundant array.

· Multiple UPS power units with battery backup provide electrical power.

· Multiple diesel generators, also in a fully redundant array, are available 
for extended power outages.

See 5(b)(i)-Figure 2: Fault tolerance allows for high degree of stability and 
reliability, below.

Multiple air conditioning units are configured in a fully redundant array. 
Multiple UPS power units with battery backup provide clean and reliable 
electrical power. Multiple diesel generators, also in a fully redundant array, 
are available during extended power outages.

See 5(b)(i)-Figure 3: Modular, structured systems management allows staff to 
add and replace equipment quickly, below.

Server racks, cases, network cables and components are systematically labeled 
with color coded identifiers; minimizing the possibility of any human error 
during plant services work, and accelerating trouble-shooting capabilities in 
the event of equipment failure.

See 5(b)(i)-Figure 4: Organized floor plans allow quick system access, below.

Security guards are on duty 24/7, and enforce a sign-in process where IBM 
staff entering the facility must be on the approved list and be accompanied by 
a minimum of one other IBM staff member. The entire facility is monitored by 
video surveillance.

See 5(b)(i)-Figure 5: Highest Standards of Redundancy and Security, below.

... V. Hardware Architecture

A. Afilias' system uses a distributed architecture that achieves the goals of 
scalability, reliability, and extensibility.  The system will continue to 
function even if an entire server were to suffer catastrophic failure.

· Use of load balancers to assist in scalability and to prevent service 
outages.  Our load balancing design allows the performance of hardware 
upgrades without any customer impact. 

· Afilias' registry facilities/services are operated in a minimum of three two 
geographic locations, currently operating in more than two locations, allowing 
for redundancy and fault tolerance. 

· The primary registry facility is a "live" facility, meaning that it is the 
normal full-time registry. 

· The secondary registry facility is both a functional and standby facility, 
meaning that it would be activated for primary registry services if 
operational problems ever arose at the primary facility (due to natural 
disasters, etc.). 

· The secondary facilities are continuously synchronized with the primary.  
Afilias has designed sophisticated database replication systems that make 
these continuous updates possible. 

· The secondary site is also used to provide ongoing secondary registry 
services such as reporting, daily zone file distribution, OT&E testing 
environments, and enhanced registry services. 

· Afilias operates several database servers to provide redundancy.  The 
primary registry facility houses multiple database servers, one being the main 
database and the others being secondary databases.  The standby registry 
facility houses multiple database servers, which are constantly synchronized 
with the primary registry.  The database servers are replicated but are not 
load balanced. 

· There are at least two (4) WHOIS Servers (load balanced) on multiple 
physical enterprise Unix servers for at least N+1 redundancy.  These are on a 
shared application server with an instance of Web server and registry server 
running on each enterprise server. 

See 5(b)(i)-Figure 6: Hardware Architecture, below.

B. Key Hardware Components

1. Server Specifications

The specifications of the individual servers are described below.  As 
technology improves and new hardware and systems technology becomes available, 
the registry intends to upgrade its servers and systems to well-tested systems 
at periodic intervals.

a. Primary Site

Shared Application Servers:

The following application servers are distributed on multiple physical 
enterprise Unix or Linux servers for at least N+1 redundancy. 

· Two (2) or more Web servers (load balanced) 

· Two (2) or more Registry servers (load balanced) 

· Two (2) or more WHOIS servers (load balanced) 

  - -- Base Components for Shared Application and Database Servers --- 

   Component           Typical Components for Each Enterprise Server
   ----------         -----------------------------------------------
   Server             Sun, Dell and IBM enterprise Unix and Linux
                      servers
   Processor          Multi-processor, large cache, advanced memory
                      gate features
   Memory             Minimum 8 gigabytes of RAM, up to 36 gigabytes of
                      RAM
   Disk (for systems  SCSI 15K multiple mirrored pairs sets per
   software)          application server with configured hot spares

   Disk (for data)    Large external disk array with 1+0 RAID using
                      multiple mirror sets and configured hot spares.
                      Interconnect to primary and secondary servers
                      through redundant fibre SAN switches and Fiber
                      GBNIC channels
   Network Adapter    Average 6 10/100/1000 network interfaces

   Operating System   Sun Solaris 8.0 (BOS), AIX 5.1, 5.2, Red Hat
                      Enterprise Advanced Server 3.0

   Other Software     Veritas File System, Veritas Volume Manager, IBM
                      FASTIT Volume Manager


· Two (2) or more Dedicated Application Layer Firewalls (VPN) 

          --- Base Components for Application Layer Firewalls ---

   Component                        Base Components
   ---------          ----------------------------------------------
    Server            Nokia and Cisco Enterprise Firewalls


· Two (2) Dedicated Database Firewalls (VPN)

          --- Base Components for Database Firewalls ---

   Component                        Base Components
   ---------          ------------------------------------------------
    Server            Nokia and Cisco Enterprise Firewalls


· Two (2) Load Balancer Switches

         --- Base Components for Load Balancer Switches ---

   Component                        Base Components
   ---------          ------------------------------------------------
   Switch type        Alteon A180E

   Adapter            8-Port 10/100/1000 GB Ethernet Module

   Other software     Web OS - 10.x

· Two (2) Rate Limiter Switches

           --- Base Components for Rate Limiter Switches ---

   Component                        Base Components
   ---------          -----------------------------------------------
   Switch type        Packeteer 6500, 4500

   Adapter            2-Port 10/100 Ethernet Module(in-line
                      configuration)
   Other software     Web OS - Local


· Two (2) Server Access Switches

           --- Base Components for Server Access Switches ---

   Component                        Base Components
   ---------          ------------------------------------------------
   Switch type        Cisco 9 Slot Catalyst Cisco 6506 Chassis

   Adapter            16-Port GB Ethernet Module

   Other software     CAT 6000 Supervisor Image (version and patch
                      control maintained)


                 --- Dedicated TSM (Backup System) ---

   Component                        Base Components
   ---------          ------------------------------------------------
   Hardware           One Ultrium Tape Library 3583-L72 6 x LTO Drive
                      Sled 4 x 20 Data Cartridges
   Other software     IBM Tivoli Storage Manager, IBM Tivoli Disaster
                      Recovery Manager, IBM Tivoli Support TDP & TSM
                      (version and patch control maintained)

b. Secondary Site:

Shared Application Servers:

The following application servers are distributed on at least two physical 
Enterprise Unix or Linux Servers for N+1 Redundancy. 

· Two (2) or more Web servers (load balanced) 

· Two (2) or more registry servers (load balanced) 

· Two (2) or more WHOIS servers (load balanced) (or more)

   --- Base Components for Shared Application and Database Servers ---

   Component            Typical Components for each Enterprise Server
   ---------          ------------------------------------------------
   Server             Sun, Dell, and IBM Enterprise Unix and Linux
                      servers
   
   Processor          Multi-processor, large cache, advanced memory

                      gate features
   Memory             Minimum 8 gigabytes of RAM, up to 36 gigabytes of
                      RAM

   Disk (for systems  SCSI 15K multiple mirrored pairs sets per
   software)          application server with configured hot spares

   Disk (for data)    Large external disk array with 1+0 RAID using
                      multiple mirror sets and configured hot spares.
                      Interconnect to primary and secondary servers
                      through redundant fibre SAN switches and Fiber
                      GBNIC channels

   Network Adapter    Average 6 10/100/1000 network interfaces
 
   Operating System   Sun Solaris 8.0 (BOS), AIX 5.1, 5.2, Red Hat
                      Enterprise Advanced Server 3.0

   Other Software     Veritas File System, Veritas Volume Manager, IBM
                      FASTIT Volume Manager


· Two (2) Dedicated Application Layer Firewalls (VPN) (or more)

        --- Base Components for Application Layer Firewalls ---

   Component                       Base Components
   ---------          -------------------------------------------------
   Server             Nokia and Cisco Enterprise Firewalls

· Two (2) Dedicated Database Firewalls (VPN) 

             --- Base Components for Database Firewalls ---

   Component                       Base Components
   ---------          -------------------------------------------------
   Server             Nokia and Cisco Enterprise Firewalls


· Two (2) Load Balancer Switches

             --- Base Components for Load Balancer Switches ---

   Component                        Base Components
   ---------          -------------------------------------------------
   Switch type        Alteon A180E

   Adapter            8-Port 10/100/1000 GB Ethernet Module

   Other software     Web OS - 10.x


· Two (2) Rate Limiter Switches

           --- Base Components for Rate Limiter Switches ---

   Component                        Base Components
   ---------          -------------------------------------------------
   Switch type        Packeteer 6500, 4500

   Adapter            2-Port 10/100 Ethernet Module (in-line
                      configuration)

   Other software     Web OS - Local



· Two (2) Server Access Switches

           --- Base Components for Server Access Switches ---

   Component                         Base Components
   ---------          -------------------------------------------------
   Switch type        Cisco 9 Slot Catalyst Cisco 6506 Chassis

   Adapter            16-Port GB Ethernet Module

   Other software     CAT 6000 Supervisor Image (version and patch
                      control maintained)


· Dedicated TSM (Backup System)

              --- Base Components for Backup Systems ---

   Component                        Base Components
   ---------          -------------------------------------------------
   Hardware           One Ultrium Tape Library 3583-L72 6 x LTO Drive
                      Sled 4 x 20 Data Cartridges

   Other software     Tivoli Storage Manager, Tivoli Disaster Recovery,
                      Tivoli Support TDP & TSM (version and patch
                      control maintained)


...  VI. Connectivity

Connectivity between the Internet and the primary and secondary registry sites 
is via multiple redundant connections.  In addition, connections between 
servers on the internal registry network are via redundant multi-homed 100 
Mbps Ethernet.  Connectivity between the primary and secondary registry 
facility (for replication) is via redundant VPN connections.

· A separate network is used for backups, insuring that the production network 
has full use of bandwidth at all times - even during backups. 

· High capacity routers and switches are used to route traffic to registry 
services. 

· Load balancing and rate limiting is used for balancing all aspects of the 
registry, including the registry gateway, WHOIS services and DNS API gateways. 

Internet connectivity is supplied via a BGP-based solution with fully diverse 
connections to multiple ISPs.  Registry Internet connections at both the 
primary and secondary sites is provisioned for a burst of up to 100 Mbps 
capacity and can be further upgraded as required. 

See 5(b)(i)-Figure 7: Internet Access Architecture, below.

...  VII. Hardware and Architecture Disclaimer

Afilias may adjust both the equipment list and systems architecture to reflect 
the continuing advancement of both registry functions and hardware/operating 
systems in the marketplace.  Any changes therein will not adversely affect the 
sustained performance, reliability, stability, or security of the registry.

...  I. Overview of Resolution and Performance Capabilities

Afilias currently has over 50 DNS appliances located on publicly accessible 
segments of the Internet that are capable of resolving better than 1 million 
queries per second across three autonomous networks.  In addition, DNS 
appliances are currently installed within 9 major networks globally, capable 
of answering 100% of all queries sourced from within those networks under 
normal circumstances, and representing 15% of all queries currently received 
by the existing TLD's served.  By May 2005, there will be a total of 96 DNS 
appliances deployed across both public and private networks, capable of 
answering in excess of 1.5 million queries per second.


...  II. Response Time and Packet Loss Targets

The UltraDNS Anycast network infrastructure mitigates packet loss and latency 
by ensuring DNS queries always prefer a route to the closest topological 
server.  Reducing the distance and number of hops a query must transit, both 
to and from the server, ensures the entire query/response transaction is 
completed quickly.  Additionally, the shorter the distance, and specifically 
the fewer hops across which a query must travel, the less likely the query 
will be dropped by an intermediate network.   Since the bulk of real world DNS 
transactions occur using the UDP datagram protocol, the advantage of 
topological proximity can significantly reduce the incidence of lost packets 
and thus the latency and extra traffic expenses that would be incurred for 
retransmission.  On average, response time is less than 5 milliseconds from 
the edge of the UltraDNS network for greater than 90% of queries.


...  III. Availability of Authoritative Name Servers

By utilizing advanced replication techniques UltraDNS is able to manage 
multiple instances of the DNS data across the global network.  Each copy of 
the data resides on multiple servers, which announce a common pool of Anycast 
IP addresses.  In the event that a device in the network were to fail it would 
be transparent to end user requests, and the remaining devices would continue 
responding accurately to queries while not affecting end user resolution.

Additionally, the functioning servers would continue to respond to queries 
from the closest most available device due to the dynamics of BGP routing.  
UltraDNS has maintained an industry leading 99.999% network uptime Service 
Level Agreement for five years without violation.


...  IV. Processes, Tools and Automated Monitoring to Ensure Accuracy of Zone 
Data for Resolution

At the core of the UltraDNS data distribution infrastructure are numerous 
architectural and operational implementations that ensure all injections to 
the database are propagated quickly and accurately to all nodes within the 
global network.  The primary mechanism is a combination of intelligent and 
logical injection segregation combined with the advanced conflict detection 
and resolution features of the Oracle Advanced Replication facility.  Each of 
the different methods of data injection (i.e.: UI, XML-API, AXFR) are assigned 
to a single specific core injection point at any time.  This method allows 
UltraDNS to take advantage of multiple simultaneous injection points, 
increasing overall efficiency and redundancy, while virtually eliminating any 
possibility of conflict.  In rare cases where there may be a conflict or other 
distribution problem, the advanced replication monitoring and alerting system 
will notify the UltraDNS Network Center immediately, and the on-call database 
engineer will investigate, evaluate, and resolve any problem well within the 
data propagation time required by our SLA metric for injections.

In addition, UltraDNS has also engineered a real-time Database Consistency 
Crawler (DCC) that constantly runs in the background on all of the primary 
database nodes.  This engine is responsible for working through the entire 
resource record set in each database, comparing each record for accuracy and 
consistency with every other database in the infrastructure.  If a discrepancy 
is found, a second comparison is performed to ensure it was not simply a 
temporary difference caused by the short distribution latency inherent in any 
global replication mechanism.  If the conflict persists, it will generally be 
resolved manually.  Once again, the Network Operations Center will be 
notified, and the on-call database engineer will investigate to ensure data 
integrity.


...  V. Diversity of DNS Infrastructure

A. UltraDNS Architecture

The UltraDNS architecture is comprised of three different levels.  

·	System level:  The system level architecture provides for multiple 
separate, yet related, meshes of servers that have a primary-and-secondary, or 
master-and-slave relationship. 

·	Mesh level:  The mesh level architecture is made up of multiple nodes 
that have identical data sets, which are synchronized via replication over the 
wide area network. 

·	Node level:  At the node level, system components are co-located at 
the same network point of presence and function together to provide the DNS 
protocol service.

B. UltraDNS Data Model

The UltraDNS node is designed around a data model maintained within a 
commercial database.  The data model contains information about principal 
objects managed by the system (e.g., users, DNS zones, and resource records) 
and the additional information required to control the processes operating on 
the data (e.g., service configuration parameters and ACL info).  The various 
functionalities of the UltraDNS system are provided by numerous disparate 
processes, which primarily serve as a conduit between the database and end 
user requests.

C. UltraDNS Server

The UltraDNS name server answers Internet protocol DNS queries based on 
authoritative DNS data maintained in the database.  One of UltraDNS' 
achievements was the ability to make an authoritative DNS server that was 
capable of answering DNS from a database-reliant system at a speed comparable 
to that of a memory-resident system, such as BIND.  UltraDNS uses network 
deployment and routing control to allow the scalability of such a system by 
linear addition of hardware to meet load requirements along with DNS-specific 
caching algorithms and associated cache invalidation mechanisms.  With this 
configuration, UltraDNS has confirmed load capacity one order of magnitude 
above the combined load of all existing TLDs.

D. UltraDNS Nodes

Each node is designed to provide both security and scalability for the 
UltraDNS network.  By utilizing dedicated hardware, UltraDNS partitions each 
major part of the network to function independently, thereby ensuring access 
control to each point, as well as growth capability.  Hardware can be 
transparently added to an existing node without effecting service to that 
node.  In this case, once a new device is added, it will immediately begin 
announcing the Anycast addresses and be included in the pool of servers 
available to answer queries within that node.  Likewise, if a server were to 
fail, it would immediately stop announcing the Anycast addresses and queries 
would be answered by the next functioning server in that node. For more 
information see Section 5 (b) (V)

Each node in the UltraDNS infrastructure contains the following components:

·	An Oracle database to contain DNS information. 

·	A second genetically diverse commercial database from a different 
manufacturer provides redundancy at each core node. 

·	Five or more name servers that service DNS requests and interact with 
the Oracle database, or alternatively with the diverse database. 

·	Connectivity to the Internet that is moderated by firewall technology. 

·	VPN connectivity for data synchronization and management. 

·	Alternate connectivity method for out-of-band management. 

E. Hardware Specifications

UltraDNS operates a globally deployed network infrastructure of nodes, each 
comprised of an assemblage of robust hardware and software components from 
industry leaders including Sun, Dell, Intel, AMD, Juniper, Cisco, Oracle, and 
MySQL.  Each individual hardware component is chosen based on the specific 
task or the operational functionality that it provides.

F. Software

UltraDNS is based on a non-BIND proprietary code built from the ground up.  In 
2004, the code base underwent an extensive third party security audit which 
found no vulnerabilities that could be remotely abused to acquire restricted 
privileges or cause failure of directory resolution capabilities on the 
UltraDNS system.  In addition to supporting the standard DNS specifications 
and RFC's, there are numerous features and enhancements that have been 
incorporated into the UltraDNS system to support robustness, security, and 
redundancy well above what is capable with legacy DNS server implementations.

As part of the infrastructure assurance programs within the company, UltraDNS 
has implemented a disaster recovery system running NSD version 2 in a hot 
standby mode providing an unprecedented level of code diversity.  This 
implementation is more fully described in Section ii (6).

G. Border Gateway Protocol (BGP) and Anycast Enhances Robustness and Client 
Performance 

UltraDNS has incorporated BGP announcements generate code directly into 
UltraDNS' DNS resolver.  This allows for nameservers or complete nodes to be 
removed from the pool of active systems upon the detection of anomalous data, 
or the failure of any key element of that nameserver or node.  Should the 
entire node fail, the BGP announcements for that node are withdrawn, and 
queries are automatically routed only to the operational nodes.  The code is 
fully compliant with the following RFCs:  2453, 2080, 2328, 2460, 2373, 2463, 
2464, 2236, 1812, 1771.

H. Multi-Threaded Server Increases Machine Utilization

UltraDNS was designed as a multi-threaded server, allowing maximum utilization 
of machine resources, particularly when multiple CPUs are available.  If one 
thread is in the middle of stuffing and transmitting a DNS response, it can 
continue running while another thread can be off retrieving DNS data from the 
database.


...  VI. Diversity and Redundancy of Network and DNS Infrastructure to Handle 
Bandwidth Congestion and Network Failures of ISPs and Host Providers

A. Redundancy of Systems

UltraDNS has implemented an architecture designed to ensure that there is no 
single point of failure in any segment of the System.  To this end, the 
following individual sub-systems are identified, and protected from failure as 
defined:

1. Database:

Primary:  The primary database and repository for data is housed using Oracle 
9i enterprise version.  The system consists currently of four Master Nodes, in 
geographically diverse locations, and four slave nodes in separate locations.  
Every node has access to a local instance of the Oracle database, or to a 
private connection to a remote Oracle database instance.

Alternative:  Each transaction in the primary database system is replicated in 
real time into a secondary series of databases using the commercial version of 
MySQL.  Every UltraDNS node has access to a local instance of the MySQL 
database.

2. Nameserver:

a. Primary:  Every location consists of a number of proprietary UltraDNS 
nameservers.  These nameservers respond to all queries under normal 
circumstances, and are capable of answering all queries received by the node 
under normal, as well as certain abnormal circumstances.

b. Alternative A:  Every location includes some number of servers running the 
NSD version 2 nameserver implementation from NLnet Labs.  Using a rolling 
schedule, a current snapshot of the authoritative zones hosted by UltraDNS are 
compiled on one or more servers, and then brought on line in standby mode.  
However, the NSD nameservers do not receive any queries until the UltraDNS NOC 
identifies an event that meets specific criteria, at which time some or all of 
the local queries are funnelled to the NSD servers, which then actively 
respond.  These nameservers are capable of handling all queries received by 
the node, but with certain features restricted (speed of updates and 
propagation, etc).

Alternative B:  Should the need arise, UltraDNS's Managed DNS network (Second 
Level Domains) can be brought on line with the ability to answer TLD queries.  
Under normal circumstances, the Managed DNS network is totally separate and 
segregated from the TLD infrastructure.

3. Network Connectivity:

A.  DNS Infrastructure

The primary mechanism for addressing and route announcements pioneered and 
used by UltraDNS is known as Anycast.  This technique involves the 
announcement of the same IP addresses by multiple nodes at the same time.  The 
result is a DNS infrastructure that has the highest level of performance and 
lowest level of latency and packet loss, while allowing the ability to 
increase the number of available namneservers globally during times of need 
(DDoS attacks, etc) without the need for modifications by any users or 
networks external to UltraDNS.

By injecting a BGP route from each node, the system leverages IP routing to 
deliver user queries to a topologically nearby node.  This results in:

·	A reduction of network latency for DNS transactions, as compared with 
a "standard" deployment of DNS services. 

·	A reduction in the number of queries that are routed to distant 
servers, thereby reducing the likelihood of encountering congested routers. 

·	A reduction in the number of query packets that are dropped and cause 
DNS timeouts/retries. 

·	Improved performance and reliability to the end user. 

UltraDNS's mechanism has been adopted by most major root/TLD operators as the 
Best Current Practice.

Diverse network connectivity is deployed within the UltraDNS network.  Primary 
connectivity is provided by two International Network Providers: NTT/Verio, 
and XO Networks.  Each node is multi-homed with 100mb (Fast Ethernet) 
connections from each provider.  However, to ensure robustness and redundancy, 
a carefully architected matrix of network announcements is utilized to ensure 
that both minor and catastrophic failures of any elements within the UltraDNS 
network will not result in failures of resolution for end users. 

UltraDNS has also implemented additional connections at most nodes to local 
public switched peering fabrics.  The Company employs a liberal peering 
policy, and over 50 networks are peered directly with UltraDNS at one or more 
locations, using these public peering facilities.  A partial list of peering 
partners is shown below.

Japan Telecom   SBC        TDS Telecom     HopOne Telecom   PCCW/BTN

Atlantech       Digital    Reach Networks   Hurricane       Nominet UK
                Wireworks                   Electric

KDDI            WVFiber    Global NAPs      Xmission        RCN

Globix          TSN        Net Access       SoverNet        Sonic.net
                Internet

ICG             New Edge   Novia.net       Shaw Cable/      Akamai
Communications  Networks                   Big Pipe 

MSN/Hotmail     Google     Telefonica      Doubleclick      Tastylime
                           International

Peer1 Network   Supernews  RealConnect     Mzima            United Pan 
                                           Networks         Europe
                                                            Commun.

Primus          GT Group   Bungi           Route Views      PoweredCom
Telecomm.       Telecom    Communications

DSLExtreme      CENIC      HanseNet        Infinity-        Jupiter
                                           Hosting          Hosting

ServePath       Limelight  Swisscom IP-    Lambdanet        InterWorld
                Networks   Plus Internet
                           Services

B.  Six Global Anycast Network Announcements Provide Redundancy (6x /24)

Added reliability is achieved by announcing up to six global IP addresses from 
each device in the UltraDNS TLD sever network infrastructure.  This provides 
additional redundancy in the face of network routing problems that can be 
caused by third parties.  In the unlikely event that one of the IP address 
become un-routable, the user will be able to fail-over to an alternate global 
IP address.  The fundamental design creates over twenty unique combinations of 
IP address, network provider, and physical node locations such that, even in 
the event of a catastrophic failure of an entire physical location, entire 
network backbone provider, or even an entire region, queries from any location 
in the world would still have a viable set of address/route/location options 
that would still be functional.

...  I. DNS Queries Including Peak Periods and Projected Growth

The UltraDNS network and infrastructure was designed using a hierarchical 
methodology in which the simplicity of component scalability is inversely 
proportionate to the rate at which available component capacity will be 
consumed.  As a result of this architecture, UltraDNS' existing network can be 
expanded by orders of magnitude with very little additional capital 
expenditure.

The DNS service solves scalability problems, since the architecture is capable 
of managing more than 200,000,000 domain names.  It also gives .NET 
registrants instant global reach and enables them to supply their 
international users with the same great quality-of-connection experience that 
their domestic users enjoy.

A. Capabilities

The UltraDNS network is capable of handling in excess of 2 trillion directory 
service transactions each month.  Put more into perspective based on services 
currently deployed, the existing infrastructure can easily provide 
authoritative DNS services to every domain name currently known to be 
registered and have significant capacity left over.
The Oracle replication mechanism that UltraDNS employs has no theoretical 
limit for scaling.  However, the real world limitations have shown up to 60 
multimaster machines in a mesh and hundreds of snapshot sites running from a 
single node.

B. Replication

UltraDNS runs a two-tier replication environment for maximum scalability and 
performance.  Database replication is the process by which database 
information is propagated and received by and from one or more sites to one or 
more sites with the goal of data being the same between all sites for the 
selected replication group.  Simply stated, replication is the process by 
which data is duplicated from one database to another.  

Replication can be broken into various categories:  advanced multimaster 
synchronous, advanced multimaster asynchronous, one-way snapshot, updateable 
snapshot, and fast refresh snapshot.  UltraDNS uses a hybrid configuration by 
combining two methods of replication methodologies: , advanced multimaster 
asynchronous and fast refresh snapshot.  The number of simultaneous queries 
that can be leveraged against the UltraDNS network is at a minimum, 1,000,000 
queries per second.

C. Monitoring

The UltraDNS Network Operations Center (NOC) monitors the production network 
24 hours a day, 365 days a year, and will immediately escalate at the 
slightest hint of any anomaly, if there is an impact on service or security.  
All network access to any UltraDNS machine is monitored proactively to ensure 
unauthorized access attempts are isolated and addressed long before the 
security or integrity of the production machines is compromised.

To ensure UltraDNS never violates its Service Level Agreement, the NOC is also 
responsible for monitoring the Company's directory services proactively.  
Vigilant monitoring, coupled with UltraDNS' redundant, fault tolerant and 
automatic fail-over architecture, ensures that the company's directory 
services are never interrupted, for any reason.


...  II. DDoS Attacks, Viruses, Worms and Spam

A.  DDoS Attacks on UltraDNS Systems

UltraDNS has devoted significant resources in research and development to 
thwart DDoS attacks and improve both the security and reliability of the 
Internet's critical DNS infrastructure.

UltraDNS' success in defending itself from Distributed Denial of Service 
attacks in Q4 of 2002 prompted the Company to evaluate its preparedness for 
more complex DDoS attacks in the future.  As the results of forensic 
diagnostics were applied to advanced simulation models for projecting 
evolution of attack scenarios, the concept of an out-of-band signaling network 
for the DNS was identified as the most secure defense against the next 
progression of DDoS attacks.

In late 2002 following a 1-hour DDoS attack against the root servers, an 
attack was launched against the UltraDNS TLD server network.  The intensity of 
the attack required coordinated action by UltraDNS and its upstream providers; 
the scale of the attack required even the diverse upstream providers to apply 
mitigation steps to stabilize their own networks.  During this 48-hour attack, 
Afilias and UltraDNS maintained 100% availability of all TLDs, with no end 
user impact.. 

Studies have shown that a carefully crafted DDoS attack with sophisticated 
attack tools could create a situation where normal mitigation efforts could 
fall short.  As a result, UltraDNS began a process of laboratory simulations 
to test the effectiveness of a probable solution.  Our tests indicated that in 
the most advanced implementations, at up to approximately 1gb (gigabit) of 
sustained attack traffic, commonly used DDoS mitigation solutions would be 
successful.  However, above 1gb sustained attack traffic, an attack would 
succeed against conventional DNS systems.  In 2003, the evolution of Trojan 
armies, or "botnets" reached the point that attacks greater than 1gb+ became 
relatively simple to mount, and likely to be used.  

Until June of 2004 the "perfect DNS DDoS" attack was still theoretical.  In 
June 2004, a four hour attack against the worldwide DNS systems of Akamai 
effectively shut down their service, leading to service interruptions of major 
Internet and commerce systems worldwide. 

UltraDNS' forensic analysis indicates that the June 2004 attack fit the 
profile of a "perfect DNS DDoS" attack.  The Akamai attack was orchestrated, 
and appeared to be well above 1gb of sustained traffic.

Since it is clear that even some of the world's largest DNS networks can be 
taken down by an array of botnets, a stronger, more resilient solution had to 
be created: the "DNS Cloud".

Since there is currently no commercially available or practical method of 
filtering or processing the "Perfect DNS DDoS" packet, the DNS Cloud solution 
provides a mechanism that meets the primary objective of an authoritative DNS 
system while under a crushing attack --enabling recursive servers to continue 
to resolve queries normally.

UltraDNS has achieved this by identifying the largest sources of legitimate 
DNS queries for the zones that UltraDNS is authoritative for, and then 
deploying complete authoritative UltraDNS Nodes onto local segments that 
contain the "Trusted Recursive Servers".  These "Local Nodes" are then 
connected via point-to-point Ethernet circuits, and queries from the Trusted 
Recursive Servers for the UltraDNS zones are then asked, and answered, in a 
fully isolated and protected environment.  This topology provides for 
unprecedented sub 5 millisecond query response times within the networks where 
Local Nodes are installed.

The Local Nodes are functionally identical to the normal Public Nodes, and 
include the use of the announced Anycast IP addresses via BGP as well as 
protected connectivity to the UltraDNS Replication System, to assure data 
consistency.  The Local Nodes employ the same operational mechanisms as the 
Public Nodes so that anomalies are identified in the same way, and are handled 
accordingly.  Should the Local Nodes within a Host ISP's network fail for any 
reason, the local routes would be withdrawn as a result, and the Trusted 
Recursive Servers will automatically follow the normal external announcements 
and paths to the UltraDNS Public Nodes.  The Host ISPs (the ISPs controlling 
the Trusted Recursive Servers that are the sources of the queries) protect 
access to "their" UltraDNS Local Nodes, and are encouraged to permit their 
customers to also access the Local Nodes via their own recursive servers that 
are configured to forward queries for UltraDNS's zones to the Trusted 
Recursive Servers.  However the Host ISP is responsible for making this 
decision and for managing it.  The Host ISPs must confirm their understanding 
that if they have not maintained the integrity of the local isolated network, 
they will not experience the benefits of this system during a DDoS.  

By inviting the largest service providers to connect directly and privately to 
the UltraDNS directory infrastructure via the DNS Cloud, the authoritative DNS 
information stored by UltraDNS can be assured as being valid and always 
available to these participating ISPs' end users.  The DNS Cloud will provide 
DDoS resistant resolution to almost 100 million Internet users, and is 
anticipated to provide resolution for double that number by the end of the 
second quarter of 2005.  As more Local Nodes are deployed into Host ISP 
networks, the effectiveness and viability of the Cloud increases 
proportionally with the number of end users now protected from the effects of 
DDoS within those networks.  In addition, UltraDNS has begun to distribute 
this innovative solution around the world.  The first of these was announced 
at the ICANN meeting in Cape Town, and is now deployed at the JINX exchange in 
Johannesburg, South Africa, to serve that region.

Connectivity to the Cloud is by invitation only to the largest ISPs and 
recursive DNS server operators.  Smaller enterprises and lower usage recursive 
DNS server operators will not have direct access to the Local Node DNS Cloud.  
However, they can utilize their upstream service provider for this purpose.  
This forced hierarchy preserves the decentralized and public nature of the 
DNS, but introduces a now-required level of security, authentication and 
responsibility into the entire model in order to maintain the security and 
stability of the DNS. 

Adoption of the DNS Cloud has occurred at the expected rate, and it is 
anticipated that upon award of the .NET contract, Afilias would expand the DNS 
Cloud to include an international base of regional ISPs in emerging Internet 
communities.



B. WHOIS

Abuse of WHOIS services at the registry level will be subject to an automated 
rate-limiting system that will ensure that the uniformity of service to users 
will be unaffected by a few parties whose activities might threaten to 
overload the WHOIS system.  The automated rate-limiting system also helps to 
resist DDoS attacks on the WHOIS system.

Data mining of any sort will be strictly prohibited, and Afilias reserves the 
right to take all appropriate actions should data-mining activities be noticed 
on its WHOIS system.

These measures contribute to curb abusive harvesting of WHOIS information for 
SPAM spam and other purposes.  Even though the concern of spam and other 
abusive propagation of viruses and worms cannot be rooted out by efforts at 
the TLD registry alone, Afilias is committed to all efforts it can to ensure 
that the .NET registry will be aligned with the interests of the community and 
hence to contribute to the reduction of such activities.

The knowledge and expertise in maintenance of a TLD and is relavent to 
combating such malicious intents.  For example, Afilias' rapid registration-to-
resolution lead-time is critically accompanied with a near-real-time WHOIS 
update.  An example of the importance of timely WHOIS publishing to go in-hand 
with rapid registration-to-resolution is that if the DNS is updated 
immediately and the WHOIS lags for 12-24 hours, spammers and other abusers 
have a significant time haven for conducting their activities without the 
WHOIS reflecting even the sponsoring registrar.

After the pioneering rapid registration-to-resolution DNS publishing by 
Afilias, the .NET (and .COM) registry has dramatically reduced its DNS 
publishing lead-times.  However, this is not accompanied by a timely WHOIS 
update.  Based on Afilias' knowledge, WHOIS updates are reflected in 12-24 
hours for the .NET registry currently.  This lag in time could therefore be 
exploited by spammers as illustrated above.

Afilias will rectify this vulnerability and upgrade the NET registry to enjoy 
the same benefits as the .INFO and .ORG TLDs with near-real-time WHOIS updates 
to go along with rapid registration-to-resolution DNS publishing.

C. Network Infrastructure

See Section5(b)(XIII)System Security sub-section D. Operations

D. Registration System

Afilias' Shared Registry System (SRS) is built to be fast, stable and secure. 

Any registry's SRS is susceptible to attack.  The Afilias SRS is equipped with 
automated Add-Storm mechanisms to curb and discourage abusive attacks by 
registrars.  Rate-limiting measures as well as additional policies ensure that 
such aggression by one registrar will not compromise services for other 
registrars on the system, and to uphold the equivalent access principle.
The Afilias SRS system is also designed with high level of security to prevent 
virus and other malicious attacks on its EPP, mail or other components.

E. Alert and Warning system

Afilias subscribes to early alert and warning systems and monitors global 
issues on DDoS attacks, Viruses, Worms and SPAM proactively.  This allows 
Afilias to obtain timely information and to provide the .NET registry with 
additional protection, and monitoring as such events occur. 


...  V. Restart Capabilities

Nodes Monitor Their Name Servers to Ensure DNS Query Responses

Another improvement layered on top of the advanced routing functionality 
implemented by UltraDNS further ensures that user queries are answered 
promptly without incurring the delay of a DNS timeout and retry.  Each 
UltraDNS node monitors its name servers to make certain that it is responding 
to DNS queries.  Should a name server fail to answer for any reason, the 
routing announcement for that node is withdrawn, which removes it from 
the "reach" of an end user.  Hence, user queries are transparently routed to 
avoid servers that cannot answer and that will cause additional delay.  Once a 
server comes back on-line or is restarted, it will immediately begin 
announcing the Anycast addresses and be included in the pool of servers 
available to answer queries within that node.

EPP and Whois Registry Servers are designed as "stateless" application 
servers. These systems run process independent monitoring software ("Registry 
Sentry") designed to kill and restart applications. All hardware is redundant 
and is monitored for failures; on-site support from relevant equipment vendors 
will be made available within 4 hours, on a 24/7.

...  I.  General Overview

Afilias will implement a registry system functionally similar to the.INFO 
and .ORG registries which comply with ICANN policies and exceed Service Level 
Agreements in effect for .NET today.  Consistent with this, Afilias will 
ultimately maintain a thick registry system that centralizes the authoritative 
registrant and other contact details at the registry.  A thick registry system 
will provide for greater stability and data consistency.

Initially, Afilias will allow authorized registrars to connect to the registry 
using the Registry-Registrar Protocol (RRP). After a 10-day stability period, 
Afilias will also allow use of the Extensible Provisioning Protocol (EPP) with 
no initial enforcement of authoritative domain contact associations.  Afilias 
pioneered the use of an RRP-to-EPP translator device - termed RRP proxy - in 
order to facilitate a registry migration between these protocols. Details of 
Afilias' plan for the transition from RRP to EPP can be found in Section 8 of 
this proposal. 

Afilias has the highest level of service level agreements in the industry and 
intends to hold the .NET to this same standard of excellence. Afilias will 
significantly improve the performance of individual SRS query and write 
commands, increase the speed of Whois updates to match its fast DNS services, 
and reduce the alloted outage periods for the .NET registry.

...  II. RRP Usage Overview

A. RRP Interface

Following cutover to the new registry operator, the RRP interface will be 
accessible through a proxy interface for EPP commands, so that the fundamental 
application need not change when registrars have been fully transitioned to 
the newer EPP protocol with enforcement of authoritative domain contact 
associations.  Each RRP key-value pair will be translated to EPP XML.  The 
proxy will add additional, required fields to the XML, where necessary, to 
generate valid EPP commands.  Additional out-of-band services may be provided 
to help facilitate current RRP functionality.  The registry will maintain some 
information about each domain, in order to indicate whether the domain was 
last manipulated through RRP; this will allow the SRS to indicate whether it 
has authoritative contact data for the domain.

Afilias currently maintains a RRP-EPP proxy facility that is compatible with 
VeriSign's RRP protocol today. This system was employed during the transition 
of the .ORG registry from VeriSign to Afilias'.

B. RRP RFCs Referenced

RFC2832: Registry-Registrar Protocol (RRP)

This document describes a protocol for the registration and management of 
second level domain names and associated name servers in both generic Top 
Level Domains (gTLDs) and country code Top Level Domains (ccTLDs).  This 
protocol was developed by the Network Solutions Registry for use within the 
Shared Registration System and is being published "as-is" to document the 
protocol implementation developed by the Network Solutions, Inc. Registry.

RFC3632: Registry-Registrar Protocol (RRP)

This document updates RFC2832.  The combination of the two documents specifies 
RRP 2.0.



...  III. EPP Usage Overview

A. EPP at Afilias

EPP is a connection-oriented, application layer client-server protocol for the 
provisioning and management of objects stored in a shared central repository.

EPP is the most advanced registry protocol available, and has been proven as 
the standard for current registry operations in virtually every new gTLD 
launched since 2000.

Afilias has been a pioneer and innovator in EPP use.  .INFO was the first EPP-
based gTLD registry and was launched on EPP version 02/00.  Afilias currently 
runs the .ORG registry at EPP-RFC compliance (EPP 1.0), the most advanced 
version of EPP in use by any TLD.

Afilias has a proven history of building EPP registries and bringing EPP-based 
distribution channels online.  Afilias brought registrars up on EPP for the 
first time in history during the launch of the .INFO registry system, and 
transitioned more than 120 .ORG registrars from the legacy RRP protocol to EPP 
07/05, and then to EPP 1.0.

Key technical staff members from Afilias actively participated in the IETF 
process that finalized the new standard for EPP.

Afilias intends to implement the formally issued EPP RFCs for the .NET domain 
in a manner functionally identical to the .ORG and .INFO registries.  Afilias' 
expertise in educating registrars on advancements to EPP and transitioning 
from legacy protocols will ensure that the .NET gTLD operates on an efficient 
and standards-complaint SRS.

B.  EPP Supported Object/Command Set

Text from the EPP RFC's has been used where possible to avoid paraphrasing 
technical details pertaining to object command behavior.

C.  EPP Greeting

An EPP server shall respond to a successful connection by returning a greeting 
to the client.  The greeting response includes information such as:

·	The name of the server

·	The server's current date and time in UTC

·	The features supported by this server, which may include:

                        -  One or more protocol versions supported by the 
server

                        -  One or more languages for the text response 
supported by the server

                        -  One or more elements which identify the objects 
that the server is capable
                            of managing

D. EPP Session Management Commands

EPP provides two commands for session management: <login> to establish a 
session with a server, and <logout> to end a session with a server.


E. Login

The EPP <login> command is used to establish a session with an EPP server in 
response to a greeting issued by the server. A <login> command MUST be sent to 
a server before any other EPP command.

F. Logout

The EPP <logout> command is used to end a session with an EPP server.

G. EPP Objects

1. Domain (RFC3731):

Domain Name mapping for the provisioning and management of Internet domain 
names stored in a shared central repository.

2. Host (RFC3732)

Host mapping for the provisioning and management of Internet host names stored 
in a shared central repository.

3. Contact (RFC3733):

Contact mapping for the provisioning and management of identifiers 
representing individuals or organizations (known as "contacts") stored in a 
shared central repository.

H. EPP Object Query Commands

EPP provides three commands to retrieve object information: <info> to retrieve 
detailed information associated with a known object, <check> to determine if 
an object is known to the server, and <transfer> to retrieve known object 
transfer status information.

1. Info:

The EPP <info> command is used to retrieve information associated with a known 
object. The elements needed to identify an object and the type of information 
associated with an object are both object-specific, so the child elements of 
the <info> command are specified using the EPP extension framework.

2. Check:

The EPP <check> command is used to determine if an object is known to the 
server. The elements needed to identify an object are object-specific, so the 
child elements of the <check> command are specified using the EPP extension 
framework.

3. Transfer (Query):

The EPP <transfer> command provides a query operation that allows a client to 
determine real-time status of pending and completed transfer requests. The 
elements needed to identify an object that is the subject of a transfer 
request are object-specific, so the child elements of the <transfer> query 
command are specified using the EPP extension framework.

I. EPP Object Transform Commands:

EPP provides five commands to transform objects: <create> to create an 
instance of an object with a server, <delete> to remove an instance of an 
object from a server, <renew> to extend the validity period of an object, 
<update> to change information associated with an object, and <transfer> to 
manage changes in client sponsorship of a known object.

1. Create:

The EPP <create> command is used to create an instance of an object. An object 
may be created for an indefinite period of time, or an object may be created 
for a specific validity period. The EPP mapping for an object MUST describe 
the status of an object with respect to time, to include expected client and 
server behavior if a validity period is used.

2. Delete:

The EPP <delete> command is used to remove an instance of a known object.  The 
elements needed to identify an object are object-specific, so the child 
elements of the <delete> command are specified using the EPP extension 
framework.

3. Renew:

The EPP <renew> command is used to extend the validity period of an object. 
The elements needed to identify and extend the validity period of an object 
are object-specific, so the child elements of the <renew> command are 
specified using the EPP extension framework.

4. Transfer:

The EPP <transfer> command is used to manage changes in client sponsorship of 
a known object. Clients may initiate a transfer request, cancel a transfer 
request, approve a transfer request, and reject a  transfer request.

5. Update:

The EPP <update> command is used to change information associated with a known 
object. The elements needed to identify and modify an object are object-
specific, so the child elements of the <update> command are specified using 
the EPP extension framework.

6. Redemption Grace Period Specific (RFC3915):

The EPP <update> command provides a transform operation that allows a client 
to change the state of a domain object.  The registry grace period extension 
modifies base update processing to support redemption of domain names for 
which a <delete> command has been processed, but the name has not yet been 
purged.

J. EPP RFCs Referenced

1. RFC3730: Extensible Provisioning Protocol (EPP)
This document describes the foundation upon which all of the specific objects 
(Domains, Hosts, Contacts) must adhere to in order to maintain a consistent 
interface. A standard registry specific extensible object management framework 
is also described in this document to handle any extra information need to 
satisfy policy or other agreements the registry may be required to sustain.

2. RFC3731: Domain Name Mapping

This document describes an Extensible Provisioning Protocol (EPP) mapping for 
the provisioning and management of Internet domain names stored in a shared 
central repository. Specified in XML, the mapping defines EPP command syntax 
and semantics as applied to domain names.

3. RFC3732: Host Mapping

This document describes an Extensible Provisioning Protocol (EPP) mapping for 
the provisioning and management of Internet host names stored in a shared 
central repository. Specified in XML, the mapping defines EPP command syntax 
and semantics as applied to host names.

4. RFC3733: Contact Mapping

This document describes an Extensible Provisioning Protocol (EPP) mapping for 
the provisioning and management of identifiers representing individuals or 
organizations (known as "contacts") stored in a shared central repository. 
Specified in XML, the mapping defines EPP command syntax and semantics as 
applied to contacts.

5. RFC3734: Transport Over TCP

This document dictates the TCP connection strategies to use and is almost 
identical to the existing NSI RRP implementation. Therefore, the EPP Server 
implementation structure will mirror the existing RRP Server design using 
TCP/IP and SSL to secure transport.

6. RFC3735: Guidelines for Extending EPP

This document describes high-level functional and interface requirements for a 
client-server protocol for the registration and management of Internet domain 
names in shared registries. Specific technical requirements detailed for 
protocol design are not presented here.  Instead, this document focuses on the 
basic functions and interfaces required of a protocol to support multiple 
registry and registrar operational models.

7. RFC3915: Domain Registry Grace Period Mapping

This document describes an Extensible Provisioning Protocol (EPP) extension 
mapping for the management of Domain Name System (DNS) domain names subject 
to "grace period" policies defined by ICANN.  Grace period policies exist to 
allow protocol actions to be reversed or otherwise revoked during a short 
period of time after the protocol action has been performed.  .

K. EPP Registrar Client Software

The registrar is responsible for developing the client application that it 
will use to interface with the registry.   Afilias will provide registrars 
with free EPP client software, which they may choose to modify if they so 
choose.  This kit is provided in different versions of code, for use with 
Windows and a version for use with Unix/Linux.  Afilias has already developed 
and currently distributes kits to .ORG, .INFO, and its ccTLD registrars and 
registry operators.

A registrar may also opt to develop their application to conform to the EPP 
specification without the use of the kit.  This is acceptable as long as the 
client is able to pass the OT&E certification process.  The registry-registrar 
communication channel will be encrypted.  A SSL certificate from an approved 
certificate authority is required to establish this encrypted channel.  The 
registrar is responsible for acquiring the SSL certificate and developing 
support for SSL in their client application. 

Registrars will be responsible for procuring and maintaining their own 
registrar-side systems.  Afilias does not offer registrant-oriented systems 
that enable retail operations by registrars (registrar Web sites, credit-card 
processing capabilities for registrars to use on their Web sites, databases 
for registrant billing data, etc.).

B)  Availability of a shared registration system, including processing times 
for standard queries (add, modify, delete)

As defined in Appendix D, Section 2.12: 

"Service Availability" means when the System is operational and predictably 
responding in a commercially reasonable manner.  By definition, this does not 
include Planned Outages or Extended Planned Outages.

As stated in Appendix D, Section 3:

Protocol Command Category and Performance Requirement Matrix:

Add/Renew/Delete/Update
     Category C2
     Priority P1

Transfer
     Category C2
     Priority P6

Check
     Category C2
     Priority P2

    Where the Category and Performance Requirements are:

    Category Two (C2):

Total duration of Unplanned Outage Time of C2 class services must not exceed 
240 minutes per monthly Time-frame.  This represents a Service Availability 
percentage of 99.45%.

    Performance Requirement One (P1):

For a single-entity payload, Round-trip time should not exceed 800ms as 
measured by the system monitoring

Performance Requirement Two (P2):

For a single-entity payload, Round-trip time should not exceed 400ms as 
measured by the system monitoring tools that simulates a representative 
registrar. A request with a multiple-entity payload should materially perform 
consistent with the behavior of multiple, single entity payload operation.

Performance Requirement Six (P6):

For a single-entity payload, Round-trip time should not exceed 1600ms as 
measured by the system monitoring tools that simulates a representative 
registrar. A request with a multiple-entity payload should materially perform 
consistent with the behavior of multiple, single entity payload operation. 

C)  Duration of any planned or unplanned outages

As defined in Appendix D, Section 2.10: 

"Planned Outage" means the periodic pre-announced occurrences during the 
Service Term when the System will be taken out of service for maintenance or 
care. Planned Outages will only be scheduled during the following window 
period of time each week, 1500 to 2300 UTC on Saturday (the "Planned Outage 
Period"). This Planned Outage Period may be changed from time to time by the 
Registry Operator, in its sole discretion, upon prior notice to each 
Registrar. Planned Outages will not exceed four (4) hours/per calendar week 
beginning at 0000 UTC Monday nor total more than eight (8) hours/per Monthly 
Time-frame. Planned Outage for a nameserver shall not coincide with or overlap 
Planned Outage for any other nameserver. Not withstanding the foregoing, in 
each calendar year Registry Operator may incur one (1) additional Planned 
Outage of up to eight (8) hrs in duration during the Planned Outage Period for 
major systems or software upgrades ("Extended Planned Outages"). This Extended 
Planned Outage represents the total allowed Planned Outages for the month. 

As stated in Appendix D, Section 4.2:

SRS service planned outage duration, maximum (hours/month):
8 hrs/month (includes Whois)

SRS service planned outage time-frame (day and hours):
15:00-23:00 UTC Saturday

SRS service extended planned outage duration, maximum (hours/quarter):
0 hrs (Planned Outage Time can be used as Extended Planned Outage Time; the 
total planned outage time per period is the sum of Planned Outage and Extended 
Planned Outage.) 

SRS service extended planned outage time-frame (days and hours):
15:00-23:00 UTC Saturday

Whois service planned outage duration, maximum (hours/month):
8 hrs/month (includes SRS)

Whois service planned outage time-frame (days and hours):
15:00-23:00 UTC Saturday


As defined in Appendix D, Section 2.8: 

"Monthly Unplanned Outage Time" shall be the sum of minutes of all Unplanned 
Outage Time during the Monthly Time-frame. Each minute of Unplanned Outage 
Time subtracts from the available Monthly Planned Outage Time up to four (4) 
hours.

As defined in Appendix D, Section 2.18:

"Unplanned Outage Time" shall mean all of the following:

1. With respect to services other than Whois Service and nameserver 
resolution, the amount of time recorded between a trouble ticket first being 
opened by the Registry Operator in response to a Registrar's claim of Service 
Unavailability for that Registrar through the time when the Registrar and 
Registry Operator agree the Service Unavailability has been resolved with a 
final fix or a temporary work around, and the trouble ticket has been closed. 
This will be considered Service Unavailability only for those individual 
Registrars impacted by the outage;

2. With respect to services other than Whois Service and nameserver 
resolution, the amount of time recorded between a trouble ticket first being 
opened by the Registry Operator in the event of Service Unavailability that 
affects all Registrars through the time when the Registry Operator resolves 
the problem with a final fix or a temporary work around, and the trouble 
ticket has been closed;

3. With respect to all services, the amount of time that Planned Outage time 
exceeds the limits established in Section 2.10 above; or

4. With respect to all services, the amount of time that Planned Outage time 
occurs outside the window of time established in Section 2.10 above.

L. Related Transfer Dispute Mechanism:

Summary and Reference:

The Afilias Registry has added support for the Transfer Dispute mechanism, in 
compliance with the new ICANN Transfer Policy, as of November 12, 2004: The 
Transfer Dispute process requires a series of administrative functions 
supported within the Registry; these include a set of administrative charges 
and the "Transfer Undo Mechanism"; which is supported out of band.

The Referred ICANN Transfer Policy can be found at:

http://www.icann.org/transfers/policy-12jul04.htm

... I. Overview of Database Capabilities

Afilias uses the highly scalable, open-source relational database management 
system (RDBMS) PostgreSQL.  PostgreSQL is well suited for a domain registry 
and has been proven in its implementation in the .INFO and .ORG registries.
Like other enterprise-grade database systems, PostgreSQL scales to handle 
large loads on one database server, and scales across multiple machines to 
distribute load.  Afilias will use that capability to manage the future growth 
of the .NET gTLD.  Afilias' registry database system at present has sufficient 
capacity available to handle anticipated peak loads from .NET without any 
major change to its base configuration.  But if .NET grows even more quickly 
than Afilias anticipates, Afilias will still be able to use the facilities of 
PostgreSQL to serve .NET traffic in the same fast, stable, and secure manner 
it serves other TLDs.

Afilias uses PostgreSQL because it is an RDBMS with the speed, power, and 
features Afilias needs.  PostgreSQL offers a high-concurrency transaction 
management model which provides best-in-class data-locking semantics, a record 
of rock-solid stability, ANSI SQL and ACID conformance, and a rich set of 
programming interfaces.  PostgreSQL also offers its users access to its source 
code - a guarantee of auditability and maintainability which is not available 
to users of some other RDBMS.  PostgreSQL has the scalability, reliability, 
and performance that critical Internet infrastructure needs.

...  II. Database Capabilities:  Software, Size, Throughput, and Scalability, 
Ability to Handle Volumes

The Afilias plan for .NET ensures scalability in every part of the data 
layer.    We use redundant copies of redundant, scalable systems.


The planned systems will operate at a sustained 12-15% of total capacity, with 
peak load of 25% capacity.  In the event of unexpected load increase, this 
available overhead will permit Afilias to add additional memory and CPU to 
continue to scale load appropriately.  Additional storage can be added 
dynamically.   Disk free space will be maintained at 50% over sustained use.

High-speed interfaces are used for all disk subsystems, to ensure that 
input/output limits do not cause performance difficulties.  Multi-processor 
servers ensure that the RDBMS never lacks processing power.  The systems have 
large amounts of system memory to ensure that datasets can reside in memory, 
rather than on disk.

Afilias plans to use PostgreSQL version 7.4.6 or, at our discretion, any 
subsequent version.

The RDBMS itself will easily support the smooth operation of .NET, because of 
its high capacity and excellent concurrency model.

PostgreSQL is able to accommodate over 65,000 GB of data in a single table, 
which is more than adequate storage for a thick registry operating at many 
times the current size of .NET (.INFO and .ORG currently use less than .0001% 
of this capacity).  It can hold more than a terabyte in any single row.  The 
PostgreSQL technology has no built-in limit in the size of the database it can 
support.  Its recovery logs are restricted only by disk capacity (rather than 
being a fixed size).

Users of PostgreSQL testify to its high speeds even with terabyte-sized 
databases. PostgreSQL can handle the data volume of any current top-level 
domains, because it already does so in the case of .INFO and .ORG.  
Because .ORG and .INFO are thick, the databases hold much more data per name 
record than is held in a thin registry.  Afilias' registry today supports 
nearly 7,000,000 domain names and more than 50,000,000 database records.  
Because it is thick, Afilias' current system is of the same order of magnitude 
as the .COM/.NET registry.  Moreover , domain by domain, Afilias keeps track 
not only of the name server data, but also the contact data, which is an 
increase in complexity as well as size.  Afilias does it with more stringent 
SLAs than the .COM/.NET registry currently faces.

With the current infrastructure capabilities, Afilias' system can, through 
modular growth, accommodate .NET registry growth to over 10 million domain 
names with no significant changes.  This permits the immediate support of the 
anticipated volume from .NET.

A. Concurrency

Capacity of a DBMS is important, but any enterprise-class system could 
accommodate easily the size of the .NET database.  For a registry, however, 
the more pressing question is how the DBMS scales under transaction volume.  
Here, too, PostgreSQL provides more than adequate scalability, because of its 
concurrency model.

Afilias' RDBMS is fast - it can handle thousands of transactions per second 
with hundreds of concurrent users.  The most important barrier to speed in any 
registry application is concurrency: an unpredictable number of requests for 
the same object may arrive at the same time.  The reason that PostgreSQL can 
handle the load is its multi-version concurrency control (MVCC).  MVCC is a 
method of ensuring that every database transaction sees a completely 
consistent view of the database, while at the same time ensuring that very 
high transaction volumes can be accommodated. 

Traditional locking makes for slow query times when under high load.  MVCC 
prevents that problem, meaning that queries are nearly as fast for 1,000 users 
as for 100 or 10.

In order to provide for concurrent transactions, most DBMSs use various 
locking schemes, or else depend upon a two-phase commit technique.  PostgreSQL 
provides better than row-level locking by allowing different readers to see 
the data in different states: readers can see data even while it is being 
modified.  "Readers do not wait for writes," except where there is a direct 
data-access conflict.  For a registry, this means that domain information 
queries are fast and up to date exactly up to and continuing past the moment 
that a data-altering command is processed and committed.  No reader has to 
wait for a transaction to process, improving overall service speed. 

The effect of this sort of concurrency control is significant.  In lock-based 
concurrency regimes, an update of a record requires that an attempt to read 
that record must wait until the update succeeds or fails.  In PostgreSQL's 
high-concurrency approach, the reading query of the record can proceed even 
while the update is happening. 

For a registry, MVCC enhances performance in WHOIS and object queries.  For 
example, a <domain:info> EPP query, or a WHOIS query, will return quick, 
accurate results even if the domain has an update command in process against 
it.  Because this sort of concurrency management is handled automatically by 
the database, work-arounds such as "optimistic locking" are not necessary.  
The result is a fast, stable and secure registry system. 

In summary, PostgreSQL can handle not only a high quantity of data, but 
supports that access for many concurrent users.  Afilias' internal tests and 
experience with the .INFO and .ORG registries indicate that PostgreSQL will 
scale to thousands of simultaneous requests without significantly affecting 
query speed.  It has more than adequate throughput capabilities.  Between 
January and November 2003 the registry database processed over 4 billion 
transactions .  In just two days in September of 2004 Afilias processed over a 
million domain adds, without a measurable effect on database performance.  
Here are the database-writetransaction counts for all objects for just one 
hour of that day in .INFO:


Create: 40551
Delete: 981
Renew: 65
Transfer:127
Update: 1359

And here are the average response times for operations in that same hour::

Create domain: 174
Check domain: 103
Renew domain: 178
Transfer domain: 125
Delete domain: 174
Update registrar: 142
Check balance: 139
Update balance: 131

This data shows PostgreSQL's easy scalabilty to perform under this sort of 
load and is further evidence of its unique ability to service registry 
systems. Afilias is willing to commit to stringent service level agreements on 
the basis of that evidence.


...  III. Advanced Database Features 

PostgreSQL is a fully-featured, enterprise class system.  It has features that 
some commercial systems still do not offer.  Here are some of its technical 
capabilities:

·	Fully ACID compliant

·	ANSI SQL compliant

·	Referential Integrity

·	Replication 

·	Native interfaces for ODBC, JDBC, C, C++, PHP, Perl, TCL, ECPG, 
Python, and Ruby

·	Rules

·	Views

·	Triggers

·	Unicode

·	Sequences

·	Inheritance

·	Outer Joins

·	Sub-selects

·	An open API

·	Stored Procedures

·	Native SSL support

·	Procedural languages

·	Better than row-level locking


...  IV. Procedures for Object Manipulation

All manipulations of database objects, including object creation, editing, 
deletion, change notification, transfer between registrars, and the 
implementation of grace periods, are performed through EPP commands, which are 
processed by the EPP server and translated into the appropriate SQL 
statements.  For details, see section 5.b.iv.  

1. Grace Periods

Afilias plans to offer the same set of grace periods to registrars as is 
currently available in .INFO and .ORG today: add grace period (AGP), 
renew/extend grace period (EGP), transfer grace period (TGP), auto-renew grace 
period (ARGP), and redemption grace period (RGP).  These are outlined below.

2. AGP

If a registrar successfully issues a <domain:delete> command against a domain 
within five 24-hour days of having successfully issued a <domain:create> 
command for that domain, the registration fee shall be refunded and the name 
shall become immediately subject to registration by any registrar.

3. RGP 

If a registrar successfully issues a <domain:delete> command against a domain 
within five 24-hour days of having successfully issued a <domain:renew> 
command for that domain, the renewal fee shall be refunded.  The name shall 
enter the RGP.  If another registrar successfully completes a transfer of a 
domain, and the transfer was initiated within five 24-hour days of the 
successful completion of a <domain:renew>  for that domain, the renewal fee 
shall be refunded to the account of the registrar who originally performed the 
renew transaction.

4. TGP

If a registrar successfully issues a <domain:delete> command against a domain 
within five 24-hour days of having successfully completed a <domain: transfer> 
command for that domain, the transfer fee shall be refunded.  The name shall 
enter the RGP.  This grace period excluded ICANN-approved bulk transfers; 
there is no grace period for bulk transfers.  

5. ARGP

If a registrar successfully issues a <domain:delete> command against a domain 
within 45 24-hour days of the name having been automatically renewed at the 
end of its previous registration period, the auto-renew fee shall be 
refunded.  The name shall enter the RGP (outlined below).  If another 
registrar successfully completes a transfer of a domain, and the transfer was 
initiated within 45 24-hour days of the domain having been automatically 
renewed at the end of its previous registration period, the renewal fee shall 
be refunded to the account of the registrar originally charged in the 
automatic renewal.

More than one of these grace periods may be in effect at any one time.  If the 
AGP and EGP overlap, then upon deletion, the name is immediately deleted from 
the registry (i.e. does not enter the RGP).  If any grace period overlaps with 
the TGP, only transactions performed by the current sponsor registrar are 
subject to grace periods.

6. RGP

If a registrar successfully issues a <domain: delete> command against a domain 
name, and the domain is not within the AGP, then the domain enters the RGP.  
The name is flagged with the pendingDelete status (for EPP) for 30 days.  
During this period, the sponsoring registrar may issues a <restore> command 
for the name.  After 30 days, the name remains pendingDelete for five days 
(the redemption hold period) before being released for possible re-
registration.


...  VI. Uptime and Unplanned Outages

Each registry database in the primary site will be installed on multiple-
redundant clusters of database servers.  In the event of the failure of one 
member of the cluster, another can take over its job automatically.  See 
section 5.b.i for details on the hardware to be used.  

The registry database is also replicated in real time to geographically 
distant alternate sites.  So, in the event of the total failure of the primary 
data center, database processing could be moved to a backup site within a few 
minutes.


...  VII. Reporting Capabilities

Afilias keeps a replicated copy of all registry databases available at all 
times.  PostgreSQL uses ANSI SQL as its query language, so any data that is 
collected during registry operations may be reported  upon.  A full 
description of regularly-generated reports are outlined Additional Support, 
section xix.


...  VIII. The PostgreSQL Community:  Future Developments and Support

PostgreSQL is the collective work of hundreds of developers, building on 
almost twenty years of development that started at the University of 
California at Berkeley.  It enjoys a large-base of community support including 
corporations such as Fujitsu, SRA America, RedHat, Pervasive Software, Cisco, 
Chrysler, and 3Com.   It is under active development: the 8.0 release of 
PostgreSQL, scheduled for January of 2005, includes more new features than 
ever before.

Afilias is an active participant in the PostgreSQL community.  In the past 
year, Afilias employees have contributed a new I/O scheduler for smoother disk 
and memory access under  changing load (bgwriter);  a cascading-node multi-
point replication and group communication system (Slony-I); management and 
tuning functions and procedures; and countless hours of community support on 
the PostgreSQL mailing lists.

Why does Afilias expend so many resources on PostgreSQL?  The advantage of 
having access to the RDBMS source code is that, in case the need presents 
itself, it is possible to optimize the system for local conditions.  Since 
Afilias employs developers who work on the PostgreSQL code, in the event such 
optimizations are necessary, Afilias can take advantage of its in-house 
expertise to meet those needs immediately.  No one using commercial, 
proprietary database technology can have the database systems expertise that 
Afilias does, because Afilias employs people whose primary job is to know 
intimately the source code of the database system.   As a result, Afilias can 
know more about its underlying technologies than anyone using a "closed 
source" solution.

Afilias' expertise also contributes to the reliability of its registry 
systems.  In the event an issue were uncovered in the RDBMS code, Afilias 
employed experts would be able to diagnose and repair them.  Afilias believes 
that this approach is the best one for supporting critical Internet 
infrastructure because it shortens the time required to fix a software defect 
in the RDBMS, should one be found.  Users of proprietary systems cannot enjoy 
this advantage, and instead have to wait for a system vendor to fix the 
problem.  

Another advantage of the community development model is the resulting 
distributed knowledge.  When optimizations that Afilias uncovers are 
generalizable, Afilias contributes its modifications to the community.  This 
dissemination results in a virtuous cycle of others contributing 
modifications, as well, resulting in a process of peer-reviewed continuous 
improvement.  In the same way, Afilias can take advantage of its participation 
by sharing its discoveries (good or bad) and advice with others.  Because of 
PostgreSQL's permissive license, Afilias does not need to sign a non-
disclosure agreement or restrict the discoveries it can share with others.  
And because PostgreSQL is in use for mission-critical applications and the 
community of interested users is large and growing.  A vibrant community of 
users and developers is the assurance that the RDBMS will continue to grow and 
be supported. 

Several companies offer commercial support for PostgreSQL, from 
small "boutique"  firms which solve particular problems; to large 
organizations like SRA Japan, one of Japan's largest and oldest software 
houses, or  Pervasive Software, a 20-year veteran of the database services 
market.   

In the upcoming year, Afilias's primary planned contribution to the PostgreSQL 
code will be a new, read-anywhere, write-everywhere replication and scaling 
engine.  Afilias is developing this system in the community, and will release 
it under the same BSD license that it releases all its other PostgreSQL work:  
this innovation will be available to everyone who uses PostgreSQL.


...  IX. PostgreSQL Market Support and Alternatives

Afilias takes seriously the requirement always to evaluate and adjust systems 
and architecture in respect of the continuing changes in registry and  
database systems.  

The adoption of any technology always runs the risk that one day it will 
become an "orphan".  In the case of proprietary software, it is always 
possible that a software vendor will discontinue a product, or will go out of 
business.  The lack of these risks is one of the strengths Afilias sees in 
PostgreSQL.  That is not to say that there is no risk that PostgreSQL will 
stop being supported.  But it is extremely unlikely that all development of 
the product will cease, because of the vibrant community of developers; but if 
it did, Afilias would be able to support our existing code indefinitely, while 
we determined what alternative technologies we might adopt, because we have 
access to the source code.  Moreover, because PostgreSQL is Open Source 
software, there are data migration utilities available for virtually any 
competing database system.  Finally, PostgreSQL's excellent ANSI SQL 
conformance means that porting our applications to use other, conforming SQL 
systems will be easier than it might be with less-conformant systems. 


(vi) Geographic network coverage, including physically diverse sites and 
support of growing and emerging markets.


...  I. Overview of Geographic Network Coverage

Afilias and its partners have built a robust geographically diverse network to 
support registry operations. Each service that Afilias offers has multiple, 
redundant locations in order to prevent extended registry downtime due to man-
made or natural disasters. Registry services such as the SRS, WHOIS, and 
support facilities are located in several redundant data centers. DNS 
resolution services are provided by UltraDNS, a global DNS services provider 
who has implemented a geographically diverse network that can support gTLDs 
such as .NET. 

...  I. Overview of Geographic Network Coverage

Afilias and its partners have built a robust geographically diverse network to 
support registry operations. Each service that Afilias offers has multiple, 
redundant locations in order to prevent extended registry downtime due to man-
made or natural disasters. Registry services such as the SRS, WHOIS, and 
support facilities are located in several redundant data centers. DNS 
resolution services are provided by UltraDNS, a global DNS services provider 
who has implemented a geographically diverse network that can support gTLDs 
such as .NET. 


...  II. Physically Diverse Sites in Network

The primary and secondary Afilias data centers are geographically seperated in 
the Midwest and east coast of the continental United States. Tertiary support 
facilities are located in Toronto, Canada and New Delhi, India providing 
further geographic seperation by country and continent. Each data center 
location has multiple, independent links to major backbone service providers 
who are themselves isolated from failure by their independent network and 
satellite infrastructure. DNS resolution services are provided by the world 
class DNS service and infrastructure provider UltraDNS. UltraDNS has multiple, 
independent DNS server locations throughout the world ensuring global network 
coverage.  UltraDNS servers are situated at strategic Internet traffic 
aggregation points, and currently exceed the scalability demands projected for 
the growth of network traffic of .NET.  For a detailed description of site 
distribution, please see section 5. Technical Competence, part (viii) Zone 
File Distribution and Publication, 4. Location of Nameservers.  


...  III. Support of Growing and Emerging Markets

Afilias is committed to its support of the ICANN Strategic Plan and most 
particularly in its efforts to sponsor emerging Internet communities around 
the globe.  The Company is dedicated to enabling these communities by 
addressing the need for critical DNS infrastructure services as their adoption 
of Internet usage continues to grow.  Afilias was please that during the 
fourth quarter of 2004, UltraDNS was the first TLD infrastructure provider to 
expand its network footprint onto the African continent with a deployment into 
Johannesburg, South Africa.  UltraDNS intends to support the continuation of 
this network installation with location specific service offerings in 2005. 

Afilias's commitment to open standards and contributions in the development of 
open source, community-developed software, is also a contribution to 
developing markets.  The development of commodity infrastructure for 
enterprises is the best way to ensure that emerging Internet communities can 
enjoy the benefits of network. Afilias has also taken a forward looking stance 
in expanding its own network and business infrastructure in developing 
countries. A new data center and operations office in India will ensure that 
emerging markets in such countries are provided with the infrastructure they 
need to grow. Just as the development of commodity TCP/IP implementations 
spurred Internet growth in the past, development of a standards-based and 
standards-compliant network space today is the best way to ensure continued 
Internet growth in parts of the world where the Internet is not yet 
ubiquitous. Afilias'  history of working with the community and within 
standards is the surest way to promote growth in emerging markets.

...  I. Zone File Generation Overview

Afilias will provide continuous, near-real-time zone file generation, 
resulting in up-to-date responses from nameservers distributed worldwide.  As 
registrars submit changes to domain records, Afilias will reflect these in the 
zone file almost immediately, enabling .NET to deliver current DNS quickly and 
reliably, worldwide - a critical benefit to Internet users.

DNS queries will be serviced using one of the world's leading DNS providers, 
UltraDNS, who is under contract with Afilias.  UltraDNS is currently the 
authoritative DNS provider for 25 gTLD and ccTLD zones and will host the DNS 
data on a custom implementation of their premier Directory Server 
infrastructure.  The data will be maintained within their systems in a 
commercial Oracle database network while maintaining full compliance with both 
IT and Internet standards.  In the unlikely event of catastrophic failure of 
both UltraDNS' primary and disaster recovery network, a secondary network will 
be immediately available from Autonomica AB.; who maintains 15"DNSNODE sites" 
located around the world (See Section 5 Zone File Distribution and Publication 
below for additional details.)  Afilias will commit to a .NET network uptime 
SLA of better than 99.999%.

The zone file will be available to registrars and others who wish to 
subscribe, according to registry policy.

·	The service will operate by generating a daily file that contains the 
entire list of registered domain names. 

·	The file will be delimited to allow for easy extraction and 
manipulation of the data contained within it. 

·	Subscribers will be able to download this file through a secure HTTP 
(HTTPS) interface. 

As file transfer standards change, Afilias may choose to implement different 
protocols to deliver the zone file to recipients.

The registry will support restricted bulk access to the TLD zone file for 
qualified third parties.  Restricted bulk access means that the recipient of 
the file may not distribute or use the file in violation of the contract.  
This will be enforced via technical and business practices.

...  II. Procedure for Changes, Editing by Registrars, and Updating

When registrars wish to change, add, or remove zone information on behalf of 
their registrants, they will be required to do so using standard EPP commands 
or the Web Admin Interface.  In order to make any change, registrars will be 
required to be authenticated (see User Authentication, below) before being 
granted access to the system.


...  III. Frequency

Changes by registrars will be immediately reflected in the registry database, 
and new zone files containing this information will be generated 
continuously.  This will allow near-real time updating of the zone file, 
resulting in always-current DNS.


...  IV. Security

Access to the zone file will be managed on the basis of user credentials (See 
User Authentication, below), including IP address, SSL certificate 
authentication and user name and password.

Registrars wishing to change information for their registrants will have to 
pass a user authentication process prior to being granted access. 

Zone file subscribers will be allowed to download the file only after 
successfully completing a similarly rigorous authentication process.


...  V. Process

Zone generation will involve the creation of DNS zone information using the 
registry database as the authoritative source of domain names and their 
associated hosts (name servers).  Updates to the zone information will be 
generated automatically on a continuous basis and published to the name 
servers.  These updates will reflect any modifications, additions or deletions 
to the registry, that have been made by the registrars during that time 
period.  Only changes that have been committed to the database will be 
reflected in the zone information update; incomplete units of work will be 
ignored.

The master zone file will include the following resource records:

·	A single SOA record.

·	A number of NS and A records, up to a maximum of 13 of each, for the 
TLD DNS servers for .NET.

·	One NS record for each unique domain/nameserver combination.  Only 
domain objects with status values of ACTIVE, LOCK, CLIENT-LOCK and PENDING-
TRANSFER are included in the zone file.

·	One A record for each required glue record.  The registry implements, 
on a rational schedule, glue generation and pruning criteria as specified by 
ICANN from time to time.

·	Necessary records for supporting IPv6 in the zone.

Glue records will be required for any nameserver whose names are subordinate 
to the zone.  In these cases, registrars will be required to submit IP 
addresses for the nameservers in question.


...  VI. IPv6 Support

Afilias is committed to fostering the adoption of IPv6. In support of this, 
Afilias has identified three high-level market requirements:

IPv6 connectivity (i.e., addressability and routes) to the registry to the 
extent where it is in control of the registry service; 

Provisioning of IPv6 (name, address) information from registrars to shared 
registry system; 

Provisioning of IPv6 (name, address) information to the primary .NET name 
servers
To meet these market requirements, the registry will follow the guidelines 
developed by the IETF for IPv6 Node Requirements, currently in Internet 
draft.  Specifically, the registry operator's DNS server infrastructure must 
be compliant with RFC 3596 and related supporting IETF Draft Standards.  
Furthermore, the registry will be required to remain in compliance with ICANN 
policy related to the DNS service implementation for IPv6 and coexistence of 
IPv6 and IPv4.

UltraDNS' database and DNS resolvers support IPv6 per RFC 1886 and 3596 both 
in the zone (IPv6 record types including AAAA) and on the wire (native IPv6 
connectivity and stack support).


...  VII. DNS Interface; Zone File Access

Afilias will inject changes into the UltraDNS DNS system as well as into the 
alternative Autonomica DNS system using the preferred methods for each. In the 
case of the UltraDNS set of nameservers, Afilias will manipulate DNS 
information through an advanced and secure protocol found within UltraDNS' XML-
based Application Programming Interface (API).  The API is a client-server 
model used to insert DNS  resource "records" remotely into the UltraDNS 
system.  A remote client will send requests and a server will respond with 
results of the requests.  Afilias will then send requests for the user 
specified operations.  All communications will be secured by the Secure Socket 
Layer (SSL) protocol and through an IP access control mechanism.  In the case 
of the Autonomica service the defined interface is so-called Incremental Zone 
transfers (IXFR, RFC 1995) that only contain the minimum changes associated 
with each update to the zone contents thereby facilitating efficient 
distribution of the data throughout a large and growing set of globally 
deployed nameservers. All communication is protected by transaction signatures 
(TSIG, RFC  2845).

Subscription to zone files by registrars or other interested parties is not 
contemplated in this proposal.


...  VIII. User Authentication.

To submit changes, registrars will be required to authenticate themselves with 
the Afilias registry system before changes will be accepted into the 
database.  The following criteria identify a registrar at the application 
layer:

·	SSL Certificate on connection to application server.

·	Registrar user name and password credentials.

·	Registrars will only be permitted to alter domain information 
designated by their registrants.  Transfers of domains from registrar to 
registrar will be permitted and supported.

Zone file subscribers will be required to authenticate before being granted 
access to the file.  Each will be given a unique access account and password.  
Subscribers will only be able to access the system from a single, known IP 
address.  Access to the TLD zone file will be granted only if the account 
name, password and IP address are authenticated and validated.  Subscribers 
will be urged to maintain the confidentiality of their passwords.  When a 
subscription expires, access to the secure file transfer server will be 
discontinued until the subscription is renewed.


...  IX. Logging

HTTPS file transfers will be logged on the server for auditing purposes.  This 
log will contain a mapping of user names to IP addresses, as well as download 
statistics.  The statistics will be comprised of zone file download and user 
access times.  Retention of these logs will be at the discretion of the 
registry and maintained on a reasonable basis.


...  X. DNS Data Backup

The primary repository of backup information for the zone data will reside 
with Afilias.  (Backup of DNS information is discussed in more detail in part 5
(b)(viii), Zone File Distribution and Publication.

Zone file information gathered for the purpose of TLD zone file access will be 
retained for 24 hours until the following TLD zone file is generated.  
UltraDNS will be considered the authoritative source for zone file information 
and, should a backup of the TLD zone file be required, one will be re-acquired 
from UltraDNS.

DNS information will be stored within UltraDNS' nameserver infrastructure in a 
distributed relational database (as opposed to a legacy flat-file format).  
This feature makes the UltraDNS data storage model more flexible and secure 
than traditional implementations.  Additionally Veritas Tape Backup is used 
throughout the enterprise every 24 hours. Tapes are stored off site. If 
needed, the Oracle database used for DNS has three re-installation methods: 
the normal installation script, an archived version that must be manually 
reconfigured, and an archived version with an automated re-configuration 
script. The database instance is then recovered and re-initialized through 
three creation scripts, all of which are version controlled.

The zone file will be generated by Afilias in the event of a catastrophic 
failure at UltraDNS.

...  I. Overview 

The DNS infrastructure propagates DNS changes to a global network in as fast 
as 120 seconds and provides a Service Level Agreement (SLA) with a 99.999% 
network uptime commitment.  The speed, reliability, and scalability of the 
system are critical for a time-sensitive domain such as .NET that serves a 
large and growing market.

Afilias partners with UltraDNS, which provides DNS infrastructure for 
the .INFO and .ORG gTLD domains, the .UK and .NZ ccTLDs (as well as 21 
additional ccTLDs), and telecommunications providers such as AT&T Wireless.  
UltraDNS' services were designed to be the industry's most scalable, 
manageable, and reliable service.

·	UltraDNS is the first to use a commercial Oracle database as its 
primary information repository, thus enabling scalable data management that 
can handle a large number of zones and access for many users.  UltraDNS 
supports IPv6. 

·	UltraDNS features network and infrastructure design that uses a 
hierarchical methodology for scalability; and the capability to handle in 
excess of 2 trillion directory service transactions per month, well over the 
expected levels for .NET. 

Additionally, in order to provide complete genetic as well as operational 
diversity, Afilias has contracted with Autonomica AB to provide DNS resolution 
services in the event of catastrophic failure of UltraDNS.   In order to have 
real-time failover capability, UltraDNS will implement a first of its kind 
routing solution that will enable Autonomica to receive queries immediately 
after UltraDNS routes are withdrawn due to network failure.  This solution 
will consist of UltraDNS assigning IP space to Autonomica. that is less 
specific to that announced by UltraDNS in the production .NET infrastructure.  
The Anycast network announcements for all UltraDNS nodes are announced 
as /24s. In addition, Autonomica AB will announce the less specific /23 
aggregated routes where applicable. UltraDNS will also announce these less 
specific /23s from it's primary failover network of genetically diverse NSD 
servers. At the time that a systemic failure of the entire UltraDNS core 
system is identified, the /24 routes will be withdrawn from the UltraDNS 
network. Resolution will switch to the /23 less specific announcements from 
the secondary NSD nameservers within the UltraDNS datacenters, as well as the 
Autonomica AB servers. Should the catastrophic event include the UltraDNS NSD 
servers, all routes will be withdrawn by UltraDNS, and all queries will flow 
to Autonomica via their less specific /23 announcements of theirs.  

The Autonomica service is centered around the design of a large and growing 
number of "DNSNODEs", which are small clusters of nameservers located all 
across the global Internet. 

Autonomica presently provides nameservice for a roughly 10 TLDs, 
including .SE, .NO, .DK, and.NL. The Autonomica network design is fully 
redundant with zero single points of failure, multiple servers and multiple 
paths for all communication. Autonomica "dnsnodes" do support IPv6 transport 
although that capability is not yet utilized at all sites.


...  II. Zone File Publication

Zone publication will occur immediately following zone generation.  The 
publication of zone information will involve sending NS, A, and other 
applicable record updates to UltraDNS' application server for publication.


...  III. Zone File Distribution

Zone distribution will occur immediately following zone publication.  The 
distribution of zone information will involve the replication of zone updates 
on the DNS name servers around the world.

A. Replication

UltraDNS runs a two-tier replication environment for maximum scalability and 
performance.  Database replication is the process by which database 
information is propagated and received by and from one or more sites to one or 
more sites with the goal of data being the same between all sites for the 
selected replication group.  Simply stated, replication is the process by 
which data is duplicated from one database to another.  

Replication can be broken into various categories:  advanced multimaster 
synchronous, advanced multimaster asynchronous, one-way snapshot, updateable 
snapshot, and fast refresh snapshot.  UltraDNS uses a hybrid configuration by 
combining two methods of replication methodologies:  advanced multimaster 
asynchronous and fast refresh snapshot.

Serving as the foundation of the UltraDNS data distribution infrastructure is 
a mesh of four core servers running Oracle Enterprise Server and RedHat 
Enterprise Linux hosted on high availability Dell server hardware powered by 
the latest Intel CPU technology.  The replication mechanism within the core 
group is advanced asynchronous multi-master.  Transactions are stored for a 
period of one minute at any originating core in batches, and then forwarded on 
to the other three machines in the group.  The machines reside in Palo Alto, 
CA; San Jose, CA; Ashburn, VA, and Vienna, VA.  These machines are tasked 
exclusively with supporting the data injection requirements of all the 
disparate sources of updates to the directory information maintained in 
UltraDNS system, ensuring high efficiency and availability of the near real-
time data propagation service.

The replication network is designed as a two-tier hierarchy with multiple leaf 
databases being served by each of the core machines.  It is these leaf 
databases that serve as the workhorses, powering UltraDNS' advanced, 
intelligent directory services query resolution engine.  This two level multi-
node approach allows UltraDNS to target each system for specific tasks, 
ensuring maximum reliability and the lowest possibly latency for both 
injection and query operations.

See 5(b)(vii), Figure 1:  UltraDNS Two-Level, Multinode Model, below.

The data set maintained by core nodes is comprised of the complete set of 
database information that includes DNS data, user information, control 
information, and access restrictions.  Leaf nodes only maintain the subset of 
the total system data that is required to answer DNS queries and control the 
UltraDNS name server.


...  IV. Locations of Nameservers

UltraDNS servers are distributed strategically, and will grow to meet 
scalability demands and geographic coverage in line with the growth of network 
traffic of .NET:

·	Switch and Data, CA, USA 

·	Switch and Data, VA, USA

·	Equinix Inc, CA, USA

·	Equinix Inc, VA, USA

·	Equinix Inc, Chicago, USA

·	Equinix Inc, Hong Kong

·	Metromedia Fiber Network Inc (AboveNet): UK

·	USC Information Sciences Institute (ISI): CA, USA

·	JINX, Johannesburg, South Africa

UltraDNS has established geographically dispersed peering in the following 
locations:

·	Switch and Data (formerly PAIX), East and West

·	Equinix East, West and Chicago

·	LAAP Los Angeles

·	ExchangePoint, London

A partial list of peering partners is included in part (ii), Stability of 
Resolution and Performance Capabilities  section 5.b.ii.

Autonomica has DNSNODEs in production at seventeen locations
·	Stockholm, Sweden
·	Oslo, Norway
·	Helsinki, Finland
·	Brussels, Belgium
·	Bucharest, Romania
·	Ankara, Turkey
·	Amsterdam, The Netherlands
·	London, United Kingdom
·	Frankfurt, Germany
·	Geneva, Switzerland
·	Milano, Italy
·	Kuala Lumpur, Malaysia
·	Tokyo, Japan
·	Bangkok, Thailand
·	Hong Kong, China
·	Washington, MD, USA
·	Chicago, IL, USA

At most of these location the DNSNODE peers at the local Internet Exchange 
Point.

Autonomica plans to reach 25+ DNSNODEs before the end of this year and already 
has hardware on site at five more locations.

...  I. Overview

Afilias billing and collection system has three main components:

·	Registrar (Customer) Billing Account Management: An account is 
established and managed for each of the registry customers (registrars). 

·	Account & Billing Payment policies: The collection of all policies 
through which a registrar account is established, maintained, and billed. 

·	SRS Billing mechanism: Billing process as a registry SRS Sub-System. 


...  II. Technical Characteristics

A. Billing Account Management

A registrar must establish an account in which billing activities take place. 
The account may be either a deposit account, or based on an irrevocable Letter 
of Credit, in order to be debited and credited for ongoing domain 
name "billable" transactions (registrations, renewals, transfers, and so on).  

·	Cash Deposit: A deposit account where cash has been deposited in order 
to maintain a positive balance against the amount owed to the registry. The 
wire transfer requirements and banking information are given to the registrar. 

·	Letter of Credit: The irrevocable transferable Stand-by Letter of 
Credit from an acceptable bank provides security for the registrars' 
satisfaction of its obligations under the Registry-Registrar Agreement. 

To establish an account, a registrar must complete a Credit Information Form 
and a Registrar Data Form. Registrars establish credit in the .net SRS system 
to commence registrations.

B. Account and Billing Payment Policies

1. Credit Policies

As domain names are registered, the registrar account is debited. The 
registrar's credit limit is based on the irrevocable letter of credit, cash 
deposit, or combination thereof maintained with Afilias. A monthly invoice 
will be mailed from Afilias to the registrar for domain names processed during 
the preceding month.

If the registrar fails to pay the invoice within terms or if the payment 
security should be depleted, registration of domain names for the registrar 
will be suspended and new registrations will not be accepted until the payment 
security is replenished. The registrar should ensure timely payment of 
invoices and will provide Afilias with a notification threshold sufficient to 
prevent the payment security account from depleting to zero.

2. Payment Policies

·	Payment must be made in U.S. dollars. 

·	Confirmation of receipt of funds will be sent to the Billing Contact 
#1 e-mail address designated by the registrar on the Registrar Data Form. 

Statements of activity will be sent at least monthly.

·	Funds must be wired to the international bank designated from time to 
time by Afilias. 

·	Funds will be credited to the registrar's account no later than the 
next business day following receipt by the designated bank. 

·	Registrars can access their account balance information in one of two 
ways: 

                 -  Online using appropriate identification protocols.

                 -  Directly with Afilias' financial services department 
during the hours of operation
                    announced by Afilias.

·	Only authorized personnel of Afilias can modify this policy. 

C. Letter Of Credit Requirements

The irrevocable, transferable stand-by Letter of Credit must:

·	Be advised to the registry, in U.S. dollars and available for payment 
at the counters of the registry bank. 

·	Have a form and provisions acceptable to the registry, in its sole and 
reasonable discretion. 

·	Be issued by a bank approved by the registry, in its sole and 
reasonable discretion, and in the initial amount determined by the parties. 

·	Be maintained in full force and effect until the expiration of the 60-
day period commencing on the expiration or termination of the term of the 
Agreement. The Letter of Credit will be irrevocable for the term thereof and 
will provide that it is automatically renewable for successive one-year 
periods without any action whatsoever on the part of the registry; provided, 
however, that the issuing bank will have the right not to renew the Letter of 
Credit upon written notice, given by certified mail, to the registry. 

·	Allow multiple draws, and will allow the registry to draw against the 
irrevocable, transferable stand-by Letter of Credit in the event of (a) a 
breach of any payment obligation under the Agreement as determined by the 
registry and/or (b) upon receipt of any notice not to renew the irrevocable, 
transferable stand-by Letter of Credit. 

If, as a result of any draw of all or any part of the Letter of Credit, the 
amount of the Letter of Credit shall be less than the then required amount, 
registrar will promptly provide the registry with additional letter(s) of 
credit, or a cash security deposit, in an amount equal to the deficiency, and 
no default of registrar will be deemed cured until such deficiency is restored.

D. SRS Billing Subsystem

1. Overview

The SRS Billing Subsystem handles all billing events from Afilias created as 
part of normal registry operations. This mechanism also handles requests from 
the Afilias administration facility. The billing mechanism interfaces with the 
Afilias financial system via a database interface.

The SRS Billing subsystem is composed of the following:

·	SRS Billing subsystem event-driven mechanism: handles billing events 
from the registration process. 

·	Administration interface: enables Afilias administrators to operate 
the billing mechanism, and allows some self-service activities to the 
registrars. 

·	Notification system: sends out-of-band notices to warn registrars of 
low-balance conditions. 

2. Billing Events

The SRS Billing subsystem executes as a part of the same subsystem that 
controls base Afilias transactions. This ensures transactional integrity 
between the billing server and the Afilias server.

3. The Billing Process

Billing events require an immediate response and enable the registration 
process to take place. The billing implementation reflects a pre-paid billing 
model where a balance is debited for each bill event presented.

A negative response is returned by the billing subsystem if there are 
insufficient funds available to complete the requested event. An EPP operation 
that receives a negative response from the billing subsystem will return a 
2104, "Billing failure" response to the registrar that initiated the operation.

Each Billing subsystem event has a dependency on the Afilias Administrator 
having ensured the following:

·	The registrar is valid within the described registrars. 

·	The billing event is fully described with sufficient price 
information. 

·	There is a balance for any registrars who require processing for 
billable events. 

Billing events will record the transaction ID as outlined in the EPP 
specification. This enables Afilias events to be traced in terms of their 
billing consequences. Reversed billing events will record the transaction ID 
of the reversing event, and the original, charged event, to allow a complete 
audit of reversed events.

III. Security

Registrars can access their account information through the SSL-secured 
registry administrative interface. Account information is available to 
registrars on the .net Admin Web site with a valid User/Pass pair from a 
machine within the .NETnet extranet. This requires a browser capable of 128-
bit encryption. .NETnet may adopt other strong authentication standards 
including, but not restricted to, strong X.509 authentication. The Account 
Balance information page displays the registrar's funds available in U.S. 
dollars.

IV. Accessibility

A. Registrar Online Account Information

The interface also allows a registrar to change its contact information. These 
contacts must exist already within the .net database. The contacts represent 
the people who should be contacted by the registry for various administrative, 
billing, and technical functions. 

B. Administration

Administration is performed via the same Web admin interface that registrars 
use to update their contact information and query their balances. 
Administration staff is able to perform any operation on any registrar's 
account. There are several registry-only functions:

·	Add Registrar Account: Creates a new registrar account

·	Delete Registrar Account

·	Update Registrar Account: Allows the modification of fields that are 
read-only for registrars

·	Update Registrar Account Status: Change the operational status of a 
registrar account

·	Update Registrar Account Balance: Credit or debit the current balance 
for a particular registrar. This function is used when a registrar submits 
payment to Afilias. 

Permission to perform the various functions available through the interface is 
granted according to the roles system, an access-control list function 
implemented in the billing subsystem. Only registry administrators have access 
to all functions, including ability to use the interface to manage accounts 
for administration staff and define roles to restrict functionality on an 
account.

The administrative interface uses only SSL-secured connections via the Web. 

C. Notification System

Because registrars may have different staff members who control the operation 
of their registrar software and the financial arrangements they make with 
registries, the registry provides registrars' billing contacts with e-mailed 
notification of a low balance. This notification results when the registrar 
reaches a pre-determined threshold. The threshold can be calculated according 
to a preset formula, or can be a pre-set U.S. dollar amount requested by the 
registrar.

...  I. Overview

Afilias' software is designed and the servers are selected in such a way that 
a complete failure should never happen. In particular, the independent, 
replicated systems should ensure that there is always available a "live" copy 
of the registry systems available for use.  In order to offer additional 
insurance, however, and in order to provide a sure recovery path in the 
unlikely event of a failure, Afilias has a comprehensive backup strategy in 
place to ensure continued operations.


...  II. Frequency of backup

Snapshot backups are performed daily, at midnight UTC.

...  III. Procedures for Backup of Data

Zero-downtime, snapshot backups are performed daily, at midnight UTC. No 
special procedures are required to put the database in backup mode. The 
backups are made directly to the redundant-fibre-channel attached RAID array, 
and then copied (at lower speed) to LTO tapes housed in a local tape library. 

Tapes are rotated in and out of the library in such a way as to maintain a 
long-term archive. One backup per week is sent off-site and stored until 
locally housed backups expire. Additionally, one backup per month is stored 
off-site indefinitely in a Class A secure location. Other backups are 
overwritten after 30 days.

For application servers, back ups are performed via a completely isolated 
administrative network, to a shared tape library.  Backups are maintained for 
seven days, except that when a file is deleted, all versions of the file are 
stored off-site for 30 days, and the final version of the file stored off-site 
for 90 days.  These back-ups are maintained in IBM's secure storage facilities.


...  IV. Backup Hardware and Systems

Afilias maintains geographically separated live instances of the database to 
reduce the risk of needing to restore anything from backups. These instances 
are connected by redundant virtual private network connections, to ensure that 
the stand-by site is always synchronized with the primary site.  See section 
[###insert xref###]5.b.i for details of the provisioning of multiple sites. 

In the event of a catastrophe in the primary site, any of the secondary sites 
would allow Afilias to continue to function with a minimum of disruption. 

The backup device and media offer high reliability. Afilias selected only LTO 
drives using error-correction protocols during read and write operations, to 
ensure that no random errors are introduced to the data during transfer to 
tape. Mean time between failure for LTO drives is approximately 250,000 hours 
at 100% duty cycle, with a head life of approximately 60,000 hours. Back-up 
Data Format

The registry database is backed up using database-native tools and formats. 
The resulting files are then stored using Tivoli Storage Manager. All backed 
up data is held in Tivoli Storage Manager format, which enables restoration of 
data should that become necessary.


...  VI. Suggested Escrow Agent

The database backup is deposited each day with DSI Technology Escrow Services, 
a division of Iron Mountain Incorporated (NYSE: IRM). Iron Mountain receives 
escrowed data through encrypted transmission across the Internet. Iron 
Mountain provides dynamically scalable multi-terabyte storage as required.


...  VII. Procedures for retrieval of data/rebuild of database

In the case of a failure of the active node in the primary data cluster, 
processing would move automatically and seamlessly to an inactive node in the 
same cluster.  Only in the event that every node in the primary cluster failed 
would a secondary cluster be promited to primary.  In such an event, there 
would need to be a brief interruption in service, while data processing moved 
to the backup data server. This is necessary to ensure perfect data integrity. 
Because the data servers use external RAID arrays, a failure of the primary 
server does not entail the loss of the data stored there; instead, the data 
can be moved instantly to the secondary server. Only in the case of a complete 
RAID array failure is any reconfiguration necessary; such an interruption 
would last only briefly, because the data is replicated on another, identical 
array.

In the event of the total failure of the primary data center, registrars would 
be notified of the decision to move operations to a stand-by center. Except 
for the change in physical location, nothing will change in the manner of 
operation. 

The registry is prepared for the unlikely, cataclysmic case in which all data 
centers are destroyed at the same time. In this case, the registry will be 
able to restore operations by reverting to the most recently deposited escrow 
copy of the system. The registry's extensive backup arrangements will ensure 
that data will be preserved, the data can be restored, and operations can 
resume in a short period of time.

For DNS, as noted in the section Zone File Publication and Distribution 
section in Part VII, DNS changes are mirrored to at least four servers every 
two minutes. Veritas Tape Backup is used throughout the enterprise every 24 
hours. Tapes are stored off site. If needed, the Oracle database used for DNS 
has three re-installation methods: the normal installation script, an archived 
version that must be manually reconfigured, and an archived version with an 
automated re-configuration script. The database instance is then recovered and 
re-initialized through three creation scripts, all of which are version 
controlled.

...  I. Overview

Afilias provides for backups of the database and other active files to be 
deposited in secure offsite storage.  These backups guarantee that, given even 
a major catastrophe, the registry could be fully restored.

Afilias' design offers an easily audited escrow facility.  With the fully 
thick registry, there is a single, authoritative source for data on 
registrants for each domain.  The single data source means that only one 
escrow deposit needs to be audited to check for compliance.


...  II. Escrow Arrangements

The database backup is deposited each day with DSI Technology Escrow Services, 
a division of Iron Mountain Incorporated (NYSE: IRM).  Iron Mountain/DSI is 
the leading software and data escrow company in the world, with more than US$1 
billion in yearly revenues.  The files are encrypted using OpenPGP as 
documented in RFC 2440 [http://www.ietf.ORG/rfc/rfc2440.txt]), and sent to the 
secure servers of the escrow agent.  Iron Mountain uses an internally secure 
method to ensure the integrity of all deposits.

Non-database servers are also backed up daily, and seven versions are 
maintained of all active files.  One backup per week goes to the off-site 
facility and is recycled when the local copies expire.  If a file were to be 
deleted, all versions would be stored for 60 days; the newest version would be 
kept for a total of 90 days.


...  III. Data formats

All data submitted by registrars is in XML format.  This data is encrypted 
using OpenPGP as documented in RFC 2440 
[http://www.ietf.ORG/rfc/rfc2440.txt]), and sent to the secure servers of the 
escrow agent. In addition, full native database dumps, which are in SQL 
format, are similarly encrypted and sent to the escrow agent.  Should the data 
format specification from ICANN change, Afilias is prepared to adjust 
accordingly.


DO WE NEED TO ADD IN THE NATIVE FORMAT DATABASE BACKUP REFERENCES IN APPENDIX 
R?

...  IV. Insurance Arrangements

To support .NET, Afilias expects similar provisions to those included in 
the .INFO gTLD agreement with ICANN.  Specifically, Afilias' escrow agent will 
be requested to indemnify Afilias, Afilias and ICANN from and against any and 
all claims, actions, damages, suits, liabilities, obligations, costs, fees, 
charges, and any other expenses whatsoever, including reasonable attorney's 
fees and costs, that may be asserted by a third party against any indemnity in 
connection with the misrepresentation, negligence, or misconduct of the escrow 
agent. 


...  V. Backup Plans for Data Recovery

Complete details of our plan for recovery, including scenarios from partial to 
total failure of all data centers, are provided in Section N of Part 
E5.b.xviii, System Recovery Procedures.

...  I. WHOIS Overview

For the .NET registry, Afilias will provide accessible WHOIS database services 
which include accurate information about registrants for legitimate purposes 
that comply with ICANN policies.  Afilias intends to implement its registry 
database utilizing a commercial database system which meets the registry's 
needs for the currency, availability, and reliability of registry data.  The 
registry database will include a flexible WHOIS reporting system that conforms 
to existing ICANN policies and will be adapted to comply with emerging mobile 
community, regulatory and ICANN privacy policies as they are approved.

Afilias will support standard and restricted WHOIS data access, as well 
as "thin" and "thick" responses during the .net transition.


...  II. Hardware and Software

A. Hardware

There are at least two (2) WHOIS Servers (load balanced) on two physical 
enterprise-class servers for N+1 redundancy.  These are on a Shared 
Application server with an instance of Web Server and registry Server running 
on each enterprise server.  For details on hardware architecture, please refer 
to section 5. Technical Competence, part (i) Proposed Facilities and Systems, 
Hardware Architecture.

B. WHOIS (Port 43)

Afilias maintains a registry-level centralized WHOIS database that contains 
information for every registered domain.  The WHOIS service is available on 
the common WHOIS port (port 43) and contains data submitted by registrars 
during the registration process.  Changes made to the data by a registrant are 
submitted to Afilias by the registrar and are reflected in the WHOIS in near 
real-time, thus providing all interested parties with up-to-date information 
for every domain.  The WHOIS maintained by Afilias is authoritative, 
consistent, and accurate and people do not have to query different registrars 
for WHOIS information as there is only one central WHOIS system.

WHOIS is used to look up records in the Afilias database.  Information about 
domain, host, contact, and registrar objects are searchable using this WHOIS 
service.

The WHOIS system has been designed keeping in mind robustness, availability, 
and performance.  Provisions for detection of abusive usage (e. g., excessive 
numbers of queries from one source) have also been made.  The WHOIS system is 
intended as a publicly available single object lookup.  Afilias uses an 
advanced, persistent caching system to ensure extremely fast query response 
times.

Information available through the standard WHOIS database includes:

·	Registrant contact information, including names, postal and e-mail 
addresses, and telephone numbers of technical, administrative and billing 
contacts

·	Registration status and registration's expiration date

·	Date registration was issued for domain name

·	Registrar contact information, including name, postal and e-mail 
addresses, and telephone number

·	Registrar status, including whether registrar is in good standing with 
Afilias

·	Technical information about each domain name, including information 
about nameserver and IP address.

·	As relevant, additional information regarding the privacy policy 
applicable to the stored information.

·	Authoritative WHOIS information for "thin" domain names

We will develop restricted WHOIS functions based on .NET policy , regulatory, 
and telecommunications requirements and will develop these functions as 
required for operating the business.  It is also possible that contact and 
registrant information can be returned based on a user's privacy 
specifications and regulatory requirements.

C. Web-based WHOIS

Afilias and the .NET registrars will provide an input form on their public Web 
sites, through which a visitor can perform WHOIS queries.  The input form 
accepts the string to query, along with the necessary input elements to select 
the object type and interpretation controls.  This input form sends its data 
to the port 43 WHOIS server.  The results from the WHOIS query are returned by 
the server and displayed in the visitor's Web browser.

The sole purpose of the Web interface is to provide a user-friendly interface 
for WHOIS queries.  It does not provide any additional features beyond those 
previously described in this section.


...  III. Connection Speed

A. WHOIS System Capacity

Afilias' WHOIS system supports almost 225 million WHOIS queries per month (as 
of December, 2004) and consistently maintains its .INFO Service Level 
Agreement (SLA) to provide WHOIS singular query/response in under 800 
milliseconds (September, 2004 actual: Avg. 82ms and October, 2004:  Avg. 
60ms).  The ORG SLA results for September/October, 2004, are:  September 
actual: Avg. 110ms and October:  Avg. 64ms.  The WHOIS systems have sufficient 
capacity to withstand sustained requests for the .NET domain.

B. WHOIS Rate Limiting

Abuse of WHOIS services at the registry level will be subject to an automated 
rate-limiting system that will ensure that the uniformity of service to users 
will be unaffected by a few parties whose activities might threaten to 
overload the WHOIS system.

Data mining of any sort without prior written permission on the WHOIS system 
will be strictly prohibited, and Afilias reserves the right to take all 
appropriate actions should data-mining activities be noticed on its WHOIS 
system.


...  IV. Search Capabilities

A. WHOIS Queries

For all WHOIS queries, a user is required to enter the character string 
representing the information for which they want to search.  The object type 
and interpretation control parameters to limit the search are required to be 
used.  If object type or interpretation control parameters are not specified, 
WHOIS will search for the character string in the Name field of the Domain 
object.

WHOIS queries are required to be either an "exact search" or a "partial 
search", both of which are insensitive to the case of the input string.

·	An exact search specifies the full string to search for in the 
database field.  An exact match between the input string and the field value 
is required.  For example, `icann.net' will only match with `icann.net.' 

·	A partial search specifies the start of the string to search for in 
the database field.  Every record with a search field that starts with the 
input string will be considered a match.  For example: `icann.net' will match 
with 'icann.net' as well as `icann.net, Ltd'.  By default, if multiple matches 
are found for a query, then a summary containing up to 50 matching results is 
presented.  A second query will be required to retrieve the specific details 
of one of the matching records. 

If only a single match is found, then full details are provided.  Full detail 
consists of the data in the matching object as well as the data in any 
associated objects.  For example: a query that results in a domain object 
includes the data from the associated host and contact objects.

B. Query Controls

WHOIS query controls fall into two categories:  1) those that specify the type 
of field, and 2) those that modify the interpretation of the input or 
determine the type of output to provide.

1. Object Type Control

The following keywords will restrict a search to a specific object type:

·	Domain:  Searches only domain objects.  The input string is in the 
Name field. 

·	Host:  Searches only name server objects.  The input string is 
searched in the Name field and the IP Address field. 

·	Contact:  Searches only contact objects.  The input string is searched 
in the ID field. 

·	Registrar:  Searches only registrar objects.  The input string is 
searched in the Name field. 

By default, if no object type control is specified, then the Name field of the 
Domain object will be searched.

2. Interpretation Control

The following keywords modify the interpretation of the input or determine the 
level of output to provide:

·	ID:  Search on ID field of an object.  This is applied to Contact IDs 
and registrar IDs. 

·	Full or '=':  Always show detailed results, even for multiple matches. 

·	Summary or SUM:  Always show summary results, even for single matches. 

·	'%' or '...':  Used as a suffix on the input, will produce all records 
that start with that input string. 

·	'_':  Used as a suffix on the input, will produce all records that 
start with that input string and have one and only one additional character. 

By default, if no interpretation control keywords are used, the output will 
include full details if a single record is found and a summary if multiple 
matches are found.

C. WHOIS Output Fields

This section describes the output fields provided for each type of object.  
For purposes of demonstration, it assumes that full contact data should be 
returned.

1.  Domain Record

A WHOIS query that results in domain information will return the following 
fields from the Domain object, and the associated data from Host and Contact 
objects.  This set of data is also referred to as the Domain Record.
      Domain Name
      Sponsoring Registrar
      Domain Status
      Registrant, Administrative, Technical and Billing Contact Information 
including
           Contact ID
           Contact Name
           Contact Organization
           Contact Address, City, State/Province, Country
           Contact Postal Code
           Contact Phone, Fax, E-mail
      Name Servers associated with this domain
      Domain Registration Date
      Domain Expiration Date
      Domain Last Updated Date

2.  Name Server Record

A WHOIS query that results in name server information will return the 
following set of information, referred to as the Name Server Record or Host 
Record.
      Name Server Host Name
      Name Server IP Addresses if applicable 
      Sponsoring registrar
      Name Server Creation Date
      Name Server Last Updated Date

3.  Contact Record

A WHOIS query that results in contact information will return the following 
set of information, referred to as the Contact Record.
      Contact ID
      Sponsoring registrar
      Contact Name
      Contact Organization
      Contact Address, City, State/Province, Country
      Contact Postal Code
      Contact Phone, Fax, E-mail
      Contact Registration Date
      Contact Last Updated Date

4.  Registrar Record

A WHOIS query that results in registrar information will return the following 
set of information, referred to as the registrar Record.
      Registrar ID (conforming to the IANA registrar-ids registry)
      Registrar Name
      Registrar Status
      Registrar Address, City, State/Province, Country
      Registrar Postal Code
      Registrar Phone, Fax, E-mail 
      Registrar Creation Date 
      Registrar Last Updated Date

D. Sample Outputs 

This section describes example output provided for each type of object.   For 
purposes of demonstration, it assumes that full contact data should be 
returned.  Further examples of outputs for "thin" RPP and EPP domains, IDN, 
and DCP enabled domains can be found in Section 7.3 of Appendix O.


1. Domain

a. Input: 

WHOIS mydomain.net

b. Output:

Domain ID:D5353344-LRNT
Domain Name:WHOISDOMAIN.NET
Created On:01-Jan-2005 04:00:00 UTC
Last Updated On:10-Jan-2005 20:25:23 UTC
Expiration Date:01-Jan-2007 04:00:00 UTC
Sponsoring Registrar:EXAMPLE REGISTRAR LLC (R63-LRNT)
Status:DELETE PROHIBITED
Status:RENEW PROHIBITED
Status:TRANSFER PROHIBITED
Status:UPDATE PROHIBITED
Registrant ID:5372808-ERL
Registrant Name:EXAMPLE REGISTRAR REGISTRANT
Registrant Organization:EXAMPLE REGISTRANT ORGANIZATION
Registrant Street1:123 EXAMPLE STREET
Registrant City:ANYTOWN
Registrant State/Province:AP
Registrant Postal Code:A1A1A1
Registrant Country:EX
Registrant Phone:+1.1235551234
Registrant Email:EMAIL@EXAMPLE.COM
Admin ID:5372809-ERL
Admin Name:EXAMPLE REGISTRAR ADMINISTRATIVE 
Admin Organization:EXAMPLE REGISTRANT ORGANIZATION
Admin Street1:123 EXAMPLE STREET
Admin City:ANYTOWN
Admin State/Province:AP
Admin Postal Code:A1A1A1
Admin Country:EX
Admin Phone:+1.1235551234
Admin Email:EMAIL@EXAMPLE.COM
Billing ID:5372810-ERL
Billing Name:EXAMPLE REGISTRAR BILLING 
Billing Organization:EXAMPLE REGISTRANT ORGANIZATION
Billing Street1:123 EXAMPLE STREET
Billing City:ANYTOWN
Billing State/Province:AP
Billing Postal Code:A1A1A1
Billing Country:EX
Billing Phone:+1.1235551234
Billing Email:EMAIL@EXAMPLE.COM
Tech ID:5372811-ERL
Tech Name:EXAMPLE REGISTRAR TECHNICAL 
Tech Organization:EXAMPLE REGISTRAR LLC
Tech Street1:123 EXAMPLE STREET
Tech City:ANYTOWN
Tech State/Province:AP
Tech Postal Code:A1A1A1
Tech Country:EX
Tech Phone:+1.1235551234
Tech Email:EMAIL@EXAMPLE.COM
Name Server:NS01.EXAMPLEREGISTRAR.NET
Name Server:NS02.EXAMPLEREGISTRAR.NET

2. Host

a. Input: 

WHOIS Host ns01.exampleregistrar.net

b. Output:

Host ID:H123456-LRNT
Host Name:NS01.EXAMPLEREGISTRAR.NET
Sponsoring Registrar:R123-LRNT
Created On:01-Jan-2005 20:21:50 UTC
Last Updated On:01-Jan-2005 20:22:58 UTC
IP Address:192.168.0.100

3. Contact

a. Input:

WHOIS C ID CNT-2222

b. Output: 

Contact ID:CNT-2222
Sponsoring Registrar:R1234-LRNT
Name:EXAMPLE CONTACT
Organization:EXAMPLE ORGANIZATION LLC
Street1:123 EXAMPLE STREET
City:ANYTOWN
Postal Code:A1A1A1
Country:EX
Phone:+1.4443331234
Email:EMAIL@EXAMPLE.COM
Created On:01-Jan-2005 14:33:12 UTC

4. Registrar

a. Input: 

WHOIS registrar Example Registrar LLC

b. Output: 

Registrar ID:R145-LRNT
Registrar Organization:Example Registrar LLC
Street1:123 Example Street
City:Anytown
State/Province:EX
Postal Code:A1A1A1
Phone:+1.5558881234
Fax:+1.5558884567
Email:email@example.com
Created On:01-Jan-2005 21:25:42 UTC
Last Updated On:03-Jan-2005 15:52:46 UT
Status:OK


...  V. Coordination with Other WHOIS Systems

The .NET registry system will conform to RFC 954 as well as ICANN's WHOIS 
standards.  Afilias has a demonstrated track record of adopting industry best 
practices (such as cross-registry standard WHOIS status fields for RGP).


...  VI. Frequency of WHOIS Updates, Availability and Processing Times

The .net WHOIS will be updated in near real-time thus providing all interested 
parties with up-to-date information for every domain.  Being a critical part 
of the entire registry system, the WHOIS will maintain similar SLAs for both 
availability and processing times as other registry components.  For further 
information related to availability and processing times please refer to 
Section 5. part (xiv) as well as Appendix E.


...  VII. Using a "Thick" Registry Model as Opposed to a "Thin" Registry Model

The .NET registry system will be migrated from a "thin" to a "thick" system.  
Afilias believes that moving the .NET registry to a "thick" registry model 
will provide registrants with a more reliable, authoritative, secure, and 
centralized WHOIS service.  For the details of the thick registry, please see 
section 5. Technical Competence, part (iv) Registry-Registrar Protocol, 1. EPP 
Registry-Registrar Model, A. Overview.  For details on how Afilias plans to 
migrate the .NET registry to a "thick" registry model, please see section 2-8.

[RESPONSE IS CONFIDENTIAL]

I. Overview

The Afilias system has been designed to be scalable while maintaining 
reliability, stability and speed.  The following three examples illustrate the 
ability of the system to absorb sudden large load increases.

The first example is the migration of the .ORG domain of 2.8 million domains 
from VeriSign to Afilias' system in 2003.  While the number of transactions 
increased substantially, our speed of response improved as shown below:

·	Jan 2003:   64 million transactions, average WHOIS:  45ms

·	Jun 2003:   400 million transactions, average WHOIS:  42ms
 
·	Dec 2003:  1 billion transactions, average WHOIS:  39ms

The second example is reflective of committed improvements to registry 
performance well in advance of anticipated growth.  Afilias invested in 
significant infrastructure upgrades in September 2004 even though the .ORG 
Registry transactional times were running well under the SLA. 

·	August 2004    (Pre-Upgrades): SRS write transactions average: 373ms 
(SLA:  800ms)

·	October 2004  (Post Upgrades): SRS write transactions average: 133ms 
(SLA:  800ms)

·	October 2004  WHOIS singular query/response:  Avg. 64ms (SLA: 800ms) 

·	The third example is the resilience of our system in the face of the 
largest DDoS attack of 2003.  While some root servers were slowed down or 
taken completely out of service, domains served by Afilias remained in 
operation without any impact on performance.

Our ability to maintain service quality despite variations in load is critical 
to the satisfaction of .NET users, who demand and deserve reliability and 
quality.  Our system has the capacity to support the expected volumes and peak 
demands of .NET.  And we have the ability to scale it quickly should .NET 
expand faster than anticipated.


...  II. Handling a Larger-Than-Projected Demand for Registration or Load

In the event of unexpected or unplanned load that results in contention; the 
registry server complex has the ability to provide equal access to all 
registrars for those available resources.

Registrar Add Storms, Rate Limiting and Guaranteed Bandwidth

A. Sustained and Peak Bandwidth

While projected sustained bandwidth for the .NET registry is currently 5 
megabits per second, the Internet connectivity solutions provided for at both 
the primary and secondary sites are dynamically scalable to 100 megabits per 
second.

B. Bandwidth and Connection Throttling Controls

Equal access to all registrars for all available resources will be provided 
through use of a rate-limiting and bandwidth shaping network appliance. This 
device will limit each registrar from their permitted known IP sources to a 
combined maximum number of concurrent connections and bandwidth to the 
registry. The total number of connections permitted to each registrar will be 
decided based on connection usage policy to be stated in the final 
registry/registrar agreement.

These devices are also capable of throttling or shaping specific types of 
packet requests, allowing the registry operator to set priorities on not only 
the number of concurrent connections a registrar is permitted, but to also 
prioritize the type of traffic.

These devices are part of a strategic design to handle aggression attempts to 
register desirable names pending re-release.  Fair access to public WHOIS 
services will be handled using a combination of total concurrent connection 
handles, limitations to wildcard searches, and an aggressive high duplicate 
response system (specifically designed to handle large volumes of repeated 
same requests).


...  III. Effects of Load on Servers

A. Application Layer

The registry applications are designed to have stateless operation with load 
balancers.  This permits dynamic scaling at the application layer for all 
registry functions.  The registry applications are expected to exercise 5-6% 
sustained load on the currently slated application servers, with bursted loads 
of up to 12-13%.  The registry application servers will be operated with a 
minimum bursted capacity of 50% over sustained loads.  In the event of 
unexpected load increase, this available overhead should permit the registry 
Operator to promote additional application servers into production without 
expected degradation of service. 

B. Database Layer

Database servers in use will have the capacity to dynamically add additional 
processors and memory.  As primary services will be balanced across the two 
main database load averages on currently slated database servers are expected 
to operate at a sustained 12-15% of capacity, with bursted loads of 20-25%.  
The database servers will be operated with a minimum bursted capacity of 50% 
over sustained loads.  (Multi-version concurrency control (MVCC) ensures that 
every user sees a view of the database proper to the transaction.  Traditional 
locking makes for slow query times when under high load. MVCC prevents that 
problem, meaning that queries are just as fast for 1,000 users as for 100 or 
10).  In the event of unexpected load increase, this available overhead should 
permit the registry Operator to add additional memory and CPU to continue to 
scale load appropriately.  Disk storage space is provided for in an external 
disk array and can be added to dynamically, while available unused disk space 
will be maintained at levels of 50% over sustained usage.  In addition, the 
registry operator will continually monitor new advances in dynamically 
scalable database clustering technologies, with the intent of incorporating 
such a solution when proven reliable and secure.  In view of the current 
design of the registry database, which focuses on two main databases, this 
data structure can be further distributed across more databases in the event 
of unexpected increased load.  For more details about redundancy and capacity 
of the database layer please refer to Section 5b(v).


...  IV. Effects of Load on Databases

In view of the current design of the Afilias database, and its performance in 
scaling to meet the needs of .ORG, we anticipate no problems in scaling to 
meet the .NET demand.

In addition, the database systems will run on a fully redundant cluster of 
servers.  Afilias continually monitors new advances in dynamically scalable 
database clustering technologies, with the intent of incorporating such a 
solution when proven reliable and secure.  For more details on database 
capacities please refer to Section 5b(v).


...  V. Effects of Load on Backup Systems

Backup systems will be based on high-speed, production to cached disk to high 
capacity LTO drives in both the primary and secondary sites using Tivoli 
Storage Manager.  This is a fully managed service provided by IBM and is 
dynamically scalable to be able to provide multi-terabyte storage capacity if 
required.


...  VI. Effects of Load on Support Systems 

Support systems will include WHOIS, invoicing, and DNS.  WHOIS and invoicing 
systems are designed to work from replicated databases, not the main 
production database.  Excessive production system load will not affect 
performance on these support systems.

While DNS resolution is completely unaffected by increased production loads, 
updates to the DNS may be affected since the database changes won't be 
available as quickly.  Rate of DNS updates is configurable and can be 
throttled under heavy loads.


...  VII. Effects of Load on Escrow Systems

Iron Mountain will receive escrowed data on a daily basis through encrypted 
transmission across the Internet and provide dynamically scalable multi-
terabyte storage as required.


...  VIII. Effects of Load on Maintenance

Ongoing maintenance work is largely focused on optimization of the databases 
and promotion of software enhancements.  Afilias has a highly advanced 
replication system deployed on highly redundant cluster of servers which 
allows us to take a complete cluster out for extended maintenances periods 
without impacting the time for maintenances if needed.  This would allow a 
phased approach to database maintenance cycles and schema changes with code 
promotion, allowing the registry to maintain the slated maintenance cycles.

Other uses of maintenance periods include the updating of registry software to 
add enhanced and improved feature sets.  Additional and unexpected loads will 
not affect the maintenance periods required for code promotion except in the 
event of a large schema change.


...  IX. Effects of Load on Personnel

In the event of unexpected volumes of registration, the primary staff area 
that would be affected is the technical and customer support staff.  These 
departments are structured heavily with well-documented procedures and 
training materials giving Afilias the ability to rapidly train additional 
staff.  Running on a 24x7 basis, the Tech Support group has the ability to 
double up personnel on a shift-to-shift basis in response to unexpected load 
capacity.  In further support of these areas, at any given time there are two 
managers available on call to assist with any unexpected staffing issues.

...  I. System Reliability Overview

Afilias has an experienced technology management team leading an expert staff 
of technical support, customer service, and product management specialists who 
assist registrars and registrants 24x7x365.  This disciplined team has created 
well-defined processes that allow it to avoid emergencies and quickly address 
issues as they arise.

Afilias has a proven track record of running a reliable registry system.  
Afilias has consistently performed within the ICANN Service Level Agreements 
(SLAs) for both .INFO and .ORG registries.

Among the contributors to the reliability of Afilias' system are:

·	A history of performing under heavy load

·	Proven, stable registry system

·	Redundant and scalable registry system architecture

·	Redundant DNS network

·	Software development and methodology

·	Extensive testing

Afilias recognizes that operational reliability is critical for the .NET 
domain.  Within this competitive environment, it is important to evaluate 
provider reliability against common benchmarks.  Three issues are important to 
consider in an evaluation of reliability: 1) total registry availability; 2) 
transparency and accountability; and 3) performance versus equivalent 
benchmarks.  The data illustrate that Afilias operates .INFO in a more 
reliable manner than .BIZ, .COM or .NET are operated.

1. Total Registry Availability:  INFO has the least downtime.

One can assess total registry availability by examining the Registry 
Operators' Reports published on the ICANN site.  In these monthly reports, 
each Registry Operator must disclose the amount of time the registry was 
actually out of service, which is the best true indicator of registry 
reliability.

A close examination of the Jan - Sept 2004 data (the most recently published 
data) shows the following cumulative minutes of downtime (planned plus 
unplanned) by domain:

                                Minutes of Registry DOWNTIME Jan - Sept 2004

             gTLD                                   Minutes
            --------                                  ------------
.INFO:	1,174 minutes (.INFO has the least downtime)
.BIZ:	1,650 minutes
.ORG:	1,685 minutes (.ORG beats .COM and .NET)
.NET:	1,936 minutes
.COM:	1,936 minutes

2. Transparency and Accountability:  .INFO is the most transparent.

Afilias has also set the standard for transparency and accountability.  On a 
monthly basis, Afilias faithfully reports results on 25 indicators of registry 
performance on .INFO, and provides the same 25 indicators for PIR to report 
on .ORG.  NeuLevel by contrast, reports only 15 indicators on .BIZ.  And 
VeriSign is required to report on only 4 indicators, excluding indicators in 
areas such as nameserver and WHOIS availability and response times.  
Further,.NET and .COM results appear to be the same, raising concerns 
over .NET actual performance with respect to .COM

3. Performance versus Equivalent Benchmarks:  .INFO is better than .COM/.NET.

When evaluated versus equivalent benchmarks, .INFO is shown to have a much 
stronger record than .COM and .NET today.  One such critical indicator 
is "unplanned downtime."  VeriSign has an actual total of 258 minutes of 
unplanned outage during the January - September 2004 period for "both" .COM 
and .NET.  During the same period, .INFO had only 110 minutes. 

Performance versus the .NET standard:  The current .NET contract allows 240 
minutes per month of unplanned downtime.  By this standard, VeriSign has had 
zero months in which it exceeded the unplanned outage allowed for .NET 
and .COM during January - September 2004.  Holding Afilias to this 
standard, .INFO also had zero months in which it exceeded the allowance, 
and .ORG had one month.

Performance versus the INFO standard:  .INFO is only allowed 30 minutes of 
unplanned downtime per month.  By this standard, VeriSign would have exceeded 
the allowance in three of the last nine months on .NET as well as three of the 
last nine months on .COM, whereas Afilias exceeded the allowance in one month 
on .INFO and four months on .ORG.

.INFO is more reliable when evaluated in the context of equivalent benchmarks.

Although .INFO is the registry with the best overall reliability record, 
Afilias has taken steps to further improve performance.  The most significant 
action has been the complete phasing out of legacy servers and replacement 
with state of the art IBM servers.  This was done first on .INFO (the smaller 
domain at the time), and once proven, on .ORG.  The new servers have 
enabled .ORG to deliver zero unplanned downtime from August through year-end, 
2004.  Actions such as this have enabled us to set the industry standard for 
overall reliability.

In summary, careful scrutiny of the relevant data indicates that Afilias is 
the standard-setter for reliable registry performance.  We offer the lowest 
total downtime (see the table "Minutes of Registry DOWNTIME Jan - Sept 2004" 
above), the greatest level of transparency and accountability, and better 
performance when evaluated against equivalent benchmarks.  Afilias will 
improve .NET's current performance to meet our higher standards.

...  II. History of Performing Under Heavy Load

Afilias has continued to operate at the capacity to support a high volume, 
high transaction registry. 

In October 2004, the registry processed the following:

·	Over 700 million successful domain check commands

·	Over 400,000 successful domain create commands

·	Over 105,000 successful domain delete commands

·	Over 20 million successful domain info commands

·	Over 2.6 million successful domain update commands

·	Over 75,000 successful domain transfer commands

·	Over 250,000 successful domain renew commands

·	Almost 150 million WHOIS queries


...  III. Proven, Stable Registry System

Afilias' registry system has been demonstrated to withstand a number 
challenges including rapid scalability, Denial of Service (DoS) attacks, 
abusive registry behaviors such as Add Storms and EPP Check Storms, as well as 
emergencies such as the electrical power outage of 2003.

Afilias' registry system has demonstrated its ability to seamlessly handle 
increased load and rapid scalability.  The system has supported the growth of 
the world's third and fourth largest domains .ORG and .INFO.

Afilias' DNS system, supported by UltraDNS, withstood the DDoS attack on the 
Internet root servers in October 2002.  .INFO domain names continued to 
function and resolve quickly, resulting in no impact to the end-users.


...  IV. Redundant Registry System Architecture 

Afilias uses a distributed architecture to achieve the goals of scalability, 
reliability, and extensibility.  System redundancies exist at the network, 
hardware, database, and application layer.  The registry will use load 
balancers to assist in scalability as well as to prevent service outages.  The 
application layer architecture allows a fully scalable number of application 
instances of the system to be running simultaneously.  Automatic fail-over of 
the system and subsystems is an integral part of the design of the 
architecture.  Afilias services in the primary data center will be balanced 
across at least two main database systems.  The database systems will run on a 
fully redundant cluster of servers.  In the event one member of the cluster 
fails, another cluster member will assume the duties automatically.  

Connectivity between the Internet and the Primary and Secondary registry is 
via multiple redundant connections.  A separate network is used for backups.  
Load balancing is used for balancing all aspects of the registry, including 
the registry gateway, WHOIS services and DNS API Gateways.

There will be 24/7 on-site and remote network and system monitoring to ensure 
system uptime and performance at all times.


... V. Redundant DNS Network 

More than any other service, DNS operations require extremely high 
availability.  The registry, in partnership with UltraDNS, will provide 
guarantees that name services for .NET are available 99.999% of the time on an 
annual basis.  This unprecedented availability is due to UltraDNS' 
infrastructure of multiple, redundant servers, located throughout the world, 
as well as UltraDNS' peering arrangements with major network nodes.  Because 
of the multi-path replication their databases use, it would require a 
simultaneous failure of 90% of the servers in order to cause an outage.


... VI. Software Development

A. Overview

The registry has chosen to adopt the RAD methodology in its software 
development process.  We have developed a specific framework that is utilized 
to develop a new software product.  This framework involves several 
encompassing stages, including consultation/business development, core system 
design, architecture design, operational evaluation, implementation and 
operational growth and testing.

1. Business Development

The first stage of the development process is designed to finalize the 
business elements of the software product.  During specialized meeting 
sessions system requirements, business process flows, business logic, and 
system data requirements are developed and evaluated.  The result of this 
stage is a focused plan describing what services the software product will 
provide and how it will function to provide them.

2. Core System Design

With the plan from the initial stage of development completed, the registry 
will then begin the technical system design.  The system design stage is used 
to develop technical designs of the system.  Each different system 
object/module is designed using object-oriented design tools, pseudo code, and 
process outlines.  Procedures for storing data, interacting with clients and 
back end operations are designed and evaluated.  The result from this stage is 
an overall technical design and functional specification.

3. Architecture Design

Once the technical system design is ready, the hardware and software 
architecture is developed to provide a platform for the software product.  
This stage involves evaluating different hardware systems that would be most 
effective for the software product.  These evaluations are based on hardware 
capability, support systems, and financial considerations.  The software 
architecture is evaluated in a very similar way, specifically focusing on 
capability, support systems, and experience from other implementations.  The 
final result from this stage is plan for the support systems of the software 
product.

4. Operational Evaluation

During this stage, members of the management, operations and development teams 
involved evaluate all plans, specifications and requirements developed during 
the first three stages.  Evaluation takes place in coordinated sessions where 
any minor changes can be made.  However, if a critical piece of the overall 
plan needs to be changed, the evaluation team can refer the piece to be re-
developed in one of the previous stages.  The result from this stage is a 
final and locked software development plan that serves as a full blueprint for 
the entire project.

5. Implementation

In this stage, the software product is developed for the chosen hardware 
platforms and operating system environment using object-oriented programming 
languages, database development tools, and fourth-generation languages.  
Development test beds are built for software testing.  The software product is 
built and tested in increments, and the functionality grows with each build, 
from alpha to beta to full production.  The system hardware and software are 
installed in the planned data centers for rollout and tested to work with the 
software product.

6. Operational Growth and Testing

During this phase, the software product is successively upgraded in planned 
build and release cycles.  Software bug reports are addressed in each build 
and release.  Maintenance releases are developed for serious software problems 
that cannot wait until a planned upgrade release.  Each new release is 
required to go through the registry's rigorous and extensive multi-level 
quality assurance process.  A scaled down version of the Production 
environment is setup for testing of the software to eliminate any Operating 
system and Hardware incompatibilities as well.

7. Tools

The registry is using object-oriented analysis and object-oriented design 
tools for requirements evaluation and detailed software design.  We employ 
object-oriented programming, database development tools, and fourth-generation 
programming languages for software development.

The development process is managed by using a Concurrent Version System.  This 
system gives us the ability to maintain a code depository in a central 
location where all developers can access it.  It prevents code mismatch, 
duplication and other issues that can be introduced when many people are 
working on the same project. 

To facilitate bug tracking, the registry uses a comprehensive tracking 
system.  It tracks all bugs found during the various development and testing 
stages as well managing bug fix timelines, priorities and responsibilities. 

The following list gives examples of the tools the .INFO/.ORG registries have 
used in the past and would use with .NET: 

JAVA, C/C++, SSLava, Xerces, Struts, VI, Electric XML, JSSE 


... VII. Software Quality Assurance

A. Overview

Once the software product has been developed, it must undergo several unique 
levels of testing.  Each level is specifically designed to not only test 
different functions of the software, but also to verify each function's 
interactive-ness and ability to work as one unit. 

B. Level 1: Functional Testing

Level one is designed to verify that all operational functions of the software 
are working as designed.  This includes all possible commands, negative cases, 
billing operations, DNS, WHOIS, Web interface and reporting.  Any changes to 
backend/internal logic and operation are also tested.  The software product 
must go through this test a minimum number of times to verify that consistent 
results are be obtained.

C. Level 2: Distributed Environment Testing

Level two is designed to test how the software performs on a distributed 
environment.  This means that each separate component of the software is 
placed on its own server to simulate real production and then evaluated to 
make sure that component interaction performs as expected.  The functions that 
are tested here include all possible commands, negative cases, billing 
operations, DNS, WHOIS, Web interface and reporting as well as any back end 
changes.  This test is similar to the level one test, however it is based on 
many different machines and the database contains a large dataset.  This test 
is also performed a minimum number of times to verify that the results are 
consistent.

D. Level 3: Load Testing

Level three is designed to evaluate our software on a basis of how well it 
handles different degrees of load.  The registry employs many different types 
of load tests to verify that our software performs to its performance 
specifications.  The load tests are designed to send load incrementally at the 
server.  They start off at a low level, and slowly progress to a massive load 
scenario that is actually beyond what the system allows during production.  
Each load test is a series of mutable and non-mutable transactions.  These 
tests not only demonstrate that the system can handle requests from many 
different connections, but also that data integrity is maintained while client 
requests are being served.

E. Tools

The registry has developed many different tools to test software 
functionality.  We have specialized test harnesses for which many test cases 
have been developed to evaluate software product.  We test the software on 
many different levels, from pure XML and protocol compliance to high level 
reporting and accounting operations.  Each tool can be easily operated and 
quickly adapted to many different types of tests.  The following is a list of 
some of the tools we currently employ in our projects.

Examples:

·	EPPTT:  XML-based client, highly configurable, used for all types of 
testing. 

·	OXRSTT:  High speed low memory footprint, C based EPP load tool. 

·	WAPT:  Tool to load test web applications. 

·	RTT:  RTK-based client, used to verify RTK operations as well as all 
types of testing. 

·	TCP/SSL Test Tool:  Used to test different cases in regards to 
connection management. 

·	WHOIS/DNS Tool:  Used to verify WHOIS and DNS accuracy. 


... VIII. Overview of Testing Platform

To facilitate the quality assurance process, the registry has built an 
extensive testing platform.  Hardware that is located in the testing platform 
is a scaled down version of the production environment.  Hardware is divided 
into two separate sections.  The single server section developed for level 1 
testing, and the multi- server section developed for both level 2 and 3 
testing.  Each server is set-up to specific variables to mirror the production 
environment as much as possible providing a testing platform as reflective of 
production as possible.

Database and system administration specialists will be available 24 hours a 
day, seven days a week, to aid in system support when necessary.  Quality 
Assurance and Development resources are also available 24 hours a day for any 
software enhancements and bug fixes that require immediate attention.

Any changes will be documented in a central location, so that there is a well-
known location for staff to find the latest news about the system.  Problems 
are tracked in a ticketing and bug reporting system that affords the 
development of a comprehensive system history. 

The system has been designed and implemented with an eye to simplicity.  "Keep 
it simple" design reduces the potential for failure due to mis-configuration, 
and ensures that the system is not so complex that no one can understand it.  
Modular design ensures the separation of components, so that interdependencies 
will not render the whole system inoperative if a single component were to 
fail.

These policies and procedures all rely on the extensive experience Afilias has 
in operating the .INFO and .ORG registries.  Afilias will use commercially 
reasonable efforts to provide registry services for the .NET TLD.  The 
performance specifications provide a means to measure registry operator's 
delivery of registry services including WHOIS and DNS.  Please refer to 
Section 5, Appendix D for details concerning registry performance 
specifications.

...  I. Overview

Afilias' system relies upon multiple, high-availability components in order to 
reduce the risk of failure. The SRS and WHOIS services are able to continue to 
function, even in the event of a total failure of one server. Subsystems are 
interconnected with redundant networks, to ensure that a data path is always 
available. The whole system is designed to avoid single points of failure.

Afilias deploys a tested, stable design, based on the experience of supporting 
other large registries, such as .ORG and .INFO.

Specified below are few factors that allow Afilias' system to resist outages.

·	Selected fault tolerant hardware deployed in grade "A" data centers so 
that, in most cases, the hardware can function even if part of it is damaged 
and can be serviced without interruption. 

·	Built the system with multiple-redundant subsystems to ensure the 
entire system remains functional even if whole subsystems fail. 

·	Placed its data centers at multiple, geographically separated 
locations to ensure service even upon the complete destruction of one data 
center. 

·	Uses hardware and programming techniques that guard against 
introduction of bad data and allow multiple audit paths. 

·	Uses development and operations policies and procedures to ensure the 
system always functions. 

More than any other service, DNS operations require extremely high 
availability. The registry, in partnership with UltraDNS, will provide 
guarantees that name services for .NET are available 99.999% of the time on an 
annual basis. This unprecedented availability is due to UltraDNS's 
infrastructure of multiple, redundant servers, located throughout the world, 
as well as UltraDNS's peering arrangements with major network nodes.


...  II. Procedures for Problem Detection

All systems are monitored continuously for performance from multiple 
locations. Anomalies are escalated immediately to management and appropriate 
action taken. Unauthorized access attempts are treated as anomalies.

The system is monitored for security breaches from within the data center, 
using both system-based and network-based testing tools developed by IBM. Use 
of isolated VLANs is practiced for enhanced security and access control.

·	7X24 Server Management using real time tools: 

               - Software management

               - System administration

               - Security administration

               - Inventory management

               - Alert management

·	7X24 Network Management using real time tools

               - Monitoring of all network components

               - Performance and load monitoring

               - Real time alerts 

               - Multiple levels of pre-defined escalation paths

Afilias' Network Operations staff also monitors systems for security-related 
performance anomalies. Triple-redundant monitoring ensures multiple detection 
paths for any compromise.

Except for administration of the system, interaction with the database happens 
only through the application server. Access from the application layer to the 
database layer is controlled through the firewall. This assures careful data 
normalization before any data reaches the data store. Keeping data 
normalization and data integrity checks outside the database ensures that no 
malicious or mistaken input will get into or persist in the system.


...  III. Redundancy of All Systems

Afilias, via contract with IBM, maintains the main databases in two 
geographically separate data centers. The primary facilities are fully hosted 
solutions in IBM's V3 telco-grade, high security buildings. The secondary and 
all other fail-over production sites are in V5 facilities (Managed and Self-
Managed Data Centers).

Afilias also has a data center at Q9 Network' facility in Toronto. This adds 
to redundancy in terms of vendor diversity.

The DNS service is also highly redundant, enabling the 99.999% uptime 
commitment. This unprecedented availability is due to UltraDNS' infrastructure 
of multiple, redundant servers, located throughout the world, as well as 
UltraDNS' peering arrangements with major network providers. By injecting a 
BGP route from each node, the system routes user queries to a topologically 
nearby node, resulting in reduced network latency for DNS transactions, fewer 
queries that are routed to distant servers and fewer dropped query packets. 
Should a name server fail to answer for any reason, the routing announcement 
for that node is withdrawn, removing it from the "reach" of an end user.

All data is backed up regularly and escrowed in an offsite secure location to 
enable recovery in the event of disaster.

...  IV. Backup Power Supply
There are 2 utility feeds from 2 substations at all data centers. Automatic 
transfer scheme (ATS) restores power if one line is lost. There is N+2 
redundancy architecture for the generators at the data center.

Multiple module, parallel redundant UPS power units with battery backup 
provide clean and reliable electrical power. The facilities are fitted with 
redundant diesel generators to be able to weather an extended power failure.

On-site resources enable approximately 50 hours of operation before fresh 
supplies are needed.

Afilias' back up power and disaster recovery plans are tested and proven.  Our 
systems have withstood even the most challenging emergencies, such as the 
electrical power outage of August 2003.

As stated earlier, Afilias' operational facilities are geographically 
diversified, with our operations center located in Toronto, Canada and co-
location facilities provided by Q9 in Toronto and IBM out of St. Louis and 
Secaucus, New Jersey USA. During the blackout, the grids powering the Q9 and 
IBM Secaucus, NJ facilities suffered from a prolonged loss of power prompting 
Afilias to launch its disaster recovery procedures. IBM's St. Louis center is 
maintained on a separate power grid and therefore was not affected by the 
blackout.

Afilias' was able to immediately respond to the issue and rely on established 
procedures for back-up generator power and existing policies for staff support 
to fail over to other locations not affected by the blackout.

Afilias was able to continue to provide excellent service for the .INFO 
and .ORG domain names without interruption and without degradation throughout 
the entire blackout period which lasted for 30 hours.

Our learnings from this event have helped Afilias strengthen our disaster 
recovery procedures and have spurred our introduction of new improvements to 
our plans.


...  V. Facility Security

The components of the system are located in Class A secure facilities (for 
additional discussion of facility security. For complete information, please 
see 5. Technical Competence, part (xiii) System Security and Physical 
Security. The primary site copies its data to other secure locations, so that 
the complete destruction of the entire primary data centre would not destroy 
the ability to register and query names.

There are 24/7 onsite security personnel and access is only for authorized 
personnel via Access cards/biometric scans. All areas are monitored by 
security cameras. Specially trained staff monitors all circuit breakers, 
switches, switchgear, UPS systems, generators, chillers, air handlers and air 
supply for the data center. There is telco-service and last-mile diversity.


...  VI. Technical Security

Afilias uses a five-tier design to ensure that each service is exposed only as 
much as is necessary. (See 5. Technical Competence, part (xiii) System 
Security and Physical Security for details.) Different services are isolated 
to reduce exposure. The tiers are segmented on the network.

Afilias uses only strong encryption and multiple authentication methods in all 
tiers. EPP connections are encrypted using SSL, and authenticated using both 
certificate checks and login/password combinations. Web connections are 
encrypted using SSL in the browser, and authenticated in the same manner as 
EPP connections. Connections to the extranet are limited to pre-approved IP 
addresses, so that an attack would have to come from a trusted source before 
it could attempt to foil other authentication methods.

Finally, to ensure that hosts configured erroneously or maliciously cannot 
deny service to all registrars, Afilias uses traffic shaping and quality of 
service technologies to prevent attacks from any single registrar account, IP 
address, or subnet. This additional layer of security reduces the likelihood 
of outages for all registrars, even in the case of security compromise at a 
subset of registrars.

Access to make changes to the registry systems are limited to specially 
trained, expert system and database administrators. Special procedures are in 
place for security purposes in the event any personnel having access to the 
systems has left the organization.


...  VII. Availability of Backup Software/Operating System/Hardware

A. Backup Software

Afilias' system uses multiple-redundant subsystems to ensure that, in the 
event of a failure of any component, the entire system is not affected. Each 
server in the primary data centre is paired with another server, so that one 
server may be removed from service without affecting data processing. Should 
it become necessary to remove a single server from service, its paired member 
will continue to provide the affected service. All software used for the 
registry purposes is stored at multiple secure locations.

All network components and data paths are configured in active-standby, fail-
over configurations, so that the failure of a component will not affect data 
processing. In the event one component fails, its pair will automatically take 
over. External RAID arrays are also attached by redundant, fail-over links.

The facilities have redundant, telco-grade connections to the Internet. Each 
server is fed by a fully redundant uninterruptible power supply to provide 
consistent, reliable power.

Multiple, redundant climate-control units ensure the proper operating 
environment for the servers.

B. Operating System

The operations network is segmented to limit access through it to the SRS 
management network. Several layers of password and certificate authentication 
are necessary to connect to the management network.

The DNS system is also well protected. (See Section 5. Technical Competence, 
part (vii) Zone File Generation for details.)

C. Hardware

Afilias uses enterprise-class hardware, which is designed to tolerate the 
failure of its components, and which can be serviced without removing power. 
The failure of a CPU, memory module, disk drive, or system board will not 
cause the servers to fail, but will generate warning messages to inform 
systems administrators that a fault condition occurs. Only ECC memory is used, 
to ensure a failing memory module cannot affect system operation or data 
integrity.

In the event the ECC memory detects a fault, it reports that fault to systems 
administrators.

In the case of a fault condition, it is possible to replace the failing 
component without removing power from the server. The failing component is 
replaced, and the server continues to handle requests. Details about hardware 
can be found in Section 5. Technical Competence, part (i) General description 
of proposed facilities and systems subsection V. Hardware Architecture.


...  VIII. System Monitoring/Technical Maintenance Staff/Server Locations

A. System Monitoring

Each registry system component will be monitored for security, performance and 
stability both from within the data centres, and from a remote site. Three 
different monitoring systems provide triple-checks for potential problems. 
This allows the earliest possible warning of trouble, in order to allow ample 
preparation in case of a detected fault. 

B. Technical Maintenance Staff

Network Operations staff, monitoring systems 24 hours a day, will be alerted 
immediately in the event of any hardware or software troubles. Second-level 
technical staff will be available 24 hours a day, seven days a week, to 
address immediately any potential failure of a system component.

Consistent policies on maintenance script placement, commenting rules, and 
rigorous schedules for audits and maintenance will ensure that the system does 
not experience outages arising from operator error.

Upgrades and maintenance will be conducted according to well-established 
policies. Each proposed system change will be documented in advance, and will 
undergo peer review before being implemented.

Proposed changes are also tested fully in the quality-assurance environment 
before being moved into the live system. See section 5. Technical Competence 
XV System Reliablity subsection VII. Software Quality Assurance for more 
details.

C. Server Locations

Servers are dispersed geographically and interconnected via multiple routes to 
assure connectivity. Telco service and last-mile diversity at all data centers 
is practiced. 

Afilias uses georgraphically distributed Class "A" grade data centers. Two 
major IBM data centres are located in the central and eastern US. Another data 
center Afilias uses is at Q9 Networks in Toronto. For more details please see 
Section 5. Technical Competence, part (i) General description of proposed 
facilities and systems subsection IV. Physical Facilities.

DNS servers are distributed worldwide for stability, reliability and 
redundancy. Please see section 5. Technical Competence (ii) Stability of 
resolution and performance capabilities subsection V. Diversity of DNS 
Infrastructure.

...  I.  .NET Feature Functionality

Afilias will maintain and improve the basic feature functionality of .NET 
registrations:

·	Automated registrar-registry domain registration system through RRP 
and EPP

·	DNS publishing and propagation with improved speed for registration-to-
resolution time

·	Near-real-time WHOIS publishing

·	Registrar web-tool for connecting to the registry system with 
additional features

·	Registrar reports repository with enhanced security

Detailed specifications for the described feature functionalities of the 
registry system and their respective improvements over the current .NET 
registry are discussed in more detail in other sections of Part 5.  Besides 
these basic functionalities, we understand that the .NET registry also 
provides the following four domain registry features:

·	IDN Registrations and Resolution

·	IPv6 RR Provisioning and DNS Publishing

·	Special Deletion Batch Pool

·	Expiration Date Synchronization Service


...  II. IDN Registrations and Resolution

Afilias will maintain the resolution for all registered IDNs transparently in 
the same manner as all ASCII (i.e. LDH -- "Letter, Digit, Hyphen") domains.

In the implementation of the IDN registration and resolution services for 
the .NET registry, Afilias will adhere to the relevant IETF standards, 
including RFC 3490, 3491, 3492 and 3454 as well as the ICANN IDN 
Implementation Guidelines.  Afilias is a pioneer in IDN implementation and has 
participated in, committed to and has contributed significant efforts to the 
establishment of the IDN standards as well as the registry guidelines.  
Afilias was the first TLD to register a Language-Table at the IANA IDN 
Language-Table registry and the first gTLD to launch fully standards compliant 
IDN registrations.

In order to ensure full compliance with the ICANN IDN Guidelines, Afilias 
intends to continue seamless registration of IDNs in scripts for which 
Language-Tables and policies have been established according to the ICANN IDN 
Guidelines.  Furthermore, based on the current RRP specifications, IDN variant 
provisioning and management is not supported.  Afilias has already initiated 
and is continuing to devote efforts to the establishment of standards-based 
EPP extensions for IDN provisioning, including variant management mechanisms.  
Accordingly, fully compliant IDN registrations for scripts requiring variant 
management may be provisioned.

Afilias understands that currently the incumbent provider utilizes an "IDN-
wildcard" (i.e. high-bit wildcard) to forward all possible "IDN" queries 
(queries containing characters beyond the LDH repertoire) to a web-redirection 
service in order to assist the resolution of IDNs.  With the consensus of, and 
direction from, ICANN and the community, Afilias is capable of continuing this 
service.  However, we caution that this is not a standards-compliant 
configuration, and the issues have previously been discussed in a series of 
correspondence between ICANN, IAB and VeriSign in early 2003.  The details of 
the VeriSign implementation are also included in the public letters.


...  III. IPv6 RR Provisioning and DNS Publishing

Afilias is committed to fostering the adoption of IPv6. In support of this, 
Afilias has identified three high-level market requirements:

·	IPv6 connectivity (i.e., addressability and routes) to the registry to 
the extent it is in control of the registry service; 

·	Provisioning of IPv6 (name, address) information from registrars to 
shared registry system; 

·	Provisioning of IPv6 (name, address) information to the primary .NET 
name servers; 

To meet these market requirements, the registry will follow the guidelines, as 
developed by the IETF for IPv6 Node Requirements. Specifically, the vendor's 
DNS server infrastructure must be compliant with RFC 3596 and related 
supporting IETF Draft Standards.  Furthermore, the registry will be required 
to remain in compliance with ICANN policy related to the DNS service 
implementation for IPv6 and coexistence of IPv6 and IPv4. 

Afilias will also be working in partnership with UltraDNS to provide an IPv6 
solution. UltraDNS has already devoted time to build their database and DNS 
resolvers to support IPv6 per RFC 1886 and 3596 both in the zone (IPv6 record 
types including AAAA) and on the wire (native IPv6 connectivity and stack 
support).

Afilias has deployed a sandbox IPv6 solution that includes a dual stack on the 
wire IPv6 and IPv4 implementation as well as EPP 1.0 support for host ip 
addresses in both IPv6 and IPv4 format. This sandbox also includes delegation 
to an IPv6 enabled DNS zone to complete an end-to-end IPv6 environment.

By committing to implement IPv6 in the DNS, Afilias is supporting .NET and the 
entire Internet community as a whole.


...  IV. Special Deletion Batch Pool

Afilias will provide a seamless migration for all current .NET registrars and 
maintain a special Deletion Batch Pool system along with all other regular 
transactions through RRP.  The Deletion Batch Pool will also support EPP for 
registrars who decide to migrate to EPP immediately.

Furthermore, Afilias recognizes that the incumbent is planning to introduce a 
Wait-List Service (WLS) to replace the Special Deletion Batch Pool 
arrangements.  Afilias has noticed strong objections against the 
implementation of WLS and is aware of outstanding litigation.  If the 
community resolves to a consensus based on the WLS model, Afilias will be able 
to provide a technical platform to support its operation.

Afilias proposes to work closely with ICANN and the community to investigate 
and explore even better alternatives that would be amenable to registrars, 
promote equal access, and encourage competition.


...  V. Expiration Date Synchronization Service

According to the "General Counsel's Briefing Regarding Proposed Revisions 
to .com and .net Registry Agreements to Reflect Services Introduced 25 January 
2003" dated 23 February 2003, VeriSign has started to offer an Expiration Date 
Synchronizing service called ConsoliDate.

"ConsoliDate is a VeriSign-proposed service designed to allow registrants 
(such as companies with large portfolios of domain names) to synchronize the 
expiration dates of the domain registrations. It allows the registrant to add 
any number of days to a registration's term from one day to one day less than 
a year, for a maximum fee depending on the length of extension ranging from 
US$3 to US$14."

VeriSign further clarified the ConsoliDate technical functionality in its 
proposed contract update as follows:

"The ConsoliDate service allows registrars to offer their customers the 
ability to obtain a specific anniversary date for any domain name 
registration. Registrants will have the entirely optional ability to 
synchronize (or stagger) the expiration date of their registrations in order 
to simplify record-keeping and accounting..."

"...The ConsoliDate service is implemented by means of the SYNC command.  The 
ability to SYNC a registration will be available through both the Registry-
Registrar Protocol (RRP) and the Registrar Web Tool..."

Even though preliminary authorization was provided to VeriSign to introduce 
this service, subsequent definitive adjustments to the .NET agreement, to the 
best of Afilias' knowledge, have not been published.

Afilias is capable of providing a Domain Expiration Date Synchronization 
Service.  If ICANN and the community believe that it is a useful service.  
Thus far however, there have been different views in the ICANN community about 
the ConsoliDate service, in terms of its cost and pricing structure as well as 
in its value as a registry service.  Should ICANN wish to see the .NET 
registry to continue to offer this feature, Afilias will work closely with 
ICANN and the community to establish clear objectives, guidelines and policies.


...VII. DNSSEC Support

Afilias is fully committed to a complete implementation of DNSSEC in the .NET 
registry.  Our technology team participates actively in the DNS operations and 
extensions working groups in the IETF.  Further, the company's Techincal 
Advisory Group (TAG) consists of renowned technologists who have deep 
knowledge and ability to guide the company in its DNSSEC implementation.

Existing support by a gTLD for DNSSEC is currently in an experimental, testbed 
stage. DNSSEC's implementation in a gTLD registry is hampered by the lack of 
resolution of certain fundamental issues, including:

·	Signing the root

·	Key exchange policies between TLDs and the root

·	Zone walking via NSEC records 

·	Key rollover

·	Widespread deployment of DNSSEC compliant resolver libraries

·	Key exchange between zone operators and registries.

Signing the root: 

Afilias will cooperate closely with root server operators on the deployment of 
DNSSEC, particularly with respect to deploying experimentally signed zones for 
the purpose of testing.

Key exchange policies: 

Afilias will work with root operators, gTLDs and ccTLDs to help form policies 
for key exchange that are secure, workable and compliant with local policies, 
both for the root server operators and the TLD operators. Since trust in 
DNSSEC keys trickles down from the root, via TLDs to registrants, the security 
and responsiveness of this system to compromise are absolutely critical and 
must be carefully worked out.

Zone walking: 

Although not all TLDs consider this an issue, Afilias recognises that this is 
a problem that cannot be ignored if DNSSEC is to be widely deployed. As such, 
Afilias will work with the IETF, particularly the DNSEXT working group and 
other TLD operators, to produce a viable technical solution to the problem.

Key rollover: 

Afilias will support the necessary modifications to DNSSEC software 
(particularly resolver libraries) to support key rollover, and deploy it 
experimentally and operationally.

Deployment of resolver libraries: 

Although some DNS software (for example, BIND and NSD) now have DNSSEC 
support, both as a server and a client, it is not tested in a large scale. 
Afilias will sponsor an aggressive testing program for both servers and 
clients. It will also assist with the development of a second client resolver 
library, as is required by the IETF before a standard can be fully ratified.

UltraDNS has agreed to execute the implementation of DNSSEC solutions in their 
DNS systems.  

Key exchange between zone operators and registries: 

The security of DNSSEC rests completely on the secure exchange of keying 
material between the zone operator (i.e. the registrant or the registrant's 
ISP) and the registry, who must publish the correct keys in order to secure 
the zone. Afilias will sponsor and implement policies and software that make 
this process manageable, even for small operators, and also will take into 
account the extra complications caused by having registrars acting on behalf 
of the registrants.

Afilias also recognizes that since much of the Internet's critical 
infrastructure makes use of the .NET domain, this issue is of particular 
importance to its operations.

DNSSEC over EPP: 

Although the standards are being written to support the deployment of DNSSEC 
over EPP, little thought has yet been given to the validation of registrants 
and securing the EPP communications channel.  As noted above, Afilias will 
sponsor and implement policies and software that address this concern.

...  I. Overview

Afilias has designed a system with extremely high fault tolerance, and fully 
addresses any system failures.

Redundant systems, and hardware which allows parts to be replaced without 
shutting the hardware down, both contribute to making a system that is 
extremely reliable.  In order to complete its responsible preparations for any 
contingency, however, the registry has a full plan to deal with failure.  
Afilias' network operations team monitors all critical registry services 24 
hours a day, 365 days a year.  At any time, at least four qualified registry 
operations engineers are available by pager, or on site, to respond to 
emergencies.  The registry operations engineers are intimately familiar with 
the software, configuration and setup of the registry system, and able to 
quickly diagnose and correct faults

In the event of a software failure that registry operations engineers are 
unable to solve, system programmers will be contacted to work on the fault. 
The issue will be immediately looked into and the fix will be tested by the QA 
engineer before being deployed into production. All software and hardware 
vendors will provide 24-hour, 365-day-per-year telephone and on-site support.  
The data centers will keep extra parts for all hardware involved, allowing 
quick repairs in the event of hardware failure.  The supplies will be adequate 
to allow for multiple concurrent component failures.  If replacement parts 
stock is exhausted, additional parts will be available within four hours of 
request.

The registry offers a system which avoids unnecessary complexity.  Design 
plans, QA results and known problems are all accessible through a knowledge-
management system to all registry operations and systems maintenance personnel 
at all times.  In the extreme case where it becomes necessary for another 
provider to assume responsibility for operations, Afilias maintains the core 
registry database files in an ANSI-SQL compliant manner, enabling complete 
portability of the data from our operating systems or escrow. Afilias has well 
defined backup and recovery procedures in place to ensure fast recovery of 
systems in the event of outages. Expected outages as a result of planned 
hardware of software upgrades are well documented and tested on multiple 
testing and staging environments to ensure accuracy and completeness of 
upgrades. Well-documented emergency and escalation procedures are defined for 
unexpected outages to keep downtime to a minimum.


...  II. Procedures for Restoring the System to Operation in the Event of a 
System Outage, Both Expected and Unexpected.

Expected maintenances are planned events; they are controlled events, and 
responses to them fall within the bounds of standard operations procedure.  In 
a normal expected maintenance, a subsystem known to be somehow faulty is 
simply removed from operation; a secondary (backup) subsystem is activated to 
replace the faulty subsystem.  When the faulty subsystem is fixed, it is 
reintroduced to the system to replace the former secondary subsystem.  All 
these activities are accomplished without interrupting data processing.  Our 
(n+1) architecture, combined with the High Availability Clustering technology 
(HACMP) means that scheduled maintenance operations to replace hardware parts 
are well protected.

In the event the entire system is planned to be shut down for maintenance, 
registrars would be notified of the anticipated shutdown of the primary data 
center, and the activation of the stand-by data centers.

At the announced time, the primary center would be removed from service, and 
operations would continue at the secondary center, with the tertiary and 
further data centers acting as secondary data centers.

Given the high fault tolerance of the hardware the registry is using, a 
complete expected shutdown of a data center is extremely unlikely.  More 
likely is planned withdrawal of a single subsystem.  In such a case, the 
system would be reconfigured not to rely on the failing subsystem.   The 
failing subsystem is then taken out of service.  For most subsystems, the 
reconfiguration would happen without any interruption of service.  In the case 
of removing the primary database from service, it is imperative to ensure that 
no transaction was in process during the switch-over; therefore, there would 
be a short interruption of data processing.

Unexpected failures fall into four classes:

·	Partial failure - part of some subsystem fails. 

In the event of a partial failure of a subsystem, the fault tolerance of the 
design will isolate the problem.  Such failures really act only as warnings 
for an expected failure; the system would be able to continue to function 
(although possibly at a degraded level of service) until the fault could be 
corrected at a scheduled time.  The defective subsystems will be replaceable 
without incurring any interruption of service, because of the "hot-swap" 
capabilities built into most components.

·	Failure of one subsystem - a complete component (e.g. a server or 
network switch) fails. 

Our design uses redundant hardware. If a single component were to fail, one of 
the paired pieces of hardware would be able to operate alone.  The system 
would continue to function (although possibly with degraded service) until the 
fault could be corrected at a scheduled time.

In the event that the primary data server failed, there would need to be a 
brief interruption (1 to 2 minutes) while data processing moved to the backup 
data server.  This is necessary to ensure perfect data integrity.  Because the 
data servers use external RAID arrays, a failure of the primary server does 
not entail the loss of the data stored there; instead, the data can be moved 
instantly to the secondary server.  Only in the case of a complete RAID array 
failure is any reconfiguration necessary; such an interruption would last only 
briefly, because the data is replicated on another, identical array.  Afilias 
has developed a best of breed replication system "SLONY" with the support of 
the Postgres community, that supports the switches of slave to master nodes 
within a few minutes.  This allows Afilias to move processing to a slave disk 
array system with minimal disruption if the master database cluster suffers 
complete failure.

·	Total failure of one data center

Afilias maintains three geographically isolated data centers and is creating a 
fourth.  These centers are connected via high-speed, redundant virtual private 
network connections, so that the second data center will always have the same 
data as the primary center.

In the event of the total failure of the primary data center, registrars would 
be notified of the decision to move operations to the stand-by center. Except 
for the change in physical location, nothing will change in the manner of 
operation.


·	Total failure of all data centers

The registry is prepared for the unlikely, cataclysmic case in which all data 
centers are destroyed at the same time.  The registry's extensive backup 
arrangements will ensure that data will be preserved, the data can be 
restored, and operations can resume in a short period of time.  In the event 
of the physical destruction of all data centers, the registry will be able to 
restore operations by reverting to the most recently deposited escrow copy of 
the system.

In addition to the core registry systems, we have ensured that UltraDNS has 
established back up and recovery procedures for the DNS service as well as 
failover capability to another DNS vendor.

For further DNS Disaster Recovery capability, please refer to the Section 5 
(ii) (vi)   Diversity and Redundancy, Section 2-5 (vii) vii zone generation, 2-
5(viii) zone file distribution, for description of multiple DNS vendor usage 
and Section 2-6 Security and Stability.

III. Redundant/Diverse Systems for Providing Service in the Event of an 
Outage/Process for Recovery from Various Types of Failures

As noted above, backups exist for each major scenario, and procedures are in 
place to guide recovery activity, regardless of the circumstances of the 
failure.


IV. Training of the Technical Staff Who Will Perform Tasks

Afilias employs highly trained technical staff as part of its operations team. 
Key staff members, including database administrators, developers, system and 
network administrators, network operations team, tech support and customer 
support, are provided procedures and training materials regarding system 
restoration and re-start.  Additionally, at least two managers are available 
on call, and a clear escalation procedure is in place.

Documents are updated regularly with any changes and regular audits are 
performed to ensure correctness and completeness of the documents and manuals. 
Training is provided on an ongoing basis to any new staff and to keep existing 
staff familiar with any changes. Recovery methods are regularly tested and 
drills are performed in the test environment to simulate unexpected outages.

V. Availability and Backup of Software and Operating Systems Needed to Restore 
System to Operation

Full, current copies of the database and operating system are kept safely in 
escrow.  They can be quickly retrieved, installed, and re-started if needed. 
Multiple copies of the primary database are also maintained using the Slony 
advanced replication systems used by Afilias at multiple data centers.


VI. Availability of Hardware Needed to Restore and Run System

In the event of hardware failure of one of the application servers, the 
systems should not fail.  The second server will take over, and continue 
handling processing.  Well trained Systems staff will handle all operations to 
restore the application machine:

·	Open a ticket to track the outage. Include the approximate failure 
time; 

·	Alert the customer support center at the data center, if they are not 
aware; 

·	The load balancers will detect the hardware failure and disable the 
failed machine from the cluster so that no new client connections are directed 
towards it. Operations staff will ensure that the machine has been removed 
from the load balancer; 

·	Wait for hardware to be restored. (Note that data centers maintain 
inventory of key parts); 

·	Perform validation test, to ensure the same failure will not recur; and

·	Restore server to system by restarting application and test; add it to 
the load balancer, if need be. 

Afilias has adopted IBM's HACMP technology for Server Clustering.  Total 
failure of the Master Database Server will result in automated activation of a 
standy-by system  with no effect to the Registry operations. All hardware 
components are monitored from within the data center and various registry 
components are monitored from the Afilias Network Operations center.

VII. Back up Electrical Power Systems and Projected Time for System Restoration

Our main data centers are managed by IBM . There are 2 utility feeds from 2 
substations at all data centres. Automatic transfer scheme (ATS) restores 
power if one line is lost. There is N+2 redundancy architecture for the 
generators at the data centre, IBM  maintains capacity to generate clean, 
uninterrupted power for at least 50 hours after a power failure.  If needed, 
additional capacity (diesel fuel) can be brought in to supplement the on-site 
capability.

The Afilias NOC in Toronto has similar capability.  During the major power 
failure in the Eastern US in August 2003, the Toronto center stayed 
operational, providing continuous service and support to Afilias' domains.

VIII. Procedures for Testing Process of Restoring System to Operation in Event 
of Outage

Afilias has detailed internal procedures for  migrating from the primary 
database to the secondary. These procedures address not only a system outage, 
but also the loss of the entire primary data center.  The procedures cover 
communications with registrars by the tech support team as well as internal 
coordination with IBM and UltraDNS to ensure the primary to secondary cutover 
is handled properly.  It includes database checks to ensure proper synching. 


IX. Documentation Kept on System Outages and On Potential System Problems that 
Could Result in Outages

As soon as an outage occurs, the network operations team immediately opens up 
a incident ticket. All work done to restore services back to their normal 
operations are tracked in this ticket.  Once the problem is resolved, all 
outages are reported in an incident report that includes an analysis of root 
causes and recommendations for remediation.  In addition, weekly meetings are 
held by the Operations team to discuss current activities, trends in problems, 
etc.  These meetings help identify emerging problems, and enable preemptive 
action to keep minor problems from becoming major. 

...  I. Overview

Afilias' technical support and customer service departments are recognized as 
among the best in the industry.  Afilias will provide the same personalized 
service to .NET as it does for its other gTLDs and ccTLDs.

Afilias currently employs sixteen (16) technical and customer service staff to 
provide 24/7 coverage of all customer service and technical support issues.  
Afilias' customer service is organized into the following departments.

·	Front-line Customer Support
·	Administrative/ Billing/ Financial Support
·	Technical Support

Afilias' customer support, tech support, and operations staff is experienced 
in handling the wide variety of issues that a registry will invariably 
encounter.  Afilias has superior customer service, with a very fast response 
time, as a result of our experience and skills.

At present Afilias supports more than 160 registrars from 30 different 
countries, along with providing support to potential registrars and registrars 
in the Operational Test & Evaluation (OT&E) phase.  The customer support 
department also answers many registrant queries.

...  II. Registrar Support

A. Front-line Customer Support

Front-line Customer Support will be the first point of contact for all 
registrars.  This 24/7/365 operation is able to answer general registrar 
questions.  If the query is out of the bounds of Customer Support, a service 
support case will be opened and a support ticket issued.  These support 
tickets will be escalated to either the technical support team or the 
Administrative/Financial/Billing Support team, depending on the nature of the 
problem.

B. Administrative/Financial/Billing Support

The Administrative/Financial/Billing Support team will deal with registrars' 
business, account management, financial and billing issues.  Examples that 
fall into these categories include:

·	Registrar account balance inquiries 
·	Registrar low-balance warning notifications 
·	Crediting a registrar's account after payment
·	Legal issues related to the Registry-Registrar Agreement
·	Administrative issues for the acceptance of new registrars
·	Billing report and invoice

The support team has guidelines in place to ensure a conduit exists for 
escalation to higher levels of the registry's management team with respect to 
unresolved administrative/billing/financial issues.

C. Technical Support

Tech(nical) Support will be responsible for dealing with registrars' technical 
issues.  Tech Support is provided through the central Help Desk.  Access to 
the help desk telephone support is through an automatic call distributor that 
routes each call to the next available Tech Support Specialist.  The Tech 
Support Specialist will authenticate the caller by using a pre-established 
security pass phrase.  Request for assistance may also come to Tech Support 
via e-mail, fax or front-line Customer Support. These services will be 
dedicated primarily to authorized registrars on a 27/7/365 basis.

Afilias will diagnose and analyze the registry activity log file on regular 
basis and proactively reach out to the registrars who may require technical 
guidance on fixing certain repetitive errors or exceptions caused by mis-
configured client software.

...  III. Registrant and Internet User Support

Registrants are the customers of their registrars.  Since this is so, and 
since Afilias is the registry services provider, Afilias never provides direct 
customer service to registrants.  However, Afilias will direct queries by 
registrants to the appropriate sponsoring registrar.

...  IV. Technical Help Systems

Methods of contact supported by Customer Support include:  telephone, fax, 
postal mail and e-mail.

Web-based self-help will be available to the registrars and includes:

·	Registry policies
·	Frequently asked questions
·	Knowledge bases
·	Downloads of registry client software

...  V. Personnel Accessibility and Escalation Process

Tech Support operates with an escalation process.  Normally support calls or 
other forms of communication start with the lowest level of support and are 
escalated should the first level of support be insufficient.  In cases where 
higher levels of support are immediately apparent (all levels of support staff 
are trained in identifying these), the escalation chain may be jumped.  Also, 
should the time limit expire with no notice, the support level may be 
escalated.  The escalation levels and response requirements are as follows:

Level 1:  This is a technical question, usually unique to a registrar, which 
may require support from an Afilias systems operator or engineer.  Responses 
to requests for information or technical support will be provided within one 
hour unless is it deemed to be a Level 2 incident.

Level 2:  This is a systems outage involving non-critical operations to 
Afilias affecting one or more registrars only, but not the entire system.  
Response reports will be provided every 30 minutes, by no less than a 
qualified Afilias systems engineer.

Level 3:  This is a catastrophic outage, or disaster recovery involving 
critical operations to Afilias overall.  Response reports will be provided 
every 15 minutes, by no less than a senior Afilias systems engineer.

...  VI. Support Services

A. Ticketing System and Call Statistics

Afilias' Help Desk uses an automated software package to collect call 
statistics and record service requests and trouble tickets in a help desk 
database.  Request Tracker manages key tasks including identification, 
prioritization, assignment, resolution and notification.  

Afilias will further extend the Web-based Request Tracker to allow registrars 
to view their own active and resolved tickets online via a self-service 
interface.

B. Access to Registry Data

The Tech Support group will have access to registry data sufficient to support 
authorized registrars, to the extent that current operating status can be 
determined, response to specific registrar queries about registrar-specific 
data or specific transactions can be provided.  Afilias employees will be 
required to properly identify the authorized registrar before providing any 
registrar critical data, and will be prohibited from providing information 
about other authorized registrar operations.

1. Security of Customer Support Service

Since Afilias' customer service can take actions on behalf of registrars, the 
personal communication process will be secure as well.  Registrars will be 
required to supply a list of specific individuals (1 to 10 people) who are 
authorized to contact the registry.  Each individual is assigned a pass 
phrase.  Any phone requests made by a registrar to Afilias customer service 
must come from one of the authorized contacts, and a pass phrase will be 
supplied.  In the event that an attempt is made to contact Afilias support on 
behalf of a registrar, but appropriate authentication is not provided, Afilias 
will make contact with the registrar to inform it of a breach of security 
protocol.

2. Registrar Contact Information

Afilias' support team will maintain a registrar contact information database 
to ensure it has an accurate list of appropriate registrar contacts and pass 
codes.

C. Notifications

The Afilias Tech Support group will be responsible for notifying authorized 
registrars of upcoming maintenance and outages with strict requirements 
regarding advance notice.  At a minimum, all planned outages and maintenance 
will be announced at least seven days prior to the scheduled date.  Further, 
Tech Support will be required to provide immediate notice of unplanned or 
unscheduled outages and maintenance.

...  VII. Language-Availability of Support

Currently both customer and technical support are provided to registrars in 
English.  Afilias has selected a partner to providing technical and customer 
support in the following languages:  English, Chinese (Cantonese and 
Mandarin), French, German, Hindi, Italian, Japanese, Korean, Russian and 
Spanish.

...  VIII. Registrar Operational Communications

It is critical that registrars stay current on activities at the registry, 
especially changes that affect their operations.  To address this, Afilias 
will maintain regular contact with registrars on operational issues.

The following are key communications:

A. Scheduled Maintenance/Outage

At least seven (7) days in advance of a scheduled maintenance, Tech Support 
will issue a notification to the registrar-info mailing list.  The 
notification will provide:

·	Expected time of the activity; 
·	Expected duration of the activity; 
·	Reason for the activity; 
·	Services affected; and
·	Contact information for questions. 

At the conclusion of the maintenance, a second notification will be issued 
informing registrars that the maintenance is concluded.

B. New Programs or Operations

When new programs are launched, Afilias will prepare and disseminate 
communications to aid in successful execution by the registrars, including:

·	Operational manual and instructions; 
·	Webcast presentations (MS Powerpoint, script, Q&A, logistics, etc); 
·	Notifications to registrars on meeting times and instructions, etc; 
·	Solicitation and confirmation of schedules; and
·	Contact information for questions. 

Approved communications will be provided to the registrars on a timetable 
established in the project plan for each new program.

C. Unscheduled Maintenance/Outage

In the event of unscheduled maintenance or outages, Tech Support will prepare 
a communication that informs registrars of:

·	Unscheduled events occurring at the registry; 
·	Expected duration of the activity (if known); 
·	Services affected (if known); 
·	What the registrar should expect next; and
·	Contact information for questions. 

At the conclusion of the event, a notification will be issued informing 
registrars that the event is concluded.

D. Responses to Questions

Afilias will also provide written responses (primarily email) to registrar 
questions.  These communications will follow the Tech Support and Customer 
Support processes described in relevant sections of this manual.


...  IX. Ability to Support New and Emerging Technologies

Afilias Customer and Technical Support are regularly trained and provided with 
sufficient documents to support new and emerging technologies.  Afilias has 
quality control in place and regularly evaluates the changes in existing 
processes, procedures and policies due to the introduction of new service or 
launch of a new program.

When new and emerging technologies are launched, Afilias will prepare and 
disseminate communications to Customer and Technical Support Group to better 
assist the registrars including:

·	Operational Manual
·	Frequently Asked Questions
·	Webcase presentations
·	Q&A sessions

Afilias' Customer and Technical Support group was provided with compressive 
training to support our registrars due to the introduction of RGP, IDN, 
Transfer Undo, .INFO Free Program through the aforementioned method.

...  X. Additional Support Services:

A. Operational Test and Evaluation

Kinds of OT&E tests

Before a registrar is allowed to join the live Shared Registry System it must 
first pass Operational Test and Evaluation (OT&E) certification. The purpose 
of OT&E certification is to verify the correct operation of a registrar's 
client system. Afilias proposed to make this certification is optional for 
Registrars that can demonstrate existing OT&E certification with Afilias.

Registrars will be offered an additional optional OT&E component test that 
demonstrates their ability to successfully complete a transfer from a thin EPP 
Registrar to a thick EPP Registrar. 

Initial OT&E (Phase 1 of OT&E)

The OT&E certification process begins when a registrar becomes accredited by 
ICANN to register names in the .NET TLD. At this point an OT&E welcome package 
will be provided to the registrar along with the additional accreditation 
materials to become Afilias-authorized. This package will include information 
that will assist the registrar in developing its client application for the 
Shared Registry System and will include the following:

·	Username and password to access the registrar only area of the 
registry web site. 
·	OT&E server information and username/password for two accounts to 
access OT&E environment for registrar client testing.
·	Instructions on where to download the Registrar Tool Kit. 
·	Instructions on where to download the documentation for the Registrar 
Tool Kit. 
·	Instructions on where to download the EPP specifications. 
·	Instructions on how to proceed with the OT&E certification process. 
·	Instructions on how to obtain an SSL certificate from an approved 
Certificate Authority. 
·	Instructions on how to provide the registry with the list of subnets 
that will be used to access the live Shared Registry System. 
·	Documentation that will explain the tests to be performed during OT&E 
verification.

The registrar is responsible for developing the client application that will 
interface to the registry using the EPP protocol.  Afilias' Registrar Tool Kit 
will be available to any interested party that would like to develop registrar 
client applications. A registrar may opt to develop its application to conform 
to the EPP specification without the use of the Registrar Tool Kit. This is 
acceptable as long as the client is able to pass the OT&E certification 
process. 

During client development, the registrar has access to Afilias' OT&E 
environment. In the OT&E environment, the registrar may test the operation of 
its software to verify the correct handling of EPP commands and their 
responses. There will be no charges associated with operations performed in 
the OT&E environment and they will not have any impacts on the live Shared 
Registry System. Registrars will continue to have access to the OT&E 
environment after certification, so that they may continue to test their 
software systems.

EPP thin-to-EPP thick OT&E (Phase 2 of OT&E)

In order to ensure the stability of the functioning registry, and to ensure a 
smooth migration for registrars, registrars will be allowed to perform an 
optional additional OT&E test; prior to the "thin to thick" EPP migration 
cutover date. This second test evaluates the ability of the registrar, to 
successfully request and complete transfers of domain names held by registrars 
operating in EPP "thin" mode to registrars operating in EPP "thick" mode. 
During this test registrars will demonstrate the ability to submit an extended 
Transfer request that includes the mandatory contacts to fulfill the thick 
registry model.

B. Registrar Reports

Afilias will generate reports for each registrar on a daily and weekly basis. 
Two types of reports will be created for each registrar: Daily Reports and 
Weekly Reports. These are described below.

Daily Reports

Daily Transaction Report: These reports include: Addition, Modification, 
Delete and domain Transfer activity by the registrar. Domain operations 
produce one row for each associated nameserver. Nameserver operations produce 
one row for each associated IP address. A transaction ID is included in column 
1 to allow unique identification of transactions. Column 2 contains the 
transaction operation. The content of column 3 and 4 is dependent on the 
operation according to Table 1. 

Operation            Column 2                Column3
---------            -------                 -------
Add domain          Domain name            Server name
Mod domain          Domain name            Server name
Del domain          Domain name            Server name
Add nameserver      IP Address             Server name
Mod nameserver      IP Address             Server name
Del nameserver      IP Address             Server name
Transfer domain     Domain name            Null
Autorenew domain    Domain name            Null

                       


Daily Transfer Report: This report includes gaining and losing transfer 
activity. There are two separate reports for transfers:

Gaining Transfer Report: Indicates domains transferred to the registrar 
("gaining registrar"). 

Losing Transfer Report: Indicates domains transferred away from the registrar 
("losing registrar"). 

The Transfer reports will have the following fields: Gaining registrar name, 
Domain name, Losing registrar name, Date/time of transfer request, Status (one 
of ACK, NACK or PENDING), Date/time of ACK/NACK. The value of Date/time of 
ACK/NACK will be NULL if the status is PENDING. For example:

Registrar A, Inc.:EXAMPLE1.net:Registrar B Inc.:2001.07.01.15.13.41:PENDING:
Registrar A, Inc.:TEST.net:Registrar B 
Inc.:2001.07.01.15.14.00:ACK:2001.07.03.04.23.12
Registrar A, Inc.:TEST2.net:Registrar B 
Inc.:2001.07.01.15.25.00:NACK:2001.07.03.05.50.39

Weekly Reports 

Weekly Domain Report: Lists all domain names currently sponsored by the 
registrar. The domain is listed once with each current status and associated 
name server. For example:

EXAMPLE1.net:ACTIVE:NS1.EXAMPLE1.net
EXAMPLE1.net:ACTIVE:NS2.EXAMPLE1.net
EXAMPLE2.net:ACTIVE:NS1.EXAMPLE1.net
EXAMPLE2.net:ACTIVE:NS2.EXAMPLE1.net
TEST.net:HOLD:NS1.TEST.net
TEST.net:HOLD:NS2.TEST.net
HAPPY.net:ACTIVE:

Weekly Nameserver Report: Lists all nameservers currently sponsored by the 
registrar. The nameserver is listed once with each associated IP address. For 
example:

NS1.EXAMPLE1.net:111.222.123.211
NS1.EXAMPLE1.net:111.222.123.212
NS1.TEST.net:123.14.2.4

Domains Hosted by Nameserver Weekly Report: Lists all domains hosted on 
nameservers currently sponsored by the registrar. The nameserver is listed 
once with each associated domain name. 

NS1.EXAMPLE1.net:EXAMPLE1.net
NS1.EXAMPLE1.net:EXAMPLE2.net
NS2.EXAMPLE1.net:EXAMPLE1.net
NS2.EXAMPLE1.net:EXAMPLE2.net
NS1.TEST.net:TEST.net
NS2.TEST.net:TEST.net

C. Report Frequency 

Daily reports will be generated daily every four hours. Previous reports for 
that day shall be overwritten each time a new daily report is generated.

Weekly reports will be generated on Sunday at 00:00 UTC and shall contain 
activity for the previous week. 

D. Storage

Daily registrar reports are maintained for each registrar for seven days. 
Daily reports older than seven days will be archived for a period of 30 days, 
after which they will be removed.

Weekly registrar reports are maintained for each registrar for four weeks. 
Weekly reports older than four weeks will be archived for a period of 6 
months, after which they will be removed.

E. Distribution

Registrar reports shall be available for download via a secured Reports web 
administrative interface. A given registrar will only have access to its own 
reports, and the ability to create and manage additional accounts (and 
associated permissions) for their own administrative purposes. The registry 
operator reserves the right to change the distribution method as new protocols 
are adopted.