ICANN Logo

.NET Application Form


RFP Part 1: General Applicant Information

1. Name and Address fields

The full legal name, principal address, telephone and fax numbers, and e-mail address of the applicant, and the URL of its principal World Wide Web site. Additionally, each applicant must provide the Application Deposit Receipt Number issued to the applicant upon ICANN's receipt of the wired funds for the application deposit.

Organization Name:
Afilias Limited
Address:
Office 110
52 Broomhill Road
Tallaght, Dublin 24, Ireland
Telephone:
+353.1.431.0511
Fax:
+353.1.431.0557
Email:
dotnet@afilias.info
Confirm Email:
dotnet@afilias.info
URL:
www.afilias.info
Application Deposit Receipt Number:
[RESPONSE IS CONFIDENTIAL]
   

2. Applicant's Business and Other Associated Activities

Provide a general description of the applicant's business and other activities currently or expected to be associated with the services described in this RFP.

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.

3. Directors, Officers and other Key Staff

Provide the full names, positions and the qualification and experience of each of the following persons:

(i) the person or persons who will have direct responsibility for the business operations of the registry,
The following executives are currently employed by the company and will be 
supporting .NET operations:

-------  Henry A. "Hal" Lubsen - Chief Executive Officer  ---------------------

Mr. Lubsen is the CEO of Afilias and a veteran in the domain name industry.  
Mr. Lubsen co-founded leading registrar Domain Bank, Inc., one of the 
Internet's first ICANN authorized domain name registrars and one of Afilias' 
18 founding members.  He has also served as a member of the Executive 
Committee of the Internet Council of Registrars (CORE) from 1998 to 2001.

As the CEO of Afilias, Mr. Lubsen directed the launch of .INFO, the most 
successful generic Top Level Domain since .COM was introduced.  The .INFO 
launch included a number of pioneering efforts, including the first large 
scale deployment of the new Extensible Provisioning Protocol (EPP) protocol.  
Mr. Lubsen also worked closely with ISOC during ICANN's .ORG redelegation 
process, resulting in Afilias' successful management of the historic migration 
of .ORG to ISOC's sole-member, not-for-profit Public Interest Registry for 
whom Afilias provides registry services.

Mr. Lubsen has over 35 years of business experience in various industries.  In 
addition to Internet companies, he owns Altronics, Inc., an alarm and security 
system vendor, and Allied Central Services, an alarm monitoring company.  As 
such, he has extensive experience in the operation of 24/7 customer service 
departments, and the development and maintenance of high security, redundant 
databases and networks.  Mr. Lubsen's business experience has provided him 
with a solid base of expertise in recurring revenue businesses, as well as the 
accounting and related issues unique to such ventures.  

Mr.  Lubsen holds a B.A. degree from Muhlenburg College, located in Allentown, 
Pennsylvania.


-------  Ram Mohan - Vice President, Business Operations and Chief Technical 
Officer  ----------------------------------------------------------------------

Mr. Mohan is Vice President, Business Operations & Chief Technical Officer of 
Afilias.  Mr. Mohan manages all of Afilias' technical operations which support 
the generic top-level domains (gTLD) .INFO and .ORG, in addition to a number 
of country code (ccTLD) domains.

Under Mr. Mohan's guidance, Afilias was the first domain registry to implement 
an XML-based "thick" registry running on the new EPP.  Afilias also completed 
the largest transition of a domain registry to date when it successfully 
transitioned .ORG from VeriSign on behalf of the .ORG Registry Operator, the 
Public Interest Registry.

Before joining Afilias in September 2001, Mr. Mohan was at Infonautics Corp., 
a pioneering online database and content distribution company.  He has held 
various leadership positions at Infonautics, including Interim COO, CTO and 
VP, Product Marketing.  He is the founder of the award-winning CompanySleuth 
(http://www.companysleuth.com) product, and created the Sleuth line of 
business at Infonautics.  He helped develop Electric Library 
(http://www.elibrary.com), the United States' most used online reference 
database in schools and libraries, and Encyclopedia.com 
(http://www.encyclopedia.com), the first free encyclopedia on the Internet.  
Prior to joining Infonautics, Mr. Mohan worked with First Data Corporation, 
Unisys Corporation and KPMG Peat Marwick in a variety of leadership, 
engineering and technology positions.
 
Mr. Mohan has been active in the Internet and ICANN community, serving on the 
Security and Stability Advisory Committee (SSAC), which is the ICANN Board 
advisory committee comprised of Internet pioneers and technical experts.  Mr. 
Mohan presently serves on the ICANN Nominating Committee.  He also served on 
the Redemption Grace Period (RGP) implementation task force, the GNSO WHOIS 
task force, and the Internationalized Domain Name (IDN) registry 
implementation committee.  In 2003, he was named one of the Philadelphia 
Business Journal's "40 under 40".  Mr. Mohan serves on the Board of the 
Philadelphia-based Metropolitan Career Center, and the advisory boards of 
several Philadelphia-area startup companies.

Mr. Mohan's educational background reflects his belief that technology is best 
used for business advantage and market leadership.  He has a Bachelor's degree 
in Electrical Engineering from the University of Mangalore, an MBA in 
Entrepreneurial Management from Bharathidasan University, and is completing a 
second Master's in Computer Science at Philadelphia's Drexel University.


-------  Roland LaPlante - Vice President and Chief Marketing Officer  --------

Roland LaPlante is the Vice President and Chief Marketing Officer at Afilias.  
Mr. LaPlante oversaw the marketing and launch planning for .INFO in 2001, and 
the transition and launch of every TLD supported by Afilias since.  An 
accomplished marketing expert, Mr. LaPlante crafted an 18-month outreach plan 
for .ORG registrars that resulted in the smooth and well-communicated 
migration of registrars from a thin registry (VeriSign) to a thick one.

During his 25-year career in marketing, he has held senior marketing positions 
at McGraw Hill, Providian Corporation, Citibank and Heublein, Inc.  Before 
joining Afilias, he was Vice President and Chief Marketing Officer of Xlibris, 
an Internet publishing company based in Philadelphia.  Mr. LaPlante has 
extensive Internet marketing experience, having built Xlibris into the 
recognized brand leader in the Internet publishing space, according to 
Newsweek, Inside.com, New York Times and Harper's.  While at McGraw Hill, Mr. 
LaPlante was responsible for bringing two 100-year old construction brands, 
Sweets and Dodge, into the digital age, focusing marketing and product efforts 
on the Internet.  His consumer marketing background is equally as extensive.  
As Vice President and Director of Marketing in Citi's upstate NY and DC banks, 
Mr LaPlante launched numerous new products; he also managed global marketing 
for Smirnoff vodka at Heublein.

Mr. LaPlante holds a B.A. from Dartmouth College and an M.B.A. from Amos Tuck


-------  M. Scott Hemphill - Vice President and General Counsel  --------------

Mr. Hemphill joined Afilias as Vice President and General Counsel in September 
of 2003.  He is responsible for the oversight of legal and policy issues for 
Afilias.

Mr. Hemphill started practicing law in the Washington, D.C. area in 1991, 
later relocating his practice to the Eastern Pennsylvania region.  While in 
private practice, he focused on corporate law with a concentration in mergers 
and acquisitions as well as general technology and Internet issues.

Mr. Hemphill left private practice in 2000 to join Domain Bank, one of the 
Internet's first domain name registrars and one of Afilias' 18 founding 
members, as Vice President & General Counsel.  In 2002, he became President of 
Domain Bank.

While at Domain Bank, Mr. Hemphill was deeply involved in the creation of 
Afilias, serving as co-chair of the Policy Committee formed from Afilias' 
shareholders to help guide the creation of the .INFO registry. 

Mr. Hemphill holds a B.S. in Business from Wake Forest University and a J.D. 
from the College of William & Mary.


-------  Thomas Wade - Chief Financial Officer  -------------------------------

Mr. Wade joined Afilias as Chief Finance Officer in 2001 with over 20 years of 
global experience in the Finance industry.  Prior to joining Afilias, Mr. Wade 
was the Financial Director of Nua Ltd., an Internet Solutions Company in 
Dublin, Ireland.

Previously, Mr. Wade worked on the Nishimatsu Kumagai Joint Venture in Hong 
Kong for the HK$7 Billion IMT tunnel project.  He has also held various 
financial positions in Australia and Ireland including at the State Government 
Insurance Commission of South Australia (SGIC), BSS, and Asahi Synthetic 
Fibers Ltd.

Mr. Wade has a Bachelor of Commerce Degree from the University College of 
Dublin, a Masters of Applied Finance from Macquarie University in Sydney, 
Australia and is a Chartered Management Accountant licensed in the United 
Kingdom, and a Certified Practicing Accountant licensed in Australia.


-------  Steven Pack - Compliance Officer  ------------------------------------

Mr. Pack joined Afilias in October of 2001 as the registry's Compliance 
Officer, specializing in managing organizational compliance regarding policies 
and procedures affecting conflicts of interest and equal access for partners 
and organizational members engaged within the various channel segments of the 
domain name market.

Prior to Mr. Wade joining Afilias, Mr. Pack served as acting Chief Financial 
Office (CFO) on a consulting basis.  During this period, he established 
Afilias' accounting systems, policies, and procedures.

During the .ORG transition in early January 2003, Mr. Pack was responsible for 
the creation of operating guidelines and policies that ensured compliance with 
equivalent access provisions to all registrars who were transitioning from an 
RRP based system to an EPP based system.  This included the training and 
certification of all transition team members.  Mr. Pack provided advice to 
ISOC and its subsidiary PIR in the establishment of registry accounting 
systems and procedures.

Mr. Pack has over twenty years of management experience.  He has held 
positions at numerous industry leaders such as Avis, American Forest 
Products/Louisiana Pacific, Mack Trucks, J.K. Lasser/Deloitte & Touche, as 
well as some mid-sized firms and start-ups.

Prior to joining Afilias, Mr. Pack was a consultant at CFO Synergy, LLC 
serving as Chief Financial Officer for many small to mid-sized companies.  Mr. 
Pack has also held a myriad of finance-related positions for RHI Management 
Resources, Diesel Performance, Inc. and Stockton Kenworth, Inc., among 
others.  He was the managing partner of SPB, a consulting firm in northern 
California providing support as Chief Financial Officer for small and medium-
size organizations.

Mr. Pack holds a B.S. in Business and Accounting from Towson State College.  
He is currently a member of the AICPA and the Pennsylvania Institute of 
Certified Public Accountants.


In addition to the above, the following new positions will be established to 
further support .NET operations:

Chief Operating Officer

Vice President, Engineering

Vice President, External Relations
(ii) each person in the chain of command with decision making authority from that person or persons to the principal executive officer of the applicant,
The following executives are currently employed by the company and will be 
supporting .NET operations:

-------  Michael Young - Senior Director, Information Technology  -------------

Michael Young strengthens the company's technology leadership.  In his role as 
Senior Director of Information Technology, Mr. Young oversees the day-to-day 
operations of the registry, and is responsible for the significant 
optimization of the registry system since 2001, leading to its stable, speedy 
and scalable characteristics.  Prior to joining Afilias, Mr. Young's IT career 
has been concentrated in systems operations and software development 
management, specializing in 24/7 high availability environments.  Mr. Young 
headed up technology operations for one of the Toronto Stock Exchange's 
institutional brokerage houses, GMP Securities.  As Senior Project Manager at 
an Internet-based home delivery service, GroceryGateway.com, he coordinated 
and engineered the start-up of mission critical systems involving business 
systems, development and IT.

In addition to numerous technology certifications, Mr. Young holds a B.A. from 
the University of Toronto and is currently enrolled at the Queen's School of 
Business.


-------  Howard Eland - Senior Technology Architect  --------------------------

Mr. Eland is Afilias' Senior Technology Architect.  Mr. Eland is responsible 
for the architectural design of Afilias' high volume, high availability 
systems, which currently support two gTLDs and seven ccTLDs.  Mr. Eland's area 
of specialization is DNS and SRS Operations, and includes specific focus on 
topics affecting registry security and stability such as DNSSEC and IPv6.

Mr. Eland brings a background in networking, security, database and systems 
architecture.  He is an entreprenuer who founded Information Technology 
Enterprises Inc., an early Internet and application services company.  Mr. 
Eland's prior experience includes significant assignments at Infonautics Inc. 
and at AT&T GIS' Federal Systems Division, including the development of 
2,000,000 lines of C language code for X.400 systems for the US Army.  Mr. 
Eland is actively involved in various IETF forums and working groups with a 
focus on DNS and SRS Operations.  He has been published in various peer-
reviewed technical journals.

Mr. Eland holds a B.S. in Computer Science from Michigan State University.


-------  Andrew Sullivan - Data Architect  ------------------------------------

Mr. Sullivan is Afilias' Data Architect and brings strong knowledge and 
experience in database design, development and deployment.  Mr. Sullivan was 
part of the original group of people who launched .INFO in 2001, and has been 
involved in the design of the database.

Prior to joining the technical team at Afilias, Mr. Sullivan taught at 
McMaster University in Hamilton, Ontario, Canada.  Mr. Sullivan is Secretary 
of the PostgreSQL Foundation, an Open Source database project, and is an 
acknowledged expert in both database design and operation.

Mr. Sullivan holds a B.A. from the University of Ottawa and an M.A. from 
McMaster University.


In addition to the above, the following new positions will be established to 
further support .NET operations:

Director - NET
(iii) the top two financial officers of the applicant,
The following executives are currently employed by the company and will be 
supporting .NET operations:

-------  Thomas Wade - Chief Financial Officer  -------------------------------

Mr. Wade joined Afilias as Chief Finance Officer in 2001 with over 20 years of 
global experience in the Finance industry.  Prior to joining Afilias, Mr. Wade 
was the Financial Director of Nua Ltd., an Internet Solutions Company in 
Dublin, Ireland.

Previously, Mr. Wade worked on the Nishimatsu Kumagai Joint Venture in Hong 
Kong for the HK$7 Billion IMT tunnel project.  He has also held various 
financial positions in Australia and Ireland including at the State Government 
Insurance Commission of South Australia (SGIC), BSS, and Asahi Synthetic 
Fibers Ltd.

Mr. Wade has a Bachelor of Commerce Degree from the University College of 
Dublin, a Masters of Applied Finance from Macquarie University in Sydney, 
Australia and is a Chartered Management Accountant licensed in the United 
Kingdom, and a Certified Practicing Accountant licensed in Australia.


-------  Steven Pack - Compliance Officer  ------------------------------------

Mr. Pack joined Afilias in October of 2001 as the registry's Compliance 
Officer, specializing in managing organizational compliance regarding policies 
and procedures affecting conflicts of interest and equal access for partners 
and organizational members engaged within the various channel segments of the 
domain name market.

Prior to Mr. Wade joining Afilias, Mr. Pack served as acting Chief Financial 
Office (CFO) on a consulting basis.  During this period, he established 
Afilias' accounting systems, policies, and procedures.

During the .ORG transition in early January 2003, Mr. Pack was responsible for 
the creation of operating guidelines and policies that ensured compliance with 
equivalent access provisions to all registrars who were transitioning from an 
RRP based system to an EPP based system.  This included the training and 
certification of all transition team members.  Mr. Pack provided advice to 
ISOC and its subsidiary PIR in the establishment of registry accounting 
systems and procedures.

Mr. Pack has over twenty years of management experience.  He has held 
positions at numerous industry leaders such as Avis, American Forest 
Products/Louisiana Pacific, Mack Trucks, J.K. Lasser/Deloitte & Touche, as 
well as some mid-sized firms and start-ups.

Prior to joining Afilias, Mr. Pack was a consultant at CFO Synergy, LLC 
serving as Chief Financial Officer for many small to mid-sized companies.  Mr. 
Pack has also held a myriad of finance-related positions for RHI Management 
Resources, Diesel Performance, Inc. and Stockton Kenworth, Inc., among 
others.  He was the managing partner of SPB, a consulting firm in northern 
California providing support as Chief Financial Officer for small and medium-
size organizations.

Mr. Pack holds a B.S. in Business and Accounting from Towson State College.  
He is currently a member of the AICPA and the Pennsylvania Institute of 
Certified Public Accountants.


No new positions with these responsibiliwill be established.
(iv) the person with the principal technical responsibility for the operation of the registry,
The following executive is currently employed by the company and will be 
supporting .NET operations:

-------  Ram Mohan - Vice President, Business Operations and Chief Technical 
Officer  ----------------------------------------------------------------------

Mr. Mohan is Vice President, Business Operations & Chief Technical Officer of 
Afilias.  Mr. Mohan manages all of Afilias' technical operations which support 
the generic top-level domains (gTLD) .INFO and .ORG, in addition to a number 
of country code (ccTLD) domains.

Under Mr. Mohan's guidance, Afilias was the first domain registry to implement 
an XML-based "thick" registry running on the new EPP.  Afilias also completed 
the largest transition of a domain registry to date when it successfully 
transitioned .ORG from VeriSign on behalf of the .ORG Registry Operator, the 
Public Interest Registry.

Before joining Afilias in September 2001, Mr. Mohan was at Infonautics Corp., 
a pioneering online database and content distribution company.  He has held 
various leadership positions at Infonautics, including Interim COO, CTO and 
VP, Product Marketing.  He is the founder of the award-winning CompanySleuth 
(http://www.companysleuth.com) product, and created the Sleuth line of 
business at Infonautics.  He helped develop Electric Library 
(http://www.elibrary.com), the United States' most used online reference 
database in schools and libraries, and Encyclopedia.com 
(http://www.encyclopedia.com), the first free encyclopedia on the Internet.  
Prior to joining Infonautics, Mr. Mohan worked with First Data Corporation, 
Unisys Corporation and KPMG Peat Marwick in a variety of leadership, 
engineering and technology positions.
 
Mr. Mohan has been active in the Internet and ICANN community, serving on the 
Security and Stability Advisory Committee (SSAC), which is the ICANN Board 
advisory committee comprised of Internet pioneers and technical experts.  Mr. 
Mohan presently serves on the ICANN Nominating Committee.  He also served on 
the Redemption Grace Period (RGP) implementation task force, the GNSO WHOIS 
task force, and the Internationalized Domain Name (IDN) registry 
implementation committee.  In 2003, he was named one of the Philadelphia 
Business Journal's "40 under 40".  Mr. Mohan serves on the Board of the 
Philadelphia-based Metropolitan Career Center, and the advisory boards of 
several Philadelphia-area startup companies.

Mr. Mohan's educational background reflects his belief that technology is best 
used for business advantage and market leadership.  He has a Bachelor's degree 
in Electrical Engineering from the University of Mangalore, an M.B.A. in 
Entrepreneurial Management from Bharathidasan University, and is completing a 
second Master's in Computer Science at Philadelphia's Drexel University.


No new position with this responsibility will be established.
(v) each other executive or management person of the applicant who will have significant policy making or operational influence regarding the registry operations,
The following executives are currently employed by the company and will be 
supporting .NET operations:

-------  Henry A. "Hal" Lubsen - Chief Executive Officer  ---------------------

Mr. Lubsen is the CEO of Afilias and a veteran in the domain name industry.  
Mr. Lubsen co-founded leading registrar Domain Bank, Inc., one of the 
Internet's first ICANN authorized domain name registrars and one of Afilias' 
18 founding members.  He has also served as a member of the Executive 
Committee of the Internet Council of Registrars (CORE) from 1998 to 2001.

As the CEO of Afilias, Mr. Lubsen directed the launch of .INFO, the most 
successful generic Top Level Domain since .COM was introduced.  The .INFO 
launch included a number of pioneering efforts, including the first large 
scale deployment of the new Extensible Provisioning Protocol (EPP) protocol.  
Mr. Lubsen also worked closely with ISOC during ICANN's .ORG redelegation 
process, resulting in Afilias' successful management of the historic migration 
of .ORG to ISOC's sole-member, not-for-profit Public Interest Registry for 
whom Afilias provides registry services.

Mr. Lubsen has over 35 years of business experience in various industries.  In 
addition to Internet companies, he owns Altronics, Inc., an alarm and security 
system vendor, and Allied Central Services, an alarm monitoring company.  As 
such, he has extensive experience in the operation of 24/7 customer service 
departments, and the development and maintenance of high security, redundant 
databases and networks.  Mr. Lubsen's business experience has provided him 
with a solid base of expertise in recurring revenue businesses, as well as the 
accounting and related issues unique to such ventures.  

Mr.  Lubsen holds a B.A. degree from Muhlenburg College, located in Allentown, 
Pennsylvania.


-------  Ram Mohan - Vice President, Business Operations and Chief Technical 
Officer  ----------------------------------------------------------------------

Mr. Mohan is Vice President, Business Operations & Chief Technical Officer of 
Afilias.  Mr. Mohan manages all of Afilias' technical operations which support 
the generic top-level domains (gTLD) .INFO and .ORG, in addition to a number 
of country code (ccTLD) domains.

Under Mr. Mohan's guidance, Afilias was the first domain registry to implement 
an XML-based "thick" registry running on the new EPP.  Afilias also completed 
the largest transition of a domain registry to date when it successfully 
transitioned .ORG from VeriSign on behalf of the .ORG Registry Operator, the 
Public Interest Registry.

Before joining Afilias in September 2001, Mr. Mohan was at Infonautics Corp., 
a pioneering online database and content distribution company.  He has held 
various leadership positions at Infonautics, including Interim COO, CTO and 
VP, Product Marketing.  He is the founder of the award-winning CompanySleuth 
(http://www.companysleuth.com) product, and created the Sleuth line of 
business at Infonautics.  He helped develop Electric Library 
(http://www.elibrary.com), the United States' most used online reference 
database in schools and libraries, and Encyclopedia.com 
(http://www.encyclopedia.com), the first free encyclopedia on the Internet.  
Prior to joining Infonautics, Mr. Mohan worked with First Data Corporation, 
Unisys Corporation and KPMG Peat Marwick in a variety of leadership, 
engineering and technology positions.
 
Mr. Mohan has been active in the Internet and ICANN community, serving on the 
Security and Stability Advisory Committee (SSAC), which is the ICANN Board 
advisory committee comprised of Internet pioneers and technical experts.  Mr. 
Mohan presently serves on the ICANN Nominating Committee.  He also served on 
the Redemption Grace Period (RGP) implementation task force, the GNSO WHOIS 
task force, and the Internationalized Domain Name (IDN) registry 
implementation committee.  In 2003, he was named one of the Philadelphia 
Business Journal's "40 under 40".  Mr. Mohan serves on the Board of the 
Philadelphia-based Metropolitan Career Center, and the advisory boards of 
several Philadelphia-area startup companies.

Mr. Mohan's educational background reflects his belief that technology is best 
used for business advantage and market leadership.  He has a Bachelor's degree 
in Electrical Engineering from the University of Mangalore, an M.B.A. in 
Entrepreneurial Management from Bharathidasan University, and is completing a 
second Master's in Computer Science at Philadelphia's Drexel University.


-------  Roland LaPlante - Vice President and Chief Marketing Officer  --------


Roland LaPlante is the Vice President and Chief Marketing Officer at Afilias.  
Mr. LaPlante oversaw the marketing and launch planning for .INFO in 2001, and 
the transition and launch of every TLD supported by Afilias since.  An 
accomplished marketing expert, Mr. LaPlante crafted an 18-month outreach plan 
for .ORG registrars that resulted in the smooth and well-communicated 
migration of registrars from a thin registry (VeriSign) to a thick one.

During his 25-year career in marketing, he has held senior marketing positions 
at McGraw Hill, Providian Corporation, Citibank and Heublein, Inc.  Before 
joining Afilias, he was Vice President and Chief Marketing Officer of Xlibris, 
an Internet publishing company based in Philadelphia.  Mr. LaPlante has 
extensive Internet marketing experience, having built Xlibris into the 
recognized brand leader in the Internet publishing space, according to 
Newsweek, Inside.com, New York Times and Harper's.  While at McGraw Hill, Mr. 
LaPlante was responsible for bringing two 100-year old construction brands, 
Sweets and Dodge, into the digital age, focusing marketing and product efforts 
on the Internet.  His consumer marketing background is equally as extensive.  
As Vice President and Director of Marketing in Citi's upstate NY and DC banks, 
Mr LaPlante launched numerous new products; he also managed global marketing 
for Smirnoff vodka at Heublein.

Mr. LaPlante holds a B.A. from Dartmouth College and an M.B.A. from Amos Tuck


-------  M. Scott Hemphill - Vice President and General Counsel  --------------

Mr. Hemphill joined Afilias as Vice President and General Counsel in September 
of 2003.  He is responsible for the oversight of legal and policy issues for 
Afilias.

Mr. Hemphill started practicing law in the Washington, D.C. area in 1991, 
later relocating his practice to the Eastern Pennsylvania region.  While in 
private practice, he focused on corporate law with a concentration in mergers 
and acquisitions as well as general technology and Internet issues.

Mr. Hemphill left private practice in 2000 to join Domain Bank, one of the 
Internet's first domain name registrars and one of Afilias' 18 founding 
members, as Vice President & General Counsel.  In 2002, he became President of 
Domain Bank.

While at Domain Bank, Mr. Hemphill was deeply involved in the creation of 
Afilias, serving as co-chair of the Policy Committee formed from Afilias' 
shareholders to help guide the creation of the .INFO registry. 

Mr. Hemphill holds a B.S. in Business from Wake Forest University and a J.D. 
from the College of William & Mary.


-------  Thomas Wade - Chief Financial Officer  -------------------------------

Mr. Wade joined Afilias as Chief Finance Officer in 2001 with over 20 years of 
global experience in the Finance industry.  Prior to joining Afilias, Mr. Wade 
was the Financial Director of Nua Ltd., an Internet Solutions Company in 
Dublin, Ireland.

Previously, Mr. Wade worked on the Nishimatsu Kumagai Joint Venture in Hong 
Kong for the HK$7 Billion IMT tunnel project.  He has also held various 
financial positions in Australia and Ireland including at the State Government 
Insurance Commission of South Australia (SGIC), BSS, and Asahi Synthetic 
Fibers Ltd.

Mr. Wade has a Bachelor of Commerce Degree from the University College of 
Dublin, a Masters of Applied Finance from Macquarie University in Sydney, 
Australia and is a Chartered Management Accountant licensed in the United 
Kingdom, and a Certified Practicing Accountant licensed in Australia.


-------  Steven Pack - Compliance Officer  ------------------------------------

Mr. Pack joined Afilias in October of 2001 as the registry's Compliance 
Officer, specializing in managing organizational compliance regarding policies 
and procedures affecting conflicts of interest and equal access for partners 
and organizational members engaged within the various channel segments of the 
domain name market.

Prior to Mr. Wade joining Afilias, Mr. Pack served as acting Chief Financial 
Office (CFO) on a consulting basis.  During this period, he established 
Afilias' accounting systems, policies, and procedures.

During the .ORG transition in early January 2003, Mr. Pack was responsible for 
the creation of operating guidelines and policies that ensured compliance with 
equivalent access provisions to all registrars who were transitioning from an 
RRP based system to an EPP based system.  This included the training and 
certification of all transition team members.  Mr. Pack provided advice to 
ISOC and its subsidiary PIR in the establishment of registry accounting 
systems and procedures.

Mr. Pack has over twenty years of management experience.  He has held 
positions at numerous industry leaders such as Avis, American Forest 
Products/Louisiana Pacific, Mack Trucks, J.K. Lasser/Deloitte & Touche, as 
well as some mid-sized firms and start-ups.

Prior to joining Afilias, Mr. Pack was a consultant at CFO Synergy, LLC 
serving as Chief Financial Officer for many small to mid-sized companies.  Mr. 
Pack has also held a myriad of finance-related positions for RHI Management 
Resources, Diesel Performance, Inc. and Stockton Kenworth, Inc., among 
others.  He was the managing partner of SPB, a consulting firm in northern 
California providing support as Chief Financial Officer for small and medium-
size organizations.

Mr. Pack holds a B.S. in Business and Accounting from Towson State College.  
He is currently a member of the AICPA and the Pennsylvania Institute of 
Certified Public Accountants.


In addition, the following new positions will be established to further 
support .NET operations:

Chief Operating Officer
Vice President, Engineering
Vice President, External Relations
(vi) all directors or persons with equivalent positions for non-corporate entities, and
-------  Philipp Grabensee - Chairman of the Board  ---------------------------

Philipp Grabensee studied law and philosophy at the Free University of Berlin 
and the Rheinischen-Friedrich-Wilhelms-University in Bonn.  Mr. Grabensee is a 
member of the bar and is registered as a lawyer with the District Court in 
Duesseldorf, Germany.

Mr. Grabensee is a partner at the law firm of SHSG, Attorneys at Law.  Mr. 
Grabensee focuses on all legal questions concerning the Internet.  He 
represented the first German ICANN accredited registrar - EPAG AG.

Mr. Grabensee also served as a member of the policy task force during the 
initial founding of Afilias.  In 2001, Mr. Grabensee was appointed to Afilias' 
Board of Directors, and in September of 2003 he began serving as Chairman of 
the Board.

Mr. Grabensee represented the ICANN Registrar Constituency on the Names 
Council of the DNSO in 2002.  He also participated as a member of the WHOIS 
Task Force and testified in front of the US Federal Trade Commission as an 
expert of WHOIS policy.  He is actively involved in the World Summit on the 
Information Society (WSIS) process.

He also lectured in multimedia law at the Akademie für Werbung und 
Kommunikation in Cologne, Germany.


-------  Richard Lindsay - Executive Committee  -------------------------------

Mr. Lindsay serves as a member of the Executive Committee and Board of 
Directors of Afilias Limited, a global provider of domain name registry 
services.  He was involved with writing the technical portion of Afilias' 
proposal to introduce the .INFO TLD into the domain market.  He was Afilias' 
first Chairman of the Board, serving for three years after the company's 
founding.

Mr. Lindsay is current an Internet Technology and Strategy Consultant in 
Japan, providing consulting services to major Japanese Internet corporations.  
Previously, he was Chief Technical Officer for Global Media Online Inc., an 
ICANN-accredited domain name registrar based in Tokyo, Japan.  While at GMO, 
Mr. Lindsay built and managed the company's technical operations.

Prior to working at GMO, Mr. Lindsay served as Director at the Medical Bank 
Institute in Tokyo where he was responsible for the day to day operations of 
the Network Department.  Mr. Lindsay was also previously employed in sales and 
research by Airborne Express and Fuji Xerox Corporation.  He also served as an 
operations intelligence officer for the United States Navy.

Mr. Lindsay received a B.A. in Russian Studies from Tufts University, 
graduating Magna Cum Laude, and a M.B.A. from the International University of 
Japan.


-------  Moshe Fogel - Director  ----------------------------------------------

Mr. Fogel, of Communigal Communications Ltd., based in Tel Aviv, Israel, 
offers more than 23 years of experience in management and development of 
information systems.  Mr. Fogel has served on Afilias' Board of Directors 
since 2000 and initially served as a member of the Board's Executive 
Committee.  In this capacity Mr. Fogel helped establish Afilias' initial 
business operations when the company first launched in 2001.

Mr. Fogel is the president of Communigal Communications Ltd., an ICANN-
accredited registrar, and has worked as both a software engineer and in senior 
management positions.  He has more than ten years of experience with Internet 
technology, and during the last seven years has focused on Internet and 
Intranet solutions.


-------  John Kane - Director  ------------------------------------------------

John Kane has more than 15 years of experience in sales, marketing and 
management and is currently Vice President of Business Development for eNom 
Inc., a Seattle, WA based ICANN-accredited domain name registrar.

For the last seven years, Mr. Kane has been focused on the online/Internet 
industry, specifically in the area of domain name management, brand protection 
and Internet security.  Previously Mr. Kane served as Vice President of Name 
Management & IP Services for the Corporation Service Company (CSC), the 
largest direct incorporation company in the United States.  At CSC, Mr. Kane 
previously held positions as Vice President of Sales and as General Manager of 
The Company Corporation, which was acquired in 1999.

Mr. Kane is currently Director of Afilias.  While at CSC, Mr. Kane served as 
Marketing Task Force Leader during the formation of Afilias where he led 
initial branding, marketing and public relations efforts for Afilias as it 
launched the .INFO top-level domain until permanent staff was hired. 


-------  Elmar Knipp - Director  ----------------------------------------------

Mr. Knipp has been a member of Afilias' Board of Directors since September 
2003.

Mr. Knipp is Managing Director of Knipp Medien und Telekommunikation GmbH, 
mainly responsible for technology and strategy.  Together with his brother, 
Dietmar Knipp, he founded the company in 1994.  In 1997, Mr. Knipp entered the 
domain market and has since gained experience as a registrar, a Registry 
Operator for sponsored top-level domains (through his involvement with CORE), 
and also as a software vendor for registry systems.

Mr. Knipp is Deputy Chair of the Supervisory Board of DENIC eG and Deputy 
Chair of the Board of CORE as well.

Mr. Knipp holds a university degree in Computer Science and Business 
Administration from the University of Dortmund.


-------  Henry A. (Hal) Lubsen - Director--------------------------------------

Mr. Lubsen is the CEO of Afilias and a veteran in the domain name industry.  
Mr. Lubsen co-founded leading registrar Domain Bank, Inc., one of the 
Internet's first ICANN authorized domain name registrars and one of Afilias' 
18 founding members.  He has also served as a member of the Executive 
Committee of the Internet Council of Registrars (CORE) from 1998 to 2001.

As the CEO of Afilias, Mr. Lubsen directed the launch of .INFO, the most 
successful generic Top Level Domain since .COM was introduced.  The .INFO 
launch included a number of pioneering efforts, including the first large 
scale deployment of the new Extensible Provisioning Protocol (EPP) protocol.  
Mr. Lubsen also worked closely with ISOC during ICANN's .ORG redelegation 
process, resulting in Afilias' successful management of the historic migration 
of .ORG to ISOC's sole-member, not-for-profit Public Interest Registry for 
whom Afilias provides registry services.

Mr. Lubsen has over 35 years of business experience in various industries.  In 
addition to Internet companies, he owns Altronics, Inc., an alarm and security 
system vendor, and Allied Central Services, an alarm monitoring company.  As 
such, he has extensive experience in the operation of 24/7 customer service 
departments, and the development and maintenance of high security, redundant 
databases and networks.  Mr. Lubsen's business experience has provided him 
with a solid base of expertise in recurring revenue businesses, as well as the 
accounting and related issues unique to such ventures.  

Mr.  Lubsen holds a B.A. degree from Muhlenburg College, located in Allentown, 
Pennsylvania.


-------  Thomas Moerz - Director-----------------------------------------------

Mr. Moerz is President and CEO of PSI-USA Inc., an ICANN-accredited domain 
name registrar based in the United States.

He also serves as CEO of InterNetX GmbH / Regensburg, an internet service 
provider in Germany, since 2000.

Mr. Moerz studied Law at the Bavarian Julius-Maximilians-University at 
Würzburg and Friedrich-Alexander University Erlangen-Nürnberg, receiving his 
first state examination in law in 1997.  He then completed his judicial 
training at the district court of Bamberg until 1999 where he sat for his 
second state examination.  During much of this time Mr. Moerz was employed at 
the law-firm of Wannemacher & Partner in Saalfeld, Munich.  He has been 
certified as a lawyer since 1999.

Mr. Moerz became a Member of the Board of Directors of Afilias in June 2002.


-------  Jonathan Robinson - Director------------------------------------------

Mr. Robinson is currently Business Development Director for NetBenefit plc, 
one of Afilias' shareholders and an ICANN-accredited registrar.  At 
Netbenefit, Mr. Robinson serves as a board member and member of the executive 
management team.  Prior to his current role, Mr. Robinson served as Managing 
Director and CEO of Netbenefit from 1997 until 2001, during which time he 
successfully floated NetBenefit plc on LSE and completed the acquisition of 
the company's French subsidiary and a major UK competitor.

Mr. Robinson is also a Director of Nominet UK Ltd., the .UK domain registry.  
He also served as Deputy Chairman of CORE, from 1998 to 1999.

Mr. Robinson has received three successive Deloitte & Touche Fast 50 awards on 
behalf of NetBenefit plc and was an Ernst & Young Entrepreneur of the Year 
semi-finalist in 2000.

Mr. Robinson holds a Ph.D. in Materials Engineering, an M.Sc. in Applied 
Science and a B.Sc. in Physics from the University of Cape Town, in South 
Africa.


-------  Eric Schaetzlein - Director  -----------------------------------------

Mr. Schaetzlein is CTO for Schlund + Partner's Domain Services, a company he 
co-founded in 1995.  He joined the management board of Schlund in 2001 as 
Chief Technical Officer and is responsible for Schlund's domain services 
department.

Mr. Schaetzlein has also worked with German top level domain registry DENIC 
and helped develop DENIC's domain registration system.

Mr. Schaetzlein designed and implemented Schlund + Partner's domain 
registration and DNS system, which has registered some 3.8 million domain 
names.  He also co-designed Schlund + Partner's com/net/org registrar system 
and is familiar with the NSI-RRP and EPP.

In April 2001, Mr. Schaetzlein joined the supervisory board of the .DE 
registry, DENIC eG.  Since December 2003, Mr. Schaetzlein has been a member of 
the advisory council of the Austrian ccTLD registry, nic.at.

Mr. Schaetzlein has attended various workshops on political, legal, and 
technical domain name issues, e.g. ICANN Studienkreis, Domain Pulse, ECLIP, as 
well as RIPE meetings.  Mr. Schaetzlein is a private member of ISOC.

Mr. Schaetzlein holds a Bachelor's degree in Computer Science from the 
University of Karlsruhe, Germany.


-------  Ken Stubbs - Director  -----------------------------------------------

Mr. Stubbs has provided consulting services to various clients for over 25 
years, with a principle focus on the development of marketing strategies and 
operational and organizational structures.  Previously, Mr. Stubbs worked for 
KPMG and Ernst & Young specializing in accounting systems and operations 
management consulting with special emphasis on travel, retail, and real estate 
industries.  Since 1994, Mr. Stubbs has consulted on Internet business 
development strategies for the development of both commercial as well as non-
profit sites. 

Since 1994, Mr. Stubbs has consulted on Internet business development 
strategies for the development of both commercial as well as non-profit sites. 

Mr. Stubbs is also the former Chairman of the Executive Committee of CORE.  
Mr. Stubbs has testified before both the House Commerce as well as the House 
Judiciary Committees as an expert on Internet development and commerce.

Mr. Stubbs has been an active participant in ICANN activities since it's 
inception, participating as a member of the Names Council, (serving as its 
chairman for 2 terms) representing both the Registrar as well as Registry 
constituencies. He was a member of the working group which formulated the UDRP 
and has been an active member of numerous task forces over the last 5 years.

He has also been active participant in the World Summit on the Information 
Society and United Nations ICT Task Force.

Mr. Stubbs graduated with honors from California State University at San Diego 
with a degree in business and is a Certified Public Accountant.
(vii) identify any persons or entities who own or will own or otherwise control, directly or indirectly, 5% or more of the outstanding voting power held by all persons or entities entitled to participate in the election (or other selection) of the applicant’s board of directors or other governing body.
Afilias is a financially sound, privately held company with a strong position 
in a growing and profitable market.  Our shareholders are located worldwide 
with no registrar or registry owning over 9%.

In listing shareholders below, refererence to a "30% threshold owner(s)" shall 
mean an owner(s) of 30% or more of the equity of the listed shareholder.

     Corporate Domains, Inc. (a wholly owned subsidiary of Corporation Service
     Company)
         CEO:  Bruce Winn

     DNS Investment GmbH
         CEO:  Philipp Grabensee
         30% threshold owners:  Philipp Grabensee; Net Investments, LLC

     Domain Bank, Inc.
         CEO:  Keith A. Lubsen
         30% threshold owners:  Keith A. Lubsen; Henry A. Lubsen

     Domain Registration Services, Inc.
         CEO:  John Wong
         30% threshold owner:  John Wong

     Global Media Online 
         CEO:  Masatoshi Kumagai
         30% threshold owner:  Kumagai Masatoshi Office, Ltd.

     Internet Council of Registrars (CORE)
         Executive Committee:  Marcus Faure, Elmar Knipp, Roland Irle, Fredie
         Mezui me Ze, Jordi Hinojosa

     NS Holding Company (a wholly owned subsidary of VeriSign, Inc.)
         CEO:  Stratton Sclavos

     Register.com, Inc.
         CEO:  Peter A. Forman

     Schlund & Partner, AG (a wholly owned subsidiary of 1 & 1 Internet AG)
         Managing Directors:  Eric Schaetzlein, Joerg Hennig, Kirsten
         Haynberg, Achim Weiss

     Tucows, Inc.
         President:  Eliot Noss

The independent evaluators may seek additional information from applicants regarding the qualifications of personnel if deemed necessary.

   

4. Applicant Organization Type

Provide the applicant's type of entity (e.g., corporation, partnership, etc.) and law (e.g., Denmark) under which it is or will be organized. Please state whether the applicant is for-profit or non-profit. If it is non-profit, please provide a detailed statement of its mission. Applicants should be prepared to submit articles of incorporation, or other similar organizational documents later in the evaluation process.

In September 2000, Afilias, LLC (a Delaware Limited Liability Company) was 
formed for the purpose of investigating the feasibility of managing a Top 
Level Domain (TLD).  The membership consisted of 18 registrars.

In February 2001, Afilias Limited ("Afilias"), a private, for-profit company 
limited by shares, was formed under the laws of Ireland, for the purpose of 
negotiating and executing a contract with ICANN for the management of 
the .INFO TLD.  Initially, Afilias LLC owned the outstanding common shares of 
Afilias Limited.  These shares were later distributed to the members of 
Afilias LLC, and Afilias LLC was dissolved.

In June 2001, Afilias USA, Inc. was established as a Delaware Corporation 
wholly owned by Afilias Limited.  Afilias USA, Inc. provides management 
support, together with marketing and customer support services, for Afilias 
Limited.

In March 2002, the company acquired Liberty Registry Management Services 
Company, a Nova Scotia Unlimited Liability Company, with offices in Toronto, 
Canada, from Tucows, Inc.  The name of Liberty Registry Management Services 
Company was changed to Afilias Canada, dba Liberty Registry Management 
Services Company.

In November 2004, Afilias India Pvt. Ltd. was formed in support of the .IN 
domain.

-----------------------------------------------------------------------


***Outsource Vendor Identifying Information***

In compliance with the RFP, Afilias outsources a significant portion of our 
registry service (DNS)  to UltraDNS Corp. 

Identifying information regarding UltraDNS is provided below:

Address:  
UltraDNS Corporation
1000 Marina Blvd
Suite 600
Brisbane, CA 94005

Office:  +1.650.228.2300
Facsimile:  +1.650.228.2001
Principal Web Site:  www.ultradns.com

UltraDNS Corporation is the world's leading Managed DNS Service Provider with 
over ten million domains currently under management, delivering solutions that 
enhance the reliability and performance of the world's largest directories and 
the mission-critical applications that access them. UltraDNS offers highly 
scalable solutions - both as a managed services provider and as a developer of 
custom infrastructure solutions - built on its unique Directory Services 
Platform and proprietary, patented technologies. UltraDNS infrastructure 
services, such as Managed DNS, address the growing need for fast, reliable 
responses to directory queries in today's converging Internet/telecom 
environment. By connecting a user's information request to the proper 
directory and assuring a quick, accurate response, UltraDNS plays a key 
enabling role in delivering content, information and data to users when, where 
and on whatever device they choose. 

Founded in November 1999, UltraDNS Corporation is a for-profit company 
established as a Delaware corporation.  UltraDNS is privately held and is 
funded by Reuters Group PLC, VantagePoint Venture Partners and New Enterprise 
Associates. For more information please visit www.ultradns.com.

The current number of employees at UltraDNS is forty-five (45).

Contact Person:
Michael Guglielmi
Vice President, Corporate Development
UltraDNS Corporation
1000 Marina Blvd.
Suite 600
Brisbane, CA 94005
USA
Phone:  +1.650.227.2658
Fax:  +1.650.228.2001
mikeg@ultradns.com
   

5. Number of Employees

Provide the number of employees currently employed by the applicant or to be employed concurrently with a selection as the successor registry operator.

The current total number of employees of Afilias is seventy-five (75).

Staffing is planned to increase by forty-six (46) in the first year if Afilias 
is selected as the .NET registry operator.  Complete details of the plan 
including positions, functions, and locations is included in part 2, section 4,
(b)(ii).
   

6. Contact Person

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

[RESPONSE IS CONFIDENTIAL]
   

RFP Part 2: Technical and Financial Information

The criteria by which the applicants will be evaluated are set forth below. Each criterion is labeled as either absolute or relative. Diagrams, charts and other similar material may be submitted in response to specific provisions where so indicated in the RFP as posted.

1. ICANN Policy Compliance

Criteria: The successor .NET registry operator must comply with all existing consensus policies of ICANN and must agree to comply with all future consensus policies of ICANN. This is an absolute criterion.

Describe in detail your method for implementing ICANN's Inter-Registrar Transfer Policy.

Since its inception, Afilias has been committed to supporting all ICANN 
policies including consensus policies.  Further, we remain committed to 
participating in the ICANN policy development process and commit to 
implementing and complying in all respects with all future consensus policies 
of ICANN.

...  I. Compliance Overview

By virtue of its agreement with ICANN for the .INFO TLD, Afilias has already 
successfully implemented, and will continue to refine, mechanisms that ensure 
compliance with ICANN-developed policies and requirements as outlined in 
registry agreements.

Afilias has actively participated in the ICANN policy development process 
(PDP) discussions since its inception, and continues to constructively support 
ICANN's bottom-up PDP.

Afilias has strongly supported GNSO and ICANN policies as well as broader 
community activities.  Afilias is the only gTLD registry accredited to the 
World Summit on the Information Society (WSIS), and is organizing a conference 
to assist the Working Group on Internet Governance (WGIG) to ensure 
continuation of private sector management of the DNS.  Afilias is a committed 
sponsor of many ccTLDs' managers training workshops, policy meetings of 
regional TLD organizations, DNS related technical meetings and industry events.

Because of ICANN's unique mandate to preserve the operational stability of the 
Internet, it is important that the .NET registry operator implements 
mechanisms for assuring compliance with the various policies and contractual 
requirements that arise by virtue of its unique relationship with ICANN.  In 
proposing such mechanisms, a prospective registry operator cannot merely 
recite its intention to abide by the requirements of the registry agreement 
with ICANN.  Based on its experience with .INFO, Afilias has demonstrated to 
ICANN that, as the registry operator, it understands policy and contractual 
requirements, and can immediately comply with both on an ongoing basis.

Afilias' business, technical, and policy operations have successfully 
implemented methodology for ensuring compliance with ICANN-developed policies 
and requirements contained in registry agreements as well as new policies 
established by ICANN.  These methods further described below, include active 
participation in ICANN policy-making processes, as well as internal review of 
TLD business decisions for legal and policy compliance. 

In addition to these processes, Afilias has established an external Technical 
Advisory Group (TAG), consisting of several respected professionals from the 
Internet's technical, operational and registry communities.  The TAG will help 
Afilias review and establish practices and policies related to the .NET 
registry operation.  It will also evaluate new services for the .NET registry, 
thus improving and contributing to the ICANN PDP and technical standards 
compliance process. 

The formation of the TAG itself reflects our improved approach for overall 
policy development and compliance, providing greater transparency and better 
mechanisms for protecting the .NET registry management from unilateral 
decision-making.  

The TAG will also be responsible for steering the Internet Infrastructure 
Innovation Fund (IIIF), that Afilias will establish to further improve the 
security and stability of the DNS through sponsorship of various activites 
such as research, standards development, implementation and interoperability 
testing, technology trials and deployment projects.  Afilias pledges to 
allocate $1,000,000 USD towards the IIFF.

Afilias proposes to maintain and continue to refine such methodology.  With 
these methods in place, Afilias ensures that policy compliance is fully 
integrated into all operations in an efficient and streamlined fashion.

...  II. Participation in ICANN Policy-making Process

Afilias considers it a basic principle of .NET TLD administration that the 
operator of the registry is a trustee of a valuable and important global 
public resource.  Therefore, Afilias proposes to continue working with ICANN 
in the development and enhancement of policies affecting the Internet at 
large.  Examples of such participation include:

· Active participation in ICANN Working Groups, Task Forces, Committees, GNSO 
and ccNSO constituencies, as well as in open GAC meetings.

·Afilias actively participates in the work of gTLD constituency.  Afilias 
Chairman, Mr Grabensee, represented the ICANN Registrar Constituency on the 
Names Council of the DNSO in 2002.   He was a member of the WHOIS Task Force 
and testified in front of the US Federal Trade Commission as an expert in 
WHOIS policy. 

· Mr Stubbs, a member of the Afilias Board of Directors, has been an active 
participant in ICANN activities since its inception, participating as a member 
of the Names Council, (serving as its chairman for 2 terms) representing both 
the Registrar as well as Registry constituencies.  He was a member of the 
working group which formulated the UDRP and has been an active member of 
numerous task forces over the last 5 years.

· Members of the Afilias management are involved with many ICANN policy 
development committees, such as the IDN Registry Implementation committee, 
Security and Stability ICANN committee, and many other workshops, such as the 
recent IDN workshop in Cape Town meeting, amongst many others.

· Leveraging and continuing our legacy of active participation in the 
development of Internet governance policies.  Afilias's International Affairs 
and Policy Adviser, Ms Desiree Miloshevic, is leading our efforts in the 
development of Internet Governance policies to ensure continued support of 
private sector self-regulation with community and limited government 
participations in the management of the DNS.  She actively participates in the 
meetings of the Working Group on Internet Governance and the World Summit on 
the Information Society (WSIS), The UN ICT Task Force on Internet Governance 
and in many other international policy forums worldwide.

· Afilias also contributes to technical innovation in the DNS by sponsoring in 
particular IPv6 and Enum activities around the world. 

Afilias also commits to strictly comply with the Consensus Policy procedures 
set forth in Section 4 of the existing registry agreement for the .NET TLD.  
Afilias has successfully operated under the Consensus Policy procedures by 
virtue of its agreement with ICANN for the .INFO TLD.  By continuing such 
participation, Afilias is positioned to understand and properly implement 
ICANN-developed policies.

...  III.  Legal and Policy Review

From our registry experience, Afilias has learned that the most effective 
method for ensuring policy and contractual compliance is for the TLD registry 
operator to rigorously review operational plans and programs prior to 
implementation.  Afilias ensures that such review is accomplished in 
accordance with the following processes:

· Requiring managers to submit operational plans and programs, such as the
deployment of new services, for compliance review.

· A Compliance Officer with significant experience in Internet governance,
operations, and contract compliance conducting compliance reviews. 

· Maintaining constant contact with ICANN staff regarding proposed activities
and compliance issues. 

· The establishment of TAG to help shape future GNSO policies; thereby 
contributing to the stability and security of the Registry operations.

With respect to ICANN, Afilias has already successfully incorporated the above 
mechanisms under its Registry Agreement for the .INFO TLD.  For example, in 
accordance with Appendix H of the .INFO Registry Agreement, there is a 
compliance officer that ensures ICANN's requirement of "Equal Access and 
Nondiscrimination" is followed and strictly enforced.  Afilias has 
demonstrated its ability to continually provide equal access to all ICANN-
accredited registrars in its operation of .INFO.

...  IV.  Method For Implementing ICANN's Inter-Registrar Transfer Policy

Afilias was at the forefront of the implementation of the Inter-Registrar 
Transfer Policy, including the Transfer Dispute Resolution Policy, which took 
effect in November, 2004.  Working within the Registry Constituency framework, 
Afilias took a leading role in designing and implementing a workable technical 
solution to the "transfer undo" feature of the policy.  Afilias also worked 
diligently to ensure that the processes and procedures put in place to 
implement and administer the policy would be straightforward and easy for 
registrars to understand and use.

As implemented by Afilias, the various forms required to make use of the 
Transfer Policy may be accessed by registrars on the secure section of the 
Afilias website.  Afilias has made available web forms by which registrars may 
file requests for enforcement, responses, and withdrawals and take other 
relevant actions in respect of a dispute case.  Afilias has established an 
internal process for handling such filings, with decisions on Requests for 
Enforcement (RFE) made by members of the company's legal staff.

In implementing the "transfer undo" feature, Afilias has created a new command 
by which the sponsorship of a domain name may be transferred between 
registrars without the registry system automatically adding a year to the 
registration term of such domain name, and without charging the account of the 
gaining registrar.  Once a transfer undo has been completed, the gaining 
registrar may access the account and make desired modifications to the domain 
record.
   

2. Equivalent Access for Registrars

Criteria: All ICANN-accredited registrars must be allowed to qualify to register names in .NET. The registry operator must treat all registrars that have qualified to operate as .NET registrars equivalently. This is an absolute criterion (except as described below regarding languages).

(a) Describe in detail your methods of providing registry services on an equivalent basis to all accredited registrars having registry-registrar agreements in effect. Your description should include any measures intended to make registration, technical assistance, and other services available to ICANN-accredited registrars in multiple time zones and multiple languages. Please include in your description the languages that you agree to support if you are selected as the .NET registry operator. Support in English is an absolute criterion. Support in additional languages is a relative criterion. In addition, describe the Registry Code of Conduct and other commitments you propose to make to ensure that all such registrars receive equivalent access to registry services. In preparing your response to this item, you may wish to refer to Appendices H and I of the registry agreements ICANN has entered into for other unsponsored TLDs (e.g., .biz, .com, .info, .name, .org and .pro).

... I. Overview of Equivalent Access

Afilias has continually offered registry services and provided access to the 
Shared Registry System (SRS) on an equivalent basis to all ICANN-Accredited 
registrars that have executed a Registry-Registrar Agreement (RRA).  Upon 
execution of the .NET Registry Agreement, Afilias will have each registrar 
with a Registry-Registrar Agreement in effect with VeriSign execute an Afilias 
Registry-Registrar Agreement, similar to Appendix F of the .INFO and .ORG 
Agreements with ICANN.

All registrars who currently have Registry-Registrar Agreements with Afilias 
experience equivalent and fair access to registry services.  Afilias has 
accomplished this through its commitment to the following principles:

· A Registry Code of Conduct (Appendix I)

· Fair treatment of registrars

· Making registration, technical assistance and other services available to 
all ICANN-accredited registrars on a 24/7/365 basis..

Afilias proposes to maintain these proven mechanisms for the .NET Registry, 
which will ensure the provision of all registry services to registrars on an 
equivalent basis.  As described below, Afilias meets or exceeds this absolute 
criterion in the RFP.  Afilias also excels at the relative criterion of 
support in languages other than English through its commitment to providing 
technical support in the following languages:  English, Chinese (Cantonese and 
Mandarin), French,
German, Hindi, Italian, Japanese, Korean, Russian and Spanish.

...  II. Code of Conduct 

Afilias recognizes that domain names are the means by which businesses, 
consumers, and individuals gain access to, navigate, and reap the benefits of 
the global Internet.  These benefits cannot be fully realized, however, unless 
DNS resources are administered in a fair, efficient, and neutral manner that 
makes them available to all parties desiring to provide DNS services.  To 
ensure the provision of neutral registry services, Afilias will comply with 
the following Code of Conduct:

1. Other than in connection with the distribution of dividends or other 
profits to Afilias' shareholders, Afilias will not, directly or indirectly, 
show any preference or provide any special consideration to any company, 
person, or entity that is a DNS registry provider or registrar services 
provider, as those terms are defined by ICANN.

2. All ICANN-accredited Registrars authorized to register names in the .NET 
top-level domain shall have equal access to Registry Services provided by 
Afilias.

3. Afilias shall not in any way attempt to register domain names in its own 
right, except for names designated for operational purposes in compliance with 
Subsections 3.6.1 or 3.6.2 of the Registry Agreement.  In its monthly report 
to ICANN, Afilias shall include a list of all names designated for operational 
purposes.

4. Any shareholder, subsidiary, affiliate, or other related entity of Afilias 
that also operates as a provider of registrar services shall maintain separate 
books of account with respect to its registrar operations.

5. Neither Afilias, nor its owners, subsidiaries, affiliates, or other related 
entities shall have access to user data or proprietary information of a 
registrar served by Afilias, except as necessary for registry management and 
operations.

6. Afilias will ensure that no user data or proprietary information from any 
registrar is disclosed to its affiliates, subsidiaries, or other related 
entities, except as necessary for registry management and operations.

7. Confidential information about Afilias' business services will not be 
shared with employees of any DNS services provider, except as necessary for 
registry management and operations.

8. Afilias will conduct internal neutrality reviews on a regular basis.  In 
addition, Afilias and ICANN may mutually agree on an independent party that 
ICANN may hire, at ICANN's expense, to conduct a neutrality review of Afilias, 
ensuring that Afilias and its owners comply with all the provisions of this 
Registry Operator Code of Conduct.  The neutrality review may be conducted as 
often as once per year.  Afilias will provide the analyst with reasonable 
access to information and records appropriate to complete the review.  The 
results of the review will be provided to ICANN and shall be deemed to be 
confidential and proprietary information of Afilias and its owners.

...  III. Fair Treatment

Afilias is committed to the fair treatment of all ICANN-accredited registrars, 
which is a requirement set forth in Section 3.5 of the existing .net registry 
agreement.  Afilias proposes implementing measures similar to those utilized 
in the .INFO TLD to ensure all registrars are treated fairly.  These measures 
include:

* Avoiding arrangements with inherent conflicts of interest

* Developing and implementing a statement of equal access and non-
discriminatory practices.

...  IV.  Avoiding Conflicts of Interest

Among the shareholders of Afilias are sixteen (16) ICANN-accredited 
registrars.  Afilias has implemented and continually monitors procedures to 
ensure that its registrar-owners do not receive preferential treatment or 
benefits not available to all ICANN-accredited registrars at the same time.  
All registrar-owners have signed a shareholder agreement that already ensures 
that NONE of the owners may obtain any information from Afilias that could be 
used as a competitive advantage of any sort.  This arrangement has been 
successfully implemented with respect to Afilias' current registry operations, 
and we are confident a similarly successful implementation will occur for .NET.

Afilias has avoided and will not place itself in a position where a conflict 
of interest might compromise its neutrality.  Furthermore, Afilias agrees to 
abide by its Code of Conduct, which prohibits Afilias from:

* Showing any preference or providing any special consideration to any ICANN-
accredited registrars

* Allowing its shareholders, subsidiaries, affiliates, and other related 
entities to have access to user data or proprietary information of an ICANN-
accredited registrar

* Disclosing to its affiliates, subsidiaries, and other related entities any 
user data or proprietary information from any ICANN-accredited registrar

* Sharing its confidential information with employees of any ICANN-accredited 
registrars, and

* Afilias will continue avoiding any conflicts of interest that detract from 
ICANN's mission to promote the public interest in a neutral manner.


...  V.  Equivalent Access Certification

As part of Exhibit H of the .INFO registry agreement, the Afilias Equivalent 
Access Certification details Afilias' policies and procedures for ensuring 
that registrars are treated fairly by the registry operator.  With respect to 
the Equivalent Access Certification, Afilias proposes to accomplish the 
following:

* Provide all registrars worldwide with the opportunity to register domain 
names pursuant to the terms and conditions of the registry-registrar agreement

* Provide all ICANN-accredited registrars with equivalent access to the 
registry-registrar protocol

* Certify to ICANN on a semi-annual basis that Afilias, in its capacity as 
the .net TLD registry operator, is providing all ICANN-accredited registrars 
with equivalent access.

...  VI.  Implementing Equivalent Access Doctrine for .NET

By employing methods utilized in operating the .info TLD, Afilias proposes to 
implement the Equivalent Access doctrine by taking the following steps:

* Abide by the Registry Code of Conduct.

* Conducting business and technical operations from different premises than 
any ICANN-accredited registrar.

* Restricting access to Afilias premises and facilities to assigned personnel 
employed or contracted by Afilias.

* Afilias will have various procedural safeguards in place to ensure that the 
data and information of the registry business are not utilized to the 
advantage of one ICANN-accredited registrar over another or others.

* All Afilias personnel and other employee who have a need to know its 
business will undergo a formal Organizational Conflict of Interest (OCI) 
Training Program that will provide a clear understanding of the Plan and will 
focus on the Equivalent Access Policy and their responsibility under the 
Plan.  All staff members will be required to receive OCI training before they 
are given an assignment or access to Afilias material.  Annual OCI refresher 
training will be required.

* Providing a compliance officer solely for ensuring that Afilias acts in 
accordance with equal access and non-discriminitory practices.

* Requiring that all Afilias personnel and others with a need to know its 
business sign a non-disclosure agreement and a Business Organizational 
Conflict of Interest  Avoidance Certificate acknowledging, among other things, 
his/her understanding of the OCI requirements, and certifying that he/she will 
strictly comply with the provisions of the OCI Plan.

Afilias has successfully implemented the foregoing procedures in its current 
TLD registry operations.  For the .NET TLD, Afilias proposes to implement and 
meet these same requirements.

...  VII.  Registration, Technical Assistance, and Other Services

Afilias currently provides registry services, including, but not limited to, 
registration, technical assistance and other services on an equivalent basis 
to all accredited registrars having registry-registrar agreements in effect, 
including to those registrars in different time zones and speaking different 
languages.  As part of this proposal to ICANN, Afilias will continue to 
provide the following services to registrars:

· Web-based, self-help services

· 24/7 year-around support

· Communications via email

· Assistance in ten languages -  English, Chinese (Cantonese and Mandarin), 
French, German, Hindi, Italian, Japanese, Korean, Russian and Spanish

Afilias proposes to continue providing these high quality services to 
registrars under the .NET TLD, thus ensuring that registrars are granted an 
equivalent level of support regardless of the time of day or where they are 
located.

If ICANN agrees that the TLD database should be migrated from a thin model to 
a thick model, Afilias will provide registrars with equivalent access to the 
SRS via the Extensible Provisioning Protocol (EPP) once the transition from 
the Registry-Registrar Protocol (RRP) to EPP is complete.  During the 
transition period, registrars that wish to use RRP will be provided equivalent 
access to the SRS through an RRP-to-EPP Proxy until the registrar has passed 
the EPP Operational Test and Evaluation certification process.  Registrars 
will receive assistance with the transition from RRP to EPP through Afilias 
Tech(nical) Support, which operates 24x7x365.

(b) VeriSign, Inc., the current operator of the .NET registry uses a registry-registrar protocol (RRP) documented in RFC 2832. At the time of the transition, the selected successor operator will be required to continue to support the RRP (unless a migration of registrars in .NET to another protocol has already been completed by that time). In addition, the selected successor operator will be required to implement support for Version 1.0 of the Extensible Provisioning Protocol as specified in RFC's 3730, 3731, 3732, 3733, 3734, and 3735. Provide a detailed description of your plan for supporting RRP at the time of transition, for supporting EPP 1.0, and for providing registrars with a smooth, low-cost migration path from RRP to EPP.

...  I. Overview

Afilias, with the successful transition of the .ORG registry for Public 
Interest Registry, and its registrars from RRP to EPP became the world's first 
gTLD provider to ever accomplish such a feat.  Afilias executed a clear well-
thought through migration plan that was easy to follow as well as implement 
for the registrars involved in the transition.  Everything from toolkits, 
outreach programs and 24/7 technical support, to operational test environments 
were at the disposal of each and every registrar throughout the course of the 
migration period and beyond.  Afilias has complete confidence that it can 
successfully replicate for .NET the smooth, low-cost migration path from RRP 
to EPP that was developed for .ORG, which is now the industry benchmark.

...  II. Supporting RRP at the Time of Transition

At the time of transition, registrars will connect to the registry using 
Registry-Registrar Protocol (RRP).

The RRP interface will be a proxy for EPP commands, so that the fundamental 
application need not change when registrars have been fully transitioned to 
the newer EPP.  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.  From the perspective of an existing .NET 
registrar, it will appear as if it is still connected to the original .NET 
registry.  However, with Afilias' .NET solution, they are now free to make the 
gradual transition to EPP 1.0 which is the most modern registry-registrar 
protocol to date.

Details of the entire transition plan can be found in Part 2, Section 8 of 
this proposal.  Furthermore, the Registry-Registrar Model portion of Part 2, 
Section 5.b.iv, provides detailed usage of both RRP and EPP 1.0 for the 
Afilias .NET implementation.

...  III. Supporting EPP 1.0

Support for EPP 1.0 will follow a smooth gradual transition phasing process.  
Registrars will be able to connect to the EPP 1.0 system immediately at the 
conclusion of the RRP stability period.  EPP 1.0 at the start, however, will 
have some policies relaxed for domain contacts to emulate RRP behavior.  This 
domain contact policy which provides the ability to create domains without 
authoritative contact associations is the "Thin EPP" or "EPP thin" System.  
Later, when the authoritative domain contact associations are mandatory, 
Afilias will refer to this as "Thick EPP" or "EPP thick".

A. Phase 1: RRP and EPP

At cutover, all registrars will continue to connect to the registry using the 
RRP protocol.  Ten days following the cutover, and lasting for six months 
thereafter, the Afilias .NET registry will support both RRP and Thin EPP.  RRP 
support will be provided by the use of Afilias' innovative RRP-to-EPP proxy.  
During this phase, registrars can add contacts and associate them to domains 
if they choose to.  This allows registrars to accelerate the pace of migration 
to EPP, and set their own schedules.  During this phase, registrars that have 
not made the switch to EPP will prepare for the migration to an EPP thin only 
registry service (the discontinuation of RRP).  Some registrars may choose to 
use EPP right from the beginning of its availability in .NET to take full 
advantage of the improvements our EPP implementation brings over RRP.  
Throughout the dual RRP and EPP phase, Afilias will assist and further educate 
RRP-based registrars about using EPP.  This will ensure the successful 
transition of all registrars to EPP 1.0, either thin or thick based on their 
preference.
    
B. Phase 2: Thin EPP (thin domain contact policy)

After the six month dual protocol support period has ended, the second phase 
of the transition commences, and will last for twelve months.  All registrars 
must connect to the .NET registry via EPP 1.0 and the registry will operate 
under the EPP thin domain contact policy.  During this period, registrars will 
continue to be able to populate authoritative contact data and associate them 
with domains.  This complete flexibility affords registrars to move to EPP 
thick at a pace that suits their needs. 

EPP thick registry policy requires that every domain contain a registrant 
contact and at least one authoritative contact for each of the following 
contact types: Billing, Technical and Administration.  Data Collection Policy 
(DCP) markup via the EPP <contact:disclose> element will be set at contact 
creation time, instantaneously enabling the .NET registry to reflect privacy 
policies for .NET.  In addition, Afilias' EPP thick registry will support 
whatever policy decisions are made as a result of the WHOIS discussions under 
way in ICANN.

C. Phase 3: Thick EPP (thick domain contact policy)

At the end of phase 2, and after eighteen months have transpired since 
the .NET registry cutover to Afilias, the .NET registry will become an EPP 
thick registry, and the EPP thick domain contact policy will be enforced.  
Registrars that have not created any further associated authoritative contact 
data with their domains will now receive enforcement messages returned by 
commands that maintain the .NET thick domain contact policies.  Afilias' 24/7 
technical support staff will continue to assist and enable registrars to make 
this final migration to the safe and secure EPP 1.0 standard.

...  IV. Providing Registrars With a Smooth, Low-cost Migration Path from RRP 
to EPP

The deliberate and paced three-phase registry transition model is cost-
effective for registrars as it provides both the current .NET RRP interface 
and  the newer,  successor protocol EPP 1.0 in parallel execution.  For all 
registrars with and without experience in EPP registry connectivity, Afilias 
will make available a .NET OT&E environment that will be functionally the same 
as the production .NET environment.  Here registrars can become familiar with 
EPP in preparation for the phasing out of RRP.  

To further ease migration, Afilias will make available open-source EPP-RFC and 
RRP Registrar Toolkits.  In addition, Afilias will make available a Unix based 
registrar client application program and its source code to enable registrars 
to connect and work using EPP 1.0.  Both will be packaged and available on the 
Afilias web site for quick, easy and free download.

In addition, Afilias intends to help registrars defray the registrar cost of 
transitioning from the RRP thin registry to the EPP thick registry.  It has 
set aside funds to reimburse each NET-accredited registrar at a rate of $0.25 
per domain name under management at the time of the transition from VeriSign.

...  V. Incumbent Transition Risk

Although VeriSign does not have to migrate its database if it is selected as 
the successor .NET registry operator, VeriSign would still face a significant 
migration risk for the transition from RRP to EPP, which require fundamental 
changes in the registry system.  Even teams that are experienced in migrating 
registries with a few thousand domains may find serious shortcomings in their 
approach to migrating a registry with over five million domains.

No other registry has the equivalent experience of Afilias when it comes to 
the mistake-free migration of a domain name registry system.
   

The applicant's response to Part 2, Section 3 will remain confidential to ICANN and the independent evaluators. ICANN will use reasonable efforts to avoid publication or release of this information, but in no circumstance will ICANN's liability for any release of this information exceed the amount of the application fee.

3. Registry Operations

Criteria: The successor .NET registry operator must provide name registration within the time specified in the Appendix D to the existing .NET registry operator agreement. This is an absolute criterion. The ability to provide additional registry services and/or the ability to provide name registration faster than the specifications on Appendix D are relative criteria. An assessment of this ability will include the evaluators’ assessment of the factors described below.

(a) Provide a full description of all registry services you propose to provide and demonstrate your technical and legal ability to provide them, including your prior experience offering these or similar services. If you propose to offer any registry services that you believe are not now offered, include for such services your assessment of the benefits and burdens associated with such new services, as those benefits and burdens apply to registrants and registrars. In addition, describe the technical components and aspects of the planned registry services, and how you will support the same.

[RESPONSE IS CONFIDENTIAL]

(b) To enable the evaluators to assess your capability (both technical and financial) to deliver the registry services you propose to provide, please include the following information:

(i) A detailed description of your current business operations, including (A) core capabilities in registry/database and Internet related operations and (B) the services and products you currently offer, with data on how long you have offered them on the current scale. To the extent this description does not fully capture your ability to provide the registry services you propose to offer, add the appropriate supplementary information to fully describe that ability.

[RESPONSE IS CONFIDENTIAL]
(ii) Whether you currently provide any domain name registration services and describe such services.

[RESPONSE IS CONFIDENTIAL]
(iii) A description (including location) of facilities (including available network capacity) available to house staff and equipment necessary to operate the registry.

[RESPONSE IS CONFIDENTIAL]
   

4. Revenue and Pricing Model; Financial Strength and Stability

Criteria: Each applicant must demonstrate sufficient financial strength and stability, based upon its existing financial condition and its proposed business model for operation of the registry, to provide reasonable certainty that it will be able to fulfill its obligations over the life of the .NET registry agreement. This is an absolute criterion. In building their financial and pricing models, applicants should assume that the following fees will be payable: (i) an annual fee to ICANN of US$132,000 for the first year, increasing by no more than 15% each year thereafter and (ii) registry-level transaction fees totaling non-refundable amounts of US$0.75 for each annual increment of an initial domain name registration and US$0.75 for each annual increment of a domain name re-registration registered by a registrar (in addition to preexisting fee obligations payable annually by registrars to ICANN), to be allocated equally to the following three purposes: (a) a special restricted fund for developing country Internet communities to enable further participation in the ICANN mission by developing country stakeholders, (b) a special restricted fund to enhance and facilitate the security and stability of the global Internet’s system of unique identifiers, and (c) general operating funds to support ICANN's mission to ensure the stable and secure operation of the global Internet's systems of unique identifiers. The per-name price charged to registrars is a relative criterion, with lower committed prices being preferable to higher prices.

All applicants should note that registration fees paid to VeriSign prior to the actual transfer of operational responsibility will not be transferred to a subsequent registry operator.

(a) Provide the following financial statements for the applicant (or, if the applicant is a wholly owed subsidiary of another entity, for the applicant and such other entity on a consolidated basis): three years of financial statements (including balance sheet, income statement, cash flow statement and statement of stockholders’ equity), audited by an independent accounting firm and prepared in accordance with either U.S. generally accepted accounting principles or the International Accounting Standards. Applicants who do not have such audited financial statements may substitute such other information and statements about their operations that are reasonably equivalent to such financial statements. The independent evaluators will be responsible for determining whether such information and statements are sufficiently equivalent to allow the evaluators to conduct an evaluation of the applicant’s financial strength comparable to the evaluation conducted on those applicants who do submit the requested financial statements.

[RESPONSE IS CONFIDENTIAL]

(b) Provide the applicant's business plan for the operation of the registry, including:

(i) a detailed description of all revenue or commercial benefit to be derived from or related to your operation of the registry, including but not limited to details of the expected or anticipated revenue and the assumptions about prices charged for services to be offered, and anticipated demand for those services at high, medium and low levels;

[RESPONSE IS CONFIDENTIAL]
(ii) staffing model, showing the number and types of employees needed at the various levels of demand and the expenses associated with that staff. Include information on (A) applicant’s hiring policy and training programs (for both new and continuing staff), (B) staffing level to handle both expected and unexpected volume levels, and react to unplanned outages, infrastructure vulnerabilities and security breaches and (C) customer service staff to support on a 24 hour basis in multiple languages;

[RESPONSE IS CONFIDENTIAL]
(iii) expense model, incorporating both the staffing expenses described above and all other anticipated expenses of the operating the registry;

[RESPONSE IS CONFIDENTIAL]
(iv) property, plant and equipment budget;

[RESPONSE IS CONFIDENTIAL]
(v) a projection for the sources and uses of cash, showing the applicant's current cash available and the sources of cash available to applicant in the future to fund operating and capital expenditures.
[RESPONSE IS CONFIDENTIAL]
   

5. Technical Competence

Criteria: The .NET registry operator must meet the specifications of the current .NET registry contained in the following sections of the current .NET registry agreement listed below (if a “thick registry” model is being proposed by applicant, the specifications for the current .org agreement, rather than the current .NET agreement, shall apply in the case of Appendices O, P and Q). This is an absolute criterion. The degree to which applicant’s proposal commits applicant to exceed these specifications shall be relative criteria:

Appendix C.4, Name server Functional Specifications

Afilias meets the absolute specifications for Appendix C.4 in Name Server 
Functional Specifications.  In addition, itand  exceeds the specifications 
absolute and relative criteria for Appendix C.4 in the following manner:
&#61623;Details the exact specifications by which it will comply to operate 
the DNS 
services for the .NET domain including descriptions and locations of 
facilities, systems.
 
· Implementation of a Agrees to comply with a more expansive set of RFCs thean 
in the current .NET registry agreement

· Discusses the iImplementation ofation of IPv4 and IPv6 records for the .NET 
TLD

· Significantly improvement on current SLAs (Commits to SLAs provided in .NET 
Appendix D), guaranteeing which guarantee 99.999% network availability

-----------------

Zone file generation involves 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 continuously in near real-time and published to the name servers. 
These updates will reflect any DNS-related 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, up to a maximum of 13, for each unique domain/nameserver 
combination. Domain objects with status values of clientHold, serverHold, or 
inactive will not be included in the zone file.

In the case of IPv4, one A record for each required glue record, up to a 
maximum of 13 per domain name. The registry will implement, on a rational 
schedule, glue generation and pruning criteria as specified by ICANN from time 
to time.

In the case of IPv6, one AAAA record for each required glue record will be 
supported. Additional glue records may also be published, if symbolic domain 
name servers included as part of a domain name's AAAA record are also 
subordinate to the .NET TLD. 

The .NET registry will provide bulk access to the TLD zone file for qualified 
third parties. The service will operate according to the prevailing policies 
of ICANN and Afilias.

The DNS services comply fully with the following RFCs: 1034, 1035, 1101, 2181, 
and 2182, as well as (to the extent applicable) 1771, 1812, 2080, 2236, 2328, 
2373, 2453, 2460, 2463, and 2464.

The registry operator shall provide domain name services via multiple meshes 
of core servers located around the world, in accordance with the provisions of 
Appendices D and E. Some of the domain name server sites are listed below, and 
illustrated in Figure 2. Additional sites may be added as the need arises.

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

Autonomica has DNSNODEs in producation 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 locations the DNSNODE peers at the local Internet Exchange 
Point.

Appendix C.5, Patch, Update, and Upgrade Policy

Afilias meets the absolute criteria specifications for Appendix C.5 in its 
Patch, Update and Upgrade Policy. In addition it exceeds the specifications 
relative criteria in the following manner: 

· Afilias will commit to producing changes in the OT&E system that affect 
registrar clients at least 60 days ahead of a new promotion

Afilias may issue periodic patches, updates or upgrades to the Software, RRP, 
EPP or APIs ("Licensed Product") licensed under the Registry-Registrar 
Agreement (the "Agreement") that will enhance functionality or otherwise 
improve the Shared Registration System under the Agreement. For the purposes 
of this Part 13 of Appendix C, the following terms have the associated 
meanings set forth herein.

(1) A "Patch" means minor modifications to the Licensed Product made by 
Afilias during the performance of error correction services. A Patch does not 
constitute a Version.

(2) An "Update" means a new release of the Licensed Product which may contain 
error corrections, minor enhancements, and, in certain circumstances, major 
enhancements, and which is indicated by a change in the digit to right of the 
decimal point in the version number of the Licensed Product.
(3) An "Upgrade" means a new release of the Licensed Product which involves 
the addition of substantial or substantially enhanced functionality and which 
is indicated by a change in the digit to the left of the decimal point in the 
version of the Licensed Product.

(4) A "Version" means the Licensed Product identified by any single version 
number. Each Update and Upgrade causes a change in Version. Patches do not 
require corresponding changes to client applications developed, implemented, 
and maintained by each registrar. Updates may require changes to client 
applications by each registrar in order to take advantage of the new features 
and/or capabilities and continue to have access to the Shared Registration 
System. Upgrades require changes to client applications by each registrar in 
order to take advantage of the new features and/or capabilities and continue 
to have access to the Shared Registration System.

Afilias in its sole discretion will deploy Patches during scheduled and 
announced Shared Registration System maintenance periods.

For Updates and Upgrades, Afilias will give each registrar notice prior to 
deploying the Updates and Upgrades into the production environment. The notice 
shall be at least ninety (90) days. Such notice will include an initial thirty 
(30) days' notice before deploying the Update that requires changes to client 
applications or the Upgrade into the Operational Test and Evaluation ("OT&E") 
environment to which all registrars have access. Afilias will maintain the 
Update or Upgrade in the OT&E environment for at least thirty (60) days, to 
allow each registrar the opportunity to modify its client applications and 
complete testing, before implementing the new code in the production 
environment. 

Appendix D, Performance Specifications

Afilias exceeds absolute and relative criteria:
· Adds 21 service metrics (including DNS and Whois)
· Reduces monthly planned outage from 8 hours per month to 4 hours 
· Reduced yearly major outages from two 12-hour periods, to one 8-hour period
· Improve SRS query performance to 400 milliseconds or less, from 3000 
milliseconds)
· Improves write command performance to 800 milliseconds or less (from 5000 
milliseconds)

Note:  Exhibit A (Sampling and Testing) will not fit in this form, but is 
substantially the same as Appendix D in the ORG contract

Registry Performance Specifications

Registry Operator shall use commercially reasonable efforts to provide 
Registry Services for the .NET TLD. The Performance Specifications, defined 
below, provide a means to measure Registry Operator's delivery of Registry 
Services under Subsection 3.3 of the Registry Agreement between Registry 
Operator and ICANN and, when applicable, allow for calculation of the SLA 
Credit payable to Registrar pursuant to Appendix E of the Registry Agreement.

1. Conventions.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in IETF RFC 2119.

2. Definitions. Capitalized terms used herein and not otherwise defined shall 
have the meaning ascribed to them in the Registry Agreement.

2.1 "Core Internet Service Failure" refers to an extraordinary and 
identifiable event beyond the control of Registry Operator affecting the 
Internet services to be measured pursuant to Section 2 of Nameserver 
Availability and Performance Measurements in Exhibit A of this Appendix D. 
Such events include but are not limited to congestion, collapse, partitioning, 
power grid failures, and routing failures.

2.2 "Current Pricing Level" refers to prices charged for Registry Services as 
provided in Appendix G of the Registry Agreement as adjusted pursuant to 
Subsections 3.14.5 and 4.4 of the Registry Agreement.

2.3 "C1" means Category 1, a mission critical service.

2.4 "C2" means Category 2, a mission important service.

2.5 "C3" means Category 3, a mission beneficial service.

2.6 "Degraded Performance" means a service not meeting the performance 
requirement set forth in this document. Round-trip time is used as the basis 
of this metric for all services except nameservice; for nameservice packet 
loss and Round-trip time are used as metrics.

2.7 "Monthly Timeframe" shall mean each single calendar month beginning and 
ending at 0000 Coordinated Universal Time (UTC).

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

2.9 "Not Responding" means a service will be deemed as "Not Responding" in the 
event that the Registry Component Ping (rcPing), as described in Exhibit A 
attached hereto, responds with a negative or degraded service response.

2.10 "Planned Outage" means the periodic pre-announced occurrences during the 
Service Term when the System is 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"). 
The 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 Timeframe. 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 (an "Extended Planned Outage"). An Extended Planned Outage 
represents the total allowed Planned Outages for the month. 

2.11 "Round-trip" means the amount of measured time, usually measured in 
milliseconds, that it takes for a reference query to make a complete trip from 
the sampling agent to the system or process being tested and back again. 

2.12 "Service Availability" means when the System is operational and 
predictably responding in a commercially reasonable manner. By definition, 
neither Planned Outages nor Extended Planned Outages shall be considered or 
included in determining Service Availability.

2.13 "Service Unavailability" means when, as a result of a failure of systems 
(with respect to systems that are within the Registry Operator's control):

2.13.1 With respect to services other than Whois Service and nameservice, 
Registrar is unable to establish a session with the System gateway which shall 
be defined as:

2.13.1.1 successfully complete a TCP session start,

2.13.1.2 successfully complete the SSL authentication handshake, and

2.13.1.3 successfully complete the Extensible Provisioning Protocol ("EPP") 
<login> or RRP login command.

2.13.2 With respect to all services, system monitoring tools register three 
(3) consecutive monitoring failures on any of the components listed in Section 
3-System Services.

2.13.3  Neither Planned Outages nor Extended Planned Outages shall be 
considered or included in determining Service Unavailability.

2.14 "SLA" means the service level agreement between Registry Operator and 
Registrar attached as Appendix E to the Registry Agreement.

2.15 "SLA Credit" means those credits available to the Registrar pursuant to 
the SLA.

2.16 "System" shall mean the list of components listed in Section 3-System 
Services.

2.17 "Transaction" shall mean chargeable Registry Services, which includes 
initial and renewal registrations.

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

2.18.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 Service Unavailability 
experienced by a Registrar through the time when the Service Unavailability 
has been resolved with a final fix or a temporary work around. This will be 
considered Service Unavailability only for those individual Registrars 
impacted by the Service Unavailability;

2.18.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;

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

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

2.19 "Whois Service" means the Registry Operator Whois Services described in 
Appendix O of the Registry Agreement.

2.20 With respect to the use of ".NET nameservers" (Appendix D, Exhibit A) for 
definition of described testing, ".NET nameservers" will refer to those 
hostnames and IP addresses associated for operation of the .NET zone file 
delegation as listed within the root zone, and published by the Internet 
Assigned Numbers Authority.

3. System Services.

The following table lists, by category (C1, C2, or C3), the Registry System 
services for which availability and performance requirements are established. 
Services shall meet availability requirements according to their category, as 
listed in the "Cat." column below. In addition, various services must meet the 
performance requirements listed in the "Perf." column below. These 
availability and performance requirements are the subject of the Service Level 
Agreement (SLA) between Registry Operator and registrars (SLA) or the 
requirements of Subsection 3.3 of the Registry Agreement between Registry 
Operator and ICANN, as noted by the × marks below.


Component/Service                  Cat.    Perf.    SLA    ICANN
-----------------                  ----    ----     ---    -----
     DNS
    *****
AXFR/IXFR Updates                   C3      P5       ×       ×

Resolution of queries within        C1      P4               ×
the .net TLD, each nameserver

     Whois
    ********
Singular query/response             C2      P3               ×

    Billing
   **********
Account balance check/modify        C2               ×

Manual balance adjust               C3               ×

     Admin
    ********
Update Registrar profile            C3               ×       ×

Update Registrar status             C3               ×       ×

   Protocol Interface
  ********************
Add/Renew/Delete/ Update            C2      P1       ×       ×

Transfer                            C2      P6       ×       ×

Check                               C2      P2       ×       ×

4. Service Levels (Availability and Performance)

4.1 Service Level Matrix

-----------------------------------------------------------------------
C1       Total duration of Unplanned Outage Time of C1 class services must not 
exceed 20 seconds per Monthly Timeframe. This represents a Service 
Availability percentage of 99.999%.

          Total duration of Service Unavailability of C1 class services must 
not exceed 15 minutes per Monthly Timeframe. This represents a Service 
Availability percentage of 99.997%.
-----------------------------------------------------------------------
C2       Total duration of Unplanned Outage Time of C2 class services must not 
exceed 240 minutes per monthly Timeframe.  This represents a Service 
Availability percentage of 99.45%.

          Total duration of all Service Unavailability of C2 class services 
must not exceed 240 minutes per Monthly Timeframe.  This represents a Service 
Availability percentage of 99.45%.
-----------------------------------------------------------------------
C3       Total duration of Unplanned Outage Time of C3 class services must not 
exceed 300 minutes per Monthly Timeframe.  This represents a Service 
Availability percentage of 99.31%.

            Total duration of all Service Unavailability of C3 class services 
not to exceed 480 minutes per Monthly Timeframe.  This represents a Service 
Availability percentage of 98.90%.
-----------------------------------------------------------------------
P1        For a single-entity payload, Round-trip time should not exceed 800ms 
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.

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.
-----------------------------------------------------------------------
P3        For a singular query/response, Round-trip time should not exceed 
800ms as measured by the system monitoring tools.

P4        Each nameserver achieves a measured Round-trip time of under 300ms 
and  measured packet loss of under 10%.  See Exhibit A for the measurement 
methodology.
-----------------------------------------------------------------------
P5        See Section 6.3 below.

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


4.2 Service Definition and Service Level Requirement

Service Attribute                     Unit of Measure                        
Commitment 
----------------------             --------------------
                         

DNS service availability              
percentage uptime                 99.93%
from each nameserver,
minimum

DNS service availability              
percentage uptime                         99.999%
from any nameserver
(i.e. at least one
nameserver available), 
minimum

DNS query response rate                 
queries/sec                              minimum 10,000/sec
for all nameservers 
combined,                                                        
minimum absolute

DNS query response rate           
% of measured load                          300%
for each nameserver,                 (busiest hour averaged              (see 
RFC 2780, 
minimum                               over one month) on                      
sec. 2.3)                               most loaded server

Cross-network nameserver                
milliseconds                                 300
round-trip time, maximum

Cross-network nameserver                 
percentage                                <10%
packet loss, maximum

DNS update interval, maximum             
minutes                                     15

SRS service availability,                
 percentage uptime                         99.45%
minimum

SRS processing time,                         
milliseconds                              400ms
maximum for query operations

SRS processing time,                         
milliseconds                              800ms
maximum for write operations

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

SRS service planned outage            
days and hours                    15:00-23:00 UTC 
Saturday                                                                       
                      timeframe

SRS service planned outage                  
days                                       7 days
notification, minimum

SRS service extended planned          
hours/quarter                  1 8 hour extended outage per year 
outage duration, maximum     which constitutes the entire outage 
for                                                                     Time 
can be used                       the month in which it is 
taken                                                                          
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                      
days and hours             15:00-23:00 UTC Saturday
planned outage timeframe

Whois service availability,              
percentage uptime                         99.45%
minimum

Whois query processing time,            
milliseconds                               800 ms
maximum

Whois update interval,                          
minutes                                        15
maximum

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

Whois service planned                     
days and hours                     15:00-23:00 UTC Saturday
outage timeframe

Whois service planned outage                 
days                                       7 days
notification, minimum

5. Measurement.

Except for nameserver performance measurements (P4), Registry Operator will 
monitor the System in accordance with the following principles.

5.1 System/Component Monitoring:

The services defined in this Appendix will be sampled and tested as to 
availability pursuant to the schedule attached hereto as Exhibit A.

5.2 Performance Monitoring:

The services defined in this Appendix will be sampled and tested as to their 
performance pursuant to the schedule attached hereto as Exhibit A. Services 
Not Responding within the Round-trip response times listed in Section 4 - 
Service Levels will be deemed suffering from Degraded Performance for the 
purposes of this Appendix.

Nameserver performance measurements will be conducted by ICANN according to 
Exhibit A.

6. Responsibilities of the Parties.

6.1 Except in the case of nameserver performance measurements, Registry 
Operator will perform monitoring from internally located systems as a means to 
verify that the availability and performance measurements of this document are 
being met.

6.2 The Registry Operator will update the Whois Service on a near real-time 
basis. During normal operation, all registration and information updates sent 
from a Registrar to the Registry are stored in the primary database (database 
A). The information in database A is replicated to a backup database (database 
B) at regular intervals, normally within five (5) minutes. The Whois Service 
uses database B as its source of information. The time lag in the Whois 
information update is determined by the database replication interval.  Whois 
may be serviced by multiple backup replicated databases (database B, C, D 
etc). The Registry Operator will notify Registrars in advance when changes to 
the Whois Service update schedule occur.

6.3 The Registry Operator will initiate the addition, deletion, or other 
modification of DNS zone information to the master DNS server within 5 minutes 
after a Transaction. The Registry Operator will notify Registrar in advance 
when changes to the schedule occur. The Registry Operator will notify 
Registrars regarding any scheduled maintenance and unavailability of the TLD 
nameservers.

6.4 The Registry Operator will use commercially reasonable efforts to restore 
the critical systems of the System within 24 hours in the event of a force 
majeure and restore full system functionality within 48 hours. Outages due to 
a force majeure will not be considered Service Unavailability.

6.5 Beginning no later than 60 days post Commencement-of-Service Date, the 
Registry Operator will publish preliminary weekly system performance and 
availability reports. Registry Operator will use best efforts to finalize 
these reports no later than 30 days after the preliminary reports are provided.

6.6 The Registry Operator will provide Service Availability percentages during 
each Monthly Timeframe as listed in Section 4.1 - Service Level Matrix.

7. Miscellaneous.

7.1 This Appendix is not intended to replace any term or condition in the 
Registry Agreement.

7.2 Dispute Resolution will be handled pursuant to the terms of Subsection 5.9 
of the Registry Agreement.

Appendix E, Service-Level Agreement

Afilias meets the absolute specifications for Appendix E.  In addition, it 
exceeds the specifications Afilias meets and exceeds the absolute and relative 
criterion for Appendix E in the following manner:
· Does not set a maximum credit of 5% of a registrar's monthly volume due to 
Add and Check functionality not meeting SLAs
· Does not set a maximum credit of 10% of registrar's monthly volume for 
exceeding unplanned monthly outages



1. Definitions. Capitalized terms used herein and not otherwise defined shall 
have the definitions ascribed to them in Appendix D, to the Registry Agreement.

2. Credits.

2.1 C1 - If availability of C1 class services does not meet C1 Service Levels 
in any given calendar month, Registry Operator will credit Registrar according 
to this calculation;

       C = (amv/t)*sle

Where:

       C = number of Transactions to be credited to Registrar for the calendar
           month.

    amv  = average month's volume (previous four calendar months total
           Transaction volume/4 months).

       T = time period, number of minutes per month averaged over number of
           days in previous four calendar months (for example, if previous
           four months had 30, 31, 30, 31 days, these time period = (30 + 31 +
           30 + 31)/4 * 24 hours * 60 minutes = 43,920 minutes).

     sle = service level exception.  The number of Unavailable minutes minus
           the number of SLA acceptable Unavailable minutes.

Example:

Registry Operator records 15 minutes of service level exception beyond the 
time periods contemplated by the SLA. The current amv is 30,000 total names 
registered and time period was 43,920 minutes. As such, Registry Operator will 
credit Registrar for 10.25 Transactions at the then Current Pricing Level.

2.2 C2 - If availability of C2 class services does not meet C2 Service Levels 
in any given calendar month, Registry Operator will credit Registrar according 
to this calculation;

         C = (amv/t)*sle * 60% 

Where:

       C = number of Transactions to be credited to Registrar for the calendar 
           month.

     mv  = average month's volume (previous four calendar months total
           Transaction volume/4 months)

       t = time period, number of minutes per month averaged over number of
           days in previous four calendar months (see example in Subsection
           2.1).

     sle = service level exception.  The number of Unavailable minutes minus
           the number of SLA acceptable Unavailable minutes.

     60% = priority adjustment.

Example:

Registry Operator records 15 minutes of service level exception beyond the 
time periods contemplated by the SLA.  The current amv is 30,000 total names 
registered and time period was 43,920 minutes.  s such, Registry Operator will 
credit Registrar for 6.15 Transactions at the then Current Pricing Level.

2.3 C3 - If availability of C3 services does not meet C3 Service Levels in any 
given calendar month, Registry Operator will credit Registrar according to 
this calculation;

          C = (amv/t)*sle * 30% 

2.3 C 3 - If availability of C3 services does not meet C3 Service Levels in 
any given calendar month, Registry Operator will credit Registrar according to 
this calculation;

          C = (amv/t)*sle * 30% 

Where:

       C = number of Transactions to be credited to Registrar for the calendar 
           month.

    amv  = average month's volume (previous four calendar months total
           Transaction volume/4 months)

      t  = time period, number of minutes per month averaged over number of
           days in previous four calendar months (see example in Subsection
           2.1).

    sle  = service level exception.  The number of Unavailable minutes minus
           the number of  SLA acceptable Unavailable minutes.

    30%  = priority adjustment.

Example:

Registry Operator records 15 minutes of service level exception beyond the 
time periods contemplated by the SLA. The current amv is 30,000 total names 
registered and the time period was 43,920 minutes. As such, Registry Operator 
will credit Registrar for 3.07 Transactions at the then Current Pricing Level.

2.4 Degraded Performance - If the performance of the transactive systems 
(OpenXRS API, Whois) does not meet the performance expectations outlined in 
Service Levels over the calendar month in question, Registry Operator will 
credit Registrar according to this calculation;

           C = (amv/t)*sle * 7.5% 

Where:

       C  = number of Transactions to be credited to Registrar for the
            calendar month.

     amv  = average month's volume (previous four calendar months total 
            Transaction volume/4months)

       t  = time period, number of minutes per month averaged over number of 
            days in previous four calendar months (see example in Subsection 
            2.1).

     sle  = service level exception.  The number of Degraded Performance 
            minutes.

     7.5% = priority adjustment.

Example:

Registry Operator records 15 minutes of service level exception beyond the 
time periods contemplated by the SLA. The current amv is 30,000 total names 
registered and time period was 43,920 minutes. As such, Registry Operator will 
credit Registrar for 0.77 Transactions at the then Current Pricing Level.

2.5 Receipt of Credits - In order for Registrars to claim credits, the 
following procedure must be followed:

2.5.1 Issue a Request for SLA Credits.

The claiming Registrar must make a request for credits to Registry Operator 
within 7 days of the SLA violation claiming that it experienced downtime or 
degraded performance in excess of what is outlined in Appendix D.

2.5.2 Provide documentation to indicate SLA violation.

A Registrar may provide documentation in the form of either:

2.5.2.1 Registrar initiated notification(s) to the Registry Operator of a down 
time that exceeded SLA limits, including the trouble ticket number issued by 
the Registry Operator. The closing ticket(s) should be included as well in 
order to determine the total downtime (unless the closing ticket includes 
this); or

2.5.2.2 Notification from the Registry Operator (with trouble ticket number 
attached) of down time or degraded performance. The closing ticket(s) should 
be included as well in order to determine the total downtime (unless the 
closing ticket includes this).

2.5.2.3 Confirmation of SLA violation:

Upon the request of the Registry Operator, the claiming Registrar must provide 
reasonably available server and/or application logs demonstrating a violation 
of the SLA limits. The Registrar is expected to demonstrate response times 
from point of entry into the registry server complex to point of exit from the 
registry server complex. This will exclude any time taken by establishing a 
TCP connection, the SSL handshake and EPP/RRP logon to the registry.

2.5.3 Justification of Volume.

In order to calculate credits, the Registrar should include volume figures for 
the past four (4) calendar months, and a certification that these numbers 
accurately reflect the LEAST registration activity that would be covered 
during the affected SLA outage.

2.5.4 Receipt of Credit.

When the above steps have been completed to the Registry Operator's 
satisfaction, the Registry Operator shall provide notification of the number 
of credits that will be entered in the Registrar's account balance and that 
can be used immediately toward registrations in the Registry.  Under no 
circumstances shall credits be applied when the availability problems are 
caused by network providers and/or the systems of individual Registrars (See 
Section 2.13, Appendix D)

3. Responsibilities of the Parties.

3.1 The affected ICANN-Accredited Registrar will assist Registry Operator by 
reporting each occurrence of alleged Service Unavailability to Registry 
Operator customer service help desk in the manner required by Registry 
Operator (i.e., e-mail, fax or telephone) in order for an occurrence to be 
treated as Service Unavailability for purposes of this SLA. Registry Operator 
will treat all system performance problems in order of decreasing severity and 
fix them within a commercially reasonable period of time. Incidents flagged by 
the measurement system will also qualify as ticketed events and will be 
classed as Unavailability.

3.2 Registry Operator will perform monitoring from internally located systems 
as a means to verify that the conditions of the SLA are being met(see Exhibit 
A Appendix D).

3.2.1 Registry Operator will perform external monitoring from at least two 
external locations to verify that the conditions of the SLA are being met (see 
Exhibit A Appendix D).

3.2.2 Registry Operator will allow external monitoring of the SRS via an 
acceptable means to both parties.

3.3 The SLA will be reconciled on a quarterly basis.

3.4 The Registrar will have the option to choose which of the credit 
calculations described in Section 2 of the SLA will apply where service level 
credit overlaps occur. There can be several types of credits over the same 
calendar month, but the Registrar can only claim one type of refund for each 
event.

3.5 Registry Operator will not attempt to discern what discount levels were in 
effect at the specific time of a service level exception, but rather use the 
discount level in effect at the time the credits issue. All service level 
credits will be paid out using the appropriate discounts and rate levels 
reflected by the then current rate schedule.
3.6 The Registrar may, under reasonable terms and conditions, audit the 
reconciliation records for the purposes of verifying service level 
performance. The frequency of these audits will be no more than once every six-
month period during the term of the Registry-Registrar Agreement between 
Registry Operator and the Registrar.

3.7 Registry Operator's obligations under this SLA are waived during the first 
120 days after the Commencement-of-Service Date.

3.8 Incident trouble tickets must be opened within a commercially reasonable 
period of time.

3.9 In the event that Service Unavailability affects all Registrars, the 
Registry Operator is responsible for opening a blanket trouble ticket and 
immediately notifying all Registrars of the trouble ticket number and details.

3.10 Both Registrar and the Registry Operator agree to use reasonable 
commercial good faith efforts to establish the cause of any alleged Service 
Unavailability. If it is mutually determined to be a Registry Operator 
problem, the issue will become part of the Unplanned Outage Time.

3.11 Registrars must inform the Registry Operator any time their estimated 
volume of transactions (excluding check domain commands), will exceed their 
previous calendar month's volume by more than 25%. In the event that a 
Registrar fails to inform Registry Operator of a forecasted increase of volume 
of transactions of 25% or more and the Registrar's volume increases 25% or 
more over the previous month, and should the total volume of transactions 
added by the Registry Operator for all Registrars for that month exceed the 
Registry Operator's actual volume of the previous month's transactions by more 
than 20%, then the Registrar(s) failing to give such notice will not be 
eligible for any SLA Credits in that Monthly Timeframe. Registrars shall 
provide their forecasts at least 30 days prior to the first day of the next 
calendar month. In addition, the Registry Operator agrees to provide monthly 
transaction summary reports starting no later than 60 days after the 
Commencement-of-Service Date.

3.12 The Registry Operator will notify Registrar of Planned Outages outside 
the Planned Outage Period at least 7 days in advance of such Planned Outage. 
In addition, Registry Operator will use reasonable commercial good faith 
efforts to maintain an accurate 30 day advance schedule of possible upcoming 
Planned Outages.

3.13 The Registry Operator will update the Whois Service on a near real-time 
basis. During normal operation, all registration and information updates sent 
from a Registrar to the Registry are stored in the primary database (database 
A). The information in database A is replicated to a backup database (database 
B) at regular intervals, normally within five (5) minutes. The Whois Service 
uses database B as its source of information. The time lag in the Whois 
information update is determined by the database replication interval. The 
Registry Operator will notify Registrars in advance when changes to the Whois 
Service update schedule occur.

3.14 The Registry Operator will initiate the addition, deletion or other 
modification of DNS zone information to the master DNS server within 5 minutes 
after a Transaction. The Registry Operator will notify Registrar in advance 
when changes to the schedule occur. The Registry Operator will notify 
Registrars regarding any scheduled maintenance and unavailability of the TLD 
nameservers.

3.15 The Registry Operator will use commercially reasonable efforts to restore 
the critical systems of the System within 24 hours in the event of a force 
majeure and restore full system functionality within 48 hours. Outages due to 
a force majeure will not be considered Service Unavailability.

3.16 Beginning no later than 60 days after the Commencement-of-Service Date, 
the Registry Operator will publish preliminary weekly system performance and 
availability reports. Registry Operator will use best efforts to finalize 
these reports no later than 30 days after the preliminary reports are provided.

3.17 The Registry Operator will provide Service Availability percentages 
during each Monthly Timeframe as listed in Section 4.1 - Service Level Matrix 
of Appendix D.

4. Miscellaneous.

4.1 This Appendix is not intended to replace any term or condition in the 
Registry-Registrar Agreement.

4.2 Dispute Resolution will be handled pursuant to the arbitration provisions 
of the Registry-Registrar Agreement.

Appendix O*, Whois Specification – Public Whois

Afilias meets the absolute specifications for Appendix O.  In addition, it 
exceeds the specifications Afilias meets and exceeds the absolute and relative 
criterion for Appendix O (as based on the .ORG registry agreement) in the 
following manner:
·	Support for IDNs including the language tag, as well as the Punycode 
representation of the IDN name in addition to Unicode Hex and Unicode HTLM 
formats
·	Enhanced support for privacy protection using the DCP element 
contained in EPP 1.0
·	Emulates the thin Whois response as required, without need of dummy 
contacts
·	Enables registrars operating under thin EPP the optional ability to 
display associated contacts

NOTE: As registry services provider to the Public Interest Registry for 
the .ORG domain, Afilias continually meets the requirements of the .ORG Whois 
specification under ICANN's supervision today.

Overview
The Whois service is compliant with RFC 954. The primary Whois services 
consist of:

·	Port 43 Whois services (thick registry)

·	Port 43 Whois services (thin registry)

·	Web-based Whois services (thin and thick registry)

Afilias reserves the right to offer other, enhanced Whois services, some of 
which are described in this document.

Afilias Whois service is the authoritative Whois service for all second-level 
Internet domain names registered in the .NET top-level domain and for all 
hosts registered using these names. This service is available to anyone. It is 
accessible via port 43 and through the Afilias wWeb site. 

Afilias will initially operate the .NET registry Whois in a manner consistent 
with both a "thin" registry and a "thick" registry. This is to facilitate 
legacy RRP domains, thin EPP domains as well as new thick EPP registrations.

Upon conclusion of the Transition Process (as detailed in Section 8), the .NET 
Whois service will provide a central, openly accessible system for information 
regarding a particular second level domain name registration in the .NET TLD. 

The Registry Whois system has been designed for robustness, availability, and 
performance. Provisions for detection of abusive usage, like excessive numbers 
of queries from one source, have been taken into account, and other 
countermeasures against abuse will be activated if necessary.

Afilias will initially provide at least two operational Whois databases 
running simultaneously at two different locations. The Whois databases will be 
situated on a high-availability system at both locations.

The Whois will be updated in near real-time by a specialized application. For 
Whois servers at the main data center, the update application will only be 
accessible from the internal network. External Whois sites, including the 
Disaster Recovery site Whois server, will utilize a secure communication 
channel for updates. 

The Whois servers shall provide results in ASCII for standard and IDN .NET 
domains.

The status values reported will be those stated in 
http://www.ietf.org/rfc/rfc3731.txt except that domains in PendingDelete 
status will be reported as either PENDING-DELETE (Restorable) or PENDING-
DELETE (Scheduled for release) as appropriate.

This Appendix is subject to change by agreement of Afilias and ICANN during 
the design process as well as during the IETF standards process. 
1. Port 43 Whois service (thick registry)

1. The format of responses will follow a semi-free text format outline below, 
preceded by a mandatory disclaimer specifying the rights of Afilias, and of 
the user querying the database.

2. Each data object shall be represented as a set of key/value pairs, with 
lines beginning with keys, followed by the colon as a delimiter, followed by 
the value.

3. All Whois data will be in the ASCII character set, which has encoding 
compatible with UTF-8 for easy transition to including internationalized data, 
and as per the IETF's recommendations on i18n in Internet protocols. For 
fields where more than one value exists, multiple key/value pairs with the 
same key shall be allowed (for example to list multiple name servers). The 
first key/value pair after a blank line should be considered the start of a 
new record, and should be considered as identifying that record, and is used 
to group data, such as hostnames and IP addresses, or a domain name and 
registrant information, together.

4. All record and key types shall be specified in a publicly available 
description on the Afilias website. The key names and record types should 
change as infrequently as possible, and only upon the agreement of ICANN and 
Afilias.

2. Port 43 Whois service (thin registry)

1. The format of responses for thin registry output will be similar to the 
guidelines listed above for thick-registry Whois, however it may include 
optional contact information. The optional contact information will only be 
provided in a "thin" EPP response. 

2. The Whois response will indicate that the Whois information for this domain 
is not authoritative and indicate an URL to the Whois server of the registrar 
responsible for providing the contact Whois information. 

3. Web-based Whois service (thick and thin registry)

Afilias will make available a Whois interface on its Web site which can also 
be linked to by each ICANN-Accredited Registrar that is a party to a Registry-
Registrar Agreement. The information available in the Whois database will be 
returned as a results page on the Web site.

The only purpose of this web interface is to provide a user-friendly interface 
for Whois queries. It does not provide any additional features beyond what is 
described in the port 43 section of this appendix.

4. Minimum Data Update Frequency

The update frequency of Whois data is specified in Section 4.2 of Appendix D.

5. Protocols Through Which Access is Provided 

Access to the Whois data is provided through a subset of the Whois protocol, 
supporting exact queries for domain names, contact IDs, registrar name, 
nameserver, hostname and nameserver ip-address. Bulk access to the Whois data 
will be made available as specified in Appendix P and Appendix Q.

6. Security

General security measures such as password aging policy, firewalls, Intrusion 
Detection Systems (IDS) and network traffic monitoring systems will be 
provided for the Whois services, as further described in the Security section 
of Appendix C.

The Whois output in the thick registry model, which will be the only supported 
model at the completion of the Transition Plan, will be returned with all 
respective key/value pairs, which will eliminate the need for registrars to 
store additional information in their own local database. The proposed 
capability will also ensure that end users will view the same information no 
matter which registrar they use to retrieve Whois data. 

7. Query and Output for Reports Delivered by Web Page and Port 43

7.1 Whois Queries

For all Whois queries, the client provides a character string for which 
information is desired and optionally, the object type and interpretation 
control parameters to limit the search. Several interpretation controls are 
defined below to limit searches. If the object type and interpretation control 
parameters are not specified, Whois searches for the character string in the 
Name fields of the Domain object. Queries can be made as either an "exact 
search" or as a "partial search", both of which are insensitive to the case of 
the input string.

By default, if multiple matches are found for a query, then a summary of all 
the matching results is presented. A second query is required to retrieve the 
specific details of one of the matching records.

If only a single match is found, then full details will be provided. Full 
detail consists of the data in the matching object as well as the data in any 
associated objects. Additional information and samples of the various types of 
Whois result records are available in the section below.

7.2 Query Controls

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

Object Type Control

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

DOomain:	Search only domain objects. The input string is searched in 
the Name field.
Host:	Search only name server objects. The input string is searched in the 
Name field and the IP Address field.
Contact:	Search only contact objects. The input string is searched in 
the ID field.
Registrar:	Search 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 is searched.

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 applies 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
'%':	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.

7.3 Query Examples

7.3.1 Domain Record

A Whois query that results in domain information will return the following 
example 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.

Thick Registry Whois Outputs

The following output is an example of a Whois response for a domain that is 
stored in the registry as an EPP-based domain however it is a thick IDN domain 
name.

Input:
XN--EXAMPLEDOMAIN-VOB.NET
-or-
domain XN--EXAMPLEDOMAIN-VOB.NET
Domain ID:D5353345-LRNT
Domain Name:XN--EXAMPLEDOMAIN-VOB.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

IDN Script:de
Unicode Hex:U+00FC U+0065 U+0078 U+0061 U+006D U+0070 U+006C U+0065 U+0064 
U+006F U+006D U+0061 U+0069 U+006E
Unicode HTML:&#252;exampledomain

The following output is an example of a Whois response for a domain that is 
stored in the registry as an EPP-based domain however certain information is 
not disclosed because of DCP considerations. 

Input:

WHOISDOMAIN.NET
-or-
domain WHOISDOMAIN.NET

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:DATA PROTECTION ENABLED
Registrant City:DATA PROTECTION ENABLED
Registrant State/Province:DATA PROTECTION ENABLED
Registrant Postal Code:DATA PROTECTION ENABLED
Registrant Country:DATA PROTECTION ENABLED
Registrant Phone:DATA PROTECTION ENABLED
Registrant Email:DATA PROTECTION ENABLED
Admin ID:5372809-ERL
Admin Name:EXAMPLE REGISTRAR ADMINISTRATIVE 
Admin Organization:EXAMPLE REGISTRANT ORGANIZATION
Admin Street1:DATA PROTECTION ENABLED
Admin City:DATA PROTECTION ENABLED
Admin State/Province:DATA PROTECTION ENABLED
Admin Postal Code:DATA PROTECTION ENABLED
Admin Country:DATA PROTECTION ENABLED
Admin Phone:DATA PROTECTION ENABLED
Admin Email:DATA PROTECTION ENABLED
Billing ID:5372810-ERL
Billing Name:EXAMPLE REGISTRAR BILLING 
Billing Organization:EXAMPLE REGISTRANT ORGANIZATION
Billing Street1:DATA PROTECTION ENABLED
Billing City:DATA PROTECTION ENABLED
Billing State/Province:DATA PROTECTION ENABLED
Billing Postal Code:DATA PROTECTION ENABLED
Billing Country:DATA PROTECTION ENABLED
Billing Phone:DATA PROTECTION ENABLED
Billing Email:DATA PROTECTION ENABLED
Tech ID:5372811-ERL
Tech Name:EXAMPLE REGISTRAR TECHNICAL 
Tech Organization:EXAMPLE REGISTRAR LLC
Tech Street1:DATA PROTECTION ENABLED
Tech City:DATA PROTECTION ENABLED
Tech State/Province:DATA PROTECTION ENABLED
Tech Postal Code:DATA PROTECTION ENABLED
Tech Country:DATA PROTECTION ENABLED
Tech Phone:DATA PROTECTION ENABLED
Tech Email:DATA PROTECTION ENABLED
Name Server:NS01.EXAMPLEREGISTRAR.NET
Name Server:NS02.EXAMPLEREGISTRAR.NET

Thin Registry Outputs

The following output is an example of a response from the Whois server for a 
domain that is RRP-based and, thus, emulates a thin registry response. In this 
way the response will be inclusive of a thin registry Whois server but will 
contain extra information to indicate that the contact information is not 
authoritative. 

Input:

WHOISDOMAIN.NET
-or-
domain WHOISDOMAIN.NET

Output:

Domain ID:D5353343-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
Authoritative Whois Referral Url:WHOIS.EXAMPLEREGISTRAR.NET
Name Server:NS01.EXAMPLEREGISTRAR.NET
Name Server:NS02.EXAMPLEREGISTRAR.NET

The following output is an example of a response from the Whois server for a 
domain that is EPP-based however it emulates a thin registry response. In this 
way the response will reflect a thin registry Whois server but will indicate 
that the information is not authoritative. The thin EPP response may also 
contain one or more contacts that have been added by the registrar during the 
process of bringing the domain into compliance with a "thick" registry model.

Input:

WHOISDOMAIN.NET

-or-

domain WHOISDOMAIN.NET
	
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
Authoritative Whois Referral Url:WHOIS.EXAMPLEREGISTRAR.NET
Tech ID:5372807-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

7.3.2 Nameserver Record

A Whois query that results in Nameserver information will return the 
following. This set of information is referred to as the Nameserver Record. 

Input:
host ns01.exampleregistrar.net
-or-
host 192.168.0.100 
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

7.3.3 Contact Record

A Whois query that results in contact information will return the following. 
This set of information is referred to as the Contact Record.

Input:

contact CNT-2222 

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
7.3.4 Registrar Record

A Whois query that results in Registrar information will return the following. 
This set of information is referred to as the Registrar Record. 

Input:

Whois registrar EXAMPLE REGISTRAR LLC

Output:

Registrar ID:FDRD-DRE
Registrar GUID:99
Registrar Organization:EXAMPLE REGISTRAR LLC
Street1:123 EXAMPLE STREET
City:ANYTOWN
Postal Code:A1A1A1
Country:EX
Phone:+1.4443331234
Email:EMAIL@EXAMPLE.COM
Created On:01-Jan-2005 16:50:58 UTC
Last Updated On:10-Jan-2005 15:34:36 UTC
Status:OK

8. Extended Whois (xWhois)
Afilias reserves the right to develop and implement an extended Whois (xWhois) 
service. This subscription-based service would be intended to provide:

An interface to the Whois database that will permit interested third parties 
to conduct enhanced Whois searches using Boolean and character string 
technologies.

Enhanced search functions will include the ability to identify

Registered domain names that incorporate a certain character string, or

All domain names registered by a certain registrant.

Support for a new lookup key, "list_registrars" which will generate a list of 
all accredited registrars pursuant to a query.

This service would be intentionally separated from the standard Whois service 
due to the high transaction loads that will be placed on the standard service 
due to the thick-registry model, and the requirements to meet service level 
agreements. While the RFC954-conformant Whois service will be updated in near 
real-time, there is no need for the enhanced service to have this requirement 
due to the nature of its usage The maximum update latency of the enhanced 
service would be 48 hours after updates to the core registry database are 
received.

9. Extensible-Field Capability

Afilias reserves the right to introduce the ability for registrars to use XRP, 
to add customized fields to a record in the registry database. These fields 
would appear in an "additional information" section of the Whois data. The 
maximum number of custom fields allowed per record is yet to be determined.

Appendix P*, Whois Data Specification – Independent Whois Provider

Afilias meets the absolute specifications for Appendix P.  In addition, it 
exceeds the specifications Afilias meets and exceeds the absolute and relative 
criterion for Appendix P in the same manner as it does for the Whois 
requirements in Appendix O. NOTE: As registry services provider to the Public 
Interest Registry for the .ORG domain, Afilias continually meets the 
requirements of the .ORG Whois specification under ICANN's supervision today.

Afilias will provide bulk access to up-to-date data concerning domain name and 
nameserver registrations maintained by Afilias in connection with the .net TLD 
on a daily schedule.  This is only for purposes of providing free public query-
based access to up-to-date data concerning domain name and nameserver 
registrations in multiple TLDs, to a party designated from time to time in 
writing by ICANN (the "Designated Recipient").

The procedures for providing access, and the specification of the content and 
format of this data, will be as stated below, until changed according to the 
Registry Agreement. 

This Appendix is subject to change by agreement of Afilias and ICANN during 
the design process as well as during the IETF standards process.  The target 
architecture and functionality specified in this Appendix conforms to RFC 3730 
and related object mappings(RFC 3731, 3732, 3733, 3734, 3735).  Afilias also 
agrees to work with ICANN to implement changes to this Appendix in order to 
provide services based on RFC 3981 and RFC 3982.

A. Procedures for Providing Access

Afilias will prepare (i) full data sets for one day of each week (the day to 
be designated by ICANN) and (ii) incremental data sets for all seven days of 
each week.  Full and incremental data sets shall be up-to-date and coherent as 
of 12:00 UTC on the day to which they relate.  Until a different day is 
designated by ICANN, the full data sets will be prepared for Sundays.  (Note 
that on the ICANN-designated day both an incremental and a full data set are 
prepared.)

1. Preparation of Files Containing Data Sets. Each full and incremental data 
set consists of an XML document meeting the content and format requirements of 
Parts B and C of this document.  Once the XML document is generated, the 
following preparation steps will be performed:

a. The XML document will be placed in a file names according to the following 
convention:

For full data sets: "wfYYMMDD" where "YYMMDD" is replaced with the date 
(YY=last two digits of year; MM=number of month; DD=day; in all cases a single-
digit number should be left-padded with a zero).

For incremental data sets: "wiYYMMDD" where "YYMMDD" follows the same format.

b. The Registry Operator may optionally split the document using the Unix 
SPLIT command (or equivalent) to produce files no less than 1GB each (except 
the final file).  If files are split, a .MD5 file (produced with MD5SUM or 
equivalent) must be included with the escrow files to isolate errors in case 
of transfer fault.

c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or 
above, with a key of DH/DSS type and 2048/1024-byte length.  (Note that PGP 
compresses the escrow file in addition to encrypting it.)  The Data 
Recipient's public key will be used for the encryption and the Registry 
Operator's private key will be used for the signature.  Public keys will be 
exchanged between the Registry Operator and the Designated Recipient by 
physical delivery of floppy diskettes or other agreed means.

2. Transmission of Full Data Sets. Once prepared, full data sets will be 
provided either by the procedures for incremental data sets described in item A
(3) below or, at the option of either Afilias or the Designated Recipient, by 
writing the full data set to DAT tape (or other media mutually agreed by 
Afilias and the Designated Recipient) and sending it to the Designated 
Recipient by expedited delivery service (such as FedEx or DHL).  If sent by 
expedited delivery service, the full data set will be scheduled for arrival no 
later than the second calendar day following the day to which the full backup 
relates.

3. Transmission of Incremental Data Sets.  To permit the transmission of 
incremental data sets, Afilias will make them available for download by the 
Designated Recipient by Internet file transfer protocol.  Incremental data 
sets will be made available for download no later than 20:00 UTC on the day to 
which they relate.

B. Content

The data sets (whether full or incremental) will consist of four types of 
objects:

1. Registrar objects. The first type of object corresponds to a single 
registrar.  It includes the following data:

Registrar ID (conforming to the IANA registrar-ids registry)
Contact ID of Registrar
Registrar Administrative Contacts
Registrar Technical Contacts
Registrar Billing Contacts
Registrar URL
Registrar Creation Date
Registrar Last Updated Date

2. Contact objects.  A second type of object is the contact object, which 
corresponds to a single contact (whether registrant, administrative, technical 
or billing contact).  The contact object includes the following data:

Contact ID
Contact Name
Contact Organization
Contact Address, City, State/Province, Country
Contact Postal Code
Contact Phone, Fax, E-mail

3. Nameserver objects.  A third type of object is the nameserver object, which 
corresponds to a single registered nameserver.  The nameserver object includes 
the following data:

Name Server ID
Name Server Host Name
Name Server IP Addresses if applicable 
Current Registrar
Name Server Creation Date
Name Server Last Updated Date

4. Domain objects.  The final type of object is the domain object, which 
corresponds to a single Registered Name. Each domain object includes the 
following data:

Domain ID
Domain Name
Sponsoring Registrar
Domain Status
All contact information (including all details) with at least one each of:
  *  Registrant
  *  Administrative
  *  Technical
  *  Billing
All nameservers associated with this domain
Domain Registration Date
Domain Expiration Date
Domain Last Updated Date

5. Objects Contained in Full and Incremental Data Sets.  Full data sets 
include one domain object for each Registered Name within the Registry TLD; 
and nameserver, contact, and registrar objects for each nameserver, contact, 
and registrar referred to in any domain object.  Incremental data sets consist 
of (a) those of the objects constituting a full data set that have been added 
or updated since the last incremental data set and (b) notations of deletion 
of any objects since the last incremental data set.

C. Format

Full and incremental data sets will be XML version 1.0, UTF-8 encoded 
documents conforming to the following document type definition:

<!DOCTYPE whois-data [

<!ELEMENT whois-data (domain*, del-domain*, nameserver*, del-nameserver*, 
contact*, del-contact*, registrar*, del-registrar*) >

<!-- del-domain, del-nameserver, del-contact, and del-registrar child elements 
are only meaningful where the attribute type="Full" | "Incremental" -->

<!ATTLIST whois-data 
   tld NMTOKEN #FIXED "net"
   date CDATA #REQUIRED
   type (Full | Incremental)
   version CDATA #FIXED "1.0" >

<!ELEMENT domain (name)>
<!ATTLIST domain 
   dom-id ID #REQUIRED 
   registrar-id IDREF #REQUIRED 
   registrant-id IDREF #REQUIRED
   admin-id IDREF #REQUIRED
   tech-id IDREF #REQUIRED
   billing-id IDREF #REQUIRED
   nameserver-id IDREFS #IMPLIED
   status (Ok | serverHOLD | serverTransferProhibited | serverRenewProhibited 
| serverDeleteProhibited | serverUpdateProhibited | clientTransferProhibited | 
clientRenewProhibited | clientDeleteProhibited | clientUpdateProhibited | 
pendingTransfer | pendingDelete) 
   cre-date CDATA #REQUIRED
   exp-date CDATA #REQUIRED
   upd-date CDATA #REQUIRED>
<!ELEMENT del-domain EMPTY >

<!-the presence of this element in an incremental data set indicates that the 
domain has been deleted since the last incremental data set -->
<!ATTLIST del-domain
   dom-id ID #REQUIRED >

<!ELEMENT nameserver (name, ip, ip+) >
<!ATTLIST nameserver
   nameserver-id ID #REQUIRED
   registrar-id IDREF #REQUIRED 
   cre-date CDATA #REQUIRED
   upd-date CDATA #REQUIRED>
<!ELEMENT del-nameserver EMPTY >

<!-the presence of this element in an incremental data set indicates that the 
nameserver has been deleted since the last incremental data set -->
<!ATTLIST del-nameserver
   nameserver-id ID #REQUIRED >

<!ELEMENT contact (name, org, address, post-code, country, phone, fax-, e-
mail) >
<!ATTLIST contact 
   contact-id ID #REQUIRED
   registrar-id IDREF #REQUIRED 
   cre-date CDATA #REQUIRED
   upd-date CDATA #REQUIRED>
<!ELEMENT del-contact EMPTY >

<!-the presence of this element in an incremental data set indicates that the 
contact has been deleted since the last incremental data set -->

<!ATTLIST del-contact
   contact-id ID #REQUIRED >

<!ELEMENT registrar (reg-status, url) >
<!ATTLIST registrar 
   registrar-id ID #REQUIRED 
   contact-id IDREF #REQUIRED
   admin-id IDREFS #REQUIRED
   tech-id IDREFS #REQUIRED
   billing-id IDREFS #REQUIRED
   cre-date CDATA #REQUIRED
   upd-date CDATA #REQUIRED>
<!ELEMENT del-registrar EMPTY >

<!-the presence of this element in an incremental data set indicates that the 
registrar has been deleted since the last incremental data set -->

<!ATTLIST del-registrar
   registrar-id ID #REQUIRED >

<!ELEMENT name (#PCDATA) >
<!ELEMENT ip (#PCDATA) >
<!ELEMENT org (#PCDATA) >
<!ELEMENT address (#PCDATA) >
<!ELEMENT post-code (#PCDATA) >

<!ELEMENT country EMPTY >
<!ATTLIST country cc (AF | AL | DZ | AS | AD | AO | AI | AQ | AG | AR | AM | 
AW | AU | AT | AZ | BS | BH | BD | BB | BY | BE | BZ | BJ | BM | BT | BO | BA 
| BW | BV | BR | IO | BN | BG | BF | BI | KH | CM | CA | CV | KY | CF | TD | 
CL | CN | CX | CC | CO | KM | CG | CD | CK | CR | CI | HR | CU | CY | CZ | DK 
| DJ | DM | DO | AX | EC | EG | SV | GQ | ER | EE | ET | FK | FO | FJ | FI | 
FR | GF | PF | TF | GA | GM | GE | DE | GH | GI | GR | GL | GD | GP | GU | GT 
| GN | GW | GY | HT | HM | VA | HN | HK | HU | IS | IN | ID | IR | IQ | IE | 
IL | IT | JM | JP | JO | KZ | KE | KI | KP | KR | KW | KG | LA | LV | LB | LS 
| LR | LY | LI | LT | LU | MO | MK | MG | MW | MY | MV | ML | MT | MH | MQ | 
MR | MU | YT | MX | FM | MD | MC | MN | MS | MA | MZ | MM | NA | NR | NP | NL 
| AN | NC | NZ | NI | NE | NG | NU | NF | MP | NO | OM | PK | PW | PS | PA | 
PG | PY | PE | PH | PN | PL | PT | PR | QA | RE | RO | RU | RW | SH | KN | LC 
| PM | VC | WS | SM | ST | SA | SN | SC | SL | SG | SK | SI | SB | SO | ZA | 
GS | ES | LK | SD | SR | SJ | SZ | SE | CH | SY | TW | TJ | TZ | TH | TG | TK 
| TO | TT | TN | TR | TM | TC | TV | UG | UA | AE | GB | US | UM | UY | UZ | 
VU | VE | VN | VG | VI | WF | EH | YE | CS | ZM | ZW | TL) >
<!ELEMENT phone (#PCDATA) >
<!ELEMENT fax (#PCDATA) >
<!ELEMENT e-mail (#PCDATA) >
<!ELEMENT reg-status (#PCDATA) >
<!ELEMENT url (#PCDATA) >
<!ELEMENT date (#PCDATA) >
<!ELEMENT number (#PCDATA) >
]>

Appendix Q*, Whois Data Specification – ICANN

Afilias meets all absolute criterion for Appendix Q. NOTE: As registry 
services provider to the Public Interest Registry for the .ORG domain, Afilias 
continually meets the requirements of the .ORG Whois specification under 
ICANN's supervision today. There is no substantive reason to exceed this 
specification and therefore relative criterion should not apply in this case. 
Afilias will provide bulk access by ICANN to up-to-date data concerning domain 
name and nameserver registrations maintained by Afilias in connection with 
the .net TLD on a daily schedule, only for purposes of verifying and ensuring 
the operational stability of Registry Services, the DNS, and the Internet.

The procedures for providing access, and the specification of the content and 
format of this data, will be as stated below, until changed according to the 
Registry Agreement.  This Appendix is subject to change by agreement of 
Afilias and ICANN during the design process as well as during the IETF 
standards process.  The target architecture and functionality specified in 
this Appendix conforms to RFC 3730 and related object mappings(RFC 3731, 3732, 
3733, 3734, 3735).  Afilias also agrees to work with ICANN to implement 
changes to this Appendix in order to provide services based on RFC 3981 and 
RFC 3982.

A. Procedures for Providing Access

Afilias will prepare a full data set once each week (the day to be designated 
by ICANN).  Full data sets shall be up-to-date and coherent as of 1200 UTC on 
the day to which they relate.  Until a different day is designated by ICANN, 
the full data sets will be prepared for Sundays.

1. Preparation of Files Containing Data Sets. Each full data set consists of 
an XML document meeting the content and format requirements of Parts B and C 
of this document.  Once the XML document is generated, the following 
preparation steps will be performed:

a. The XML document will be placed in a file named according to the following 
convention: "wfYYMMDD" where "YYMMDD" is replaced with the date (YY=last two 
digits of year; MM=number of month; DD=day; in all cases a single-digit number 
should be left-padded with a zero).

b. Afilias may optionally split the document using the Unix SPLIT command (or 
equivalent) to produce files no less than 1GB each (except the final file).  
If files are split, an MD5 file (produced with MD5SUM or equivalent) must be 
included with the resulting files to isolate errors.  Afilias may optionally 
compress the document using the Unix GZIP command (or equivalent) to reduce 
the filesize.

c. The file(s) will then be encrypted and signed using PGP, version 6.5.1 or 
above, with a key of DH/DSS type and 2048/1024-byte length.  (Note that PGP 
compresses the escrow file in addition to encrypting it.)  An ICANN public key 
will be used for the encryption and the Registry Operator's private key will 
be used for the signature.  Public keys will be exchanged between Afilias and 
ICANN by e-mail, physical delivery of floppy diskettes, or other agreed means.

2. Transmission of Full Data Sets. Once prepared, full data sets will be 
provided according to paragraph a below or, at Afilias' option, according to 
paragraph b below:

a. Afilias will make full data sets available for download by ICANN by secure 
and authenticated methods, including, but not limited to, Secure FTP (sftp) or 
HTTPS protocols.  The data sets will be made available for download beginning 
no later than 2000 UTC on the day to which they relate and until the next full 
data set becomes available for download.

b. Afilias will write the full data set to DAT (DDS-4) tape (or other media 
specified by ICANN) and send it to ICANN by expedited delivery service (such 
as FedEx or DHL).  The full data set will be scheduled for arrival at ICANN no 
later than the fourth calendar day following the day to which the data set 
relates.

B. Content

The full data sets will consist of the objects and contents described for full 
data sets in Part B of Appendix P.

C. Format

Full data sets will be XML version 1.0, UTF-8 encoded documents conforming to 
the schema/document type declaration set forth in Part C of Appendix P.

Appendix R, Data Escrow Specification

Afilias meets the absolute specifications for Appendix R.  In addition, it 
exceeds the specifications Afilias meets and exceeds the absolute and relative 
criterion for Appendix R in the following manner: 

· Afilias enables ICANN to participate in the verification process of the 
escrowed data dumps 

· Afilias offers to provide ICANN not only with the required XML report 
containing the registry data, but also with a true native format registry 
database backup

This Appendix R to the Registry Agreement consists of four of the five 
exhibits to the Service Level Agreement that constitutes Appendix S to the 
Registry Agreement:

Exhibit A-Schedule for Escrow Deposits

Exhibit B-Escrow Deposit Format Specification

Exhibit C-Escrow Transfer Process

Exhibit D-Escrow Verification Procedures


              --- Exhibit A-Schedule for Escrow Deposits ---

Full Deposit Schedule

Full Deposits shall consist of data that reflects the state of the registry as 
of 00:00 UTC on each Sunday. Pending transactions at that time (i.e. 
transactions that have not been committed to the Registry Database) shall not 
be reflected in the Full Deposit.

Full Deposits shall be made, according to the transfer process described in 
Exhibit C below, within a four-hour window beginning at 04:00 UTC on the same 
Sunday.

Incremental Deposit Schedule

Incremental Deposits shall reflect database transactions made since the most 
recent Full or Incremental Deposit. Incremental Deposits for Monday shall 
include transactions completed through 00:00 UTC on that day that had not been 
committed to the registry database at the time the last Full Deposit was 
taken. Incremental Deposits on Tuesday through Saturday shall include 
transactions completed through 00:00 UTC on the day of the deposit that were 
not reflected in the immediately prior Incremental Deposit.
Incremental Deposits shall be made, according to the transfer process 
described in Exhibit C below, within a four-hour window beginning at 04:00 UTC 
on the day to which the Incremental Deposit relates.

               --- Exhibit B-Escrow Deposit Format Specification ---

This Appendix is subject to change by agreement of Registry Operator and ICANN 
during the design process as well as during the IETF standards process. In 
addition, Registry Operator agrees to implement changes to this Appendix 
specified by ICANN to conform to the IETF provreg working group's protocol 
specification no later than 135 days after the IETF specification is adopted 
as a Proposed Standard [RFC 2026, section 4.1.1]. 

Each Full Deposit includes a series of reports that are concatenated in the 
Escrow Process.  Each Full Deposit may further include a full backup of the 
operating database in native format.

Each Incremental Deposit includes a series of reports that are concatenated in 
the Escrow Process.  Each Incremental Deposit may further include a full 
backup of the operating database in native format.

Each Incremental Deposit consists of a series of reports that are concatenated 
in the Escrow Process.

Full Deposit Contents. The reports involved in a Full Deposit are:

Domain Object Report-This reports on the contents of all domain objects in the 
registry database.

Host Object Report-This reports on the contents of all host objects in the 
registry database.

Contact Object Report-This reports on the contents of all contact objects in 
the registry database.

Registrar Object Report-This reports on the contents of all registrar objects 
in the registry database.

Incremental Deposit Contents. The report involved in an Incremental Deposit is:

Transaction Report-This reports on the contents of all transaction records 
included in the Incremental Deposit.

Format of Reports. All reports are to be formatted in XML format. In 
compliance with the XML 1.0 specification, certain characters in the data must 
be escaped, as described in item 1 below. Each Report shall then be prepared 
according to the general XML format described in items 2 to 7 below. Item 2 
describes the report container that is common to all reports. Items 3 to 7 
describe the structure of the contents of the report container for each of the 
specific reports.  Report formats may be modified (with at least 90 days 
notification to participating parties) in respect of relevant changes to the 
Registry and all dependent specifications including but not limited to 
relevant RFCs. 

1. Escape-Character Requirements.  In compliance with the XML 1.0 
specification, data escrowed using the XML format the following characters in 
any data elements must be replaced with the corresponding escape sequences 
listed here: 

               Character                         Escape Sequence
             -------------                   -----------------------
                   "                                  &quot;
                   &                                  &amp;
                   `                                  &apos;
                   <                                   &lt;
                   >                                   &qt

2. The Report Container. At its highest level, the XML format consists of an 
escrow container with header attributes followed by escrow data. The header 
attributes are required and include the version of escrow (1.0), the Registry 
TLD ("org"), the report type (domain, host, contact, registrar, or 
transaction), and database-committed date and time as to which the escrow 
relates. The date and time of the escrow will be specified in UTC. The general 
format of the report container is as follows:

<?xml version="1.0" encoding='UTF-8' ?>
<!DOCTYPE escrow SYSTEM "whois-export.dtd" >
<escrow version="1.0" tld="org" report="domain" date="15-Jan-2003 3:15:00AM">

{Here the report contains the actual data being escrowed. It contains one 
element for each object of the type (domain, host, contact, registrar, or 
transaction) covered by the report. The specific format for each report is 
described in items 3 to 7 below.}

</escrow>

3. The Domain Element.  The domain element has the attribute "fqdn" (the fully 
qualified name of the domain) and is a container consisting of the following 
elements:

a. status: The domain status code. Possible values are: NEW, ACTIVE, INACTIVE, 
HOLD, LOCK, CLIENT-HOLD, CLIENT-LOCK, PENDING-TRANSFER, PENDING-DELETE

b. period: The registration period in years.

c. owned-by: An identification (the "id" attribute of the registrar element) 
of the sponsoring registrar of the domain.

d. created-code: A reference to the transaction that created the domain object.

e. created-on: The date/time the domain object was originally created.

f. renewed-on: The date/time the domain was last renewed.

g. updated-by: An identification (the "id" attribute of the registrar element) 
of the registrar that last updated the domain object.

h. updated-on: The date/time the domain object was last updated.

i. transferred-by: An identification (the "id" attribute of the registrar 
element) of the registrar that last transferred the domain object.

j. transferred-on: The date/time when the domain object was last transferred.

k. transferred-code: A reference to the transaction that last transferred the 
domain object.

l. host: Up to thirteen (13) host names that are nameservers for the domain to 
which the domain object relates.

m. contact-id: Up to four (4) contact-ids that reference the contact records 
for this domain. Contact-id has the attribute "type" to denote the type of 
contact. "Type" can be one of: Registrant, Administrative, Technical or 
Billing.

An example domain container appears below:

<domain fqdn="example.org"> 
   <status>ACTIVE</status>
   <period>1</period>
   <owned-by>42</owned-by>
   <created-code>12345678</created-code>
   <created-on>14-Jan-2003 12:34:56AM</created-on>
   <renewed-on></renewed-on>
   <updated-by>42</updated-by>
   <updated-on>14-Jan-2003 12:34:56AM</updated-on>
   <transferred-by></transferred-by>
   <transferred-on></transferred-on>
   <transferred-code></transferred-code>
   <host>dns1.example.org</host>
   <host>dns2.example.org</host> 
   <contact-id type="Registrant">1</contact-id>
   <contact-id type="Administrative">2</contact-id>
   <contact-id type="Technical">3</contact-id>
   <contact-id type="Billing">4</contact-id> 
</domain>

4. The Host Element.  The host element has the attribute "fqdn" (the fully 
qualified name of the host) and is a container consisting of the following 
elements:

a. owned-by: An identification (the "id" attribute of the registrar element) 
of the sponsoring registrar of the host.

b. created-code: A reference to the transaction that created the host object.

c. created-on: The date/time the host object was originally created.

d. updated-by: An identification (the "id" attribute of the registrar element) 
of the registrar that last updated the host object.

e. updated-on: The date/time the host object was last updated.

f. ip-address: Any number of IP addresses associated with this host.

An example host container appears below:

<host fqdn="dns1.example.org">
   <owned-by>42</owned-by>
   <created-code>12345679</created-code>
   <created-on>14-Jan-2003 12:40:32AM</created-on>
   <updated-by>42</updated-by>
   <updated-on>14-Jan-2003 12:40:32AM</updated-on>
   <ip-address>192.168.1.1</ip-address>
</host>

5. The Contact Element.  The contact element has the attribute "id" and is a 
container consisting of the following elements:

a. name: The name of the contact.

b. organization: The organization for the contact.

c. Within the "contact" container is a sub-container named "address" with the 
following elements:

i. street1: The first part of the street address of the contact.

ii. street2: The second part of the street address of the contact.

iii. city: The name of the city of the contact.

iv. state-province: The name of the state/province of the contact.

v. postal-code: The postal/zip code of the contact.

vi. country: The two-letter ISO 3166 code for the contact's country.

d. voice: The voice phone number of the contact in E164a format.

e. fax: The fax number of the contact in E164a format.

f. email: The e-mail address of the contact.

g. owned-by: An identification (the "id" attribute of the registrar element) 
of the sponsoring registrar of the contact.

h. created-code: A reference to the transaction that created the contact 
object.

i. created-on: The date/time the contact object was originally created.

j. updated-by: An identification (the "id" attribute of the registrar element) 
of the registrar that last updated the contact object.

k. updated-on: The date/time the contact object was last updated.

l. transferred-by: An identification (the "id" attribute of the registrar 
element) of the registrar that last transferred the contact object.

m. transferred-on: The date/time when the contact object was last transferred.

n. transferred-code: A reference to the transaction that last transferred the 
contact object.

An example contact container appears below:

<contact id="1">
   <name>John Doe</name>
   <organization>aol</organization>
   <address>
      <street1>1234 East 11th Street</street1>
      <street2></street2>
      <city>New York</city>
      <state-province>NY</state-province>
      <postal-code>12345</postal-code>
      <country>US</country>
   </address>
   <voice>+212.1234567</voice>
   <fax>+212.1234568</fax>
   <email>jdoe@example.org</email>
   <owned-by>42</owned-by>
   <created-code>12345680</created-code>
   <created-on>14-Jan-2003 12:42:22AM</created-on>
   <updated-by>42</updated-by>
   <updated-on>14-Jan-2003 12:42:22AM</updated-on>
   <transferred-by></transferred-by>
   <transferred-on></transferred-on>
   <transferred-code></transferred-code>
</contact>

6. The Registrar Element.  The registrar element has the attribute "id", which 
is a unique identifier assigned by the IANA. The registrar element is a 
container consisting of the following elements:

a. password: The password for the registrar.

b. name: The name of the registrar.

c. status: The registrar status code.

d. contact-id: Any number of contact-id associated with this registrar. 
Contact-id has the attribute "type" to denote the type of contact. "Type" can 
be one of: Administrative, Technical or Billing.

An example registrar container appears below:
<registrar id="42">
   <password>registrarrus</password>
   <name>Registrar R Us</name>
   <status>ACTIVE</status>
   <contact-id type="Administrative">10</contact-id>
   <contact-id type="Administrative">11</contact-id>
   <contact-id type="Technical">12</contact-id>
   <contact-id type="Technical">13</contact-id>
   <contact-id type="Billing">14</contact-id>
</registrar>

7. The Transaction Element.  The transaction element has the 
properties "operation" and "type". "Operation" can be one of: add, modify or 
delete. "Type" can be one of: domain, host, contact or registrar. The 
transaction element is a container consisting of elements from the 
corresponding "type" element. For example, a transaction element with a "type" 
of "registrar" will have the same set of elements as a Registrar element. For 
a "delete" operation, only the object ID is included in the transaction 
element.

An example transaction container appears below:

<transaction operation="modify" type="registrar">
   <password>new password</password>
   <name>Registrar R Us</name>
   <status>ACTIVE</status>
   <contact-id type="Administrative">10</contact-id>
   <contact-id type="Administrative">11</contact-id>
   <contact-id type="Technical">12</contact-id>
   <contact-id type="Technical">13</contact-id>
   <contact-id type="Billing">14</contact-id>
</transaction>

                   --- Exhibit C-Escrow Transfer Process --- 

Deposit Transfer Process.

Registry Operator shall prepare and transfer the Deposit file by the following 
steps, in sequence:

1. The Reports making up the Deposit will first be created according to the 
format specification. (See Exhibit B above, "Escrow Deposit Format 
Specification").

2. The Reports making up the Deposit will be concatenated. The resulting file 
shall be named according to the following format: "orgSEQN", where "SEQN" is a 
four digit decimal number that is incremented as each report is prepared.

3. Next, the Deposit file will be processed by a program (provided by ICANN or 
a mutually designated third party) that will verify that it complies with the 
format specification and contains reports of the same date/time (for a Full 
Deposit), count the number of objects of the various types in the Deposit, and 
append to the file a report of the program's results.

4. Registry Operator may optionally split the resulting file using the Unix 
SPLIT command (or equivalent) to produce files no less than 1 GB each (except 
the final file). If Deposit files are split, a .MD5 file (produced with MD5SUM 
or equivalent) must be included with the split files to isolate errors in case 
of transfer fault.

5. The Deposit file(s) will then be encrypted using Escrow Agent's public key 
for PGP and signed using Registry Operator's private key for PGP, both version 
6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte length. (Note 
that PGP compresses the Deposit file(s) in addition to encrypting it (them).)

The formatted, encrypted and signed Deposit file(s) will be sent, by anonymous 
file transfer, to Escrow Agent's ftp server within the specified time window.

               --- Exhibit D-Escrow Verification Procedures ---

Verification Procedures.  Escrow Agent will verify the format and completeness 
of each Deposit by the following steps:

1. At the conclusion of the deposit window, all Deposit files will be moved to 
a not-publicly-accessible directory and the existence and size of each will be 
noted.

2. Each Deposit file will be decrypted using Escrow Agent's private key for 
PGP and authenticated using Registry Operator's public key for PGP. (In this 
step, PGP will also automatically decompress the escrow file).

3. If there are multiple files, they will be concatenated in sequence.

4. Escrow Agent will run a program on the Deposit file (without report) that 
will split it in to its constituent reports (including the format report 
prepared by the Registry Operator and appended to the Deposit) check its 
format, count the number of objects of each type, and verify that the data set 
is internally consistent. This program will compare its results with the 
results of the Registry-generated format report, and will generate a Deposit 
format and completeness report. The program will encrypt the report using 
ICANN's public key for PGP and signed using Escrow Agent's private key for 
PGP, both versions 6.5.1 or above, with a key of DH/DSS type and 2048/1024-
byte length. (Note that PGP compresses the Deposit file(s) in addition to 
encrypting it (them).)

5. The decrypted Deposit file will be destroyed to reduce likelihood of data 
loss to intruders in case of partial security failure.

Distribution Of Public Keys.  Each of Registry Operator and Escrow Agent will 
distribute its public key to the other party (Registry Operator or Escrow 
Agent, as the case may be) via email to an email address to be specified. Each 
party will confirm receipt of the other party's public key with a reply email, 
and the distributing party will subsequently reconfirm the authenticity of the 
key transmitted. In this way, public key transmission is authenticated to a 
user able to send and receive mail via a mail server operated by the 
distributing party. Escrow Agent and ICANN shall exchange keys by the same 
procedure.

Along with providing the information requested below, the applicant should include its own proposed versions of appendices C, D, E, O, P, Q, and R based on the current .NET registry agreement <http://www.icann.org/tlds/agreements/verisign/net-index.htm> which the applicant would be willing to have included in the subsequent .NET registry agreement. Applicants should ensure that their proposed versions of these appendices include any relevant subsequent updates to the RFCs referenced in these appendices. For example, RFC1035 as listed in Appendix C4 has been updated by RFC2845 and RFC3645, among other updates.

(a) Outline your technical capabilities. Provide a description of your technical capabilities, including information about key technical personnel (qualifications and experience), size of technical workforce and access to systems development tools. Outline any significant prior technical achievements.

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

(b) Technical plan and capabilities for the proposed registry operations. In certain sections of the web-based form, applicants are permitted to make non-textual submissions together with, and as part of, their application (e.g., graphs, flowcharts, models and diagrams). Present a technical plan and capabilities outline for the proposed registry operations. The technical plan should address the following factors:

(i) General description of proposed facilities and systems. Describe all system locations. Identify the specific types of systems being used, their capacity and interoperability, general availability and level of security of technical environment. Describe in appropriate detail buildings, hardware, software systems, environmental equipment and Internet connectivity.

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



(ii) Stability of resolution and performance capabilities, including: response times and packet loss targets; availability of authoritative name servers; processes, tools and automated monitoring to ensure accuracy of zone data for resolution; diversity of DNS infrastructure; diversity and redundancy of network and DNS infrastructure to handle bandwidth congestion and network failures of ISPs and host providers.

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

(iii) Operational scalability sufficient to handle existing registry database and projected growth; DNS queries including peak periods and projected growth; DDoS attacks, viruses, worms and spam; and restart capabilities.

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

(iv) Describe the registry-registrar model and protocol; availability of a shared registration system, including processing times for standard queries (add, modify, delete); and duration of any planned or unplanned outages.

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

(v) Database capabilities including database software, size, throughput, scalability, procedures for object creation, editing, and deletion, change notifications, registrar transfer procedures, grace period implementation , availability of system with respect to unplanned outage time, response time performance; ability to handle current volumes and expected growth and reporting capabilities.

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

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


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


(vii) Zone file generation including procedures for changes, editing by registrars and updates. Address frequency, security, process, interface, user authentication, logging and data back-up.

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

(viii) Zone file distribution and publication. Locations of name servers, procedures for and means of distributing zone files to them.

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


(ix) Billing and collection systems. Technical characteristics, system security, accessibility.

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

(x) Backup. Describe frequency and procedures for backup of data. Describe hardware and systems used, data format, identity of suggested escrow agent(s) and procedures for retrieval of data/rebuild of database.

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

(xi) Escrow. Describe arrangements for data escrow, or equivalent data backup security, data formats, insurance arrangements and backup plans for data recovery.

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



(xii) Publicly accessible WHOIS service. Address software and hardware, connection speed, search capabilities and coordination with other WHOIS systems. Frequency of WHOIS updates, availability and processing times. Identify whether you propose to use a “thick” registry model or “thin” registry model, and explain why you believe your choice is preferable.

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

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

The applicant's response to Part 2, Section 5, Subsection b, Question xiii will remain confidential to ICANN and the independent evaluators. ICANN will use reasonable efforts to avoid publication or release of this information, but in no circumstance will ICANN's liability for any release of this information exceed the amount of the application fee.


[RESPONSE IS CONFIDENTIAL]


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

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.

(xv) System reliability. Define, analyze and quantify quality of service.

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

(xvi) System outage prevention. Procedures for problem detection, redundancy of all systems, backup power supply, facility security and technical security. Outline the availability of backup software, operating system and hardware. Outline system monitoring, technical maintenance staff and server locations.

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

(xvii) Ability to support current feature functionality of .NET (to the extent publicly or otherwise available to the applicant, including IDNs, support of IPv6, DNSSEC.

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

(xviii) System recovery procedures. Procedures for restoring the system to operation in the event of a system outage, both expected and unexpected. Identify redundant/diverse systems for providing service in the event of an outage and describe the process for recovery from various types of failures. Describe the training of technical staff that will perform these tasks, the availability and backup of software and operating systems needed to restore the system to operation and the availability of the hardware needed to restore and run the system. Describe backup electrical power systems and the projected time for system restoration. Describe procedures for testing the process of restoring the system to operation in the event of an outage, the documentation kept on system outages and on potential system problems that could result in outages.

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

(xix) Technical and other support. Support for registrars and for Internet users and registrants. Describe technical help systems, personnel accessibility, web-based, telephone and other support services to be offered, time availability of support and language-availability of support. Ability to support new and emerging technologies.

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

6. Security and Stability

Criteria: The entity chosen to operate the .NET registry must: (i) maintain .NET registry functions efficiently and reliably, (ii) demonstrate disaster recovery capability and (iii) deliver high quality of service for all .NET users worldwide. Providing documentation for procedures insuring a very high level of security and stability is an absolute criterion.

(a) Provision for Registry Failure. Describe in detail how you would assure continuity of operations in the event of operational failure of the registry and make provision for contingencies and a failsafe back-up plan. A commitment to provide ICANN with escrowed data, in and of itself, will not satisfy the absolute criterion.

...I: Continuity of Operations and Emergency Response

The Afilias operations team has professionally handled numerous incidents 
since the inception of the company.  The .INFO registry opened for 
unrestricted registrations on September 12, 2001, while mitigating 
consequences of the 9/11 terrorist attacks. in New York City.  For example, 
wWe helped registrars who had key management personnel unavailable, and were 
suffering from problems at their facilities and service providers.

In another example, the power grid in northeastern North America failed in 
August 2003. The Afilias Operations Center in Toronto was in the affected 
area, which experienced a complete loss of power.   However, our smooth 
response to this event resulted in no impact to the availability of .INFO 
or .ORG names, both in the DNS and in the SRS, nor did it affect Afilias' 
ability to provide support to the registrars.

The Afilias team will implement well-defined procedures to ensure that .NET 
registry functions efficiently and reliably.  Further, it has put in place 
disaster recovery capabilities.  This combination will deliver the highest 
quality of service to all .NET users, worldwide.

Registry failure can be separated into two major categories.  First is a 
catastrophic failure of the registry, in which the propagation and resolution 
of names in DNS may fail and the shared registry system is unavailable.  
(i.e., It is not possible to add or modify names in the registry.)  Afilias 
classifies these incidents as "Complete Failures." The primary response to 
mitigate a catastrophic failure is to sufficiently provision registry systems 
and ensure diversity at each layer in a geographically diverse manner.  
Afilias has executed such a strategy.

The second category consists of partial failure of a registry system, 
prioritized in the order provided below.  We classify these incidents 
as "Emergencies":

A. Failure of the registry to serve already registered names (Failure A)

B. Failure of the registry to register new names or update information about 
existing names (Failure B)

C. Unauthorized access or exposure of sensitive registry data (Failure C)

D. Data management failure (Failure D)

In our experience, and based on empirical evidence, registries are more likely 
to experience Emergencies than Complete Failures.  Accordingly, Afilias has 
implemented an Emergency Response Program (EMP) and a Global Emergency 
Response System (GERS) to deal with each type incident.

The Emergency Response Program (EMP) ensures the coordination and 
implementation of activities to ensure that adequate and timely response 
measures are taken.  Emergency management is a dynamic process, requiring 
planning, training, drills, testing equipment, and coordinating activities 
with stakeholders.  The EMP works on a defined schedule and has an allocated 
budget that includes consideration for research, seminars, consulting 
services, and other expenses that may be necessary.

The main EMP areas are:
·	The Emergency Management Group (EMG) controls all incident-related 
activities.  The EMG allocates resources and interfaces with the community, 
the media, the outside response organizations, and regulatory agencies.  The 
EMG is headed by the Emergency Director (ED), who is usually the Chief 
Technology Officer.  Other EMG members are senior managers who have the 
authority to: determine the short- and long-term effects of an emergency; 
order the partial or complete shutdown of the registry; interface with 
registrars, outside organizations and the media; and issue updates to 
registrars to aid registrants and other .NET stakeholders.  The new Afilias 
Technical Advisory Group (TAG) will provide assistance to the cCompany to help 
us plan for potential emergencies.

·	The Incident Command System (ICS) provides for coordinated response, a 
clear chain of command, and safe operations.  Each incident is assigned an 
Incident Coordinator (IC), usually a senior member of management with the 
authority to make decisions.  The IC is responsible for front-line management 
of the incident --  tactical planning and execution, determining whether 
outside assistance is needed, and for relaying requests for internal resources 
or outside assistance through the Emergency Operations Center (EOC).  

·	The Emergency Operations Center (EOC) serves as a centralized 
management center for emergency operations.  Decisions are made by the EMG 
based on information provided by the IC and other personnel.  Due to the 
global nature of the registry, the EOC usually meets using conventional means 
such as meeting in person, or through a telephone or video conference, or if 
those are unavailable, then via an Internet conference.  

·	Afilias' Global Emergency Response System (GERS) will be activated for 
a catastrophe resulting in Complete Failure.  This system involves teams from 
local, remote, and affiliated organizations, industry, and other organizations 
to share expertise and resources to ensure that control and recovery 
activities are timely and efficient, and that they minimize threats to the 
stability and security of the system..

·	At the heart of the system is the Registry Emergency Contingency Plan 
(ECP), a system developed to ensure that the resources and expertise of the 
registry staff are available immediately for problems that are beyond the 
normal tolerance limits of operational failure.  The ECP provides the 
framework for the Global Emergency Response System and establishes how it 
works.


...II:  Emergency Registry Handover

Should there be a disaster in which the entire registry database and operation 
has to be handed over, the Afilias DNS Emergency Contingency Plan contains 
detailed procedures that ensure such a transfer will occur quickly.

Afilias will contract with one of the other applicants that meet the absolute 
criteria for the .NET RFP to serve as backup for the .NET registry in the rare 
event of a failure that requires emergency registry handover.

In order to ensure smooth operation of the registry under such an eventuality, 
copies of Afilias's software and systems, including the source code, systems 
configurations, operations manuals, data and all other related material is 
stored at each of the EOCs The plans for the operation of the registry, 
including the operations manual, listing of automated (cron) jobs, quality 
assurance manuals, and similar documents required for the stable operation of 
the registry will be stored at each of the EOCs..

As a contingency, the DNS ECP also plans for a data reconciliation procedure 
that will be procured from registrars which allows for a separate and 
independent path of reconciliation of data.

Finally, the DNS ECP contains a defined succession plan with members backed up 
in different geographic locations (i.e., US key personnel are backed up in 
Canada, Germany, UK, and/or India) in the case of loss of key personnel.


...III: Fail-safe Backup Plans

Afilias has designed a system with extremely high fault tolerance.  Provided 
below is a relevant excerpt from the Afilias DNS Emergency Contingency Plan 
(ECP).

Redundant systems, and hardware which allows parts to be replaced without 
shutting the hardware down, both make the system extremely reliable.  To deal 
with any contingency, however, the registry has a full plan to deal with 
failures.  Afilias t
Technical Support 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 on site, or by pager, 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.

Our data centers keep extra parts for all equipment used in the registry, 
allowing quick repairs in the event of hardware failure.  The supplies are 
adequate to allow for multiple concurrent component failures.  Additional 
preparedness comes from 24-hour, 365 -days- per- year telephone and on-site 
support from all our software and hardware vendors.  If replacement parts 
stock were to be exhausted, additional parts are available within four hours 
of request.  Hardware will be selected for the highest degree of 
serviceability.

The registry offers a system that 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.

The ECP deals with two classes of potential outage:  expected and unexpected.

Expected Maintenance

Expected maintenances are planned events.  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.

Unexpected Failures 

(See also (Please refer to part 2, section 5, Technical Competence with 
respect to , for more details on Afilias procedures for unexpected failures)

The ECP classified unexpected failures into four categories:

1. 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 act as warnings for an 
expected failure; the system would be able to continue to function 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 the components.

2. 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 continue operation 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 every member of the primary data server cluster failed, 
there would need to be a minimal interruption in service, while data 
processing moved to the backup data server cluster. Because the data servers 
use external RAID arrays, a failure of the primary server cluster does not 
entail the loss of the data stored there; instead, the data is moved instantly 
to the secondary server cluster.  

3.  Total failure of one data center -- for example, the total destruction of 
one data center.

The registry maintains three geographically isolated data centers, and is 
creating a fourth.  These centers are connected via high-speed redundant VPN 
connections, so the secondary data centers 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.  

4.  Total failure of all data centers -- for example, an attack that destroys 
all the databases.

The registry is prepared for the unlikely case in which all data centers are 
destroyed at the same time.  In the event that the failure is merely a loss of 
data, the registry's extensive backup arrangements will ensure that data will 
be preserved; data can be restored, and operations can resume shortly.

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.  The registry will invoke the Emergency Management 
Group (EMG) immediately.  The registry would suspend the acceptance of new 
registrations for the period that it might take to restore registrations taken 
between the time of the creation of the escrow deposit, and the destruction of 
all data centers.  Such restoration might proceed by data-restoration services 
performed by a company specializing in such restoration.  In the event that no 
restoration where is possible, the registry will revert to the database as it 
was at the time of escrow. The destruction in two or more geographically 
distant locations would indicate other similar problems for other parts of the 
world.  


...III:   Provision for Contingencies and Operational Failure - Registry 
Emergency Contingency Plan (ECP)

Afilias' preparedness is demonstrated by the step-by-step contingency plans it 
has for various kinds of outages.  The following is a representative example.  
Plans exist for a variety of situations, including hardware failure and 
network problems.

In Case of Reports of Poor Response

It is necessary to determine whether there is a real problem in the data 
center, or whether the problem may be with routes on the Internet.  

1.  Technical support staff open a ticket to track the report. 

2.  Technical support staff perform standard monitor checks.  Ensure that 
response-time tools are not reporting trouble, and that all network monitor 
stations indicate normal operations.  If not, see step 3.  If all appears 
normal, proceed to the next step. 

3.  Technical support staff check for abnormal operation outside the Afilias 
VPN.  If all is normal in the VPN, but there is a failure from outside the 
VPN, there is a problem with the outer network layer at the data center.  
Escalate to the data center technical support group, and note ticket number in 
internal ticket notes.  If there is no apparent failure, proceed to the next 
step. 

4.  If all appears normal from inside and outside the VPN, technical support 
staff report back to registrar.  The network issue may be a failure in their 
own network.  Continue investigation and monitoring of system. 

5.  Technical support staff make a full report to systems staff, detailing the 
nature of the failure and the number of affected registrars. 

6.  Systems staff investigate log files, to discover nature and cause of 
failure.  If the failure is a network problem, see step 7.  If the failure is 
a problem with the SRS, see step 8.  If the failure is a problem with WHOIS, 
see step 9.  If the failure relates to DNS, see step 10.  If the outage is 
related to the databases, see step 12. 

7.  Systems staff use standard network diagnostic tools, including packet 
sniffers and routing tools, to discover where the fault lies in the network.  
In the event it is in the operations network, reconfigure according to current 
network documentation.  In the event it is in the data center network, contact 
data center technical support and get a ticket number.  Inform technical 
support staff of expected return to service. 

8.  Systems staff analyze logs to determine what may have caused the fault.  
Check for abnormal operation.  Analyze current connection patterns (if any) 
and determine thread health.  In the event a restart of the service is 
necessary, ensure a graceful shutdown and restart.  Contact technical support 
staff when the trouble is resolved; technical support staff close the ticket. 

9.  Systems staff analyze logs to determine what may have caused the fault.  
Check for abnormal operation.  Examine current connection patterns, looking 
for hanging network problems.  Be particularly aware of DoS possibilities, 
because WHOIS is on the Web server layer.  Watch for traffic growth after 
restart, if necessary.  Contact technical support staff when the trouble is 
resolved; technical support staff close the ticket. 

10. Ensure that interruption in DNS service is not really a failure of DNS 
propagation.  If so, determine the fault, and repair or restart the DNS update 
service. If so, contact name service provider.

11. Work to restore service.  Contact technical support staff when the trouble 
is resolved; technical support staff close the ticket. 

12. A database interruption is the most critical disruption.  If a database 
interruption occurs, database administrators should be involved immediately.  
If database has stopped, analyze logs.  Look for anomalies, and anything that 
might represent a problem with the data.  Restart the database in local mode 
only, to ensure integrity of data.  Allow redo log to complete, and restart in 
multi-user mode. Monitor.  Contact technical support staff when the trouble is 
resolved; technical support staff close the ticket. 


...  IV: Emergency Response Program
When an emergency occurs, the Afilias Network Operations Center (NOC) is 
responsible for the evaluation and escalation of emergency response personnel. 
The NOC also monitors the emergency against pre-established reporting triggers.

Emergency Operations Centers

The Afilias EOCs are geographically dispersed.  Physical EOC locations exist 
in Horsham, USA and Toronto, Canada; a third center is being setup in New 
Delhi, India.  The EOC is equipped with communications equipment, reference 
materials, activity logs, and the tools necessary to respond quickly and 
appropriately to an emergency.

If the scope of the emergency exceeds the established reporting triggers, the 
NOC is required to notify the Afilias Emergency Operations Center (EOC).  Then 
the EOC immediately notifies the designated Incident Coordinator (IC).  The IC 
determines the status of the local response and monitors the situation to 
determine whether to form the EMG and broaden the scope of the emergency 
response.  If the scope of the emergency exceeds the established reporting 
triggers, the EOC hands over mobilization activities to the EMG.

Each Tech-Ops team consists of qualified systems administrators, database 
administrators, quality assurance engineers, systems developers, a project 
manager, and a documentation expert.  The size of this team can be increased 
based on the need.

(b) Provision for Business Failure. Describe in detail what advance arrangements you will implement to ensure that, if your operation of the .NET registry becomes financially non-viable, the registry operations will be quickly, smoothly and efficiently transferred to another operator so as to minimize disruption of the registry functions.

...  I. Overview

Afilias is an established registry services company with a strong track record 
of prudent fiscal management.   Afilias has significant reserves to cover 
years of sustained operation.  We are confident that the pricing and financial 
model for the .NET registry provides sufficient basis to ensure continued 
financial viability of the Ccompany.  For details on the financial strength 
that Afilias brings to the operation of .NET, please see section 2-4. 
Nevertheless, Afilias makes responsible plans for every eventuality.

As part of the process of contract negotiation, Afilias will undertake to 
negotiate, with an alternate registry operator who has successfully passed 
the .NET absolute criteria, an agreement for the emergency takeover and 
operation of the registry.

In order to ensure smooth operation of the registry under such an eventuality, 
Afilias will depost copies of its copies of Afilias's software and systems, 
including the source code, systems configurations, operations manuals, data 
and all other related material will be deposited with an escrow agent under a 
royalty-free, unrestricted license, which takes effect in case rare event that 
Afilias becomes financially non-viable.  Further, key members of Afilias' 
management team and staff will be provided with incentives to provide any 
services that may be necessary for the registry handover.

As a strong, fiscally responsible company, we recognize that many warning 
signs would be apparent before critical financial failure occurs.  Were such 
an event to ever occur, we have a plan in place that triggers actions based on 
these warning signs.

...  II. Operational Phases for the Implementation of Critical Financial 
Condition

A. Phase One - Adjustment To Ongoing Operations

The company may determine that conditions are such that adjustments which do 
not require involuntary separation or salary adjustments of regular employees 
are sufficient to maintain institutional financial viability. Adjustments 
could include, but not be limited to:

1. Accepting voluntary early retirement with benefits continued where possible.

2. Modifying programs or services to improve efficiency and/or minimize future 
losses.

3. Reordering priorities to minimize the anticipated financial shortfall or 
change of program direction.

4. Seeking additional revenue from external sources.

5. Freezing all new hiring and filling of vacancies.

6. Waiving promotions and/or salary increases.

B. Phase Two - Program Change or Redirection

When adjustments to ongoing operations are insufficient to deal with the 
financial problem, the company may determine that program change or 
redirection is necessary. These changes may result in the need to change 
employees' wages, hours and working conditions. When program redirection 
involves the curtailment or elimination of one or more programs or services, 
involuntary separation of personnel in those areas may result. Adjustments at 
this phase may include remedial efforts appearing in Phase One as well as 
those appearing below:

1. Reduction of part-time personnel

2. Mandatory change in hours worked, workweek, fringe benefits, work 
assignments and possible resulting in a reduction in pay for staff. Mandatory 
modification of workweek and work assignments possibly resulting in a 
percentage reduction in pay.

3. Suspension of all salary increases.

4. Across the board salary reductions for all employees.

C. Phase Three - A Critical Financial Condition

Under this scenario, Tthe Ccompany may first indicate an intention to declare 
a critical financial condition., which we believe is extremely unlikely to 
occur due to our strong financial position. In doing so, the company shall 
would indicate that all appropriate remedial efforts have been considered and 
to the extent possible implemented, but that conditions are such that further 
enterprise-wide action is required.

Once declared, the Afilias Global Emergency Recovery System (GERS) will be 
invoked, resulting in extraordinary measures being put in place to ensure 
responsivenessa smooth transition.

Under the provisions of the Afilias GERS system, we will work closely with 
IBM, UltraDNS, Autonomica, and Iron Mountain to provide continued services for 
the Internet community without service interruption.  The GERS plan 
contemplates the inclusion of cross-verified catastrophic contingency plans 
that allow our contracted vendors to provide these services until an 
appropriate backup registry operator is identified, and to provide incentives 
to employees to provide necessary services.

(c) Describe in detail your arrangements to provide a secure environment in which the registry infrastructure is to be operated.

The applicant's response to Part 2, Section 6, Question c will remain confidential to ICANN and the independent evaluators. ICANN will use reasonable efforts to avoid publication or release of this information, but in no circumstance will ICANN's liability for any release of this information exceed the amount of the application fee.

[RESPONSE IS CONFIDENTIAL]
   

7. Additional Relative Criteria

The following are additional relative criteria: (i) the degree to which the applicant’s proposal promotes competition in the registration of domain names, (ii) the degree to which an applicant’s business model relies on multiple, rather than sole source, suppliers, to reduce the impact of failure by any one supplier, and (iii) the degree to which an applicant’s proposal results in improved implementation of, and support for, GNSO policies, such as transfers and deletes.

Provide a detailed explanation of the manner and degree to which your proposal accomplishes the three relative criteria described above.

This section will clearly illustrate how Afilias:  1) is the Registry Operator 
that can best stimulate competition in the industry; 2) leverages its 
philosophy of partnering with "best in class" suppliers to minimize the risk 
of a single point of failure; and 3) will dramatically improve the 
implementation of GNSO policies in .NET.


(i) Degree to Which the Afilias Proposal Promotes Competition in the 
Registration of Domain Names

Afilias is the Registry Operator that can best improve competition in the 
registration of .NET domain names and thereby challenge VeriSign's market 
dominance.

...  I. Continuation of the .COM/.NET Monopoly Prevents Robust Competition

"Introducing and promoting competition in the registration of domain names" is 
a Core Value noted in ICANN's Strategic Plan. But .COM and .NET continue to 
dominate the domain market despite establishment of new TLDs and registry 
companies. As long as VeriSign controls both TLDs, it has no incentive to 
build up .NET at the expense of .COM.  SinceVerisign's .COM contract has 
presumptive renewal, separating .NET from VeriSign is a key way to spur robust 
competition and enable .NET growth to accelerate.

The combination of .COM (72%) and .NET (12%) currently gives VeriSign 84% of 
the gTLD market. A chart of "gTLD Market Shares by Domain" is below (source:  
www.webhosting.info, as of Jan 15, 2005):

  - .COM    72%    33.3M    (VeriSign)

  - .NET    11%     5.3M    (VeriSign)

  - .ORG     7%     3.3M    (Public Interest Registry)

  - .INFO    7%     3.3M    (Afilias)

  - .BIZ     2%     1.1M    (NeuLevel/NeuStar)

Even factoring in the top country code TLDs (ccTLDs) does not change 
VeriSign's dominance.  The two largest country codes are .DE, with roughly 8 
million domains, and .UK, with about 3.8 million domains. While ccTLDs are 
growing overall, no ccTLD operator has the global experience, technical 
expertise, or scale to effectively challenge VeriSign in the gTLD arena.

Transferring .NET to another registry operator will still leave VeriSign with 
a gTLD market share of 72%. But, more importantly, it will create the 
conditions for a competitive .NET by removing it from .COM. The critical issue 
for ICANN is: which applicant can best develop .NET into a competitive TLD?

...  II. Afilias' Ability to Develop .NET into Competition with .COM is 
Unmatched

Afilias and NeuLevel/NeuStar launched their new gTLDs within weeks of each 
other in 2001. Afilias, however, has developed .INFO into a TLD of more than 
3.4 million names, with a market share of 7.2%. NeuLevel/NeuStar, by contrast, 
has built .BIZ to only about 1.1 million names, with a 2.3% market share. 
NeuLevel/NeuStar is also the Registry Operator for the .US TLD, where 
disappointing registrations have leveled off at less than 1 million.. (Note: 
Afilias' market share does not include .ORG because PIR is the Registry 
Operator for .ORG).

Some might suggest stimulating competition by awarding .NET to the qualified 
applicant with the lowest market share, but that would not satisfy the RFP 
criteria of promoting "competition in the registration of domain names." ICANN 
could also consider only the number of TLDs for which an applicant is already 
the registry operator. While such a calculation could favor Afilias (the 
Registry Operator for only .INFO) over NeuLevel/NeuStar (which operates 
both .BIZ and .US), this would not satisfy the RFP either. The most important 
factor is: which applicant can best stimulate competition? The answer depends 
on more than resources, for NeuLevel/NeuStar is a multi-million dollar 
telecommunications company with adequate funds to develop BIZ, but it has been 
unable to do so. Indeed, the lackluster development of both .BIZ and .US 
suggests that a company focused primarily on telecommunications lacks 
sufficient understanding of the domain industry to create such competition.

For competition to work, .NET requires a Registry Operator that can 
effectively support, market and develop the domain. Only Afilias has the 
proven ability to do this, with its strategic focus on registry operations and 
its track record of market effectiveness. In addition, only Afilias has every 
incentive to make .NET a success on its own, rather than an afterthought 
to .COM, or just another line of business in a larger "telco." Afilias' 
competitive successes include:

· Lower prices for .INFO: For 2005, Afilias is offering .INFO for only 
$.75 for the first domain year on new registrations.  This program follows the 
successful  "Free" .INFO" program which offered a free first domain year and 
drove prices down for both registrars and consumers. The program increased the 
number of registrations in the registry from 1.2 million in August to more 
than 3.3 million by year-end, as many registrars aggressively marketed .INFO 
to their customers at attractive (even free) prices. The program also 
intensified registrar competition as registrars worked to avoid being out-
sold. Market research shows high usage and hence good renewal potential. No 
other registry operator has been so bold as to promote 75%-100% discounts on 
domains.

· Faster .INFO DNS that has stimulated faster DNS market-wide: .INFO was 
the first gTLD to employ the innovative "anycasting" DNS approach, which was 
pioneered by UltraDNS and is now used on the root server system. This process, 
coupled with Afilias' use of EPP, yielded for the first time DNS updates which 
could be seen on the Internet globally in near real-time, and it rapidly 
became the benchmark for other registries. Now even VeriSign, which for years 
resisted updating its DNS at less than 12-hour intervals, has only recently 
improved its update speeds.

· Afilias' standards-compliant IDNs have helped set industry standards: 
Afilias resisted the temptation to forge ahead with a non-interoperable 
artifice, such as a plug-in (e.g. VeriSign's I-Nav IDN solution), and instead 
worked within the Community to finalize the standard. Afilias' launch of a 
compliant German IDN solution for .INFO did not falter, as DENIC's system did 
during its IDN launch.

· Domain Usage: With .INFO's launch, Afilias began measuring not just 
registration counts, but also domain usage. Afilias believes that usage is an 
indicator of TLD quality, and a key metric for all domains. Usage metrics have 
now become standard among registries, with NeuLevel/NeuStar hosting seminars 
to share this data, PIR tracking .ORG usage, and even VeriSign publishing 
usage data.

...  III. Afilias will Move to Immediately Improve the Competitiveness of 
the .NET Registry

Afilias will launch several programs immediately to improve .NET 
competitiveness:

· Reduced Price: Afilias will immediately reduce the .NET price from 
$6.00 to US$4.00 per domain year (which INCLUDES the $.75 ICANN fee). 

· $1.00 .NET Promotion: Afilias will offer .NET for only $1.00 for the 
first 6 months of new registrations (this also includes the ICANN fee).  As 
with the similar .INFO programs, Afilias will encourage .NET registrars to 
share this 83.3% discount (off VeriSign's price today) with registrants.

· Improved Registry Services: Afilias believes in responsible 
innovation, which will serve to realign the NET registry with the ICANN 
community. For example, we support the auction concept for handling deleting 
names, and will work with the Community through the PDP system to resolve any 
issues.

· Stronger DNS security:  Afilias' primary DNS provider, UltraDNS, has 
developed and implemented a new platform that enables normal query resolution 
even while under a severe attack.  This new process enables DDoS survivability 
for ISP's that contain "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.

· Faster WHOIS Updates: Afilias will provide near-real-time updates for 
WHOIS (as it does for .INFO and .ORG), rather than the current 12-24 hours 
delay on .NET, thereby eliminating an unnecessary lag that spammers and others 
can abuse.

· Improved IDN Deployment: Afilias will apply its pioneering expertise 
in standards-based IDN implementation to the .NET registry. VeriSign's 
introduction of IDNs led to strong objections from China and other 
governments; .NET now requires a new approach. (Even today, VeriSign and DENIC 
refuse to register their IDN language-tables at the IANA IDN Language-Table 
Registry, and are deploying solutions that diverge from ICANN IDN guidelines.)

· New Technical Advisory Group (TAG): The TAG will advise Afilias in 
technical areas, and help to rebuild trust with the .NET technical community. 
In addition, Afilias will fund a $1,000,000 Infrastructure Innovation Fund 
(IIF) for TAG to do its work. The TAG and IIF will work to improve the 
security and stability of the DNS through sponsorship of research, standards 
development, implementation and interoperability testing, technology trials, 
deployment activities and other important projects.



(ii) Degree to Which Afilias' Business Model Relies on Multiple, Rather Than 
Sole Source, Suppliers, to Reduce the Impact of Failure by Any One Supplier

Afilias' entire business model is based on ensuring diversity of suppliers to 
eliminate single points of failure. We seek out best in class providers, and 
team together to provide an overall superior service. Our model is modular and 
driven by technical standards, which allows interoperability, flexibility and 
cost effectiveness. It results in a more secure and reliable means of 
managing .NET than the status quo, which relies on VeriSign's proprietary 
systems. Afilias has established supplier diversity in the key components of 
registry service, including DNS, SRS, and Database:

DNS: Afilias uses UltraDNS as its primary DNS provider. UltraDNS has an 
architecture designed to ensure that there is no single point of failure in 
any segment of the system. In addition, Afilias has an arrangement with 
Autonomica AB of Sweden to provide backup DNS support upon the transfer and 
migration of .NET. Autonomica is owned by Netnod AB and has run Netnod's 
operations since 2000, including i.root-servers.net as well as slave servers 
for a number of TLDs. Autonomica will receive zone files continuously from 
Afilias and is prepared to begin serving DNS immediately if needed.

SRS Diversity: Afilias uses two suppliers, IBM and Q9, to providing telco-
grade support for our SRS. Afilias has used IBM data centers as primary 
support since 2001. As detailed in part 2, section 3, Registry Operations, IBM 
provides a primary site in St. Louis, MO and a failover site in Secaucus, NJ. 
In addition, Afilias has recently upgraded to IBM equipment at these sites, 
further enhancing our reliability. During the major power blackout in 
northeastern North America in 2003, Afilias' service was uninterrupted. Q9 
Networks is a leading Canadian provider of outsourced Internet infrastructure 
and related managed services. Q9's data centers and network are backed by an 
SLA that guarantees 100% network and power availability.

Diverse Database Capability: Afilias uses PostgreSQL, an open source database 
that has proven itself for registry applications. PostgreSQL has successfully 
supported .INFO for over 3 years, and .ORG for nearly 2 years. PostgreSQL is 
supported by a large and thriving community of developers, eliminating 
dependence upon proprietary code. One of the leading PostgreSQL developers now 
works at Afilias, a collaboration that has resulted in significant improvement 
in replication capability (SLONY-- 
http://gborg.postgresql.org/project/slony1), benefiting both our domains and 
the Internet Community in general. PostgreSQL is not only independent of a 
single supplier, but entirely standards-based.  Porting data into another 
database is simple and direct, should the need arise.

In summary, Afilias will not only operate .NET on robust, reliable systems, 
but will provide supplemental redundancy to establish a new standard in 
reliability and security.



(iii)  Degree to Which Afilias' Proposal Results in Improved Implementation 
of, and Support for, GNSO Policies, Such as Transfers and Deletes

Afilias' proposal will result in improved implementation of and support for 
GNSO policies, including Transfers and Deletes, by bringing .NET into full 
compliance for NET.

...  I. Afilias' has a Strong Record of GNSO Leadership and Adherence to ICANN 
Policies

An excellent example of our supportive approach (and speed of execution) is 
the implementation of the 2001 ICANN Board resolution on "Geographic and 
Geopolitical Names in .info." Since .INFO was the first new gTLD to launch, 
the issue of reserving country names was not addressed in the contracts. When 
the GAC raised the issue only days before launch, Afilias worked closely with 
the GNSO and ICANN to create a way to quickly reserve names on the ISO 3166-1 
list. Other examples include: 

A. Transfers: Following approval of the Transfer policy, Afilias worked 
closely with ICANN to ensure consistent implementation across registries, 
facilitating the process for registrars and registrants. Afilias identified 
executional issues (e.g., the "transfer-undo" feature) and addressed them in a 
manner that complemented existing practices. 

B. Deletes: Afilias supported the "Deletes" policy, including the RGP. Afilias 
facilitated PIR's implementation of this policy for .ORG and subsequently 
introduced it to .INFO. Both implementations were supported by detailed 
documentation for registrars to ensure smooth execution.

C. UDRP: Afilias has strongly supported the UDRP process and worked closely 
with WIPO to ensure swift implementation of its decisions. We have helped 
promulgate the use of UDRP principles by ccTLD customers, working to expand it 
as a global standard.

E. WHOIS: Afilias is committed to providing reliable WHOIS service, and 
implements an extensive array of protections to discourage abuse of data.

...  II. Afilias' Record is Unmatched by Other Registry Operators

There is no question of Afilias' commitment to abide by all existing and 
future GNSO policies. Our record stands in sharp contrast to those of other 
applicants, some of whom have gone to extraordinary lengths to avoid 
implementing ICANN policies and requirements. The records of three potential 
applicants are instructive:

The VeriSign Record: VeriSign has tried to thwart or circumvent ICANN policies 
on many occasions. One was VeriSign's abrupt launch of the "Site Finder" 
wildcard service in September 2003, which changed the way .NET and .COM were 
operated. ICANN promptly requested VeriSign to suspend the wild card service, 
but VeriSign refused until ICANN threatened to compel compliance. After 
careful study, ICANN's Security and Stability Advisory Committee determined 
that VeriSign's .COM/.NET actions had violated "fundamental architecture 
principles and well-established codes of conduct and good practice intended to 
ensure stability." They further stated that Verisign's action stimulated 
responses having the effect of  "...cumulatively reducing the overall coherence 
of the system... ."  VeriSign's response was to sue ICANN.

VeriSign has made clear that it believes it has the right to relaunch its wild 
cards at any time. As recently as January 9, 2005, in a San Francisco 
Chronicle interview, VeriSign's CEO was quoted as saying: "We've invested 
millions, if not hundreds of millions, of dollars in these services and we'd 
like to build new services on top of them that have some customer value. We 
believe Site Finder was one of those."

When it was a wholly owned subisidary of VeriSign, Network Solutions, Inc. was 
found by the U.S. Federal Trade Commission (FTC) in 2003 to have 
used "deceptive marketing practices" that "unlawfully tricked consumers into 
transferring their Internet domain name registrations to the company." 
Further, ICANN's General Counsel notified the VeriSign Registrar in 2002 of 
seventeen (17) instances of breach of its ICANN Registrar Accreditation 
Agreement, involving persistent nonresponsiveness to requests to correct 
incomplete and inaccurate WHOIS data. VeriSign's behavior spurred the GNSO to 
develop new consensus policies on WHOIS marketing restrictions and data 
accuracy.

The NeuLevel/NeuStar Record: NeuLevel/NeuStar surreptitiously launched a Site 
Finder-like service called "LookSmart" in the .BIZ and .US TLDs in May 2003. 
NeuLevel said that the "motive of the test was to come up with a service that 
would enhance the user experience . . .  ." Many users, however, disagreed. 
One accused NeuLevel of running "a TLD delegation as a private dukedom" and 
correctly pointed out that the "determination of what is `better' for the 
various interests in the DNS is a matter for the ICANN consensus process and 
RFC1581" (see 
http://www.biglist.com/lists/lists.inta.org/tmtopics/archives/0305/msg00066).  

During GNSO Council deliberations on VeriSign's wild card deployment, a 
NeuLevel executive asserted that to "state there are `grave technical 
concerns' is probably one of the greatest overstatements that I have heard in 
a long time . . ." (email from Jeff Neuman to Thomas Roessler, sent Tue, 16 
Sep 2003 15:05:27 -0400, at http://gnso.icann.org/mailing-
lists/archives/council/msg00082.html). After thorough examination, ICANN's 
Security and Stability Advisory Committee determined that such concerns were 
indeed warranted.

The DENIC Record: DENIC has a long standing record of non-support for ICANN 
and its policies. On 1 August 2002, .DE and three other ccTLD operators 
announced they had worked closely with VeriSign "in reaching a common view of 
a lightweight ICANN." More recently, DENIC refused to help develop ICANN's 
ccNSO into an important part of the new ICANN. DENIC had earlier criticized 
ICANN's efforts to obtain a share of funding from ccTLDs and challenged the 
idea of paying fees to ICANN on the basis of the number of 
registrations "since the service that ICANN supplies for the individual 
registries is by no means dependent on the number of domains and is basically 
identical for all registries" (see "European Domain Registries turn down 
financial contributions demanded by ICANN" at 
http://www.denic.de/en/denic/presse/press_36.html). Such a registration-based 
fee structure is a specific requirement of this RFP.

DENIC's position on data protection laws in relation to IANA raises questions 
about DENIC's ability to implement current and future ICANN policies, 
particularly regarding WHOIS. In "Comments on ICANN Zone Access Policy," 
CENTR's Executive Committee (which included DENIC) stated in 2002 that it "is 
our considered view that providing zone files to ICANN would constitute a 
breach of data protection laws that cover many jurisdictions within Europe" 
(see http://old.centr.org/news/ICANN-Zone-Access-Comments.html). CENTR has 
opposed the use of zone transfers as one method for data escrow. Both 
procedures are vital to the reliable functioning of the .NET registry and to 
fulfilling this RFP.

Afilias, in contrast, has demonstrated consistent leadership and a strong 
commitment to implementing all ICANN policies. Afilias would continue to do so 
as operator of the .NET TLD, in full coordination with and for the benefit of 
the entire ICANN Community.
   

8. Transition and Migration Plans

Criteria: Applicants should document their plan for (i) migrating .NET from the current registry operator (if applicable) with specific attention paid to maintaining existing functional capabilities as defined at the time of the RFP, including the existing RRP and (ii) for implementing support for Version 1.0 of EPP.

Present a detailed plan for the transition of the registry function from the current facilities and services provided by VeriSign, Inc., to the facilities and services you propose. Issues that should be discussed in this detailed plan include:

...  I. Steps of the Proposed Transition

A. Overview

Afilias has developed a comprehensive migration plan for all facets of 
the .NET transition.  Our continued success in moving complex registries to 
our world-class systems - on time and accurately - makes Afilias the only 
registry services provider with the experience and expertise to complete the 
transition of the .NET registry by the July 1, 2005 deadline.

Afilias has developed the migration process, infrastructure, and experience 
gained from by transitioning the .ORG gTLD and several ccTLDs from various 
registry systems to systems we operate and  have designed and operate.  During 
these migrations, we have learned to handle the technical protocol, data 
evaluation, policy, and business needs of each TLD, and migrate the registries 
smoothly and safely.  Afilias has used this experience to create a 
comprehensive transition plan that mitigates the any risks associated with 
moving .NET to a new registry operator.   Afilias already possesses the 
infrastructure and tools to execute gTLD registry transitions, and can already 
easily handle the many complexities involved in the .NET transition. By 
following our plan, registrars will also require much less time and effort to 
complete the process, helping to ensure the stability of  .NET throughout the 
migration project.

Using its experience, Afilias has designed a migration plan tailored to .NET.  
This new system will utilize existing, proven production tools that were used 
in the .ORG migration, which will greatly reduce cutover risk.  Afilias also 
proposeds to offer registrars who that maintain existing proficiency with 
Afilias' EPP 1.0 registry system the ability to bypass certain tests, easing 
their technical and financial burden.

Flexibility is an important factor for registrars.  This plan offers 
registrars the ability to begin using EPP 10 days following the cutover, or 
continue to use RRP as they do today.

Afilias' transition plan for the .NET Top Level Domain consists of five major 
components:

·	The Registry Data Migration: this involves moving the current data set 
that exists at VeriSign to Afilias.

·	The Registry Business Transition: this involves the coordination of 
Customer and Technical Support, providing registrars with the information and 
tools they need to successfully switch to Afilias, setting policies and 
practices for the .NET registry, establishing registrar financial credentials, 
and possible development of additional reporting requirements.

·	The Protocol Transition: this is the switch from RRP to EPP 1.0.

·	The DNS Cutover: This is the switch from VeriSign's name servers to 
Afilias.

·	Registrar Data Model Compliance: this is the change required to move 
the .NET registry from a two-tiered or "thin" contact model to a single-tier 
or "thick" model.

Each of these distinct transformations requires the skills and expertise that 
Afilias has uniquely garnered gained through the multitude of migrations we 
have completed.  We believe it is critical to the stability of the .NET zone 
to make these migration distinctions, and handle each of these items with 
equal care and concern.

B. The Registry Data Migration and Business Transition

The Registry Data Migration consists of moving the registry data from VeriSign 
to Afilias, and loading it into our EPP 1.0 system.  Upon successful 
conversion, registrars will connect to the Afilias systems using RRP (via the 
RRP to EPP Proxy).  The Business Transition involves providing the registrars 
with the tools and information they need to begin transacting with the system 
immediately following the Registry Data Migration.

1. Kick-off Planning Session

Immediately following the contract signature, Afilias will contact VeriSign, 
and conduct a kick-off planning meeting with VeriSign staff.  In attendance 
will be representatives from the Technical Group, the Financial Group, 
Customer Support, Policy and Compliance, as well as the General Business 
Unit.  Afilias and VeriSign staff will follow up as needed.

The Technical Group will work on the physical aspects of the migration:

·	Assessing the current status of the registry data and DNS zone 
information

·	Discuss extract file formats and testing procedures

·	Work out an internal schedule for testing the data cutover process

·	Discuss changes in systems and protocols since the .ORG conversion

The Financial Group will discuss any monetary issues of the migration:

·	Handling of renewals, auto-renewals, transfers, and deletes within 
grace periods.

·	Discuss differences in Redemption Grace Period (RGP) implementations 
and their impact on the registrars.

·	Handling of registrar account balances at time of cutover (including 
NSF accounts).

Customer Support will work together on registrar related issues:

·	Hand-off of current open tickets that will carry over into the new 
system.

·	Internal and registry-relevant items that need to be carried forward.

Policy and Compliance will assure that general policies, and specific policy 
implementations, are documented and provisioned for:

·	Discussion of current registry policies to ensure a smooth transition. 
This may include exploration of VeriSign's unique implementations of IDNs, 
transfer dispute mechanisms, etc.  These will then be explored with the 
Technical Group for continuity and coverage.
·	Review of reserved names, names under lock for legal reasons, etc.

The General Business Unit will work on the corporate aspects of the migration:

·	Discussion on responsibilities of each party

·	Ensuring effective communication between each organization

·	Building the internal project calendar and deliverable sets

·	Discuss access of the current VeriSign .NET OT&E system

·	Discuss connectivity of the parallel DNS system

Timeframe: this will be scheduled immediately, to be completed no more than 3 
weeks following the contract signing.

2. Registrar Outreach 1

Afilias will immediately schedule the first of three web-casts to educate 
registrars on the details of the registry cutover.  This program will be 
followed up by written materials ("Registrar Packet") that will contain the 
cutover instructions and documentation.  This session will discuss the 
following:

·	Short introduction to Afilias

·	Detailed Description of the cutover process

·	Schedule of cutover events

·	Instructions on Registrar cutover requirements

·	Q&A Session

Timeframe: scheduled immediately upon contract signing, and held within 3 
weeks of contract signing.

3. Initial Conversion Design and Coding

Following the outcome of the kick-off meeting, Afilias will begin adjusting 
the conversion systems for the .NET data migration.  Utilizing the existing 
migration code base, only differences between the .ORG system of 2003 and the 
current .NET system will need to be written, greatly reducing the time 
required for this step.

Timeframe: this will begin immediately following the kick-off meeting, and 
last for approximately 8 weeks.

4. Afilias Access to VeriSign OT&E Systems

Our experience with the .ORG migration has shown us that there could be 
potential variances between VeriSign's implementation of RRP and the 
description of RRP in relevant RFCs.  To ensure stability post-cutover, 
Afilias will request access to the current VeriSign OT&E systems for .NET.  
This will allow Afilias to pre-test client RRP toolkits, and test RRP 
functionality.  Afilias would like access to the test environment as a mock 
registrar, with no access to the production VeriSign registry system.

Timeframe: this should be made available within one week of the kick-off 
meeting, and last until two weeks after the cutover. 

5. Begin VeriSign registry and zone file dumps

VeriSign will extract a copy of the .NET data, along with a corresponding DNS 
zone file, and send it to Afilias using a secure transport, with a checksum 
provided each time in a separate file for verification.  Afilias will use this 
data to do initial testing of the conversion code, look for anomalies within 
the data, and refine processes.

Timeframe: this should occur weekly starting within 3 weeks of the kick-off 
meeting, and continue up until the cutover.

6. Setup Parallel DNS Systems

Afilias will use the VeriSign zone files sent during the testing phase to 
setup the .NET zone on our name servers.  We will coordinate zone file updates 
between Afilias DNS and VeriSign DNS systems, and begin initial setup of the 
connectivity between DNS systems.

Timeframe: initial zone setup will begin at contract signing.  Testing to 
commence once the first zone file is received.  Connectivity to begin once the 
results of this topic at the kick-off meeting is finalized.  This parallel 
system will remain in place for 60 days after the DNS cutover.

7. Begin building QA test scripts and procedures

Afilias' QA Team will begin modifying the scripts and procedures used for 
the .ORG conversion to build the test-bed for the.NET  conversion data load.  
These scripts, some automated, some manual, will provide a multi-point 
checklist to ensure the data integrity as it is loaded into the Afilias 
systems.

Timeframe: this will commence after the kick-off meeting, and will continue 
throughout the development cycle.  Final use of these scripts will be during 
the cutover itself.

8. Registrar Outreach #2

A second Registrar web-cast will be conducted roughly 3-4 weeks following the 
first outreach.  

This session will consist of the following items:

·	Any modifications to timelines and/or schedules

·	A Q&A session to answer any registrars questions

·	Clarification on any policies, if needed

Timeframe:  this will occur about 4 weeks after the first outreach program.  

9. Data Migration Test Runs

Upon completion of the full development cycle of the conversion code changes, 
Afilias will use the latest data sent by VeriSign to conduct a series of 
conversion dry runs.  Any anomalies discovered will be analyzed to determine 
if the issue lies within the data, or within the conversion code.  Feedback 
for data issues will be provided to VeriSign immediately.

Timeframe: Test runs will begin once the code changes have been completed, and 
will continue as modifications to the code are required, up until the cutover.

10. DNS population and push tests

Using a zone file provided in the dumps, Afilias will populate name servers 
and test the push back to VeriSign.

Timeframe:  this will commence after the first data dump, and commence until 
the final cutover.

11. Setup of Afilias OT&E servers

Afilias will setup OT&E servers that will allow registrars to test their 
clients.  As the cutover nears, Afilias may populate the OT&E servers with 
actual data provided from the VeriSign extracts, allowing registrars to test 
with their own data.  Those registrars that are currently registering .ORG 
names will not be required to pass an OT&E test for .NET.  Registrars that do 
not currently register .ORG names will be required to pass these test before 
be allowed into production.

Timeframe: the OT&E servers will be made available four weeks prior to cutover.

12. Final Registrar Outreach

The last registrar web-cast for the Registry Data Migration will occur one 
week prior to cutover.  This outreach will include:

·	Any last modifications to the timeline

·	Final Q&A for registrars

·	Any policy changes

Timeframe: scheduled approximately one week before cutover.

13. Contact of Registrars by Customer Support

Any registrar that has not completed the items outlined in the Registrar 
Packet will be contacted by Customer Support beginning two weeks before 
cutover.  This will be done to assist the registrar and make sure that each 
registrar can continue to register names after the cutover has been completed.

Timeframe: this will occur (if needed) beginning two weeks prior to cutover, 
and continue until all registrars have completed the necessary items.

14. VeriSign shutdown and final data cut

To being the cutover, VeriSign will shutdown the .NET registry, and extract 
the data and corresponding zone file.  This will be sent over a secure 
transport to Afilias.

Timeframe: This will commence at the official start time of the cutover.  
Estimated time from the start of the VeriSign shutdown until Afilias receives 
and verifies the data is eight hours.

15. Data Migration

Once the data file is received and verified, Afilias will begin the data load 
into the EPP system (see below for discussion on the RRP to EPP Protocol 
Conversion).  Afilias will notify the registrars as to the status of the 
conversion every 2 hours.

Timeframe: The data load will begin as soon as the data has been verified.  
This step is expected to take approximately 16 hours.

16. Population of DNS zone file and push test

The final zone file will be loaded onto the Afilias name servers, and a final 
test will be conducted to ensure that the zone can be pushed back to VeriSign.

Timeframe: this is expected to take 2 hours.

17. Systems check

After data load, Afilias runs through the QA scripts and procedures developed 
earlier to test the data load.  Only after successful completion of these 
scripts will the system be accepted by Operations for production.  Afilias 
will notify the registrars as to the status of the conversion every 2 hours.

Timeframe: this process is expected to take 8 hours.

18. Afilias Systems Online

Once the systems check is completed, Afilias will open the registrar 
connection pool, and notify registrars that they may begin transactions within 
the registry.

Timeframe: this should take one hour.

C. The Protocol Transition

Afilias' experience with the .ORG transition from VeriSign in 2003 yielded 
valuable knowledge of the intricacies of performing both the Registry Data 
Migration and the Protocol Transition.  By treating these as separate but 
equally important tasks, Afilias was able to minimize the time and costs 
required by registrars, and help ensure a smooth transition.

 Afilias will build on this knowledge base and utilize tools already proven in 
the .ORG transition to further alleviate the work involved by the registrars

During the Registry Data Migration, the registry data from VeriSign will be 
moved from the extracted data format into the Afilias EPP framework, while 
employing the RRP-to-EPP proxy interface to which registrars will connect.  By 
doing this, neither Afilias nor the registrars will need to take an additional 
data transformation step to move registrars to EPP.  In fact, registrars will 
have the flexibility of continuing to use RRP, or to begin using EPP as early 
as 10 days after the Registry Data Migration.  We will use our RRP to EPP 
proxy is described in detail below.

We believe that this is a critical feature of the Registry Data Migration.  It 
allows registrars to use their existing production RRP clients, which helps to 
eradicate the possibility of client code issues.  Our RRP to EPP proxy was 
used during the transition of the 2.6 million .ORG names from VeriSign to 
Afilias'systems, and it performed in excellent fashion.  Removing these 
variables will reduce the amount of time needed for the Registry Data 
Migration.

Afilias will provide additional accommodations to those registrars eager to 
move to EPP.  Afilias proposes not to require an additional OT&E test for 
current .ORG registrars who have already shown a proven ability to transact 
with Afilias' EPP 1.0 compliant registry system.  This will allow registrars, 
if they desire, to begin using EPP after the 10 day initial stability period.

It is important to note that the Protocol Transition involves moving the 
registrars from using RRP to EPP 1.0 - not changing from a "thin" to "thick" 
registry model (which is discussed below).  One of the experiences that 
Afilias has learned from the .ORG migration was that the requirement of pre-
loading contacts while moving to EPP was a large burden on the registrars.  To 
alleviate this, Afilias will run the registry in EPP "thin" mode - with no 
contact pre-loading required at cutover.  Because the data has been loaded 
into the Afilias systems within the EPP framework, no data transformation need 
occur.  This feature will help ensure stability for the registrars as they 
convert to EPP and to isolate any problems the registrars may have.

Using these features, coupled with our experience with transitions, Afilias 
will create a smooth migration from not only registry providers, but to the 
EPP protocol as well.  These migrations, from the point of view of a given 
registrar, are a simple process that minimizes the registrar's effort.

The RRP to EPP Proxy

To facilitate the .ORG Protocol Transition from RRP to EPP, Afilias developed 
an RRP to EPP proxy.  This proxy was successfully used by.ORG registrars to 
continue their operations after the data had been moved from VeriSign to 
Afilias.  Features of the RRP proxy include:

·	The proxy runs completely on the server (Afilias) side of the 
connection.  The registrar currently running RRP only has to change the 
address of the server to connect and begin submitting transactions.

·	There is no additional software that the registrar needs to run to 
immediately begin submitting transactions to Afilias once the data has 
migrated.

·	The proxy communicates to the actual EPP system.  When a registrar 
switches to EPP, there is no additional data conversion that must take place - 
the data is already housed within the EPP framework.

·	Moving a registrar to EPP from the RRP proxy is a trivial matter, 
since no data migration has to occur.

·	The proxy has been tuned to handle for the various differences between 
the published RRP protocol specifications, and the implementation that is run 
by VeriSign.

·	Registrars will move from the RRP proxy to EPP individually.  There is 
no need to setup an additional "RRP to EPP Transition Day" that affects all 
registrations.

·	The modular design of the RRP to EPP proxy allows us to "turn it off" 
once all registrars are on EPP, without adverse affect to the registrars.

Protocol Transition Schedule

Because registrars have the flexibility to operate in either RRP or EPP "thin" 
mode at this stage, there is no need for a "Protocol Transition Flag Day".  
However, it is important to outline the steps required by the registrar that 
currently does not register names for the .ORG zone, and wishes to move to 
EPP.  These steps are handled on a per-registrar basis, and will vary in times 
based on the success to the registrar's code tests.

1. Registrar receives Afilias EPP toolkit and builds / modifies client code.

The toolkit will be made available on Afilias' Web site 
(http://www.afilias.info).  Once registrars download the toolkit, they can 
begin either coding a new client, or to modify their existing clients to use 
the toolkit.

Timeframe: this will vary by registrar, but should not take more than six 
weeks.

2. Registrar schedules OT&E test with Afilias

The registrar should schedule an OT&E test with Technical Support as soon as 
they feel comfortable with a time frame for the completion of their code.

Timeframe: the registrar should allow for a full day of testing for this step.

3. Registrar begins using new EPP client for .NET registrations

Once these tasks are finished, the registrar can access the production EPP 
system.  Afilias will notify the registrar of their access credentials once 
the test has been passed.

Timeframe: two business days.

Finalization of the Protocol Transition

Afilias expects that a large number of registrars will begin to use EPP 
closely following the registry cutover.  Because of this, we expect that 
the .NET zone will be completely transacted using the EPP protocol within six 
months of the cutover. Afilias will monitor the migration of registrars to 
EPP "thin" mode after the Registry Data Migration.  If, after three months, 
Afilias notices that a significant number of registrars are still using the 
RRP protocol, Customer Support will begin additional outreach programs.

These programs will be designed to aide the registrar with whatever help they 
need to make the move to EPP thin.  Afilias will work with the registrar to 
schedule their OT&E date, and even assist them with interpreting the results 
of a failed OT&E test.

Once all registrars are using EPP, Afilias will turn off the RRP to EPP proxy.

D. The DNS Cutover

Because of the sensitivity of DNS resolution, Afilias has chosen to migrate 
the DNS from VeriSign after the Registry Data Migration has been completed.  
This is done to ensure that the stability of the .NET domain is not 
compromised.  At the end of the Registry Data Migration, the Afilias name 
servers will be sending updated information to VeriSign to populate their name 
servers using a secure connection.  This mechanism eliminates the need for a 
critically timed change to the root zone during the Registry Data Migration.

Because the connectivity between VeriSign and Afilias' name servers has been 
established in the Registry Data Migration, it is not required here.  The only 
outstanding items are to move off of the VeriSign DNS servers.  This is 
detailed below.

1. Afilias will send IANA a request to add the Afilias name servers to the 
root zone
After the Registry Data Migration, Afilias will instruct IANA to add the 
Afilias name servers to the root zone for .NET.

Timeframe: Afilias will send the required information to IANA one week 
following the Registry Data Migration.

2. IANA completes the request, and notifies Afilias

Once IANA has completed the request they will notify Afilias.  Afilias will 
verify the inclusion of the name servers in the root zone.

Timeframe: Afilias expects this request to complete in one business week once 
IANA receives the request.

3. Afilias and VeriSign name servers run the .NET zone in parallel
To ensure stabilization of the DNS,Afilias will request that the .NET zone 
will run on both Verisign and Afilias name servers in parallel.

Timeframe: this will run for a period of 30 days.

4. Afilias will send IANA a request to remove the VeriSign name servers from 
the root zone
Once the 30 days has passed, Afilias will instruct IANA to remove the VeriSign 
name servers from the root zone for .NET.

Timeframe: this will occur immediately after the end of the 30 day parallel 
run.

5. IANA completes the request, and notifies Afilias

Once IANA has completed the request they will notify Afilias.  Afilias will 
verify the exclusion of the VeriSign name servers from the root zone.

Timeframe: Afilias expects this request to complete in one business week once 
IANA receives the request.

6. Disconnection from VeriSign

Afilias will notify VeriSign that the connection between name servers will be 
removed, and they may exclude the .NET zone from their name servers.

Timeframe: this will occur one week after IANA removes VeriSign from the zone.

E. Registrar Thick Model Compliance

Afilias does intend to move the .NET registry to a "thick" EPP model, where 
the registry itself contains all of the contacts for a domain.

During the .ORG migration, registrars were required to upload their contacts 
immediately before switching over to EPP.  Afilias has used its experience in 
the .ORG migration to improve the transition plan for .NET, proposing that 
registrars have the flexibility of uploading contacts at their leisure.  This 
step reduces the time required for the actual switchover to the EPP thick 
model. 

Registrars will be able to upload their contacts anytime after the Registry 
Data Migration.  Once a registrar has finished loading contacts, and have 
moved to EPP "thin", they will contact Afilias, and, in a matter of minutes, 
be switched over to EPP "thick".  At that time, all contacts (as discussed in 
Section 2.5.b) will be required for any transactions on a domain.  Registrars 
can make this switch as soon as all of their contacts are loaded.

If a registrar should miss a contact upload, the EPP system, now in "thick" 
mode for them, will simply return an error that the required contact 
associations have not been made for this domain.  The registrar can then 
upload the missing contacts, associate them to the domain, and continue normal 
operations.

This is discussed in greater detail in the sub-section III.


...  II. Extent of Registry Interruption

A. Registrations

Afilias will take every precaution up front to ensure a safe, stable 
transition.  To this effect, registrars will not be allowed to connect to 
either VeriSign or Afilias during the actual cutover process.  This process, 
as currently presented above, is expected to take 33 hours.

B. WHOIS

VeriSign will be expected to maintain the WHOIS servers until Afilias comes 
online.  Once online, VeriSign should begin sending "referrals" to the Afilias 
servers.

C. DNS

DNS updates will not occur while the registry is being cutover.  This is 
expected to be 33 hours.  Because of the separate DNS Cutover plan, resolution 
will not be interrupted in any way, and the switch to Afilias name servers 
from VeriSign can occur in a controlled fashion.


...  III. Moving From Thick to Thin

Afilias plans to move the current .NET registry to an EPP thick model.  
However Afilias proposes to decouple the requirement for thick data from the 
conversion to EPP. Registrars can first concentrate on their EPP clients, and 
then work on uploading contacts to the registry at a later date.  Again, 
Afilias will complete this step on per-registrar basis, eliminating the need 
for a "Thick EPP Flag Day".  Registrars have the ability to operate in EPP 
thick mode (associating contacts to domains) as soon as 10 days after the 
Registry Data Migration has completed, but it will not be required until after 
the registrar switches to EPP Thick Only Mode.

The transition to thick EPP for a given registrar will occur as follows:

A. Registrars begin uploading contacts

Registrars can begin uploading contacts as soon as 10 days after the Registry 
Data Migration has finished.  No contact with Afilias is required.

Timeframe: uploading can start immediately after the initial stability 
period.  The time it will take to upload contacts will vary by registrar.

B. Registrar contacts Technical Support to switch to EPP Thick Only mode

Once all contacts have been uploaded, the registrar will contact Technical 
Support, who will switch them over to EPP Thick Only mode.

Timeframe: this will take a few minutes.

Afilias expects the entire process for all registrars to be finished within 18 
months of the completed Registry Data Migration.  Afilias will monitor the 
progress of registrars in uploading their contacts, and may work with them to 
schedule their date to switch to EPP Thick Only Mode.


...  IV. Contingency Plans

By creating a transition plan that migrates registrars from RRP to EPP and 
from thin to thick on a per-registrar basis, many of the stability concerns 
for much of the process is greatly alleviated.  The following outlines, step 
by step, how we will ensure that this transition follows in the footsteps of 
Afilias' previous successful migrations.

A. Contingency Plans for the Registry Data Migration

1. Kick-Off Meeting

In the event that the kick-off meeting cannot occur as scheduled, it will be 
re-scheduled as soon as possible, or, if assembling all of the required 
personnel on both teams is not feasible, then each group will try to schedule 
their own meeting.  As a last resort, a phone conference between groups can be 
scheduled.

Risk: LOW

2. Registrar Outreach Web casts

In the event that a Web cast needs to be rescheduled, it will be done within a 
reasonable timeframe.  If there exists technical difficulties that cannot be 
overcome by that time, then the materials from the Web cast will be sent to 
each registrar, and a conference call will be used instead.  If even this 
cannot be accomplished within the timeframe needed to meet the schedule, the 
cutover schedule will be altered.

Risk: LOW

3. Initial Conversion Design and Coding

If substantial problems arise during the conversion code writing and / or 
testing that prolong the readiness of the code beyond the scheduled timeframe, 
then the schedule will be shifted to allow for the code changes to be 
completed.

Risk: MEDIUM

4. Afilias' access to VeriSign OT&E servers

If VeriSign cannot supply Afilias with access to their OT&E systems for .NET, 
then Afilias will request a registrar toolkit from VeriSign to test with.  If 
even this cannot be provided, then Afilias will rely on the RRP protocol 
information provided from the kick-off meeting, as well as the current RRP 
proxy setup that was used for .ORG.

Risk: LOW

5. Begin VeriSign registry and zone file dumps

If VeriSign cannot provide registry and corresponding zone file dumps on a 
timely basis, then the schedule will be pushed back until such time that 
VeriSign can send the requested data.

Risk: LOW

6. Setup Parallel DNS Systems

If Afilias cannot setup the .NET zone as planned, the schedule will need to be 
pushed back until this task can be accomplished.  If the connection between 
Verisign and Afilias servers cannot be provided on a timely basis, the 
schedule may be modified.

Risk: LOW

7. Begin building QA test scripts and procedures

If QA is having difficulty producing adequate testing scripts, they will 
consult with Afilias development, and / or VeriSign personnel for assistance.  
If the scripts are not ready by the time they are due, then the schedule will 
be changed to reflect the completion of the scripts.

Risk: LOW

8. Data Migration Test Runs

The first few of these test runs are expected to fail, as development works on 
the cutover process.  However, if the data should appear inconsistent between 
runs, the anomaly will need to be corrected before the final cutover.  Failure 
to do so will result in a schedule change.  If the problems occur within the 
conversion code, then Afilias Development will examine the code, and 
troubleshoot the problem.  If a timely fix cannot be found, then the schedule 
will be modified.

Risk: LOW

9. DNS population and push tests

If the .NET zone cannot be populated on the Afilias servers during the testing 
phase, or the push to VeriSign is not successful, then the schedule will need 
to be changed.

Risk: MEDIUM

10. Setup of Afilias OT&E servers

If the OT&E servers cannot be brought online, then the schedule will need to 
shift.  If the servers can be brought up, but the current registry data cannot 
be loaded into the OT&E system, the process will continue without a schedule 
change.

Risk: LOW

11. Contact of Registrars by Customer Support

If a current .NET registrar has not completed all items required, and Customer 
Support is not able to contact or convince them to complete the work, the 
cutover will continue.  If, at the time of cutover, the registrar is still not 
finished, they will be denied entry into the Afilias systems.

Risk: LOW

12. VeriSign shutdown and final data cut

If VeriSign is not able to either shutdown the current system or extract the 
registry and corresponding zone file data in a reasonable amount of time, then 
Afilias will either delay or postpone the cutover.  If postponed, Customer 
Support will immediately notify the registrars of the situation.

Risk: LOW

13. Data Migration

In the event that the data migration is falling behind or has an unforeseen 
problem, Afilias management will decide to either keep going, or to postpone 
the migration.  If postponed, Customer Support will immediately notify the 
registrars of the situation.

Risk: MEDIUM

14. Systems Check

If the system checks continue to fail, Afilias will make the decision to delay 
or postpone the cutover.  If postponed, Customer Support will immediately 
notify the registrars of the situation.

Risk: MEDIUM

15. Afilias Systems Online

If after the conversion Afilias cannot bring the system online, then 
management will decide to delay or postpone the cutover.  If postponed, 
Customer Support will immediately notify the registrars of the situation.

Risk: LOW

16. DNS Cutover

In the event that IANA cannot make the changes required in the root zone, 
Afilias and VeriSign will leave the DNS servers as they are, and wait until 
IANA can make the necessary changes.

Risk: LOW

17. RRP to EPP Protocol Transition

Because the work of moving the data into the EPP framework is done during the 
Registry Data Migration, the risk is minimized to a single registrar at a 
time.  In the event that a registrar has a problem using EPP that they are 
having trouble resolving, they can continue to access the registry via RRP.

Risk: LOW

18. Registry Model Migration

This step is completed individually with each registrar, and therefore the 
risk is mitigated to a single registrar at any given time.  If the registrar 
is having problems uploading contacts, they can work through the problem with 
Technical Support until the problem is resolved, and continue to register 
names using the EPP "thin" model.

Risk: LOW


...  V. Transition Effects

The carefully designed transition plan has been developed to minimize any 
negative impact on the .NET community.

Afilias has included knowledge and feedback from our customers during the .ORG 
migration that indicated that coupling the migration of both protocols and 
registry models simultaneously was very challenging.  This new transition plan 
for .NET eases the burden of the .NET registrars immensely, by:

·	allowing them to use their current RRP code after the Registry Data 
Migration switch over
·	giving them the flexibility to use RRP, EPP thin, or EPP thick almost 
immediately
·	no longer requiring an OT&E test for current .ORG registrars
·	letting registrars switch to an EPP without pre-loading contacts
greatly increasing the time to load contacts and move to a "thick" model

Once the authoritative data for the zone resides at the registry, it will no 
longer be technically necessary for .NET registrars to run their own WHOIS 
servers.  End users will be able to get all WHOIS information from one place, 
instead of following records from the registry to the registrar, as they do 
today.

Our new Service Level Agreements for .NET are stringent, helping to ensure 
uptime for each component in the registry.  This benefits both registrars and 
registrants.

During the Registry Data Migration itself, registrars will not be able to make 
any modifications to the zone.  They may continue to take registrations off-
line from the registry, although this is discouraged by the registry, as those 
names are not guaranteed to be available, the registrar will not be able to 
check the status.  Because of this, registrants may not be able to register 
names during the Registry Data Migration period.

WHOIS and DNS resolution will continue to operate during this time, without 
interruption.  Once the Registry Data Migration is complete, end users will 
get a referral from VeriSign WHOIS servers to Afilias, or users can go 
directly to Afilias WHOIS servers for authoritative domain information.

With Afilias' world class registration to resolution time, end users will be 
able to register domain names, and have them completely proliferate throughout 
the registry systems in seconds - including WHOIS information as well as DNS 
resolution.


...  VI. Cooperation with VeriSign

A. Registry Data Migration

During this process, VeriSign will be consulted for various questions 
regarding the registry data, the zone file, and / or the RRP protocol 
implementation that they are using in production.

Additionally, it will be asked to provide access to the .NET OT&E servers, as 
mentioned above.

Technical Support will work together to address any registry-relevant issues 
that will not be addressed by the cutover.

VeriSign will be asked to provide registry data and corresponding zone file 
test dumps on a regular basis before the cutover.

Written confirmation from VeriSign that both WHOIS and DNS services will not 
be affected in any way when the RRP system is stopped during the cutover.

VeriSign will be asked to operate their WHOIS servers in "referral" mode after 
the cutover, so that any WHOIS requests are re-directed to Afilias' servers.

VeriSign will be required to provide information to help ensure the continuity 
of .NET services that Afilias is required to continue offering.  This may 
include exploration of VeriSign's implementation of transfer dispute 
mechanisms, etc.  

VeriSign will be required to provide essential policy and legal information, 
such as a list of reserved names, lists of names under lock for legal reasons, 
etc.

B. DNS Cut-over

VeriSign will be asked to operate their name servers for a period of time 
after the Registry Data Migration until the DNS Cut-over is completed.  
Connectivity between the two organizations will be required during that time.

C. Contingency Planning
 
Afilias expects VeriSign to cooperate in a transition, as refusing to do so 
would not be in the company's long-term interest.  There is, of course, a 
remote possibility that VeriSign could try to use litigation to slow down the 
process.  If so, Afilias is prepared to work closely with ICANN and its legal 
team to successfully counter any challenge.  For purposes of initial planning, 
Afilias has set aside sufficient funds to be available to defend ICANN's 
decision, if that becomes necessary.  We have also retained Hancock Rothert & 
Bunshoft LLP, a leading California law firm to be ready to provide immediate 
legal assistance to Afilias, should that be required.  If selected as NET 
Registry Operator, Afilias shall dedicate itself to ensuring a swift and 
successful transition.


... VII. Relevant Experience

Afilias has a proven track record of successfully completing registry 
migrations. Afilias completed the largest-ever transition of a gTLD registry 
when it transitioned the .ORG registry on behalf of PIR to Afilias' systems.  
In addition, Afilias has migrated several country code domains.  Our expertise 
in transitioning zones is unmatched and positions Afilias as the most 
competent registry services provider to migrate the .NET TLD.

A.  Register.com Migrations

In February 2003, Afilias transitioned several country code top-level domains 
(ccTLDs) from Register.com's management system, including .AG (Antigua 
&Barbuda), .SC (The Seychelles), and .LA (Lao Democratic People's Republic).

Upon contract signing, Afilias immediately began outreach programs to each 
individual country code manager.  We outlined the migration process, assisted 
with policy setup, and helped define agreements between Afilias, the 
governments' registry operators, and the registrars.  Afilias provided 
technical assistance with the DNS to improve our customers' zone stability and 
security.

The migration process itself involved many of the exact steps outlined in this 
bid.  Successive data dumps were provided by the previous registry provider, 
which we used to build and refine the conversion process.  Each of these 
customers, still operating with us today, enjoy the features of Afilias' world 
class registry system, for a fraction of the time and cost to build and deploy 
themselves.

B. The .ORG transition

In 2003, Afilias facilitated the largest gTLD migration to date - the .ORG 
registry from VeriSign to the Public Interest Registry (PIR).  The Afilias 
Team began early on with months of data preparation, Customer Support 
coordination, and many Registrar Reach-Out programs.

The .ORG transition was conducted in two phases:

The Registry Data Migration

The Switch from and RRP-thin registry to an EPP-thick registry.

On January 25th, 2003, the .ORG registry at VeriSign was shut down, and the 
data was migrated to Afilias.  As in this proposal, the data was loaded 
directly into an EPP system, and registrars connected to the registry using 
the RRP to EPP Proxy (described earlier).  Once the Registry Data Migration 
was complete, Afilias began the task of moving individual registrars to EPP.

Afilias coordinated the scheduling of each registrar to upload the contacts 
for each domain name under their registration.  Once this was complete, the 
registrar was converted over to EPP.  Technical Support handled any problems 
that registrars encountered in this process on a case-by-case basis.  The 
entire registrar base was converted over by December 31, 2003.

C. India (.in)

In December 2004, Afilias migrated India's ccTLD registry from a system run by 
a legacy government operator to a system designed, installed, and operated by 
Afilias.  This migration involved a new EPP SRS running in India, with backups 
in North America.  In addition to the normal challenges posed in a zone 
transition, Afilias personnel worked on-location to ensure that infrastructure 
and equipment were set up in accordance with our rigorous standards.  The 
migration involved a deep analysis of the legacy registry data, during which 
Afilias fixed a number of data issues and imposed additional safeguards for 
the submission, policy compliance, and security of registry data.  Afilias 
also advised the government of India regarding the liberalization of .IN 
registration policies, and implemented those policies in the new SRS,  At the 
time of this writing, the .IN registry is in a successful Sunrise period that 
is paving the way for open registrations.

D.  .HN and .GI Migrations

In 2003, Afilias transitioned the .HN (Honduras) and .GI (Gibraltar) ccTLDs 
from systems run by their respective registry operators to Afilias' systems.   

The migrations involved many of the exact steps outlined in this bid.  
Successive data dumps were provided by the previous registry providers, which 
we used to build and refine the conversion process.  .HN and .GI now uses DNS 
provided by Afilias and UltraDNS.

E. Internal Software Migrations

In addition to migrating zones from external registries and other data 
sources, Afilias has moved its ccTLD customer base from proprietary systems 
onto EPP-based systems.  These transitions involved the same care and customer 
interaction that a full registry migration would entail.  The previously 
mentioned Register.com ccTLDs and .HN were individually migrated in this 
fashion as well as .VC (St. Vincent and the Grenadines), which was running on 
a pre-standard version of EPP.


...VIII. Transition Success

The success of this transition will be measured through several mechanisms:

A. Registrar Feedback Program

The ability for current registrars to be able to immediately perform all 
current RRP and EPP transactions when the registry is cutover will be polled. 

B. Zone File Comparison Test

A comparison of the name server zone files will be conducted after the first 
push to the VeriSign name servers. The only significant changes to the zone 
file should be with changes made after the cutover. This will ensure that all 
names that previously resolved are still in operation.

C. Registration-to-Resolution Test

A set of names will be registered through different registrars by Afilias, and 
the total time until the names resolve in DNS will be measured. This will 
measure the improvement in the domain name registration process as a whole.

D. WHOIS Data Testing

The information within the registry for both RRP and EPP domains will be 
examined (although an EPP name cannot be examined until the first registrar 
goes live with the EPP process) by looking at randomly selected domain names 
both before and after the cutover.

E. Random Domain Sampling

A randomly selected subset of previously registered domains will be tracked 
for a period of one year. This data will be used to assess the typical types 
of transforms that occur during the lifetime of a domain, and how well the 
thick-registry EPP model accommodates these changes.

F. Adherence to Transition SLAs and Specifications

As stated in the various transitions, items such as DNS resolution and WHOIS 
will not be affected.  Any interruption of these services during the migration 
will play a role in the measurement of success of the transition as a whole.

Provide a detailed description of your plan for supporting RRP at the time of transition, for supporting EPP 1.0, and for providing registrars with a smooth, low-cost migration path from RRP to EPP.

As detailed in the previous subsection, Afilias will provide both RRP support 
at the time of transition. After a 10 day stability period, Afilias will also 
make available to registrars the EPP interface.  This period is intended to 
reduce the number of variables to be co-ordinated with registrars at the time 
of the Registry Data Migration.

Our support of RRP will be via Afilias' RPP to EPP proxy, a system used to 
execute RRP transactions for the .ORG zone during its migration in 2003.  
Technical details for the proxy and how it supports RRP are located in Section 
2, and a feature list is included in the previous sub-section.

Afilias was the first gTLD registry to implement an EPP-based registry. Our 
systems currently support an EPP 1.0 compliant environment. Afilias proposes 
to support EPP 1.0 as soon as the Registry Data Migration has been completed 
thereby enabling current .NET registry who have already demonstrated technical 
proficiency with Afilias' .ORG EPP 1.0 environment to their EPP clients 
immediately following the initial stability period.

The Afilias Transition Plan has been carefully designed with the registrar in 
mind to minimize risk and cost of a .NET registry transition to the 
distribution channel.
   

Please check that you have completed all the following steps to ensure you have fulfilled the requirements of the Request for Proposals:

  1. Submitted by wire transfer the application fee
  2. Downloaded and completed all the application materials.
  3. Affirmatively evidenced your agreement to all terms and conditions included in the Request for Proposal.
  4. Printed, signed and sent to ICANN the final copy of your application.
  5. Kept a copy for your records.

When you complete this application and finalize it for sending to ICANN, you will need to confirm the following:

  1. By checking this box the applicant agrees (if selected as the successor registry operator for .NET) to the following:
  2. By checking this box, the applicant certifies that (a) he or she has full authority to make this application on behalf of the applicant and to make and fulfill all agreements, representations, waivers, and undertakings stated in this transmittal form and accompanying materials; copies of the documents demonstrating this authority are attached and (b) all information contained in this application transmittal form and accompanying documents is true, accurate and complete to the best of the person's and the applicant's knowledge and information. The undersigned acknowledges on his or her own behalf and that of the applicant that any material misstatement or misrepresentation (or omission of material information) will reflect negatively on any application.

  3. By checking this box, the applicant acknowledges that there are five parts of the Request for Proposals that have been thoroughly reviewed and considered in their entirety by the applicant. The applicant (or, if there are multiple applicants, each applicant) understands that failure to fully follow instructions or the requirements set forth for each of the documents transmitted with this Application Form will be a factor negatively affecting consideration of this application.

  4. By checking this box, the applicant (or, if there are multiple applicants, each applicant) hereby authorizes ICANN to:
  5. By checking this box the applicant (or, if there are multiple applicants, each applicant) understands that difficulties encountered by ICANN in verifying, elaborating on, supplementing, analyzing, assessing, investigating, or otherwise evaluating any aspect within or related to this application may reflect negatively on the application. In consideration of the review of the application conducted on behalf of ICANN, the applicant (or, if there are multiple applicants, each applicant) hereby releases ICANN (and each of its officers, directors, employees, consultants, attorneys evaluators, attorneys, accountants, and agents, hereinafter jointly referred to as "ICANN Affiliated Parties") from any and all claims by any applicant that arise out of, are based upon, or are in any way related to, any action, or failure to act, by ICANN or any ICANN Affiliated Party in connection with ICANN’s review of this application, investigation or verification, any characterization or description of applicant or the information in the application, or the decision by ICANN to determine the next .NET registry operator. Each applicant further indemnifies ICANN and the ICANN Affiliated Parties from any and all liability to applicant in any way related to or in connection with, any of such matters, provided, however that this shall not diminish any preexisting contractual rights a party may have to challenge such matters.

  6. By checking this box the applicant (or, if there are multiple applicants, each applicant) hereby authorizes ICANN and ICANN Affiliated Parties to publish on ICANN's web site, and to disclose or publicize in any other manner, any materials submitted to, or obtained or generated by, ICANN and the ICANN Affiliated Parties in connection with the application, including ICANN's (or their) evaluations and analyses in connection with the application or ICANN's investigation or evaluation of the application, other than the confidential material included in Part 2, which will remain confidential to ICANN and the independent evaluators. The applicant(s) further certify that it has obtained permission for the posting of any personally identifying information included in the application materials. The applicant understands and acknowledges that ICANN does not and will not agree to keep any portion of the application or materials submitted with the application confidential except for the material specifically identified in Part 2. The applicant (or, if there are multiple applicants, each applicant) grants ICANN and ICANN Affiliated Parties a license to use any copyright or other intellectual property that applicant may have in any portion of the application for this purpose.

  7. By checking this box the applicant (or, if there are multiple applicants, each applicant) hereby gives ICANN permission to use the applicant's name, descriptive materials and/or logo in ICANN's public announcements (including informational web pages) relating to top-level domain space expansion.

  8. The applicant agrees that the applicant information, certified by the undersigned (a) that he or she has authority to do so on behalf of the applicant and, on his or her own behalf and on behalf of the applicant, (b) that all information contained in this proposal is true and accurate to the best of its knowledge and information. The applicant understands that any material misstatement or misrepresentation (or omission of material information) will reflect negatively on any application of which this proposal is a part and may cause cancellation of any selection to operate a registry based on such an application.

Signature: ___________________________________________________________________________
Title: ___________________________________________________________________________
Organization: ___________________________________________________________________________
Date: ___________________________________________________________________________


Please report any problems with this application to
net-rfp@icann.org

© 2005 The Internet Corporation for Assigned Names and Numbers